That gets back to the question of why change in the first place... build files may be smaller and easier to maintain, but there may not be a good reason!
-David > On 20 Apr 2015, at 09:37, Pierre Smits <pierre.sm...@gmail.com> wrote: > > David, > > Thanks for sharing your insights. You talk about 'pretty much anything > can be done with'. What, in your experience, can't be done -at the > moment- in relation to OFBiz? > > Best regards, > > Pierre > > Op maandag 20 april 2015 heeft David E. Jones <d...@me.com> het volgende > geschreven: > >> >> Not to muddy the waters... but Gradle might be a good alternative. There >> is a lot more in it than Ant that "just works" without needing to be >> explicit, especially when you follow Maven conventions for layout of src >> directories. >> >> One big upside of Gradle is that all build files are Groovy scripts and >> you can do pretty much anything in them. One downside is the learning >> curve... there is an extensive DSL with pretty good documentation, but some >> things that would seem simple are non-obvious (to put it generously). On >> the other hand, there is fairly wide use so I still have yet to run >> anything where I couldn't find a solution quickly with a google search. >> >> -David >> >> >>> On 19 Apr 2015, at 22:51, Hans Bakker <mailingl...@antwebsystems.com >> <javascript:;>> 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 <javascript:;>>: >>>>>>> >>>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit : >>>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb < >> slidingfilame...@gmail.com <javascript:;>> 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 >>>>>>> >>>>>> >>>>>> >>>> >>> >> >> > > -- > Pierre Smits > > *ORRTIZ.COM <http://www.orrtiz.com>* > Services & Solutions for Cloud- > Based Manufacturing, Professional > Services and Retail & Trade > http://www.orrtiz.com