When people start looking into an alternative to Ant, it's usually because of the lack of dependency management. Not having dependency management for libraries nowadays is as bad as not having a VCS for source code. Ant+Ivy, Maven and Gradle offer this feature in a very similar way. The problem is: none of then offer a complete solution to the dependency management problem. They solve half of the problem and that is where developers start to complain about the tool. Even worse, some developers start to look for the wrong means to manage dependencies with those tools.
Dependency management is a way of consuming libraries and its dependencies in a declarative manner. Nothing new here. However, it's also a way of producing dependencies. The question is: where do you put a library developed to be consumed by other projects and by other developers? A dependency management repository is required to solve the problem. My recommendation to anyone interested in using Ant+Ivy, Maven or Gradle is to take the time to analyze one of the main Repository Managers available: Archiva, Artifactory or Nexus.
Also there are other topics that make a build tool excel. -Integration (IDE, build server, editors, frameworks and etc) -Plugin ecosystem
I've been using the combo Maven + Nexus for a long time. Maven is a mature tool. It integrates very well with a wide range of tools. I've been solving all my needs using existing plugins. It's also the de facto build tool for a lot of open source projects. Specifically for WO development, I have less problems now than 5 years ago, but of course there are still problems.
For anyone trying an alternative to Ant, don't be fooled. In the end, every build tool requires time and configuration.
Cheers,
Henrique
I think that “Maven expert” is the key here. This is not a trivial thing to setup correctly and maintain. It is trivial to setup and use incorrectly and I have seen the pain resulting from that. To benefit from Maven you need to really deeply understand
Maven and its approach to dependancy management. And you need to ensure that the whole team plays by The Maven Rules, even if it makes more work short term and a bit of cheating does not seem that bad at the moment.
Chuck
On 2015-05-04, 8:29 AM, "Jean-François Veillette" wrote:
At my previous workplace, we did the switch to Maven. Luckily we had a real maven expert to drive the move.
We started with around 50+ projects, all ant based, using the ‘standard’ fluffy-bunny layout. He added pom.xml here and there, and everything just started working with maven. We had choice to build/run with maven and/or ant and it was (almost)
transparent. The only exception was that if you decided to use in maven, you had to change the class path to remove everything but the maven and java dependencies (2 lines left), a simple .classpath that was standard and could be copied from one project to
the other.
The maven build was then integrated with Jenkins (CI) and SonarQube (so that future ‘JF’ is happy with old ‘JF’, and all the team's work are standardized a bit) with ease.
From my experience, the team was happy with the Maven switch, none of us had to become an expert (because we had one already).
Maven help a lot on easing the dependency management of your apps (a building block only declare his direct dependency). Once you remove the noise of declaring dependencies, you will be left with a clear graph of dependent block. You will then
have to tackle the real problem of incompatible dependencies (A need B and Xv1, but B need Xv2). Maven will make the graph simple and clear, it will try to provide helper but can’t really help much after that.
jfv
On May 4, 2015, at 5:09 AM, David Avendasora < email@hidden> wrote:
On May 1, 2015, at 6:35 PM, Chuck Hill < email@hidden> wrote:
Maven
seems like a better thought out and implemented solution.
…
Have you ever had one of those moments where things just seem so off-kilter you’re sure you’re having a dream, but no matter how many times you cry out for mommy you are left sitting there slowly realizing that there’s been some fundamental shift
in the universe that you missed out on. (And your wife is slowly picking up her phone and dialing your therapist. Again.)
—————————————————————————————
WebObjects - so easy that even Dave Avendasora can do it!™
—————————————————————————————
David Avendasora
Senior Software Abuser
Nekesto, Inc.
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|