working with maven release plugin or any plugin with version x.y.z-LABEL

[asafbennatan]

the setup:
lets say i have two plugins
the first is plugin-a-1.0.0-SNAPSHOT.jar and the second is plugin-b-1.0.0.jar ,
now i want to make plugin-b dependent on plugin-a .
usually the best way would be to set a maven property (in plugin-b POM) called plugin-a.version and use it in both the maven dependency section and the Plugin-Dependencies manifest entry so when a version is changed you dont have to change in both places.
now the issue:
if i set plugin-a.version variable as 1.0.0-SNAPSHOT , pf4j complains that:

com.github.zafarkhaja.semver.expr.LexerException: null
	at com.github.zafarkhaja.semver.expr.Lexer.tokenize(Lexer.java:218)
	at com.github.zafarkhaja.semver.expr.ExpressionParser.parse(ExpressionParser.java:86)
	at com.github.zafarkhaja.semver.expr.ExpressionParser.parse(ExpressionParser.java:43)
	at com.github.zafarkhaja.semver.Version.satisfies(Version.java:325)

if i try seperating it into two variables plugin-a.version-full plugin-a.version-numeric then 1.0.0-SNAPSHOT < 1.0.0 (as expected) and the runtime files due to incompatible plugin dependencies.
since maven release plugin is in high usage - what would be the correct way to develop and check plugins with version scheme of x.y.z.-SNAPSHOT?

UPDATE:
ok after some research it seems like the issue is with https://github.com/zafarkhaja/jsemver
which seems like is not being maintened anymore , so i think pf4j should switch semver implementation to a maintained library or roll out its on fork of https://github.com/zafarkhaja/jsemver
one other library option would be https://github.com/asarkar/jsemver though it is not on maven central

[decebals]

ok after some research it seems like the issue is with https://github.com/zafarkhaja/jsemver
which seems like is not being maintened anymore

zafarkhaja/jsemver#56

One idea is to switch to semver4j, but it's not an easy decision because I don't know how many people use internally the jsemver's API, although they shouldn't because we have VersionManager interface.

Maybe it's a good idea to add a PR with another implementation of VersionManager (for example semver4j), to have something an alternative. Can you try to add this PR, and test it with your use case?
Also, can you add a test in DefaultVersionManagerTest that fails on your use case?

In the end, related to this NPE. what is wrong in jsemver (the root of the problem)? I ask you because I'm curious.

[asafbennatan]

@decebals
1.agree with the issues of switching to semver4j - also they still do not support condition expressions such as >= only parsing of versions and programmatically checking for condition. another option would be to fork jsemver
2.yes will try doing so
3.actually the exception is a LexerException that is caused by jsemver failing to tokenize the '-SNAPSHOT' part of the 1.0.0-SNAPSHOT

regarding what you wrote about the test that you want to add to DefaultVersionManagerTest - the test should pass expecting the error right ? not fail

FYI this passes

    @Test
    public void unsupportedConstraint() {
        Assertions.assertTrue(Version.valueOf("1.0.0-SNAPSHOT").greaterThanOrEqualTo(Version.valueOf("1.0.0-SNAPSHOT")));
        assertThrows(LexerException.class, () -> versionManager.checkVersionConstraint("1.0.0", ">=1.0.0-SNAPSHOT"));
    }

[decebals]

@asafbennatan jsemver has updated recently. If we need help, we have to create an issue on that project.