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

Paul Gordon gordonp at cbr.nrc.ca
Thu Sep 16 14:37:47 UTC 2004


Hey Martin,

>   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
>  
>
I agree, we should probably fit the other classes into this hierarchy 
for core classes,
and at least into a contrib folder if it's not core.

>   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?
>  
>
Yeah, we use Ant here too, it's a godsend.  Are there any subprojects that
require fancy compilation, or can we just use a generic task?

>   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.
>  
>
I'm thinking that 95% of users checkout the whole Java archive when they 
fetch
the code.  Also, they usually won't dig deep enough to figure out 
exactly what parts
of the code they are using require what third-party libraries (and hence 
would have
to include all the jars when they wrap up their own MOBY apps).  Then 
you get the
issue of classpaths, and possible conflicts if two sub projects use 
different versions of
the  third party programs. I'm for a libs directory where all the .jars 
are stored, and
probably a README that says which parts of the code use which jars.

>   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.
>  
>
I agree.

>   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?
>  
>
I've got nothing so far, but would like to contrbute a page on MOBY 
object instance creation...

>   With kindest regards,
>   Martin   
>
>  
>




More information about the MOBY-dev mailing list