versions
versions copied to clipboard
Invalid segment error when version contains more than 3 segments
According to this blog, http://blog.soebes.de/blog/2017/02/04/apache-maven-how-version-comparison-works/
Maven now supports more than 3 segments. However the versions plug-in immediately dies with
[ERROR] Failed to execute goal use-latest-versions (default-cli) on project mdm: Execution default-cli of goal use-latest-versions failed: Invalid segment, 1, for the 1 segment version: '2.2.38.141' -> [Help 1]
Any time it comes across a version with more than 3 segments. I've been mitigating this in the past with a long long list of -Dexcludes , however that's a manual effort.
I'm wondering if @khmarbaise you have anything planned to address this. Would it be appropriate to instead of fail and throw an error, WARN that a version has not been updated, or that it has been skipped?
Thx
Which version of versions-maven-plugin do you use?
I've reproduced it with the head of master, so 2.6-SNAPSHOT. Which i'm just starting to use now.
I am currently on 2.1 but as part of my move to 2.6 i'm also trying to rework my usage of it.
What i've done locally and temporarily is gone into the 3 VersionComparator classes, commented out the throw to InvalidSegment exception and instead
System.out.println(String.format( "Can't Touch this: Invalid segment, %d, for the %d segment version: '%s'", segment, segmentCount,
v.toString() ) );
return (v);
Based on first impressions, i'm liking this behavior more.
Hi... i use 2.5 of maven-versions-plugin and have Google Analytics as dependency ( https://mvnrepository.com/artifact/com.google.apis/google-api-services-analytics ).
I get the message: [ERROR] Failed to execute goal org.codehaus.mojo:versions-maven-plugin:2.5:update-properties (default-cli) on project aldi-bus-bom: Execution default-cli of goal org.codehaus.mojo:versions-maven-plugin:2.5:update-properties failed: Invalid segment, 1, for the 1 segment version: 'v3-rev126-1.19.1'
Is this relevant? Is there a work around?
Thanks.
Open from Jan. Still nothing... Is this error expected? Are we doing something wrong?
In my case invalid segment error occurs only if I am ignoring minor & major updates.
mvn versions:use-latest-versions -DallowMajorUpdates=false -DallowMinorUpdates=false
In my case invalid segment error occurs only if I am ignoring minor & major updates.
I encounter the same issue. Should use-latest-versions skip segments anyway? Or at least propose an option not to process segments?
@blacelle Would you mind filing a PR from your fork?
Also applies to update-properties
goal...like @nsidhaye , I am also ignoring minor & major updates.
this is super annoying. fails on multiple like:
a:b:1.2.1.21
c:d:1.8.4.1
etc.
This basically undoes any benefit of updating through the plugin
I'm getting the same error when I run
mvn versions:update-properties -DallowMajorUpdates=false -DallowMinorUpdates=false
but NOT if I run:
mvn versions:update-properties -DallowMajorUpdates=false
or
mvn versions:update-properties -DallowMinorUpdates=false
although in the latter case it still implements minor version updates.
Same here for property <ojdbc.version>19.11.0.0</ojdbc.version>
with the following configuration:
<goals>
<goal>display-property-updates</goal>
<goal>display-dependency-updates</goal>
</goals>
<configuration>
<allowAnyUpdates>false</allowAnyUpdates>
<allowMajorUpdates>false</allowMajorUpdates>
<allowMinorUpdates>false</allowMinorUpdates>
</configuration>
Plugin version: 2.8.1.
Not sure if this helps but according to the version rules documentation on the homepage (see https://www.mojohaus.org/versions-maven-plugin/version-rules.html)
the version rules is as follows:
<MajorVersion [> . <MinorVersion [> . <IncrementalVersion ] ] [> - <BuildNumber | Qualifier ]>
and
If your version number does not match this format, then the entire version number is treated as being the Qualifier.
So (if I read this correctly), a version like 1.2.3.4
is treated as a qualifier!
Also versions like a.b.1´ or
1.2.c` are not compliant, hence treated as qualifiers.
There's a notice at the top that basically calls into question the whole page. It then links to a proposal https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning Which links to an issue https://issues.apache.org/jira/browse/MNG-3010 The issue was closed as fixed.
Guys, I'll look into it.
I get the message:
[ERROR] Failed to execute goal org.codehaus.mojo:versions-maven-plugin:2.5:update-properties (default-cli) on project aldi-bus-bom: Execution default-cli of goal org.codehaus.mojo:versions-maven-plugin:2.5:update-properties failed: Invalid segment, 1, for the 1 segment version: 'v3-rev126-1.19.1'
Related, has to do with the way segments are determined.
I appreciate the maven versioning policy however it might fit the reality (but in such irregular cases Maven and the plugin will simply treat the whole version as qualifier), but the issue people are dealing with here is that those irregular dependencies act as poison for the plugin: the whole run will be stopped by a single such dependency. This is why some chose to patch the plugin and "sanitise" the exception.
So, I'm working on a fix.
There are 59 more issues to go. I hope that not every single one has to be solved to unblock
- https://github.com/mojohaus/versions-maven-plugin/issues/645
The more I look into it, the more issues I see:
- segment appears to be 0-based (see e.g.
AbstractVersionsUpaterMojo.determineUnchangedSegment
orMavenVersionComparator.innerIncrementSegment
), but the comparison against the segment count suffers from the 1-off problem:
if ( segment > segmentCount )
{
throw new InvalidSegmentException( segment, segmentCount,
version.toString() );
}
- segment determination flags (allowMajorUpdates, etc.) are actually not at all independent, but are actually a sort of enum; so an actual enum or an unchanged segment index would be better;
- part of the above: it's not actually possible to have allowMajorUpdates = true and allowMinorUpdates = false; allowMajorUpdates = true implies all others also being true;
There are probably more problems with this, but I'll limit the scope of this item to the issue OP raised only. The other findings will be done as separate issues.
The PR will be rather large due to the fact that I'm leveraging the InvalidSegmentException
and InvalidVersionSpecificationException
rather than simply ignoring those; they are then handled in the Mojo itself. Due to the fact that InvalidVersionSpecificationException
was a RuntimeException
and therefore unchecked, a relatively small refactor was due. However, due to the size of the PR, it's possible that it's not gonna fit into the release.
I'm getting the same error when I run
mvn versions:update-properties -DallowMajorUpdates=false -DallowMinorUpdates=false
but NOT if I run:
mvn versions:update-properties -DallowMajorUpdates=false
ormvn versions:update-properties -DallowMinorUpdates=false
although in the latter case it still implements minor version updates.
The reason for that is that the check would only fail if the determined "leftmost unchanged segment" is greater than the determined number of segments in the version.
"leftmost unchanged segment" is based on your "allow{Major,Minor,Incremental}Updates" flags (those flags are actually a sort of enum switch), and will assume -1 for Major (meaning no restrictions), 0 for minor (meaning only major segment is restricted), and so forth.
So, the exception would only be raised if that segment is greater (actually should have been greater or equal because it's 0-based, but that's for another PR) than the total number of segments ;)
However, this will be effectively fixed once the PR gets merged in.