[Biojava-dev] more release preparations
Scooter Willis
HWillis at scripps.edu
Tue Nov 23 12:04:40 UTC 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