RE: [jira] Commented: (MNG-415) allow exclusion of certain depend encies from inclusion in an archive

[Maczka Michal <mi...@imtf.ch>]

 

> -----Original Message-----
> From: Brett Porter (JIRA) [mailto:jira@codehaus.org] 

>  
>to your point, however - making your change: 
>a) triples what needs to be specified for most compile dependencies - you'd
also need to specify test, and hope we never add anything else implied from
compile. This violates the rule we're 
>following of making the defaults work most of the time, and the amount of
configuration needed minimal. 

How does it violates this rule?
The defaults will remain the same - if you don't give provide dependency
scope (as far as I see it now this will be a case for most of the non test
dependencies) dependencies will be visible in all classpaths.
Only when you will want to have one of them  excluded  from some classpaths
you will want to use scope tags. both compile time and runtime dependecies
can be also still visible in test class path.

And it indeed requires some amount of extra work in a very limited set of
cases ( "triples what needs to be specified " is not really accurate - see
below).  But if you compare this to amount of work needed in any other
solution I can think of it actually reduces that amount by much larger
factor (probably more then 10).  So if you look for simplicity - this is
probaly the simplest solution. Just to exclude serlvletapi from war you will
have to change:

from:
<dependency>
     ..
    <artifactId>servletapi</artifactId>
    ..
</dependency>

to:
<dependency>
     ..
    <artifactId>servletapi</artifactId>
    <scope>compile</scope>  (you just need to add this single line to
excluded dependency from "runtime" classpath)
    ..
</dependency>

I don't see how does it "triples what needs to be specified" and how it can
get any simpler :)


>b) is not actually scope any more. Excluding something from runtime, but
including it compile assumes something about the end environment, which the
dependencies should not do - that's the job of the >assembling plugin. 

Sure. But war is an assembling plugin and if you have project packaging set
to "war" you are actually not likely going to use the same pom for creating
other assemblies and you definitly know something about environment in which
this artifact will be used (servlet container). It is just a question if
standard attributes of dependencies are sufficient or not and if they are
not sufficient how it can be done in the other way. 
Anyway scope tag (scope=test) is already used for filtering out artifacts
from assemblies so I don't see what's actually the problem with that.


>>From a pure point of view a compile time dependency is always needed at
runtime (unless the code is never hit, or the server provides the jar, all
of which is environmental, not by >definition) 

Not true. For example servletapi is a jar agaist which you want to compile
but most servlet containers have classes from that jar bundled in their own
jars which have completely different names. 


> So unless there is something else missing, the scope will 
> remain as it is. We can't go breaking backwards compatibility 
> unless it is a really serious problem that we can't take forward.
> 

I think this case qualifies for such change :) 
 
regards

michal

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org

Re: [jira] Commented: (MNG-415) allow exclusion of certain depend encies from inclusion in an archive

[Brett Porter <br...@apache.org>]

my comments inline. To me, you seem to be viewing all of dependency
management through the eyes of a single use case (being war exclusions),
which is where we are disagreeing.

Maczka Michal wrote:

>And it indeed requires some amount of extra work in a very limited set of
>cases ( "triples what needs to be specified " is not really accurate - see
>below).  
>
To allow for multiple values:
<scope>foo</scope>
becomes
<scopes>
  <scope>foo</scope>
</scopes>
if we are to retain the conventions used so far.

>But if you compare this to amount of work needed in any other
>solution I can think of it actually reduces that amount by much larger
>factor (probably more then 10).  
>
Actaully, your example adds 3 lines instead of 1, so its a factor of 3,
not 10 - exactly the same - but for the other example each additional
dependency is only one more on top of that, instead of 3 or 4 again as
you are proposing :)

But, really, I didn't intend to nitpick about the number of lines
needed. That's not the point I was getting at.

>So if you look for simplicity - this is
>probaly the simplest solution. Just to exclude serlvletapi from war you will
>have to change:
>  
>
Or for simplicity, let's make servletapi a default exclude for WAR and
not configure anything. It's not worth changing the defiition of the
dependencies for a single JAR.

>Sure. But war is an assembling plugin and if you have project packaging set
>to "war" you are actually not likely going to use the same pom for creating
>other assemblies and you definitly know something about environment in which
>this artifact will be used (servlet container). It is just a question if
>standard attributes of dependencies are sufficient or not and if they are
>not sufficient how it can be done in the other way. 
>Anyway scope tag (scope=test) is already used for filtering out artifacts
>from assemblies so I don't see what's actually the problem with that.
>
>  
>
I'm probably missing something, but I can't see how what you are saying
here is related to my point at all. I'm saying you can't change the
definition of scope for the entire system to fit the war use case.

>>>From a pure point of view a compile time dependency is always needed at
>runtime (unless the code is never hit, or the server provides the jar, all
>of which is environmental, not by >definition) 
>
>Not true. For example servletapi is a jar agaist which you want to compile
>but most servlet containers have classes from that jar bundled in their own
>jars which have completely different names. 
>  
>
Read what I wrote again. The servletapi, needed at compile time, is also
needed at runtime. You've just said so yourself. Just because the
container happens to provide it, doesn't change anything.

Since we seem to be stuck on servletapi, let's go to a practical
example. You run some tests using a mock library that calls your code,
which utilises the servletapi. No container. What scope does the
servletapi have in your proposal? You'll probably answer "compile, test"
which in this example is valid. What if these tests were not junit
tests, but some other set using the "runtime" classpath? So you add
runtime to servletapi and now it is automatically included in the war -
exactly what you didn't want.

We can't mix concepts. scope != bundling, so we can't try and abuse it
to make it the same. It will give you the right default 99% of the time,
the other 1% you need to configure it, under the war plugin in terms of
bundling.

>I think this case qualifies for such change :) 
>  
>
That's much easier for you to say since you aren't doing the work :)

You can't argue the point in terms of one use case. You need to address
how all the counter examples raised would work under your scheme too.
Then, if there are others who agree that is better, we can look into it.
But I think the confusion here is just how it is being communicated, not
that the concept is broken.

- Brett


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org