I know this is a much discussed topic. There are severals pages with happy and sad endings.
I've read:
maven-dependency-range-does-not-work-as-expected
maven-version-ranges-do-not-behave-as-expected
Maven Version Range References
Legit but Useless: Maven Version Ranges Explained
All of these articles seems to talk about Hardcoded versions.
What if the version is managed ? e.g: Sprigboot
Using the property
<maven-javadoc-plugin.version>[3.4.1)</maven-javadoc-plugin.version>
To override SpringBoot's one will result in a failure since it will try to use even ranges characters are version identifier attached image will show what I meant, and what maven is trying to do:
Related
I'm trying to find out if the maven-release-plugin uses the string release.arguments or arguments to pass additional arguments to the maven release plugin. For example,
mvn release:perform -DignoreSnapshots=true -Drelease.arguments=-DaltDeploymentRepository=my-login::default::https://nexus.example.com/repository/maven-releases/
I found the latest release at https://maven.apache.org/maven-release/maven-release-plugin/index.html which at the time of this question is 3.0.0-M4. The current version uses arguments and it's documented.
My question is:
Does Maven have a standard way of storing/referring to previous releases of plugins? If not, what is a way to get the list of arguments available in the 2.8.2 version?
Many sites have a dropdown that lets you pick the prior versions, but I didn't see that on this website or this plugin.
Looking for the solution
A search of the above question did not find anything useful. A search on SO found several questions but none that answered my question, see https://stackoverflow.com/search?q=%5Bmaven%5D+release+plugin
maven release plugin - manipulating project release version
Accesing release version of maven-release-plugin
Several others questions, that I won't list.
The documentation for the parameters has as "since" column.
There you can see that arguments was always called arguments.
I'm looking for possibilities for generating documentation using DocBook as part of my Maven build process. What I'm finding is everyone is suggesting docbkx-maven-plugin over Doxia. The problem is that it seems docbkx is no longer maintained or at least they've moved and left no forwarding address for where to look at the source code. According to the plugin's website the repository is on googlecode.com which of course hasn't existed for many years now. The last update I found of the plugin was back in 2016. This leads me to believe that the plugin is no longer maintained. Does anyone have any news to the contrary, or a different option for generating DocBook output during a maven build?
The source is available here: https://github.com/mimil/docbkx-tools
It does look like the project is no longer maintained, having seen no commits since 2015.
You don't actually need the plugin. If you have a working DocBook toolchain, you can use Maven to invoke it. The plugin could make certain aspects easier, but it also adds a limitation in that it only supports HTML output.
I would like to update a property in a given pom to the major+minor version of the new version when I perform a release.
To do this, I need to set goals to run during the release. I can calculate the property ahead of time, but the versions:set-property I've seen elsewhere appears to be gone (according to http://www.mojohaus.org/versions-maven-plugin/ and CLI use), and other goals for this plugin don't seem to be able to handle not using the exact version.
Is there any reasonably simple way to do this, or do I have to shell out to the exec or antrun plugins to do it? Regardless, it seems that there's nothing but text replacing that will fix it. The replacer plugin seems to work, but that requires grabbing the previous version, and would take work to not break other references.
The Maven build helper plugin can set properties using regex. Maybe this is what you need.
In a gradle file it's possible to specify a dependency with a dynamic version, like:
compile 'some.dependency:name:1.+'
This is documented to resolve the "newest" matching version. I have two questions:
[1] What does "newest" mean? Suppose the available versions are:
1.0
1.1-beta
1.1
Is the "newest" one 1.1-beta or 1.1? Does it depend at all on when the versions were published, or is it purely based on the version strings? If purely based on the strings, what ordering is used, because if it's just alphabetical then I think 1.1-beta would end up being "newer" than 1.1.
[2] As a publisher of a module, is there a sensible way of publishing a beta build such that developers who are depending on your module and using dynamic versions wont automatically pick it up? Is there a standard or recognized way of doing this?
Thanks!
[I'm aware using dynamic versions is discouraged. These questions are from the point of view of someone providing a module, and wanting to ensure that developers who do use it and ignore this advice still don't end up pulling in something unexpected]
I' m guessing you are publishing to maven, and as I know, there should be an xml file named maven-metadata.xml which holds the information of the latest upload to the corresponding artifact. So I guess it does not depend on your naming convention but what you upload the latest. If you would upload 1.0.0.1 the latest then it would be downloaded not 1.1-beta or 1.1 versions.
For more info check here.
At work someone has committed a lot of changes into a project that are JDK 1.5 specific. Unfortunately, some of the production environment is still at Java 1.4, and so they have resorted to creating a dual branch consisting of a jdk1.4 version of /trunk.
This 1.4-branch is likely to have at least a one year lifetime, during which changes in trunk are merged into the jdk1.4 branch.
The question I was asked is if there was any best practices on dealing with Maven artifact ids in this situation? Obviously best practices would probably avoided getting us in this situation to begin with, but now that we are ... what to do?
We thought about giving the other branch a unique artifact id, such as "myapp-jdk14", while keeping every other identifier field (groupId, version) in sync. Any obvious downsides to doing this?
You could use a classifier for this:
classifier:
The classifier allows to distinguish artifacts that were built from the same POM but differ in their content. It is some optional and arbitrary string that - if present - is appended to the artifact name just after the version number.
As a motivation for this element, consider for example a project that offers an artifact targeting JRE 1.5 but at the same time also an artifact that still supports JRE 1.4. The first artifact could be equipped with the classifier jdk15 and the second one with jdk14 such that
clients can choose which one to use.
Source: http://maven.apache.org/pom.html
In fact, there are 2 commonly used solutions for this:
Adding some special, custom suffix to artifacts' names, like jdk14. For example, Bouncy Castle or SLF4j use this strategy.
Using classifiers, that are in fact designed for such tasks like distinguishing variations about same artifact (exactly your case).
What is interesting from my experience, first solution is really more often used despite the fact that the second one is officially suggested for such stuff.
Personally, I use first solution, but - to be honest - I don't see any strong advantage (or disadvantage) of one solution against the other one.
You can use your solution but I would suggest to have different version numbers.
For example:
1.0.X for JDK 1.4
1.1.X for JDK 1.5
That doesn't mean my suggestion is better than yours. Your solution has the advantage to see based on the artifactId which jdk it is for very obviously.