<scope>peri</scope>

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

<scope>peri</scope>

Benson Margulies
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: <scope>peri</scope>

Arnaud Héritier
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 <[hidden email]>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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: <scope>peri</scope>

Benson Margulies
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 <[hidden email]>:

> 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 <[hidden email]>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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: <scope>peri</scope>

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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: <scope>peri</scope>

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

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: <scope>peri</scope>

stephenconnolly
On 28 June 2011 00:15, Benson Margulies <[hidden email]> 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
> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>> 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 <[hidden email]>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: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: <scope>peri</scope>

Benson Margulies
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
<[hidden email]> wrote:

> On 28 June 2011 00:15, Benson Margulies <[hidden email]> 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
>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>>> 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 <[hidden email]>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: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: <scope>peri</scope>

stephenconnolly
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" <[hidden email]> 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
> <[hidden email]> wrote:
>> On 28 June 2011 00:15, Benson Margulies <[hidden email]> 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
>>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>>>> 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 <
[hidden email]>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: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
Reply | Threaded
Open this post in threaded view
|

Re: <scope>peri</scope>

stephenconnolly
surefire not surfer... stupid phone

- 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 01:32, "Stephen Connolly" <[hidden email]>
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" <[hidden email]> 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
>> <[hidden email]> wrote:
>>> On 28 June 2011 00:15, Benson Margulies <[hidden email]> 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
>>>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>>>>> 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 <
> [hidden email]>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: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
Reply | Threaded
Open this post in threaded view
|

Re: <scope>peri</scope>

brettporter
Administrator
I found the "tomato" reference funnier.

On 28/06/2011, at 8:33 AM, Stephen Connolly wrote:

> surefire not surfer... stupid phone
>
> - 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 01:32, "Stephen Connolly" <[hidden email]>
> 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" <[hidden email]> 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
>>> <[hidden email]> wrote:
>>>> On 28 June 2011 00:15, Benson Margulies <[hidden email]> 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
>>>>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>>>>>> 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 <
>> [hidden email]>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: [hidden email]
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>

--
Brett Porter
[hidden email]
http://brettporter.wordpress.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: <scope>peri</scope>

brettporter
Administrator
In reply to this post by Benson Margulies

On 28/06/2011, at 7:46 AM, Benson Margulies 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.

Right - you should be declaring a new type in a plugin that can turn off <addedToClasspath/> - or use a packaging type like zip which wasn't already.

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

The currently recommended approach to this is to filter the list of dependencies with includes/excludes configuration in the plugin, like the dependency plugin does. This doesn't require duplicating as much information since you can use some short hand.

- Brett

--
Brett Porter
[hidden email]
http://brettporter.wordpress.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: <scope>peri</scope>

Jörg Schaible-3
Brett Porter wrote:

>
> On 28/06/2011, at 7:46 AM, Benson Margulies 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.
>
> Right - you should be declaring a new type in a plugin that can turn off
> <addedToClasspath/>

A component descriptor is normally enough. A plugin is only needed if such
an archive requires a very special handling that cannot be accomplished
easily with the dependency or assembly plugin.

> - or use a packaging type like zip which wasn't
> already.

Just as a side node: ZIP *is* added to the classpath - unfortunately. We use
therefore a simple jar file with a plexus component descriptor that turns
that off:

==== %< =====
 <component-set>
   <components>
     <component>
       <role>org.apache.maven.artifact.handler.ArtifactHandler</role>
       <role-hint>zip</role-hint>
       <implementation>org.apache.maven.artifact.handler.DefaultArtifactHandler</implementation>
       <configuration>
         <type>zip</type>
         <addedToClasspath>false</addedToClasspath>
         <includesDependencies>true</includesDependencies>
       </configuration>
     </component>
   </components>
 </component-set>
==== %< =====

This jar is added as extension to our global parent POM. Additionally you
have to set the extensions flag for all plugins to true that have to respect
this (e.g. compiler plugin) which is also done in this parent POM in the
pluginMgmt section.

[snip]

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: <scope>peri</scope>

Stan Devitt-2

Stan Devitt,  Platform Group

----- Original Message -----
From: Jörg Schaible [mailto:[hidden email]]
Sent: Tuesday, June 28, 2011 02:40 AM
To: [hidden email] <[hidden email]>
Subject: Re: <scope>peri</scope>

Brett Porter wrote:

>
> On 28/06/2011, at 7:46 AM, Benson Margulies 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.
>
> Right - you should be declaring a new type in a plugin that can turn off
> <addedToClasspath/>

A component descriptor is normally enough. A plugin is only needed if such
an archive requires a very special handling that cannot be accomplished
easily with the dependency or assembly plugin.

> - or use a packaging type like zip which wasn't
> already.

Just as a side node: ZIP *is* added to the classpath - unfortunately. We use
therefore a simple jar file with a plexus component descriptor that turns
that off:

==== %< =====
 <component-set>
   <components>
     <component>
       <role>org.apache.maven.artifact.handler.ArtifactHandler</role>
       <role-hint>zip</role-hint>
       <implementation>org.apache.maven.artifact.handler.DefaultArtifactHandler</implementation>
       <configuration>
         <type>zip</type>
         <addedToClasspath>false</addedToClasspath>
         <includesDependencies>true</includesDependencies>
       </configuration>
     </component>
   </components>
 </component-set>
==== %< =====

This jar is added as extension to our global parent POM. Additionally you
have to set the extensions flag for all plugins to true that have to respect
this (e.g. compiler plugin) which is also done in this parent POM in the
pluginMgmt section.

[snip]

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: <scope>peri</scope>

Stan Devitt-2
Apologies: I hit the wrong button.

I am enjoying this thread.  My main observation so far is that if you need one custom scope (and I think you do) then you will need more. "Provided" is not enough.

The custom scope seems to let you get at lists of dependencies that have a special purpose.  They seem to do this without breaking anything or interfering with the existing classpaths.. There can be more than one special purpose.  There is more than just Java.

Stan
Stan Devitt,  Platform Group
---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: <scope>peri</scope>

Benson Margulies
In reply to this post by stephenconnolly
I was pretty sleepy last night.

My residual disagreement is that 'provided' doesn't just mean 'copy to
local repo'. It means 'copy to local repo and put in test classpath.'
Yes, I now get it, an appropriate packaging avoids any classpath. The
word 'provided' is used because it's 'provided' by the environment by
magic at runtime. I end up thinking that one more scope would make
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?


On Mon, Jun 27, 2011 at 8:32 PM, Stephen Connolly
<[hidden email]> 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" <[hidden email]> 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
>> <[hidden email]> wrote:
>>> On 28 June 2011 00:15, Benson Margulies <[hidden email]> 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
>>>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>>>>> 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 <
> [hidden email]>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: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: <scope>peri</scope>

stephenconnolly
On 28 June 2011 11:31, Benson Margulies <[hidden email]> wrote:

> I was pretty sleepy last night.
>
> My residual disagreement is that 'provided' doesn't just mean 'copy to
> local repo'. It means 'copy to local repo and put in test classpath.'
> Yes, I now get it, an appropriate packaging avoids any classpath. The
> word 'provided' is used because it's 'provided' by the environment by
> magic at runtime. I end up thinking that one more scope would make
> 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
> <[hidden email]> 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" <[hidden email]> 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
>>> <[hidden email]> wrote:
>>>> On 28 June 2011 00:15, Benson Margulies <[hidden email]> 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
>>>>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>>>>>> 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 <
>> [hidden email]>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: [hidden email]
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: <scope>peri</scope>

stephenconnolly
On 28 June 2011 11:38, Stephen Connolly <[hidden email]> wrote:
> On 28 June 2011 11:31, Benson Margulies <[hidden email]> wrote:
>> I was pretty sleepy last night.
>>
>> My residual disagreement is that 'provided' doesn't just mean 'copy to
>> local repo'. It means 'copy to local repo and put in test classpath.'
>> Yes, I now get it, an appropriate packaging avoids any classpath. The
>> word 'provided' is used because it's 'provided' by the environment by
>> magic at runtime. I end up thinking that one more scope would make

The critical scope to add for me is something along the lines of
"provides" or "supplies" or "embeds-equivalent"

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
>> <[hidden email]> 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" <[hidden email]> 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
>>>> <[hidden email]> wrote:
>>>>> On 28 June 2011 00:15, Benson Margulies <[hidden email]> 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
>>>>>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>>>>>>> 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 <
>>> [hidden email]>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: [hidden email]
>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: <scope>peri</scope>

Benson Margulies
> 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
>>> <[hidden email]> 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" <[hidden email]> 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
>>>>> <[hidden email]> wrote:
>>>>>> On 28 June 2011 00:15, Benson Margulies <[hidden email]> 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
>>>>>>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>>>>>>>> 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 <
>>>> [hidden email]>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: [hidden email]
>>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: <scope>peri</scope>

stephenconnolly
On 28 June 2011 14:01, Benson Margulies <[hidden email]> wrote:

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

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"

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
>>>> <[hidden email]> 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" <[hidden email]> 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
>>>>>> <[hidden email]> wrote:
>>>>>>> On 28 June 2011 00:15, Benson Margulies <[hidden email]> 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
>>>>>>>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>>>>>>>>> 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 <
>>>>> [hidden email]>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: [hidden email]
>>>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: <scope>peri</scope>

Benson Margulies
>
> 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
>>>>> <[hidden email]> 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" <[hidden email]> 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
>>>>>>> <[hidden email]> wrote:
>>>>>>>> On 28 June 2011 00:15, Benson Margulies <[hidden email]> 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
>>>>>>>>> <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>>>>>>>>>>>> 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 <
>>>>>> [hidden email]>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: [hidden email]
>>>>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [hidden email]
>>>>>>> For additional commands, e-mail: [hidden email]
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: [hidden email]
>>>>> For additional commands, e-mail: [hidden email]
>>>>>
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12