Thanks for sharing the viewpoints. I could (just barely) suppress a physical reaction when I read 'Getting rid of ant is a good thing regardless'.
Luckily we implement changes based on consensus, not the preference of the few. 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 8:00 PM, Ron Wheeler <rwhee...@artifact-software.com > wrote: > Maven imposes a philosophy on builds that you either follow or fight (and > lose). > > The good side is that once you have your structure and supporting > processes in place anyone who knows a little bit of Maven can run a build > without looking at the pom and can add a dependency without destroying the > build. > You can build plug-ins to encapsulate best practices or to accomplish > tasks that are not part of the software build. > It is still possible to misuse Maven but it takes a lot of work and there > is an active community to help avoid doing silly things. > It is also actively supported with regular new versions so bug fixes and > enhancement do get released quickly. > > I have used Maven for years and like it a lot. > > Gradle is new and getting a lot of attention so it might be a better > choice but I have never used it. > Flexibility is nice until some bad practices get put into a build process > to solve a problem quickly rather than well. > > I love Ant and use it for other things but as a build tool it is too > flexible and does not impose any structure or "Best Practices". > > It also is an additional step on the learning curve which acts as a > barrier to attracting developers; specially younger members who have been > using more modern tools. > > Getting rid of Ant is a "good thing" regardless of where you go. > > Ron > > > On 20/04/2015 1:25 PM, Jacopo Cappellato wrote: > >> Some of the build files are really ugly at the moment and difficult to >> read: see the macros.xml, src-extra-set etc... >> The ability to write real code snippets may greatly simplify them. >> >> Jacopo >> >> On Apr 20, 2015, at 7:00 PM, David E. Jones <d...@me.com> wrote: >> >> 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 >>>> >>> >> > > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > >
