As I discuss in SUREFIRE-303, there appears to be no way to report JUnit 4
@Ignores, even in principle.
http://jira.codehaus.org/browse/SUREFIRE-303
I can't find ANY example of a JUnit XML file that lists out the ignored
tests anywhere on the web. Ant 1.7 just throws @Ignored tests away, as
Today I checked in an integration test for SUREFIRE-389
(IncompatibleClassChangeError when useSystemClassLoader=true). You get an
ICCE simply by running "mvn test -Dsurefire.useSystemClassLoader=true" on
the quickstart archetype; it's pretty bad.
The problem appears to be in the plexus-arch
Brett Porter wrote:
As for p-archiver, I'm inclined to try and remove it since it's just
assembling a very basic JAR.
Beware... manifest classpaths are surprisingly tricky to construct. They
have a lot of weird corner cases you have to take care of. (They must be
wrapped, wrapped lines mus
Dennis Lundberg wrote:
Hervé BOUTEMY wrote:
I fixed DOXIA-189 for newline problems: the unwanted newlines were added
after anchor, link, bold, italic and monospace tags.
[snip]
How come I don't receive any e-mail when you commit on doxia?
Is [EMAIL PROTECTED] moderated in any way?
I've bee
There are still three bugs targeted for 2.3.1. These bugs are there in
2.3 today, so I guess we could live with them for 2.3.1 and ship a fix in
2.3.2, but it sure would be nice to get those fixed.
I think the bugs are currently assigned to Brett. Brett, are you still
thinking about these
-0. I can try to fix the three open 2.3.1 bugs sometime this weekend; if
you can afford to wait that long, I think that'd be preferable.
-Dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMA
John Casey wrote:
Did we ever remove the dependency on plexus-archiver, so we are just creating
the manifest-only jar directly? I know you and I talked about it, Dan...I was
just wondering.
Nope. SUREFIRE-347 is "regression: plexus is not properly isolated" which
is what I'd wish we'd fix b
I recently added a bunch of integration tests for Surefire. These
integration tests automatically fork a separate Maven process to run real
Maven builds, like the Maven core integration tests do.
This naturally led me to wonder: Does Surefire (now) have reasonable code
coverage? Specifical
Dan Fabulich wrote:
I didn't realize that shade had a JIRA project at the time, so I didn't file
bugs... I'll file them now.
OK, I've filed bugs MSHADE-5 through MSHADE-9. MSHADE-9 [failure to shade
plexus-archiver (interfaces not properly shaded)] is the absolute
Daniel Kulp wrote:
2) What issues are known that still need fixing? (I fixed all the JIRAs
at http://jira.codehaus.org/browse/MSHADE)
Last time I used alpha-14 it was seriously broken. Specifically, it was
unable to shade plexus-archiver due to bugs in translating the interface.
I didn't
I just posted a long e-mail to surefire-dev about my findings re: Surefire
2.3.1, 2.4 and Shade. I won't repost it here, but here's the summary:
Summary: I think we're ready to release 2.3.1, because I can't reproduce
"regression" SUREFIRE-347, the only bug targeted for 2.3.1. I was able to
Surefire; with the
added integration tests we've covered 79.4% (87 classes, 3,323 / 4,187
elements). It also highlighted some key areas where we could add more
tests, which was exactly what I wanted.
-Dan
2007/12/7, Dan Fabulich <[EMAIL PROTECTED]>:
I recently added a bunch of in
+1. This works with the latest Surefire trunk. (It's a pity MSHADE-9 is
still broken, but I think it's OK for another alpha; we should fix it for
beta-1.)
-Dan
Mauro Talevi wrote:
As version 1.0-alpha-14 has been staged for release, I'd like to call a vote
for its release and the move out
Surefire trunk currently depends on a couple of SNAPSHOT versions that we
expect to be released in the next couple of days, but other than that, as
far as I know, there's nothing else standing in the way of a Surefire 2.4
release. It includes more than 50 bug fixes.
With that said, the more
Dan Tran wrote:
Can I assume you already have the latest 1.4 snapshot at Apache's
snapshot repository?
Yes, maven-surefire-plugin-2.4-20071210.231259-19 is latest right now.
(Its various other dependencies like surefire-api, surefire-booter, etc.
are all deployed at the same time.)
-Dan
-
Marat Radchenko wrote:
Exception in thread "main" java.lang.NoClassDefFoundError:
Yes, it sure is! I've been bitten hard by MSHADE-5, which I just
re-opened.
-Dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
least prevented
me from deploying a defective binary. I still don't see a great way to
resolve MSHADE-5 except to pursue a strategy like the one described in
MSHADE-7 (perhaps, as dkulp suggested, as an option).
I'm going to go try to do the deploy directly from people.apache.org now.
Dan Fabulich wrote:
Marat Radchenko wrote:
Exception in thread "main" java.lang.NoClassDefFoundError:
Yes, it sure is! I've been bitten hard by MSHADE-5, which I just re-opened.
OK, I've done the deploy from a Linux box to avoid MSHADE-5. The
currently deployed sn
Daniel Kulp wrote:
I changed the rename logic to do a whole bunch of fallback things if the
first rename fails. It first will try a gc to see if any Streams that
are holding it locked can be cleaned up. If that still fails, then it
will just copy the new file over the old file. Not ideal, b
Mauro Talevi wrote:
I've commented on MSHADE-7 - as far as I can tell, feature is already
implemented, via shadedArtifact attachment. Please try out the configuration
in:
MSHADE-7 is a very different feature from shadedArtifactAttached.
MSHADE-7 suggests that the generated classes just get
Fixed on my end (I think... this bug is finicky); try it on your end to
make sure I didn't break anything further?
-Dan
Dan Fabulich wrote:
Daniel Kulp wrote:
I changed the rename logic to do a whole bunch of fallback things if the
first rename fails. It first will try a gc to s
Daniel Kulp wrote:
OK. I fixed one more issue with it. Can you give it another try. :-)
Getting closer.
Yup, looks good to me. I've closed MSHADE-5 again.
-Dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additi
As you've all heard endlessly by now, we're running a lot of integration
tests in the new Surefire 2.4; these integration tests are currently
designed to just fork/run the current version of Maven (discovered from
the M2_HOME env var or an optional system property) on a set of checked-in
proj
Forgive me if I'm picking at a sore spot, but can someone help me
understand the difference/overlap between maven-invoker and
maven-verifier?
As I understand it, they both do roughly the same thing, except one of
them is a Maven plugin where you write your test in a goals.txt file +
beanshe
John Casey wrote:
What you're seeing as overlap is a mixture of concerns in the invoker
plugin. The verifications beanshell really needs to be migrated out to
some sort of proper integration-testing plugin (or, even better, a
plugin that unites invoker and verifier under a common
configuratio
+1 (for sure, this time!)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
John Casey wrote:
First things first. maven-invoker and maven-invoker-plugin are not
separate things. The maven-invoker-plugin uses maven-invoker, but
maven-invoker is meant to be a reusable library, not just a plugin.
I find this remark quite confusing... if one is a library, and one is a
p
John Casey wrote:
Not at all; I mean running the test. In order to run one of these tests
(which are orchestrated by something akin to the maven-verifier from a JUnit
or other java-driven test case), you must run JUnit or whatever, so you can
be sure you have the same options enabled, environm
nicolas de loof wrote:
I tried to look at maven-eclipse-plugin tests and was really confused on
it's testing framework complexity.
Am I right in thinking that right now it's using the
"maven-plugin-testing-harness?" (I've never understood that either,
though I haven't tried very hard.)
Wh
John Casey wrote:
On Dec 12, 2007, at 9:47 PM, Dan Fabulich wrote:
I tweak the test to add a MAVEN_OPTS environment variable, including the
-Xrunjdwp string. (It would be easy to add some sugar to Verifier and/or
Invoker to make this easier; I didn't want to go fooling around wit
nicolas de loof wrote:
shitty is a very simple way to it-test plugins.
So I've heard... But I've also heard good things about
maven-invoker-plugin. And I've said a lot of good things about
maven-verifier tests. Why use SHITTY and not one of the others?
Or, let me phrase my question a di
olivier lamy wrote:
But this means we have to wait the end of the discussions before
releasing something ?
No, don't wait. I haven't voted (I've never used Maven Invoker Plugin)
but these discussions shouldn't hold up the vote.
+0, if that helps. [I haven't tried the new version, but I'm
Hi,
Maven Surefire version 2.4 is on the runway. Hopefully folks have spent
some time trying out the SNAPSHOT version, because we expect ordinary
users to get auto-upgraded to version 2.4 when we decide to release.
This version fixes numerous long-outstanding bugs, notably in TestNG
suppor
Jason Chaffee wrote:
You can compile test classes and still use maven.test.skip=true if you
have the compliler plugin configured as followings:
maven-compiler-plugin
false
This works, but I think using -Dmaven.test.skip.exec=true is a
Jerome Lacoste wrote:
java.lang.NoClassDefFoundError:
org/apache/maven/surefire/util/NestedRuntimeException
Exception in thread "main"
.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:507)
Strange... Can you get any tests to work at all, even simple ones? (e.g.
use the quickstart
Stephen Connolly wrote:
Can we make the property shorter and easier to remember...
that's what I liked about the -Dtest=0 hack
Just for you, I've filed SUREFIRE-417 (Make new "skipTests" parameter to
replace skipExec). ;-)
I've got to fix SUREFIRE-416 anyway, and I'd forgotten that this ha
Jerome Lacoste wrote:
java.lang.NoClassDefFoundError:
org/apache/maven/surefire/util/NestedRuntimeException
Exception in thread "main"
.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:507)
It looks like:
http://jira.codehaus.org/browse/SUREFIRE-328
I can't reproduce this problem,
Thanks very much for working on this, Brett! This is a great document.
Brett Porter wrote:
Firstly - does that feature matrix look accurate to everyone involved in
this?
I do have some remarks, most of which are aimed towards improving
maven-verifier's grade.
1) This document draws a dist
Hi,
Maven Surefire version 2.4 is back on the runway. A handful of bugs were
fixed since the previous take, including SUREFIRE-416 (which blocked the
release).
Note that I'm still unable to reproduce SUREFIRE-328, which some people
claim to have seen in the wild. If you can reproduce it w
I knew it was a mistake to call a vote on the day after Christmas. ;-)
More votes, please! Currently it's just me and Marat Radchenko, both +1
non-binding.
-Dan
Dan Fabulich wrote:
Hi,
Maven Surefire version 2.4 is back on the runway. A handful of bugs were
fixed since the pre
I think this vote still hasn't quite passed yet, for lack of a third
PMC member...?
PMC +1: Jason Van Zyl, Vincent Siveton
Non-binding +1: Dan Fabulich, Marat Radchenko, Dan Tran, Mauro Talevi,
Jerome Lacoste, Oliver Lamy
-Dan
Dan Fabulich wrote:
Hi,
Maven Surefire version 2.4 is
Vote passed!
PMC +1: Jason Van Zyl, Vincent Siveton, Brian Fox
Non-binding +1: Dan Fabulich, Marat Radchenko, Dan Tran, Mauro Talevi,
Jerome Lacoste, Oliver Lamy
I'll update the repo (probably on Monday) and send out a notification that
I've done it.
This means that some people
Brett Porter wrote:
Hi Dan,
I'm just flipping back through the commits by way of a quick review and had a
question about this one.
Does TestNG set a default thread count once parallel is enabled?
I assume the problematic configuration is parallel = false + any thread
count, so maybe a bett
I'm blocked from releasing Maven Surefire due to permissions.
Right now it's every developer's responsibility to run fix-permissions
when he/she deploys. This creates a problem, because it's easy for
developers to forget to run the script and get other later developers in
trouble.
It seems
Jason van Zyl wrote:
I asked infrastructure and they basically told me to "go find out who is
causing the problem so you don't have to bother us". That's pretty much
verbatim.
I can ask again.
I feared that the cron job might be less palatable to infrastructure than
a simple setuid wrapper
I still can't release Maven Surefire today due to MSTAGE-4.
http://jira.codehaus.org/browse/MSTAGE-4
At first I'd assumed that there was just some bug with running it on my
personal Windows XP box, but today I tried running it from
people.apache.org and found that I reproduced the exact same
I don't have the right to edit this page, to add Surefire to "Recent
Releases":
http://docs.codehaus.org/display/MAVEN/Home
Could someone appropriate grant me the karma?
-Dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
The Maven team is pleased to announce the release of the Maven Surefire Plugin,
version 2.4
http://maven.apache.org/plugins/maven-surefire-plugin/
This version fixes numerous long-outstanding bugs, notably in TestNG support.
You can run mvn -up to get the latest version of the plugin, or speci
I approve of the idea of releasing another version of maven-shade-plugin,
but I don't think we should call it non-alpha until MSHADE-9 is fixed.
http://jira.codehaus.org/browse/MSHADE-9
If this were called 1.0-alpha-16, I'd give it a +1; as it stands, I have
to vote -1 (non-binding).
-Dan
Evan Worley wrote:
Does anyone have any examples or know how to construct negative integration
tests using the maven-integration-test-helper and it-verifier, or any other
component? I am trying to write an integration tests that validates that a
build fails when a test fails.
http://svn.apach
Responding out of order, techincal stuff first...
Daniel Kulp wrote:
The fact is MSHADE-9 is not something we can fix in maven-shade-plugin.
It's a bug in ASM and isn't fixable until they provide a fix. (unless
someone wants to jump into ASM code. I don't have the time.)
I'm not saying MSH
Milos Kleint wrote:
And some of them got hit by this one already:
http://jira.codehaus.org/browse/SUREFIRE-121
I've commited the hotfix.
I was a bit concerned about implementing SUREFIRE-121, but I only posted
about it on surefire-dev.
This hotfix switches from using System.getProperties t
Thanks for posting that, Benjamin. I've filed SUREFIRE-436 that we should
update the site documentation to include a more explicit debugging
tutorial (at least for debugging forked tests).
You both may note that I've posted a long rant about the bug Andreas is
interested in (SUREFIRE-433) o
Class path ordering is tricky, and changed recently. Benjamin Bentmann
provides a regression test in SUREFIRE-428.
However, I'm not certain if I should apply it in Surefire, because we use
those integration tests to verify backwards compatibility with older
versions of Maven.
My initial t
Benjamin Bentmann wrote:
I see. Now, if the user can provide an option to Surefire, indicating
that the unit tests do not have inter-class dependencies, wouldn't this
allow to get back the old behavior? I.e. enabling Surefire to pass test
classes individually into TestNG?
That option sounds
Steve Loughran wrote:
What I propose is that, in order to avoid destroying information, Surefire
should generate XML that looks like Example 7 (all-in-one-file), and not
try to fake it to look like Example 2 (one-file-per-class). (TestNG's
junit-like output also generates files like Example 7.)
Benjamin Bentmann wrote:
For my curiosity: What would be the benefit of setting up a hand-crafted
test suite? I am a lazy guy and prefer the dumb machine to do the nasty
things for me so I really like the idea of just dropping a test class into
src/test/java without bothering to additionally mai
With a change as big as Surefire 2.4, there turned out to be a few bugs
still lurking.
We solved 7 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10541&styleName=Html&version=14016
There are still 38 issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?
Fabrizio Giustina wrote:
while testing this I found http://jira.codehaus.org/browse/SUREFIRE-444
I verified that the bug was still in 2.4 and I am not sure how many
users can be affected... since it can breaks builds without providing
any useful information about the cause I'd like it to be incl
ndard Time)
From: Dan Fabulich <[EMAIL PROTECTED]>
Reply-To: Maven Developers List
To: Maven Developers List
Subject: [VOTE] Release Maven Surefire plugin version 2.4.1
With a change as big as Surefire 2.4, there turned out to be a few bugs still
lurking.
We solved 7 issues:
http://jira.cod
Jason van Zyl wrote:
Correct me if I'm wrong here Benjamin but I think he's talking about
stating what tests you want to run, and how they are grouped
declaratively. As a best practice don't use suites and come up with a
way in Surefire to group things and avoid grouping of things in code.
I
Dan Tran wrote:
-0
This may not be a blocking bug but It is a regresion since 2.4 where
my Spring JpaDao with embedded Derby test fails . Other databases are fine.
The exception is producable with 2.5-SNAPSHOT ( build from source ),
2.4.1-SNAPSHOT( at apache snapshot repo).
surefire 2.3 and 2
Jan Nielsen wrote:
Finding the definitive help information for a plugin should be
absolutely trivial and built-in; having the CLI option which give the
code-you-are-executing-right-now the ability to answer that question
avoids the issues we have today with multiple sources for a plugin with
Jason van Zyl wrote:
I'm not saying the CLI is a good option. I think it's a bad option. Keep this
out of the core. It's perfectly fine as a plugin.
I'll throw in my two cents and point out that while I basically agree with
this, I don't think the help plugin is adequately documented by the
Tim O'Brien wrote:
I'm sorry, hold on... starting stopwatch "mvn help:describe
-Dplugin=nifty -Dmojo=nifty -Dfull" - alright, I type fast, but that took me
10 seconds. Then I hit enter and a whole *crapload* of information zoomed
past. Ok, CTRL-R, mvn, adding a "| less". Ok, for some
Vote passed.
+1 binding: Dan Fabulich, Arnaud Heritier, Brian Fox, Lukas Theussl
+1 non-binding: Fabrizio Giustina, Nicolas de Loof, Mauro Talevi
-0 non-binding: Dan Tran
I'm going to try to stage this release today (though I'm predicting more
MSTAGE-4 and fix-permissions troubl
In Surefire 2.4, we stopped having surefire-booter depend directly on
plexus-archiver. We did that partly to workaround MSHADE-9 and partly to
simply reduce the number of dependencies in surefire-booter (which
unfortunately has to be in the classpath of the launched tests).
Our dependency o
Dumb question (possibly): what does the @aggregator annotation do,
exactly?
I read the doc here:
http://maven.apache.org/developers/mojo-api-specification.html
It says: "Flags this Mojo to run it in a multi module way, i.e. aggregate
the build with the set of projects listed as modules."
B
Max Bowsher wrote:
Daniel Kulp wrote:
Dan,
I'm cannot really answer the question about what @aggregator does, but I
can say the javadoc example is not a good one. There are many of us that
think the javadoc mojo should NOT have it and have our javadoc plugins
locked down to a previous ver
Stuart McCulloch wrote:
On 07/02/2008, Dan Fabulich <[EMAIL PROTECTED]> wrote:
Based on preliminary research, I hypothesize that @aggregator is simply
broken so it's therefore not needed on any plugin, including javadoc.
hmm, well I use @aggregator on some local mojos and it seems
Stephen Connolly wrote:
I would have expected that there would be two javadoc mojo's something
like javadoc:javadoc which just generates the javadoc for the current
module, and javadoc:unified-javadoc which would be an @aggregator mojo that
produces the unified javadoc of all child modules.
Vincent Siveton wrote:
Yep see for instance MJAVADOC-171
Based on some simple experiments on my machine, the fix for this is simply
to drop @aggregator; it's broken... (at least for reporting plugins that
fork lifecycles like javadoc, jxr and surefire), and its effect can be
easily simulate
I didn't know this, so I imagine others might not. The string "�" is
invalid XML. The character is simply not allowed in XML in any
representation. XML 1.0 standard blocks most of the characters under x20,
allowing only x9 xA and xD. XML 1.1 allows x1-x20, but still blocks x0.
http://www
Dan Fabulich wrote:
But neither does it seem right to insert "�" when it's illegal XML.
Notably, Java will cheerfully print � in XML if you tell it to do so, and
many parsers will figure out what to do with it just fine; the same applies
to "".
Notably, Java's
roadtripryan wrote:
I am trying to test using TestNG/Spring/ and Maven Surefire 2.4.1.
My test suite runs great from within eclipse as individual tests or as a
whole suite. When I try and run the tests in Maven Surefire, however, they
fail. It appears Surefire is not calling the correct @Before
Jason van Zyl wrote:
Where did you run into this?
One of our integration tests says:
junit.framework.Assert.fail("\u");
When it's as bald as that it's not very important, but it's considerably
more likely when you Assert.assertEquals(expected, actual) where they both
contain control cha
Jochen Wiedmann wrote:
As he wrote, these characters are illegal, regardless of encoding,
CDATA, and so on. XML is a text format and ASCII 0 is a binary
character.
The suggested way to embed binary data into XML is using the base64 encoding.
Apart from that, I do not understand the use case. W
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
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
Benjamin's links are the right place to start, though I might add that the
head of that thread is a really long e-mail from me that doesn't directly
address your question. The rest of the thread is about your question.
Executive summary: TestNG support was broken in Surefire 2.3.x; it only
wo
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
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
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
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. 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
(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
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
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
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
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
+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
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
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
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
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:
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
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
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
+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
1 - 100 of 198 matches
Mail list logo
