Maven 2, Nexus and snapshot timestamps are causing problems with eclipse:eclipse - maven-2

We have moved from Archiva to Nexus and are still using Maven 2.
We execute eclipse:eclipse locally so that Eclipse .project and .classpath files are generated, based on the dependencies in the POMs, and then we import the projects into Eclipse to do our development. We don't use M2Eclipse for a variety of reasons.
Since using Nexus, we have the problem that projects don't always reference each other in the workspace, rather they reference the respective JAR.
I have noticed that Nexus is appending a timestamp to the JAR name, and the MVN output states, e.g.:
[INFO] Artifact myapp-bom:jar:7.3.0.2.1-SNAPSHOT already available as a workspace project, but with different version. Expected: 7.3.0.2.1-20120508.115037-68, found: 7.3.0.2.1-SNAPSHOT
I get the feeling that is the reason why eclipse:eclipse generates .classpath files which contains JAR references (based on local maven repo) rather than project references. When we used Archiva (and there were no timestamps) then we used to get project references, and that is exactly what we want.
Has anyone else had this problem and how is it solved? I read that maven 3 forces timestamps to always be generated. Again, how do you get eclipse:eclipse to generate sensible .classpath files?
Cheers,
Ant
PS - some of our projects come from different SVN repositories. It seems that if the Eclipse Projects are refernced in the parent pom, eclipse:eclipse creates a project reference, but if the Eclipse Projects are from a different parent pom, but still in the workspace, then it can only generate JAR references.

The problem was resolved by using maven-eclipse-plugin (eclipse:eclipse) version 2.9, rather than 2.8! Doh...

Related

Can I install several files into one artifact with Maven2 instal:install-file command

I'm developping application with JOGL2 and my favorite IDE Eclipse, also I want to use Maven2 for this purpose. Unfortunately, JOGL2 has no artifact yet. Also, I plan to deploy it as a runnable jar file.
So I want to install JOGL artifact locally : so i'll use the install:install-file command.
But I want to group several jars to make several artifacts, that is :
gluegen-rt.jar and jogl.all.jar as a single artifact named jogl.core
gluegen-rt-natives-linux-i586.jar and jogl.all-natives-linux-i586.jar as a single jar named jogl-natives-linux-i586
and so on
Is it possible ? (The official documentation does not mention the possibility or unpossibility to do so).
Thanks in advance
Install all files as usual like file:jar:version. Than create pom with pom packaging and use gluegen-rt.jar and jogl.all.jar as dependencies in it (they must be already installed). After that use new pom as dependency in your project.
maven doesn't have support for that. You would have to unpack these JAR files and repackage them together.
maven does have support for merging JAR with dependencies (http://stackoverflow.com/questions/574594) - and it's done the way I mentioned above. But you are asking about merging two arbitrary JARs, which is not possible in maven.

Maven is using incorrect location for downloading plugin pom

(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.

How to convert Ant project to Maven project

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/

Maven adds class files of snapshot dependencies

on my Windows machine I do have several proeject that I build with maven. At the moment they are all in SNAPSHOT-State. When I build a project that relies on one of the other projects maven always adds the class files of the other projects to the jar.
If I build the project on my CI-Server this problem does not occur. Does anyone have an idea why maven adds the class files to my jar?
I'm using maven 2.2.1
When I build a project that relies on one of the other projects maven always adds the class files of the other projects to the jar.
This is not a default behavior and, if it happens, you're somehow telling Maven to do so. If you want to hunt potential discrepancies, check the effective-pom, the effective-settings, the active-profiles using the following goals on both machines:
help:effective-pom
help:effective-settings
help:active-profiles
Also double check how Maven is invoked on the CI machine (extra command line parameter, etc).

Maven and Spring

Hi i am studying Spring In Action 2.0 and i am new to maven.
I am walking through the chapters and codes but i i got following error when i imported project through pom.xml on the pom editor in eclipse.
6/21/09 3:19:42 AM CDT: Missing
indirectly referenced artifact
incubator-activemq:activeio-core:jar:3.0-beta3:compile
6/21/09 3:19:42 AM CDT: Missing
indirectly referenced artifact
incubator-activemq:activemq-core:jar:4.0:compile
I downloaded the jar file and added to the library. still it does not work.
I am stuck what to do next? Can anyone help me with this?
Thanks in advance.
The referenced jars aren't available on the Maven2 central repository, so unless you have an additional repository declaration in your POM or an active profile in your settings, Maven will not know where to obtain the artifacts from.
There are a few public repositories like here and here hosting these artifacts.
To use these repositories you could add the relevant repository declaration to your POM or settings. See here for an example configuration.
Alternatively if you don't trust the repositories you could manually download the jars and put them into your local Maven repository, though you'd need to be careful to replicate the structure Maven expects, and you may well encounter the same problem for different jars.
Another alternative is to use a Maven repository manager like Nexus or Artifactory, to manage Maven's interactions with external repositories, though that is almost certainly too much information if you're just starting out.
For general help/information on Maven, check out the Maven book.