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


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

Reply via email to