Re: [jira] Commented: (MNG-415) allow exclusion of certain depend encies from inclusion in an archive
Maczka Michal wrote: What was surprising to me is that you have disqualified this proposition in 2 minutes without even reading with attention what I have written in my jira comment and judged it as something "too complicated". I started to reply to your invidual points until I got to this. I've given your responses careful consideration and detailed replies, and spent reasonable time on it. Sorry you feel this way. So if you are saying: scopes in m2 are not going to change and this is not something which we are ever going to consider - I think that this discussion is useless and I am not going to waste my precious time anymore. This is not only my call to make, so I will bring this up again in the design discussions next week, and see if there is some consensus among people working in here. What you do with your time is up to you. The problems you have highlighted centre around believing there is a need for a compile time dependency that is not runtime. This stems from believing runtime equates to bundling. Runtime is not only bundling - it is also used for classpath construction, such as for the execution of javadoc. An alternative has been proposed which we will discuss alongside the other design items: scope = container. This takes the bundling into consideration, separate from runtime as it should be. A container scoped dependency would be available at compile, run and test time, but would not be bundled. This was a quick idea from Jason, but its the best alternative I've heard so far. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Commented: (MNG-415) allow exclusion of certain depend encies from inclusion in an archive
Hey Brett! >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: >foo >becomes > > foo > >if we are to retain the conventions used so far. > > > This is just one of many possibilities. Some of others are: a) use predefined tags (do you want to have more scopes then "compile", "runtime" and "test"?) : b) use "flat" structure test compile c) change the rules which exists and add one more predefined scope one more scope maybe introduced (e.g. named "global") and your rules: compile --> runtime (--> means "imply") runtime --> test can be replaced with: global --> compile global --> runtime runtime --> test compile --> test And have a default scope set to "global" I am sure that there is bunch of much better options then those which I found quite quickly. But the question is: do you want to still consider changes in that part of m2 or for you this part is fixed? At the moment the number of POMs which are using scope tag is very low. So this will be no almost breaking change. So if you are saying: scopes in m2 are not going to change and this is not something which we are ever going to consider - I think that this discussion is useless and I am not going to waste my precious time anymore. I also believe that the best option here will be this one, which will be the most intuitive for users. So they can guess what are the rules without even looking at the documentation. So my proposition c) and what exists now as for me seem to be an inferior solutions as users have to learn some unintuitive and very arbitrary rules. But to know that for sure what's easy and intuitive you must actually ask your users what is simple for them. As something which is simple for you or for me does not have to be simple for avg. user. You wrote: "Hugo - if you make "runtime" imply "compile" you can never have a runtime only dependency, which is a valid and common use case (i.e. anything where you only call into it via reflection - like a JCE provider, etc). " I can replay to that if you make "compile" imply "runtime" you can never have a compile time only dependency, which is a valid and common use case. I don't think that any of those two usecase is more important and that's why it would be nice to support both. [...] >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. > > > you may have classes from servletapi incorporated into some other jars (e.g. j2ee). And you still need to exclude some other jars. >>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. > > One more time: no! The container doesn't have to provide _the_ servletapi jar which was used at compile time. It just needs to provide the compatible substitute. It maybe be a different jar (e.g. something like geronimo-spec) or servletapi with higher version. >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, tes
Re: [jira] Commented: (MNG-415) allow exclusion of certain depend encies from inclusion in an archive
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: foo becomes foo 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [jira] Commented: (MNG-415) allow exclusion of certain depend encies from inclusion in an archive
> -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: .. servletapi .. to: .. servletapi compile (you just need to add this single line to excluded dependency from "runtime" classpath) .. 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]
