You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "[Quipsy] Markus Karg" <ka...@quipsy.de> on 2022/06/10 08:54:43 UTC
Keeping dependency out of all classpaths
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
AW: Keeping dependency out of all classpaths
Posted by "[Quipsy] Markus Karg" <ka...@quipsy.de>.
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 <us...@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 <ka...@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 <us...@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 <ka...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Keeping dependency out of all classpaths
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 <ka...@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 <us...@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 <ka...@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
>>> >
>>> >
>>>
>>
Re: Keeping dependency out of all classpaths
Posted by Falko Modler <f....@gmx.net>.
Hi,
for some reason I didn't get your initial mail, so I'm replying here.
I had a somewhat comparable challenge in Quarkus (making sure that
-amd/-am are picking up modules that must not contribute anything
relevant to the classpath) and ended up with this workaround:
https://github.com/quarkusio/quarkus/blob/2.10.0.CR1/docs/pom.xml#L64-L78
(the solution in Quarkus is even script-driven, but let's ignore that here)
So I'm merely targeting the pom of the module (type) and together with
scope test and wildcard exclusions only the pom.xml is added as a
resource to the surefire classpath, which doesn't bother anyone, and
it's not "visible" for consumers.
It's far from pretty, but the workaorund fills a certain gap in Maven in
terms of controlling upstream/downstream.
And for projects like Quarkus with ~1k modules, being able to build
incrementally is really important (it uses
https://github.com/gitflow-incremental-builder/gitflow-incremental-builder
for that).
So, this _might_ work for you if you combine that with a plugin dependency.
Cheers,
Falko
Am 10.06.2022 um 14:04 schrieb [Quipsy] Markus Karg:
> The third party plugin does not expect anything from the classpath as it is a non-Java Maven plugin. Imagine this case: The ZIP (hypothetically) contains SVG, the third party plugin renders into PDF, the PDF goes into the WAR as a resource. Again, just hypothetically. Just ignore WHY the ZIP is not a "normal" ZIP but concentrate on "it is of no value for the Java compiler and not processable by it".
>
> But let's make the use case even easier: Just kick the third party plugin out of the project and instead let's just use the normal dependency plugin pick some content from the ZIP file to put it into the WAR. Then your question is gone, but still the problem exists: The Maven compiler plugin fails because the ZIP is not in the expected format to be processable by the Maven compiler plugin. That ZIP simply is NOT INTENDED to be consumed by the Maven Compiler plugin. BTW, your assumption is wrong: Java does NOT say "ALL zip MUST be on the classpath", it just says "THOSE zips that you WANT to consume by the compiler must be on the classpath". This is a huge difference!
>
> -Markus
>
>
> -----Ursprüngliche Nachricht-----
> Von: Tamás Cservenák <ta...@cservenak.net>
> Gesendet: Freitag, 10. Juni 2022 13:53
> An: Maven Users List <us...@maven.apache.org>
> Betreff: Re: Keeping dependency out of all classpaths
>
> So let's enumerate what we have so far:
>
> - the ZIP is built in same multi module build, and is "intentionally incompatible"
> - the ZIP should be a dependency of WAR module, needed for Maven to be able to make proper build ordering decisions
> - Java specifically says "JARs and ZIPs are added to classpath"
> - only third party plugin processes the content of zip file
> - the result of WAR module class compilation AND third party plugin output should be part of resulting WAR
>
> But I still have questions:
> - how is the third party plugin expecting the input? Is injecting a project and programmatically finding the ZIP? Or does it expect it on the classpath? (as in this case....)
>
> IMO, still the custom packaging (well, artifact handler bit) is the solution here, especially as both, producing ZIP and consuming ZIP happens in the same multi module build. Either the plugin should define type=foo-plugin-resources or something like that, or you could define custom packaging (as you do build the zip file) and use custom type to reference ZIP dependency?
>
>
> HTH
> T
>
>
>
>
> On Fri, Jun 10, 2022 at 1:23 PM [Quipsy] Markus Karg <ka...@quipsy.de> wrote:
>
>> It is a dependency because it shall be built with -am if this project
>> is built, and it is consumed by this project using third party
>> plugins. But it simply is not consumed by the Java toolchain. This has
>> nothing to do with the plugin. The WAR produced here is built from
>> Java source compiled to Java classes and from ZIP-delivered binaries
>> to be put into the WAR as simple resources. There is nothing special
>> with that content nor with that properties. I do not see that the
>> third party plugin is the problem here; the problem is solely the "ALL
>> zips go into the Java classpath" default policy, which simply is
>> wrong: Even if the third-party plugin is removed, still it ist he
>> Maven compiler plugin which fails when it assumes specific ZIP format.
>>
>> So there is no misusing dependencies at all.
>>
>> -Markus
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: Tamás Cservenák <ta...@cservenak.net>
>> Gesendet: Freitag, 10. Juni 2022 13:15
>> An: Maven Users List <us...@maven.apache.org>
>> Betreff: Re: Keeping dependency out of all classpaths
>>
>> Well, shoot in the dark: why is this ZIP a _dependency_ in the first place?
>> As you say "they solely serve as an input to third party plugins (not
>> dealing with Java at all)". If so, maybe the plugin needs improvement
>> itself, and allow it's configuration to pick up the zip that holds
>> resources needed/used by only itself, instead to "force" these inputs
>> through the whole build ONLY to be fed/found/used by that 3rd party plugin?
>>
>> IMO, the plugin in question should stop misusing project dependencies,
>> that again, if it is part of multi module build (so project
>> ordering/inter dependencies should remain correct), then yes, maven
>> should "know" about it, should be dependency, but then again the
>> plugin itself should declare custom packaging (my 1st mail), and that is the proper solution IMO.
>>
>> T
>>
>>
>> On Fri, Jun 10, 2022 at 12:21 PM [Quipsy] Markus Karg <ka...@quipsy.de>
>> wrote:
>>
>>> That might work, but my intention is not to play with arbitrary
>>> experimental PRs, but is to find a consensus, what such a future
>>> feature should look like to get it accepted by the Maven team. Is
>>> that specific PR agreed to get adopted to Maven 4? IIUC this PR
>>> stops adding ANY zips tot he classpath, but how to keep a specific
>>> one one
>> still?
>>> -----Ursprüngliche Nachricht-----
>>> Von: Tamás Cservenák <ta...@cservenak.net>
>>> Gesendet: Freitag, 10. Juni 2022 12:13
>>> An: Maven Users List <us...@maven.apache.org>
>>> Betreff: Re: Keeping dependency out of all classpaths
>>>
>>> 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
>>>> <ka...@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 <us...@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/ma
>>>>> in
>>>>> /j
>>>>> ava/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-
>>>>> 2d
>>>>> 69
>>>>> ad832720
>>>>> (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/ma
>>>>> in
>>>>> /j
>>>>> ava/org/apache/maven/artifact/handler/ArtifactHandler.java#L31
>>>>>
>>>>>
>>>>> HTH
>>>>> T
>>>>>
>>>>>
>>>>> On Fri, Jun 10, 2022 at 10:54 AM [Quipsy] Markus Karg
>>>>> <ka...@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-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
AW: Keeping dependency out of all classpaths
Posted by "[Quipsy] Markus Karg" <ka...@quipsy.de>.
The third party plugin does not expect anything from the classpath as it is a non-Java Maven plugin. Imagine this case: The ZIP (hypothetically) contains SVG, the third party plugin renders into PDF, the PDF goes into the WAR as a resource. Again, just hypothetically. Just ignore WHY the ZIP is not a "normal" ZIP but concentrate on "it is of no value for the Java compiler and not processable by it".
But let's make the use case even easier: Just kick the third party plugin out of the project and instead let's just use the normal dependency plugin pick some content from the ZIP file to put it into the WAR. Then your question is gone, but still the problem exists: The Maven compiler plugin fails because the ZIP is not in the expected format to be processable by the Maven compiler plugin. That ZIP simply is NOT INTENDED to be consumed by the Maven Compiler plugin. BTW, your assumption is wrong: Java does NOT say "ALL zip MUST be on the classpath", it just says "THOSE zips that you WANT to consume by the compiler must be on the classpath". This is a huge difference!
-Markus
-----Ursprüngliche Nachricht-----
Von: Tamás Cservenák <ta...@cservenak.net>
Gesendet: Freitag, 10. Juni 2022 13:53
An: Maven Users List <us...@maven.apache.org>
Betreff: Re: Keeping dependency out of all classpaths
So let's enumerate what we have so far:
- the ZIP is built in same multi module build, and is "intentionally incompatible"
- the ZIP should be a dependency of WAR module, needed for Maven to be able to make proper build ordering decisions
- Java specifically says "JARs and ZIPs are added to classpath"
- only third party plugin processes the content of zip file
- the result of WAR module class compilation AND third party plugin output should be part of resulting WAR
But I still have questions:
- how is the third party plugin expecting the input? Is injecting a project and programmatically finding the ZIP? Or does it expect it on the classpath? (as in this case....)
IMO, still the custom packaging (well, artifact handler bit) is the solution here, especially as both, producing ZIP and consuming ZIP happens in the same multi module build. Either the plugin should define type=foo-plugin-resources or something like that, or you could define custom packaging (as you do build the zip file) and use custom type to reference ZIP dependency?
HTH
T
On Fri, Jun 10, 2022 at 1:23 PM [Quipsy] Markus Karg <ka...@quipsy.de> wrote:
> It is a dependency because it shall be built with -am if this project
> is built, and it is consumed by this project using third party
> plugins. But it simply is not consumed by the Java toolchain. This has
> nothing to do with the plugin. The WAR produced here is built from
> Java source compiled to Java classes and from ZIP-delivered binaries
> to be put into the WAR as simple resources. There is nothing special
> with that content nor with that properties. I do not see that the
> third party plugin is the problem here; the problem is solely the "ALL
> zips go into the Java classpath" default policy, which simply is
> wrong: Even if the third-party plugin is removed, still it ist he
> Maven compiler plugin which fails when it assumes specific ZIP format.
>
> So there is no misusing dependencies at all.
>
> -Markus
>
>
> -----Ursprüngliche Nachricht-----
> Von: Tamás Cservenák <ta...@cservenak.net>
> Gesendet: Freitag, 10. Juni 2022 13:15
> An: Maven Users List <us...@maven.apache.org>
> Betreff: Re: Keeping dependency out of all classpaths
>
> Well, shoot in the dark: why is this ZIP a _dependency_ in the first place?
> As you say "they solely serve as an input to third party plugins (not
> dealing with Java at all)". If so, maybe the plugin needs improvement
> itself, and allow it's configuration to pick up the zip that holds
> resources needed/used by only itself, instead to "force" these inputs
> through the whole build ONLY to be fed/found/used by that 3rd party plugin?
>
> IMO, the plugin in question should stop misusing project dependencies,
> that again, if it is part of multi module build (so project
> ordering/inter dependencies should remain correct), then yes, maven
> should "know" about it, should be dependency, but then again the
> plugin itself should declare custom packaging (my 1st mail), and that is the proper solution IMO.
>
> T
>
>
> On Fri, Jun 10, 2022 at 12:21 PM [Quipsy] Markus Karg <ka...@quipsy.de>
> wrote:
>
> > That might work, but my intention is not to play with arbitrary
> > experimental PRs, but is to find a consensus, what such a future
> > feature should look like to get it accepted by the Maven team. Is
> > that specific PR agreed to get adopted to Maven 4? IIUC this PR
> > stops adding ANY zips tot he classpath, but how to keep a specific
> > one one
> still?
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Tamás Cservenák <ta...@cservenak.net>
> > Gesendet: Freitag, 10. Juni 2022 12:13
> > An: Maven Users List <us...@maven.apache.org>
> > Betreff: Re: Keeping dependency out of all classpaths
> >
> > 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
> > > <ka...@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 <us...@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/ma
> > >> in
> > >> /j
> > >> ava/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-
> > >> 2d
> > >> 69
> > >> ad832720
> > >> (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/ma
> > >> in
> > >> /j
> > >> ava/org/apache/maven/artifact/handler/ArtifactHandler.java#L31
> > >>
> > >>
> > >> HTH
> > >> T
> > >>
> > >>
> > >> On Fri, Jun 10, 2022 at 10:54 AM [Quipsy] Markus Karg
> > >> <ka...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
Re: Keeping dependency out of all classpaths
Posted by Tamás Cservenák <ta...@cservenak.net>.
So let's enumerate what we have so far:
- the ZIP is built in same multi module build, and is "intentionally
incompatible"
- the ZIP should be a dependency of WAR module, needed for Maven to be able
to make proper build ordering decisions
- Java specifically says "JARs and ZIPs are added to classpath"
- only third party plugin processes the content of zip file
- the result of WAR module class compilation AND third party plugin output
should be part of resulting WAR
But I still have questions:
- how is the third party plugin expecting the input? Is injecting a
project and programmatically finding the ZIP? Or does it expect it on the
classpath? (as in this case....)
IMO, still the custom packaging (well, artifact handler bit) is the
solution here, especially as both, producing ZIP and consuming ZIP happens
in the same multi module build. Either the plugin should define
type=foo-plugin-resources or something like that, or you could define
custom packaging (as you do build the zip file) and use custom type to
reference ZIP dependency?
HTH
T
On Fri, Jun 10, 2022 at 1:23 PM [Quipsy] Markus Karg <ka...@quipsy.de> wrote:
> It is a dependency because it shall be built with -am if this project is
> built, and it is consumed by this project using third party plugins. But it
> simply is not consumed by the Java toolchain. This has nothing to do with
> the plugin. The WAR produced here is built from Java source compiled to
> Java classes and from ZIP-delivered binaries to be put into the WAR as
> simple resources. There is nothing special with that content nor with that
> properties. I do not see that the third party plugin is the problem here;
> the problem is solely the "ALL zips go into the Java classpath" default
> policy, which simply is wrong: Even if the third-party plugin is removed,
> still it ist he Maven compiler plugin which fails when it assumes specific
> ZIP format.
>
> So there is no misusing dependencies at all.
>
> -Markus
>
>
> -----Ursprüngliche Nachricht-----
> Von: Tamás Cservenák <ta...@cservenak.net>
> Gesendet: Freitag, 10. Juni 2022 13:15
> An: Maven Users List <us...@maven.apache.org>
> Betreff: Re: Keeping dependency out of all classpaths
>
> Well, shoot in the dark: why is this ZIP a _dependency_ in the first place?
> As you say "they solely serve as an input to third party plugins (not
> dealing with Java at all)". If so, maybe the plugin needs improvement
> itself, and allow it's configuration to pick up the zip that holds
> resources needed/used by only itself, instead to "force" these inputs
> through the whole build ONLY to be fed/found/used by that 3rd party plugin?
>
> IMO, the plugin in question should stop misusing project dependencies,
> that again, if it is part of multi module build (so project ordering/inter
> dependencies should remain correct), then yes, maven should "know" about
> it, should be dependency, but then again the plugin itself should declare
> custom packaging (my 1st mail), and that is the proper solution IMO.
>
> T
>
>
> On Fri, Jun 10, 2022 at 12:21 PM [Quipsy] Markus Karg <ka...@quipsy.de>
> wrote:
>
> > That might work, but my intention is not to play with arbitrary
> > experimental PRs, but is to find a consensus, what such a future
> > feature should look like to get it accepted by the Maven team. Is that
> > specific PR agreed to get adopted to Maven 4? IIUC this PR stops
> > adding ANY zips tot he classpath, but how to keep a specific one one
> still?
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Tamás Cservenák <ta...@cservenak.net>
> > Gesendet: Freitag, 10. Juni 2022 12:13
> > An: Maven Users List <us...@maven.apache.org>
> > Betreff: Re: Keeping dependency out of all classpaths
> >
> > 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
> > > <ka...@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 <us...@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
> > >> /j
> > >> ava/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-2d
> > >> 69
> > >> ad832720
> > >> (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
> > >> /j
> > >> ava/org/apache/maven/artifact/handler/ArtifactHandler.java#L31
> > >>
> > >>
> > >> HTH
> > >> T
> > >>
> > >>
> > >> On Fri, Jun 10, 2022 at 10:54 AM [Quipsy] Markus Karg
> > >> <ka...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
>
AW: Keeping dependency out of all classpaths
Posted by "[Quipsy] Markus Karg" <ka...@quipsy.de>.
It is a dependency because it shall be built with -am if this project is built, and it is consumed by this project using third party plugins. But it simply is not consumed by the Java toolchain. This has nothing to do with the plugin. The WAR produced here is built from Java source compiled to Java classes and from ZIP-delivered binaries to be put into the WAR as simple resources. There is nothing special with that content nor with that properties. I do not see that the third party plugin is the problem here; the problem is solely the "ALL zips go into the Java classpath" default policy, which simply is wrong: Even if the third-party plugin is removed, still it ist he Maven compiler plugin which fails when it assumes specific ZIP format.
So there is no misusing dependencies at all.
-Markus
-----Ursprüngliche Nachricht-----
Von: Tamás Cservenák <ta...@cservenak.net>
Gesendet: Freitag, 10. Juni 2022 13:15
An: Maven Users List <us...@maven.apache.org>
Betreff: Re: Keeping dependency out of all classpaths
Well, shoot in the dark: why is this ZIP a _dependency_ in the first place?
As you say "they solely serve as an input to third party plugins (not dealing with Java at all)". If so, maybe the plugin needs improvement itself, and allow it's configuration to pick up the zip that holds resources needed/used by only itself, instead to "force" these inputs through the whole build ONLY to be fed/found/used by that 3rd party plugin?
IMO, the plugin in question should stop misusing project dependencies, that again, if it is part of multi module build (so project ordering/inter dependencies should remain correct), then yes, maven should "know" about it, should be dependency, but then again the plugin itself should declare custom packaging (my 1st mail), and that is the proper solution IMO.
T
On Fri, Jun 10, 2022 at 12:21 PM [Quipsy] Markus Karg <ka...@quipsy.de>
wrote:
> That might work, but my intention is not to play with arbitrary
> experimental PRs, but is to find a consensus, what such a future
> feature should look like to get it accepted by the Maven team. Is that
> specific PR agreed to get adopted to Maven 4? IIUC this PR stops
> adding ANY zips tot he classpath, but how to keep a specific one one still?
>
> -----Ursprüngliche Nachricht-----
> Von: Tamás Cservenák <ta...@cservenak.net>
> Gesendet: Freitag, 10. Juni 2022 12:13
> An: Maven Users List <us...@maven.apache.org>
> Betreff: Re: Keeping dependency out of all classpaths
>
> 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
> > <ka...@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 <us...@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
> >> /j
> >> ava/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-2d
> >> 69
> >> ad832720
> >> (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
> >> /j
> >> ava/org/apache/maven/artifact/handler/ArtifactHandler.java#L31
> >>
> >>
> >> HTH
> >> T
> >>
> >>
> >> On Fri, Jun 10, 2022 at 10:54 AM [Quipsy] Markus Karg
> >> <ka...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
Re: Keeping dependency out of all classpaths
Posted by Tamás Cservenák <ta...@cservenak.net>.
Well, shoot in the dark: why is this ZIP a _dependency_ in the first place?
As you say "they solely serve as an input to third party plugins (not
dealing with Java at all)". If so, maybe the plugin needs improvement
itself, and allow it's configuration to pick up the zip that holds
resources needed/used by only itself, instead to "force" these
inputs through the whole build ONLY to be fed/found/used by that 3rd party
plugin?
IMO, the plugin in question should stop misusing project dependencies, that
again, if it is part of multi module build (so project ordering/inter
dependencies should remain correct), then yes, maven should "know" about
it, should be dependency, but then again the plugin itself should declare
custom packaging (my 1st mail), and that is the proper solution IMO.
T
On Fri, Jun 10, 2022 at 12:21 PM [Quipsy] Markus Karg <ka...@quipsy.de>
wrote:
> That might work, but my intention is not to play with arbitrary
> experimental PRs, but is to find a consensus, what such a future feature
> should look like to get it accepted by the Maven team. Is that specific PR
> agreed to get adopted to Maven 4? IIUC this PR stops adding ANY zips tot he
> classpath, but how to keep a specific one one still?
>
> -----Ursprüngliche Nachricht-----
> Von: Tamás Cservenák <ta...@cservenak.net>
> Gesendet: Freitag, 10. Juni 2022 12:13
> An: Maven Users List <us...@maven.apache.org>
> Betreff: Re: Keeping dependency out of all classpaths
>
> 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 <ka...@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 <us...@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/j
> >> ava/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-2d69
> >> ad832720
> >> (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/j
> >> ava/org/apache/maven/artifact/handler/ArtifactHandler.java#L31
> >>
> >>
> >> HTH
> >> T
> >>
> >>
> >> On Fri, Jun 10, 2022 at 10:54 AM [Quipsy] Markus Karg
> >> <ka...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
AW: Keeping dependency out of all classpaths
Posted by "[Quipsy] Markus Karg" <ka...@quipsy.de>.
That might work, but my intention is not to play with arbitrary experimental PRs, but is to find a consensus, what such a future feature should look like to get it accepted by the Maven team. Is that specific PR agreed to get adopted to Maven 4? IIUC this PR stops adding ANY zips tot he classpath, but how to keep a specific one one still?
-----Ursprüngliche Nachricht-----
Von: Tamás Cservenák <ta...@cservenak.net>
Gesendet: Freitag, 10. Juni 2022 12:13
An: Maven Users List <us...@maven.apache.org>
Betreff: Re: Keeping dependency out of all classpaths
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 <ka...@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 <us...@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/j
>> ava/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-2d69
>> ad832720
>> (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/j
>> ava/org/apache/maven/artifact/handler/ArtifactHandler.java#L31
>>
>>
>> HTH
>> T
>>
>>
>> On Fri, Jun 10, 2022 at 10:54 AM [Quipsy] Markus Karg
>> <ka...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Keeping dependency out of all classpaths
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 <ka...@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 <us...@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 <ka...@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
>> >
>> >
>>
>
Re: Keeping dependency out of all classpaths
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 <ka...@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 <us...@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 <ka...@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
> >
> >
>
AW: Keeping dependency out of all classpaths
Posted by "[Quipsy] Markus Karg" <ka...@quipsy.de>.
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 <us...@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 <ka...@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
>
>
Re: Keeping dependency out of all classpaths
Posted by Tamás Cservenák <ta...@cservenak.net>.
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 <ka...@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
>
>