Re: Strange ServiceLoader issue with Surefire and JDK 21 bytecode

On 2023-10-16T13:59:05 +0200 Romain Manni-Bucau wrote: > Yes, this is the one I had in mind, think it comes from plexus transitive > deps. For reference: org.apache.maven.plugins maven-surefire-plugin 3.1.2

Re: Strange ServiceLoader issue with Surefire and JDK 21 bytecode

Yes, this is the one I had in mind, think it comes from plexus transitive deps. Romain Manni-Bucau @rmannibucau | Blog | Old Blog | Github | LinkedIn

Re: Strange ServiceLoader issue with Surefire and JDK 21 bytecode

On 2023-10-16T08:14:40 +0200 Romain Manni-Bucau wrote: > Hi, > > Didn't check in details but it can be the bytecode reader version we have > today in surefire is too old to read java 21 bytecode so it does not put > your module on module path but classpath so then, without > META-INF/services/x

Re: Strange ServiceLoader issue with Surefire and JDK 21 bytecode

Hi, Didn't check in details but it can be the bytecode reader version we have today in surefire is too old to read java 21 bytecode so it does not put your module on module path but classpath so then, without META-INF/services/x file it is not detected. Romain Manni-Bucau @rmannibucau

Strange ServiceLoader issue with Surefire and JDK 21 bytecode

Hello! I'm seeing test failures when javac produces JDK 21 bytecode as opposed to JDK 20 bytecode: https://github.com/io7m/surefire-20231015 You'll need JDK 21. Essentially, `mvn package` will work, but `mvn -Dio7m.java.targetJavaVersion=21 package` will cause a test failure. The actual root s

Surefire and JUnit Categories - groups in reactor

Hi, I would lke to use the categories facility with JUnit 4.12 in a reactor project, I am finding some issue, but they seem to me so basic that maybe it is only a lack of documentation or that we can provide some minor fix in order to make life easier: 1) In a reactor a would like to run mvn test

Re: Maven Surefire and JUnit 5

JUnit project some while ago. They have in > the mean time updated their provider code. They are planning to bring those > changes back to surefire, once we get of the ground with the implementation > in surefire. So if you’re seeing difference in the implementation in > surefi

Re: Maven Surefire and JUnit 5

he code from the JUnit project some while ago. They have in the > mean time updated their provider code. They are planning to bring those > changes back to surefire, once we get of the ground with the implementation > in surefire. So if you’re seeing difference in the implementation in sur

Re: Maven Surefire and JUnit 5

ed the code from the JUnit project some while ago. They have in the mean time updated their provider code. They are planning to bring those changes back to surefire, once we get of the ground with the implementation in surefire. So if you’re seeing difference in the implementation in suref

Re: Maven Surefire and JUnit 5

M, Benedikt Ritter wrote: > Hello, > > for over a year now I’m trying to help getting JUnit 5 support into Maven > Surefire. This has been hard since Tibor seems to be the only one > maintaining Maven Surefire and he had to come with other things. > > For this reason I’d lik

Re: Maven Surefire and JUnit 5

ut having > > > to build jUDDI > > > > This is the wrong mailing list...Users list was the subject about jUDDI > > ;-).. > > > > Not related to Surefire and JUnit 5 ... > > > > Kind regards > > Karl Heinz Marbaise > > > Cheers >

Re: Maven Surefire and JUnit 5

did you try to update all of your maven plugins to latest version? > > > Can you share some stacktrace? This will give a first hint without > having > > > to build jUDDI > > > > This is the wrong mailing list...Users list was the subject about jUDDI > > ;-

Re: Maven Surefire and JUnit 5

gt; > Can you share some stacktrace? This will give a first hint without having > > to build jUDDI > > This is the wrong mailing list...Users list was the subject about jUDDI > ;-).. > > Not related to Surefire and JUnit 5 ... > > Kind regards > Karl Heinz Marbaise &g

Re: Maven Surefire and JUnit 5

;-).. Not related to Surefire and JUnit 5 ... Kind regards Karl Heinz Marbaise Cheers Enrico Il sab 30 set 2017, 10:34 Benedikt Ritter ha scritto: Hello, for over a year now I’m trying to help getting JUnit 5 support into Maven Surefire. This has been hard since Tibor seems to be the only

Re: Maven Surefire and JUnit 5

p getting JUnit 5 support into Maven > Surefire. This has been hard since Tibor seems to be the only one > maintaining Maven Surefire and he had to come with other things. > > For this reason I’d like to ask other Maven maintainers to help with the > JUnit 5 support. I’m happy

Maven Surefire and JUnit 5

Hello, for over a year now I’m trying to help getting JUnit 5 support into Maven Surefire. This has been hard since Tibor seems to be the only one maintaining Maven Surefire and he had to come with other things. For this reason I’d like to ask other Maven maintainers to help with the JUnit 5

Re: Surefire and Java 9

FYI, it's SUREFIRE-1262[1] where most of the details are for implementing this. Robert [1] htps://issues.apache.org/jira/browse/SUREFIRE-1262 On Wed, 05 Apr 2017 19:08:27 +0200, Jörg Schaible wrote: Hi Tibor, Tibor Digana wrote: Hi Joerg, We will continue on this issue after this re

Re: Surefire and Java 9

Hi Tibor, Tibor Digana wrote: > Hi Joerg, > > We will continue on this issue after this release. > Would you help us with your Java 9 knowhow? actually, I am completely lost with Java 9 for now. I simply assumed that someone managed to run the unit tests by now that opens access to some class

Re: Surefire and Java 9

Hi Joerg, We will continue on this issue after this release. Would you help us with your Java 9 knowhow? We have a ticket with Java9 issue in Jira. On Wed, Apr 5, 2017 at 11:32 AM, Jörg Schaible wrote: > Hi, > > does anyone already have a setup to execute surefire with Java 9 where the > tested

Surefire and Java 9

Hi, does anyone already have a setup to execute surefire with Java 9 where the tested code requires the opening of some modules? I already tried with different configuration stuff, but failed so far. Cheers, Jörg - To unsubsc

Re: [VOTE] Revert Surefire and commit to branches

If you are doing revert, there is no need for a vote. Just commit the reverts in reverse order. (If somebody objects then they can veto the revert commits ;-) as long as they provide a valid technical reason) The need for a vote is only if you want to do a reset. A reset makes it harder for other

Re: [VOTE] Revert Surefire and commit to branches

Git revert hash produces an inverse commit to hash. If from the 11 only one is bad, revert is your friend. If you want to get back to the same state, my options previously are required, not a single revert operation with just a hash supplied. man git revert && man git reset # :-) On Wed, Jan 18, 2

Re: [VOTE] Revert Surefire and commit to branches

For me it is useful to still see the history because we want to be motivated and open branches which fix the reverted commits. There are only 11 commits to revert. Few days ago, unlike in Maven. So pure git revert is fine. On Wed, Jan 18, 2017 at 6:01 AM, Fred Cooke wrote: > By revert do you me

Re: [VOTE] Revert Surefire and commit to branches

By revert do you mean reset --hard or keep the full history and rest the contents then re commit and verify with a diff to that hash? Or did you mean revert, each commit, in reverse order, back to that base? On Wed, Jan 18, 2017 at 5:43 PM, Tibor Digana wrote: > Hi, > > We have messed up Sure

[VOTE] Revert Surefire and commit to branches

Hi, We have messed up Surefire codeline and we want to revert to [1] where CI was stable. This enables us to continue with development. [1] 66bc4c0839ba11af7a8915930f76abf3cd58ee53 Vote open for at least 72 hours. [ ] +1 [ ] +0 [ ] -1

Re: Surefire and low memory conditions

> It would be quite simple to have a thread in the forked process > simply pulsing a heartbeat back to the plugin ? > > And if 3 heartbeats are missed, we simply kill it ? (Pardon the pun ;) Yeah, I sort of have that already but not in a background thread form (it's a longer story). Anyway, a back

Re: Surefire and low memory conditions

when running under low memory. > > Anyway, out of curiousity I checked with surefire and it seems to hang > for me (Windows, 8 core cpu). The code is here. > https://github.com/dweiss/surefire-hardtests > > The single-threaded version says the forked VM shut down without > saying

Re: Surefire and low memory conditions

r leichten Manipulierbarkeit von > E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. > > From: dawid.we...@gmail.com > > Date: Wed, 2 Jan 2013 09:33:20 +0100 > > Subject: Surefire and low memory conditions > > To: dev@maven.apache.org > > > > Hi. Just

Re: Surefire and low memory conditions

kung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen > wir keine Haftung fuer den Inhalt uebernehmen. > > From: dawid.we...@gmail.com >> Date: Wed, 2 Jan 2013 09:33:20 +0100 >> Subject: Surefire and low memory conditions >> To: dev@maven.apache.org >&

RE: Surefire and low memory conditions

onditions (and signal it back as such to the controlling process). > Seems to be quite hard because various JVMs appear to go crazy > themselves when running under low memory. > > Anyway, out of curiousity I checked with surefire and it seems to hang > for me (Windows, 8 core cpu)

Surefire and low memory conditions

hard because various JVMs appear to go crazy themselves when running under low memory. Anyway, out of curiousity I checked with surefire and it seems to hang for me (Windows, 8 core cpu). The code is here. https://github.com/dweiss/surefire-hardtests The single-threaded version says the forked VM shut

enforcer:enforce and not forking lifecycle for surefire and cobertura?

I've got enforcer up and running, but now I am pushing releases (via Jenkins) I have noticed in the build output : INFO] [INFO] Forking My Project X.Y.X-SNAPSHOT [INFO]

Surefire and java 1.3, SUREFIRE-621

I started digging deeper into this issue, and it turns out that java 1.3 support last functioned in surefire 2.2. The plexus-utils dependency has been 1.4-dependant since 18 june 07, and currently has some fairly heavy 1.4 dependencies. Now 1.3 has been EOL'ed for 5 years. It's not as if the issu

[surefire] and

Hi. I have a requirement to use a javaagent and system properties in the same test run. I found out about the properties mentioned in the title, but here is what I noticed (mvn 2.2.1): - to be able to use the agent () JVM has to be forked, but then are not set - when never javaagent naturally doe

Re: Surefire and non-jar artifacts

On 16 February 2010 07:48, Stephen Connolly wrote: > Just to clarify what I am suggesting: > > Plan 1 - which I have rejected on the basis that I feel it is > un-Maven-like... if somebody who has a strong opinion on the > architecture and direction of Maven feels that it actually is a > Maven-like

Re: Surefire and non-jar artifacts

Just to clarify what I am suggesting: Plan 1 - which I have rejected on the basis that I feel it is un-Maven-like... if somebody who has a strong opinion on the architecture and direction of Maven feels that it actually is a Maven-like way, then perhaps we should reconsider: Add an additional dep

Re: Surefire and non-jar artifacts

Sent from my [rhymes with tryPod] ;-) On 15 Feb 2010, at 19:23, David Jencks wrote: Recall that a conformant rar file has all its classes in embedded jar files, so putting the "outside" actual rar file on the classpath doesn't give you access to any classes. If you put classes "loose"

Re: Surefire and non-jar artifacts

Recall that a conformant rar file has all its classes in embedded jar files, so putting the "outside" actual rar file on the classpath doesn't give you access to any classes. If you put classes "loose" inside a rar then a compliant j2ca container will probably ignore them. On Feb 15, 2010,

Surefire and non-jar artifacts

Hi, So the lovely JCA resource adapters (a.k.a. rar files)... In Maven 2.0.9, these were added to the classpath In Maven 2.2.1, these are no longer added to the classpath... The former made testing resource adapters easy, but causes issues when packaging a resource adapter in an EAR... The lat

RE: surefire and testng integration issues with surefire-2.4.2

ps clear up any confusion. Thanks, Dana H. P'Simer Dana.P'[EMAIL PROTECTED] -Original Message- From: Dan Fabulich [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2008 1:25 PM To: Maven Developers List Cc: [EMAIL PROTECTED]; Maven Users List Subject: Re: surefire and testng int

RE: surefire and testng integration issues with surefire-2.4.2

--Original Message- From: P'Simer, Dana (Matrix) [mailto:Dana.P'[EMAIL PROTECTED] Sent: Thursday, March 20, 2008 11:03 AM To: Maven Users List; Maven Developers List Cc: [EMAIL PROTECTED] Subject: RE: surefire and testng integration issues with surefire-2.4.2 I think part of the di

RE: surefire and testng integration issues with surefire-2.4.2

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

RE: surefire and testng integration issues with surefire-2.4.2

Users List Subject: Re: surefire and testng integration issues with surefire-2.4.2 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 actua

Re: surefire and testng integration issues with surefire-2.4.2

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 here:

Re: surefire and testng integration issues with surefire-2.4.2

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

Re: surefire and testng integration issues with surefire-2.4.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

RE: Re: surefire and testng integration issues with surefire-2.4.2

behavior still works as expected. -Original Message- From: Dan Fabulich [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2008 10:18 AM To: Maven Developers List Cc: [EMAIL PROTECTED]; Maven Users List Subject: Re: surefire and testng integration issues with surefire-2.4.2 Jason Chaffee wrote

RE: RE: Re: surefire and testng integration issues with surefire-2.4.2

Users List Subject: RE: Re: surefire and testng integration issues with surefire-2.4.2 I did try it. I created my own listener and got the exact output I was looking for. I am not sure where our disconnect is here, but we certainly are seeing two different things with respect to the code

RE: Re: surefire and testng integration issues with surefire-2.4.2

, March 20, 2008 10:05 AM To: Maven Developers List Cc: Maven Users List; [EMAIL PROTECTED] Subject: Re: surefire and testng integration issues with surefire-2.4.2 Jason Chaffee wrote: > I brought this up in the past the maven guys were adamant that they were > not able to get per test informat

RE: surefire and testng integration issues with surefire-2.4.2

rom me, but I think it is worthwhile to have the maven developers hear critical feedback from time to tome. -Original Message- From: P'Simer, Dana (Matrix) [mailto:Dana.P'[EMAIL PROTECTED] Sent: Thursday, March 20, 2008 6:39 AM To: Maven Users List; Maven Developers List Subject:

RE: surefire and testng integration issues with surefire-2.4.2

-Original Message- From: Jason Chaffee [mailto:[EMAIL PROTECTED] Sent: Thursday, March 20, 2008 5:32 AM To: Maven Developers List Cc: Maven Users List Subject: surefire and testng integration issues with surefire-2.4.2 I brought this up in the past the maven guys were adamant that they w

surefire and testng integration issues with surefire-2.4.2

I brought this up in the past the maven guys were adamant that they were not able to get per test information to output on the console unless testng changed. I felt all along that this was not correct and I finally had a chance to look into it. Surefire could simply register a listener to get cal

surefire and testng integration issues with surefire-2.4.2

I brought this up in the past the maven guys were adamant that they were not able to get per test information to output on the console unless testng changed. I felt all along that this was not correct and I finally had a chance to look into it. Surefire could simply register a listener to get cal

Re: Test Suites, Ant, Surefire, and JunitReport

dfabulich wrote: > > Inter-class dependencies are one of TestNG's fundamental features > Use of this feature is optional. For my sake, call it an "abuse" of TestNG if I run that simple unit tests without inter-class dependencies ;-) dfabulich wrote: > > [...] but TestNG is meant to support

Re: Test Suites, Ant, Surefire, and JunitReport

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

Re: Test Suites, Ant, Surefire, and JunitReport

ounds really confusing. What would you call it? How would you document it? You'd have to know a lot about the guts of Surefire and TestNG for an option like that to make much sense. Not to mention that it'd be error prone. Developer X would assess the tests, verifying that the

Re: Test Suites, Ant, Surefire, and JunitReport

dfabulich wrote: > > Typically it's used for slow tests; you can identify a subset of tests > that you want to run and just run those. (You can even pull just one > method from Class X, and another method from Class Y, and so on.) > Thanks for the explanation. To me, this seems more useful f

Re: [testng-users] Re: Test Suites, Ant, Surefire, and JunitReport

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.)

Re: Test Suites, Ant, Surefire, and JunitReport

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

Re: [vote] replace surefire and surefire plugin trunk with test NG branches

> > > -Original Message- > > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > > Sent: Saturday, March 04, 2006 8:09 AM > > To: Maven Developers List > > Subject: Re: [vote] replace surefire and surefire plugin trunk with test > > NG branches > >

Re: [vote] replace surefire and surefire plugin trunk with test NG branches

Tue but can test later on and report my > experience. > > -Original Message- > From: Jason van Zyl [mailto:[EMAIL PROTECTED] > Sent: Saturday, March 04, 2006 8:09 AM > To: Maven Developers List > Subject: Re: [vote] replace surefire and surefire plugin trunk with

RE: [vote] replace surefire and surefire plugin trunk with test NG branches

pers List Subject: Re: [vote] replace surefire and surefire plugin trunk with test NG branches Brett Porter wrote: > Hi, > > I've been doing the revolutionary thing with surefire. The branch is > now working for pojo, junit and testNG tests, under all 3 fork modes. > Some ot

Re: [vote] replace surefire and surefire plugin trunk with test NG branches

Brett Porter wrote: Hi, I've been doing the revolutionary thing with surefire. The branch is now working for pojo, junit and testNG tests, under all 3 fork modes. Some other bugs have been fixed, the surefire and junit classloaders are separate to avoid plexus-utils and junit version cl

Re: [vote] replace surefire and surefire plugin trunk with test NG branches

bugs have been fixed, the surefire and junit classloaders are > separate to avoid plexus-utils and junit version clashes (this doesn't > happen for test ng yet), and the test suite runners are now in the > provider structure so you don't have to use testng if you don't wa

[vote] replace surefire and surefire plugin trunk with test NG branches

Hi, I've been doing the revolutionary thing with surefire. The branch is now working for pojo, junit and testNG tests, under all 3 fork modes. Some other bugs have been fixed, the surefire and junit classloaders are separate to avoid plexus-utils and junit version clashes (this doesn

[m2] surefire and commons-logging problem

Hello, I have a problem with running surefire tests when I have commons-logging in my classpath. I get java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory. I am subscriber of this list and I think I saw a solution here (adding something to the commons-logging...???) but

[result] Re: bringing surefire and doxia to Maven

Brett, Carlos, John, Jason, Arnaud, Emmanuel, Vincent S, Fabrizio: +1 Kenney, Vincent M, Trygve: +0 Dave Sag, Eric Pugh both spoke positively but didn't cast a numberical vote. Jason is discussing this with Infrastructure, and I have reviewed the IP clearance template to check everything is ok.

Re: bringing surefire and doxia to Maven

Kenney Westerhof wrote: On Tue, 1 Nov 2005, Brett Porter wrote: +0. I believe these projects are not technically maven related, and hence do not require to be in the m2 repository. There is a distinction between Maven the build tool and Maven the Apache project. Both tools fall within the m

Re: bringing surefire and doxia to Maven

On Tue, 2005-11-01 at 13:10 +0100, Kenney Westerhof wrote: > On Tue, 1 Nov 2005, Brett Porter wrote: > > +0. +0 myself, I agree with Kenney's arguments. > > I believe these projects are not technically maven related, and hence do > not require to be in the m2 repository. It would be the same as

Re: bringing surefire and doxia to Maven

Would surefire or doxia ever be used outside of the Maven2 world? I can actually see doxia being used elsewhere, but would surefire? Having some set of code that Maven uses over on Codehaus, when it is all developed by Maven committers and tightly intertwined seems odd. If there isn't a g

Re: bringing surefire and doxia to Maven

+1 Emmanuel Brett Porter a écrit : Hi, Doxia and Surefire were small projects started at Codehaus to experiment with new technology that has since been used from Maven 2.0. With one recent exception the committer set are entirely Maven committers. Doxia is the underpinnings of the site plu

Re: bringing surefire and doxia to Maven

On Tue, 1 Nov 2005, Brett Porter wrote: +0. I believe these projects are not technically maven related, and hence do not require to be in the m2 repository. It would be the same as moving classworlds to maven2, except we know classworlds is also used by other projects. To promote usage of these c

RE: bringing surefire and doxia to Maven

big +1 Cheers, Vincent > -Original Message- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: Monday, October 31, 2005 8:15 PM > To: Maven Developers List > Subject: bringing surefire and doxia to Maven > > Hi, > > Doxia and Surefire were small proj

Re: bringing surefire and doxia to Maven

On 11/1/05, Brett Porter <[EMAIL PROTECTED]> wrote: > Since the code is our own work, it is easy to bring here, and the > development can be more easily worked with alongside the primary uses > and discussion can happen in one place. + 1000! fabrizio -

RE: bringing surefire and doxia to Maven

+0 -Vincent > -Original Message- > From: Brett Porter [mailto:[EMAIL PROTECTED] > Sent: mardi 1 novembre 2005 02:15 > To: Maven Developers List > Subject: bringing surefire and doxia to Maven > > Hi, > > Doxia and Surefire were small projects started at Co

Re: bringing surefire and doxia to Maven

good idea. Kind regards, Dave Sag   Brett Porter <[EMAIL PROTECTED]> wrote on 01/11/2005 02:15:12 AM: > Hi, > > Doxia and Surefire were small projects started at Codehaus to experiment > with new technology that has since been used from Maven 2.0. > > With one recent exception the comm

RE: bringing surefire and doxia to Maven

+1 Arnaud > -Message d'origine- > De : Brett Porter [mailto:[EMAIL PROTECTED] > Envoyé : mardi 1 novembre 2005 02:15 > À : Maven Developers List > Objet : bringing surefire and doxia to Maven > > Hi, > > Doxia and Surefire were small projects started a

Re: bringing surefire and doxia to Maven

On Tue, 2005-11-01 at 12:15 +1100, Brett Porter wrote: > Hi, > > Doxia and Surefire were small projects started at Codehaus to experiment > with new technology that has since been used from Maven 2.0. > > With one recent exception the committer set are entirely Maven committers. > > Doxia is th

Re: bringing surefire and doxia to Maven

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 +1 Brett Porter wrote: | Hi, | | Doxia and Surefire were small projects started at Codehaus to experiment | with new technology that has since been used from Maven 2.0. | | With one recent exception the committer set are entirely Maven committers

Re: bringing surefire and doxia to Maven

+1 On 10/31/05, Brett Porter <[EMAIL PROTECTED]> wrote: > Hi, > > Doxia and Surefire were small projects started at Codehaus to experiment > with new technology that has since been used from Maven 2.0. > > With one recent exception the committer set are entirely Maven committers. > > Doxia is the

bringing surefire and doxia to Maven

Hi, Doxia and Surefire were small projects started at Codehaus to experiment with new technology that has since been used from Maven 2.0. With one recent exception the committer set are entirely Maven committers. Doxia is the underpinnings of the site plugin, and is used to generate document

Re: issues with 1) forking surefire and 2) Surefire's IsolatedClassloader class

On Sat, 1 Oct 2005, Andy Glick wrote: Hi Andy, > I've been working on adding forking to the surefire plugin, really into the > surefire package, in order to allow clover to work and to allow our > implementation to offer features similar to those provided by the JUnit Ant > task > > I've run into

issues with 1) forking surefire and 2) Surefire's IsolatedClassloader class

I've been working on adding forking to the surefire plugin, really into the surefire package, in order to allow clover to work and to allow our implementation to offer features similar to those provided by the JUnit Ant task I've run into a number of problems: 1) on windows using both plexus.