Is part of the intent to use the Maven release plugin for deployment and such as well?
-David On Jul 13, 2011, at 3:12 PM, Eric Bowman wrote: > Hi, > > One other point: this tool is currently useful against ofbiz "as-is", in > order to build software that depends on it, using maven. Converting ofbiz to > use maven is a considerably bigger project. > > On 13 Jul 2011, at 15:01, David E Jones wrote: > >> >> I know various people have expressed interest in Maven over the years. From >> a quick search I see such discussions going back to 2003! >> >> OFBiz would definitely benefit from more modularization, and Maven may be >> able to help with that. However, it is just a tool and would still require >> significant work in addition to what Eric describes below to clean up >> higher-level OFBiz artifacts like services and screens and such to make the >> dependency tree clean. >> >> Based on the build-time dependencies Eric has generated an interesting graph >> that he sent to me, and it turns out to be a pretty good graph of component >> dependencies (even though technically if everything were written in the way >> intended by the framework, there wouldn't be so many build-time dependencies >> like this). The graph is actually better than the old old one I hand-rolled >> (that is in the Component and Component Set Dependencies document in the >> OFBADMIN space on Confluence). >> >> Getting back to the point, does anyone have an opinion on: >> >> 1. better modularizing OFBiz >> 2. using Maven for build and/or module dependency management? >> >> -David >> >> >> On Jul 12, 2011, at 12:09 PM, Eric Bowman wrote: >> >>> Hi, >>> >>> I've written a tool that we're considering open sourcing, and I'm curious >>> to gauge how much interest there would be in it. >>> >>> The purpose of the tool is to generate proper poms for each of the ofbiz >>> modules by inspecting an ofbiz directory. It works in two steps, and it >>> uses the Nexus search API (so it's not that interesting unless you have a >>> Nexus repository installed somewhere nearby). >>> >>> Here's what it does: >>> >>> 1. Inspects $OFBIZ_HOME recursively, identifying external dependency >>> libraries >>> 2. Generates the SHA1 hash of each jar, and uses a Nexus API to determine >>> whether that jar already exists in Nexus as a known artifact. >>> 3. If it does not, it takes a random sample of the classes in each jar, and >>> queries Nexus to see can it figure out a reasonable groupId & artifactId. >>> 4. For artifacts not already in Nexus, it synthesizes a mvn >>> deploy:deploy-file for each jar and each possible >>> groupId/artifactId/version it decides might be useful, and lets you decide >>> which commands to run to get all the dependency jars in Nexus. >>> 5. After all the external dependencies are in Nexus, it looks through >>> $OFBIZ_HOME again, and determines all the transitive dependencies between >>> ofbiz modules >>> 6. Next it synthesizes a pom for each module, that captures both the >>> dependencies in that module's lib directory, as well as the simplest >>> transitive graph of dependencies on other modules. >>> 7. Finally it prints out mvn deploy:deploy-file commands which can be run >>> separately to put each ofbiz module's jar file into Nexus, along with its >>> pom. >>> >>> If you are using maven, this is pretty nice -- this way you don't have to >>> worry about declaring dependencies against all the jars in the ofbiz >>> directory; it figures all that out, and leverages maven's transitive >>> dependency resolution to make a clean build. >>> >>> Obviously it doesn't solve other problems, like how to deploy an ofbiz >>> server in a maveny way, but that may follow. >>> >>> If you're interested in seeing this open sourced, perhaps you can reply >>> off-list; if there is enough interest I'll put this on github. And maybe >>> even if there isn't. :) >>> >>> Cheers, >>> Eric Bowman >>> >> >
