I try to include the git commit hash in the artifact name to distinguish between Snapshot-Versions in an CI scenario.
The git hash is successfully included in the target/ folder of my project, but in the last maven step it copies the artifact into my HOME/.m2/repositories folder and changes the name to ARTIFACTID-VERSION-mta.jar.
How can I keep the file name from the target/ folder that includes the commit hash?
I had a look at the maven-install-plugin, but couldn't find a "finalName" property or something like this.
[INFO] --- maven-install-plugin:2.5.2:install (default-install) # projectname ---
[INFO] Installing PROJECTDIR/pom.xml to ~/.m2/repository/GroupIdDir/projectname/1.0.1/projectname-1.0.1.pom
[INFO] Installing PROJECTDIR/target/projectname-1.0.1-d054c42-mta.jar to ~/.m2/repository/GroupIdDir/projectname/1.0.1/projectname-1.0.1-mta.jar
I would like the last line to be
[INFO] Installing PROJECTDIR/target/projectname-1.0.1-d054c42-mta.jar to ~/.m2/repository/GroupIdDir/projectname/1.0.1/projectname-1.0.1-d054c42-mta.jar
Controlling maven final name of jar artifact
does not solve the problem because it modifies the output folder.
it is probrably because of repository layout.
Repository Layout Definition
This is the final layout for the repository available in Maven 2.x and
its related Ant tasks.
For primary artifacts:
/$groupId[0]/../${groupId[n]/$artifactId/$version/$artifactId-$version.$extension
For secondary artifacts:
/$groupId[0]/../$groupId[n]/$artifactId/$version/$artifactId-$version-$classifier.$extension
See https://cwiki.apache.org/confluence/display/MAVENOLD/Repository+Layout+-+Final
Related
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
I am trying to publish some of my SBT projects on my personal webserver. As far as I know you usually export a SBT project as a Maven directory including a POM.xml, that contains the project definitions.
As Brian Clapper pointed out, you can publish such a Maven repository by creating several configuration files and using sbt publish. In his tutorial, the repository is transferred via FTP.
I want to push my Maven repository to the server manually so I have more control. Can you give me some hints, how to accomplish this?
I figured out how you can do this. This solution creates a local Ivy repository, which is compatible with Maven.
You have to set the following values in your build.sbt:
name := "project-name"
organization := "org.example"
version := "0.0.0"
scalaVersion := "2.9.2"
publishTo := Some(Resolver.file("file", new File("/path/to/your/releases"))
After that, you can publish your release
sbt publish
This will print something like the following lines
[info] Set current project to project-name (in build file:/path/to/your/project/)
[info] Updating {file:/path/to/your/project/}default-2e51ea...
[info] Packaging /path/to/your/project/target/scala-2.9.2/project-name_2.9.2-0.0.0-S
NAPSHOT-sources.jar ...
[info] Resolving org.scala-lang#scala-library;2.9.2 ...
[info] Done packaging.
[info] Done updating.
[info] :: delivering :: org.example#project-name_2.9.2;0.0.0 :: 0.0.0 :: release :: Tue Jul 24 15:41:04 CEST 2012
[info] delivering ivy file to /path/to/your/project/target/scala-2.9.2/ivy-0.0.0.xml
[info] Wrote /path/to/your/project/target/scala-2.9.2/project-name_2.9.2-0.0.0.pom
[info] Packaging /path/to/your/project/target/scala-2.9.2/project-name_2.9.2-0.0.0.jar ...
[info] Done packaging.
[info] published project-name_2.9.2 to /path/to/your/releases/org/example/project-name_2.9.2/0.0.0-SNAPSHOT/project-name_2.9.2-0.0.0.pom
[info] published project-name_2.9.2 to /path/to/your/releases/org/example/project-name_2.9.2/0.0.0-SNAPSHOT/project-name_2.9.2-0.0.0.jar
[info] published project-name_2.9.2 to /path/to/your/releases/org/example/project-name_2.9.2/0.0.0-SNAPSHOT/project-name_2.9.2-0.0.0-sources.jar
[info] published project-name_2.9.2 to /path/to/your/releases/org/example/project-name_2.9.2/0.0.0-SNAPSHOT/project-name_2.9.2-0.0.0-javadoc.jar
[success] Total time: 1 s, completed 24.07.2012 15:41:05
You can put the generated files on any web server (e.g. http://repo.example.org/) and use it in the build script of another project by adding the following lines to your build.sbt:
resolvers += "Personal repository" at "http://repo.example.org/"
libraryDependencies += "org.example" % "project-name" % "0.0.0"
For more information, see SBT: Getting Started Library Dependencies and SBT: Publishing.
From sbt, you can use
project myproject
[myproject] $ publish-local
Which will publish to your local ivy directory (usually ~/.ivy2/local).
In the output you will see the paths of all the files:
[info] Done packaging.
[info] published myproject_2.9.1 to .../ivy2/...myproject.../poms/myproject_2.9.1.pom
[info] published myproject_2.9.1 to .../ivy2/...myproject.../jars/myproject_2.9.1.jar
[info] published myproject_2.9.1 to .../ivy2/...myproject.../srcs/myproject_2.9.1-sources.jar
[info] published myproject_2.9.1 to .../ivy2/...myproject.../docs/myproject_2.9.1-javadoc.jar
[info] published ivy to .../ivy2/...myproject.../ivys/ivy.xml
Then you can grab those files and upload them to your ftp server.
I would still recommend the approach described in the linked blogpost though. At least that's how we do it. Just a small note on storing credentials. Use the following sbt setting:
val credentials = Credentials(Path.userHome / ".ivy2" / ".my-credentials")
The credentials file will look like this:
realm=Sonatype Nexus Repository Manager
host=nexus.example.com
user=deployment
password=pass
The credentials are the same you use for logging in to the Nexus web interface.
I'm trying to purge the local repository of a project dependency before launching releasing it in order to make sure every dependency required is on the central repository and is downloaded from it.
In the project folder (containing the pom.xml), I launch the following command:
mvn clean dependency:purge-local-repository -DreResolve=false -Dverbose=true
The project's POM is very simple and just have a declared dependency to junit:junit:3.8.1
The command's output give me:
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building corelib-api 0.1.2-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-clean-plugin:2.4.1:clean (default-clean) # corelib-api ---
[INFO] Deleting d:\Users\fpaillard\git-repositories\TEST_CORELIB\corelib-api\target
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building corelib-api 0.1.2-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.1:purge-local-repository (default-cli) # corelib-api ---
[WARNING] Missing POM for junit:junit:jar:3.8.1
[INFO] Skipping: corelib-api. It cannot be resolved.
[INFO] Nothing to do for project: test:corelib-api:jar:0.1.2-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 0.953s
[INFO] Finished at: Mon May 14 11:34:40 CEST 2012
[INFO] Final Memory: 6M/15M
[INFO] ------------------------------------------------------------------------
When I look in the local repository (path checked with mvn help:effetive-settings), junit JARs nor POMs are still in .m2/repository/junit/junit/3.8.1 folder.
Isn't dependency:purge-local-repository supposed to delete it?
I don't understand the WARNING of the output above. Why is junit:junit:jar:3.8.1 POM missing? It is still present at .m2/repository/junit/junit/3.8.1/junit-3.8.1.pom
Is the problem related to the INFO line Skipping: corelib-api. It cannot be resolved.? corelib-api is the artifact name of the project I ran mvn dependency:purge-local-repository against.
I know this is old, but I had the same issue, and adding -DactTransitively=false to the command line fixed this issue. I'm unable to tell why it helped, but it did...
I hope this helps.
Looking at the documentation, disabling the actTransitively option causes the purge goal to only purge the dependencies that are named directly by your pom.xml. When it is time for the build, Maven automatically pulls not only your direct dependencies, but all of the TRANSITIVE dependencies down into your local repo as well.
When the purge goal is looking for what to delete, if it finds other dependencies in the dependencies' poms, it transverses those dependencies to figure out the entire tree in your local repository that can be purged. To do this, it at least needs the transitive project's pom.xml. If it cannot find it in the local repo, or if it thinks there might be a more recent version to analyze, it will go to the external repositories to find it.
I don't think it actually tries to download full project content before it starts purging. But since it at least pulls down the projects' pom.xml files, it will complain if it can't find one just like it would if it were resolving dependencies for an actual build.
Besides just preventing Maven from accessing external repositories while purging, another practical reason would be if you have two projects that have the same transitive dependency, and you don't want the purge from one to affect the performance of the other (since the latter will have to download any missing dependencies again).
On the other hand, something to carefully consider is that if you do NOT allow the purge to consider all of the transitive dependencies possible, you stand to leave a set of downstream dependencies sitting in your local repository that you would otherwise have wanted to remove.
I could make a case for saying that the output you are getting is either unnecessary or preventable with another flag like "reportInaccessibleDependencies=false". But unless it is killing your build, I wouldn't say it is anything to worry about.
I am trying to download a specific artifact (and all of its dependencies) to a machine's local repository.
It would seem that using the dependency:get goal would be the best option for this, but despite the documentation it does not seem to actually get the transitive dependencies.
Here is an example where I have tried to use dependency:get to download the spring-core jar and all of its many dependencies. You'll notice that the spring-core jar is the only thing downloaded despite the fact that this was done after cleaning the local repository.
$ mvn org.apache.maven.plugins:maven-dependency-plugin:2.2:get -DrepoUrl=http://repo1.maven.org/maven2/ -Dartifact=org.springframework:spring-core:3.0.5.RELEASE -Dtransitive=true
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] --- maven-dependency-plugin:2.2:get (default-cli) # standalone-pom ---
Downloading: http://repo1.maven.org/maven2/org/springframework/spring-core/3.0.5.RELEASE/spring-core-3.0.5.RELEASE.jar
Downloaded: http://repo1.maven.org/maven2/org/springframework/spring-core/3.0.5.RELEASE/spring-core-3.0.5.RELEASE.jar (374 KB at 548.4 KB/sec)
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.401s
[INFO] Finished at: Wed May 25 00:29:47 CDT 2011
[INFO] Final Memory: 7M/107M
[INFO] ------------------------------------------------------------------------
My questions are:
Is this a bug with the dependency:get goal?
If not, what am I doing wrong?
Are there any alternatives methods I could use to accomplish my initially stated goal?
If this is a one time or irregular occurrence for you, The simplest thing to do would be to define the dependency in a POM and run mvn package or similar to retrieve the dependency artifacts. You could also try mvn dependency:sources if you'd like to have the source jars too.
If this is something you want to do more regularly or as part of a process, you could look at using Aether directly to retrieve the dependencies for you.
Another approach if this is something you need to do regularly to manage groups of artifacts into your internal development ecosystem is to use Nexus' procurement suite to retrieve the dependencies and manage them into your repository.
You might can go with this solution
1) Download the artifact as you described (I tested with version 2.5.2)
c:\test>mvn -DrepoUrl=http://repo1.maven.org/maven2/ -Dartifact=org.springframework:spring-core:2.5.2 -Dtransitive=true
2) Download the pom (-Dpackaging=pom) of this artifact
c:\test>mvn -DrepoUrl=http://repo1.maven.org/maven2/ -Dartifact=org.springframework:spring-core:2.5.2 -Dtransitive=true -Dpackaging=pom org.apache.maven.plugins:maven-dependency-plugin:2.2:get
3) Use the downloaded pom to copy all dependencies via the dependency:copy-dependency gaol
c:\test>mvn -DoutputDirectory=C:/test/dependency -f C:/<path-to-repository>/org/springframework/spring-core/2.5.2/spring-core-2.5.2.pom dependency:copy-dependencies
You will find the dependencies (including test and optional scope!) in the created c:\test\dependency folder. To exclude test and optional scope use -DincludeScope=runtime.
You need to dynamically build some path information (e.g. path to the pom in your repository) to set up this solution and also need to bring the artifact itself together with its dependencies but it should work in a script without generating a special pom (which might be easier).
It would appear the answer to question #1 (Is this a bug with the dependency:get goal?) is yes. As of 5/25/2011 issue MDEP-308 is still unresolved.
I try to develop one jenkins (a.k.a hudson) plugin, and follow the Tutorial, and generated source code tree after mvn -cpu hpi:create command.
While when I do "mvn package", it reports error like
[INFO] Building Unnamed - com.example.jenkins:redmine2:hpi:1.0-SNAPSHOT
[INFO] task-segment: [clean]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).
Project ID: org.apache.maven.plugins:maven-enforcer-plugin
Reason: Error getting POM for 'org.apache.maven.plugins:maven-enforcer-plugin' from the repository: Failed to resolve artifact, possibly due to a repository list that is not appropriately equipped for this artifact's metadata.
org.apache.maven.plugins:maven-enforcer-plugin:pom:1.1-SNAPSHOT
from the specified remote repositories:
nexus (http://maven.nexus.local:8888/nexus/content/groups/public)
for project org.apache.maven.plugins:maven-enforcer-plugin
From my nexus server, it has maven-enforcer-plugin:1.0 version only, but this dependence is generated from jenkins by default, anyone can help me to solve it ?
(How) Can I change to plugin-1.0 version.
what can I add in nexus server
I just have basic knowledge of maven.
I fixed it by myself by doing two things.
1. Added Apache snapshot from here into my nexus repo group besides those setting in Tutorial
2. It seems my local maven repo is messed up as well, so I can clean it up and reload from nexus.
And it still use maven-enforcer-plugin:pom:1.1-SNAPSHOT plugins.
Hope it helps you as well.