David,
> Actually, OFBiz doesn't do any searching around, everything on the classpath
> is configured very explicitly, mostly through the ofbiz-component.xml files
> for runtime, and through build.xml file for the build.
All the more why it's a good idea to get every module's ofbiz-component.xml to run off of
/runtime, and to get build.xml to build into /runtime.
But, if I didn't misunderstand, I do get your point about "polluting" the module-specific
ofbiz-component.xml(s) with lots of "../..", and we might make the mistake of putting one too many
".."(s). We could get ComponentConfig to automatically prepend
"../../runtime/build/<component-name>/" (eg "../../runtime/build/manufacturing/") to every
classpath element specified. How's that?
Anyway, the build.xml files already have "../.." in them. We'll just have to
replace:
<property name="build.dir" value="build"/>
with
<property name="build.dir" value="${ofbiz.home.dir}/runtime/${name}/build"/>
Yes, I'm crazy about Jacopo's idea with /runtime . :)
Jonathon
David E. Jones wrote:
On Apr 4, 2007, at 8:22 AM, Jonathon -- Improov wrote:
> For development it's nice to have the jar files to make it possible to
> rebuild incrementally. I guess each build.xml file would have to know
> about the runtime folder and explicitly put it's stuff there, and if it
> doesn't and instead puts it in its own folder, then that's okay and it
> will just stay that way (mainly for add-in hot-deploy components and
such).
Wouldn't matter, since OFBiz will/should still search the build/lib
folders for each module.
However, I'd recommend that OFBiz issues a warning whenever it
encounters jar files in module-specific build/lib folders. We don't
want developers loading 2 sets of the same classes, and spending hours
wondering why their changes to the .java files have no effect.
Actually, OFBiz doesn't do any searching around, everything on the
classpath is configured very explicitly, mostly through the
ofbiz-component.xml files for runtime, and through build.xml file for
the build.
-David
