You should give Buildr a try. I've had some issues with it (particularly installation), but they seem to be working hard to resolve them. It's somewhat similar to Gradle in that it is a drop-in replacement for Maven2, but quite a bit more concise (at least based on the examples I've seen).
Brian Fox
· 1 year ago
To add multiple source directories, simply use the build-helper-maven-plugin, or better...the plugin implementing the compiler should define and add them itself. The intent was to provide one default to the default java compiler, but the plugin api makes it possible (and desired) for new compiler plugins to be able to define their own standard and tell Maven about it.
Hans Dockter
· 1 year ago
Buildr is a nice tool. But though the basic approach is similar to Gradle (Buildr was there first) there are also significant differences. Some of them are:
* Gradle is based on Ivy, the most advanced dependency management solution in the Java world. * Gradle calculates the graph of tasks which actually gets executed beforehand. This is a very powerful feature. This graph for example is provided to the tasks during execution. * Gradle offers sophisticated ways to configure multi-project builds. * Gradle has a java-core which will eventually enable it to support multiple build script languages (e.g. JRuby). Though for a Java team (building Java projects is what Buildr and Gradle is mostly about) we think that Groovy is usually the language which offers the highest transparency to the developers.
Regarding the conciseness. I would be very interested in concrete examples to improve Gradle here.
Buildr is a nice tool. But though the basic approach is similar to Gradle (Buildr was there first) there are also significant differences. Some of them are:
* Gradle is based on Ivy, the most advanced dependency management solution in the Java world. * Gradle calculates the graph of tasks which actually gets executed beforehand. This is a very powerful feature. This graph for example is provided to the tasks during execution. * Gradle offers sophisticated ways to configure multi-project builds. * Gradle has a java-core which will eventually enable it to support multiple build script languages (e.g. JRuby). Though for a Java team (building Java projects is what Buildr and Gradle is mostly about) we think that Groovy is usually the language which offers the highest transparency to the developers.
Regarding the conciseness. I would be very interested in concrete examples to improve Gradle here.
>First, let me say, I like Maven - a lot. >I’ve liked the idea, if not the execution
100% agree. I am using maven for hobby projects, but I don't know if I would recommend it on the workplace. Too complicate, lack of documentation, plenty of bugs.
I don't think that maven is really chained to a specific language: some plugins can add support to other languages. Well, I'm not aware of those plugins, but itself maven doesn't preclude to other languages. The reason why ant and maven use XML is to be language agnostic. I find interesting gant and gmaven...
I wondering why nobody is writing jant and jmaven, now... :)
Hans Dockter
· 1 year ago
Buildr is a nice tool. But though the basic approach is similar to Gradle (Buildr was there first) there are also significant differences. Some of them are:
* Gradle is based on Ivy, the most advanced dependency management solution in the Java world. * Gradle calculates the graph of tasks which actually gets executed beforehand. This is a very powerful feature. This graph for example is provided to the tasks during execution. * Gradle offers sophisticated ways to configure multi-project builds. * Gradle has a java-core which will eventually enable it to support multiple build script languages (e.g. JRuby). Though for a Java team (building Java projects is what Buildr and Gradle is mostly about) we think that Groovy is usually the language which offers the highest transparency to the developers.
Regarding the conciseness. I would be very interested in concrete examples to improve Gradle here.
Buildr is a nice tool. But though the basic approach is similar to Gradle (Buildr was there first) there are also significant differences. Some of them are:
* Gradle is based on Ivy, the most advanced dependency management solution in the Java world. * Gradle calculates the graph of tasks which actually gets executed beforehand. This is a very powerful feature. This graph for example is provided to the tasks during execution. * Gradle offers sophisticated ways to configure multi-project builds. * Gradle has a java-core which will eventually enable it to support multiple build script languages (e.g. JRuby). Though for a Java team (building Java projects is what Buildr and Gradle is mostly about) we think that Groovy is usually the language which offers the highest transparency to the developers.
Regarding the conciseness. I would be very interested in concrete examples to improve Gradle here.
Buildr is a nice tool. But though the basic approach is similar to Gradle (Buildr was there first) there are also significant differences. Some of them are:
* Gradle is based on Ivy, the most advanced dependency management solution in the Java world. * Gradle calculates the graph of tasks which actually gets executed beforehand. This is a very powerful feature. This graph for example is provided to the tasks during execution. * Gradle offers sophisticated ways to configure multi-project builds. * Gradle has a java-core which will eventually enable it to support multiple build script languages (e.g. JRuby). Though for a Java team (building Java projects is what Buildr and Gradle is mostly about) we think that Groovy is usually the language which offers the highest transparency to the developers.
Regarding the conciseness. I would be very interested in concrete examples to improve Gradle here.
Hans Dockter (Gradle Project lead)
Warner Onstine
· 1 year ago
@Brian
Alright, that plugin does look like it solves the multiple source problem, but honestly this should be part of Maven core IMO. I think I'm ready to move on to something else though as I've seen [other](http://tapestryjava.blogspot.com/2007/11/maven-wont-get-fooled-again.html) [issues](http://tapestryjava.blogspot.com/2008/06/maven-for-dependencies-not-building.html) with Maven builds so [Buildr](http://incubator.apache.org/buildr) and [Gradle](http://gradle.org) look like good alternatives.
As I said I've been a big proponent of Maven for a long time so this isn't an easy switch for me, while I'm not looking for a drop-in replacement I am looking for something that makes my life easier as a developer, not more complex (as Ant does inherently).
Dion Gillard
· 1 year ago
This looks a lot better than Maven 2.
Less verbose, real scripting, simple, smaller concept set.
Maybe I've found something I can use to migrate away from Maven 1
Ravi
· 1 year ago
Our entire company is on the verge of being completely Maven. Team development using Maven in our IDEs makes development so much easier than anything else. The infrastructure provided behind every tag in the POM provides so much to our environment. The fact that things aren't willy-nilly added to the manifest and is performed by Maven plugins makes things structured really well. Our stack is CVS+Archiva+Hudson+(Mevenide2/EclipseMaven) and works great once you understand it.
All Comments
The intent was to provide one default to the default java compiler, but the plugin api makes it possible (and desired) for new compiler plugins to be able to define their own standard and tell Maven about it.
* Gradle is based on Ivy, the most advanced dependency management solution in the Java world.
* Gradle calculates the graph of tasks which actually gets executed beforehand. This is a very powerful feature. This graph for example is provided to the tasks during execution.
* Gradle offers sophisticated ways to configure multi-project builds.
* Gradle has a java-core which will eventually enable it to support multiple build script languages (e.g. JRuby). Though for a Java team (building Java projects is what Buildr and Gradle is mostly about) we think that Groovy is usually the language which offers the highest transparency to the developers.
Regarding the conciseness. I would be very interested in concrete examples to improve Gradle here.
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
</br>
* Gradle is based on Ivy, the most advanced dependency management solution in the Java world.
* Gradle calculates the graph of tasks which actually gets executed beforehand. This is a very powerful feature. This graph for example is provided to the tasks during execution.
* Gradle offers sophisticated ways to configure multi-project builds.
* Gradle has a java-core which will eventually enable it to support multiple build script languages (e.g. JRuby). Though for a Java team (building Java projects is what Buildr and Gradle is mostly about) we think that Groovy is usually the language which offers the highest transparency to the developers.
Regarding the conciseness. I would be very interested in concrete examples to improve Gradle here.
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
</br>
>I’ve liked the idea, if not the execution
100% agree. I am using maven for hobby projects, but I don't know if I would recommend it on the workplace. Too complicate, lack of documentation, plenty of bugs.
I don't think that maven is really chained to a specific language: some plugins can add support to other languages. Well, I'm not aware of those plugins, but itself maven doesn't preclude to other languages.
The reason why ant and maven use XML is to be language agnostic.
I find interesting gant and gmaven...
I wondering why nobody is writing jant and jmaven, now... :)
* Gradle is based on Ivy, the most advanced dependency management solution in the Java world.
* Gradle calculates the graph of tasks which actually gets executed beforehand. This is a very powerful feature. This graph for example is provided to the tasks during execution.
* Gradle offers sophisticated ways to configure multi-project builds.
* Gradle has a java-core which will eventually enable it to support multiple build script languages (e.g. JRuby). Though for a Java team (building Java projects is what Buildr and Gradle is mostly about) we think that Groovy is usually the language which offers the highest transparency to the developers.
Regarding the conciseness. I would be very interested in concrete examples to improve Gradle here.
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
</br>
* Gradle is based on Ivy, the most advanced dependency management solution in the Java world.
* Gradle calculates the graph of tasks which actually gets executed beforehand. This is a very powerful feature. This graph for example is provided to the tasks during execution.
* Gradle offers sophisticated ways to configure multi-project builds.
* Gradle has a java-core which will eventually enable it to support multiple build script languages (e.g. JRuby). Though for a Java team (building Java projects is what Buildr and Gradle is mostly about) we think that Groovy is usually the language which offers the highest transparency to the developers.
Regarding the conciseness. I would be very interested in concrete examples to improve Gradle here.
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
</br>
* Gradle is based on Ivy, the most advanced dependency management solution in the Java world.
* Gradle calculates the graph of tasks which actually gets executed beforehand. This is a very powerful feature. This graph for example is provided to the tasks during execution.
* Gradle offers sophisticated ways to configure multi-project builds.
* Gradle has a java-core which will eventually enable it to support multiple build script languages (e.g. JRuby). Though for a Java team (building Java projects is what Buildr and Gradle is mostly about) we think that Groovy is usually the language which offers the highest transparency to the developers.
Regarding the conciseness. I would be very interested in concrete examples to improve Gradle here.
Hans Dockter (Gradle Project lead)
Alright, that plugin does look like it solves the multiple source problem, but honestly this should be part of Maven core IMO. I think I'm ready to move on to something else though as I've seen [other](http://tapestryjava.blogspot.com/2007/11/maven-wont-get-fooled-again.html) [issues](http://tapestryjava.blogspot.com/2008/06/maven-for-dependencies-not-building.html) with Maven builds so [Buildr](http://incubator.apache.org/buildr) and [Gradle](http://gradle.org) look like good alternatives.
As I said I've been a big proponent of Maven for a long time so this isn't an easy switch for me, while I'm not looking for a drop-in replacement I am looking for something that makes my life easier as a developer, not more complex (as Ant does inherently).
Less verbose, real scripting, simple, smaller concept set.
Maybe I've found something I can use to migrate away from Maven 1