I'm building Maven projects via TeamCity/Git and trying to insert the TeamCity build numbers in the pom.xml that gets published to my repository upon a successful build. Unfortunately I can't determine how to publish a pom.xml with the substitutions inserted.
My pom.xml contains info like:
<version>${build.number}</version>
where build.number is provided by TeamCity. That all builds ok, and if (say) build.number = 0.1, then the deployment is a pom.xml to a directory with 0.1. All well and good.
However, the pom.xml that is deployed is the pom.xml without the substitutions made. i.e. Maven is running with a pom.xml with appropriate substitutions, but deploys the initial version and so I get
<version>${build.number}</version>
in the final pom.xml. How can I get the build version number in the pom.xml ?
I wouldn't use this approach because it makes building a project checked out from the SCM not possible without providing the build.number property. I don't think that this is a good thing. Maybe I'm missing something though.
Actually, I don't get what you are trying to achieve exactly (why don't you write the build number in the manifest for example). But, according to the Maven Features on the Teamcity website:
By default, it also keeps TeamCity build number in sync with the Maven version number (...).
Couldn't that be helpful? There is another thread about this here.
Try to use generateReleasePoms property of maven-realease-plugin, maybe that helps a little.
Related
(This question is asked on Maven User mailing list too)
I have recently faced a strange problem, that I cannot even able to judge the cause or source of problem. It will be great if someone can give me some direction:
(The story may be a bit long)
I am using Nexus 1.8.0 as our company's repository manager. I use it as proxy of external repo, and hosting our own repository.
There are many repositories in Nexus. I have one repository group (let's call it PUBLIC) which groups all public repositories, including maven central, codehaus etc.
There is another repository group (let's call it EXT) which we put 3rd party artifacts.
In our project, we used org.codehaus.mojo:native2ascii-maven-plugin.
Due to a bug at that time, instead of using the publicly available org.codehaus.mojo:native2ascii-maven-plugin:1.0-alpha-1, I have fixed the bug and deploy it to our EXT repository, and called it org.codehaus.mojo:native2ascii-maven-plugin:1.0-alpha-1.1 (i.e. used a new version number 1.0-alpha-1.1 instead of 1.0-alpha-1)
This have been running fine for several years.
However recently a new developer tries to get the code and build, using Maven 2.2.1. Strange things happened: the build failed. By inspecting result of mvn -X clean install, it states that POM of native2ascii-maven-plugin:1.0-alpha-1.1 cannot be downloaded from PUBLIC, therefore it will use a default emtpy POM, which cause the build problem.
By inspecting the local repository, I found that only the JAR of native2ascii-maven-plugin:1.0-alpha-1.1 was downloaded. I am sure that there is no native2ascii-maven-plugin:1.0-alpha-1.1 in PUBLIC repository, and the SHA of the JAR matches with native2ascii-maven-plugin:1.0-alpha-1.1 in EXT. It seems that, Maven is capable to download the JAR correctly from EXT repo, but when it tries to download the POM afterwards, Maven mistakenly think that it should be downloaded from PUBLIC. Because PUBLIC do not contains 1.0-alpha-1.1, Maven assume there is no POM.
I have EXT repo defined before PUBLIC in my settings.xml. What even more strange is, I tried to block accessing in Nexus for native2ascii-maven-plugin from PUBLIC. Maven, instead of getting the POM from repository EXT, it get from central directly. At last I add PUBLIC as mirror for central, and Maven can build correctly, because EXT is the the only repo that contains native2ascii-maven-plugin. Maven seems tries to download the POM from every repository else which contains native2ascii-maven-plugin in despite of the version number, except from EXT
I simply cannot understand why this will happen. This have been used for years, and it used to be fine even several weeks before (I have other new developers, who can correctly download the plugin, several weeks ago). May anyone guide me the possible cause of the problem? I have neither changed anything in my repo, nor changed version of Maven. Why Maven's "download" behavior suddenly changed?
It's hard to say.
First my theory on why it no longer works. I am guessing this "worked for years" because at one time it worked, and afterwards everything was in your local repository (<home>/.m2/repository). Later, something broke, but you never noticed because you had everything local. The new developer did not have a populated local repository so when they built for the first time, they had failures.
Now my suggestion which may not work out for you. When using Nexus, I think its best to create a single "group" repository that links in all other repositories, and configure the group to order the priority of the linked repositories. So for you, in the group, you would list EXT first, then PUBLIC. Your POMs and/or settings would reference only the group repository. This may just duplicate what you are already doing through other means, but at least it is moving the ordering rules up into Nexus. I would rename your local repository (so you can revert back if necessary) and try re-building to see if everything resolves correctly.
You might want to consider a continuous build tool like Hudson that periodically deletes its own local repository so you can catch issues like this sooner.
At last I managed to find out the "cause" of the problem. It is due to my fault, combined with still-unknown behavior of Maven. I add this as an answer to ease future reference for other people.
They key problem is that I missed plugin version for this specific project (I did put corresponding pluginManagement for other projects, and other plugins for this project... I wonder how come I made this mistake this time)
The way to reproduce the problem:
A separate repository to store the plugin (in my case, org.codehaus.mojo:native2ascii-maven-plugin:1.0-alpha-1.1)
In project POM, add plugin, without version. For example,
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>native2ascii-maven-plugin</artifactId>
<plugin>
</plugins>
in settings.xml, avoid defining mirrors (i.e. the settings.xml contains list of repositories and pluginRepositories only)
With such setup, first purge the local repository. Then build the project. After build, inspect the directory in local repository for that plugin (in my case .m2\repository\org\codehaus\mojo\native2ascii-maven-plugin\1.0-alpha-1.1), you will find only the JAR presents, without corresponding POM. (Caused by Maven successfully get the plugin JAR corresponding to the pluginRepositories in settings.xml, but trying to get the POM from a weird location)
With the same setup, put the version in project POM, clean up the local repo, and build again. Everything is fine now.
The reason for work fine even for a recently clean CI environment, is probably due to other "correct" project made the plugin downloaded correctly, which can be used by this "incorrect" project. A periodic purge in local repository in CI won't necessary help much on this too because for that many projects, the chance is always very high for other "correct" project build earlier than that "incorrect" project.
The reason behind such behavior of Maven is still unknown, but at least in a "correct" POM (with plugin version correctly declared), Maven works fine. I will raise this as a issue for Maven though.
I'd start off by agreeing with SingleShot in that Continuous Integration - even a simple smoke test where you simply compile and run unit tests on the trunk - would have prevented you getting into the situation of assuming that the because the build works on one machine, it does not work on the other.
This have been running fine for several years.
That's the kicker with Maven repositories - all you need to do is download it once succesfully, and you'll be forever good to go. Just because it's been working successfully from your local repository doesn't mean it was working.
It is fine several months ago (coz I have migrated our CI server and I have a clean env to build, and everything is fine).
Interesting. So my theory would be then to go and make sure the new developer is set up correctly - that the settings.xml file is in place and is being read (I've had instances that the settings.xml is THERE, but in the wrong place!). It's a simple one, but Maven does not fail if there's no settings.xml, it just uses a default that may have you seeing ghosts.
You mentioned that you use maven 2.2.1 and I can only ask you to doublecheck, we had some strange behavior concerning downloading jars from internal repo that was caused by OSX Lion update that comes with maven3. Our fix was to redeploy affected project.
I know there are various known issues with the M2eclipse plugin and I guess this is just one of them. Hopefully someone is aware of a solution or workaround.
We have like 30 projects in our workspace but for clarity lets assume there are only 2: A en B.
B includes A as a dependency in the pom.xml of B.
The problem we have is that in eclipse the classes of A can't be found so you get compilation errors. However, if you 'mvn install' A to deploy it in the local repository and the close project A then everything is fine; no compilation errors. So, if A exists in the project M2Eclipse does not seem to be able to correctly set the classpath in eclipse.
To make things stranger, we also have project C that also depends (in exactly the same way as B) on project A but here we have no compilation errors. We can't identify anything meaningful difference between project B or C; as said, they include A in the same manner.
thanks for your help,
Stijn
P.S. I'm using version 0.10.2.20100623 of the plugin
I've experienced this behavior before, and it has occurred for me in the past when I imported or checked out the maven projects separately.
Prerequisite: make sure you have m2extras installed before you check out a multi-module Maven project: update site
First thing to try: right-click each project and choose Maven -> update project configuration. The plugin might be smart enough to detect that it could be building project references between the projects.
Second thing to try (if your 30 projects are all submodules off one root): this would be easiest, because you could use the SCM integration of m2eclipse to do a "Checkout as Maven Project..." on the root pom. M2eclipse would make a project for the superpom and for each submodule, with project references built appropriately.
Third thing to try: I'd try manually creating project references in the project settings of each project to mirror their interdependencies. It'd be a lot of work, and unless you check in your eclipse .project/.settings (eww), it would have to be done individually for each working copy.
RESOLVED
finally, after agonizing hours I found the cause.
I was focussing on the .classpath and the .settings files but the problem was located in the .project file. This file in project A was missing following entry in the tag natures:
<nature>org.eclipse.wst.common.modulecore.ModuleCoreNature</nature>
Adding this resolved the issues.
How to convert a Ant project to Maven project? A sample project that would link (a Wicket project)
Thanks
The nice part of using maven is that most standard stuff works automatically once you do things the maven way. For a simple webapp:
Create a pom with groupId, artifactId and version (packaging: war)
Add the required dependencies to the pom
move the
java sources to src/main/java,
resources to src/main/resources,
webapp content to src/main/webapp,
test content to src/test/java and src/test/resources
set the compiler compliance version using the maven compiler plugin
That should get you up 'n' running.
http://www.sonatype.com/people/2009/04/how-to-convert-from-ant-to-maven-in-5-minutes/
I don't know what your ant script looks like, but assuming its a basic script for building, you will need to create a pom.xml file for your project, add your dependencies, and then build it via maven.
For anyone who lands here in future, there is an easier way to find dependencies for maven using the file hashes. So, you won't have to guess artifact versions.
As per the below article, the idea is to generate a SHA1 checksum of the dependency that you want to find the information, then do a reverse search in Nexus repository manager using that hash. For the checksum generation, you can use Microsoft's FCIV (free) utility.
https://devreads.xyz/ant-to-maven-conversion-the-painless-method/
Is there a way to specify the artifact version outside of the POM file?
I have 2 CI projects that build an artifact. One builds a "stable" development version from a 'develop' branch and the other builds an unstable version which is the result of merging all active feature branches into the develop branch. I want the stable version to build as xyz-1.0.jar and the integration build to go in as xyz-1.0-SNAPSHOT.jar. Is there a way for the CI job to run a maven task or specify via the command line if a release or snapshot jar should be built without manually modifying the POM? Currently I have the version specified as 1.0 in the pom. I considered using the release plugin but I don't want the automatic version number increase and tagging that it does.
Short answer: no. And here are some additional remarks:
It doesn't make much sense to use a "released" version (i.e. non SNAPSHOT) for a branch under CI since released versions are not downloaded again even if a newer version is available.
Released versions should be tagged (e.g. 1.0), maintenance is done is in a branch derived from the tag (e.g. 1.0.1-SNAPSHOT).
If you want to distinguish versions built from different branches, use different versions in the POMs.
I was able to accomplish this by using a property in my POM and then overriding it via the command line.
pom.xml:
...
<version>${artifactVersion}</version>
<properties>
<artifactVersion>1.0</artifactVersion> <!-- default version -->
</properties>
...
Then overriding with mvn -DartifactVersion=1.0-SNAPSHOT package
But Pascal's answer above is more in line with what I was really asking. My solution is more of a workaround I feel.
You should be able to achieve this using maven profiles
What are the minimum steps I should follow to replace Ant with Maven?
Set up your project according to the standard directory layout.
Create a minimal pom.xml with groupId, artifactId and version.
Add your dependencies to the pom.xml
Compare the WAR/JAR/EAR to the old version see if there is any change. Take actions to minimize the differences as told here.
You should now be able to build a simple project, run the tests and package it.
Anecdote: Once you are in Maven, the reverse trip (though why would you ever go back!) is so simple:
mvn ant:ant
generates functionally equivalent ant scripts. Now if only an Ant->Maven generator existed.
You can have a look to ant2maven script, that builds pom.xml from Ant scripts. I've never tried it, but it can be used to have a good pom.xml to start with...