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