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: Security Problems With Uber Jar
> Exception in thread "main" java.lang.SecurityException: Invalid signature > file digest for Manifest main attributes > > the problem seems to be that the jar is no longer signed properly. Has > anyone else run into this problem before and found a way to fix it? If the signature is a problem... did you just try to resign it? I readily admit that my expertise in this area is pretty shallow, limited to a few thick clients and applets that we signed so we could get out of the sandbox. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Getting compilation errors despite including the correct repo
> > src Are you sure about that line, or is it also potentially incorrect? 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
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: Getting compilation errors despite including the correct repo
Thanks, Dennis. I removed that line, leaving my pom.xml like below, however, I'm sadly getting the same compilation errors. Any other advice for things I should troubleshoot? - Dave ==Begin pom.xml 4.0.0 leads_testing leads_testing 1.0-SNAPSHOT junit junit 4.8.2 test org.seleniumhq.selenium.client-drivers selenium-java-client-driver 1.0.1 test oracle classes12 10.2.0.3.0 src maven-compiler-plugin 1.6 1.6 ===End pom.xml -- View this message in context: http://maven.40175.n5.nabble.com/Getting-compilation-errors-despite-including-the-correct-repo-tp4382157p4383031.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: Best practice for migrating existing system
Not every problem is solved by waving the lemon of 'SOA' over it and expecting it to turn into lemonade. Some of us code things that have actual computations in them, and those computations have shared, reused classes, and those classes do not belong behind a web service -- either for performance or sheer common sense. And the effect of this, in toto, is that it highlights some of the edges of what the maven-release-plugin is useful for. When working on the far side of those edges, it makes (to me) more sense to find another procedure than to warp the software architecture. There's a line between "the maven way" and "procrustes' bed," and that line does not necessarily pass through a point at infinity. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Fwd: creating dynamic menu used in maven site plugin
Hi. I'm trying this mailinglist since I got no response on the dev mailing list. Regards Thobias Bergqvist -- Forwarded message -- From: Thobias Bergqvist Date: Sat, Apr 30, 2011 at 1:33 AM Subject: creating dynamic menu used in maven site plugin To: d...@maven.apache.org Hi. I'm looking into the maven-site-plugin but can't figure out how to create my own menu. What I want is to specify in my site.xml something similar to i.e. . Then I want in the site generating phase to add menu items of the 3, or something plugin-configurable, latest examples. Example: First I write 3 articles about something in different apt-files. The resulting menu would then look like this: Latest How to speak How to eat How to crawl Then I write another article about something in another apt-file. The resulting menu would look like this: Latest How to code How to speak How to eat What is the best practise concerning this? And is this the place to ask for help? best regards Thobias Bergvist - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Security Problems With Uber Jar
I'm using shade to create an uber jar, but when I try to run it I get C:\Program Files (Open)\Kodak\Intersystem\Service>java -jar service.jar Exception in thread "main" java.lang.SecurityException: Invalid signature file digest for Manifest main attributes at sun.security.util.SignatureFileVerifier.processImpl(Unknown Source) at sun.security.util.SignatureFileVerifier.process(Unknown Source) at java.util.jar.JarVerifier.processEntry(Unknown Source) at java.util.jar.JarVerifier.update(Unknown Source) at java.util.jar.JarFile.initializeVerifier(Unknown Source) at java.util.jar.JarFile.getInputStream(Unknown Source) at sun.misc.URLClassPath$JarLoader$2.getInputStream(Unknown Source) at sun.misc.Resource.cachedInputStream(Unknown Source) at sun.misc.Resource.getByteBuffer(Unknown Source) at java.net.URLClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.access$000(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) Could not find the main class: com.kodak.intersystem.service.Service. Program will exit. According to http://www.mail-archive.com/itext-questions@lists.sourceforge.net/msg34999.html the problem seems to be that the jar is no longer signed properly. Has anyone else run into this problem before and found a way to fix it? Cheers, Eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Getting compilation errors despite including the correct repo
On 2011-05-09 17:24, laredotornado-3 wrote: > Hi, > > I'm using Maven 3.0.3. I want to run "mvn test" to execute some a Junit > test, but I'm getting some compilation errors. I have placed my test file > in my src/test/java/package/of/my/file directory, and included the > appropriate JUnit JAR in my dependency list (pom.xml listed below). > However, I'll get compilation errors like > > [ERROR] symbol : class After > [ERROR] location: class com.myco.infinitiusa.tests.InfinitiConfigOldG25Base > [ERROR] > /Users/davea/Documents/workspace-sts-2.6.0.SR1/infinitiusa_leads_testing/src/test/java/com/myco/infinitiusa/tests/InfinitiConfigOldG25Base.java:[43,2] > cannot find symbol > > Below is my pom.xml. What am I overlooking? Thanks, - Dave > > > 4.0.0 > infinitiusa_leads_testing > infinitiusa_leads_testing > 1.0-SNAPSHOT > > > junit > junit > 4.8.2 > test > > > > org.seleniumhq.selenium.client-drivers > selenium-java-client-driver > 1.0.1 > test > > > > > src > test Here you are telling Maven that your tests are in the folder 'test', not 'src/test/java'. > > > maven-compiler-plugin > > 1.6 > 1.6 > > > > > > ~ > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Getting-compilation-errors-despite-including-the-correct-repo-tp4382157p4382157.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 > > -- Dennis Lundberg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Getting compilation errors despite including the correct repo
That is a good thought, but this is one of 50 errors, all classes located in the junit jar. I do have the import statements at the top of my Java file. Is the test goal any different classpath-wise than other goals? I have verified that the junit Jar is in my local repo -- ~/.m2/repository/junit/junit/4.8.2/junit-4.8.2.jar . - Dave =Begin imports === import com.thoughtworks.selenium.*; import org.junit.After; import org.junit.Before; import org.junit.Test; import java.sql.Connection; import java.sql.PreparedStatement; import java.sql.ResultSet; import java.sql.DriverManager; import java.util.Calendar; import java.util.Properties; import java.util.regex.Pattern; import java.io.InputStream; import junit.framework.Assert; End imports === -- View this message in context: http://maven.40175.n5.nabble.com/Getting-compilation-errors-despite-including-the-correct-repo-tp4382157p4382531.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: Best practice for migrating existing system
On 09/05/2011 11:25 AM, Benson Margulies wrote: It sounds good, but there's a medium size in which it doesn't quite work out this way. You can't create a new maven module for every single class. Thus, in my experience, we have ended up with some sort of 'common' component that (a) gets a lot of changes and (b) has many things that depend on it -- at least in the early phases of building out a large system. Over time, that component slows down, or even splits up. Every class is way too much. Separating business functions from utilities is a good place to start. Moving to SOA and breaking the business processes into services is a "good thing". This hides datastructure details from many levels and isolates processing into services that are shared. Functional changes start to have smaller scope and it becomes easier to identify the modules that are affected. Ron On Mon, May 9, 2011 at 11:10 AM, Ron Wheeler wrote: On 09/05/2011 10:42 AM, Wayne Fay wrote: As far as I can tell, Option 1 is only practical once the velocity of change slows down to the point where at least some components sit unchanged for a good long time -- that is, for more than one development iteration. It's only useful to 'use a version with a But it seems like a good (best?) practice to break modules up into functional components such that parts which have no reason to change for a given release are not changed. If you find it annoying that a small change in a small piece of code that is wrapped up inside a much larger library means the entire library has to bump a version, you may want to consider breaking the smaller bits out into its own independent module. Especially if the velocity of change in those small bits is significantly greater than the velocity of the rest of the bits. This does mean that you may end up with 150 modules rather than 70. Suddenly your processes which were OK at 70 modules are really not working with 150, so you may need to be willing to adjust your processes etc as well. +1 More robust structure Easier to assure that small functional modules are working correctly Easier to test libraries than applications - usually. Increases likeliness of sharing of code. Lots of other good reasons to do this. Maven and Nexus makes it easy to manage this. Ron Wayne - 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 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: Maven, Subversion and Eclipse issue
Yep the team menu worked. Thank you for that tip. Always the simple things we overlook... --Refr inn gra "Wars are to be won with swords and spears, not with rice and salt." -- Uesugi Kenshin - Original Message From: Refr Bruhl To: Maven Users List Cc: Subversion Mailing List Sent: Mon, May 9, 2011 12:54:01 PM Subject: Re: Maven, Subversion and Eclipse issue I did not catch that until you told me about it. I will experiment with that today. Thank you! --Refr inn gra "Wars are to be won with swords and spears, not with rice and salt." -- Uesugi Kenshin - Original Message From: Ron Wheeler To: users@maven.apache.org Sent: Mon, May 9, 2011 12:22:15 PM Subject: Re: Maven, Subversion and Eclipse issue You can do it in Eclipse from the Team menu. On 09/05/2011 11:07 AM, Refr Bruhl wrote: > So that is manual svn command outside of eclipse? > > I'll give it a shot. Thank you! > > --Refr inn gra > > > "Wars are to be won with swords and spears, > not with rice and salt." -- Uesugi Kenshin > > > > - Original Message > From: Brian Smith > To: Maven Users List > Cc: Subversion Mailing List > Sent: Mon, May 9, 2011 9:56:14 AM > Subject: Re: Maven, Subversion and Eclipse issue > > We set the following on each module's trunk: > > $ svn ps svn:ignore core " > target > .project > .classpath > .settings" > > > > On 9 May 2011 15:42, Refr Bruhl wrote: > >> Team >> >> I've an issue with the m2 plugin using maven in conjunction with >> subversion. >> Since this crosses three platforms I thought I would try both the >> subversion and >> maven list to see if anyone has run across a similar issue and what the >> solution >> was. >> >> When maven dependency is enabled for an eclipse project the maven plugin >> will >> ensure the target subdirectory exists. This is usally a good thing. >> >> >> When the project is committed to subversion is when issues arise >> >> When a mvn clean is issued either thru the plugin or at the command shell >> the >> target directory is deleted. The eclipse maven 2 plugin will recreate the >> target >> subdirectory >> >> However subversion now complains the directory is out of sync. Most times >> the >> subversion plugin will not allow a force update. >> >> >> My current workaround is not to commit the entire project -- just subfolder >> components when I make updates. I'm thinking there is a cleaner solution to >> this. >> >> Using this method I am forced to use svn shell commands to create tags. The >> tag >> feature of the subversion plugin will not work unless all sub directories >> are >> commitable. >> >> >> has anyone else ran into this? If so what solutions or workarounds were >> found? >> >> >> Platform details below >> >> Eclipse: >> >> Eclipse Java EE IDE for Web Developers. >> >> Version: Helios Release >> Build id: 20100617-1415 >> >> (c) Copyright Eclipse contributors and others 2005, 2010. All rights >> reserved. >> Visit http://www.eclipse.org/webtools >> >> Maven for Eclipse: >> >> M2 plugin by Sonatype 0.12.1.2011 >> >> Subversion for Eclipse >> Subversive byu Polarion 2.2.2 >> >> >> OS: Windows XP >> >> >> --Refr inn gra >> >> >> "Wars are to be won with swords and spears, >> not with rice and salt." -- Uesugi Kenshin >> >> >> - >> 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 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: Maven, Subversion and Eclipse issue
I did not catch that until you told me about it. I will experiment with that today. Thank you! --Refr inn gra "Wars are to be won with swords and spears, not with rice and salt." -- Uesugi Kenshin - Original Message From: Ron Wheeler To: users@maven.apache.org Sent: Mon, May 9, 2011 12:22:15 PM Subject: Re: Maven, Subversion and Eclipse issue You can do it in Eclipse from the Team menu. On 09/05/2011 11:07 AM, Refr Bruhl wrote: > So that is manual svn command outside of eclipse? > > I'll give it a shot. Thank you! > > --Refr inn gra > > > "Wars are to be won with swords and spears, > not with rice and salt." -- Uesugi Kenshin > > > > - Original Message > From: Brian Smith > To: Maven Users List > Cc: Subversion Mailing List > Sent: Mon, May 9, 2011 9:56:14 AM > Subject: Re: Maven, Subversion and Eclipse issue > > We set the following on each module's trunk: > > $ svn ps svn:ignore core " > target > .project > .classpath > .settings" > > > > On 9 May 2011 15:42, Refr Bruhl wrote: > >> Team >> >> I've an issue with the m2 plugin using maven in conjunction with >> subversion. >> Since this crosses three platforms I thought I would try both the >> subversion and >> maven list to see if anyone has run across a similar issue and what the >> solution >> was. >> >> When maven dependency is enabled for an eclipse project the maven plugin >> will >> ensure the target subdirectory exists. This is usally a good thing. >> >> >> When the project is committed to subversion is when issues arise >> >> When a mvn clean is issued either thru the plugin or at the command shell >> the >> target directory is deleted. The eclipse maven 2 plugin will recreate the >> target >> subdirectory >> >> However subversion now complains the directory is out of sync. Most times >> the >> subversion plugin will not allow a force update. >> >> >> My current workaround is not to commit the entire project -- just subfolder >> components when I make updates. I'm thinking there is a cleaner solution to >> this. >> >> Using this method I am forced to use svn shell commands to create tags. The >> tag >> feature of the subversion plugin will not work unless all sub directories >> are >> commitable. >> >> >> has anyone else ran into this? If so what solutions or workarounds were >> found? >> >> >> Platform details below >> >> Eclipse: >> >> Eclipse Java EE IDE for Web Developers. >> >> Version: Helios Release >> Build id: 20100617-1415 >> >> (c) Copyright Eclipse contributors and others 2005, 2010. All rights >> reserved. >> Visit http://www.eclipse.org/webtools >> >> Maven for Eclipse: >> >> M2 plugin by Sonatype 0.12.1.2011 >> >> Subversion for Eclipse >> Subversive byu Polarion 2.2.2 >> >> >> OS: Windows XP >> >> >> --Refr inn gra >> >> >> "Wars are to be won with swords and spears, >> not with rice and salt." -- Uesugi Kenshin >> >> >> - >> 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 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: Maven, Subversion and Eclipse issue
You can do it in Eclipse from the Team menu. On 09/05/2011 11:07 AM, Refr Bruhl wrote: So that is manual svn command outside of eclipse? I'll give it a shot. Thank you! --Refr inn gra "Wars are to be won with swords and spears, not with rice and salt." -- Uesugi Kenshin - Original Message From: Brian Smith To: Maven Users List Cc: Subversion Mailing List Sent: Mon, May 9, 2011 9:56:14 AM Subject: Re: Maven, Subversion and Eclipse issue We set the following on each module's trunk: $ svn ps svn:ignore core " target .project .classpath .settings" On 9 May 2011 15:42, Refr Bruhl wrote: Team I've an issue with the m2 plugin using maven in conjunction with subversion. Since this crosses three platforms I thought I would try both the subversion and maven list to see if anyone has run across a similar issue and what the solution was. When maven dependency is enabled for an eclipse project the maven plugin will ensure the target subdirectory exists. This is usally a good thing. When the project is committed to subversion is when issues arise When a mvn clean is issued either thru the plugin or at the command shell the target directory is deleted. The eclipse maven 2 plugin will recreate the target subdirectory However subversion now complains the directory is out of sync. Most times the subversion plugin will not allow a force update. My current workaround is not to commit the entire project -- just subfolder components when I make updates. I'm thinking there is a cleaner solution to this. Using this method I am forced to use svn shell commands to create tags. The tag feature of the subversion plugin will not work unless all sub directories are commitable. has anyone else ran into this? If so what solutions or workarounds were found? Platform details below Eclipse: Eclipse Java EE IDE for Web Developers. Version: Helios Release Build id: 20100617-1415 (c) Copyright Eclipse contributors and others 2005, 2010. All rights reserved. Visit http://www.eclipse.org/webtools Maven for Eclipse: M2 plugin by Sonatype 0.12.1.2011 Subversion for Eclipse Subversive byu Polarion 2.2.2 OS: Windows XP --Refr inn gra "Wars are to be won with swords and spears, not with rice and salt." -- Uesugi Kenshin - 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 additional commands, e-mail: users-h...@maven.apache.org
Re: Getting compilation errors despite including the correct repo
> [ERROR] symbol : class After > [ERROR] location: class com.myco.infinitiusa.tests.InfinitiConfigOldG25Base > cannot find symbol The class is org.junit.After. Are you missing an import statement maybe? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Use of Doxia for mixed horizontal-vertical navigation
Hi, I have a website written using a customised version of the Maven1 site process. See http://www.datanucleus.org/products/accessplatform_3_0/index.html To explain, I have horizontal navigation as a form of top-level menu, and then each top-level option defines what vertical navigation options are added to the side of the pages in that section. e,g I have horizontal (top-level) navigation options of "General | JDO Mapping | JPA Mapping | JDO API | JPA API | REST API | Guides" and under "General" I have vertical navigation of "Welcome", "Whats New", ... and if I click on "JDO Mapping" I have vertical navigation of "Class Mapping", "Identity", ... etc Is there some way that the same can be achieved using Doxia? (and Maven2/3). If so, how would I configure the site.xml to do that? Second question, the current site using Maven1 could previously use the Maven1 PDF plugin (using FOP) to generate a PDF of the docs. The docs have since grown and gained many cross-links, causing FOP to give OutOfMemory. Does Doxia use another process to generate PDF that may get around this problem? TIA -- Andy
Getting compilation errors despite including the correct repo
Hi, I'm using Maven 3.0.3. I want to run "mvn test" to execute some a Junit test, but I'm getting some compilation errors. I have placed my test file in my src/test/java/package/of/my/file directory, and included the appropriate JUnit JAR in my dependency list (pom.xml listed below). However, I'll get compilation errors like [ERROR] symbol : class After [ERROR] location: class com.myco.infinitiusa.tests.InfinitiConfigOldG25Base [ERROR] /Users/davea/Documents/workspace-sts-2.6.0.SR1/infinitiusa_leads_testing/src/test/java/com/myco/infinitiusa/tests/InfinitiConfigOldG25Base.java:[43,2] cannot find symbol Below is my pom.xml. What am I overlooking? Thanks, - Dave 4.0.0 infinitiusa_leads_testing infinitiusa_leads_testing 1.0-SNAPSHOT junit junit 4.8.2 test org.seleniumhq.selenium.client-drivers selenium-java-client-driver 1.0.1 test src test maven-compiler-plugin 1.6 1.6 ~ -- View this message in context: http://maven.40175.n5.nabble.com/Getting-compilation-errors-despite-including-the-correct-repo-tp4382157p4382157.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: dependency checksum failling
> Actually the checksum is failing because the jar file is corrupted. That's > why the building is breaking. You'll have to complain to the owner of that Netbeans repo to get a corrupted file fixed. This is not the right place to complain about such matters. > What do you mean with things locked down? I was suggesting that the default configuration of Maven will not BREAK your build simply due to checksums not matching. Only if you "lock things down" with some stricter configuration would the build fail on such issues. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best practice for migrating existing system
> of 'common' component that (a) gets a lot of changes and (b) has many > things that depend on it -- at least in the early phases of building > out a large system. Over time, that component slows down, or even > splits up. Yes, this echoes my experience as well. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: cargo tomcat configurations in settings.xml
I solved this problem. Acutally maven is unable to read the settings.xml file. So I placed the file in users home/.m2 directory then it worked. Thanks for your support. -- View this message in context: http://maven-users.828.n2.nabble.com/cargo-tomcat-configurations-in-settings-xml-tp6338184p6344655.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: Best practice for migrating existing system
It sounds good, but there's a medium size in which it doesn't quite work out this way. You can't create a new maven module for every single class. Thus, in my experience, we have ended up with some sort of 'common' component that (a) gets a lot of changes and (b) has many things that depend on it -- at least in the early phases of building out a large system. Over time, that component slows down, or even splits up. On Mon, May 9, 2011 at 11:10 AM, Ron Wheeler wrote: > On 09/05/2011 10:42 AM, Wayne Fay wrote: >>> >>> As far as I can tell, Option 1 is only practical once the velocity of >>> change slows down to the point where at least some components sit >>> unchanged for a good long time -- that is, for more than one >>> development iteration. It's only useful to 'use a version with a >> >> But it seems like a good (best?) practice to break modules up into >> functional components such that parts which have no reason to change >> for a given release are not changed. If you find it annoying that a >> small change in a small piece of code that is wrapped up inside a much >> larger library means the entire library has to bump a version, you may >> want to consider breaking the smaller bits out into its own >> independent module. Especially if the velocity of change in those >> small bits is significantly greater than the velocity of the rest of >> the bits. >> >> This does mean that you may end up with 150 modules rather than 70. >> Suddenly your processes which were OK at 70 modules are really not >> working with 150, so you may need to be willing to adjust your >> processes etc as well. > > +1 > More robust structure > Easier to assure that small functional modules are working correctly > Easier to test libraries than applications - usually. > Increases likeliness of sharing of code. > > Lots of other good reasons to do this. > > Maven and Nexus makes it easy to manage this. > > Ron >> >> Wayne >> >> - >> 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 additional commands, e-mail: users-h...@maven.apache.org
Re: Maven, Subversion and Eclipse issue
Somethnig to investigate. Thanks for the heads up }:O) --Refr inn gra "Wars are to be won with swords and spears, not with rice and salt." -- Uesugi Kenshin - Original Message From: Fernando Ribeiro To: Maven Users List Cc: Subversion Mailing List Sent: Mon, May 9, 2011 10:05:48 AM Subject: Re: Maven, Subversion and Eclipse issue The SVN ignore file does that trick, right? on, May 9, 2011 at 12:03 PM, Refr Bruhl wrote: > > The subversion plugin doesn't really give that as an option unless every > time > you commit you uncheck the target directory. It would be nice if the > subversion > plugin had an option to exclude directories at set up time. > > > > --Refr inn gra > > > "Wars are to be won with swords and spears, > not with rice and salt." -- Uesugi Kenshin > > > > - Original Message > From: Alex Lopez > To: users@maven.apache.org > Sent: Mon, May 9, 2011 9:50:36 AM > Subject: Re: Maven, Subversion and Eclipse issue > > never a good idea to commit the target dir IMO... > > Em 09-05-2011 15:42, Refr Bruhl escreveu: > > > > Team > > > > I've an issue with the m2 plugin using maven in conjunction with > subversion. > > Since this crosses three platforms I thought I would try both the > subversion > >and > > maven list to see if anyone has run across a similar issue and what the > >solution > > was. > > > > When maven dependency is enabled for an eclipse project the maven plugin > will > > ensure the target subdirectory exists. This is usally a good thing. > > > > > > When the project is committed to subversion is when issues arise > > > > When a mvn clean is issued either thru the plugin or at the command shell > the > > target directory is deleted. The eclipse maven 2 plugin will recreate the > >target > > subdirectory > > > > However subversion now complains the directory is out of sync. Most times > the > > subversion plugin will not allow a force update. > > > > > > My current workaround is not to commit the entire project -- just > subfolder > > components when I make updates. I'm thinking there is a cleaner solution > to > > this. > > > > Using this method I am forced to use svn shell commands to create tags. > The > tag > > feature of the subversion plugin will not work unless all sub directories > are > > commitable. > > > > > > has anyone else ran into this? If so what solutions or workarounds were > found? > > > > > > Platform details below > > > > Eclipse: > > > > Eclipse Java EE IDE for Web Developers. > > > > Version: Helios Release > > Build id: 20100617-1415 > > > > (c) Copyright Eclipse contributors and others 2005, 2010. All rights > reserved. > > Visit http://www.eclipse.org/webtools > > > > Maven for Eclipse: > > > > M2 plugin by Sonatype 0.12.1.2011 > > > > Subversion for Eclipse > > Subversive byu Polarion 2.2.2 > > > > > > OS: Windows XP > > > > > > --Refr inn gra > > > > > > "Wars are to be won with swords and spears, > > not with rice and salt." -- Uesugi Kenshin > > > > > > - > > 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 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: Maven, Subversion and Eclipse issue
The SVN ignore file does that trick, right? on, May 9, 2011 at 12:03 PM, Refr Bruhl wrote: > > The subversion plugin doesn't really give that as an option unless every > time > you commit you uncheck the target directory. It would be nice if the > subversion > plugin had an option to exclude directories at set up time. > > > > --Refr inn gra > > > "Wars are to be won with swords and spears, > not with rice and salt." -- Uesugi Kenshin > > > > - Original Message > From: Alex Lopez > To: users@maven.apache.org > Sent: Mon, May 9, 2011 9:50:36 AM > Subject: Re: Maven, Subversion and Eclipse issue > > never a good idea to commit the target dir IMO... > > Em 09-05-2011 15:42, Refr Bruhl escreveu: > > > > Team > > > > I've an issue with the m2 plugin using maven in conjunction with > subversion. > > Since this crosses three platforms I thought I would try both the > subversion > >and > > maven list to see if anyone has run across a similar issue and what the > >solution > > was. > > > > When maven dependency is enabled for an eclipse project the maven plugin > will > > ensure the target subdirectory exists. This is usally a good thing. > > > > > > When the project is committed to subversion is when issues arise > > > > When a mvn clean is issued either thru the plugin or at the command shell > the > > target directory is deleted. The eclipse maven 2 plugin will recreate the > >target > > subdirectory > > > > However subversion now complains the directory is out of sync. Most times > the > > subversion plugin will not allow a force update. > > > > > > My current workaround is not to commit the entire project -- just > subfolder > > components when I make updates. I'm thinking there is a cleaner solution > to > > this. > > > > Using this method I am forced to use svn shell commands to create tags. > The > tag > > feature of the subversion plugin will not work unless all sub directories > are > > commitable. > > > > > > has anyone else ran into this? If so what solutions or workarounds were > found? > > > > > > Platform details below > > > > Eclipse: > > > > Eclipse Java EE IDE for Web Developers. > > > > Version: Helios Release > > Build id: 20100617-1415 > > > > (c) Copyright Eclipse contributors and others 2005, 2010. All rights > reserved. > > Visit http://www.eclipse.org/webtools > > > > Maven for Eclipse: > > > > M2 plugin by Sonatype 0.12.1.2011 > > > > Subversion for Eclipse > > Subversive byu Polarion 2.2.2 > > > > > > OS: Windows XP > > > > > > --Refr inn gra > > > > > > "Wars are to be won with swords and spears, > > not with rice and salt." -- Uesugi Kenshin > > > > > > - > > 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 additional commands, e-mail: users-h...@maven.apache.org > >
Re: Best practice for migrating existing system
On 09/05/2011 10:42 AM, Wayne Fay wrote: As far as I can tell, Option 1 is only practical once the velocity of change slows down to the point where at least some components sit unchanged for a good long time -- that is, for more than one development iteration. It's only useful to 'use a version with a But it seems like a good (best?) practice to break modules up into functional components such that parts which have no reason to change for a given release are not changed. If you find it annoying that a small change in a small piece of code that is wrapped up inside a much larger library means the entire library has to bump a version, you may want to consider breaking the smaller bits out into its own independent module. Especially if the velocity of change in those small bits is significantly greater than the velocity of the rest of the bits. This does mean that you may end up with 150 modules rather than 70. Suddenly your processes which were OK at 70 modules are really not working with 150, so you may need to be willing to adjust your processes etc as well. +1 More robust structure Easier to assure that small functional modules are working correctly Easier to test libraries than applications - usually. Increases likeliness of sharing of code. Lots of other good reasons to do this. Maven and Nexus makes it easy to manage this. Ron Wayne - 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: Maven, Subversion and Eclipse issue
So that is manual svn command outside of eclipse? I'll give it a shot. Thank you! --Refr inn gra "Wars are to be won with swords and spears, not with rice and salt." -- Uesugi Kenshin - Original Message From: Brian Smith To: Maven Users List Cc: Subversion Mailing List Sent: Mon, May 9, 2011 9:56:14 AM Subject: Re: Maven, Subversion and Eclipse issue We set the following on each module's trunk: $ svn ps svn:ignore core " target .project .classpath .settings" On 9 May 2011 15:42, Refr Bruhl wrote: > > Team > > I've an issue with the m2 plugin using maven in conjunction with > subversion. > Since this crosses three platforms I thought I would try both the > subversion and > maven list to see if anyone has run across a similar issue and what the > solution > was. > > When maven dependency is enabled for an eclipse project the maven plugin > will > ensure the target subdirectory exists. This is usally a good thing. > > > When the project is committed to subversion is when issues arise > > When a mvn clean is issued either thru the plugin or at the command shell > the > target directory is deleted. The eclipse maven 2 plugin will recreate the > target > subdirectory > > However subversion now complains the directory is out of sync. Most times > the > subversion plugin will not allow a force update. > > > My current workaround is not to commit the entire project -- just subfolder > components when I make updates. I'm thinking there is a cleaner solution to > this. > > Using this method I am forced to use svn shell commands to create tags. The > tag > feature of the subversion plugin will not work unless all sub directories > are > commitable. > > > has anyone else ran into this? If so what solutions or workarounds were > found? > > > Platform details below > > Eclipse: > > Eclipse Java EE IDE for Web Developers. > > Version: Helios Release > Build id: 20100617-1415 > > (c) Copyright Eclipse contributors and others 2005, 2010. All rights > reserved. > Visit http://www.eclipse.org/webtools > > Maven for Eclipse: > > M2 plugin by Sonatype 0.12.1.2011 > > Subversion for Eclipse > Subversive byu Polarion 2.2.2 > > > OS: Windows XP > > > --Refr inn gra > > > "Wars are to be won with swords and spears, > not with rice and salt." -- Uesugi Kenshin > > > - > 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: metadata.xml
Gracia, Adrien wrote: The problem we are having, is that even if there is a new version of a SNAPSHOT, the newer version is not downloaded. [...] The way we understood the format of this file is as follow the group id the artifact id ... the formatted timestamp of the most up to date version This file actually exists at different levels of the repository, having a different format/contents at each level. maven-metadata.xml at the groupId level serves plugin prefix mappings, metadata at the groupId:artifactId level serves version range resolution and metadata at the groupId:artifactId:version level supports SNAPSHOT resolution. The format you pasted actually describes groupId:artifactId level metadata. To investigate issues with SNAPSHOT resolution, you need to look at the metadata of this format: org.apache.maven maven-aether-provider 3.0-SNAPSHOT 20101004.110147 62 20101004110401 During resolution of X-SNAPSHOT, Maven will read the maven-metadata.xml for all configured remote repos, select the one having the biggest/newest field, and finally resolve the artifact X--. Now one question would be: Does the order of the version matter? No. Benjamin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven, Subversion and Eclipse issue
The subversion plugin doesn't really give that as an option unless every time you commit you uncheck the target directory. It would be nice if the subversion plugin had an option to exclude directories at set up time. --Refr inn gra "Wars are to be won with swords and spears, not with rice and salt." -- Uesugi Kenshin - Original Message From: Alex Lopez To: users@maven.apache.org Sent: Mon, May 9, 2011 9:50:36 AM Subject: Re: Maven, Subversion and Eclipse issue never a good idea to commit the target dir IMO... Em 09-05-2011 15:42, Refr Bruhl escreveu: > > Team > > I've an issue with the m2 plugin using maven in conjunction with subversion. > Since this crosses three platforms I thought I would try both the subversion >and > maven list to see if anyone has run across a similar issue and what the >solution > was. > > When maven dependency is enabled for an eclipse project the maven plugin will > ensure the target subdirectory exists. This is usally a good thing. > > > When the project is committed to subversion is when issues arise > > When a mvn clean is issued either thru the plugin or at the command shell the > target directory is deleted. The eclipse maven 2 plugin will recreate the >target > subdirectory > > However subversion now complains the directory is out of sync. Most times the > subversion plugin will not allow a force update. > > > My current workaround is not to commit the entire project -- just subfolder > components when I make updates. I'm thinking there is a cleaner solution to > this. > > Using this method I am forced to use svn shell commands to create tags. The tag > feature of the subversion plugin will not work unless all sub directories are > commitable. > > > has anyone else ran into this? If so what solutions or workarounds were found? > > > Platform details below > > Eclipse: > > Eclipse Java EE IDE for Web Developers. > > Version: Helios Release > Build id: 20100617-1415 > > (c) Copyright Eclipse contributors and others 2005, 2010. All rights reserved. > Visit http://www.eclipse.org/webtools > > Maven for Eclipse: > > M2 plugin by Sonatype 0.12.1.2011 > > Subversion for Eclipse > Subversive byu Polarion 2.2.2 > > > OS: Windows XP > > > --Refr inn gra > > > "Wars are to be won with swords and spears, > not with rice and salt." -- Uesugi Kenshin > > > - > 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 additional commands, e-mail: users-h...@maven.apache.org
Re: Maven, Subversion and Eclipse issue
We set the following on each module's trunk: $ svn ps svn:ignore core " target .project .classpath .settings" On 9 May 2011 15:42, Refr Bruhl wrote: > > Team > > I've an issue with the m2 plugin using maven in conjunction with > subversion. > Since this crosses three platforms I thought I would try both the > subversion and > maven list to see if anyone has run across a similar issue and what the > solution > was. > > When maven dependency is enabled for an eclipse project the maven plugin > will > ensure the target subdirectory exists. This is usally a good thing. > > > When the project is committed to subversion is when issues arise > > When a mvn clean is issued either thru the plugin or at the command shell > the > target directory is deleted. The eclipse maven 2 plugin will recreate the > target > subdirectory > > However subversion now complains the directory is out of sync. Most times > the > subversion plugin will not allow a force update. > > > My current workaround is not to commit the entire project -- just subfolder > components when I make updates. I'm thinking there is a cleaner solution to > this. > > Using this method I am forced to use svn shell commands to create tags. The > tag > feature of the subversion plugin will not work unless all sub directories > are > commitable. > > > has anyone else ran into this? If so what solutions or workarounds were > found? > > > Platform details below > > Eclipse: > > Eclipse Java EE IDE for Web Developers. > > Version: Helios Release > Build id: 20100617-1415 > > (c) Copyright Eclipse contributors and others 2005, 2010. All rights > reserved. > Visit http://www.eclipse.org/webtools > > Maven for Eclipse: > > M2 plugin by Sonatype 0.12.1.2011 > > Subversion for Eclipse > Subversive byu Polarion 2.2.2 > > > OS: Windows XP > > > --Refr inn gra > > > "Wars are to be won with swords and spears, > not with rice and salt." -- Uesugi Kenshin > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: Maven, Subversion and Eclipse issue
Definitely. On Mon, May 9, 2011 at 11:50 AM, Alex Lopez wrote: > never a good idea to commit the target dir IMO... > > Em 09-05-2011 15:42, Refr Bruhl escreveu: > >> >> Team >> >> I've an issue with the m2 plugin using maven in conjunction with >> subversion. >> Since this crosses three platforms I thought I would try both the >> subversion and >> maven list to see if anyone has run across a similar issue and what the >> solution >> was. >> >> When maven dependency is enabled for an eclipse project the maven plugin >> will >> ensure the target subdirectory exists. This is usally a good thing. >> >> >> When the project is committed to subversion is when issues arise >> >> When a mvn clean is issued either thru the plugin or at the command shell >> the >> target directory is deleted. The eclipse maven 2 plugin will recreate the >> target >> subdirectory >> >> However subversion now complains the directory is out of sync. Most times >> the >> subversion plugin will not allow a force update. >> >> >> My current workaround is not to commit the entire project -- just >> subfolder >> components when I make updates. I'm thinking there is a cleaner solution >> to >> this. >> >> Using this method I am forced to use svn shell commands to create tags. >> The tag >> feature of the subversion plugin will not work unless all sub directories >> are >> commitable. >> >> >> has anyone else ran into this? If so what solutions or workarounds were >> found? >> >> >> Platform details below >> >> Eclipse: >> >> Eclipse Java EE IDE for Web Developers. >> >> Version: Helios Release >> Build id: 20100617-1415 >> >> (c) Copyright Eclipse contributors and others 2005, 2010. All rights >> reserved. >> Visit http://www.eclipse.org/webtools >> >> Maven for Eclipse: >> >> M2 plugin by Sonatype 0.12.1.2011 >> >> Subversion for Eclipse >> Subversive byu Polarion 2.2.2 >> >> >> OS: Windows XP >> >> >> --Refr inn gra >> >> >> "Wars are to be won with swords and spears, >> not with rice and salt." -- Uesugi Kenshin >> >> >> - >> 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: Maven, Subversion and Eclipse issue
never a good idea to commit the target dir IMO... Em 09-05-2011 15:42, Refr Bruhl escreveu: Team I've an issue with the m2 plugin using maven in conjunction with subversion. Since this crosses three platforms I thought I would try both the subversion and maven list to see if anyone has run across a similar issue and what the solution was. When maven dependency is enabled for an eclipse project the maven plugin will ensure the target subdirectory exists. This is usally a good thing. When the project is committed to subversion is when issues arise When a mvn clean is issued either thru the plugin or at the command shell the target directory is deleted. The eclipse maven 2 plugin will recreate the target subdirectory However subversion now complains the directory is out of sync. Most times the subversion plugin will not allow a force update. My current workaround is not to commit the entire project -- just subfolder components when I make updates. I'm thinking there is a cleaner solution to this. Using this method I am forced to use svn shell commands to create tags. The tag feature of the subversion plugin will not work unless all sub directories are commitable. has anyone else ran into this? If so what solutions or workarounds were found? Platform details below Eclipse: Eclipse Java EE IDE for Web Developers. Version: Helios Release Build id: 20100617-1415 (c) Copyright Eclipse contributors and others 2005, 2010. All rights reserved. Visit http://www.eclipse.org/webtools Maven for Eclipse: M2 plugin by Sonatype 0.12.1.2011 Subversion for Eclipse Subversive byu Polarion 2.2.2 OS: Windows XP --Refr inn gra "Wars are to be won with swords and spears, not with rice and salt." -- Uesugi Kenshin - 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: dependency checksum failling
Hi Wayne, thanks for your reply. Actually the checksum is failing because the jar file is corrupted. That's why the building is breaking. Another important info: It doesn't matter if I download it from my nexus repo or netbens remote repo ( http://bits.netbeans.org/maven2/org/netbeans/modules/org-netbeans-bootstrap/) the file is always corrupted, even if I download it using my browser. I can dowload several other files from the same repos an all of them are ok. I really think it is a proxy issue now, but I wonder why it only happening with this specific file! What do you mean with things locked down? Luiz 2011/5/9 Wayne Fay > > I'm trying to build a simple application with Netbeans using maven. > > The dependency "org-netbeans-bootstrap-RELEASE70.jar" is with checksum > > errors when downloaded and the build is breaking. > > I think Nexus can recalculate checksums and regenerate these files for > you if you ask it the right way. But that would be a question for the > Nexus Users list. Also, I find it odd that your build "is breaking" as > a result of checksum errors -- you must have things locked down, I > doubt most people do that. > > > It seems to be a proxy issue but I can't tell what it is. Its curious > > because in some machines the jar is downloaded properly but in others > not! > > Proxies have certainly been known to cause problems during file > transmission now and then, so this would not surprise me. > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Improvements to Central failover: Temporary IP Change to Central on Monday Night
In short, we're moving to a clustered IP for the US Central machines to improve the reliability and get automatic failover. We know some users have firewall rules locked to the existing IP, if that's you, pay attention: We're failing over to the backover IP tonight so we can install the clustered software on the current ip. Once that's done, the DNS will be reverted back to the current ip. We expect that to happen on Tuesday. For everyone not locked to the IP, we don't anticipate this to have any noticable impact since we're leaving 12 hours minimum for the DNS change to propagate before starting work. (TTL is 5 minutes) If you want to see more details, read here: http://bit.ly/jj2bnu Any concerns, let me know. Thanks, Brian - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best practice for migrating existing system
> As far as I can tell, Option 1 is only practical once the velocity of > change slows down to the point where at least some components sit > unchanged for a good long time -- that is, for more than one > development iteration. It's only useful to 'use a version with a But it seems like a good (best?) practice to break modules up into functional components such that parts which have no reason to change for a given release are not changed. If you find it annoying that a small change in a small piece of code that is wrapped up inside a much larger library means the entire library has to bump a version, you may want to consider breaking the smaller bits out into its own independent module. Especially if the velocity of change in those small bits is significantly greater than the velocity of the rest of the bits. This does mean that you may end up with 150 modules rather than 70. Suddenly your processes which were OK at 70 modules are really not working with 150, so you may need to be willing to adjust your processes etc as well. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven, Subversion and Eclipse issue
Team I've an issue with the m2 plugin using maven in conjunction with subversion. Since this crosses three platforms I thought I would try both the subversion and maven list to see if anyone has run across a similar issue and what the solution was. When maven dependency is enabled for an eclipse project the maven plugin will ensure the target subdirectory exists. This is usally a good thing. When the project is committed to subversion is when issues arise When a mvn clean is issued either thru the plugin or at the command shell the target directory is deleted. The eclipse maven 2 plugin will recreate the target subdirectory However subversion now complains the directory is out of sync. Most times the subversion plugin will not allow a force update. My current workaround is not to commit the entire project -- just subfolder components when I make updates. I'm thinking there is a cleaner solution to this. Using this method I am forced to use svn shell commands to create tags. The tag feature of the subversion plugin will not work unless all sub directories are commitable. has anyone else ran into this? If so what solutions or workarounds were found? Platform details below Eclipse: Eclipse Java EE IDE for Web Developers. Version: Helios Release Build id: 20100617-1415 (c) Copyright Eclipse contributors and others 2005, 2010. All rights reserved. Visit http://www.eclipse.org/webtools Maven for Eclipse: M2 plugin by Sonatype 0.12.1.2011 Subversion for Eclipse Subversive byu Polarion 2.2.2 OS: Windows XP --Refr inn gra "Wars are to be won with swords and spears, not with rice and salt." -- Uesugi Kenshin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: metadata.xml
> Now one question would be: Does the order of the version matter? Off the top of my head, I don't know how the code worked in Maven1 days as I did not start using Maven until Maven2. But it would not surprise me to hear the version ordering was important. This seems like a very easy thing to test before digging too deep into code to sort it out by simply faking a few metadata.xml files for some fake artifacts and seeing which version was picked, then change the metadata.xml (add a new version at top/middle/bottom and adjust lastUpdated) and try an update and see what was picked. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dependency checksum failling
> I'm trying to build a simple application with Netbeans using maven. > The dependency "org-netbeans-bootstrap-RELEASE70.jar" is with checksum > errors when downloaded and the build is breaking. I think Nexus can recalculate checksums and regenerate these files for you if you ask it the right way. But that would be a question for the Nexus Users list. Also, I find it odd that your build "is breaking" as a result of checksum errors -- you must have things locked down, I doubt most people do that. > It seems to be a proxy issue but I can't tell what it is. Its curious > because in some machines the jar is downloaded properly but in others not! Proxies have certainly been known to cause problems during file transmission now and then, so this would not surprise me. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
metadata.xml
Hi We have a jar repository that was created a while back during the maven one time. It is not a maven repo. Now that we are slowly migrating to maven 2/3, we create a wrapper around the repo to be able to send artifact to way maven expects them. This will disappear once all our projects are migrated to maven. We use nexus as our main repo. The problem we are having, is that even if there is a new version of a SNAPSHOT, the newer version is not downloaded. We added the updatePolicy to always for all our snapshot repos and it works for Nexus but not "our repo". We are trying to understand how it works to be able to mimic the behavior. We saw the request for the metadata.xml come and we thought that it was the solution to our problem, but it seems that we are missing something. The way we understood the format of this file is as follow the group id the artifact id ... the formatted timestamp of the most up to date version Now one question would be: Does the order of the version matter? How does it really works? I am doing some remote debugging into the maven code to try to understand the process, but I'd like to see if someone could also point me in the right direction. Thanks a lot Adrien Gracia Bank of America -- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing.
dependency checksum failling
Hi, I'm trying to build a simple application with Netbeans using maven. The dependency "org-netbeans-bootstrap-RELEASE70.jar" is with checksum errors when downloaded and the build is breaking. It seems to be a proxy issue but I can't tell what it is. Its curious because in some machines the jar is downloaded properly but in others not! Has it happened with anyone before? Downloading: http://snepnexus.ep.petrobras.com.br:8080/nexus/content/groups/public//org/netbeans/modules/org-netbeans-bootstrap/RELEASE70/org-netbeans-bootstrap-RELEASE70.jar 370K downloaded (org-netbeans-bootstrap-RELEASE70.jar) *** CHECKSUM FAILED - Checksum failed on download: local = 'c3f33dd49a98370b4e8f94c03bc9b043ed469dab'; remote = '08cc79fe82140df4e8fc04f60210a4230ec8c58a' - RETRYING Downloading: http://snepnexus.ep.petrobras.com.br:8080/nexus/content/groups/public//org/netbeans/modules/org-netbeans-bootstrap/RELEASE70/org-netbeans-bootstrap-RELEASE70.jar 370K downloaded (org-netbeans-bootstrap-RELEASE70.jar) *** CHECKSUM FAILED - Checksum failed on download: local = 'f92efb44f861126408231bc12a3a5e614ffd1f83'; remote = '08cc79fe82140df4e8fc04f60210a4230ec8c58a' - IGNORING Downloading: http://snepnexus.ep.petrobras.com.br:8080/nexus/content/groups/public//org/netbeans/modules/org-netbeans-core-startup/RELEASE70/org-netbeans-core-startup-RELEASE70.jar 755K downloaded (org-netbeans-core-startup-RELEASE70.jar) cheers, Luiz
Re: Run a multimodule build up to a certain module in maven 3
On Thu, May 5, 2011 at 2:44 PM, Wim Deblauwe wrote: > I want to run the build up to the 'server' module, but not run the installer > and installer-gui modules. What would be the easiest way to do this in Maven > 3? In Maven 2, i used the reactor plugin for it. Is this still the best way > or is there a better/easier way in Maven 3? You could put the modules you build less often in a profile, and activate the profile only when you need it. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Run a multimodule build up to a certain module in maven 3
To answer my own question: mvn -pl server -am clean install "-pl server" builds the server project and "-am" makes sure that everything "server" needs is also build. See http://www.sonatype.com/people/2009/10/maven-tips-and-tricks-advanced-reactor-options/ for some more info. The docs on the maven page itself are very short: http://maven.apache.org/guides/mini/guide-multiple-modules.html and they link to a page in "Maven: The definitive guid", but the link ( http://www.sonatype.com/books/maven-book/reference/multimodule.html) is broken. regards, Wim 2011/5/5 Wim Deblauwe > Hi, > > Suppose the following multimodule project > > project > + client-common > + client-gui > + server-common > + server-api > + server > + installer > + installer-gui > > > I want to run the build up to the 'server' module, but not run the > installer and installer-gui modules. What would be the easiest way to do > this in Maven 3? In Maven 2, i used the reactor plugin for it. Is this still > the best way or is there a better/easier way in Maven 3? > > regards, > > Wim >
