I would offer <scope>alsoProvides</scope>
for the feature you propose. On Tue, Jun 28, 2011 at 11:11 AM, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
