+1
Stéphane
On 1/15/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Hi,
I would like to release invoker plugin which is being used in many
ITs in plugins and is now being used in the core ITs to fully
automate the installation of the requirements for running the ITs.
Revision:
495459
Snapshot:
On 1/15/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
I myself have intentionally stayed away from artifact resolution on
the branch so do you have a test project I can use. I need to be able
to reproduce your problem and turn it into some form of test. So I
can see what's going on and so it doe
On 1/16/07, berndq <[EMAIL PROTECTED]> wrote:
Hi,
I did not get an answer on the users list so I try it here:
I use the assembly plugin to create multiple assemblies from a multi
module project:
src/main/assembly/server.xml
src/main/assembly/client.xml
Hi,
I did not get an answer on the users list so I try it here:
I use the assembly plugin to create multiple assemblies from a multi
module project:
src/main/assembly/server.xml
src/main/assembly/client.xml
This works nicely.
But how could I ma
On 12/17/06, Jason van Zyl <[EMAIL PROTECTED]> wrote:
The maven-site-plugin should be good now.
This problem is back. When site.xml contains ${modules}, I get:
[INFO]
[ERROR] BUILD ERROR
[INFO] -
Yeah... I saw this right after I sent that last email...
http://jira.codehaus.org/browse/MNG-2351
Sorry!
On 1/15/07, Brett Porter <[EMAIL PROTECTED]> wrote:
I think -X just doesn't work at all on trunk - right?
It's not deliberate, just logging changes that need fixing.
On 16/01/2007, at 9:
So... why not comment out cvs and local too? Nobody uses them any
more... and the local one is certainly the weirdest :)
Personally, I'd turn all the integration-ish tests off in the normal
build (including svn which is very long), and put them in a profile.
On 16/01/2007, at 12:37 PM, Jaso
On 15 Jan 07, at 8:32 PM 15 Jan 07, Brett Porter wrote:
For example, so that we can run them in CI and make sure they still
build.
Then why not let CI do the hard work and turn on the profile and make
it easier for folks checking out and building?
You were running them all anyway? So j
For example, so that we can run them in CI and make sure they still
build.
If we had multiple boxes and could target builds to where they could
run, sure... but we're not there yet.
- Brett
On 16/01/2007, at 12:10 PM, Jason van Zyl wrote:
On 15 Jan 07, at 7:54 PM 15 Jan 07, Brett Porter
IIRC, the order in which dependencies are declared effectively becomes the
tie-breaker when two dependency versions are declared at the same depth...so
if:
A -> B, C
B -> D (v2)
C -> D (v3)
and A declares the following:
[...]
B
[...]
C
then Maven should choose D (v2) beca
On 15 Jan 07, at 7:54 PM 15 Jan 07, Brett Porter wrote:
Yeah, I'd really rather we didn't put the builds in a profile, but
instead moved the tests to the profile.
Why?
- Brett
On 16/01/2007, at 2:40 AM, Emmanuel Venisse wrote:
Jason,
clearcase, perforce, starteam, synergy and vss pro
I think -X just doesn't work at all on trunk - right?
It's not deliberate, just logging changes that need fixing.
On 16/01/2007, at 9:34 AM, Patrick Schneider wrote:
Did the indented list of dependencies in the debug output go away
in the
trunk? 2.0.x would give a list like:
[DEBUG] com.te
What happened?
On 16/01/2007, at 2:50 AM, Emmanuel Venisse wrote:
build fine now
Emmanuel
Brett Porter a écrit :
Hi,
There appears to be a test failure in Continuum for Bazaar now
that I have the client installed again. This is bzr-0.13,
Python-2.5, Solaris 10 x86.
http://maven.zones.apa
Yeah, I'd really rather we didn't put the builds in a profile, but
instead moved the tests to the profile.
- Brett
On 16/01/2007, at 2:40 AM, Emmanuel Venisse wrote:
Jason,
clearcase, perforce, starteam, synergy and vss providers can be
tested without SCM installations. Why do you put th
Thanks
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
On 15 Jan 07, at 5:48 PM 15 Jan 07, Barrie Treloar wrote:
Sparked by http://www.nabble.com/forum/ViewPost.jtp?
post=8371995&framed=y&skin=177
One of the discussions I wanted to have was about the release plugin.
You should catch up on Joakim's original mail that start all the new
tools t
On 15/01/2007, at 5:59 PM, Stephane Nicoll wrote:
I don't think I have access to this machine but if I do, let me know
how and I'll have a look. Otherwise, check
target/projects/project-XXX/target/jboss-app.xml or application.xml
(where XXX is 031, 032 or 033).
You can take a look by navigati
On 1/16/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
On 15 Jan 07, at 8:56 AM 15 Jan 07, Max Bowsher wrote:
> Kenney Westerhof wrote:
>> tags cannot change, ever.
>
> The maven-2.0.5 tag already has been changed a bit since creation.
>
The only way we'll move toward having releases be perfect
Sparked by
http://www.nabble.com/forum/ViewPost.jtp?post=8371995&framed=y&skin=177
One of the discussions I wanted to have was about the release plugin.
The way I look at it tags can change, but only until just prior to
when you deploy the release. Once it is deployed you can't change the
tag b
Did the indented list of dependencies in the debug output go away in the
trunk? 2.0.x would give a list like:
[DEBUG] com.test:project-a:jar:1.0-SNAPSHOT (applying version: 1.0-SNAPSHOT
;)
[DEBUG] com.test:project-a:jar:1.0-SNAPSHOT (selected for null)
[DEBUG] junit:junit:jar:3.8.1:compile (ap
I revert the branch, apply the fix, redo the release and call for
another vote.
Fabrice can you please check again on your builds and make sure it's
not something with the checkstyle plugin.
Jason.
In the
On 15 Jan 07, at 11:40 AM 15 Jan 07, Jason van Zyl wrote:
On 15 Jan 07, at 11:19
It also reverts the changes fixed in this bug:
http://jira.codehaus.org/browse/MNG-2692 -- after bootstrapping, I had to
make changes to mvn.bat and m2.conf in order to be able to run...
Patrick
On 1/15/07, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
Not sure why, but this brought back the old
There were a couple of invalid poms in the central repo [1]. Even
after correcting them in the managed repository and re-indexing,
Archiva continues to show an error.
Likewise, if I intentionally mess up another pom (put a & character in
the ) and re-index, Archiva continues to display the old,
+1
On 1/15/07, Jesse McConnell <[EMAIL PROTECTED]> wrote:
+1
On 1/15/07, Eric Redmond <[EMAIL PROTECTED]> wrote:
> +1
>
> On 1/15/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > I would like to release invoker plugin which is being used in many
> > ITs in plugins and is now be
Not sure why, but this brought back the old license headers...
[EMAIL PROTECTED] wrote:
Author: jvanzyl
Date: Mon Jan 15 13:10:57 2007
New Revision: 496493
URL: http://svn.apache.org/viewvc?view=rev&rev=496493
Log: (empty)
Modified:
maven/components/trunk/maven-cli/src/bin/m2.conf
mave
+1
On 1/15/07, Eric Redmond <[EMAIL PROTECTED]> wrote:
+1
On 1/15/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I would like to release invoker plugin which is being used in many
> ITs in plugins and is now being used in the core ITs to fully
> automate the installation of the requir
+1
On 1/15/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Hi,
I would like to release invoker plugin which is being used in many
ITs in plugins and is now being used in the core ITs to fully
automate the installation of the requirements for running the ITs.
Revision:
495459
Snapshot:
http://pe
All fixed, see below
On 1/14/07, Brett Porter <[EMAIL PROTECTED]> wrote:
-1 (sorry)
* license headers are not updated
kindly fixed by brett
* svn revision needs to be provided
rev# 496418
* staged bundle/snapshot needs to be provided
http://people.apache.org/repo/m2-snapshot-repo
Hi,
I would like to release invoker plugin which is being used in many
ITs in plugins and is now being used in the core ITs to fully
automate the installation of the requirements for running the ITs.
Revision:
495459
Snapshot:
http://people.apache.org/repo/m2-snapshot-repository/org/apache
On 15 Jan 07, at 11:19 AM 15 Jan 07, Kenney Westerhof wrote:
Hi,
I've fixed this bug a while back on trunk but haven't merged it to
the branch.
The cause is that for non-existing metadata files at the checked
repositories,
no local metadata file is written. The 'daily' policy uses the
tim
Hi,
I've fixed this bug a while back on trunk but haven't merged it to
the branch.
The cause is that for non-existing metadata files at the checked repositories,
no local metadata file is written. The 'daily' policy uses the timestamp for
that file to see if it should update again, which it alwa
Trygve Laugstøl wrote:
Jason van Zyl wrote:
Hi,
The entire release is staged here:
http://people.apache.org/~jvanzyl/maven-2.0.5/
The assemblies that people are interested in are staged here:
http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/maven-core/2.0.5/
Here is the JIR
+1
Tested against our build and appears to work identically to 2.0.4.
On 1/12/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
Hi,
The entire release is staged here:
http://people.apache.org/~jvanzyl/maven-2.0.5/
The assemblies that people are interested in are staged here:
http://people.apache
Jason,
clearcase, perforce, starteam, synergy and vss providers can be tested without
SCM installations. Why do you put them in a profile?
Emmanuel
[EMAIL PROTECTED] a écrit :
Author: jvanzyl
Date: Mon Jan 15 06:58:34 2007
New Revision: 496356
URL: http://svn.apache.org/viewvc?view=rev&rev=
Thank you for your answer,
If I understands well :
http://svn.apache.org/repos/asf/maven/continuum/branches/gbuild/ will be
used as a basis of the development of CONTINUUM-563.
and it will work with Continuum trunk ?
I will look immediately at this implementation.
--
View this message in cont
On 1/15/07, Fabrice Bellingard <[EMAIL PROTECTED]> wrote:
The first is about dependency resolution. In the dependency tree of one of
my projects, I have 2 versions of the same lib at the same depth: version
3.1 and 2.1. With Maven 2.0.4, version 3.1 is selected for compiling and
testing, which
The copy of gbuild that we have was given to us by David Blevins, the
original author and that's the only version we'll be looking at.
Geronimo will eventually move away from Continuum, they are currently
using Ant Hill so I doubt there will be any activity there.
Jason.
On 15 Jan 07, at 9
Hi,
+1 works fine for me
But I confirmed DOXIA-90 for 2.0.5. Is it a known issue on core?
Cheers,
Vincent
2007/1/12, Jason van Zyl <[EMAIL PROTECTED]>:
Hi,
The entire release is staged here:
http://people.apache.org/~jvanzyl/maven-2.0.5/
The assemblies that people are interested in are st
I have a need for continuous integration on several platforms.
I looked at GBuild, and I see CONTINUUM-563.
But in continuum svn, i have
http://svn.apache.org/repos/asf/maven/continuum/branches/gbuild/ svn
revision is 437461
and in geronimo svn
http://svn.apache.org/repos/asf/geronimo/gbuild/tru
On 15 Jan 07, at 8:56 AM 15 Jan 07, Max Bowsher wrote:
Kenney Westerhof wrote:
tags cannot change, ever.
The maven-2.0.5 tag already has been changed a bit since creation.
The only way we'll move toward having releases be perfect is to do
lots of them.
The perpetual tension between bu
On 15 Jan 07, at 6:29 AM 15 Jan 07, Fabrice Bellingard wrote:
Hi Jason,
I've just tested Maven 2.0.5 on complex projects, and I've had 2
problems
who broke the builds.
The first is about dependency resolution. In the dependency tree of
one of
my projects, I have 2 versions of the same li
Kenney Westerhof wrote:
> tags cannot change, ever.
The maven-2.0.5 tag already has been changed a bit since creation.
The perpetual tension between burning publicly visible version numbers,
and retaining unique identity of versions strikes again. Unfortunately,
it's a problem without any obvious
I think we need to change the changes check. Actually, we do an update on all
projects to check if we have changes.
It will be better to use the status command (I don't know if this command exist
in all SCM), but with svn, we'll can use 'svn status -u'
I think the changes check will improve per
On 14 Jan 07, at 4:37 PM 14 Jan 07, Dennis Lundberg wrote:
Jason,
Would you consider upgrading the dependency on modello-maven-plugin
in maven-model to alpha-13 (or alpha-14 if that is released) for
this release? It would bring in a couple of nice features for the
generated documentation
This pb appears because maven use an old wagon version and continuum use the
latest 1.0-beta-2.
The jetty plugin doesn't fork the process and use the old version instead of
the one declared in continuum pom.
All works fine with maven 2.0.5.
Emmanuel
Marcelo Fukushima a écrit :
hello devs (he
+1. It works fine for me.
Emmanuel
Jason van Zyl a écrit :
Hi,
The entire release is staged here:
http://people.apache.org/~jvanzyl/maven-2.0.5/
The assemblies that people are interested in are staged here:
http://people.apache.org/~jvanzyl/maven-2.0.5/org/apache/maven/maven-core/2.0.5/
Dennis Lundberg wrote:
Jason,
Would you consider upgrading the dependency on modello-maven-plugin in
maven-model to alpha-13 (or alpha-14 if that is released) for this
release? It would bring in a couple of nice features for the generated
documentation. If not, I'll add it to JIRA for 2.0.6
Emmanuel Venisse wrote:
[EMAIL PROTECTED] a écrit :
Author: kenney
Date: Fri Jan 12 16:42:33 2007
New Revision: 495802
URL: http://svn.apache.org/viewvc?view=rev&rev=495802
Log:
Lots of fixes and improvements:
* changed the ScmCvsExeWagonTest to extend from the abstractCVS wagon
test, so
>I had the second problem when executing the Checkstyle plugin (version
2.1).
>So I dug a bit to see if this could be related to maven core or not,
and here is what I found.
>I isolated the code that breaks the build in the checkstyle plugin: it
happens when the plugin tries to load my Checkstyle
Hi
This is not the first problem with cycle forking. The others I know are:
- test coverage checking with clover plugin
- jspc plugin (codehaus mojo) - forking was removed
Do you have any idea, what to do with it?
Grzegorz Slowikowski
- Original Message -
From: "Chris Hilton (JIRA)" <
Brett Porter wrote:
so... you're saying you don't trust our dog food? :)
No, I'm saying it's there to verify the dog food. If there is no
discrepancies between what the cron is saying and the C instance is
saying, it's good. If there is an discrepancy it's not good.
It will be more a tool t
Hi Jason,
I've just tested Maven 2.0.5 on complex projects, and I've had 2 problems
who broke the builds.
The first is about dependency resolution. In the dependency tree of one of
my projects, I have 2 versions of the same lib at the same depth: version
3.1 and 2.1. With Maven 2.0.4, version 3.
52 matches
Mail list logo
