[Biojava-dev] Where BioJava3 is going

[Mark Schreiber]

Any reason why we couldn't have a maven module where Sequence<C
extends Compound> interface goodness is backed by an Ensembl mapping
beany implementation?  This would seem to me to be the best approach.
That way if you want to use Ensembl and BioJava you could just drop in
the appropriate module.

- Mark

On Thu, May 20, 2010 at 4:53 PM, Andy Yates <ayates at ebi.ac.uk> wrote:
> Changed the subject to something more relevant.
>
> I think this is more exemplified by the current state of the API rather than the intention of where it can go. Scooter's main focus is working towards solid objects to represent entities on Sequence e.g. GeneSequence/ChromosomeSequence are perfect examples of this. My focus is more towards working at the generic level so more programming against Sequence<C extends Compound> interfaces; translation, reversing & complementing strongly points towards this. Between us though I really do hope we can generate a framework which lets a user come in and use the more solid classes but also let another API use the backing classes.
>
> The rest will be coming soon. I am also looking at supporting features and attributes against Sequences but this is still some time off. I'm also looking at coordinate translation but again this is something that is sometime away (mostly because I do not have the test case to do it).
>
> The enemy here is time as I am sure it is for your group.
>
> Probably the best thing I can do is put up some design documents onto the wiki about where I think parts of the API should go and people can pick this to pieces as much as they want to. Interfaces and test cases about intended behaviour would also help. Again this will take time :(
>
> Andy
>
> On 20 May 2010, at 09:30, LAW Andrew wrote:
>
>>
>> On 20 May 2010, at 05:11, Mark Schreiber wrote:
>>
>>> If you are using BioJava objects as fake DTO's or EntityBean
>>> look-a-likes you should really question why you are using BioJava
>>> objects in the first place. Not sure what BioJava3 objects will look
>>> like but BJ1.X objects are definitely not good at this.
>>>
>>> It also raises and interesting point which I haven't seen discussed
>>> much on the list; what will BJ3 be for (or not for). One of the
>>> painful lessons (for me) from working on BioJava is you can't make an
>>> API do everything. The more modular approach to BJ3 should help avoid
>>> this. I see nothing wrong with having a module that is more suitable
>>> for the kind of work sequence-data-binding you are proposing. This
>>> modules objects should definitely have public constructors and public
>>> setters. Why not make use of Entity Beans (Post EJB 3) while your at
>>> it. If it is in it's own module it will not corrupt the other parts of
>>> BioJava with "unsafe" beany objects.
>>>
>>> In this case making your own objects (and sharing them) would actually
>>> be a whole lot better than trying to shoe horn an API that wasn't made
>>> for this. Some IDEs will even auto-generate databinding objects for
>>> you; although, I understand there is some strange cases in Ensembl
>>> that might not make this a good idea).
>>
>>
>> I think this is really the point that we have been picking at all along. The current way that BJ3 objects seem to be set up makes them difficult to use in any manner other than that intended by the core BJ3 developers. We were hoping that there would be all the generic sequence and coordinate transformation "goodness" available for us in a bean format and then all we would have to do (!!) would be to define the data access methods necessary to populate those objects. That seems to be not the way that things are set up and mapping our ideas and thought processes to BJ3 has not been as easy as we would have liked.
>>
>>
>>
>> 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.
>>
>>
>>
>>
>>
>>
>> --
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
>>
>> _______________________________________________
>> biojava-dev mailing list
>> biojava-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/biojava-dev
>
> --
> Andrew Yates                   Ensembl Genomes Engineer
> EMBL-EBI                       Tel: +44-(0)1223-492538
> Wellcome Trust Genome Campus   Fax: +44-(0)1223-494468
> Cambridge CB10 1SD, UK         http://www.ensemblgenomes.org/
>
>
>
>
>