Open xamde opened 2 years ago
Adding some more logging gives us a little bit more insight:
[INFO] Recurse into org.reflections:reflections:0.9.12 =http://github.com/ronmamo/reflections
[INFO] Recurse into org.javassist:javassist:3.26.0-GA =http://www.javassist.org/
[INFO] Recurse into org.slf4j:slf4j-api:1.7.30 =http://www.slf4j.org
[INFO] Recurse into org.dom4j:dom4j:2.1.1 =http://dom4j.github.io/
[WARNING] The artifact xml-apis:xml-apis:jar:2.0.2 has been relocated to xml-apis:xml-apis:jar:1.0.b2
[INFO] Recurse into jaxen:jaxen:1.1.6 =http://jaxen.codehaus.org/
[WARNING] The POM for stax:stax-ri:jar:1.0 is missing, no dependency information available
[INFO] Recurse into dom4j:dom4j:1.6.1 =http://dom4j.org
[INFO] Recurse into jaxme:jaxme-api:0.3 =null
[INFO] Recurse into jaxen:jaxen:1.1-beta-6 =http://jaxen.codehaus.org/
[INFO] Recurse into dom4j:dom4j:1.5.2 =http://dom4j.org
[INFO] Recurse into jaxen:jaxen:1.1-beta-4 =http://jaxen.codehaus.org/
[INFO] Recurse into dom4j:dom4j:1.5.2 =http://dom4j.org
[INFO] Recurse into jaxen:jaxen:1.1-beta-4 =http://jaxen.codehaus.org/
[INFO] Recurse into dom4j:dom4j:1.5.2 =http://dom4j.org
[INFO] Recurse into jaxen:jaxen:1.1-beta-4 =http://jaxen.codehaus.org/
[INFO] Recurse into dom4j:dom4j:1.5.2 =http://dom4j.org
[INFO] Recurse into jaxen:jaxen:1.1-beta-4 =http://jaxen.codehaus.org/
[INFO] Recurse into dom4j:dom4j:1.5.2 =http://dom4j.org
[INFO] Recurse into jaxen:jaxen:1.1-beta-4 =http://jaxen.codehaus.org/
[INFO] Recurse into dom4j:dom4j:1.5.2 =http://dom4j.org
(These two repeating over and over)
Indeed in the POMs of this stone age old jaxen and dom4j they depend on each other
https://repo1.maven.org/maven2/jaxen/jaxen/1.1-beta-4/jaxen-1.1-beta-4.pom https://repo1.maven.org/maven2/dom4j/dom4j/1.5.2/dom4j-1.5.2.pom
Well that's terrible, thanks for digging in. In other places where this kind of thing has occurred, we've tried to remove the dependency entirely.
Without diminishing the impact of broken poms already published somewhere, can you comment on where in your dependency tree you get to dom4j/jaxen to begin with, and how that dependency makes sense (they don't appear in your tree at all)?
We can probably guard against this by testing a bit earlier in the AbstractBuildMojo.buildProject loop if the dependency has been seen before, even if not been completed, but I don't know what the "correct" answer is - do we "succeed" and somehow build this terrible classpath? How should the build tool react in general if there are two projects that mutually depend on each other and one changes, do we rebuild that one, then rebuild the dependent, and then the original again to make sure it is steady-state? I'm not enjoying the idea of building that into the plugin...
I would much prefer to just fail as "sorry, this is absurd, and I won't do it" than account for clearly broken project structure. As a workaround for projects that need these dependencies, I assume these either don't actually belong in your client code, or that these are deliberate dependencies for an annotation processor? If it is for an annotation processor, I would suggest shading either (as an external project) the processor itself or making a shaded jar to correct this mess and contain these broken dependencies. Note that shading a processor can have other important benefits, such as preventing two different processors from having conflicting dependencies that a downstream developer isn't going to want to deal with.
I got it via an older version of org.reflections. The current version has the same issue. However, the dom4j is marked as "optional" and excluding it works fine for me.
Now that I found out the poms are really the cause, even just dying is fine for me. Certainly not support that! Maybe keep a set of built projects when recursing and print an error when descending into a known project. At most.
We do actually keep a set of built projects as you suggest, and use that to avoid creating duplicates - the problem is that while actively building a single project, we don't consider it built, as we're still building its dependencies. Only once we have the dependencies etc can we call a project built, and then we register it.
I'll mark this for follow up after this release process is complete, thanks for your insights.
Upon further investigation: The j2cl maven plugin seems to ignore the Maven POM exclusions. Still get an infinite loop. mvn dependency:tree
no longer shows the dom4j & jaxen dependencies.
Yes, that's by design - each dependency in the graph should be built as it was written, so that it can be shared in multiple places of the build, even if they have slightly different results of dependencyManagement+excludes. Shading is probably your best bet, either just a single dependency to paper over that subsection of the ... well, the not-tree, or shading the entire processor.
Thanks for explaining in more detail @niloc132 , I'll summarize here for other readers:
IF your projects depends weirdly enough on a dependency A which in turn depends on B and C, but B and C depend on each other (or more complex variations of this theme), THEN you can use the maven shade plugin to create one single uber-jar in which A, B and C are included. THEN use that uber jar in your build and j2cl maven plugin wont even try to download/compile multiple things.
I call
mvn clean j2cl:build
and get this StackOverflowError.The last line loops forever until the JVM dies.
The dependencies are medium complex:
After stripping,
org.reflections
should no longer be called.Console output