[
https://issues.apache.org/jira/browse/MNG-8479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated MNG-8479:
----------------------------
Description:
h2. *Recreate steps*
With either a recent version of 3.9.x or 4.0.0-x, build my recreate plugin and
use the j2ee-simple archetype to create a test project then run the test goal
like this:
# git clone g...@github.com:scottkurz/counter-maven-plugin.git; cd
counter-maven-plugin; mvn install
# mvn -B archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
-DarchetypeArtifactId=maven-archetype-j2ee-simple -DarchetypeVersion=1.5
-DgroupId=mygroup -DartifactId=myartifact -Dversion=1.0-SNAPSHOT -Dpackage=myco
# cd myartifact; {{{}mvn
mygroup:counter-maven-plugin:1.0-SNAPSHOT:countTargets{}}}{{{{}}{}}}
You'll see an artifact resolution failure like this:
{{[ERROR] Failed to execute goal on project ear: Could not resolve dependencies
for project mygroup:ear:ear:1.0-SNAPSHOT}}
{{[ERROR] dependency: mygroup:ejbs:jar:1.0-SNAPSHOT (compile)}}
{{[ERROR] : The following artifacts could not be resolved:
mygroup:ejbs:jar:1.0-SNAPSHOT (absent)}}
h2. *More Details*
I was able to fix the issue by making this simple change to *ReactorReader.java*
[https://github.com/apache/maven/pull/2016]
Note my recreate/test plugin mojo looks like
{code:java}
@Mojo( name = "countTargets", defaultPhase = LifecyclePhase.PROCESS_SOURCES,
requiresDependencyResolution = ResolutionScope.TEST )
@Execute(phase = LifecyclePhase.PROCESS_TEST_CLASSES)
public class MyMojo{code}
If I understand correctly, the role of the `@Execute` here is not to directly
resolve the artifact (since this other stuff, IIUC, happens in a forked
Maven)... but rather to enable the test in
_*org.apache.maven.ReactorReader.find(MavenProject, Artifact)*_ to pass (the
test we use to decide whether to employ this special technique of resolving the
artifact to the project output dir):
{code:java}
if ( project.hasLifecyclePhase( "compile" ) && COMPILE_PHASE_TYPES.contains(
type ) ){code}
I'm not really sure where the list of "types" from *ReactorReader* comes from:
{code:java}
privatestaticfinal Collection<String> COMPILE_PHASE_TYPES = new HashSet<>(
Arrays.asList("jar", "ejb-client", "war", "rar", "ejb3", "par", "sar", "wsr",
"har", "app-client"));
{code}
It seems there's some overlap with packaging types but also that this is
possibly a slightly different layer of abstraction?
I wonder though if these types though should align with the types here:
[https://github.com/apache/maven/blob/master/impl/maven-impl/src/main/java/org/apache/maven/internal/impl/resolver/type/DefaultTypeProvider.java]
e.g.
{code:java}
new DefaultType("ejb", Language.JAVA_FAMILY, "jar", null, false,
JavaPathType.CLASSES),
new DefaultType("ejb-client", Language.JAVA_FAMILY, "jar",
"client", false, JavaPathType.CLASSES),{code}
That's just a guess grepping through code..haven't traced it through.
h2. *Workarounds*
I can avoid the problem either by:
# Adding a compile: `mvn compile
mygroup:counter-maven-plugin:1.0-SNAPSHOT:countTargets`
# Running a similar sample switching from an 'ejb' package type dependency to
a regular 'jar' package
h2. *References*
* It was working on this issue:
[https://github.com/openrewrite/rewrite-maven-plugin/issues/920] that led me to
investigate this.
* I didn't take the time to digest this but it seems like there might? be some
overlap: https://issues.apache.org/jira/browse/MNG-8097
* The issue in which ReactorReader was changed to the relevant code today:
https://issues.apache.org/jira/browse/MNG-5898
was:
h2. *Recreate steps*
With either a recent version of 3.9.x or 4.0.0-x, build my recreate plugin and
use the j2ee-simple archetype to create a test project then run the test goal
like this:
# git clone g...@github.com:scottkurz/counter-maven-plugin.git; cd
counter-maven-plugin; mvn install
# mvn -B archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
-DarchetypeArtifactId=maven-archetype-j2ee-simple -DarchetypeVersion=1.5
-DgroupId=mygroup -DartifactId=myartifact -Dversion=1.0-SNAPSHOT -Dpackage=myco
# cd myartifact; {{{}mvn
mygroup:counter-maven-plugin:1.0-SNAPSHOT:countTargets{}}}{{{{}}{}}}
You'll see an artifact resolution failure like this:
{{{{}}{}}}{{{}[ERROR] Failed to execute goal on project ear: Could not resolve
dependencies for project mygroup:ear:ear:1.0-SNAPSHOT{}}}
{{[ERROR] dependency: mygroup:ejbs:jar:1.0-SNAPSHOT (compile)}}
{{{}[ERROR] : The following artifacts could not be resolved:
mygroup:ejbs:jar:1.0-SNAPSHOT (absent)\{{{}{{}}}}}}
{{{{}}{}}}{{{{}}{}}}
h2. *More Details*
I was able to fix the issue by making this simple change to *ReactorReader.java*
[https://github.com/apache/maven/pull/2016]
Note my recreate/test plugin mojo looks like
{code:java}
@Mojo( name = "countTargets", defaultPhase = LifecyclePhase.PROCESS_SOURCES,
requiresDependencyResolution = ResolutionScope.TEST )
@Execute(phase = LifecyclePhase.PROCESS_TEST_CLASSES)
public class MyMojo{code}
If I understand correctly, the role of the `@Execute` here is not to directly
resolve the artifact (since this other stuff, IIUC, happens in a forked
Maven)... but rather to enable the test in
_*org.apache.maven.ReactorReader.find(MavenProject, Artifact)*_ to pass (the
test we use to decide whether to employ this special technique of resolving the
artifact to the project output dir):
{code:java}
if ( project.hasLifecyclePhase( "compile" ) && COMPILE_PHASE_TYPES.contains(
type ) ){code}
I'm not really sure where the list of "types" from *ReactorReader* comes from:
{code:java}
privatestaticfinal Collection<String> COMPILE_PHASE_TYPES = new HashSet<>(
Arrays.asList("jar", "ejb-client", "war", "rar", "ejb3", "par", "sar", "wsr",
"har", "app-client"));
{code}
It seems there's some overlap with packaging types but also that this is
possibly a slightly different layer of abstraction?
I wonder though if these types though should align with the types here:
[https://github.com/apache/maven/blob/master/impl/maven-impl/src/main/java/org/apache/maven/internal/impl/resolver/type/DefaultTypeProvider.java]
e.g.
{code:java}
new DefaultType("ejb", Language.JAVA_FAMILY, "jar", null, false,
JavaPathType.CLASSES),
new DefaultType("ejb-client", Language.JAVA_FAMILY, "jar",
"client", false, JavaPathType.CLASSES),{code}
That's just a guess grepping through code..haven't traced it through.
h2. *Workarounds*
I can avoid the problem either by:
# Adding a compile: `mvn compile
mygroup:counter-maven-plugin:1.0-SNAPSHOT:countTargets`
# Running a similar sample switching from an 'ejb' package type dependency to
a regular 'jar' package
h2. *References*
* It was working on this issue:
[https://github.com/openrewrite/rewrite-maven-plugin/issues/920] that led me to
investigate this.
* I didn't take the time to digest this but it seems like there might? be some
overlap: https://issues.apache.org/jira/browse/MNG-8097
* The issue in which ReactorReader was changed to the relevant code today:
https://issues.apache.org/jira/browse/MNG-5898
> Multi-module, intra-reactor artifact resolution doesn't work for 'ejb'
> packaged types like with 'jar' packaged types and requires compile
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: MNG-8479
> URL: https://issues.apache.org/jira/browse/MNG-8479
> Project: Maven
> Issue Type: Bug
> Components: Core, Reactor and Workspace
> Affects Versions: 3.9.6, 4.0.0-rc-2
> Reporter: Scott Kurz
> Priority: Minor
>
> h2. *Recreate steps*
> With either a recent version of 3.9.x or 4.0.0-x, build my recreate plugin
> and use the j2ee-simple archetype to create a test project then run the test
> goal like this:
> # git clone g...@github.com:scottkurz/counter-maven-plugin.git; cd
> counter-maven-plugin; mvn install
> # mvn -B archetype:generate -DarchetypeGroupId=org.apache.maven.archetypes
> -DarchetypeArtifactId=maven-archetype-j2ee-simple -DarchetypeVersion=1.5
> -DgroupId=mygroup -DartifactId=myartifact -Dversion=1.0-SNAPSHOT
> -Dpackage=myco
> # cd myartifact; {{{}mvn
> mygroup:counter-maven-plugin:1.0-SNAPSHOT:countTargets{}}}{{{{}}{}}}
> You'll see an artifact resolution failure like this:
>
> {{[ERROR] Failed to execute goal on project ear: Could not resolve
> dependencies for project mygroup:ear:ear:1.0-SNAPSHOT}}
> {{[ERROR] dependency: mygroup:ejbs:jar:1.0-SNAPSHOT (compile)}}
> {{[ERROR] : The following artifacts could not be resolved:
> mygroup:ejbs:jar:1.0-SNAPSHOT (absent)}}
> h2. *More Details*
>
> I was able to fix the issue by making this simple change to
> *ReactorReader.java*
> [https://github.com/apache/maven/pull/2016]
>
> Note my recreate/test plugin mojo looks like
>
> {code:java}
> @Mojo( name = "countTargets", defaultPhase = LifecyclePhase.PROCESS_SOURCES,
> requiresDependencyResolution = ResolutionScope.TEST )
> @Execute(phase = LifecyclePhase.PROCESS_TEST_CLASSES)
> public class MyMojo{code}
>
>
> If I understand correctly, the role of the `@Execute` here is not to directly
> resolve the artifact (since this other stuff, IIUC, happens in a forked
> Maven)... but rather to enable the test in
> _*org.apache.maven.ReactorReader.find(MavenProject, Artifact)*_ to pass (the
> test we use to decide whether to employ this special technique of resolving
> the artifact to the project output dir):
>
>
> {code:java}
> if ( project.hasLifecyclePhase( "compile" ) && COMPILE_PHASE_TYPES.contains(
> type ) ){code}
>
>
> I'm not really sure where the list of "types" from *ReactorReader* comes from:
>
>
> {code:java}
> privatestaticfinal Collection<String> COMPILE_PHASE_TYPES = new HashSet<>(
> Arrays.asList("jar", "ejb-client", "war", "rar", "ejb3", "par", "sar", "wsr",
> "har", "app-client"));
> {code}
>
> It seems there's some overlap with packaging types but also that this is
> possibly a slightly different layer of abstraction?
>
> I wonder though if these types though should align with the types here:
> [https://github.com/apache/maven/blob/master/impl/maven-impl/src/main/java/org/apache/maven/internal/impl/resolver/type/DefaultTypeProvider.java]
> e.g.
>
> {code:java}
> new DefaultType("ejb", Language.JAVA_FAMILY, "jar", null, false,
> JavaPathType.CLASSES),
> new DefaultType("ejb-client", Language.JAVA_FAMILY, "jar",
> "client", false, JavaPathType.CLASSES),{code}
> That's just a guess grepping through code..haven't traced it through.
>
> h2. *Workarounds*
>
> I can avoid the problem either by:
> # Adding a compile: `mvn compile
> mygroup:counter-maven-plugin:1.0-SNAPSHOT:countTargets`
> # Running a similar sample switching from an 'ejb' package type dependency
> to a regular 'jar' package
> h2. *References*
> * It was working on this issue:
> [https://github.com/openrewrite/rewrite-maven-plugin/issues/920] that led me
> to investigate this.
> * I didn't take the time to digest this but it seems like there might? be
> some overlap: https://issues.apache.org/jira/browse/MNG-8097
> * The issue in which ReactorReader was changed to the relevant code today:
> https://issues.apache.org/jira/browse/MNG-5898
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
