[MOBY-dev] Java developers, let's talk together

[Martin Senger]

Hi, all,
    We all know that OpenSource is a wonderful idea, and we like it. But 
sometimes the end users (in our case those who are going to use our Java 
libraries) may be confused if there are too many styles involved. I am not 
talking about the coding style - that's usually hidden and as long as it 
does what it says it does, who cares - but about the style how our code is 
deployed and used. I think that our code may provide better service if we 
can follow - when and where possible - similar principles.
   Can we, therefore, have here a chat about these principles? I do not 
want to be seen as an intruder and a dictator (even though I am both), and 
the things I am going to list here (below) are just issues for comments, 
nothing more.
   Also, I am talking about things that are part of the moby-live CVS, not
about code provided by individual service provider - unless this code is
also part of this CVS. Also, I concentrate only on MOBY-S - but it would 
be nice to apply similar principles for both MOBYs - so, Gary, please your 
comments are also valuable.

   1) Package names. It does not matter where the Java code is in the CVS
module (because one can partition things either by language, or by topic,
and both approaches can be mixed) but it would be nice if the Java package
names reflected what the code deals with. I started with names (I hope 
with obvious meanings - if not I am ready to explain):
   org.biomoby.client
   org.biomoby.shared
   org.biomoby.registry
   org.biomoby.service

   Others started their own package names:
   ca.icapture.moby
      Does this mean that the code is owned by somebody else? BTW, there
is no source for this package in the current CVS (just binaries). I
strongly feel that the biomoby CVS should have source code for everything
unless it is clearly labelledf as third-party library. Is this such case? 
   org.mobycentral...
      I think that this actually belongs more to org.biomoby.client - 
because it does not implement mobycentral funtionality (in which case I 
would recommend to use org.biomoby.registry, or org.biomoby.central...) 
but it implements new ways how to access the registry. But I am not sure.

   2) Building. What about to use Ant? :-) At the moment, some subprojects
does not support much re-building by other users. Such support should be a
primary rule for an open source project. Or am I too autocrative here?

   3) Third-party libraries (the ones we have only as jar files).
   There is no single solution. We may have them as part of the CVS, or 
let Ant download them when a user is re-building.
   If we have them as part of moby-live CVS:
   - it is always sure that after 'cvs co' you have everything and in 
correct version
   - the CVS can be huge (as it is now) and many users will use just a 
small sub-part (like perl users) but they still need to check-out 
everything.
   Almost opposite arguments apply for not to have them here. Open 
question...
   But I feel that having the same third-party libraries in several places 
within the same project (Ed?) does sound good.

   4) Generated documentation. I think that Java API that is generated 
from Java code should not be part of the CVS. It is anyway a paint in the 
neck to keep it sync with the CVS. The build procedures (Ant, hopefully) 
should be able to generate it for each user when [s]he is re-building.

   4) Documentation. I hope to have one BioMoby Java starting page from
where Java users can go to all Java-based subprojects. I will update the
current jMoby pages (if you do not mind) - but could you send me the text
you would like to be added at the starting page and pointing to 
yoursub-project please?

   With kindest regards,
   Martin   

-- 
Martin Senger

EMBL Outstation - Hinxton                Senger at EBI.ac.uk     
European Bioinformatics Institute        Phone: (+44) 1223 494636      
Wellcome Trust Genome Campus             (Switchboard:     494444)
Hinxton                                  Fax  : (+44) 1223 494468
Cambridge CB10 1SD
United Kingdom                           http://industry.ebi.ac.uk/~senger