Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
Le 22/04/2015 00:03, Adam Heath a écrit : 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? It was just a lack of time, I was then just leaving for few days. I always had and still have a reluctance against statistics and the world it's creating around us (think big data). There is of course sound aspects but I fear the humanity will suffer of it in the long term. It relates to my experience in the context of IA where you have mostly 2 approaches: statistical vs logical (OK they are mixing/mixed now http://en.wikipedia.org/wiki/Artificial_intelligence ) So yes was more a knee-jerk response :) I have still not enough time to expand and be totally clear. I hope from my digression above I guess you get my point. Jacques Jacques
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
Maven is only one of the alternatives that could be investigated. It would be nice if the people who build OFBiz every day tried to use Adam's solution before it is removed. Is it as easy to test Ant+Ivy. Ron On 22/04/2015 5:13 AM, Pierre Smits 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 -- 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
+1 Ron On 22/04/2015 5:25 AM, Pierre Smits wrote: 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 -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
Adam, This all sounds good to me. I will have time to review your improvements after May 1. Adrian Crum Sandglass Software www.sandglass-software.com On 4/21/2015 9:37 PM, Adam Heath 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/22/2015 12:52 PM, David E. Jones wrote: On 21 Apr 2015, at 14:17, Adam Heath doo...@brainfood.com wrote: 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. This is an appeal to popularity, not utility. Did further. Read what is linked from google(or your search engine of choice). Just like code formatting can be a proxy to code quality, so can search result count. But you still have to investigate, and maven does seem to have higher community, support, etc.
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
On 04/22/2015 12:53 PM, David E. Jones 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? I haven't done any forcing. I haven't done any commit wars. I've done a POC, as David mentions.
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
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
On 21 Apr 2015, at 14:17, Adam Heath doo...@brainfood.com wrote: 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. This is an appeal to popularity, not utility. -David
Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml
From: David E. Jones d...@me.com Subject: Re: Long: Re: discussion: Move to Maven was:Re: svn commit: r1674216 - in /ofbiz/trunk: framework/start/pom.xml pom.xml This is an appeal to popularity, not utility. I don't think we've proven that those fail to converge over time.
Re: Long: Re: discussion: Move to Maven was:Re: 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
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
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: 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
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
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
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 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
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? 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
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
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.
