I think the biggest problem actually ist hat Maven once was build with Java in mind, then developed to a cross-platform tool. Just because a ZIP is a ZIP does not tell us to put ALL zips on the classpath. Hence what we need is either a generic exclusion mechanism or a generic inclusion mechanism what goes on the classpath and what not. This is a Java-only problem, so the solution should be in the Java-specific plugins. I could imagine that a good solution would be to extend the compiler plugin with classpath-excludes accepting dependency coordinates.
-Markus -----Ursprüngliche Nachricht----- Von: Tamás Cservenák <ta...@cservenak.net> Gesendet: Freitag, 10. Juni 2022 12:01 An: Maven Users List <users@maven.apache.org> Betreff: Re: Keeping dependency out of all classpaths 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/ja > va/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-2d69a > d832720 > (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/ja > va/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 > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
