I am trying to deploy signature files separately using deploy-file goal to Nexus staging repository, but I noticed that mvn deploy plugin removes the extension. My file is something like: azerty-0.1.jar.asc
but the file that gets deployed is: azerty-0.1.asc
I tried adding a classifier: -Dclassifier=jar
the file that gets deployed is: azerty-0.1-jar.asc
This seems like a strange behaviour.
Question: Any ideas how to work around it?
This is rather a normal behavior, Maven is using the file extension as artefact packaging, from maven-deploy-plugin, deploy-file, packaging option:
Type of the artifact to be deployed. Retrieved from the <packaging> element of the POM file if a POM file specified. Defaults to the file extension if it is not specified via command line or POM.
Note: bold is mine.
Moreover, the classifier option would indeed add an - between the version and the string provided as classifier: that's maven convention.
In your case you want to specify a special packaging, which would be jar.asc if you really want the remote file to have as extension jar.asc.
The following would hence work:
mvn deploy:deploy-file -Dfile=azerty-0.1.jar.asc -Dpackaging=jar.asc -DrepositoryId=your_id -Durl=http://your_repository -DgroupId=your_groupId -DartifactId=azerty -Dversion=0.1
Note the -Dpackaging=jar.asc which effectively tells Maven the file extension would be jar.asc.
As a general note, if you are using the repository as a build store, that would still be reasonable, otherwise in your case you would push to a Maven repository an artifact which would then be difficult (or rather weird) to import in a project.
If instead this is really an additional artifact of your project, you should look at the attach-artifact goal of the build-helper-maven-plugin, to effective define it as additional artifact, then Maven will automatically add it to its install and deploy phase.
Related
I have a zip file and a Nexus repo and I would like to know if it is possible to create a goal to upload the zip file in the repot root folder, without groupId and artifactId
my artifact is build by a pom.xml
It depends on the type of repository declared in your Nexus 3 instance.
For a Maven one, you need a GAV (group/artifactID/Version).
(NEXUS-5170 is illustrates that, even without a GAV, the GUI still proposes 'Add Artifact', but that is a bug)
In your case, as a workaround, you would create one "default/root" group dedicated to host those kind of artifacts: one group to host them all.
You can then use deploy:deploy-file, which, as you have seen, requires a GAV.
But if your artifact is built by a pom.xml (which does specify the GAV), a simple mvn deploy is enough (target deploy:deploy)
I've got one myPackage maven project, compiled and installed to local maven repository under
~/.m2/repository/mygroup/myPackage/1.0-SNAPSHOT/myPackage-1.0-SNAPSHOT.jar
In another maven project, I wish to use it, and in pom.xml I write <dependency> section for it. But I don't know how to write the "systemPath" for this jar:
I cannot use "~" to specify the path, because "~" is a *nix shell extention, java/maven cannot recognize it.
I cannot hard code like
/home/myself/.m2/...
It's not portable.
I cannot use ${project.basedir} because these 2 maven projects are under different folders. But I guess there should be some other maven environment variables that could indicate "home directory"?
All I wish to do is to get this "systemPath" done.
---------------Problem solved by using another project as dependency------------
<systemPath>${project.basedir}/../myPackage/pom.xml</systemPath>
That works!
A system path is required when the library that your project depends on is not in the maven local repository.
As a rule of thumb, this approach is indeed not portable at all and should be avoided for real projects.
Now, the dependency is in local repository if:
It was downloaded from some remote repository (usually)
You've installed it locally (in this case its in your local repository but might not be in your team-mate repo)
In order to install the dependency into the local repo consider using: mvn install:install-file+ parameters as written here
But from your question, it looks like the file is already there... Anyway once the file is in the local repository you can just define a "regular" dependency (group, artifact, version) and Maven will pick it, no need to fiddle with system Path in this case.
I would need to execute a specific Maven plugin from command line. For example, in the following I execute a specific version of Maven Surefire Plugin to test Java projects:
mvn org.apache.maven.plugins:maven-surefire-plugin:2.19-SNAPSHOT:test
However, the above assumes to find the surefire plugin 2.19 in the default Maven repository path. Now, my question is, if I want to use the plugin with a specific path (not Maven default one), what should I do using the command line? I would expect something like the following, without modifying pom.xml:
mvn /path/to/some/jar/version/org.apache.maven.plugins:maven-surefire-plugin:2.19-SNAPSHOT:test
or more generally, for the following invocation
mvn groupId:artifactId:version:goal
I would need somewhere to specify a customized path to execute its goal
mvn /some/path/to/groupId:artifactId:version:goal
On the other hand, please let me know if this is not even supported by Maven.
This is not how it works. Maven will always look-up artifacts inside your local repository. And if it can't find it in your local repository, it will try to download it from configured remote repositories.
As such, you don't specify a path to a plugin. You specify a path to a local repository, where that plugin is installed. In this local repository will be installed all the dependencies of the plugin you're trying to invoke. This also means that you cannot have a JAR to a plugin "sitting around" anywhere; it needs to be located inside a correct repository tree directory. With a local repository of /my/local/repo, the artifacts of the plugin groupId:artifactId:version must be located in /my/local/repo/groupId/artifactId/version and be named artifactId-version.jar (and .pom). In the same say, the location of the dependencies of that plugin must follow that directory structure.
By default, the local repository is located inside ~/.m2/repository. But you can change that by:
Specifying the maven.repo.local system property on the command line, for example with mvn -Dmaven.repo.local=/path/to/local/repo groupId:artifactId:version:goal;
Use a custom settings.xml and tell Maven to use it with the -s command line option. It would contain:
<settings>
<localRepository>/path/to/local/repo</localRepository>
</settings>
and be used with mvn -s /path/to/settings.xml groupId:artifactId:version:goal
My pom.xml has scm configuration as follows
<scm>
<url>${my.scm.url}</url>
</scm>
I have property file which I am reading using properties-maven-plugin which has the value of ${my.scm.url}, and also I am using buildnumber-maven-plugin to get latest revision from SVN.
The issue is buildnumber-maven-plugin throws invalid scm url error but, when i replace ${my.scm.url} with actual url to my svn repo , it works perfectly.
How can I achieve successful execution without having to hard code scm url ?
PS: I run build using : mvn clean install command.
The problem is probably due to the order that the plugins run. The following should work:
Bind the properties-maven-plugin to the initialize phase
AFTER that plugin configuration in the POM, add the buildnumber-maven-plugin plugin
AFTER the previous two, put the buildnumber-maven-plugin plugin (which by default bind to the initialize phase).
Now all 3 plugins should run in the correct order (you can check this from the logs). Alternatively you can bind the to different phases to ensure that they run in the correct order, but the above should be enough and conforms with the goal of the initialize phase (initialize build state, e.g. set properties or create directories).
Because you didn't post the POM file, I'm guessing a bit.
Obviously, the order is going to matter, you must get the properties loaded first. That said, looking at the mojo, I'm not sure setting properties is the equivalent of essentially setting a -D.
If you did a mvn -Dscm.url= clean install, then the value would be there because it's being defined to the mvn JVM. Depending at what point the ${scm.url} is being evaluated, if it's before the properties mojo has a chance to run, it's going to be too late.
If you use a CI tool (i.e. Jenkins, Hudson) that can load the properties before the mvn call, then the variable is defined.
I've used the buildNumber mojo for my builds, because I have buildNumbers automatically generated for my snapshot artifacts. The order things occurred:
property file is downloaded from Jenkins master to slave for this job
Jenkins plugin loads the properties file into the job
maven build starts, the build number is already defined before mvn is called (again, behaving like a -D) and my buildNumber is incorporated into my artifact version
buildNumber mojo causes the property file to have buildNumber incremented
property file copied back to Jenkins master
I also wanted to load the properties file within maven and have it "update" the artifact id on the fly, but by that point, Maven had already evaluated; hence, I had to do it beforehand.
Hope this helps.
I have copied the JARs into src\main\webapp\WEB-INF\lib.
I use eclipse. If I add the jars one-by-one to Project-> Java Build Path-> Add jars, then I do Project-> Maven-> Update Project Configuration, they are removed by Maven. And Eclipse shows errors, which contain " xxx cannot be resolved".
Env:
Eclipse Java EE IDE for Web Developers.
Version: Indigo Service Release 1
Build id: 20110916-0149
m2e - Maven Integration for Eclipse 1.0.100.20110804-1717
Note: I don't want to create my own Maven repository. It will be just used once.
How should I proceed ?
Not all libraries can be found in a public Maven repository, for example your own libraries or proprietary libraries. Anyway first you can search the Maven Repository, maybe some of them are there.
In case they are really not there, and you don't want to install Nexus or Artifactory, you can choose one of these two approaches:
install the jars in your local repository cache, no need to create a special repository. See the instructions on mkyong.
another approach is using system dependencies, you just put a path to reach the Jar in the filesystem. It's a less recommended approach, but if you really want it will work. Here is the official documentation.
Add this an a Systems Dependency.
In case you want to add this (this uses jquantlib as example) to the maven local repo use:
mvn install:install-file -Dfile=./jquantlib-0.2.4.jar -DgroupId=org.jquantlib -DartifactId=jquantlib -Dversion=0.2.4 -Dpackaging=jar
In order to do this I use a batch file
#echo off
cd lib
CMD /C "mvn install:install-file -Dfile=./jquantlib-0.2.4.jar -DgroupId=org.jquantlib -DartifactId=jquantlib -Dversion=0.2.4 -Dpackaging=jar"
CMD /C "mvn install:install-file -Dfile=./jquantlib-helpers-0.2.4.jar -DgroupId=org.jquantlib -DartifactId=jquantlib-helpers -Dversion=0.2.4 -Dpackaging=jar"
CMD /C "mvn install:install-file -Dfile=./jquantlib-samples-0.2.4-ubber.jar -DgroupId=org.jquantlib -DartifactId=jquantlib-ubber -Dversion=0.2.4 -Dpackaging=jar"
CMD /C "mvn install:install-file -Dfile=./jquantlib-samples-0.2.4.jar -DgroupId=org.jquantlib -DartifactId=jquantlib-samples -Dversion=0.2.4 -Dpackaging=jar"
CMD /C "mvn install:install-file -Dfile=./ta-lib-0.4.0.jar -DgroupId=com.tictactec -DartifactId=ta-lib -Dversion=0.4.0 -Dpackaging=jar"
You can use a similar script file on other systems.
I believe the system dependency approach shouldn't be used unless you don't have any other choice, and that's because you're loosing the whole 'build portability thing' here.
Of course you can store your jars in your source control system together with your project's source files, but I don't think its a good approach neither...
Using only install:install-file is not good enough - this would indeed deploy the jars in the proper format into your local repository, but what happens when you'll move to another computer and start to build your project there?
You will need to make this once more.
So, If you don't want to install nexus/artifactory (which is the best solution, I believe), you probably should create an another repository (just in a file system on some of your servers), and deploy the jars there (you can use mvn install:install-file as was suggested here, and then just copy the whole tree). Now you can configure apache web server and access the directory with all your jars via http. I don't believe its better then nexus/artifactory approach, but it can be a little be easier to do if you're familiar with apache web server.
In order to get your maven aware about this new repository you'll need to edit the %MAVEN_HOME%\conf\settings.xml file
There are atleast three approaches in which 3rd party JARs can be added to Maven projects.
Install manually using mvn install command
Adding the location of jar file in pom dependency with the the following tag system
Creating a 'dummy' maven repository pointing to jar location.
While approach 1 and 2 has been suggested above, I will focus on third approach which I find more cleaner and does not require any mvn command and works out of box from any IDE.
Step 1: Add the location of local 'dummy' repository in pom.xml
<repositories>
<repository>
<id>repo</id>
<name>repo</name>
<url>file:${project.basedir}/src/main/resources/lib</url>
</repository>
</repositories>
Here the 'dummy' repository location is the 'lib' folder of my project directory
Step 2 : Add the jar dependency into your pom.xml
<dependency>
<groupId>com.cloudera.impala</groupId>
<artifactId>impala-frontend</artifactId>
<version>0.1-SNAPSHOT</version>
</dependency>
choose any groupId but make sure that artifactId and version is of the format <artifactId>-<version>.jar ( Name of 3rd party jar)
Step 3 : Create the folder structure as per the groupId,artifactId and version mentioned in the Step 2 in your local 'dummy' repository. So in this case the folder struction would be /src/main/resources/lib/com/cloudera/impala/impala-frontend/0.1-SNAPSHOT/
Place your jar in the version folder and build your project.
You will get the following output which treats your 'dummy' repository to be the provider of your 3rd party jar.
[INFO] Downloading from repo: file:C:\Users\skumar\eclipse-workspace\chdQueryBuilder/src/main/resources/lib/com/cloudera/impala/impala-frontend/0.1-SNAPSHOT/maven-metadata.xml
[INFO] Downloading from repo: file:C:\Users\skumar\eclipse-workspace\chdQueryBuilder/src/main/resources/lib/com/cloudera/impala/impala-frontend/0.1-SNAPSHOT/impala-frontend-0.1-SNAPSHOT.pom
[WARNING] The POM for com.cloudera.impala:impala-frontend:jar:0.1-SNAPSHOT is missing, no dependency information available
[INFO] Downloading from repo: file:C:\Users\skumar\eclipse-workspace\chdQueryBuilder/src/main/resources/lib/com/cloudera/impala/impala-frontend/0.1-SNAPSHOT/impala-frontend-0.1-SNAPSHOT.jar
[WARNING] Could not validate integrity of download from file:C:\Users\skumar\eclipse-workspace\chdQueryBuilder/src/main/resources/lib/com/cloudera/impala/impala-frontend/0.1-SNAPSHOT/impala-frontend-0.1-SNAPSHOT.jar: Checksum validation failed, no checksums available
[WARNING] Checksum validation failed, no checksums available from repo for file:C:\Users\skumar\eclipse-workspace\chdQueryBuilder/src/main/resources/lib/com/cloudera/impala/impala-frontend/0.1-SNAPSHOT/impala-frontend-0.1-SNAPSHOT.jar
[INFO] Downloaded from repo: file:C:\Users\skumar\eclipse-workspace\chdQueryBuilder/src/main/resources/lib/com/cloudera/impala/impala-frontend/0.1-SNAPSHOT/impala-frontend-0.1-SNAPSHOT.jar (7.0 MB at 79 MB/s)
[INFO]
To add external JAR files not in the local repository simply right click on your main source folder and from the build path menu select: "configure build path", then navigate to the libraries tab and click "add external JAR files". next, locate the JAR (or zip) file you would like to add as a library and click ok.
Congratulations, you have now successfully added an external JAR (or zip) to your build path and you can now import any classes from that JAR file in your project without throwing an errorPicture How-To :) http://hostthenpost.org/uploads/541be8420657320c74489ff8d456ad08.png