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?
相关问题
- Could not read entry … from cache taskArtifacts.bi
- Configure gradle plugin based on future tasks
- How to fix the error Cannot change strategy of con
- Include pom.xml in Jar with gradle
- Gradle vs Compiler
相关文章
- Android BuildConfig Field generating String incorr
- Gradle Could not find method “() for arguments on
- Gradle Custom Plugin: gradleApi() vs Explicit Depe
- Android Studio 3.5 ERROR: Unable to resolve depend
- How to specify @category in test task in gradle?
- How to clean your build with Flutter RP2 in Androi
- Remove transitive classpath dependency in gradle
- Execution failed for task ':bintrayUpload'
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.
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.
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.