I ran
mvn release:prepare for a project and it is a multi-module build.
I entered yes for the following question :
There are still some remaining snapshot dependencies.: Do you want to
resolve them now? (yes/no) no: : yes
Dependency type to resolve,: specify the selection number ( 0:All 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: :0
Resolve All Snapshots.: 'com.test:core-api' set to release? (yes/no) yes: : yes
What is the next development version? (0.0.6-SNAPSHOT) 0.0.6-SNAPSHOT: : 1.2.0-SNAPSHOT
and it keeps on asking me the following in an unending cycle.
What is the next development version?
I have to Ctrl+C to exit the loop.
I ran into this same issue when I refactored the groupId in my multi-module build.
The cause is exactly what the error message says, but it can be elusive to spot the snapshots dependency.
In my case, the toplevel groupId and the groupIds in the <parent> stanzas in the submodules were all correct, but also some modules in the tree have cross dependencies to other modules, and as such are included in the <dependencies> or <dependencyManagement> stanzas.
These dependencies are tied to the project version by, well,${project.version}, so they're easy to miss in a text search for 'SNAPSHOT'. Since I forgot to refactor the groupIds in these dependencies, maven sees it as a 'foreign' snapshot dependency, outside of the project itself.
From past experience it's not an un-ending cycle, but a HUGE amount of snapshots dependencies need to be confirmed (hence you get the impression it's an infinite loop). This typically happen in a maven aggregation (multi module) project.
If you know you always accept the DEFAULT answer, you can try running it in batch mode
mvn --batch-mode release:prepare
The default behavior of release plugin is to ask confirmation everytime it detects a snapshot dependencies. If you follow maven common practice, release your snapshot dependencies first and update reference to the dependencies before releasing your project.
http://maven.apache.org/maven-release/maven-release-plugin/examples/non-interactive-release.html has a good information on performing non-interactive release
Related
I need to sort the dependencies in the dependencyManagement section of a POM file that is used as a parent for all projects of my team's portfolio.
The motivation for this is similar to the one described here. In my case, I am just trying to harmonize the versions used throughout our portfolio, in order to avoid the recurring nightmare of version discrepancy: due to copy-paste, some projects use a version of a dependency while others use another version. Another motivation is to have only one place where to manage dependencies. What I am doing is essentially merging dependency specifications from all modules into a giant dependencyManagement section of a parent POM. (EDIT: In the process of looking for an answer to this need of mine, I learned that such a POM is what Maven calls a BOM or "bill of materials".)
However, this task requires that I define the version of each dependency in our parent POM. Doing so, I find myself putting the dependency specification somewhere in what is a growing list of dependencies. It gets more and more difficult to add a dependency and find out whether the dependency is already specified. But that would be much easier if I could sort the dependencies, for instance by group ID.
Is there a plugin that serves that purpose of reordering the dependencies? As a last resort, I will end up writing a small program that will read the XML file from the parent POM and output it sorted.
The recently released version 0.2.0 of BOM Helper Maven Plugin now has the sort goal that does exactly that.
You need to add the plugin to your pom:
<plugin>
<groupId>com.commsen.maven</groupId>
<artifactId>bom-helper-maven-plugin</artifactId>
<version>0.2.0</version>
</plugin>
You can configure it to run on every build, but I would rather run it manually only when I add/change a dependency. Something like:
mvn bom-helper:sort -Dbom-helper.inplace=true
should do the job. See the docs for more options.
I used sortpom. See more about parameters at https://github.com/Ekryd/sortpom/wiki/Parameters
mvn com.github.ekryd.sortpom:sortpom-maven-plugin:sort -Dsort.encoding=UTF-8 -Dsort.sortDependencies=scope,groupId,artifactId -Dsort.sortPlugins=groupId,artifactId -Dsort.sortProperties=true -Dsort.sortExecutions=true -Dsort.sortDependencyExclusions=groupId,artifactId -Dsort.lineSeparator="\n" -Dsort.ignoreLineSeparators="false" -Dsort.expandEmptyElements=false -Dsort.nrOfIndentSpace=2 -Dsort.indentSchemaLocation=true
The easiest way to sort your dependencies is to use the sortpom maven plugin.
It is very easy to use. Just go to your project directory, open terminal and run the following command:
mvn com.github.ekryd.sortpom:sortpom-maven-plugin:sort -Dsort.keepBlankLines -Dsort.predefinedSortOrder=custom_1
To find more about the project, check their github repo: https://github.com/Ekryd/sortpom
The command mvn -U forcing all project dependencies to get updated from remote repository.
Is it possible to force such update for specific selection of dependencies, by explicit selection / by some logic?
The reasoning:
I don't want to force checking all the dependencies we have because how time consuming it is. All I need, is to verify a few of them or even specify only one dependency. So, such solution is highly desired.
There are two maven plugins that may help you here.
The first, dependency, will simply download the given version of a dependency:
mvn dependency:get -Dartifact=groupId:artifactId:version
The second, versions, offers some behaviors which you may also find helpful.
By running mvn versions:use-latest-releases -Dincludes=groupId:artifactId your project's pom will be updated with the latest release version of the dependency specified by the '-Dincludes' flag. You could then run the first command to download the version now referenced by your pom.
Both of these behaviors can be heavily customized and automated to do some quite awesome things. To get more help on a plugin goal, run: mvn plugin:help -Ddetail=true -Dgoal=goal
Example: mvn versions:help -Ddetail=true -Dgoal=use-latest-releases
For further information:
versions, dependency, and plugins
After working with Maven for a while, I am thrilled by the many features that Maven brings into the build architecture, particularly the dependency management. However, I have run into one issue again and again - how Maven resolves dependencies between multi-module projects. I am wondering if this is the big flaw of the current Maven implementation and/or if there is any satisfactory workaround.
Let's say I have a multi-module Maven project. The Parent pom contains three modules -- moduleA (jar), moduleB (jar), and moduleC(war). B depends on A and C depends on B. Simple enough? Now that I want to run the mvn dependency:go-offline at the parent project, which is supposed to resolve all the dependencies and bring them into the local .m2 directory. It fails because Maven complains that it cannot solve dependency for moduleA when it is acting on moduleB. Because all these modules belong to one groupId, I even try to use -DexcludeGroupIds=x.y.z to exclude these module dependencies, but it still fails at the same point.
I understand why Maven is complaining - moduleA is not built yet and thus there is no moduleA:jar artifact in my local or internal repository when go-offline goal is executed. But IMHO the plugin should treat these inter-module dependencies differently. In this case, it should simply ignore it. One might argues that I can simply do mvn clean install, which will install moduleA:jar into the local repository. After that, running mvn dependency:go-offline will work for sure. But that workaround defeats the purpose of this go-offline goal. This plugin allows us to resolve and pull dependencies into our local repository without building the whole project. I used dependency:copy-dependencies goal in another case and it has the same issue.
I also ran into similar issue in other scenarios: "mvn clean generate-source" could not resolve dependencies. When I ran mvn clean compile, everything works fine, but when I ran mvn clean generate-source, it fails because Maven cannot resolve inter-module dependency. In that case, the was caused by #requiresDependencyResolution in the antrun plugin.
Since both antrun plugin and dependency plugin are very popular in the Maven world, I am sure I am not the only one who have run into this issue. Anyone finds any solution/workaround?
Maven has the concept of a "reactor" where artifacts that have been built in a single run (e.g. maven package) are available for dependency resolution during the build. For example, if your dependency graph yields the build order moduleA moduleB moduleC, and you do mvn package, Maven will build moduleA, package its artifact and add it to the reactor, then build moduleB, package it and add it to the reactor, then the same for moduleC. This means moduleB has access to moduleA's artifact for dependency resolution, and moduleC has access to moduleA and moduleB. This only works if artifacts are actually built, i.e. when you run the package goal.
The problem is that when you don't run the package goal because you're not interested in the artifacts (as for your dependency:go-offline example), artifacts for modules that have been processed don't get built and thus not added to the reactor. I find this annoying as well; I think Maven should look at the POM files in its list of modules to build and look there as well; but it doesn't.
In short, the solution to your problem is to do mvn package dependency:go-offline . This will not install artifacts in your local repository (which I believe is very bad practice) but it will put them in the reactor for the duration of the build, meaning that Maven will be able to resolve dependencies from your moduleB to the moduleA that has already been built. The downside is every module will be tested and packaged, which is a lot of work when all you wanted is to do dependency:go-offline.
Either way, hope this helps.
This has been finally been resolved with Maven Dependency Plugin version 3.1.2.
You can make sure it's used by pinning the version in your pom.xml:
<build>
<pluginManagement>
<plugins>
<plugin>
<artifactId>maven-dependency-plugin</artifactId>
<version>3.1.2</version>
</plugin>
</plugins>
</pluginManagement>
</build>
I have created a JIRA ticket with a sample project here:
https://issues.apache.org/jira/browse/MDEP-516
Please vote for it.
You explained why it doesn't work so you understand the issues. The problem for you is that it stops when it can't find A.jar but that will only happen when you get to building B. So there is a sort of, sometimes useful strategy.
You have to mess with A by itself. Just build A. Use your plan of loading dependencies and then building it.
Once it builds, you can move on to doing the same thing with B and then C. Step by step.
One thing to remember here is that its sometimes ok to build B with an old snapshot of A in the local repo. You only need the new snapshot of A build in the repo if there are signature changes or new stuff required by B.
There are some discussions here too: Maven Modules + Building a Single Specific Module
One final not that usually these sort of questions come up when people have builds that take too long. There are several ways to make builds go faster:
Get faster hardware. The build computer, the disk storage or the network speed are typical components that are cheaper to upgrade than waste the time taken in slow builds.
Make the build go faster by not building stuff that doesn't need rebuilding. (For example, I had a build that rebuilt all the generated code every time. I added some stuff into the build that kept it from doing that except when dependencies to the generated code changed.)
Speed up the tests. Sometimes this means breaking the tests into two parts. Part 1 is fast tests and part 2 is slow tests. Run the fast tests on every build and the slow tests before any checkin of code or release of artifacts.
Break a multi-module build into 2 or more separate builds and use human intelligence to decide when to rebuild things. This works well when some jars are stable and don't change much any more.
Fill in your own method to make the build go faster.
I doubt such functionality would ever be possible with Maven. Whilst your projects share a common parent and depend upon each other, Maven cannot possibly know where to find these projects in order to build them. It also cannot determine whether the projects just need to be built, or whether you've specified the wrong version number for your dependency.
That's going to be supported by dependency:go-offline goal starting from Maven Dependency Plugin v3.1.2. Related jira ticket MDEP-204 and patch 23b7ca8790ae14175ed8e3a20c75c6274efe5ad8 with fix.
mvn release:prepare
It constantly asks me to resolve snapshot dependencies.
Is there a way to do this in batch mode so that maven automatically uses the associated release. i.e. if a dependency is 1.0.0-SNAPSHOT it will automatically update this dependency to the 1.0.0 release?
[INFO] Checking dependencies and plugins for snapshots ...
There are still some remaining snapshot dependencies.: Do you want to resolve them now? (yes/no) no: : yes
Dependency type to resolve,: specify the selection number ( 0:All 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3) 1: : 1
Resolve Project Dependency Snapshots.: 'com.my.project' set to release? (yes/no) yes: : yes
What is the next development version? (0.0.2-SNAPSHOT) 0.0.2-SNAPSHOT: : 0.0.2-SNAPSHOT
Note that you can configure Maven ignore SNAPSHOT dependencies checking by using allowTimestampedSnapshots, according to maven-release-plugin documentation:
allowTimestampedSnapshots:
Whether to allow timestamped SNAPSHOT dependencies. Default is to fail when finding any SNAPSHOT.
Type: boolean
Since: 2.0-beta-7
Required: No
Expression: ${ignoreSnapshots}
Default: false
Or simply run the command below:
mvn release:prepare -DignoreSnapshots=true
However, it is still recommended to resolve all SNAPSHOT dependencies before doing the final release, as it is the convention used by most people. You should always consider to do it manually at developing phase rather than automatically batching at release phase, as change/upgrade project's dependencies (either your own or third party jar) may sometimes introduce bug or incompatibility and break your project, which usually need developer's attention and fix them before doing final release.
In another word, dependency resolution is not a task which should be done at release phase, moreover, it is not a task which should be done automatically without developer's attention.
You can do update of the SNAPSHOT's via the versions-maven-plugin before the release.
If your dependency is a program of you own and its lifecycle is closely linked to the one you try to release, you may think about using a multimodule project : http://maven.apache.org/guides/mini/guide-multiple-modules.html. Maven release plugin would update version for all of you dependencies modules.
If not, you are probably doing something you should not.
Just changing 1.0.0-SNAPSHOT to 1.0.0 does not ensure you app will continue to work. So does not consider that Maven should !
Further considerations
Maven release plugin checks if you are using a snapshot dependency, because Snapshot, by definition, are unstable vesions. It may change along the time. That means what was working today may not work tomorrow.
Releasing means that your version is stable, and the build can be reproduce anytime without any change. Using Snapshot version, this assertion become false.
So,
I've got a project with Maven in which one subproject (A) wants to depend on another subproject (B) which uses "pom" packaging.
If I do this the straightforward way, where A specifies a dependency on B with <type>pom</type>, things work perfectly if I do "mvn install", but if I run any phase earlier than install, such as mvn compile or mvn package, then it fails while trying to build A: it goes looking for B's pom in the repository, and doesn't find it.
I don't really want this pom in the repository, because it's part of our active source code and changes frequently.
For all the jar-packaged projects we build, it seems to work fine to keep them out of the repository, build with mvn package, and Maven knows how to find all the dependencies in the source and build trees it manages without resorting to the repository; however for the pom-packaged project it always wants to go to the repository.
A couple things I learned while trying to understand this:
Maven best practices encourage you to use pom-packaged projects to group dependencies, but with the added step of "mvn install" on the POM project
Maven lifecycle documentation says "a project that is purely metadata (packaging value is pom) only binds goals to the install and deploy phases"; maybe this is why the POM project is invisible as a dependency target unless I invoke the install phase? I tried binding the compiler plugin to the compile phase and this didn't seem to help.
Is there a way that I can specify the POM subproject as a dependency of another subproject in the same parent project, without installing the POM project to the repository?
It isn't purely a question of which goals are bound to which lifecycle phases for POM projects. If it were, then binding the "package" goal would solve the problem.
When building a multi-module project, Maven reads the POMs of all modules to determine dependencies between modules, so that it can build the depended-upon modules before the depending modules. It's able to achieve this even when running the "package" goal (such that the depended-upon modules are not yet in the local repository).
Therefore, the code that constructs the classpath for builds must be managing several cases, notably:
extra-project jar dependency, where it looks for the POM in the local repository, handles its dependencies, and adds the POM's jar to the classpath
extra-project pom dependency, where it looks for the POM in the local repository and handles its dependencies
intra-project jar dependency, where it looks for the POM within the project tree, handles its dependencies, and adds that module's target/classes folder to the classpath
intra-project pom dependency, where for some reason it doesn't look for the POM within the project tree, and therefore doesn't handle it's dependencies.
Notice the asymmetry in the last two cases, as compared to the first two.
I can see two solutions to your problem. One is to file a bug report, or rather a request to change the behaviour (since it's obviously intentional), perhaps only for the case of intra-project dependencies on multi-module projects. Or indeed propose a patch. But since the behaviour is intentional, you might meet a refusal. In the best of cases, you're in for a long wait. (I'd vote for your bug report though - I've been stung by that same behaviour, in a different context.)
The other solution is simply to run an install on your project. I don't really understand why you don't want the POM project in your repository: if needs be, you can use a snapshot repository, where it doesn't matter if things change frequently, to avoid polluting your main repository.
Configuring maven-install-plugin to run during the compile phase, and copy the relevant pom.xml to the repository, seems to accomplish what I wanted as far as Maven itself is concerned, though m2eclipse still is not happy (it throws "failed to read artifact descriptor" errors with no additional description for the pom.xml that has a dependency on the other POM project).