Publish to maven repository as "latest"

[Theodore David Williams]

Is there any way that I can get a "latest" link in my local .m2 repository for each artifact? For reasons I don't really want to explain (and unfortunately I cannot change this, I know it sucks but I am stuck with it) I have to manually link in eclipse my maven dependencies. It would be nice if I could link something like .m2/repository/com/test/test/latest/test.jar. Where latest pointed to a specific version

i.e. .m2/repository/com/test/test/2.1/test.jar

that represents the latest version. That way every time someone publishes/deploys a new version I do not have to update my eclipse classpath.

Is it also possible to publish a "latest" to my internal maven repo?

Thanks, any and all ideas are always welcome!

[Tim Holloway]

Maven is designed to facilitate large projects made up of components from many sources. To minimize breakage, each component comes in discrete, fixed releases and the preferred method is that the project that's referencing them should pull by explicit version. In other words, they're trying to eliminate a form of "DLL Hell".

Of course, when you're talking in-house projects, you may have a lot more volatility. In such cases, you can make more general version dependencies in the POM, although for best business continuity practices, I recommend adjusting them for production releases.

If you do nightly builds, you can give them names like 2.3.26-SNAPSHOT and simply replace the previous edition. There's also a "release" goalset which can automatically tag artifacts with names such as 2.3.26-SNAPSHOT20110201124847, which I find useful for deploying Linux RPM-based builds, since the RPM package manager won't update if it thinks the latest version of a package is already installed.

[Theodore David Williams]

Ok so maybe my question was confusing, sorry about that ;)

I know I can publish an internal artifact to my repo and have any other internal projects depend on the specific version (i.e. 1.2.1), or LATEST, RELEASE, or use the range mechanism.

My problem lies in the fact that the project I need to checkout (again I cannot change this, I know it sucks but it is what I am stuck with at the moment), has the eclipse classpath "hardcoded".

i.e. each jar I am dependent on was added one by one to the class path referencing my local .m2 repository.

The reason this sucks is that every time I change a version in my pom.xml file I need to remove the old version from my hardcoded classpath and add in the new version.

I would not have to do this if there was a latest link for each artifact in my local .m2 repo. That way I could hardcode in my classpath:
.m2/repository/com/test/test/latest/test.jar

rather than
.m2/repository/com/test/test/1.2.1/test.jar

I can't imagine anything like this is possible but I ask because I do not know for sure

Thanks again!

[Tim Holloway]

Actually, your clarification was more confusing than the question. For one thing, I'm not sure why an open-ended version request isn't the same as "latest" in your view.

If, in fact, your Eclipse classpath is hardcoded in the POM, that is a serious problem. Neither Maven nor Ant should be doing that, and in fact, it's not good practice for batch building anywhere. It makes it a lot harder to do automated builds and makes it darn near impossible to maintain a separate non-GUI production build environment like I've had in some shops.

One of the biggest reasons I use batch build tools is because they keep the IDE from holding me hostage. I've already experienced the situation where a program would break and need a one-line fix, the fix couldn't be compiled because the IDE had changed, and the older IDE couldn't be installed on the latest OS. No thanks. Batch processes are simpler and less prone to breakage.

If Maven is going to do the build, the Maven repository should be sufficient via Maven's own (non-IDE) processes. If your problem is making Eclipse Maven-friendly and you don't have the Sonatype m2eclipse plugin, get it. Among other things, it will add the project's Maven dependencies to the Project Explorer View. And even without Maven, avoid hard-coding absolute paths into Eclipse projects. Eclipse has symbolic definition capabilities that can be used to help ensure that when you go on vacation and Sally Schmuckendorf has to do an emergency fix, she can do it on her own computer and not have to hack into yours. I worked in a shop where in theory we were supposed to be using the same setup as another group and in practice did no such thing, because they'd tied their build processes intimately into an IDE configuration that wasn't appropriate to us.

Regardless, I'd be very careful with POMs calling for the "latest" version of an artefact. It's OK for development, but a production build that gets dragged out in the middle of the night 3 years from now may discover that the latest versions of its dependencies are all over the map and you're right back where I was 10 years ago with IDE-only builds.

[Theodore David Williams]

There is no dependency on eclipse to build. I.E. I can build using maven from the command line and things work perfectly.

We use eclipse to develop so it is nice to open the project in eclipse and have it "build" such that eclipse does not complain.

There are few ways to do this with maven.
1. You can use the maven eclipse plugin and type 'mvn eclipse:eclipse' from the command line to generate your .classpath file from your pom
2. You can have the eclipse maven plugin "m2eclipse" generate a "Maven Libraries" folder in your class path which is dynamically generated from your pom file

I cannot use either of these as we have nested poms (modules) and the plug ins are expecting in eclipse that you have separate projects for each pom file. Again for reasons that I do not want to get into I cannot change this right now.

To work around this in eclipse (ONLY IN ECLIPSE, TO GET ECLIPSE TO STOP COMPLAINING) we edit the eclipse .classpath file to have an entry for each jar we are dependent on that points to the physical location in our .m2 local repository. That way eclipse will not complain about not being able to find things. The problem with this approach is that when we change our pom.xml file to have a new version of a jar we need to update the eclipse .classpath and remove the link to the old version in my .m2 repository and add a new link to the new version. This does not affect building with maven because when we update the pom and build with maven it does the right thing, but in eclipse (since we are not using one of the two ways above to configure our eclipse classpath) eclipse will not be looking at the right version of the jar until we make a manual change.

Does that make more sense?

[Tim Holloway]

Much more sense! However, you're working too hard, I think.

Unless I misremember, Sonatype supports 2 different approaches to this.

1. Create a separate Eclipse project and make them Eclipse dependencies. NOTE THAT a local Eclipse project does NOT have to reference a top-level CVS artifact. Or at least it doesn't when Subversion is being used.

2. Import the whole thing as one big project. The m2eclipse plugin understands that sub-projects contain sub-poms and sub-targets and it can resolve matters accordingly.

Actually, I think I have one project which is both of the above, since the auxiliary projects are just references into the main project.

In any event, we've determined that yes, it is possible to keep a floating "LATEST' version in Maven, and I further assert that when properly set up, Eclipse can reference these artifacts without the need to request them explicitly or hard-code any filesystem references into the repository. Doing so may require a little fiddling, but this capability is designed into the system.

[Theodore David Williams]

Tim thanks again for the help!

Unfortunately (verified by m2eclipse guys) m2eclipse will not pull dependencies from sub-projects/sub-poms into the "Maven Libraries" classpath that it generates. Which is my problem, we have on REALLY big project and we don't really want to break it down into different projects on checkout. Not a huge deal its just not easy on the eyes. So we only get dependencies from the top/root level pom. So that is why I have to add all other dependencies one at time to my eclipse classpath, because m2eclipse is not adding them.

Seems like they have no intention of fixing this which is a real bummer. I am using the latest release 0.12.1, if you have gotten this to work please let me know how.

http://dev.eclipse.org/mhonarc/lists/m2e-users/msg00261.html

[Tim Holloway]

Hmmm. Maybe it's just the way I organized things. I can see where Eclipse might have issues with more than one set of Maven libraries in a project.

In practical terms, I thing what would probably work would be to run the root project and generate Eclipse sub-projects for each directory that contains a pom.xml file using the "maven eclipse:eclipse" goal. Then when you need to work on a given sub-project, use the SVN explorer to pull the root project down as one Eclipse project and the sub project down as another Eclipse project. I think that when done properly, they can even be made to share directories so that you don't end up with 2 copies of things, although the root project should generally be considered read-only regardless. Since typically you wouldn't be modifying more than a handful of sub-projects at a time, simply don't check out the others to keep the workspace simple. And a project of this magnitude probably should be in its own private workspace, but that's a matter of taste.

I won't guarantee that this approach works in all cases, but keeping sub-projects in a source tree and checking them out does work for Subversion, at least. Although when I use the term "sub-project" what I mean is relative to Version Control Storage, since in Eclipse, all projects are top-level, regardless of where in the VCS hierarchy they get checked out from.

Sorry I don't have a "cookbook recipe" for doing this at my fingertips, but I definitely have done something more or less like this without too much wartiness, so I know there are ways to do it.