First, let me say, I like Maven – a lot. I’ve liked the idea, if not the execution, since 1.0 (yes, I know there is some serious bad blood for the implementation of 1.0, and yes I still liked it). But I’ve recently run into some irritating problems with Maven that would again, I think, require a major reworking of what it does.
Here is the main issue Maven is designed to handle one language only for its compilation – primarily Java. This is rapidly starting to fall apart now that the JVM has some serious contenders besides Java, namely Groovy, JRuby, Jython, and Scala. There are some hackish things for getting Maven to deal with these, however it still only has one “true” source directory for compilation. A case in point is a mixed Java/Groovy project – trying to get IntelliJ to respect the fact that I want not one, but two main source directories is a pain in the ass as I have to either tell it not to sync everytime I launch or I have to refix the source directories each time I update the project.
This is what triggered this post – what happens when I want to do some Flex programming with some Java, ActionScript and MXML, all of these are true source files (and in Maven specfic directories). I’m sure some Mavenite is going to say that these should be separate projects, but in alot of cases they aren’t and it doesn’t make sense to actually separate them into sub-projects. And I’m equally as sure that some Ant-ite is going to come along and tell me to use Ant – I won’t. Ant is stuck in the past and I won’t use it unless I absolutely have to. I like the “imposed” structure that Maven offers. I can walk up to any project and know where to find stuff instead of blindly hunting around for hours trying to piece it together like some giant source-code jigsaw puzzle, blech.
So, I’m at cross-roads, what should I do? There is Ivy (for dependency management -which they got from Maven natch), but that requires Ant, blech. There’s also Gant, ok, this is better, but still Ant. GMaven, but I’m right back where I started.
Enter, Gradle, a new Groovy-based build system that offers alot of the benefits of Maven without locking you in and the flexibility of Ant. I’m not 100% sold on it yet, but I’m going to give it a shot for a relatively complex project that will have a fair amount of Java, Groovy and other fun resource files. It looks interesting in that all the build files are actually Groovy scripts that are a DSL (like Gant files). Here’s a short example with some dependencies (taken directly from their examples in the download).
import org.gradle.api.tasks.util.FileSet
usePlugin('groovy')
group = 'org.gradle'
version = '1.0'
sourceCompatibility = 1.5
targetCompatibility = 1.5
dependencies {
clientModule(['groovy'], ":groovy-all:1.6-beta-1") {
dependency(":commons-cli:1.0")
}
compile project(':groovycDetector')
testCompile ":junit:4.4"
}
compile {
exclude('**/Exclude.java')
groovyExclude('**/ExcludeGroovy.groovy')
groovyJavaExclude('**/ExcludeGroovyJava.java')
}
manifest.mainAttributes(myprop: 'myvalue')
metaInf << new FileSet(new File(srcRoot, 'metaInfFiles'))
test.options.systemProperties['org.gradle.integtest.buildDir'] = buildDir.absolutePath
I will try and keep everyone up to date as I continue to investigate this new build system. They also state that they are going to be supporting polyglot programming in the near future which I’m looking forward to.
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).
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.
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
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
>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…
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
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
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)
@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).
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
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.
JP9MXi comment4, buy cialis, http://www.suite101.com/profile.cfm/hyptor#6 buy cialis, 7508, order ambien, http://www.suite101.com/profile.cfm/vahrum#9 order ambien, %PP, fioricet online, http://www.suite101.com/profile.cfm/kamboja#11 fioricet online, eekt, buy tramadol, https://labs.mozilla.com/forum/index.php?action=profile;u=4208#1 buy tramadol, pwwpk, xanax, http://www.suite101.com/profile.cfm/naddya#5 xanax, yhushq,