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 >> >
