Depends on what you want to program. If you want to have a collection of objects which are Things & perform a common action on them then annotations are not the way forward.
If you want to have some kind of meta-programming occurring & need a class to be multiple things then annotations are right. There is currently no way to enforce compile time dependencies on annotations & my thinking is that this is right. Annotations should be meta data or provide a way to alter a class in a non-invasive way (think Web Service annotations creating WS Servers & Clients without any alteration of the class). Andy Richard Holland wrote: > Spot on. > > Annotation/interface.... i think Annotation is probably better as you > suggest, but I'd have to look into that. Not sure how it works with > collections and generics. If it does turn out to be a better bet, I'll > change it over. > > With the BioSQL dependencies, take a look at the pom.xml file inside the > biojava-dna module. It declares a dependency on biojava-core. If you want to > add dependencies to external JARs, take a look at biojava-biosql's pom.xml > to see how it depends on javax.persistence. (The easiest way to add these is > via an IDE such as NetBeans, which is what I'm using at the moment). > > cheers, > Richard > > 2008/10/21 Mark Schreiber <[EMAIL PROTECTED]> > >> So if I want to build a BioSQL loader from Genbank then would the >> classes (or there wrappers) in the BioSQL Entity package need to >> implement Thing? Would maven have an issue with that or would it just >> create a dependency on core? (you can tell I've never used Maven >> right). >> >> From a design point of view should Thing be an interface or an >> Annotation? The reason I ask is that it doesn't define any methods so >> it is more of a tag than an interface. >> >> Anyway, my understanding is that I would use a Genbank parser (or >> write one). Write a EntityReceiver interface (probably more than one >> given the number of entities in BioSQL, implement a EntityBuilder >> (again possibly more than one) that implements EntityReceiver and >> builds Entity beans from messages it receives. In this case I probably >> wouldn't provide a writer as JPA would be writing the beans to the >> database. Would this be how you imagine it? >> >> - Mark >> >> >> On Tue, Oct 21, 2008 at 1:52 AM, Richard Holland >> <[EMAIL PROTECTED]> wrote: >>> (From now on I will only be posting these development messages to >>> biojava-dev, which is the intended purpose of that list. Those of you who >>> wish to keep track of things but are currently only subscribed to >> biojava-l >>> should also subscribe to biojava-dev in order to keep up to date.) >>> >>> As promised, I've committed a new package in the biojava-core module that >>> should help understand how to do file parsing and conversion and writing >> in >>> the new BJ3 modules. Here's an example of how to use it to write a >> Genbank >>> parser (note no parsers actually exist yet!): >>> >>> 1. Design yourself a Genbank class which implements the interface Thing >> and >>> can fully represent all the data that might possibly occur inside a >> Genbank >>> file. >>> >>> 2. Write an interface called GenbankReceiver, which extends ThingReceiver >>> and defines all the methods you might need in order to construct a >> Genbank >>> object in an asynchronous fashion. >>> >>> 3. Write a GenbankBuilder class which implements GenbankReceiver and >>> ThingBuilder. It's job is to receive data via method calls, use that data >> to >>> construct a Genbank object, then provide that object on demand. >>> >>> 4. Write a GenbankWriter class which implements GenbankReceiver and >>> ThingWriter. It's job is similar to GenbankBuilder, but instead of >>> constructing new Genbank objects, it writes Genbank records to file that >>> reflect the data it receives. >>> >>> 5. Write a GenbankReader class which implements ThingReader. It can read >>> GenbankFiles and output the data to the methods of the ThingReceiver >>> provided to it, which in this case could be anything which implements the >>> interface GenbankReceiver. >>> >>> 6. Write a GenbankEmitter class which implements ThingEmitter. It takes a >>> Genbank object and will fire off data from it to the provided >> ThingReceiver >>> (a GenbankReceiver instance) as if the Genbank object was being read from >> a >>> file or some other source. >>> >>> That's it! OK so it's a minimum of 6 classes instead of the original 1 or >> 2, >>> but the additional steps are necessary for flexibility in converting >> between >>> formats. >>> >>> Now to use it (you'll probably want a GenbankTools class to wrap these >> steps >>> up for user-friendliness, including various options for opening files, >>> etc.): >>> >>> 1. To read a file - instantiate ThingParser with your GenbankReader as >> the >>> reader, and GenbankBuilder as the receiver. Use the iterator methods on >>> ThingParser to get the objects out. >>> >>> 2. To write a file - instantiate ThingParser with a GenbankEmitter >> wrapping >>> your Genbank object, and a GenbankWriter as the receiver. Use the >> parseAll() >>> method on the ThingParser to dump the whole lot to your chosen output. >>> >>> The clever bit comes when you want to convert between files. Imagine >> you've >>> done all the above for Genbank, and you've also done it for FASTA. How to >>> convert between them? What you need to do is this: >>> >>> 1. Implement all the classes for both Genbank and FASTA. >>> >>> 2. Write a GenbankFASTAConverter class that implements >> ThingConverter<FASTA> >>> and GenbankReceiver, and will internally convert the data received and >> pass >>> it on out to the receiver provided, which will be a FASTAReceiver >> instance. >>> 3. Write a FASTAGenbankConverter class that operates in exactly the >> opposite >>> way, implementing ThingConverter<Genbank> and FASTAReceiver. >>> >>> Then to convert you use ThingParser again: >>> >>> 1. From FASTA file to Genbank object: Instantiate ThingParser with a >>> FASTAReader reader, a GenbankBuilder receiver, and add a >>> FASTAGenbankConverter instance to the converter chain. Use the iterator >> to >>> get your Genbank objects out of your FASTA file. >>> >>> 2. From FASTA file to Genbank file: Same as option 1, but provide a >>> GenbankWriter instead and use parseAll() instead of the iterator methos. >>> >>> 3. From FASTA object to Genbank object: Same as option 1, but provide a >>> FASTAEmitter wrapping your FASTA object as the reader instead. >>> >>> 4. From FASTA object to Genbank file: Same as option 1, but swap both the >>> reader and the receiver as per options 2 and 3. >>> >>> 5/6/7/8. From Genbank * to FASTA * - same as 1,2,3,4 but swap all >> mentions >>> of FASTA and Genbank, and use GenbankFASTAConverter instead. >>> >>> One last and very important feature of this approach is that if you >> discover >>> that nobody has written the appropriate converter for your chosen pair of >>> formats A and C, but converters do exist to map A to some other format B >> and >>> that other format B on to C, then you can just put the two converts A-B >> and >>> B-C into the ThingParser chain and it'll work perfectly. >>> >>> Enjoy! >>> >>> cheers, >>> Richard >>> >>> -- >>> Richard Holland, BSc MBCS >>> Finance Director, Eagle Genomics Ltd >>> M: +44 7500 438846 | E: [EMAIL PROTECTED] >>> http://www.eaglegenomics.com/ >>> _______________________________________________ >>> Biojava-l mailing list - [email protected] >>> http://lists.open-bio.org/mailman/listinfo/biojava-l >>> > > > _______________________________________________ Biojava-l mailing list - [email protected] http://lists.open-bio.org/mailman/listinfo/biojava-l
