Multi-threaded Maven, skipped projects, "successful" build
Has anybody ever seen this before? I'm running Maven 3.04 with "--threads 16" on an AWS High-Memory Quadruple Extra Large Instance, and I'm getting weird build behavior: the build claims to have succeeded, but not all of the projects were finished building. This reactor summary below (censored for privacy) reports that the "build succeeded" but a dozen projects were marked "SKIPPED." The process ultimately returns with exit code 0, as if everything were fine, but you can see one last running unit test on the console *after* the reactor summary, before the whole process exits. What's going on here? Is there a good way to diagnose this problem? We can workaround it by not using multi-threaded builds, but that will seriously hurt our build performance. [INFO] [INFO] Reactor Summary: [INFO] [INFO] Full xx Build (Trunk) . SUCCESS [2.151s] [INFO] xxSearch .. SUCCESS [5.971s] [INFO] Group SUCCESS [0.708s] [INFO] xxx ... SUCCESS [6.142s] [INFO] xx.hibernateConfig SUCCESS [5.050s] [INFO] xx Public Test Data ... SUCCESS [2.717s] [INFO] xx Business Logic Build ... SUCCESS [0.395s] [INFO] xx Util Library (xx.util) . SUCCESS [20.003s] [INFO] xx.core.domain SUCCESS [24.734s] [INFO] xx Production Data SUCCESS [5.105s] [INFO] Assorted Build Tools .. SUCCESS [7.377s] [INFO] xx Data Layer Test Utilities .. SUCCESS [2:09.089s] [INFO] xx.core.dataAccess SUCCESS [7:45.951s] [INFO] xx Core Build . SUCCESS [0.730s] [INFO] xx.core.domain SUCCESS [2.868s] [INFO] xx Data Access SUCCESS [9.795s] [INFO] .. SUCCESS [17.346s] [INFO] emailService .. SUCCESS [6.925s] [INFO] xx Test Util (xx.testUtil) SUCCESS [1.848s] [INFO] xx Common Tests ... SUCCESS [1.796s] [INFO] xx Business Logic . SUCCESS [2:54.245s] [INFO] xx.crm.sforce.client .. SUCCESS [19.909s] [INFO] xx.crm.client . SUCCESS [15.082s] [INFO] Core .. SUCCESS [5.912s] [INFO] xx.crm.service.adapter SUCCESS [8.355s] [INFO] xx.core.mvc ... SUCCESS [36.263s] [INFO] xPlatform . SUCCESS [9.672s] [INFO] xx.Config . SUCCESS [4.311s] [INFO] xx.crm.job.proxy .. SUCCESS [4.591s] [INFO] xxx ... SUCCESS [27.871s] [INFO] x . SUCCESS [19.499s] [INFO] Active Aggregator SUCCESS [5.404s] [INFO] .. SUCCESS [14.795s] [INFO] .alerts ... SUCCESS [19.158s] [INFO] dataServices .. SUCCESS [0.713s] [INFO] xClient ... SUCCESS [7.120s] [INFO] xService .. SUCCESS [9.809s] [INFO] dataService Webservice SUCCESS [12.964s] [INFO] Imports ... SUCCESS [0.714s] [INFO] importerUtils . SUCCESS [26.396s] [INFO] xx Graph and ID importer . SUCCESS [6.891s] [INFO] Synchronizer .. SUCCESS [8.604s] [INFO] buildingImporter .. SUCCESS [3.855s] [INFO] cycleImporter . SUCCESS [19.862s] [INFO] xxxImporter ... SUCCESS [39.024s] [INFO] x . SUCCESS [6.838s] [INFO] propertyImporter .. SUCCESS [14.468s] [INFO] xxImporter SUCCESS [17.224s] [INFO] xxImporter SUCCESS [1:14.325s] [INFO] importerTools . SUCCESS [18.044s] [INFO] xx.alerts . SKIPPED [INFO] xxAggregator .. SUCCESS [8.655s] [INFO] com.xx.x .. SUCCESS [7.402s] [INFO] xx Datamover Core . SUCCESS
Re: [ANN] Maven Reactor Plugin 1.0 Released
Rodrigo Ruiz wrote: So, if you create an aggregation project and add the domain module and all those dependant applications to its modules section, it should work, shouldn't it? :-) Yes, but watch out for MREACTOR-1... you can't use ".." in your section with maven-reactor-plugin. (This is something I hope to fix at some point, possibly by generating a temporary POM file automatically.) -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Maven Reactor Plugin 1.0 Released
Wim Deblauwe wrote: 1) You spawn a different maven process are thoses processing using MAVEN_OPTS by default (most important would be the memory settings I have set)? Yes. It launches "mvn" with the current environment variables specified. 2) How does it know how to stop walking up the inheritance tree? What I mean is, why does not try to build hibernate for example (assuming my project depends on that)? Does there need to be a parent project with a section for it to work? Yes, it requires a section; it can only build projects specified in your modules list. (That's what a Maven "reactor" is: a multimodule build.) The reactor plugin has no way to build third-party libraries like Hibernate; it would have to pull the code down out from some remote SCM to do that. Would it work if I have a domain module which is used by several applications (but is just a dependency, not part of a multimodule build) to make that part of the chain (in either direction), if of course the source code is available on the building pc. Nope, a multimodule build is required here. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: reactor plugin "Embedded error: Roots differ"
Dan Fabulich wrote: Jorg Heymans wrote: The root-pom/pom.xml contains a modules section that just references the project modules ../modules Yup, this is a known bug MREACTOR-1 http://jira.codehaus.org/browse/MREACTOR-1 It'll be pretty tough to fix it, I think. :-( Wait, no, actually, I'm wrong. MREACTOR-1 is perfectly real, but the "Different roots" error you're getting is surprising to me; I can't reproduce it even following your directions. Note that, in the system you showed me, you should be able to go to the "modules" directory and do "mvn reactor:make -Dmake.folders=A/api" and get it to work. If that doesn't work, please put together a reduced test case (zip up a simplified set of Maven projects) and file a bug. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: reactor plugin "Embedded error: Roots differ"
Jorg Heymans wrote: The root-pom/pom.xml contains a modules section that just references the project modules ../modules Yup, this is a known bug MREACTOR-1 http://jira.codehaus.org/browse/MREACTOR-1 It'll be pretty tough to fix it, I think. :-( -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Maven Reactor Plugin 1.0 Released
Paul Benedict wrote: Congrats on the plugin. Could you maybe add to the plugin home page why this plugin is required or useful? What common problem is it trying to solve? It would be nice to know that background, because I am grasping to find its purpose. Which plugin home page do you mean? Do you mean this page? http://maven.apache.org/plugins/maven-reactor-plugin/ I feel like that page pretty clearly outlines what you can do with Maven Reactor Plugin. Does that not make (enough) sense? There's a more detailed explanation of use cases for the reactor plugin here: http://maven.apache.org/plugins/maven-reactor-plugin/examples.html And some of it is based on the page here: http://docs.codehaus.org/display/MAVEN/Make+Like+Reactor+Mode Hopefully the Examples page makes more sense... If the plugin still makes absolutely no sense after reading that stuff, let's chat on IRC or something and I'll try to figure out what to add. If, on the other hand, the Examples page makes perfect sense but the homepage makes no sense, I'd appreciate concrete suggestions on how to make the home page better. :-) -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Maven Reactor Plugin 1.0 Released
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/plugins/maven-reactor-plugin/ The Reactor plugin is normally run from the command line, like this: * reactor:resume resumes a reactor at a certain point (e.g. when it fails in the middle) Example: mvn reactor:resume -Dfrom=bar * reactor:make builds a project X and all of the reactor projects on which X depends Example: mvn reactor:make -Dmake.folders=foo,bar * reactor:make-dependents builds a project X and all of the reactor projects that depend on X (the reverse of reactor:make) Example: mvn reactor:make-dependents -Dmake.folders=foo,bar * reactor:make-scm-changes build all reactor projects that you personally have changed (according to SCM) and all reactor projects that depend on your changes Example: mvn reactor:make-scm-changes This is the first release of the Maven Reactor Plugin. Enjoy, -The Maven team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Maven Invoker 2.0.10 Released
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-54] - Invoker should provide support for "activateReactor" Enjoy, -The Maven team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
New sandbox plugin: maven-reactor-plugin
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: reactor:resume - resume a reactor at a certain point (e.g. when it fails in the middle) Example: mvn reactor:resume -Dfrom=bar reactor:make - build a project X and all of the reactor projects on which X depends Example: mvn reactor:make -Dmake.folders=foo,bar reactor:makeDependents - build a project X and all of the reactor projects that depend on X Example: mvn reactor:make -Dmake.folders=foo,bar (e.g. if foo depends on baz and quz depends on bar, :make will build foo,bar,baz whereas :makeDependents will build foo,bar,quz) reactor:makeMyChanges - build all reactor projects that you personally have changed (according to SCM) and all reactor projects that depend on your changes Example: mvn reactor:makeMyChanges All of these take an argument -Dmake.printOnly which you can use to see what the plugin would have done without actually doing it. (This is handy for debugging and exploration.) This plugin was easy to write, so I fear that it may duplicate other work, or that there may already be some clever command line tool to do this stuff. Feedback is appreciated. It seems to kinda-sorta work on my machine. The sources are here: https://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins/maven-reactor-plugin there are some TODOs: http://svn.apache.org/viewvc/maven/sandbox/trunk/plugins/maven-reactor-plugin/TODO.txt?view=markup I've deployed a snapshot: http://people.apache.org/repo/m2-snapshot-repository/org/apache/maven/plugins/maven-reactor-plugin/ If you want to try it on your machine, copy and paste this POM into a file (e.g. myfile.xml): http://maven.apache.org/POM/4.0.0"; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> 4.0.0 example example jar 1.0-SNAPSHOT example org.apache.maven.plugins maven-reactor-plugin 1.0-SNAPSHOT maven-plugin apache-snapshots http://people.apache.org/repo/m2-snapshot-repository/ Then run "mvn -U -cpu -f myfile.xml dependency:resolve". That should download the deployed snapshot into your local repository. Since it's a snapshot, you'll have to run it like this: mvn org.apache.maven.plugins:maven-reactor-plugin:1.0-SNAPSHOT:make -Dmake.printOnly -Dmake.folders=foo Please do that and e-mail me to let me know what breaks, or tell me that I'm an idiot. :-) -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mvn --reactor option
Stephen Connolly wrote:
Frickin' cool
I agree. It would be nice if the invoker supported it, too:
DefaultInvocationRequest.java:87
public InvocationRequest activateReactor( String[] includes, String[]
excludes )
{
throw new UnsupportedOperationException( "Not implemented yet." );
}
I've filed this as MINVOKER-54.
-Dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
mvn --reactor option
What does "--reactor" do on the mvn command line? The --help doc just says "Execute goals for project found in the reactor" which doesn't make much sense to me. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Creating an assembly with a symlink
Is there a way to create a symlink in a Maven assembly? How would I describe that in an assembly descriptor? -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Failing the build on dep convergence problems
This seems like a common/obvious request but a bit of googling didn't turn it up. At my work we're using the Dependency Convergence report to detect dependency conflicts. We'd like to fail the build if we don't have 100% dependency convergence on that report. I had hoped that I'd be able to do this using maven-dependency-plugin, but it's not obvious how to get it to do that. The "analyze-dep-mgt" is sort-of what I want, but not exactly, since I'm concerned about sibling conflicts as well as conflicts with the root POM's dependencyManagement section. (And anyway, I seem to be having problems with analyze-dep-mgt; when ignoreDirect is enabled it complains about dependency problems that I don't see in the Dependency Convergence report, and that don't show up with dependency:tree -Dverbose.) The Dependency Convergence report doesn't use maven-dependency-plugin, does it? How does it work? Can I make my build fail when that report says < 100%? -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [maven-surefire-plugin] problem with my tests
Guillaume Boucherie wrote: I have a strange behavior with my junit tests. I have a project with multi-modules. When I run the tests individually for module (mvn test) everything is ok. But when I run the tests from the parent pom (mvn test) I have always an error when my program try to parse an xml file. This doesn't immediately ring a bell; it seems impossible to diagnose it based on only this information. Try to create a reduced test case (a zip of minimal Maven projects that reproduce the problem) and file it as a bug. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Test classpath issue with v2.0.8 and v2.0.9
jlo_gestalt wrote:
When trying to access test resources in my unit tests, maven 2.0.8 and above
are returning the wrong directory.
Here is my basic code to access the folder
def file = new JmblXsltDriverTest().getClass().getResource("/")?.file
println file
On 2.0.7 this would print
/workspace/checkout/weather/trunk/jetjwis/jbi/jmbl-xslt/target/test-classes/
On 2.0.8 and 2.0.9 this prints
/workspace/checkout/weather/trunk/jetjwis/jbi/jmbl-xslt/target/classes/
To me this is a critical bug that would almost certainly cause every
projects unit tests that access test resources to fail.
I'm going to guess you're encountering the bug described here:
http://docs.codehaus.org/display/MAVENUSER/Classpath+Ordering+Bugs+in+Maven+Surefire
Upgrading Surefire will probably restore you to the correct behavior.
-Dan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Maven Surefire 2.4.3 Released
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.org/plugins/maven-surefire-plugin/ You can specify the plugin version in your project's plugin configuration: org.apache.maven.plugins maven-surefire-plugin 2.4.3 Surefire 2.4.3 requires Maven 2.0.6 or higher. Release Notes - Maven Surefire - Version 2.4.3 ** Bug * [SUREFIRE-264] - XRef links do not work with aggregated reports on windows * [SUREFIRE-423] - Output a title for the report * [SUREFIRE-440] - Fix serialization of File[] into properties for forked Surefire run * [SUREFIRE-459] - Integration test using Jetty and JSP 2.1 fails after update to maven-surefire-plugin 2.4 * [SUREFIRE-460] - surefire-api manifest content is wrong: it is a copy of commons-lang * [SUREFIRE-463] - ClassCastException when using testng suiteXmlFile and forkMode=always * [SUREFIRE-467] - NoSuchMethodError UrlUtils.getURL when using JDK3 for testing * [SUREFIRE-481] - java.lang.NoSuchMethodError when forking on a 1.3 JDK * [SUREFIRE-491] - All system properties from Maven process are copied to forked Surefire process * [SUREFIRE-492] - Allow "test" parameter to override suiteXmlFiles * [SUREFIRE-493] - UrlUtilsTest fails ** Improvement * [SUREFIRE-422] - Strip "Maven" from report title * [SUREFIRE-426] - Add german translation * [SUREFIRE-473] - Documentation for additionalClassPath feature * [SUREFIRE-474] - Allow TestNG to use its built-in HTMLReporter * [SUREFIRE-484] - Don't output empty tables * [SUREFIRE-485] - Support AntUnit XML output * [SUREFIRE-490] - Provide an option to use simplified classloading ** Task * [SUREFIRE-488] - Document TestNG listeners/reporters * [SUREFIRE-489] - Document classpath issues Enjoy, -The Maven team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Classpath Loader Differences between Surefire 2.3 and 2.4 causes tests to fail
Andreas Guther wrote: Does anyone have an idea how to solve this issue and get the classes back on the path under Surefire 2.4? This is a somewhat frequently asked question, so I've written a wiki article about it: http://docs.codehaus.org/display/MAVENUSER/Classloading+and+Forking+under+Maven+Surefire Executive summary: useSystemClassLoader changed between Surefire 2.3 and Surefire 2.4. The default was useSystemClassLoader=false, but now the default is useSystemClassLoader=true. If you're having problems, try turning it back off to see if that helps. I've also written another article about classpath ordering (not relevant to you, but it has come up a few times): http://docs.codehaus.org/display/MAVENUSER/Classpath+Ordering+Bugs+in+Maven+Surefire -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 (without re-introducing a bunch of evil TestNG bugs from Surefire 2.3). http://jira.codehaus.org/browse/SUREFIRE-457 I've also attached my sample project there. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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: http://www.theblackforge.net/tmphtml/testngListenerTest.zip -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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 additional commands, e-mail: [EMAIL PROTECTED]
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-method, but in TestNG we can only log per-method. I think that means we should complain to the TestNG team! :-) What do you think? -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Running two builds of the same branch simultaneously
Brian E. Fox wrote: Samuel Le Berrigaud wrote: 1. only run mvn verify, this way nothing gets installed into the local repository, This doesn't work in a multi-module reactor build where the modules depend on each other, does it? No, it will only work if you at least do compile (then a reference to /target/classes is passed instead of the jar) Huh? verify is after compile, right before install. (Actually, I did "package", then later tried "verify" to see if it would work; neither did.) Should that have worked? -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Running two builds of the same branch simultaneously
Samuel Le Berrigaud wrote: 1. only run mvn verify, this way nothing gets installed into the local repository, This doesn't work in a multi-module reactor build where the modules depend on each other, does it? I've got a project X that depends on project Y; project Y built (without installing anything in my local repo) but project X claimed that it couldn't find project Y. Is this even supposed to work? -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Running two builds of the same branch simultaneously
Wendy Smoak wrote: Not really. It's developer-specific, so it goes in settings.xml (or on the command line). Too bad... It wouldn't make sense in the pom, which needs to work for all developers. Sure it would; you'd set the local repo to be "./localrepo". -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Running two builds of the same branch simultaneously
Wendy Smoak wrote: You can use -Dmaven.repo.local=... to specify a different local repository on the command line. Is there some way to wire up a POM to make that be the default for my project? -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Running two builds of the same branch simultaneously
I'm working on a multi-module reactor project that has a long build. I'd like to be able to sync down two copies of trunk (X and Y), do a little bit of work in X, and start building X. While X builds, I'd like to go over to Y, do a little bit of work in Y, and kick off a build of Y. The problem with this is the local repository: my X changes may incorrectly commingle with my Y changes. Can anyone suggest a way to make this work? If possible, I'd prefer not to have to login to my box as two separate users to make this work. (FYI, I'm on Windows XP.) -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svnmerge and multi module parent pom version updates
Wendy Smoak wrote: What's happening exactly? I'm not familiar with the svnmerge tool. svnmerge.py is what you should use if you intend to merge branches. http://www.orcaware.com/svn/wiki/Svnmerge.py "svn merge" doesn't really work for anything but the simplest cases; it will be fixed in SVN 1.5, which is scheduled to be released someday, probably. ;-) http://www.javaworld.com/javaworld/jw-01-2008/jw-01-svnmerging.html?page=1 The moral of this story is that it should be possible to use the release plugin to increment version numbers without checking in to SCM. I've filed MRELEASE-324 on this. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is it possible to make some delaying between surefire plugin executions?
vetalok wrote: 1. Is it possible to add some delaying between few execution phases of surefire plugin, e.g 10 seconds (hsqldb says: ".lck file is locked by another process")? Not really. Much easier to add a "Thread.sleep()" line to your tests. 2. Is it possible to run my surefire executions in the same JVM across all executions?. You've already set forkMode=never, which should do that by virtue of never spawning another JVM. Do you find it's not doing that? -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Surefire 2.4.1 classpath order
Ben Lidgey wrote: Made the tests pass. I've no idea why. Do you want me to raise this as a bug? Yes... nice work! That sounds like a Core bug and not a Surefire bug, so file it against "Maven 2" (MNG) in JIRA. Thanks! -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [m208]surefire report error with site:deploy
That error certainly looks strange to me. I know that site:deploy can work because I just did a site-deploy with Surefire 2.4.2 for its release earlier today. Please file a bug with a minimal Maven project attached that reproduces this failure. (You can set it up to deploy to a file URL so the project can be simple and self-contained.) -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Maven Surefire Plugin 2.4.2 for Maven 2 Released
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.maven.plugins maven-surefire-plugin 2.4.2 Release Notes - Maven Surefire - Version 2.4.2 ** Bug * [SUREFIRE-445] - Surefire-Booter Manifest not correct * [SUREFIRE-449] - In multi-module projects, all tests are run for each module in the module tree * [SUREFIRE-452] - suitename always = "TestSuite" even if defined as property * [SUREFIRE-455] - XML delimiter characters in attribute and text content are escaped twice. ** Improvement * [SUREFIRE-451] - ManifestJarWriter should use java.util.jar.Manifest Enjoy, -The Maven team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Surefire 2.4.1 classpath order
Ken Liu wrote: Do you know if that bug was introduced in 2.0.7 (or some other earlier release)? I talked about two JIRA issues; their interactions are complex. SUREFIRE-61 is listed as affecting "2.0 (2.2 plugin)"; that means it has probably been around for a long time. MNG-3118 is an "Improvement" and not a "Bug"; it was filed in July of 2007, but for all I know Maven has been behaving the old bad way since 2.0.0. What's complex about this problem is that the two issues obfuscate each other. For many users, Maven was trying to use the "wrong" classpath, but Surefire was accidentally reversing it, resulting in the "right" classpath for some users. Since both bugs have been fixed in the latest versions of the software, people who get only one fix and not the other will suffer. :-( My team is using 2.0.4 and we encountered a problem with the classpath ordering recently that caused builds to that were previously working to suddenly start failing. If your project doesn't explicitly declare a version of Surefire, it will be automatically upgraded to the latest version (currently 2.4.1). The developers who designed that feature are very sorry about it. ;-) Based on what I think I know about this problem, you're probably being auto-upgraded to 2.4.1; Surefire 2.4.1 + Maven 2.0.4 = bad classpath ordering. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Surefire 2.4.1 classpath order
Ben Lidgey wrote: With target/classes before targe/test-classes. This is the reverse order from what it's supposed to be. Not only are test-classes supposed to appear before classes, but both of those are supposed to appear before your dependency jars. Looks like we'll need to try some more debugging. :-) 1) If you run mvn -X you'll see lots of useful debugging information, including the command line we used to launch Surefire. It looks something like this: Forking command line: cmd.exe /X /C '"C:\jdk1.5.0_12\jre\bin\java -jar C:\DOCUME~1\dan\LOCALS~1\Temp\surefirebooter61534.jar C:\DOCUME~1\dan\LOCALS~1\Temp\surefire61532tmp C:\DOCUME~1\dan\LOCALS~1\Temp\surefire61533tmp"' You may notice that none of your jars appear on this list; that's by design. Go take a look at the jar file and you'll see that it's a "manifest-only" jar; it contains only a META-INF/MANIFEST.MF file, specifying a Main-Class and a Class-Path to run the code. Make sure that the manifest looks correct and that the jars/dirs appear in the correct order. 2) Try pulling down our "classpath-order" test project here: http://svn.apache.org/repos/asf/maven/surefire/trunk/surefire-integration-tests/src/test/resources/classpath-order http://tinyurl.com/3csqca Run "mvn test" and confirm that you see the same thing I do in classpath-order/target/surefire-reports/TEST-it.BasicTest.xml. I get test-classes first, classes second, and then a whole bunch of jars. If the classpath order is incorrect, the test should fail. Hopefully, classpath-order will pass on your machine. If that's the case, then the next thing to do will be to investigate what's different between your Inuk projects and our classpath-order test. If classpath-order doesn't work on your machine, then I'll be surprised; I'm not exactly certain how to investigate that. You could try filing a bug in that case and attaching debugging information for the classpath-order test. To debug, we'd want: -X logs, a copy of your surefirebooter#.jar, and the two surefire#tmp files that are passed in as arguments. Good luck! -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Surefire 2.4.1 classpath order
Ben Lidgey wrote: We are running tests using Surefire 2.4.1 and Maven 2.0.8. [...] Looking at the debug output shows: [DEBUG] Test Classpath : [DEBUG] C:\Documents and Settings\benl\.m2\repository\junit\junit\4.2\junit-4.2.jar [more jars] [DEBUG] c:\Development\Projects\MyProject\target\classes [DEBUG] c:\Development\Projects\MyProject\target\test-classes Which would explain it. Is there anyway to get the test-classes before classes in the classpath order? Setting childDelegation to true doesn't. I'm not 100% certain you're using the software you think you're using; here's some debugging/analysis tips. Take a look at http://jira.codehaus.org/browse/MNG-3118. That bug was fixed in Maven 2.0.8 and called out in the release announcement as a backwards compatibility risk: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00432.html As noted in MNG-3118, Surefire 2.3 had a bizarre classpath ordering bug that made the test classpath appear to be correct (test-classes first) under Maven 2.0.7 for some users with large classpaths: http://jira.codehaus.org/browse/SUREFIRE-61 SUREFIRE-61 was fixed in Surefire 2.3.1. Notably, it would make the "Test Classpath" output in -X look correct, while secretly under the hood it would munge the classpath incorrectly! As a result, for at least one project here at my work, we've seen: Maven 2.0.7 + Surefire 2.3: test-classes before classes Maven 2.0.8 + Surefire 2.3: classes before test-classes Maven 2.0.7 + Surefire 2.3.1 or higher: classes before test-classes Maven 2.0.8 + Surefire 2.3.1 or higher: test-classes before classes Benjamin checked in a classpath ordering test in the Surefire trunk that we now run with every release. It's currently passing for me with Surefire 2.4.1 (and 2.4.2-SNAPSHOT) and Maven 2.0.8, and failing with Maven 2.0.7. Finally, note that your "real" classpath is being output in your target/surefire-reports/*.xml files as the "surefire.test.classpath" property; that may be useful for debugging purposes. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: changes to surefire output with testng
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 forks a single Java process to run all tests and begins gathering console output from that process. If you configure Surefire's output using redirectTestOutputToFile, we'll print it all out to a file, UNLESS the line begins with a special marker indicating that the console output is intended for Surefire, in which case we'll display it in the clear on the console. Hence, TestNG can print out "foo" and that will go to the file, but Surefire itself can print out "Tests run: 1, Failures: 0, Errors: 0 [...]". If you don't redirectTestOutputToFile, console messages from the forked process appear directly on the console, but we also take extra steps to strip out the special markers. Currently, Surefire only knows to log when TestNG calls us back. We register as an org.testng.IResultListener, so we get notifications when the run starts and finishes, and when an individual method starts and finishes, but not when the entire class starts and finishes. If TestNG notified us at the right time, we could log the right stuff. But I think this won't be an easy fix on the TestNG side, because TestNG runs stuff in a crazy order, by design. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: changes to surefire output with testng
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-433 was a separate problem. I think I understood Benjamin's problem (I think, Benjamin can decide) but chose not to fix it in Surefire. [I think this is really a TestNG feature; if it matters at all, the TestNG team should implement it.] I've filed bug SUREFIRE-457 so people can vote for if if they like. It's currently a "Wish" marked Minor and targeted for post 2.x "Future", meaning "Maybe someday, maybe never". ;-) -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: changes to surefire output with testng
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 worked in certain simple cases. In Surefire 2.4 we give more control over to TestNG, fixing the functional errors, but reducing our ability to log, because TestNG doesn't call us back at the right times. There is no option to switch back to the old mostly-broken behavior. If this feature matters (in the linked thread I argue that it doesn't matter very much) then users should pester the TestNG team to provide support for it, by creating an "onClassStart"/"onClassFinish" event that Surefire can use. -Dan Benjamin Bentmann wrote: Surefire-2.3.1 used to output which test was running and it would create an output file for each test. I am using testng. Can anyone tell me why this changed and if there is any way to configure it to behave in the same manner as previous releases? Nice to see I am not the only one who is missing that after trying Surefire 2.4 out... You might want to look at - http://jira.codehaus.org/browse/SUREFIRE-433 - http://www.nabble.com/Test-Suites%2C-Ant%2C-Surefire%2C-and-JunitReport-to15076378.html#a15076378 As a workaround, I tried to set forkMode=always to get test-per-class behavior back but ended again in some discussion: - http://jira.codehaus.org/browse/SUREFIRE-446 - http://www.nabble.com/testng%2C-surefire%2C-and-forkMode%3Dalways-to15323782.html Regards, Benjamin Bentmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Surefire not picking up tests from test-jar
Stephen Connolly wrote: Has anybody tried running a test-jar with Surefire 2.4.1? It's not picking up any of our unit tests from the test jar. We're using JUnit 4.4 (but the tests in the test jar are all JUnit 3.8.1) It's picking up the unit tests from src/test/java fine, but we have packaged our compatability tests are in a separate jar file so that they can be used across the two modules that must be compatable. When you say "with Surefire 2.4.1" do you mean that this used to work in an earlier version? Based on what I think I know about Surefire, it would surprise me if this ever worked. The algorithm for finding tests searches for .class files in target/test-classes. One workaround would be to use maven-dependency-plugin to unpack your test-jar(s) into the target/test-classes directory. If this is a regression, please file an issue in JIRA with a minimal Maven project that reproduces the problem. (In this case, I think the appropriate thing would be a simple reactor build that installs a test-jar in one sub-project and tries to run its tests in a second sub-project.) -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: surefire 2.4 + testng, changing "TestSuite" name
Erez Nahir wrote: Created http://jira.codehaus.org/browse/SUREFIRE-452 and provided fix for it as attachment. I saw your bug; it seems to fail some of the integration tests, so I'm not applying it right now. Can someone from surefire team clarify when is the next minor release of surefire-plugin planned? I don't think we have any schedules/plans, but you're in luck, because there's a handful of bugs that we found right around the time that 2.4.1 shipped. [Maybe people were waiting for the first service pack ;-)] If you can get me a patch that passes the tests in the next couple of days, I'll probably submit it. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Maven Surefire Plugin 2.4.1 for Maven 2 Released
Haroon Rafique wrote: For me when the error about "Failed to load Main-Class manifest attribute from /tmp/surefirebooter???.jar" appeared, I re-ran the tests with mvn -X and then opened up the /tmp/surefirebooter???.jar file. It is a .jar file with only one entry META-INF/MANIFEST.MF. Inside the MANIFEST.MF there are 2 entries. Class-Path and Main-Class. Sure enough, the file was in tact, yet surefirebooter would say it can't find the Main-Class. You can even try the actual "java -jar /tmp/surebooter???.jar ." command and it still failed. Looking a little bit more, I was able to extract the MANIFEST.MF file and change its format from "dos" to "unix" in vim and repackaged it back into a jar and sure enough the "java -jar /tmp/surefirebooter???.jar ." command was able to run. Ah, hearing that makes me strongly suspect that this is SUREFIRE-445 and SUREFIRE-451. http://jira.codehaus.org/browse/SUREFIRE-445 http://jira.codehaus.org/browse/SUREFIRE-451 Thanks for doing this research; I've moved these bugs into the upcoming 2.4.2 release. -Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Maven Surefire Plugin 2.4.1 for Maven 2 Released
The Maven team is pleased to announce the release of the Maven Surefire Plugin, version 2.4.1 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.maven.plugins maven-surefire-plugin 2.4.1 Release Notes - Maven Surefire - Version 2.4.1 ** Bug * [SUREFIRE-121] - System properties set on the command line get clobbered * [SUREFIRE-432] - Surefire swallows redirected test output if uncaught exceptions occur in forked SurefireBooter * [SUREFIRE-433] - All tests run in a single execution are reported as coming from just one class * [SUREFIRE-439] - Test listeners / reporters don't work with TestNG 5.7 * [SUREFIRE-444] - NPE in PojoStackTraceWriter.writeTraceToString ** Improvement * [SUREFIRE-425] - Add dedicated resource bundle for locale "en". ** Task * [SUREFIRE-428] - Add integration test to check class path order * [SUREFIRE-436] - Add documentation section on debugging tests Enjoy, -The Maven team - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
LayoutException working with SNAPSHOTs
I just filed MRM-674 which is preventing us from deploying our nightly build distribution with Archiva. I think this bug is a subtle dupe with MRM-632 and MRM-658. Put together, these bugs seem pretty serious for anyone using SNAPSHOT dependencies. It sure would be nice if somebody were to fix this bug soon-ish. -Dan
can't untar archiva with cygwin tar 1.18
I'm on Windows XP. Using cygwin tar 1.18, I find that I can't untar archiva; I get "A lone zero block at 49260". I've filed it as MRM-671. I've found the zip version, and I'm going to use it. But I've filed MRM-672 that the zip version should be more visible, because tar isn't very standardized across OSes... Linux tar can easily create archives that Cygwin tar won't extract, Solaris tar can get confused by long file names in GNU tar files, etc. -Dan
RE: [M2] FAQ? Debugging unit tests in Maven2
Probably what's happening is Maven is launching a second JVM to run your tests. If so, you can use -DargLine="=-Xdebug -Xnoagent -Djava.compiler=NONE -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=4657" to pass those arguments to the launched JVM. Alternately, you can set surefire to forkMode=never and then your MAVEN_OPTS trick will work just fine. -Dan > -Original Message- > From: matthewadams [mailto:[EMAIL PROTECTED] > Sent: Monday, October 23, 2006 3:46 PM > To: users@maven.apache.org > Subject: [M2] FAQ? Debugging unit tests in Maven2 > > > Hi, > > This seems to be a FAQ, and searches on this list seem not to yield > definitive answers. I have a plain old Maven2 project whose unit tests > I'd > like to debug using an IDE. I've tried launching Maven2 with debug > options > set, but I never hit any breakpoints that I've set after attaching the > debugger. Here's my handy dandy mvnd.bat file, to make things a bit > easier: > > setlocal > set MAVEN_OPTS=-Xdebug -Xnoagent -Djava.compiler=NONE > -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=4657 > call mvn.bat test > > Maven gets launched and waits for the debugger to attach on port 4657. > The > debugger attaches just fine, then the tests get run and my breeakpoints > never get hit. > > What do I have to do to get my breakpoints to work? Please help! > > --matthew > > PS: Once I get this question resolved, the next one has to do with > debugging my Maven2 plugin, which is used in this plain old Maven2 > project! > -- > View this message in context: http://www.nabble.com/-M2--FAQ---Debugging- > unit-tests-in-Maven2-tf2498076.html#a6963756 > Sent from the Maven - Users mailing list archive at Nabble.com. > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: selenium plugin?
In Selenium RC, you don't have to put Selenium into your WAR. You just run JUnit tests. Take a look here: http://www.openqa.org/selenium-rc/ -Dan -Original Message- From: Mick Knutson [mailto:[EMAIL PROTECTED] Sent: Friday, October 20, 2006 3:20 PM To: Maven Users List Subject: Re: selenium plugin? Where did you put selimuim then? I made a whole sub project for it and deploy a war file. Sounds like I went the wRong way. On 10/20/06, Dan Fabulich <[EMAIL PROTECTED]> wrote: > > In the latest version of Selenium (using Selenium Remote Control or > "RC") tests run in JUnit or TestNG... Maven already has plugins for > those. Just write your tests and use "mvn test" to run them. > > -Dan > > > -Original Message- > > From: Mick Knutson [mailto:[EMAIL PROTECTED] > > Sent: Friday, October 20, 2006 3:06 PM > > To: maven > > Subject: selenium plugin? > > > > Is this plugin available for maven 2? > > > > -- > > > > Thanks > > > > DJ MICK > > http://www.djmick.com > > http://www.myspace.com/mickknutson > ___ > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual > or entity named in this message. If you are not the intended recipient, > and have received this message in error, please immediately return this > by email and then delete it. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Thanks DJ MICK http://www.djmick.com http://www.myspace.com/mickknutson ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: selenium plugin?
In the latest version of Selenium (using Selenium Remote Control or "RC") tests run in JUnit or TestNG... Maven already has plugins for those. Just write your tests and use "mvn test" to run them. -Dan > -Original Message- > From: Mick Knutson [mailto:[EMAIL PROTECTED] > Sent: Friday, October 20, 2006 3:06 PM > To: maven > Subject: selenium plugin? > > Is this plugin available for maven 2? > > -- > > Thanks > > DJ MICK > http://www.djmick.com > http://www.myspace.com/mickknutson ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
