Quoting: pps: I did a comparison of ant, ivy, maven, and gradle at http://trends.google.com/. Maven is the correct choice, gradle is too new.
Ohh. Then we could just as well wait and sit it out to see another 'winner' rising to the top? Following the fad (http://en.wikipedia.org/wiki/Fad) is a good argument? I dare to say: not! 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 Tue, Apr 21, 2015 at 12:33 AM, Adam Heath <doo...@brainfood.com> wrote: > (picking a random email to respond to; I haven't read anything of this > thread all weekend, I will need to spend some time doing so) > > Fyi, I have framework/start, base, and entity all compiling with maven > now. API test cases work. Separate foo.jar and foo-test.jar are done. > META-INF/services/ all located properly. Everything in base/lib/** and > entity/lib/** has <dependency> settings in pom.xml, but *without* having to > download anything(yet). I can't stress enough that there are *no* changes > to any existing files. Absolutely none. > > As such, due to the volume of this discussion, I will be coming up with a > way to have all these poms overlayed(or some other technical solution) to > an unmodified ofbiz checkout. Git submodules might not be the right > approach, I need to look at git subtree a bit more. > > ps: It's suprising how quickly I was able to start getting maven to work. > I thought it would be extremely difficult. > > pps: I did a comparison of ant, ivy, maven, and gradle at > http://trends.google.com/. Maven is the correct choice, gradle is too > new. > > On 04/20/2015 01:43 PM, Pierre Smits wrote: > >> 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 >>> >>> >>> >
