maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Curley (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (MSHADE-203) "shadeTestJar" option not working?
Date Tue, 04 Aug 2015 22:40:04 GMT

     [ https://issues.apache.org/jira/browse/MSHADE-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Aaron Curley updated MSHADE-203:
--------------------------------
    Description: 
So, I'm pretty new to using the maven-shade-plugin and I'm not really that familiar with the
maven-shade-plugin's design/code; however, it appears that the <shadeTestJar> option
in the maven-shade-plugin configuration does not work correctly.  

__Symtoms__
While running "mvn package" in my project (which has <shadeTestJar> set to true), maven-shade-plugin
appears to perform the "test jar shading" step (after performing the regular jar's shade),
but the "shaded" test JAR doesn't actually include any shaded dependency files (it just includes
the "original" test jar's contents, which is essentially a "no-op").

__Possible Diagnosis__
I took a quick look at the release code base for v2.4.1, in particularly, the mojo/ShadeMojo.java
file.  In the execute() method, at line 437, there is method call:
processArtifactSelectors( artifacts, artifactIds, sourceArtifacts, artifactSelector );

This method call appears to populate the "artifacts" and "sourceArtifacts" sets created earlier
in execute() but the code noticeably does not populate the similar "testArtifacts" set.  My
guess is that this is causing the "shade" operation to skip processing any artifacts for the
test jar shade operation (since only the project-level artifact is populated in the "testArtifacts"
set at line 432).

__Possible Solution__
(Obviously) Add an additional parameter to processArtifactSelectors() that accepts the additional
"testArtifacts" set.  Then, processArtifactSelectors could populate that set (much like it
does for the "sourceArtifacts" set at line 623).  A more extensible design might be to populate
a list of Set's and supply that to processArtifactSelectors(), but there are some other difficulties
with that (under the current design).

Best wishes.  Like I said, I'm pretty new to this plugin, so the above may be incorrect.

  was:
So, I'm pretty new to using the maven-shade-plugin and I'm not really that familiar with the
maven-shade-plugin's design/code; however, it appears that the <shadeTestJar> option
in the maven-shade-plugin configuration does not work correctly.  

__Symtoms__
While running "mvn package" in my project (which has <shadeTestJar> set to true), maven-shade-plugin
appears to perform the "test jar shading" step (after performing the regular jar's shade),
but the "shaded" test JAR doesn't actually include any shaded dependency files (it just includes
the "original" test jar's contents, which is essentially a "no-op").

__Possible Diagnosis__
I took a quick look at the release code base for v2.4.1, in particularly, the mojo/ShadeMojo.java
file.  In the execute() method, at line 437, there is method call:
processArtifactSelectors( artifacts, artifactIds, sourceArtifacts, artifactSelector );

This method call appears to populate the "artifacts" and "sourceArtifacts" sets created earlier
in execute() but the code noticeably does not populate the similar "testArtifacts" set.  My
guess is that this is causing the "shade" operation to skip processing any artifacts for the
test jar shade operation (since only the project-level artifact is populated in the "testArtifacts"
set at line 432).

__Possible Solution__
(Obviously) Add an additional parameter to processArtifactSelectors() that accepts the additional
"testArtifacts" set.  Then, processArtifactSelectors could populate that set (much like it
does for the "sourceArtifacts" set at line 623).

Best wishes.  Like I said, I'm pretty new to this plugin, so the above may be incorrect.


> "shadeTestJar" option not working?
> ----------------------------------
>
>                 Key: MSHADE-203
>                 URL: https://issues.apache.org/jira/browse/MSHADE-203
>             Project: Maven Shade Plugin
>          Issue Type: Bug
>    Affects Versions: 2.4.1
>            Reporter: Aaron Curley
>            Priority: Minor
>
> So, I'm pretty new to using the maven-shade-plugin and I'm not really that familiar with
the maven-shade-plugin's design/code; however, it appears that the <shadeTestJar> option
in the maven-shade-plugin configuration does not work correctly.  
> __Symtoms__
> While running "mvn package" in my project (which has <shadeTestJar> set to true),
maven-shade-plugin appears to perform the "test jar shading" step (after performing the regular
jar's shade), but the "shaded" test JAR doesn't actually include any shaded dependency files
(it just includes the "original" test jar's contents, which is essentially a "no-op").
> __Possible Diagnosis__
> I took a quick look at the release code base for v2.4.1, in particularly, the mojo/ShadeMojo.java
file.  In the execute() method, at line 437, there is method call:
> processArtifactSelectors( artifacts, artifactIds, sourceArtifacts, artifactSelector );
> This method call appears to populate the "artifacts" and "sourceArtifacts" sets created
earlier in execute() but the code noticeably does not populate the similar "testArtifacts"
set.  My guess is that this is causing the "shade" operation to skip processing any artifacts
for the test jar shade operation (since only the project-level artifact is populated in the
"testArtifacts" set at line 432).
> __Possible Solution__
> (Obviously) Add an additional parameter to processArtifactSelectors() that accepts the
additional "testArtifacts" set.  Then, processArtifactSelectors could populate that set (much
like it does for the "sourceArtifacts" set at line 623).  A more extensible design might be
to populate a list of Set's and supply that to processArtifactSelectors(), but there are some
other difficulties with that (under the current design).
> Best wishes.  Like I said, I'm pretty new to this plugin, so the above may be incorrect.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message