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

[Nina Opushneva]

 Hi 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
> 

You are definitely right regarding the package name
convention. I didn’t find any rules for that, so I
used my own. Sorry about that, I’ll change the package
names. From my point of view the RDF Agent logically
belongs to the registry. Will be the
org.biomoby.registry.rdfagent as a RDF Agent’s base
package name ok?


>    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?
> 

Agree. I’ll develop an ANT build file for the RDF
Agent and will commit it to the CVS with source code.

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

Location for the third-party libraries is real issue.
I think we should discuss that altogether with
subproject directory structure. I would suggest
following:

…
 |
 subroject name
  |
  + doc
  +config
  + lib
  + src
  |
  Manifest.mf
  readme
  build.xml
  build.sh
  build.bat
  run.sh
  run.bat

This structure provides good subproject encapsulation
and resolves libraries’ version conflict problem. Main
disadvantage –duplicate some libraries. As a result
less efficient use of  the server disk space and some
extra traffic. I think that easy subproject’s
sourcecode / libs administration is much more
valuable. To put all libraries in the same place could
become a nightmare for the project
support/administration especially if keep in mind that
a jar file name means nothing. Two jars with the same
name could have absolutely different content and/or
library versions. 



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

Agree. An ANT build file should have task “generate
JavaDoc” or similar.


>    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?
> 

It is a very good idea. I will prepare the text and
send it to you as soon as I can.

Best regards,

Nina Opushneva


		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com