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.
Related
For some reason I'm struggling wih the following and looking at all the examples on the web are not helping with my use case. I'm at the end of a very complex and odd build cycle with delivers a zip file to my desktop which contains a number of components.
I don't have any control on the creation of the zip file.
I'd like to upload this zip file into Nexus, partly for storage and for release control.
I'm trying to use mvn deploy:deploy-file but when i try to use
zip in my pom file I get the following error :
[ERROR] Unknown packaging: zip # line 6, column 13
A lot of the example suggest using
pom within the pom file, which doesn't error but doesn't upload the zip file.
Command Line I'm using is :
D:\tmp3>mvn deploy:deploy-file -Durl=http://localhost:8081/nexus/content/repositories/snapshots
-DrepositoryId=snapshots
-Dfile=d:\tmp3\test.zip
-DpomFile=pom.xml
Pom file is as simple as I could make it :
<project>
<modelVersion>4.0.0</modelVersion>
<groupId>com.test.app</groupId>
<artifactId>testzip</artifactId>
<version>1.0.0.0-SNAPSHOT</version>
<packaging>zip</packaging>
</project>
If I ignore using a pom file and specify the groupID etc as part of the commandline it works.
D:\tmp3>mvn deploy:deploy-file -Durl=http://localhost:8081/nexus/content/repositories/snapshots -DrepositoryId=snapshots -Dfile=d:\tmp3\test.zip
-DgroupId=com.test.app -DartifactId=testzip -Dversion=1.0.0.0-SNAPSHOT
If I remove the packaging tag from the pom, it works, but uploads the zip as a jar !
Eventually I'll need to bubble this up into Jenkins, but for now I'll be happy to get it to work from the command line.
Any ideas ?
Zip files are often deployed as jar into the Nexus. Javadoc and Sources are not really jars as well, but handled as such. Technically, a jar is a zip file anyway.
You can try to deploy it with -Dpackaging=zip over the command line or you just deploy it as jar.
Running into a small problem. I have a spring-maven project. And there are some external jars I need to add into the POM which I did using .
Now to build the WAR file we are using an Ant Maven task i.e. artifact:mvn providing the argument war:war.
Here somehow my external jars are not getting added to the WAR file i.e. WEB-INF/lib
Can some one please let me know if I am missing something. Below is my pom entry
<dependency>
<groupId>{test}</groupId>
<artifactId>Test</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${project.basedir}/lib/test.jar</systemPath>
</dependency>
Best solution is to start using a repository manager (a.k.a "Maven proxy server") and install the needed artifacts (test.jar) into the repository manager and use it as a usual dependency instead of using system scope via systemPath.
Calling mvn war:war via Ant does not make sense and shows you should learn how Maven works.
Change the packaging type in your pom file to war and you can simply call maven via:
mvn clean package
and everything should work. But this is only gues cause you didn't show your full pom file.
Install the test.jar locally using mvn install:install-file (docs). Now you can remove the system scope (and the systemPath) and everything will work out of the box.
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)?
I don't have a Maven project. What I have is a jar with the pom.xml embedded in the file. When I deploy this via the Artifactory GUI, Artifactory finds the pom and deploys it with the jar. It even recognizes the groupId, artifactId, and version.
When I try using mvn deploy:deploy-file it fails. If I extract the pom, and run mvn deploy:deploy-file with the -DpomFile=pom.xml, it works. Is there a way of deploying this jar with the embedded pom via the Maven command line? Or, do I need to extract the pom.xml first?
I have not heard of the possibility to specify the pom file from archive. I think it is unlikely to be an option, because Maven itself is just a light-weight program, which runs with plugins; and it needs some configurations to run with; and all references to plugins to be used are in those files.
Consider writing an Ant script that will extract the file, run mvn deploy:deploy-file -DpomFile=pom.xml and then delete the file.
The solution looks not very nice, I know, but it should help.
This is an Artifactory feature and not standard Maven behaviour.
Keep in mind that, for example, if you use dependency:unpack-dependencies or the assembly plugin to create some sort of über jar there would be multiple pom.xml files within the jar under the /META-INF/ path so it would be very difficult to select which pom was the true pom.
The maven configuration mentioned in the Usage section of the Natural Docs Maven Plugin site:
<groupId>org.codehaus.mojo.naturaldocs</groupId>
<artifactId>naturaldocs-maven-plugin</artifactId>
<version>1.0-SNAPSHOT</version>
However; I can't seem to find any version in any Maven repository including Maven Central or the Snapshot repo.
I was able to find what seems like the initial version attached to this Mojo plugin submission but it only includes source, and while it's nice to look at I don't wish to compile it for use myself.
Grab the source archive that you referenced and unzip it in a convenient spot.
From that folder, run:
mvn clean install
Assuming that runs without issue, run:
mvn install:install-file -Dpackaging=jar -Dfile=target\naturaldocs-maven-plugin-1.0-SNAPSHOT.jar -DgroupId=org.codehaus.mojo.naturaldocs -DartifactId=naturaldocs-maven-plugin -Dversion=1.0-SNAPSHOT
Assuming that runs fine, check the local deploy works as expected by including the pom reference in your project.
<dependency>
<groupId>org.codehaus.mojo.naturaldocs</groupId>
<artifactId>naturaldocs-maven-plugin</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
If your project build without issue, then deploy it to your local Maven repo by running:
mvn deploy:deploy-file -Dpackaging=jar-Drepository=extNonFree -Durl=scpexe://maven.your-company.com/your-serverpath/maven/proximity/ext-non-free/storage -Dfile=target\naturaldocs-maven-plugin-1.0-SNAPSHOT.jar -DgroupId=org.codehaus.mojo.naturaldocs -DartifactId=naturaldocs-maven-plugin -Dversion=1.0-SNAPSHOT
Or have one of your local Maven admins deploy the pom and jar manually.
I hope that helps.