On 28 June 2011 14:38, Benson Margulies <bimargul...@gmail.com> wrote:
>>
>> 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.
>

I agree, but if you stick to the "cannot change the pom format" the
only thing you can just about do is introduce a new scope.

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