I am unable to edit pom.xml. Is there a way to define final name of the maven artifact built by Hudson, something like this
<finalName>${project.artifactId}-${project.version}-${timestamp}</finalName>
Since mvn -DfinalName="xxx" on command line does not seem to work.
I am looking for Hudon/Jenkins feature to achieve this as well, or modifying settings.xml in maven repo. Basically any method except editing pom.xml
First, you could have a second build step (execute shell or windows batch) to simply rename the artifacts. Obviously, this will forego the automatic maven module artifacting, but are you using that? If not, just archive the file with post-build actions directly on Jenkins or repository of choice.
Second, the moment you check out the files from SVN, you do have access to modify them in your local workspace. Just don't commit them back to repository.
You could run a regex replace to look for <fileName>.*</filename> and replace with whatever you want.
Related
I am trying to implement a staged CI/CD pipeline with a Gradle library. I have managed to get Gradle publishing the produced library to a local Maven repository (build/repository). What I'd like to do then is manually 'promote' the artifact in this local repository to a remote one. A different remote one for each stage in the build pipeline.
And I don't want that logic to be part of Gradle. What I'd like is a way to simply run a Maven command (mvn) to copy the artifact in build/repository to http://myrepositoryurl. I've found Maven copy:stage. However, it fails with some exception about missing implementation for org.apache.maven.plugins.stage.RepositoryCopier.
Problem is I know nothing about Maven, and don't know what this means. It recognizes 'copy', as it is trying to Do Something, and has figured out that RepositoryCopier at least is the thing it needs. But it won't work.
What do I need to do to get this to work?
AFAIK there is not Maven command to copy from a local repository to a remote one.
Maven deploys files from the target directory to remote repositories.
We're building feature branches into a version 'feature_'. Each feature build will produce the same version. Since these are no releases, I want to deploy the artefacts into the Snapshots repo, but Nexus does not allow versions without 'SNAPSHOT' into the Snapshot repo.
How to configure Nexus to allow any version in a repo?
Solved it by appending '-SNAPSHOT' to the branch version.
It's quite tricky to get Maven in Jenkins to use the right version. The way I solved it now is like this. In the build job configure Git to build the branches origin/feature/*. Then:
In the 'build' section, first thing to do is execute a shell command to construct a file 'env.properties' containing the feature branch version to be used by the Maven build command.
echo BRANCH_VERSION="feature_${GIT_BRANCH##*/}-SNAPSHOT" > env.properties
This uses the GIT_BRANCH environment property of Jenkins. The '##*/' is a Bash Shell Parameter Expansion which strips everything from the parameter value except the part after the last '/' character.
Then use the Environment Injector Plugin to 'inject environment variables' to the build job using the 'env.properties' created in the previous step.
Put 'env.properties' in the 'Properties File Path' field.
Use Maven to build a versioned pom with the correct version using 'Invoke top-level Maven targets':
help:effective-pom -Dbuild.number=${BRANCH_VERSION} -Doutput=versioned-pom.xml. This step is necessary because otherwise the pom in the jar artefact does not contain the correct version causing other problems.
Use another 'Invoke top-level Maven targets' step to do the actual build and deploy using the pom version created in the previous step: -f versioned-pom.xml clean source:jar deploy
That's all folks. If anyone knows a simpler solution, let me know.
This is actually a Maven restriction. You can still use version like feature_x-1.2.3-SNAPSHOT though.
What are you actually trying to achieve though?
I use the git-describe maven plugin to replace the POMs <version>${describe}</version> placeholder. mvn deploy needs a custom parameter passed in order for it to properly use the actual git describe value.
I'm now using Jenkins to build the project every time we push to the repo however it too doesn't properly use the actual git-describe value.
The jenkins build artifacts always end named project-${describe}
Are there any suggestions on ways I can customize the file names or force it to use the git-describe result? Otherwise I may be back to manual versioning...
The version property does not allow variable substitution. The first link I found googling this was this SO question.
You'll have to use one of the versioning maven plugins. The maven release plugin is the most popular, but you might find that the versions maven plugin better meets your requirements.
We do not have our own repository at the moment. So, when we build with maven it creates .m2 repository in the home directory of the current user.
Now there are two third party jars which are not found in the Maven Central. Suppose one of them is hasp-srm-api.jar. Today the process is this:
a. The pom.xml of the project depending on hasp-srm-api.jar contain these lines:
<dependency>
<groupId>com.safenet</groupId>
<artifactId>hasp</artifactId>
<version>1</version>
</dependency>
b. Before doing the first build we execute the following command:
mvn install:install-file -Dfile=hasp-srm-api.jar -DgroupId=com.safenet -DartifactId=hasp -Dversion=1 -Dpackaging=jar
My question is this - is it possible to automate this step? I would like to be able to tell maven to check whether the hasp artifact exists and if not - install it manually using the aforementioned command line. How can I do it?
NO. It is not possible to have maven automatically deploy an artifact into a repository in the fashion you suggest. This goes for both local and remote repositories. If the artifact exists in a some repository somewhere, you can add that repository to your build's list of known remote repos, but other than that you have to add it yourself.
You can add it to your local .m2 repository, but that will then only be good for that individual environment. Other dev's will have to repeat the process. This is one of the main attractions of running your own repository server( like Nexus ); you can add the artifact to that repository and then everyone in your organization can use it forever. There is still no way to automate the deployment of the artifact, but it's easy to do and is permanent.
Note, setting up a repository manager is very easy to do. It's highly recommended. It makes the whole Maven thing make a whole lot more sense.
The best solution for such problems is using a repository manager which results in installing such kind of dependencies only once into the repository manager and the whole company can use it a usual dependency. That's it.
Other option you have is to write your own maven plugin. May be below link will be right place for you start
MOJO FAQ
I'm about to write a tool with which our developers can checkout sources for an artifact given its maven coordinates. The tool should be able to optionally checkout sources recursively for all SNAPSHOT dependencies as well.
My first question would be: Do I need to write this tool at all? One would imagine that this isn't a very unique user scenario, but I have yet failed to find something suitable to achieve this. I have looked at scm:checkout and scm:bootstrap, both require knowledge about the connection url where as I only have a artifactID. Is there any other way, but to write a custom tool, to do this?
If not, my home brew tool would do something in the lines of:
Parse .m2/settings.xml to determine which repo to use Download the pom for the artefact.
Create a temporary bootstrap-pom with the scm-tag from the downloaded pom.
Use scm:bootstrap and the bootstrap-pom to checkout sources.
[Optionally] Search the sources for poms with SNAPSHOT dependencies and repeat the process.
My second question would be: Does this sound like a good way to go about it to you? Any caveats spring to mind?
For each project you want to checkout this way, you could add a profile containing plugin configuration for the scm plugin's bootstrap goal. The plugin config would be in the same POM as the scm URL, so that handles #2 & 3; you wouldn't need a separate bootstrap-pom.
For getting the initial POM, you could use dependency:get from the command line:
mvn dependency:get -Dartifact=some.group:my.artifact:version:pom -Ddestination=someDirectory
In the directory with the downloaded POM, you perform the bootstrap:
mvn -Pbootstrap-profile-id scm:bootstrap
which would check out the top level project.
I don't know how you'd make this recursive. You might be able to use dependency:copy-dependencies asking for transitive dependencies and copying POMs, and then running the bootstrap process on each of those. Not sure how that would work.
The solution of user944849 doesn't work for me, but here is an example that works
mvn dependency:get -Dartifact=ar.com.hjg:pngj:2.1.0:pom -Ddest=pom.xml
mvn scm:bootstrap -Dgoals=validate
mv target/checkout ~/projects/pngj