Nope, it does not work (order of things is not so simple, addedToClasspath remains always true), hold on a few...
On Fri, Jun 10, 2022 at 12:12 PM Tamás Cservenák <ta...@cservenak.net> wrote: > If you can use Maven4, try out this one: > https://github.com/apache/maven/pull/752 > > T > > On Fri, Jun 10, 2022 at 12:00 PM Tamás Cservenák <ta...@cservenak.net> > wrote: > >> I see. >> >> Well, as long as oracle Java doco says this: >> >> Class paths to the JAR, zip or class files. Each class path should end >> with a file name or directory depending on what you are setting the class >> path to, as follows: >> * For a JAR or zip file that contains class files, the class path ends >> with the name of the zip or JAR file. >> .... >> >> Maven should comply, no? Or could maven do something about "zip file that >> contains class files"? >> >> T >> >> On Fri, Jun 10, 2022 at 11:28 AM [Quipsy] Markus Karg <k...@quipsy.de> >> wrote: >> >>> Thanks for the quick tip. >>> >>> While it might solve the actual problem I did have this morning, it is >>> neither a clean nor a general solution for everybody and for always, as it >>> still implies that all ZIPs shall go in the Java classpath unless >>> custom-packaged. Which means, possibly repackage rather EACH ZIP, as least >>> ZIPs shall go on the classpath in reality (in 20+ years fulltime with Java >>> I never wanted to add any ZIP to the Java classpath). >>> >>> In fact, the actual intention of this discussion is not how to make my >>> personal POM build right now (it in fact already does as I do not have any >>> tests, so I could go with runtime scope), but what I want to reach is that >>> we find a consensus how a clean and generic solution should look like -- >>> and propose that solution to the Maven team. 😊 >>> >>> Thanks! >>> -Markus >>> >>> >>> -----Ursprüngliche Nachricht----- >>> Von: Tamás Cservenák <ta...@cservenak.net> >>> Gesendet: Freitag, 10. Juni 2022 11:13 >>> An: Maven Users List <users@maven.apache.org> >>> Betreff: Re: Keeping dependency out of all classpaths >>> >>> Howdy, >>> >>> just a quick idea: introduce your own packaging "quipsy-zip"? (yes, >>> you'd need your extension to be added to build, but it's worth it, trust >>> me). >>> >>> Look here: >>> >>> https://github.com/apache/maven/blob/master/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L58 >>> >>> So, your packaging defines (name="quipsy-zip", extension="zip", >>> addedToClasspath=false... it should work, and you'd depend on this zip as >>> >>> <dependency> >>> <groupId>org.group</groupId> >>> <artifactId>artifact</artifactId> >>> <version>1.0</version> >>> <type>quipsy-zip</type> >>> </dependency> >>> >>> See >>> >>> https://medium.com/javarevisited/create-your-own-maven-packaging-2d69ad832720 >>> (note: if you are NOT building this ZIP with maven, then you do not need >>> lifecycle mapping, only the ArtifactHandler ) >>> >>> >>> https://github.com/apache/maven/blob/master/maven-artifact/src/main/java/org/apache/maven/artifact/handler/ArtifactHandler.java#L31 >>> >>> >>> HTH >>> T >>> >>> >>> On Fri, Jun 10, 2022 at 10:54 AM [Quipsy] Markus Karg <k...@quipsy.de> >>> wrote: >>> >>> > How can I keep a dependency out of all classpaths? >>> > >>> > I do have a dependency in my project that produces a ZIP full of >>> > resources. None of those resources is actually of any use for the Java >>> > compiler; they solely serve as an input to third party plugins (not >>> > dealing with Java at all). Unfortunately the Maven Compiler plugin >>> > sees that ZIP and tries to read it, leading to error messages as the >>> > ZIP is in an "unexpected" format (for now let's just say, it is >>> > intentionally incompatible). So the question is, how to tell Maven to >>> > not put that dependency on ANY Java classpath? >>> > >>> > >>> > 1. "runtime" Scope: compile is happy now, but test-compile still >>> fails >>> > 2. Moving the dependency from being a project dependency to being a >>> > plugin-specific dependency: compile and test-compile are happy now, >>> > but -am doesn't build the dependency anymore and dependency:tree (and >>> > other >>> > scanners) does not tell me about the existence oft hat dependency at >>> all >>> > 3. "resource" Scope: would be exactly what I like to do, but Maven >>> > does not have such a scope: compile and test-compile would be happy, >>> > and -am still would build the dependency just like other scanners it >>> > would still see the dependency >>> > >>> > In the end, the bigger question actually is, how to tell ANY plugin to >>> > ignore particular dependencies of my POM? Just because my project is >>> > of type WAR does not mean that EVERYTING it depends upon shall be >>> > processed by the Java toolchain... Maybe it would be better if the >>> > Maven Compiler Plugin JUST puts those dependencies on the classpath >>> that actually are JARs...? >>> > >>> > Thanks a lot! >>> > -Markus >>> > >>> > >>> >>
