On 28 June 2011 14:38, Benson Margulies <bimargul...@gmail.com> wrote: >> >> Because why should I have to always state that I'm using >> org.slf4j:log4j-over-slf4j and that it provides log4j:log4j much >> better that the pom for org.slf4j:log4j-over-slf4j says "oh and by the >> way I provide log4j:log4j myself so you don't need to pull it in >> transitively if you depend on me" > > I think that you are abusing the term 'dependency' here. I think that, > if this is worth doing, it's worth adding a new element to the POM at > the same level as 'dependencies' to declare that the project's > artifact also provides a list of additional gavs. >
I agree, but if you stick to the "cannot change the pom format" the only thing you can just about do is introduce a new scope. >> >> maven could then break the build for you if you pull in log4j:log4j >> and org.slf4j:log4j-over-slf4j just as it does if you try to pull in >> two different versions of log4j:log4j >> >> and it could ensure that a project that depends on >> org.slf4j:log4j-over-slf4j never has log4j:log4j in its dependency >> tree. >> >> People will say that OSGi is the real answer here, and that you have >> to... blah blah blah... we are in the real world here, OSGi is good >> for some things and not for others, Maven needs a solution that is >> better than having to add >> <excludes><exclude><groupId>log4j</groupId><artifactId>log4j</artifactId></exclude></excludes> >> to _all_ the dependencies in your project just because you have added >> a dependency on org.slf4j:log4j-over-slf4j >> >>> >>> >>>> So that when computing the dependency tree, we could automatically >>>> exclude dependencies that are already provided or supplied or embedded >>>> in another dependency. >>>> >>>> The sticking point for me is that it needs a good name different from >>>> "provided" >>>> >>>>>> this easier to explain. Try writing a paragraph of doc that we'd put >>>>>> in the pom doc to explain 'provided' if we decide to just stick with >>>>>> this. >>>>>> >>>>>> However, I have a really simple idea. What if we permitted *no scope >>>>>> at all* for non-jar artifacts to serve this purpose? >>>>>> >>>>> >>>>> no scope => compile (modello default value) >>>>> >>>>> also dependency on war artifacts is used for war overlays.... >>>>> >>>>> what I am thinking is that if we change the war plugin so that only >>>>> scope compile wars are used for overlays, then tomcat maven plugin is >>>>> free to use either provided and/or runtime as the scope for >>>>> side-deployment... runtime could be good if you always needed it as a >>>>> side webapp (e.g. the ear plugin could then pull those runtime wars in >>>>> transitively, while the provided would behave as non-transitive) >>>>> >>>>>> >>>>>> On Mon, Jun 27, 2011 at 8:32 PM, Stephen Connolly >>>>>> <stephen.alan.conno...@gmail.com> wrote: >>>>>>> the wars are really side web apps that are provided by somebody else at >>>>>>> deployment time in the runtime container. >>>>>>> >>>>>>> just as the server api is provided by somebody else. >>>>>>> >>>>>>> the tomcat plugin is providing the container, so as it knows those side >>>>>>> apps >>>>>>> are not present it would make sense to me if it provided them for me. >>>>>>> just >>>>>>> like when running unit tests, surfer will provide the provided deps on >>>>>>> my >>>>>>> test classpath. >>>>>>> >>>>>>> what i am saying is tomato does not need a special scope. symmantically >>>>>>> their required scope is provided. >>>>>>> >>>>>>> - Stephen >>>>>>> >>>>>>> --- >>>>>>> Sent from my Android phone, so random spelling mistakes, random nonsense >>>>>>> words and other nonsense are a direct result of using swype to type on >>>>>>> the >>>>>>> screen >>>>>>> On 28 Jun 2011 00:46, "Benson Margulies" <bimargul...@gmail.com> wrote: >>>>>>>> The tomcat wars are NOT provided. The idea is to grab them from the >>>>>>>> repositories, copy them to the local repo, and have the tomcat plugin >>>>>>>> 'collect them all.' >>>>>>>> >>>>>>>> I didn't know that maven already had the concept of non-classpath >>>>>>>> artifact types. I've been laboring under the idea that these things >>>>>>>> would end up in the classpath if not excluded somehow. >>>>>>>> >>>>>>>> Tomcat could stop using the special scope, but then it would need to >>>>>>>> redundantly list these artifacts in its own config, unless the author >>>>>>>> were willing to take the attitude that *all* war dependencies should >>>>>>>> be launched. Using foo:bar syntax instead of a nest of XML that is >>>>>>>> perhaps not too awful, but it still feels like listing the same thing >>>>>>>> twice. Hmm: how does the new site plugin avoid this? With the new site >>>>>>>> plugin, can you built a reporting plugin in the reactor and then use >>>>>>>> it in a site? I bet not. >>>>>>>> >>>>>>>> In short, I'm arguing for some idea of annotating dependencies to >>>>>>>> avoid redundantly calling them out in plugins, but I'm not arguing >>>>>>>> terribly loudly. >>>>>>>> >>>>>>>> On Mon, Jun 27, 2011 at 7:22 PM, Stephen Connolly >>>>>>>> <stephen.alan.conno...@gmail.com> wrote: >>>>>>>>> On 28 June 2011 00:15, Benson Margulies <bimargul...@gmail.com> wrote: >>>>>>>>>> Consider the tomcat use case, and then mine. >>>>>>>>>> >>>>>>>>>> The tomcat use-case is: declare additional artifacts of >>>>>>>>>> type/packaging >>>>>>>>>> 'war'. The plugin launches them as additional webapps. >>>>>>>>> >>>>>>>>> Why won't provided work for this? >>>>>>>>> >>>>>>>>> war is a non-classpath dependency... compile (default) makes sense for >>>>>>> overlays >>>>>>>>> >>>>>>>>> provided -> supplied by the container... in this case tomcat >>>>>>>>> >>>>>>>>>> >>>>>>>>>> My use case: This artifact of code, here, depends on that giant >>>>>>>>>> artifact of data, there. >>>>>>>>>> >>>>>>>>>> In both cases, the dependency *does* need to be copied to the local >>>>>>>>>> repo, but does *not* want to be in classpath. >>>>>>>>> >>>>>>>>> then that is a non-classpath artifact type unless i mis-understand >>>>>>>>> your >>>>>>> case >>>>>>>>> >>>>>>>>>> >>>>>>>>>> So, what would you think of >>>>>>>>>> >>>>>>>>>> <dependency> >>>>>>>>>> <!-- gav --> >>>>>>>>>> <scope>non-classpath</scope> >>>>>>>>>> <list>tomcat</list> >>>>>>>>>> </dependency> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> That is, define the concept of a named list of dependencies, which >>>>>>>>>> seems harmlessly extensible, while defining exactly one more scope, >>>>>>>>>> to >>>>>>>>>> use for this purpose? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Jun 27, 2011 at 6:54 PM, Stephen Connolly >>>>>>>>>> <stephen.alan.conno...@gmail.com> wrote: >>>>>>>>>>> Allowing people to have custom scopes is a thin end of the wedge... >>>>>>>>>>> >>>>>>>>>>> The scopes we have are not sufficient, so I am +1 to expanding them >>>>>>>>>>> >>>>>>>>>>> Custom scopes are a recipe for disaster... the whole point of >>>>>>>>>>> standardization is that everyone knows what they mean. >>>>>>>>>>> >>>>>>>>>>> Currently we have: >>>>>>>>>>> >>>>>>>>>>> compile - which we have borked to be transitive but shouldn't be >>>>>>>>>>> runtime - fair enough >>>>>>>>>>> provided - which is closer to what compile should have been >>>>>>>>>>> test - not good enough for the multitude of testing phases >>>>>>>>>>> system - Eeek! don't use >>>>>>>>>>> import - nobody has a clue what exactly this does >>>>>>>>>>> >>>>>>>>>>> Critically missing from my PoV are: >>>>>>>>>>> >>>>>>>>>>> provides - needs a better name, but I want to signify that I >>>>>>>>>>> provide a >>>>>>>>>>> specific GAV in my pom so that you don't bother trying to pull it in >>>>>>>>>>> for another dep... eg. log4j-over-slf4 would provides log4j >>>>>>>>>>> >>>>>>>>>>> test-compile >>>>>>>>>>> test-runtime >>>>>>>>>>> >>>>>>>>>>> some scope that is like compile & runtime but not the test >>>>>>>>>>> classpath... >>>>>>>>>>> >>>>>>>>>>> Actually the more I think about it what you really want to specify, >>>>>>>>>>> in >>>>>>>>>>> a standardized way is the list of classpaths to add to, and whether >>>>>>>>>>> it >>>>>>>>>>> is transitive on that classpath... >>>>>>>>>>> >>>>>>>>>>> And of course in the non-maven world, classpath does not make >>>>>>>>>>> sense... >>>>>>>>>>> but there are equivalents >>>>>>>>>>> >>>>>>>>>>> <dependency> >>>>>>>>>>> <groupId>...</groupId> >>>>>>>>>>> <artifactId>...</artifactId> >>>>>>>>>>> <version>...</version> >>>>>>>>>>> <scopes> >>>>>>>>>>> <scope> >>>>>>>>>>> <name>compile</name> >>>>>>>>>>> <transitive>true</transitive> >>>>>>>>>>> </scope> >>>>>>>>>>> <scope> >>>>>>>>>>> <name>runtime</name> >>>>>>>>>>> <transitive>false</transitive> >>>>>>>>>>> </scope> >>>>>>>>>>> <scope> >>>>>>>>>>> <name>test</name> >>>>>>>>>>> <transitive>true</transitive> >>>>>>>>>>> </scope> >>>>>>>>>>> </scopes> >>>>>>>>>>> </dependency> >>>>>>>>>>> >>>>>>>>>>> Man that's ugly >>>>>>>>>>> >>>>>>>>>>> On 27 June 2011 23:27, Benson Margulies <bimargul...@gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>>> Two options in my head: >>>>>>>>>>>> >>>>>>>>>>>> 1) Eliminate the warning. >>>>>>>>>>>> 2) Allow some means for officially defining scopes -- the problem >>>>>>>>>>>> being that the consumer is the logical place for the definition. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2011/6/27 Arnaud Héritier <aherit...@gmail.com>: >>>>>>>>>>>>> I don't have any pointer in mind except this page which doesn't >>>>>>>>>>>>> say >>>>>>> much >>>>>>>>>>>>> than a stricter validation of POM : >>>>>>>>>>>>> >>>>>>> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-StricterPOMValidation >>>>>>>>>>>>> But that right that in maven 2 we just ignored unknown scopes >>>>>>>>>>>>> while >>>>>>> maven 3 >>>>>>>>>>>>> throws a warning >>>>>>>>>>>>> >>>>>>>>>>>>> Arnaud >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Jun 27, 2011 at 7:02 PM, Benson Margulies < >>>>>>> bimargul...@gmail.com>wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> In looking at the tomcat plugin, I noticed that it depends on >>>>>>>>>>>>>> using >>>>>>> a >>>>>>>>>>>>>> custom scope, and there was commentary complaining that maven 3 >>>>>>>>>>>>>> complains. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Is there a thread or a JIRA about this? I'm contemplating >>>>>>>>>>>>>> creating >>>>>>>>>>>>>> something like this of my own, and I'd like to know what trouble >>>>>>>>>>>>>> I'm >>>>>>>>>>>>>> getting myself into. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>>>> >>>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>>> For additional commands, e-mail: dev-h...@maven.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org