> > 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 packaging?
Not currently, but certainly that's the goal, and certainly there are hard dependenies between them. > > 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. The Java SE stuff is actually available both inside and outside the container. So we've got the Java SE stuff in the 'jpa' module. The Kodo team has not built anything for the container contract; Kodo just consumes a PersistenceUnitInfo, which can be provided by Kodo's bootstrapping / parsing or by a container. > > 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. Gotcha. We actually put that stuff into a sub-package in core; there isn't much to that glue. I could imagine having it separate, but seems kinda silly to have a separate module for like 5 classes that are highly coupled to a different module anyways. There aren't any JPA-specific Java EE-only constructs in Kodo, actually. All the Java EE constructs are at the broker / kernel level. Of course, we at BEA have implemented a container binding, but that's a BEA-specific thing. Similarly, you could imagine the Spring guys building a container binding etc. > >> 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. We actually just bulid into a single build path and overlay the package structure currently. We ensure that we do not load the 1.4-specific or 1.5-specific code unless such a VM is available. > But setting up multiple src-xxx directories parallel to src > might be a problem for maven. So much for Maven then... > > Happily, we won't need one of these: Kodo's mappingtool is > responsible > > for this. > > How do you test mapping from SQL to Java? I believe that we create a schema from an XML representation of the schema which we store parallel to the test case. > Is Kodo's tool > sufficient to generate all possible SQL DDL that you support? Naturally. > >> 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. Ah. We don't have a src/java or test/java concept; we just have a package structure in each location and store additional resources relevant to particular sources / tests in the package structure next to it. We do this basically to reduce the amount of switching around between directory trees to locate given files. -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.
Description: S/MIME cryptographic signature