This is an interesting idea, and there seem to be a number of plugins for Maven that deal with release/build/deploy automation.
Looking around to learn more about this I found this interesting intro presentation that talks about the Maven release plugin, plus plugins for other tools like Codehaus Cargo and LiquiBase (with a nice little intro to LiquiBase, which is very cool BTW): http://www.slideshare.net/wakaleo/automated-deployment-with-maven-going-the-whole-nine-yards -David On Jul 13, 2011, at 3:39 PM, Eric Bowman wrote: > Yes. We version our changes of ofbiz in a mavenesque way, and intend to use > the maven release plugin to generate releases which get "deployed" (in maven > terminology) to a repository, from which they get deployed to real servers. > > On 13 Jul 2011, at 15:18, David E Jones wrote: > >> >> 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 >>>>> >>>> >>> >> >
