> > 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. > > 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
