Why is the Maven user-specific settings folder .m2 called, well, .m2 in Maven 3?
I've read through the Maven Settings Reference and am still clueless, and I can't find any similar questions here. I know M2_HOME replaced MAVEN_HOME in Maven 2, so I'm guessing that is part of the reason.
The directory exists since the version 2.0 of Maven, hence the name. . means hidden files on Unix/Linux plaforms, m for Maven, 2 for version 2.0.
I guess the authors wanted to distinguish the then-new v2.0 version from the old 1.x versions, hence they created the M2 name. It's worth mentioning that Maven 2.0 was completely incompatible with Maven 1.x, while Maven 3.0 is almost fully backwards compatible with v2.0, and it only has major changes and improvements "under the hood". Since Maven 3.0 should have no visible changes from the users' perpective (to be backward compatible), the authors must not change the name of all options/directory names for the new version.
Related
The versions of Maven plugins specified in default-bindings.xml is not latest.
For example, maven-resources-plugin is 2.6, but latest is 3.1.0,
maven-jar-plugin is 2.4, but latest is 3.1.0.
https://github.com/apache/maven/blob/master/maven-core/src/main/resources/META-INF/plexus/default-bindings.xml
I think it's not necessary to update default-bindings.xml at every minor version update of plugins.
However, the above is major update.
I know I can change the versions myself if I want.
My Question is why default versions that affect most of the maven users are clearly old.
The thing is you should always pin all your plugin (and I mean all plugins) inside your build which means define the version of all plugins via <pluginManagement>..</pluginManagmenet> this is best practice and you should never rely on those in Maven Core.
Furthermore there is work done in the background to decouple the artifact handlers (plugin binding) from Maven Core and move it to the plugins1, 2 and 3 and so on (which is done in very small steps and will take a long time).
I've got multiple projects using a certain Dependency of Version XX, if I release a new version, I have to touch every project to change it to version XX.Y.
I've came across an approach to edit my m2 settings <version>${my.version}</version>, to add a parameter and bind it into my POM.xml, but this implicit means, everyuser has to manage their m2 settings when I do a new release.
Is there a way to central (user independant) manage the versions as in SVN, so none has to change anything and it always uses the up2date version, if I release a new version?
In general, the maintainer of every project should decide for themselves if they update the version or not. Updating the version might break things, so they may choose to stay on the older version. Particularly, it is important that the maintainers notice that something has changed, so that tests are run.
For development, though, there are Snapshot versions. A Snapshot dependency always references the newest version, but the -SNAPSHOT indicates this to the maintainer of the project. Snapshot versions should not go to production - the builds are not reproducible.
If artifacts are so tightly coupled that they are build together, think about using multi module projects.
You can use a pattern called "Bill of Material".
I think your question is somehow similar to this question (but not exactly a duplicate), and my answer applies here aswell:
You create a new maven project (the bill of material) that only consists of a pom with dependency management block. Here you declare all your dependencies and their versions. The packaging should be set to pom.
This bill of material (bom) project is now used as parent of all other projects. When using a dependency, only group id and artifact id is specified, the version tag is ommited. In that way, the version will be taken from the bom and you have one central place to manage the versions of the dependencies.
More details with examples are here (in the lower part of the page) or here.
Consider a project that is used in other projects, and this project has version 1.0 and is present in the Nexus.
After that, some changes are done in this project.
Now there are two solutions:
Increment the version of the project to 2.0, and delete the version 1.0 from Nexus. When the developers try to get the dependencies from the Nexus with version 1.0 they will get an error that this version does not exist and need to change the version to 2.0.
Change the functionalities of this project and inform the crew that some changes are done, but this is not the practice at all.
Is there any functionality in Maven and Nexus to simplify this task and make this all happen in the backend so the developers can't do anything, or is this not possible?
If you have an old version of an artifact that must not be used anymore because it has some dangerous bug, or it does not work with the new database structure or something like this, it may be advisable to move it to some non-public Nexus repository (and also delete it from the local repository of the build server), so that nobody can use it for release builds (people can use it for local builds, but this is usually not dangerous).
If you want to manage standard versions throughout your company, it is a good idea to have a parent pom or some boms which collect versions in a <dependenyManagment> section and can be included by the developers. This way, you only need to inform them to change one version number (namely the one of the parent pom or bom) instead of many.
Still, you are left with the problem that people do not read company newsletters. I know the problem that many developers of jars compile and test their source code against very old versions of their dependencies while the war/ear (that includes the jar) uses new versions.
In the src/test/resources folder of a maven project there's a relative symbolic link.
With the 2.6 version of the plugin, the actual file is copied.
After updating to the 3.0.1 version, it copies the link instead of the file and on a subsequent run (without clean) fails (mvn -e shows it's because of a FileAlreadyExistsException).
Is there any config option to restore the behavior from the previous version ?
I agree, having a link as a test resource is a really bad idea.
This is a known bug in the maven-resources-plugin: MRESOURCES-237 Resource plugin’s handling of symbolic links changed in 3.0.x, broke existing behaviour, unfixed but known for 1½ years.
Unfortunately, there’s not (yet) a configuration option. Introducing it (and defaulting it to “follow symlinks” instead of copy-preserving them) would fix this issue.
For now, the only solution is to downgrade the maven-resources-plugin. I also upgraded from 2.6, and have just now downgraded to 2.7 (last of the 2.x series), and can confirm that it works around this bug and properly copies the symlinks’ contents.
Update: due to the “Mark invalid” issue (a bug in maven-filtering) you should consider staying with 2.6 if you don’t need any of the new 2.7 features, or have to amend the plugin definition with an updated dependency on maven-filtering 1.3 (or maybe newer).
Our team manages Java projects using Maven. We have a policy that all code on the master branch of a repository should:
itself have a -SNAPSHOT version (releases are created using the Maven Release plugin)
have Maven dependencies only on releases and never on -SNAPSHOTs.
This has an unfortunate consequence in IntelliJ IDEA (version 15, build 143.1821.5). Suppose Maven artifact A depends on some release version of Maven artifact B, say 1.2.3. The current code for B on master, though, will be something like 1.2.4-SNAPSHOT. If I load the source for both A and B in IDEA, go to a class in B which is used in A, and do a Find Usages (Ctrl-click the class name or Alt-7), no results are found. If, however, I navigate in the IDE to the decompiled class file for the 1.2.4 release and do Find Usages, it finds the usages in A.
I understand why this happens --- the -SNAPSHOT version of the code really isn't being used by A --- but this degree of pickiness makes Find Usages nearly useless across Maven artifacts. However, I seem to remember at some point in the recent past IDEA's Find Usages wasn't so picky. Unfortunately Googling hasn't turned up anyone else mentioning this problem or a mention of a change in IDEA behavior, so now we are thinking we just imagined the previous behavior.
So, does anyone know how to get IDEA to ignore version mismatches on Maven modules when doing Find Usages? Was there some setting we had enabled before that we now can't find?
I think you're doing this incorrectly.
By definition, the MASTER branch should be a released version (no -SNAPSHOT).
You want to talk to your team and review your build and release processes.
Have a read about the git-flow branching model for some more information about branching strategies.