Hi all.
As a side-note: the current "provided" scope is not transitive, which
IMHO doesn't make much sense. After all, if your environment magically
provides dependency A that assures you that it also provides dependency
B, then this should effectively mean that both A and B are provided. Or
yes i forgot about endorsed... it is definitely required... complicates
plugins that run in the same jvm though... eg jetty, surefire in no fork
mode, etc
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using s
true should get you the non-transitive.
hard to digest the rest of your post with my son pulling out of me ;-)
- 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 29 Jun 2011 1
On 06/27/2011 06:54 PM, Stephen Connolly wrote:
Critically missing from my PoV are:
Consider also 'endorsed' (a serious issue for EE projects especially):
http://jira.codehaus.org/browse/MNG-4752
Also some notes on a non-transitive compile scope: for NetBeans module development, module -> mod
On 28 June 2011 16:27, Benson Margulies wrote:
>>
>> 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.
>>
>
> Is this, "let's make this feature before we're willing to change the
> pom" or "let's never change the pom".
I would offer
alsoProvides
for the feature you propose.
On Tue, Jun 28, 2011 at 11:11 AM, Stephen Connolly
wrote:
> On 28 June 2011 14:38, Benson Margulies wrote:
>>>
>>> Because why should I have to always state that I'm using
>>> org.slf4j:log4j-over-slf4j and that it provides log4j:log4j
>
> 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.
>
Is this, "let's make this feature before we're willing to change the
pom" or "let's never change the pom".
---
On 28 June 2011 14:38, Benson Margulies 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
>
> 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
On 28 June 2011 14:01, Benson Margulies 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
> element?
>
>
>
>
>
>
>
> 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
element?
> So that when computing the dependency tree, we
On 28 June 2011 11:38, Stephen Connolly wrote:
> On 28 June 2011 11:31, Benson Margulies 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 ge
On 28 June 2011 11:31, Benson Margulies 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. Th
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
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. Th
Stan Devitt, Platform Group
- Original Message -
From: Jörg Schaible [mailto:joerg.schai...@scalaris.com]
Sent: Tuesday, June 28, 2011 02:40 AM
To: dev@maven.apache.org
Subject: Re: peri
Brett Porter wrote:
>
> On 28/06/2011, at 7:46 AM, Benson Margulies wrote:
>
>>
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 conc
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
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
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"
wrote:
> the wars are really side web apps that ar
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 provi
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
On 28 June 2011 00:15, Benson Margulies 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...
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*
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
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 :
> I don't have any pointer in mind except this page which doesn't say much
> than a str
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
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 in
28 matches
Mail list logo
