Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

[Pierre Smits]

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 <[hidden email]> 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 <[hidden email]
> <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 <
> [hidden email] <javascript:;>>:
> >>>>>
> >>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
> >>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
> [hidden email] <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

[David E. Jones-2]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]
>> <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 <
>> [hidden email] <javascript:;>>:
>>>>>>>
>>>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>> [hidden email] <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

[Jacopo Cappellato-5]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]
>>> <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 <
>>> [hidden email] <javascript:;>>:
>>>>>>>>
>>>>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>> [hidden email] <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]

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]
>>>> <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 <
>>>> [hidden email] <javascript:;>>:
>>>>>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>>> [hidden email] <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: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Pierre Smits]

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 <[hidden email]
> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]
>>>>>>
>>>>> <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 <
>>>>>>>>>>
>>>>>>>>> [hidden email] <javascript:;>>:
>>>>>
>>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>>>>>>
>>>>>>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>>>>>>>>>>
>>>>>>>>>> [hidden email] <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: [hidden email]
> skype: ronaldmwheeler
> phone: [phone], ext 102
>
>

[Ron Wheeler]

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 <[hidden email]
>> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]
>>>>>> <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 <
>>>>>>>>>> [hidden email] <javascript:;>>:
>>>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>>>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>>>>>>>>>>>
>>>>>>>>>>> [hidden email] <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: [hidden email]
>> skype: ronaldmwheeler
>> phone: [phone], ext 102
>>
>>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Pierre Smits]

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 <[hidden email]
> 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 <
>> [hidden email]
>>
>>> 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 <[hidden email]> 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 <[hidden email]>
>>>>> 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 <[hidden email]> 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 <
>>>>>>> [hidden email]
>>>>>>> <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 <
>>>>>>>>>>> [hidden email] <javascript:;>>:
>>>>>>>>>>>
>>>>>>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>>>>
>>>>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>>>>>>>>>>>>
>>>>>>>>>>>>>  [hidden email] <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: [hidden email]
>>> skype: ronaldmwheeler
>>> phone: [phone], ext 102
>>>
>>>
>>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: [hidden email]
> skype: ronaldmwheeler
> phone: [phone], ext 102
>
>

[Pierre Smits]

Quoting: 'why change in the first place'. That is one of the most important
question, perhaps even 'the most important'.... And it seems, that one
isn't answered to the fullest.

I like: if it aint broken, don't try to fix it'. But also 'a square peg
doesn't fit in a round hole'. Is our current build mechanism broken? Is our
current mechanism a square peg?

But beyond that: have we fully explored the all/other paths? We currently
have following options: Ant+IVY, Groovy/Gradle, Maven. They are all 'build'
solutions (at least according to their sites, but the writers of any of
those pages could be disregarded as experts). But there are also Apache
Buildr and Continiuum, according to this site listing options:
http://en.wikipedia.org/wiki/List_of_build_automation_software.

Should we explore inviting the real experts (those of all these tools) to
share their insights, so that we can base the decision on real information
than just conjecture/limited experiences?

And on another and related aspect: how much effort would the benefit of
each option require to have it fully operational for OFBiz? That should
help determination too.

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 7:00 PM, David E. Jones <[hidden email]> 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
>

[Ron Wheeler]

I tried to express my experience with Maven and Ant
I also expressed my sentiments about Gradle.

I hope that my bias for build systems that impose a bit of discipline
was clear.
It is based on many years of software development, application support
and system administration as well as recent experience running a small
team of developers (with wildly differing backgrounds) building a a few
medium sized applications (SaaS LMS with over 70 maven projects,
eComerce front-end for virtual  ILT and an ETVL product).


I am aware that other viewpoints exist and that ANT has worked for many
years.

Ron

On 20/04/2015 2: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 <[hidden email]
>> 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 <
>>> [hidden email]
>>>
>>>> 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 <[hidden email]> 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 <[hidden email]>
>>>>>> 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 <[hidden email]> 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 <
>>>>>>>> [hidden email]
>>>>>>>> <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 <
>>>>>>>>>>>> [hidden email] <javascript:;>>:
>>>>>>>>>>>>
>>>>>>>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>>>>>>>>>>>>>   [hidden email] <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: [hidden email]
>>>> skype: ronaldmwheeler
>>>> phone: [phone], ext 102
>>>>
>>>>
>>>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: [hidden email]
>> skype: ronaldmwheeler
>> phone: [phone], ext 102
>>
>>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Ron Wheeler]

Pierre is right to be cautious.

It is not just s swap of one build program for another.
There is a real change in the way one looks at software applications.

The current mixup with the dependencies would be much harder to do under
Maven.
Moving to Maven would almost certainly require that this be fixed.

The software parts of the project would probably have to be restructured
into a much more cleanly layered set of dependencies.
One would want to look at the structure of seed data and the whole
process of installing OFBiz.

One would also want to look at the Framework as a separate product (if
the community wants to promote this use of OFBiz) and set that up as a
separate deliverable with a separate build structure that produces a jar
of code and a process to deliver and install the seed data required for
a non-ERP application to call on the Framework as a dependency.

This would have many advantages for building custom ERPs based on OFBiz
but would require some work and consensus building that might be hard to
say the least.

Ron


On 20/04/2015 2:58 PM, Pierre Smits wrote:

> Quoting: 'why change in the first place'. That is one of the most important
> question, perhaps even 'the most important'.... And it seems, that one
> isn't answered to the fullest.
>
> I like: if it aint broken, don't try to fix it'. But also 'a square peg
> doesn't fit in a round hole'. Is our current build mechanism broken? Is our
> current mechanism a square peg?
>
> But beyond that: have we fully explored the all/other paths? We currently
> have following options: Ant+IVY, Groovy/Gradle, Maven. They are all 'build'
> solutions (at least according to their sites, but the writers of any of
> those pages could be disregarded as experts). But there are also Apache
> Buildr and Continiuum, according to this site listing options:
> http://en.wikipedia.org/wiki/List_of_build_automation_software.
>
> Should we explore inviting the real experts (those of all these tools) to
> share their insights, so that we can base the decision on real information
> than just conjecture/limited experiences?
>
> And on another and related aspect: how much effort would the benefit of
> each option require to have it fully operational for OFBiz? That should
> help determination too.
>
> 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 7:00 PM, David E. Jones <[hidden email]> 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
>>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[David E. Jones-2]

Buildr is similar to Gradle, though Ruby-based where Gradle is Groovy-based and so has more affinity with OFBiz. Continuum is a different sort of animal, a continuous integration tool that can run a variety of build tools.

BTW, what is an expert, let alone a "real" expert? A little like the term "true Scotsman" and the corresponding logical fallacy IMO...

-David

> On 20 Apr 2015, at 11:58, Pierre Smits <[hidden email]> wrote:
>
> Quoting: 'why change in the first place'. That is one of the most important
> question, perhaps even 'the most important'.... And it seems, that one
> isn't answered to the fullest.
>
> I like: if it aint broken, don't try to fix it'. But also 'a square peg
> doesn't fit in a round hole'. Is our current build mechanism broken? Is our
> current mechanism a square peg?
>
> But beyond that: have we fully explored the all/other paths? We currently
> have following options: Ant+IVY, Groovy/Gradle, Maven. They are all 'build'
> solutions (at least according to their sites, but the writers of any of
> those pages could be disregarded as experts). But there are also Apache
> Buildr and Continiuum, according to this site listing options:
> http://en.wikipedia.org/wiki/List_of_build_automation_software.
>
> Should we explore inviting the real experts (those of all these tools) to
> share their insights, so that we can base the decision on real information
> than just conjecture/limited experiences?
>
> And on another and related aspect: how much effort would the benefit of
> each option require to have it fully operational for OFBiz? That should
> help determination too.
>
> 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 7:00 PM, David E. Jones <[hidden email]> 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
>>

[Ron Wheeler]

On 20/04/2015 3:19 PM, David E. Jones wrote:
> Buildr is similar to Gradle, though Ruby-based where Gradle is Groovy-based and so has more affinity with OFBiz. Continuum is a different sort of animal, a continuous integration tool that can run a variety of build tools.
>
> BTW, what is an expert, let alone a "real" expert? A little like the term "true Scotsman" and the corresponding logical fallacy IMO...
I was always told that an expert was "a man with a briefcase 50 miles
from home".
Not sure how this translates into the modern virtual world taking into
account the role of women.


Ron

>
> -David
>
>
>> On 20 Apr 2015, at 11:58, Pierre Smits <[hidden email]> wrote:
>>
>> Quoting: 'why change in the first place'. That is one of the most important
>> question, perhaps even 'the most important'.... And it seems, that one
>> isn't answered to the fullest.
>>
>> I like: if it aint broken, don't try to fix it'. But also 'a square peg
>> doesn't fit in a round hole'. Is our current build mechanism broken? Is our
>> current mechanism a square peg?
>>
>> But beyond that: have we fully explored the all/other paths? We currently
>> have following options: Ant+IVY, Groovy/Gradle, Maven. They are all 'build'
>> solutions (at least according to their sites, but the writers of any of
>> those pages could be disregarded as experts). But there are also Apache
>> Buildr and Continiuum, according to this site listing options:
>> http://en.wikipedia.org/wiki/List_of_build_automation_software.
>>
>> Should we explore inviting the real experts (those of all these tools) to
>> share their insights, so that we can base the decision on real information
>> than just conjecture/limited experiences?
>>
>> And on another and related aspect: how much effort would the benefit of
>> each option require to have it fully operational for OFBiz? That should
>> help determination too.
>>
>> 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 7:00 PM, David E. Jones <[hidden email]> 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
>>>
>

--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[David E. Jones-2]

> On 20 Apr 2015, at 12:29, Ron Wheeler <[hidden email]> wrote:
>
> On 20/04/2015 3:19 PM, David E. Jones wrote:
>> Buildr is similar to Gradle, though Ruby-based where Gradle is Groovy-based and so has more affinity with OFBiz. Continuum is a different sort of animal, a continuous integration tool that can run a variety of build tools.
>>
>> BTW, what is an expert, let alone a "real" expert? A little like the term "true Scotsman" and the corresponding logical fallacy IMO...
> I was always told that an expert was "a man with a briefcase 50 miles from home".
> Not sure how this translates into the modern virtual world taking into account the role of women.

Not a bad definition, representative of the concept including often arbitrary inclusion/exclusion. ;)

I say that having been a man with a briefcase over 50 miles from home on regular occasions...

-David

[Ron Wheeler]

On 20/04/2015 4:15 PM, David E. Jones wrote:

>> On 20 Apr 2015, at 12:29, Ron Wheeler <[hidden email]> wrote:
>>
>> On 20/04/2015 3:19 PM, David E. Jones wrote:
>>> Buildr is similar to Gradle, though Ruby-based where Gradle is Groovy-based and so has more affinity with OFBiz. Continuum is a different sort of animal, a continuous integration tool that can run a variety of build tools.
>>>
>>> BTW, what is an expert, let alone a "real" expert? A little like the term "true Scotsman" and the corresponding logical fallacy IMO...
>> I was always told that an expert was "a man with a briefcase 50 miles from home".
>> Not sure how this translates into the modern virtual world taking into account the role of women.
> Not a bad definition, representative of the concept including often arbitrary inclusion/exclusion. ;)
>
> I say that having been a man with a briefcase over 50 miles from home on regular occasions...

Having been in that situation, I can assure you that in the "olden
days", once was usually enough.
Of course when you went back to your home office the next day or week ,
the designation ceased.
In one case where a vice-president of one division of a company
recommended me to another division in his company, I asked what would be
a reasonable charge.
The answer was "Charge enough so that they know you are an expert".

In the end I did save them over $500,000 so I did not feel to bad about
the fee.


>
> -David
>
>


--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: [phone], ext 102

[Pierre Smits]

Yes, managing the perception regarding 'Expert' is a smart decision. You
used one of the correct means.


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 10:38 PM, Ron Wheeler <
[hidden email]> wrote:

> On 20/04/2015 4:15 PM, David E. Jones wrote:
>
>> On 20 Apr 2015, at 12:29, Ron Wheeler <[hidden email]>
>>> wrote:
>>>
>>> On 20/04/2015 3:19 PM, David E. Jones wrote:
>>>
>>>> Buildr is similar to Gradle, though Ruby-based where Gradle is
>>>> Groovy-based and so has more affinity with OFBiz. Continuum is a different
>>>> sort of animal, a continuous integration tool that can run a variety of
>>>> build tools.
>>>>
>>>> BTW, what is an expert, let alone a "real" expert? A little like the
>>>> term "true Scotsman" and the corresponding logical fallacy IMO...
>>>>
>>> I was always told that an expert was "a man with a briefcase 50 miles
>>> from home".
>>> Not sure how this translates into the modern virtual world taking into
>>> account the role of women.
>>>
>> Not a bad definition, representative of the concept including often
>> arbitrary inclusion/exclusion. ;)
>>
>> I say that having been a man with a briefcase over 50 miles from home on
>> regular occasions...
>>
> Having been in that situation, I can assure you that in the "olden days",
> once was usually enough.
> Of course when you went back to your home office the next day or week ,
> the designation ceased.
> In one case where a vice-president of one division of a company
> recommended me to another division in his company, I asked what would be a
> reasonable charge.
> The answer was "Charge enough so that they know you are an expert".
>
> In the end I did save them over $500,000 so I did not feel to bad about
> the fee.
>
>
>
>
>> -David
>>
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: [hidden email]
> skype: ronaldmwheeler
> phone: [phone], ext 102
>
>

[Adam Heath-2]

(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 <[hidden email]
>> 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 <
>>> [hidden email]
>>>
>>>> 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 <[hidden email]> 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 <[hidden email]>
>>>>>> 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 <[hidden email]> 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 <
>>>>>>>> [hidden email]
>>>>>>>> <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 <
>>>>>>>>>>>> [hidden email] <javascript:;>>:
>>>>>>>>>>>>
>>>>>>>>>>> Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>>>>>>>>>>>>>   [hidden email] <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: [hidden email]
>>>> skype: ronaldmwheeler
>>>> phone: [phone], ext 102
>>>>
>>>>
>>>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: [hidden email]
>> skype: ronaldmwheeler
>> phone: [phone], ext 102
>>
>>

[Jacopo Cappellato-5]

On Apr 21, 2015, at 12:33 AM, Adam Heath <[hidden email]> 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.

Hi Adam,

I would suggest you to revert your commit until this discussion settles down and a final decision is taken by the community.

Jacopo

[Pierre Smits]

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 <[hidden email]> 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 <
>> [hidden email]
>>
>>> 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 <
>>>> [hidden email]
>>>>
>>>>  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 <[hidden email]> 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 <[hidden email]>
>>>>>>> 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 <[hidden email]> 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 <
>>>>>>>>> [hidden email]
>>>>>>>>> <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 <
>>>>>>>>>>>>> [hidden email] <javascript:;>>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>  Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
>>>>>>>>>>>>
>>>>>>>>>>> On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb <
>>>>>>>>>>>
>>>>>>>>>>>>   [hidden email] <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: [hidden email]
>>>>> skype: ronaldmwheeler
>>>>> phone: [phone], ext 102
>>>>>
>>>>>
>>>>>
>>>>>  --
>>> Ron Wheeler
>>> President
>>> Artifact Software Inc
>>> email: [hidden email]
>>> skype: ronaldmwheeler
>>> phone: [phone], ext 102
>>>
>>>
>>>
>

[Sharan-F]

Hi All

A reminder that this is a public list and while I understand that there is a lot of heated discussions happening here - the use of swearwords or bad language is not acceptable.

Thanks
Sharan

[Adam Heath-2]

On 04/21/2015 12:29 AM, Jacopo Cappellato wrote:

> On Apr 21, 2015, at 12:33 AM, Adam Heath <[hidden email]> 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.
> Hi Adam,
>
> I would suggest you to revert your commit until this discussion settles down and a final decision is taken by the community.

My commit is not breaking anything.  Why remove something that is harmless?

Let's be positive and forward enabling; if a commit is reverted, then
that reversion has not stopped any discussion, and now the original
committer will have to do more work to re-add what was removed.

This particular commit has not changed anyone's workflow, has not
altered any existing file; it hasn't even broken any automated tests.  
Has anyone complained about eclipse or netbeans ceasing to function,
because suddenly there is a pom.xml at the top level?  in fact, no one
will notice unless they run maven themselves. Seriously, what is the
harm in leaving this early POC in trunk, esp. when I am willing to move
over to an svn branch away from trunk?

You have my attention.  I have altered my off-work hours, to give up
some of my free time, to improve the project.  That is a big deal for
me.  Why not make use of this time in a productive matter?  I am willing
to do work.  I am willing to move forward.  I am implementing.

Also, and this may sound like I'm tooting my own horn(well, ok, it is),
but *I* implemented macros.xml and common.xml.  I made the build system
simpler.  We used to have to copy the full build.xml into every
component, and any changes had to be done to all of them.  With this new
build system(stating again, nothing has been broken *at all* with what
has been added), not only will we be able to have the same set of
current features, but we will get *even more*.

Proper inter-project dependencies.  Proper downloading of external
libraries.  No longer will anything be embedded.  The LICENSE and NOTICE
files will be reduced to a fraction of their size(and auto-generated,
there's a maven plugin for this, based on all listed <dependency>
items).  All those project pages you see about project info, javadocs,
etc, are produced by maven plugins.  Better project distribution(maven
can publish directory to a repo). Automatic version updates(all that
TRUNK stuff in my examples). OFBiz will be a better behaved system in
the Apache Family.  Less work will be needed to maintain our own custom
build.xml, as now the community at large will continue to improve the
maven ecosystem. Less NIH.

ps: In case you didn't notice, I have created a JIRA issue for
this(OFBIZ-6271), and an svn branch.  I will not be submitting separate
patches into that issue; instead, changes will be in the branch.  This
allows for proper history to be maintained, once the change is merged
in.  I will continue to use git locally for this(as I always have), and
will go silent for a short bit, but then mass-commit changes afterI have
finessed them into something presentable.  A new burst is coming in a
few hours.