Re: Question about Maven2 and Heap Space
Sure, I already did that a couple of times. The more important and complex part actually resides in the release:prepare goal. Release:perform is basically just a svn checkout from the freshly created tag (during the prepare) followed by a mvn deploy run from the checkouted directory. Cheers. 2009/6/8 Ryan Moquin > Ok, if I do just a mvn:deploy with 1024MB of memory, it fails at the same > spot with what I think is the same stack trace: > > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] Java heap space > [INFO] > > [INFO] Trace > java.lang.OutOfMemoryError: Java heap space > at java.util.Arrays.copyOf(Arrays.java:2786) > at > java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94) > at > sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61) > at > org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:492) > at > org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:457) > at > org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:411) > at > org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:392) > at > org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:365) > at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:160) > at > > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:262) > at > > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:172) > at > > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:107) > at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:190) > at > > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371 > ) > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) > at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) > 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:597) > 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) > [INFO] > > [INFO] Total time: 28 minutes 3 seconds > [INFO] Finished at: Mon Jun 08 16:10:21 EDT 2009 > [INFO] Final Memory: 459M/992M > [INFO] > > > If I use 1284 with either goal (release:perform or deploy), my project > fails > a lot sooner with an OOME at growableArray.cpp (at that point the heap is > only at 500MB) .. which makes no sense since with deploy only one JVM is > running at 1284 and fails, but with release:perform using 1024, there are > two JVMs running with 1024MB of memory.. so something has to be wrong with > the JVM with that much memory. > > Once again, once the checkout is done in target, can I just do a mvn deploy > on the individuals modules to effectively finish the release:perform? It's > the only way I'm going to be able to finish my release. > > Thanks, > Ryan > > On Mon, Jun 8, 2009 at 11:51 AM, Ryan Moquin > wrote: > > > It looks like it does fork since if I use jconsole, I will get a second > JVM > > that has identical properties as the first. Part of the issue with this > is > > I notice that both JVMs will have the amount of memory I specify for > > MAVEN_OPTS. In the above case, 1GB. If I run release:perform, the > forked > > J
[ANN] Build Helper Maven Plugin 1.3 Released
The Mojo team is pleased to announce the release of the Build Helper Maven Plugin version 1.3. http://mojo.codehaus.org/build-helper-maven-plugin/ Some notable features in this release include: - A new goal to retrieve the current version of Maven to a property. - A new goal to parse the current project version into it's components (major version, minor version, etc) - A new goal to add resources to a project A comprehensive list of changes is attached at the end of this mail. To get this update, simply specify the version in your project's plugin configuration: org.codehaus.mojo build-helper-maven-plugin 1.3 Please allow up to 24 hours for the new release to synchronize with the central repository. Regards, The Mojo team. Release Notes - Maven 2.x Build Helper Plugin - Version 1.3 ** New Feature * [MBUILDHELPER-4] - build-helper-maven-plugin: Add resources * [MBUILDHELPER-9] - New Mojo to store the maven version in a property * [MBUILDHELPER-10] - Add mojo to set properties containing parsed project version string - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to specify no snapshots?
> How do I specify that I don't want any snapshots if a version is not > specified for a plugin? You can't. Ranges are also a bad idea as they can pull in Snapshots. Therefore, lock down the plugin version in the pom with [1.1.0] etc. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Get Maven's Error Message
Hello All,
I'm running Maven programatically in Java, so the point is to build the
projects (run the pom file), so every time a build process fails, I want to
get this error message! Somehow I can get an error message, for my example,
it returns: "class org.apache.maven.shared.invoker.DefaultInvocationResult"
which is a generic error message, while in the console, there is this error
message: "Error occurred during initialization of VM
java.lang.OutOfMemoryError: unable to create new native thread" And this is
the error I'm interested in getting (the same as the console/terminal)!
I'm getting this generic error msg from the "result.getClass().toString()",
I also tried to get an error msg from
"result.getExecutionException().toString()" but it always raises "Exception
in thread "main" java.lang.NullPointerException"
So I was wondering if there is a special method to get the same error msg
that shows in the terminal (console).
Here is a peace of my code:
request.setGoals(Collections.singletonList("install"));
Invoker invoker = new DefaultInvoker();
File mavenHome = new File(mavenHomePath);
invoker.setMavenHome(mavenHome);
InvocationResult result = null;
request.setProperties(mavenProperty);
try {
result = invoker.execute(request);
} catch (MavenInvocationException e) {
db.insertBuildData(Integer.toString(revisionNumber), "NO",
e.toString());
e.printStackTrace();
}
if (result.getExitCode() != 0) {
db.insertBuildData(Integer.toString(revisionNumber), "NO",
result.getClass().toString());
}
Cheers,
--
David Nemer
Sent from Kaiserslautern, RP, Germany
Re: Question about Maven2 and Heap Space
Ok, if I do just a mvn:deploy with 1024MB of memory, it fails at the same spot with what I think is the same stack trace: [INFO] [ERROR] FATAL ERROR [INFO] [INFO] Java heap space [INFO] [INFO] Trace java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2786) at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94) at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61) at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:492) at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:457) at org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:411) at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:392) at org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:365) at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:160) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:262) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:172) at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:107) at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:190) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371 ) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) 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:597) 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) [INFO] [INFO] Total time: 28 minutes 3 seconds [INFO] Finished at: Mon Jun 08 16:10:21 EDT 2009 [INFO] Final Memory: 459M/992M [INFO] If I use 1284 with either goal (release:perform or deploy), my project fails a lot sooner with an OOME at growableArray.cpp (at that point the heap is only at 500MB) .. which makes no sense since with deploy only one JVM is running at 1284 and fails, but with release:perform using 1024, there are two JVMs running with 1024MB of memory.. so something has to be wrong with the JVM with that much memory. Once again, once the checkout is done in target, can I just do a mvn deploy on the individuals modules to effectively finish the release:perform? It's the only way I'm going to be able to finish my release. Thanks, Ryan On Mon, Jun 8, 2009 at 11:51 AM, Ryan Moquin wrote: > It looks like it does fork since if I use jconsole, I will get a second JVM > that has identical properties as the first. Part of the issue with this is > I notice that both JVMs will have the amount of memory I specify for > MAVEN_OPTS. In the above case, 1GB. If I run release:perform, the forked > JVM is maxed at 1 GB of memory when the error occurs. > > I did try to run the JVM with 1284 MB for the maven instance (which is the > highest I can run it where the JVM will start), but in that case, my build > dies sooner because it can't allocate enough memory for the forked > instance. The initial instance of Maven2 only uses 40K of memory, so it's > unnecessary for it to have as much memory as the spawned process. The > server I'm building on, has 4GB of physical memory, but apparently enough > isn't available to have the initi
Re: Question about Maven2 and Heap Space
It looks like it does fork since if I use jconsole, I will get a second JVM that has identical properties as the first. Part of the issue with this is I notice that both JVMs will have the amount of memory I specify for MAVEN_OPTS. In the above case, 1GB. If I run release:perform, the forked JVM is maxed at 1 GB of memory when the error occurs. I did try to run the JVM with 1284 MB for the maven instance (which is the highest I can run it where the JVM will start), but in that case, my build dies sooner because it can't allocate enough memory for the forked instance. The initial instance of Maven2 only uses 40K of memory, so it's unnecessary for it to have as much memory as the spawned process. The server I'm building on, has 4GB of physical memory, but apparently enough isn't available to have the initial Maven2 instance and the spawned one both running at 1284MB of memory. Other than checking out the tag, is the only other thing that the release:perform does is a "deploy"? Ryan On Mon, Jun 8, 2009 at 10:35 AM, Baptiste MATHUS wrote: > Interesting. The artifact you're trying to deploy is 350MB+ large. > Could you please try and just "mvn deploy" your project? > > I don't remember is the release plugin forks or not. > > My 2 cents, > Cheers > > 2009/6/8 Ryan Moquin > > > I'm trying to figure out why maven 2.1 is running out of heap space when > I > > do a release:perform on my project. The project builds fine until I do a > > release:perform in which case it runs out of memory. The stack trace > seems > > to indicate that there was enough memory. Do I need to give more memory > to > > the release plugin? Here is the stacktrace, it seems like there is a > > spawned JVM at the time of the error which doesn't have enough memory: > > > > [INFO] 262144/351338K > > [INFO] 262148/351338K > > [INFO] [INFO] > > > > [INFO] [ERROR] FATAL ERROR > > [INFO] [INFO] > > > > [INFO] [INFO] Java heap space > > [INFO] [INFO] > > > > [INFO] [INFO] Trace > > [INFO] java.lang.OutOfMemoryError: Java heap space > > [INFO] at java.util.Arrays.copyOf(Arrays.java:2786) > > [INFO] at > > java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94) > > [INFO] at > > sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61) > > [INFO] at > > org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:492) > > [INFO] at > > org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:457) > > [INFO] at > > org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:411) > > [INFO] at > > org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:392) > > [INFO] at > > org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:365) > > [INFO] at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:160) > > [INFO] at > > > > > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:262) > > [INFO] at > > > > > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:172) > > [INFO] at > > > > > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:107) > > [INFO] at > > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:190) > > [INFO] at > > > > > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) > > [INFO] at > > > > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) > > [INFO] at > > > > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) > > [INFO] at > > > > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) > > [INFO] at > > > > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371 > > ) > > [INFO] at > > > > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) > > [INFO] at > > > > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) > > [INFO] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) > > [INFO] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) > > [INFO] at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) > > [INFO] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > [INFO] at > > > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > > [INFO] at > > > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > > [INFO] at java.lang.reflect.Method.invoke(Method.java:597) > > [INFO] at > > org.codehaus.classworlds.Launche
Re: follow to: problem upgrading from maven 2.0.9 to 2.1
Maybe unrelated, but your java_home seems to point to a jre, not a jdk. It seems abnormal to me, although I don't see how it could be related to your authentication problem. Are you sure you're using the very same Java_home between both maven installations? And btw, I guess diff'ing mvn help:effective-settings and help:effective-pom between the two installs could also provide you with some hints. Cheers. 2009/6/8 Robert Glover > >>Try again with "mvn -X package" and see what that says. Paste the > output to www.pastebin.org and send us the link > >I can't connect to www.pastebin.org, so I pasted the console > output of running "mvn -X package" below. I have no idea what to do except > not upgrade from maven 2.0.9 to maven 2.1.0. It works perfectly with maven > 2.0.9 but always fails in maven 2.1.0. Below is the console output (with > the proxy name in the "paste" changed in 3 places for privacy reasons to " > b1web1.obfuscated.org" instead of the real proxy name): > > + Error stacktraces are turned on. > Apache Maven 2.1.0 (r755702; 2009-03-18 15:10:27-0400) > Java version: 1.5.0_12 > Java home: C:\progfile\Java\jdk1.5.0_12\jre > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" > [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and > Settings\B1RXGC0\.m2\plugin-registry.xml' > [DEBUG] Building Maven global-level plugin registry from: > 'C:\JavaLibs\apache-maven-2.1.0\conf\plugin-registry.xml' > [INFO] Scanning for projects... > [DEBUG] Wagons could not be registered as the extension container was never > created > [INFO] > > [INFO] Building FormBuilder Maven Webapp > [INFO]task-segment: [package] > [INFO] > > [DEBUG] Retrieving parent-POM: > org.apache.maven.plugins:maven-plugins:pom:12 for project: > null:maven-resources-plugin:maven-plugin:2.3 from the repository. > [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:9 for > project: org.apache.maven.plugins:maven-plugins:pom:12 from the repository. > [DEBUG] Retrieving parent-POM: org.apache:apache:pom:4 for project: > org.apache.maven:maven-parent:pom:9 from the repository. > [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins:pom:8 > for project: null:maven-compiler-plugin:maven-plugin:2.0.2 from the > repository. > [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:5 for > project: org.apache.maven.plugins:maven-plugins:pom:8 from the repository. > [DEBUG] Retrieving parent-POM: org.apache:apache:pom:3 for project: > org.apache.maven:maven-parent:pom:5 from the repository. > [DEBUG] Trying repository central > [DEBUG] Checking for pre-existing User-Agent configuration. > [DEBUG] Adding User-Agent configuration. > [DEBUG] Connecting to repository: 'central' with url: ' > http://repo1.maven.org/maven2'. > [DEBUG] Using Proxy: b1web1.obfuscated.org > Downloading: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.4.3/maven-surefire-plugin-2.4.3.pom > [DEBUG] Access denied to: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.4.3/maven-surefire-plugin-2.4.3.pom > org.apache.maven.wagon.authorization.AuthorizationException: Access denied > to: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.4.3/maven-surefire-plugin-2.4.3.pom >at > org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:119) >at > org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116) >at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88) >at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61) >at > org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:491) >at > org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:372) >at > org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:327) >at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:216) >at > org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:90) >at > org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:558) >at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:251) >at > org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:270) >at > org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:198) >at > org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:177) >at > org.apache.maven.lif
Re: Question about Maven2 and Heap Space
Well, after some research, it seems like this is due to the fact that PosterOutputStream/ByteArrayOutputStream class is quite space-greedy, according to: https://issues.alfresco.com/jira/browse/ETHREEOH-974 Looking at the code shows that PosterOutputStream can't be the culprit, as it's not doing a lot of things apart maintaining an additional "closed" boolean: http://www.docjar.org/html/api/sun/net/www/http/PosterOutputStream.java.html But I don't completely understand what version of ByteArrayOutputStream was used. More precisely, I don't find the "java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94)" method, even in the hierarchy. What version of Java are you running? Anyway, I guess you could file an issue. But please run mvn deploy so that you can file the issue into deploy-plugin (or even the right wagon impl) instead of release-plugin jira if more apropriate. Cheers 2009/6/8 Baptiste MATHUS > Interesting. The artifact you're trying to deploy is 350MB+ large. > Could you please try and just "mvn deploy" your project? > > I don't remember if the release plugin forks or not. > > My 2 cents, > Cheers > > 2009/6/8 Ryan Moquin > > I'm trying to figure out why maven 2.1 is running out of heap space when I >> do a release:perform on my project. The project builds fine until I do a >> release:perform in which case it runs out of memory. The stack trace >> seems >> to indicate that there was enough memory. Do I need to give more memory >> to >> the release plugin? Here is the stacktrace, it seems like there is a >> spawned JVM at the time of the error which doesn't have enough memory: >> >> [INFO] 262144/351338K >> [INFO] 262148/351338K >> [INFO] [INFO] >> >> [INFO] [ERROR] FATAL ERROR >> [INFO] [INFO] >> >> [INFO] [INFO] Java heap space >> [INFO] [INFO] >> >> [INFO] [INFO] Trace >> [INFO] java.lang.OutOfMemoryError: Java heap space >> [INFO] at java.util.Arrays.copyOf(Arrays.java:2786) >> [INFO] at >> java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94) >> [INFO] at >> sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61) >> [INFO] at >> org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:492) >> [INFO] at >> org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:457) >> [INFO] at >> org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:411) >> [INFO] at >> org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:392) >> [INFO] at >> org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:365) >> [INFO] at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:160) >> [INFO] at >> >> org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:262) >> [INFO] at >> >> org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:172) >> [INFO] at >> >> org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:107) >> [INFO] at >> org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:190) >> [INFO] at >> >> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) >> [INFO] at >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) >> [INFO] at >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) >> [INFO] at >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) >> [INFO] at >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371 >> ) >> [INFO] at >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) >> [INFO] at >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) >> [INFO] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) >> [INFO] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) >> [INFO] at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) >> [INFO] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> [INFO] at >> >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >> [INFO] at >> >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >> [INFO] at java.lang.reflect.Method.invoke(Method.java:597) >> [INFO] at >> org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) >> [INFO] at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) >> [INFO] at >> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) >> [INFO] at org.codehaus.classworlds.L
follow to: problem upgrading from maven 2.0.9 to 2.1
>>Try again with "mvn -X package" and see what that says. Paste the output to www.pastebin.org and send us the link I can't connect to www.pastebin.org, so I pasted the console output of running "mvn -X package" below. I have no idea what to do except not upgrade from maven 2.0.9 to maven 2.1.0. It works perfectly with maven 2.0.9 but always fails in maven 2.1.0. Below is the console output (with the proxy name in the "paste" changed in 3 places for privacy reasons to "b1web1.obfuscated.org" instead of the real proxy name): + Error stacktraces are turned on. Apache Maven 2.1.0 (r755702; 2009-03-18 15:10:27-0400) Java version: 1.5.0_12 Java home: C:\progfile\Java\jdk1.5.0_12\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and Settings\B1RXGC0\.m2\plugin-registry.xml' [DEBUG] Building Maven global-level plugin registry from: 'C:\JavaLibs\apache-maven-2.1.0\conf\plugin-registry.xml' [INFO] Scanning for projects... [DEBUG] Wagons could not be registered as the extension container was never created [INFO] [INFO] Building FormBuilder Maven Webapp [INFO]task-segment: [package] [INFO] [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins:pom:12 for project: null:maven-resources-plugin:maven-plugin:2.3 from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:9 for project: org.apache.maven.plugins:maven-plugins:pom:12 from the repository. [DEBUG] Retrieving parent-POM: org.apache:apache:pom:4 for project: org.apache.maven:maven-parent:pom:9 from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins:pom:8 for project: null:maven-compiler-plugin:maven-plugin:2.0.2 from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:5 for project: org.apache.maven.plugins:maven-plugins:pom:8 from the repository. [DEBUG] Retrieving parent-POM: org.apache:apache:pom:3 for project: org.apache.maven:maven-parent:pom:5 from the repository. [DEBUG] Trying repository central [DEBUG] Checking for pre-existing User-Agent configuration. [DEBUG] Adding User-Agent configuration. [DEBUG] Connecting to repository: 'central' with url: 'http://repo1.maven.org/maven2'. [DEBUG] Using Proxy: b1web1.obfuscated.org Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.4.3/maven-surefire-plugin-2.4.3.pom [DEBUG] Access denied to: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.4.3/maven-surefire-plugin-2.4.3.pom org.apache.maven.wagon.authorization.AuthorizationException: Access denied to: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-surefire-plugin/2.4.3/maven-surefire-plugin-2.4.3.pom at org.apache.maven.wagon.providers.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:119) at org.apache.maven.wagon.StreamWagon.getInputStream(StreamWagon.java:116) at org.apache.maven.wagon.StreamWagon.getIfNewer(StreamWagon.java:88) at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:61) at org.apache.maven.artifact.manager.DefaultWagonManager.getRemoteFile(DefaultWagonManager.java:491) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:372) at org.apache.maven.artifact.manager.DefaultWagonManager.getArtifact(DefaultWagonManager.java:327) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:216) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:90) at org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:558) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:251) at org.apache.maven.plugin.DefaultPluginManager.checkRequiredMavenVersion(DefaultPluginManager.java:270) at org.apache.maven.plugin.DefaultPluginManager.verifyVersionedPlugin(DefaultPluginManager.java:198) at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:177) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1517) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1786) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:1274) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:1238) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:518) at or
Re: Question about Maven2 and Heap Space
Interesting. The artifact you're trying to deploy is 350MB+ large. Could you please try and just "mvn deploy" your project? I don't remember is the release plugin forks or not. My 2 cents, Cheers 2009/6/8 Ryan Moquin > I'm trying to figure out why maven 2.1 is running out of heap space when I > do a release:perform on my project. The project builds fine until I do a > release:perform in which case it runs out of memory. The stack trace seems > to indicate that there was enough memory. Do I need to give more memory to > the release plugin? Here is the stacktrace, it seems like there is a > spawned JVM at the time of the error which doesn't have enough memory: > > [INFO] 262144/351338K > [INFO] 262148/351338K > [INFO] [INFO] > > [INFO] [ERROR] FATAL ERROR > [INFO] [INFO] > > [INFO] [INFO] Java heap space > [INFO] [INFO] > > [INFO] [INFO] Trace > [INFO] java.lang.OutOfMemoryError: Java heap space > [INFO] at java.util.Arrays.copyOf(Arrays.java:2786) > [INFO] at > java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94) > [INFO] at > sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61) > [INFO] at > org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:492) > [INFO] at > org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:457) > [INFO] at > org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:411) > [INFO] at > org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:392) > [INFO] at > org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:365) > [INFO] at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:160) > [INFO] at > > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:262) > [INFO] at > > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:172) > [INFO] at > > org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:107) > [INFO] at > org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:190) > [INFO] at > > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) > [INFO] at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) > [INFO] at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) > [INFO] at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) > [INFO] at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371 > ) > [INFO] at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) > [INFO] at > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) > [INFO] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) > [INFO] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) > [INFO] at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) > [INFO] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > [INFO] at > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > [INFO] at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > [INFO] at java.lang.reflect.Method.invoke(Method.java:597) > [INFO] at > org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > [INFO] at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > [INFO] at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > [INFO] at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > [INFO] [INFO] > > [INFO] [INFO] Total time: 30 minutes 19 seconds > [INFO] [INFO] Finished at: Sat Jun 06 02:19:04 EDT 2009 > [INFO] [INFO] Final Memory: 473M/1016M > [INFO] [INFO] > > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Maven execution failed, exit code: '1' > > [INFO] > > [INFO] For more information, run Maven with the -e switch > [INFO] > > [INFO] Total time: 33 minutes 32 seconds > [INFO] Finished at: Sat Jun 06 02:19:21 EDT 2009 > [INFO] Final Memory: 36M/65M > [INFO] > --
Re: eclipse:eclipse
Hm, there is no error message, neither with mvn install nor with mvn eclipse:eclipse. Both works fine using the command line. It just fails in Eclipse... Thanks, Peter
Question about Maven2 and Heap Space
I'm trying to figure out why maven 2.1 is running out of heap space when I do a release:perform on my project. The project builds fine until I do a release:perform in which case it runs out of memory. The stack trace seems to indicate that there was enough memory. Do I need to give more memory to the release plugin? Here is the stacktrace, it seems like there is a spawned JVM at the time of the error which doesn't have enough memory: [INFO] 262144/351338K [INFO] 262148/351338K [INFO] [INFO] [INFO] [ERROR] FATAL ERROR [INFO] [INFO] [INFO] [INFO] Java heap space [INFO] [INFO] [INFO] [INFO] Trace [INFO] java.lang.OutOfMemoryError: Java heap space [INFO] at java.util.Arrays.copyOf(Arrays.java:2786) [INFO] at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94) [INFO] at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61) [INFO] at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:492) [INFO] at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:457) [INFO] at org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:411) [INFO] at org.apache.maven.wagon.AbstractWagon.transfer(AbstractWagon.java:392) [INFO] at org.apache.maven.wagon.AbstractWagon.putTransfer(AbstractWagon.java:365) [INFO] at org.apache.maven.wagon.StreamWagon.put(StreamWagon.java:160) [INFO] at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:262) [INFO] at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:172) [INFO] at org.apache.maven.artifact.deployer.DefaultArtifactDeployer.deploy(DefaultArtifactDeployer.java:107) [INFO] at org.apache.maven.plugin.deploy.DeployMojo.execute(DeployMojo.java:190) [INFO] at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:483) [INFO] at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:678) [INFO] at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:540) [INFO] at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:519) [INFO] at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:371 ) [INFO] at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:332) [INFO] at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:181) [INFO] at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) [INFO] at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) [INFO] at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) [INFO] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [INFO] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [INFO] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [INFO] at java.lang.reflect.Method.invoke(Method.java:597) [INFO] at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) [INFO] at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) [INFO] at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) [INFO] at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [INFO] [INFO] [INFO] Total time: 30 minutes 19 seconds [INFO] [INFO] Finished at: Sat Jun 06 02:19:04 EDT 2009 [INFO] [INFO] Final Memory: 473M/1016M [INFO] [INFO] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Maven execution failed, exit code: '1' [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 33 minutes 32 seconds [INFO] Finished at: Sat Jun 06 02:19:21 EDT 2009 [INFO] Final Memory: 36M/65M [INFO] Thanks, Ryan
How to specify no snapshots?
Hello, Here is what I'm trying to do: How do I specify that I don't want any snapshots if a version is not specified for a plugin? I am trying to debug a plugin we are writing and deploying the snapshot version for some to test. Our designers are used to using this plugin on the command-line without specifying the version and now the version they are using is the snapshot one and I don't want thatI want them to continue using the latest non-snapshot version. Please help! Soni -- View this message in context: http://www.nabble.com/How-to-specify-no-snapshots--tp23926367p23926367.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: eclipse:eclipse
Can you send me the error message you are getting when you do a eclipse:eclipse, or a clean install? --- On Mon, 8/6/09, Peter Horlock wrote: From: Peter Horlock Subject: Re: eclipse:eclipse To: "Maven Users List" Date: Monday, 8 June, 2009, 11:44 AM 2009/6/8 SEAN MCELROY Hi Peter, I don't know if this will solve your problem but I suspect it might. Try creating a manifest file - src/main/resources/META-INF/ > > MANIFEST.MF if the META-INF directory does not exists create it. Then add > something like this to your manifest: > > Manifest-Version: 1.0 > Archiver-Version: Plexus Archiver > Created-By: Apache Maven > Built-By: > Build-Jdk: 1.6.0_06 > Main-Class: > Class-Path: . lib/commons-io-1.4.jar lib/hibernate-3.2.6.ga.jar ... > > You need to change: Build-By, Build-Jdk, Main-Class and Class-Path. The > Class-Path is a space delimited set of jars the compose you class path. So in other words, you are suggesting that I would manually update the classpath every time? Hm, not the best option either, I guess. Well now I got my (new) company to accept that this problem is a problem, even though it only happens to me (so far), and we try to fix the problem itself, instead of trying to change how maven sets up the build path for me. As I see it now, the problem is Java 6 with cocoon 2.1.11. Cocoon 2.1.11 uses excalibur-xmlutil 2.1 which uses jtidy which implemts org.w3c classes that are implemented by the JDK 6 itself. I found a newer version of jtidy in a hibernate project, this one does not reimplement the org.w3c classes, however, then there is another third party jar in excalibur-xmutil 2.1, xml-apis 2.0.2 that also reimplements org.w3c classes and I got the same conflict. Looking on the maven repo, there is: http://repo1.maven.org/maven2/xml-apis/xml-apis/ where 2.0.2 is the newest version, and there is http://repo1.maven.org/maven2/xml-apis/xml-apis-ext/1.3.04/ which seems to be newer - I assume, yet don't know, that this might be a newer version of xml-apis, that was deployed after Java 6 was out, so it might be just the same but without the java 6 org.w3c classes? Is that so? Did anyone of you ever have this or a similar problem? What's the best way to solve it? Thanks in advance, Peter
Re: eclipse:eclipse
Yeah, I am just trying that myself, even though it comes from a great variety of third party dependencies. What I am not sure yet - will this really not be needed anymore, using Java 6? Thanks in advance, Peter
Re: eclipse:eclipse
Ok, I obviously didn't read your first email properly. Can you remove xml-apis 2.0.2 from your class path? --- On Mon, 8/6/09, Peter Horlock wrote: From: Peter Horlock Subject: Re: eclipse:eclipse To: "Maven Users List" Date: Monday, 8 June, 2009, 11:44 AM 2009/6/8 SEAN MCELROY Hi Peter, I don't know if this will solve your problem but I suspect it might. Try creating a manifest file - src/main/resources/META-INF/ > > MANIFEST.MF if the META-INF directory does not exists create it. Then add > something like this to your manifest: > > Manifest-Version: 1.0 > Archiver-Version: Plexus Archiver > Created-By: Apache Maven > Built-By: > Build-Jdk: 1.6.0_06 > Main-Class: > Class-Path: . lib/commons-io-1.4.jar lib/hibernate-3.2.6.ga.jar ... > > You need to change: Build-By, Build-Jdk, Main-Class and Class-Path. The > Class-Path is a space delimited set of jars the compose you class path. So in other words, you are suggesting that I would manually update the classpath every time? Hm, not the best option either, I guess. Well now I got my (new) company to accept that this problem is a problem, even though it only happens to me (so far), and we try to fix the problem itself, instead of trying to change how maven sets up the build path for me. As I see it now, the problem is Java 6 with cocoon 2.1.11. Cocoon 2.1.11 uses excalibur-xmlutil 2.1 which uses jtidy which implemts org.w3c classes that are implemented by the JDK 6 itself. I found a newer version of jtidy in a hibernate project, this one does not reimplement the org.w3c classes, however, then there is another third party jar in excalibur-xmutil 2.1, xml-apis 2.0.2 that also reimplements org.w3c classes and I got the same conflict. Looking on the maven repo, there is: http://repo1.maven.org/maven2/xml-apis/xml-apis/ where 2.0.2 is the newest version, and there is http://repo1.maven.org/maven2/xml-apis/xml-apis-ext/1.3.04/ which seems to be newer - I assume, yet don't know, that this might be a newer version of xml-apis, that was deployed after Java 6 was out, so it might be just the same but without the java 6 org.w3c classes? Is that so? Did anyone of you ever have this or a similar problem? What's the best way to solve it? Thanks in advance, Peter
Re: Maven assembly: cut down on number of assemblies made?
BRIAN FOX-5 wrote: > > On Sat, Jun 6, 2009 at 11:37 AM, ljnelson wrote: > There is no preconfigured descriptor in the assembly config. More > likely your project is inheriting from a pom that defines this > configuration. Just redefine it and use your own descriptor. > Er, it's in the super POM. Go ahead and include the assembly plugin in a sample project, for example, with no configuration, and type: mvn help:effective-pom. You'll see that the super POM supplies a configuration that makes the assembly plugin use "project" as one of its descriptorRefs. I can't find a way to override this. Thanks, Laird -- View this message in context: http://www.nabble.com/Maven-assembly%3A-cut-down-on-number-of-assemblies-made--tp23904468p23923016.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Attach plugin to particular phase:goal
Hi All! After running "mvn eclipse:eclipse" I want to execute a mvn-ant-run automatically. Is there way to combine two plugins or to attach "some logic" to a particular phase:goal (like "eclipse:eclipse" in my case)? Thanks in advance Jens - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: eclipse:eclipse
2009/6/8 SEAN MCELROY Hi Peter, I don't know if this will solve your problem but I suspect it might. Try creating a manifest file - src/main/resources/META-INF/ > > MANIFEST.MF if the META-INF directory does not exists create it. Then add > something like this to your manifest: > > Manifest-Version: 1.0 > Archiver-Version: Plexus Archiver > Created-By: Apache Maven > Built-By: > Build-Jdk: 1.6.0_06 > Main-Class: > Class-Path: . lib/commons-io-1.4.jar lib/hibernate-3.2.6.ga.jar ... > > You need to change: Build-By, Build-Jdk, Main-Class and Class-Path. The > Class-Path is a space delimited set of jars the compose you class path. So in other words, you are suggesting that I would manually update the classpath every time? Hm, not the best option either, I guess. Well now I got my (new) company to accept that this problem is a problem, even though it only happens to me (so far), and we try to fix the problem itself, instead of trying to change how maven sets up the build path for me. As I see it now, the problem is Java 6 with cocoon 2.1.11. Cocoon 2.1.11 uses excalibur-xmlutil 2.1 which uses jtidy which implemts org.w3c classes that are implemented by the JDK 6 itself. I found a newer version of jtidy in a hibernate project, this one does not reimplement the org.w3c classes, however, then there is another third party jar in excalibur-xmutil 2.1, xml-apis 2.0.2 that also reimplements org.w3c classes and I got the same conflict. Looking on the maven repo, there is: http://repo1.maven.org/maven2/xml-apis/xml-apis/ where 2.0.2 is the newest version, and there is http://repo1.maven.org/maven2/xml-apis/xml-apis-ext/1.3.04/ which seems to be newer - I assume, yet don't know, that this might be a newer version of xml-apis, that was deployed after Java 6 was out, so it might be just the same but without the java 6 org.w3c classes? Is that so? Did anyone of you ever have this or a similar problem? What's the best way to solve it? Thanks in advance, Peter
Re: eclipse:eclipse
Hi Peter, I don't know if this will solve your problem but I suspect it might. Try creating a manifest file - src/main/resources/META-INF/MANIFEST.MF if the META-INF directory does not exists create it. Then add something like this to your manifest: Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: Build-Jdk: 1.6.0_06 Main-Class: Class-Path: . lib/commons-io-1.4.jar lib/hibernate-3.2.6.ga.jar ... You need to change: Build-By, Build-Jdk, Main-Class and Class-Path. The Class-Path is a space delimited set of jars the compose you class path. Once you have done this you should do a mvn clean install. Hope this works. Regards, Sean McElroy --- On Mon, 8/6/09, Peter Horlock wrote: From: Peter Horlock Subject: Re: eclipse:eclipse To: "Maven Users List" Date: Monday, 8 June, 2009, 6:55 AM Hello everyone, I'm still having the problem as described below - can no one help me out, please? Thanks, Peter 2009/6/6 Peter Horlock > Hi all, > > I type mvn eclipse:eclipse to get the necessary project files for eclipse. > Everything works fine, > except the fact that the dependency to the JDK / JRE is always the last one > in the eclipse project setting. > There's another jar that unfortunately has got the exact same class name > (include the entire package name) > as a class of the JDK / JRE. Now as the third party jar appears before the > JDK in the eclipse classpath, > its class gets used instead of the one from the JDK. > > What can I do to prevent this from happening? > > Thanks, > > Peter >
Re: eclipse:eclipse
On Mon, Jun 8, 2009 at 3:25 PM, Peter Horlock wrote: > Hello everyone, > > I'm still having the problem as described below - can no one help me out, > please? This ordering is now the intended behaviour. There is no way to change this. It is meant to mirror what maven does on compilation. How does mvn compile or mvn test work for this problem class? Why does this class exist? Is it not a compatible replacement of the jdk class? A workaround is for you to manually change the ordering inside eclipse after running mvn eclipse:eclipse. Alternatively fix the third party jar that is shading jdk classes. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Nested configuration objects not getting created
I have the following situation where I have a plugin that starts
another java process and I want to allow the user to configure it to
fork or not fork. If the process is forked, the user has some
optional attributes they are allowed to also specify. So, I have the
following bits in my Mojo:
public class StartMojo extends AbstractMojo {
private static final ForkConfiguration NON_FORKING = new
ForkConfiguration(false, null, null, "");
/**
* Determines if the framework is started in a separate process or
in the same process Maven is running in and
* the extra configuration options available. If not specified
the default is to not fork.
*
* @parameter
* @optional
*/
private ForkConfiguration fork = NON_FORKING;
public static class ForkConfiguration {
/**
* Whether the framework should be run in a forked process.
*
* @parameter default-value="true"
* @optional
*/
boolean fork;
/**
* File to send all the frameworks standard output to.
*
* @parameter
default-value="${project.build.directory}/bunches/output.log"
* @optional
*/
File outputFile;
/**
* File to send all the frameworks standard error to.
*
* @parameter
default-value="${project.build.directory}/bunches/error.log"
* @optional
*/
File errorFile;
/**
* Arguments to be passed to the jvm
*
* @parameter default-value=""
* @optional
*/
String jvmArgs;
/**
* Parameterless ctor for Maven.
*/
public ForkConfiguration() {}
/**
* Ctor that allows all parameters to be set.
*/
ForkConfiguration(boolean fork, File outputFile, File
errorFile, String jvmArgs) {
this.fork = fork;
this.outputFile = outputFile;
this.errorFile = errorFile;
this.jvmArgs = jvmArgs;
}
}
}
If the user wants to configure the thing to fork but doesn't want to
specify any other information, it would be nice if they could just use
this configuration
But that doesn't seem to inject a ForkConfiguration object configured
by maven into the fork member. I was expecting to create a
ForkConfiguration object with the default-values from the @parameter
annotations. Instead, it doesn't seem to set it at all. But, if I
add an element to configuration, it creates the
ForkConfiguration object with the default values for all but the user
set property. Is there anyway I can force the creation of a
ForkConfiguration object when just a is provided? If not, is
there a way to lookup the whole DOM element and check
for it's presence? Any other way I might be able to check the value?
Thanks,
Rich
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
