ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Bowman <ebow...@boboco.ie>
Subject Re: ofbiz "mavenizer"
Date Wed, 13 Jul 2011 13:12:21 GMT
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
>> 
> 


Mime
View raw message