[Biojava-dev] more release preparations

Scooter Willis HWillis at scripps.edu
Tue Nov 23 07:04:40 EST 2010


George

Features are still a work in progress where you can assigned a generic feature to a location. Basic functionality in place where I would rather have concrete features for as many well defined attributes of a sequence as possible. I was not planning on doing any change/veto/event firing when features are adjusted. I do have FeatureListener code in the biojava3-sequence-gui that when you click on a Feature listeners are notified. My current plan is to try and support XML data attributes as Features for a sequence found in a uniprot.xml file for proteins. I am also doing work with GFF3/GMOD for an internal project so I want to support Features that can be found in a GFF3 file for DNA sequences. Trying to use existing/established data elements to drive the design/api.

Let me know what you need in the way of Changeable as a use case and will see if it is something I can put together. I do want to minimize the api complexity and adding Changeable/Veto logic can get complicated for both the developer and the user.

Thanks

Scooter



On Nov 23, 2010, at 1:24 AM, George Waldon wrote:

> Hi Scooter,
> 
> Talking features, is-there an equivalent for  
> org.biojava.utils.Changeable in bj3? And for ChangeEvent? What type of  
> events are fired in bj3?
> 
> George
> 
> Quoting Scooter Willis <HWillis at scripps.edu>:
> 
>> Andreas
>> 
>> Sounds like a plan. It would be interesting to do a table of what  
>> features are supported in 1.7 and 3.0 as a guide.
>> 
>> Scooter
>> 
>> On Nov 20, 2010, at 7:38 PM, Andreas Prlic wrote:
>> 
>>> Hi,
>>> 
>>> A while ago we discussed what to do about the legacy code that is
>>> still in SVN (in particular the old core module). Last time we had a
>>> discussion about this, the general consensus was that it should be
>>> taken out of the release to avoid confusion. I am not fully happy to
>>> just delete this code, since there will probably be one or two
>>> features that we don't have in 3.0 yet.  As such I propose the
>>> following procedure:  I will create a new project on the same level as
>>> biojava-trunk. It will be called biojava-legacy and it will contain
>>> anything that is code from 1.7 or depends on it. This way we can
>>> easily move features from the legacy project into the main release, if
>>> we realize something is missing.
>>> 
>>> Any thoughts / objectons?
>>> 
>>> Andreas
>>> _______________________________________________
>>> biojava-dev mailing list
>>> biojava-dev at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/biojava-dev
>> 
>> 
>> _______________________________________________
>> biojava-dev mailing list
>> biojava-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/biojava-dev
>> 
> 
> 
> 




More information about the biojava-dev mailing list