Comments on: Is Maven going away? http://www.warneronstine.com/2008/07/06/is-maven-going-away/ Where technology and art disappear Wed, 17 Nov 2010 10:52:45 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Daniel Spiewak http://www.warneronstine.com/2008/07/06/is-maven-going-away/comment-page-1/#comment-179 Daniel Spiewak Thu, 01 Jan 1970 00:00:00 +0000 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). 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).

]]> By: Brian Fox http://www.warneronstine.com/2008/07/06/is-maven-going-away/comment-page-1/#comment-180 Brian Fox Thu, 01 Jan 1970 00:00:00 +0000 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. 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.

]]> By: Hans Dockter http://www.warneronstine.com/2008/07/06/is-maven-going-away/comment-page-1/#comment-181 Hans Dockter Thu, 01 Jan 1970 00:00:00 +0000 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. --<br> Hans Dockter<br> Gradle Project lead<br> http://www.gradle.org<br> 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
http://www.gradle.org

]]> By: Hans Dockter http://www.warneronstine.com/2008/07/06/is-maven-going-away/comment-page-1/#comment-182 Hans Dockter Thu, 01 Jan 1970 00:00:00 +0000 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. --<br> Hans Dockter<br> Gradle Project lead<br> http://www.gradle.org<br> 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
http://www.gradle.org

]]> By: Luigi R. Viggiano http://www.warneronstine.com/2008/07/06/is-maven-going-away/comment-page-1/#comment-183 Luigi R. Viggiano Thu, 01 Jan 1970 00:00:00 +0000 >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... :) >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… :)

]]> By: Hans Dockter http://www.warneronstine.com/2008/07/06/is-maven-going-away/comment-page-1/#comment-184 Hans Dockter Thu, 01 Jan 1970 00:00:00 +0000 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. --<br> Hans Dockter<br> Gradle Project lead<br> http://www.gradle.org<br> 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
http://www.gradle.org

]]> By: Hans Dockter http://www.warneronstine.com/2008/07/06/is-maven-going-away/comment-page-1/#comment-185 Hans Dockter Thu, 01 Jan 1970 00:00:00 +0000 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. --<br> Hans Dockter<br> Gradle Project lead<br> http://www.gradle.org<br> 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
http://www.gradle.org

]]> By: Hans Dockter http://www.warneronstine.com/2008/07/06/is-maven-going-away/comment-page-1/#comment-186 Hans Dockter Thu, 01 Jan 1970 00:00:00 +0000 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) 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)

]]> By: Warner Onstine http://www.warneronstine.com/2008/07/06/is-maven-going-away/comment-page-1/#comment-187 Warner Onstine Thu, 01 Jan 1970 00:00:00 +0000 @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). @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).

]]> By: Dion Gillard http://www.warneronstine.com/2008/07/06/is-maven-going-away/comment-page-1/#comment-188 Dion Gillard Thu, 01 Jan 1970 00:00:00 +0000 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 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

]]>