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.
Related
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.
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 am working on a fairly large project (with a number of modules, a bunch of external libraries etc.) and we are now considering switching from Ant to Maven. I understand the differences between the two, but I am not convinced that it is really worth spending time converting the project layout, setting up all the dependencies, teaching developers and configuration managers doing things "the new way" etc.
There are a lot of resources on the web describing how to migrate from Ant to Maven, but I haven't found that many that say why :-)
Before changing your build system, ask yourself (and the group) why you're changing? If you're changing just because Maven is the "new thing", don't. If you actually see a technical reason to migrate, do it.
In general, unless there's a major compelling reason to do so (new capabilities or much simpler management), I'd say stay with what you have for the current project, but consider Maven for future projects.
Have you read chapter 1 of "Maven, the definitive guide"? In particular, 1.7 Comparing Maven with Ant has an interesting discussion.
I agree with the other answers that advise caution. Maven has strong points, but nothing that can't be done by an Ant build process:
dependency management: Ant has the Ivy subproject, which can interact with Maven repositories.
convention over configuration: you can also do that with Ant, it's just a matter of establishing the rules and enforcing them.
build lifecycle: same as above, you can enforce a convention over the tasks exposed by each build.
build logic reuse (Maven plugins): you can also achieve that in Ant with macrodefs and task libraries.
The thing is, with Maven you get these features out-of-the-box, while with Ant you need a rock-solid build, a very strict set of rules and a way to enforce them (for instance, make sure that everyone follows the conventions when they create a new subproject, that they reuse the existing blocks instead of doing everything from scratch, etc.).
Personally, I would see how well the existing process addresses the issues above: how are dependencies managed, is there a central repository? Are the project structures uniform (when I checkout a project I don't know, how long does it take to figure out how to build it)? Is there some form of build logic reuse, or does each project reinvent the wheel? Which of these features are needed?
Then I would try to balance the cost of adding the missing features to the existing Ant script, against the cost of migrating to Maven (if you don't know Maven, that also includes the cost of learning it).
In any case, I suggest you build a small Maven prototype (5 to 10 projects) illustrating the common cases in your build. You can test a lot of Maven's features with dummy projects containing little java logic (use the archetype plugin to generate them).
Before Maven we were checking dependency libraries (typically third-party, open source variety) into source control - so that we could insure our components compiled and got packaged with the precise versions intended.
Now with Maven in place, we're relying on artifact repositories to hold those versions and we let our pom.xml dependency declarations be the official means of defining version dependencies. This has proven to be a simplifying approach that makes project organization in version control repositories (and their Hudson build projects) much easier to devise. Our local artifact repository is under backup policy along with our source control repositories. It's nice to use the Maven tools to go and search and specify a needed library version. We also use parent pom files to specify dependencies that other project poms inherit by default. So if you want all projects to use the same log4j version, then that is specified in one place in the parent pom file. (But any project can at anytime override and specify a specific version instead of just accepting the default from the parent pom.)
Here is the secret to a successful adoption of Maven:
Use Maven project build approach for
your new greenfield projects
Modify existing legacy projects that
use ant build.xml files to incorporate Maven task
for managing depenedencies (a hybrid
approach)
The benefit is that you can then get all of your projects under Maven dependency management, which is of course it's greatest benefit.
The nice thing about the Maven task for ant, where you specify all dependencies in a pom.xml file, is that it involves just modest modification of the existing ant build.xml file to incorporate Maven for this. From the ant file's perspective, Maven is just a means for defining classpath definitions, which are subsequently used by the various ant build task.
The Maven scope classifier of dependencies can be utilized when defining classpaths such that a suitable classpath can be set for compiling, running unit test, packaging, et al. Other definitions in the pom can also be accessed as ant property definitions.
A lot of existing ant build files are rather complex. It can be a formidable undertaking to convert such projects to a full Maven build process. This hybrid approach of having Maven manage all the dependencies and leave the bulk of the ant build.xml file as is, is most pragmatic.
First, like I'm sure a lot of people will mention, Ant and Maven are not exactly intended to solve the same goals. Since you said you understand what each provides, I won't get into the details of that, so suffice it to say that Ant lets you define the details of how to build individual components, while Maven manages the dependencies between components plus Maven lets you define a complete project build cycle from compile through test and deploy in a programmatic way.
I've used Maven on a couple projects in the past, and I just started using it on another one recently. There are plenty of articles on the net that compare Ant and Maven, so you can look at those, but from my experience, its always worthwhile to consider how you can improve a project. Dependency management and build lifecycle are two important aspects of any large project, and Maven helps in both those areas. If you already have a good build system in place using ant, and your dependencies are kept in a easy to access central location, and you don't plan on extending your build process to include any more advanced build management, then maybe you should stay with what you have.
On the other hand, if you want to use a continuous integration server like hudson or an artifact repository like nexus, then moving your project to maven can really help with build efficiency and automation. You probably would like maven in those situations because the full cycle from dependency to build to artifact can be achieved using those types of tools and you'll be able to better control your builds and releases. On my current project we have many modules and dependencies, like you mention. Migrating to maven so we could use hudson and nexus really helped because we could drop all those 3rd party jars into a nexus repository and stop having to check them into version control or email them around. Also, builds were out of hand because the CM people had a build plan as a document that they would sometimes follow, but making that part of your project (i.e., the pom.xml) defines how you are supposed to build and lets you enforce it. Maven is the glue that holds all of those things together.
In the end, its a matter of how long you expect the project to last, how good your process is now, whether you want to clean up your dependencies, whether you want to enforce your build plan, and whether you want to have the option to use continuous integration and artifact management. If you any of those things, Maven is a strong candidate.
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.
My company starts a new project next week. We have planned to develop the application with eclipse rcp. The build process should be fully automated, so we're prepared to set up a continuous integration environment (e.g. Continuum). For the build-automation-part I intended to use maven2, because I want use its dependency management.
I have used maven2 for a small old-style java project, but have never set up maven for using it with eclipse rcp.
What's the best way to do this? Basic concepts? Common traps? Are any tutorials or book's around there? The tutorials and informations I found, seemed outdated or incomplete.
PS: The main project will be divided into sub-project's (plug-in's). But I think this is typical for eclipse rcp projects.
You should take a look at Tycho:
the-future-of-maven-osgi-join-the-tycho-users-mailing-list
the-next-generation-of-build-tools-for-eclipse-plugins-and-rcp-applications
Like most Maven questions, this is solved by a link to a plug-in:
"pde-maven-plugin"
Other advice:
use the assembly plug-in to build
the update site
consider using hudson rather than
Continuum
I've been battling maven2/Eclipse RCP integration for some time. The key is not so much getting your setup right: You can get it to work - eventually - by reverse-engineering Eclipse's build process in maven.
In my experience, the hard part is keeping everything up to date. Every time Eclipse revs their libs, you'll find yourself re-writing a bunch of pom files for that newest RCP widget or SWT lib. Naturally, CI helps with this somewhat. The problem is that Eclipse and maven are very particular about the way they do the business of building, and their approaches are quite different. To make matters worse, PDE dev (and Eclipse dev, more generally) is powered by a lot of wizard code, which is sometimes quite opaque as to what's happening behind the scenes.
The question you really need to ask yourself is if it's worth the effort. In my particular case, I believe it has been. (CI is too good to live without.) But the trade-off is that you may find yourself being the "build guy", which can take valuable time away from actual development, which is probably what you enjoy most.
I've got recently the same problem : build eclipse RCP application through continuous integration.
I haven't applied them yet but I've found some interesting articles :
Here's the documentation for Tycho
Building Eclipse Plugins with Maven 2 on eclipse.org
Build Eclipse RCP products using Maven 2 - how hard can it be? from Immo Hüneke's blog
Here's an article about PDE build automation
Here's a shell script to automate JUnit test launch