Craig L Russell wrote:
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).
I don't know what you mean by "enhanced pojos". What does it actually
do to the classes? If you actually need to modify the pojo code then
that basically means you'll have to work out of a special JDO branch
rather than just out of the sandbox, because we don't want to change
code that is going into the released Roller build. If it doesn't
require changing the pojo code then I don't see what the problem is,
just enable the enhancements for the build you are planning to use JDO
with and don't worry about making it to run Hibernate from the same build.
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.
right, the Hibernate stuff is supposed to be generated each time the
business layer is built because it's a critical part of the business
layer and there isn't a way to only run it if a pojo has been changed.
it only takes a matter of seconds on a decent machine, so i don't think
it's a big deal to just leave it. it doesn't harm anything, so why mess
with it. and i am pretty sure it's not a licensing issue for a couple
reasons 1) we don't actually distribute it, it's a build tool only and
2) it's not part of hibernate, it's from xdoclet.
Any insight on the build.xml is certainly appreciated.
i did a JDO build earlier today and didn't have any problems with it.
all you need to do is uncomment the lines about the jdobackend from the
custom-jars.xmlf and custom-beans.xmlf files in the custom directory,
like we talked about in the hackathon. then just add this to the
roller-custom.properties file in the testdata directory ...
persistence.roller.classname=org.apache.roller.business.jdo.JDORollerImpl
after that you can just run the build script target 'test-business' and
you are all set. although, the current code won't work because there is
no JDO config or mapping files. once those are available then
everything should work.
-- Allen
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:
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.
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.
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.
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.
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'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.
-- Allen
Craig
-- Allen
Thanks,
Craig
Craig Russell
[EMAIL PROTECTED] http://db.apache.org/jdo
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!
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!
