I have a Maven project that needs to be versioned. I have chosen to use the versions-maven-plugin as my versioning plugin but am unsure if that's the best option.
I have read the documentation that such plugin actually modifies the POM and I don't really like that approach. I have worked on projects where they had separate build.properties file that got modified manually.
What I want to achieve is to have my CI generating the artifact for me ready to be deployed and update the version number automatically.
So, any suggestions? How have you done before?
Thank you
I'd get the version number from the one source that matters: that's the source code management system (Subverson, Mercurial, or Git), not Maven.
I'd say that Maven might be out of synch unless your Maven plug-in is getting it from SCM.
Use the Release Plugin. You want to perform automatic deployment and batch release. The Versions Plugin is designed for something else.
We have found MAVEN-RELEASE-PLUGIN super useful and can not imagine releasing and managing version with it.
Related
Currently I'm in the transition of moving ANT projects to Maven and struggling on how to get the project versioning working correctly. Currently I have about 30+ projects/modules that all rely on each other so everything must be at the latest version to work correctly. This was easily done with ANT but when it comes to Maven I would need to make constant changes to all other released project POM's to allow them to pick up these new changes.
I discussed with a few other developers and we decided we might not even need a maven repo with version numbers, we just have everything at the same version number and build locally or through Jenkins to update our .m2 folders. Does this sound like the correct route for our situation? Are we missing anything doing this?
I did suggest having our test Jenkins to deploy to a repo with version numbers like 1.0.Beta-SNAPSHOT. We have Jenkins setup to build when our testing branches are updated. This means I would not have to locally compile every project on that branch to update my .m2, I could just change the POM to pull all these Beta-SNAPSHOT versions in one place. Would there be a good way for me to do this that would not affect the release if it was pushed and released with this version number set? If I wanted to use my local versions I would then just switch this version number to 1.0.0 which isn't within the repo but my local .m2.
Any suggestions on how to properly manage the maven projects/modules with version numbers would be welcome! Something that reduces the need to change every POM when releasing 1 of the projects/modules would be best!
Our developer struggle with this problem a lot. It is a lot of manual work to update all the POMs for a release.
We are going to aim for multi-module projects, which also seems like a good fit for you.
If you say, that everything must be using the latest versions all the time, I would put all the projects into one large multi-module project. This means that you have one (git) repository with a main POM in the root directory and a directory for each module (sub-project) with its own POM references the main POM as parent.
Then you can run mvn clean install on the parent and build all the modules with consistent version numbers. So releasing is then just one large build.
You should note, though, that you tie the projects (modules) closely together in this way, but it I understood you correctly, they are already tightly interrelated.
What does "Maven -> Update Project..." do in Eclipse?
It syncs the Eclipse project settings with that of the pom. If you for example change important plugin settings, such as the output java version, you will find that Eclipse will ask you to update the project and afterwards the configured Java runtime in the project will have changed to reflect what your Maven pom indicates.
That is an important thing to keep in mind: the Maven pom is the lead in this kind of project setup. If you want settings to change, try to do that through the pom and not through Eclipse project settings directly or doing a project update might revert what you have changed. There are usually some things I have to correct myself anyway though, such as build path exclusions that m2eclipse likes to put in and strange deployment assembly configurations.
To add on to what #Gimby said - Update Project also provides more options such as Force Update of Snapshots / Releases which is extremely helpful when you have dependencies that are looking for the latest. (e.g.: [1.0) will find 1.0.* - whatever's the latest.)
Updating project is synonymous with Ivy's Resolve. It will make sure that all referenced dependencies are there, as well as clean the project to make sure that they are included correctly.
I could not dig out the documentaiton, but I was able to dig out the code. To complement #Gimby answer - you can go into details and look into what the function does in here:
https://github.com/eclipse/m2e-core/blob/41f5ae34ad2543ef1439b7fd7e0a03b596af8685/org.eclipse.m2e.core/src/org/eclipse/m2e/core/internal/project/ProjectConfigurationManager.java#L365
Look for : updateProjectConfiguration0 function.
Cheers,
Warning: I have just picked up Maven, so things mentioned might be wrong or not best practice.
I have a medium size open source project that I am migrating to Maven from the basic
NetBeans project management. This is not a developer team sharing the same room, this is 1-5 people over the internet sharing a SVN repo. Reading over the how-tos on dependencies, it seems that the only way to get dependencies is to get them from an online repo or install them locally.
This is not what I was looking for. I want to keep all dependencies in the SVN for many reasons including portability (anybody can pass by, check out the repo, build, and use; all that simply without manual adding to local repo's and whatnot), getting newer versions (discussed below), and manual versioning.
The other issue I have with the maven repository is that they are quite behind in versions. Logback for example is 0.9.18 in mvnbrowser but 0.9.24 officially. PircBot is 1.4.6 in mvnbrowser but 1.5.0 officially. Why such old versions?
Issue 3 is that I have dependencies that don't even exist in the repos, like Easier Java Persistence.
So
How can I force all dependencies to come from /lib for example
On a related note, can mvn build from library's SVN repo directly? Just curious
Is there an automatic way to get the newest version directly from a dependencies site/svn repo if they also use Maven? IE libraries like commons-lang or logback
Is there a better way of managing dependencies? (IE Ivy or some weird POM option I'm missing)
FYI, this is a Java project with 3 modules, project global dependencies and module specific dependencies.
Bonus points if it can work with the bundled version of Maven that comes with NetBeans.
Not a duplicate of
Maven: add a dependency to a jar by relative path - Not wanting to install to local repository
maven compile fails because i have a non-maven jar - Don't think a System dependency is the right answer
maven look for new versions of dependencies - Still uses(?) repository, just the latest (old) version
This is not what I was looking for. I want to keep all dependencies in the SVN for many reasons (...)
I will come back on this but the solution I described in Maven: add a dependency to a jar by relative path (using a file-based repository) allows to implement such a solution.
The other issue I have with the maven repository is that they are quite behind in versions. Logback for example is 0.9.18 in mvnbrowser but 0.9.24 officially. PircBot is 1.4.6 in mvnbrowser but 1.5.0 officially. Why such old versions?
It looks like mvnbrowser indices are totally out of date (making it useless as repository search engine) because the maven central repository does have logback-core-0.9.24.jar (the logback project is doing what has to be done to make this happen) but only has an old pircbot-1.4.2.jar. Why? Ask the pircbot team. Anyway, you're right, the central repository might not always have ultimate versions.
Issue 3 is that I have dependencies that don't even exist in the repos, like Easier Java Persistence.
Yeah, this happens too.
How can I force all dependencies to come from /lib for example
As previously hinted, you should re-read carefully the solution suggested in Maven: add a dependency to a jar by relative path. This solution is not about installing libraries to the local repository but is about using a file-based repository (that could thus be stored in SVN). You might have missed the point, this matches your use case. And also check Brett's answer for a variation.
On a related note, can mvn build from library's SVN repo directly? Just curious
Didn't get that one. Can you clarify?
Is there an automatic way to get the newest version directly from a dependencies site/svn repo if they also use Maven? IE libraries like commons-lang or logback
Maven supports version ranges and you could use a syntax allowing to use "any version greater than X". But I do NOT recommend using version ranges at all, for the sake of build reproducibility. You don't want the build to suddenly fail because of some automatic update that happened on your back. Only upgrade if you need bug fixes or new features, but do it explicitly (if it ain't broke, don't fix it).
You might also find mentions of the LATEST and RELEASE version markers. I don't recommend them neither for the same reasons as above and even less since they're removed from Maven 3.x.
Is there a better way of managing dependencies? (IE Ivy or some weird POM option I'm missing)
Can't say for Ivy. But in the Maven land, if you can't host up a "corporate" repository for your project (Nexus, Archiva, Artifactory), then the file-based repository is IMO the best approach.
Setup your own Maven repository.
http://archiva.apache.org/
On the development shop I work for, we have an internal MAVEN repository, to keep our libraries (proprietary & open-souce). A common problem that we face is that, sometimes, the open-source libraries in our local MAVEN repository gets obsolete. Is there an automatic way to keep all the open-source libraries I use in my MAVEN repository always updated? What do you suggest to resolve this issue?
Archiva has been mentioned, but nexus seems more popular. Both have been designed to solve problems like the one you're having
Assuming you:
Don't want to download everything
Don't want to run another server
process
Only want to track a limited number
of projects
You might want to create a separate pom.xml file with dependencies like this:
<dependency>
<groupId>org.openfoo</groupId>
<artifactId>jfoo</artifactId>
<version>[1.0.0,2.0.0)</version>
</dependency>
This will tell maven to use jfoo 1.0.0 up to jfoo 2.0.0 so when jfoo releases version 1.2.17, you'll be fetching that in the next build assuming your settings are set to check versions each time.
This pom doesn't have to actually build anything. Just list those things you want to track.
Running:
cd the-path-to-the-project; mvn -q -B -U package
Via cron once a day will update all the dependencies in that pom and only report when there is a problem
BTW, this is a hack. If the number of developers is > 3 and you have the resources to run nexus, don't bother with the hack.
Take a look at Apache Archiva, a repository manager for Maven.
When you start to use a third party library in Java, you add their jars to your project. Do you also add the jars to the repository or do you just keep a local installation. And if the latter, how do you sync between team members to be able to work?
Thanks.
Yes. You should add to the repository whatever is required for a developer on a clean system (aside from having the JDK and ant installed) to check out and build the project.
No, if you use Maven. Put them into Maven repository (if they are not there yet, most open source libraries are in public Maven repositories already).
Yes, if you use Ant.
If you're using ANT and you want maven style dependency management without maven, take a look at Ivy. It can download from maven repositories and can even read maven pom files.
Yes, third-party libraries should be version controlled since you will want everyone to compile against the same version of that library. This way when updates to that third-party library happen you will simply have to change it in one place and everyone will update to the new version. Otherwise you could easily end up with the famous: "It compiles on my machine!"-syndrome.
Assuming you do not use Maven, then you should definitely check in versions of 3rd party jars. You (or more importantly, the maintenance developer coming along after you) should be able to pull a version of your application from the repository and have all the correct versions of all the 3rd party jars required at compile- and runtime.
You also should maintain the versioning history of the 3rd party jars, again to help the maintenance developer out. Checking them in to the repository is the easiest and most effective way to do this.
I would recommend versioning everything you need to build a project. Unless your using a build tool like maven.
Short Answer
No
Longer answer
In the interim, use a folder on your network separate from the repo.
A Long Term Solution
Use maven. It was built for handling your build, configuration and external jar dependencies.
Go here for documentation though. (The official maven documentation is known to be pretty spotty).
Lately I've been keeping JARs out of SVN. I have a separate repository that I use to pull them into projects, manage dependencies, and keep track of different versions.
This is what Maven is born for. I've got to learn how to use it well, but until then I'm keeping my own JAR repository.