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

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

Reply via email to