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
The Maven Standard Directory Layout says that scripts should be placed in src/main/scripts in a maven project. Besides the advantages of "convention over configuration" are there any other advantages of doing it this way? I have a project that builds an executable jar-with-dependencies using the assembly plugin. There are also some useful scripts that go along with it. Are there any tools that take advantage of this layout in building something else, for example, an archive that includes the jar and these scripts in a reasonable location?
[update]
In fact, I would go so far as to say that that putting scripts in src/main/scripts is disadvantageous, as far as use with the maven-assembly plugin is concerned.. It appears that EVERYTHING under /src/main (except src/main/java of course) is copied into the root directory of the jar-with-dependencies, as with src/main/resources, where this is useful. But there is no good reason to have scripts in the jar, although it does no particular harm. If, instead of placing them in src/main/scripts, one places them in src/scripts (analogously to the standard src/assembly, which also isn't included), then they are not copied into the jar and can be copied by a later run of the assembly plugin into a larger archive.
Update: It appears that we must distinguish between runtime scripts that are launched from within the java code and others which launch the jar or do other things. For the former, putting them in src/main/scripts may be appropriate. For the latter, inappropriate.
Update: I entered a bug against the maven documentation about this.
Update: The src/main/scripts directory was removed from the Standard Directory Layout documentation due to it being misleading. (Remnants however still remain in Introduction to POM as it's tied to the project.build.scriptSourceDirectory property.)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
What does another build tool targeted at Java really get me?
If you use Gradle over another tool, why?
I don't use Gradle in anger myself (just a toy project so far) [author means they have used Gradle on only a toy project so far, not that Gradle is a toy project - see comments], but I'd say that the reasons one would consider using it would be because of the frustrations of Ant and Maven.
In my experience Ant is often write-only (yes I know it is possible to write beautifully modular, elegant builds, but the fact is most people don't). For any non-trivial projects it becomes mind-bending, and takes great care to ensure that complex builds are truly portable. Its imperative nature can lead to replication of configuration between builds (though macros can help here).
Maven takes the opposite approach and expects you to completely integrate with the Maven lifecycle. Experienced Ant users find this particularly jarring as Maven removes many of the freedoms you have in Ant. For example there's a Sonatype blog that enumerates many of the Maven criticisms and their responses.
The Maven plugin mechanism allows for very powerful build configurations, and the inheritance model means you can define a small set of parent POMs encapsulating your build configurations for the whole enterprise and individual projects can inherit those configurations, leaving them lightweight. Maven configuration is very verbose (though Maven 3 promises to address this), and if you want to do anything that is "not the Maven way" you have to write a plugin or use the hacky Ant integration. Note I happen to like writing Maven plugins but appreciate that many will object to the effort involved.
Gradle promises to hit the sweet spot between Ant and Maven. It uses Ivy's approach for dependency resolution. It allows for convention over configuration but also includes Ant tasks as first class citizens. It also wisely allows you to use existing Maven/Ivy repositories.
So if you've hit and got stuck with any of the Ant/Maven pain points, it is probably worth trying Gradle out, though in my opinion it remains to be seen if you wouldn't just be trading known problems for unknown ones. The proof of the pudding is in the eating though so I would reserve judgment until the product is a little more mature and others have ironed out any kinks (they call it bleeding edge for a reason). I'll still be using it in my toy projects though, It's always good to be aware of the options.
Gradle can be used for many purposes - it's a much better Swiss army knife than Ant - but it's specifically focused on multi-project builds.
First of all, Gradle is a dependency programming tool which also means it's a programming tool. With Gradle you can execute any random task in your setup and Gradle will make sure all declared dependecies are properly and timely executed. Your code can be spread across many directories in any kind of layout (tree, flat, scattered, ...).
Gradle has two distinct phases: evaluation and execution. Basically, during evaluation Gradle will look for and evaluate build scripts in the directories it is supposed to look. During execution Gradle will execute tasks which have been loaded during evaluation taking into account task inter-dependencies.
On top of these dependency programming features Gradle adds project and JAR dependency features by intergration with Apache Ivy. As you know Ivy is a much more powerful and much less opinionated dependency management tool than say Maven.
Gradle detects dependencies between projects and between projects and JARs. Gradle works with Maven repositories (download and upload) like the iBiblio one or your own repositories but also supports and other kind of repository infrastructure you might have.
In multi-project builds Gradle is both adaptable and adapts to the build's structure and architecture. You don't have to adapt your structure or architecture to your build tool as would be required with Maven.
Gradle tries very hard not to get in your way, an effort Maven almost never makes. Convention is good yet so is flexibility. Gradle gives you many more features than Maven does but most importantly in many cases Gradle will offer you a painless transition path away from Maven.
This may be a bit controversial, but Gradle doesn't hide the fact that it's a fully-fledged programming language.
Ant + ant-contrib is essentially a turing complete programming language that no one really wants to program in.
Maven tries to take the opposite approach of trying to be completely declarative and forcing you to write and compile a plugin if you need logic. It also imposes a project model that is completely inflexible. Gradle combines the best of all these tools:
It follows convention-over-configuration (ala Maven) but only to the extent you want it
It lets you write flexible custom tasks like in Ant
It provides multi-module project support that is superior to both Ant and Maven
It has a DSL that makes the 80% things easy and the 20% things possible (unlike other build tools that make the 80% easy, 10% possible and 10% effectively impossible).
Gradle is the most configurable and flexible build tool I have yet to use. It requires some investment up front to learn the DSL and concepts like configurations but if you need a no-nonsense and completely configurable JVM build tool it's hard to beat.
Gradle nicely combines both Ant and Maven, taking the best from both frameworks. Flexibility from Ant and convention over configuration, dependency management and plugins from Maven.
So if you want to have a standard java build, like in maven, but test task has to do some custom step it could look like below.
build.gradle:
apply plugin:'java'
task test{
doFirst{
ant.copy(toDir:'build/test-classes'){fileset dir:'src/test/extra-resources'}
}
doLast{
...
}
}
On top of that it uses groovy syntax which gives much more expression power then ant/maven's xml.
It is a superset of Ant - you can use all Ant tasks in gradle with nicer, groovy-like syntax, ie.
ant.copy(file:'a.txt', toDir:"xyz")
or
ant.with{
delete "x.txt"
mkdir "abc"
copy file:"a.txt", toDir: "abc"
}
We use Gradle and chose it over Maven and Ant. Ant gave us total flexibility, and Ivy gives better dependency management than Maven, but there isn't great support for multi-project builds. You end up doing a lot of coding to support multi-project builds. Also having some build-by-convention is nice and makes build scripts more concise. With Maven, it takes build by convention too far, and customizing your build process becomes a hack. Also, Maven promotes every project publishing an artifact. Sometimes you have a project split up into subprojects but you want all of the subprojects to be built and versioned together. Not really something Maven is designed for.
With Gradle you can have the flexibility of Ant and build by convention of Maven. For example, it is trivial to extend the conventional build lifecycle with your own task. And you aren't forced to use a convention if you don't want to. Groovy is much nicer to code than XML. In Gradle, you can define dependencies between projects on the local file system without the need to publish artifacts for each to a repository. Finally, Gradle uses Ivy, so it has excellent dependency management. The only real downside for me thus far is the lack of mature Eclipse integration, but the options for Maven aren't really much better.
This isn't my answer, but it definitely resonates with me. It's from ThoughtWorks' Technology Radar from October 2012:
Two things have caused fatigue with XML-based build tools like Ant and
Maven: too many angry pointy braces and the coarseness of plug-in
architectures. While syntax issues can be dealt with through
generation, plug-in architectures severely limit the ability for build
tools to grow gracefully as projects become more complex. We have come
to feel that plug-ins are the wrong level of abstraction, and prefer
language-based tools like Gradle and Rake instead, because they offer
finer-grained abstractions and more flexibility long term.
Gradle put the fun back into building/assembling software. I used ant to build software my entire career and I have always considered the actual "buildit" part of the dev work being a necessary evil. A few months back our company grew tired of not using a binary repo (aka checking in jars into the vcs) and I was given the task to investigate this. Started with ivy since it could be bolted on top of ant, didn't have much luck getting my built artifacts published like I wanted. I went for maven and hacked away with xml, worked splendid for some simple helper libs but I ran into serious problems trying to bundle applications ready for deploy. Hassled quite a while googling plugins and reading forums and wound up downloading trillions of support jars for various plugins which I had a hard time using. Finally I went for gradle (getting quite bitter at this point, and annoyed that "It shouldn't be THIS hard!")
But from day one my mood started to improve. I was getting somewhere. Took me like two hours to migrate my first ant module and the build file was basically nothing. Easily fitted one screen. The big "wow" was: build scripts in xml, how stupid is that? the fact that declaring one dependency takes ONE row is very appealing to me -> you can easily see all dependencies for a certain project on one page. From then on I been on a constant roll, for every problem I faced so far there is a simple and elegant solution. I think these are the reasons:
groovy is very intuitive for java developers
documentation is great to awesome
the flexibility is endless
Now I spend my days trying to think up new features to add to our build process. How sick is that?
It's also much easier to manage native builds. Ant and Maven are effectively Java-only. Some plugins exist for Maven that try to handle some native projects, but they don't do an effective job. Ant tasks can be written that compile native projects, but they are too complex and awkward.
We do Java with JNI and lots of other native bits. Gradle simplified our Ant mess considerably. When we started to introduce dependency management to the native projects it was messy. We got Maven to do it, but the equivalent Gradle code was a tiny fraction of what was needed in Maven, and people could read it and understand it without becoming Maven gurus.
I agree partly with Ed Staub. Gradle definitely is more powerful compared to maven and provides more flexibility long term.
After performing an evaluation to move from maven to gradle, we decided to stick to maven itself for two issues
we encountered with gradle ( speed is slower than maven, proxy was not working ) .
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I am very new to Maven. I have the following questions:
Do we need to create POM file our own?Do we need to understand POM file fully to use Maven?
We are mentioning Plugin in the POM. will that plugins only be downloaded by Maven when use Maven? or by default all plugins will be downloaded?
Please explain.
First you need to understand the pom content otherwise you are not able to influence the build process. The pom file should be created manually but there are some exceptions like Spring Roo which will create the pom but it's better to understand the pom to see if something is going wrong.
The plugins mentioned in the pom will be downloaded automatically by Maven but there are plugins which are by default in the life cycle which will be downloaded as well in contradiction to naming them in the pom file.
You need at least to understand some basics of Maven: dependencies, how to configure plugins, how to start a new POM (you can do this in IDE or create a project from an archetype), basic commands: mvn compile, mvn package, mvn install. If your only need is to build your classes into JARs, Maven configuration would be as small as a list of dependencies.
Everything in Maven is downloaded by default - all artifacts are being searched in Central and any other configured repositories. Once downloaded, they are stored on your machine at $HOME/.m2/repository.
Might be helpful: Maven Quick-start Guide.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
This might be a stupid question. Currently in my company the usage of gradle is starting to emerge. I have been learning about the basic of gradle and use it for my small projects.
Because of gradle's flexibility, the usage can be very vast. I'm coming from maven and now I'm confused about the role of gradle in our project as it is a general-purpose tool.
Here are some of the usages that pops questions in my head:
Gradle tasks are treated as CLI sub commands. The command line arguments are passed as properties. It seems to me that the project can just be written as a normal java/groovy that uses library common-cli or args4j that are already quite mature (supporting help, usage, etc).
Some of the sub projects are checked out using gradle instead of using the svn:externals.
My question is not about how?, it's more about should it?
Gradle gives you a lot of flexibility, indeed. As it uses Groovy - you can really create all kind of workflows and commands. I'm not sure if this is the best practice though.
The best is when you can leverage the declarative side of Gradle (via Java plugin), the same way as you do with Maven - build by conventions, and then you may have customizations if you need to do something extra with the build artifacts. So Gradle is a kind of a tool that merges all the benefits from Maven and Ant, replacing XML with Groovy DSL.
What you described sounds more like a project with a very custom structure and the only thing you actually leveraged is the task execution engine. Same you would do with Ant. But you didn't mention, for instance, if you're using plugins.
Some of the sub projects are checked out using gradle instead of using
the svn:externals
I think you could do the same with any other build tool out there. To me it sounds quite strange - there's already a CLI tool for that (svn, git, hg, ). Probably the person who established this had a desperate wish to accommodate all the commands into one tool, which is some cases may be quite useful, why not. But as you didn't provide more context, this all sounds like an overuse of scripting and over-engineering.
The features that are in gradle page shows a lot about this tool.
Gradle has the flexibility of ant and the conventions of Maven. Gradle can use ANT and Maven. Everything in Groovy.
Features
Declarative builds and build-by-convention
Gradle uses DSL(Domain Specific Language) based on Groovy.
Language for dependency based programming
The tasks are based in a hierarchy, favoring the builds
Structure your build
Easy to compose buid from reusable pieces
Deep API
Allow to monitor and customize the configuration and behavior execution
Scalability
Reusability allows one project uses parts of other projects increasing the produtivity
Multi-project builds
You can rebuild a project or its sub-project, that depends on another sub-project.
Different ways to manage dependencies
Maven has just one way. Can integrate with maven and ivy, or just use jars or directories.
Groovy
Insteady of XML.
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 9 years ago.
Improve this question
What is the difference between Gradle and Maven?
I am new to Gradle but I used to work with maven.
When to use Gradle and When to use Maven ?
You can think of Gradle as goodness of Ant and Maven put together minus the noise of XML. And scriptability with groovy is very big plus.
Gradle gives you conventions but still gives you power to override them easily.
Gradle build files are less verbose as they are written in groovy.
It provides very nice DSL for writing build tasks.
Has lot of good plugins and vibrant ecosystem
When to use Gradle and When to use Maven ?
Almost everywhere for creating java/groovy project. The build files are much terse.
With Google choosing Gradle as the new build system for Android SDK and mature libraries like Spring, Hibernate, Grails, Groovy etc. already using it to power their builds, there is no doubt that Gradle is becoming de-facto build system for the Java ecosystem.
Gradle is the next evolutionary step in JVM-based build tools. It draws on lessons
learned from established tools like Ant and Maven and takes their best ideas to the next
level. Following a build-by-convention approach, Gradle allows for declaratively modeling your problem domain using a powerful and expressive Domain-Specific Language (DSL)
implemented in Groovy instead of XML. As Gradle is a JVM native, it allows you to write
custom logic in the language you are most comfortable with, be it Java or Groovy
For more information here: Next generation builds with Gradle