Re: How to support modelVersion > 4.0.0

[Brett Porter]

No. I wouldn't see any model or deployment changes occurring in 2.0.x.  
However, since the deploy plugin delegates to Maven's artifact  
mechanism in 2.1.0, it can do the extra adjustments itself if there  
were a new model version introduced.


- Brett

On 25/11/2008, at 6:51 PM, nicolas de loof wrote:


Does this mean maven 2.0.10+ will require a new plugin attached to
(pre)deploy phase to generate a 4.0.0 compatible POM ?

2008/11/25 Brett Porter <[EMAIL PROTECTED]>

I'm not sure even rolling in changes to support this in 2.0.11+  
answers the
question. We're still having trouble getting people up from 2.0.6  
type
versions, and we're still supporting Maven 1 clients. A forced  
upgrade, even

over time, seems impractical at this point.

A lot of good suggestions in this thread that I agree with, though.

Here is what I would propose:

1) start deploying artifactId-version-pom.xml to the repository as  
the
original, unmodified POM artifact alongside the 4.0.0 versioned POM  
file
2) continue deploying 4.0.0 versioned .pom files as we do now. We  
could
potentially strip these down to just a subset of the information  
that is

actually used by client tools today
3) use tools to produce those 4.0.0 POMs in the future (or repository
managers), much like the m2 -> m1 situation that is available today

These steps give us enough to start incrementing the modelVersion  
already,

and the code is already available in various places.

4) continue to map out a future where repository metadata is unified,
extensible, and business logic like transitive dependencies  
algorithms,
inheritence and interpolation are not wound into it, for new tools  
to take
advantage of. Probably use a new repository layout (even if the  
layout is
the same) as a hint to Maven for how to treat it so it can be  
cleaned up


This seems pretty much the direction everyone is headed, right?

- Brett


On 25/11/2008, at 5:08 AM, Shane Isbell wrote:

On Mon, Nov 24, 2008 at 12:00 AM, Gilles Scokart <[EMAIL PROTECTED]>

wrote:


A big +1.  Changing the published poms format is very impacting.   
Not

only for the maven client, but for all tools that are using the
repository as a server (ivy, buildr, maven proxies & repository
managers, etc...).




It may be impacting but these tools should be transforming poms to a
format
that they internally understand and need, not directly relying on  
the pom
format itself, as that design will make it nearly impossible to  
upgrade
versions.  For Java based clients, a lot of the transform work is  
already

done for them in maven-shared-model. They just need to create a
transformer
for transforming from the canonical format to their internal  
format. That

should give a start.

And none of this would occur overnight. For maven 2.0.x, it is not  
trivial
to make the changes. So this is more of a long-term thing that  
other tool

developers need to start putting some brain-cycles into.

Shane



--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to support modelVersion > 4.0.0

[nicolas de loof]

Does this mean maven 2.0.10+ will require a new plugin attached to
(pre)deploy phase to generate a 4.0.0 compatible POM ?

2008/11/25 Brett Porter <[EMAIL PROTECTED]>

> I'm not sure even rolling in changes to support this in 2.0.11+ answers the
> question. We're still having trouble getting people up from 2.0.6 type
> versions, and we're still supporting Maven 1 clients. A forced upgrade, even
> over time, seems impractical at this point.
>
> A lot of good suggestions in this thread that I agree with, though.
>
> Here is what I would propose:
>
> 1) start deploying artifactId-version-pom.xml to the repository as the
> original, unmodified POM artifact alongside the 4.0.0 versioned POM file
> 2) continue deploying 4.0.0 versioned .pom files as we do now. We could
> potentially strip these down to just a subset of the information that is
> actually used by client tools today
> 3) use tools to produce those 4.0.0 POMs in the future (or repository
> managers), much like the m2 -> m1 situation that is available today
>
> These steps give us enough to start incrementing the modelVersion already,
> and the code is already available in various places.
>
> 4) continue to map out a future where repository metadata is unified,
> extensible, and business logic like transitive dependencies algorithms,
> inheritence and interpolation are not wound into it, for new tools to take
> advantage of. Probably use a new repository layout (even if the layout is
> the same) as a hint to Maven for how to treat it so it can be cleaned up
>
> This seems pretty much the direction everyone is headed, right?
>
> - Brett
>
>
> On 25/11/2008, at 5:08 AM, Shane Isbell wrote:
>
>  On Mon, Nov 24, 2008 at 12:00 AM, Gilles Scokart <[EMAIL PROTECTED]>
>> wrote:
>>
>>
>>> A big +1.  Changing the published poms format is very impacting.  Not
>>> only for the maven client, but for all tools that are using the
>>> repository as a server (ivy, buildr, maven proxies & repository
>>> managers, etc...).
>>>
>>
>>
>> It may be impacting but these tools should be transforming poms to a
>> format
>> that they internally understand and need, not directly relying on the pom
>> format itself, as that design will make it nearly impossible to upgrade
>> versions.  For Java based clients, a lot of the transform work is already
>> done for them in maven-shared-model. They just need to create a
>> transformer
>> for transforming from the canonical format to their internal format. That
>> should give a start.
>>
>> And none of this would occur overnight. For maven 2.0.x, it is not trivial
>> to make the changes. So this is more of a long-term thing that other tool
>> developers need to start putting some brain-cycles into.
>>
>> Shane
>>
>
> --
> Brett Porter
> [EMAIL PROTECTED]
> http://blogs.exist.com/bporter/
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: How to support modelVersion > 4.0.0

[Brett Porter]

I'm not sure even rolling in changes to support this in 2.0.11+  
answers the question. We're still having trouble getting people up  
from 2.0.6 type versions, and we're still supporting Maven 1 clients.  
A forced upgrade, even over time, seems impractical at this point.


A lot of good suggestions in this thread that I agree with, though.

Here is what I would propose:

1) start deploying artifactId-version-pom.xml to the repository as the  
original, unmodified POM artifact alongside the 4.0.0 versioned POM file
2) continue deploying 4.0.0 versioned .pom files as we do now. We  
could potentially strip these down to just a subset of the information  
that is actually used by client tools today
3) use tools to produce those 4.0.0 POMs in the future (or repository  
managers), much like the m2 -> m1 situation that is available today


These steps give us enough to start incrementing the modelVersion  
already, and the code is already available in various places.


4) continue to map out a future where repository metadata is unified,  
extensible, and business logic like transitive dependencies  
algorithms, inheritence and interpolation are not wound into it, for  
new tools to take advantage of. Probably use a new repository layout  
(even if the layout is the same) as a hint to Maven for how to treat  
it so it can be cleaned up


This seems pretty much the direction everyone is headed, right?

- Brett

On 25/11/2008, at 5:08 AM, Shane Isbell wrote:

On Mon, Nov 24, 2008 at 12:00 AM, Gilles Scokart  
<[EMAIL PROTECTED]> wrote:




A big +1.  Changing the published poms format is very impacting.  Not
only for the maven client, but for all tools that are using the
repository as a server (ivy, buildr, maven proxies & repository
managers, etc...).



It may be impacting but these tools should be transforming poms to a  
format
that they internally understand and need, not directly relying on  
the pom
format itself, as that design will make it nearly impossible to  
upgrade
versions.  For Java based clients, a lot of the transform work is  
already
done for them in maven-shared-model. They just need to create a  
transformer
for transforming from the canonical format to their internal format.  
That

should give a start.

And none of this would occur overnight. For maven 2.0.x, it is not  
trivial
to make the changes. So this is more of a long-term thing that other  
tool

developers need to start putting some brain-cycles into.

Shane


--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: CI servers

[Barrie Treloar]

On Tue, Nov 25, 2008 at 3:43 PM, Brett Porter <[EMAIL PROTECTED]> wrote:
> Continuum already does this by retrieving the email address from the POM for
> the given SVN id in the developers section.

That would assume I've updated that section to include myself :)
I'm sure others forget too...

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Improve staging support in the release plugin

[Brett Porter]

It sounds like that would supercede the need for the stage plugin. If  
you can get that to work more efficiently than what it does now that'd  
be a good thing.


Even though most repository managers will support this functionality  
in fairly near future, I imagine we'll need a basic capability in  
Maven itself.


- Brett

On 25/11/2008, at 9:32 AM, Arnaud HERITIER wrote:


Hi guys,

 What do you think about this :
http://jira.codehaus.org/browse/MRELEASE-391
 Do you think I forgot something ?
 Does it make sense for you ?

--
..
Arnaud HERITIER
12 guidelines to boost your productivity with a Java software  
factory -

http://tinyurl.com/56s9tw
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...


--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

JUnitDoclet Question

[Kedra G Sims]

Hello, 
I am using JUnitDoclet, when it is executed on my .java files it only 
produces a skeleton of the test class. It automates all methods that are 
in that test class but the test statements were not generated. 
Does JUnitDoclet only produce the skeleton of a .java file, or does it 
produce a fully written test case?
Thanks,

Kedra G. Sims
Software Engineer
(256)542-4089

3145-15
WPC 
Integrated Defense Systems

Re: CI servers

[Brett Porter]

On 25/11/2008, at 3:12 AM, Arnaud HERITIER wrote:

Is there someone with required rigths who can stop notifications  
from unused

servers ?


I can send the notifications for the Continuum ones elsewhere if  
nobody is listening to them (feel free to object if you do). Just bear  
in mind they're currently providing useful information that the grid  
hasn't been (like the changes plugin ITs that are currently failing,  
as are the 2.0.x ITs). They get noisy when Apache's SVN goes down, but  
that's getting fixed and otherwise should only complain when something  
is actually broken.


You also missed listing ci.sonatype.org which is the only thing that  
seems to send notifications at the moment. AFAIK the grid wasn't  
considered "live" yet.


My feeling is no one really looks at the notifications at all,  
considering most of the stuff on the grid is pretty cloudy/thundery  
right now.


I'm still interested in running these builds separately to follow the  
effectiveness of Continuum, and to sanity check the builds from the  
grid.


- Brett


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: CI servers

[Brett Porter]

Continuum already does this by retrieving the email address from the  
POM for the given SVN id in the developers section.


On 25/11/2008, at 12:31 PM, Barrie Treloar wrote:

On Tue, Nov 25, 2008 at 6:45 AM, Brian E. Fox <[EMAIL PROTECTED] 
> wrote:

Not easily because the grid is working with several different svn's
where the userid's don't line up to a single domain for email. It  
only
works if the svn user=email which can be true for only one domain  
at a

time.


That feels like a new requirement for the CI servers.

For the apache SVN servers all users = apache domain email addresses.

In general, for SVN this doesn't have to be true (as a SVN user
doesn't = local user with email) but for apache it is.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: CI servers

[Barrie Treloar]

On Tue, Nov 25, 2008 at 6:45 AM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> Not easily because the grid is working with several different svn's
> where the userid's don't line up to a single domain for email. It only
> works if the svn user=email which can be true for only one domain at a
> time.

That feels like a new requirement for the CI servers.

For the apache SVN servers all users = apache domain email addresses.

In general, for SVN this doesn't have to be true (as a SVN user
doesn't = local user with email) but for apache it is.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Release plugin & lib

[Jason van Zyl]

On 24-Nov-08, at 1:04 PM, Arnaud HERITIER wrote:

Why didn't we store the maven-release-manager under shared and the  
plugin

under plugins ? Just to share the version used of SCM ?



Because they always got released together because they are so coupled.  
When you fix something in the plugin you inevitably have to go fix the  
release manager so there's no point in splitting them up. Leave them  
together because it wasn't fun having to release them separately before.



Arnaud

On Mon, Nov 24, 2008 at 6:08 PM, Arnaud HERITIER  
<[EMAIL PROTECTED]>wrote:



Hi

 Is it normal to have 3 lifecycles for the release plugin ?
 - The release plugin itself : 2.0-beta-9-SNAPSHOT in the trunk
 - The release library : 1.0-alpha-6-SNAPSHOT in the trunk
 - The release pom parent : 6-SNAPSHOT in the trunk

 But we have only one Jira : https://jira.codehaus.org/browse/ 
MRELEASE


 Is it just to show that we can handle various versions in a  
release or is

there a real need to have a separate lifecycle ?

Cheers,

--
..
Arnaud HERITIER
12 guidelines to boost your productivity with a Java software  
factory -

http://tinyurl.com/56s9tw
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...





--
..
Arnaud HERITIER
12 guidelines to boost your productivity with a Java software  
factory -

http://tinyurl.com/56s9tw
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...


Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--

A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.

  -- Jakob Burckhardt


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Release plugin & lib

[Brett Porter]

I'm not quite sure why the versions are different, I'd go more towards  
having one release cycle.


- Brett

On 25/11/2008, at 9:06 AM, Paul Gier wrote:

I agree with Arnaud.  If they had a shared release cycle it would  
make sense to group together the release manager with the plugin.   
But since all three parts are released separately, I think it would  
be better to move the plugin part to plugins and the manager to  
shared.


Arnaud HERITIER wrote:
Why didn't we store the maven-release-manager under shared and the  
plugin

under plugins ? Just to share the version used of SCM ?
Arnaud
On Mon, Nov 24, 2008 at 6:08 PM, Arnaud HERITIER  
<[EMAIL PROTECTED]>wrote:

Hi

 Is it normal to have 3 lifecycles for the release plugin ?
 - The release plugin itself : 2.0-beta-9-SNAPSHOT in the trunk
 - The release library : 1.0-alpha-6-SNAPSHOT in the trunk
 - The release pom parent : 6-SNAPSHOT in the trunk

 But we have only one Jira : https://jira.codehaus.org/browse/MRELEASE

 Is it just to show that we can handle various versions in a  
release or is

there a real need to have a separate lifecycle ?

Cheers,

--
..
Arnaud HERITIER
12 guidelines to boost your productivity with a Java software  
factory -

http://tinyurl.com/56s9tw
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: roll back 2.0.10 wagon to beta-2

[Brett Porter]

+1

On 25/11/2008, at 6:30 AM, Brian E. Fox wrote:


There are still issues with the scp wagon beta-3 that represent a
regression over 2.0.9. I'm thinking we should roll 2.0.x back to  
beta-2

now that there is 2.1.x for people to use. Does anyone have a strong
opinion on this? If we pull it back then 2.0.10 is ready to go.





--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Vote] invite Charlie Collins on Mojo to merge googlecode GWT plugins with Mojo one

[Brett Porter]

+1

On 25/11/2008, at 2:31 AM, nicolas de loof wrote:


Hi,
Charlie Collins, who created and maintain the gwt-maven project on
googlecode, would like to join Mojo to merge with the recently  
released Mojo
one. Both plugins share some goals but also have original features.  
Merging
them will avoid two equivalent plugins and provide a better tested,  
more

featured plugin.

[+1] Welcome Charlie
[ 0 ] Don't care
[ -1] I won't support this guy, cause ...


--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Vote] invite Charlie Collins on Mojo to merge googlecode GWT plugins with Mojo one

[Brett Porter]

what's with the cross posting to [EMAIL PROTECTED]

On 25/11/2008, at 2:31 AM, nicolas de loof wrote:


Hi,
Charlie Collins, who created and maintain the gwt-maven project on
googlecode, would like to join Mojo to merge with the recently  
released Mojo
one. Both plugins share some goals but also have original features.  
Merging
them will avoid two equivalent plugins and provide a better tested,  
more

featured plugin.

[+1] Welcome Charlie
[ 0 ] Don't care
[ -1] I won't support this guy, cause ...


--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Improve staging support in the release plugin

[Arnaud HERITIER]

Hi guys,

  What do you think about this :
http://jira.codehaus.org/browse/MRELEASE-391
  Do you think I forgot something ?
  Does it make sense for you ?

-- 
..
Arnaud HERITIER
12 guidelines to boost your productivity with a Java software factory -
http://tinyurl.com/56s9tw
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...

Re: Release plugin & lib

[Paul Gier]

I agree with Arnaud.  If they had a shared release cycle it would make sense to 
group together the release manager with the plugin.  But since all three parts 
are released separately, I think it would be better to move the plugin part to 
plugins and the manager to shared.


Arnaud HERITIER wrote:

Why didn't we store the maven-release-manager under shared and the plugin
under plugins ? Just to share the version used of SCM ?

Arnaud

On Mon, Nov 24, 2008 at 6:08 PM, Arnaud HERITIER <[EMAIL PROTECTED]>wrote:


Hi

  Is it normal to have 3 lifecycles for the release plugin ?
  - The release plugin itself : 2.0-beta-9-SNAPSHOT in the trunk
  - The release library : 1.0-alpha-6-SNAPSHOT in the trunk
  - The release pom parent : 6-SNAPSHOT in the trunk

  But we have only one Jira : https://jira.codehaus.org/browse/MRELEASE

  Is it just to show that we can handle various versions in a release or is
there a real need to have a separate lifecycle ?

Cheers,

--
..
Arnaud HERITIER
12 guidelines to boost your productivity with a Java software factory -
http://tinyurl.com/56s9tw
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...








-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: roll back 2.0.10 wagon to beta-3

[Brian E. Fox]

Ok yeah that's what I thought. I mean put it back to whatever 2.0.9 was
running

-Original Message-
From: John Casey [mailto:[EMAIL PROTECTED] 
Sent: Monday, November 24, 2008 3:44 PM
To: Maven Developers List
Subject: Re: roll back 2.0.10 wagon to beta-3

I think you'll have to roll back to beta-2 from beta-4. Beta-4 came out 
specifically to address major problems found in beta-3.

Brian E. Fox wrote:
> FWIW, I meant roll back to beta3 from beta4
> 
> -Original Message-
> From: Brian E. Fox [mailto:[EMAIL PROTECTED] 
> Sent: Monday, November 24, 2008 2:31 PM
> To: Maven Developers List
> Subject: roll back 2.0.10 wagon to beta-2
> 
> There are still issues with the scp wagon beta-3 that represent a
> regression over 2.0.9. I'm thinking we should roll 2.0.x back to
beta-2
> now that there is 2.1.x for people to use. Does anyone have a strong
> opinion on this? If we pull it back then 2.0.10 is ready to go. 
> 
>  
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Release plugin & lib

[Arnaud HERITIER]

Why didn't we store the maven-release-manager under shared and the plugin
under plugins ? Just to share the version used of SCM ?

Arnaud

On Mon, Nov 24, 2008 at 6:08 PM, Arnaud HERITIER <[EMAIL PROTECTED]>wrote:

> Hi
>
>   Is it normal to have 3 lifecycles for the release plugin ?
>   - The release plugin itself : 2.0-beta-9-SNAPSHOT in the trunk
>   - The release library : 1.0-alpha-6-SNAPSHOT in the trunk
>   - The release pom parent : 6-SNAPSHOT in the trunk
>
>   But we have only one Jira : https://jira.codehaus.org/browse/MRELEASE
>
>   Is it just to show that we can handle various versions in a release or is
> there a real need to have a separate lifecycle ?
>
> Cheers,
>
> --
> ..
> Arnaud HERITIER
> 12 guidelines to boost your productivity with a Java software factory -
> http://tinyurl.com/56s9tw
> ..
> OCTO Technology - aheritier AT octo DOT com
> www.octo.com | blog.octo.com
> ..
> ASF - aheritier AT apache DOT org
> www.apache.org | maven.apache.org
> ...
>



-- 
..
Arnaud HERITIER
12 guidelines to boost your productivity with a Java software factory -
http://tinyurl.com/56s9tw
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...

Re: svn commit: r720229 - /maven/release/trunk/maven-release-manager/pom.xml

[Arnaud HERITIER]

ok cool.
I'll fix it.

On Mon, Nov 24, 2008 at 7:10 PM, Olivier Lamy <[EMAIL PROTECTED]> wrote:

> Hi,
> We could replace all dependencies by the pom
> org.apache.maven.scm:maven-scm-providers-standard which include all
> scm providers.
>
> --
> Olivier
>
> 2008/11/24 Dennis Lundberg <[EMAIL PROTECTED]>:
> > [EMAIL PROTECTED] wrote:
> >> Author: aheritier
> >> Date: Mon Nov 24 09:02:03 2008
> >> New Revision: 720229
> >>
> >> URL: http://svn.apache.org/viewvc?rev=720229&view=rev
> >> Log:
> >> MRELEASE-390 : Add VSS dependency
> >> + Remove unused git-commons dependency
> >
> > Isn't maven-scm-provider-git-commons required by
> maven-scm-provider-gitexe?
> >
> > It's a runtime dependency, so there are probably not any direct
> > references to it in the code.
> >
> >>
> >> Modified:
> >> maven/release/trunk/maven-release-manager/pom.xml
> >>
> >> Modified: maven/release/trunk/maven-release-manager/pom.xml
> >> URL:
> http://svn.apache.org/viewvc/maven/release/trunk/maven-release-manager/pom.xml?rev=720229&r1=720228&r2=720229&view=diff
> >>
> ==
> >> --- maven/release/trunk/maven-release-manager/pom.xml (original)
> >> +++ maven/release/trunk/maven-release-manager/pom.xml Mon Nov 24
> 09:02:03 2008
> >> @@ -138,13 +138,7 @@
> >>maven-scm-provider-gitexe
> >>${scmVersion}
> >>runtime
> >> -
> >> -
> >> -  org.apache.maven.scm
> >> -  maven-scm-provider-git-commons
> >> -  ${scmVersion}
> >> -  runtime
> >> -
> >> +
> >>  
> >>org.apache.maven.scm
> >>maven-scm-provider-hg
> >> @@ -167,7 +161,7 @@
> >>org.apache.maven.scm
> >>maven-scm-provider-svn-commons
> >>${scmVersion}
> >> -
> >> +
> >>  
> >>org.apache.maven.scm
> >>maven-scm-provider-svnexe
> >> @@ -181,6 +175,12 @@
> >>runtime
> >>  
> >>  
> >> +  org.apache.maven.scm
> >> +  maven-scm-provider-vss
> >> +  ${scmVersion}
> >> +  runtime
> >> +
> >> +
> >>jdom
> >>jdom
> >>1.0
> >>
> >>
> >>
> >
> >
> > --
> > Dennis Lundberg
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
..
Arnaud HERITIER
12 guidelines to boost your productivity with a Java software factory -
http://tinyurl.com/56s9tw
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...

Re: svn commit: r720229 - /maven/release/trunk/maven-release-manager/pom.xml

[Arnaud HERITIER]

It's not a runtime dependency for gitexe thus we should take it as a
transitive dep :
http://svn.apache.org/repos/asf/maven/scm/trunk/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/pom.xml
I have to admit I don't realy understand why the code was split in several
modules for some SCMs which has actually only one provider. I think we add
complexity to early.

Arnaud

On Mon, Nov 24, 2008 at 6:47 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:

> [EMAIL PROTECTED] wrote:
> > Author: aheritier
> > Date: Mon Nov 24 09:02:03 2008
> > New Revision: 720229
> >
> > URL: http://svn.apache.org/viewvc?rev=720229&view=rev
> > Log:
> > MRELEASE-390 : Add VSS dependency
> > + Remove unused git-commons dependency
>
> Isn't maven-scm-provider-git-commons required by maven-scm-provider-gitexe?
>
> It's a runtime dependency, so there are probably not any direct
> references to it in the code.
>
> >
> > Modified:
> > maven/release/trunk/maven-release-manager/pom.xml
> >
> > Modified: maven/release/trunk/maven-release-manager/pom.xml
> > URL:
> http://svn.apache.org/viewvc/maven/release/trunk/maven-release-manager/pom.xml?rev=720229&r1=720228&r2=720229&view=diff
> >
> ==
> > --- maven/release/trunk/maven-release-manager/pom.xml (original)
> > +++ maven/release/trunk/maven-release-manager/pom.xml Mon Nov 24 09:02:03
> 2008
> > @@ -138,13 +138,7 @@
> >maven-scm-provider-gitexe
> >${scmVersion}
> >runtime
> > -
> > -
> > -  org.apache.maven.scm
> > -  maven-scm-provider-git-commons
> > -  ${scmVersion}
> > -  runtime
> > -
> > +
> >  
> >org.apache.maven.scm
> >maven-scm-provider-hg
> > @@ -167,7 +161,7 @@
> >org.apache.maven.scm
> >maven-scm-provider-svn-commons
> >${scmVersion}
> > -
> > +
> >  
> >org.apache.maven.scm
> >maven-scm-provider-svnexe
> > @@ -181,6 +175,12 @@
> >runtime
> >  
> >  
> > +  org.apache.maven.scm
> > +  maven-scm-provider-vss
> > +  ${scmVersion}
> > +  runtime
> > +
> > +
> >jdom
> >jdom
> >1.0
> >
> >
> >
>
>
> --
> Dennis Lundberg
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
..
Arnaud HERITIER
12 guidelines to boost your productivity with a Java software factory -
http://tinyurl.com/56s9tw
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...

Re: roll back 2.0.10 wagon to beta-3

[John Casey]

I think you'll have to roll back to beta-2 from beta-4. Beta-4 came out 
specifically to address major problems found in beta-3.


Brian E. Fox wrote:

FWIW, I meant roll back to beta3 from beta4

-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED] 
Sent: Monday, November 24, 2008 2:31 PM

To: Maven Developers List
Subject: roll back 2.0.10 wagon to beta-2

There are still issues with the scp wagon beta-3 that represent a
regression over 2.0.9. I'm thinking we should roll 2.0.x back to beta-2
now that there is 2.1.x for people to use. Does anyone have a strong
opinion on this? If we pull it back then 2.0.10 is ready to go. 

 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: CI servers

[Brian E. Fox]

Not easily because the grid is working with several different svn's
where the userid's don't line up to a single domain for email. It only
works if the svn user=email which can be true for only one domain at a
time.

-Original Message-
From: Barrie Treloar [mailto:[EMAIL PROTECTED] 
Sent: Monday, November 24, 2008 2:59 PM
To: Maven Developers List
Subject: Re: CI servers

On Tue, Nov 25, 2008 at 2:42 AM, Arnaud HERITIER <[EMAIL PROTECTED]>
wrote:
> Is there someone with required rigths who can stop notifications from
unused
> servers ?

And can it be setup to email the committer causing failures?
I'm not on the notification list because most of (read almost all) the
messages are not relevant to me.
But I definitely want to be notified when I break the build.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: CI servers

[Barrie Treloar]

On Tue, Nov 25, 2008 at 2:42 AM, Arnaud HERITIER <[EMAIL PROTECTED]> wrote:
> Is there someone with required rigths who can stop notifications from unused
> servers ?

And can it be setup to email the committer causing failures?
I'm not on the notification list because most of (read almost all) the
messages are not relevant to me.
But I definitely want to be notified when I break the build.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: roll back 2.0.10 wagon to beta-3

[Brian E. Fox]

FWIW, I meant roll back to beta3 from beta4

-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED] 
Sent: Monday, November 24, 2008 2:31 PM
To: Maven Developers List
Subject: roll back 2.0.10 wagon to beta-2

There are still issues with the scp wagon beta-3 that represent a
regression over 2.0.9. I'm thinking we should roll 2.0.x back to beta-2
now that there is 2.1.x for people to use. Does anyone have a strong
opinion on this? If we pull it back then 2.0.10 is ready to go. 

 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

roll back 2.0.10 wagon to beta-2

[Brian E. Fox]

There are still issues with the scp wagon beta-3 that represent a
regression over 2.0.9. I'm thinking we should roll 2.0.x back to beta-2
now that there is 2.1.x for people to use. Does anyone have a strong
opinion on this? If we pull it back then 2.0.10 is ready to go. 

 

Unable to find the mojo 'org.apache.maven.doxia:doxia-maven-plugin:1.0-beta-1-SNAPSHOT:render-books'

[Paul Spencer]

I just checked out and build doxia from the source, and I get the following 
stack trace from the goal doxia:render-books.  I do not get
then error with 1.0-alpha-11.

o The book is composed on 2 chapters with section of apt document
o apt documents contain only text bocks, not figures or links.
o excerpt of plugin configuration in pom is below.
o book.xml is below.


***
* Stack Trace
***

+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'doxia'.
[INFO] 
[INFO] Building Database Backup Scripts
[INFO]task-segment: [doxia:render-books]
[INFO] 
-
this realm = app0.child-container[org.apache.maven.doxia:doxia-maven-plugin]
urls[0] = file:/C:/Documents and 
Settings/paul/.m2/repository/org/apache/maven/doxia/doxia-maven-plugin/1.0-beta-1-SNAPSHOT/doxia-maven-plugin-1.0-beta-1-SNAPSHOT.jar
urls[1] = file:/C:/Documents and 
Settings/paul/.m2/repository/org/apache/maven/doxia/doxia-book/1.0-beta-1-SNAPSHOT/doxia-book-1.0-beta-1-SNAPSHOT.jar
urls[2] = file:/C:/Documents and 
Settings/paul/.m2/repository/org/apache/maven/doxia/doxia-core/1.0-beta-1-SNAPSHOT/doxia-core-1.0-beta-1-SNAPSHOT.jar
urls[3] = file:/C:/Documents and 
Settings/paul/.m2/repository/org/apache/maven/doxia/doxia-logging-api/1.0-beta-1-SNAPSHOT/doxia-logging-api-1.0-beta-1-SNAPSHOT.jar
urls[4] = file:/C:/Documents and 
Settings/paul/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.6/plexus-utils-1.5.6.jar
urls[5] = file:/C:/Documents and 
Settings/paul/.m2/repository/xerces/xercesImpl/2.8.1/xercesImpl-2.8.1.jar
urls[6] = file:/C:/Documents and 
Settings/paul/.m2/repository/xml-apis/xml-apis/1.3.03/xml-apis-1.3.03.jar
urls[7] = file:/C:/Documents and 
Settings/paul/.m2/repository/org/apache/maven/doxia/doxia-module-xdoc/1.0-beta-1-SNAPSHOT/doxia-module-xdoc-1.0-beta-1-SNAPSHOT.jar
urls[8] = file:/C:/Documents and 
Settings/paul/.m2/repository/org/apache/maven/doxia/doxia-module-xhtml/1.0-beta-1-SNAPSHOT/doxia-module-xhtml-1.0-beta-1-SNAPSHOT.jar
urls[9] = file:/C:/Documents and 
Settings/paul/.m2/repository/org/apache/maven/doxia/doxia-module-apt/1.0-beta-1-SNAPSHOT/doxia-module-apt-1.0-beta-1-SNAPSHOT.jar
urls[10] = file:/C:/Documents and 
Settings/paul/.m2/repository/org/apache/maven/doxia/doxia-module-itext/1.0-beta-1-SNAPSHOT/doxia-module-itext-1.0-beta-1-SNAPSHOT.jar
urls[11] = file:/C:/Documents and 
Settings/paul/.m2/repository/com/lowagie/itext/1.4/itext-1.4.jar
urls[12] = file:/C:/Documents and 
Settings/paul/.m2/repository/org/apache/maven/doxia/doxia-module-latex/1.0-beta-1-SNAPSHOT/doxia-module-latex-1.0-beta-1-SNAPSHOT.jar
urls[13] = file:/C:/Documents and 
Settings/paul/.m2/repository/org/apache/maven/doxia/doxia-module-docbook-simple/1.0-beta-1-SNAPSHOT/doxia-module-docbook-simple-1.0-beta-1-SNAPSHOT.jar
urls[14] = file:/C:/Documents and 
Settings/paul/.m2/repository/org/codehaus/plexus/plexus-i18n/1.0-beta-6/plexus-i18n-1.0-beta-6.jar
urls[15] = file:/C:/Documents and 
Settings/paul/.m2/repository/org/codehaus/plexus/plexus-cli/1.0/plexus-cli-1.0.jar
Number of imports: 6
import: [EMAIL PROTECTED]
import: [EMAIL PROTECTED]
import: [EMAIL PROTECTED]
import: [EMAIL PROTECTED]
import: [EMAIL PROTECTED]
import: [EMAIL PROTECTED]


this realm = plexus.core
urls[0] = file:/c:/apache/apache-maven-2.0.9/lib/maven-2.0.9-uber.jar
Number of imports: 6
import: [EMAIL PROTECTED]
import: [EMAIL PROTECTED]
import: [EMAIL PROTECTED]
import: [EMAIL PROTECTED]
import: [EMAIL PROTECTED]
import: [EMAIL PROTECTED]
-
[INFO] 
[ERROR] BUILD ERROR
[INFO] 
[INFO] Internal error in the plugin manager executing goal 
'org.apache.maven.doxia:doxia-maven-plugin:1.0-beta-1-SNAPSHOT:render-books': 
Unable to find the mojo 
'org.apache.maven.doxia:doxia-maven-plugin:1.0-beta-1-SNAPSHOT:render-books' in 
the plugi
n 'org.apache.maven.doxia:doxia-maven-plugin'
org/apache/maven/doxia/sink/SinkEventAttributes
[INFO] 
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the 
plugin manager executing goal 
'org.apache.maven.doxia:doxia-maven-plugin:1.0-beta-1-SNAPSHOT:render-books': 
Unable to find the mojo 'org.apache.maven.doxia:doxia-maven-plug
in:1.0-beta-1-SNAPSHOT:render-books' in the plugin 
'org.apache.maven.doxia:doxia-maven-plugin'
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:562)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
at 
org.apache.maven.lifecyc

Re: [Vote] invite Charlie Collins on Mojo to merge googlecode GWT plugins with Mojo one

[Jesse McConnell]

+1 certainly

--
jesse mcconnell
[EMAIL PROTECTED]


On Mon, Nov 24, 2008 at 10:33 AM, Jamie Whitehouse <
[EMAIL PROTECTED]> wrote:

> On Mon, 2008-11-24 at 16:31 +0100, nicolas de loof wrote:
>
> > Hi,
> > Charlie Collins, who created and maintain the gwt-maven project on
> > googlecode, would like to join Mojo to merge with the recently released
> Mojo
> > one. Both plugins share some goals but also have original features.
> Merging
> > them will avoid two equivalent plugins and provide a better tested, more
> > featured plugin.
> >
> > [+1] Welcome Charlie
> > [ 0 ] Don't care
> > [ -1] I won't support this guy, cause ...
>
> +1 (opinion only); this is a very welcome addition!
>
>
>
> ---
> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
> confidential and proprietary information of Alcatel-Lucent and/or its
> affiliated entities. Access by the intended recipient only is authorized.
> Any liability arising from any party acting, or refraining from acting, on
> any information contained in this e-mail is hereby excluded. If you are not
> the intended recipient, please notify the sender immediately, destroy the
> original transmission and its attachments and do not disclose the contents
> to any other person, use it for any purpose, or store or copy the
> information in any medium. Copyright in this e-mail and any attachments
> belongs to Alcatel-Lucent and/or its affiliated entities.
>
>

Re: svn commit: r720229 - /maven/release/trunk/maven-release-manager/pom.xml

[Olivier Lamy]

Hi,
We could replace all dependencies by the pom
org.apache.maven.scm:maven-scm-providers-standard which include all
scm providers.

--
Olivier

2008/11/24 Dennis Lundberg <[EMAIL PROTECTED]>:
> [EMAIL PROTECTED] wrote:
>> Author: aheritier
>> Date: Mon Nov 24 09:02:03 2008
>> New Revision: 720229
>>
>> URL: http://svn.apache.org/viewvc?rev=720229&view=rev
>> Log:
>> MRELEASE-390 : Add VSS dependency
>> + Remove unused git-commons dependency
>
> Isn't maven-scm-provider-git-commons required by maven-scm-provider-gitexe?
>
> It's a runtime dependency, so there are probably not any direct
> references to it in the code.
>
>>
>> Modified:
>> maven/release/trunk/maven-release-manager/pom.xml
>>
>> Modified: maven/release/trunk/maven-release-manager/pom.xml
>> URL: 
>> http://svn.apache.org/viewvc/maven/release/trunk/maven-release-manager/pom.xml?rev=720229&r1=720228&r2=720229&view=diff
>> ==
>> --- maven/release/trunk/maven-release-manager/pom.xml (original)
>> +++ maven/release/trunk/maven-release-manager/pom.xml Mon Nov 24 09:02:03 
>> 2008
>> @@ -138,13 +138,7 @@
>>maven-scm-provider-gitexe
>>${scmVersion}
>>runtime
>> -
>> -
>> -  org.apache.maven.scm
>> -  maven-scm-provider-git-commons
>> -  ${scmVersion}
>> -  runtime
>> -
>> +
>>  
>>org.apache.maven.scm
>>maven-scm-provider-hg
>> @@ -167,7 +161,7 @@
>>org.apache.maven.scm
>>maven-scm-provider-svn-commons
>>${scmVersion}
>> -
>> +
>>  
>>org.apache.maven.scm
>>maven-scm-provider-svnexe
>> @@ -181,6 +175,12 @@
>>runtime
>>  
>>  
>> +  org.apache.maven.scm
>> +  maven-scm-provider-vss
>> +  ${scmVersion}
>> +  runtime
>> +
>> +
>>jdom
>>jdom
>>1.0
>>
>>
>>
>
>
> --
> Dennis Lundberg
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to support modelVersion > 4.0.0

[Shane Isbell]

On Mon, Nov 24, 2008 at 12:00 AM, Gilles Scokart <[EMAIL PROTECTED]> wrote:

>
> A big +1.  Changing the published poms format is very impacting.  Not
> only for the maven client, but for all tools that are using the
> repository as a server (ivy, buildr, maven proxies & repository
> managers, etc...).


It may be impacting but these tools should be transforming poms to a format
that they internally understand and need, not directly relying on the pom
format itself, as that design will make it nearly impossible to upgrade
versions.  For Java based clients, a lot of the transform work is already
done for them in maven-shared-model. They just need to create a transformer
for transforming from the canonical format to their internal format. That
should give a start.

And none of this would occur overnight. For maven 2.0.x, it is not trivial
to make the changes. So this is more of a long-term thing that other tool
developers need to start putting some brain-cycles into.

Shane

Re: svn commit: r720229 - /maven/release/trunk/maven-release-manager/pom.xml

[Dennis Lundberg]

[EMAIL PROTECTED] wrote:
> Author: aheritier
> Date: Mon Nov 24 09:02:03 2008
> New Revision: 720229
> 
> URL: http://svn.apache.org/viewvc?rev=720229&view=rev
> Log:
> MRELEASE-390 : Add VSS dependency
> + Remove unused git-commons dependency

Isn't maven-scm-provider-git-commons required by maven-scm-provider-gitexe?

It's a runtime dependency, so there are probably not any direct
references to it in the code.

> 
> Modified:
> maven/release/trunk/maven-release-manager/pom.xml
> 
> Modified: maven/release/trunk/maven-release-manager/pom.xml
> URL: 
> http://svn.apache.org/viewvc/maven/release/trunk/maven-release-manager/pom.xml?rev=720229&r1=720228&r2=720229&view=diff
> ==
> --- maven/release/trunk/maven-release-manager/pom.xml (original)
> +++ maven/release/trunk/maven-release-manager/pom.xml Mon Nov 24 09:02:03 2008
> @@ -138,13 +138,7 @@
>maven-scm-provider-gitexe
>${scmVersion}
>runtime
> -
> -
> -  org.apache.maven.scm
> -  maven-scm-provider-git-commons
> -  ${scmVersion}
> -  runtime
> -
> + 
>  
>org.apache.maven.scm
>maven-scm-provider-hg
> @@ -167,7 +161,7 @@
>org.apache.maven.scm
>maven-scm-provider-svn-commons
>${scmVersion}
> -
> +
>  
>org.apache.maven.scm
>maven-scm-provider-svnexe
> @@ -181,6 +175,12 @@
>runtime
>  
>  
> +  org.apache.maven.scm
> +  maven-scm-provider-vss
> +  ${scmVersion}
> +  runtime
> +
> +
>jdom
>jdom
>1.0
> 
> 
> 


-- 
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Release plugin & lib

[Arnaud HERITIER]

Hi

  Is it normal to have 3 lifecycles for the release plugin ?
  - The release plugin itself : 2.0-beta-9-SNAPSHOT in the trunk
  - The release library : 1.0-alpha-6-SNAPSHOT in the trunk
  - The release pom parent : 6-SNAPSHOT in the trunk

  But we have only one Jira : https://jira.codehaus.org/browse/MRELEASE

  Is it just to show that we can handle various versions in a release or is
there a real need to have a separate lifecycle ?

Cheers,

-- 
..
Arnaud HERITIER
12 guidelines to boost your productivity with a Java software factory -
http://tinyurl.com/56s9tw
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...

Re: [Vote] invite Charlie Collins on Mojo to merge googlecode GWT plugins with Mojo one

[Jamie Whitehouse]

On Mon, 2008-11-24 at 16:31 +0100, nicolas de loof wrote:

> Hi,
> Charlie Collins, who created and maintain the gwt-maven project on
> googlecode, would like to join Mojo to merge with the recently released Mojo
> one. Both plugins share some goals but also have original features. Merging
> them will avoid two equivalent plugins and provide a better tested, more
> featured plugin.
> 
> [+1] Welcome Charlie
> [ 0 ] Don't care
> [ -1] I won't support this guy, cause ...

+1 (opinion only); this is a very welcome addition!


---
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain 
confidential and proprietary information of Alcatel-Lucent and/or its 
affiliated entities. Access by the intended recipient only is authorized. Any 
liability arising from any party acting, or refraining from acting, on any 
information contained in this e-mail is hereby excluded. If you are not the 
intended recipient, please notify the sender immediately, destroy the original 
transmission and its attachments and do not disclose the contents to any other 
person, use it for any purpose, or store or copy the information in any medium. 
Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or 
its affiliated entities.

Re: CI servers

[Arnaud HERITIER]

Is there someone with required rigths who can stop notifications from unused
servers ?

Arnaud

On Mon, Nov 24, 2008 at 4:43 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:

>
> On 24-Nov-08, at 3:10 AM, Arnaud HERITIER wrote:
>
>  Hi just noticed we have now 3 CI servers :
>>
>> http://vmbuild.apache.org/continuum : Continuum @ Apache
>>
>
> I don't look at this.
>
>
>> http://hudson.zones.apache.org/hudson/view/Maven/ : Hudson @ Apache
>>
>
> This one can definitely be taken down. I'll take all the jobs out of there.
> I put some jobs in there before the grid instance was up.
>
>
>> https://grid.sonatype.org/ : Hudson @ Sonatype
>>
>>
> This is the only one that has a chance of providing useful information
> given we have most of the platforms covered.
>
>  Isn't it a little bit to much ??
>>
>> Do you follow notifications ?
>> Are they reporting the same issues ?
>>
>> ..
>> Arnaud HERITIER
>> 12 guidelines to boost your productivity with a Java software factory -
>> http://tinyurl.com/56s9tw
>> ..
>> OCTO Technology - aheritier AT octo DOT com
>> www.octo.com | blog.octo.com
>> ..
>> ASF - aheritier AT apache DOT org
>> www.apache.org | maven.apache.org
>> ...
>>
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> jason at sonatype dot com
> --
>
> believe nothing, no matter where you read it,
> or who has said it,
> not even if i have said it,
> unless it agrees with your own reason
> and your own common sense.
>
>  -- Buddha
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
..
Arnaud HERITIER
12 guidelines to boost your productivity with a Java software factory -
http://tinyurl.com/56s9tw
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...

Re: [mojo-dev] [Vote] invite Charlie Collins on Mojo to merge googlecode GWT plugins with Mojo one

[david]

On Mon, 24 Nov 2008, nicolas de loof wrote:


Hi,
Charlie Collins, who created and maintain the gwt-maven project on
googlecode, would like to join Mojo to merge with the recently released Mojo
one. Both plugins share some goals but also have original features. Merging
them will avoid two equivalent plugins and provide a better tested, more
featured plugin.

[+1] Welcome Charlie
[ 0 ] Don't care
[ -1] I won't support this guy, cause ...



Great - I've used both - so this seems very promising!
+1 - welcome onboard Charlie!

--
David J. M. Karlsen - +47 90 68 22 43
http://www.davidkarlsen.com
http://mp3.davidkarlsen.com

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Vote] invite Charlie Collins on Mojo to merge googlecode GWT plugins with Mojo one

[Jason van Zyl]

+1

On 24-Nov-08, at 7:31 AM, nicolas de loof wrote:


Hi,
Charlie Collins, who created and maintain the gwt-maven project on
googlecode, would like to join Mojo to merge with the recently  
released Mojo
one. Both plugins share some goals but also have original features.  
Merging
them will avoid two equivalent plugins and provide a better tested,  
more

featured plugin.

[+1] Welcome Charlie
[ 0 ] Don't care
[ -1] I won't support this guy, cause ...


Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--

Three people can keep a secret provided two of them are dead.

 -- Unknown


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: CI servers

[Jason van Zyl]

On 24-Nov-08, at 3:10 AM, Arnaud HERITIER wrote:


Hi just noticed we have now 3 CI servers :

http://vmbuild.apache.org/continuum : Continuum @ Apache


I don't look at this.



http://hudson.zones.apache.org/hudson/view/Maven/ : Hudson @ Apache


This one can definitely be taken down. I'll take all the jobs out of  
there. I put some jobs in there before the grid instance was up.




https://grid.sonatype.org/ : Hudson @ Sonatype



This is the only one that has a chance of providing useful information  
given we have most of the platforms covered.



Isn't it a little bit to much ??

Do you follow notifications ?
Are they reporting the same issues ?

..
Arnaud HERITIER
12 guidelines to boost your productivity with a Java software  
factory -

http://tinyurl.com/56s9tw
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...


Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--

believe nothing, no matter where you read it,
or who has said it,
not even if i have said it,
unless it agrees with your own reason
and your own common sense.

 -- Buddha


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [mojo-dev] [Vote] invite Charlie Collins on Mojo to merge googlecode GWT plugins with Mojo one

[Arnaud HERITIER]

+1

Arnaud

On Mon, Nov 24, 2008 at 4:31 PM, nicolas de loof <[EMAIL PROTECTED]> wrote:

> Hi,
> Charlie Collins, who created and maintain the gwt-maven project on
> googlecode, would like to join Mojo to merge with the recently released Mojo
> one. Both plugins share some goals but also have original features. Merging
> them will avoid two equivalent plugins and provide a better tested, more
> featured plugin.
>
> [+1] Welcome Charlie
> [ 0 ] Don't care
> [ -1] I won't support this guy, cause ...
>
>
>


-- 
..
Arnaud HERITIER
12 guidelines to boost your productivity with a Java software factory -
http://tinyurl.com/56s9tw
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...

[Vote] invite Charlie Collins on Mojo to merge googlecode GWT plugins with Mojo one

[nicolas de loof]

Hi,
Charlie Collins, who created and maintain the gwt-maven project on
googlecode, would like to join Mojo to merge with the recently released Mojo
one. Both plugins share some goals but also have original features. Merging
them will avoid two equivalent plugins and provide a better tested, more
featured plugin.

[+1] Welcome Charlie
[ 0 ] Don't care
[ -1] I won't support this guy, cause ...

Re: [Fwd: Problem Eclipse-Plugin v2.5.1 while create MyEclipse EJB project]

[Arnaud HERITIER]

Please open an issue here
http://jira.codehaus.org/browse/MECLIPSE

Without it we'll certainly forgot your patch.
It will help if you deliver also an integration test with a maven project
and what you expect in eclipse config files.

Arnaud


On Mon, Nov 24, 2008 at 12:11 PM, Marcus Padberg <[EMAIL PROTECTED]
> wrote:

>
> --
> DCO GmbH
> Stockholmer Alle 30c
> 44269 Dortmund
>
> Fon: +(49) 231 477766-60
> Fax: +(49) 231 477766-80
>
> Geschäftsführer: Uwe Falkenberg, Walter Dilba
> Eingetragen Amtsgericht Dortmund HRB 21208
> USt.-ID: DE 256 202 508
>
>
> Hello,
>
> we evaluating MyEclipse (v6.5) as our new development tool. Actual we found
> a problem while creating a EJB project. If we try it some required
> parameters in .mymetadata are missing. Please add this to the next version
> of MyEclipseMetadataWriter.write() at line 103 to generate right code:
>
>   if ( Constants.PROJECT_PACKAGING_EJB.equalsIgnoreCase( packaging ) )
>   {
>   writer.addAttribute( MYECLIPSE_METADATA_PROJECT_J2EE_SPEC,
> getJeeVersion() );
>   // TODO : use maven final name
>   writer.addAttribute( MYECLIPSE_METADATA_PROJECT_ARCHIVE,
> config.getEclipseProjectName() + ".jar" );
>   }
>
> Best regards
> Marcus Padberg
>
> P.S.
> Attached our POM and a modified MyEclipseMetadataWriter which works fine.
>
> --
> DCO GmbH
> Stockholmer Alle 30c
> 44269 Dortmund
>
> Fon: +(49) 231 477766-60
> Fax: +(49) 231 477766-80
>
> Geschäftsführer: Uwe Falkenberg, Walter Dilba
> Eingetragen Amtsgericht Dortmund HRB 21208
> USt.-ID: DE 256 202 508
>
>
> package org.apache.maven.plugin.eclipse.writers.myeclipse;
>
> import java.io.File;
> import java.io.FileWriter;
> import java.io.IOException;
>
> import org.apache.maven.plugin.MojoExecutionException;
> import org.apache.maven.plugin.eclipse.Constants;
> import org.apache.maven.plugin.eclipse.Messages;
> import org.apache.maven.plugin.eclipse.writers.AbstractEclipseWriter;
> import org.apache.maven.plugin.ide.IdeUtils;
> import org.apache.maven.plugin.ide.JeeDescriptor;
> import org.apache.maven.plugin.ide.JeeUtils;
> import org.codehaus.plexus.util.IOUtil;
> import org.codehaus.plexus.util.xml.PrettyPrintXMLWriter;
> import org.codehaus.plexus.util.xml.XMLWriter;
>
> /**
>  * MyEclipse .mymetadata configuration file writer
>  *
>  * @author Olivier Jacob
>  */
> public class MyEclipseMetadataWriter
>extends AbstractEclipseWriter
> {
>
>private static final String MYECLIPSE_MYMETADATA_FILENAME =
> ".mymetadata";
>
>private static final String MYECLIPSE_METADATA_PROJECT =
> "project-module";
>
>private static final String MYECLIPSE_METADATA_PROJECT_TYPE = "type";
>
>private static final String MYECLIPSE_METADATA_PROJECT_NAME = "name";
>
>private static final String MYECLIPSE_METADATA_PROJECT_ID = "id";
>
>private static final String MYECLIPSE_METADATA_PROJECT_CONTEXT_ROOT =
> "context-root";
>
>private static final String MYECLIPSE_METADATA_PROJECT_J2EE_SPEC =
> "j2ee-spec";
>
>private static final String MYECLIPSE_METADATA_PROJECT_ARCHIVE =
> "archive";
>
>private static final String MYECLIPSE_METADATA_PROJECT_TYPE_WAR = "WEB";
>
>private static final String MYECLIPSE_METADATA_PROJECT_TYPE_EAR = "EAR";
>
>private static final String MYECLIPSE_METADATA_PROJECT_TYPE_EJB = "EJB";
>
>private static final String MYECLIPSE_METADATA_PROJECT_ATTRIBUTES =
> "attributes";
>
>private static final String MYECLIPSE_METADATA_PROJECT_ATTRIBUTE =
> "attribute";
>
>/**
> * Writer entry point
> *
> * @throws MojoExecutionException
> */
>public void write()
>throws MojoExecutionException
>{
>String packaging = config.getProject().getPackaging();
>
>if ( !Constants.PROJECT_PACKAGING_EAR.equalsIgnoreCase( packaging )
> &&
>!Constants.PROJECT_PACKAGING_WAR.equalsIgnoreCase( packaging )
> &&
>!Constants.PROJECT_PACKAGING_EJB.equalsIgnoreCase( packaging ) )
>{
>return;
>}
>
>FileWriter w;
>
>try
>{
>w = new FileWriter( new File(
> config.getEclipseProjectDirectory(), MYECLIPSE_MYMETADATA_FILENAME ) );
>}
>catch ( IOException ex )
>{
>throw new MojoExecutionException( Messages.getString(
> "EclipsePlugin.erroropeningfile" ), ex ); //$NON-NLS-1$
>}
>
>XMLWriter writer = new PrettyPrintXMLWriter( w, "UTF-8", null );
>
>writer.startElement( MYECLIPSE_METADATA_PROJECT );
>writer.addAttribute( MYECLIPSE_METADATA_PROJECT_TYPE,
> getMyEclipseProjectType( packaging ) );
>writer.addAttribute( MYECLIPSE_METADATA_PROJECT_NAME,
> config.getEclipseProjectName() );
>writer.addAttribute( MYECLIPSE_METADATA_PROJECT_ID,
> config.getEclipseProjectName() );
>
>if ( Constants.PROJECT_PACKAGING_WAR.equalsIgnoreCase( packaging ) )
>{
>// Find web application context root from maven-war-plugin
> configura

[Fwd: Problem Eclipse-Plugin v2.5.1 while create MyEclipse EJB project]

[Marcus Padberg]

--
DCO GmbH
Stockholmer Alle 30c
44269 Dortmund

Fon: +(49) 231 477766-60
Fax: +(49) 231 477766-80

Geschäftsführer: Uwe Falkenberg, Walter Dilba
Eingetragen Amtsgericht Dortmund HRB 21208
USt.-ID: DE 256 202 508

--- Begin Message ---

Hello,

we evaluating MyEclipse (v6.5) as our new development tool. Actual we 
found a problem while creating a EJB project. If we try it some required 
parameters in .mymetadata are missing. Please add this to the next 
version of MyEclipseMetadataWriter.write() at line 103 to generate right 
code:


   if ( Constants.PROJECT_PACKAGING_EJB.equalsIgnoreCase( packaging ) )
   {
   writer.addAttribute( MYECLIPSE_METADATA_PROJECT_J2EE_SPEC, 
getJeeVersion() );

   // TODO : use maven final name
   writer.addAttribute( MYECLIPSE_METADATA_PROJECT_ARCHIVE, 
config.getEclipseProjectName() + ".jar" );

   }

Best regards
Marcus Padberg

P.S.
Attached our POM and a modified MyEclipseMetadataWriter which works fine.

--
DCO GmbH
Stockholmer Alle 30c
44269 Dortmund

Fon: +(49) 231 477766-60
Fax: +(49) 231 477766-80

Geschäftsführer: Uwe Falkenberg, Walter Dilba
Eingetragen Amtsgericht Dortmund HRB 21208
USt.-ID: DE 256 202 508

http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";>
  4.0.0
  de.dco
  cactus-project-ejb
  ejb
  cactus-project-ejb

  
de.dco
cactus-project
1.0-SNAPSHOT
  
  
  

  junit
  junit
  3.8.1
  test



  org.apache.openejb
  javaee-api
  5.0-1
  provided
  
  
  
  

  
org.apache.maven.plugins
maven-ejb-plugin

  3.0
  true
  

  true

   

  
  
org.apache.maven.plugins
maven-eclipse-plugin

  
com.genuitec.eclipse.j2eedt.core.ejbnature
org.eclipse.dali.core.persistenceNature
org.eclipse.jdt.core.javanature
  
  
org.eclipse.jdt.core.javabuilder
com.genuitec.eclipse.j2eedt.core.DeploymentDescriptorValidator
org.eclipse.dali.core.persistenceBuilder
org.eclipse.wst.validation.validationbuilder
  
  
org.eclipse.jdt.launching.JRE_CONTAINER
melibrary.com.genuitec.eclipse.j2eedt.core.MYECLIPSE_JAVAEE_5_CONTAINER
  

  

  

package org.apache.maven.plugin.eclipse.writers.myeclipse;

import java.io.File;
import java.io.FileWriter;
import java.io.IOException;

import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.plugin.eclipse.Constants;
import org.apache.maven.plugin.eclipse.Messages;
import org.apache.maven.plugin.eclipse.writers.AbstractEclipseWriter;
import org.apache.maven.plugin.ide.IdeUtils;
import org.apache.maven.plugin.ide.JeeDescriptor;
import org.apache.maven.plugin.ide.JeeUtils;
import org.codehaus.plexus.util.IOUtil;
import org.codehaus.plexus.util.xml.PrettyPrintXMLWriter;
import org.codehaus.plexus.util.xml.XMLWriter;

/**
 * MyEclipse .mymetadata configuration file writer
 * 
 * @author Olivier Jacob
 */
public class MyEclipseMetadataWriter
extends AbstractEclipseWriter
{

private static final String MYECLIPSE_MYMETADATA_FILENAME = ".mymetadata";

private static final String MYECLIPSE_METADATA_PROJECT = "project-module";

private static final String MYECLIPSE_METADATA_PROJECT_TYPE = "type";

private static final String MYECLIPSE_METADATA_PROJECT_NAME = "name";

private static final String MYECLIPSE_METADATA_PROJECT_ID = "id";

private static final String MYECLIPSE_METADATA_PROJECT_CONTEXT_ROOT = 
"context-root";

private static final String MYECLIPSE_METADATA_PROJECT_J2EE_SPEC = 
"j2ee-spec";

private static final String MYECLIPSE_METADATA_PROJECT_ARCHIVE = "archive";

private static final String MYECLIPSE_METADATA_PROJECT_TYPE_WAR = "WEB";

private static final String MYECLIPSE_METADATA_PROJECT_TYPE_EAR = "EAR";

private static final String MYECLIPSE_METADATA_PROJECT_TYPE_EJB = "EJB";

private static final String MYECLIPSE_METADATA_PROJECT_ATTRIBUTES = 
"attributes";

private static final String MYECLIPSE_METADATA_PROJECT_ATTRIBUTE = 
"attribute";

/**
 * Writer entry point
 * 
 * @throws MojoExecutionException
 */
public void write()
throws MojoExecutionException
{
String packaging = config.getProject().getPackaging();

if ( !Constants.PROJECT_PACKAGING_EAR.equalsIgnoreCase( packaging ) &&
!Constants.PROJECT_PACKAGING_WAR.equalsIgnoreCase( packaging ) &&
!Constants.PROJECT_PACKAGING_EJB.equalsIgnoreCase( packaging ) )
{
return;
}

FileWriter w;

try
{
w = new FileWriter( new File( config.g

CI servers

[Arnaud HERITIER]

Hi just noticed we have now 3 CI servers :

http://vmbuild.apache.org/continuum : Continuum @ Apache
http://hudson.zones.apache.org/hudson/view/Maven/ : Hudson @ Apache
https://grid.sonatype.org/ : Hudson @ Sonatype

Isn't it a little bit to much ??

Do you follow notifications ?
Are they reporting the same issues ?

..
Arnaud HERITIER
12 guidelines to boost your productivity with a Java software factory -
http://tinyurl.com/56s9tw
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...

Re: [eclipse-plugin] java 1.5

[Arnaud HERITIER]

No, our plugins have to be compatible with java 1.4 (which is the current
java version supported by maven 2.0.X).
Be careful to not use 1.5 APIs and syntax in your patch.

Arnaud

On Sun, Nov 23, 2008 at 8:17 PM, Andreas Höhmann <
[EMAIL PROTECTED]> wrote:

> Hello folks,
>
> can we add a
>
>  
>org.apache.maven.plugins
>maven-compiler-plugin
>
>  1.5
>  1.5
>
>  
>
> to the pom of maven-eclipse-plugin (2.6-SNAPSHOT: trunk).
>
> Currently im fixing the bug http://jira.codehaus.org/browse/MECLIPSE-273
> and i want use java 1.5 features (generics etc.). Is this possible or not
> (for backward compatibility)?
>
> regards
> höhmi
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
..
Arnaud HERITIER
12 guidelines to boost your productivity with a Java software factory -
http://tinyurl.com/56s9tw
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...

[RESULT] [VOTE] Release Maven Changes plugin version 2.1

[Olivier Lamy]

Hi,
The vote has passed with the following result :
3 +1 (binding) ; snicoll, evenisse, olamy.
1 +1 (non-binding) :  bellingard.

I will move artifacts to the central repo.

Thanks,
--
Olivier

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Maven Changes plugin version 2.1

[Emmanuel Venisse]

+1

Emmanuel

On Tue, Nov 18, 2008 at 10:57 PM, Olivier Lamy <[EMAIL PROTECTED]> wrote:

> Hi,
> I'd like to release maven-changes-plugin version 2.1.
>
> We solved 27 issues :
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14064&styleName=Html&projectId=11212&Create=Create
>
> Staging repo: 
> http://people.apache.org/~olamy/staging-repo/
>
> Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.1
> (wait sync)
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Here my +1.
>
> --
> Olivier
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: [VOTE] Release Maven Changes plugin version 2.1

[Olivier Lamy]

Hi,
ping (one binding vote missing).

Thanks !
--
Olivier

2008/11/18 Olivier Lamy <[EMAIL PROTECTED]>:
> Hi,
> I'd like to release maven-changes-plugin version 2.1.
>
> We solved 27 issues :
> http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14064&styleName=Html&projectId=11212&Create=Create
>
> Staging repo: http://people.apache.org/~olamy/staging-repo/
>
> Staging site: http://maven.apache.org/plugins/maven-changes-plugin-2.1
> (wait sync)
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Here my +1.
>
> --
> Olivier
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to support modelVersion > 4.0.0

[Stephen Connolly]

2008/11/23 Brian E. Fox <[EMAIL PROTECTED]>

>
> >what I'm saying is let's go farther and make the pom deployed to the
> >repo a more minimal pom... keeping only that which is actually needed
>
> This can only be done for poms that are not  poms, that is
> for things that are not inherited. Otherwise you still need to have the
> new pom version deployed to support all the features when building.
>

Actually what I was saying is to deploy two poms...

1 -> without a classifier, that just has the dependencies, license, and is
fully resolved with no internal properties and no parent reference... this
pom is modelVersion 4.0.0

2 -> with calssifier "v4.1.0" and is the full pom.

My logic being, you cannot use a 4.1.0 pom as your parent *unless* your pom
is 4.1.0+

Re: How to support modelVersion > 4.0.0

[Gilles Scokart]

2008/11/23 Stephen Connolly <[EMAIL PROTECTED]>:
> 2008/11/22 Stephen Connolly <[EMAIL PROTECTED]>
>
>> The problem is that repo1.maven.org is used by everyone, and even some
>> things that are not Maven (e.g. ivy, etc)
>>

A big +1.  Changing the published poms format is very impacting.  Not
only for the maven client, but for all tools that are using the
repository as a server (ivy, buildr, maven proxies & repository
managers, etc...).


-- 
Gilles Scokart

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]