subject:"svn commit\: r1674216 \- in \/ofbiz\/trunk\: framework\/start\/pom.xml pom.xml"

@David: Really? No, I projected a scenario that could happen if due process
isn't upheld. I rather not see such a scenario unfolding. And in this case
I feel the gun was jumped. While still debating over pros and cons. A bit
of patience applied would not have led to that projection.

And remember I did a PoC on Ant+IVY (outside of our repository) and opened
the discussion regarding opening a dev branch so that people evaluate that
alternative and learn from my insights gathered in the beginning of 2014.

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 Wed, Apr 22, 2015 at 7:53 PM, David E. Jones d...@me.com wrote:


  On 21 Apr 2015, at 14:09, Pierre Smits pierre.sm...@gmail.com wrote:
 
  Is this the path you want to walk? Code over Community? Engage in commit
  wars, just to force your way? Please don't!  Collaborating is easier than
  forcing. The latter harms the project more than the first.

 Really? Doing a POC and proposing a direction implies all of this to you?

 -David

Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

2015-04-22 Thread Jacopo Cappellato

On Apr 21, 2015, at 10:37 PM, Adam Heath doo...@brainfood.com wrote:

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

Hi Adam,

The fact that a commit is harmless is not enough for its approval.
I know that your commit doesn't cause any side effects and I appreciate that 
you are now doing your work in a feature branch.
I am asking you to revert that commit to trunk not because its quality is bad 
or I see potential issues but only because the decision about the official 
build tool for the project must be taken by the community and we are not 
planning to maintain more than one alternative options in the official 
repository.
Just to make it super clear, I restate my request: please revert 1674216 (it is 
the only commit to trunk) then let's continue the work about Maven in the 
release branch you have created. 
In the meantime the discussion about ant vs ant+ivy vs maven vs gradle vs ... 
will go on and its outcome will determine the final decision; since there are 
clearly different points of view for the different tools we all have to be open 
to consider other's opinions: crystallized positions will not help much in this 
context.
The branch you have created is valuable because it provides a reference 
implementation for the discussion, but it is important that you appreciate that 
it may not be merged into the project (based on the outcome of the ongoing 
discussion).

Regards,

Jacopo

Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

In order to give the project the best basis for reaching a sound decision
(pro-con comparison between the three suggested angles - ant+ivy, gradle,
maven), we could just as easily create also dev branches for the other two
options and have proponents work on that so that these can also be
evaluated by all.

I am willing to work on the ant+ivy angle.

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 Wed, Apr 22, 2015 at 11:13 AM, Pierre Smits pierre.sm...@gmail.com
wrote:

 I already establised a working solution for better dependency management
 based on ant+ivy. Resulting in a reduction of zip size to 1/5 of the
 checkout at that time (35 MBs). And it seems with less effort/less
 complexity than is now is being shown in the OFBIZ-6172 branch...

 I suggested a dev branch back then (
 https://issues.apache.org/jira/browse/OFBIZ-5464) so that others could
 evaluate. Unfortunately it didn't gather momentum at the time.

 Does that mean that it is a worse fit? I dare say: not!







 Pierre Smits

 *ORRTIZ.COM http://www.orrtiz.com*
 Services  Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail  Trade
 http://www.orrtiz.com

 On Wed, Apr 22, 2015 at 10:32 AM, Ron Wheeler 
 rwhee...@artifact-software.com wrote:

 Perhaps it would be a good idea for some of the key people to take a
 close look at what has been done.

 This is potentially a big step forward in modernizing the product.

 Having a working solution takes a lot of the FUD out of the discussion
 and allows the approach to be tested by the people who are building OFBiz
 every day.

 Even if it actually does everything that Adam claims and the consensus of
 the committers is to move to Maven, it will still be a good idea to support
 the 2 build methods until everyone important is ready to commit to Maven.
 It may take a while to get the Maven approach sold to everyone even if they
 know that at some point they will be forced to move. Some will be early
 adopters and some will be late but if you don't have to force everyone to
 move at once, it does make the transition easier.

 If it is the consensus that the Ant build is still better, the Maven
 stuff is easy to remove without damaging the Ant build.

 I suggest leaving it in until everyone who needs to test it before the
 decision is made, has a chance to test it.
 It is unreasonable to expect each of the committers to make their own
 Maven build to test the idea.

 Adam has saved us a lot of speculation about what it means to move to
 Maven.

 Give the supporters and skeptics some time to test before removing it.

 Ron


 On 22/04/2015 2:52 AM, Jacopo Cappellato wrote:

 On Apr 21, 2015, at 10:37 PM, Adam Heath doo...@brainfood.com wrote:

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

 Hi Adam,

 The fact that a commit is harmless is not enough for its approval.
 I know that your commit doesn't cause any side effects and I appreciate
 that you are now doing your work in a feature branch.
 I am asking you to revert that commit to trunk not because its quality
 is bad or I see potential issues but only because the decision about the
 official build tool for the project must be taken by the community and we
 are not planning to maintain more than one alternative options in the
 official repository.
 Just to make it super clear, I restate my request: please revert 1674216
 (it is the only commit to trunk) then let's continue the work about Maven
 in the release branch you have created.
 In the meantime the discussion about ant vs ant+ivy vs maven vs gradle
 vs ... will go on and its outcome will determine the final decision; since
 there are clearly different points of view for the different tools we all
 have to be open to consider other's opinions: crystallized positions will
 not help much in this context.
 The branch you have created is valuable because it provides a reference
 implementation for the discussion, but it is important that you appreciate
 that it may not be merged into the project (based on the outcome of the
 ongoing discussion).

 Regards,

 Jacopo



 --
 Ron Wheeler
 President
 Artifact Software Inc
 email: rwhee...@artifact-software.com
 skype: ronaldmwheeler
 phone: 866-970-2435, ext 102

Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

I already establised a working solution for better dependency management
based on ant+ivy. Resulting in a reduction of zip size to 1/5 of the
checkout at that time (35 MBs). And it seems with less effort/less
complexity than is now is being shown in the OFBIZ-6172 branch...

I suggested a dev branch back then (
https://issues.apache.org/jira/browse/OFBIZ-5464) so that others could
evaluate. Unfortunately it didn't gather momentum at the time.

Does that mean that it is a worse fit? I dare say: not!







Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Wed, Apr 22, 2015 at 10:32 AM, Ron Wheeler 
rwhee...@artifact-software.com wrote:

 Perhaps it would be a good idea for some of the key people to take a close
 look at what has been done.

 This is potentially a big step forward in modernizing the product.

 Having a working solution takes a lot of the FUD out of the discussion and
 allows the approach to be tested by the people who are building OFBiz every
 day.

 Even if it actually does everything that Adam claims and the consensus of
 the committers is to move to Maven, it will still be a good idea to support
 the 2 build methods until everyone important is ready to commit to Maven.
 It may take a while to get the Maven approach sold to everyone even if they
 know that at some point they will be forced to move. Some will be early
 adopters and some will be late but if you don't have to force everyone to
 move at once, it does make the transition easier.

 If it is the consensus that the Ant build is still better, the Maven stuff
 is easy to remove without damaging the Ant build.

 I suggest leaving it in until everyone who needs to test it before the
 decision is made, has a chance to test it.
 It is unreasonable to expect each of the committers to make their own
 Maven build to test the idea.

 Adam has saved us a lot of speculation about what it means to move to
 Maven.

 Give the supporters and skeptics some time to test before removing it.

 Ron


 On 22/04/2015 2:52 AM, Jacopo Cappellato wrote:

 On Apr 21, 2015, at 10:37 PM, Adam Heath doo...@brainfood.com wrote:

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

 Hi Adam,

 The fact that a commit is harmless is not enough for its approval.
 I know that your commit doesn't cause any side effects and I appreciate
 that you are now doing your work in a feature branch.
 I am asking you to revert that commit to trunk not because its quality is
 bad or I see potential issues but only because the decision about the
 official build tool for the project must be taken by the community and we
 are not planning to maintain more than one alternative options in the
 official repository.
 Just to make it super clear, I restate my request: please revert 1674216
 (it is the only commit to trunk) then let's continue the work about Maven
 in the release branch you have created.
 In the meantime the discussion about ant vs ant+ivy vs maven vs gradle
 vs ... will go on and its outcome will determine the final decision; since
 there are clearly different points of view for the different tools we all
 have to be open to consider other's opinions: crystallized positions will
 not help much in this context.
 The branch you have created is valuable because it provides a reference
 implementation for the discussion, but it is important that you appreciate
 that it may not be merged into the project (based on the outcome of the
 ongoing discussion).

 Regards,

 Jacopo



 --
 Ron Wheeler
 President
 Artifact Software Inc
 email: rwhee...@artifact-software.com
 skype: ronaldmwheeler
 phone: 866-970-2435, ext 102

Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

2015-04-22 Thread Ron Wheeler

Perhaps it would be a good idea for some of the key people to take a 
close look at what has been done.


This is potentially a big step forward in modernizing the product.

Having a working solution takes a lot of the FUD out of the discussion 
and allows the approach to be tested by the people who are building 
OFBiz every day.


Even if it actually does everything that Adam claims and the consensus 
of the committers is to move to Maven, it will still be a good idea to 
support the 2 build methods until everyone important is ready to commit 
to Maven. It may take a while to get the Maven approach sold to everyone 
even if they know that at some point they will be forced to move. Some 
will be early adopters and some will be late but if you don't have to 
force everyone to move at once, it does make the transition easier.


If it is the consensus that the Ant build is still better, the Maven 
stuff is easy to remove without damaging the Ant build.


I suggest leaving it in until everyone who needs to test it before the 
decision is made, has a chance to test it.
It is unreasonable to expect each of the committers to make their own 
Maven build to test the idea.


Adam has saved us a lot of speculation about what it means to move to Maven.

Give the supporters and skeptics some time to test before removing it.

Ron

On 22/04/2015 2:52 AM, Jacopo Cappellato wrote:

On Apr 21, 2015, at 10:37 PM, Adam Heath doo...@brainfood.com wrote:


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

Hi Adam,

The fact that a commit is harmless is not enough for its approval.
I know that your commit doesn't cause any side effects and I appreciate that 
you are now doing your work in a feature branch.
I am asking you to revert that commit to trunk not because its quality is bad 
or I see potential issues but only because the decision about the official 
build tool for the project must be taken by the community and we are not 
planning to maintain more than one alternative options in the official 
repository.
Just to make it super clear, I restate my request: please revert 1674216 (it is 
the only commit to trunk) then let's continue the work about Maven in the 
release branch you have created.
In the meantime the discussion about ant vs ant+ivy vs maven vs gradle vs ... 
will go on and its outcome will determine the final decision; since there are clearly 
different points of view for the different tools we all have to be open to consider 
other's opinions: crystallized positions will not help much in this context.
The branch you have created is valuable because it provides a reference 
implementation for the discussion, but it is important that you appreciate that 
it may not be merged into the project (based on the outcome of the ongoing 
discussion).

Regards,

Jacopo



--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

The Groovy/Gradle approach enables this project to bring build/dependency
management regarding base applications and optionals (special
purpose/outside ASF solutions) from the CLI to an application. Increasing
the user experience of those who manage the implementation for their users.
Leading to potentially more adopters.

I don't care particularly for the argument of the trend projection (Maven
vs Gradle vs ANT+IVY). That is based on an algorithm that pulls in all
kinds of stuff. And whether that stuff is applicable to the needs of this
project can't be determined.

What I see happening in this thread (and others similarly related to the
subject) is projection of favouritism (Apple vs Microsoft, BMW vs Mercedes,
et all).

We should first focus on the need of the project, build consensus before
moving on. Having a dev branch filled with something to evaluate comes
second.

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 Wed, Apr 22, 2015 at 11:13 AM, Pierre Smits pierre.sm...@gmail.com
wrote:

 I already establised a working solution for better dependency management
 based on ant+ivy. Resulting in a reduction of zip size to 1/5 of the
 checkout at that time (35 MBs). And it seems with less effort/less
 complexity than is now is being shown in the OFBIZ-6172 branch...

 I suggested a dev branch back then (
 https://issues.apache.org/jira/browse/OFBIZ-5464) so that others could
 evaluate. Unfortunately it didn't gather momentum at the time.

 Does that mean that it is a worse fit? I dare say: not!







 Pierre Smits

 *ORRTIZ.COM http://www.orrtiz.com*
 Services  Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail  Trade
 http://www.orrtiz.com

 On Wed, Apr 22, 2015 at 10:32 AM, Ron Wheeler 
 rwhee...@artifact-software.com wrote:

 Perhaps it would be a good idea for some of the key people to take a
 close look at what has been done.

 This is potentially a big step forward in modernizing the product.

 Having a working solution takes a lot of the FUD out of the discussion
 and allows the approach to be tested by the people who are building OFBiz
 every day.

 Even if it actually does everything that Adam claims and the consensus of
 the committers is to move to Maven, it will still be a good idea to support
 the 2 build methods until everyone important is ready to commit to Maven.
 It may take a while to get the Maven approach sold to everyone even if they
 know that at some point they will be forced to move. Some will be early
 adopters and some will be late but if you don't have to force everyone to
 move at once, it does make the transition easier.

 If it is the consensus that the Ant build is still better, the Maven
 stuff is easy to remove without damaging the Ant build.

 I suggest leaving it in until everyone who needs to test it before the
 decision is made, has a chance to test it.
 It is unreasonable to expect each of the committers to make their own
 Maven build to test the idea.

 Adam has saved us a lot of speculation about what it means to move to
 Maven.

 Give the supporters and skeptics some time to test before removing it.

 Ron


 On 22/04/2015 2:52 AM, Jacopo Cappellato wrote:

 On Apr 21, 2015, at 10:37 PM, Adam Heath doo...@brainfood.com wrote:

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

 Hi Adam,

 The fact that a commit is harmless is not enough for its approval.
 I know that your commit doesn't cause any side effects and I appreciate
 that you are now doing your work in a feature branch.
 I am asking you to revert that commit to trunk not because its quality
 is bad or I see potential issues but only because the decision about the
 official build tool for the project must be taken by the community and we
 are not planning to maintain more than one alternative options in the
 official repository.
 Just to make it super clear, I restate my request: please revert 1674216
 (it is the only commit to trunk) then let's continue the work about Maven
 in the release branch you have created.
 In the meantime the discussion about ant vs ant+ivy vs maven vs gradle
 vs ... will go on and its outcome will determine the final decision; since
 there are clearly different points of view for the different tools we all
 have to be open to consider other's opinions: crystallized positions will
 not help much in this context.
 The branch you have created is valuable because it provides a reference
 implementation for the discussion, but it is important that you appreciate
 that it may not be merged into the project (based on the outcome of the
 ongoing discussion).

 Regards,

 Jacopo



 --
 Ron Wheeler
 President
 Artifact Software Inc
 email: rwhee...@artifact-software.com
 skype: ronaldmwheeler
 phone: 866-970-2435, ext 102

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

2015-04-21 Thread 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 doo...@brainfood.com wrote:

 (picking a random email to respond to; I haven't read anything of this
 thread all weekend, I will need to spend some time doing so)

 Fyi, I have framework/start, base, and entity all compiling with maven
 now. API test cases work.  Separate foo.jar and foo-test.jar are done.
 META-INF/services/ all located properly.  Everything in base/lib/** and
 entity/lib/** has dependency settings in pom.xml, but *without* having to
 download anything(yet).  I can't stress enough that there are *no* changes
 to any existing files. Absolutely none.

 As such, due to the volume of this discussion, I will be coming up with a
 way to have all these poms overlayed(or some other technical solution) to
 an unmodified ofbiz checkout.  Git submodules might not be the right
 approach, I need to look at git subtree a bit more.

 ps: It's suprising how quickly I was able to start getting maven to work.
 I thought it would be extremely difficult.

 pps: I did a comparison of ant, ivy, maven, and gradle at
 http://trends.google.com/.  Maven is the correct choice, gradle is too
 new.

 On 04/20/2015 01:43 PM, Pierre Smits wrote:

 Assumptions are the Mother of all Fuckups, is often said.

 Nevertheless, bringing all viewpoints and insights together (without the
 assumptions and/or coloured projections) will lead to a better informed
 community, enabling it to take the right decision.

 Best regards,

 Pierre Smits

 *ORRTIZ.COM http://www.orrtiz.com*
 Services  Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail  Trade
 http://www.orrtiz.com

 On Mon, Apr 20, 2015 at 8:31 PM, Ron Wheeler 
 rwhee...@artifact-software.com

 wrote:
 Sorry Pierre.
 I hope it did not not ruin your evening.
 I guess old tools are like old homes.
 Hard to say goodbye even if the new house fits your needs better.
 (Assuming that the consensus is that Ant needs replacing)

 Ron

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

  Thanks for sharing the viewpoints. I could (just barely) suppress a
 physical reaction when I read 'Getting rid of ant is a good thing
 regardless'.

 Luckily we implement changes based on consensus, not the preference of
 the
 few.

 Best regards,

 Pierre Smits

 *ORRTIZ.COM http://www.orrtiz.com*
 Services  Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail  Trade
 http://www.orrtiz.com

 On Mon, Apr 20, 2015 at 8:00 PM, Ron Wheeler 
 rwhee...@artifact-software.com

  wrote:
 Maven imposes a philosophy on builds that you either follow or fight
 (and
 lose).

 The good side is that once you have your structure and supporting
 processes in place anyone who knows a little bit of Maven can run a
 build
 without looking at the pom and can add a dependency without destroying
 the
 build.
 You can build plug-ins to encapsulate best practices or to accomplish
 tasks that are not part of the software build.
 It is still possible to misuse Maven but it takes a lot of work and
 there
 is an active community to help avoid doing silly things.
 It is also actively supported with regular new versions so bug fixes
 and
 enhancement do get released quickly.

 I have used Maven for years and like it a lot.

 Gradle is new and getting a lot of attention so it might be a better
 choice but I have never used it.
 Flexibility is nice until some bad practices get put into a build
 process
 to solve a problem quickly rather than well.

 I love Ant and use it for other things but as a build tool it is too
 flexible and does not impose any structure or Best Practices.

It also is an additional step on the learning curve which acts as a
 barrier to attracting developers; specially younger members who have
 been
 using more modern tools.

 Getting rid of Ant is a good thing regardless of where you go.

 Ron


 On 20/04/2015 1:25 PM, Jacopo Cappellato wrote:

   Some of the build files are really ugly at the moment and difficult
 to

 read: see the macros.xml, src-extra-set etc...
 The ability to write real code snippets may greatly simplify them.

 Jacopo

 On Apr 20, 2015, at 7:00 PM, David E. Jones d...@me.com wrote:

That gets back to the question of why change in the first place...
 build

  files may be smaller and easier to maintain, but there may not be a
 good
 reason!

 -David


On 20 Apr 2015, at 09:37, Pierre Smits pierre.sm...@gmail.com
 wrote:

  David,

 Thanks for sharing your insights. You talk about

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

2015-04-21 Thread 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







--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/Re-svn-commit-r1674216-in-ofbiz-trunk-framework-start-pom-xml-pom-xml-tp498p4667055.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml



On 04/21/2015 04:06 PM, Nicolas Malin wrote:

Le 21/04/2015 22:37, Adam Heath a écrit :
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. 
Definitely, all commiter try to have a positive attitude to improve 
OFBiz. Your commit break nothing (on technical aspect), and I'm sure 
maven would be a good improvement.


Only, Jacopo start a discussion to improve OFBiz with Gradle 
http://ofbiz.135035.n4.nabble.com/Discussion-migrating-from-Ant-to-Gradle-td4654092.html#a4654170 
and adding pom.xml has an effect of bombshell. If you explain before 
on this thread that maven is better and why, your commit would be 
appreciate in its just value.


Before your commit I had not idea on gradle or maven, but with my 
french mentality now I prefer Gradle ;) (completely not subjective!)




Gradle is a non-starter.  When I saw that mentioned, I actually did do 
some comparisons.


In google, search for maven, then gradle.  See how many responses each 
one gets.


Then, go to trends.google.com, compare the above 2 items, and then add 
ant.  You might want to say apache ant or apache maven, and/or add 
java terms.


Then, also do a A vs B vs C search, aka, maven vs gradle vs ant.

After doing this, maven is still the right choice.

Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

2015-04-21 Thread Nicolas Malin


Le 21/04/2015 22:37, Adam Heath a écrit :
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. 
Definitely, all commiter try to have a positive attitude to improve 
OFBiz. Your commit break nothing (on technical aspect), and I'm sure 
maven would be a good improvement.


Only, Jacopo start a discussion to improve OFBiz with Gradle 
http://ofbiz.135035.n4.nabble.com/Discussion-migrating-from-Ant-to-Gradle-td4654092.html#a4654170 
and adding pom.xml has an effect of bombshell. If you explain before on 
this thread that maven is better and why, your commit would be 
appreciate in its just value.


Before your commit I had not idea on gradle or maven, but with my french 
mentality now I prefer Gradle ;) (completely not subjective!)


You are a competent commiter but please community over the code.

Regards
Nicolas

Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

On 04/21/2015 04:30 PM, Jacques Le Roux wrote:

Le 21/04/2015 23:17, Adam Heath a écrit :

On 04/21/2015 04:06 PM, Nicolas Malin wrote:

Le 21/04/2015 22:37, Adam Heath a écrit :
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.
Definitely, all commiter try to have a positive attitude to improve
OFBiz. Your commit break nothing (on technical aspect), and I'm sure
maven would be a good improvement.

Only, Jacopo start a discussion to improve OFBiz with Gradle
http://ofbiz.135035.n4.nabble.com/Discussion-migrating-from-Ant-to-Gradle-td4654092.html#a4654170
and adding pom.xml has an effect of bombshell. If you explain before
on this thread that maven is better and why, your commit would be
appreciate in its just value.

Before your commit I had not idea on gradle or maven, but with my
french mentality now I prefer Gradle ;) (completely not subjective!)

Gradle is a non-starter. When I saw that mentioned, I actually did
do some comparisons.

In google, search for maven, then gradle. See how many responses
each one gets.

Then, go to trends.google.com, compare the above 2 items, and then
add ant. You might want to say apache ant or apache maven,
and/or add java terms.

Then, also do a A vs B vs C search, aka, maven vs gradle vs ant.

After doing this, maven is still the right choice.

Quantity is not quality

That seems to be a bit of an abrupt statement. Do you have anything
more substantive to say? Did you actually attempt to dig down into the
suggestions I gave? Or was this a knee-jerk response to my attempt at
actually investigating gradle?

Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml



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

On Apr 21, 2015, at 12:33 AM, Adam Heath doo...@brainfood.com wrote:


(picking a random email to respond to; I haven't read anything of this thread 
all weekend, I will need to spend some time doing so)

Fyi, I have framework/start, base, and entity all compiling with maven now. API test 
cases work.  Separate foo.jar and foo-test.jar are done.  META-INF/services/ all 
located properly.  Everything in base/lib/** and entity/lib/** has dependency 
settings in pom.xml, but *without* having to download anything(yet).  I can't stress 
enough that there are *no* changes to any existing files. Absolutely none.

As such, due to the volume of this discussion, I will be coming up with a way 
to have all these poms overlayed(or some other technical solution) to an 
unmodified ofbiz checkout.  Git submodules might not be the right approach, I 
need to look at git subtree a bit more.

ps: It's suprising how quickly I was able to start getting maven to work.  I 
thought it would be extremely difficult.

pps: I did a comparison of ant, ivy, maven, and gradle at 
http://trends.google.com/.  Maven is the correct choice, gradle is too new.

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.

Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

2015-04-21 Thread Heidi Dehaes

Step forward to use Maven !
Easy to use. Difficult to learn.

Eric
Olagos bvba
Heidi Dehaes
Kerkstraat 34
2570 Duffel
Belgium
Tel. : 015/31 53 04
GSM :0485/22 35 80
E-mail : info.ola...@gmail.com
http://www.olagos.eu
http://www.olagos.com
http://www.olagos.be
http://www.olagos.nl




2015-04-21 22:37 GMT+02:00 Adam Heath doo...@brainfood.com:

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

 On Apr 21, 2015, at 12:33 AM, Adam Heath doo...@brainfood.com wrote:

 (picking a random email to respond to; I haven't read anything of this
 thread all weekend, I will need to spend some time doing so)

 Fyi, I have framework/start, base, and entity all compiling with maven
 now. API test cases work.  Separate foo.jar and foo-test.jar are done.
 META-INF/services/ all located properly.  Everything in base/lib/** and
 entity/lib/** has dependency settings in pom.xml, but *without* having to
 download anything(yet).  I can't stress enough that there are *no* changes
 to any existing files. Absolutely none.

 As such, due to the volume of this discussion, I will be coming up with a
 way to have all these poms overlayed(or some other technical solution) to an
 unmodified ofbiz checkout.  Git submodules might not be the right approach,
 I need to look at git subtree a bit more.

 ps: It's suprising how quickly I was able to start getting maven to work.
 I thought it would be extremely difficult.

 pps: I did a comparison of ant, ivy, maven, and gradle at
 http://trends.google.com/.  Maven is the correct choice, gradle is too new.

 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.

Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

2015-04-21 Thread Jacques Le Roux

Le 21/04/2015 23:17, Adam Heath a écrit :

On 04/21/2015 04:06 PM, Nicolas Malin wrote:

Le 21/04/2015 22:37, Adam Heath a écrit :

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

Only, Jacopo start a discussion to improve OFBiz with Gradle
http://ofbiz.135035.n4.nabble.com/Discussion-migrating-from-Ant-to-Gradle-td4654092.html#a4654170 and adding pom.xml has an effect of bombshell. If
you explain before on this thread that maven is better and why, your commit would be appreciate in its just value.

Before your commit I had not idea on gradle or maven, but with my french
mentality now I prefer Gradle ;) (completely not subjective!)

Gradle is a non-starter. When I saw that mentioned, I actually did do some
comparisons.

In google, search for maven, then gradle. See how many responses each one gets.

Then, go to trends.google.com, compare the above 2 items, and then add ant. You might want to say apache ant or apache maven, and/or add java
terms.

Then, also do a A vs B vs C search, aka, maven vs gradle vs ant.

After doing this, maven is still the right choice.

Quantity is not quality

Jacques

Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml



On 04/21/2015 04:07 PM, Heidi Dehaes wrote:

Step forward to use Maven !
Easy to use. Difficult to learn.


If you had asked me a week ago, at the start of ApacheCon, whether I 
thought a move to maven was possible, I would have gone postal; No way, 
hell no, not going to happen.


By the end of day Thursday, I had a working PoC.  And, I was returning 
from ApacheCon on Thursday, and didn't get home until 6pm or so.  And 
this PoC was only 45 minutes of time investment.  So, difficult to 
learn?  No, not really.

Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

2015-04-21 Thread Pierre Smits

The discussion whether or not to switch is still ongoing, is still
undecided. You have made your choice. That is your prerogative. No one
within this community can deny you that. But you're forcing... Your
preference without consensus within/of the Community.

You're actions don't match the responsibilities that come with the
privileges. Not those of a committer. Even less those of a PMC Member.

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 11:17 PM, Adam Heath doo...@brainfood.com wrote:

On 04/21/2015 04:06 PM, Nicolas Malin wrote:

Le 21/04/2015 22:37, Adam Heath a écrit :

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

Definitely, all commiter try to have a positive attitude to improve
OFBiz. Your commit break nothing (on technical aspect), and I'm sure maven
would be a good improvement.

Only, Jacopo start a discussion to improve OFBiz with Gradle
http://ofbiz.135035.n4.nabble.com/Discussion-migrating-from-Ant-to-Gradle-td4654092.html#a4654170
and adding pom.xml has an effect of bombshell. If you explain before on
this thread that maven is better and why, your commit would be appreciate
in its just value.

Before your commit I had not idea on gradle or maven, but with my french
mentality now I prefer Gradle ;) (completely not subjective!)

Gradle is a non-starter. When I saw that mentioned, I actually did do
some comparisons.

In google, search for maven, then gradle. See how many responses each one
gets.

Then, go to trends.google.com, compare the above 2 items, and then add
ant. You might want to say apache ant or apache maven, and/or add java
terms.

Then, also do a A vs B vs C search, aka, maven vs gradle vs ant.

After doing this, maven is still the right choice.

Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

2015-04-21 Thread Ron Wheeler

The nice thing about Maven is that very few people actually have to 
learn it.
Once you have the pom set up and the projects structured, the 
maintenance is very simple and you don't really need to know Maven to do 
most common operations (update dependency version - change a property in 
the pom, add a new dependency - add a GAV).


You are right for those who want to restructure the project or change 
the deliverable structure but you have the same problem with Ant.


From the core committers' (project managers/gatekeeper) points of view, 
it is easier to see what libraries are being used and easy to know if 
someone tries to change one.


I found it very easy to add junior programmers to our project since they 
did not have to learn the build system at all except for being able to 
click on the POM and select install.


If there are a few Maven experts in the project, that should be sufficient.

Ron


On 21/04/2015 5:07 PM, Heidi Dehaes wrote:

Step forward to use Maven !
Easy to use. Difficult to learn.

Eric
Olagos bvba
Heidi Dehaes
Kerkstraat 34
2570 Duffel
Belgium
Tel. : 015/31 53 04
GSM :0485/22 35 80
E-mail : info.ola...@gmail.com
http://www.olagos.eu
http://www.olagos.com
http://www.olagos.be
http://www.olagos.nl




2015-04-21 22:37 GMT+02:00 Adam Heath doo...@brainfood.com:

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

On Apr 21, 2015, at 12:33 AM, Adam Heath doo...@brainfood.com wrote:


(picking a random email to respond to; I haven't read anything of this
thread all weekend, I will need to spend some time doing so)

Fyi, I have framework/start, base, and entity all compiling with maven
now. API test cases work.  Separate foo.jar and foo-test.jar are done.
META-INF/services/ all located properly.  Everything in base/lib/** and
entity/lib/** has dependency settings in pom.xml, but *without* having to
download anything(yet).  I can't stress enough that there are *no* changes
to any existing files. Absolutely none.

As such, due to the volume of this discussion, I will be coming up with a
way to have all these poms overlayed(or some other technical solution) to an
unmodified ofbiz checkout.  Git submodules might not be the right approach,
I need to look at git subtree a bit more.

ps: It's suprising how quickly I was able to start getting maven to work.
I thought it would be extremely difficult.

pps: I did a comparison of ant, ivy, maven, and gradle at
http://trends.google.com/.  Maven is the correct choice, gradle is too new.

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;

Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

As another point, you keep responding with attacks, instead of 
discussing actual datapoints.  I'm mentioning features, additions, 
whatever, but I see nothing constructive from your direction.


Let's move back to a technical discussion, and can we have a stop of 
this vitriol?


On 04/21/2015 05:12 PM, Adam Heath wrote:


On 04/21/2015 04:27 PM, Pierre Smits wrote:

The discussion whether or not to switch is still ongoing, is still
undecided. You have made your choice. That is your prerogative. No one
within this community can deny you that. But you're forcing... Your
preference without consensus within/of the Community.

You're actions don't match the responsibilities that come with the
privileges. Not those of a committer. Even less those of a PMC Member.


Bother.  You're really burning bridges here.  Seriously.  This is a 
personal attack from you.  Go read the code of conduct that Jacopo 
posted.  NOW!


ps: as a history lesson, look who added java 1.5 generics, enhanced 
for-loop, and other new features, to *ALL* of the framework.  That was 
all done without any kind of automatic tool. I typed in *every* 
*single* *one* of those lines.  Just to state again, *ALL* of 
framework.  And realize what that means.


pps: Also, I have since filed an issue, and will be further commiting 
into a branch; so, your personal attacks aren't holding water.

Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

2015-04-21 Thread Pierre Smits

Adam,

Shall we let other committers, who favour the ANT+IVY approach also move
forward and implement their stuff as well as it will surely not break
anything as well?
Shall we also let other committers, who favour the Groovy/Gradle approach
also move forward and implement their solutions as well as it will surely
not break anything?

Is this the path you want to walk? Code over Community? Engage in commit
wars, just to force your way? Please don't!  Collaborating is easier than
forcing. The latter harms the project more than the first.

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 10:37 PM, Adam Heath doo...@brainfood.com wrote:


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

 On Apr 21, 2015, at 12:33 AM, Adam Heath doo...@brainfood.com wrote:

  (picking a random email to respond to; I haven't read anything of this
 thread all weekend, I will need to spend some time doing so)

 Fyi, I have framework/start, base, and entity all compiling with maven
 now. API test cases work.  Separate foo.jar and foo-test.jar are done.
 META-INF/services/ all located properly.  Everything in base/lib/** and
 entity/lib/** has dependency settings in pom.xml, but *without* having to
 download anything(yet).  I can't stress enough that there are *no* changes
 to any existing files. Absolutely none.

 As such, due to the volume of this discussion, I will be coming up with
 a way to have all these poms overlayed(or some other technical solution) to
 an unmodified ofbiz checkout.  Git submodules might not be the right
 approach, I need to look at git subtree a bit more.

 ps: It's suprising how quickly I was able to start getting maven to
 work.  I thought it would be extremely difficult.

 pps: I did a comparison of ant, ivy, maven, and gradle at
 http://trends.google.com/.  Maven is the correct choice, gradle is too
 new.

 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.

Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml



On 04/21/2015 04:27 PM, Pierre Smits wrote:

The discussion whether or not to switch is still ongoing, is still
undecided. You have made your choice. That is your prerogative. No one
within this community can deny you that. But you're forcing... Your
preference without consensus within/of the Community.

You're actions don't match the responsibilities that come with the
privileges. Not those of a committer. Even less those of a PMC Member.


Bother.  You're really burning bridges here.  Seriously.  This is a 
personal attack from you.  Go read the code of conduct that Jacopo 
posted.  NOW!


ps: as a history lesson, look who added java 1.5 generics, enhanced 
for-loop, and other new features, to *ALL* of the framework.  That was 
all done without any kind of automatic tool.  I typed in *every* 
*single* *one* of those lines.  Just to state again, *ALL* of 
framework.  And realize what that means.


pps: Also, I have since filed an issue, and will be further commiting 
into a branch; so, your personal attacks aren't holding water.

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml


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

On 20 Apr 2015, at 12:29, Ron Wheeler rwhee...@artifact-software.com 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: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

2015-04-20 Thread Adam Heath

(picking a random email to respond to; I haven't read anything of this 
thread all weekend, I will need to spend some time doing so)


Fyi, I have framework/start, base, and entity all compiling with maven 
now. API test cases work.  Separate foo.jar and foo-test.jar are done.  
META-INF/services/ all located properly.  Everything in base/lib/** and 
entity/lib/** has dependency settings in pom.xml, but *without* having 
to download anything(yet).  I can't stress enough that there are *no* 
changes to any existing files. Absolutely none.


As such, due to the volume of this discussion, I will be coming up with 
a way to have all these poms overlayed(or some other technical solution) 
to an unmodified ofbiz checkout.  Git submodules might not be the right 
approach, I need to look at git subtree a bit more.


ps: It's suprising how quickly I was able to start getting maven to 
work.  I thought it would be extremely difficult.


pps: I did a comparison of ant, ivy, maven, and gradle at 
http://trends.google.com/.  Maven is the correct choice, gradle is too new.


On 04/20/2015 01:43 PM, Pierre Smits wrote:

Assumptions are the Mother of all Fuckups, is often said.

Nevertheless, bringing all viewpoints and insights together (without the
assumptions and/or coloured projections) will lead to a better informed
community, enabling it to take the right decision.

Best regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Mon, Apr 20, 2015 at 8:31 PM, Ron Wheeler rwhee...@artifact-software.com

wrote:
Sorry Pierre.
I hope it did not not ruin your evening.
I guess old tools are like old homes.
Hard to say goodbye even if the new house fits your needs better.
(Assuming that the consensus is that Ant needs replacing)

Ron

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


Thanks for sharing the viewpoints. I could (just barely) suppress a
physical reaction when I read 'Getting rid of ant is a good thing
regardless'.

Luckily we implement changes based on consensus, not the preference of the
few.

Best regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Mon, Apr 20, 2015 at 8:00 PM, Ron Wheeler 
rwhee...@artifact-software.com


wrote:
Maven imposes a philosophy on builds that you either follow or fight (and
lose).

The good side is that once you have your structure and supporting
processes in place anyone who knows a little bit of Maven can run a build
without looking at the pom and can add a dependency without destroying
the
build.
You can build plug-ins to encapsulate best practices or to accomplish
tasks that are not part of the software build.
It is still possible to misuse Maven but it takes a lot of work and there
is an active community to help avoid doing silly things.
It is also actively supported with regular new versions so bug fixes and
enhancement do get released quickly.

I have used Maven for years and like it a lot.

Gradle is new and getting a lot of attention so it might be a better
choice but I have never used it.
Flexibility is nice until some bad practices get put into a build process
to solve a problem quickly rather than well.

I love Ant and use it for other things but as a build tool it is too
flexible and does not impose any structure or Best Practices.

   It also is an additional step on the learning curve which acts as a
barrier to attracting developers; specially younger members who have been
using more modern tools.

Getting rid of Ant is a good thing regardless of where you go.

Ron


On 20/04/2015 1:25 PM, Jacopo Cappellato wrote:

  Some of the build files are really ugly at the moment and difficult to

read: see the macros.xml, src-extra-set etc...
The ability to write real code snippets may greatly simplify them.

Jacopo

On Apr 20, 2015, at 7:00 PM, David E. Jones d...@me.com wrote:

   That gets back to the question of why change in the first place...
build


files may be smaller and easier to maintain, but there may not be a
good
reason!

-David


   On 20 Apr 2015, at 09:37, Pierre Smits pierre.sm...@gmail.com
wrote:


David,

Thanks for sharing your insights. You talk about 'pretty much anything
can be done with'. What, in your experience, can't be done -at the
moment- in relation to OFBiz?

Best regards,

Pierre

Op maandag 20 april 2015 heeft David E. Jones d...@me.com het
volgende
geschreven:

   Not to muddy the waters... but Gradle might be a good alternative.


There
is a lot more in it than Ant that just works without needing to be
explicit, especially when you follow Maven conventions for layout of
src
directories.

One big upside of Gradle is that all build files are Groovy scripts
and
you can do pretty much anything in them. One downside is the learning
curve... there is an extensive DSL with pretty good documentation,
but
some

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

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 
rwhee...@artifact-software.com wrote:

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

 On 20 Apr 2015, at 12:29, Ron Wheeler rwhee...@artifact-software.com
 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: rwhee...@artifact-software.com
 skype: ronaldmwheeler
 phone: 866-970-2435, ext 102

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

2015-04-20 Thread Jacopo Cappellato

On Apr 21, 2015, at 12:33 AM, Adam Heath doo...@brainfood.com wrote:

 (picking a random email to respond to; I haven't read anything of this thread 
 all weekend, I will need to spend some time doing so)
 
 Fyi, I have framework/start, base, and entity all compiling with maven now. 
 API test cases work.  Separate foo.jar and foo-test.jar are done.  
 META-INF/services/ all located properly.  Everything in base/lib/** and 
 entity/lib/** has dependency settings in pom.xml, but *without* having to 
 download anything(yet).  I can't stress enough that there are *no* changes to 
 any existing files. Absolutely none.
 
 As such, due to the volume of this discussion, I will be coming up with a way 
 to have all these poms overlayed(or some other technical solution) to an 
 unmodified ofbiz checkout.  Git submodules might not be the right approach, I 
 need to look at git subtree a bit more.
 
 ps: It's suprising how quickly I was able to start getting maven to work.  I 
 thought it would be extremely difficult.
 
 pps: I did a comparison of ant, ivy, maven, and gradle at 
 http://trends.google.com/.  Maven is the correct choice, gradle is too new.

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

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml


 On 20 Apr 2015, at 12:29, Ron Wheeler rwhee...@artifact-software.com 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

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Ant + IVY delivers as much dependency management functionality as maven
does.

Maven is good for building jar solutions. We don't build jar solutions. We
exploit jars!

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:51 AM, Hans Bakker mailingl...@antwebsystems.com
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

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Ant + IVY are a better fit for the OFBiz.

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 1:02 PM, Pierre Smits pierre.sm...@gmail.com
wrote:

 Ant + IVY delivers as much dependency management functionality as maven
 does.

 Maven is good for building jar solutions. We don't build jar solutions. We
 exploit jars!

 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:51 AM, Hans Bakker 
 mailingl...@antwebsystems.com 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

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Thanks for sharing the viewpoints. I could (just barely) suppress a
physical reaction when I read 'Getting rid of ant is a good thing
regardless'.

Luckily we implement changes based on consensus, not the preference of the
few.

Best regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Mon, Apr 20, 2015 at 8:00 PM, Ron Wheeler rwhee...@artifact-software.com
 wrote:

 Maven imposes a philosophy on builds that you either follow or fight (and
 lose).

 The good side is that once you have your structure and supporting
 processes in place anyone who knows a little bit of Maven can run a build
 without looking at the pom and can add a dependency without destroying the
 build.
 You can build plug-ins to encapsulate best practices or to accomplish
 tasks that are not part of the software build.
 It is still possible to misuse Maven but it takes a lot of work and there
 is an active community to help avoid doing silly things.
 It is also actively supported with regular new versions so bug fixes and
 enhancement do get released quickly.

 I have used Maven for years and like it a lot.

 Gradle is new and getting a lot of attention so it might be a better
 choice but I have never used it.
 Flexibility is nice until some bad practices get put into a build process
 to solve a problem quickly rather than well.

 I love Ant and use it for other things but as a build tool it is too
 flexible and does not impose any structure or Best Practices.

  It also is an additional step on the learning curve which acts as a
 barrier to attracting developers; specially younger members who have been
 using more modern tools.

 Getting rid of Ant is a good thing regardless of where you go.

 Ron


 On 20/04/2015 1:25 PM, Jacopo Cappellato wrote:

 Some of the build files are really ugly at the moment and difficult to
 read: see the macros.xml, src-extra-set etc...
 The ability to write real code snippets may greatly simplify them.

 Jacopo

 On Apr 20, 2015, at 7:00 PM, David E. Jones d...@me.com wrote:

  That gets back to the question of why change in the first place... build
 files may be smaller and easier to maintain, but there may not be a good
 reason!

 -David


  On 20 Apr 2015, at 09:37, Pierre Smits pierre.sm...@gmail.com wrote:

 David,

 Thanks for sharing your insights. You talk about 'pretty much anything
 can be done with'. What, in your experience, can't be done -at the
 moment- in relation to OFBiz?

 Best regards,

 Pierre

 Op maandag 20 april 2015 heeft David E. Jones d...@me.com het
 volgende
 geschreven:

  Not to muddy the waters... but Gradle might be a good alternative.
 There
 is a lot more in it than Ant that just works without needing to be
 explicit, especially when you follow Maven conventions for layout of
 src
 directories.

 One big upside of Gradle is that all build files are Groovy scripts and
 you can do pretty much anything in them. One downside is the learning
 curve... there is an extensive DSL with pretty good documentation, but
 some
 things that would seem simple are non-obvious (to put it generously).
 On
 the other hand, there is fairly wide use so I still have yet to run
 anything where I couldn't find a solution quickly with a google search.

 -David


  On 19 Apr 2015, at 22:51, Hans Bakker mailingl...@antwebsystems.com

 javascript:; wrote:

 We should seriously consider the comments from Adam and move to maven.

 Regards,
 Hans
 antwebsystems.com


 On 18/04/15 00:41, Adam Heath wrote:

 On 04/17/2015 10:20 AM, Jacques Le Roux wrote:

 Thanks for your detailed heads-up Martin, notably your last point!

 I mostly agree, and indeed I also think Maven might not be so bad
 when

 you start anew (or are forced to use it ;) ) but for OFBiz, really
 NO!

 Jacques

 Le 17/04/2015 16:27, Martin Becker a écrit :

 +1 for lack of benefit (and for fear ;-))

 The commit I did last night took me 45 minutes.  Full stop.  I
 started

 at 12:03am.  And I did it while drinking a second beer. Maven was that
 simple.  I had resisted for years.  Years!  But when I actually sat
 down to
 do it, I realized that I did *not* have to change what I was doing.
 Maven
 could be configured to work with the existing design.

 The benefits are:

 * not having to write our own build system; ant is not a build
 system.

 * full external dependency management.  This can be done very

 incrementally.  I just got framework/base to compile, by reusing the
 previously downloaded jars in framework/base/lib.  Then, when all
 dependencies are *properly* listed, we can switch to the download
 mechanism, and suddenly, the checkout becomes smaller.

 * full internal dependency support.  As part of framework/base now

 having a working pom.xml, it has a dep on framework/start.  This can
 allow
 for end-users wanting to just install applications/party, and having
 just
 what is required get downloaded.

 *

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

2015-04-20 Thread Jacopo Cappellato

Some of the build files are really ugly at the moment and difficult to read: 
see the macros.xml, src-extra-set etc...
The ability to write real code snippets may greatly simplify them.

Jacopo

On Apr 20, 2015, at 7:00 PM, David E. Jones d...@me.com wrote:

 
 That gets back to the question of why change in the first place... build 
 files may be smaller and easier to maintain, but there may not be a good 
 reason!
 
 -David
 
 
 On 20 Apr 2015, at 09:37, Pierre Smits pierre.sm...@gmail.com wrote:
 
 David,
 
 Thanks for sharing your insights. You talk about 'pretty much anything
 can be done with'. What, in your experience, can't be done -at the
 moment- in relation to OFBiz?
 
 Best regards,
 
 Pierre
 
 Op maandag 20 april 2015 heeft David E. Jones d...@me.com het volgende
 geschreven:
 
 
 Not to muddy the waters... but Gradle might be a good alternative. There
 is a lot more in it than Ant that just works without needing to be
 explicit, especially when you follow Maven conventions for layout of src
 directories.
 
 One big upside of Gradle is that all build files are Groovy scripts and
 you can do pretty much anything in them. One downside is the learning
 curve... there is an extensive DSL with pretty good documentation, but some
 things that would seem simple are non-obvious (to put it generously). On
 the other hand, there is fairly wide use so I still have yet to run
 anything where I couldn't find a solution quickly with a google search.
 
 -David
 
 
 On 19 Apr 2015, at 22:51, Hans Bakker mailingl...@antwebsystems.com
 javascript:; wrote:
 
 We should seriously consider the comments from Adam and move to maven.
 
 Regards,
 Hans
 antwebsystems.com
 
 
 On 18/04/15 00:41, Adam Heath wrote:
 
 On 04/17/2015 10:20 AM, Jacques Le Roux wrote:
 Thanks for your detailed heads-up Martin, notably your last point!
 
 I mostly agree, and indeed I also think Maven might not be so bad when
 you start anew (or are forced to use it ;) ) but for OFBiz, really NO!
 
 Jacques
 
 Le 17/04/2015 16:27, Martin Becker a écrit :
 +1 for lack of benefit (and for fear ;-))
 
 The commit I did last night took me 45 minutes.  Full stop.  I started
 at 12:03am.  And I did it while drinking a second beer. Maven was that
 simple.  I had resisted for years.  Years!  But when I actually sat down to
 do it, I realized that I did *not* have to change what I was doing.  Maven
 could be configured to work with the existing design.
 
 The benefits are:
 
 * not having to write our own build system; ant is not a build system.
 
 * full external dependency management.  This can be done very
 incrementally.  I just got framework/base to compile, by reusing the
 previously downloaded jars in framework/base/lib.  Then, when all
 dependencies are *properly* listed, we can switch to the download
 mechanism, and suddenly, the checkout becomes smaller.
 
 * full internal dependency support.  As part of framework/base now
 having a working pom.xml, it has a dep on framework/start.  This can allow
 for end-users wanting to just install applications/party, and having just
 what is required get downloaded.
 
 * Each ofbiz component could be moved to separate repos, and
 development can progress on its own.  All that specialpurpose/* stuff no
 longer needs to be carried along with the rest of the codebase.
 
 * continuous integration becomes so much simpler; the standard mvn
 package call does command-line unit tests, *by default*.
 
 * these poms do not break anything.  Nothing calls them.  Everyone can
 continue to use ant, eclipse, or DIP switches, to compile and run ofbiz.
 So, having them in trunk won't cause issue for anyone else.  This is the
 way linux-kernel functions.  Completely new, isolated features, that affect
 no one else, are added to master/linux-next, so that they can get pushed
 out to more users, for more testing.  If something is done in a separate
 branch, they have discovered it doesn't recieve enough widespread testing.
 
 
 
 My first thoughts:
 
 = If a change is desired, than Gradle would surely be a good choice
 as it is the next generation build tool witch tries to combine the
 advantages from tools like ant, maven and others…
 
 Sure, why not?
 
 
 Besides, I'm the one who created ${ofbiz.home.dir}/macros.xml and
 common.xml, but really, lets not go there.
 
 
 = I think the stability of Gradle is not a question as it is used by
 projects like Spring, Hibernate, Grails, Groovy and others…
 
 = With the ability to use ant tasks and whole ant build scripts
 within Gradle, a smooth migration could be an option
 
 
 Maven can call ant.  I'm even doing so in the 2 poms that I added.
 
 = Maven rely on it’s convention over configuration pattern, so it is
 never a good idea to NOT follow it’s conventions by configuring it for a
 different project structure for example. So there may be the need for
 massive changes to the OFBiz project structure and so on.
 
 
 I just got framework/base to compile with maven.  This

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Maven imposes a philosophy on builds that you either follow or fight 
(and lose).


The good side is that once you have your structure and supporting 
processes in place anyone who knows a little bit of Maven can run a 
build without looking at the pom and can add a dependency without 
destroying the build.
You can build plug-ins to encapsulate best practices or to accomplish 
tasks that are not part of the software build.
It is still possible to misuse Maven but it takes a lot of work and 
there is an active community to help avoid doing silly things.
It is also actively supported with regular new versions so bug fixes and 
enhancement do get released quickly.


I have used Maven for years and like it a lot.

Gradle is new and getting a lot of attention so it might be a better 
choice but I have never used it.
Flexibility is nice until some bad practices get put into a build 
process to solve a problem quickly rather than well.


I love Ant and use it for other things but as a build tool it is too 
flexible and does not impose any structure or Best Practices.


 It also is an additional step on the learning curve which acts as a 
barrier to attracting developers; specially younger members who have 
been using more modern tools.


Getting rid of Ant is a good thing regardless of where you go.

Ron

On 20/04/2015 1:25 PM, Jacopo Cappellato wrote:

Some of the build files are really ugly at the moment and difficult to read: 
see the macros.xml, src-extra-set etc...
The ability to write real code snippets may greatly simplify them.

Jacopo

On Apr 20, 2015, at 7:00 PM, David E. Jones d...@me.com wrote:


That gets back to the question of why change in the first place... build files 
may be smaller and easier to maintain, but there may not be a good reason!

-David



On 20 Apr 2015, at 09:37, Pierre Smits pierre.sm...@gmail.com wrote:

David,

Thanks for sharing your insights. You talk about 'pretty much anything
can be done with'. What, in your experience, can't be done -at the
moment- in relation to OFBiz?

Best regards,

Pierre

Op maandag 20 april 2015 heeft David E. Jones d...@me.com het volgende
geschreven:


Not to muddy the waters... but Gradle might be a good alternative. There
is a lot more in it than Ant that just works without needing to be
explicit, especially when you follow Maven conventions for layout of src
directories.

One big upside of Gradle is that all build files are Groovy scripts and
you can do pretty much anything in them. One downside is the learning
curve... there is an extensive DSL with pretty good documentation, but some
things that would seem simple are non-obvious (to put it generously). On
the other hand, there is fairly wide use so I still have yet to run
anything where I couldn't find a solution quickly with a google search.

-David



On 19 Apr 2015, at 22:51, Hans Bakker mailingl...@antwebsystems.com

javascript:; wrote:

We should seriously consider the comments from Adam and move to maven.

Regards,
Hans
antwebsystems.com


On 18/04/15 00:41, Adam Heath wrote:

On 04/17/2015 10:20 AM, Jacques Le Roux wrote:

Thanks for your detailed heads-up Martin, notably your last point!

I mostly agree, and indeed I also think Maven might not be so bad when

you start anew (or are forced to use it ;) ) but for OFBiz, really NO!

Jacques

Le 17/04/2015 16:27, Martin Becker a écrit :

+1 for lack of benefit (and for fear ;-))

The commit I did last night took me 45 minutes.  Full stop.  I started

at 12:03am.  And I did it while drinking a second beer. Maven was that
simple.  I had resisted for years.  Years!  But when I actually sat down to
do it, I realized that I did *not* have to change what I was doing.  Maven
could be configured to work with the existing design.

The benefits are:

* not having to write our own build system; ant is not a build system.

* full external dependency management.  This can be done very

incrementally.  I just got framework/base to compile, by reusing the
previously downloaded jars in framework/base/lib.  Then, when all
dependencies are *properly* listed, we can switch to the download
mechanism, and suddenly, the checkout becomes smaller.

* full internal dependency support.  As part of framework/base now

having a working pom.xml, it has a dep on framework/start.  This can allow
for end-users wanting to just install applications/party, and having just
what is required get downloaded.

* Each ofbiz component could be moved to separate repos, and

development can progress on its own.  All that specialpurpose/* stuff no
longer needs to be carried along with the rest of the codebase.

* continuous integration becomes so much simpler; the standard mvn

package call does command-line unit tests, *by default*.

* these poms do not break anything.  Nothing calls them.  Everyone can

continue to use ant, eclipse, or DIP switches, to compile and run ofbiz.
So, having them in trunk won't cause issue for anyone else.  This is the
way linux-kernel functions.

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

David,

Thanks for sharing your insights. You talk about 'pretty much anything
can be done with'. What, in your experience, can't be done -at the
moment- in relation to OFBiz?

Best regards,

Pierre

Op maandag 20 april 2015 heeft David E. Jones d...@me.com het volgende
geschreven:


 Not to muddy the waters... but Gradle might be a good alternative. There
 is a lot more in it than Ant that just works without needing to be
 explicit, especially when you follow Maven conventions for layout of src
 directories.

 One big upside of Gradle is that all build files are Groovy scripts and
 you can do pretty much anything in them. One downside is the learning
 curve... there is an extensive DSL with pretty good documentation, but some
 things that would seem simple are non-obvious (to put it generously). On
 the other hand, there is fairly wide use so I still have yet to run
 anything where I couldn't find a solution quickly with a google search.

 -David


  On 19 Apr 2015, at 22:51, Hans Bakker mailingl...@antwebsystems.com
 javascript:; wrote:
 
  We should seriously consider the comments from Adam and move to maven.
 
  Regards,
  Hans
  antwebsystems.com
 
 
  On 18/04/15 00:41, Adam Heath wrote:
 
  On 04/17/2015 10:20 AM, Jacques Le Roux wrote:
  Thanks for your detailed heads-up Martin, notably your last point!
 
  I mostly agree, and indeed I also think Maven might not be so bad when
 you start anew (or are forced to use it ;) ) but for OFBiz, really NO!
 
  Jacques
 
  Le 17/04/2015 16:27, Martin Becker a écrit :
  +1 for lack of benefit (and for fear ;-))
 
  The commit I did last night took me 45 minutes.  Full stop.  I started
 at 12:03am.  And I did it while drinking a second beer. Maven was that
 simple.  I had resisted for years.  Years!  But when I actually sat down to
 do it, I realized that I did *not* have to change what I was doing.  Maven
 could be configured to work with the existing design.
 
  The benefits are:
 
  * not having to write our own build system; ant is not a build system.
 
  * full external dependency management.  This can be done very
 incrementally.  I just got framework/base to compile, by reusing the
 previously downloaded jars in framework/base/lib.  Then, when all
 dependencies are *properly* listed, we can switch to the download
 mechanism, and suddenly, the checkout becomes smaller.
 
  * full internal dependency support.  As part of framework/base now
 having a working pom.xml, it has a dep on framework/start.  This can allow
 for end-users wanting to just install applications/party, and having just
 what is required get downloaded.
 
  * Each ofbiz component could be moved to separate repos, and
 development can progress on its own.  All that specialpurpose/* stuff no
 longer needs to be carried along with the rest of the codebase.
 
  * continuous integration becomes so much simpler; the standard mvn
 package call does command-line unit tests, *by default*.
 
  * these poms do not break anything.  Nothing calls them.  Everyone can
 continue to use ant, eclipse, or DIP switches, to compile and run ofbiz.
 So, having them in trunk won't cause issue for anyone else.  This is the
 way linux-kernel functions.  Completely new, isolated features, that affect
 no one else, are added to master/linux-next, so that they can get pushed
 out to more users, for more testing.  If something is done in a separate
 branch, they have discovered it doesn't recieve enough widespread testing.
 
 
 
  My first thoughts:
 
  = If a change is desired, than Gradle would surely be a good choice
 as it is the next generation build tool witch tries to combine the
 advantages from tools like ant, maven and others…
 
  Sure, why not?
 
 
  Besides, I'm the one who created ${ofbiz.home.dir}/macros.xml and
 common.xml, but really, lets not go there.
 
 
  = I think the stability of Gradle is not a question as it is used by
 projects like Spring, Hibernate, Grails, Groovy and others…
 
  = With the ability to use ant tasks and whole ant build scripts
 within Gradle, a smooth migration could be an option
 
 
  Maven can call ant.  I'm even doing so in the 2 poms that I added.
 
  = Maven rely on it’s convention over configuration pattern, so it is
 never a good idea to NOT follow it’s conventions by configuring it for a
 different project structure for example. So there may be the need for
 massive changes to the OFBiz project structure and so on.
 
 
  I just got framework/base to compile with maven.  This includes *NO*
 changes to ofbiz layout.  framework/base/lib still exists. Nothing is being
 downloaded(except maven plugins, of course).
 
  = Also the ability to only produce one artifact per project in maven
 would perhaps end up in configuring sub projects for each application and
 module in OFBiz with a frustrating handling of multi module configurations
 with version-/release-tags, dependency handling and so on...
 
 
  This is wrong.  You can produce multiple artifacts.  I've seen it done

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml


That gets back to the question of why change in the first place... build files 
may be smaller and easier to maintain, but there may not be a good reason!

-David


 On 20 Apr 2015, at 09:37, Pierre Smits pierre.sm...@gmail.com wrote:
 
 David,
 
 Thanks for sharing your insights. You talk about 'pretty much anything
 can be done with'. What, in your experience, can't be done -at the
 moment- in relation to OFBiz?
 
 Best regards,
 
 Pierre
 
 Op maandag 20 april 2015 heeft David E. Jones d...@me.com het volgende
 geschreven:
 
 
 Not to muddy the waters... but Gradle might be a good alternative. There
 is a lot more in it than Ant that just works without needing to be
 explicit, especially when you follow Maven conventions for layout of src
 directories.
 
 One big upside of Gradle is that all build files are Groovy scripts and
 you can do pretty much anything in them. One downside is the learning
 curve... there is an extensive DSL with pretty good documentation, but some
 things that would seem simple are non-obvious (to put it generously). On
 the other hand, there is fairly wide use so I still have yet to run
 anything where I couldn't find a solution quickly with a google search.
 
 -David
 
 
 On 19 Apr 2015, at 22:51, Hans Bakker mailingl...@antwebsystems.com
 javascript:; wrote:
 
 We should seriously consider the comments from Adam and move to maven.
 
 Regards,
 Hans
 antwebsystems.com
 
 
 On 18/04/15 00:41, Adam Heath wrote:
 
 On 04/17/2015 10:20 AM, Jacques Le Roux wrote:
 Thanks for your detailed heads-up Martin, notably your last point!
 
 I mostly agree, and indeed I also think Maven might not be so bad when
 you start anew (or are forced to use it ;) ) but for OFBiz, really NO!
 
 Jacques
 
 Le 17/04/2015 16:27, Martin Becker a écrit :
 +1 for lack of benefit (and for fear ;-))
 
 The commit I did last night took me 45 minutes.  Full stop.  I started
 at 12:03am.  And I did it while drinking a second beer. Maven was that
 simple.  I had resisted for years.  Years!  But when I actually sat down to
 do it, I realized that I did *not* have to change what I was doing.  Maven
 could be configured to work with the existing design.
 
 The benefits are:
 
 * not having to write our own build system; ant is not a build system.
 
 * full external dependency management.  This can be done very
 incrementally.  I just got framework/base to compile, by reusing the
 previously downloaded jars in framework/base/lib.  Then, when all
 dependencies are *properly* listed, we can switch to the download
 mechanism, and suddenly, the checkout becomes smaller.
 
 * full internal dependency support.  As part of framework/base now
 having a working pom.xml, it has a dep on framework/start.  This can allow
 for end-users wanting to just install applications/party, and having just
 what is required get downloaded.
 
 * Each ofbiz component could be moved to separate repos, and
 development can progress on its own.  All that specialpurpose/* stuff no
 longer needs to be carried along with the rest of the codebase.
 
 * continuous integration becomes so much simpler; the standard mvn
 package call does command-line unit tests, *by default*.
 
 * these poms do not break anything.  Nothing calls them.  Everyone can
 continue to use ant, eclipse, or DIP switches, to compile and run ofbiz.
 So, having them in trunk won't cause issue for anyone else.  This is the
 way linux-kernel functions.  Completely new, isolated features, that affect
 no one else, are added to master/linux-next, so that they can get pushed
 out to more users, for more testing.  If something is done in a separate
 branch, they have discovered it doesn't recieve enough widespread testing.
 
 
 
 My first thoughts:
 
 = If a change is desired, than Gradle would surely be a good choice
 as it is the next generation build tool witch tries to combine the
 advantages from tools like ant, maven and others…
 
 Sure, why not?
 
 
 Besides, I'm the one who created ${ofbiz.home.dir}/macros.xml and
 common.xml, but really, lets not go there.
 
 
 = I think the stability of Gradle is not a question as it is used by
 projects like Spring, Hibernate, Grails, Groovy and others…
 
 = With the ability to use ant tasks and whole ant build scripts
 within Gradle, a smooth migration could be an option
 
 
 Maven can call ant.  I'm even doing so in the 2 poms that I added.
 
 = Maven rely on it’s convention over configuration pattern, so it is
 never a good idea to NOT follow it’s conventions by configuring it for a
 different project structure for example. So there may be the need for
 massive changes to the OFBiz project structure and so on.
 
 
 I just got framework/base to compile with maven.  This includes *NO*
 changes to ofbiz layout.  framework/base/lib still exists. Nothing is being
 downloaded(except maven plugins, of course).
 
 = Also the ability to only produce one artifact per project in maven
 would perhaps end up in configuring sub projects for each

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml


Not to muddy the waters... but Gradle might be a good alternative. There is a 
lot more in it than Ant that just works without needing to be explicit, 
especially when you follow Maven conventions for layout of src directories.

One big upside of Gradle is that all build files are Groovy scripts and you can 
do pretty much anything in them. One downside is the learning curve... there is 
an extensive DSL with pretty good documentation, but some things that would 
seem simple are non-obvious (to put it generously). On the other hand, there is 
fairly wide use so I still have yet to run anything where I couldn't find a 
solution quickly with a google search.

-David


 On 19 Apr 2015, at 22:51, Hans Bakker mailingl...@antwebsystems.com 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

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml


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 rwhee...@artifact-software.com

wrote:
Sorry Pierre.
I hope it did not not ruin your evening.
I guess old tools are like old homes.
Hard to say goodbye even if the new house fits your needs better.
(Assuming that the consensus is that Ant needs replacing)

Ron

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


Thanks for sharing the viewpoints. I could (just barely) suppress a
physical reaction when I read 'Getting rid of ant is a good thing
regardless'.

Luckily we implement changes based on consensus, not the preference of the
few.

Best regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Mon, Apr 20, 2015 at 8:00 PM, Ron Wheeler 
rwhee...@artifact-software.com


wrote:
Maven imposes a philosophy on builds that you either follow or fight (and
lose).

The good side is that once you have your structure and supporting
processes in place anyone who knows a little bit of Maven can run a build
without looking at the pom and can add a dependency without destroying
the
build.
You can build plug-ins to encapsulate best practices or to accomplish
tasks that are not part of the software build.
It is still possible to misuse Maven but it takes a lot of work and there
is an active community to help avoid doing silly things.
It is also actively supported with regular new versions so bug fixes and
enhancement do get released quickly.

I have used Maven for years and like it a lot.

Gradle is new and getting a lot of attention so it might be a better
choice but I have never used it.
Flexibility is nice until some bad practices get put into a build process
to solve a problem quickly rather than well.

I love Ant and use it for other things but as a build tool it is too
flexible and does not impose any structure or Best Practices.

   It also is an additional step on the learning curve which acts as a
barrier to attracting developers; specially younger members who have been
using more modern tools.

Getting rid of Ant is a good thing regardless of where you go.

Ron


On 20/04/2015 1:25 PM, Jacopo Cappellato wrote:

  Some of the build files are really ugly at the moment and difficult to

read: see the macros.xml, src-extra-set etc...
The ability to write real code snippets may greatly simplify them.

Jacopo

On Apr 20, 2015, at 7:00 PM, David E. Jones d...@me.com wrote:

   That gets back to the question of why change in the first place...
build


files may be smaller and easier to maintain, but there may not be a
good
reason!

-David


   On 20 Apr 2015, at 09:37, Pierre Smits pierre.sm...@gmail.com
wrote:


David,

Thanks for sharing your insights. You talk about 'pretty much anything
can be done with'. What, in your experience, can't be done -at the
moment- in relation to OFBiz?

Best regards,

Pierre

Op maandag 20 april 2015 heeft David E. Jones d...@me.com het
volgende
geschreven:

   Not to muddy the waters... but Gradle might be a good alternative.


There
is a lot more in it than Ant that just works without needing to be
explicit, especially when you follow Maven conventions for layout of
src
directories.

One big upside of Gradle is that all build files are Groovy scripts
and
you can do pretty much anything in them. One downside is the learning
curve... there is an extensive DSL with pretty good documentation,
but
some
things that would seem simple are non-obvious (to put it generously).
On
the other hand, there is fairly wide use so I still have yet to run
anything where I couldn't find a solution quickly with a google
search.

-David


   On 19 Apr 2015, at 22:51, Hans Bakker 
mailingl...@antwebsystems.com
javascript:; wrote:

  We should seriously consider the comments from Adam and move to

maven.

Regards,
Hans
antwebsystems.com


On 18/04/15 00:41, Adam Heath wrote:

  On

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

Assumptions are the Mother of all Fuckups, is often said.

Nevertheless, bringing all viewpoints and insights together (without the
assumptions and/or coloured projections) will lead to a better informed
community, enabling it to take the right decision.

Best regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Mon, Apr 20, 2015 at 8:31 PM, Ron Wheeler rwhee...@artifact-software.com
 wrote:

 Sorry Pierre.
 I hope it did not not ruin your evening.
 I guess old tools are like old homes.
 Hard to say goodbye even if the new house fits your needs better.
 (Assuming that the consensus is that Ant needs replacing)

 Ron

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

 Thanks for sharing the viewpoints. I could (just barely) suppress a
 physical reaction when I read 'Getting rid of ant is a good thing
 regardless'.

 Luckily we implement changes based on consensus, not the preference of the
 few.

 Best regards,

 Pierre Smits

 *ORRTIZ.COM http://www.orrtiz.com*
 Services  Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail  Trade
 http://www.orrtiz.com

 On Mon, Apr 20, 2015 at 8:00 PM, Ron Wheeler 
 rwhee...@artifact-software.com

 wrote:
 Maven imposes a philosophy on builds that you either follow or fight (and
 lose).

 The good side is that once you have your structure and supporting
 processes in place anyone who knows a little bit of Maven can run a build
 without looking at the pom and can add a dependency without destroying
 the
 build.
 You can build plug-ins to encapsulate best practices or to accomplish
 tasks that are not part of the software build.
 It is still possible to misuse Maven but it takes a lot of work and there
 is an active community to help avoid doing silly things.
 It is also actively supported with regular new versions so bug fixes and
 enhancement do get released quickly.

 I have used Maven for years and like it a lot.

 Gradle is new and getting a lot of attention so it might be a better
 choice but I have never used it.
 Flexibility is nice until some bad practices get put into a build process
 to solve a problem quickly rather than well.

 I love Ant and use it for other things but as a build tool it is too
 flexible and does not impose any structure or Best Practices.

   It also is an additional step on the learning curve which acts as a
 barrier to attracting developers; specially younger members who have been
 using more modern tools.

 Getting rid of Ant is a good thing regardless of where you go.

 Ron


 On 20/04/2015 1:25 PM, Jacopo Cappellato wrote:

  Some of the build files are really ugly at the moment and difficult to
 read: see the macros.xml, src-extra-set etc...
 The ability to write real code snippets may greatly simplify them.

 Jacopo

 On Apr 20, 2015, at 7:00 PM, David E. Jones d...@me.com wrote:

   That gets back to the question of why change in the first place...
 build

 files may be smaller and easier to maintain, but there may not be a
 good
 reason!

 -David


   On 20 Apr 2015, at 09:37, Pierre Smits pierre.sm...@gmail.com
 wrote:

 David,

 Thanks for sharing your insights. You talk about 'pretty much anything
 can be done with'. What, in your experience, can't be done -at the
 moment- in relation to OFBiz?

 Best regards,

 Pierre

 Op maandag 20 april 2015 heeft David E. Jones d...@me.com het
 volgende
 geschreven:

   Not to muddy the waters... but Gradle might be a good alternative.

 There
 is a lot more in it than Ant that just works without needing to be
 explicit, especially when you follow Maven conventions for layout of
 src
 directories.

 One big upside of Gradle is that all build files are Groovy scripts
 and
 you can do pretty much anything in them. One downside is the learning
 curve... there is an extensive DSL with pretty good documentation,
 but
 some
 things that would seem simple are non-obvious (to put it generously).
 On
 the other hand, there is fairly wide use so I still have yet to run
 anything where I couldn't find a solution quickly with a google
 search.

 -David


   On 19 Apr 2015, at 22:51, Hans Bakker 
 mailingl...@antwebsystems.com
 javascript:; wrote:

  We should seriously consider the comments from Adam and move to
 maven.

 Regards,
 Hans
 antwebsystems.com


 On 18/04/15 00:41, Adam Heath wrote:

  On 04/17/2015 10:20 AM, Jacques Le Roux wrote:

  Thanks for your detailed heads-up Martin, notably your last point!

 I mostly agree, and indeed I also think Maven might not be so bad
 when

  you start anew (or are forced to use it ;) ) but for OFBiz,
 really

 NO!

  Jacques

 Le 17/04/2015 16:27, Martin Becker a écrit :

  +1 for lack of benefit (and for fear ;-))

  The commit I did last night took me 45 minutes.  Full stop.  I

 started

  at 12:03am.  And I did it while drinking a second beer. Maven was
 that

 simple.  I had resisted for years.  Years!  But

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml


Sorry Pierre.
I hope it did not not ruin your evening.
I guess old tools are like old homes.
Hard to say goodbye even if the new house fits your needs better.
(Assuming that the consensus is that Ant needs replacing)

Ron

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

Thanks for sharing the viewpoints. I could (just barely) suppress a
physical reaction when I read 'Getting rid of ant is a good thing
regardless'.

Luckily we implement changes based on consensus, not the preference of the
few.

Best regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Mon, Apr 20, 2015 at 8:00 PM, Ron Wheeler rwhee...@artifact-software.com

wrote:
Maven imposes a philosophy on builds that you either follow or fight (and
lose).

The good side is that once you have your structure and supporting
processes in place anyone who knows a little bit of Maven can run a build
without looking at the pom and can add a dependency without destroying the
build.
You can build plug-ins to encapsulate best practices or to accomplish
tasks that are not part of the software build.
It is still possible to misuse Maven but it takes a lot of work and there
is an active community to help avoid doing silly things.
It is also actively supported with regular new versions so bug fixes and
enhancement do get released quickly.

I have used Maven for years and like it a lot.

Gradle is new and getting a lot of attention so it might be a better
choice but I have never used it.
Flexibility is nice until some bad practices get put into a build process
to solve a problem quickly rather than well.

I love Ant and use it for other things but as a build tool it is too
flexible and does not impose any structure or Best Practices.

  It also is an additional step on the learning curve which acts as a
barrier to attracting developers; specially younger members who have been
using more modern tools.

Getting rid of Ant is a good thing regardless of where you go.

Ron


On 20/04/2015 1:25 PM, Jacopo Cappellato wrote:


Some of the build files are really ugly at the moment and difficult to
read: see the macros.xml, src-extra-set etc...
The ability to write real code snippets may greatly simplify them.

Jacopo

On Apr 20, 2015, at 7:00 PM, David E. Jones d...@me.com wrote:

  That gets back to the question of why change in the first place... build

files may be smaller and easier to maintain, but there may not be a good
reason!

-David


  On 20 Apr 2015, at 09:37, Pierre Smits pierre.sm...@gmail.com wrote:

David,

Thanks for sharing your insights. You talk about 'pretty much anything
can be done with'. What, in your experience, can't be done -at the
moment- in relation to OFBiz?

Best regards,

Pierre

Op maandag 20 april 2015 heeft David E. Jones d...@me.com het
volgende
geschreven:

  Not to muddy the waters... but Gradle might be a good alternative.

There
is a lot more in it than Ant that just works without needing to be
explicit, especially when you follow Maven conventions for layout of
src
directories.

One big upside of Gradle is that all build files are Groovy scripts and
you can do pretty much anything in them. One downside is the learning
curve... there is an extensive DSL with pretty good documentation, but
some
things that would seem simple are non-obvious (to put it generously).
On
the other hand, there is fairly wide use so I still have yet to run
anything where I couldn't find a solution quickly with a google search.

-David


  On 19 Apr 2015, at 22:51, Hans Bakker mailingl...@antwebsystems.com
javascript:; wrote:


We should seriously consider the comments from Adam and move to maven.

Regards,
Hans
antwebsystems.com


On 18/04/15 00:41, Adam Heath wrote:


On 04/17/2015 10:20 AM, Jacques Le Roux wrote:


Thanks for your detailed heads-up Martin, notably your last point!

I mostly agree, and indeed I also think Maven might not be so bad
when


you start anew (or are forced to use it ;) ) but for OFBiz, really

NO!


Jacques

Le 17/04/2015 16:27, Martin Becker a écrit :


+1 for lack of benefit (and for fear ;-))


The commit I did last night took me 45 minutes.  Full stop.  I

started


at 12:03am.  And I did it while drinking a second beer. Maven was that

simple.  I had resisted for years.  Years!  But when I actually sat
down to
do it, I realized that I did *not* have to change what I was doing.
Maven
could be configured to work with the existing design.


The benefits are:

* not having to write our own build system; ant is not a build
system.

* full external dependency management.  This can be done very


incrementally.  I just got framework/base to compile, by reusing the

previously downloaded jars in framework/base/lib.  Then, when all
dependencies are *properly* listed, we can switch to the download
mechanism, and suddenly, the checkout becomes smaller.


* full internal dependency support.  As part of framework/base

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

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 d...@me.com wrote:


 That gets back to the question of why change in the first place... build
 files may be smaller and easier to maintain, but there may not be a good
 reason!

 -David

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml


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 d...@me.com wrote:


That gets back to the question of why change in the first place... build
files may be smaller and easier to maintain, but there may not be a good
reason!

-David




--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml


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 pierre.sm...@gmail.com 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 d...@me.com wrote:
 
 
 That gets back to the question of why change in the first place... build
 files may be smaller and easier to maintain, but there may not be a good
 reason!
 
 -David

Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml


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 pierre.sm...@gmail.com 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 d...@me.com wrote:


That gets back to the question of why change in the first place... build
files may be smaller and easier to maintain, but there may not be a good
reason!

-David






--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml

2015-04-19 Thread Hans Bakker


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

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

2015-04-17 Thread Michael Brohl


+1!

We should have very strong reasons to make this move.

Michael
ecomify.de

Am 17.04.15 um 10:35 schrieb Jacques Le Roux:
After installing and setting last Maven version (3.3.1) this does not 
work well on Windows (I miss the maven-compiler-plugin I guess)


Anyway I think we should really discuss before going in this direction.
I, for instance, am strongly against moving to Maven when we have Ant 
already embedded and so friendly.
Also I'd not like to have to move Maven related changes to Attic in a 
year or two because it's unfinished...


tested: ant clean  mvn clean compile  ant start

Jacques





smime.p7s
Description: S/MIME Cryptographic Signature

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


Do you intend to convert to use Maven for building? I mean to replace Ant?
Else what does this add compared to Ant?

BTW are you aware of our policy of creating Jira in order to capture releases 
changes?
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities#OFBizCommittersRolesandResponsibilities-Followingchanges

Jacques

Le 17/04/2015 07:52, doo...@apache.org a écrit :

Author: doogie
Date: Fri Apr 17 05:52:32 2015
New Revision: 1674216

URL: http://svn.apache.org/r1674216
Log:
Well, this is the start of converting ofbiz to use maven for building
and packaging.  There's a workable parent-pom, and I have converted
framework/start to maven as well.  To use this, the following commands
are useful:

* mvn clean
* mvn compile
* mvn package

All 3 can be run in either ${ofbiz.home.dir}, or in framework/start.
The trick that made this simple, was that I was able to redefine maven's
default file layout away from src/main/java and target/*, to something
more ofbiz specific.  This way of doing things is just to get things
going; eventually, we should adopt a more standard maven like layout.

Another thing not dealt with in these first 2 files, is downloading of
dependencies.  The top-level and framework/start have no external
requirements, so it allowed me to get going quite quickly.

Added:
 ofbiz/trunk/framework/start/pom.xml
 ofbiz/trunk/pom.xml

Added: ofbiz/trunk/framework/start/pom.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/framework/start/pom.xml?rev=1674216view=auto
==
--- ofbiz/trunk/framework/start/pom.xml (added)
+++ ofbiz/trunk/framework/start/pom.xml Fri Apr 17 05:52:32 2015
@@ -0,0 +1,69 @@
+?xml version=1.0 encoding=UTF-8?
+!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+License); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied.  See the License for the
+specific language governing permissions and limitations
+under the License.
+--
+
+project
+  parent
+groupIdorg.apache.ofbiz/groupId
+artifactIdofbiz-parent/artifactId
+versionTRUNK/version
+relativePath../../pom.xml/relativePath
+  /parent
+  modelVersion4.0.0/modelVersion
+  artifactIdofbiz-start/artifactId
+
+  build
+finalNameofbiz/finalName
+plugins
+  plugin
+groupIdorg.apache.maven.plugins/groupId
+artifactIdmaven-jar-plugin/artifactId
+configuration
+  archive
+manifestEntries
+  Manifest-Version1.0/Manifest-Version
+  Implementation-TitleApache OFBiz Startup/Implementation-Title
+  Implementation-VendorThe Apache Open for Business 
Project/Implementation-Vendor
+  Main-Classorg.ofbiz.base.start.Start/Main-Class
+/manifestEntries
+  /archive
+/configuration
+  /plugin
+  plugin
+groupIdorg.apache.maven.plugins/groupId
+artifactIdmaven-antrun-plugin/artifactId
+executions
+  execution
+phasepackage/phase
+configuration
+  tasks
+copy todir=${project.parent.relativePath}/..
+  fileset dir=${project.build.directory} 
includes=ofbiz.jar/
+/copy
+  /tasks
+/configuration
+goals
+  goalrun/goal
+/goals
+  /execution
+/executions
+  /plugin
+/plugins
+  /build
+/project

Added: ofbiz/trunk/pom.xml
URL: http://svn.apache.org/viewvc/ofbiz/trunk/pom.xml?rev=1674216view=auto
==
--- ofbiz/trunk/pom.xml (added)
+++ ofbiz/trunk/pom.xml Fri Apr 17 05:52:32 2015
@@ -0,0 +1,76 @@
+?xml version=1.0 encoding=UTF-8?
+!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements.  See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership.  The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+License); you may not use this file except in compliance
+with the License.  You may obtain a copy of the License at
+
+http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either

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


After installing and setting last Maven version (3.3.1) this does not work well 
on Windows (I miss the maven-compiler-plugin I guess)

Anyway I think we should really discuss before going in this direction.
I, for instance, am strongly against moving to Maven when we have Ant already 
embedded and so friendly.
Also I'd not like to have to move Maven related changes to Attic in a year or 
two because it's unfinished...

tested: ant clean  mvn clean compile  ant start

Jacques
PS:
[WARNING]
[WARNING] Some problems were encountered while building the effective model for 
org.apache.ofbiz:ofbiz-start:jar:TRUNK
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ org.apache.ofbiz:ofbiz-parent:TRUNK, 
C:\projectsASF\ofbiz\pom.xml, line 58, column 15
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-jar-plugin is missing. @ org.apache.ofbiz:ofbiz-start:[unknown-version], 
C:\projectsASF\ofbiz\framework\start\pom.xml, line 34, colu

mn 15
[WARNING]
[WARNING] Some problems were encountered while building the effective model for 
org.apache.ofbiz:ofbiz-parent:pom:TRUNK
[WARNING] 'build.plugins.plugin.version' for 
org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 58, column 15
[WARNING] The expression ${artifactId} is deprecated. Please use 
${project.artifactId} instead.
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten 
the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support 
building such malformed projects.
[WARNING]
[INFO] 
[INFO] Reactor Build Order:
[INFO]
[INFO] ofbiz-parent
[INFO] ofbiz-start
[INFO]
[INFO] 
[INFO] Building ofbiz-parent TRUNK
[INFO] 
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ ofbiz-parent ---
[INFO]
[INFO] 
[INFO] Building ofbiz-start TRUNK
[INFO] 
[INFO]
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ ofbiz-start ---
[INFO]
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ 
ofbiz-start ---
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, 
i.e. build is platform dependent!
[INFO] Copying 8 resources
[INFO] Copying 2 resources
[INFO]
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ ofbiz-start ---
[INFO] Changes detected - recompiling the module!
[WARNING] File encoding has not been set, using platform encoding Cp1252, i.e. 
build is platform dependent!
[INFO] Compiling 8 source files to 
C:\projectsASF\ofbiz\framework\start\build\classes
[INFO] 
[INFO] Reactor Summary:
[INFO]
[INFO] ofbiz-parent ... SUCCESS [  0.160 s]
[INFO] ofbiz-start  SUCCESS [  1.012 s]
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time: 1.303 s
[INFO] Finished at: 2015-04-17T10:26:24+02:00
[INFO] Final Memory: 13M/308M
[INFO] 
C:\Program Files\Java\jdk1.7.0_45\bin\java -jar c:\projectsASF\ofbiz\\framework\base\lib\ant-1.9.0-ant-launcher.jar -lib 
c:\projectsASF\ofbiz\\framework\base\lib\ant start -Dportoffset 1

Buildfile: c:\projectsASF\ofbiz\build.xml

start:
 [java] Error: Unable to access jarfile c:\projectsASF\ofbiz\ofbiz.jar
 [java] Java Result: 1

BUILD SUCCESSFUL
Total time: 1 second

Le 17/04/2015 10:08, Jacques Le Roux a écrit :

Do you intend to convert to use Maven for building? I mean to replace Ant?
Else what does this add compared to Ant?

BTW are you aware of our policy of creating Jira in order to capture releases 
changes?
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities#OFBizCommittersRolesandResponsibilities-Followingchanges 



Jacques

Le 17/04/2015 07:52, doo...@apache.org a écrit :

Author: doogie
Date: Fri Apr 17 05:52:32 2015
New Revision: 1674216

URL: http://svn.apache.org/r1674216
Log:
Well, this is the start of converting ofbiz to use maven for building
and packaging.  There's a workable parent-pom, and I have converted
framework/start to maven as well.  To use this, the following commands
are useful:

* mvn clean
* mvn compile
* mvn package

All 3 can be run in either ${ofbiz.home.dir}, or in framework/start.
The trick that made this simple, was that I was able to redefine maven's
default file layout away from src/main/java and

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

2015-04-17 Thread Jacopo Cappellato

On Apr 17, 2015, at 3:35 AM, Jacques Le Roux jacques.le.r...@les7arts.com 
wrote:

 Anyway I think we should really discuss before going in this direction.

+1

Jacopo

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

2015-04-17 Thread Taher Alkhateeb

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 

- Original Message -

From: Jacques Le Roux jacques.le.r...@les7arts.com 
To: dev@ofbiz.apache.org, doo...@apache.org 
Sent: Friday, 17 April, 2015 11:35:04 AM 
Subject: Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml 
pom.xml 

After installing and setting last Maven version (3.3.1) this does not work well 
on Windows (I miss the maven-compiler-plugin I guess) 

Anyway I think we should really discuss before going in this direction. 
I, for instance, am strongly against moving to Maven when we have Ant already 
embedded and so friendly. 
Also I'd not like to have to move Maven related changes to Attic in a year or 
two because it's unfinished... 

tested: ant clean  mvn clean compile  ant start 

Jacques 
PS: 
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for 
org.apache.ofbiz:ofbiz-start:jar:TRUNK 
[WARNING] 'build.plugins.plugin.version' for 
org.apache.maven.plugins:maven-compiler-plugin is missing. @ 
org.apache.ofbiz:ofbiz-parent:TRUNK, 
C:\projectsASF\ofbiz\pom.xml, line 58, column 15 
[WARNING] 'build.plugins.plugin.version' for 
org.apache.maven.plugins:maven-jar-plugin is missing. @ 
org.apache.ofbiz:ofbiz-start:[unknown-version], 
C:\projectsASF\ofbiz\framework\start\pom.xml, line 34, colu 
mn 15 
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for 
org.apache.ofbiz:ofbiz-parent:pom:TRUNK 
[WARNING] 'build.plugins.plugin.version' for 
org.apache.maven.plugins:maven-compiler-plugin is missing. @ line 58, column 15 
[WARNING] The expression ${artifactId} is deprecated. Please use 
${project.artifactId} instead. 
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten 
the stability of your build. 
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support 
building such malformed projects. 
[WARNING] 
[INFO]  
[INFO] Reactor Build Order: 
[INFO] 
[INFO] ofbiz-parent 
[INFO] ofbiz-start 
[INFO] 
[INFO]  
[INFO] Building ofbiz-parent TRUNK 
[INFO]  
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ ofbiz-parent --- 
[INFO] 
[INFO]  
[INFO] Building ofbiz-start TRUNK 
[INFO]  
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ ofbiz-start --- 
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ 
ofbiz-start --- 
[WARNING] Using platform encoding (Cp1252 actually) to copy filtered resources, 
i.e. build is platform dependent! 
[INFO] Copying 8 resources 
[INFO] Copying 2 resources 
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ ofbiz-start 
--- 
[INFO] Changes detected - recompiling the module! 
[WARNING] File encoding has not been set, using platform encoding Cp1252, i.e. 
build is platform dependent! 
[INFO] Compiling 8 source files to 
C:\projectsASF\ofbiz\framework\start\build\classes 
[INFO]  
[INFO] Reactor Summary: 
[INFO] 
[INFO] ofbiz-parent ... SUCCESS [ 0.160 s] 
[INFO] ofbiz-start  SUCCESS [ 1.012 s] 
[INFO]  
[INFO] BUILD SUCCESS 
[INFO]  
[INFO] Total time: 1.303 s 
[INFO] Finished at: 2015-04-17T10:26:24+02:00 
[INFO] Final Memory: 13M/308M 
[INFO]  
C:\Program Files\Java\jdk1.7.0_45\bin\java -jar 
c:\projectsASF\ofbiz\\framework\base\lib\ant-1.9.0-ant-launcher.jar -lib 
c:\projectsASF\ofbiz\\framework\base\lib\ant start -Dportoffset 1 
Buildfile: c:\projectsASF\ofbiz\build.xml 

start: 
[java] Error: Unable to access jarfile c:\projectsASF\ofbiz\ofbiz.jar 
[java] Java Result: 1 

BUILD SUCCESSFUL 
Total time: 1 second 

Le 17/04/2015 10:08, Jacques Le Roux a écrit : 
 Do you intend to convert to use Maven for building? I mean to replace Ant? 
 Else what does this add compared to Ant? 
 
 BTW are you aware of our policy of creating Jira in order to capture releases 
 changes? 
 https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities#OFBizCommittersRolesandResponsibilities-Followingchanges
  
 
 
 Jacques 
 
 Le 17/04/2015 07:52, doo...@apache.org a écrit : 
 Author: doogie

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

2015-04-17 Thread Nicolas Malin


Same remarks :)

Maven would be interesting for some site project, but directly add on 
the ofbiz projet root ...


Adam if you want use maven with OFBiz, maybe we can add a 
tools/contrib.xml use by ant who can prepare OFBiz for a specific system 
but not maintain by us.


Like this :
$ ant mvn
- download pom.xml from sourcefore, github or another community forge

And with the same logical than specialpurpose, the crontrib.xml would be 
not link by default on the ofbiz ant configuration


Nicolas

Le 17/04/2015 13:44, Adrian Crum a écrit :

+1 for a discussion.

One of the things I despise about working with Commons Convert is the 
labyrinth of Maven files and dependencies. It's a complicated black 
box that I can't understand, and when something doesn't work, I don't 
know how to fix it.


I hope OFBiz doesn't end up the same way.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/17/2015 11:49 AM, Jacopo Cappellato wrote:
On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb 
slidingfilame...@gmail.com wrote:



Hi All,

Thank you for your work but I thought we are more inclined to move 
to gradle based build systems given its many advantages as a full 
programming language build system based on groovy.


Taher Alkhateeb


I agree: we could explore the switch to Gradle and also review the 
way our source files (Java, Groovy and Minilang/xml) are organized 
(we could actually follow the layout that is considered the default 
for Maven and Gradle and possibly other tools).


Jacopo

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

2015-04-17 Thread Pierre Smits

On Apr 17, 2015, at 3:35 AM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:

 Anyway I think we should really discuss before going in this direction.

+1

So please revert this commit, before it is another dead weight.

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

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


Le 17/04/2015 12:49, Jacopo Cappellato a écrit :

On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb slidingfilame...@gmail.com wrote:


Hi All,

Thank you for your work but I thought we are more inclined to move to gradle 
based build systems given its many advantages as a full programming language 
build system based on groovy.

Taher Alkhateeb

I agree: we could explore the switch to Gradle and also review the way our 
source files (Java, Groovy and Minilang/xml) are organized (we could actually 
follow the layout that is considered the default for Maven and Gradle and 
possibly other tools).

Jacopo



I don't know if Gradle is stable now, but I'd surely be for instead of Maven. If ever we really desire to move from Ant, I don't clearly see the 
necessity at this stage...


Jacques

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



Le 17/04/2015 13:44, Adrian Crum a écrit :

+1 for a discussion.

One of the things I despise about working with Commons Convert is the labyrinth of Maven files and dependencies. It's a complicated black box that I 
can't understand, and when something doesn't work, I don't know how to fix it.


I hope OFBiz doesn't end up the same way.


Thanks to well express my opinion Adrian, same fear here!

Jacques



Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/17/2015 11:49 AM, Jacopo Cappellato wrote:

On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb slidingfilame...@gmail.com wrote:


Hi All,

Thank you for your work but I thought we are more inclined to move to gradle based build systems given its many advantages as a full programming 
language build system based on groovy.


Taher Alkhateeb


I agree: we could explore the switch to Gradle and also review the way our source files (Java, Groovy and Minilang/xml) are organized (we could 
actually follow the layout that is considered the default for Maven and Gradle and possibly other tools).


Jacopo

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

2015-04-17 Thread Adrian Crum


+1 for a discussion.

One of the things I despise about working with Commons Convert is the 
labyrinth of Maven files and dependencies. It's a complicated black box 
that I can't understand, and when something doesn't work, I don't know 
how to fix it.


I hope OFBiz doesn't end up the same way.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 4/17/2015 11:49 AM, Jacopo Cappellato wrote:

On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb slidingfilame...@gmail.com wrote:


Hi All,

Thank you for your work but I thought we are more inclined to move to gradle 
based build systems given its many advantages as a full programming language 
build system based on groovy.

Taher Alkhateeb


I agree: we could explore the switch to Gradle and also review the way our 
source files (Java, Groovy and Minilang/xml) are organized (we could actually 
follow the layout that is considered the default for Maven and Gradle and 
possibly other tools).

Jacopo

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

2015-04-17 Thread Jacopo Cappellato

On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb slidingfilame...@gmail.com wrote:

 Hi All, 
 
 Thank you for your work but I thought we are more inclined to move to gradle 
 based build systems given its many advantages as a full programming language 
 build system based on groovy. 
 
 Taher Alkhateeb

I agree: we could explore the switch to Gradle and also review the way our 
source files (Java, Groovy and Minilang/xml) are organized (we could actually 
follow the layout that is considered the default for Maven and Gradle and 
possibly other tools).

Jacopo

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

2015-04-17 Thread Martin Becker

+1 for lack of benefit (and for fear ;-))


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…

= 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 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.

= 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...

= 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.


Martin Becker
ecomify GmbH



 Am 17.04.2015 um 13:56 schrieb Jacques Le Roux jacques.le.r...@les7arts.com:
 
 Le 17/04/2015 12:49, Jacopo Cappellato a écrit :
 On Apr 17, 2015, at 4:39 AM, Taher Alkhateeb slidingfilame...@gmail.com 
 wrote:
 
 Hi All,
 
 Thank you for your work but I thought we are more inclined to move to 
 gradle based build systems given its many advantages as a full programming 
 language build system based on groovy.
 
 Taher Alkhateeb
 I agree: we could explore the switch to Gradle and also review the way our 
 source files (Java, Groovy and Minilang/xml) are organized (we could 
 actually follow the layout that is considered the default for Maven and 
 Gradle and possibly other tools).
 
 Jacopo
 
 
 I don't know if Gradle is stable now, but I'd surely be for instead of Maven. 
 If ever we really desire to move from Ant, I don't clearly see the necessity 
 at this stage...
 
 Jacques

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


Le 17/04/2015 16:27, Martin Becker a écrit :

= I think the stability of Gradle is not a question as it is used by projects 
like Spring, Hibernate, Grails, Groovy and others…


I mean the stability/differences between versions. I know some crossed (minor?) 
issues...

Jacques

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