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 : [email protected] 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 <[email protected]>: > > On 04/21/2015 12:29 AM, Jacopo Cappellato wrote: >> >> On Apr 21, 2015, at 12:33 AM, Adam Heath <[email protected]> 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.
