openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Repository structure
Date Thu, 04 May 2006 19:01:12 GMT

On May 4, 2006, at 9:31 AM, Patrick Linskey wrote:

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

Having the directory structure roughly correct will help a lot. More  
detail below.
>> 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.

That's fine. It should be possible to create maven build instructions  
parallel to ant.
>> 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?

Right. It's the site that comes up when you click on

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

I just made up some stuff. I don't mind what names are used.

> 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
I suppose that each of these projects results in its own jar file for  

> What do you anticipate in a Java SE implementation?

You have the implementation of the SE contract that is different from  
the Java EE container contract. The bootstrapping interaction with  
the Persistence class is different, as I recall.

> Also, currently Kodo
> does not do any EJB container integration per se. What are you  
> anticipating
> there?

There are some implementation artifacts that only apply to Java EE  
containers. So the project would have to depend on EE jar files,  
which you clearly don't want for the Java SE project.

> IOW, what do you see living under the EJB container interface area?

Only those java classes that depend on EE interfaces.
>> 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.

How do you package these? I could imagine that the jar files contain  
all the classes and they are dynamically selected at runtime based on  
the environment you are running in. But do you have to have a high  
level directory structure for these, or can they have different  
package names and the build scripts would be different for the  
specific files.

But setting up multiple src-xxx directories parallel to src might be  
a problem for maven.
>> 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.

How do you test mapping from SQL to Java? Is Kodo's tool sufficient  
to generate all possible SQL DDL that you support?
>> testdata contains test data files
> What are test data files, and why do they live somewhere other than  
> next to
> the tests themselves?

There are a bunch of test data files that are used by multiple tests  
in the directory structure, and anyway, all the files in the src/java  
and test/java directories are java. Other files are in different high  
level directories.

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

Craig Russell
Architect, Sun Java Enterprise System
408 276-5638
P.S. A good JDO? O, Gasp!

View raw message