This question is unlikely to help any future visitors; it is only relevant to a small geographic area, a specific moment in time, or an extraordinarily narrow situation that is not generally applicable to the worldwide audience of the internet. For help making this question more broadly applicable, visit the help center.
Closed 11 years ago.
I'm in the process of porting several J2EE projects from Ant to Maven2. All of these projects contain 1 EJB and 1 web module, and use the recommended "skinny" EAR packaging method. This means that the JARs that the EJB and/or web modules depend on are all just put in the root of the EAR. Both EJB and web modules have Class-Path entries in their respective manifests to reference the specific JARs, plus the web module Class-Path will also reference the EJB jar.
I was horrified (is that too strong? :)) to find that Maven doesn't support this very well. I read the official page on handling skinny WARs, but that meant I had to duplicate the WAR dependencies in the EAR pom and, even worse, also the transitive dependencies. It seems pointless to adopt Maven if you have to manually handle dependencies anywhere!
I then starting Googling and found a variety of workarounds - obviously, I'm not the first person to (a) want to do a skinny EAR and (b) don't like the Maven suggested approach (which is itself a workaround).
I tried some of these approaches, but none of them worked for me. I also found some issues that looked like Maven bugs, e.g. the WAR plugin 'packagingExcludes' directive excludes only the direct dependencies, not any transitive ones! Not very confidence inspiring. I found a JIRA issue for this specific one, but it's still open.
I then found that my command-line Maven 2.2.1 does things differently to my m2eclipse embedded Maven (Embedder v. 3.0). Our developers would definitely want to drive Maven from Eclipse, so relying on the latest command-line version was not an option.
So, my question is: right now, and for the forseeable future, is it worth migrating to Maven if we do all our development in Eclipse, and work mostly on skinny EAR projects? Is there anything in Maven's future that would make it handle EARs in a more robust and integrated way?
So, my question is: right now, and for
the forseeable future, is it worth
migrating to Maven if we do all our
development in Eclipse, and work
mostly on skinny EAR projects? Is
there anything in Maven's future that
would make it handle EARs in a more
robust and integrated way?
Short story: No, not while M2Eclipse remains broken.
Long story:
Currently, I would recommend against it, at least in Eclipse. At the time of writing the M2Eclipse plugin has and always has had a very nasty bug where it generates its own version of the application.xml descriptor file rather than use the one Maven would otherwise create.
Unfortunately, this custom-created application.xml is downright wrong: it ignores finalNames, has an apparently hardcoded "lib/" prefix and assigns EJB JARs the extension ".ejb" for some reason. What's worse, you cannot remove it to be replaced with Maven's version as it keeps getting regenerated by M2Eclipse.
Maven will only generate application.xml if it's not already in place. Because the WTP/M2Eclipse-generated application.xml keeps getting regenerated, the Maven application.xml doesn't get a chance.
There is a workaround for this problem, however: you can tell Maven to ignore the application.xml during packaging so that it thinks application.xml is not there, in which case it will still generate its own version. That way, the wrongly-generated application.xml file wouldn't matter. For future reference:
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<version>5</version>
<earSourceExcludes>**/application.xml</earSourceExcludes>
<generateApplicationXml>true</generateApplicationXml>
</configuration>
</plugin>
One major problem though is that the Ant script used for deployment to GlassFish in Eclipse generates its own separate EAR for deployment, and uses the M2Eclipse-generated application.xml for doing so. That means the EARs it generates will always be wrong as long as the M2Eclipse plugin remains broken. There are bug reports for this on the codehaus JIRA, can't access them right now though.
YMMV for other application servers, but be prepared for heavy fiddling with application.xml.
Unfortunately, this custom-created application.xml is downright wrong: it ignores finalNames, has an apparently hardcoded "lib/" prefix and assigns EJB JARs the extension ".ejb" for some reason. What's worse, you cannot remove it to be replaced with Maven's version as it keeps getting regenerated by M2Eclipse.
Are you really sure it's m2eclipse doing this? I'm using JBoss Tools 3.1 which includes m2eclipse integration and get exactly the problem you're stating. However, I don't see the rationale for m2eclipse to care at all about the source application.xml.
My suspicion is that JBoss Tools injects information into the application.xml. Please prove I'm wrong, I'd stop using m2eclipse forever fi it changed anything that's not under /target.
//GG
I was horrified (is that too strong? :)) to find that Maven doesn't support this very well (...)
Indeed, Maven doesn't support skinny WARs (see also the Solving the Skinny Wars problem wiki page) very well because this was just not planned from the start and Maven assumes fat WARs. So the way to build skinny WARs and skinny EARs is indeed more a workarounds built on top of existing plugins. And, yes, this is error prone.
(...) I then found that my command-line Maven 2.2.1 does things differently to my m2eclipse embedded Maven (Embedder v. 3.0).
Note that you can configure m2eclipse to use an external Maven instead of the embedded Maven. This is actually what I do, I want exactly the same version that the CI engine uses.
So, my question is: right now, and for the forseeable future, is it worth migrating to Maven if we do all our development in Eclipse, and work mostly on skinny EAR projects?
My advice is simple: if Maven doesn't support the way you want to build software (legitimate or not, that's not the question), don't use it.
Related
I want to deliver a single .jar file to my clients, but my project is currently built with Maven, and I have several modules that generate a single .jar each.
I know nesting different .jar files is not a great idea, so I am not sure how can I achieve this.
Any ideas?
If you really want to go this direction, there are several ways to do that:
with the Maven Assembly Plugin and maybe the jar-with-dependencies predefined assembly descriptor (that will unpack dependencies)
with the Maven Shade Plugin (similar to the above one but gives more flexibility)
with the Maven One-Jar Plugin (that uses One-JAR and its custom classloader to allow nesting of JARs)
Depending on your exact requirements and constraints, you might prefer one or the other.
First of all, ask yourself if you have a really good reason for packaging your application and all of its dependencies in to a single jar. I haven't found a very many good reason for this at all (with most reasons being related to organizational policy foolishness or just plain ignorance). The way to go is to keep libraries in their own jars and supplying a .zip/.tar.gz containing all of your libraries and your application with either
An executable .jar with the
classpath setup appropriately in
your MANFIEST.MF file
a .bat/.sh
script that invokes java and builds
an appropriate classpath based on
your deps
Conversely, use JNLP (better known as Java Web Start).
If you really want to have maven bundle all of your dependencies and your application under a single jar, what you want to use is the "jar-with-dependencies" predefined assembly. The maven assembly plugin usage page also shows how you might this up as well.
You can try Maven Shade plugin too.
http://maven.apache.org/plugins/maven-shade-plugin/
General instructions on how to use the Shade Plugin can be found on the usage page. Some more specific use cases are described in the examples given below. Last but not least, users occasionally contribute additional examples, tips or errata to the plugin's wiki page.
In case you still have questions regarding the plugin's usage, please feel free to contact the user mailing list. The posts to the mailing list are archived and could already contain the answer to your question as part of an older thread. Hence, it is also worth browsing/searching the mail archive.
If you feel like the plugin is missing a feature or has a defect, you can fill a feature request or bug report in our issue tracker. When creating a new issue, please provide a comprehensive description of your concern. Especially for fixing bugs it is crucial that the developers can reproduce your problem. For this reason, entire debug logs, POMs or most preferably little demo projects attached to the issue are very much appreciated. Of course, patches are welcome, too. Contributors can check out the project from our source repository and will find supplementary information in the guide to helping with Maven.
Actually, nesting .jar files is not possible. A jar can't have other jars in it.
.war and .ear files can contain jars, and that's a good solution if you're delivering a J2EE application.
If your app is just J2SE, however, I recommend looking at the Maven Assembly plugin. As the name implies, it allows you to create a single binary distribution of your build.
I am newbie with maven.
Other than its use for managing dependencies, I am finding little use for it.
It was getting so hard to write up a pom.xml, that I generated a ant build.xml from one of maven's tasks (which is a nice handy task...)
I had to tweak the build.xml that was generated by maven. And now all my compiling, testing, etc., is being done with this build.xml..
Is such a combination common? I am thinking of making it permanent in my project.
Other than its use for managing dependencies, I am finding little use for it.
That's because you don't get it :) Dependencies management is only a small part of Maven, Maven has really much more. Quoting Maven: The Definitive Guide:
Maven is a project management tool which encompasses a project object model, a set of standards, a project lifecycle, a dependency management system, and logic for executing plugin goals at defined phases in a lifecycle. When you use Maven, you describe your project using a well-defined project object model, Maven can then apply cross-cutting logic from a set of shared (or custom) plugins.
Maven uses convention over configuration with lots of useful defaults (directory locations, a defined life-cycle, a set of common plugins that know how to build and assemble software), Maven provides a common interface to build project (unlike Ant, you know how to do things like running tests, packaging, etc with every project, no need to open the build script to find out how it's done), Maven implements reuse through maven plugins (build logic is embedded into plugins for DRY purpose, you don't have to repeat yourself over and over, you don't have to copy/paste parts of your build scripts), Maven has a Project Object Model that allows you to describe your project through meta-data (this enables dependency management, remote repositories, reuse of build logic, tool integration, artifacts search...).
So, because Maven provides a lingua franca or shared language for project management, comparing Maven vs. Ant (+ Ivy if you want), Maven vs. Buildr, Maven vs. Gradle is like comparing apples to oranges, the comparison is just irrelevant.
Is such a combination common? I am thinking of making it permanent in my project.
Well, no, that's really not the maven way of doing things. This might seem tempting (because you have the feeling that you regain control because you understand what is happening with Ant) but you are actually repeating yourself again and losing all advantages of Maven. Sure, there is some learning curve with Maven and I'm not saying you'll learn it in one night but once you'll get it, you'll feel the power. I'd thus recommend to keep trying, to ask questions on the mailing list or here on SO, to read the Maven Book, etc. But don't give up.
So you re-did what Maven gives you for free by writing Ant Tasks within a pom.xml?
Besides doing the Dep-Mgmt, Maven will compile the sources, run all test cases and package the whole thing as jar file for you with no extra configuration. That's the default.
It is not common to enrich a pom.xml with Ant clutter. However, some special tasks or legacy Ant tasks are sometimes embedded into the pom.xml lifecycle, but these are exceptions and not the common case.
What exactly is hard when writing a pom.xml?
I wonder, because most of the time you will do this once for a project and not struggle with it all the time. Also, most IDEs have support for creating the minimum pom.xml, which is just a few lines anyway.
I've tried Maven, personally for home projects and professionally at my workplace, and... I hate it. I must admit I don't have a lot of experience, but it doesn't feel good. I get the idea Maven is a less-than-perfect implementation of a good idea. I'll probably get flamed by Maven enthusiasts, but this is my personal opinion.
I think Maven comes into its own in organizations that deal with a network of interrelated projects, like Apache does; where dependencies tend to change a lot and need to be quite explicitly specified to avoid "jar version hell". For isolated projects dependent on a few seldom changing jars, I find it overly intrusive.
To answer your question: I've read forum and blog posts on the Internet of other people doing exactly what you propagate. They use Maven for dependency management and then do their building with Ant. This undermines some of the benefits Maven is supposed to bring, such as the fact that a "normal" build is simpler to specify in Maven than Ant. However, I think you can be encouraged by the fact that you're not the only person with this idea, and it is indeed working for some other people.
I'd like to give you links to quotes, but I came across this stuff in the past few weeks and didn't collect references.
I'm a Maven fan, but it's not without its problems. Some of the issues I remember (and still fight):
Just like Ant, it has a magical syntax that can be hard to understand. If you're familiar with Any you may forget that, but lots of Ant tasks are terribly documented. The same is true for Maven. One of the reasons I eventually switched to Maven, though, is that for many of the mojos (similar to Ant tasks), you don't have to understand how to configure them. You just have to put the various pieces in the right place (which can be as hard as configuring a task...).
The automatic dependency management is amazing!... when it works. When you have to use non-Maven dependencies (like Hadoop) it becomes a problem. You either have to reference them as system scope dependencies, find somebody else who has packaged them, or package them yourself. And you eventually need to setup your own Maven proxy, like Nexus. And that's a whole extra hassle.
Maven is a lot of trouble on non-network or isolated LANs. The automagic is great, as long as you're networked.
It was getting so hard to write up a pom.xml, that I generated a ant build.xml from one of maven's tasks (which is a nice handy task...) I had to tweak the build.xml that was generated by maven. And now all my compiling, testing, etc., is being done with this build.xml..
Well. you can use maven archetype plugin to generate pom :)
Is such a combination common? I am thinking of making it permanent in my project.
JBoss Seam uses Maven internally to handle dependencies and do some targets in Maven. It's a big project that grew up with Ant, and now is difficult to build entire project solely in Maven, but that is going to happen in near future.
If you just need dependency management with Ant, you could give Ivy a try. Maven is a tool for managing the whole lifecycle of the build process.
Personally, I find Maven a nice tool once you get over the learning curve since you can standardize the build process for a lot of projects and there are a lot of great add-ons (particularly for code analysis tools). However, it's very possible that you do enough custom stuff with your build that the Ivy + Ant combo makes more sense.
Honestly, I would love to see a dependency management tool that implemented that part of Maven, specifically as a command line tool. For everything BUT dependency management, I find Maven to be absolutely awful if you're doing anything but exactly what the most general case is. Every time I try to do something that isn't "normal" (system/acceptance tests, etc), I run into a brick wall due to
either horrid documentation,
being told it's "not the maven way" (when it's a task that needs to happen, and "the way" shouldn't be a factor), or
being told to wait for the next version of maven, because maybe it'll be supported then.
I'd love to have a command line tool that can implement the "I need this as a dependency, go get it" functionality of Maven, possibly even using the pom.xml files of various packages. Then I could just use that in a Makefile and happy :)
Simple answer to the question posed: YES <-- click the link for details and reasoning.
I requested Maven training at work, and the bosses want to hire someone who knows Maven to come work with us as a consultant so that we'll learn Maven from a real-world perspective instead of a training perspective.
I've been tasked with coming up with questions of various difficulty to ask potential hires in order to ascertain their Maven ability. The problem is that I don't fully understand Maven yet (hence the training request).
What questions would you ask someone to determine their Maven ability, and what level of knowledge would someone have to have of Maven to answer them?
In my opinion, a "Maven consultant" should:
Have a good understanding of how Maven differs from other build tools like Ant (Maven provides a "lingua franca" for project management).
Have a good understanding of Maven principles: Conventions over Configuration, the default layout, the naming conventions, the philosophy of the tool (one primary output per project).
Have a good understanding of how Maven works: from where the conventions are coming from (the super POM), the lifecycles (main, clean, site), the phases, how plugins are bound to phases, the influence of packaging, etc
Know what profiles are and how they can be used to deal with different environments, how to trigger them.
Know how to use plugins, how to configure them, how to plug them in a maven build.
Know how repositories work, the difference between local and remote repositories, what SNAPSHOT dependencies are.
Know how dependencies are resolved, what transitive dependencies are, how to control them, what dependencies scope are, how to use dependencyManagement.
Know how to implement code health checks, the essential plugins (Checkstyle, PMD and Findbugs plugins), how to implement various kind of tests (unit, integration, functional), how to measure coverage, when to fail the build, when to report.
Know how to setup maven in a corporate environment (using a shared repository, setting up CI, a company POM).
Know how to handle advanced packaging scenarii (with the assembly plugin)
Know how to handle deployment, the various protocols, the deploy plugin, the release plugin, the SNAPSHOT resolution.
Know how to setup a Maven build for a Java EE project, how to setup a multi-modules build, what modules are required, how to test in the development environment, how to handle the production environment.
Someone with these skills should put you on the right path (and has very likely a decent experience of Maven).
A lot of good questions here, especially the ones proposed by Pascal Thivent. However, I would ask another question:
Q: What is the difference between the aggregation and inheritence in Maven?
A: You can have a short explanation here.
I would suggest that you think about what you wanna do with Maven, or why you wanna introduce it into your projects. Maybe ask your boss for his reasons/goals in introducing Maven.
After you have named your main goals why to introduce Maven. Ask potential consultants how they would use Maven to achieve those goals.
Examples 1
Goal: Improve overall code quality in project.
Question: How may we use Maven to improve our overall code quality in projects.
Possible answer: Maven has several plug-ins to force/meassure code quality in projects, we could integrate those into our buildscripts in almost no time. (e.g. checkstlye, pmd, cobertura, xradar...)
Examples 2
Goal: Creating automated deployment scripts for several destination environments.
Question: How may we use Maven to automatically deploy artifacts to several destination environments.
Possible answer: We could use Maven plug-ins for deployment (e.g. Cargo) and use maven's profiles to handle several configurations.
a.s.o.
I would ask:
Describe what is the practice of SCM?
Describe your ideal Maven infrastructure (server, repositories, CI, plug-ins, conventions, etc.)?
Both are very open questions, but they should give your a feeling of his skills and what you can learn from him and what he could bring to your company.
EDIT
Maven is just one piece in the overall software configuration management (SCM) strategy. A good consultant should know the details of maven in and out but also know how it fit in the big picture. Just like you expect a Java EE consultant to be expert in a Java but to know what it means to deliver enterprise application to a customer.
In the company I worked, we had a guy responsible of the SCM who had been a Maven contributor. And his view was way broader than "just" maven. He was in charge to have a productive build, configuration and release process. Two examples:
We were hard-coding the release number in java code to be able to display it into the "about" dialog of our desktop applications. Most of the time we forgot to change it after the release resulting in a mismatch between the actual release number and the about dialog -- big problem for integrators on-site. This was a bad practice. He then set up something so that the release number in Maven would be correct in the manifest file and educated us to read the manifest file from Java to ensure both match.
When you would release a module, he wrote a script to not only build the application, but also close the corresponding version in the ticket system (JIRA) and push the release notes in the wiki.
All that to say that knowing how to "mavenize" a project is important, but more important, the guy must understand how you currently work, what is in place and help you set up something reasonable to improve your productivity.
Here are the questions I would ask:
How would you enforce the use of JDK6
for a group of projects?
How would you enforce the use of a
particular version of a plugins?
What are some of the reasons why you
would use an assembly to build a jar
rather than the jar plugin?
Describe the process of releasing a
Java EE project made up of an EJB, a WAR
file and two utility jars.
How many repositories should an
internal company repository server have and why?
How would you structure a POM project made up of N child projects so they it can easily be used in Eclipse?
All of these questions have at least two answers. I would be looking for someone who can provide at least two answers and point out the pros and cons of each approach. Ideally, this person should be tweaking the set up to be less disruptive to the way your environment already works.
If you have the luxury, I suggest having the consultant come onsite for a day, give him/her an existing java project that you're working on and have him/her "mavenize" it for you. The next day, sit with him/her and have them explain how to compile, and build a jar (or war).
Or maybe have them come to the interview with a maven project to demonstrate. The should be able to compile, and build a jar/war at the very least, imo. If they can run unit tests, deploy to tomcat, integrate with any of the various frameworks like gwt, hibernate, spring, etc, then even better.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I am really tired of struggling with Maven 2 all the time. Build tools should not be in the way. Recently I have been looking at Buildr and Gradle. Maven 3 seems to fix some of the struggles. So, what should I go for now? Buildr? Gradle? Or wait a year for Maven 3?
I wouldn't expect too much from Maven 3. The people behind the Maven pedigree of build tools have always held the assumption that project builds are homogeneous, that is: all build problems fundamentally boil down to the same problem. This view of the world can be held fairly consistently in the face of opposing views but comes at a cost. The absence of scripting logic in Maven ("when you want to script you know you're doing something wrong"), the cumbersome plugin API ("no ordinary Maven user should want to write a plugin") and the central repository ("we all have the same dependencies") are all testaments of this overarching assumption.
In the real world build problems are heterogeneous because people build software for a wide variety of reasons. They all 'develop' like we all 'drill holes' once in a while for solving unique problems. Regardless of your level of abstraction you'll always find similarities when comparing arbitrary build problems. It is the reveration of these similarities and the condemnation of differences that is the downfall for Maven's design and the reason why it draws so much flak. Basically, Maven is authoritarian and utopian in its outlook.
PS: Maven has good features, like convention-over-configuration and the idea of using repositories (the Maven implementation of this idea is troublesome).
No build system is a magic bullet. I find Maven solves more problems than it causes for me, but I'm quite comfortable writing plugins to get round its shortcomings, I also deal with hundreds of projects, so Maven's inheritance and dependency processing is quite helpful for me.
Browse SO a bit and you'll see Buildr and Gradle both have issues too (same for Ant and Ivy), generally you're trading one set of problems for another and its a case of finding the least painful.
Is there anything in particular that is bothering you about Maven or is it a general itch? If it is a particular problem it is worth looking at the Maven 3 issues on Jira, if the problem isn't addressed, you can raise it, or else there may be little point in you waiting
We use Maven here, but I find that once you get outside of a simple project, the pom.xml starts to get more and more complex. You start spending a lot of time working out how in the heck to configure your pom to do what you want, and how to work around the various issues.
The thing that really got me was the ear we're building. We have multiple wars in that ear file, and Maven normally sticks the libraries in the wars. However, to reduce the size of the wars, and to keep the jars all the same, we wanted to put the jars shared between the wars in the ear's lib directory.
Unfortunately, Maven doesn't handle this very well. We needed to manually configure this for each of the wars' poms, and then add all of these dependencies into the ear's pom.
In another project we have HTML based help files. The people who write the help write them in Microsoft Word then use a program to translate them into HTML. A single character change can reverberate throughout hundreds of files.
To get around this issue, our help system is stored in our source repository as a single zipped file. When our documentation team creates a new set of help files, they zip it up and replace what is in the repository.
So, part of my build is unzipping this file and placing it in the war. Easy to do in Ant, can't do it in Maven unless you use the Antrun plugin which allows you to write Ant code to handle issues that Maven cannot handle without a full blown plugin.
I can see what Maven is doing, but theory got ahead of reality. What I found is that Ivy and Ant can do most of the dependency checking that Maven does without all the issues of writing and maintaining the poms.
If you're not already using Maven, try Ant with Ivy first. Then when, Maven 3 comes out, try that. I remember the transition from Maven 1 to Maven 2. They were entirely incompatible with each other and anything you learned using Maven 1 was obsolete. It would be silly to learn and redo your projects in Maven 2 to suddenly find yourself redoing everything for Maven 3.
maven 3.x is already embedded in IDEs (at least on netbeans, check this link for more infomration). You can play today with maven 3.x simply building a Maven project with netbeans.
Another nice news is that maven got more 'enterprise' support with integrating EJB/WS in IDE projects (again, at least on netbeans).
So I would stick to maven 2.x for production builds and play with maven 3.x for development.
Maven 2 and 3 have both been working perfectly for me on a variety of projects. I am currently using Maven 3 alpha 7 which works very well, especially in conjunction with the Eclipse Maven plugin.
Maven integrates seamlessly with Ant - in both directions. In my current project, we invoke Maven from Ant multiple times in order to perform complex integration test. Likewise, we use Ant via Maven's AntRun plugin, and we also wrote our own Maven plugins. This, by the way, is a matter of minutes and boils down to writing an annotated Pojo.
Maven gets a lot of flak because many developers don't like rules or conventions. Quite simply, nobody forces you to use Maven. If you want ultimate freedom - by any means - re-write your own build process for every project you join. However, if you like to create software rather than re-inventing the wheel with a custom-made build process on every project, go for Maven.
Keep your code well maintained and broken into well defined modules and porting between build systems becomes a minor problem.
As for now, maven-2 is a good choice for the middle 2/3rd of projects. For the really simple, ant is still ok. For the really complex, a hybrid of maven-2 and other tools (like antrun) becomes inevitable.
Not sure why you are having problems with maven-2.
It differs from ant and buildr in that it is a tool for describing your build process, not scripting it. Complex builds, the ones with multiple dynamic parts and nested and/or transient dependencies are hard to build because they are hard to describe.
Give Lattice https://github.com/hackingspirit/Lattice a try. I am the author. Here is the scoop:
In Lattice build files are written not in XML, but in the Python language. The ben- efits are much better readability and powerful imperative build scripting supported by Python.
For multi-module projects. Lattice uses topological sorting to decide the correct order to build each module. It’s also planned that Lattice will analyze the module dependency to determine how the module compilation can be parallelized.
Lattice’s source code is extremely lean, currently it consists of about 500 lines of Python source code.
I think people complaining about Maven should spend a little extra time investigating available plugins. In response to comments complaining that Maven is rigid and makes it hard to use custom build logic / provide fine-grained control over the build process - I would recommend looking into Ant plug-in for Maven (there are actually several, but here is one: http://maven.apache.org/plugins/maven-antrun-plugin). I have had great success customizing Maven builds with it over the years. Basically, it allows you to run any Ant command as part of the Maven build, and you can do pretty much anything with Ant ;)
Ant with Ivy does the same dependency management Maven does (in fact, it uses Maven's whole dependency management infrastructure including the same URL repositories), but without all the POM configuration mess.
Ant with Ivy might be a way of handling the dependency issues for people who really don't want to use Maven. It solves 90% of the stuff that Maven was suppose to solve.
I was wondering about the best way to manage projects dependencies from ant. What are the pros and cons of the Maven Ant task and of Ivy?
Since what you're wanting to do is add dependency management to an existing Ant project, that's precisely what Ivy's designed to do. Dependency management is a big part of Maven, but far from all of it. Maven is more of a project-oriented tool that does several other things in addition to dependencies. It would be worth considering if you were planning to migrate to Maven and use additional Maven features as well, but it's a bit much if all you'd use it for is to spin off Ant.
Your type of dependencies and your expectations for how they behave will also make a difference. Pulling third-party dependencies is almost trivial in Maven, while Ivy excels in rebuilding your own dependent components. In either case, the tools won't provide decent build, versioning, and repository policies, those are still up to you and needed to get the configuration right.
Ant + Ivy == A campground, where people use the facilities as needed.
Maven == A resort, where you rely on someone else to provide services.
Maven is easier for a team lacking build/integration experience, but when the team needs to diverge from Maven standards they will find themselves reaching for groovy, gradle, and the lack of solid documentation will become frustrating.
Ant + Ivy will take longer to startup a project, but if the team has build/integration experience they can tailor the build system around they way they develop and release code.
In engineering... technology companies I always push for the campsite solution versus the resort.
It is amazing though that both Ant and Maven choose XML as their langauge to express build recipes with. The Java community is stuck on that XML...
I think this blog post covers exactly what the OP is looking for:
Why you should use the Maven Ant Tasks instead of Maven or Ivy
Ivy+Ant is far, far more flexible. Ivy does dependency management, period, and it does that extremely well, better than Maven. And with Ant you can pretty much put together any build system that you want.
Maven tries to control everything - the "lifecycle" (compile, test, package, etc.), where files should live, and so on. Have fun customizing plugins and the like if you don't like the "Maven way".
Maven is the answer to a question no one asked. Writing an Ant script is not hard, and Ivy gives you better dependency management than Maven. I am confused by some of the previous comments stating they couldn't get Ivy working. Ivy is quite a bit simpler than Maven to get up and running.
The Spring Framework uses Ivy in its build process. I think that can be seen as quite a vote of confidence for Ivy.
If your long term goal is to migrate to using Maven to manage the entire build process (which one might intend to do for new greenfield projects), then I heartily recommend using Maven pom.xml files to manage dependencies on behalf of Ant build.xml files. The end result is that both your greenfield projects and your legacy projects are then all using the same mechanism to manage dependencies. And it turns out Maven really does a better job of managing dependencies for Ant build.xml files than does Ivy.
Prior to adopting Maven as our flagship build tool, I had a developer attempt to use Ivy in combination to existing Ant build.xml files. This was most frustrating experience that very soon lead us to reject Ivy. We went ahead with an adoption of Maven. Our greenfield projects began to be built with the stock Maven approach, etc.
However, I went back to the Ant legacy projects and started using the Maven Ant task to define classpath definitions (and occasionally other Ant property definitions pulled in from the pom.xml). This turned out to be a most superlative experience. The existing Ant build.xml files need only be modified slightly to use Maven ant integration to define any classpath that were in use in the build.xml file. All dependencies required by the project became defined in an accompanying pom.xml file that gets processed by Maven via the Ant task incorporated into the build.xml files.
Maven scopes can be used to fine tune classpath definitions such that one suitable for compiling, or running unit test, or for packaging, et al, can be established. Also, pretty much any element of something defined in the pom.xml file can be referenced as an Ant property within the build.xml file.
Really with the Ant task for Maven there is no viable reason for Ivy to even exist.
Comparing Maven with ivy/ant is to compare a smartphone to telegraphy.
If you want to leverage a real enduring effect in your build infrastructure, it's better to use Maven because it anticipates and abstracts all processes and tasks every software project or other software-like project is faced with. I took part in many projects and if your projects get more complex and more diverse and more heterogeneous, you will praise even more the simplicity of a Maven project configuration. Indeed, it will become complex but not complicated compared to ivy/ant-driven projects.
The main advantage of Maven is "convention over configuration" (http://en.wikipedia.org/wiki/Convention_over_configuration) a very important paradigm. In short, this means that you don't need to know/configure things that are obvious/trivial/commonplace. Although Maven and all its plugins ship with many default-settings, you always have the option to configure your projects for your special needs. With Maven, on the one hand you can setup a project very easy and quickly; on the other hand, you can customize a growing project up to your needs with minimum effort. If you have understood the key concepts behind Maven you will leverage every project and also projects that are not typical software development projects as well.
In the past, I wrote many ant scripts and with upcoming Maven I began to hate ant. One disadvantage is that you always copy scripts and repeat yourself, develop ant tasks that don't repeat tasks that don't repeat tasks that don't repeat... And the main disadvantage is that growing ant scripts tend to get unmaintainable, especially if a dozen ant geeks want to pimp up each others ant scripts.
Many ant-enthusiasts suffer from getting overall control over trivial things like copying of artifacts and printing buildmessages. But because Maven's key concept is to hide these trivial things the legend will forever keep alive that Maven restricts customization needs. But don't worry, that’s a legend! And so you finally understand my initial statement: don't bother with trivial things that are already solved.
Maybe ivy/ant is an option for simple projects but for complex growing projects you need simplicity and conventions. Otherwise you will be overwhelmed with more and more maintaining problems. Especially if you have many dependent projects, technologies and heterogeneous product parts in a global project you don't have time and money for developing and testing ant scripts or solving dependency problems.
Another advice should be mentioned: Ant offers the integration of Maven. This integration is often used to test and play with maven in projects that are grown up with ant. Avoid this stupid approach because it generates more problems. Instead stay with ant and its pain or migrate fully to maven.
If you are in doubt about the migration costs I suggest you to use the contrary way of integrating that different worlds by the Maven-Ant-Plugin. With this standard plugin you can run every ant-script without any effort. Sure it’s a legacy solution for a while, but it gives you as much time you need to understand mega-lines of monstrous distorted uncommented ant scripts of your predecessor.
And now you will praise the next advantage of maven: You need very less documentation of your configuration, because documentation is part of every maven-plugin you want to use.
So I confess I was a Maven-Antagonist.
I know that one advantage of Ivy is that it can use different kinds of repositories. Maven is typically very rigid in the format of the repository it will use. That's all I know.
I've just spent 2 days reading through the Ivy documentation and I have to say, USE MAVEN if you have any kind of choice. Ivy is complete and utter garbage as far as I can tell. I just wasted 2 days trying to incorporate it into my build and am cutting my losses now. Why?
Ivy is a half-assed attempt at dependency management
Ivy documentation is a total joke
Ivy examples and tutorial are useless
As soon as I introduced 'configurations' (read as maven profiles), Ivy started going bezerk downloading all sorts of junk I don't need then failing. The documentation for Ivy is an utter joke. Maven documentation in comparison reads like a dream. If you want an example of how impenetrable and badly written the Ivy documentation is, take a look at the reference page for configurations. These are an essential part of any build, but in Ivy they seem to be a badly designed after thought.