You probably want to check with Oleg as he fully implemented this with
plexus-cypher. Not sure where he put the Maven code but he can't point
you right direction if you want to piece it together.
On 11-Aug-08, at 7:55 PM, Maria Odea Ching (JIRA) wrote:
[ http://jira.codehaus.org/browse/
So that suggests that the only appropriate place to use inheritance for
the section would be in projects using a parent POM such that the
parent and these children are released at the same time. This way, I
*think*, the inherited SCM urls would be correct after the release, and
the new develop
I think that is the issue
On Mon, Aug 11, 2008 at 9:37 PM, David Jencks <[EMAIL PROTECTED]>wrote:
> Maybe I misunderstood what Benjamin is saying but I believe I've run into
> this also... IIUC the situation is that the plugin and its parent pom are in
> totally unrelated svn locations and _not_
Maybe I misunderstood what Benjamin is saying but I believe I've run
into this also... IIUC the situation is that the plugin and its parent
pom are in totally unrelated svn locations and _not_ including the svn
tag in the plugin results in _completely incorrect and meaningless_
scm info in
John,
Performance is a bit better, but in a multi-project reactor build, the source
jars are now all "wrong". None of the source ends up in the jars. Just
the "extra" things from the remote-resources.
Dan
On Friday 08 August 2008 6:52:07 pm John Casey wrote:
> Hi everyone,
>
> Well, I
It sounds more like problems in particular plugins. Restating the SCM
URL is a bad thing and we should make it so that it can be used
reliably. If certain plugins are not dealing with it correctly then
those need to be fixed soon.
On 11-Aug-08, at 11:41 AM, Benjamin Bentmann wrote:
Brian
Hi Jonh,
I've tried RC6 for my projects on Hudson and I get the above exception
for all projects. Building with RC6 from terminal works. Building with
2.0.9 or RC4 on Hudson also works.
Cheers,
Henrique
[INFO] [clean:clean]
[HUDSON] Archiving
/Users/hprange/.hudson/jobs/pas/workspace/trunk
Brian E. Fox wrote:
Seems fishy to me as well. We have inheritance for a reason.
Over at Mojo I suggested adding several times for the following
reason. Most of the time, a plugin inherits from a released parent whose
SCM URL points to its tag, say
repo/tags/parent-1
Now, running "mvn si
Seems fishy to me as well. We have inheritance for a reason.
-Original Message-
From: Vincent Siveton [mailto:[EMAIL PROTECTED]
Sent: Monday, August 11, 2008 1:53 PM
To: Maven Developers List
Subject: Re: element in plugin POMs
2008/8/11, Jason van Zyl <[EMAIL PROTECTED]>:
>
> On 11-Au
2008/8/11, Jason van Zyl <[EMAIL PROTECTED]>:
>
> On 11-Aug-08, at 10:29 AM, Vincent Siveton wrote:
>
>
> > 2008/8/11, Benjamin Bentmann <[EMAIL PROTECTED]>:
> >
> > > Hi,
> > >
> > > about 2/3 of the plugin POMs have a element, the others can
> > > apparently live well without. Maybe we could de
On 11-Aug-08, at 10:29 AM, Vincent Siveton wrote:
2008/8/11, Benjamin Bentmann <[EMAIL PROTECTED]>:
Hi,
about 2/3 of the plugin POMs have a element, the others can
apparently live well without. Maybe we could decide for one of these
approaches to have things consistent. How do we want to han
2008/8/11, Benjamin Bentmann <[EMAIL PROTECTED]>:
> Hi,
>
> about 2/3 of the plugin POMs have a element, the others can
> apparently live well without. Maybe we could decide for one of these
> approaches to have things consistent. How do we want to handle this, delete
> the SCM stuff from them or
Hi,
about 2/3 of the plugin POMs have a element, the others can
apparently live well without. Maybe we could decide for one of these
approaches to have things consistent. How do we want to handle this,
delete the SCM stuff from them or add it to all POMs? WDYT?
Benjamin
--
On 11-Aug-08, at 1:55 AM, Brett Porter wrote:
Hi,
The proposal in the "Versioning" thread brings us to having 3 main
development lines for Maven itself, and that has a couple of
consequences for how we develop that I wanted to explore separately
to see if we're on the same page. These ar
ok.
I hope will release the enforcer soon.
Too many users (ourself also) are waiting it.
Arnaud
On Mon, Aug 11, 2008 at 12:49 PM, Vincent Siveton <[EMAIL PROTECTED]
> wrote:
> Hi Arnaud,
>
>
> 2008/8/10 Arnaud HERITIER <[EMAIL PROTECTED]>:
> > Why are you locking it here instead in the parent po
Hi,
2008/8/10 Jochen Wiedmann <[EMAIL PROTECTED]>:
> Hi,
>
> I have attempted to use the javadocDirectory plugin of the
> maven-javadoc-plugin. In 2.4, this parameter is documented like this:
>
>Specifies the Javadoc ressources directory to be included in the
> Javadoc (i.e. package.html, imag
Hi Arnaud,
2008/8/10 Arnaud HERITIER <[EMAIL PROTECTED]>:
> Why are you locking it here instead in the parent pom ?
Benjamin already did it in r684360 but without deployed it [1]. I did
it this morning.
> I think it's a better practice to do it in an higher level ASAP to check
> that we don't f
Hi,
The proposal in the "Versioning" thread brings us to having 3 main
development lines for Maven itself, and that has a couple of
consequences for how we develop that I wanted to explore separately to
see if we're on the same page. These are my thoughts...
* Merging changes
- All 2.0.x
On 11/08/2008, at 3:23 PM, Jason van Zyl wrote:
So it looks like the general consensus is:
- Cut a 2.1.x branch from a 2.0.x tag (I saw 2.0.9 and 2.0.10 float
by as options)
- Call trunk 3.0-SNAPSHOT
We'll just bugfix 2.0.x. The 2.1.x branch will be the mediator
toward 3.0, and given t
Jason van Zyl wrote:
So it looks like the general consensus is:
- Cut a 2.1.x branch from a 2.0.x tag (I saw 2.0.9 and 2.0.10 float
by as options)
- Call trunk 3.0-SNAPSHOT
We'll just bugfix 2.0.x. The 2.1.x branch will be the mediator toward
3.0, and given the mediator exists we're a lo
20 matches
Mail list logo
