Re: Heap overflow in deploy:deploy
No, Nexus is not "WebDAV compliant" (you cannot mount repository as a drive for example). But YES, you can use DAV wagon to deploy to it. You need build extension with DAV wagon _and_ modify your deploy URL. Thanks, ~t~ On Tue, May 10, 2011 at 6:29 AM, Anders Hammar wrote: > No, Nexus does not support webdav. You should use http. > > /Anders > > On Tue, May 10, 2011 at 04:34, Phillip Hellewell wrote: > > > Thanks. I didn't even know I could select a different wagon. Does Nexus > > supports WebDAV? > > > > I skimmed a few places but I couldn't tell exactly which of these I am > > supposed to do: > > 1. Just prepend "dav:" to the front of my repository url in my > > distributionManagement? > > 2. Specify a wagonProvider of webdav or something in my settings.xml in > the > > server section? > > 3. Build extension?? > > > > I'll try #1 first. > > > > Phillip > > > > 2011/5/7 Arnaud Héritier > > > > > I'm using the webdav wagon to bypass this problem. But yes we should > try > > to > > > propose something better. > > > Patches are welcome ;) > > > > > > Le 7 mai 2011 à 10:32, Stephen Connolly < > stephen.alan.conno...@gmail.com > > > > > > a écrit : > > > > > > > select a different wagon. it's documented on one of the mini howtos > in > > > the > > > > wagon sub-site (I'm on a phone so have a look yourself) > > > > > > > > - Stephen > > > > > > > > --- > > > > Sent from my Android phone, so random spelling mistakes, random > > nonsense > > > > words and other nonsense are a direct result of using swype to type > on > > > the > > > > screen > > > > On 7 May 2011 04:37, "Phillip Hellewell" wrote: > > > >> With Maven 3.0.1 I am still running into this bug. It's been 1/2 > year; > > > any > > > >> ETA on when it will be fixed? Could Maven use an alternative to > > > > httpclient? > > > >> > > > >> I have a component with five zip classifiers ranging in size from > 80MB > > > to > > > >> 800MB. I had to adjust my max heap size to 2.5GB before it would > > deploy > > > >> without a heap overflow. > > > >> > > > >> Phillip > > > >> > > > >> On Wed, Oct 13, 2010 at 11:45 PM, Dan Tran > wrote: > > > >> > > > >>> It is a known problem where maven (wagon) uses jvm's httpclient to > do > > > >>> the upload. > > > >>> > > > >>> -D > > > >>> > > > >>> On Wed, Oct 13, 2010 at 8:52 PM, Ron Wheeler > > > >>> wrote: > > > On 13/10/2010 7:29 PM, Phillip Hellewell wrote: > > > > > > > > I'm using Maven 2.2.1 and getting a heap overflow when trying to > > > > deploy an artifact about 50MB in size. I'm deploying to an Nexus > > > > server (HTTP). > > > > > > > > I added "@set MAVEN_OPTS=-Xms128m -Xmx512m" to my mvn.bat and now > > it > > > > is > > > > working. > > > > > > > > But my question is, why should uploading a file require so much > > > > memory? It's not like it tries to read the whole file into > memory, > > or > > > > does it? If so, that seems kinda dumb. > > > > > > We have seen this one as well. > > > Probably more of a comment on the guys that set the default way > too > > > > low. > > > Who would buy a computer with 512Mb of memory and no paging space? > > > I suspect that the guys that write the code that we use, do not > have > > > > real > > > world examples where you need to move 50 Mb around. > > > We had the problem with CXF (Apache web services) where we could > not > > > >>> deploy > > > the basic library jar to Nexus without setting the Eclipse > > parameters > > > > for > > > >>> a > > > JVM fork to something more in keeping with the natural capacity of > > our > > > actual workstations (2Gb physical memory with 4Gb of cache) . > > > I just set the JVM options to -Xmx1024m to start, on any Java > > program, > > > since the JVM is already running in a virtual machine (Linux or > > Vista) > > > anyway that can easily deal with a 1Gb task if it does not use the > > > >>> memory. > > > > > > Ron > > > > > > > > Phillip > > > > > > > > P.S. Here's the trace: > > > > > > > > java.lang.OutOfMemoryError: Java heap space > > > > at java.util.Arrays.copyOf(Unknown Source) > > > > at java.io.ByteArrayOutputStream.write(Unknown Source) > > > > at sun.net.www.http.PosterOutputStream.write(Unknown Source) > > > > 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:163) > > > > at > > > > > > > >>> > > > > > > > > >
Re: Heap overflow in deploy:deploy
No, Nexus does not support webdav. You should use http. /Anders On Tue, May 10, 2011 at 04:34, Phillip Hellewell wrote: > Thanks. I didn't even know I could select a different wagon. Does Nexus > supports WebDAV? > > I skimmed a few places but I couldn't tell exactly which of these I am > supposed to do: > 1. Just prepend "dav:" to the front of my repository url in my > distributionManagement? > 2. Specify a wagonProvider of webdav or something in my settings.xml in the > server section? > 3. Build extension?? > > I'll try #1 first. > > Phillip > > 2011/5/7 Arnaud Héritier > > > I'm using the webdav wagon to bypass this problem. But yes we should try > to > > propose something better. > > Patches are welcome ;) > > > > Le 7 mai 2011 à 10:32, Stephen Connolly > > > a écrit : > > > > > select a different wagon. it's documented on one of the mini howtos in > > the > > > wagon sub-site (I'm on a phone so have a look yourself) > > > > > > - Stephen > > > > > > --- > > > Sent from my Android phone, so random spelling mistakes, random > nonsense > > > words and other nonsense are a direct result of using swype to type on > > the > > > screen > > > On 7 May 2011 04:37, "Phillip Hellewell" wrote: > > >> With Maven 3.0.1 I am still running into this bug. It's been 1/2 year; > > any > > >> ETA on when it will be fixed? Could Maven use an alternative to > > > httpclient? > > >> > > >> I have a component with five zip classifiers ranging in size from 80MB > > to > > >> 800MB. I had to adjust my max heap size to 2.5GB before it would > deploy > > >> without a heap overflow. > > >> > > >> Phillip > > >> > > >> On Wed, Oct 13, 2010 at 11:45 PM, Dan Tran wrote: > > >> > > >>> It is a known problem where maven (wagon) uses jvm's httpclient to do > > >>> the upload. > > >>> > > >>> -D > > >>> > > >>> On Wed, Oct 13, 2010 at 8:52 PM, Ron Wheeler > > >>> wrote: > > On 13/10/2010 7:29 PM, Phillip Hellewell wrote: > > > > > > I'm using Maven 2.2.1 and getting a heap overflow when trying to > > > deploy an artifact about 50MB in size. I'm deploying to an Nexus > > > server (HTTP). > > > > > > I added "@set MAVEN_OPTS=-Xms128m -Xmx512m" to my mvn.bat and now > it > > > is > > > working. > > > > > > But my question is, why should uploading a file require so much > > > memory? It's not like it tries to read the whole file into memory, > or > > > does it? If so, that seems kinda dumb. > > > > We have seen this one as well. > > Probably more of a comment on the guys that set the default way too > > > low. > > Who would buy a computer with 512Mb of memory and no paging space? > > I suspect that the guys that write the code that we use, do not have > > > real > > world examples where you need to move 50 Mb around. > > We had the problem with CXF (Apache web services) where we could not > > >>> deploy > > the basic library jar to Nexus without setting the Eclipse > parameters > > > for > > >>> a > > JVM fork to something more in keeping with the natural capacity of > our > > actual workstations (2Gb physical memory with 4Gb of cache) . > > I just set the JVM options to -Xmx1024m to start, on any Java > program, > > since the JVM is already running in a virtual machine (Linux or > Vista) > > anyway that can easily deal with a 1Gb task if it does not use the > > >>> memory. > > > > Ron > > > > > > Phillip > > > > > > P.S. Here's the trace: > > > > > > java.lang.OutOfMemoryError: Java heap space > > > at java.util.Arrays.copyOf(Unknown Source) > > > at java.io.ByteArrayOutputStream.write(Unknown Source) > > > at sun.net.www.http.PosterOutputStream.write(Unknown Source) > > > 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:163) > > > at > > > > > >>> > > > > > > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:317) > > > at > > > > > >>> > > > > > > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:227) > > > 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:490) > >
Re: Heap overflow in deploy:deploy
Thanks. I didn't even know I could select a different wagon. Does Nexus supports WebDAV? I skimmed a few places but I couldn't tell exactly which of these I am supposed to do: 1. Just prepend "dav:" to the front of my repository url in my distributionManagement? 2. Specify a wagonProvider of webdav or something in my settings.xml in the server section? 3. Build extension?? I'll try #1 first. Phillip 2011/5/7 Arnaud Héritier > I'm using the webdav wagon to bypass this problem. But yes we should try to > propose something better. > Patches are welcome ;) > > Le 7 mai 2011 à 10:32, Stephen Connolly > a écrit : > > > select a different wagon. it's documented on one of the mini howtos in > the > > wagon sub-site (I'm on a phone so have a look yourself) > > > > - Stephen > > > > --- > > Sent from my Android phone, so random spelling mistakes, random nonsense > > words and other nonsense are a direct result of using swype to type on > the > > screen > > On 7 May 2011 04:37, "Phillip Hellewell" wrote: > >> With Maven 3.0.1 I am still running into this bug. It's been 1/2 year; > any > >> ETA on when it will be fixed? Could Maven use an alternative to > > httpclient? > >> > >> I have a component with five zip classifiers ranging in size from 80MB > to > >> 800MB. I had to adjust my max heap size to 2.5GB before it would deploy > >> without a heap overflow. > >> > >> Phillip > >> > >> On Wed, Oct 13, 2010 at 11:45 PM, Dan Tran wrote: > >> > >>> It is a known problem where maven (wagon) uses jvm's httpclient to do > >>> the upload. > >>> > >>> -D > >>> > >>> On Wed, Oct 13, 2010 at 8:52 PM, Ron Wheeler > >>> wrote: > On 13/10/2010 7:29 PM, Phillip Hellewell wrote: > > > > I'm using Maven 2.2.1 and getting a heap overflow when trying to > > deploy an artifact about 50MB in size. I'm deploying to an Nexus > > server (HTTP). > > > > I added "@set MAVEN_OPTS=-Xms128m -Xmx512m" to my mvn.bat and now it > > is > > working. > > > > But my question is, why should uploading a file require so much > > memory? It's not like it tries to read the whole file into memory, or > > does it? If so, that seems kinda dumb. > > We have seen this one as well. > Probably more of a comment on the guys that set the default way too > > low. > Who would buy a computer with 512Mb of memory and no paging space? > I suspect that the guys that write the code that we use, do not have > > real > world examples where you need to move 50 Mb around. > We had the problem with CXF (Apache web services) where we could not > >>> deploy > the basic library jar to Nexus without setting the Eclipse parameters > > for > >>> a > JVM fork to something more in keeping with the natural capacity of our > actual workstations (2Gb physical memory with 4Gb of cache) . > I just set the JVM options to -Xmx1024m to start, on any Java program, > since the JVM is already running in a virtual machine (Linux or Vista) > anyway that can easily deal with a 1Gb task if it does not use the > >>> memory. > > Ron > > > > Phillip > > > > P.S. Here's the trace: > > > > java.lang.OutOfMemoryError: Java heap space > > at java.util.Arrays.copyOf(Unknown Source) > > at java.io.ByteArrayOutputStream.write(Unknown Source) > > at sun.net.www.http.PosterOutputStream.write(Unknown Source) > > 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:163) > > at > > > >>> > > > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:317) > > at > > > >>> > > > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:227) > > 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:490) > > at > > > >>> > > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) > > at > > > >>> > > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > > at > > > >>> > > > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > > at > > > >>> > > > or
Re: Heap overflow in deploy:deploy
I'm using the webdav wagon to bypass this problem. But yes we should try to propose something better. Patches are welcome ;) Le 7 mai 2011 à 10:32, Stephen Connolly a écrit : > select a different wagon. it's documented on one of the mini howtos in the > wagon sub-site (I'm on a phone so have a look yourself) > > - Stephen > > --- > Sent from my Android phone, so random spelling mistakes, random nonsense > words and other nonsense are a direct result of using swype to type on the > screen > On 7 May 2011 04:37, "Phillip Hellewell" wrote: >> With Maven 3.0.1 I am still running into this bug. It's been 1/2 year; any >> ETA on when it will be fixed? Could Maven use an alternative to > httpclient? >> >> I have a component with five zip classifiers ranging in size from 80MB to >> 800MB. I had to adjust my max heap size to 2.5GB before it would deploy >> without a heap overflow. >> >> Phillip >> >> On Wed, Oct 13, 2010 at 11:45 PM, Dan Tran wrote: >> >>> It is a known problem where maven (wagon) uses jvm's httpclient to do >>> the upload. >>> >>> -D >>> >>> On Wed, Oct 13, 2010 at 8:52 PM, Ron Wheeler >>> wrote: On 13/10/2010 7:29 PM, Phillip Hellewell wrote: > > I'm using Maven 2.2.1 and getting a heap overflow when trying to > deploy an artifact about 50MB in size. I'm deploying to an Nexus > server (HTTP). > > I added "@set MAVEN_OPTS=-Xms128m -Xmx512m" to my mvn.bat and now it > is > working. > > But my question is, why should uploading a file require so much > memory? It's not like it tries to read the whole file into memory, or > does it? If so, that seems kinda dumb. We have seen this one as well. Probably more of a comment on the guys that set the default way too > low. Who would buy a computer with 512Mb of memory and no paging space? I suspect that the guys that write the code that we use, do not have > real world examples where you need to move 50 Mb around. We had the problem with CXF (Apache web services) where we could not >>> deploy the basic library jar to Nexus without setting the Eclipse parameters > for >>> a JVM fork to something more in keeping with the natural capacity of our actual workstations (2Gb physical memory with 4Gb of cache) . I just set the JVM options to -Xmx1024m to start, on any Java program, since the JVM is already running in a virtual machine (Linux or Vista) anyway that can easily deal with a 1Gb task if it does not use the >>> memory. Ron > > Phillip > > P.S. Here's the trace: > > java.lang.OutOfMemoryError: Java heap space > at java.util.Arrays.copyOf(Unknown Source) > at java.io.ByteArrayOutputStream.write(Unknown Source) > at sun.net.www.http.PosterOutputStream.write(Unknown Source) > 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:163) > at > >>> > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:317) > at > >>> > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:227) > 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:490) > at > >>> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) > at > >>> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > at > >>> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > at > >>> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > at > >>> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > at > >>> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) > at >>> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) > at > > org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) > at sun.
Re: Heap overflow in deploy:deploy
select a different wagon. it's documented on one of the mini howtos in the wagon sub-site (I'm on a phone so have a look yourself) - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 7 May 2011 04:37, "Phillip Hellewell" wrote: > With Maven 3.0.1 I am still running into this bug. It's been 1/2 year; any > ETA on when it will be fixed? Could Maven use an alternative to httpclient? > > I have a component with five zip classifiers ranging in size from 80MB to > 800MB. I had to adjust my max heap size to 2.5GB before it would deploy > without a heap overflow. > > Phillip > > On Wed, Oct 13, 2010 at 11:45 PM, Dan Tran wrote: > >> It is a known problem where maven (wagon) uses jvm's httpclient to do >> the upload. >> >> -D >> >> On Wed, Oct 13, 2010 at 8:52 PM, Ron Wheeler >> wrote: >> > On 13/10/2010 7:29 PM, Phillip Hellewell wrote: >> >> >> >> I'm using Maven 2.2.1 and getting a heap overflow when trying to >> >> deploy an artifact about 50MB in size. I'm deploying to an Nexus >> >> server (HTTP). >> >> >> >> I added "@set MAVEN_OPTS=-Xms128m -Xmx512m" to my mvn.bat and now it is >> >> working. >> >> >> >> But my question is, why should uploading a file require so much >> >> memory? It's not like it tries to read the whole file into memory, or >> >> does it? If so, that seems kinda dumb. >> > >> > We have seen this one as well. >> > Probably more of a comment on the guys that set the default way too low. >> > Who would buy a computer with 512Mb of memory and no paging space? >> > I suspect that the guys that write the code that we use, do not have real >> > world examples where you need to move 50 Mb around. >> > We had the problem with CXF (Apache web services) where we could not >> deploy >> > the basic library jar to Nexus without setting the Eclipse parameters for >> a >> > JVM fork to something more in keeping with the natural capacity of our >> > actual workstations (2Gb physical memory with 4Gb of cache) . >> > I just set the JVM options to -Xmx1024m to start, on any Java program, >> > since the JVM is already running in a virtual machine (Linux or Vista) >> > anyway that can easily deal with a 1Gb task if it does not use the >> memory. >> > >> > Ron >> >> >> >> Phillip >> >> >> >> P.S. Here's the trace: >> >> >> >> java.lang.OutOfMemoryError: Java heap space >> >> at java.util.Arrays.copyOf(Unknown Source) >> >> at java.io.ByteArrayOutputStream.write(Unknown Source) >> >> at sun.net.www.http.PosterOutputStream.write(Unknown Source) >> >> 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:163) >> >> at >> >> >> org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:317) >> >> at >> >> >> org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:227) >> >> 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:490) >> >> at >> >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) >> >> at >> >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) >> >> at >> >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) >> >> at >> >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) >> >> at >> >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) >> >> at >> >> >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) >> >> at >> org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) >> >> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) >> >> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) >> >> at >> >> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) >> >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> >> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) >> >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown >> Source) >> >> at java.lang.reflect.Method.invoke(Unknown Source) >> >> at >> >> org.codehaus.classworlds.Launcher.
Re: Heap overflow in deploy:deploy
With Maven 3.0.1 I am still running into this bug. It's been 1/2 year; any ETA on when it will be fixed? Could Maven use an alternative to httpclient? I have a component with five zip classifiers ranging in size from 80MB to 800MB. I had to adjust my max heap size to 2.5GB before it would deploy without a heap overflow. Phillip On Wed, Oct 13, 2010 at 11:45 PM, Dan Tran wrote: > It is a known problem where maven (wagon) uses jvm's httpclient to do > the upload. > > -D > > On Wed, Oct 13, 2010 at 8:52 PM, Ron Wheeler > wrote: > > On 13/10/2010 7:29 PM, Phillip Hellewell wrote: > >> > >> I'm using Maven 2.2.1 and getting a heap overflow when trying to > >> deploy an artifact about 50MB in size. I'm deploying to an Nexus > >> server (HTTP). > >> > >> I added "@set MAVEN_OPTS=-Xms128m -Xmx512m" to my mvn.bat and now it is > >> working. > >> > >> But my question is, why should uploading a file require so much > >> memory? It's not like it tries to read the whole file into memory, or > >> does it? If so, that seems kinda dumb. > > > > We have seen this one as well. > > Probably more of a comment on the guys that set the default way too low. > > Who would buy a computer with 512Mb of memory and no paging space? > > I suspect that the guys that write the code that we use, do not have real > > world examples where you need to move 50 Mb around. > > We had the problem with CXF (Apache web services) where we could not > deploy > > the basic library jar to Nexus without setting the Eclipse parameters for > a > > JVM fork to something more in keeping with the natural capacity of our > > actual workstations (2Gb physical memory with 4Gb of cache) . > > I just set the JVM options to -Xmx1024m to start, on any Java program, > > since the JVM is already running in a virtual machine (Linux or Vista) > > anyway that can easily deal with a 1Gb task if it does not use the > memory. > > > > Ron > >> > >> Phillip > >> > >> P.S. Here's the trace: > >> > >> java.lang.OutOfMemoryError: Java heap space > >> at java.util.Arrays.copyOf(Unknown Source) > >> at java.io.ByteArrayOutputStream.write(Unknown Source) > >> at sun.net.www.http.PosterOutputStream.write(Unknown Source) > >> 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:163) > >> at > >> > org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:317) > >> at > >> > org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:227) > >> 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:490) > >> at > >> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) > >> at > >> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) > >> at > >> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) > >> at > >> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) > >> at > >> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) > >> at > >> > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) > >> at > org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) > >> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) > >> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) > >> at > >> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > >> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown > Source) > >> at java.lang.reflect.Method.invoke(Unknown Source) > >> 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.codehau
Re: Heap overflow in deploy:deploy
> I don't know. To me it looks like the code limits it to sending > DEFAULT_BUFFER_SIZE (4K) at a time. Heh, you're right... doh. In my defense, I was looking for a place where maybe the code had a bug and was reading entirely too much into memory. Oh well, guess its just jvm's httpclient bug then like Dan said. ;-) Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Heap overflow in deploy:deploy
On Wed, Oct 13, 2010 at 11:45 PM, Dan Tran wrote: > It is a known problem where maven (wagon) uses jvm's httpclient to do > the upload. Good to know, thanks. So it is actually a bug in sun.net.www.http.PosterOutputStream you say? So what is the game plan? Just wait for Sun (well, Oracle) to fix it? In the meantime should we set a (higher) default max mem values in mvn.bat? Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Heap overflow in deploy:deploy
On Wed, Oct 13, 2010 at 8:31 PM, Wayne Fay wrote: > > You probably want to look at the following lines in particular: > > 457 transfer( resource, input, output, requestType, Integer.MAX_VALUE > ); > 480 int remaining = maxSize; > //maxSize is Integer.MAX_VALUE > 483 int n = input.read( buffer, 0, Math.min( > buffer.length, remaining ) ); > //read in full file (up to Integer.MAX_VALUE in length) into buffer [memory] > 492 output.write( buffer, 0, n ); > //then write it out > > So yes, it seems like it does read in the entire file into memory. I don't know. To me it looks like the code limits it to sending DEFAULT_BUFFER_SIZE (4K) at a time. Phillip - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Heap overflow in deploy:deploy
It is a known problem where maven (wagon) uses jvm's httpclient to do the upload. -D On Wed, Oct 13, 2010 at 8:52 PM, Ron Wheeler wrote: > On 13/10/2010 7:29 PM, Phillip Hellewell wrote: >> >> I'm using Maven 2.2.1 and getting a heap overflow when trying to >> deploy an artifact about 50MB in size. I'm deploying to an Nexus >> server (HTTP). >> >> I added "@set MAVEN_OPTS=-Xms128m -Xmx512m" to my mvn.bat and now it is >> working. >> >> But my question is, why should uploading a file require so much >> memory? It's not like it tries to read the whole file into memory, or >> does it? If so, that seems kinda dumb. > > We have seen this one as well. > Probably more of a comment on the guys that set the default way too low. > Who would buy a computer with 512Mb of memory and no paging space? > I suspect that the guys that write the code that we use, do not have real > world examples where you need to move 50 Mb around. > We had the problem with CXF (Apache web services) where we could not deploy > the basic library jar to Nexus without setting the Eclipse parameters for a > JVM fork to something more in keeping with the natural capacity of our > actual workstations (2Gb physical memory with 4Gb of cache) . > I just set the JVM options to -Xmx1024m to start, on any Java program, > since the JVM is already running in a virtual machine (Linux or Vista) > anyway that can easily deal with a 1Gb task if it does not use the memory. > > Ron >> >> Phillip >> >> P.S. Here's the trace: >> >> java.lang.OutOfMemoryError: Java heap space >> at java.util.Arrays.copyOf(Unknown Source) >> at java.io.ByteArrayOutputStream.write(Unknown Source) >> at sun.net.www.http.PosterOutputStream.write(Unknown Source) >> 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:163) >> at >> org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:317) >> at >> org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:227) >> 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:490) >> at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) >> at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) >> at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) >> at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) >> at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) >> at >> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) >> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) >> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) >> at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) >> at >> org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) >> at java.lang.reflect.Method.invoke(Unknown Source) >> 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) >> >> - >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org >> For additional commands, e-mail: users-h...@maven.apache.org >> >> > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For addit
Re: Heap overflow in deploy:deploy
On 13/10/2010 7:29 PM, Phillip Hellewell wrote: I'm using Maven 2.2.1 and getting a heap overflow when trying to deploy an artifact about 50MB in size. I'm deploying to an Nexus server (HTTP). I added "@set MAVEN_OPTS=-Xms128m -Xmx512m" to my mvn.bat and now it is working. But my question is, why should uploading a file require so much memory? It's not like it tries to read the whole file into memory, or does it? If so, that seems kinda dumb. We have seen this one as well. Probably more of a comment on the guys that set the default way too low. Who would buy a computer with 512Mb of memory and no paging space? I suspect that the guys that write the code that we use, do not have real world examples where you need to move 50 Mb around. We had the problem with CXF (Apache web services) where we could not deploy the basic library jar to Nexus without setting the Eclipse parameters for a JVM fork to something more in keeping with the natural capacity of our actual workstations (2Gb physical memory with 4Gb of cache) . I just set the JVM options to -Xmx1024m to start, on any Java program, since the JVM is already running in a virtual machine (Linux or Vista) anyway that can easily deal with a 1Gb task if it does not use the memory. Ron Phillip P.S. Here's the trace: java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Unknown Source) at java.io.ByteArrayOutputStream.write(Unknown Source) at sun.net.www.http.PosterOutputStream.write(Unknown Source) 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:163) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:317) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:227) 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:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) 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) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Heap overflow in deploy:deploy
> Maybe taking a look at the source code would help you figure out why > its giving you problems? You probably want to look at the following lines in particular: 457 transfer( resource, input, output, requestType, Integer.MAX_VALUE ); 480 int remaining = maxSize; //maxSize is Integer.MAX_VALUE 483 int n = input.read( buffer, 0, Math.min( buffer.length, remaining ) ); //read in full file (up to Integer.MAX_VALUE in length) into buffer [memory] 492 output.write( buffer, 0, n ); //then write it out >> But my question is, why should uploading a file require so much >> memory? It's not like it tries to read the whole file into memory, or >> does it? If so, that seems kinda dumb. So yes, it seems like it does read in the entire file into memory. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Heap overflow in deploy:deploy
> But my question is, why should uploading a file require so much > memory? It's not like it tries to read the whole file into memory, or > does it? If so, that seems kinda dumb. Maybe taking a look at the source code would help you figure out why its giving you problems? http://maven.apache.org/wagon/wagon-provider-api/xref/org/apache/maven/wagon/AbstractWagon.html If you patch a bug, please contribute it back. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Heap overflow in deploy:deploy
I'm using Maven 2.2.1 and getting a heap overflow when trying to deploy an artifact about 50MB in size. I'm deploying to an Nexus server (HTTP). I added "@set MAVEN_OPTS=-Xms128m -Xmx512m" to my mvn.bat and now it is working. But my question is, why should uploading a file require so much memory? It's not like it tries to read the whole file into memory, or does it? If so, that seems kinda dumb. Phillip P.S. Here's the trace: java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Unknown Source) at java.io.ByteArrayOutputStream.write(Unknown Source) at sun.net.www.http.PosterOutputStream.write(Unknown Source) 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:163) at org.apache.maven.artifact.manager.DefaultWagonManager.putRemoteFile(DefaultWagonManager.java:317) at org.apache.maven.artifact.manager.DefaultWagonManager.putArtifact(DefaultWagonManager.java:227) 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:490) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) 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) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Heap overflow in deploy:deploy-file
At least on *nix, you can set MAVEN_OPTS in ~/.mavenrc On Fri, 2007-09-07 at 11:16 +0200, Jo Vandermeeren wrote: > Have you tried increasing the max heap size for maven by setting > MAVEN_OPTS? > > On Fri, 2007-09-07 at 02:08 -0700, Larry Suto wrote: > > > Hi I am trying to upload an artifact to Maven repository with > > deploy:deploy-file. I am getting a java.lang.OutOfMemoryError > > . The file is about 42mb in size. I am using Maven 2.07. Has anyone else > > come across this problem. > > > > Thanks, > > > > Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Heap overflow in deploy:deploy-file
Thanks it works On 9/7/07, ossi petz <[EMAIL PROTECTED]> wrote: > > hallo > > outofmemory yes, but with reports. > > set an env varaiable: > > MAVEN_OPTS=-Xms128m -Xmx512m > > to allow maven to use more memory. that should do the trick > > > regards > ossi > > > > Larry Suto schrieb: > > Hi I am trying to upload an artifact to Maven repository with > > deploy:deploy-file. I am getting a java.lang.OutOfMemoryError > > . The file is about 42mb in size. I am using Maven 2.07. Has anyone else > > come across this problem. > > > > Thanks, > > > > Larry > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Heap overflow in deploy:deploy-file
Have you tried increasing the max heap size for maven by setting MAVEN_OPTS? On Fri, 2007-09-07 at 02:08 -0700, Larry Suto wrote: > Hi I am trying to upload an artifact to Maven repository with > deploy:deploy-file. I am getting a java.lang.OutOfMemoryError > . The file is about 42mb in size. I am using Maven 2.07. Has anyone else > come across this problem. > > Thanks, > > Larry
Re: Heap overflow in deploy:deploy-file
hallo outofmemory yes, but with reports. set an env varaiable: MAVEN_OPTS=-Xms128m -Xmx512m to allow maven to use more memory. that should do the trick regards ossi Larry Suto schrieb: Hi I am trying to upload an artifact to Maven repository with deploy:deploy-file. I am getting a java.lang.OutOfMemoryError . The file is about 42mb in size. I am using Maven 2.07. Has anyone else come across this problem. Thanks, Larry - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Heap overflow in deploy:deploy-file
Hi I am trying to upload an artifact to Maven repository with deploy:deploy-file. I am getting a java.lang.OutOfMemoryError . The file is about 42mb in size. I am using Maven 2.07. Has anyone else come across this problem. Thanks, Larry