openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@bea.com>
Subject RE: Repository structure
Date Thu, 04 May 2006 16:31:30 GMT
Comments inline.

> Before you check in code, it would be nice to discuss the 
> directory structure to facilitate development, release, and 
> documentation.

Agreed, but given how long it's taken me to get to this point, I'm not going
to hold up check-in for that purpose. So some of this work might have to
take place after check-in. Happily, svn is move-intelligent.

> It would also be good to decide what build tool to use. I 
> personally like maven for a project as complex as this one. 
> Especially if it depends on other projects (e.g. antlr, logging, etc).

We currently use ant and manually maintain our dependencies. I can see that
maven could be something to move to at some point, but again I want to lower
the bar to getting the source into svn as far as possible.

> docs/ everything that is used to display the site index.html 
> the main page downloads.html images/ images used on the site 
> team.html the development/test/doc team members releases/ 
> pages for downloading releases ... other site pages

Just for clarification, this is just the project HTML etc, and not the
documentation for the product itself, correct? Clearly, the product docs
need to live in the trunk alongside the code so that it can be branched etc.
along with its corresponding code.

> trunk/
> core contains the kodo core
> spec contains the jsr220 jar artifacts from the spec 
> ejb contains the ejb container interface 
> se contains the java se implementation

FYI, I avoid the word 'core' like the plague, since I still see the
occasional core dump. The structure that we've got so far looks like:

util/ 	general utility (XML processing, logging, annotation utils, etc.)
kernel/ 	the Broker interface etc. What you're calling core.
jdbc/ 	the JDBC back-end. Kodo has very clean separation between different
back-end types; there is no JDBC-related code in kernel.
jpa/ 		the JPA bindings to the Broker
jpa-jdbc 	the JDBC-related JPA bits

What do you anticipate in a Java SE implementation? Also, currently Kodo
does not do any EJB container integration per se. What are you anticipating
there? IOW, what do you see living under the EJB container interface area?

> core/ structure is repeated for each sub-project under trunk 
> src contains the sources for the core jar test contains the 
> test cases for the core target contains the compiler output, 
> distribution working area, javadoc, etc.
> 
> src/
> java source code for the jar

Kodo can run on a variety of JDK versions, from 1.3 up to 1.5 (and beyond,
presumably). So we actually have different src/ directories for code that
relies on different language levels: src/, jdk1.4-src/, jdk1.5-src/.
Probably wouldn't hurt to change these names to src-1.3, src-1.4, src-5, for
happy tab-completion and symmetry.

> test/
> java source code for tests

See comments above for JDK versioning.

> xml xml configuration files for testing

Ours is called 'conf' and contains both XML and properties files. 

> sql contains sql scripts for building test schema 

Happily, we won't need one of these: Kodo's mappingtool is responsible for
this.

> testdata contains test data files

What are test data files, and why do they live somewhere other than next to
the tests themselves?

-Patrick
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

Mime
View raw message