maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benson Margulies <bimargul...@gmail.com>
Subject Re: <scope>peri</scope>
Date Mon, 27 Jun 2011 23:46:27 GMT
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.connolly@gmail.com> wrote:
> On 28 June 2011 00:15, Benson Margulies <bimargulies@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.connolly@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 <bimargulies@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 <aheritier@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 <bimargulies@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-unsubscribe@maven.apache.org
>>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message