Full external dependency management relates to something I proposed already in the beginning of 2014, see https://issues.apache.org/jira/browse/OFBIZ-5464
A proof of concept established that downloads could be downsized to approx 35 mb. Something that would not only be to the benefit of adopters of this project and its works, but also the ASF. 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 Fri, Apr 17, 2015 at 7:41 PM, Adam Heath <doo...@brainfood.com> 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 >>>> >>>> >>> >>> >
