enableOverrideArtifact=true make version append twice to artifact name


When enabling the flag


The artifact created will get double version appended to its name

[INFO] Installing /.../target/some-installer-1.0.0-SNAPSHOT.jar to /.../some-installer-1.0.0-SNAPSHOT/1.0.0-SNAPSHOT/some-installer-1.0.0-SNAPSHOT-1.0.0-SNAPSHOT.jar

Reason is this code:

Since finalName per default is

chainging the name of the artifact.setArtifactId become

Chaing it to

Would solve that problem, but it would also change the final name of all artifacts in the whole build. I believe using finalName on <build> level instead of per plugin is the recommended.

Besides that.. not using the 'enableOverrideArtifact' flag at all actually overwrite the default artifact - so I'm not sure if it is needed at all?

Remove finalName and enableOverrideArtifact parameters and default to the finalName taken from the <build>. If a customization of the installer name would be needed, maybe use parameters similar to the maven-assembly-plugin (stripVersion... and such)




René Krell
March 26, 2018, 8:34 PM

Well done, thank you guys for investigating and coding.

Zdeněk Vaník
March 26, 2018, 6:08 PM

I will mark this issue as resolved, since similar problem was fixed by IZPACK-1596, if it does not fit what you would need please feel free to reopen the issue.

René Krell
March 26, 2018, 10:05 AM

will provide a change which will remove enableOverrideArtifact and keep finalName, which appears to be a good compromise to me. Although it might break running build environments.

René Krell
April 20, 2017, 10:17 AM

We could also mark the enableOverrideArtifact and finalName configuration elements of the Izpack Maven plugin deprecated, printing a warning at compile time, and parallely implement an alternative approach, like using stripVersion from the final installer name.

In a subsequent major version we might remove enableOverrideArtifact and finalName as allowed plugin parameters completely.
Just to go on with this.
What do you think about this?

René Krell
March 31, 2017, 3:11 PM

Personally I'd leave the finalName just for the purpose to override the installer file name generated in the build in target/, for instance if it should be directly uploaded to a share without any Maven renaming voodoo. In each case it defaults to the build's finalName. We have also two use cases here, the izpack-jar packaging type executing the izpack-maven-plugin implicitely replacing some parts of the jar lifecycle, and a regular execution of the izpack-maven-plugin within a module with another packaging type.
I can imagine to have differences between module name, artifact name and the resulting installer jar, for example a multi module build directory structure:

but the jar file name to be myapp-component1-installer.jar and so on at the end.
I'd not break this behavior for existing environments.

I agree with enableOverrideArtifact to be a logical mistake, this is not absolutely necessary to override the artifact name and it is quite the same which name it gets in a local or remote repository. Nevertheless, I'd like to avoid break existing environments in a maintenance version, so better mark it deprecated instead of completely removing it now. We can mention in the documentation to require the finalName tag value to be without the version suffix to avoid this effect. In addition, we can require the finalName
to be explicitly set when enableOverrideArtifact is set to true.

It seems the code you suggested mostly fulfills this. You may check if there are further pitfalls I haven't noticed yet.

Meant as a suggestion from my side.

Your pinned fields
Click on the next to a field label to start pinning.


René Krell


Tomas Forsman


Functional - may break existing environments