Ant + IVY are a better fit for the OFBiz. Best regards,
Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Mon, Apr 20, 2015 at 1:02 PM, Pierre Smits <pierre.sm...@gmail.com> wrote: > Ant + IVY delivers as much dependency management functionality as maven > does. > > Maven is good for building jar solutions. We don't build jar solutions. We > exploit jars! > > Best regards, > > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com > > On Mon, Apr 20, 2015 at 7:51 AM, Hans Bakker < > mailingl...@antwebsystems.com> wrote: > >> We should seriously consider the comments from Adam and move to maven. >> >> Regards, >> Hans >> antwebsystems.com >> >> >> On 18/04/15 00:41, Adam Heath wrote: >> >>> >>> On 04/17/2015 10:20 AM, Jacques Le Roux wrote: >>> >>>> Thanks for your detailed heads-up Martin, notably your last point! >>>> >>>> I mostly agree, and indeed I also think Maven might not be so bad when >>>> you start anew (or are forced to use it ;) ) but for OFBiz, really NO! >>>> >>>> Jacques >>>> >>>> Le 17/04/2015 16:27, Martin Becker a écrit : >>>> >>>>> +1 for lack of benefit (and for fear ;-)) >>>>> >>>> >>> The commit I did last night took me 45 minutes. Full stop. I started >>> at 12:03am. And I did it while drinking a second beer. Maven was that >>> simple. I had resisted for years. Years! But when I actually sat down to >>> do it, I realized that I did *not* have to change what I was doing. Maven >>> could be configured to work with the existing design. >>> >>> The benefits are: >>> >>> * not having to write our own build system; ant is not a build system. >>> >>> * full external dependency management. This can be done very >>> incrementally. I just got framework/base to compile, by reusing the >>> previously downloaded jars in framework/base/lib. Then, when all >>> dependencies are *properly* listed, we can switch to the download >>> mechanism, and suddenly, the checkout becomes smaller. >>> >>> * full internal dependency support. As part of framework/base now >>> having a working pom.xml, it has a dep on framework/start. This can allow >>> for end-users wanting to just install applications/party, and having just >>> what is required get downloaded. >>> >>> * Each ofbiz component could be moved to separate repos, and development >>> can progress on its own. All that specialpurpose/* stuff no longer needs >>> to be carried along with the rest of the codebase. >>> >>> * continuous integration becomes so much simpler; the standard "mvn >>> package" call does command-line unit tests, *by default*. >>> >>> * these poms do not break anything. Nothing calls them. Everyone can >>> continue to use ant, eclipse, or DIP switches, to compile and run ofbiz. >>> So, having them in trunk won't cause issue for anyone else. This is the >>> way linux-kernel functions. Completely new, isolated features, that affect >>> no one else, are added to master/linux-next, so that they can get pushed >>> out to more users, for more testing. If something is done in a separate >>> branch, they have discovered it doesn't recieve enough widespread testing. >>> >>> >>>>> >>>>> My first thoughts: >>>>> >>>>> => If a change is desired, than Gradle would surely be a good choice >>>>> as it is the next generation build tool witch tries to combine the >>>>> advantages from tools like ant, maven and others… >>>>> >>>> >>> Sure, why not? >>> >>> >>> Besides, I'm the one who created ${ofbiz.home.dir}/macros.xml and >>> common.xml, but really, lets not go there. >>> >>> >>>>> => I think the stability of Gradle is not a question as it is used by >>>>> projects like Spring, Hibernate, Grails, Groovy and others… >>>>> >>>>> => With the ability to use ant tasks and whole ant build scripts >>>>> within Gradle, a smooth migration could be an option >>>>> >>>>> >>> Maven can call ant. I'm even doing so in the 2 poms that I added. >>> >>> => Maven rely on it’s convention over configuration pattern, so it is >>>>> never a good idea to NOT follow it’s conventions by configuring it for a >>>>> different project structure for example. So there may be the need for >>>>> massive changes to the OFBiz project structure and so on. >>>>> >>>>> >>> I just got framework/base to compile with maven. This includes *NO* >>> changes to ofbiz layout. framework/base/lib still exists. Nothing is being >>> downloaded(except maven plugins, of course). >>> >>> => Also the ability to only produce one artifact per project in maven >>>>> would perhaps end up in configuring sub projects for each application and >>>>> module in OFBiz with a frustrating handling of multi module configurations >>>>> with version-/release-tags, dependency handling and so on... >>>>> >>>>> >>> This is wrong. You can produce multiple artifacts. I've seen it done >>> in other projects. >>> >>> => I used maven in multi module project setups before and it has it’s >>>>> nice features, although it is sometimes hard to understand details and >>>>> effects of the build lifecycle or single plugins. But the main fact is, >>>>> that this were green-field projects, so things in terms of convention over >>>>> configuration are much easier to adopt than in legacy projects like an >>>>> OFBiz… >>>>> >>>>> >>> >>> >>> => The change of the build tool for OFBiz would be a fundamental >>>>> change, particularly for upgrading existing installations. So a change to >>>>> the project structure could be a deathblow to OFBiz vendor imports in >>>>> customer projects. I think it could be a good starting point to look at >>>>> Gradle and see if there is a wise way to use the strength and new features >>>>> of a modern build tool without the need to turn things inside out in >>>>> OFBiz. >>>>> >>>>> >>> I'm not just some noob in ofbiz. I've been around for quite a bit. I've >>> been around when ofbiz was still using CVS. I was the first to start using >>> git locally for ofbiz development, and for our own ofbiz >>> extensions/fixes/client work. I've also been invovled with Debian in years >>> past, being involved in several migrations. I also added generics(and >>> enhanced for loops, etc), to *all* of framework, to spearhead that >>> project. But seriously, moving on. >>> >>> But, what structure changes have I propsed? None. I've got it working >>> with the exsting layout. Nothing has turned inside out. >>> >>> >>>>> Martin Becker >>>>> ecomify GmbH >>>>> >>>>> >>>>> >>>>> Am 17.04.2015 um 13:56 schrieb Jacques Le Roux < >>>>>> jacques.le.r...@les7arts.com>: >>>>>> >>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit : >>>>>> >>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb < >>>>>>> slidingfilame...@gmail.com> wrote: >>>>>>> >>>>>>> Hi All, >>>>>>>> >>>>>>>> Thank you for your work but I thought we are more inclined to move >>>>>>>> to gradle based build systems given its many advantages as a full >>>>>>>> programming language build system based on groovy. >>>>>>>> >>>>>>>> Taher Alkhateeb >>>>>>>> >>>>>>> I agree: we could explore the switch to Gradle and also review the >>>>>>> way our source files (Java, Groovy and Minilang/xml) are organized (we >>>>>>> could actually follow the layout that is considered the default for >>>>>>> Maven >>>>>>> and Gradle and possibly other tools). >>>>>>> >>>>>>> Jacopo >>>>>>> >>>>>>> I don't know if Gradle is stable now, but I'd surely be for instead >>>>>> of Maven. If ever we really desire to move from Ant, I don't clearly see >>>>>> the necessity at this stage... >>>>>> >>>>>> Jacques >>>>>> >>>>>> >>>>> >>>>> >>> >> >
