[jira] [Commented] (MENFORCER-477) failWhenParentIsSnapshot does not respect onlyWhenRelease

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MENFORCER-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709776#comment-17709776
 ] 

Peter De Maeyer commented on MENFORCER-477:
---

This is not a bug after all. I had made a mistake: I had put the 
{{onlyWhenRelease}} and {{failWhenParentIsSnapshot}} directly in the 
{{configuration}} section instead of _inside_ the {{requireReleaseDeps}} rule. 
Once I put the parameters in the right place, it works as expected. Sorry for 
the noise. This can be closed.

> failWhenParentIsSnapshot does not respect onlyWhenRelease
> -
>
> Key: MENFORCER-477
> URL: https://issues.apache.org/jira/browse/MENFORCER-477
> Project: Maven Enforcer Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.1, 3.3.0
>Reporter: Peter De Maeyer
>Priority: Major
>
> I have a snapshot project that has a snapshot parent.
> At release time, I want to use the enforcer plugin to make sure the release 
> version of my project only depends on release versions, including the parent, 
> so I use {{failWhenParentIsSnapshot=true}}.
> For snapshot versions of my project, I want to _allow_ snapshot dependencies 
> including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
> enforcer for snapshot versions.
> *Expected:* my snapshot project build succeeds with a snapshot parent.
> *Actual:* my snapshot project build _fails_ with a snapshot parent, despite 
> {{onlyWhenRelease=true}}.
> I suspect that {{failWhenParentIsSnapshot}} does not take {{onlyWhenRelease}} 
> into account.
> The intuitive fix for me would be that the combination of both options 
> behaves as expected.
> I imagine that maybe it was a design choice to keep both options completely 
> independent of each other, so an acceptable alternative for me would be to 
> introduce yet another option, e.g. {{onlyWhenParentIsRelease}} that behaves 
> similar to {{onlyWhenRelease}} but applies to the parent only.
> {noformat}
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective settings
> [WARNING] Unrecognised tag: 'properties' (position: START_TAG seen 
> ...\n\t... @13:14)  @ /home/peter/.m2/settings.xml, 
> line 13, column 14
> [WARNING] 
> [INFO] Scanning for projects...
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for su.pernova:assertions-parent:pom:1.1.0-SNAPSHOT
> [WARNING] 'build.pluginManagement.plugins.plugin.(groupId:artifactId)' must 
> be unique but found duplicate declaration of plugin 
> org.apache.maven.plugins:maven-failsafe-plugin @ 
> su.pernova:bom:1.1.0-SNAPSHOT, 
> /home/peter/.m2/repository/su/pernova/bom/1.1.0-SNAPSHOT/bom-1.1.0-SNAPSHOT.pom,
>  line 263, column 17
> [WARNING] 
> [WARNING] It is highly recommended to fix these problems because they 
> threaten the stability of your build.
> [WARNING] 
> [WARNING] For this reason, future Maven versions might no longer support 
> building such malformed projects.
> [WARNING] 
> [INFO] Inspecting build with total of 5 modules...
> [INFO] Installing Nexus Staging features:
> [INFO]   ... total of 5 executions of maven-deploy-plugin replaced with 
> nexus-staging-maven-plugin
> [INFO] 
> 
> [INFO] Reactor Build Order:
> [INFO] 
> [INFO] Supernova Assertions - Parent  
> [pom]
> [INFO] Supernova Assertions - Main
> [jar]
> [INFO] Supernova Assertions - JUnit 4 
> [jar]
> [INFO] Supernova Assertions - JUnit 5 
> [jar]
> [INFO] Supernova Assertions - JUnit 4 + JUnit 5   
> [jar]
> [INFO] 
> [INFO] < su.pernova:assertions-parent 
> >
> [INFO] Building Supernova Assertions - Parent 1.1.0-SNAPSHOT  
> [1/5]
> [INFO] [ pom 
> ]-
> [INFO] 
> [INFO] --- maven-clean-plugin:3.2.0:clean (default-clean) @ assertions-parent 
> ---
> [INFO] 
> [INFO] --- flatten-maven-plugin:1.3.0:clean (flatten-clean) @ 
> assertions-parent ---
> [INFO] 
> [INFO] --- maven-enforcer-plugin:3.2.1:enforce 
> (enforce-no-snapshots-in-releases) @ assertions-parent ---
> [INFO] 
> 
> [INFO] Reactor Summary for Supernova Assertions - Parent 1.1.0-SNAPSHOT:
> [INFO] 
> [INFO] Supernova Assertions - Parent .. FAILURE [  0.464 
> s]
> [INFO] Supernova Assertions - Main  SKIPPED
> [INFO] Supernova Assertions - JUnit 4 . SKIPPED
> [INFO] Supernova Assertions - JUnit 5 . SKIPPED
> [INFO] Supernova Assertion

[jira] [Updated] (MENFORCER-477) failWhenParentIsSnapshot does not respect onlyWhenRelease

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MENFORCER-477:
--
Description: 
I have a snapshot project that has a snapshot parent.

At release time, I want to use the enforcer plugin to make sure the release 
version of my project only depends on release versions, including the parent, 
so I use {{failWhenParentIsSnapshot=true}}.

For snapshot versions of my project, I want to _allow_ snapshot dependencies 
including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
enforcer for snapshot versions.

*Expected:* my snapshot project build succeeds with a snapshot parent.

*Actual:* my snapshot project build _fails_ with a snapshot parent, despite 
{{onlyWhenRelease=true}}.

I suspect that {{failWhenParentIsSnapshot}} does not take {{onlyWhenRelease}} 
into account.

The intuitive fix for me would be that the combination of both options behaves 
as expected.

I imagine that maybe it was a design choice to keep both options completely 
independent of each other, so an acceptable alternative for me would be to 
introduce yet another option, e.g. {{onlyWhenParentIsRelease}} that behaves 
similar to {{onlyWhenRelease}} but applies to the parent only.

{noformat}
[WARNING] 
[WARNING] Some problems were encountered while building the effective settings
[WARNING] Unrecognised tag: 'properties' (position: START_TAG seen 
...\n\t... @13:14)  @ /home/peter/.m2/settings.xml, line 
13, column 14
[WARNING] 
[INFO] Scanning for projects...
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for 
su.pernova:assertions-parent:pom:1.1.0-SNAPSHOT
[WARNING] 'build.pluginManagement.plugins.plugin.(groupId:artifactId)' must be 
unique but found duplicate declaration of plugin 
org.apache.maven.plugins:maven-failsafe-plugin @ su.pernova:bom:1.1.0-SNAPSHOT, 
/home/peter/.m2/repository/su/pernova/bom/1.1.0-SNAPSHOT/bom-1.1.0-SNAPSHOT.pom,
 line 263, column 17
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten 
the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support 
building such malformed projects.
[WARNING] 
[INFO] Inspecting build with total of 5 modules...
[INFO] Installing Nexus Staging features:
[INFO]   ... total of 5 executions of maven-deploy-plugin replaced with 
nexus-staging-maven-plugin
[INFO] 
[INFO] Reactor Build Order:
[INFO] 
[INFO] Supernova Assertions - Parent  [pom]
[INFO] Supernova Assertions - Main[jar]
[INFO] Supernova Assertions - JUnit 4 [jar]
[INFO] Supernova Assertions - JUnit 5 [jar]
[INFO] Supernova Assertions - JUnit 4 + JUnit 5   [jar]
[INFO] 
[INFO] < su.pernova:assertions-parent >
[INFO] Building Supernova Assertions - Parent 1.1.0-SNAPSHOT  [1/5]
[INFO] [ pom ]-
[INFO] 
[INFO] --- maven-clean-plugin:3.2.0:clean (default-clean) @ assertions-parent 
---
[INFO] 
[INFO] --- flatten-maven-plugin:1.3.0:clean (flatten-clean) @ assertions-parent 
---
[INFO] 
[INFO] --- maven-enforcer-plugin:3.2.1:enforce 
(enforce-no-snapshots-in-releases) @ assertions-parent ---
[INFO] 
[INFO] Reactor Summary for Supernova Assertions - Parent 1.1.0-SNAPSHOT:
[INFO] 
[INFO] Supernova Assertions - Parent .. FAILURE [  0.464 s]
[INFO] Supernova Assertions - Main  SKIPPED
[INFO] Supernova Assertions - JUnit 4 . SKIPPED
[INFO] Supernova Assertions - JUnit 5 . SKIPPED
[INFO] Supernova Assertions - JUnit 4 + JUnit 5 ... SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  1.023 s
[INFO] Finished at: 2023-04-06T21:12:23+02:00
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce 
(enforce-no-snapshots-in-releases) on project assertions-parent: 
[ERROR] Rule 0: org.apache.maven.enforcer.rules.dependency.RequireReleaseDeps 
failed with message:
[ERROR] Parent Cannot be a snapshot: su.pernova:bom:pom:1.1.0-SNAPSHOT
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and pos

[jira] [Commented] (MENFORCER-477) failWhenParentIsSnapshot does not respect onlyWhenRelease

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MENFORCER-477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17709517#comment-17709517
 ] 

Peter De Maeyer commented on MENFORCER-477:
---

Yes, I tried with 3.3.0, the behavior is the same.

> failWhenParentIsSnapshot does not respect onlyWhenRelease
> -
>
> Key: MENFORCER-477
> URL: https://issues.apache.org/jira/browse/MENFORCER-477
> Project: Maven Enforcer Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.1, 3.3.0
>Reporter: Peter De Maeyer
>Priority: Major
>
> I have a snapshot project that has a snapshot parent.
> At release time, I want to use the enforcer plugin to make sure the release 
> version of my project only depends on release versions, including the parent, 
> so I use {{failWhenParentIsSnapshot=true}}.
> For snapshot versions of my project, I want to _allow_ snapshot dependencies 
> including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
> enforcer for snapshot versions.
> *Expected:* my snapshot project build succeeds with a snapshot parent.
> *Actual:* my snapshot project build _fails_ with a snapshot parent, despite 
> {{onlyWhenRelease=true}}.
> *Workaround:* disable {{failWhenParentIsSnapshot}}, but then I lose the 
> enforcement on the parent when I make a release of my project.
> I suspect that {{failWhenParentIsSnapshot}} does not take {{onlyWhenRelease}} 
> into account.
> The intuitive fix for me would be that the combination of both options 
> behaves as expected.
> I imagine that maybe it was a design choice to keep both options completely 
> independent of each other, so an acceptable alternative for me would be to 
> introduce yet another option, e.g. {{onlyWhenParentIsRelease}} that behaves 
> similar to {{onlyWhenRelease}} but applies to the parent only.
> {noformat}
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective settings
> [WARNING] Unrecognised tag: 'properties' (position: START_TAG seen 
> ...\n\t... @13:14)  @ /home/peter/.m2/settings.xml, 
> line 13, column 14
> [WARNING] 
> [INFO] Scanning for projects...
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for su.pernova:assertions-parent:pom:1.1.0-SNAPSHOT
> [WARNING] 'build.pluginManagement.plugins.plugin.(groupId:artifactId)' must 
> be unique but found duplicate declaration of plugin 
> org.apache.maven.plugins:maven-failsafe-plugin @ 
> su.pernova:bom:1.1.0-SNAPSHOT, 
> /home/peter/.m2/repository/su/pernova/bom/1.1.0-SNAPSHOT/bom-1.1.0-SNAPSHOT.pom,
>  line 263, column 17
> [WARNING] 
> [WARNING] It is highly recommended to fix these problems because they 
> threaten the stability of your build.
> [WARNING] 
> [WARNING] For this reason, future Maven versions might no longer support 
> building such malformed projects.
> [WARNING] 
> [INFO] Inspecting build with total of 5 modules...
> [INFO] Installing Nexus Staging features:
> [INFO]   ... total of 5 executions of maven-deploy-plugin replaced with 
> nexus-staging-maven-plugin
> [INFO] 
> 
> [INFO] Reactor Build Order:
> [INFO] 
> [INFO] Supernova Assertions - Parent  
> [pom]
> [INFO] Supernova Assertions - Main
> [jar]
> [INFO] Supernova Assertions - JUnit 4 
> [jar]
> [INFO] Supernova Assertions - JUnit 5 
> [jar]
> [INFO] Supernova Assertions - JUnit 4 + JUnit 5   
> [jar]
> [INFO] 
> [INFO] < su.pernova:assertions-parent 
> >
> [INFO] Building Supernova Assertions - Parent 1.1.0-SNAPSHOT  
> [1/5]
> [INFO] [ pom 
> ]-
> [INFO] 
> [INFO] --- maven-clean-plugin:3.2.0:clean (default-clean) @ assertions-parent 
> ---
> [INFO] 
> [INFO] --- flatten-maven-plugin:1.3.0:clean (flatten-clean) @ 
> assertions-parent ---
> [INFO] 
> [INFO] --- maven-enforcer-plugin:3.2.1:enforce 
> (enforce-no-snapshots-in-releases) @ assertions-parent ---
> [INFO] 
> 
> [INFO] Reactor Summary for Supernova Assertions - Parent 1.1.0-SNAPSHOT:
> [INFO] 
> [INFO] Supernova Assertions - Parent .. FAILURE [  0.464 
> s]
> [INFO] Supernova Assertions - Main  SKIPPED
> [INFO] Supernova Assertions - JUnit 4 . SKIPPED
> [INFO] Supernova Assertions - JUnit 5 . SKIPPED
> [INFO] Supernova Assertions - JUnit 4 + JUnit 5 ... SKIPPED
> [INFO] 
> 
> [INFO]

[jira] [Updated] (MENFORCER-477) failWhenParentIsSnapshot does not respect onlyWhenRelease

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MENFORCER-477:
--
Affects Version/s: 3.3.0

> failWhenParentIsSnapshot does not respect onlyWhenRelease
> -
>
> Key: MENFORCER-477
> URL: https://issues.apache.org/jira/browse/MENFORCER-477
> Project: Maven Enforcer Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.1, 3.3.0
>Reporter: Peter De Maeyer
>Priority: Major
>
> I have a snapshot project that has a snapshot parent.
> At release time, I want to use the enforcer plugin to make sure the release 
> version of my project only depends on release versions, including the parent, 
> so I use {{failWhenParentIsSnapshot=true}}.
> For snapshot versions of my project, I want to _allow_ snapshot dependencies 
> including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
> enforcer for snapshot versions.
> *Expected:* my snapshot project build succeeds with a snapshot parent.
> *Actual:* my snapshot project build _fails_ with a snapshot parent, despite 
> {{onlyWhenRelease=true}}.
> *Workaround:* disable {{failWhenParentIsSnapshot}}, but then I lose the 
> enforcement on the parent when I make a release of my project.
> I suspect that {{failWhenParentIsSnapshot}} does not take {{onlyWhenRelease}} 
> into account.
> The intuitive fix for me would be that the combination of both options 
> behaves as expected.
> I imagine that maybe it was a design choice to keep both options completely 
> independent of each other, so an acceptable alternative for me would be to 
> introduce yet another option, e.g. {{onlyWhenParentIsRelease}} that behaves 
> similar to {{onlyWhenRelease}} but applies to the parent only.
> {noformat}
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective settings
> [WARNING] Unrecognised tag: 'properties' (position: START_TAG seen 
> ...\n\t... @13:14)  @ /home/peter/.m2/settings.xml, 
> line 13, column 14
> [WARNING] 
> [INFO] Scanning for projects...
> [WARNING] 
> [WARNING] Some problems were encountered while building the effective model 
> for su.pernova:assertions-parent:pom:1.1.0-SNAPSHOT
> [WARNING] 'build.pluginManagement.plugins.plugin.(groupId:artifactId)' must 
> be unique but found duplicate declaration of plugin 
> org.apache.maven.plugins:maven-failsafe-plugin @ 
> su.pernova:bom:1.1.0-SNAPSHOT, 
> /home/peter/.m2/repository/su/pernova/bom/1.1.0-SNAPSHOT/bom-1.1.0-SNAPSHOT.pom,
>  line 263, column 17
> [WARNING] 
> [WARNING] It is highly recommended to fix these problems because they 
> threaten the stability of your build.
> [WARNING] 
> [WARNING] For this reason, future Maven versions might no longer support 
> building such malformed projects.
> [WARNING] 
> [INFO] Inspecting build with total of 5 modules...
> [INFO] Installing Nexus Staging features:
> [INFO]   ... total of 5 executions of maven-deploy-plugin replaced with 
> nexus-staging-maven-plugin
> [INFO] 
> 
> [INFO] Reactor Build Order:
> [INFO] 
> [INFO] Supernova Assertions - Parent  
> [pom]
> [INFO] Supernova Assertions - Main
> [jar]
> [INFO] Supernova Assertions - JUnit 4 
> [jar]
> [INFO] Supernova Assertions - JUnit 5 
> [jar]
> [INFO] Supernova Assertions - JUnit 4 + JUnit 5   
> [jar]
> [INFO] 
> [INFO] < su.pernova:assertions-parent 
> >
> [INFO] Building Supernova Assertions - Parent 1.1.0-SNAPSHOT  
> [1/5]
> [INFO] [ pom 
> ]-
> [INFO] 
> [INFO] --- maven-clean-plugin:3.2.0:clean (default-clean) @ assertions-parent 
> ---
> [INFO] 
> [INFO] --- flatten-maven-plugin:1.3.0:clean (flatten-clean) @ 
> assertions-parent ---
> [INFO] 
> [INFO] --- maven-enforcer-plugin:3.2.1:enforce 
> (enforce-no-snapshots-in-releases) @ assertions-parent ---
> [INFO] 
> 
> [INFO] Reactor Summary for Supernova Assertions - Parent 1.1.0-SNAPSHOT:
> [INFO] 
> [INFO] Supernova Assertions - Parent .. FAILURE [  0.464 
> s]
> [INFO] Supernova Assertions - Main  SKIPPED
> [INFO] Supernova Assertions - JUnit 4 . SKIPPED
> [INFO] Supernova Assertions - JUnit 5 . SKIPPED
> [INFO] Supernova Assertions - JUnit 4 + JUnit 5 ... SKIPPED
> [INFO] 
> 
> [INFO] BUILD FAILURE
> [INFO] 
> -

[jira] [Updated] (MENFORCER-477) failWhenParentIsSnapshot does not respect onlyWhenRelease

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MENFORCER-477:
--
Description: 
I have a snapshot project that has a snapshot parent.

At release time, I want to use the enforcer plugin to make sure the release 
version of my project only depends on release versions, including the parent, 
so I use {{failWhenParentIsSnapshot=true}}.

For snapshot versions of my project, I want to _allow_ snapshot dependencies 
including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
enforcer for snapshot versions.

*Expected:* my snapshot project build succeeds with a snapshot parent.

*Actual:* my snapshot project build _fails_ with a snapshot parent, despite 
{{onlyWhenRelease=true}}.

*Workaround:* disable {{failWhenParentIsSnapshot}}, but then I lose the 
enforcement on the parent when I make a release of my project.

I suspect that {{failWhenParentIsSnapshot}} does not take {{onlyWhenRelease}} 
into account.

The intuitive fix for me would be that the combination of both options behaves 
as expected.

I imagine that maybe it was a design choice to keep both options completely 
independent of each other, so an acceptable alternative for me would be to 
introduce yet another option, e.g. {{onlyWhenParentIsRelease}} that behaves 
similar to {{onlyWhenRelease}} but applies to the parent only.

{noformat}
[WARNING] 
[WARNING] Some problems were encountered while building the effective settings
[WARNING] Unrecognised tag: 'properties' (position: START_TAG seen 
...\n\t... @13:14)  @ /home/peter/.m2/settings.xml, line 
13, column 14
[WARNING] 
[INFO] Scanning for projects...
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for 
su.pernova:assertions-parent:pom:1.1.0-SNAPSHOT
[WARNING] 'build.pluginManagement.plugins.plugin.(groupId:artifactId)' must be 
unique but found duplicate declaration of plugin 
org.apache.maven.plugins:maven-failsafe-plugin @ su.pernova:bom:1.1.0-SNAPSHOT, 
/home/peter/.m2/repository/su/pernova/bom/1.1.0-SNAPSHOT/bom-1.1.0-SNAPSHOT.pom,
 line 263, column 17
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten 
the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support 
building such malformed projects.
[WARNING] 
[INFO] Inspecting build with total of 5 modules...
[INFO] Installing Nexus Staging features:
[INFO]   ... total of 5 executions of maven-deploy-plugin replaced with 
nexus-staging-maven-plugin
[INFO] 
[INFO] Reactor Build Order:
[INFO] 
[INFO] Supernova Assertions - Parent  [pom]
[INFO] Supernova Assertions - Main[jar]
[INFO] Supernova Assertions - JUnit 4 [jar]
[INFO] Supernova Assertions - JUnit 5 [jar]
[INFO] Supernova Assertions - JUnit 4 + JUnit 5   [jar]
[INFO] 
[INFO] < su.pernova:assertions-parent >
[INFO] Building Supernova Assertions - Parent 1.1.0-SNAPSHOT  [1/5]
[INFO] [ pom ]-
[INFO] 
[INFO] --- maven-clean-plugin:3.2.0:clean (default-clean) @ assertions-parent 
---
[INFO] 
[INFO] --- flatten-maven-plugin:1.3.0:clean (flatten-clean) @ assertions-parent 
---
[INFO] 
[INFO] --- maven-enforcer-plugin:3.2.1:enforce 
(enforce-no-snapshots-in-releases) @ assertions-parent ---
[INFO] 
[INFO] Reactor Summary for Supernova Assertions - Parent 1.1.0-SNAPSHOT:
[INFO] 
[INFO] Supernova Assertions - Parent .. FAILURE [  0.464 s]
[INFO] Supernova Assertions - Main  SKIPPED
[INFO] Supernova Assertions - JUnit 4 . SKIPPED
[INFO] Supernova Assertions - JUnit 5 . SKIPPED
[INFO] Supernova Assertions - JUnit 4 + JUnit 5 ... SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  1.023 s
[INFO] Finished at: 2023-04-06T21:12:23+02:00
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce 
(enforce-no-snapshots-in-releases) on project assertions-parent: 
[ERROR] Rule 0: org.apache.maven.enforcer.rules.dependency.RequireReleaseDeps 
failed with message:
[ERROR] Parent Cannot be a snapshot: su.pernova:bom:pom:1.1.0-SNAPSHOT
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
swit

[jira] [Updated] (MENFORCER-477) failWhenParentIsSnapshot does not respect onlyWhenRelease

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MENFORCER-477:
--
Description: 
I have a snapshot project that has a snapshot parent.

At release time, I want to use the enforcer plugin to make sure the release 
version of my project only depends on release versions, including the parent, 
so I use {{failWhenParentIsSnapshot=true}}.

For snapshot versions of my project, I want to _allow_ snapshot dependencies 
including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
enforcer for snapshot versions.

*Expected:* my snapshot project build succeeds with a snapshot parent.

*Actual:* my snapshot project build _fails_ with a snapshot parent, despite 
{{onlyWhenRelease=true}}.

I suspect that {{failWhenParentIsSnapshot}} does not take {{onlyWhenRelease}} 
into account.

The intuitive fix for me would be that the combination of both options behaves 
as expected.

I imagine that maybe it was a design choice to keep both options completely 
independent of each other, so an acceptable alternative for me would be to 
introduce yet another option, e.g. {{onlyWhenParentIsRelease}} that behaves 
similar to {{onlyWhenRelease}} but applies to the parent only.

{noformat}
[WARNING] 
[WARNING] Some problems were encountered while building the effective settings
[WARNING] Unrecognised tag: 'properties' (position: START_TAG seen 
...\n\t... @13:14)  @ /home/peter/.m2/settings.xml, line 
13, column 14
[WARNING] 
[INFO] Scanning for projects...
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for 
su.pernova:assertions-parent:pom:1.1.0-SNAPSHOT
[WARNING] 'build.pluginManagement.plugins.plugin.(groupId:artifactId)' must be 
unique but found duplicate declaration of plugin 
org.apache.maven.plugins:maven-failsafe-plugin @ su.pernova:bom:1.1.0-SNAPSHOT, 
/home/peter/.m2/repository/su/pernova/bom/1.1.0-SNAPSHOT/bom-1.1.0-SNAPSHOT.pom,
 line 263, column 17
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten 
the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support 
building such malformed projects.
[WARNING] 
[INFO] Inspecting build with total of 5 modules...
[INFO] Installing Nexus Staging features:
[INFO]   ... total of 5 executions of maven-deploy-plugin replaced with 
nexus-staging-maven-plugin
[INFO] 
[INFO] Reactor Build Order:
[INFO] 
[INFO] Supernova Assertions - Parent  [pom]
[INFO] Supernova Assertions - Main[jar]
[INFO] Supernova Assertions - JUnit 4 [jar]
[INFO] Supernova Assertions - JUnit 5 [jar]
[INFO] Supernova Assertions - JUnit 4 + JUnit 5   [jar]
[INFO] 
[INFO] < su.pernova:assertions-parent >
[INFO] Building Supernova Assertions - Parent 1.1.0-SNAPSHOT  [1/5]
[INFO] [ pom ]-
[INFO] 
[INFO] --- maven-clean-plugin:3.2.0:clean (default-clean) @ assertions-parent 
---
[INFO] 
[INFO] --- flatten-maven-plugin:1.3.0:clean (flatten-clean) @ assertions-parent 
---
[INFO] 
[INFO] --- maven-enforcer-plugin:3.2.1:enforce 
(enforce-no-snapshots-in-releases) @ assertions-parent ---
[INFO] 
[INFO] Reactor Summary for Supernova Assertions - Parent 1.1.0-SNAPSHOT:
[INFO] 
[INFO] Supernova Assertions - Parent .. FAILURE [  0.464 s]
[INFO] Supernova Assertions - Main  SKIPPED
[INFO] Supernova Assertions - JUnit 4 . SKIPPED
[INFO] Supernova Assertions - JUnit 5 . SKIPPED
[INFO] Supernova Assertions - JUnit 4 + JUnit 5 ... SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  1.023 s
[INFO] Finished at: 2023-04-06T21:12:23+02:00
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce 
(enforce-no-snapshots-in-releases) on project assertions-parent: 
[ERROR] Rule 0: org.apache.maven.enforcer.rules.dependency.RequireReleaseDeps 
failed with message:
[ERROR] Parent Cannot be a snapshot: su.pernova:bom:pom:1.1.0-SNAPSHOT
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and pos

[jira] [Updated] (MENFORCER-477) failWhenParentIsSnapshot does not respect onlyWhenRelease

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MENFORCER-477:
--
Description: 
I have a snapshot project that has a snapshot parent.

At release time, I want to use the enforcer plugin to make sure the release 
version of my project only depends on release versions, including the parent, 
so I use {{failWhenParentIsSnapshot=true}}.

For snapshot versions of my project, I want to _allow_ snapshot dependencies 
including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
enforcer for snapshot versions.

*Expected:* my snapshot project build succeeds with a snapshot parent.

*Actual:* my snapshot project build _fails_ with a snapshot parent, despite 
{{onlyWhenRelease=true}}.

I suspect that {{failWhenParentIsSnapshot}} does not take {{onlyWhenRelease}} 
into account.

The intuitive fix for me would be that the combination of both options behaves 
as expected.

I imagine that maybe it was a design choice to keep both options completely 
independent of each other, so an acceptable alternative for me would be to 
introduce yet another option, e.g. {{onlyWhenParentIsRelease}} that behaves 
similar to {{onlyWhenRelease}} but applies to the parent only.

{noformat}
[WARNING] 
[WARNING] Some problems were encountered while building the effective settings
[WARNING] Unrecognised tag: 'properties' (position: START_TAG seen 
...\n\t... @13:14)  @ /home/peter/.m2/settings.xml, line 
13, column 14
[WARNING] 
[INFO] Scanning for projects...
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for 
su.pernova:assertions-parent:pom:1.1.0-SNAPSHOT
[WARNING] 'build.pluginManagement.plugins.plugin.(groupId:artifactId)' must be 
unique but found duplicate declaration of plugin 
org.apache.maven.plugins:maven-failsafe-plugin @ su.pernova:bom:1.1.0-SNAPSHOT, 
/home/peter/.m2/repository/su/pernova/bom/1.1.0-SNAPSHOT/bom-1.1.0-SNAPSHOT.pom,
 line 263, column 17
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten 
the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support 
building such malformed projects.
[WARNING] 
[INFO] Inspecting build with total of 5 modules...
[INFO] Installing Nexus Staging features:
[INFO]   ... total of 5 executions of maven-deploy-plugin replaced with 
nexus-staging-maven-plugin
[INFO] 
[INFO] Reactor Build Order:
[INFO] 
[INFO] Supernova Assertions - Parent  [pom]
[INFO] Supernova Assertions - Main[jar]
[INFO] Supernova Assertions - JUnit 4 [jar]
[INFO] Supernova Assertions - JUnit 5 [jar]
[INFO] Supernova Assertions - JUnit 4 + JUnit 5   [jar]
[INFO] 
[INFO] < su.pernova:assertions-parent >
[INFO] Building Supernova Assertions - Parent 1.1.0-SNAPSHOT  [1/5]
[INFO] [ pom ]-
[INFO] 
[INFO] --- maven-clean-plugin:3.2.0:clean (default-clean) @ assertions-parent 
---
[INFO] 
[INFO] --- flatten-maven-plugin:1.3.0:clean (flatten-clean) @ assertions-parent 
---
[INFO] 
[INFO] --- maven-enforcer-plugin:3.2.1:enforce 
(enforce-no-snapshots-in-releases) @ assertions-parent ---
[INFO] 
[INFO] Reactor Summary for Supernova Assertions - Parent 1.1.0-SNAPSHOT:
[INFO] 
[INFO] Supernova Assertions - Parent .. FAILURE [  0.464 s]
[INFO] Supernova Assertions - Main  SKIPPED
[INFO] Supernova Assertions - JUnit 4 . SKIPPED
[INFO] Supernova Assertions - JUnit 5 . SKIPPED
[INFO] Supernova Assertions - JUnit 4 + JUnit 5 ... SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  1.023 s
[INFO] Finished at: 2023-04-06T21:12:23+02:00
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce 
(enforce-no-snapshots-in-releases) on project assertions-parent: 
[ERROR] Rule 0: org.apache.maven.enforcer.rules.dependency.RequireReleaseDeps 
failed with message:
[ERROR] Parent Cannot be a snapshot: su.pernova:bom:pom:1.1.0-SNAPSHOT
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and pos

[jira] [Updated] (MENFORCER-477) failWhenParentIsSnapshot does not respect onlyWhenRelease

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MENFORCER-477:
--
Description: 
I have a snapshot project that has a snapshot parent.

At release time, I want to use the enforcer plugin to make sure the release 
version of my project only depends on release versions, including the parent, 
so I use {{failWhenParentIsSnapshot=true}}.

For snapshot versions of my project, I want to _allow_ snapshot dependencies 
including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
enforcer for snapshot versions.

*Expected:* my snapshot project build succeeds with a snapshot parent.

*Actual:* my snapshot project build _fails_ with a snapshot parent, despite 
{{onlyWhenRelease=true}}.

I suspect that {{failWhenParentIsSnapshot}} does not take {{onlyWhenRelease}} 
into account.

The intuitive fix for me would be that the combination of both options behaves 
as expected.

I imagine that maybe it is a design choice to keep both options completely 
independent of each other, so an acceptable alternative for me would be to 
introduce yet another option, e.g. {{onlyWhenParentIsRelease}} that behaves 
similar to {{onlyWhenRelease}} but applies to the parent only.

{noformat}
[WARNING] 
[WARNING] Some problems were encountered while building the effective settings
[WARNING] Unrecognised tag: 'properties' (position: START_TAG seen 
...\n\t... @13:14)  @ /home/peter/.m2/settings.xml, line 
13, column 14
[WARNING] 
[INFO] Scanning for projects...
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for 
su.pernova:assertions-parent:pom:1.1.0-SNAPSHOT
[WARNING] 'build.pluginManagement.plugins.plugin.(groupId:artifactId)' must be 
unique but found duplicate declaration of plugin 
org.apache.maven.plugins:maven-failsafe-plugin @ su.pernova:bom:1.1.0-SNAPSHOT, 
/home/peter/.m2/repository/su/pernova/bom/1.1.0-SNAPSHOT/bom-1.1.0-SNAPSHOT.pom,
 line 263, column 17
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten 
the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support 
building such malformed projects.
[WARNING] 
[INFO] Inspecting build with total of 5 modules...
[INFO] Installing Nexus Staging features:
[INFO]   ... total of 5 executions of maven-deploy-plugin replaced with 
nexus-staging-maven-plugin
[INFO] 
[INFO] Reactor Build Order:
[INFO] 
[INFO] Supernova Assertions - Parent  [pom]
[INFO] Supernova Assertions - Main[jar]
[INFO] Supernova Assertions - JUnit 4 [jar]
[INFO] Supernova Assertions - JUnit 5 [jar]
[INFO] Supernova Assertions - JUnit 4 + JUnit 5   [jar]
[INFO] 
[INFO] < su.pernova:assertions-parent >
[INFO] Building Supernova Assertions - Parent 1.1.0-SNAPSHOT  [1/5]
[INFO] [ pom ]-
[INFO] 
[INFO] --- maven-clean-plugin:3.2.0:clean (default-clean) @ assertions-parent 
---
[INFO] 
[INFO] --- flatten-maven-plugin:1.3.0:clean (flatten-clean) @ assertions-parent 
---
[INFO] 
[INFO] --- maven-enforcer-plugin:3.2.1:enforce 
(enforce-no-snapshots-in-releases) @ assertions-parent ---
[INFO] 
[INFO] Reactor Summary for Supernova Assertions - Parent 1.1.0-SNAPSHOT:
[INFO] 
[INFO] Supernova Assertions - Parent .. FAILURE [  0.464 s]
[INFO] Supernova Assertions - Main  SKIPPED
[INFO] Supernova Assertions - JUnit 4 . SKIPPED
[INFO] Supernova Assertions - JUnit 5 . SKIPPED
[INFO] Supernova Assertions - JUnit 4 + JUnit 5 ... SKIPPED
[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time:  1.023 s
[INFO] Finished at: 2023-04-06T21:12:23+02:00
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-enforcer-plugin:3.2.1:enforce 
(enforce-no-snapshots-in-releases) on project assertions-parent: 
[ERROR] Rule 0: org.apache.maven.enforcer.rules.dependency.RequireReleaseDeps 
failed with message:
[ERROR] Parent Cannot be a snapshot: su.pernova:bom:pom:1.1.0-SNAPSHOT
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and poss

[jira] [Updated] (MENFORCER-477) failWhenParentIsSnapshot does not respect onlyWhenRelease

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MENFORCER-477:
--
Description: 
I have a snapshot project that has a snapshot parent.

At release time, I want to use the enforcer plugin to make sure the release 
version of my project only depends on release versions, including the parent, 
so I use {{failWhenParentIsSnapshot=true}}.

For snapshot versions of my project, I want to _allow_ snapshot dependencies 
including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
enforcer for snapshot versions.

*Expected:* my snapshot project build succeeds with a snapshot parent.

*Actual:* my snapshot project build _fails_ with a snapshot parent, despite 
{{onlyWhenRelease=true}}.

I suspect that {{failWhenParentIsSnapshot}} does not take {{onlyWhenRelease}} 
into account.

The intuitive fix for me would be that the combination of both options behaves 
as expected.

I imagine that maybe it is a design choice to keep both options completely 
independent of each other, so an acceptable alternative for me would be to 
introduce yet another option, e.g. {{onlyWhenParentIsRelease}} that behaves 
similar to {{onlyWhenRelease}} but applies to the parent only.

  was:
I have a snapshot project that has a snapshot parent.

At release time, I want to use the enforcer plugin to make sure the release 
version of my project only depends on release versions, including the parent, 
so I use {{failWhenParentIsSnapshot=true}}.

For snapshot versions of my project, I want to _allow_ snapshot dependencies 
including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
enforcer for snapshot versions.

Expected: my snapshot project build succeeds with a snapshot parent.

Actual: my snapshot project build _fails_ with a snapshot parent, despite 
{{onlyWhenRelease=true}}.

I suspect that {{failWhenParentIsSnapshot}} does not take {{onlyWhenRelease}} 
into account.

The intuitive fix for me would be that the combination of both options behaves 
as expected.

I imagine that maybe it is a design choice to keep both options completely 
independent of each other, so an acceptable alternative for me would be to 
introduce yet another option, e.g. {{onlyWhenParentIsRelease}} that behaves 
similar to {{onlyWhenRelease}} but applies to the parent only.


> failWhenParentIsSnapshot does not respect onlyWhenRelease
> -
>
> Key: MENFORCER-477
> URL: https://issues.apache.org/jira/browse/MENFORCER-477
> Project: Maven Enforcer Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Peter De Maeyer
>Priority: Major
>
> I have a snapshot project that has a snapshot parent.
> At release time, I want to use the enforcer plugin to make sure the release 
> version of my project only depends on release versions, including the parent, 
> so I use {{failWhenParentIsSnapshot=true}}.
> For snapshot versions of my project, I want to _allow_ snapshot dependencies 
> including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
> enforcer for snapshot versions.
> *Expected:* my snapshot project build succeeds with a snapshot parent.
> *Actual:* my snapshot project build _fails_ with a snapshot parent, despite 
> {{onlyWhenRelease=true}}.
> I suspect that {{failWhenParentIsSnapshot}} does not take {{onlyWhenRelease}} 
> into account.
> The intuitive fix for me would be that the combination of both options 
> behaves as expected.
> I imagine that maybe it is a design choice to keep both options completely 
> independent of each other, so an acceptable alternative for me would be to 
> introduce yet another option, e.g. {{onlyWhenParentIsRelease}} that behaves 
> similar to {{onlyWhenRelease}} but applies to the parent only.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (MENFORCER-477) failWhenParentIsSnapshot does not respect onlyWhenRelease

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MENFORCER-477:
--
Description: 
I have a snapshot project that has a snapshot parent.

At release time, I want to use the enforcer plugin to make sure the release 
version of my project only depends on release versions, including the parent, 
so I use {{failWhenParentIsSnapshot=true}}.

For snapshot versions of my project, I want to _allow_ snapshot dependencies 
including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
enforcer for snapshot versions.

Expected: my snapshot project build succeeds with a snapshot parent.

Actual: my snapshot project build _fails_ with a snapshot parent, despite 
{{onlyWhenRelease=true}}.

I suspect that {{failWhenParentIsSnapshot}} does not take {{onlyWhenRelease}} 
into account.

The intuitive fix for me would be that the combination of both options behaves 
as expected.

I imagine that maybe it is a design choice to keep both options completely 
independent of each other, so an acceptable alternative for me would be to 
introduce yet another option, e.g. {{onlyWhenParentIsRelease}} that behaves 
similar to {{onlyWhenRelease}} but applies to the parent only.

  was:
I have a snapshot project that has a snapshot parent.

At release time, I want to use the enforcer plugin to make sure the release 
version of my project only depends on release versions, including the parent. 
So I use {{failWhenParentIsSnapshot=true}}.

For snapshot versions of my project, I want to _allow_ snapshot dependencies 
including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
enforcer for snapshot versions.

Expected: my snapshot project build succeeds with a snapshot parent.

Actual: my snapshot project build _fails_ with a snapshot parent, despite 
{{onlyWhenRelease=true}}.

I suspect that {{failWhenParentIsSnapshot}} does not take {{onlyWhenRelease}} 
into account.

The intuitive fix for me would be that the combination of both options behaves 
as expected.

I imagine that maybe it is a design choice to keep both options completely 
independent of each other, so an acceptable alternative for me would be to 
introduce yet another option, e.g. {{onlyWhenParentIsRelease}} that behaves 
similar to {{onlyWhenRelease}} but applies to the parent only.


> failWhenParentIsSnapshot does not respect onlyWhenRelease
> -
>
> Key: MENFORCER-477
> URL: https://issues.apache.org/jira/browse/MENFORCER-477
> Project: Maven Enforcer Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Peter De Maeyer
>Priority: Major
>
> I have a snapshot project that has a snapshot parent.
> At release time, I want to use the enforcer plugin to make sure the release 
> version of my project only depends on release versions, including the parent, 
> so I use {{failWhenParentIsSnapshot=true}}.
> For snapshot versions of my project, I want to _allow_ snapshot dependencies 
> including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
> enforcer for snapshot versions.
> Expected: my snapshot project build succeeds with a snapshot parent.
> Actual: my snapshot project build _fails_ with a snapshot parent, despite 
> {{onlyWhenRelease=true}}.
> I suspect that {{failWhenParentIsSnapshot}} does not take {{onlyWhenRelease}} 
> into account.
> The intuitive fix for me would be that the combination of both options 
> behaves as expected.
> I imagine that maybe it is a design choice to keep both options completely 
> independent of each other, so an acceptable alternative for me would be to 
> introduce yet another option, e.g. {{onlyWhenParentIsRelease}} that behaves 
> similar to {{onlyWhenRelease}} but applies to the parent only.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (MENFORCER-477) failWhenParentIsSnapshot does not respect onlyWhenRelease

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MENFORCER-477:
--
Description: 
I have a snapshot project that has a snapshot parent.

At release time, I want to use the enforcer plugin to make sure the release 
version of my project only depends on release versions, including the parent. 
So I use {{failWhenParentIsSnapshot=true}}.

For snapshot versions of my project, I want to _allow_ snapshot dependencies 
including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
enforcer for snapshot versions.

Expected: my snapshot project build succeeds with a snapshot parent.

Actual: my snapshot project build _fails_ with a snapshot parent, despite 
{{onlyWhenRelease=true}}.

I suspect that {{failWhenParentIsSnapshot}} does not take {{onlyWhenRelease}} 
into account.

The intuitive fix for me would be that the combination of both options behaves 
as expected.

I imagine that maybe it is a design choice to keep both options completely 
independent of each other, so an acceptable alternative for me would be to 
introduce yet another option, e.g. {{onlyWhenParentIsRelease}} that behaves 
similar to {{onlyWhenRelease}} but applies to the parent only.

  was:
I have a snapshot project that has a snapshot parent.

At release time, I want to use the enforcer plugin to make sure the release 
version of my project only depends on release versions, including the parent. 
So I use {{failWhenParentIsSnapshot=true}}.

For snapshot versions of my project, I want to _allow_ snapshot dependencies 
including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
enforcer for snapshot versions.

Expected: my snapshot project build succeeds with a snapshot parent.

Actual: my snapshot project build _fails_ with a snapshot parent, despite 
{{onlyWhenRelease=true}}.

I suspect that {{failWhenParentIsSnapshot}} does not take {{onlyWhenRelease}} 
into account.

The intuitive fix for me would be that the combination of both options behaves 
as expected.

I imagine that maybe it is a design choice to keep both options completely 
independent of each other, so an acceptable alternative for me would be to 
introduce yet another option, e.g. {{onlyWhenParentIsRelase}} that behaves 
similar to {{onlyWhenRelease}} but applies to the parent only.


> failWhenParentIsSnapshot does not respect onlyWhenRelease
> -
>
> Key: MENFORCER-477
> URL: https://issues.apache.org/jira/browse/MENFORCER-477
> Project: Maven Enforcer Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Peter De Maeyer
>Priority: Major
>
> I have a snapshot project that has a snapshot parent.
> At release time, I want to use the enforcer plugin to make sure the release 
> version of my project only depends on release versions, including the parent. 
> So I use {{failWhenParentIsSnapshot=true}}.
> For snapshot versions of my project, I want to _allow_ snapshot dependencies 
> including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
> enforcer for snapshot versions.
> Expected: my snapshot project build succeeds with a snapshot parent.
> Actual: my snapshot project build _fails_ with a snapshot parent, despite 
> {{onlyWhenRelease=true}}.
> I suspect that {{failWhenParentIsSnapshot}} does not take {{onlyWhenRelease}} 
> into account.
> The intuitive fix for me would be that the combination of both options 
> behaves as expected.
> I imagine that maybe it is a design choice to keep both options completely 
> independent of each other, so an acceptable alternative for me would be to 
> introduce yet another option, e.g. {{onlyWhenParentIsRelease}} that behaves 
> similar to {{onlyWhenRelease}} but applies to the parent only.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (MENFORCER-477) failWhenParentIsSnapshot does not respect onlyWhenRelease

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MENFORCER-477:
--
Description: 
I have a snapshot project that has a snapshot parent.

At release time, I want to use the enforcer plugin to make sure the release 
version of my project only depends on release versions, including the parent. 
So I use {{failWhenParentIsSnapshot=true}}.

For snapshot versions of my project, I want to _allow_ snapshot dependencies 
including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
enforcer for snapshot versions.

Expected: my snapshot project build succeeds with a snapshot parent.

Actual: my snapshot project build _fails_ with a snapshot parent, despite 
{{onlyWhenRelease=true}}.

I suspect that {{failWhenParentIsSnapshot}} does not take {{onlyWhenRelease}} 
into account.

The intuitive fix for me would be that the combination of both options behaves 
as expected.

I imagine that maybe it is a design choice to keep both options completely 
independent of each other, so an acceptable alternative for me would be to 
introduce yet another option, e.g. {{onlyWhenParentIsRelase}} that behaves 
similar to {{onlyWhenRelease}} but applies to the parent only.

  was:
I have a snapshot project that has a snapshot parent.

At release time, I want to use the enforcer plugin to make sure the release 
version of my project only depends on release versions, including the parent. 
So I use {{failWhenParentIsSnapshot=true}}.

For snapshot versions of my project, I want to _allow_ snapshot dependencies 
including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
enforcer for snapshot versions.

Expected: my snapshot project build succeeds with a snapshot parent.

Actual: my snapshot project build _fails_ with a snapshot parent, despite the 
{{onlyWhenRelease=true}}.

I suspect that {{failWhenParentIsSnapshot}} does not take the 
{{onlyWhenRelease}} into account.

The intuitive fix for me would be that the combination of both options behaves 
as expected.

I imagine that maybe it is a design choice to keep both options completely 
independent of each other, so an acceptable alternative for me would be to 
introduce yet another option, e.g. {{onlyWhenParentIsRelase}} that behaves 
similar to {{onlyWhenRelease}} but applies to the parent only.


> failWhenParentIsSnapshot does not respect onlyWhenRelease
> -
>
> Key: MENFORCER-477
> URL: https://issues.apache.org/jira/browse/MENFORCER-477
> Project: Maven Enforcer Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Peter De Maeyer
>Priority: Major
>
> I have a snapshot project that has a snapshot parent.
> At release time, I want to use the enforcer plugin to make sure the release 
> version of my project only depends on release versions, including the parent. 
> So I use {{failWhenParentIsSnapshot=true}}.
> For snapshot versions of my project, I want to _allow_ snapshot dependencies 
> including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
> enforcer for snapshot versions.
> Expected: my snapshot project build succeeds with a snapshot parent.
> Actual: my snapshot project build _fails_ with a snapshot parent, despite 
> {{onlyWhenRelease=true}}.
> I suspect that {{failWhenParentIsSnapshot}} does not take {{onlyWhenRelease}} 
> into account.
> The intuitive fix for me would be that the combination of both options 
> behaves as expected.
> I imagine that maybe it is a design choice to keep both options completely 
> independent of each other, so an acceptable alternative for me would be to 
> introduce yet another option, e.g. {{onlyWhenParentIsRelase}} that behaves 
> similar to {{onlyWhenRelease}} but applies to the parent only.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (MENFORCER-477) failWhenParentIsSnapshot does not respect onlyWhenRelease

[Peter De Maeyer (Jira)]

Peter De Maeyer created MENFORCER-477:
-

 Summary: failWhenParentIsSnapshot does not respect onlyWhenRelease
 Key: MENFORCER-477
 URL: https://issues.apache.org/jira/browse/MENFORCER-477
 Project: Maven Enforcer Plugin
  Issue Type: Bug
Affects Versions: 3.2.1
Reporter: Peter De Maeyer


I have a snapshot project that has a snapshot parent.

At release time, I want to use the enforcer plugin to make sure the release 
version of my project only depends on release versions, including the parent. 
So I use{{failWhenParentIsSnapshot=true}}.

For snapshot versions of my project, I want to _allow_ snapshot dependencies 
including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
enforcer for snapshot versions.

Expected: my snapshot project build succeeds with a snapshot parent.

Actual: my snapshot project build _fails_ with a snapshot parent, despite the 
{{onlyWhenRelease=true}}.

I suspect that {{failWhenParentIsSnapshot}} does not take the 
{{onlyWhenRelease}} into account.

The intuitive fix for me would be that the combination of both options behaves 
as expected.

I imagine that maybe it is a design choice to keep both options completely 
independent of each other, so an acceptable alternative for me would be to 
introduce yet another option, e.g. {{onlyWhenParentIsRelase}} that behaves 
similar to {{onlyWhenRelease}} but applies to the parent only.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (MENFORCER-477) failWhenParentIsSnapshot does not respect onlyWhenRelease

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MENFORCER-477:
--
Description: 
I have a snapshot project that has a snapshot parent.

At release time, I want to use the enforcer plugin to make sure the release 
version of my project only depends on release versions, including the parent. 
So I use {{failWhenParentIsSnapshot=true}}.

For snapshot versions of my project, I want to _allow_ snapshot dependencies 
including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
enforcer for snapshot versions.

Expected: my snapshot project build succeeds with a snapshot parent.

Actual: my snapshot project build _fails_ with a snapshot parent, despite the 
{{onlyWhenRelease=true}}.

I suspect that {{failWhenParentIsSnapshot}} does not take the 
{{onlyWhenRelease}} into account.

The intuitive fix for me would be that the combination of both options behaves 
as expected.

I imagine that maybe it is a design choice to keep both options completely 
independent of each other, so an acceptable alternative for me would be to 
introduce yet another option, e.g. {{onlyWhenParentIsRelase}} that behaves 
similar to {{onlyWhenRelease}} but applies to the parent only.

  was:
I have a snapshot project that has a snapshot parent.

At release time, I want to use the enforcer plugin to make sure the release 
version of my project only depends on release versions, including the parent. 
So I use{{failWhenParentIsSnapshot=true}}.

For snapshot versions of my project, I want to _allow_ snapshot dependencies 
including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
enforcer for snapshot versions.

Expected: my snapshot project build succeeds with a snapshot parent.

Actual: my snapshot project build _fails_ with a snapshot parent, despite the 
{{onlyWhenRelease=true}}.

I suspect that {{failWhenParentIsSnapshot}} does not take the 
{{onlyWhenRelease}} into account.

The intuitive fix for me would be that the combination of both options behaves 
as expected.

I imagine that maybe it is a design choice to keep both options completely 
independent of each other, so an acceptable alternative for me would be to 
introduce yet another option, e.g. {{onlyWhenParentIsRelase}} that behaves 
similar to {{onlyWhenRelease}} but applies to the parent only.


> failWhenParentIsSnapshot does not respect onlyWhenRelease
> -
>
> Key: MENFORCER-477
> URL: https://issues.apache.org/jira/browse/MENFORCER-477
> Project: Maven Enforcer Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Peter De Maeyer
>Priority: Major
>
> I have a snapshot project that has a snapshot parent.
> At release time, I want to use the enforcer plugin to make sure the release 
> version of my project only depends on release versions, including the parent. 
> So I use {{failWhenParentIsSnapshot=true}}.
> For snapshot versions of my project, I want to _allow_ snapshot dependencies 
> including snapshot parent, so I use {{onlyWhenRelease=true}} to disable the 
> enforcer for snapshot versions.
> Expected: my snapshot project build succeeds with a snapshot parent.
> Actual: my snapshot project build _fails_ with a snapshot parent, despite the 
> {{onlyWhenRelease=true}}.
> I suspect that {{failWhenParentIsSnapshot}} does not take the 
> {{onlyWhenRelease}} into account.
> The intuitive fix for me would be that the combination of both options 
> behaves as expected.
> I imagine that maybe it is a design choice to keep both options completely 
> independent of each other, so an acceptable alternative for me would be to 
> introduce yet another option, e.g. {{onlyWhenParentIsRelase}} that behaves 
> similar to {{onlyWhenRelease}} but applies to the parent only.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MINSTALL-151) Projects without primary artifacts, but with attachment artifacts fail install

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17627326#comment-17627326
 ] 

Peter De Maeyer edited comment on MINSTALL-151 at 11/1/22 8:53 PM:
---

My use case: some of my submodules in my multi-module project only produce 
artifacts of type "test-jar". In other words, they don't have produce a main 
{{my-artifact-1.0.0.jar}}, but they _do_ produce a 
{{my-artifact-1.0.0-tests.jar}}. In my parent POM I have a section which fits 
for any module that produces either or both a main or test artifact, as 
supported by the default {{maven-jar-plugin}}:

{code:xml}

maven-jar-plugin



default-jar

jar



true




test-jar



true




{code}

{{maven-install-plugin}} fails with the above "The packaging plugin for this 
project did not assign a main file to the project but it has attachments. 
Change packaging to 'pom'."

The advice is wrong, I can't change packaging to 'pom' because then it won't 
compile nor run my tests.


was (Author: peterdm):
My use case: some of my submodules in my multi-module project only produce 
artifacts of type "test-jar". In other words, they don't have produce a main 
{{my-artifact-1.0.0.jar}}, but they _do_ produce a 
{{my-artifact-1.0.0-tests.jar}}. In my parent POM I have a section which fits 
for any module that produces either or both a main or test artifact, as 
supported by the default {{maven-jar-plugin}}:

{code:xml}

maven-jar-plugin



default-jar

jar



true




test-jar



true




{code}

> Projects without primary artifacts, but with attachment artifacts fail install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151-example-PeterSchloemer.zip, minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the 
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the 
> following error occurs:
> {code:java}
> Failed to execute goal 
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install 
> (default-install) on project : NoFileAssignedException: The 
> packaging plugin for this project did not assign a main file to the project 
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (MINSTALL-151) Projects without primary artifacts, but with attachment artifacts fail install

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MINSTALL-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17627326#comment-17627326
 ] 

Peter De Maeyer commented on MINSTALL-151:
--

My use case: some of my submodules in my multi-module project only produce 
artifacts of type "test-jar". In other words, they don't have produce a main 
{{my-artifact-1.0.0.jar}}, but they _do_ produce a 
{{my-artifact-1.0.0-tests.jar}}. In my parent POM I have a section which fits 
for any module that produces either or both a main or test artifact, as 
supported by the default {{maven-jar-plugin}}:

{code:xml}

maven-jar-plugin



default-jar

jar



true




test-jar



true




{code}

> Projects without primary artifacts, but with attachment artifacts fail install
> --
>
> Key: MINSTALL-151
> URL: https://issues.apache.org/jira/browse/MINSTALL-151
> Project: Maven Install Plugin
>  Issue Type: Bug
>Affects Versions: 3.0.0-M1
>Reporter: Peter Huffer
>Priority: Major
> Attachments: minstall-151-example-PeterSchloemer.zip, minstall-151.zip
>
>
> I have a module which has a packaging of {{feature}} from the 
> {{karaf-maven-plugin}}. When running the {{mvn install}} command, the 
> following error occurs:
> {code:java}
> Failed to execute goal 
> org.apache.maven.plugins:maven-install-plugin:3.0.0-M1:install 
> (default-install) on project : NoFileAssignedException: The 
> packaging plugin for this project did not assign a main file to the project 
> but it has attachments. Change packaging to 'pom'. -> [Help 1]
> {code}
> Reverting back to version {{2.5.2}} made the {{mvn install}} command succeed.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (MNG-6608) Why can't project.version in pom.xml be set as a variable?

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251336#comment-17251336
 ] 

Peter De Maeyer edited comment on MNG-6608 at 12/18/20, 9:34 PM:
-

My observation: for practical purposes, the ci-friendly feature of Maven 
produces broken POMs.
The POMs are broken because the variables such as ${revision} are not resolved 
in the deployed POM, which breaks dependent projects.
The workaround is to use the org.codehaus.mojo's maven-flatten-plugin, which 
even has an option resolveCiFriendliesOnly 
specifically for that purpose.

CI-friendly is a great feature in Maven, I use it all the time, but it's 
half-baked because it requires an org.codehaus.mojo to make it work.
Without the flatten-maven-plugin, it just doesn't work, which is a shame.
Ideally, the feature would just work without requiring an org.codehaus.mojo 
plugin.

I'm going to take a stab at fixing this.


was (Author: peterdm):
My observation: for practical purposes, the ci-friendly feature of Maven 
produces broken POMs.
The POMs are broken because the variables such as ${revision} are not resolved 
in the deployed POM, which breaks dependent projects.
The workaround is to use the org.codehaus.mojo's maven-flatten-plugin, which 
even have an option resolveCiFriendliesOnly 
specifically for that purpose.

CI-friendly is a great feature in Maven, I use it all the time, but it's 
half-baked because it requires an org.codehaus.mojo to make it work.
Without the flatten-maven-plugin, it just doesn't work, which is a shame.
Ideally, the feature would just work without requiring an org.codehaus.mojo 
plugin.

I'm going to take a stab at fixing this.

> Why can't project.version in pom.xml be set as a variable?
> --
>
> Key: MNG-6608
> URL: https://issues.apache.org/jira/browse/MNG-6608
> Project: Maven
>  Issue Type: New Feature
>  Components: Design, Patterns & Best Practices
>Affects Versions: 3.6.0
>Reporter: chenxiaoyong
>Assignee: Robert Scholte
>Priority: Major
> Attachments: example.zip, revision-test.zip
>
>
> we need modify project.version in pom.xml  when we merge source code from 
> develope branch to master branch in git. it‘s troublesome!
> Why can't project.version in pom.xml be set as a variable?
> for example:
> {code:xml}
> 
> 4.0.0
> org.example
> example
> ${project-version}
> jar
> 
> 1.0.0-SNAPSHOT
> 
> 
> 
> 
> dev
> 
> dev
> 1.0.0-SNAPSHOT
> 
> 
> true
> 
> 
> 
> 
> release
> 
> release
> 1.0.0-RELEASE
> 
> 
> 
>   
> 
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MNG-6608) Why can't project.version in pom.xml be set as a variable?

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MNG-6608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251336#comment-17251336
 ] 

Peter De Maeyer commented on MNG-6608:
--

My observation: for practical purposes, the ci-friendly feature of Maven 
produces broken POMs.
The POMs are broken because the variables such as ${revision} are not resolved 
in the deployed POM, which breaks dependent projects.
The workaround is to use the org.codehaus.mojo's maven-flatten-plugin, which 
even have an option resolveCiFriendliesOnly 
specifically for that purpose.

CI-friendly is a great feature in Maven, I use it all the time, but it's 
half-baked because it requires an org.codehaus.mojo to make it work.
Without the flatten-maven-plugin, it just doesn't work, which is a shame.
Ideally, the feature would just work without requiring an org.codehaus.mojo 
plugin.

I'm going to take a stab at fixing this.

> Why can't project.version in pom.xml be set as a variable?
> --
>
> Key: MNG-6608
> URL: https://issues.apache.org/jira/browse/MNG-6608
> Project: Maven
>  Issue Type: New Feature
>  Components: Design, Patterns & Best Practices
>Affects Versions: 3.6.0
>Reporter: chenxiaoyong
>Priority: Major
> Attachments: example.zip, revision-test.zip
>
>
> we need modify project.version in pom.xml  when we merge source code from 
> develope branch to master branch in git. it‘s troublesome!
> Why can't project.version in pom.xml be set as a variable?
> for example:
> {code:xml}
> 
> 4.0.0
> org.example
> example
> ${project-version}
> jar
> 
> 1.0.0-SNAPSHOT
> 
> 
> 
> 
> dev
> 
> dev
> 1.0.0-SNAPSHOT
> 
> 
> true
> 
> 
> 
> 
> release
> 
> release
> 1.0.0-RELEASE
> 
> 
> 
>   
> 
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHADE-339) Shaded test jar has wrong type "jar"

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17013572#comment-17013572
 ] 

Peter De Maeyer commented on MSHADE-339:


I updated the pull request with the "attach( "test-jar" )" solution, since we 
all agree on that.

Note that it's now a bit inconsistent with "attach( "java-source", "sources" )" 
a couple of lines above, which could ultimately become "attach( "java-sources" 
)" as well following the same rationale. My fingers were itching to bring that 
in line too, but I didn't want to stir up the debate again, so I left it alone.

> Shaded test jar has wrong type "jar"
> 
>
> Key: MSHADE-339
> URL: https://issues.apache.org/jira/browse/MSHADE-339
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 2.2, 3.2.2
>Reporter: Peter De Maeyer
>Assignee: Karl Heinz Marbaise
>Priority: Minor
> Fix For: 3.2.2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The shaded test jar has the wrong type "jar".
> It should be "test-jar".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHADE-342) Many integration tests fail when run in isolation

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17007010#comment-17007010
 ] 

Peter De Maeyer commented on MSHADE-342:


{quote}
I don't know if running every setup job when launching an isolated IT is really 
a good idea...
{quote}

I have no prior experience with Maven invoker, but my gut feeling says it would 
be the right thing to do.
My gut feeling is based on the analogy with JUnit 4, with which I have a lot of 
experience.
In JUnit, when you run "all tests", every {{@BeforeClass}} is invoked once 
before all tests in a test class and {{@AfterClass}} is invoked after.
When running an isolated test in a class, e.g. from the right-click menu in 
your IDE, the {{@BeforeClass}} and {{@AfterClass}} methods are _also_ run 
before and after.
It is elegant and corresponds to intuition, it seems like the right thing to do.

Indeed it would be best to move this issue to {{MINVOKER}}.

> Many integration tests fail when run in isolation
> -
>
> Key: MSHADE-342
> URL: https://issues.apache.org/jira/browse/MSHADE-342
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Maven invoker plugin supports running ITs in isolation, but many ITs fail 
> when run in isolation.
> One example (there are many others):
> {code:bash}
> mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
> {code}
> They fail because of a missing {{target/it/setup-parent/pom.xml}}.
> The failure is logged in {{target/it/setup-parent/build.log}}.
> The reason is that there is a missing parent dependency, which is apparently 
> required for _any_ IT in this project.
> When you run all the ITs together, it works by accident because the missing 
> directory is created by some other test in the beginning of the IT test run, 
> and then all subsequent tests work as well.
> h3. Potential solution
> A fix is to identify the broken ITs by running all of them in isolation and 
> add the following to all of the broken ones:
> {code:xml}
> 
> org.apache.maven.plugins.shade.its
> shade-parent
> 1.0
> ../setup-parent
> 
> {code}
> It should be documented somewhere (maybe it is but I overlooked it?) that, 
> when writing an IT, this _must_ be the parent.
> The acceptance criteria for the fix should be:
> # {{mvn -Run-its clean verify -Dinvoker.test=}} must run the IT in 
> isolation.
> # Optional, but nice if it works: after running the IT (or all ITs) once, it 
> must be possible to debug the Maven project by doing {{cd target/it/; 
> mvnDebug install}}.
> (+) It satisfies both acceptance criteria.
> (-) Every individual IT's {{pom.xml}} needs to be updated with a parent 
> dependency it has no business with.
> (-) It excludes writing an IT for a root project (that has no parent).
> Maybe we can find a solution that doesn't involve updating all IT projects.
> I'll need to investigate a bit more, first I'll need to figure out where the 
> {{setup-parent}} project comes from.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MSHADE-339) Shaded test jar has wrong type "jar"

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006478#comment-17006478
 ] 

Peter De Maeyer edited comment on MSHADE-339 at 1/1/20 8:55 PM:


In terms of file distribution, indeed you can achieve the same by using "jar", 
since the type is not stored in the artifact name.
Reactor resolution on the other hand is exactly the case where I expected to 
prove my point that "jar" is a bug and it should be "test-jar":
- "test-jar" should end up on the _test_ classpath and be propagated as such to 
dependent projects. Test classpaths should not be visible on the main classpath.
- "jar" should end up on the main classpath (which is also visible on the main 
classpath).

What I expected is that, because shaded test classes are attached with the 
wrong type "jar", test classes from a shaded project would pollute the _main_ 
classpath of a dependent project, which would be a bug.
Unfortunately, the reactor behaves differently than I thought, and I wasn't 
able to prove anything yet.


was (Author: peterdm):
In terms of file distribution, indeed you can achieve the same by using "jar", 
since the type is not stored in the artifact name.
Reactor resolution on the other hand is exactly the case where I expected to 
prove my point that "jar" is a bug and it should be "test-jar":
- "test-jar" should end up on the _test_ classpath and be propagated as such to 
dependent projects. Test classpaths should not be visible on the main classpath.
- "jar" should end up on the main classpath (which is also visible on the main 
classpath).

What I expected is that, because shaded test classes are attached with the 
wrong type "jar", test classes from a shaded project would pollute the _main_ 
classpath of a dependent project, which would be a bug.
Unfortunately, the reactor behaves differently than I thought - it seems to use 
the type of the _consuming_ project instead of that of the _producing_ project 
- and I wasn't able to prove anything yet.

> Shaded test jar has wrong type "jar"
> 
>
> Key: MSHADE-339
> URL: https://issues.apache.org/jira/browse/MSHADE-339
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 2.2, 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
> Fix For: 3.2.2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The shaded test jar has the wrong type "jar".
> It should be "test-jar".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHADE-339) Shaded test jar has wrong type "jar"

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006478#comment-17006478
 ] 

Peter De Maeyer commented on MSHADE-339:


In terms of file distribution, indeed you can achieve the same by using "jar", 
since the type is not stored in the artifact name.
Reactor resolution on the other hand is exactly the case where I expected to 
prove my point that "jar" is a bug and it should be "test-jar":
- "test-jar" should end up on the _test_ classpath and be propagated as such to 
dependent projects. Test classpaths should not be visible on the main classpath.
- "jar" should end up on the main classpath (which is also visible on the main 
classpath).

What I expected is that, because shaded test classes are attached with the 
wrong type "jar", test classes from a shaded project would pollute the _main_ 
classpath of a dependent project, which would be a bug.
Unfortunately, the reactor behaves differently than I thought - it seems to use 
the type of the _consuming_ project instead of that of the _producing_ project 
- and I wasn't able to prove anything yet.

> Shaded test jar has wrong type "jar"
> 
>
> Key: MSHADE-339
> URL: https://issues.apache.org/jira/browse/MSHADE-339
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 2.2, 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
> Fix For: 3.2.2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The shaded test jar has the wrong type "jar".
> It should be "test-jar".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHADE-342) Many integration tests fail when run in isolation

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17006476#comment-17006476
 ] 

Peter De Maeyer commented on MSHADE-342:


That feels like a workaround and no real solution to me.
The downside of that is that you require everyone who wants to run an IT in 
isolation suddenly needs to "know" about a parent project that the IT project 
itself has no relation with.
Can't we do better than that?
The {{maven-invoker-plugin}} knows that it needs to run a parent project when 
you run a test in isolation.
I think that the only thing that is missing is that the parent project isn't 
been copied to the {{target/}} directory, which is causing the failure.
Why can't we just fix that and make sure the setup project is copied to the 
{{target/}} directory?
That would be a fix in {{MINVOKER}} rather than {{MSHADE}}...



> Many integration tests fail when run in isolation
> -
>
> Key: MSHADE-342
> URL: https://issues.apache.org/jira/browse/MSHADE-342
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Maven invoker plugin supports running ITs in isolation, but many ITs fail 
> when run in isolation.
> One example (there are many others):
> {code:bash}
> mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
> {code}
> They fail because of a missing {{target/it/setup-parent/pom.xml}}.
> The failure is logged in {{target/it/setup-parent/build.log}}.
> The reason is that there is a missing parent dependency, which is apparently 
> required for _any_ IT in this project.
> When you run all the ITs together, it works by accident because the missing 
> directory is created by some other test in the beginning of the IT test run, 
> and then all subsequent tests work as well.
> h3. Potential solution
> A fix is to identify the broken ITs by running all of them in isolation and 
> add the following to all of the broken ones:
> {code:xml}
> 
> org.apache.maven.plugins.shade.its
> shade-parent
> 1.0
> ../setup-parent
> 
> {code}
> It should be documented somewhere (maybe it is but I overlooked it?) that, 
> when writing an IT, this _must_ be the parent.
> The acceptance criteria for the fix should be:
> # {{mvn -Run-its clean verify -Dinvoker.test=}} must run the IT in 
> isolation.
> # Optional, but nice if it works: after running the IT (or all ITs) once, it 
> must be possible to debug the Maven project by doing {{cd target/it/; 
> mvnDebug install}}.
> (+) It satisfies both acceptance criteria.
> (-) Every individual IT's {{pom.xml}} needs to be updated with a parent 
> dependency it has no business with.
> (-) It excludes writing an IT for a root project (that has no parent).
> Maybe we can find a solution that doesn't involve updating all IT projects.
> I'll need to investigate a bit more, first I'll need to figure out where the 
> {{setup-parent}} project comes from.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHADE-343) Shaded artifact has no version when finalName is set

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17005805#comment-17005805
 ] 

Peter De Maeyer commented on MSHADE-343:


I jumped the gun on this one, this is not a bug.
{{finalName}} already includes the version, so that's why it's not attached.
Also, {{finalName}} in the code doesn't correspond to the {{}} 
parameter in the plugin configuration.
Not sure how exactly that fits together, but it's clear I was too quick here.
You can close this as not a bug.

> Shaded artifact has no version when finalName is set
> 
>
> Key: MSHADE-343
> URL: https://issues.apache.org/jira/browse/MSHADE-343
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> {{ShadeMojo.shadedArtifactFile}} omits the version in the shaded artifact 
> file name when {{finalName}} is set.
> That looks like a bug: I think the version should be part of the 
> {{shadedName}} in any case.
> I just found this by eyeballing the code, I haven't tried reproducing it with 
> an actual scenario yet.
> It only affects situations where {{finalName}} is explicitly set, and it only 
> affects non-main artifacts (test jar, sources and test sources).
> The main shaded jar artifact doesn't go through this code path AFAICT, so is 
> not affected.
> {code:java}
> if ( project.getBuild().getFinalName() != null )
> {
> // Shouldn't artifact.getVersion() be part of the shadedName here 
> too?
> shadedName = project.getBuild().getFinalName() + "-" + classifier 
> + "."
> + artifact.getArtifactHandler().getExtension();
> }
> else
> {
> shadedName = shadedArtifactId + "-" + artifact.getVersion() + "-" 
> + classifier + "."
> + artifact.getArtifactHandler().getExtension();
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHADE-343) Shaded artifact has no version when finalName is set

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSHADE-343:
---
Description: 
{{ShadeMojo.shadedArtifactFile}} omits the version in the shaded artifact file 
name when {{finalName}} is set.
That looks like a bug: I think the version should be part of the {{shadedName}} 
in any case.
I just found this by eyeballing the code, I haven't tried reproducing it with 
an actual scenario yet.
It only affects situations where {{finalName}} is explicitly set, and it only 
affects non-main artifacts (test jar, sources and test sources).
The main shaded jar artifact doesn't go through this code path AFAICT, so is 
not affected.

{code:java}
if ( project.getBuild().getFinalName() != null )
{
// Shouldn't artifact.getVersion() be part of the shadedName here 
too?
shadedName = project.getBuild().getFinalName() + "-" + classifier + 
"."
+ artifact.getArtifactHandler().getExtension();
}
else
{
shadedName = shadedArtifactId + "-" + artifact.getVersion() + "-" + 
classifier + "."
+ artifact.getArtifactHandler().getExtension();
}
{code}

  was:
{{ShadeMojo.shadedArtifactFile}} omits the version in the shaded artifact file 
name when {{finalName}} is set.
That looks like a bug: I think the version should be part of the {{shadedName}} 
in any case.
I just found this by eyeballing the code, I haven't tried reproducing it with 
an actual scenario yet.
It only affects situations where {{finalName}} is explicitly set, and it only 
affects non-main artifacts (test jar, sources and test sources). The main jar 
artifact doesn't go through this method AFAICT, so is not affected.

{code:java}
if ( project.getBuild().getFinalName() != null )
{
// Shouldn't artifact.getVersion() be part of the shadedName here 
too?
shadedName = project.getBuild().getFinalName() + "-" + classifier + 
"."
+ artifact.getArtifactHandler().getExtension();
}
else
{
shadedName = shadedArtifactId + "-" + artifact.getVersion() + "-" + 
classifier + "."
+ artifact.getArtifactHandler().getExtension();
}
{code}


> Shaded artifact has no version when finalName is set
> 
>
> Key: MSHADE-343
> URL: https://issues.apache.org/jira/browse/MSHADE-343
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> {{ShadeMojo.shadedArtifactFile}} omits the version in the shaded artifact 
> file name when {{finalName}} is set.
> That looks like a bug: I think the version should be part of the 
> {{shadedName}} in any case.
> I just found this by eyeballing the code, I haven't tried reproducing it with 
> an actual scenario yet.
> It only affects situations where {{finalName}} is explicitly set, and it only 
> affects non-main artifacts (test jar, sources and test sources).
> The main shaded jar artifact doesn't go through this code path AFAICT, so is 
> not affected.
> {code:java}
> if ( project.getBuild().getFinalName() != null )
> {
> // Shouldn't artifact.getVersion() be part of the shadedName here 
> too?
> shadedName = project.getBuild().getFinalName() + "-" + classifier 
> + "."
> + artifact.getArtifactHandler().getExtension();
> }
> else
> {
> shadedName = shadedArtifactId + "-" + artifact.getVersion() + "-" 
> + classifier + "."
> + artifact.getArtifactHandler().getExtension();
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHADE-343) Shaded artifact has no version when finalName is set

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSHADE-343:
---
Description: 
{{ShadeMojo.shadedArtifactFile}} omits the version in the shaded artifact file 
name when {{finalName}} is set.
That looks like a bug: I think the version should be part of the {{shadedName}} 
in any case.
I just found this by eyeballing the code, I haven't tried reproducing it with 
an actual scenario yet.
It only affects situations where {{finalName}} is explicitly set, and it only 
affects non-main artifacts (test jar, sources and test sources). The main jar 
artifact doesn't go through this method AFAICT, so is not affected.

{code:java}
if ( project.getBuild().getFinalName() != null )
{
// Shouldn't artifact.getVersion() be part of the shadedName here 
too?
shadedName = project.getBuild().getFinalName() + "-" + classifier + 
"."
+ artifact.getArtifactHandler().getExtension();
}
else
{
shadedName = shadedArtifactId + "-" + artifact.getVersion() + "-" + 
classifier + "."
+ artifact.getArtifactHandler().getExtension();
}
{code}

  was:
{{ShadeMojo.shadedArtifactFile}} omits the version in the shaded artifact file 
name when {{finalName}} is set.
That looks like a bug: I think the version should be part of the file name in 
any case.
I just found this by eyeballing the code, I haven't tried reproducing it with 
an actual scenario yet.
It only affects situations where {{finalName}} is explicitly set, and it only 
affects non-main artifacts (test jar, sources and test sources). The main jar 
artifact doesn't go through this method AFAICT, so is not affected.

{code:java}
if ( project.getBuild().getFinalName() != null )
{
// Shouldn't artifact.getVersion() be part of the shadedName here 
too?
shadedName = project.getBuild().getFinalName() + "-" + classifier + 
"."
+ artifact.getArtifactHandler().getExtension();
}
else
{
shadedName = shadedArtifactId + "-" + artifact.getVersion() + "-" + 
classifier + "."
+ artifact.getArtifactHandler().getExtension();
}
{code}


> Shaded artifact has no version when finalName is set
> 
>
> Key: MSHADE-343
> URL: https://issues.apache.org/jira/browse/MSHADE-343
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> {{ShadeMojo.shadedArtifactFile}} omits the version in the shaded artifact 
> file name when {{finalName}} is set.
> That looks like a bug: I think the version should be part of the 
> {{shadedName}} in any case.
> I just found this by eyeballing the code, I haven't tried reproducing it with 
> an actual scenario yet.
> It only affects situations where {{finalName}} is explicitly set, and it only 
> affects non-main artifacts (test jar, sources and test sources). The main jar 
> artifact doesn't go through this method AFAICT, so is not affected.
> {code:java}
> if ( project.getBuild().getFinalName() != null )
> {
> // Shouldn't artifact.getVersion() be part of the shadedName here 
> too?
> shadedName = project.getBuild().getFinalName() + "-" + classifier 
> + "."
> + artifact.getArtifactHandler().getExtension();
> }
> else
> {
> shadedName = shadedArtifactId + "-" + artifact.getVersion() + "-" 
> + classifier + "."
> + artifact.getArtifactHandler().getExtension();
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHADE-343) Shaded artifact has no version when finalName is set

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSHADE-343:
---
Description: 
{{ShadeMojo.shadedArtifactFile}} omits the version in the shaded artifact file 
name when {{finalName}} is set.
That looks like a bug: I think the version should be part of the file name in 
any case.
I just found this by eyeballing the code, I haven't tried reproducing it with 
an actual scenario yet.
It only affects situations where {{finalName}} is explicitly set, and it only 
affects non-main artifacts (test jar, sources and test sources). The main jar 
artifact doesn't go through this method AFAICT, so is not affected.

{code:java}
if ( project.getBuild().getFinalName() != null )
{
// Shouldn't artifact.getVersion() be part of the shadedName here 
too?
shadedName = project.getBuild().getFinalName() + "-" + classifier + 
"."
+ artifact.getArtifactHandler().getExtension();
}
else
{
shadedName = shadedArtifactId + "-" + artifact.getVersion() + "-" + 
classifier + "."
+ artifact.getArtifactHandler().getExtension();
}
{code}

  was:
{{ShadeMojo.shadedArtifactFile}} omits the version in the shaded artifact file 
name when {{finalName}} is set.
That looks like a bug: I think the version should be part of the file name in 
any case.
I just found this by eyeballing the code, I haven't tried reproducing it with 
an actual scenario yet.
It only affects situations where {{finalName}} is explicitly set, and it only 
affects non-main artifacts (test jar, sources and test sources). The main jar 
artifact doesn't go through this method AFAICT, so is not affected.

{code:java}
if ( project.getBuild().getFinalName() != null )
{
// Shouldn't there be an artifact.getVersion() in the shadedName 
here too?
shadedName = project.getBuild().getFinalName() + "-" + classifier + 
"."
+ artifact.getArtifactHandler().getExtension();
}
else
{
shadedName = shadedArtifactId + "-" + artifact.getVersion() + "-" + 
classifier + "."
+ artifact.getArtifactHandler().getExtension();
}
{code}


> Shaded artifact has no version when finalName is set
> 
>
> Key: MSHADE-343
> URL: https://issues.apache.org/jira/browse/MSHADE-343
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> {{ShadeMojo.shadedArtifactFile}} omits the version in the shaded artifact 
> file name when {{finalName}} is set.
> That looks like a bug: I think the version should be part of the file name in 
> any case.
> I just found this by eyeballing the code, I haven't tried reproducing it with 
> an actual scenario yet.
> It only affects situations where {{finalName}} is explicitly set, and it only 
> affects non-main artifacts (test jar, sources and test sources). The main jar 
> artifact doesn't go through this method AFAICT, so is not affected.
> {code:java}
> if ( project.getBuild().getFinalName() != null )
> {
> // Shouldn't artifact.getVersion() be part of the shadedName here 
> too?
> shadedName = project.getBuild().getFinalName() + "-" + classifier 
> + "."
> + artifact.getArtifactHandler().getExtension();
> }
> else
> {
> shadedName = shadedArtifactId + "-" + artifact.getVersion() + "-" 
> + classifier + "."
> + artifact.getArtifactHandler().getExtension();
> }
> {code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MSHADE-343) Shaded artifact has no version when finalName is set

[Peter De Maeyer (Jira)]

Peter De Maeyer created MSHADE-343:
--

 Summary: Shaded artifact has no version when finalName is set
 Key: MSHADE-343
 URL: https://issues.apache.org/jira/browse/MSHADE-343
 Project: Maven Shade Plugin
  Issue Type: Bug
Affects Versions: 3.2.2
Reporter: Peter De Maeyer


{{ShadeMojo.shadedArtifactFile}} omits the version in the shaded artifact file 
name when {{finalName}} is set.
That looks like a bug: I think the version should be part of the file name in 
any case.
I just found this by eyeballing the code, I haven't tried reproducing it with 
an actual scenario yet.
It only affects situations where {{finalName}} is explicitly set, and it only 
affects non-main artifacts (test jar, sources and test sources). The main jar 
artifact doesn't go through this method AFAICT, so is not affected.

{code:java}
if ( project.getBuild().getFinalName() != null )
{
// Shouldn't there be an artifact.getVersion() in the shadedName 
here too?
shadedName = project.getBuild().getFinalName() + "-" + classifier + 
"."
+ artifact.getArtifactHandler().getExtension();
}
else
{
shadedName = shadedArtifactId + "-" + artifact.getVersion() + "-" + 
classifier + "."
+ artifact.getArtifactHandler().getExtension();
}
{code}



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHADE-286) Shading fails when a dependency's main artifact does not exist

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSHADE-286:
---
Description: 
Shading fails when a dependency's main artifact does not exist, see the methods 
{{ShadeMojo.invalidMainArtifact/createErrorOutput}} and their caller.
A similar existence check (luckily) does not exist for the other artifacts: 
test jar, sources, and test sources.
This was done intentionally, but it's overly strict because it prohibits a 
legitimate use case: some projects don't produce a main artifact, but only e.g. 
a test artifact.
Such projects can't be shaded because of this existence check.

It would be better to:
- Get rid of this check, or at least relax it, such that shading also works for 
projects that don't produce a main artifact.
- Complete the symmetry between jar, test jar, sources and test sources by 
adding a {{shadeJar}} boolean with default value {{true}}, which disables 
shading of main artifacts in a similar way {{shadeTestJar}}, 
{{createSourcesJar}} and {{createTestSourcesJar}} work. This will allow shading 
to disable creation of a main artifact altogether, even when the dependencies 
_do_ have a main artifact.

  was:
Shading fails when a dependency's main artifact does not exist, see the methods 
{{ShadeMojo.invalidMainArtifact/createErrorOutput}} and their caller.
A similar existence check (luckily) does not exist for the other artifacts: 
test jar, sources, and test sources.
This was done intentionally, but it's overly strict because it prohibits a 
legitimate use case: some projects don't produce a main artifact, but only e.g. 
a test artifact.
Such projects can't be shaded because of this existence check.

It would be better to:
- Get rid of this check, or at least relax it, such that shading also works for 
projects that don't have a main artifact.
- Complete the symmetry between jar, test jar, sources and test sources by 
adding a {{shadeJar}} boolean with default value {{true}}, which disables 
shading of main artifacts in a similar way {{shadeTestJar}}, 
{{createSourcesJar}} and {{createTestSourcesJar}} work. This will allow shading 
to disable creation of a main artifact altogether, even when the dependencies 
_do_ have a main artifact.


> Shading fails when a dependency's main artifact does not exist
> --
>
> Key: MSHADE-286
> URL: https://issues.apache.org/jira/browse/MSHADE-286
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Assignee: Mark Struberg
>Priority: Minor
>
> Shading fails when a dependency's main artifact does not exist, see the 
> methods {{ShadeMojo.invalidMainArtifact/createErrorOutput}} and their caller.
> A similar existence check (luckily) does not exist for the other artifacts: 
> test jar, sources, and test sources.
> This was done intentionally, but it's overly strict because it prohibits a 
> legitimate use case: some projects don't produce a main artifact, but only 
> e.g. a test artifact.
> Such projects can't be shaded because of this existence check.
> It would be better to:
> - Get rid of this check, or at least relax it, such that shading also works 
> for projects that don't produce a main artifact.
> - Complete the symmetry between jar, test jar, sources and test sources by 
> adding a {{shadeJar}} boolean with default value {{true}}, which disables 
> shading of main artifacts in a similar way {{shadeTestJar}}, 
> {{createSourcesJar}} and {{createTestSourcesJar}} work. This will allow 
> shading to disable creation of a main artifact altogether, even when the 
> dependencies _do_ have a main artifact.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MSHADE-339) Shaded test jar has wrong type "jar"

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17005051#comment-17005051
 ] 

Peter De Maeyer edited comment on MSHADE-339 at 12/30/19 9:31 AM:
--

{quote}
IMHO if we consider that the MavenProjectHelper parameter is a type (which it 
actually is given the implementation), we should attach with "test-jar" type 
and no classifier, since the implementation will fill with the default 
classifier https://maven.apache.org/ref/3.6.3/maven-core/artifact-handlers.html
{quote}

I agree with you there, but if we do that consistently in the implementation of 
{{ShadeMojo}}, that's a much bigger change than I was willing to do in the 
context of this issue. I was planning to create a separate issue for that at 
some point.

Everywhere in the implementation {{ShadeMojo}} where 
{{projectHelper.attachArtifact}} is used, we should pass {{null}} as 
classifier. In fact, the only reason to ever pass a non-null classifier is if 
you intend to use a _different_ one than the default. Classifiers and extension 
should always be gotten from the {{ArtifactHandler}} instead of the hardcoded 
ones that are currently used. If you do that, it would be easier to prove that 
"jar" is the wrong type, and it should really be "test-jar".

{quote}
if we consider we want to use it more as an extension (which is IMHO more 
logical given 
https://maven.apache.org/shared/maven-artifact-transfer/comparison.html), we 
should use "jar" extension and "tests" classifier
{quote}

I disagree with you there.
You shouldn't use type "as an extension" nor "as a classifier", because type, 
extension and classifier are 3 different things.
Let me elaborate:
There are 3 relevant types in the context of {{ShadeMojo}}: "jar", "test-jar" 
and "java-source".
The type you pass to {{(Default)MavenProjectHelper.attachArtifact}} is used to 
look up an {{ArtifactHandler}}.
The {{ArtifactHandler}} defines the extension and the default classifier.
By using "jar" instead of "test-jar", you in fact have the wrong 
{{ArtifactHandler}}.
It works by accident because "jar" happens to have the same extension as 
"test-jar", and because the {{ArtifactHandler}} isn't really used much in the 
rest of the code because the classifier "tests" is passed in to override it, 
but that doesn't make it right.


was (Author: peterdm):
{quote}
IMHO if we consider that the MavenProjectHelper parameter is a type (which it 
actually is given the implementation), we should attach with "test-jar" type 
and no classifier, since the implementation will fill with the default 
classifier https://maven.apache.org/ref/3.6.3/maven-core/artifact-handlers.html
{quote}

I agree with you there, but if we do that consistently in the implementation of 
{{ShadeMojo}}, that's a much bigger change than I was willing to do in the 
context of this issue. I was planning to create a separate issue for that at 
some point.
# Everywhere in the implementation {{ShadeMojo}} where 
{{projectHelper.attachArtifact}} is used, we should pass {{null}} as 
classifier. In fact, the only reason to ever pass a non-null classifier is if 
you intend to use a _different_ one than the default. Classifiers and extension 
should always be gotten from the {{ArtifactHandler}} instead of the hardcoded 
ones that are currently used. If you do that, it would be easier to prove that 
"jar" is the wrong type, and it should really be "test-jar".

{quote}
if we consider we want to use it more as an extension (which is IMHO more 
logical given 
https://maven.apache.org/shared/maven-artifact-transfer/comparison.html), we 
should use "jar" extension and "tests" classifier
{quote}

I disagree with you there.
You shouldn't use type "as an extension" nor "as a classifier", because type, 
extension and classifier are 3 different things.
Let me elaborate:
There are 3 relevant types in the context of {{ShadeMojo}}: "jar", "test-jar" 
and "java-source".
The type you pass to {{(Default)MavenProjectHelper.attachArtifact}} is used to 
look up an {{ArtifactHandler}}.
The {{ArtifactHandler}} defines the extension and the default classifier.
By using "jar" instead of "test-jar", you in fact have the wrong 
{{ArtifactHandler}}.
It works by accident because "jar" happens to have the same extension as 
"test-jar", and because the {{ArtifactHandler}} isn't really used much in the 
rest of the code because the classifier "tests" is passed in to override it, 
but that doesn't make it right.

> Shaded test jar has wrong type "jar"
> 
>
> Key: MSHADE-339
> URL: https://issues.apache.org/jira/browse/MSHADE-339
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 2.2, 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
> Fix For: 3.2.2
>
>  Time Spent: 10m
>  Re

[jira] [Comment Edited] (MSHADE-339) Shaded test jar has wrong type "jar"

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17005051#comment-17005051
 ] 

Peter De Maeyer edited comment on MSHADE-339 at 12/30/19 7:38 AM:
--

{quote}
IMHO if we consider that the MavenProjectHelper parameter is a type (which it 
actually is given the implementation), we should attach with "test-jar" type 
and no classifier, since the implementation will fill with the default 
classifier https://maven.apache.org/ref/3.6.3/maven-core/artifact-handlers.html
{quote}

I agree with you there, but if we do that consistently in the implementation of 
{{ShadeMojo}}, that's a much bigger change than I was willing to do in the 
context of this issue. I was planning to create a separate issue for that at 
some point.
# Everywhere in the implementation {{ShadeMojo}} where 
{{projectHelper.attachArtifact}} is used, we should pass {{null}} as 
classifier. In fact, the only reason to ever pass a non-null classifier is if 
you intend to use a _different_ one than the default. Classifiers and extension 
should always be gotten from the {{ArtifactHandler}} instead of the hardcoded 
ones that are currently used. If you do that, it would be easier to prove that 
"jar" is the wrong type, and it should really be "test-jar".

{quote}
if we consider we want to use it more as an extension (which is IMHO more 
logical given 
https://maven.apache.org/shared/maven-artifact-transfer/comparison.html), we 
should use "jar" extension and "tests" classifier
{quote}

I disagree with you there.
You shouldn't use type "as an extension" nor "as a classifier", because type, 
extension and classifier are 3 different things.
Let me elaborate:
There are 3 relevant types in the context of {{ShadeMojo}}: "jar", "test-jar" 
and "java-source".
The type you pass to {{(Default)MavenProjectHelper.attachArtifact}} is used to 
look up an {{ArtifactHandler}}.
The {{ArtifactHandler}} defines the extension and the default classifier.
By using "jar" instead of "test-jar", you in fact have the wrong 
{{ArtifactHandler}}.
It works by accident because "jar" happens to have the same extension as 
"test-jar", and because the {{ArtifactHandler}} isn't really used much in the 
rest of the code because the classifier "tests" is passed in to override it, 
but that doesn't make it right.


was (Author: peterdm):
{quote}
IMHO if we consider that the MavenProjectHelper parameter is a type (which it 
actually is given the implementation), we should attach with "test-jar" type 
and no classifier, since the implementation will fill with the default 
classifier https://maven.apache.org/ref/3.6.3/maven-core/artifact-handlers.html
{quote}

I agree with you there, but if we do that consistently in the implementation of 
{{ShadeMojo}}, that's a much bigger change than I was willing to do in the 
context of this issue. I was planning to create a separate issue for that at 
some point. _Everywhere_ in the implementation {{ShadeMojo}} where 
{{projectHelper.attachArtifact}} is used, we should pass {{null}} as 
classifier. In fact, the only reason to ever pass a non-null classifier is if 
you intend to use a _different_ one than the default, which the {{ShadeMojo}} 
plugin never does. If you do that, it would be easier to prove that "jar" is 
the wrong type, and it should really be "test-jar".


{quote}
if we consider we want to use it more as an extension (which is IMHO more 
logical given 
https://maven.apache.org/shared/maven-artifact-transfer/comparison.html), we 
should use "jar" extension and "tests" classifier
{quote}

I disagree with you there.
You shouldn't use type "as an extension" nor "as a classifier", because type, 
extension and classifier are 3 different things.
Let me elaborate:
There are 3 relevant types in the context of {{ShadeMojo}}: "jar", "test-jar" 
and "java-source".
The type you pass to {{(Default)MavenProjectHelper.attachArtifact}} is used to 
look up an {{ArtifactHandler}}.
The {{ArtifactHandler}} defines the extension and the default classifier.
By using "jar" instead of "test-jar", you in fact have the wrong 
{{ArtifactHandler}}.
It works by accident because "jar" happens to have the same extension as 
"test-jar", and because the {{ArtifactHandler}} isn't really used much in the 
rest of the code because the classifier "tests" is passed in to override it, 
but that doesn't make it right.

> Shaded test jar has wrong type "jar"
> 
>
> Key: MSHADE-339
> URL: https://issues.apache.org/jira/browse/MSHADE-339
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 2.2, 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
> Fix For: 3.2.2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The shaded test jar has the wrong type "jar".
> It should be "tes

[jira] [Comment Edited] (MSHADE-339) Shaded test jar has wrong type "jar"

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17005051#comment-17005051
 ] 

Peter De Maeyer edited comment on MSHADE-339 at 12/29/19 9:54 PM:
--

{quote}
IMHO if we consider that the MavenProjectHelper parameter is a type (which it 
actually is given the implementation), we should attach with "test-jar" type 
and no classifier, since the implementation will fill with the default 
classifier https://maven.apache.org/ref/3.6.3/maven-core/artifact-handlers.html
{quote}

I agree with you there, but if we do that consistently in the implementation of 
{{ShadeMojo}}, that's a much bigger change than I was willing to do in the 
context of this issue. I was planning to create a separate issue for that at 
some point. _Everywhere_ in the implementation {{ShadeMojo}} where 
{{projectHelper.attachArtifact}} is used, we should pass {{null}} as 
classifier. In fact, the only reason to ever pass a non-null classifier is if 
you intend to use a _different_ one than the default, which the {{ShadeMojo}} 
plugin never does. If you do that, it would be easier to prove that "jar" is 
the wrong type, and it should really be "test-jar".


{quote}
if we consider we want to use it more as an extension (which is IMHO more 
logical given 
https://maven.apache.org/shared/maven-artifact-transfer/comparison.html), we 
should use "jar" extension and "tests" classifier
{quote}

I disagree with you there.
You shouldn't use type "as an extension" nor "as a classifier", because type, 
extension and classifier are 3 different things.
Let me elaborate:
There are 3 relevant types in the context of {{ShadeMojo}}: "jar", "test-jar" 
and "java-source".
The type you pass to {{(Default)MavenProjectHelper.attachArtifact}} is used to 
look up an {{ArtifactHandler}}.
The {{ArtifactHandler}} defines the extension and the default classifier.
By using "jar" instead of "test-jar", you in fact have the wrong 
{{ArtifactHandler}}.
It works by accident because "jar" happens to have the same extension as 
"test-jar", and because the {{ArtifactHandler}} isn't really used much in the 
rest of the code because the classifier "tests" is passed in to override it, 
but that doesn't make it right.


was (Author: peterdm):
{quote}
IMHO if we consider that the MavenProjectHelper parameter is a type (which it 
actually is given the implementation), we should attach with "test-jar" type 
and no classifier, since the implementation will fill with the default 
classifier https://maven.apache.org/ref/3.6.3/maven-core/artifact-handlers.html
{quote}

In fact, I agree with you there, but if we do that consistently in the 
implementation of {{ShadeMojo}}, that's a much bigger change than I was willing 
to do in the context of this issue. I was planning to create a separate issue 
for that at some point. _Everywhere_ in the implementation {{ShadeMojo}} where 
{{projectHelper.attachArtifact}} is used, we should pass {{null}} as 
classifier. In fact, the only reason to ever pass a non-null classifier is if 
you intend to use a _different_ one than the default, which the {{ShadeMojo}} 
plugin never does. If you do that, it would be easier to prove that "jar" is 
the wrong type, and it should really be "test-jar".


{quote}
if we consider we want to use it more as an extension (which is IMHO more 
logical given 
https://maven.apache.org/shared/maven-artifact-transfer/comparison.html), we 
should use "jar" extension and "tests" classifier
{quote}

I disagree with you there.
You shouldn't use type "as an extension" nor "as a classifier", because type, 
extension and classifier are 3 different things.
Let me elaborate:
There are 3 relevant types in the context of {{ShadeMojo}}: "jar", "test-jar" 
and "java-source".
The type you pass to {{(Default)MavenProjectHelper.attachArtifact}} is used to 
look up an {{ArtifactHandler}}.
The {{ArtifactHandler}} defines the extension and the default classifier.
By using "jar" instead of "test-jar", you in fact have the wrong 
{{ArtifactHandler}}.
It works by accident because "jar" happens to have the same extension as 
"test-jar", and because the {{ArtifactHandler}} isn't really used much in the 
rest of the code because the classifier "tests" is passed in to override it, 
but that doesn't make it right.

> Shaded test jar has wrong type "jar"
> 
>
> Key: MSHADE-339
> URL: https://issues.apache.org/jira/browse/MSHADE-339
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 2.2, 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
> Fix For: 3.2.2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The shaded test jar has the wrong type "jar".
> It should be "test-jar".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MSHADE-339) Shaded test jar has wrong type "jar"

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17005051#comment-17005051
 ] 

Peter De Maeyer edited comment on MSHADE-339 at 12/29/19 9:53 PM:
--

{quote}
IMHO if we consider that the MavenProjectHelper parameter is a type (which it 
actually is given the implementation), we should attach with "test-jar" type 
and no classifier, since the implementation will fill with the default 
classifier https://maven.apache.org/ref/3.6.3/maven-core/artifact-handlers.html
{quote}

In fact, I agree with you there, but if we do that consistently in the 
implementation of {{ShadeMojo}}, that's a much bigger change than I was willing 
to do in the context of this issue. I was planning to create a separate issue 
for that at some point. _Everywhere_ in the implementation {{ShadeMojo}} where 
{{projectHelper.attachArtifact}} is used, we should pass {{null}} as 
classifier. In fact, the only reason to ever pass a non-null classifier is if 
you intend to use a _different_ one than the default, which the {{ShadeMojo}} 
plugin never does. If you do that, it would be easier to prove that "jar" is 
the wrong type, and it should really be "test-jar".


{quote}
if we consider we want to use it more as an extension (which is IMHO more 
logical given 
https://maven.apache.org/shared/maven-artifact-transfer/comparison.html), we 
should use "jar" extension and "tests" classifier
{quote}

I disagree with you there.
You shouldn't use type "as an extension" nor "as a classifier", because type, 
extension and classifier are 3 different things.
Let me elaborate:
There are 3 relevant types in the context of {{ShadeMojo}}: "jar", "test-jar" 
and "java-source".
The type you pass to {{(Default)MavenProjectHelper.attachArtifact}} is used to 
look up an {{ArtifactHandler}}.
The {{ArtifactHandler}} defines the extension and the default classifier.
By using "jar" instead of "test-jar", you in fact have the wrong 
{{ArtifactHandler}}.
It works by accident because "jar" happens to have the same extension as 
"test-jar", and because the {{ArtifactHandler}} isn't really used much in the 
rest of the code because the classifier "tests" is passed in to override it, 
but that doesn't make it right.


was (Author: peterdm):
{quote}
IMHO if we consider that the MavenProjectHelper parameter is a type (which it 
actually is given the implementation), we should attach with "test-jar" type 
and no classifier, since the implementation will fill with the default 
classifier https://maven.apache.org/ref/3.6.3/maven-core/artifact-handlers.html
{quote}

In fact, I agree with you there, but if we do that consistently in the 
implementation of {{ShadeMojo}}, that's a much bigger change than I was willing 
to do in the context of this issue. I was planning to create a separate issue 
for that at some point. _Everywhere_ in the implementation {{ShadeMojo}} where 
{{projectHelper.attachArtifact}} is used, we should pass {{null}} as 
classifier. In fact, the only reason you would ever pass a non-null classifier 
is if you intend to use a different one than the default, which the 
{{ShadeMojo}} plugin never does. If you do that, it would be easier to prove 
that "jar" is the wrong type, and it should really be "test-jar".


{quote}
if we consider we want to use it more as an extension (which is IMHO more 
logical given 
https://maven.apache.org/shared/maven-artifact-transfer/comparison.html), we 
should use "jar" extension and "tests" classifier
{quote}

I disagree with you there.
You shouldn't use type "as an extension" nor "as a classifier", because type, 
extension and classifier are 3 different things.
Let me elaborate:
There are 3 relevant types in the context of {{ShadeMojo}}: "jar", "test-jar" 
and "java-source".
The type you pass to {{(Default)MavenProjectHelper.attachArtifact}} is used to 
look up an {{ArtifactHandler}}.
The {{ArtifactHandler}} defines the extension and the default classifier.
By using "jar" instead of "test-jar", you in fact have the wrong 
{{ArtifactHandler}}.
It works by accident because "jar" happens to have the same extension as 
"test-jar", and because the {{ArtifactHandler}} isn't really used much in the 
rest of the code because the classifier "tests" is passed in to override it, 
but that doesn't make it right.

> Shaded test jar has wrong type "jar"
> 
>
> Key: MSHADE-339
> URL: https://issues.apache.org/jira/browse/MSHADE-339
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 2.2, 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
> Fix For: 3.2.2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The shaded test jar has the wrong type "jar".
> It should be "test-jar".



--
This message was sent by Atlassian Jira
(v8.3.4#803005

[jira] [Commented] (MSHADE-339) Shaded test jar has wrong type "jar"

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17005051#comment-17005051
 ] 

Peter De Maeyer commented on MSHADE-339:


{quote}
IMHO if we consider that the MavenProjectHelper parameter is a type (which it 
actually is given the implementation), we should attach with "test-jar" type 
and no classifier, since the implementation will fill with the default 
classifier https://maven.apache.org/ref/3.6.3/maven-core/artifact-handlers.html
{quote}

In fact, I agree with you there, but if we do that consistently in the 
implementation of {{ShadeMojo}}, that's a much bigger change than I was willing 
to do in the context of this issue. I was planning to create a separate issue 
for that at some point. _Everywhere_ in the implementation {{ShadeMojo}} where 
{{projectHelper.attachArtifact}} is used, we should pass {{null}} as 
classifier. In fact, the only reason you would ever pass a non-null classifier 
is if you intend to use a different one than the default, which the 
{{ShadeMojo}} plugin never does. If you do that, it would be easier to prove 
that "jar" is the wrong type, and it should really be "test-jar".


{quote}
if we consider we want to use it more as an extension (which is IMHO more 
logical given 
https://maven.apache.org/shared/maven-artifact-transfer/comparison.html), we 
should use "jar" extension and "tests" classifier
{quote}

I disagree with you there.
You shouldn't use type "as an extension" nor "as a classifier", because type, 
extension and classifier are 3 different things.
Let me elaborate:
There are 3 relevant types in the context of {{ShadeMojo}}: "jar", "test-jar" 
and "java-source".
The type you pass to {{(Default)MavenProjectHelper.attachArtifact}} is used to 
look up an {{ArtifactHandler}}.
The {{ArtifactHandler}} defines the extension and the default classifier.
By using "jar" instead of "test-jar", you in fact have the wrong 
{{ArtifactHandler}}.
It works by accident because "jar" happens to have the same extension as 
"test-jar", and because the {{ArtifactHandler}} isn't really used much in the 
rest of the code because the classifier "tests" is passed in to override it, 
but that doesn't make it right.

> Shaded test jar has wrong type "jar"
> 
>
> Key: MSHADE-339
> URL: https://issues.apache.org/jira/browse/MSHADE-339
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 2.2, 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
> Fix For: 3.2.2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The shaded test jar has the wrong type "jar".
> It should be "test-jar".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHADE-342) Many integration tests fail when run in isolation

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSHADE-342:
---
Description: 
Maven invoker plugin supports running ITs in isolation, but many ITs fail when 
run in isolation.
One example (there are many others):

{code:bash}
mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
{code}

They fail because of a missing {{target/it/setup-parent/pom.xml}}.
The failure is logged in {{target/it/setup-parent/build.log}}.

The reason is that there is a missing parent dependency, which is apparently 
required for _any_ IT in this project.
When you run all the ITs together, it works by accident because the missing 
directory is created by some other test in the beginning of the IT test run, 
and then all subsequent tests work as well.

h3. Potential solution

A fix is to identify the broken ITs by running all of them in isolation and add 
the following to all of the broken ones:

{code:xml}

org.apache.maven.plugins.shade.its
shade-parent
1.0
../setup-parent

{code}

It should be documented somewhere (maybe it is but I overlooked it?) that, when 
writing an IT, this _must_ be the parent.

The acceptance criteria for the fix should be:
# {{mvn -Run-its clean verify -Dinvoker.test=}} must run the IT in 
isolation.
# Optional, but nice if it works: after running the IT (or all ITs) once, it 
must be possible to debug the Maven project by doing {{cd target/it/; 
mvnDebug install}}.

(+) It satisfies both acceptance criteria.
(-) Every individual IT's {{pom.xml}} needs to be updated with a parent 
dependency it has no business with.
(-) It excludes writing an IT for a root project (that has no parent).

Maybe we can find a solution that doesn't involve updating all IT projects.
I'll need to investigate a bit more, first I'll need to figure out where the 
{{setup-parent}} project comes from.

  was:
Maven invoker plugin supports running ITs in isolation, but many ITs fail when 
running them in isolation.
One example (there are many others):

{code:bash}
mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
{code}

They fail because of a missing {{target/it/setup-parent/pom.xml}}.
The failure is logged in {{target/it/setup-parent/build.log}}.

The reason is that there is a missing parent dependency, which is apparently 
required for _any_ IT in this project.
When you run all the ITs together, it works by accident because the missing 
directory is created by some other test in the beginning of the IT test run, 
and then all subsequent tests work as well.

h3. Potential solution

A fix is to identify the broken ITs by running all of them in isolation and add 
the following to all of the broken ones:

{code:xml}

org.apache.maven.plugins.shade.its
shade-parent
1.0
../setup-parent

{code}

It should be documented somewhere (maybe it is but I overlooked it?) that, when 
writing an IT, this _must_ be the parent.

The acceptance criteria for the fix should be:
# {{mvn -Run-its clean verify -Dinvoker.test=}} must run the IT in 
isolation.
# Optional, but nice if it works: after running the IT (or all ITs) once, it 
must be possible to debug the Maven project by doing {{cd target/it/; 
mvnDebug install}}.

(+) It satisfies both acceptance criteria.
(-) Every individual IT's {{pom.xml}} needs to be updated with a parent 
dependency it has no business with.
(-) It excludes writing an IT for a root project (that has no parent).

Maybe we can find a solution that doesn't involve updating all IT projects.
I'll need to investigate a bit more, first I'll need to figure out where the 
{{setup-parent}} project comes from.


> Many integration tests fail when run in isolation
> -
>
> Key: MSHADE-342
> URL: https://issues.apache.org/jira/browse/MSHADE-342
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Maven invoker plugin supports running ITs in isolation, but many ITs fail 
> when run in isolation.
> One example (there are many others):
> {code:bash}
> mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
> {code}
> They fail because of a missing {{target/it/setup-parent/pom.xml}}.
> The failure is logged in {{target/it/setup-parent/build.log}}.
> The reason is that there is a missing parent dependency, which is apparently 
> required for _any_ IT in this project.
> When you run all the ITs together, it works by accident because the missing 
> directory is created by some other test in the beginning of the IT test run, 
> and then all subsequent tests work as well.
> h3. Potential solution
> A fix is to identify the broken ITs by running all of them in isolation and 
> add th

[jira] [Commented] (MSHADE-342) Many integration tests fail when run in isolation

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17004828#comment-17004828
 ] 

Peter De Maeyer commented on MSHADE-342:


{quote}
this IT should be defined as a setup IT
{quote}
I don't know how to do that, I'm not so familiar with the 
{{maven-invoker-plugin}}. I'll need to figure that out.

> Many integration tests fail when run in isolation
> -
>
> Key: MSHADE-342
> URL: https://issues.apache.org/jira/browse/MSHADE-342
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Maven invoker plugin supports running ITs in isolation, but many ITs fail 
> when running them in isolation.
> One example (there are many others):
> {code:bash}
> mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
> {code}
> They fail because of a missing {{target/it/setup-parent/pom.xml}}.
> The failure is logged in {{target/it/setup-parent/build.log}}.
> The reason is that there is a missing parent dependency, which is apparently 
> required for _any_ IT in this project.
> When you run all the ITs together, it works by accident because the missing 
> directory is created by some other test in the beginning of the IT test run, 
> and then all subsequent tests work as well.
> h3. Potential solution
> A fix is to identify the broken ITs by running all of them in isolation and 
> add the following to all of the broken ones:
> {code:xml}
> 
> org.apache.maven.plugins.shade.its
> shade-parent
> 1.0
> ../setup-parent
> 
> {code}
> It should be documented somewhere (maybe it is but I overlooked it?) that, 
> when writing an IT, this _must_ be the parent.
> The acceptance criteria for the fix should be:
> # {{mvn -Run-its clean verify -Dinvoker.test=}} must run the IT in 
> isolation.
> # Optional, but nice if it works: after running the IT (or all ITs) once, it 
> must be possible to debug the Maven project by doing {{cd target/it/; 
> mvnDebug install}}.
> (+) It satisfies both acceptance criteria.
> (-) Every individual IT's {{pom.xml}} needs to be updated with a parent 
> dependency it has no business with.
> (-) It excludes writing an IT for a root project (that has no parent).
> Maybe we can find a solution that doesn't involve updating all IT projects.
> I'll need to investigate a bit more, first I'll need to figure out where the 
> {{setup-parent}} project comes from.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHADE-342) Many integration tests fail when run in isolation

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSHADE-342:
---
Description: 
Maven invoker plugin supports running ITs in isolation, but many ITs fail when 
running them in isolation.
One example (there are many others):

{code:bash}
mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
{code}

They fail because of a missing {{target/it/setup-parent/pom.xml}}.
The failure is logged in {{target/it/setup-parent/build.log}}.

The reason is that there is a missing parent dependency, which is apparently 
required for _any_ IT in this project.
When you run all the ITs together, it works by accident because the missing 
directory is created by some other test in the beginning of the IT test run, 
and then all subsequent tests work as well.

h3. Potential solution

A fix is to identify the broken ITs by running all of them in isolation and add 
the following to all of the broken ones:

{code:xml}

org.apache.maven.plugins.shade.its
shade-parent
1.0
../setup-parent

{code}

It should be documented somewhere (maybe it is but I overlooked it?) that, when 
writing an IT, this _must_ be the parent.

The acceptance criteria for the fix should be:
# {{mvn -Run-its clean verify -Dinvoker.test=}} must run the IT in 
isolation.
# Optional, but nice if it works: after running the IT (or all ITs) once, it 
must be possible to debug the Maven project by doing {{cd target/it/; 
mvnDebug install}}.

(+) It satisfies both acceptance criteria.
(-) Every individual IT's {{pom.xml}} needs to be updated with a parent 
dependency it has no business with.
(-) It excludes writing an IT for a root project (that has no parent).

Maybe we can find a solution that doesn't involve updating all IT projects.
I'll need to investigate a bit more, first I'll need to figure out where the 
{{setup-parent}} project comes from.

  was:
Maven invoker plugin supports running ITs in isolation, but many ITs fail when 
running them in isolation.
One example (there are many others):

{code:bash}
mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
{code}

They fail because of a missing {{target/it/setup-parent/pom.xml}}.
The failure is logged in {{target/it/setup-parent/build.log}}.

The reason is that there is a missing parent dependency, which is apparently 
required for _any_ IT in this project.
When you run all the ITs together, it works by accident because the missing 
directory is created by some other test in the beginning of the IT test run, 
and then all subsequent tests work as well.

h3. Potential solution 1

A fix is to identify the broken ITs by running all of them in isolation and add 
the following to all of the broken ones:

{code:xml}

org.apache.maven.plugins.shade.its
shade-parent
1.0
../setup-parent

{code}

It should be documented somewhere (maybe it is but I overlooked it?) that, when 
writing an IT, this _must_ be the parent.

(+) This will work.
(-) Every individual IT's {{pom.xml}} needs to be updated with a parent 
dependency it has no business with.
(-) It excludes writing an IT for a root project (that has no parent).

Maybe we can find a solution that doesn't involve updating all IT projects.
I'll need to investigate a bit more, first I'll need to figure out where the 
{{setup-parent}} project comes from.


> Many integration tests fail when run in isolation
> -
>
> Key: MSHADE-342
> URL: https://issues.apache.org/jira/browse/MSHADE-342
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Maven invoker plugin supports running ITs in isolation, but many ITs fail 
> when running them in isolation.
> One example (there are many others):
> {code:bash}
> mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
> {code}
> They fail because of a missing {{target/it/setup-parent/pom.xml}}.
> The failure is logged in {{target/it/setup-parent/build.log}}.
> The reason is that there is a missing parent dependency, which is apparently 
> required for _any_ IT in this project.
> When you run all the ITs together, it works by accident because the missing 
> directory is created by some other test in the beginning of the IT test run, 
> and then all subsequent tests work as well.
> h3. Potential solution
> A fix is to identify the broken ITs by running all of them in isolation and 
> add the following to all of the broken ones:
> {code:xml}
> 
> org.apache.maven.plugins.shade.its
> shade-parent
> 1.0
> ../setup-parent
> 
> {code}
> It should be documented somewhere (maybe it is but I overlooked it?) that, 
> when writing an IT, this _must_ be t

[jira] [Updated] (MSHADE-342) Many integration tests fail when run in isolation

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSHADE-342:
---
Description: 
Maven invoker plugin supports running ITs in isolation, but many ITs fail when 
running them in isolation.
One example (there are many others):

{code:bash}
mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
{code}

They fail because of a missing {{target/it/setup-parent/pom.xml}}.
The failure is logged in {{target/it/setup-parent/build.log}}.

The reason is that there is a missing parent dependency, which is apparently 
required for _any_ IT in this project.
When you run all the ITs together, it works by accident because the missing 
directory is created by some other test in the beginning of the IT test run, 
and then all subsequent tests work as well.

h3. Potential solution 1

A fix is to identify the broken ITs by running all of them in isolation and add 
the following to all of the broken ones:

{code:xml}

org.apache.maven.plugins.shade.its
shade-parent
1.0
../setup-parent

{code}

It should be documented somewhere (maybe it is but I overlooked it?) that, when 
writing an IT, this _must_ be the parent.

(+) This will work.
(-) Every individual IT's {{pom.xml}} needs to be updated with a parent 
dependency it has no business with.
(-) It excludes writing an IT for a root project (that has no parent).

Maybe we can find a solution that doesn't involve updating all IT projects.
I'll need to investigate a bit more, first I'll need to figure out where the 
{{setup-parent}} project comes from.

  was:
Maven invoker plugin supports running ITs in isolation, but many ITs fail when 
running them in isolation.
One example (there are many others):

{code:bash}
mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
 {code}

They fail because of a missing {{target/it/setup-parent/pom.xml}}.
The failure is logged in {{target/it/setup-parent/build.log}}.

The reason is that there is a missing parent dependency, which is apparently 
required for _any_ IT in this project.
When you run all the ITs together, it works by accident because the missing 
directory is created by some other test in the beginning of the IT test run, 
and then all subsequent tests work as well.

h3. Potential solution 1

A fix is to identify the broken ITs by running all of them in isolation and add 
the following to all of the broken ones:

{code:xml}

org.apache.maven.plugins.shade.its
shade-parent
1.0
../setup-parent

{code}

It should be documented somewhere (maybe it is but I overlooked it?) that, when 
writing an IT, this _must_ be the parent.

(+) This will work.
(-) Every individual IT's {{pom.xml}} needs to be updated with a parent 
dependency it has no business with.
(-) It excludes writing an IT for a root project (that has no parent).

Maybe we can find a solution that doesn't involve updating all IT projects.
I'll need to investigate a bit more, first I'll need to figure out where the 
{{setup-parent}} project comes from.


> Many integration tests fail when run in isolation
> -
>
> Key: MSHADE-342
> URL: https://issues.apache.org/jira/browse/MSHADE-342
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Maven invoker plugin supports running ITs in isolation, but many ITs fail 
> when running them in isolation.
> One example (there are many others):
> {code:bash}
> mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
> {code}
> They fail because of a missing {{target/it/setup-parent/pom.xml}}.
> The failure is logged in {{target/it/setup-parent/build.log}}.
> The reason is that there is a missing parent dependency, which is apparently 
> required for _any_ IT in this project.
> When you run all the ITs together, it works by accident because the missing 
> directory is created by some other test in the beginning of the IT test run, 
> and then all subsequent tests work as well.
> h3. Potential solution 1
> A fix is to identify the broken ITs by running all of them in isolation and 
> add the following to all of the broken ones:
> {code:xml}
> 
> org.apache.maven.plugins.shade.its
> shade-parent
> 1.0
> ../setup-parent
> 
> {code}
> It should be documented somewhere (maybe it is but I overlooked it?) that, 
> when writing an IT, this _must_ be the parent.
> (+) This will work.
> (-) Every individual IT's {{pom.xml}} needs to be updated with a parent 
> dependency it has no business with.
> (-) It excludes writing an IT for a root project (that has no parent).
> Maybe we can find a solution that doesn't involve updating all IT projects.
> I'll need to in

[jira] [Updated] (MSHADE-342) Many integration tests fail when run in isolation

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSHADE-342:
---
Summary: Many integration tests fail when run in isolation  (was: Many ITs 
fail when run in isolation)

> Many integration tests fail when run in isolation
> -
>
> Key: MSHADE-342
> URL: https://issues.apache.org/jira/browse/MSHADE-342
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Maven invoker plugin supports running ITs in isolation, but many ITs fail 
> when running them in isolation.
> One example (there are many others):
> {code:bash}
> mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
>  {code}
> They fail because of a missing {{target/it/setup-parent/pom.xml}}.
> The failure is logged in {{target/it/setup-parent/build.log}}.
> The reason is that there is a missing parent dependency, which is apparently 
> required for _any_ IT in this project.
> When you run all the ITs together, it works by accident because the missing 
> directory is created by some other test in the beginning of the IT test run, 
> and then all subsequent tests work as well.
> h3. Potential solution 1
> A fix is to identify the broken ITs by running all of them in isolation and 
> add the following to all of the broken ones:
> {code:xml}
> 
> org.apache.maven.plugins.shade.its
> shade-parent
> 1.0
> ../setup-parent
> 
> {code}
> It should be documented somewhere (maybe it is but I overlooked it?) that, 
> when writing an IT, this _must_ be the parent.
> (+) This will work.
> (-) Every individual IT's {{pom.xml}} needs to be updated with a parent 
> dependency it has no business with.
> (-) It excludes writing an IT for a root project (that has no parent).
> Maybe we can find a solution that doesn't involve updating all IT projects.
> I'll need to investigate a bit more, first I'll need to figure out where the 
> {{setup-parent}} project comes from.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHADE-342) Many ITs fail when run in isolation

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSHADE-342:
---
Description: 
Maven invoker plugin supports running ITs in isolation, but many ITs fail when 
running them in isolation.
One example (there are many others):

{code:bash}
mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
 {code}

They fail because of a missing {{target/it/setup-parent/pom.xml}}.
The failure is logged in {{target/it/setup-parent/build.log}}.

The reason is that there is a missing parent dependency, which is apparently 
required for _any_ IT in this project.
When you run all the ITs together, it works by accident because the missing 
directory is created by some other test in the beginning of the IT test run, 
and then all subsequent tests work as well.

h3. Potential solution 1

A fix is to identify the broken ITs by running all of them in isolation and add 
the following to all of the broken ones:

{code:xml}

org.apache.maven.plugins.shade.its
shade-parent
1.0
../setup-parent

{code}

It should be documented somewhere (maybe it is but I overlooked it?) that, when 
writing an IT, this _must_ be the parent.

(+) This will work.
(-) Every individual IT's {{pom.xml}} needs to be updated with a parent 
dependency it has no business with.
(-) It excludes writing an IT for a root project (that has no parent).

Maybe we can find a solution that doesn't involve updating all IT projects.
I'll need to investigate a bit more, first I'll need to figure out where the 
{{setup-parent}} project comes from.

  was:
Maven invoker plugin supports running ITs in isolation, but many ITs in the 
"maven-shade-plugin" don't:.
One example (there are many others):

{code:bash}
mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
 {code}

If you try to run them, they fail because of a missing 
{{target/it/setup-parent/pom.xml}}.
The failure is logged in {{target/it/setup-parent/build.log}}.

The reason is that there is a missing parent dependency, which is apparently 
required for _any_ IT in this project.
When you run the ITs as a whole, it works by accident because the missing 
directory is created by some other test in the beginning of the IT test run, 
and then all subsequent tests work as well.

The fix is to identify the broken ITs by running all of them in isolation and 
add the following to all of the broken ones:

{code:xml}

org.apache.maven.plugins.shade.its
shade-parent
1.0
../setup-parent

{code}

It should be documented somewhere (maybe it is but I overlooked it?) that, when 
writing an IT, this _must_ be the parent.


> Many ITs fail when run in isolation
> ---
>
> Key: MSHADE-342
> URL: https://issues.apache.org/jira/browse/MSHADE-342
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Maven invoker plugin supports running ITs in isolation, but many ITs fail 
> when running them in isolation.
> One example (there are many others):
> {code:bash}
> mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
>  {code}
> They fail because of a missing {{target/it/setup-parent/pom.xml}}.
> The failure is logged in {{target/it/setup-parent/build.log}}.
> The reason is that there is a missing parent dependency, which is apparently 
> required for _any_ IT in this project.
> When you run all the ITs together, it works by accident because the missing 
> directory is created by some other test in the beginning of the IT test run, 
> and then all subsequent tests work as well.
> h3. Potential solution 1
> A fix is to identify the broken ITs by running all of them in isolation and 
> add the following to all of the broken ones:
> {code:xml}
> 
> org.apache.maven.plugins.shade.its
> shade-parent
> 1.0
> ../setup-parent
> 
> {code}
> It should be documented somewhere (maybe it is but I overlooked it?) that, 
> when writing an IT, this _must_ be the parent.
> (+) This will work.
> (-) Every individual IT's {{pom.xml}} needs to be updated with a parent 
> dependency it has no business with.
> (-) It excludes writing an IT for a root project (that has no parent).
> Maybe we can find a solution that doesn't involve updating all IT projects.
> I'll need to investigate a bit more, first I'll need to figure out where the 
> {{setup-parent}} project comes from.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHADE-342) Many ITs fail when run in isolation

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSHADE-342:
---
Summary: Many ITs fail when run in isolation  (was: Many ITs don't run in 
isolation)

> Many ITs fail when run in isolation
> ---
>
> Key: MSHADE-342
> URL: https://issues.apache.org/jira/browse/MSHADE-342
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Maven invoker plugin supports running ITs in isolation, but many ITs in the 
> "maven-shade-plugin" don't:.
> One example (there are many others):
> {code:bash}
> mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
>  {code}
> If you try to run them, they fail because of a missing 
> {{target/it/setup-parent/pom.xml}}.
> The failure is logged in {{target/it/setup-parent/build.log}}.
> The reason is that there is a missing parent dependency, which is apparently 
> required for _any_ IT in this project.
> When you run the ITs as a whole, it works by accident because the missing 
> directory is created by some other test in the beginning of the IT test run, 
> and then all subsequent tests work as well.
> The fix is to identify the broken ITs by running all of them in isolation and 
> add the following to all of the broken ones:
> {code:xml}
> 
> org.apache.maven.plugins.shade.its
> shade-parent
> 1.0
> ../setup-parent
> 
> {code}
> It should be documented somewhere (maybe it is but I overlooked it?) that, 
> when writing an IT, this _must_ be the parent.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHADE-342) Many ITs don't run in isolation

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17004699#comment-17004699
 ] 

Peter De Maeyer commented on MSHADE-342:


It's on my to-do list to fix this, but if someone wants to beat me to it, knock 
yourself out.

> Many ITs don't run in isolation
> ---
>
> Key: MSHADE-342
> URL: https://issues.apache.org/jira/browse/MSHADE-342
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Maven invoker plugin supports running ITs in isolation, but many ITs in the 
> "maven-shade-plugin" don't:.
> One example (there are many others):
> {code:bash}
> mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
>  {code}
> If you try to run them, they fail because of a missing 
> {{target/it/setup-parent/pom.xml}}.
> The failure is logged in {{target/it/setup-parent/build.log}}.
> The reason is that there is a missing parent dependency, which is apparently 
> required for _any_ IT in this project.
> When you run the ITs as a whole, it works by accident because the missing 
> directory is created by some other test in the beginning of the IT test run, 
> and then all subsequent tests work as well.
> The fix is to identify the broken ITs by running all of them in isolation and 
> add the following to all of the broken ones:
> {code:xml}
> 
> org.apache.maven.plugins.shade.its
> shade-parent
> 1.0
> ../setup-parent
> 
> {code}
> It should be documented somewhere (maybe it is but I overlooked it?) that, 
> when writing an IT, this _must_ be the parent.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MSHADE-342) Many ITs don't run in isolation

[Peter De Maeyer (Jira)]

Peter De Maeyer created MSHADE-342:
--

 Summary: Many ITs don't run in isolation
 Key: MSHADE-342
 URL: https://issues.apache.org/jira/browse/MSHADE-342
 Project: Maven Shade Plugin
  Issue Type: Bug
Affects Versions: 3.2.2
Reporter: Peter De Maeyer


Maven invoker plugin supports running ITs in isolation, but many ITs in the 
"maven-shade-plugin" don't:.
One example (there are many others):

{code:bash}
mvn -Prun-its clean verify -Dinvoker.test=MSHADE-258_module_relocation
 {code}

If you try to run them, they fail because of a missing 
{{target/it/setup-parent/pom.xml}}.
The failure is logged in {{target/it/setup-parent/build.log}}.

The reason is that there is a missing parent dependency, which is apparently 
required for _any_ IT in this project.
When you run the ITs as a whole, it works by accident because the missing 
directory is created by some other test in the beginning of the IT test run, 
and then all subsequent tests work as well.

The fix is to identify the broken ITs by running all of them in isolation and 
add the following to all of the broken ones:

{code:xml}

org.apache.maven.plugins.shade.its
shade-parent
1.0
../setup-parent

{code}

It should be documented somewhere (maybe it is but I overlooked it?) that, when 
writing an IT, this _must_ be the parent.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MSHADE-339) Shaded test jar has wrong type "jar"

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17004566#comment-17004566
 ] 

Peter De Maeyer edited comment on MSHADE-339 at 12/28/19 8:00 PM:
--

{quote}
I fear there is absolutely no IT checking anything about this case
{quote}

Actually, there is :-). It's the one that I wrote myself in the context of 
MSHADE-284. See 
[master/src/it/MSHADE-284_shadeTestJar/verify.groovy|https://github.com/apache/maven-shade-plugin/blob/master/src/it/MSHADE-284_shadeTestJar/verify.groovy],
 lines 37-52: those assertions would have failed if the extension had suddenly 
changed to "test-jar". I double-checked just now by running the test and 
inspecting the resulting project in the {{target/}} directory - I confirm that 
the extension is still "jar" after my fix.

Still, I'll (try to) add an IT to illustrate what can go wrong if we don't fix 
this issue. Stay tuned.


was (Author: peterdm):
{quote}
 fear there is absolutely no IT checking anything about this case
{quote}

Actually, there is :-). It's the one that I wrote myself in the context of 
MSHADE-284. See 
[master/src/it/MSHADE-284_shadeTestJar/verify.groovy|https://github.com/apache/maven-shade-plugin/blob/master/src/it/MSHADE-284_shadeTestJar/verify.groovy],
 lines 37-52: those assertions would have failed if the extension had suddenly 
changed to "test-jar". I double-checked just now by running the test and 
inspecting the resulting project in the {{target/}} directory - I confirm that 
the extension is still "jar" after my fix.

Still, I'll (try to) add an IT to illustrate what can go wrong if we don't fix 
this issue. Stay tuned.

> Shaded test jar has wrong type "jar"
> 
>
> Key: MSHADE-339
> URL: https://issues.apache.org/jira/browse/MSHADE-339
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 2.2, 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
> Fix For: 3.2.2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The shaded test jar has the wrong type "jar".
> It should be "test-jar".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHADE-339) Shaded test jar has wrong type "jar"

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17004566#comment-17004566
 ] 

Peter De Maeyer commented on MSHADE-339:


{quote}
 fear there is absolutely no IT checking anything about this case
{quote}

Actually, there is :-). It's the one that I wrote myself in the context of 
MSHADE-284. See 
[master/src/it/MSHADE-284_shadeTestJar/verify.groovy|https://github.com/apache/maven-shade-plugin/blob/master/src/it/MSHADE-284_shadeTestJar/verify.groovy],
 lines 37-52: those assertions would have failed if the extension had suddenly 
changed to "test-jar". I double-checked just now by running the test and 
inspecting the resulting project in the {{target/}} directory - I confirm that 
the extension is still "jar" after my fix.

Still, I'll (try to) add an IT to illustrate what can go wrong if we don't fix 
this issue. Stay tuned.

> Shaded test jar has wrong type "jar"
> 
>
> Key: MSHADE-339
> URL: https://issues.apache.org/jira/browse/MSHADE-339
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 2.2, 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
> Fix For: 3.2.2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The shaded test jar has the wrong type "jar".
> It should be "test-jar".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHADE-339) Shaded test jar has wrong type "jar"

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17004443#comment-17004443
 ] 

Peter De Maeyer commented on MSHADE-339:


{quote}
perhaps it's just the attribute name that is just wrongly named as 
{{artifactType}} (then implies default classifier) when it is in reality just 
{{artifactExtension}}
{quote}

Hmm, I'm not entirely certain, but I don't think think that's true - the 
extension is still jar.
The reason I dare say this is because I think I would have noticed that while 
fixing.
Even though I didn't write an additional IT, I _did_ run all the _existing_ 
ITs, and they were all green.
Surely enough, if something so obvious as the file extension would change, it 
would make some existing ITs fail (I hope)...

Anyway, point taken: I'll go back to the drawing board and either add a new IT 
or update an existing one in my PR to illustrate a scenario that could go wrong.

> Shaded test jar has wrong type "jar"
> 
>
> Key: MSHADE-339
> URL: https://issues.apache.org/jira/browse/MSHADE-339
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 2.2, 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
> Fix For: 3.2.2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The shaded test jar has the wrong type "jar".
> It should be "test-jar".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MSHADE-339) Shaded test jar has wrong type "jar"

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17004341#comment-17004341
 ] 

Peter De Maeyer edited comment on MSHADE-339 at 12/27/19 10:38 PM:
---

{quote}
and while at it, shouldn't the "tests" classifier be removed from the call, 
since it is implicit in "test-jar" type?
{quote}

That's not correct - the classifier is not implicit. "tests" is the _default_ 
classifier for "test-jar" type, but can be explicitly overridden to be anything.
See MSOURCES-124 for a more elaborate explanation.

The Shade plugin only deals well with the default classifiers, but doesn't 
properly handle non-default classifiers.
I've made another bug for that which I intend to fix at some point too, but 
let's first fix the default classifier already (the scope of _this_ issue).

{quote}
one question: is this little code inconsistency breaking anything?
{quote}

Types and classifiers are used to look up dependencies, so if a dependency is 
attached with the wrong type, a project that depends on it may not find back 
the dependency.
Hence, I think it will break projects that depend on it, which are processed 
later in the "Maven reactor processing chain" (not sure if that is a correct 
term).
I suppose I could try and write an IT test scenario that illustrates what can 
go wrong. I didn't bother initially because it takes some effort and the fix is 
obvious enough, but if you really like I can try...


was (Author: peterdm):
{quote}
and while at it, shouldn't the "tests" classifier be removed from the call, 
since it is implicit in "test-jar" type?
{quote}

That's not correct - the classifier is not implicit. "tests" is the _default_ 
classifier, but can be explicitly overridden to be anything.
See MSOURCES-124 for a more elaborate explanation.

The Shade plugin only deals well with the default classifiers, but doesn't 
properly handle non-default classifiers.
I've made another bug for that which I intend to fix at some point too, but 
let's first fix the default classifier already (the scope of _this_ issue).

{quote}
one question: is this little code inconsistency breaking anything?
{quote}

Types and classifiers are used to look up dependencies, so if a dependency is 
attached with the wrong type, a project that depends on it may not find back 
the dependency.
Hence, I think it will break projects that depend on it, which are processed 
later in the "Maven reactor processing chain" (not sure if that is a correct 
term).
I suppose I could try and write an IT test scenario that illustrates what can 
go wrong. I didn't bother initially because it takes some effort and the fix is 
obvious enough, but if you really like I can try...

> Shaded test jar has wrong type "jar"
> 
>
> Key: MSHADE-339
> URL: https://issues.apache.org/jira/browse/MSHADE-339
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 2.2, 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
> Fix For: 3.2.2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The shaded test jar has the wrong type "jar".
> It should be "test-jar".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHADE-339) Shaded test jar has wrong type "jar"

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17004341#comment-17004341
 ] 

Peter De Maeyer commented on MSHADE-339:


{quote}
and while at it, shouldn't the "tests" classifier be removed from the call, 
since it is implicit in "test-jar" type?
{quote}

That's not correct - the classifier is not implicit. "tests" is the _default_ 
classifier, but can be explicitly overridden to be anything.
See MSOURCES-124 for a more elaborate explanation.

The Shade plugin only deals well with the default classifiers, but doesn't 
properly handle non-default classifiers.
I've made another bug for that which I intend to fix at some point too, but 
let's first fix the default classifier already (the scope of _this_ issue).

{quote}
one question: is this little code inconsistency breaking anything?
{quote}

Types and classifiers are used to look up dependencies, so if a dependency is 
attached with the wrong type, a project that depends on it may not find back 
the dependency.
Hence, I think it will break projects that depend on it, which are processed 
later in the "Maven reactor processing chain" (not sure if that is a correct 
term).
I suppose I could try and write an IT test scenario that illustrates what can 
go wrong. I didn't bother initially because it takes some effort and the fix is 
obvious enough, but if you really like I can try...

> Shaded test jar has wrong type "jar"
> 
>
> Key: MSHADE-339
> URL: https://issues.apache.org/jira/browse/MSHADE-339
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 2.2, 3.2.2
>Reporter: Peter De Maeyer
>Priority: Minor
> Fix For: 3.2.2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The shaded test jar has the wrong type "jar".
> It should be "test-jar".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Comment Edited] (MSHADE-286) Shading fails when a dependency's main artifact does not exist

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17003368#comment-17003368
 ] 

Peter De Maeyer edited comment on MSHADE-286 at 12/25/19 8:41 PM:
--

[~struberg], I noticed you assigned this to yourself - are you working on this? 
I'm working on a fix myself too...


was (Author: peterdm):
I'm working on a solution on a branch in my fork.

> Shading fails when a dependency's main artifact does not exist
> --
>
> Key: MSHADE-286
> URL: https://issues.apache.org/jira/browse/MSHADE-286
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Assignee: Mark Struberg
>Priority: Minor
>
> Shading fails when a dependency's main artifact does not exist, see the 
> methods {{ShadeMojo.invalidMainArtifact/createErrorOutput}} and their caller.
> A similar existence check (luckily) does not exist for the other artifacts: 
> test jar, sources, and test sources.
> This was done intentionally, but it's overly strict because it prohibits a 
> legitimate use case: some projects don't produce a main artifact, but only 
> e.g. a test artifact.
> Such projects can't be shaded because of this existence check.
> It would be better to:
> - Get rid of this check, or at least relax it, such that shading also works 
> for projects that don't have a main artifact.
> - Complete the symmetry between jar, test jar, sources and test sources by 
> adding a {{shadeJar}} boolean with default value {{true}}, which disables 
> shading of main artifacts in a similar way {{shadeTestJar}}, 
> {{createSourcesJar}} and {{createTestSourcesJar}} work. This will allow 
> shading to disable creation of a main artifact altogether, even when the 
> dependencies _do_ have a main artifact.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHADE-286) Shading fails when a dependency's main artifact does not exist

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17003368#comment-17003368
 ] 

Peter De Maeyer commented on MSHADE-286:


I'm working on a solution on a branch in my fork.

> Shading fails when a dependency's main artifact does not exist
> --
>
> Key: MSHADE-286
> URL: https://issues.apache.org/jira/browse/MSHADE-286
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Assignee: Mark Struberg
>Priority: Minor
>
> Shading fails when a dependency's main artifact does not exist, see the 
> methods {{ShadeMojo.invalidMainArtifact/createErrorOutput}} and their caller.
> A similar existence check (luckily) does not exist for the other artifacts: 
> test jar, sources, and test sources.
> This was done intentionally, but it's overly strict because it prohibits a 
> legitimate use case: some projects don't produce a main artifact, but only 
> e.g. a test artifact.
> Such projects can't be shaded because of this existence check.
> It would be better to:
> - Get rid of this check, or at least relax it, such that shading also works 
> for projects that don't have a main artifact.
> - Complete the symmetry between jar, test jar, sources and test sources by 
> adding a {{shadeJar}} boolean with default value {{true}}, which disables 
> shading of main artifacts in a similar way {{shadeTestJar}}, 
> {{createSourcesJar}} and {{createTestSourcesJar}} work. This will allow 
> shading to disable creation of a main artifact altogether, even when the 
> dependencies _do_ have a main artifact.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHADE-286) Shading fails when a dependency's main artifact does not exist

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSHADE-286:
---
Description: 
Shading fails when a dependency's main artifact does not exist, see the methods 
{{ShadeMojo.invalidMainArtifact/createErrorOutput}} and their caller.
A similar existence check (luckily) does not exist for the other artifacts: 
test jar, sources, and test sources.
This was done intentionally, but it's overly strict because it prohibits a 
legitimate use case: some projects don't produce a main artifact, but only e.g. 
a test artifact.
Such projects can't be shaded because of this existence check.

It would be better to:
- Get rid of this check, or at least relax it, such that shading also works for 
projects that don't have a main artifact.
- Complete the symmetry between jar, test jar, sources and test sources by 
adding a {{shadeJar}} boolean with default value {{true}}, which disables 
shading of main artifacts in a similar way {{shadeTestJar}}, 
{{createSourcesJar}} and {{createTestSourcesJar}} work. This will allow shading 
to disable creation of a main artifact altogether, even when the dependencies 
_do_ have a main artifact.

  was:
While looking at {{ShadeMojo.execute}}, I noticed that the artifacts to be 
included for shading are not consistently checked for existence.

For example, on line 404, the main artifact file is _not_ checked for existence:
{code:java}
artifacts.add( project.getArtifact().getFile() );
{code}
But immediately below, the sources artifact file _is_ checked for existence:
{code:java}
if ( createSourcesJar )
{
File file = shadedSourcesArtifactFile();
if ( file.isFile() )
{
sourceArtifacts.add( file );
}
}
{code}

Apparently, it's a conscious choice to fail when the main artifact does not 
exist.


> Shading fails when a dependency's main artifact does not exist
> --
>
> Key: MSHADE-286
> URL: https://issues.apache.org/jira/browse/MSHADE-286
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Assignee: Mark Struberg
>Priority: Minor
>
> Shading fails when a dependency's main artifact does not exist, see the 
> methods {{ShadeMojo.invalidMainArtifact/createErrorOutput}} and their caller.
> A similar existence check (luckily) does not exist for the other artifacts: 
> test jar, sources, and test sources.
> This was done intentionally, but it's overly strict because it prohibits a 
> legitimate use case: some projects don't produce a main artifact, but only 
> e.g. a test artifact.
> Such projects can't be shaded because of this existence check.
> It would be better to:
> - Get rid of this check, or at least relax it, such that shading also works 
> for projects that don't have a main artifact.
> - Complete the symmetry between jar, test jar, sources and test sources by 
> adding a {{shadeJar}} boolean with default value {{true}}, which disables 
> shading of main artifacts in a similar way {{shadeTestJar}}, 
> {{createSourcesJar}} and {{createTestSourcesJar}} work. This will allow 
> shading to disable creation of a main artifact altogether, even when the 
> dependencies _do_ have a main artifact.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHADE-286) Shading fails when a dependency's main artifact does not exist

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSHADE-286:
---
Issue Type: Bug  (was: Improvement)

> Shading fails when a dependency's main artifact does not exist
> --
>
> Key: MSHADE-286
> URL: https://issues.apache.org/jira/browse/MSHADE-286
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Assignee: Mark Struberg
>Priority: Minor
>
> While looking at {{ShadeMojo.execute}}, I noticed that the artifacts to be 
> included for shading are not consistently checked for existence.
> For example, on line 404, the main artifact file is _not_ checked for 
> existence:
> {code:java}
> artifacts.add( project.getArtifact().getFile() );
> {code}
> But immediately below, the sources artifact file _is_ checked for existence:
> {code:java}
> if ( createSourcesJar )
> {
> File file = shadedSourcesArtifactFile();
> if ( file.isFile() )
> {
> sourceArtifacts.add( file );
> }
> }
> {code}
> Apparently, it's a conscious choice to fail when the main artifact does not 
> exist.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHADE-286) Shading fails when a dependency's main artifact does not exist

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSHADE-286:
---
Summary: Shading fails when a dependency's main artifact does not exist  
(was: Artifacts to be included for shading are not consistently checked for 
existence)

> Shading fails when a dependency's main artifact does not exist
> --
>
> Key: MSHADE-286
> URL: https://issues.apache.org/jira/browse/MSHADE-286
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Assignee: Mark Struberg
>Priority: Minor
>
> While looking at {{ShadeMojo.execute}}, I noticed that the artifacts to be 
> included for shading are not consistently checked for existence.
> For example, on line 404, the main artifact file is _not_ checked for 
> existence:
> {code:java}
> artifacts.add( project.getArtifact().getFile() );
> {code}
> But immediately below, the sources artifact file _is_ checked for existence:
> {code:java}
> if ( createSourcesJar )
> {
> File file = shadedSourcesArtifactFile();
> if ( file.isFile() )
> {
> sourceArtifacts.add( file );
> }
> }
> {code}
> Apparently, it's a conscious choice to fail when the main artifact does not 
> exist.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHADE-286) Artifacts to be included for shading are not consistently checked for existence

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSHADE-286:
---
Description: 
While looking at {{ShadeMojo.execute}}, I noticed that the artifacts to be 
included for shading are not consistently checked for existence.

For example, on line 404, the main artifact file is _not_ checked for existence:
{code:java}
artifacts.add( project.getArtifact().getFile() );
{code}
But immediately below, the sources artifact file _is_ checked for existence:
{code:java}
if ( createSourcesJar )
{
File file = shadedSourcesArtifactFile();
if ( file.isFile() )
{
sourceArtifacts.add( file );
}
}
{code}

Apparently, it's a conscious choice to fail when the main artifact does not 
exist.

  was:
While looking at {{ShadeMojo.execute}}, I noticed that the artifacts to be 
included for shading are not consistently checked for existence.

For example, on line 404, the main artifact file is _not_ checked for existence:
{code:java}
artifacts.add( project.getArtifact().getFile() );
{code}
But immediately below, the sources artifact file _is_ checked for existence:
{code:java}
if ( createSourcesJar )
{
File file = shadedSourcesArtifactFile();
if ( file.isFile() )
{
sourceArtifacts.add( file );
}
}
{code}

The line above


> Artifacts to be included for shading are not consistently checked for 
> existence
> ---
>
> Key: MSHADE-286
> URL: https://issues.apache.org/jira/browse/MSHADE-286
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Assignee: Mark Struberg
>Priority: Minor
>
> While looking at {{ShadeMojo.execute}}, I noticed that the artifacts to be 
> included for shading are not consistently checked for existence.
> For example, on line 404, the main artifact file is _not_ checked for 
> existence:
> {code:java}
> artifacts.add( project.getArtifact().getFile() );
> {code}
> But immediately below, the sources artifact file _is_ checked for existence:
> {code:java}
> if ( createSourcesJar )
> {
> File file = shadedSourcesArtifactFile();
> if ( file.isFile() )
> {
> sourceArtifacts.add( file );
> }
> }
> {code}
> Apparently, it's a conscious choice to fail when the main artifact does not 
> exist.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHADE-340) Shaded test jar artifact is not attached

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17003366#comment-17003366
 ] 

Peter De Maeyer commented on MSHADE-340:


Integration test added illustrating scenario, fix committed, PR created.

> Shaded test jar artifact is not attached
> 
>
> Key: MSHADE-340
> URL: https://issues.apache.org/jira/browse/MSHADE-340
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> When {{shadedArtifactAttached=true}} and {{shadeTestJar=true}}, the shaded 
> test jar file is created but the artifact is not attached to the project.
> As a result, projects that depend on the attached test artifact don't compile.
> This does not affect the default case {{shadedArtifactAttached=false}} where 
> the shaded artifact replaces the original artifact.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHADE-340) Shaded test jar artifact is not attached

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSHADE-340:
---
Description: 
When {{shadedArtifactAttached=true}} and {{shadeTestJar=true}}, the shaded test 
jar file is created but the artifact is not attached to the project.
As a result, projects that depend on the attached test artifact don't compile.
This does not affect the default case {{shadedArtifactAttached=false}} where 
the shaded artifact replaces the original artifact.

  was:
When {{shadedTestJar}} is set to {{true}}, the shaded test jar is not attached.
This does not affect the default case where the shaded artifact replaces the 
original artifact.


> Shaded test jar artifact is not attached
> 
>
> Key: MSHADE-340
> URL: https://issues.apache.org/jira/browse/MSHADE-340
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Major
>
> When {{shadedArtifactAttached=true}} and {{shadeTestJar=true}}, the shaded 
> test jar file is created but the artifact is not attached to the project.
> As a result, projects that depend on the attached test artifact don't compile.
> This does not affect the default case {{shadedArtifactAttached=false}} where 
> the shaded artifact replaces the original artifact.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHADE-339) Shaded test jar has wrong type "jar"

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSHADE-339:
---
Description: 
The shaded test jar has the wrong type "jar".
It should be "test-jar".

  was:The shaded test jar has the wrong type "jar" - that should be "test-jar".


> Shaded test jar has wrong type "jar"
> 
>
> Key: MSHADE-339
> URL: https://issues.apache.org/jira/browse/MSHADE-339
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The shaded test jar has the wrong type "jar".
> It should be "test-jar".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHADE-339) Shaded test jar has wrong type "jar"

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSHADE-339:
---
Description: The shaded test jar has the wrong type "jar" - that should be 
"test-jar".  (was: The shaded test jar introduced in the context of MSHADE-285 
has the wrong type "jar" - that should be "test-jar".)

> Shaded test jar has wrong type "jar"
> 
>
> Key: MSHADE-339
> URL: https://issues.apache.org/jira/browse/MSHADE-339
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The shaded test jar has the wrong type "jar" - that should be "test-jar".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MSHADE-340) Shaded test jar artifact is not attached

[Peter De Maeyer (Jira)]

Peter De Maeyer created MSHADE-340:
--

 Summary: Shaded test jar artifact is not attached
 Key: MSHADE-340
 URL: https://issues.apache.org/jira/browse/MSHADE-340
 Project: Maven Shade Plugin
  Issue Type: Bug
Affects Versions: 3.2.2
Reporter: Peter De Maeyer


When {{shadedTestJar}} is set to {{true}}, the shaded test jar is not attached.
This does not affect the default case where the shaded artifact replaces the 
original artifact.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHADE-339) Shaded test jar has wrong type "jar"

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSHADE-339:
---
Description: The shaded test jar introduced in the context of MSHADE-285 
has the wrong type "jar" - that should be "test-jar".  (was: The shaded test 
jar introduced in the context of MSHADE-285 has the wrong type "jar" - that 
should be "test-jar".
Also, the "test-jar" artifact is not attached to the project.)

> Shaded test jar has wrong type "jar"
> 
>
> Key: MSHADE-339
> URL: https://issues.apache.org/jira/browse/MSHADE-339
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Major
>
> The shaded test jar introduced in the context of MSHADE-285 has the wrong 
> type "jar" - that should be "test-jar".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHADE-339) Shaded test jar has wrong type "jar"

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSHADE-339:
---
Description: 
The shaded test jar introduced in the context of MSHADE-285 has the wrong type 
"jar" - that should be "test-jar".
Also, the "test-jar" artifact is not attached to the project.

  was:The shaded test jar introduced in the context of MSHADE-285 has the wrong 
type "jar" - that should be "test-jar".


> Shaded test jar has wrong type "jar"
> 
>
> Key: MSHADE-339
> URL: https://issues.apache.org/jira/browse/MSHADE-339
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Major
>
> The shaded test jar introduced in the context of MSHADE-285 has the wrong 
> type "jar" - that should be "test-jar".
> Also, the "test-jar" artifact is not attached to the project.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MSHADE-339) Shaded test jar has wrong type "jar"

[Peter De Maeyer (Jira)]

Peter De Maeyer created MSHADE-339:
--

 Summary: Shaded test jar has wrong type "jar"
 Key: MSHADE-339
 URL: https://issues.apache.org/jira/browse/MSHADE-339
 Project: Maven Shade Plugin
  Issue Type: Bug
Affects Versions: 3.2.2
Reporter: Peter De Maeyer


The shaded test jar introduced in the context of MSHADE-285 has the wrong type 
"jar" - that should be "test-jar".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSOURCES-125) Shaded test jar has wrong type "jar"

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSOURCES-125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17001976#comment-17001976
 ] 

Peter De Maeyer commented on MSOURCES-125:
--

Oops, wrong project... This should have been created in project MSHADE.

> Shaded test jar has wrong type "jar"
> 
>
> Key: MSOURCES-125
> URL: https://issues.apache.org/jira/browse/MSOURCES-125
> Project: Maven Source Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Peter De Maeyer
>Priority: Major
>
> The shaded test jar introduced in the context of MSHADE-285 has the wrong 
> type "jar" - it must be type "test-jar".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MSOURCES-125) Shaded test jar has wrong type "jar"

[Peter De Maeyer (Jira)]

Peter De Maeyer created MSOURCES-125:


 Summary: Shaded test jar has wrong type "jar"
 Key: MSOURCES-125
 URL: https://issues.apache.org/jira/browse/MSOURCES-125
 Project: Maven Source Plugin
  Issue Type: Bug
Affects Versions: 3.2.2
Reporter: Peter De Maeyer


The shaded test jar introduced in the context of MSHADE-285 has the wrong type 
"jar" - it must be type "test-jar".



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHADE-286) Artifacts to be included for shading are not consistently checked for existence

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSHADE-286:
---
Description: 
While looking at {{ShadeMojo.execute}}, I noticed that the artifacts to be 
included for shading are not consistently checked for existence.

For example, on line 404, the main artifact file is _not_ checked for existence:
{code:java}
artifacts.add( project.getArtifact().getFile() );
{code}
But immediately below, the sources artifact file _is_ checked for existence:
{code:java}
if ( createSourcesJar )
{
File file = shadedSourcesArtifactFile();
if ( file.isFile() )
{
sourceArtifacts.add( file );
}
}
{code}

The line above

  was:
While looking at {{ShadeMojo.execute}}, I noticed that the artifacts to be 
included for shading are not consistently checked for existence.

For example, on line 404, the main artifact file is _not_ checked for existence:
{code:java}
artifacts.add( project.getArtifact().getFile() );{code}
But immediately below, the sources artifact file _is_ checked for existence:
{code:java}
if ( createSourcesJar )
{
File file = shadedSourcesArtifactFile();
if ( file.isFile() )
{
sourceArtifacts.add( file );
}
}
{code}
Maybe there is a reason for this, but it seems inconsistent - it seems like a 
good idea to always check for existence before adding a file. I suppose the 
impact of this is very low - it's merely an optimization to omit non-existent 
files.


> Artifacts to be included for shading are not consistently checked for 
> existence
> ---
>
> Key: MSHADE-286
> URL: https://issues.apache.org/jira/browse/MSHADE-286
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Assignee: Mark Struberg
>Priority: Minor
>
> While looking at {{ShadeMojo.execute}}, I noticed that the artifacts to be 
> included for shading are not consistently checked for existence.
> For example, on line 404, the main artifact file is _not_ checked for 
> existence:
> {code:java}
> artifacts.add( project.getArtifact().getFile() );
> {code}
> But immediately below, the sources artifact file _is_ checked for existence:
> {code:java}
> if ( createSourcesJar )
> {
> File file = shadedSourcesArtifactFile();
> if ( file.isFile() )
> {
> sourceArtifacts.add( file );
> }
> }
> {code}
> The line above



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSOURCES-124) Sources and test sources should have separate artifact types

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSOURCES-124:
-
Priority: Minor  (was: Major)

> Sources and test sources should have separate artifact types
> 
>
> Key: MSOURCES-124
> URL: https://issues.apache.org/jira/browse/MSOURCES-124
> Project: Maven Source Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Imagine a project that has main and test sources, resulting in 4 artifacts:
> ||Artifact||Type||Default classifier||
> |Main JAR|"jar"| |
> |Test JAR|"test-jar"|"tests"|
> |Main sources|"java-source"|"sources"|
> |Test sources|"java-source"|"test-sources"|
> Both sources and test sources have have type "java-source".
> As a result, it is not possible to distinguish the sources from the test 
> sources based on type alone.
> The classifier can be used to make that distinction, but the classifier can 
> be overridden to be anything while the type is fixed.
> To fix this, I suggest to introduce a separate type "java-test-source" for 
> test sources.
> The only drawback of that is backward compatibility and impact on other 
> plugins which might use hard-coded types.
> On the other hand, attaching test sources is not often used, so I don't 
> expect it to break a lot, and it will be better in the long run.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MSOURCES-124) Sources and test sources should have separate artifact types

[Peter De Maeyer (Jira)]

Peter De Maeyer created MSOURCES-124:


 Summary: Sources and test sources should have separate artifact 
types
 Key: MSOURCES-124
 URL: https://issues.apache.org/jira/browse/MSOURCES-124
 Project: Maven Source Plugin
  Issue Type: Bug
Affects Versions: 3.2.1
Reporter: Peter De Maeyer


Imagine a project that has main and test sources, resulting in 4 artifacts:
||Artifact||Type||Default classifier||
|Main JAR|"jar"| |
|Test JAR|"test-jar"|"tests"|
|Main sources|"java-source"|"sources"|
|Test sources|"java-source"|"test-sources"|

Both sources and test sources have have type "java-source".
As a result, it is not possible to distinguish the sources from the test 
sources based on type alone.
The classifier can be used to make that distinction, but the classifier can be 
overridden to be anything while the type is fixed.
To fix this, I suggest to introduce a separate type "java-test-source" for test 
sources.
The only drawback of that is backward compatibility and impact on other plugins 
which might use hard-coded types.
On the other hand, attaching test sources is not often used, so I don't expect 
it to break a lot, and it will be better in the long run.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHADE-286) Artifacts to be included for shading are not consistently checked for existence

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSHADE-286:
---
Description: 
While looking at {{ShadeMojo.execute}}, I noticed that the artifacts to be 
included for shading are not consistently checked for existence.

For example, on line 404, the main artifact file is _not_ checked for existence:
{code:java}
artifacts.add( project.getArtifact().getFile() );{code}
But immediately below, the sources artifact file _is_ checked for existence:
{code:java}
if ( createSourcesJar )
{
File file = shadedSourcesArtifactFile();
if ( file.isFile() )
{
sourceArtifacts.add( file );
}
}
{code}
Maybe there is a reason for this, but it seems inconsistent - it seems like a 
good idea to always check for existence before adding a file. I suppose the 
impact of this is very low - it's merely an optimization to omit non-existent 
files.

  was:
While looking at {{ShaderMojo.execute}}, I noticed that the artifacts to be 
included for shading are not consistently checked for existence.

For example, on line 404, the main artifact file is _not_ checked for existence:
{code:java}
artifacts.add( project.getArtifact().getFile() );{code}
But immediately below, the sources artifact file _is_ checked for existence:
{code:java}
if ( createSourcesJar )
{
File file = shadedSourcesArtifactFile();
if ( file.isFile() )
{
sourceArtifacts.add( file );
}
}
{code}
Maybe there is a reason for this, but it seems inconsistent - it seems like a 
good idea to always check for existence before adding a file. I suppose the 
impact of this is very low - it's merely an optimization to omit non-existent 
files.


> Artifacts to be included for shading are not consistently checked for 
> existence
> ---
>
> Key: MSHADE-286
> URL: https://issues.apache.org/jira/browse/MSHADE-286
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Priority: Minor
>
> While looking at {{ShadeMojo.execute}}, I noticed that the artifacts to be 
> included for shading are not consistently checked for existence.
> For example, on line 404, the main artifact file is _not_ checked for 
> existence:
> {code:java}
> artifacts.add( project.getArtifact().getFile() );{code}
> But immediately below, the sources artifact file _is_ checked for existence:
> {code:java}
> if ( createSourcesJar )
> {
> File file = shadedSourcesArtifactFile();
> if ( file.isFile() )
> {
> sourceArtifacts.add( file );
> }
> }
> {code}
> Maybe there is a reason for this, but it seems inconsistent - it seems like a 
> good idea to always check for existence before adding a file. I suppose the 
> impact of this is very low - it's merely an optimization to omit non-existent 
> files.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Updated] (MSHADE-333) Shading of sources uses hard-coded classifier "sources"

[Peter De Maeyer (Jira)]

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

Peter De Maeyer updated MSHADE-333:
---
Summary: Shading of sources uses hard-coded classifier "sources"  (was: 
Shading sources uses hardcoded classifier "sources")

> Shading of sources uses hard-coded classifier "sources"
> ---
>
> Key: MSHADE-333
> URL: https://issues.apache.org/jira/browse/MSHADE-333
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Peter De Maeyer
>Priority: Minor
>
> Shading sources only works for the default classifier "sources".
> The 
> [maven-source-plugin|https://maven.apache.org/plugins/maven-source-plugin/jar-mojo.html]
>  can be configured to use a different classifier with the optional parameter 
> {{}}, but then shading no longer works.
> Ideally, shading of sources should adopt/recognize the classifier(s) of the 
> project(s).
> The root cause is that the classifier "sources" is hard-coded in 
> {{ShadeMojo}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (MSHADE-333) Shading sources uses hardcoded classifier "sources"

[Peter De Maeyer (Jira)]

Peter De Maeyer created MSHADE-333:
--

 Summary: Shading sources uses hardcoded classifier "sources"
 Key: MSHADE-333
 URL: https://issues.apache.org/jira/browse/MSHADE-333
 Project: Maven Shade Plugin
  Issue Type: Bug
Affects Versions: 3.2.1
Reporter: Peter De Maeyer


Shading sources only works for the default classifier "sources".
The 
[maven-source-plugin|https://maven.apache.org/plugins/maven-source-plugin/jar-mojo.html]
 can be configured to use a different classifier with the optional parameter 
{{}}, but then shading no longer works.
Ideally, shading of sources should adopt/recognize the classifier(s) of the 
project(s).

The root cause is that the classifier "sources" is hard-coded in {{ShadeMojo}}.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHADE-285) It should be possible to shade test sources as a JAR

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16970852#comment-16970852
 ] 

Peter De Maeyer commented on MSHADE-285:


Fixed + integration test added, pull request created.
I took the second approach: introduced an optional parameter 
{{createTestSourcesJar}} with similar behavior as {{createSourcesJar}}, but for 
test sources.

> It should be possible to shade test sources as a JAR
> 
>
> Key: MSHADE-285
> URL: https://issues.apache.org/jira/browse/MSHADE-285
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The configuration option {{createSourcesJar}} allows to shade sources JAR, 
> but there is no such option for test sources.
> I see two solutions:
>  # Extend the semantics of {{createSourcesJar}} such that, when combined with 
> {{shadeTestJar}}, is also creates the _test_ sources JAR.
>  # Introduce a new configuration option {{createTestSourcesJar}}, similar to 
> {{createSourcesJar}}.
> The former is very intuitive, but it lacks the flexibility to create a JAR, 
> sources JAR, test JAR, but _no_ test sources JAR. The latter allows more 
> flexibility.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHADE-284) Shaded test JARs are always empty

[Peter De Maeyer (Jira)]

[ 
https://issues.apache.org/jira/browse/MSHADE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16965103#comment-16965103
 ] 

Peter De Maeyer commented on MSHADE-284:


Integration test written, code fixed, pull request created.

> Shaded test JARs are always empty
> -
>
> Key: MSHADE-284
> URL: https://issues.apache.org/jira/browse/MSHADE-284
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Priority: Major
> Attachments: shadeTestJar.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Shading test JARs using the {{shadeTestJar}} configuration option yields an 
> empty test JAR. This has been noticed by others, see for example Steve K's 
> answer [on 
> StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
>  but people have reverted to other hacks and workarounds to overcome this 
> (e.g. use a different plugin).
> Scenario:
>  # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole 
> purpose to make an uber JAR for the combination of the first two modules. 
> {{uber}} itself has no sources.
>  # Both modules have both {{jar}} and {{test-jar}} artifacts.
>  # Configure the {{maven-shade-plugin}} in the {{uber}} module with the 
> configuration option {{shadeTestJar}} set to {{true}}.
> Expected:
>  # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and 
> {{impl.jar}}.
>  # Content of {{uber-tests.jar}} is the aggregate content of 
> {{api-tests.jar}} and {{impl-tests.jar}}.
> Actual:
>  # Content of {{uber.jar}} is as expected.
>  # {{uber-tests.jar}} is empty.
> Root cause:
>  * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is 
> buggy and incomplete.
>  * The call to {{processArtifactSelectors}} on line 425 doesn't pass the 
> {{testArtifacts}}, so they are never correctly filled in.
>  * The implementation of {{processArtifactSelectors}} doesn't deal with test 
> JARs at all and has to be extended to support them.
>  * The "if" statement on line 452 incorrectly treats a test JAR as sources.
> This whole feature looks like it was done in a hurry as a sloppy copy-paste 
> job, and in 5 years nobody took the time to report or fix it. Amazing. 
> Anyway, you can find my proposed fix in attachment: [^shadeTestJar.patch]. I 
> have tested it manually on my project and it works.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Commented] (MSHADE-284) Shaded test JARs are always empty

[Peter De Maeyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16434638#comment-16434638
 ] 

Peter De Maeyer commented on MSHADE-284:


OK, that's a fair point, I'll try to do that after I familiarize myself with 
the test code.

> Shaded test JARs are always empty
> -
>
> Key: MSHADE-284
> URL: https://issues.apache.org/jira/browse/MSHADE-284
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Priority: Major
> Attachments: shadeTestJar.patch
>
>
> Shading test JARs using the {{shadeTestJar}} configuration option yields an 
> empty test JAR. This has been noticed by others, see for example Steve K's 
> answer [on 
> StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
>  but people have reverted to other hacks and workarounds to overcome this 
> (e.g. use a different plugin).
> Scenario:
>  # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole 
> purpose to make an uber JAR for the combination of the first two modules. 
> {{uber}} itself has no sources.
>  # Both modules have both {{jar}} and {{test-jar}} artifacts.
>  # Configure the {{maven-shade-plugin}} in the {{uber}} module with the 
> configuration option {{shadeTestJar}} set to {{true}}.
> Expected:
>  # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and 
> {{impl.jar}}.
>  # Content of {{uber-tests.jar}} is the aggregate content of 
> {{api-tests.jar}} and {{impl-tests.jar}}.
> Actual:
>  # Content of {{uber.jar}} is as expected.
>  # {{uber-tests.jar}} is empty.
> Root cause:
>  * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is 
> buggy and incomplete.
>  * The call to {{processArtifactSelectors}} on line 425 doesn't pass the 
> {{testArtifacts}}, so they are never correctly filled in.
>  * The implementation of {{processArtifactSelectors}} doesn't deal with test 
> JARs at all and has to be extended to support them.
>  * The "if" statement on line 452 incorrectly treats a test JAR as sources.
> This whole feature looks like it was done in a hurry as a sloppy copy-paste 
> job, and in 5 years nobody took the time to report or fix it. Amazing. 
> Anyway, you can find my proposed fix in attachment: [^shadeTestJar.patch]. I 
> have tested it manually on my project and it works.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MSHADE-284) Shaded test JARs are always empty

[Peter De Maeyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16423099#comment-16423099
 ] 

Peter De Maeyer edited comment on MSHADE-284 at 4/2/18 8:53 PM:


While fixing this issue, I found MSHADE-285 and MSHADE-286.


was (Author: peterdm):
While fixing this issue, I found MSHADE-285.

> Shaded test JARs are always empty
> -
>
> Key: MSHADE-284
> URL: https://issues.apache.org/jira/browse/MSHADE-284
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Priority: Major
> Attachments: shadeTestJar.patch
>
>
> Shading test JARs using the {{shadeTestJar}} configuration option yields an 
> empty test JAR. This has been noticed by others, see for example Steve K's 
> answer [on 
> StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
>  but people have reverted to other hacks and workarounds to overcome this 
> (e.g. use a different plugin).
> Scenario:
>  # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole 
> purpose to make an uber JAR for the combination of the first two modules. 
> {{uber}} itself has no sources.
>  # Both modules have both {{jar}} and {{test-jar}} artifacts.
>  # Configure the {{maven-shade-plugin}} in the {{uber}} module with the 
> configuration option {{shadeTestJar}} set to {{true}}.
> Expected:
>  # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and 
> {{impl.jar}}.
>  # Content of {{uber-tests.jar}} is the aggregate content of 
> {{api-tests.jar}} and {{impl-tests.jar}}.
> Actual:
>  # Content of {{uber.jar}} is as expected.
>  # {{uber-tests.jar}} is empty.
> Root cause:
>  * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is 
> buggy and incomplete.
>  * The call to {{processArtifactSelectors}} on line 425 doesn't pass the 
> {{testArtifacts}}, so they are never correctly filled in.
>  * The implementation of {{processArtifactSelectors}} doesn't deal with test 
> JARs at all and has to be extended to support them.
>  * The "if" statement on line 452 incorrectly treats a test JAR as sources.
> This whole feature looks like it was done in a hurry as a sloppy copy-paste 
> job, and in 5 years nobody took the time to report or fix it. Amazing. 
> Anyway, you can find my proposed fix in attachment: [^shadeTestJar.patch]. I 
> have tested it manually on my project and it works.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Comment Edited] (MSHADE-284) Shaded test JARs are always empty

[Peter De Maeyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16423099#comment-16423099
 ] 

Peter De Maeyer edited comment on MSHADE-284 at 4/2/18 8:53 PM:


While fixing this issue, I also found MSHADE-285 and MSHADE-286.


was (Author: peterdm):
While fixing this issue, I found MSHADE-285 and MSHADE-286.

> Shaded test JARs are always empty
> -
>
> Key: MSHADE-284
> URL: https://issues.apache.org/jira/browse/MSHADE-284
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Priority: Major
> Attachments: shadeTestJar.patch
>
>
> Shading test JARs using the {{shadeTestJar}} configuration option yields an 
> empty test JAR. This has been noticed by others, see for example Steve K's 
> answer [on 
> StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
>  but people have reverted to other hacks and workarounds to overcome this 
> (e.g. use a different plugin).
> Scenario:
>  # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole 
> purpose to make an uber JAR for the combination of the first two modules. 
> {{uber}} itself has no sources.
>  # Both modules have both {{jar}} and {{test-jar}} artifacts.
>  # Configure the {{maven-shade-plugin}} in the {{uber}} module with the 
> configuration option {{shadeTestJar}} set to {{true}}.
> Expected:
>  # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and 
> {{impl.jar}}.
>  # Content of {{uber-tests.jar}} is the aggregate content of 
> {{api-tests.jar}} and {{impl-tests.jar}}.
> Actual:
>  # Content of {{uber.jar}} is as expected.
>  # {{uber-tests.jar}} is empty.
> Root cause:
>  * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is 
> buggy and incomplete.
>  * The call to {{processArtifactSelectors}} on line 425 doesn't pass the 
> {{testArtifacts}}, so they are never correctly filled in.
>  * The implementation of {{processArtifactSelectors}} doesn't deal with test 
> JARs at all and has to be extended to support them.
>  * The "if" statement on line 452 incorrectly treats a test JAR as sources.
> This whole feature looks like it was done in a hurry as a sloppy copy-paste 
> job, and in 5 years nobody took the time to report or fix it. Amazing. 
> Anyway, you can find my proposed fix in attachment: [^shadeTestJar.patch]. I 
> have tested it manually on my project and it works.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MSHADE-286) Artifacts to be included for shading are not consistently checked for existence

[Peter De Maeyer (JIRA)]

Peter De Maeyer created MSHADE-286:
--

 Summary: Artifacts to be included for shading are not consistently 
checked for existence
 Key: MSHADE-286
 URL: https://issues.apache.org/jira/browse/MSHADE-286
 Project: Maven Shade Plugin
  Issue Type: Improvement
Affects Versions: 3.1.0
Reporter: Peter De Maeyer


While looking at {{ShaderMojo.execute}}, I noticed that the artifacts to be 
included for shading are not consistently checked for existence.

For example, on line 404, the main artifact file is _not_ checked for existence:
{code:java}
artifacts.add( project.getArtifact().getFile() );{code}
But immediately below, the sources artifact file _is_ checked for existence:
{code:java}
if ( createSourcesJar )
{
File file = shadedSourcesArtifactFile();
if ( file.isFile() )
{
sourceArtifacts.add( file );
}
}
{code}
Maybe there is a reason for this, but it seems inconsistent - it seems like a 
good idea to always check for existence before adding a file. I suppose the 
impact of this is very low - it's merely an optimization to omit non-existent 
files.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MSHADE-284) Shaded test JARs are always empty

[Peter De Maeyer (JIRA)]

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

Peter De Maeyer updated MSHADE-284:
---
Description: 
Shading test JARs using the {{shadeTestJar}} configuration option yields an 
empty test JAR. This has been noticed by others, see for example Steve K's 
answer [on 
StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
 but people have reverted to other hacks and workarounds to overcome this (e.g. 
use a different plugin).

Scenario:
 # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole 
purpose to make an uber JAR for the combination of the first two modules. 
{{uber}} itself has no sources.
 # Both modules have both {{jar}} and {{test-jar}} artifacts.
 # Configure the {{maven-shade-plugin}} in the {{uber}} module with the 
configuration option {{shadeTestJar}} set to {{true}}.

Expected:
 # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and 
{{impl.jar}}.
 # Content of {{uber-tests.jar}} is the aggregate content of {{api-tests.jar}} 
and {{impl-tests.jar}}.

Actual:
 # Content of {{uber.jar}} is as expected.
 # {{uber-tests.jar}} is empty.

Root cause:
 * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is 
buggy and incomplete.
 * The call to {{processArtifactSelectors}} on line 425 doesn't pass the 
{{testArtifacts}}, so they are never correctly filled in.
 * The implementation of {{processArtifactSelectors}} doesn't deal with test 
JARs at all and has to be extended to support them.
 * The "if" statement on line 452 incorrectly treats a test JAR as sources.

This whole feature looks like it was done in a hurry as a sloppy copy-paste 
job, and in 5 years nobody took the time to report or fix it. Amazing. Anyway; 
you can find my proposed fix in attachment: [^shadeTestJar.patch]. I have 
tested it manually on my project and it works.

  was:
Shading test JARs using the {{shadeTestJar}} configuration option yields an 
empty test JAR. This has been noticed by others, see for example Steve K's 
answer [on 
StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
 but people have reverted to other hacks and workarounds to overcome this (e.g. 
use a different plugin).

Scenario:
 # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole 
purpose to make an uber JAR for the combination of the first two modules. 
{{uber}} itself has no sources.
 # Both modules have both {{jar}} and {{test-jar}} artifacts.
 # Configure the {{maven-shade-plugin}} in the {{uber}} module with the 
configuration option {{shadeTestJar}} set to {{true}}.

Expected:
 # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and 
{{impl.jar}}.
 # Content of {{uber-tests.jar}} is the aggregate content of {{api-tests.jar}} 
and {{impl-tests.jar}}.

Actual:
 # Content of {{uber.jar}} is as expected.
 # {{uber-tests.jar}} is empty.

Root cause:
 * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is 
buggy and incomplete.
 * The call to {{processArtifactSelectors}} on line 425 doesn't pass the 
{{testArtifacts}}, so they are never correctly filled in.
 * The implementation of {{processArtifactSelectors}} doesn't deal with test 
JARs at all and has to be extended to support them.
 * The "if" statement on line 452 incorrectly treats a test JAR as sources.

This whole feature looks like it was done in a hurry as a sloppy copy-paste 
job, and in 5 years nobody took the time to report or fix it. Amazing. You can 
find my proposed fix in attachment: [^shadeTestJar.patch]. I have tested it 
manually on my project and it works.


> Shaded test JARs are always empty
> -
>
> Key: MSHADE-284
> URL: https://issues.apache.org/jira/browse/MSHADE-284
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Priority: Major
> Attachments: shadeTestJar.patch
>
>
> Shading test JARs using the {{shadeTestJar}} configuration option yields an 
> empty test JAR. This has been noticed by others, see for example Steve K's 
> answer [on 
> StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
>  but people have reverted to other hacks and workarounds to overcome this 
> (e.g. use a different plugin).
> Scenario:
>  # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole 
> purpose to make an uber JAR for the combination of the first two modules. 
> {{uber}} itself has no sources.
>  # Both modules have both {{jar}} and {{test-jar}} artifacts.
>  # Configure the {{maven-shade-plugin}} 

[jira] [Updated] (MSHADE-284) Shaded test JARs are always empty

[Peter De Maeyer (JIRA)]

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

Peter De Maeyer updated MSHADE-284:
---
Description: 
Shading test JARs using the {{shadeTestJar}} configuration option yields an 
empty test JAR. This has been noticed by others, see for example Steve K's 
answer [on 
StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
 but people have reverted to other hacks and workarounds to overcome this (e.g. 
use a different plugin).

Scenario:
 # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole 
purpose to make an uber JAR for the combination of the first two modules. 
{{uber}} itself has no sources.
 # Both modules have both {{jar}} and {{test-jar}} artifacts.
 # Configure the {{maven-shade-plugin}} in the {{uber}} module with the 
configuration option {{shadeTestJar}} set to {{true}}.

Expected:
 # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and 
{{impl.jar}}.
 # Content of {{uber-tests.jar}} is the aggregate content of {{api-tests.jar}} 
and {{impl-tests.jar}}.

Actual:
 # Content of {{uber.jar}} is as expected.
 # {{uber-tests.jar}} is empty.

Root cause:
 * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is 
buggy and incomplete.
 * The call to {{processArtifactSelectors}} on line 425 doesn't pass the 
{{testArtifacts}}, so they are never correctly filled in.
 * The implementation of {{processArtifactSelectors}} doesn't deal with test 
JARs at all and has to be extended to support them.
 * The "if" statement on line 452 incorrectly treats a test JAR as sources.

This whole feature looks like it was done in a hurry as a sloppy copy-paste 
job, and in 5 years nobody took the time to report or fix it. Amazing. Anyway, 
you can find my proposed fix in attachment: [^shadeTestJar.patch]. I have 
tested it manually on my project and it works.

  was:
Shading test JARs using the {{shadeTestJar}} configuration option yields an 
empty test JAR. This has been noticed by others, see for example Steve K's 
answer [on 
StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
 but people have reverted to other hacks and workarounds to overcome this (e.g. 
use a different plugin).

Scenario:
 # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole 
purpose to make an uber JAR for the combination of the first two modules. 
{{uber}} itself has no sources.
 # Both modules have both {{jar}} and {{test-jar}} artifacts.
 # Configure the {{maven-shade-plugin}} in the {{uber}} module with the 
configuration option {{shadeTestJar}} set to {{true}}.

Expected:
 # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and 
{{impl.jar}}.
 # Content of {{uber-tests.jar}} is the aggregate content of {{api-tests.jar}} 
and {{impl-tests.jar}}.

Actual:
 # Content of {{uber.jar}} is as expected.
 # {{uber-tests.jar}} is empty.

Root cause:
 * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is 
buggy and incomplete.
 * The call to {{processArtifactSelectors}} on line 425 doesn't pass the 
{{testArtifacts}}, so they are never correctly filled in.
 * The implementation of {{processArtifactSelectors}} doesn't deal with test 
JARs at all and has to be extended to support them.
 * The "if" statement on line 452 incorrectly treats a test JAR as sources.

This whole feature looks like it was done in a hurry as a sloppy copy-paste 
job, and in 5 years nobody took the time to report or fix it. Amazing. Anyway; 
you can find my proposed fix in attachment: [^shadeTestJar.patch]. I have 
tested it manually on my project and it works.


> Shaded test JARs are always empty
> -
>
> Key: MSHADE-284
> URL: https://issues.apache.org/jira/browse/MSHADE-284
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Priority: Major
> Attachments: shadeTestJar.patch
>
>
> Shading test JARs using the {{shadeTestJar}} configuration option yields an 
> empty test JAR. This has been noticed by others, see for example Steve K's 
> answer [on 
> StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
>  but people have reverted to other hacks and workarounds to overcome this 
> (e.g. use a different plugin).
> Scenario:
>  # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole 
> purpose to make an uber JAR for the combination of the first two modules. 
> {{uber}} itself has no sources.
>  # Both modules have both {{jar}} and {{test-jar}} artifacts.
>  # Configure the {{maven-shade-p

[jira] [Updated] (MSHADE-284) shadeTestJar doesn't work - shaded test JARs are always empty

[Peter De Maeyer (JIRA)]

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

Peter De Maeyer updated MSHADE-284:
---
Summary: shadeTestJar doesn't work - shaded test JARs are always empty  
(was: Shaded test JARs using shadeTestJar are always empty)

> shadeTestJar doesn't work - shaded test JARs are always empty
> -
>
> Key: MSHADE-284
> URL: https://issues.apache.org/jira/browse/MSHADE-284
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Priority: Major
> Attachments: shadeTestJar.patch
>
>
> Shading test JARs using the {{shadeTestJar}} configuration option yields an 
> empty test JAR. This has been noticed by others, see for example Steve K's 
> answer [on 
> StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
>  but people have reverted to other hacks and workarounds to overcome this 
> (e.g. use a different plugin).
> Scenario:
>  # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole 
> purpose to make an uber JAR for the combination of the first two modules. 
> {{uber}} itself has no sources.
>  # Both modules have both {{jar}} and {{test-jar}} artifacts.
>  # Configure the {{maven-shade-plugin}} in the {{uber}} module with the 
> configuration option {{shadeTestJar}} set to {{true}}.
> Expected:
>  # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and 
> {{impl.jar}}.
>  # Content of {{uber-tests.jar}} is the aggregate content of 
> {{api-tests.jar}} and {{impl-tests.jar}}.
> Actual:
>  # Content of {{uber.jar}} is as expected.
>  # {{uber-tests.jar}} is empty.
> Root cause:
>  * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is 
> buggy and incomplete.
>  * The call to {{processArtifactSelectors}} on line 425 doesn't pass the 
> {{testArtifacts}}, so they are never correctly filled in.
>  * The implementation of {{processArtifactSelectors}} doesn't deal with test 
> JARs at all and has to be extended to support them.
>  * The "if" statement on line 452 incorrectly treats a test JAR as sources.
> This whole feature looks like it was done in a hurry as a sloppy copy-paste 
> job, and in 5 years nobody took the time to report or fix it. Amazing. You 
> can find my proposed fix in attachment: [^shadeTestJar.patch]. I have tested 
> it manually on my project and it works.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MSHADE-284) Shaded test JARs are always empty

[Peter De Maeyer (JIRA)]

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

Peter De Maeyer updated MSHADE-284:
---
Summary: Shaded test JARs are always empty  (was: shadeTestJar doesn't work 
- shaded test JARs are always empty)

> Shaded test JARs are always empty
> -
>
> Key: MSHADE-284
> URL: https://issues.apache.org/jira/browse/MSHADE-284
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Priority: Major
> Attachments: shadeTestJar.patch
>
>
> Shading test JARs using the {{shadeTestJar}} configuration option yields an 
> empty test JAR. This has been noticed by others, see for example Steve K's 
> answer [on 
> StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
>  but people have reverted to other hacks and workarounds to overcome this 
> (e.g. use a different plugin).
> Scenario:
>  # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole 
> purpose to make an uber JAR for the combination of the first two modules. 
> {{uber}} itself has no sources.
>  # Both modules have both {{jar}} and {{test-jar}} artifacts.
>  # Configure the {{maven-shade-plugin}} in the {{uber}} module with the 
> configuration option {{shadeTestJar}} set to {{true}}.
> Expected:
>  # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and 
> {{impl.jar}}.
>  # Content of {{uber-tests.jar}} is the aggregate content of 
> {{api-tests.jar}} and {{impl-tests.jar}}.
> Actual:
>  # Content of {{uber.jar}} is as expected.
>  # {{uber-tests.jar}} is empty.
> Root cause:
>  * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is 
> buggy and incomplete.
>  * The call to {{processArtifactSelectors}} on line 425 doesn't pass the 
> {{testArtifacts}}, so they are never correctly filled in.
>  * The implementation of {{processArtifactSelectors}} doesn't deal with test 
> JARs at all and has to be extended to support them.
>  * The "if" statement on line 452 incorrectly treats a test JAR as sources.
> This whole feature looks like it was done in a hurry as a sloppy copy-paste 
> job, and in 5 years nobody took the time to report or fix it. Amazing. You 
> can find my proposed fix in attachment: [^shadeTestJar.patch]. I have tested 
> it manually on my project and it works.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-285) It should be possible to shade test sources as a JAR

[Peter De Maeyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16423100#comment-16423100
 ] 

Peter De Maeyer commented on MSHADE-285:


Feel free to assign back to me, I'd be happy to fix this myself if you agree 
with the solution.

> It should be possible to shade test sources as a JAR
> 
>
> Key: MSHADE-285
> URL: https://issues.apache.org/jira/browse/MSHADE-285
> Project: Maven Shade Plugin
>  Issue Type: Improvement
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Priority: Major
>
> The configuration option {{createSourcesJar}} allows to shade sources JAR, 
> but there is no such option for test sources.
> I see two solutions:
>  # Extend the semantics of {{createSourcesJar}} such that, when combined with 
> {{shadeTestJar}}, is also creates the _test_ sources JAR.
>  # Introduce a new configuration option {{createTestSourcesJar}}, similar to 
> {{createSourcesJar}}.
> The former is very intuitive, but it lacks the flexibility to create a JAR, 
> sources JAR, test JAR, but _no_ test sources JAR. The latter allows more 
> flexibility.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (MSHADE-284) Shaded test JARs using shadeTestJar are always empty

[Peter De Maeyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/MSHADE-284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16423099#comment-16423099
 ] 

Peter De Maeyer commented on MSHADE-284:


While fixing this issue, I found MSHADE-285.

> Shaded test JARs using shadeTestJar are always empty
> 
>
> Key: MSHADE-284
> URL: https://issues.apache.org/jira/browse/MSHADE-284
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Priority: Major
> Attachments: shadeTestJar.patch
>
>
> Shading test JARs using the {{shadeTestJar}} configuration option yields an 
> empty test JAR. This has been noticed by others, see for example Steve K's 
> answer [on 
> StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
>  but people have reverted to other hacks and workarounds to overcome this 
> (e.g. use a different plugin).
> Scenario:
>  # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole 
> purpose to make an uber JAR for the combination of the first two modules. 
> {{uber}} itself has no sources.
>  # Both modules have both {{jar}} and {{test-jar}} artifacts.
>  # Configure the {{maven-shade-plugin}} in the {{uber}} module with the 
> configuration option {{shadeTestJar}} set to {{true}}.
> Expected:
>  # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and 
> {{impl.jar}}.
>  # Content of {{uber-tests.jar}} is the aggregate content of 
> {{api-tests.jar}} and {{impl-tests.jar}}.
> Actual:
>  # Content of {{uber.jar}} is as expected.
>  # {{uber-tests.jar}} is empty.
> Root cause:
>  * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is 
> buggy and incomplete.
>  * The call to {{processArtifactSelectors}} on line 425 doesn't pass the 
> {{testArtifacts}}, so they are never correctly filled in.
>  * The implementation of {{processArtifactSelectors}} doesn't deal with test 
> JARs at all and has to be extended to support them.
>  * The "if" statement on line 452 incorrectly treats a test JAR as sources.
> This whole feature looks like it was done in a hurry as a sloppy copy-paste 
> job, and in 5 years nobody took the time to report or fix it. Amazing. You 
> can find my proposed fix in attachment: [^shadeTestJar.patch]. I have tested 
> it manually on my project and it works.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (MSHADE-285) It should be possible to shade test sources as a JAR

[Peter De Maeyer (JIRA)]

Peter De Maeyer created MSHADE-285:
--

 Summary: It should be possible to shade test sources as a JAR
 Key: MSHADE-285
 URL: https://issues.apache.org/jira/browse/MSHADE-285
 Project: Maven Shade Plugin
  Issue Type: Improvement
Affects Versions: 3.1.0
Reporter: Peter De Maeyer


The configuration option {{createSourcesJar}} allows to shade sources JAR, but 
there is no such option for test sources.

I see two solutions:
 # Extend the semantics of {{createSourcesJar}} such that, when combined with 
{{shadeTestJar}}, is also creates the _test_ sources JAR.
 # Introduce a new configuration option {{createTestSourcesJar}}, similar to 
{{createSourcesJar}}.

The former is very intuitive, but it lacks the flexibility to create a JAR, 
sources JAR, test JAR, but _no_ test sources JAR. The latter allows more 
flexibility.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MSHADE-284) Shaded test JARs using shadeTestJar are always empty

[Peter De Maeyer (JIRA)]

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

Peter De Maeyer updated MSHADE-284:
---
Description: 
Shading test JARs using the {{shadeTestJar}} configuration option yields an 
empty test JAR. This has been noticed by others, see for example Steve K's 
answer [on 
StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
 but people have reverted to other hacks and workarounds to overcome this (e.g. 
use a different plugin).

Scenario:
 # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole 
purpose to make an uber JAR for the combination of the first two modules. 
{{uber}} itself has no sources.
 # Both modules have both {{jar}} and {{test-jar}} artifacts.
 # Configure the {{maven-shade-plugin}} in the {{uber}} module with the 
configuration option {{shadeTestJar}} set to {{true}}.

Expected:
 # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and 
{{impl.jar}}.
 # Content of {{uber-tests.jar}} is the aggregate content of {{api-tests.jar}} 
and {{impl-tests.jar}}.

Actual:
 # Content of {{uber.jar}} is as expected.
 # {{uber-tests.jar}} is empty.

Root cause:
 * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is 
buggy and incomplete.
 * The call to {{processArtifactSelectors}} on line 425 doesn't pass the 
{{testArtifacts}}, so they are never correctly filled in.
 * The implementation of {{processArtifactSelectors}} doesn't deal with test 
JARs at all and has to be extended to support them.
 * The "if" statement on line 452 incorrectly treats a test JAR as sources.

This whole feature looks like it was done in a hurry as a sloppy copy-paste 
job, and in 5 years nobody took the time to report or fix it. Amazing. You can 
find my proposed fix in attachment: [^shadeTestJar.patch]. I have tested it 
manually on my project and it works.

  was:
Shading test JARs using the {{shadeTestJar}} configuration option yields an 
empty test JAR. This has been noticed by others, see for example Steve K's 
answer [on 
StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
 but people have reverted to other hacks and workarounds to overcome this (e.g. 
use a different plugin).

Scenario:
 # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole 
purpose to make an uber JAR for the combination of the first two modules. 
{{uber}} itself has no sources.
 # Both modules have both {{jar}} and {{test-jar}} artifacts.
 # Configure the {{maven-shade-plugin}} in the {{uber}} module with the 
configuration option {{shadeTestJar}} set to {{true}}.

Expected:
 # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and 
{{impl.jar}}.
 # Content of {{uber-tests.jar}} is the aggregate content of {{api-tests.jar}} 
and {{impl-tests.jar}}.

Actual:
 # Content of {{uber.jar}} is as expected.
 # {{uber-tests.jar}} is empty.

Root cause:
 * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is 
buggy and incomplete.
 * The call to {{processArtifactSelectors}} on line 425 doesn't pass the 
{{testArtifacts}}, so they are never correctly filled in.
 * The implementation of {{processArtifactSelectors}} doesn't deal with test 
JARs at all and has to be extended to support them.
 * The "if" statement on line 452 incorrectly treats a test JAR as sources.

This whole feature looks like it was done in a hurry as a sloppy copy-paste 
job, and in 5 years nobody took the time to report or fix it. Amazing. Oh well, 
let me be the one that fixes it then. You can find my fix in attachment: 
[^shadeTestJar.patch].


> Shaded test JARs using shadeTestJar are always empty
> 
>
> Key: MSHADE-284
> URL: https://issues.apache.org/jira/browse/MSHADE-284
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Priority: Major
> Attachments: shadeTestJar.patch
>
>
> Shading test JARs using the {{shadeTestJar}} configuration option yields an 
> empty test JAR. This has been noticed by others, see for example Steve K's 
> answer [on 
> StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
>  but people have reverted to other hacks and workarounds to overcome this 
> (e.g. use a different plugin).
> Scenario:
>  # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole 
> purpose to make an uber JAR for the combination of the first two modules. 
> {{uber}} itself has no sources.
>  # Both modules have both {{jar}} and {{test-jar}} artifacts.
>  # Configure the {{maven-s

[jira] [Created] (MSHADE-284) Shading test JARs using shadeTestJar does not work

[Peter De Maeyer (JIRA)]

Peter De Maeyer created MSHADE-284:
--

 Summary: Shading test JARs using shadeTestJar does not work
 Key: MSHADE-284
 URL: https://issues.apache.org/jira/browse/MSHADE-284
 Project: Maven Shade Plugin
  Issue Type: Bug
Affects Versions: 3.1.0
Reporter: Peter De Maeyer
 Attachments: shadeTestJar.patch

Shading test JARs using the {{shadeTestJar}} configuration option yields an 
empty test JAR. This has been noticed by others, see for example Steve K's 
answer [on 
StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
 but people have reverted to other hacks and workarounds to overcome this (e.g. 
use a different plugin).

Scenario:
 # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole 
purpose to make an uber JAR for the combination of the first two modules. 
{{uber}} itself has no sources.
 # Both modules have both {{jar}} and {{test-jar}} artifacts.
 # Configure the {{maven-shade-plugin}} in the {{uber}} module with the 
configuration option {{shadeTestJar}} set to {{true}}.

Expected:
 # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and 
{{impl.jar}}.
 # Content of {{uber-tests.jar}} is the aggregate content of {{api-tests.jar}} 
and {{impl-tests.jar}}.

Actual:
 # Content of {{uber.jar}} is as expected.
 # {{uber-tests.jar}} is empty.

Root cause:
 * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is 
buggy and incomplete.
 * The call to {{processArtifactSelectors}} on line 425 doesn't pass the 
{{testArtifacts}}, so they are never correctly filled in.
 * The implementation of {{processArtifactSelectors}} doesn't deal with test 
JARs at all and has to be extended to support them.
 * The "if" statement on line 452 incorrectly treats a test JAR as sources.

This whole feature looks like it was done in a hurry as a sloppy copy-paste 
job, and in 5 years nobody took the time to report or fix it. Amazing. Oh well, 
let me be the one that fixes it then. You can find my fix in attachment: 
[^shadeTestJar.patch].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (MSHADE-284) Shaded test JARs using shadeTestJar are always empty

[Peter De Maeyer (JIRA)]

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

Peter De Maeyer updated MSHADE-284:
---
Summary: Shaded test JARs using shadeTestJar are always empty  (was: 
Shading test JARs using shadeTestJar does not work)

> Shaded test JARs using shadeTestJar are always empty
> 
>
> Key: MSHADE-284
> URL: https://issues.apache.org/jira/browse/MSHADE-284
> Project: Maven Shade Plugin
>  Issue Type: Bug
>Affects Versions: 3.1.0
>Reporter: Peter De Maeyer
>Priority: Major
> Attachments: shadeTestJar.patch
>
>
> Shading test JARs using the {{shadeTestJar}} configuration option yields an 
> empty test JAR. This has been noticed by others, see for example Steve K's 
> answer [on 
> StackOverflow|https://stackoverflow.com/questions/5149130/how-can-i-configure-the-maven-shade-plugin-to-include-test-code-in-my-jar/49617516#49617516],
>  but people have reverted to other hacks and workarounds to overcome this 
> (e.g. use a different plugin).
> Scenario:
>  # Create modules {{api}}, {{impl}} and a module {{uber}} which has as sole 
> purpose to make an uber JAR for the combination of the first two modules. 
> {{uber}} itself has no sources.
>  # Both modules have both {{jar}} and {{test-jar}} artifacts.
>  # Configure the {{maven-shade-plugin}} in the {{uber}} module with the 
> configuration option {{shadeTestJar}} set to {{true}}.
> Expected:
>  # Content of {{uber.jar}} is the aggregate content of {{api.jar}} and 
> {{impl.jar}}.
>  # Content of {{uber-tests.jar}} is the aggregate content of 
> {{api-tests.jar}} and {{impl-tests.jar}}.
> Actual:
>  # Content of {{uber.jar}} is as expected.
>  # {{uber-tests.jar}} is empty.
> Root cause:
>  * The implementation of the {{shadeTestJar}} feature in {{ShaderMojo}} is 
> buggy and incomplete.
>  * The call to {{processArtifactSelectors}} on line 425 doesn't pass the 
> {{testArtifacts}}, so they are never correctly filled in.
>  * The implementation of {{processArtifactSelectors}} doesn't deal with test 
> JARs at all and has to be extended to support them.
>  * The "if" statement on line 452 incorrectly treats a test JAR as sources.
> This whole feature looks like it was done in a hurry as a sloppy copy-paste 
> job, and in 5 years nobody took the time to report or fix it. Amazing. Oh 
> well, let me be the one that fixes it then. You can find my fix in 
> attachment: [^shadeTestJar.patch].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] Created: (MECLIPSE-625) ClassNotFoundException when running junit test ("Run As"|"Junit Test")

[Peter De Maeyer (JIRA)]

ClassNotFoundException when running junit test ("Run As"|"Junit Test")
--

 Key: MECLIPSE-625
 URL: http://jira.codehaus.org/browse/MECLIPSE-625
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
 Environment: Linux x86_64, Eclipse 3.5, M2Eclipse pluing 
0.9.9.200911171109
Reporter: Peter De Maeyer
Priority: Blocker


I have a project module A which depends on another project module B.
When I try to run a JUnit test ("Run As"|"Junit Test") in project A, I get a 
ClassNotFoundException for the all classes that are in project B.
At compile time it finds the dependencies in project module B, but not at 
runtime???

I've found another report of the same problem here:

http://blog.andrewbeacock.com/2008/11/classnotfoundexception-when-running.html

The stack trace looks like this:

---
java.lang.NoClassDefFoundError: org/de/maeyer/search/MatcherTest
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:632)
at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:277)
at java.net.URLClassLoader.access$000(URLClassLoader.java:73)
at java.net.URLClassLoader$1.run(URLClassLoader.java:212)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:319)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:264)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.loadClass(RemoteTestRunner.java:693)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.loadClasses(RemoteTestRunner.java:429)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:452)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at 
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.lang.ClassNotFoundException: org.de.maeyer.search.MatcherTest
at java.net.URLClassLoader$1.run(URLClassLoader.java:217)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:205)
at java.lang.ClassLoader.loadClass(ClassLoader.java:319)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:294)
at java.lang.ClassLoader.loadClass(ClassLoader.java:264)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:332)
... 17 more

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Issue Comment Edited: (MECLIPSE-624) M2Eclipse does not always pass configuration correctly to plugins

[Peter De Maeyer (JIRA)]

[ 
http://jira.codehaus.org/browse/MECLIPSE-624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=201332#action_201332
 ] 

Peter De Maeyer edited comment on MECLIPSE-624 at 12/4/09 6:13 PM:
---

MOJO-1468 is the symptom you'll get as a result of this issue.

Because the configuration is not correctly passed onto NativeJavaMojo, it 
reverts to the defaults, which is "try and find all native classes in 
classpath". M2Eclipse workspace resolution apparently passes an artifact of 
type "jar" onto the NativeJavaMojo. But because of workspace resolution, the 
artifact of type "jar" is in fact a real directory, but the mojo doesn't know 
this and tries to parse it as a jar (zip) file, which of course fails.

  was (Author: peterdm):
Although a bug in its own right, MOJO-1468 is the symptom you'll get as a 
result of this issue.

Because the configuration is not correctly passed onto NativeJavaMojo, it 
reverts to the defaults, which is "try and find all native classes in 
classpath". M2Eclipse workspace resolution apparently passes a an artifact of 
type "jar" onto the NativeJavaMojo. But because of workspace resolution, the 
artifact of type "jar" is in fact a real directory, but the mojo doesn't know 
this and tries to parse it as a jar (zip) file, which of course fails.
  
> M2Eclipse does not always pass configuration correctly to plugins
> -
>
> Key: MECLIPSE-624
> URL: http://jira.codehaus.org/browse/MECLIPSE-624
> Project: Maven 2.x Eclipse Plugin
>  Issue Type: Bug
>Reporter: Peter De Maeyer
>Priority: Blocker
> Attachments: project.tar.gz
>
>
> I am using M2Eclipse with the native-maven-plugin.
> However, the configuration of the native-maven-plugin is not correcly passed 
> onto the mojo: NativeJavahMojo is created with all fields to default, even 
> though some of them are configured!
> Eg. given the following configuration section of the pom.xml:
> ...
>   
> 
>   javah
>   generate-sources
>   
> my-custom-output-dir
> 
>   org.MyClassName
> 
> MyCustomOutputFileName.h
>   
>   
> javah
>   
> 
>   
> ...
> When I execute the native:javah Maven goal I expect these custom 
> configuration settings to be picked up, but they aren't. The debug output I 
> get is the following:
> ---
> [DEBUG] Configuring mojo 
> 'org.codehaus.mojo:native-maven-plugin:1.0-alpha-4-SNAPSHOT:javah' with basic 
> configurator -->
> [DEBUG]   (f) implementation = default
> [DEBUG]   (f) outputDirectory = 
> /home/peter/workspace/de-maeyer/search/native/linux/target/native/javah
> [DEBUG]   (f) project = MavenProject: 
> de.maeyer:search-native-linux:0.0.1-SNAPSHOT @ 
> /home/peter/workspace/de-maeyer/search/native/linux/pom.xml
> [DEBUG]   (f) verbose = false
> [DEBUG]   (f) workingDirectory = 
> /home/peter/workspace/de-maeyer/search/native/linux
> [DEBUG] -- end configuration --
> ---
> Another report can be found here:
> http://old.nabble.com/m2eclipse-does-not-configure-mojo-from-pom.xml-td22940611.html
> It describes a workaround involves unchecking "Skip Maven compiler plugin 
> when processing resources" and disabling workspace resolution, which is not 
> an option for me: workspace resolution is the main reason I use M2Eclipse 
> (and Maven) in the first place! I'm dead in the water as long as I can't 
> configure the native-maven-plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (MECLIPSE-624) M2Eclipse does not always pass configuration correctly to plugins

[Peter De Maeyer (JIRA)]

M2Eclipse does not always pass configuration correctly to plugins
-

 Key: MECLIPSE-624
 URL: http://jira.codehaus.org/browse/MECLIPSE-624
 Project: Maven 2.x Eclipse Plugin
  Issue Type: Bug
Reporter: Peter De Maeyer
Priority: Blocker
 Attachments: project.tar.gz

I am using M2Eclipse with the native-maven-plugin.
However, the configuration of the native-maven-plugin is not correcly passed 
onto the mojo: NativeJavahMojo is created with all fields to default, even 
though some of them are configured!

Eg. given the following configuration section of the pom.xml:
...
  

  javah
  generate-sources
  
my-custom-output-dir

  org.MyClassName

MyCustomOutputFileName.h
  
  
javah
  

  
...

When I execute the native:javah Maven goal I expect these custom configuration 
settings to be picked up, but they aren't. The debug output I get is the 
following:

---
[DEBUG] Configuring mojo 
'org.codehaus.mojo:native-maven-plugin:1.0-alpha-4-SNAPSHOT:javah' with basic 
configurator -->
[DEBUG]   (f) implementation = default
[DEBUG]   (f) outputDirectory = 
/home/peter/workspace/de-maeyer/search/native/linux/target/native/javah
[DEBUG]   (f) project = MavenProject: 
de.maeyer:search-native-linux:0.0.1-SNAPSHOT @ 
/home/peter/workspace/de-maeyer/search/native/linux/pom.xml
[DEBUG]   (f) verbose = false
[DEBUG]   (f) workingDirectory = 
/home/peter/workspace/de-maeyer/search/native/linux
[DEBUG] -- end configuration --
---

Another report can be found here:

http://old.nabble.com/m2eclipse-does-not-configure-mojo-from-pom.xml-td22940611.html

It describes a workaround involves unchecking "Skip Maven compiler plugin when 
processing resources" and disabling workspace resolution, which is not an 
option for me: workspace resolution is the main reason I use M2Eclipse (and 
Maven) in the first place! I'm dead in the water as long as I can't configure 
the native-maven-plugin.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira