Re: Negative caching in the local repository?
Oops, that already got answered. Never mind. On 2006-06-05, at 11:02, Gordon Henriksen wrote: On 2006-06-03, at 00:05, Brett Porter wrote: These are all things I have given thought to and would like to see them worked on in Maven 2.1/2.2. There are a couple of jira issues already filed for some of these specifics. How about Pragma: no-cache…? — G - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Negative caching in the local repository?
On 2006-06-03, at 00:05, Brett Porter wrote: These are all things I have given thought to and would like to see them worked on in Maven 2.1/2.2. There are a couple of jira issues already filed for some of these specifics. How about Pragma: no-cache…? — G Begin forwarded message: Here's a GET that Maven 2.0.4 generated: GET /maven/mirror/ibiblio/org/apache/maven/plugins/maven-surefire- plugin/2.2-SNAPSHOT/maven-surefire-plugin-2.2-SNAPSHOT.pom HTT P/1.1 Pragma: no-cache User-Agent: Java/1.5.0_06 Host: example.com Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Connection: keep-alive Content-type: application/x-www-form-urlencoded Is there a way to disable the no-cache pragma? I set up a caching reverse proxy of ibiblio (i.e., a partial mirror), and was surprised when Maven disabled it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: Pragma: no-cache on GET requests?
This didn't get any traction on the users' list. Is there any way to moderate the cache control pragmas on Maven's GET requests? — G Begin forwarded message: From: Gordon Henriksen <[EMAIL PROTECTED]> Date: June 2, 2006 15:49:46 EDT To: Maven Users List Subject: Pragma: no-cache on GET requests? Reply-To: Maven Users List Here's a GET that Maven 2.0.4 generated: GET /maven/mirror/ibiblio/org/apache/maven/plugins/maven-surefire- plugin/2.2-SNAPSHOT/maven-surefire-plugin-2.2-SNAPSHOT.pom HTT P/1.1 Pragma: no-cache User-Agent: Java/1.5.0_06 Host: dev.manhunt.net Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Connection: keep-alive Content-type: application/x-www-form-urlencoded Is there a way to disable the no-cache pragma? I set up a caching reverse proxy of ibiblio (i.e., a partial mirror), and was surprised when Maven disabled it.
Negative caching in the local repository?
Since central is usually slow during the day, it can be pretty painful that Maven's local repository does not cache negative responses. Maybe Maven could stash away the URL and response date for 404's so that it won't try again for a day or two, unless forced to refresh? (5xx's should not be cached, though.) For instance, if the Eclipse plugin is configured to download the source jars, it tries to download the same archives every time, even though the source archives do not exist for many artifacts. During the day when central is overloaded, this means that generating Eclipse projects may take 5 minutes or more for even a moderately sized source tree. A similar situation occasionally happens if artifacts are missing pom files; xml-apis:xml-apis:1.3.03:jar has no pom, for instance, and our build winds up pinging that on a fairly regular basis, with an utterly predictable response. Would be nice if Maven could thread HTTP connections and pipeline HTTP requests when possible, too; that could hide some latency from central. If central is taking 3 seconds to respond to each GET, that adds up to 60 seconds pretty quickly. — G - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
project.encoding?
Seems a lot of hassle to configure character sets on various plugins individually. We use UTF-8 for everything (sources, resources). I'd rather be able to just say… UTF-8 Rather than having no option but to go configuring resource directories and the compiler and source reports… Is this already on the radar, or is it somehow a bad idea? — G - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: changing surefire defaults
On May 3, 2006, at 11:38 PM, Brett Porter wrote: It seems to be common to hit XML problems with surefire because it is using child first classloading (like a webapp) to ensure you get what you ask for which often causes xml problems because the apis are not in the same place as the implementation. I'd like to suggest we make two changes: - childDelegation = false as the default. Since the classloader is totally isolated, this is probably what people expect. - forkMode = once. Most runners (like IDEs) seem to fork and a once only fork has very little speed impact. I'm not as committed to this one, but it might still be a good idea. This would've saved me some headaches when adding coverage, and will allow me to remove this explicit configuration from all of my projects. +1 (nonbinding) and all that. — G - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] release Maven Surefire Plugin 2.2 and Surefire 2.0
Woohoo! +1 (non-binding) Just don't forget to strip out that isSnapshot() call on the surefire-2.0 branch… :) — G On May 1, 2006, at 1:29 PM, Brett Porter wrote: Please test this as much as you can first, given that the classloader has change somewhat. Vote open for 72 hours, based on: maven-surefire-plugin 2.2-20060501.172356-2 and 2.0-20060501.172351-2 (r398639) [ ] +1 [ ] +0 [ ] -1 http://jira.codehaus.org/secure/ReleaseNote.jspa? projectId=11148&styleName=Html&version=12207 http://jira.codehaus.org/secure/ReleaseNote.jspa? projectId=10541&styleName=Html&version=12440 * [MSUREFIRE-23] - Support TestNG * [MSUREFIRE-57] - Forking documentation improvement to help with class loader constrainst issues * [MSUREFIRE-59] - JUnitBattery dies when TestSuite has an anonymous inner class * [MSUREFIRE-62] - forkMode=pertest shows Results: line after every battery, not at the end. * [MSUREFIRE-63] - Surefire temporary files should be put in target rather than in the main project directory * [MSUREFIRE-65] - Surefire causes OOM * [MSUREFIRE-72] - [surefire-testng] SurefireReportMojo.executeReport() throws a java.lang.NumberFormatException * [MSUREFIRE-73] - systemClassLoader.getResource returns null * [MSUREFIRE-74] - IsolatedClassloader.getResources returns duplicated results * [MSUREFIRE-80] - systemProperties and NPE * [MSUREFIRE-86] - Surefire forking doesn't work on Java 1.3 * [MSUREFIRE-88] - Surefire fork fails under windows when command has several quotes * [MSUREFIRE-93] - maven-surefire-plugin:2.2-SNAPSHOT fails with invalid option -ea when forking to a JDK < 1.4 * [MSUREFIRE-94] - settting System property "basedir" is evil. * [MSUREFIRE-95] - java.lang.NoClassDefFoundError: org/apache/ maven/surefire/util/NestedCheckedException * [MSUREFIRE-96] - Sometimes xml report has no time atribute in testcase element * [MSUREFIRE-56] - The "pertest" option for forking mode should be renamed more appropriately * [MSUREFIRE-71] - System properties are not set * [MSUREFIRE-87] - Improve error stack trace when the error comes from the user's test code * [SUREFIRE-25] - surefire property droppings in fork mode * [SUREFIRE-30] - Wrong classpath separator * [SUREFIRE-33] - java.lang.ExceptionInInitializerError in TestCase constructor kills surefire without letting any log * [SUREFIRE-37] - System properties not working during forking [surefire-testng branch, patch attached] * [SUREFIRE-40] - memory leak in junit runner * [SUREFIRE-35] - refine use of assertion enablement - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Latest org.apache.maven.surefire:surefire-testng 404?
Snapshot 20060501.153032-1 works. Thanks! On May 1, 2006, at 10:56 AM, Gordon Henriksen wrote: On May 1, 2006, at 4:57 AM, Brett Porter wrote: Make sure you are using cvs.apache.org/maven-snapshot-repository as a snapshot repository, not snapshots.maven.codehaus.org. That's how the test project was configured. My live project also includes codehaus.org for Cobertura support. However, I'll sacrifice Cobertura for TestNG at the moment. I blew away my local repository just to make sure there wasn't any overlap. Try again now (I've upgraded to the release version of test NG). No improvement. I still get to the same point of failure—just that I don't have to manually deploy TestNG to get there, now. The missing surefire-testng snapshot now at 2.0-20060501.085606-5. That isn't coming from http://cvs.apache.org/maven-snapshot-repository/ org/apache/maven/surefire/surefire-testng/2.0-SNAPSHOT/maven- metadata.xml: org.apache.maven.surefire surefire-testng 2.0-SNAPSHOT 20060501.085606 3 20060501085948 Note the discrepency; mvn wants build number 5, but the testng provider is only at build 3. When I grep my repository for the timestamp and build 5… $ cd ~/.m2/repository $ grep -rl 2.0-20060501.085606-5 * org/apache/maven/surefire/surefire-api/2.0-SNAPSHOT/surefire- api-2.0-20060501.085606-5.pom org/apache/maven/surefire/surefire-api/2.0-SNAPSHOT/surefire- api-2.0-SNAPSHOT.pom org/apache/maven/surefire/surefire-booter/2.0-SNAPSHOT/surefire- booter-2.0-20060501.085606-5.pom org/apache/maven/surefire/surefire-booter/2.0-SNAPSHOT/surefire- booter-2.0-SNAPSHOT.pom Is surefire-api or surefire-booter trying to load a matching revision of the surefire-testng provider at runtime…? Sorry if that's nonsense; I just don't see where this version number is originating, since it's not obvious to me how it could be derived from the Maven dependency graph. — G — G - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Latest org.apache.maven.surefire:surefire-testng 404?
On May 1, 2006, at 4:57 AM, Brett Porter wrote: Make sure you are using cvs.apache.org/maven-snapshot-repository as a snapshot repository, not snapshots.maven.codehaus.org. That's how the test project was configured. My live project also includes codehaus.org for Cobertura support. However, I'll sacrifice Cobertura for TestNG at the moment. I blew away my local repository just to make sure there wasn't any overlap. Try again now (I've upgraded to the release version of test NG). No improvement. I still get to the same point of failure—just that I don't have to manually deploy TestNG to get there, now. The missing surefire-testng snapshot now at 2.0-20060501.085606-5. That isn't coming from http://cvs.apache.org/maven-snapshot-repository/org/ apache/maven/surefire/surefire-testng/2.0-SNAPSHOT/maven-metadata.xml: org.apache.maven.surefire surefire-testng 2.0-SNAPSHOT 20060501.085606 3 20060501085948 Note the discrepency; mvn wants build number 5, but the testng provider is only at build 3. When I grep my repository for the timestamp and build 5… $ cd ~/.m2/repository $ grep -rl 2.0-20060501.085606-5 * org/apache/maven/surefire/surefire-api/2.0-SNAPSHOT/surefire- api-2.0-20060501.085606-5.pom org/apache/maven/surefire/surefire-api/2.0-SNAPSHOT/surefire-api-2.0- SNAPSHOT.pom org/apache/maven/surefire/surefire-booter/2.0-SNAPSHOT/surefire- booter-2.0-20060501.085606-5.pom org/apache/maven/surefire/surefire-booter/2.0-SNAPSHOT/surefire- booter-2.0-SNAPSHOT.pom Is surefire-api or surefire-booter trying to load a matching revision of the surefire-testng provider at runtime…? Sorry if that's nonsense; I just don't see where this version number is originating, since it's not obvious to me how it could be derived from the Maven dependency graph. — G
Latest org.apache.maven.surefire:surefire-testng 404?
So this afternoon, the latest surefire snapshot landed and began to politely request that I update my dependency to TestNG 4.7 instead of 4.6.1 for TestNG support. Wishing to build, I did so. TestNG 4.7 isn't up on central, though, so I installed it in ~/.m2/ repository. That was a manual process since the install-file mojo doesn't seem to support qualifiers[1]. Now I arrive at the below impasse, where it seems surefire wants to load a particular and particularly nonexistant snapshot of surefire- testng. Specifically, org.apache.maven.surefire:surefire-testng:jar: 2.0-20060430.201643-4.[2] I'm not sure where this is coming from; it's not in maven-metadata.xml[3]. From my pom or my repository, can I demand the use of a particular snapshot as opposed to “latest” that doesn't exist? (Or, otherwise, can the missing artifact be deployed, or whatever is referencing it be removed? :) I've attached an example project that demonstrates this behavior. The dependency problems must be resolved first, though. — G [1] cp -R 4.6.1 4.7; then rm 4.7/*.{sha1,jar}. I then copied in the new jars and set /project/version to 4.7 and /project/dependencies/ dependency[artifactId=bsh]/version to 2.0b4. I did something similar for bsh-2.0b4, included in the TestNG distribution. Can I just copy those files to our internal repository for my co-workers, or do I need to use deploy-file…? [2] The error is as follows. I've attached -e -X output. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.apache.maven.surefire:surefire-testng:jar:2.0-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.maven.surefire - DartifactId=surefire-testng \ -Dversion=2.0-20060430.201643-4 -Dpackaging=jar -Dfile=/ path/to/file Path to dependency: 1) dummy:dummy:jar:1.0 2) org.apache.maven.surefire:surefire-testng:jar: 2.0-20060430.201643-4 -- 1 required artifact is missing. for artifact: dummy:dummy:jar:1.0 from the specified remote repositories: Maven Snapshots (http://cvs.apache.org/maven-snapshot-repository), central (http://repo1.maven.org/maven2) [3] http://cvs.apache.org/maven-snapshot-repository/org/apache/maven/ surefire/surefire-testng/2.0-SNAPSHOT/maven-metadata.xml reads org.apache.maven.surefire surefire-testng 2.0-SNAPSHOT 20060304.160715 2 20060304161101 testng-foo.tar.gz Description: GNU Zip compressed data typescript.gz Description: GNU Zip compressed data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[RESOLVED] Re: Horrible classloader things happening under Cobertura
On Apr 26, 2006, at 8:09 PM, Carlos Sanchez wrote: Check http://maven.apache.org/plugins/maven-surefire-plugin/test- mojo.html, childDelegation option Minutes too late! Found http://jira.codehaus.org/browse/MSUREFIRE-81… Agreed with the reporter… For any others, the fix is thus: maven-surefire-plugin + + + once + + false + — G - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Horrible classloader things happening under Cobertura
On Apr 26, 2006, at 6:13 PM, Mike Perham wrote: On Apr 26, 2006, at 4:47 PM, Gordon Henriksen wrote: Is this a FAQ that I haven't found? My tests run fine uninstrumented under mvn test, but fail in spectacular and surprising ways under Cobertura (triggered from mvn site). You haven't told us which version of the plugin you are running. The plugin is cobertura-maven-plugin-2.0-20060331.055400-6.pom. Maven itself is 2.0.3. At the end of this message are the relevant entries from my parent POM. The Cobertura plugin used to inject asm 2.1 into the project classpath which broke Hibernate projects. Are you using asm? I am not using asm. My instrumented and uninstrumented test results are the same if I add this to my pom: maven-surefire-plugin once So this seems to be a surefire issue, not a cobertura-plugin issue. — G 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";> … … org.codehaus.mojo cobertura-maven-plugin clean … … … org.codehaus.mojo cobertura-maven-plugin … Maven Snapshots http://snapshots.maven.codehaus.org/maven2/ … Maven Snapshots http://snapshots.maven.codehaus.org/maven2/ … - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Horrible classloader things happening under Cobertura
Is this a FAQ that I haven't found? My tests run fine uninstrumented under mvn test, but fail in spectacular and surprising ways under Cobertura (triggered from mvn site). — G --- Battery: net.mycorp.billing.CartTest --- Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.365 sec testCart(net.mycorp.billing.CartTest) Time elapsed: 0.327 sec <<< ERROR! [ stdout ] --- Cobertura: Loaded information on 4 classes. [ stderr ] --- [ stacktrace ] --- java.lang.NoSuchMethodError: net.mycorp.xmlutil.XmlUtil.getElements (Lorg/w3c/dom/Element;Ljava/lang/String;)[Lorg/w3c/dom/Element; at net.mycorp.billing.Cart.parseCart(Cart.java:52) at net.mycorp.billing.CartTest.testCart(CartTest.java:30) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:228) at junit.framework.TestSuite.run(TestSuite.java:223) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.battery.JUnitBattery.executeJUnit (JUnitBattery.java:242) at org.apache.maven.surefire.battery.JUnitBattery.execute (JUnitBattery.java:216) at org.apache.maven.surefire.Surefire.executeBattery (Surefire.java:215) at org.apache.maven.surefire.Surefire.run(Surefire.java:163) at org.apache.maven.surefire.Surefire.run(Surefire.java:87) at org.apache.maven.surefire.Surefire.run(Surefire.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.maven.surefire.SurefireBooter.main (SurefireBooter.java:785)
Re: [vote] Release Maven WAR plugin 2.0
On Apr 7, 2006, at 6:21 AM, Franz Fehringer wrote: what does "non binding" mean in these voting mails? http://www.apache.org/foundation/voting.html Often indicates that the voter is a user rather than a contributor. — G - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tests in a JAR file and surefire
On Mar 31, 2006, at 05:57, Tomasz Pik wrote: On 3/31/06, Carlos Sanchez <[EMAIL PROTECTED]> wrote: It means that test can be reused in other projects, so you can extend or use them from the tests in that project. What is the point of runing the same tests again in another project? For example when you want to test some implementations of given API. And tests 'bootstraps' implementation using some properties. Something like TCK for JAXP implementation for example, with tests starting with - Djavax.xml.parsers.DocumentBuilderFactory=my.jaxp.impl.DBF (I've never seen a TCK for JAXP but I can imagine that such approach for testing implementations makes sense). I can second the usefulness of this. Conformance tests in base classes are a very useful feature. I implemented these in a C# test harness at one point; the initial implementation was simply running all Test-annotated methods in non-abstract classes, regardless of whether the test methods were inherited or declared there. When I moved the unit tests to separate test assemblies, the pattern changed: Instead, a base class would come with an abstract test case: /* base.dll */ abstract public class Base { abstract public object Memento { get; set; } abstract public bool SharesMemento(Base b); } /* base_t.dll */ abstract public class BaseTest { abstract protected Base CreateBase(); [Test] public void TestMemento() { Base one = CreateBase(); Base two = CreateBase(); two.Memento = one.Memento; AssertTrue(one.SharesMemento(two)); AssertTrue(two.SharesMemento(one)); } } And the subclass would also author a derived test case: /* sub.dll */ abstract public class Sub : Base { static counter = 0; int token = counter++; override public object Memento { get { return (object) token; } set { i = (int) token; } } override public bool SharesMemento(Base b) { return b is Sub && ((Sub) b).token == this.token; } } /* sub_t.dll */ abstract public class SubTest : BaseTest { abstract protected Base CreateBase() { return new Sub(); } } Might a similar pattern work with surefire? base/ src/test/java/com/example/Base.java base-conformance-suite/ { depends: main } src/test/java/com/example/BaseConformanceTest.java sub/ { depends: base, base-conformance { scope: test } } src/main/java/com/example/Sub.java { extends: Base } src/test/java/com/example/SubTest.java { extends: BaseConformanceTest } I'm not sure if surefire will find the inherited test methods, though. Very excited about the TestNG support in surefire 2, BTW. Also, war merging will find use very swiftly indeed. — G - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: No luck running integration tests
On Mar 30, 2006, at 5:27 PM, Brett Porter wrote: I would suggest patching against the branch - there is a definite slow down on trunk at the moment. AOK—I'll do that. As for the wedge - does that happen repeatedly? Ugh, it finished this time, in about 2 minutes or so. I am not instilled with an overabundance of confidence! 96 still fails, but all the others passed on the second run. I had some issues the first couple times around, and I think they boiled down to the M2_HOME var. Seemed that the build succeeded, but all of the integration tests failed. If my sense is right, it might be worth noting in how-to-build-Maven-2 that the value is not discretionary, and must reflect ../maven-${version}. Or maybe bootstrap.sh should just pass along the correct value to ./maven-core- it.sh? — G - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
No luck running integration tests
I'm just trying to build m2's trunk locally so I can submit a patch. I followed the directions, but there seem to be something awry. First of all, each one of the integration test takes a bloody eternity to run. Like a minute. Second, it0094 is (still) wedged after 20 minutes! It's alive, but not burning any CPU. Below is: - My console log. - A list of processes on the wedged TTY. - SIGQUIT dump from the parent JVM. - lsof from the child JVM. Anything obviously wrong? — G $ uname -a Darwin Gordons-MacBook-Pro.local 8.5.2 Darwin Kernel Version 8.5.2: Mon Feb 13 16:31:48 PST 2006; root:xnu-792.8.37.obj~1/RELEASE_I386 i386 i386 $ java -version java version "1.5.0_05" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-84) Java HotSpot(TM) Client VM (build 1.5.0_05-51, mixed mode, sharing) $ cd ~/Source/maven $ svn co https://svn.apache.org/repos/asf/maven/components/trunk maven-components ... time passes .. Checked out revision 390223. $ cd maven-components $ export JAVA_HOME=/Library/Java/Home $ export M2_HOME="$HOME/Source/maven/maven-2.1-SNAPSHOT" $ export PATH="$PATH:$M2_HOME/bin" $ sh bootstrap.sh ... time passes .. Running maven-core integration tests ... Using default local repository: /Users/me/.m2/repository it0102... OK it0101... OK it0100... OK it0099... OK it0098... OK it0097... OK it0096... FAILED - Standard Out - Command: /Users/me/Source/maven/maven-2.1-SNAPSHOT/bin/mvn -e --no- plugin-registry --batch-mode -Dmaven.repo.local=/Users/me/.m2/ repository clean:clean package - Standard Error - Exit code: 1 >> Error Stacktrace: org.apache.maven.it.VerificationException at org.apache.maven.it.Verifier.executeGoals(Verifier.java:676) at org.apache.maven.it.Verifier.main(Verifier.java:856) << Error Stacktrace Log file contents: + Error stacktraces are turned on. [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: unknown Reason: Could not find the model file '/Users/me/Source/maven/maven- components/maven-core-it/it0096/project/project-level2/project-level3/ pom.xml'. [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Could not find the model file '/Users/me/Source/maven/maven-components/maven-core-it/ it0096/project/project-level2/project-level3/pom.xml'. at org.apache.maven.DefaultMaven.getProjects (DefaultMaven.java:365) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java: 278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:256) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced (Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode (Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.project.ProjectBuildingException: Could not find the model file '/Users/me/Source/maven/maven-components/ maven-core-it/it0096/project/project-level2/project-level3/pom.xml'. at org.apache.maven.project.DefaultMavenProjectBuilder.readModel (DefaultMavenProjectBuilder.java:1245) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileI nternal(DefaultMavenProjectBuilder.java:412) at org.apache.maven.project.DefaultMavenProjectBuilder.build (DefaultMavenProjectBuilder.java:190) at org.apache.maven.DefaultMaven.getProject (DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects (DefaultMaven.java:447) at org.apache.maven.DefaultMaven.collectProjects (DefaultMaven.java:491) at org.apache.maven.DefaultMaven.collectProjects (DefaultMaven.java:491) at org.apache.maven.DefaultMaven.collectProjects (DefaultMaven.java:491) at org.apache.maven.DefaultMaven.getProjects (DefaultMaven.java:351) ... 11 more Caused by: java.io.FileNotFoundException: /Users/me/Source/maven/ maven-components/maven-core-it/it0096/project/project-level2/project- level3/pom.xml (No such file or directory) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:106) at java.io.FileReader.(FileReader.java:55) at org.apache.maven.projec