I have a maven project which has multiple profiles and lots of dependencies which are specific to each of those profiles. The current solution to clean this up works by creating an intermediate dependency pom for each profile which groups the dependencies together as described here in 3.6.1: http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-best-practice.html Each of these dependency grouping poms lives in their own svn project and is build and deployed as a separate jenkins job.
The problem is that these poms, and the dependencies within them change and are released often and it has become difficult to maintain. Ideally, I would like all of the dependency management to live under one svn project and one build.
Any suggestions would be appreciated.
As khmarbaise writes, it would help with more information and an example.
However, just answering your actual question, how to get all your depenency grouping poms as one project and one build. It sound as if a multi module project with each module being one of your "dependency grouping pom" projects would be what you are looking for.
The Maven Release Plugin did what we needed.
Related
I need to extract a project from a repository which uses several layers of parent projects. Every parent project adds some dependency or plugins or properties. This is becoming a nightmare as I'm not able to build any more the project, once I've manually added pieces from parent projects.
Is there a way to create a list of all dependencies/plugins/properties which are linked by a single pom.xml so that I can build a portable, single Maven project?
Thanks
You can create the effective pom (https://maven.apache.org/plugins/maven-help-plugin/effective-pom-mojo.html) that is a kind of merge with all parent POMs.
This is useful to understand the complete list and configuration of plugins.
Whether this helps you to build a "portable" Maven project, I don't know. Without the appropriate Maven repositories with all the plugins, dependencies and so on, Maven will not build.
Base concept of Maven is CoC (Convention over Configuration). Maven has a SuperPOM and all model is inherited from that. SuperPOM is located in maven-model-builder jar. Here is the source https://maven.apache.org/ref/3.6.2/maven-model-builder/super-pom.html
Each Maven goal is using a merged model called effective pom. The help plugin has effective-pom goal which displays the full model including parent model(s) and SuperPOM.
So the answer is just run: mvn help:effective-pom command to see actual model.
Very new to Maven, can someone please explain to me the difference between using maven modules vs just adding a dependency to your maven project to another maven project in your workspace? When would you use one over the other?
A dependency is a pre-built entity. You get the artifact for that dependency from Maven Central (or Nexus or the like.) It is common to use dependencies for code that belongs to other teams or projects. For example, suppose you need a CSV library in Android. You'd pull it as a dependency.
A Maven module gets built just like your project does. It is common to use Maven modules for components that the project owns. For example, maybe your project creates three jar files.
A dependency can be thought of as a lib/jar (aka Artifact in Maven parlance) that you need to use for building and/or running your code.
This artifact can either be built by your one of the modules of your multi module project or a third party pre-build library (for example log4j).
One of the concepts of maven is that each module is going to output a single artifact (say a jar). So in case of a complex project it is good idea to split your project to multiple modules. And these modules can be dependent on each other via declared dependencies.
See http://books.sonatype.com/mvnex-book/reference/multimodule-sect-intro.html for example of how a web app is split to parent and child modules and how they are linked.
One of the most confusing aspects of Maven is the fact that the parent pom can act as both a parent and as an aggregator.
99% of the functionality you think about in Maven is the parent pom aspect, where you inherit things like repositories, plugins, and most importantly, dependencies.
Dependencies are hard, tangible relationships between your libs that are evaluated during each build. If you think of your software as a meal, it's basically saying A requires ingredient B.
So let's say you're preparing lasagne. Then your dependency chain would look something like this:
lasagne
<- meatSauce
<- groundBeef
<- tomatoPaste
<- cheese
<- noodles
The key thing is, each of the above items (meatSause, groundBeef, cheese, etc) are individual builds that have their individual set of dependencies.
By contrast, the only section of your pom that pertains to aggregation is the modules section:
<modules>
<module>meatSauce</module>
<module>groundBeef</module>
<module>tomatoPaste</module>
<module>cheese</module>
<module>noodles</module>
</modules>
Aggregation simply tells your build engine that it should run these 5 builds in rapid succession:
groundBeef -> tomatoPaste -> cheese -> noodles -> meatSauce
The main benefit of aggregation is the convenience (just click build once) and ensuring the builds are in the correct order (e.g. you wouldn't want to build meatSauce before tomatoPaste).
Here's the thing though: even if you organize the libs as standalone projects without module aggregation, your build will still come out the same provided you build in the correct order.
Moreover, both Jenkins and Eclipse have mechanisms for triggering builds if a dependent project has changed (e.g. changing groundBeef will automatically trigger meatSauce).
Therefore if you're building out of Jenkins or Eclipse, there is no need for aggregation
We do not need to specify the versions and other parameters of Maven dependencies and plugins we use. We can do it only once in parent POM or may be in some other way and inherit that properties in our children POMs.
Unfortunately for many times I have met the projects where I cannot find the real parameters of dependencies and plugins that easily. I.e. the versions of dependencies are empty, but in parent POM there is no information about this.
So my questions are:
What are all the possible ways to specify the parameters of dependency and plugin in Maven? I.e. where can I look for version number if it is not present neither in plugin in child POM nor in plugin management in parent pom?
Is there any Maven command to find out where Maven takes these parameters from? For example, I may use the dependency:tree command. It will print a list of dependencies which will help me to understand the version dependency I am stuck about. But this is a hack, and it cannot help me with plugins. May be there is something better?
Before executing any command, Maven builds the "effective POM", see this stackoverflow answer for more details. You may view the effective POM for any project by running mvn help:effective-pom. Typically when I run this command I redirect the output into a file so I can view and search it in a text editor.
You asked about specific parts of the POM, dependencies and plugins. You're on the right track, the maven-dependency-plugin helps. The goals I use most often are dependency:tree, dependency:resolve, and dependency:resolve-plugins. The first two assist with project dependencies, the last one with plugins. Add the -U option to force Maven to update dependencies regardless of the update policies/repository metadata values.
It is also helpful when troubleshooting to start with an empty local repository.
Last but certainly not least, Maven will give warnings when a build uses a plugin without a specific version. ALWAYS specify an explicit version to fix the warning and avoid issues like this one.
My (new) Gradle project depends on a Maven project that is a child of a parent Maven project with many subprojects. Notice that I only care about one little subproject there, nothing else from that parent.
Trouble is, Gradle walks up the Maven project tree and when it sees the "dependencyManagement" in parent pom instead of treating it for what it is - list of "approved versions" of dependencies for any and all subprojects of that parent, it actually assumes that they are ALL actual dependencies of the child/subproject I care about... And that brings waaaay too much stuff into my Gradle project.
I am presently working around by explicitly excluding all those dependencies I presently know are not presently (again) not needed, but I don't want to do that as that would mean that I have to keep up my project essentially in sync with ALL projects from that parent.
This is with Gradle 1.6. I MAY have some (little) level of influence on how those Maven projects are structured but preferably such a thing would not be needed and I could somehow tell Gradle to behave as it should... Is there a way?
Please help!
EDIT 1
The dependency is via a maven repository. The dependency I have is a subproject of a project built and deployed by Maven, to a Maven repository.
I also asked this on Gradle forums: http://forums.gradle.org/gradle/topics/8mftwmyn8uu75?rfm=1
Turns out this was not a problem at all. Huge POM of that parent project was hiding some actual dependencies that exploded...
Every time I make a new proper project using Maven hosted on Github I have to go look at either one of my own old projects and copy the pom file or I go find a project that I think does a good job and copy there POM file. Then I have to go search and replace things like project name... etc.
Now Maven has a solution to this through archetypes but I have yet to see one that is modern enough such that it:
Uses the release plugin and deploys to SonaType Central Maven reop.
Connects to Github (meaning the scm connections and release plugin work do the right thing)
Makes all three jar artifacts (sources, javadoc, and regular jar)
I have contemplated make some giter8 templates but was hoping somebody already did something like this (most of the g8 templates are for sbt).
You can use com.jcabi:parent:pom which does exactly what you need and many more. It deploys to Sonatype, defines common dependencies with versions, pre-configures most popular plugins, and defines a few useful profiles.
This article explains more: Don't Repeat Yourself in Maven POMs; Use Jcabi-Parent
You could have a look at the parent pom released by Sonatype. It's intended to be used as a parent pom for projects that deploy to oss.sonatype.org (which may or may not be promoted to Maven Central).
When the sonatype-oss-release profile is enabled, it will ensure that sources and javadocs are built. It also includes an example of the <scm> pom element.
It turns out its incredible easy to create your own maven archetype.
Just make a generic project with stuff you like to use
In the project directory run mvn archetype:create-from-project
Generally Maven guesses the right things to make variable but if not you just edit the Velocity templates.
Install your archetype locally with mvn install
To use your new archetype: mvn archetype:generate -DarchetypeGroupId=com.mygroup -DarchetypeArtifactId=my-archetype
Now the only caveat is that there is not very good doc on the web that I could find on the archetype system. Like its unclear what variables you have available to you for Velocity (although most of them are obvious).
http://maven.apache.org/archetype/maven-archetype-plugin/create-from-project-mojo.html