I'm attempting to use the Grails Maven plugin to build a war file. There's a known problem with the plugin in that it does not resolve range dependencies, and my project pom file must contain range dependencies.
The dependency is specified like this:
<dependency>
<groupId>mygroup</groupId>
<artifactId>myartifact</artifactId>
<version>[0.0.0,999.999.999)</version>
</dependency>
The error message is like this:
[ERROR] Failed to execute goal
org.grails:grails-maven-plugin:2.2.1:clean (default-clean) on project
sdm: Failed to create classpath for Grails execution. Encountered
problems resolving dependencies of the executable in preparation for
its execution. Error resolving project artifact: Could not transfer
artifact mygroup.myartifact:pom:[0.0.0,999.999.999) from/to myRepo
(https://maven.mydomain/nexus/content/groups/myRepo):
IllegalArgumentException for project
mygroup.myartifact:pom:[0.0.0,999.999.999): Illegal character in path
at index 89:
https://maven.mydomain/nexus/content/groups/myRepo/mygroup/myartifact/[0.0.0,999.999.999)/myartifact-[0.0.0,999.999.999).pom
-> [Help 1]
As you can see, the range dependency is not being resolved, and a literal version "[0.0.0,999.999.999)" is being looked for.
To work around the problem, I can use the Maven version plugin and do this:
mvn versions:resolve-ranges [replaces range deps in pom file with actual versions]
mvn grails:war [builds war based on actual versions in newly modified pom file]
mvn versions:revert [reverts pom file to original state]
BUT here's my problem: if I combine these goals into one Maven command:
mvn versions:resolve-ranges grails:war versions:revert
the grails:war fails with the error I described above - it seems to be seeing the pom file in its initial state (with the range dependencies), even though the versions plugin has updated the pom file with actual version numbers. After the failure, the pom file has this:
<dependency>
<groupId>mygroup</groupId>
<artifactId>myartifact</artifactId>
<version>2.1.15</version>
</dependency>
So my question is - why does the second goal (grails:war) see the pom file as it was at the start of the whole chain of goals, not as it is when the goal runs? How can I make the second goal (grails:war) see the pom file as it stands after completion of the first goal (versions:resolve-ranges)?
Related
I am using maven 3.x.x and trying to use versions ranges in my pom.xml and it never worked. I tried version-ordering suggested by maven and getting the order as expected on my terminal. But when running maven compile, always getting error as below
Failed to execute goal on project test-client: Could not resolve dependencies for project com.abc.def:test-client:jar:0.0.1-SNAPSHOT: Failed to collect dependencies at development.com.abc.test:my-service:jar:jar:[1.0.211006-mr424,1.0.211014-mr427]: No versions available for development.com.abc.test:my-service:jar:jar:[1.0.211006-mr424,1.0.211014-mr427] within specified range -> [Help 1]
But if I use the fixed version in my pom.xml, things start working.
my pom.xml:
<dependency>
<groupId>development.com.abc.test</groupId>
<artifactId>my-service</artifactId>
<version>[1.0.211006-mr424, 1.0.211014-mr427]</version>
<classifier>jar</classifier>
</dependency>
PS : the artifact uploaded for my-service does not contain maven-metadata.xml in the repository.
The end goal I am trying to achieve is to resolve dynamic dependencies
In my Maven project, I am trying to make a release, but for now I don't want to deploy it anywhere(I will do that later).
I would like the JAR file or whatever is generated because of the release to remain on my local machine, without being deployed anywhere.
I am running this:
mvn release:prepare
mvn release:perform
The problem is that on the second line I am getting this error:
[INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project my-project: Deployment failed: repository element was not specified in the POM inside distributionManagement element or in -DaltDeploymentRepository=id::layout::url parameter -> [Help 1]
What is this about?
I don't have any distributionManagement tag in my project and if I would have one, I wouldn't know what to do with it.
You have 2 options:
set the value for the goals parameter of the maven-release-plugin to install
if you never want to deploy to a remote repository, set the skip parameter of the maven-deploy-plugin to true.
Add this to the code:
<properties>
<maven.deploy.skip>true</maven.deploy.skip>
</properties>
I'm trying to check a zip file (created by an external process) into Nexus using mvn deploy:deploy-file.
When I run from the command line (Win), everything works and I can see the pom and zip in my snapshot repo. However If I use a maven job in Jenkins to do the same I'm getting the following error :
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[ERROR] Unknown packaging: zip # line 6, column 13
pom looks like :
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.test.app</groupId>
<artifactId>testApp</artifactId>
<version>1.0.0.0-SNAPSHOT</version>
<packaging>zip</packaging>
</project>
mvn command is :
mvn deploy:deploy-file -DpomFile=d:\testApp.pom -Dfile=d:\testapp.zip
-DrepositoryId=snapshots
-Durl=http://localhost:8081/nexus/content/repositories/snapshots
If I was using the wrong packaging, why does it work for one and not the other ?
This page describes the <packaging> tag: http://maven.apache.org/pom.html#Maven_Coordinates
It says, and I quote:
The current core packaging values are: pom, jar, maven-plugin, ejb, war, ear, rar, par.
Additional plugins can add additional packaging types when they modify the lifecycle.
This information applies to the tag in the pom.
Possible solution: If you comment out or remove the <packaging>zip</packaging> it will stop failing with an error message.
This means when you can use the command with one more -D option
mvn deploy:deploy-file ... -Dfile=somefile.zip -Dpackaging=zip
to publish a file to a maven repository like Nexus or Artifactory. Maven will not complain because its only checking the tag for validity.
However, if you are doing anything else with Maven and that anything requires you to set the packaging type, you will need to find another solution.
Problem: make module fails because intellij fails to bring the dependencies of a snaphot dependency. Building the module through maven works fine while it fails when trying to build it through make module.
When looking on the iml file, only the snapshot dependency exists but not the internal dependencies.
The local repository contains the jar and the pom file of the dependency.
In the main pom:
<dependency>
<groupId>com.aa.bb</groupId>
<artifactId>myArtifact-dev</artifactId>
<version>6.3.00-SNAPSHOT</version>
<\dependency>
This dependency exists in the local repository. The iml file does not contanis the dependencies listed in the pom file of this dependency.
I make reimport from the pom file but it doesn't help.
Any idea?
I was able to resolve the problem by:
mvn -X -U idea:idea
This way I was able to see why it failed to parse the pom file and fix the problem in the pom file.
I have a Maven project that so far used to compile without problems. Today, when I run mvn clean package -U, I get:
[ERROR] Failed to execute goal on project myproj: Could not resolve dependencies for project org.myorg.myproj:myproj:jar:1.0-SNAPSHOT: The following artifacts could not be resolved: javax.servlet:javax.servlet-api:src:sources:3.0.1, org.eclipse.jetty:jetty-servlet:src:sources:8.1.2.v20120308, org.eclipse.jetty:jetty-server:src:sources:8.1.2.v20120308, org.eclipse.jetty:jetty-webapp:src:sources:8.1.2.v20120308, commons-io:commons-io:src:sources:2.4: Could not find artifact javax.servlet:javax.servlet-api:src:sources:3.0.1 in MyRepo (http://maven.myorg.org:9001/nexus/content/repositories/myrepo/) -> [Help 1]
I tried to with a fresh local Maven repository (rm -fr ~/.m2/repository) but that did not make any difference.
Why does Maven try to find source/src artefacts? Any ideas where the problem might lie?
Edit: My dependencies (as seen using mvn help:effective-pom) do not have any source classifiers. For example, the dependency on the jetty-server mentioned in the error message reads as follows:
<dependency>
<groupId>org.eclipse.jetty</groupId>
<artifactId>jetty-server</artifactId>
<version>8.1.2.v20120308</version>
<scope>compile</scope>
</dependency>
Solution: With the help of #AlessandroSantini and #brian-topping, I finally identified the problem. One of my indirect dependencies had a <classifier>sources</classifier> and <type>src</type>. (mvn help:effective-pom did not show these indirect dependencies, and mvn dependency:tree failed with the above error message, too; eventually, a grep -r 'jetty-server' ~/.m2/repository/ -C 3 identified the artifact with the messed up dependency.)
It turned out that one of my own SBT projects required the (non-existing) source artifacts for one of its dependencies: I used SBT's withSources() where I should have used sbteclipe's EclipseKeys.withSource := true to get the sources in Eclipse.
Do you have any dependencies on public snapshots? I'd take a look at the output of mvn dependency:tree and see if you can find a transitive dependency that is including the sources somehow. Maybe one of the transitives have changed since your last build and they messed something up.