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.
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.
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
<[email protected]> 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 <[email protected]> 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 <[email protected]>:
>>> 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
>>> <[email protected]>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: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
