I tried with my current checkout, an update (with the new invoker config)
and with a fresh checkout (directory removed and svn co). All three worked
on my Mac (15.0.4)
Can you try with a fresh checkout maybe?
Thanks,
Stéphane
On Wed, Aug 6, 2008 at 10:27 PM, Arnaud HERITIER <[EMAIL PROTECTED]>wro
The CI build bypass integration tests.
I don't yet know how many time it makes to build but I think it will be many
more reduced.
On Thu, Aug 7, 2008 at 3:14 AM, Brian E. Fox <[EMAIL PROTECTED]>wrote:
> How is the plugin its project different than the one that was already
> there? Why do we need
The Maven team is pleased to announce the release of the Maven Deploy
Plugin, version 2.4.
This plugin is used to add artifacts and associated metadata to a
remote repository [1].
http://maven.apache.org/plugins/maven-deploy-plugin/
To use this release, specify the version in your project's plug
When I reinstalled 2.0.10-RC5, it ran fine. Then I realized my
reinstall didn't include my custom settings.xml, but once I put that
back into /conf, everything went bonkers again. So that's where the
problem is.
You can reproduce the problem by doing the following:
- Edit the original settings.xml
On Wed, Aug 6, 2008 at 8:54 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> Given the recent fiasco over the snapshot repo, it's probably a good
> idea that we change the Apache root pom to have usesUnique=false and
> start inheriting from that version. This will serve two desired results:
> 1 it wil
If the surefire plugin (and compiler plugin) and such were more
configurable, so you wouldn't have to sub-class them to make plugins
for integration tests, then the simple mode would be to bind them at
other phases to compile and execute tests in those phases. That would
be nice.
Christi
Given the recent fiasco over the snapshot repo, it's probably a good
idea that we change the Apache root pom to have usesUnique=false and
start inheriting from that version. This will serve two desired results:
1 it will drastically reduce the disk size of the m2 repo and 2 it will
discourage users
Jason was talking about a new box we have. It will be running Vmware ESX
and hosting many VMs to build out a Hudson grid of various os's in
master-slave mode. The current ci.sonatype.org is not on that server but
will be once it's ready.
-Original Message-
From: Dan Tran [mailto:[EMAIL PRO
how many instances of Hudsons do you install on that box? 32x3? :-)
On Wed, Aug 6, 2008 at 6:13 PM, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> I bumped up the memory for Hudson from 192m to 384m.
>
> -Original Message-
> From: Benjamin Bentmann [mailto:[EMAIL PROTECTED]
> Sent: Wednesday
I should add this happens to me unconditionally. No goals, no matter
what they are, will execute.
On Wed, Aug 6, 2008 at 8:13 PM, Paul Benedict <[EMAIL PROTECTED]> wrote:
> I tried RC5 and got this weird error.
>
>>c:\dev\apache-maven-2.0.10-RC5\bin\mvn.bat site:deploy
> --
How is the plugin its project different than the one that was already
there? Why do we need both?
-Original Message-
From: Arnaud HERITIER [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 06, 2008 5:51 PM
To: Maven Developers List
Subject: Re: In summer, the sun shines
You're right.
Bef
I bumped up the memory for Hudson from 192m to 384m.
-Original Message-
From: Benjamin Bentmann [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 06, 2008 5:39 PM
To: Maven Developers List
Subject: Re: In summer, the sun shines
Arnaud HERITIER wrote:
> I think that the memory allocated
I tried RC5 and got this weird error.
>c:\dev\apache-maven-2.0.10-RC5\bin\mvn.bat site:deploy
---
constituent[0]:
file:/c:/Dev/apache-maven-2.0.10-RC5/bin/../lib/maven-2.0.10-RC5-uber.jar
---
java.lang.
The machine was just put in the rack for builds and it has 32gb RAM so
we can go to the next level.
On 6-Aug-08, at 2:51 PM, Arnaud HERITIER wrote:
You're right.
Before to launch the build, hudson uses the maven embedder to parse
the
project pom (and its modules).
What I don' understand it
Adding my +1, we have 4 binding +1's from Brett, Emmanuel, Olivier,
Wendy and an additional vote from Marat.
I'll go ahead with the release.
--
Wendy
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail:
Mainly, it's useful for testing various POM configurations, both for the
core and for maven plugins. Outside of that, I don't imagine you'd want
to use it, except possibly to spawn sub-builds for something exotic.
-john
Paul Benedict wrote:
I work in a team that heavily writes unit and integr
You're right.
Before to launch the build, hudson uses the maven embedder to parse the
project pom (and its modules).
What I don' understand it's why it's failing each time in CI and not in ITS
whereas it is the same list of modules.
On Wed, Aug 6, 2008 at 11:39 PM, Benjamin Bentmann <
[EMAIL PROTE
The Maven team is pleased to announce the release of the Maven
Filtering, version 1.0-beta-1
These Plexus components have been built from the filtering process/code
in Maven Resources Plugin. The goal is to provide a shared component for
all plugins which needs to filter resources.
http://ma
Arnaud HERITIER wrote:
I think that the memory allocated to hudson isn't really important.
We set memory settings in Maven builds using MAVEN_OPTS.
For Maven-Plugins, we have -Xmx512m in MAVEN_OPTS
Well, MAVEN_OPTS is for the *forked* Maven runs. Please have a look at
https://ci.sonatype.org
I think that the memory allocated to hudson isn't really important.
We set memory settings in Maven builds using MAVEN_OPTS.
For Maven-Plugins, we have -Xmx512m in MAVEN_OPTS
Arnaud
On Wed, Aug 6, 2008 at 11:22 PM, Benjamin Bentmann <
[EMAIL PROTECTED]> wrote:
> Arnaud HERITIER wrote:
>
> Ok t
Arnaud HERITIER wrote:
Ok the build takes approximatively 3 hours (and is launched every 4 hours)
which isn't very nice to do continuous integration.
Sure, Brian told me that Hudson was not a dedicated machine but I still
wonder whether this long build time is normal. For instance, both
+1
Tested on our others plugins
Arnaud
On Wed, Aug 6, 2008 at 11:08 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
> Hi,
>
> We solved 7 issues:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11441&styleName=Html&version=14348
>
> There are still a couple of issues left in JIRA:
>
This vote has passed with the following votes:
+1 from Olivier Lamy, Vincent Siveton, Stephane Nicoll, Dennis Lundberg
I'll start moving the artifacts.
Dennis Lundberg wrote:
Hi,
This release is to prepare for the release of Maven WAR Plugin.
This is a new shared component, based on code fro
+1
Arnaud
On Wed, Aug 6, 2008 at 10:45 PM, Dennis Lundberg <[EMAIL PROTECTED]> wrote:
> +1
>
>
> Dennis Lundberg wrote:
>
>> Hi,
>>
>> Second try, this time with a license header in the POM.
>>
>> Note: there is one error in the Clirr report. It was necessary to make
>> that change to solve the t
Hi,
We solved 7 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11441&styleName=Html&version=14348
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11441&status=1
Staging repo:
http://people.apache.org/~dennis
Hi all,
As you probably noticed I worked on plugins builds.
Benjamin began to cleanup some plugins poms by reordering elements, and
more.
I continued by using everywhere the new maven-parent and maven-plugins
that we will release in few days.
I moved all versions of plugins that we are us
+1
Dennis Lundberg wrote:
Hi,
Second try, this time with a license header in the POM.
Note: there is one error in the Clirr report. It was necessary to make
that change to solve the testing for IDEA-102, so it's by design.
We solved 8 issues:
http://jira.codehaus.org/secure/ReleaseNote.jsp
+1
Dennis Lundberg wrote:
Hi,
This release is to prepare for the release of Maven WAR Plugin.
This is a new shared component, based on code from Maven Resources
Plugin, so there are no issues fixed or left in JIRA. The goal of this
component is to provide a common tool for maven plugins to f
ok, thanks for your help.
On Wed, Aug 6, 2008 at 6:09 PM, Stephane Nicoll
<[EMAIL PROTECTED]>wrote:
> Weird. I have leopard as well and it works. They were some problems lately
> and I fixed them. Let me check again later today.
>
> S.
>
> On Wed, Aug 6, 2008 at 6:06 PM, Arnaud HERITIER <[EMAIL
Le mercredi 06 août 2008, Wendy Smoak a écrit :
> On Tue, Aug 5, 2008 at 11:04 PM, Brett Porter <[EMAIL PROTECTED]> wrote:
> > A curiosity though: are there any technical issues with bundling the
> > o.c.p.utils classes for MDEPLOY-66?
>
> From irc:
> wsmoak: brett: should I worry about your comme
I've used (and worked on) all the frameworks and also think SHITTY is
the closest. It needs a few improvements before it can be mainstream:
1. It freaks out 2.1 because it circumnavigates the packaging and
installs the plugin that was packaged by the main lifecycle. The problem
is the data inside h
The Maven team is pleased to announce the release of the Maven Invoker,
version 2.0.9
This shared component fires up a Maven build in a new JVM.
http://maven.apache.org/shared/maven-invoker/
Release Notes - Maven Shared Components - Version maven-invoker 2.0.9
** Bug
* [MSHARED-21] - Spa
My pick for the tool is STY. I think Brian has used it, and Jason
Dillon definitely has his opinion.
The unit testing is different and the plugin-testing-harness is for
unit testing and I'm not concerned about that in this context. If you
look at the way Jason Dillon tests his plugins I thi
Weird. I have leopard as well and it works. They were some problems lately
and I fixed them. Let me check again later today.
S.
On Wed, Aug 6, 2008 at 6:06 PM, Arnaud HERITIER <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I'm trying to build the ear plugin on leopard but tests are failing.
> Those
Hi all,
I'm trying to build the ear plugin on leopard but tests are failing.
Those unit/integration tests are using the maven-verifier which fails to
read poms with errors like :
testProject001(org.apache.maven.plugin.ear.EarMojoTest) Time elapsed: 0.059
sec <<< ERROR!
org.apache.maven.it.Ve
On 8/6/08, Brian Fox <[EMAIL PROTECTED]> wrote:
> As I said before, this was done by infra with no notice to us. The new
> policy of purging is theirs, not ours. See the infra archives if you
> would like to read about it.
It would be perfectly possible to publish long lived Milestones
provided th
+1 to all below.
All the information I could find in January is here:
http://docs.codehaus.org/display/MAVENUSER/Review+of+Plugin+Testing+Strategies
Please use that as a starting point. There has probably been stuff
added to STY since. It generally seemed the best, but I would like to
see it
Okay, I'm working on the performance problems with concrete/dynamic
transitions...that'll probably affect this issue (at least its location,
just a guess).
I have a couple of other perf-related issues that I've fixed related to
interpolation that were suggested by olamy and bentmann on IRC yes
Hi,
I think we've gotten to the point where we need to decide how we are
going to test plugins. We need to pick one of the frameworks, settle
on a pattern, and use that in the plugins otherwise there will be no
sane way to validate a set of plugins works against a given version of
Maven.
Excellent!
Mark - regarding you document: I abstracted conflict resolution even
more: one of the inputs to the DependencyBuilder is a List -
good old java comparators that can compare tree nodes. When tree is
being created, all tree nodes are sorted by these comparators and
results are added
On Tue, Aug 5, 2008 at 11:04 PM, Brett Porter <[EMAIL PROTECTED]> wrote:
> A curiosity though: are there any technical issues with bundling the
> o.c.p.utils classes for MDEPLOY-66?
>From irc:
wsmoak: brett: should I worry about your comment on the deploy plugin vote?
brett: wsmoak: I don't know
This document discusses POM processing in great detail, while in Mercury
we abstracted it into external interface MetadataProcessor. You give it
GAV to the POM, MetadataReader and it returns back a list of dependency
GAVs interpolated for the given environment. Not transitive - just
direct depe
As I said before, this was done by infra with no notice to us. The new
policy of purging is theirs, not ours. See the infra archives if you
would like to read about it.
On Aug 5, 2008, at 10:45 PM, "Patrick Moore" <[EMAIL PROTECTED]>
wrote:
Of course this means that the maven team is imp
Here's the collector page where you might want to add your stuff:
http://docs.codehaus.org/display/MAVEN/Mercury
and here's the nitty gritty:
http://docs.codehaus.org/display/MAVEN/SAT+Based+Dependency+Resolution
And a lot of this document should be reconciled as well:
http://docs.codehaus.or
Perhaps we can also update hudson.
There are few bug solved concerning maven :
https://hudson.dev.java.net/changelog.html
We are in 1.137
Arnaud
On Wed, Aug 6, 2008 at 12:06 PM, Benjamin Bentmann <
[EMAIL PROTECTED]> wrote:
> Hi John,
>
>
>> http://people.apache.org/~jdcasey/stage/apache-maven/2
Hi John,
http://people.apache.org/~jdcasey/stage/apache-maven/2.0.10-RC5/org/apache/maven/apache-maven/2.0.10-RC5
Brian was so kind to install RC5 on Hudson and Arnaud has setup the job
"Maven-Plugins-CI" to run with it. The build #22 [0] showed a NPE coming
from DefaultPluginManager.java:70
Hi guys,
I'm happy to take a look at the new Mercury code and make sure it
supersedes my conflict resolvers patch. Any pointers to documentation
and code would be appreciated.
Cheers,
Mark
2008/8/6 Jason van Zyl <[EMAIL PROTECTED]>:
> Mark/Oleg,
>
> Just wanted to make sure you guys were synce
Hello,
That didn't work well. Okay, since you don't believe me, here is an
(incomplete) list of changes I would need in StAX to be able to use it
for my work instead of having to write my own XML parser. Note: If you
feel like asking "who would ever need that?" while reading that list,
th
48 matches
Mail list logo
