> -----Original Message----- > From: Brett Porter (JIRA) [mailto:[EMAIL PROTECTED]
> >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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]