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" <stephen.alan.conno...@gmail.com>
> wrote:
>> the wars are really side web apps that are provided by somebody else at
>> deployment time in the runtime container.
>> 
>> just as the server api is provided by somebody else.
>> 
>> the tomcat plugin is providing the container, so as it knows those side
> apps
>> are not present it would make sense to me if it provided them for me. just
>> like when running unit tests, surfer will provide the provided deps on my
>> test classpath.
>> 
>> what i am saying is tomato does not need a special scope. symmantically
>> their required scope is provided.
>> 
>> - Stephen
>> 
>> ---
>> Sent from my Android phone, so random spelling mistakes, random nonsense
>> words and other nonsense are a direct result of using swype to type on the
>> screen
>> On 28 Jun 2011 00:46, "Benson Margulies" <bimargul...@gmail.com> wrote:
>>> The tomcat wars are NOT provided. The idea is to grab them from the
>>> repositories, copy them to the local repo, and have the tomcat plugin
>>> 'collect them all.'
>>> 
>>> I didn't know that maven already had the concept of non-classpath
>>> artifact types. I've been laboring under the idea that these things
>>> would end up in the classpath if not excluded somehow.
>>> 
>>> Tomcat could stop using the special scope, but then it would need to
>>> redundantly list these artifacts in its own config, unless the author
>>> were willing to take the attitude that *all* war dependencies should
>>> be launched. Using foo:bar syntax instead of a nest of XML that is
>>> perhaps not too awful, but it still feels like listing the same thing
>>> twice. Hmm: how does the new site plugin avoid this? With the new site
>>> plugin, can you built a reporting plugin in the reactor and then use
>>> it in a site? I bet not.
>>> 
>>> In short, I'm arguing for some idea of annotating dependencies to
>>> avoid redundantly calling them out in plugins, but I'm not arguing
>>> terribly loudly.
>>> 
>>> On Mon, Jun 27, 2011 at 7:22 PM, Stephen Connolly
>>> <stephen.alan.conno...@gmail.com> wrote:
>>>> On 28 June 2011 00:15, Benson Margulies <bimargul...@gmail.com> wrote:
>>>>> Consider the tomcat use case, and then mine.
>>>>> 
>>>>> The tomcat use-case is: declare additional artifacts of type/packaging
>>>>> 'war'. The plugin launches them as additional webapps.
>>>> 
>>>> Why won't provided work for this?
>>>> 
>>>> war is a non-classpath dependency... compile (default) makes sense for
>> overlays
>>>> 
>>>> provided -> supplied by the container... in this case tomcat
>>>> 
>>>>> 
>>>>> My use case: This artifact of code, here, depends on that giant
>>>>> artifact of data, there.
>>>>> 
>>>>> In both cases, the dependency *does* need to be copied to the local
>>>>> repo, but does *not* want to be in classpath.
>>>> 
>>>> then that is a non-classpath artifact type unless i mis-understand your
>> case
>>>> 
>>>>> 
>>>>> So, what would you think of
>>>>> 
>>>>> <dependency>
>>>>> <!-- gav -->
>>>>> <scope>non-classpath</scope>
>>>>> <list>tomcat</list>
>>>>> </dependency>
>>>>> 
>>>>> 
>>>>> That is, define the concept of a named list of dependencies, which
>>>>> seems harmlessly extensible, while defining exactly one more scope, to
>>>>> use for this purpose?
>>>>> 
>>>>> 
>>>>> 
>>>>> On Mon, Jun 27, 2011 at 6:54 PM, Stephen Connolly
>>>>> <stephen.alan.conno...@gmail.com> wrote:
>>>>>> Allowing people to have custom scopes is a thin end of the wedge...
>>>>>> 
>>>>>> The scopes we have are not sufficient, so I am +1 to expanding them
>>>>>> 
>>>>>> Custom scopes are a recipe for disaster... the whole point of
>>>>>> standardization is that everyone knows what they mean.
>>>>>> 
>>>>>> Currently we have:
>>>>>> 
>>>>>> compile - which we have borked to be transitive but shouldn't be
>>>>>> runtime - fair enough
>>>>>> provided - which is closer to what compile should have been
>>>>>> test - not good enough for the multitude of testing phases
>>>>>> system - Eeek! don't use
>>>>>> import - nobody has a clue what exactly this does
>>>>>> 
>>>>>> Critically missing from my PoV are:
>>>>>> 
>>>>>> provides - needs a better name, but I want to signify that I provide a
>>>>>> specific GAV in my pom so that you don't bother trying to pull it in
>>>>>> for another dep... eg. log4j-over-slf4 would provides log4j
>>>>>> 
>>>>>> test-compile
>>>>>> test-runtime
>>>>>> 
>>>>>> some scope that is like compile & runtime but not the test
> classpath...
>>>>>> 
>>>>>> Actually the more I think about it what you really want to specify, in
>>>>>> a standardized way is the list of classpaths to add to, and whether it
>>>>>> is transitive on that classpath...
>>>>>> 
>>>>>> And of course in the non-maven world, classpath does not make sense...
>>>>>> but there are equivalents
>>>>>> 
>>>>>> <dependency>
>>>>>> <groupId>...</groupId>
>>>>>> <artifactId>...</artifactId>
>>>>>> <version>...</version>
>>>>>> <scopes>
>>>>>> <scope>
>>>>>> <name>compile</name>
>>>>>> <transitive>true</transitive>
>>>>>> </scope>
>>>>>> <scope>
>>>>>> <name>runtime</name>
>>>>>> <transitive>false</transitive>
>>>>>> </scope>
>>>>>> <scope>
>>>>>> <name>test</name>
>>>>>> <transitive>true</transitive>
>>>>>> </scope>
>>>>>> </scopes>
>>>>>> </dependency>
>>>>>> 
>>>>>> Man that's ugly
>>>>>> 
>>>>>> On 27 June 2011 23:27, Benson Margulies <bimargul...@gmail.com> wrote:
>>>>>>> Two options in my head:
>>>>>>> 
>>>>>>> 1) Eliminate the warning.
>>>>>>> 2) Allow some means for officially defining scopes -- the problem
>>>>>>> being that the consumer is the logical place for the definition.
>>>>>>> 
>>>>>>> 
>>>>>>> 2011/6/27 Arnaud Héritier <aherit...@gmail.com>:
>>>>>>>> I don't have any pointer in mind except this page which doesn't say
>> much
>>>>>>>> than a stricter validation of POM :
>>>>>>>> 
>> 
> https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-StricterPOMValidation
>>>>>>>> But that right that in maven 2 we just ignored unknown scopes while
>> maven 3
>>>>>>>> throws a warning
>>>>>>>> 
>>>>>>>> Arnaud
>>>>>>>> 
>>>>>>>> On Mon, Jun 27, 2011 at 7:02 PM, Benson Margulies <
>> bimargul...@gmail.com>wrote:
>>>>>>>> 
>>>>>>>>> In looking at the tomcat plugin, I noticed that it depends on using
>> a
>>>>>>>>> custom scope, and there was commentary complaining that maven 3
>>>>>>>>> complains.
>>>>>>>>> 
>>>>>>>>> Is there a thread or a JIRA about this? I'm contemplating creating
>>>>>>>>> something like this of my own, and I'd like to know what trouble
> I'm
>>>>>>>>> getting myself into.
>>>>>>>>> 
>>>>>>>>> 
>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>>> 
>>>>>> 
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>>> 
>>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>>> 
>>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: dev-h...@maven.apache.org
>>> 

--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/


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

Reply via email to