ofbiz "mavenizer"
Locked
 
|
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 |
|
|
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 > |
|
|
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 >> > |
|
|
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 >>> >> > |
|
|
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 >>>> >>> >> > |
|
|
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 >>>>> >>>> >>> >> > |
|
|
Hi David, hi Eric,
first: cool tool Eric would love to see it! I worked a lot with maven in the last year and must say it is pretty amazing how easy thinks can be when you follow the convention over configuration pattern. There are plenty of plugins which support you by building/deploying/organization your application. So when maven is working it's is a really powerful tool. But during my projects i had to migrate some ANT based builds to Maven based build, that was a lot of work (and some times pretty frustrating). To your points David: 1. better modularizing OFBiz That would be a really great benefit and maven have a good modularization support 2. using Maven for build and/or module dependency management? That effects point one. The maven structure made it easy to create separate POMs (ProjectObjectModel) for each module (which can inherit other POMs) and combine them in one super pom which defines global (build/ deployment etc.) options ... Just a few thoughts this evening :) regards, Sascha 2011/7/13 David E Jones <[hidden email]> > > 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 > >>>>> > >>>> > >>> > >> > > > > -- Sascha Rodekamp Visit the new german OFBiz Blog: http://www.ofbiz.biz Lynx-Consulting GmbH Johanniskirchplatz 6 D-33615 Bielefeld http://www.lynx.de |
|
|
Yes, that's the point, I strong recommend migrate the build system to
maven, it's very handy to build/development/deploy/release with maven since there is lots of plugins can be use, and you also can write your plugin if possible. Just as Sascha mentioned, IMHO, 1. Maven follow the convention over configuration, you can avoid lots of unnecessary work, more important, ofbiz is also follow this principle, ofbiz follow the standard ofbiz-module-directory. 2. One of the goal of Maven is to support multiple module development, it's really easy and powerful, there is lots of project(open source or commercial ) are base upon maven build system, such as glassfish, hibernate, james, seam, xwiki....... Ofbiz is really a large multiple module project, it's easy to mapping to maven's module. You can focus on the module with maven module support, no need build other module....it's very important for larger project since you can build quickly and work more effective. 3. Beyond dependency management, maven standardize the release lifecycle, project management, document management and more development activity..... 4. Most of the IDE provide powerful support maven, you can open an maven project just as open normal IDE's project, such as idea, eclipse, netbean..... 5. Maven provide dependency management which ensure all dependent artifact have accurate version. This is very important to ensure the system stable. Seems some dependent jar of ofbiz miss the version information from my memory. So, I would vote for provide maven build support.。。 Please be free to contact with me for any question or suggestion. Thanks & Best Regards . ---------------------------------------------------------------------------- Young Gu | Software Engineer | http://www.infor.com On 7/14/2011 12:12 AM, Sascha Rodekamp wrote: > Hi David, hi Eric, > > first: cool tool Eric would love to see it! > > I worked a lot with maven in the last year and must say it is pretty amazing > how easy thinks can be when you follow the convention over configuration > pattern. There are plenty of plugins which support you by > building/deploying/organization your application. > So when maven is working it's is a really powerful tool. > But during my projects i had to migrate some ANT based builds to Maven based > build, that was a lot of work (and some times pretty frustrating). > > To your points David: > 1. better modularizing OFBiz > That would be a really great benefit and maven have a good modularization > support > > 2. using Maven for build and/or module dependency management? > That effects point one. The maven structure made it easy to create separate > POMs (ProjectObjectModel) for each module (which can inherit other POMs) and > combine them in one super pom which defines global (build/ deployment etc.) > options > > ... Just a few thoughts this evening :) > > regards, > Sascha > > > 2011/7/13 David E Jones<[hidden email]> > >> 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 >>>>>>> >> > |
|
|
I used Maven Ant Tasks in the development of new OFBiz applications.
The Maven Ant Tasks allow some of the Maven's artifact handling features including the dependency management to be used from within the Ant build. So this could be an option for those who wants to use POM to manage the dependencies, and stick to the standard OFBiz project structure at the same time. On 14/07/2011, [hidden email] <[hidden email]> wrote: > Yes, that's the point, I strong recommend migrate the build system to > maven, it's very handy to build/development/deploy/release with maven > since there is lots of plugins can be use, and you also can write your > plugin if possible. Just as Sascha mentioned, IMHO, > > 1. Maven follow the convention over configuration, you can avoid lots of > unnecessary work, more important, ofbiz is also follow this principle, > ofbiz follow the standard ofbiz-module-directory. > > 2. One of the goal of Maven is to support multiple module development, > it's really easy and powerful, there is lots of project(open source or > commercial ) are base upon maven build system, such as glassfish, > hibernate, james, seam, xwiki....... Ofbiz is really a large multiple > module project, it's easy to mapping to maven's module. You can focus on > the module with maven module support, no need build other module....it's > very important for larger project since you can build quickly and work > more effective. > > 3. Beyond dependency management, maven standardize the release > lifecycle, project management, document management and more development > activity..... > > 4. Most of the IDE provide powerful support maven, you can open an maven > project just as open normal IDE's project, such as idea, eclipse, > netbean..... > > 5. Maven provide dependency management which ensure all dependent > artifact have accurate version. This is very important to ensure the > system stable. Seems some dependent jar of ofbiz miss the version > information from my memory. > > So, I would vote for provide maven build support.。。 > > > Please be free to contact with me for any question or suggestion. > Thanks & Best Regards . > ---------------------------------------------------------------------------- > > Young Gu | Software Engineer | http://www.infor.com > > On 7/14/2011 12:12 AM, Sascha Rodekamp wrote: >> Hi David, hi Eric, >> >> first: cool tool Eric would love to see it! >> >> I worked a lot with maven in the last year and must say it is pretty >> amazing >> how easy thinks can be when you follow the convention over configuration >> pattern. There are plenty of plugins which support you by >> building/deploying/organization your application. >> So when maven is working it's is a really powerful tool. >> But during my projects i had to migrate some ANT based builds to Maven >> based >> build, that was a lot of work (and some times pretty frustrating). >> >> To your points David: >> 1. better modularizing OFBiz >> That would be a really great benefit and maven have a good modularization >> support >> >> 2. using Maven for build and/or module dependency management? >> That effects point one. The maven structure made it easy to create >> separate >> POMs (ProjectObjectModel) for each module (which can inherit other POMs) >> and >> combine them in one super pom which defines global (build/ deployment >> etc.) >> options >> >> ... Just a few thoughts this evening :) >> >> regards, >> Sascha >> >> >> 2011/7/13 David E Jones<[hidden email]> >> >>> 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 >>>>>>>> >>> >> > |
|
|
There's an ivy.xml file in the root of ofbiz trunk. Ant+Ivy seems to
be better alternative. Since we have all the build.xml ready, the only thing we need is to declare the dependencies using ivy. For this to work, components build.xml files need to be modified to install the resulting jar files in ivy (or maven repo). This is based on my understanding of ivy (which is very limited). On Wed, Jul 13, 2011 at 11:50 PM, Ray Shi <[hidden email]> wrote: > I used Maven Ant Tasks in the development of new OFBiz applications. > The Maven Ant Tasks allow some of the Maven's artifact handling > features including the dependency management to be used from within > the Ant build. > > So this could be an option for those who wants to use POM to manage > the dependencies, and stick to the standard OFBiz project structure at > the same time. > > > On 14/07/2011, [hidden email] <[hidden email]> wrote: >> Yes, that's the point, I strong recommend migrate the build system to >> maven, it's very handy to build/development/deploy/release with maven >> since there is lots of plugins can be use, and you also can write your >> plugin if possible. Just as Sascha mentioned, IMHO, >> >> 1. Maven follow the convention over configuration, you can avoid lots of >> unnecessary work, more important, ofbiz is also follow this principle, >> ofbiz follow the standard ofbiz-module-directory. >> >> 2. One of the goal of Maven is to support multiple module development, >> it's really easy and powerful, there is lots of project(open source or >> commercial ) are base upon maven build system, such as glassfish, >> hibernate, james, seam, xwiki....... Ofbiz is really a large multiple >> module project, it's easy to mapping to maven's module. You can focus on >> the module with maven module support, no need build other module....it's >> very important for larger project since you can build quickly and work >> more effective. >> >> 3. Beyond dependency management, maven standardize the release >> lifecycle, project management, document management and more development >> activity..... >> >> 4. Most of the IDE provide powerful support maven, you can open an maven >> project just as open normal IDE's project, such as idea, eclipse, >> netbean..... >> >> 5. Maven provide dependency management which ensure all dependent >> artifact have accurate version. This is very important to ensure the >> system stable. Seems some dependent jar of ofbiz miss the version >> information from my memory. >> >> So, I would vote for provide maven build support.。。 >> >> >> Please be free to contact with me for any question or suggestion. >> Thanks & Best Regards . >> ---------------------------------------------------------------------------- >> >> Young Gu | Software Engineer | http://www.infor.com >> >> On 7/14/2011 12:12 AM, Sascha Rodekamp wrote: >>> Hi David, hi Eric, >>> >>> first: cool tool Eric would love to see it! >>> >>> I worked a lot with maven in the last year and must say it is pretty >>> amazing >>> how easy thinks can be when you follow the convention over configuration >>> pattern. There are plenty of plugins which support you by >>> building/deploying/organization your application. >>> So when maven is working it's is a really powerful tool. >>> But during my projects i had to migrate some ANT based builds to Maven >>> based >>> build, that was a lot of work (and some times pretty frustrating). >>> >>> To your points David: >>> 1. better modularizing OFBiz >>> That would be a really great benefit and maven have a good modularization >>> support >>> >>> 2. using Maven for build and/or module dependency management? >>> That effects point one. The maven structure made it easy to create >>> separate >>> POMs (ProjectObjectModel) for each module (which can inherit other POMs) >>> and >>> combine them in one super pom which defines global (build/ deployment >>> etc.) >>> options >>> >>> ... Just a few thoughts this evening :) >>> >>> regards, >>> Sascha >>> >>> >>> 2011/7/13 David E Jones<[hidden email]> >>> >>>> 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 >>>>>>>>> >>>> >>> >> > |
|
To manage modularity have the same thin than Mansour.
On neogia addons librairy, we analysed maven and ivy. We use ivy directly call by the addon manager system. An example with a hat addon crm to resolve addon dependencies : dependencies tree as resoled by ivy for the addon : neogia-crm neogia-crm 0.1.14.803 consultant-b2b 1.1.22.7 crm-common-b2b 3.2.25.20 create-party-and-information 1.5.2.5 party-name-company 1.5.9.112 party-name 1.4.11 company 0.13.6.1 role-type-group 0.7.2 portlet-party 0.4.5.3 portletWidget 0.10.5.6 exampleHelp 0.3.2.7 portletExample 0.10.10 genericPortlet 0.15.2 validate-form 0.1.4 portlet-order 0.1.5 role-type-group 0.7.2 company 0.13.6.1 role-type-group 0.7.2 portlet-party 0.4.5.3 portletWidget 0.10.5.6 exampleHelp 0.3.2.7 portletExample 0.10.10 genericPortlet 0.15.2 validate-form 0.1.4 portlet-order 0.1.5 simple-content-display 1.0.5 gwtCalendarWithMultiMenus 0.1.1.23 gwtCalendarTeam 0.22.0.2-dev party-group-hierarchy 1.12.15 calendarPortlet 0.7.7.3 portlet-workeffort 0.4.0.20 portletWidget 0.10.5.6 exampleHelp 0.3.2.7 portletExample 0.10.10 genericPortlet 0.15.2 validate-form 0.1.4 portletWidget 0.10.5.6 exampleHelp 0.3.2.7 portletExample 0.10.10 genericPortlet 0.15.2 validate-form 0.1.4 party-group-hierarchy 1.12.15 themes-with-multimenu 0.4.7 recent-action 1.3.21.3 portlet-party 0.4.5.3 portletWidget 0.10.5.6 exampleHelp 0.3.2.7 portletExample 0.10.10 genericPortlet 0.15.2 validate-form 0.1.4 quote-project-management 1.9.5.10 portlet-order 0.1.5 portletWidget 0.10.5.6 exampleHelp 0.3.2.7 portletExample 0.10.10 genericPortlet 0.15.2 validate-form 0.1.4 calendarPortlet 0.7.7.3 portlet-workeffort 0.4.0.20 portletWidget 0.10.5.6 exampleHelp 0.3.2.7 portletExample 0.10.10 genericPortlet 0.15.2 validate-form 0.1.4 portletWidget 0.10.5.6 exampleHelp 0.3.2.7 portletExample 0.10.10 genericPortlet 0.15.2 validate-form 0.1.4 And addon installation order : The dependencies will be installed in this order: validate-form 0.1.4 genericPortlet 0.15.2 portletExample 0.10.10 exampleHelp 0.3.2.7 portletWidget 0.10.5.6 party-group-hierarchy 1.12.15 portlet-workeffort 0.4.0.20 role-type-group 0.7.2 portlet-party 0.4.5.3 portlet-order 0.1.5 calendarPortlet 0.7.7.3 party-name 1.4.11 company 0.13.6.1 projectMgrLabel 0.4.9-dev themes-with-multimenu 0.4.7 party-name-company 1.5.9.112 gwtCalendarTeam 0.22.0.2-dev portlet-projectmgr 0.20.1.3 create-party-and-information 1.5.2.5 simple-content-display 1.0.5 gwtCalendarWithMultiMenus 0.1.1.23 recent-action 1.3.21.3 quote-project-management 1.9.5.10 commEventByPurpose 1.0.30.17 portlet-marketing 0.5.1.3 portlet-party-advanced 0.1.2.8-dev portlet-projectmgr-more 0.4.0.8-dev fckeditor 1.0.1 html-editor 0.3.0 contactMechMgmtPortlet 0.3.3.4 clocking-project 0.3.10.60-dev portlet-humanres 0.1.2.3 crm-common-b2b 3.2.25.20 consultant-b2b 1.1.22.7 sales-adm-b2b 1.1.11.64 sales-reps-b2b 1.4.8.107 neogia-crm 0.1.14.803 Now, I not maven expert and maybe it's possible to do than with maven. Nicolas Le 14/07/2011 18:15, Mansour Al Akeel a écrit : > There's an ivy.xml file in the root of ofbiz trunk. Ant+Ivy seems to > be better alternative. > Since we have all the build.xml ready, the only thing we need is to > declare the dependencies using ivy. For this to work, components > build.xml files need to be modified to install the resulting jar files > in ivy (or maven repo). > This is based on my understanding of ivy (which is very limited). > > > On Wed, Jul 13, 2011 at 11:50 PM, Ray Shi<[hidden email]> wrote: >> I used Maven Ant Tasks in the development of new OFBiz applications. >> The Maven Ant Tasks allow some of the Maven's artifact handling >> features including the dependency management to be used from within >> the Ant build. >> >> So this could be an option for those who wants to use POM to manage >> the dependencies, and stick to the standard OFBiz project structure at >> the same time. >> >> >> On 14/07/2011, [hidden email]<[hidden email]> wrote: >>> Yes, that's the point, I strong recommend migrate the build system to >>> maven, it's very handy to build/development/deploy/release with maven >>> since there is lots of plugins can be use, and you also can write your >>> plugin if possible. Just as Sascha mentioned, IMHO, >>> >>> 1. Maven follow the convention over configuration, you can avoid lots of >>> unnecessary work, more important, ofbiz is also follow this principle, >>> ofbiz follow the standard ofbiz-module-directory. >>> >>> 2. One of the goal of Maven is to support multiple module development, >>> it's really easy and powerful, there is lots of project(open source or >>> commercial ) are base upon maven build system, such as glassfish, >>> hibernate, james, seam, xwiki....... Ofbiz is really a large multiple >>> module project, it's easy to mapping to maven's module. You can focus on >>> the module with maven module support, no need build other module....it's >>> very important for larger project since you can build quickly and work >>> more effective. >>> >>> 3. Beyond dependency management, maven standardize the release >>> lifecycle, project management, document management and more development >>> activity..... >>> >>> 4. Most of the IDE provide powerful support maven, you can open an maven >>> project just as open normal IDE's project, such as idea, eclipse, >>> netbean..... >>> >>> 5. Maven provide dependency management which ensure all dependent >>> artifact have accurate version. This is very important to ensure the >>> system stable. Seems some dependent jar of ofbiz miss the version >>> information from my memory. >>> >>> So, I would vote for provide maven build support.。。 >>> >>> >>> Please be free to contact with me for any question or suggestion. >>> Thanks& Best Regards . >>> ---------------------------------------------------------------------------- >>> >>> Young Gu | Software Engineer | http://www.infor.com >>> >>> On 7/14/2011 12:12 AM, Sascha Rodekamp wrote: >>>> Hi David, hi Eric, >>>> >>>> first: cool tool Eric would love to see it! >>>> >>>> I worked a lot with maven in the last year and must say it is pretty >>>> amazing >>>> how easy thinks can be when you follow the convention over configuration >>>> pattern. There are plenty of plugins which support you by >>>> building/deploying/organization your application. >>>> So when maven is working it's is a really powerful tool. >>>> But during my projects i had to migrate some ANT based builds to Maven >>>> based >>>> build, that was a lot of work (and some times pretty frustrating). >>>> >>>> To your points David: >>>> 1. better modularizing OFBiz >>>> That would be a really great benefit and maven have a good modularization >>>> support >>>> >>>> 2. using Maven for build and/or module dependency management? >>>> That effects point one. The maven structure made it easy to create >>>> separate >>>> POMs (ProjectObjectModel) for each module (which can inherit other POMs) >>>> and >>>> combine them in one super pom which defines global (build/ deployment >>>> etc.) >>>> options >>>> >>>> ... Just a few thoughts this evening :) >>>> >>>> regards, >>>> Sascha >>>> >>>> >>>> 2011/7/13 David E Jones<[hidden email]> >>>> >>>>> 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 >>>>>>>>>> -- Nicolas MALIN Consultant Tél : 06.17.66.40.06 Site projet : http://www.neogia.org/ ------- Société LibrenBerry Tél : 02.48.02.56.12 Site : http://www.librenberry.net/ |
|
|
In reply to this post by Eric Bowman
Hi,
I've placed "mavenizer" on github: https://github.com/ebowman/mavenizer I wouldn't say it's too polished yet, so if anyone wants to be an early adopter, much appreciated. Note that you will need a Nexus installation nearby for this to be much use. cheers, Eric On 12 Jul 2011, at 12:09, 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 > |
«
Return to OFBiz - User
|
1 view|%1 views
| Free forum by Nabble | Edit this page |