On 4-Jul-08, at 3:14 AM, Henri Gomez wrote:
Here's some tips for folks trying to debug Maven/Plexus/Plugins in
Eclipse.
Using m2e you can actually debug/execute plugin _inside_ Eclipse.
That means
the plugin executes from the workspace in-situ. Extremely handy.
On 05/07/2008, at 2:17 AM, Jason van Zyl wrote:
As part of getting adequate coverage for vetting, I have just asked
Nigel and Justin who watch over the Hudson instance here at Apache
to setup the Maven jobs we require for validation. They are running
on Solaris which will be a good
We'll get a Solaris VM running at Contegix but I'll try it when Nigel
gives me access. The Hadoop stuff seems to be running all the time and
it takes over an hour so our ITs would probably kill the machine.
On 6-Jul-08, at 9:33 AM, Brett Porter wrote:
On 05/07/2008, at 2:17 AM, Jason van
On 06/07/2008, at 3:56 AM, Jason van Zyl wrote:
I am also working with the Apache Infrastructure team to integrate
the Contegix folks who are the ones who currently host all the
hardware we're using. Maven's central repository, our Hudson
instance, and our Nexus instance. So, in short
On 6-Jul-08, at 10:08 AM, Brett Porter wrote:
On 06/07/2008, at 3:56 AM, Jason van Zyl wrote:
I am also working with the Apache Infrastructure team to integrate
the Contegix folks who are the ones who currently host all the
hardware we're using. Maven's central repository, our Hudson
You may also just want to try and clean that test up:
http://docs.codehaus.org/display/MAVEN/IT+Problems
it0081 is listed in there.
On 6-Jul-08, at 11:20 AM, [EMAIL PROTECTED] wrote:
Author: brett
Date: Sun Jul 6 08:20:18 2008
New Revision: 674307
URL:
Is there anyone working on this?
I am thinking of implementing release:release mojo which extends
release:prepare and add release:perform's params to its arguments
there will be cut/paste code from release:perform mojo.
Thoughs?
-D
You can just batch them together.
We have an example setup in our Hudson:
mvn -B -U -e -Prelease,stage -Dmaven.repo.local=/home/j2ee-hudson/
repos/${JOB_NAME} clean release:prepare release:perform -Darguments=-X
On 6-Jul-08, at 12:01 PM, Dan Tran wrote:
Is there anyone working on this?
I
Ah, that is very simple
Thanks
-D
On Sun, Jul 6, 2008 at 9:05 AM, Jason van Zyl [EMAIL PROTECTED] wrote:
You can just batch them together.
We have an example setup in our Hudson:
mvn -B -U -e -Prelease,stage
-Dmaven.repo.local=/home/j2ee-hudson/repos/${JOB_NAME} clean release:prepare
Ew. :)
I agree with wanting to centralise the versions, but this seems like a
stopgap for a less verbose POM and some sort of grouping (ie, allowing
a short burst of versions in the dependencyManagement only).
Am I understanding correctly that this is just cosmetic - or is there
a
On 6-Jul-08, at 12:32 PM, Brett Porter wrote:
Ew. :)
I agree with wanting to centralise the versions, but this seems like
a stopgap for a less verbose POM and some sort of grouping (ie,
allowing a short burst of versions in the dependencyManagement only).
Am I understanding correctly
On 07/07/2008, at 2:42 AM, Jason van Zyl wrote:
As I stated in the issue, to be able to change the versions on the
fly in the build system to use different versions. Pass in
properties is far easier then trying to muck with the version in the
depMan section. It will also allow the
On 6-Jul-08, at 12:53 PM, Brett Porter wrote:
On 07/07/2008, at 2:42 AM, Jason van Zyl wrote:
As I stated in the issue, to be able to change the versions on the
fly in the build system to use different versions. Pass in
properties is far easier then trying to muck with the version in
Fine here, and on vmbuild too.
digester being null happens after a transfer error of some sort - you
might throw in -X to see if it shows something else occuring.
The other curiosity is why it's resolved the project info reports
plugin in both cases?
Cheers,
Brett
On 07/07/2008, at 4:03
On 05/07/2008, at 1:51 AM, Oleg Gusakov wrote:
John - are you looking into this? Need it resolved for MNG-3185
I've done it in the way John was suggesting - it's not the perfect
solution but it's the best one available I think.
I stumbled upon an API regression that breaks one of
Yeah, I noticed that too. It's unrelated to the current problem (which
seems to be fixed by doing the deletion), so I haven't changed it
immediately - but if these stay stable I'll come back and change it to
use an it-built artifact instead.
- Brett
On 07/07/2008, at 1:29 AM, Jason van
On 6-Jul-08, at 2:46 PM, Brett Porter wrote:
Fine here, and on vmbuild too.
digester being null happens after a transfer error of some sort -
you might throw in -X to see if it shows something else occuring.
After a transfer error it calls transferStarted( XX )? That seems wrong.
The
On 07/07/2008, at 12:45 PM, Brett Porter wrote:
On 07/07/2008, at 5:15 AM, Jason van Zyl wrote:
On 6-Jul-08, at 2:46 PM, Brett Porter wrote:
Fine here, and on vmbuild too.
digester being null happens after a transfer error of some sort -
you might throw in -X to see if it shows
I've just run into the problem identified in these two issues (and in
others).
The suggestion in MNG-3267 proposes allowing the version (at a minimum)
as a property. It then proposes that the version be resolved and the pom
without properties be placed in the target directory. It then
There you go, we're back to normal in both Hudson and Continuum now.
On 07/07/2008, at 2:15 PM, Hudson wrote:
See http://ci.sonatype.org/job/Maven-2.1.x-ITs/172/changes
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
Is it a full moon or something? ;-)
Now that everything is building and passing Its...lets keep it that way.
-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Monday, July 07, 2008 12:28 AM
To: dev@maven.apache.org
Subject: Re: Hudson build is back to normal:
21 matches
Mail list logo
