[pzygielo]

• I hereby declare this contribution to be licenced under the Apache License Version 2.0, January 2004

[desruisseaux]

Do we need to add a new useModuleVersion plugin configuration option? Couldn't the users set the existing moduleVersion configuration option to an empty value instead if they do not want module version? It would still require a change in the code, but would avoid increasing the number of plugin configuration options.

[pzygielo]

Couldn't the users set the existing moduleVersion configuration option to an empty value instead if they do not want module version?

Let me explore that option. As long as the same goal is achieved I'm not attached to new parameter.

[pzygielo]

Do we need to add a new useModuleVersion plugin configuration option? Couldn't the users set the existing moduleVersion configuration option to an empty value

Unclear how to preserve compatibility with current default of project.version (since 3.14). Using special value not conforming to ModuleDescriptor.Version could be considered, but I don't like that idea very much.

Thus I prefer proposed solution, but I'm open to see it being solved differently.

[desruisseaux]

No special value, just allow users to specify <moduleVersion/>. The value is set to an empty or blank string, and the code just needs to test if (!moduleVersion.isEmpty()) { add the option }.

[pzygielo]

With <moduleVersion/> project.version seems to be injected. So !moduleVersion.isEmpty would always be true unless default was removed.

[pzygielo]

Then, I don't know how to differentiate the case of explicit empty or blank string set with <moduleVersion/> from the case this is not set at all, for the project.version to be used.

[desruisseaux]

It may be a question for @gnodet: we have a configuration option declared that way:

@Parameter(property = "maven.compiler.moduleVersion", defaultValue = "${project.version}")
private String moduleVersion;

Do you know if it is possible for a user to explicitly set an empty value? Apparently, using <moduleVersion/> causes Maven to fallback on defaultValue. Is there a way to said "do not use the default"? (other than adding a new useMavenVersion plugin configuration option).

[slawekjaranowski]

we can also use a special value like skip for moduleVersion parameter ... but I'm not sure if will be a clear way
so new parameter is ok for me

[pzygielo]

I'm also not sure about special value.

But perhaps new option, if it's accepted, could have better name than I proposed here.

[slawekjaranowski]

I'm also not sure about special value.

But perhaps new option, if it's accepted, could have better name than I proposed here.

for me name is ok 😄

[desruisseaux]

Sorry for being silent (I have a meeting to prepare next week). It seems to me that the cleanest solution would be to put an empty value <moduleVersion>. I haven't investigated yet why it doesn't work. I thought that maybe, if we cannot rely on the value injected automatically by Maven in annotated field, maybe we can find this information in Model. I haven't checked yet if this is feasible.

[slawekjaranowski]

Here is s reason:

• Allow empty values to overwrite default values eclipse-sisu/sisu-project#167

so I would not to do a magic in plugin for it

[desruisseaux]

Thanks for the link. Alternatively, in the following declaration (added in commit 09dce4e):

@Parameter(property = "maven.compiler.moduleVersion", defaultValue = "${project.version}")
private String moduleVersion;

What about removing the default value completely, and let users specify it explicitly? The rational given in MCOMPILER-579 (that ${project.version} is not a valid module version when the version ends with -SNAPSHOT) seems quite convincing.

[slawekjaranowski]

Thanks for the link. Alternatively, in the following declaration (added in commit 09dce4e):

@Parameter(property = "maven.compiler.moduleVersion", defaultValue = "${project.version}")
private String moduleVersion;

What about removing the default value completely, and let users specify it explicitly? The rational given in MCOMPILER-579 (that ${project.version} is not a valid module version when the version ends with -SNAPSHOT) seems quite convincing.

when we remove default value we will break a current behavior

[pzygielo]

The rational given in MCOMPILER-579

There is something missing or misunderstood.

(that ${project.version} is not a valid module version when the version ends with -SNAPSHOT)

is completely valid module version when it ends with anything, as long as it follows ModuleDescriptor.Version spec (starts with the number, which the other example in issue HEAD-SNAPSHOT does not).

[pzygielo]

For the

when we remove default value we will break a current behavior

additionally consider, that using the project.version was not introduced in

• [MCOMPILER-579] allow module-version configuration #273.

It just enabled module version to be modified.
So the behaviour of not specifying explicit module version and having it anyway is the old, old feature (2ba3f26).

[desruisseaux]

(...snip...) is completely valid module version when it ends with anything,

Ah, okay. I do not remember having tested.

[pzygielo]

@desruisseaux Do you have any other comments?

[desruisseaux]

No other comment. I'm still interested in making possible to set an empty value instead of adding a new parameter, but I may explore this possibility in version 4. I should probably learn more about the relationship between Eclipse SISU and Maven 4 (for eclipse-sisu#167).

[pzygielo]

Then, this could be merged as proposed, right?

[desruisseaux]

Yes, sorry for being so slow. For merges on the 3.x branch, I tend to leave it @slawekjaranowski or any other who is familiar with the long history of this plugin and its interaction with Maven 3 (I'm more familiar with Maven 4 code base than Maven 3).