Assumptions are the Mother of all Fuckups, is often said. Nevertheless, bringing all viewpoints and insights together (without the assumptions and/or coloured projections) will lead to a better informed community, enabling it to take the right decision.
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:31 PM, Ron Wheeler <rwhee...@artifact-software.com > wrote: > Sorry Pierre. > I hope it did not not ruin your evening. > I guess old tools are like old homes. > Hard to say goodbye even if the new house fits your needs better. > (Assuming that the consensus is that Ant needs replacing) > > Ron > > On 20/04/2015 2:17 PM, Pierre Smits wrote: > >> 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 >>> >>> >>> > > -- > Ron Wheeler > President > Artifact Software Inc > email: rwhee...@artifact-software.com > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > >
