Scott Kurz created MNG-8479:
-------------------------------
Summary: 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: 4.0.0-rc-2, 3.9.6
Reporter: Scott Kurz
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. *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)
