I think I've been misunderstood. I am referring to the
element that can contain whatever is necessary for configuration.
Oh, I see, but...
If the site is generated through a plugin, then by all means, configure
the plugin.
... this issue is about site deployment, not site generation. And th
I think I've been misunderstood. I am referring to the
element that can contain whatever is necessary for configuration. If the
site is generated through a plugin, then by all means, configure the plugin.
See my first response.
Paul
On Sat, Mar 8, 2008 at 3:05 AM, Benjamin Bentmann <[EMAIL PROTE
Why does the configuration option require a bump in version?
The primary place for configurations regarding the build is the POM. A
new option means a change to the POM schema, a new schema means to bump the
version.
it is a perfect fit for 2.0.x as well.
Besides, you proposed to break the c
it gets bumped to 2.1
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> On Behalf Of Paul Benedict
> Sent: Friday, March 07, 2008 10:34 PM
> To: Maven Developers List
> Subject: Re: Comments / Ideas for MNG-3244
>
> I find it strange
Paul,
These suggestions mean it gets bumped to 2.1
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Paul Benedict
Sent: Friday, March 07, 2008 10:34 PM
To: Maven Developers List
Subject: Re: Comments / Ideas for MNG-3244
I find it strange that software
I find it strange that software would react differently simply because
someone upgraded the POM version. It should act differently if a different
setting is specified.
My recommendation is:
1) Solve it the correct way. Change the plugin/component to generate the
paths in the fashion intended. Allo
>It's ugly, but there is a workaround for this now in respecifying the
>URLs in the child POMs. It's a pain but it's not the end of the world
>and I'd say better than adding even more voodoo.
Most people would say this isn't an acceptable workaround.
>I would say that's the best way to go -
ey are in
> place).
>
> My 2c.
>
> Cheers,
> Brett
>
> --
> Brett Porter
> [EMAIL PROTECTED]
> http://blogs.exist.com/bporter/
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
>
On 04/03/2008, at 6:22 AM, Brian E. Fox wrote:
As I understand your proposal, the don't-append-marker would vanish
after
the first inheritance step, re-enabling the default behavior for all
descendant POMs?
You're right, it probably won't work that way. I was thinking the
behavior info wo
>As I understand your proposal, the don't-append-marker would vanish
after
>the first inheritance step, re-enabling the default behavior for all
>descendant POMs?
You're right, it probably won't work that way. I was thinking the
behavior info would be available throughout the inheritance proces
>Another question: How would the special don't-append-marker behave in
>context of multiple parent POMs? I'm not fully familar with the project
>builder but wouldn't the following sequence apply:
>- grandfather POM defines "url/##"
>- parent POM inherits "url/##" and fixes it to "url/"
>- child PO
>The docs at [0] got updated to say the artifact id will always be
appended,
>regardless of a trailing slash or not. Are there any other docs handing
>around from which people might be fooled?
Probably not, but we changed the docs because of this issue.
>Also note that this unconditional appendi
[...] as documented says that only urls ending in / will be inherited in
the normal way by appending the artifactid to the end of the url.
The docs at [0] got updated to say the artifact id will always be appended,
regardless of a trailing slash or not. Are there any other docs handing
around fr
MNG-3244 is one of the most popular issues in the queue for 2.0.9 (was
also in 2.0.8 but got bumped). The issue is that url inheritance as
documented says that only urls ending in / will be inherited in the
normal way by appending the artifactid to the end of the url. The
trouble is that fixing it
14 matches
Mail list logo
