with a set if plexus component rules...not an
extension. I would add this to shared, it doesn't seem to justify a
new tree and parent structure.
On Friday, November 5, 2010, Dan Fabulich wrote:
The maven-reactor-plugin for M2 served its purpose, which was to make it easier
to build pa
The maven-reactor-plugin for M2 served its purpose, which was to make it
easier to build partial subsets of Maven projects in Maven 2.0. In Maven
2.1, we added much of the functionality of maven-reactor-plugin as
command-line arguments to maven: --resume-from, --also-make,
--also-make-depend
Kristian Rosenvold wrote:
I will re-add your stuff, and I will also set it up to use my output
demultiplexer that causes output to appear in "normal" order.
Does the demultiplexer do anything in weave mode when threads=1? Does it
make the projects appear to unweave (as far as the log is conc
Kristian Rosenvold wrote:
The only significant difference between the weave mode and the regular
mode is that the complete execution plan is determined up-front. As a
consequence of this the ReactorArtifactRepository (line 83) is forced to
use compile output from upstream modules when in weave m
Kristian Rosenvold wrote:
In this process I removed your original implementation, simply because
it allowed me to work freely in simplifying my own implementation (and I
truly believe I managed to make some good simplifications). I also
considered that I'd re-add your implementation as a third s
1) I'm encountering some integration failures in my build at work when
using -Dmaven.threads.experimental=1; I'll try to turn them into proper
bugs in the next few days.
2) In the documentation on http://github.com/krosenvold/maven3/ it says
that it does not yet build Maven 3. Does this mea
+1
Jason van Zyl wrote:
Hi,
I have reviewed the patches for the parallel build support and I think they are
great.
I think we should just give Kristian access to work with Dan and other
developers who want to support this work.
+1
Thanks,
Jason
--
Igor Fedorenko wrote:
Out of curiosity, what kind of performance difference you get with this
optimization vs without it?
I originally checked this in because it made a huge difference at my
organization. My goal was to reduce the time required to do a "no op"
build.
Our multi-module buil
Niall Pemberton wrote:
On Mon, Nov 23, 2009 at 7:59 PM, Paul Gier wrote:
I wonder if we really need a full vote for every alpha. Especially if this
is going to happen every two weeks. Why not just vote for a 2 week alpha
release schedule and then don't do another vote until it's time for bet
Kristian Rosenvold wrote:
Ever since my git-fu got sufficiently strong I get this allergic rash
every time someone says "subversion". Anyone wishing to join can just
fork and we'll have some git-fun ;)
I'm on Windows; the best Windows git client (msysgit) is covered in poison
oak. ;-)
-Dan
ibuting
those specific tasks in a cluster. If you actually had a decent model of
inter-lifecycle phase dependencies (requiredForStarting between phases),
you could probably achieve good results by keeping lifecycle execution
centralized but ditributing plugin execution ?
I suppose I may be narro
I've been meaning to reply to your earlier emails (it's been a busy week);
to this I'll just say that moving the "test" phase after the "install"
phase is a fascinating idea, which I personally like, but it seems like a
big violation of the contract for the lifecycle, and I suspect it won't be
tom.bujok wrote:
It would be grate if somebody could give a little bit of feedback.
Sorry for not responding earlier.
I think the biggest concern here is backwards compatibility; this is a
puzzle that I don't think any of us have solved, and which blocks a LOT of
cool features we've conside
Jason van Zyl wrote:
Honestly there's not really any public proposal or design to look at
Got one now :-)
http://cwiki.apache.org/confluence/display/MAVEN/Experimental+Multithreading+Support
and I really think that we should try your branch against the
performance framework and make sure ev
ation.)
-Dan
Dan Fabulich wrote:
On Friday I was playing cowboy with my experimental thread support, but
here's a more formal proposal around parallel project support in Maven 3.0.
OUTSTANDING ISSUES
In my earlier revision 833566, I attempted to fix MNG-3004:
"Allow build lifec
I was waiting until alpha-3 was out to merge in the MNG-3004 branch.
MNG-3004 passes all ITs, including a few new ITs of the experimental
multithreaded mode.
Can we recut alpha-4 with MNG-3004 in it?
-Dan
-
To unsubscribe,
Brian Fox wrote:
Does that mean that changes that we make in the Apache trunk can
automatically break people's Eclipse builds out in the wild, even without an
official release?
No. Igor has to bundle them into M2e before it's directly used, so it
could break the next time we update. It's a ps
Jorg Heymans wrote:
Would the multithreading feature make it easier or harder to implement
something like [1], ie distribute the different modules of a reactor
build across different machines ? Or is it completely unrelated you
think ?
No harder, but not much easier. With that said, I do ha
Jason van Zyl wrote:
The trunk is now critical for M2Eclipse and anyone else who is embedding
and new features just aren't going in without adequate ITs.
m2eclipse depends on the Maven 3.0-SNAPSHOT trunk?
Does that mean that changes that we make in the Apache trunk can
automatically break pe
I don't appear to have the right to kick off the maven-3.0.x-ITs build on
the Hudson installation of grid.sonatype.org.
Can someone grant that right to the "dfabulich" user?
Thanks!
-Dan
-
To unsubscribe, e-mail: dev-unsubs
Jason van Zyl wrote:
It's not going in that fast.
Fair enough; that seems to be the consensus.
Sorry, but passing all the existing ITs is the first step and then there
is ITs for the feature you multi-threading feature itself.
I've got a couple of ITs for MNG-3004 parallel projects on my m
It's clear that the consensus is against landing MNG-3004 for alpha-3, so
I'll pull back.
I've tested alpha-3 against several builds and found it good, thanks to
Benjamin's quick bugfixing last week.
+1
Dan Fabulich wrote:
I just posted a proposal that the code I ch
I just posted a proposal that the code I checked in before this
announcement should make it in to alpha-3.
I think if I vote -1 that will veto the release. I don't think that's
professional (I did just break the build three days before the release
vote, and I'm still quite ashamed by it), s
On Friday I was playing cowboy with my experimental thread support, but
here's a more formal proposal around parallel project support in Maven
3.0.
OUTSTANDING ISSUES
In my earlier revision 833566, I attempted to fix MNG-3004:
"Allow build lifecycle to execute projects in parallel"
http://j
Benjamin Bentmann wrote:
Benjamin Bentmann schrieb:
So I wouldn't like to see such experiments on trunk, given we are trying to
stabilize it. Hence I created a branch with your changes and reverted them
on trunk.
In talking with Dan and Wendy on IRC I realized that my immediate reaction of
I fixed this issue in r808537 in 3.0 trunk and r808535 in 2.2.x.
I note that I fixed this in DefaultArtifactInstaller, which now lives in
maven-compat, suggesting that it has been deprecated for the future...?
Is there some similar code that needs to be updated in Mercury?
-Dan
Dan Fabulich
http://jira.codehaus.org/browse/MARTIFACT-19
DefaultArtifactInstaller should only overwrite files if timestamp has
changed
This bug seems really bad for performance in large reactor builds or even
just for builds with large jars/wars/assemblies. The fix appears to be a
one-line fix.
I'm s
+1 works on my favorite builds
John Casey wrote:
Hi everyone,
It looks like Maven 2.1.0 is ready to release.
You can try the binaries here:
http://tinyurl.com/maven-2-1-0-vote
(https://repository.apache.org/content/repositories/maven-staging-511ea882714d8b/org/apache/maven/apache-maven/2.1.0
Wendy Smoak wrote:
Unit tests run slower in Maven than in Ant
Surefire fills up /tmp with directories
Are there bugs filed for this? Do we think that the /tmp directories are
the cause of our perf troubles?
-Dan
-
To uns
The Maven team is pleased to announce the release of the Maven Reactor
Plugin, version 1.0.
This plugin can build a subset of interdependent projects in a reactor. It
should be useful in large reactor builds that include irrelevant stuff
you're not working on.
http://maven.apache.org/plugi
Result of take 2 voting:
Binding +1: Dan Fabulich, Brett Porter, Jason Van Zyl
Vote passed.
-Dan
-- Forwarded message --
Date: Tue, 23 Sep 2008 13:27:12 -0700 (PDT)
From: Dan Fabulich <[EMAIL PROTECTED]>
Reply-To: Maven Developers List
To: Maven Developers List
S
is working well for me now
>
>On 24/09/2008, at 6:27 AM, Dan Fabulich wrote:
>
>>
> Fixed the issue Brett found (I don't know why it worked at all on my
> machine), as well as tossing in a quick new feature MREACTOR-5 which
> allows you to resume a reactor:make bu
6 Sep 2008 18:53:41 -0700 (PDT)
From: Dan Fabulich <[EMAIL PROTECTED]>
Reply-To: Maven Developers List
To: Maven Developers List
Subject: [VOTE] Release maven-reactor-plugin 1.0
This plugin can build a subset of interdependent projects in a reactor. It
should be useful in large reactor
This plugin can build a subset of interdependent projects in a reactor. It
should be useful in large reactor builds that include irrelevant stuff
you're not working on.
http://maven.apache.org/plugins/maven-reactor-plugin/
A few important notes:
* This is maven-reactor-plugin's first offici
Maven Reactor Plugin is moving inexorably towards release. The next step,
I think, is to make a Jira project for it on jira.codehaus.org. Can
someone here take care of that?
-Dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
The install plugin at revision 693933 has a funny-looking dependency that
doesn't resolve on my machine
https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-install-plugin/pom.xml
org.apache.maven
maven-plugin-testing-harness
2.4-SNAPSHOT
test
That's st
James Carpenter wrote:
If I wait a few months will all my problems simply disappear with maven
magicially supporting what I need?
As Oleg pointed out: no. Even if Mercury landed today and it were
bug-free, you can bet that a significant portion of the Maven plugin
ecosystem wouldn't work pr
ping
-- Forwarded message --
Date: Wed, 27 Aug 2008 13:02:04 -0700 (PDT)
From: Dan Fabulich <[EMAIL PROTECTED]>
Reply-To: Maven Developers List
To: Maven Developers List
Subject: [VOTE] Graduate maven-reactor-plugin from sandbox
Some people are using the maven-reactor-
OK, OK, you're convincing me. I was just about to write up an e-mail
about how we don't have to do it as four codebases: since 2.1.0 would just
be like 2.0.10, we'd EOL 2.0.x immediately upon releasing 2.1.0, and put
all future bugfixes there. But that'll require a lot of arguing and
discussi
+1 to that. I think that's actually a big advantage.
-Dan
Wendy Smoak wrote:
On Fri, Aug 29, 2008 at 8:54 AM, Ralph Goers <[EMAIL PROTECTED]> wrote:
I would like to point out that if we go with option 1 then the lifespan of
2.1.x will almost certainly be very short.
This might not actually
OK, I've added fixes I care about.
-Dan
Dan Fabulich wrote:
-1, though I could be convinced to change my mind if we felt like we were in
a rush for some reason.
I found a number of documentation-level bugs that I think should be
straightforward to fix... I'm checking in a few
-1, though I could be convinced to change my mind if we felt like we were
in a rush for some reason.
I found a number of documentation-level bugs that I think should be
straightforward to fix... I'm checking in a few fixes now.
-Dan
Vincent Siveton wrote:
Hi,
We solved less than 20 issues
+0.5 We should release that code that we did all that RC testing on, right
away, and I don't care what we call it; I thought that was what John was
proposing in his earlier [PROPOSAL].
-Dan
Brian E. Fox wrote:
We've come this far, why not make 2.1.0 right now as we were doing
2.0.10? I don
Jason van Zyl wrote:
The method that we've pushed in a couple releases is a simple profile which
lists the staging repository where a test plugin has been deployed. The
profile can be generated with the release and it's a separate file, so you
just erase it when you're done with it. Think the
Some people are using the maven-reactor-plugin and they seem to like it.
http://maven.apache.org/plugins/maven-reactor-plugin/
It's at a point where I think it's basically ready to release, but I
assume it shouldn't be released from sandbox.
One weird thing about it is that three of its goal
The Maven team is pleased to announce the release of the Maven Invoker,
version 2.0.10
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.10
** New Feature
* [MSHARED
The vote passed: dfabulich, olamy, jvanzyl, jdcasey
I'll run the stage command now...
-- Forwarded message --
Date: Tue, 19 Aug 2008 13:00:19 -0700 (PDT)
From: Dan Fabulich <[EMAIL PROTECTED]>
Reply-To: Maven Developers List
To: Maven Developers List
Subject: [VO
I've always found it to be a hassle to test plugins that don't need to be
wired up in POM files, e.g. the archetype, dependency, scm plugins. I
find that to test them I have to create a dummy POM file with a
section, as described in our guide to testing staged
releases.
http://maven.apach
+1, new settings work for me!
Olivier Lamy wrote:
Hi,
The last release of maven-scm is now 14 months old.
I'd like to release maven-scm 1.1 which include two new providers git
and accurev and fix some issues.
We solved 41 issues :
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13984&
-0.
SCM-402 scm:checkin doesn't work on OS X 10.5 Leopard
http://jira.codehaus.org/browse/SCM-402
This breaks the release plugin on Leopard also. I'd mark it -1 if I
thought I had time to help fix it.
-Dan
Olivier Lamy wrote:
Hi,
The last release of maven-scm is now 14 months old.
I'd lik
-- Forwarded message --
Date: Tue, 19 Aug 2008 13:00:19 -0700 (PDT)
From: Dan Fabulich <[EMAIL PROTECTED]>
Reply-To: Maven Developers List
To: Maven Developers List
Subject: [VOTE] Release Maven Invoker version 2.0.10
Hi,
This release is to prepare for the release of
test times a little.
Dan Fabulich wrote:
A lot of good discussion here. Just as a reminder, my changes are one very
small check-in, in code that shouldn't have changed since August 12. It
should be easy to merge, or even to back out and reapply if for some reason
that were ne
A lot of good discussion here. Just as a reminder, my changes are one
very small check-in, in code that shouldn't have changed since August 12.
It should be easy to merge, or even to back out and reapply if for some
reason that were necessary.
http://svn.apache.org/viewvc?view=rev&revision=
To kick off a glorious new era of core features, I've checked in a first
attempt at adding a "make-like" mode to Maven. Basically it's just an
attempt to port maven-reactor-plugin into the core, described in more
detail here:
http://docs.codehaus.org/display/MAVEN/Make+Like+Reactor+Mode
Ne
David Blevins wrote:
I've hacked on some plugins before, but the surefire one seems a little more
complicated than the typical plugin. Anyone with some surefire expertise
interested in working on this?
This is filed as SUREFIRE-179. It has an old patch, and no integration
test. The patch
Hi,
This release is to prepare for the release of Maven Reactor Plugin.
We solved 1 issue:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761&styleName=Html&version=14495
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=tru
Jamie Whitehouse wrote:
Would it make more sense for the make.folders parameter to be named
make.modules to keep it consistent with the same concept in multi-module
builds?
I called it "folders" because you have the choice of specifying folder
names or artifact names with make.artifacts.
Ch
Nick Stolwijk wrote:
Shouldn't those examples include one or multiple goals and/or phases? Or
will it always execute install?
Yes, check out the examples here:
http://maven.apache.org/plugins/maven-reactor-plugin/examples.html
One example:
mvn reactor:make -Dmake.folders=barBusinessLogic -Dm
Tobias Gierke wrote:
First of all, thanks for your work on this plugin...it really eases the pain
;) As far as i know, no other plugin uses camel-case goal names. Wouldn't it
be more consistent to name them "make-my-changes" and "make-scm-changes" ?
Yup, I've already changed it:
http://maven
That's interesting, and makes me want to vote for dashes going forward.
(I'll admit that I was thinking of testCompile when I wrote my plugin, to
the extent that I was thinking of anything at all.)
For the record, the offending camelCase goals are:
compiler:testCompile
resources:testResources
packages/a-package,packages/b-package
At least at first, core would not include the new reactor:makeScmChanges
because that would require maven-core to depend on maven-scm.
-
-Dan
Dan Fabulich wrote:
FYI maven-reactor-plugin 1.0-SNAPSHOT has a site now:
http://maven.apache.org/plugins/mave
Wendy Smoak wrote:
On Sat, Aug 16, 2008 at 1:09 AM, Benjamin Bentmann
<[EMAIL PROTECTED]> wrote:
do we have an agreed naming convention for plugin goals? E.g.
reactor:makeMyChanges
and
dependency:purge-local-repository
obviously follow different rules. Having one naming style would ease
mem
Brett Porter wrote:
I'm seeing them on surefire-commits.
Could we just kill the separate surefire lists? surefire doesn't have
enough of its own traffic to warrant it.
-Dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
2.1 branch (when we decide to cut it from
2.0.10 or 2.0.9...not sure where the current one came from), this would
be perfect to fit in as a new feature. I don't want the new 2.1.0 to
grow into a monster so for example we could implement this and release
it, then we could add the parallel d
I've checked in a new plugin to the sandbox called the "Maven Reactor
Plugin". You can use it to build a subset of interdependent projects in a
reactor. It should be useful in large reactor builds that include
irrelevant stuff you're not working on.
It includes the following goals:
reacto
Brett Porter wrote:
3.0-alpha-1: released as is, with or without those few fixes I was looking at
getting in.
3.0-alpha-X: later introduce the mercury and SAT based stuff as an optional
component
3.0: when all the above is stable and the resolution method is selectable
Is that how everyone se
Oleg Gusakov wrote:
SAT based resolver in the sandbox branch works differently from the old one,
and as such - it may break a few builds that rely on bugs in the old
resolver.
I think we know it will break builds that rely on bugs in the old
resolver, right?
And we need to test is more th
Brett Porter wrote:
I haven't reviewed the patch, but the comments by Eric about what he did
sound quite reasonable to me.
Me, too.
- ensure that when deployed to the repository, it is *always* set. A POM in
the repository with a versionless-parent would be considered invalid (this is
the m
MNG-624 (automatic parent versioning) is far and away the most popular MNG
issue with 85 votes (the next highest has 57).
In June of last year, Jason evaluated the attached patch and found
problems with it, but the problems weren't specified in the bug
description.
Can we revive discussion
The Maven team is pleased to announce the release of the Maven Surefire,
version 2.4.3.
Maven Surefire is used during the "test" phase of the build lifecycle to
execute your unit tests. It supports JUnit 3 & 4 as well as TestNG, and
generates TXT, XML and HTML reports.
http://maven.apache
The release announcement template is here:
http://maven.apache.org/developers/release/releasing.html
It currently says:
You can run mvn -up to get the latest version of the plugin, or specify
the version in your project's plugin configuration:
org.apache.maven.plugins
maven-XXX-plugin
Y.
Raphaël Piéroni wrote:
+1 (obviously)
Dan, i will use the script after work.
where is fix-permission.sh located?
/www/people.apache.org/repo/m2-snapshot-repository/fix-permissions.sh
It was originally just for fixing permissions in the
m2-snapshot-repository, but now you can run it there an
I've rewritten fix-permissions.sh to use absolute paths for find and
chmod, and removed the "-user ${USER}" check. I believe this modified
script should be safe to be configured setuid root. That way, anybody
could run it and clean up anyone's fix-permissions errors, even if someone
else fo
Christian Edward Gruber wrote:
Moving on to future efforts, I added the final step in support for
setup/teardown of fixture in the PojoTestSet.
Patch appreciated; it will be considered for the next Surefire version.
I didn't know people really used the Pojo tests, partly because I've never
u
My stage:copy is failing with "override rw-r--r-- rafale/apcvs" prompts.
Please remember to run fix-permissions.sh when you do a Maven release.
-Dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail
Vote passed.
+1 binding: Dan Fabulich, Herve Boutemy, Brett Porter, Olivier Lamy,
Fabrizio Giustina
+1 non-binding: Dan Tran
I'll stage the artifacts.
-Dan
-- Forwarded message --
Date: Fri, 2 May 2008 14:14:19 -0700 (Pacific Daylight Time)
From: Dan Fabulich &l
elease Maven Surefire version 2.4.3
+1: tested on Maven core 2.0.10-SNAPSHOT: no problem
we solved 20 issues: 9 fixed issues were affected to 2.5, which was the
initial target. I reaffected them to 2.4.3.
Hervé
Le vendredi 02 mai 2008, Dan Fabulich a écrit :
Hi,
We solved 11 issues
Dan Tran wrote:
can i assume the snapshot is as good the staging one? .. I can have my
build to use it for a few days
Well, it's always better to use the real staging bits, blah blah blah but
I did a snapshot deploy about 30 seconds before I ran release:prepare, so
the snapshot build is prob
Hi,
We solved 11 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&styleName=Html&version=14255
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=10541&status=1
Staging repo:
http://people.apache.org/~dfab
Brett Porter wrote:
I thought I had commented on this at some point, but I don't really remember.
You're plan of action sounds correct if there's no way around it. You might
however look into the changes John made in 2.0.9 to separate CLI properties
from existing system properties - maybe we
The sad tale of SUREFIRE-491 began when I tried to fix SUREFIRE-121.
http://jira.codehaus.org/browse/SUREFIRE-491
http://jira.codehaus.org/browse/SUREFIRE-121
The request seemed innocent enough. Wouldn't it be cool if you could pass
system properties to your tests, like this?
mvn clean te
Jason Chaffee wrote:
Thanks Dan, I will take a look at it and make sure we are clear and
there aren't any misunderstandings before I make any more comments. :)
For future reference, this is SUREFIRE-457. Vote for it if you like, but
as far as I know, we can't fix it on the Surefire side (wi
Dan Fabulich wrote:
Jason Chaffee wrote:
I did not run your project.
Well, try it and get back to me. You can use that as a starting point for
reproducing the effect you actually want.
Oops, you can't, because the mailing list software stripped my attachment.
You can get a copy
Jason Chaffee wrote:
I did not run your project.
Well, try it and get back to me. You can use that as a starting point for
reproducing the effect you actually want.
-Dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For add
Jason Chaffee wrote:
Maybe our disconnect is about callbacks after the class vs. the method.
That could be where the misunderstanding is coming from.
Sure, that could be. I claim that logging per-method is *way* too much
logging. Don't you agree?
In JUnit we can log per-class or per-metho
Benjamin Bentmann wrote:
I noticed that Maven is using junit:3.8.1 quite everywhere for its tests
although a later maintenance release of the 3.x line exists with junit:3.8.2.
Is there a known issue with 3.8.2 that makes one stick to 3.8.1?
I think it's just that JUnit 3.8.1 was released in 2
+1
I was sure I was going to have to give a -1 because MSHADE-9 was marked
"Not reproducible", but I too can't reproduce it using this version; I
think/hope that this is because we upgraded our version of asm and that
took care of it. :-)
Brett Porter wrote:
Hi,
The Shade plugin is ready
Wendy Smoak wrote:
If you make a change to a plugin that affects the documentation (new
parameter, etc.,) you can publish the updated website along with the
snapshot jar with:
mvn deploy site:stage-deploy
I still can't get that to work. I was never able to use it for Surefire
2.4.2, even
The Maven team is pleased to announce the release of the Maven Surefire
Plugin, version 2.4.2.
http://maven.apache.org/plugins/maven-surefire-plugin/
You can run mvn -up to get the latest version of the plugin, or specify
the version in your project's plugin configuration:
org.apache.mav
cc: [EMAIL PROTECTED]
Dan Fabulich wrote:
I staged Surefire 2.4.2 last night about 12 hours ago; it still hasn't shown
up on repo1.
http://repo1.maven.org/maven2/org/apache/maven/surefire/surefire/
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/maven/sur
I staged Surefire 2.4.2 last night about 12 hours ago; it still hasn't
shown up on repo1.
http://repo1.maven.org/maven2/org/apache/maven/surefire/surefire/
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/maven/surefire/surefire/
This seems longer than usual. Is the rsyn
(ahem) It looks like I forgot to check in my PMC Member status. :-)
https://svn.apache.org/viewvc/maven/pom/trunk/maven/pom.xml?r1=587312&r2=629352&diff_format=h
Also, uh, Surefire 2.4.2 would be cool. [2.4.1 has that @aggregator bug
that Javadoc has, I'm sure we'd all hate that. ;-)]
-Dan
The updated version of the release process says to do a site:stage-deploy
after doing a site:deploy, to create a versioned staged website.
I'd never done that before; when I tried just now, I was prompted for a
password.
[INFO] Generate "Project Team" report.
Using private key: C:\Docum
+1. I just used it to stage Surefire 2.4.2; looks good to me.
-Dan
Wendy Smoak wrote:
I'd like to do the first release of the Maven Stage Plugin. This
plugin is already being used for Maven releases, and although it has
limited functionality, it seems to be stable.
There are four open issue
Vote passed.
+1 binding: Dan Fabulich, Arnaud Heritier, Wendy Smoak, Brett Porter
+1 non-binding: Sejal Patel, Fabrice Bellingard
I'll try and stage this now. [This will be a great opportunity to try the
new Stage plugin... ;-)]
-Dan
-- Forwarded message --
Date: Fr
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
As you might expect, all the good bugs were found in 2.4.1 [looks like
some folks were waiting for SP1 to start testing... ;-)]
We solved 5 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&styleName=Html&version=14062
There are still 44 issues left in JIRA:
http://jira
John Casey wrote:
I'm trying to document some of the design problems with sort of exotic plugin
use cases, things like aggregation and use of ${reactorProjects}, that we're
running into under the current setup. I have proposals to address most of the
issues, but I'd love to hear what you would
Jason Chaffee wrote:
I am pretty familiar with testng code, so I would like to look into this
further. Is it a correct statement to say that the output we are seeing
on the console is coming directly from testng?
No... Console output in Surefire is a bit strange. :-)
By default, Surefire f
Jason Chaffee wrote:
Hmmm, the bug says it is fixed in 2.4.1 and it still produces a single
suite file and single suite output to the console. I agree with you
Benjamin, I don't think Dan understood the problem and thus didn't
actually fix it. Instead, the fix was for the reporting.
SUREFIRE
1 - 100 of 198 matches
Mail list logo
