[Biojava-dev] maven progress

[Andreas Prlic]

Thanks, Andy
I will try to chase up the calls and make sure they get properly
synchronized. Not sure why those issues did not get detected already
earlier!

The broken file paths I am aware of. That has to do with me moving the
files around to make the organization of the directories maven
standard compliant. probably will get fixed by tonight (west coast)
...

Andreas



On Tue, Sep 1, 2009 at 9:30 AM, Andy Law (RI)<andy.law at roslin.ed.ac.uk> wrote:
>
> On 1 Sep 2009, at 15:37, Andreas Prlic wrote:
>
>> Hi Andy,
>>
>> this repository location is ssh protected.  Anonymous checkouts are
>> possible via
>>
>> svn://code.open-bio.org/biojava/biojava-live/biojava
>
>
> OK. I've got a checkout from there thanks.
>
> I trip up over a dependency on bytecode version 3.0. That will need to
> either be incorporated into the tree or published to maven central before
> the system works as it should (version 1.5 is on the maven central repo but
> I couldn't find a later version)
>
>
>
>>>>
>>>> At the moment I am chasing an "interesting" problem. When I run the
>>>> junit tests on the new core module in eclipse, they run fine.   When I
>>>> do the same via a mvn test I get several issues like the one below.
>>>> Anybody got an idea?
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------------------
>>>> Test set: org.biojava.bio.seq.project.ProjectedFeatureHolderTest
>>>>
>>>>
>>>> -------------------------------------------------------------------------------
>>>> Tests run: 6, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.036
>>>> sec <<< FAILURE!
>>>>
>>>>
>>>> testFeatureChangeEvent(org.biojava.bio.seq.project.ProjectedFeatureHolderTest)
>>>> Time elapsed: 0.011 sec  <<< ERROR!
>>>> java.lang.AssertionError: firePreChangeEvent must be called in a
>>>> synchronized block locking the ChangeSupport
>>>>       at
>>>>
>>>> org.biojava.utils.ChangeSupport.firePreChangeEvent(ChangeSupport.java:281)
>>>>       at
>>>>
>>>> org.biojava.bio.seq.projection.ReparentContext$PFChangeForwarder.preChange(ReparentContext.java:299)
>>>>       at
>>>>
>>>> org.biojava.utils.ChangeSupport.firePreChangeEvent(ChangeSupport.java:297)
>>>>       at
>>>>
>>>> org.biojava.bio.seq.impl.SimpleFeature.setLocation(SimpleFeature.java:173)
>>>>       at
>>>>
>>>> org.biojava.bio.seq.project.ProjectedFeatureHolderTest.testFeatureChangeEvent(ProjectedFeatureHolderTest.java:297)
>>>>
>>>
>>>
>>> That's certainly not one that I've ever seen, but then I probably don't
>>> write code that is as complicated as BioJava :o}
>>>
>>> If I could get a checkout (see above) then I would try it out in NetBeans
>>> to
>>> see if it is something that Eclipse is doing to "protect" against the
>>> synchronisation problem. But I can't get the code so I can't test it :o{
>>>
>
>
>
> Thos error messages *do* appear when running the tests from inside Netbeans,
> so clearly something that Eclipse is doing must be hiding the errors from
> you :o}
>
> From what I can tell, there are instances in the code that fire off
> preChange()/postChange() in ChangeListeners without first locking down the
> ChangeSupport object (whatever that is - this is the first real delve that
> I've had in the BioJava guts).
>
> For example, SimpleSequence.java contains a private class called
> FeatureForwarder that implements ChangeListener (lines 322:332)
> This currently reads:
>
>    private class FeatureForwarder implements ChangeListener {
>      public void preChange(ChangeEvent cev)
>      throws ChangeVetoException
>      {
>        getChangeSupport(cev.getType()).firePreChangeEvent(cev);
>          }
>
>      public void postChange(ChangeEvent cev) {
>        getChangeSupport(cev.getType()).firePostChangeEvent(cev);
>          }
>    }
>
>
>
> I think that it *should* read something like
>
>    private class FeatureForwarder implements ChangeListener {
>      public void preChange(ChangeEvent cev)
>      throws ChangeVetoException
>      {
>          ChangeSupport cs = getChangeSupport(cev.getType());
>          synchronized(cs) {
>        cs.firePreChangeEvent(cev);
>          }
>      }
>
>      public void postChange(ChangeEvent cev) {
>        ChangeSupport cs = getChangeSupport(cev.getType());
>          synchronized(cs) {
>        cs.firePostChangeEvent(cev);
>          }
>      }
>    }
>
> and when I change my local copy to this, the problems go away (for at least
> one section of the tests). I still get the same error cropping up in other
> parts (where the code funnels through different ChangeListener
> implementations which all have the same style as the first version above but
> that, I guess, is to be expected.
>
> There are test problems relating to file paths too - but I presume that you
> knew that stuff already.
>
> Later,
>
> Andy
> --------
> Yada, yada, yada...
> The University of Edinburgh is a charitable body, registered in Scotland,
> with registration number SC005336
> Disclaimer: This e-mail and any attachments are confidential and intended
> solely for the use of the recipient(s) to whom they are addressed. If you
> have received it in error, please destroy all copies and inform the sender.
>
>
>
>