Re: How to Importing foreign packages?
Thanks I think that describes my issue! Am 02.05.22 um 20:19 schrieb Tamás Cservenák: Howdy, See this issue https://issues.apache.org/jira/browse/MNG-7160 Probably is related... HTH T On Mon, May 2, 2022, 19:40 Christoph Läubrich wrote: I'm currently facing an issue where I get classcast exceptions for XppDom, looking at the debug output I see Populating class realm coreExtension>org.eclipse.tycho:tycho-build:3.0.0-SNAPSHOT Included plexus-utils-3.4.1.jar ... and something further: Created new class realm maven.api Importing foreign packages Imported: org.codehaus.plexus.util.xml.Xpp3Dom < maven.ext so I think I need to "Importing foreign packages" this as well, but how is this supposed to be expressed? I checked: https://maven.apache.org/ref/3.8.4/maven-core/extension.html but it has only a mean to *export* a package to be exposed, while I want the other way round... - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: How to Importing foreign packages?
Howdy, See this issue https://issues.apache.org/jira/browse/MNG-7160 Probably is related... HTH T On Mon, May 2, 2022, 19:40 Christoph Läubrich wrote: > I'm currently facing an issue where I get classcast exceptions for > XppDom, looking at the debug output I see > > Populating class realm > coreExtension>org.eclipse.tycho:tycho-build:3.0.0-SNAPSHOT > > Included plexus-utils-3.4.1.jar > ... > > and something further: > > Created new class realm maven.api > Importing foreign packages > Imported: org.codehaus.plexus.util.xml.Xpp3Dom < maven.ext > > so I think I need to "Importing foreign packages" this as well, but how > is this supposed to be expressed? > > I checked: https://maven.apache.org/ref/3.8.4/maven-core/extension.html > but it has only a mean to *export* a package to be exposed, while I want > the other way round... > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
How to Importing foreign packages?
I'm currently facing an issue where I get classcast exceptions for XppDom, looking at the debug output I see Populating class realm coreExtension>org.eclipse.tycho:tycho-build:3.0.0-SNAPSHOT Included plexus-utils-3.4.1.jar ... and something further: Created new class realm maven.api Importing foreign packages Imported: org.codehaus.plexus.util.xml.Xpp3Dom < maven.ext so I think I need to "Importing foreign packages" this as well, but how is this supposed to be expressed? I checked: https://maven.apache.org/ref/3.8.4/maven-core/extension.html but it has only a mean to *export* a package to be exposed, while I want the other way round... - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: A Maven extension for dependency tracking
Howdy, just a few short answers: - 1st: Personally, from a Resolver perspective, I'd just provide an API (basically the author extending resolver should implement) and make it simple to "click in" (Sisu component discovery). - 2nd: resolver IMHO should not provide any out of the box component implementation at all So 1st would provide a "stable" extension point for users who would like to "integrate" with resolver at this point (like you did), but it could become possible using simply this new API, instead the hoops and loops your code was forced to do (as resolver is quite "closed" in this respect). As for 2nd point, while I do like your idea of "decorating" local repository, I'd try a bit different route: I'd integrate this https://github.com/lambdazen/bitsy that makes possible to use Apache Tinkerpop's Gremlin queries to ask about the built graph for example... And one big remark: the collector is the "hottest point" in resolver (heap and cpu wise), so ANY "new API" implementation should be aware, that each "lost" millisecond directly affects resolver collection speed, but I think for "research kind" of stuff, of just "recording the process result" should fit in just fine. I don't see this as a "standard" feature of Maven, but who knows? :) Just my 5 cents... HTH Tamas On Mon, May 2, 2022 at 4:09 PM Grzegorz Grzybek wrote: > Thank you Tamás for checking my experiment > > I'm just finishing my work before tomorrow's national holiday, but will > read your information more carefully soon. > > Whether it's DFS or BFS, as long as there's tracking from initial to > ultimate dependency, it's enough. DFS sounds more "natural" here though. I > didn't check the CollectResult class yet - is it created per dependency or > for the entire project? > > And yes - I didn't check multithreading, as in normal scenario (just `mvn > clean install`) I didn't observe concurrency issues accessing the stack. > Mind that I know a bit about maven "components", but there are definitely > few missing things in my understanding. > > Checking your output, I see there are two aspects of this potential > enhancement to the resolver: > - 1st - how to effectively collect the "reverse dependency tree" in > context of DFS/BFS/multithreading > - 2nd - how to write the information > > 2nd aspect could include: > - whether there should be ".tracking" for each GAV directory in local repo > (tracking for the purpose of entire local repository) > - maybe there should be configurable output location for single report of > a build? (tracking for the purpose of single project) > - which format to use (human consumable or machine readable?) > > For now I've used resolver 1.6.3 from Maven 3.8.5, but I'll look at `main` > branch too. > > kind regards > Grzegorz Grzybek > > > pon., 2 maj 2022 o 15:57 Tamás Cservenák napisał(a): > > > What I missed to mention: in my case the trees in the gist are about > > "resolving maven-core 3.5.8", but I guess you figured it out from the > > tree > > > > T > > > > On Mon, May 2, 2022 at 3:55 PM Tamás Cservenák > > wrote: > > > > > Howdy, > > > > > > I did some experiment, that (partially re-using your code to dump the > rev > > > tree) produces this output: > > > https://gist.github.com/cstamas/598a3266f943984442c00df30520294f > > > > > > (note: 1.8.0 resolver has two collector implementations: original > > > Depth-First and new Breadth-First called DF and BF respectively) > > > > > > The code is not pushed yet anywhere, but I plan to make an API for > this, > > > and as you can see, it works > > > for both implementations of collectors. Also, I hook ONLY into > collector, > > > as that's the place where the graph > > > is being built, but this is logically equivalent to your "More > > interesting > > > ... 2nd case". > > > > > > Will ping once again when I have the changes > > > > > > Thanks > > > Tamas > > > > > > On Thu, Apr 28, 2022 at 9:01 PM Tamás Cservenák > > > wrote: > > > > > >> Howdy, > > >> > > >> This is very cool, I was actually tinkering on very similar issues in > > >> resolver coming from totally different angles. > > >> > > >> And yes, the resolver collector is not quite "extension" friendly, but > > we > > >> will make it right. > > >> Just FYI, that in the latest resolver (1.8.0) there are actually two > > >> implementations: depth-first (original) and depth-first. > > >> > > >> By looking at your code: collection is most critical regarding > > >> performance and memory in the resolver, so "hooking" into it (like > > sending > > >> events per each step) might not be the best, but still, what kind of > > >> extension points would you envision in the collector? > > >> > > >> For example, to achieve what you want, it would be completely enough > to > > >> receive the final CollectResult (the full graph), no? > > >> As -- from a resolver perspective -- that would be simplest, > especially > > >> that now we have two collector implementations... > > >> > > >> Also, in case of
Re: A Maven extension for dependency tracking
Thank you Tamás for checking my experiment I'm just finishing my work before tomorrow's national holiday, but will read your information more carefully soon. Whether it's DFS or BFS, as long as there's tracking from initial to ultimate dependency, it's enough. DFS sounds more "natural" here though. I didn't check the CollectResult class yet - is it created per dependency or for the entire project? And yes - I didn't check multithreading, as in normal scenario (just `mvn clean install`) I didn't observe concurrency issues accessing the stack. Mind that I know a bit about maven "components", but there are definitely few missing things in my understanding. Checking your output, I see there are two aspects of this potential enhancement to the resolver: - 1st - how to effectively collect the "reverse dependency tree" in context of DFS/BFS/multithreading - 2nd - how to write the information 2nd aspect could include: - whether there should be ".tracking" for each GAV directory in local repo (tracking for the purpose of entire local repository) - maybe there should be configurable output location for single report of a build? (tracking for the purpose of single project) - which format to use (human consumable or machine readable?) For now I've used resolver 1.6.3 from Maven 3.8.5, but I'll look at `main` branch too. kind regards Grzegorz Grzybek pon., 2 maj 2022 o 15:57 Tamás Cservenák napisał(a): > What I missed to mention: in my case the trees in the gist are about > "resolving maven-core 3.5.8", but I guess you figured it out from the > tree > > T > > On Mon, May 2, 2022 at 3:55 PM Tamás Cservenák > wrote: > > > Howdy, > > > > I did some experiment, that (partially re-using your code to dump the rev > > tree) produces this output: > > https://gist.github.com/cstamas/598a3266f943984442c00df30520294f > > > > (note: 1.8.0 resolver has two collector implementations: original > > Depth-First and new Breadth-First called DF and BF respectively) > > > > The code is not pushed yet anywhere, but I plan to make an API for this, > > and as you can see, it works > > for both implementations of collectors. Also, I hook ONLY into collector, > > as that's the place where the graph > > is being built, but this is logically equivalent to your "More > interesting > > ... 2nd case". > > > > Will ping once again when I have the changes > > > > Thanks > > Tamas > > > > On Thu, Apr 28, 2022 at 9:01 PM Tamás Cservenák > > wrote: > > > >> Howdy, > >> > >> This is very cool, I was actually tinkering on very similar issues in > >> resolver coming from totally different angles. > >> > >> And yes, the resolver collector is not quite "extension" friendly, but > we > >> will make it right. > >> Just FYI, that in the latest resolver (1.8.0) there are actually two > >> implementations: depth-first (original) and depth-first. > >> > >> By looking at your code: collection is most critical regarding > >> performance and memory in the resolver, so "hooking" into it (like > sending > >> events per each step) might not be the best, but still, what kind of > >> extension points would you envision in the collector? > >> > >> For example, to achieve what you want, it would be completely enough to > >> receive the final CollectResult (the full graph), no? > >> As -- from a resolver perspective -- that would be simplest, especially > >> that now we have two collector implementations... > >> > >> Also, in case of multi threading, your shared stack would not cut, would > >> it? > >> > >> I personally was also looking into these, especially after some of the > >> latest additions to resolver in 1.8.0 and current master > >> > >> > >> Thanks > >> T > >> > >> > >> On Thu, Apr 28, 2022 at 12:45 PM Grzegorz Grzybek > > >> wrote: > >> > >>> Hello > >>> > >>> TL;DR: https://github.com/grgrzybek/tracking-maven-extension > >>> > >>> I'd like to share some proof of concept I made. It all started with a > >>> question "why I'm getting log4j:log4j:1.2.12" in my local Maven > >>> repository > >>> when building trivial project with fresh local repo? > >>> > >>> I knew it's possible to `grep -r --include=*.pom 1.2.12` the poms that > >>> declare old log4j, but I needed something better. > >>> > >>> In short words - I managed to persist the information available in > >>> > >>> > org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.Args#nodes > >>> stack. > >>> I wrote a Maven extension that can be put into $MAVEN_HOME/lib/ext or > >>> used > >>> with "-Dmaven.ext.class.path" which does two things: > >>> > >>>1. adds org.eclipse.aether.RepositoryListener component that writes > >>> some > >>>information when a dependency is FIRST downloaded from remote > >>> repository > >>>2. adds org.eclipse.aether.impl.DependencyCollector component > >>> (extension > >>>of > >>> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector) > >>>that writes some information when a dependency is resolved against >
Re: A Maven extension for dependency tracking
What I missed to mention: in my case the trees in the gist are about "resolving maven-core 3.5.8", but I guess you figured it out from the tree T On Mon, May 2, 2022 at 3:55 PM Tamás Cservenák wrote: > Howdy, > > I did some experiment, that (partially re-using your code to dump the rev > tree) produces this output: > https://gist.github.com/cstamas/598a3266f943984442c00df30520294f > > (note: 1.8.0 resolver has two collector implementations: original > Depth-First and new Breadth-First called DF and BF respectively) > > The code is not pushed yet anywhere, but I plan to make an API for this, > and as you can see, it works > for both implementations of collectors. Also, I hook ONLY into collector, > as that's the place where the graph > is being built, but this is logically equivalent to your "More interesting > ... 2nd case". > > Will ping once again when I have the changes > > Thanks > Tamas > > On Thu, Apr 28, 2022 at 9:01 PM Tamás Cservenák > wrote: > >> Howdy, >> >> This is very cool, I was actually tinkering on very similar issues in >> resolver coming from totally different angles. >> >> And yes, the resolver collector is not quite "extension" friendly, but we >> will make it right. >> Just FYI, that in the latest resolver (1.8.0) there are actually two >> implementations: depth-first (original) and depth-first. >> >> By looking at your code: collection is most critical regarding >> performance and memory in the resolver, so "hooking" into it (like sending >> events per each step) might not be the best, but still, what kind of >> extension points would you envision in the collector? >> >> For example, to achieve what you want, it would be completely enough to >> receive the final CollectResult (the full graph), no? >> As -- from a resolver perspective -- that would be simplest, especially >> that now we have two collector implementations... >> >> Also, in case of multi threading, your shared stack would not cut, would >> it? >> >> I personally was also looking into these, especially after some of the >> latest additions to resolver in 1.8.0 and current master >> >> >> Thanks >> T >> >> >> On Thu, Apr 28, 2022 at 12:45 PM Grzegorz Grzybek >> wrote: >> >>> Hello >>> >>> TL;DR: https://github.com/grgrzybek/tracking-maven-extension >>> >>> I'd like to share some proof of concept I made. It all started with a >>> question "why I'm getting log4j:log4j:1.2.12" in my local Maven >>> repository >>> when building trivial project with fresh local repo? >>> >>> I knew it's possible to `grep -r --include=*.pom 1.2.12` the poms that >>> declare old log4j, but I needed something better. >>> >>> In short words - I managed to persist the information available in >>> >>> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.Args#nodes >>> stack. >>> I wrote a Maven extension that can be put into $MAVEN_HOME/lib/ext or >>> used >>> with "-Dmaven.ext.class.path" which does two things: >>> >>>1. adds org.eclipse.aether.RepositoryListener component that writes >>> some >>>information when a dependency is FIRST downloaded from remote >>> repository >>>2. adds org.eclipse.aether.impl.DependencyCollector component >>> (extension >>>of >>> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector) >>>that writes some information when a dependency is resolved against >>> local >>>repository when it's already there (where no download is needed) >>> >>> In the first case, I write something like this: >>> >>> ~~~ >>> Downloaded artifact log4j:log4j:pom::1.2.12 (repository: central ( >>> https://repo.maven.apache.org/maven2, default, releases)) >>>-> commons-logging:commons-logging:jar:1.1 (compile) (context: plugin) >>> -> commons-digester:commons-digester:jar:1.8 (compile) (context: >>> plugin) >>>-> org.apache.velocity:velocity-tools:jar:2.0 (compile) (context: >>> plugin) >>> -> org.apache.maven.doxia:doxia-site-renderer:jar:1.11.1 >>> (compile) >>> (context: plugin) >>>-> org.apache.maven.plugins:maven-site-plugin:jar:3.11.0 () >>> (context: plugin) >>> Reading descriptor for artifact log4j:log4j:jar::1.2.12 (context: >>> plugin) >>> (scope: ?) (repository: central (https://repo.maven.apache.org/maven2, >>> default, releases)) >>> Transitive dependencies collection for >>> org.apache.maven.plugins:maven-site-plugin:jar:3.11.0 () >>> Resolution of plugin >>> org.apache.maven.plugins:maven-site-plugin:3.11.0 (org.apache:apache:25) >>> ~~~ >>> Downloaded artifact log4j:log4j:jar::1.2.12 (repository: central ( >>> https://repo.maven.apache.org/maven2, default, releases)) >>> Resolution of plugin com.mycila:license-maven-plugin:3.0 >>> (org.apache.camel:camel-buildtools:3.17.0-SNAPSHOT) >>> >>> I simply write some information from available >>> org.eclipse.aether.RepositoryEvent and event's >>> org.eclipse.aether.RequestTrace. >>> >>> More interesting information is written in 2nd case. Because I wanted to >>>
Re: A Maven extension for dependency tracking
Howdy, I did some experiment, that (partially re-using your code to dump the rev tree) produces this output: https://gist.github.com/cstamas/598a3266f943984442c00df30520294f (note: 1.8.0 resolver has two collector implementations: original Depth-First and new Breadth-First called DF and BF respectively) The code is not pushed yet anywhere, but I plan to make an API for this, and as you can see, it works for both implementations of collectors. Also, I hook ONLY into collector, as that's the place where the graph is being built, but this is logically equivalent to your "More interesting ... 2nd case". Will ping once again when I have the changes Thanks Tamas On Thu, Apr 28, 2022 at 9:01 PM Tamás Cservenák wrote: > Howdy, > > This is very cool, I was actually tinkering on very similar issues in > resolver coming from totally different angles. > > And yes, the resolver collector is not quite "extension" friendly, but we > will make it right. > Just FYI, that in the latest resolver (1.8.0) there are actually two > implementations: depth-first (original) and depth-first. > > By looking at your code: collection is most critical regarding performance > and memory in the resolver, so "hooking" into it (like sending events per > each step) might not be the best, but still, what kind of extension points > would you envision in the collector? > > For example, to achieve what you want, it would be completely enough to > receive the final CollectResult (the full graph), no? > As -- from a resolver perspective -- that would be simplest, especially > that now we have two collector implementations... > > Also, in case of multi threading, your shared stack would not cut, would > it? > > I personally was also looking into these, especially after some of the > latest additions to resolver in 1.8.0 and current master > > > Thanks > T > > > On Thu, Apr 28, 2022 at 12:45 PM Grzegorz Grzybek > wrote: > >> Hello >> >> TL;DR: https://github.com/grgrzybek/tracking-maven-extension >> >> I'd like to share some proof of concept I made. It all started with a >> question "why I'm getting log4j:log4j:1.2.12" in my local Maven repository >> when building trivial project with fresh local repo? >> >> I knew it's possible to `grep -r --include=*.pom 1.2.12` the poms that >> declare old log4j, but I needed something better. >> >> In short words - I managed to persist the information available in >> >> org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector.Args#nodes >> stack. >> I wrote a Maven extension that can be put into $MAVEN_HOME/lib/ext or used >> with "-Dmaven.ext.class.path" which does two things: >> >>1. adds org.eclipse.aether.RepositoryListener component that writes >> some >>information when a dependency is FIRST downloaded from remote >> repository >>2. adds org.eclipse.aether.impl.DependencyCollector component >> (extension >>of org.eclipse.aether.internal.impl.collect.DefaultDependencyCollector) >>that writes some information when a dependency is resolved against >> local >>repository when it's already there (where no download is needed) >> >> In the first case, I write something like this: >> >> ~~~ >> Downloaded artifact log4j:log4j:pom::1.2.12 (repository: central ( >> https://repo.maven.apache.org/maven2, default, releases)) >>-> commons-logging:commons-logging:jar:1.1 (compile) (context: plugin) >> -> commons-digester:commons-digester:jar:1.8 (compile) (context: >> plugin) >>-> org.apache.velocity:velocity-tools:jar:2.0 (compile) (context: >> plugin) >> -> org.apache.maven.doxia:doxia-site-renderer:jar:1.11.1 >> (compile) >> (context: plugin) >>-> org.apache.maven.plugins:maven-site-plugin:jar:3.11.0 () >> (context: plugin) >> Reading descriptor for artifact log4j:log4j:jar::1.2.12 (context: >> plugin) >> (scope: ?) (repository: central (https://repo.maven.apache.org/maven2, >> default, releases)) >> Transitive dependencies collection for >> org.apache.maven.plugins:maven-site-plugin:jar:3.11.0 () >> Resolution of plugin >> org.apache.maven.plugins:maven-site-plugin:3.11.0 (org.apache:apache:25) >> ~~~ >> Downloaded artifact log4j:log4j:jar::1.2.12 (repository: central ( >> https://repo.maven.apache.org/maven2, default, releases)) >> Resolution of plugin com.mycila:license-maven-plugin:3.0 >> (org.apache.camel:camel-buildtools:3.17.0-SNAPSHOT) >> >> I simply write some information from available >> org.eclipse.aether.RepositoryEvent and event's >> org.eclipse.aether.RequestTrace. >> >> More interesting information is written in 2nd case. Because I wanted to >> track ALL attempts to resolve log4j:log4j:1.2.12 (and any other >> dependency), I needed some structure. And I decided this: >> >>- every dependency directory (where e.g., _remote.repositories is >>written along with the jar/pom/sha1/md5/...) gets ".tracking" directory >>- in ".tracking" directory I write files with names of this pattern: >>
[VOTE] Release Maven Indexer 6.2.0
Howdy, We solved 8 issues: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317523=12351653 There are still some issues left in JIRA: https://issues.apache.org/jira/projects/MINDEXER/ Staging repository: https://repository.apache.org/content/repositories/maven-1749 Source SHA512 checksum: 84726bfca68475b4182d2191561edf9f593c22b750c03f5fb934f6f60ad6f5e0804eb94828f67fa2175564fa5edb2ab02cf1ff896e92a9ea1b2614e01c184f06 Staged site: https://maven.apache.org/maven-indexer-archives/maven-indexer-LATEST/ Guide to testing staged releases: https://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1
Re: MDEP-804 - Allow auto-ignore of all non-test scoped dependencies used only in test scope
T thanks. I’ll need to dig into this. It will be at least a couple of weeks before I can get to this. One quick thought. Is it possible something needs to be added to runtime scope? That’s hard to detect but it might explain what you see. On Sun, May 1, 2022 at 10:20 PM Henning Schmiedehausen < henn...@schmiedehausen.org> wrote: > Hi Elliotte, > > Thank you for the comments. I have read your comments on MDEP-791. I very > much believe in "show, not tell", so here is a (condensed down) real-world > example of the problems that I (and others) are facing: > > Please clone https://github.com/hgschmie/dep804 > > This project contains two service builds. The basic structure are four > modules: > > service --> dependency --> lib1 --> lib2 > > There is also a build that shades the libraries into the dependency module > (dependency-shaded) and then uses that shaded dependency to build a shaded > service: > > service-shaded -> dependency-shaded (which contains dependency, lib1 and > lib2) > > To establish a baseline with 3.1.2, run "mvn -Pold-dep clean install" (Use > Java 11 for this). > > The code should build successfully, all unit tests pass. No errors are > thrown. > > Test the services: > > java -jar service-shaded/target/service-shaded-0.1-SNAPSHOT-shaded.jar > Main code start! > DependencyCode is at test.DependencyCode@2eee9593 > DependencyCode code start! > lib1 is at test.lib1.Lib1@7907ec20 > lib 1 start! > lib 2 is at test.lib2.Lib2@546a03af > lib 2 start! > > java -jar service/target/service-0.1-SNAPSHOT-shaded.jar > Main code start! > DependencyCode is at test.DependencyCode@2eee9593 > DependencyCode code start! > lib1 is at test.lib1.Lib1@7907ec20 > lib 1 start! > lib 2 is at test.lib2.Lib2@546a03af > lib 2 start! > > Both services start. All is good. Now, rebuild with the new (3.3.0) plugin: > > mvn -fae clean install > [...] > [INFO] --- maven-dependency-plugin:3.3.0:analyze-only (basepom.default) @ > service --- > [WARNING] Non-test scoped test only dependencies found: > [WARNING]test:lib1:jar:0.1-SNAPSHOT:compil > [...] > INFO] --- maven-dependency-plugin:3.3.0:analyze-only (basepom.default) @ > dependency-shaded --- > [WARNING] Non-test scoped test only dependencies found: > [WARNING]test:lib2:jar:0.1-SNAPSHOT:compile > [...] > INFO] service FAILURE [ 0.798 > s] > [INFO] dependency-shaded .. FAILURE [ > 0.662 s] > > ... not good. Two of the modules fail with the dreaded "Non-test scoped > test only dependencies found:" > > Let's fix that. Put "lib1" into test scope in the "service" module and > "lib2" in test scope in the "dependency-shaded" module to fix that problem. > > mvn -fae clean install > [...] > [INFO] T E S T S > [INFO] --- > [INFO] Running test.ServiceTest > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: > 0.076 s <<< FAILURE! - in test.ServiceTest > [ERROR] test.ServiceTest.testLib1 Time elapsed: 0.008 s <<< ERROR! > java.lang.NoClassDefFoundError: test/lib2/Lib2 > at test.lib1.Lib1.(Lib1.java:7) > at test.ServiceTest.(ServiceTest.java:10) > [...] > ... 29 more > > [INFO] > [INFO] Results: > [INFO] > [ERROR] Errors: > [ERROR] ServiceTest.:10 » NoClassDefFound test/lib2/Lib2 > [INFO] > [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0 > [...] > [INFO] service-shaded . FAILURE [ > 0.541 s] > > The unit test in service-shaded fails. We haven't even touched the > service-shaded module! How could that happen? > > Let's ignore that for now. Just skip the tests: > > mvn -fae -DskipTests clean install > ... build successfully... > > java -jar service/target/service-0.1-SNAPSHOT-shaded.jar > Exception in thread "main" java.lang.NoClassDefFoundError: test/lib1/Lib1 > at test.DependencyCode.(DependencyCode.java:6) > at test.Main.(Main.java:4) > at test.Main.main(Main.java:8) > Caused by: java.lang.ClassNotFoundException: test.lib1.Lib1 > at > > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) > at > > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) > ... 3 more > > java -jar service-shaded/target/service-shaded-0.1-SNAPSHOT-shaded.jar > Exception in thread "main" java.lang.NoClassDefFoundError: test/lib2/Lib2 > at test.lib1.Lib1.(Lib1.java:7) > at test.DependencyCode.(DependencyCode.java:6) > at test.Main.(Main.java:4) > at test.Main.main(Main.java:8) > Caused by: java.lang.ClassNotFoundException: test.lib2.Lib2 > at > > java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581) > at > > java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178) > at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522) > ... 4 more > > None of the services work anymore! There are
Re: [VOTE] Release Apache Maven Daemon 0.8.0
Thx, I'll fix the missing "build directory" and I'll have a look at other issues if I can fix them easily. Le lun. 2 mai 2022 à 00:47, Hervé BOUTEMY a écrit : > finally, I tried to build from Git: > - I was able to rebuild libmvndnative.*, which is one of the tricks for > this > release > - I was also able to build locally the GraalVM native images (discovered > the > "gu install native-image" command) > > PR created to fix the issue for building from the source release archive: > https://github.com/apache/maven-mvnd/pull/629 > > I created a few other issues and PRs: it would be useful to review the PRs > before next release candidate, issues should not be a blocker if we can't > fix > for now > > Regards, > > Hervé > > Le samedi 30 avril 2022, 16:32:50 CEST Hervé BOUTEMY a écrit : > > sorry, I'll have to give a binding -1 > > > > the source archive can't be built: > > [ERROR] Failed to execute goal > > net.revelc.code.formatter:formatter-maven-plugin:2.15.0:format (format) > on > > project mvnd-build-maven-plugin: Cannot find config file > > [/tmp/mvnd-0.8.0/build/eclipse-formatter-config.xml] -> [Help 1] > > > > the build directory is in Git but not in the source archive... > > > > Regards, > > > > Hervé > > > > Le vendredi 29 avril 2022, 19:30:39 CEST Guillaume Nodet a écrit : > > > I've staged a candidate release at > > > > > > https://dist.apache.org/repos/dist/dev/maven/mvnd/0.8.0/ > > > > > > The changelog is available at > > > > > > > https://github.com/apache/maven-mvnd/blob/master/CHANGELOG.md#080-2022-04-> > > 29 > > > > > > This is the first attempt at releasing Mvnd since its move into the > Maven > > > project, so a thorough look would be welcomed ! > > > > > > Fwiw, the release process is explained at > > > https://github.com/apache/maven-mvnd/blob/master/RELEASING.adoc (this > is > > > not complete, i'll focus on the next phases once the vote passes). > > > > > > Guillaume > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Guillaume Nodet
