I want to run mvn command to get rid of all artefacts under ~/.m2/repository/here/goes/my/groupid. In order to do so, I run:
mvn -pl my-module dependency:purge-local-repository -DresolutionFuzziness=groupId -Dinclude=<here-goes-my-groupid> -DactTransitively=false -DreResolve=false -Dverbose=true
This works fine, as long as the current version (3.0.0) of the current artefact (my-maven-plugin) is in the local repo.
If the current version (3.0.0) of the current artefact (my-maven-plugin) is not in the local repo (e.g. there is only an older version of this artefact in the local repo, say 2.9.0), nothing gets purged:
[INFO] --- maven-dependency-plugin:3.0.0:purge-local-repository (default-cli) # my-maven-plugin ---
Downloading: https://repo.maven.apache.org/maven2/here/goes/my/groupid/my-maven-plugin/3.0.0/my-maven-plugin-3.0.0.jar
[INFO] Unable to resolve all dependencies for : <here-goes-my-groupid>:my-maven-plugin:3.0.0. Falling back to non-transitive mode for initial artifact resolution.
[INFO] No artifacts included for purge for project: <here-goes-my-groupid>:my-maven-plugin:maven-plugin:3.0.0
I don't understand why maven-dependency-plugin tries to download anything from maven central. All it should do is to recursively drop a folder in local filesystem.
How can I enforce purging all artefact under given groupId, no matter if the current version of the current artefact is in the local repo or not?
include expects the groupId of the dependency being purged to be exactly same as that of the project.
The options resolutionFuzziness, actTransitively and reResolve apply only when the said groupId condition is satisfied.
I guess, this might be because the plugin developers want to prevent the accidental purging of artifacts that are out of project's group. It's my wild guess though.
Relax! manualInclude comes to the rescue. It can purge the artifacts irrespective of the project's groupId.
Try this:
mvn dependency:purge-local-repository -DmanualInclude=<group-id>:<artifact-id>
or this:
mvn dependency:purge-local-repository -DmanualIncludes=<group-id>:<artifact-id>
However, the difference is that unlike include it doesn't re-resolve the artifact after purge, no matter what value you give to reResolve.
This condition skips the re-resolve.
Related
I am using Maven for my project. I have a parent project myProjectA and when I do mvn clean install it builds successfully. myProjectA has multiple children, one of which is "childA1". This childA1 calls a plugin childB1 from myProjectB.
The problem is that when I try to do mvn clean install on childA1 then it fails with error:
Plugin my-maven-plugin:0.1-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for my-maven-plugin:jar:0.1-SNAPSHOT: Failure to find org.wildfly.core:wildfly-core-parent:pom:myVersion in http://repository.jboss.org/nexus/content/groups/public/ was cached in the local repository, resolution will not be reattempted until the update interval of jboss-public-repository-group has elapsed or updates are forced
I understand from the error that the dependency org.wildfly.core in my-maven-plugin is not found. This dependency does not appear explicitly in the pom of childA1 or childB1. So to try to solve my problem I added the dependency to childB1 and did mvn clean install on childB1, the dependency was resolved and build was successful. While doing this I saw that the dependency was in fact downloaded from http://mynexus/nexus/content/groups/public and not the jboss repository that childA1 tries to get it from.
I looked at the "effective pom" tab (in Eclipse) of childA1 and childB1 and there I saw that the correct repository, mynexus, was listed and not the jboss repository.
Other things I tried is running with -U and I made sure to build myProjectA before building childA1. Unfortunately this did not solve my problem. Any suggestions how to fix it are welcome.
How can I fail the build if a certain artifact does exist in the repository? The Maven Wagon Plugin has an "exists" goal, but not the opposite.
The reason for my question is as follows.
My Maven project goes through an automated build pipeline, which ends in a release stage. This stage performs an automated release through a mvn deploy -P release, after setting the release version with a mvn versions:set -DremoveSnapshot. The stage is triggered manually (since not every push should result in a release).
The mvn deploy will fail if the artifact to be uploaded is already in the repository. But this failure would come very late, during the last stage of the pipeline, while existence in the repository could be checked much earlier.
In order to get fail-fast behavior I would like to check if the artifact that would be released has not already been uploaded to Nexus. I want to do this in the first stage of the pipeline, which only performs a mvn package -P releasable. Preferably the "releasable" profile would make Maven do this check automatically during the "validate" phase of the default lifecycle.
The mvn deploy will fail if the artifact to be uploaded is already in the repository
Note: only if you upload as a "RELEASE", not a "SNAPSHOT".
Your build could check first if that release version exists:
mvn dependency:get -Dartifact=g:a:v -o -DrepoUrl=file://path/to/your/repo
If that gav (group-artifact-version) does exists, then you don't proceed with the rest of the build.
To keep that in a pom.xml, you can use:
activation profile, activated by a properties.
said property would be set by a first build step (or even before in the lifecycle) call to mvn dependency:get using the maven-dependency-plugin task.
dependency:get simply puts the artifact in the local repository if it exists.
I'm not sure how to fail the build from that point, since checking the local repo is not good enough.
You can check if the dependency artifact exists in the local maven repo.
This may be similar to: Maven: How to check if an artifact exists?
Except I don't want to determine the existence of the artifact from within a mojo.
I want to know if the artifact exists in my repo preferably just from the command line. (ie mvn some:plugin -Drepo... -Dgroup... -Dversion... -Dartifact... etc.
The reason I want to know this is this: We have a yum repo and we are migrating it to a Sonatype Nexus repo, which is a maven repo under the covers. I don't want to "mvn deploy" a huge rpm only to have it fail because it already exists in the repo. If it exists in the repo, I don't want to deploy it.
Any ideas how I can check if an artifact exists in a maven repo without having to download it first?
The Maven Wagon plugin can determine if an artifact exists if given a URL to a Maven repository:
You will have to build that URL beforehand using groupId, artifactId, etc.
mvn wagon:exist -Dwagon.url=http://repo1.maven.org/maven2/javax/servlet/jstl/1.2
when run within your project, will produce:
[INFO]
[INFO] --- wagon-maven-plugin:1.0-beta-4:exist (default-cli) # proj ---
[INFO] exists.
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
My situation: I have project which contains several Maven modules. I make changes to one of them. Suddenly I find out, that my project is no longer possible to be built because of the errors in other modules. To fix this I need to run SVN UPDATE and rebuilt the project.
My assumption: probably, during the build process of my module some of the artifacts are taken from central repository and have the most newest version, while others are still outdated and taken from my local repo.
A question: I don't want to rebuild my project each time someone updates ANOTHER Maven module. I want to download the already built artefacts from the central repository without rebuilding them by myself. Is it possible?
You can tell Reactor which modules to build. In your case when you only change a single module and want to speed up the build you can pass -pl (Project Location) parameter to maven. For example:
mvn -pl module-with-changes
That will build single module, while taking other dependencies from your local Maven Repository or download from Central (whatever is the latest). That said, if you already ran mvn install for whole project and other artifacts have not been updated in Central repository, then Maven will see your local artifacts as latest and will not re-download them.
Another issue you might get with -pl parameter is when other modules in your project depend on the module that you are building. If there is a problem in dependent module you will not see it by building only the dependency model. To avoid that you can pass -amd (Also Make Dependents). Like this:
mvn -pl module-with-changes -amd
That will trigger the build for module-with-changes + modules that depend on module-with-changes + their dependents.
You can get more info about Reactor parameters from here:
http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-advanced-reactor-options/
In one of my Maven projects, dependency resolution will succeed once, then fail for later build attempts:
[WARNING] The POM for commons-logging:commons-logging:jar:1.1.1 is missing, no dependency information available
[WARNING] The POM for commons-httpclient:commons-httpclient:jar:3.1 is missing, no dependency information available
[WARNING] The POM for javax.mail:mail:jar:1.4.4 is missing, no dependency information available
…and so on, until I delete the maven-metadata-local.xml files corresponding to the failing artifacts (e.g. ~/.m2/repository/commons-logging/commons-logging/maven-metadata-local.xml). After those files are deleted, the next mvn invocation proceeds properly; the metadata files are restored by that invocation (presumably as part of the process of checking my upstream repositories/mirrors for updated artifacts), and I am again presented with the above errors until I again delete the metadata files.
This impacts multiple projects, though it appears to be limited to a particular set of dependencies. I suppose I could go nuclear and blow away my local repo, but I'd like to understand what the problem is.
Thoughts?
Update: It looks like it's the maven-invoker-plugin (which these builds are using for general-purpose integration testing) that is producing these maven-metadata-local.xml files. I'm not using an integration-testing-only local repo as described here, simply because doing so causes the re-downloading of all transitive dependencies (unless you want to maintain an integration-specific settings.xml file!!!). I've used the invoker plugin with a variety of other projects in this way with good results -- certainly never encountering a wedged local repository in the process like this.
Update 2 OK, this is repeatable, even after starting with a completely fresh local repository. This is on OS X, Java 1.6.0_24 with Maven 3.0.3; note that Maven 2.2.1 does NOT exhibit this problem.
Here's one of the projects in question: the 1.3.0-compat branch of rummage. To reproduce:
> mvn clean test
# no error -- can run this and other builds that don't involve maven-invoker-plugin all day w/o problems
> mvn clean integration-test
# FAIL: "Could not resolve dependencies", with warnings as noted above
> mvn clean test
# FAIL: "Could not resolve dependencies", with warnings as noted above
Once the local repository is borked (by the generation of the maven-metadata-local.xml files, AFAICT), no builds will get past the dependency resolution stage.
Running mvn -X reveals lines like this for each artifact that is later apparently not found:
[DEBUG] Verifying availability of /Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.jar from []
Of course, /Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.jar et al. does exist, as does /Users/chas/.m2/repository/javax/mail/mail/1.4.4/mail-1.4.4.pom. Totally puzzled. At this point, I'm assuming this is a bug in Maven 3 (or some underlying library), now that I see that 2.2.1 is clean.
Update 3 Bug report filed with Maven project.
This issue is resolved in aether 1.12, one rev above the aether 1.11 library that ships with Maven 3.0.3. Replacing aether 1.11 with 1.12 in one's Maven install results in expected behaviour (as noted in the bug I filed). Here's hoping Maven 3.0.4 is released with aether 1.12 ASAP. :-)
you do not mention what you may have tried, so maybe you didn't try this one: adding the -U option to force update ? (tho maybe this -U option is only relevant for SNAPSHOTs ...)
I've seen similar errors caused by corrupted files in my local repository. For example, if a download failed partway through, or a file in a remote repository changed after I downloaded it. Deleting the affected directories under ~/.m2 fixed it.