> The critical scope to add for me is something along the lines of
> "provides" or "supplies" or "embeds-equivalent"
>
Why is this a scope and not just more configuration inside the
<dependency/> element?
<dependency>
<!-- gav -->
<alsoProvides>
<alsoProvide>
<!-- gav -->
</alsoProvide>
</alsoProvides>
</dependency>
> 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
