Mojo

Use the ${project.build.finalName} to setup the name of the output library name

Details

  • Type: Wish Wish
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: None
  • Fix Version/s: None
  • Component/s: native
  • Labels:
    None
  • Complexity:
    Intermediate
  • Testcase included:
    yes
  • Patch Submitted:
    Yes
  • Number of attachments :
    1

Description

It would be great if this functionality can be implemented because using the artifactId instead of the project.build.finalName parameter is very annoying and disappointing. Moreover, the naming convention of the artifactId could prevent the build process to generate the good library generated name.

Considering the implementation of the maven-war-plugin that use the build.finalName parameter to setup the name of the generated war file, i send you a possible patch for the code.

You can have a look to the the WarMojo[1] clear to see how it is implemented (especially line 58-64) and how i updated the NativeLinkerMojo class.
I've also updated the NativeLinkerMojoTest class inspiring myself with the WarMojoTest[2] class (line 75 and 83) of the maven-war-plugin project.

I hope this patch can fix the problem. Thanks a lot for reading me.

[1] http://svn.apache.org/viewvc/maven/plugins/tags/maven-war-plugin-2.1-beta-1/src/main/java/org/apache/maven/plugin/war/WarMojo.java?revision=754916&view=markup
[2] http://svn.apache.org/viewvc/maven/plugins/tags/maven-war-plugin-2.1-beta-1/src/test/java/org/apache/maven/plugin/war/WarMojoTest.java?revision=754916&view=markup

Activity

Hide
Permalink
Karim DRIDI added a comment -

The thing i understood is you change the natural lifecycle of maven by overriding the project.build.finalName by the artifactId value to set it by default.

The drawback is that you remove the renaming functionnality i tried to reintroduce with the patch i submitted.

But if you let the default lifecycle by removing the two lines
// String finalName = project.getArtifactId();
// project.getBuild().setFinalName( finalName );
in the NativeInitializeMojo class the default behavior would come back and the library naming issue could be naturally fixed by using the standard project.build.finalName property, couldn't it ?

So the question is what is better ?

  • Remove the two above lines from the NativeInitializeMojo and use the maven standards
  • Accept my patch to reintroduce the renaming possibility but the patch will introduce also a new parameter (more difficult to understand for a normal user)
  • Suppress the renaming of the target file that could be very annoying and disappointing by refusing any of above modification.

I hope you will choose a good choice

Best regards.

Show
Karim DRIDI added a comment - The thing i understood is you change the natural lifecycle of maven by overriding the project.build.finalName by the artifactId value to set it by default. The drawback is that you remove the renaming functionnality i tried to reintroduce with the patch i submitted. But if you let the default lifecycle by removing the two lines // String finalName = project.getArtifactId(); // project.getBuild().setFinalName( finalName ); in the NativeInitializeMojo class the default behavior would come back and the library naming issue could be naturally fixed by using the standard project.build.finalName property, couldn't it ? So the question is what is better ? Remove the two above lines from the NativeInitializeMojo and use the maven standards Accept my patch to reintroduce the renaming possibility but the patch will introduce also a new parameter (more difficult to understand for a normal user) Suppress the renaming of the target file that could be very annoying and disappointing by refusing any of above modification. I hope you will choose a good choice Best regards.

People

  • Assignee:
    Unassigned
    Reporter:
    Karim DRIDI
Vote (0)
Watch (0)

Dates

  • Created:
    Updated: