[MNG-8479] Multi-module, intra-reactor artifact resolution doesn't work for 'ejb' packaged types like with 'jar' packaged types and requires compile

[jira-importer]

Scott Kurz opened MNG-8479 and commented

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:

1. git clone git@github.com:scottkurz/counter-maven-plugin.git; cd counter-maven-plugin; mvn install
2. 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
3. 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)

More Details

 

I was able to fix the issue by making this simple change to ReactorReader.java

#2016

 

Note my recreate/test plugin mojo looks like

 

@Mojo( name = "countTargets", defaultPhase = LifecyclePhase.PROCESS_SOURCES, requiresDependencyResolution = ResolutionScope.TEST )
@Execute(phase = LifecyclePhase.PROCESS_TEST_CLASSES)
public class MyMojo

 

 

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): 

 

 

 if ( project.hasLifecyclePhase( "compile" ) && COMPILE_PHASE_TYPES.contains( type ) )

 

 

I'm not really sure where the list of "types" from ReactorReader comes from:

 
 

privatestaticfinal Collection<String> COMPILE_PHASE_TYPES = new HashSet<>(
Arrays.asList("jar", "ejb-client", "war", "rar", "ejb3", "par", "sar", "wsr", "har", "app-client"));

 

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.

           

     new DefaultType("ejb", Language.JAVA_FAMILY, "jar", null, false, JavaPathType.CLASSES),
                new DefaultType("ejb-client", Language.JAVA_FAMILY, "jar", "client", false, JavaPathType.CLASSES),

That's just a guess grepping through code..haven't traced it through.

 

Workarounds

 

I can avoid the problem either by:

1. Adding a compile:   mvn compile  mygroup:counter-maven-plugin:1.0-SNAPSHOT:countTargets
2. Running a similar sample switching from an 'ejb' package type dependency to a regular 'jar' package

References 

• It was working on this issue: Within a multi-module build, the 'run' goal doesn't resolve a dependency to an 'ejb' packaging-type artifact (unless it's been installed locally) openrewrite/rewrite-maven-plugin#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

---

Affects: 3.9.6, 4.0.0-rc-2

Remote Links:

• GitHub Pull Request #2016
  

Backported to: 4.0.0-rc-3

[jira-importer]

Guillaume Nodet commented

Ideally, we'd get rid of that code, as this limited heuristic does not smell very good to me.
This all comes from MNG-2222.
I've tried to fix some of those problems by introducing the project local repository.
The new lifecycle should help too when using build instead of compile.