Hi Allen, Just to clarify what I'm talking about...
JDO requires enhancement of the pojo classes, which would be done during the build process. That is, the classes in the classpath when testing or running Roller need to be the result of running the enhancer. There's no harm in running the enhanced classes when using either Hibernate or JPA as the persistence back end, but it's not clear that there is a good reason to enhance the classes when using Hibernate or JPA. So it seems that we might want a way to package the enhanced classes only if we're running JDO. (JPA has a similar enhancement requirement, resulting in different enhanced classes).
Hibernate doclet stuff always runs during the build process. When using JDO or JPA this is unnecessary. Right now, there's no upToDate handling so the doclet stuff always runs on every build. This should be improved. I haven't checked on the license of the Hibernate doclet processor to see if it has the same issues that Hibernate runtime does.
Any insight on the build.xml is certainly appreciated. Thanks, Craig On Sep 9, 2006, at 7:29 PM, Allen Gilliland wrote:
Craig L Russell wrote:Hi Allen, On Sep 9, 2006, at 9:42 AM, Allen Gilliland wrote:In order to build the JPOX-required artifacts, we will need the JPOX stuff in the build. It's easy enough to distribute the latest JPOX stuff with Roller. But unless the Hibernate doclet processor has a suitable license, we can't ship it with Roller and so it might be awkward to always pre-process the pojo directory.Craig L Russell wrote:Hi Mitesh,I wonder if you could take a look at the build script and see what we need to do to avoid building the Hibernate metadata and see where we should put the enhancement step for those persistence frameworks that can use enhancement. It would also help if we can rationalize how the runtime artifacts that are now in testdata get copied to build/tests. Maybe we need something that specifies which framework is being run and copies a directory of testdata into build/tests?personally, i don't think we need to adopt an 'either or' strategy for building. there is no reason why the resources for all of the backends can't coexist in the built roller- business.jar file. i suggest just leaving the hibernate stuff alone, leaving those mapping files in place can't cause any harm. then just add whatever is needed for JDO and you should be all set.I don't think there is a licensing problem with the hibernate doclet stuff, but regardless of that I think you are getting ahead of yourself. We are not talking about replacing Hibernate yet, that is a completely separate discussion, lets just stick to the task of setting up a JPA/JDO backend in the sandbox to evaluate.The JDO backend can exist in the sandbox without touching anything related to Hibernate. I will help figure out the easiest way to build the JDO backend from the sandbox and test it in the next couple of days.That would be great. One thing to look at is whether the tests and the runtime both expect pojo classes to exist in the same place.i'll take a look at the testdata directory and see if that can be cleaned up. i know that when i last looked at the tests process i thought there were a few things that could be improved.I'm not sure what that means. Same place as in java package? Or same place as in on the filesystem? In any case, I don't think anything about the building of the pojos needs to change for the build of the JDO backend.-- AllenCraig-- AllenThanks, Craig Craig Russell [EMAIL PROTECTED] http://db.apache.org/jdoCraig RussellArchitect, Sun Java Enterprise System http://java.sun.com/products/ jdo408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
