2009/8/3 Benjamin Bentmann
> Brian Fox wrote:
>
> Perhaps what is needed is the addition of a
>> few more "resolution scope" tags that a plugin could ask for. I mean,
>> how many combinations aren't already covered by the existing scopes?
>> If it's small and adding one or two more might be easi
Ok, I count the following +1 votes:
Brett, Benjamin, Lukas, Brian, Olivier, Rahul, Jason, Arnaud, Hervé,
John and Dennis
and no negative votes so the vote passes. Welcome, Mark!
Jason, would you mind updating asf-authorization?
Cheers,
Brett
On 31/07/2009, at 4:16 AM, Dennis Lundberg wrote
Hi again,
After Brett sorted out some issues that got lost in the source-control
mess on my localhost, and I resolved a couple more stragglers that came
up as a result of testing out RC1, I think we're in better shape to
attempt a release again.
Before we do, I'd like to get as many eyes as
Brian Fox wrote:
Perhaps what is needed is the addition of a
few more "resolution scope" tags that a plugin could ask for. I mean,
how many combinations aren't already covered by the existing scopes?
If it's small and adding one or two more might be easier to support
and maintain than allowing a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Fox wrote:
>> Therefore I think that
>> the in Super-Pom caused some
>> trouble and confusion that you might not be aware of.
>
> It should use the version even if you invoke directly from the command
> line, if not, that's a separate bug.
To
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Brian,
> First question, wouldn't ${project.version} solve the use case of
> updating same versioned dependencies?
Nope. It would help in some of my business projects where
all artifacts get the same version when released, but
I already have a sim
I think the disconnect here is that the "resolution scope" != "specified scope"
That is to say if you ask for the runtime scope in a plugin, you get
more than things declared "runtime". We all know this intuitively but
it is confusing at times. Perhaps what is needed is the addition of a
few more
Brett Porter wrote:
>
> On 03/08/2009, at 11:23 AM, Vincent Siveton wrote:
>
>> 2009/8/3 Brett Porter :
>>> I would find that confusing. The filtering is automatic and is just as
>>> official...
>>
>> yes but it implies more work when you write doc...
>
> I am in favour of investing effort in wr
On 03/08/2009, at 11:23 AM, Vincent Siveton wrote:
2009/8/3 Brett Porter :
I would find that confusing. The filtering is automatic and is just
as
official...
yes but it implies more work when you write doc...
I am in favour of investing effort in writing the docs once to avoid
spending
2009/8/3 Brett Porter :
> I would find that confusing. The filtering is automatic and is just as
> official...
yes but it implies more work when you write doc...
Vincent
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
On 03/08/2009, at 11:15 AM, Vincent Siveton wrote:
Hi Brett,
2009/8/3 Brett Porter :
I'm not sure you guys are talking about the same thing :)
I hope
Vincent, he is pointing out that the config you have put into the
doc now
does not work (at least without a corresponding pluginManagement
Hi Brett,
2009/8/3 Brett Porter :
> I'm not sure you guys are talking about the same thing :)
I hope
> Vincent, he is pointing out that the config you have put into the doc now
> does not work (at least without a corresponding pluginManagement section).
> It's unclear from your response how you
On 03/08/2009, at 11:00 AM, Vincent Siveton wrote:
2009/8/3 Benjamin Bentmann :
Well, enabling the doc filtering is a one-time task and I wouldn't
say it's
for nothing. The problem I see with those version-less POM snippets
is that
users just use them as is, without further thought. Nobody i
2009/8/3 Benjamin Bentmann :
> Well, enabling the doc filtering is a one-time task and I wouldn't say it's
> for nothing. The problem I see with those version-less POM snippets is that
> users just use them as is, without further thought. Nobody is going to read
> each and every doc page, people do
Vincent Siveton wrote:
IMHO it will be an overhead for nothing...
Well, enabling the doc filtering is a one-time task and I wouldn't say
it's for nothing. The problem I see with those version-less POM snippets
is that users just use them as is, without further thought. Nobody is
going to re
Hi Benjamin,
2009/8/3 Benjamin Bentmann :
> Not locking down the plugin version is a bad practice but how can we expect
> users to abandon this habbit if not even the official docs show the proper
> plugin configuration? So how about filtering the document instead and use
> ${project.version}?
IM
>
>
>>
> Not locking down the plugin version is a bad practice but how can we expect
> users to abandon this habbit if not even the official docs show the proper
> plugin configuration? So how about filtering the document instead and use
> ${project.version}?
>
>
+1
I think itshould be good thing t
Hi Vincent,
Author: vsiveton
Date: Mon Aug 3 12:58:03 2009
New Revision: 800341
URL: http://svn.apache.org/viewvc?rev=800341&view=rev
Log:
MJAVADOC-248: Site 'Usage' page references 2.5 version of m-javadoc-p
o fix it
Modified: maven/plugins/trunk/maven-javadoc-plugin/src/site/apt/usage.apt
Barrie Treloar wrote:
I cant remember if this is already raised somewhere else, but there is
similar problem with the scope "test".
test means both testCompile and testRuntime (which themselves dont
exist) so things like dependency:analyze reports errors because that
level of granularity does no
19 matches
Mail list logo
