Re: Can Maven be used in an nmake environment with VPATH?
build-helper-maven-plugin allows you to add multiple sourcepaths to the build, which could be part of the answer. I've never attempted scripting the sourcepaths in but might be possible. In any case, I've done something similar in the past in an ancient c+java monolithic make build environment paired with ClearCase. Good times. Anyway, our solution was to introduce a Maven repo manager (Nexus in our case) and start modularizing, packaging up and versioning the Java parts properly. If you can use a repo manager, it's much easier to write custom Maven builds to deal with pre-built dependencies than try to add a Maven build on top of a non-standard, convoluted directory hierarchy. Of the 4+h build times where only 1-2% of the codebase would ever change, we got down to ~1h builds, with most of it spent on the C compilation and only a few minutes on the Java side. If there's any good side dealing with legacy envrionments, it's that a large part of the codebase is usually stable and really doesn't have to be compiled over and over again for every build. Kalle On Tue, Mar 31, 2015 at 11:25 AM, Steve Cohen sco...@javactivity.org wrote: I work for an organization which uses an SCM/Build process based on the following: SCM: a ancient legacy horror of a system Build: Alcatel-Lucent nmake With this system the organization maintains a large suite of applications. The system is monstrously inflexible and a pain to work with. They do manage to have an automated build process with it, but no continuous integration. A large proportion of the actual code built by this system is java. Deployment is onto various servers using versions of containers such as weblogic, or sometimes standalone. This requires old JVMs, a few of which are as old as JDK-1.3, and none use a version of java that is still supported by Oracle (=1.7). Deployment is done through RPMs and in some cases Solaris packaging. As you might imagine, change, in such an organization is difficult. The main impediment to change is the accreted base of thousands of makefiles that have been created over the years. But a few intrepid (or maybe foolhardy) souls are thinking of trying. We'd like to use maven to handle the java portion of this process. Its dependency management features would be worth the effort if we could get them. Since replacing the whole system is not in scope, the idea is to use maven to handle the java compilation, archiving into jars, wars, ears, etc., while leaving the packaging, deployment, source control systems as they are. Alcatel-Lucent nmake would invoke maven as it now invokes javac, jar, etc. If we can get this far, future upgrading of other portions of the system may come into play, but not in step 1. Such a transition will happen gradually or not at all. The problem is this. Alcatel-Lucent nmake (and other versions of make such as GNU make) includes the concept of the VPATH, an environment variable containing a path (similar to PATH, etc.) along which to search for dependent source. If a necessary file is not found along the first node of the path, the second is searched for it, then the third, etc. Only if the full VPATH is exhausted is the dependency not satisfied and the build fails. Importantly, if the dependency IS satisfied, then nodes further down the path are not looked at for that dependency. There is a little tutorial here, explaining how this works: http://nmake.alcatel-lucent.com/tutorial/s10.html Needless to say, this is not the way Maven works, especially the compiler plugin, certainly not under default settings. There is the sourcepath setting which invokes the -sourcepath switch on javac, which might be part of a solution. There would then be a need for something that could translate the $VPATH envvar to a sourcepath which would need to dig down through several layers of a directory tree (at least they would be identical in each node -e.g. $NODE/$PROJECT/src/main/java) to produce a sourcepath. I don't think this will work because if I turn on the verbose debug output, I see that maven is putting a path to each source file on the javac command line, and am guessing maven is not going to do this looking over each node of the VPATH. Another option would be to pull the source from the various vpath nodes in reverse order and then use maven in a more normal way. But I imagine that this would have negative performance consequences. Has anyone on this list ever tried anything like this? Or is this too big a hill to even contemplate climbing? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [VOTE] Name our mascot: Shotgun vs The Maven Owl
B. Kalle On Mon, Dec 15, 2014 at 7:53 AM, Tim Astle tas...@nbnet.nb.ca wrote: A - Shotgun Tim On 12/15/2014 6:39 AM, Stephen Connolly wrote: After the run-off round, we are left with two names standing. This second vote will be a straight and simple majority wins. The vote will be open for at least 72 hours (with the potential of an extension until I send a message saying that the polls are closed) There will be no discussion in this thread, we have talked it all enough already. If you want to discuss something, please use a different thread. Vote: [A]: Shotgun [B]: The Maven Owl Thank you very much for your time -Stephen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: M2E and Eclipse Luna ?
On Tue, Jul 1, 2014 at 7:41 AM, Jason van Zyl ja...@takari.io wrote: On Jun 30, 2014, at 11:53 PM, Dan Tran dant...@gmail.com wrote: Possible to configure your nexus to use port 80 so that some of use with strict corp firewall policy can access it? Not anytime soon. I run everything with Jetty on specific ports right now. I'll take a look at using Jetty on port 80 and acting as a front for the other services on the machine. This is not particularly high on my priority list and I'm not installing Apache or NGinx as it complicates the normals infrastructure I have. It's often easier to just redirect the traffic from 80 to 8080. http://glassonionblog.wordpress.com/2011/04/08/tomcat-redirecting-traffic-from-port-8080-to-80-using-iptables/ Kalle Thanks -Dan On Fri, Jun 27, 2014 at 11:49 AM, Jason van Zyl ja...@takari.io wrote: All the extras now live as separate installable units here: http://repository.takari.io:8081/nexus/content/sites/m2e.extras/ On Jun 27, 2014, at 12:42 PM, Dan Tran dant...@gmail.com wrote: My apology, should have been clearer I installed Eclipse Luna and https://repository.sonatype.org/content/repositories/forge-sites/m2e-extras/0.15.0/N/0.15.0.201206251206 the message at the pom is Plugin execution not covered by lifecycle configuration: org.apache.maven.plugins:maven-plugin-plugin:3.2:descriptor (execution: default-descriptor, phase: process-classes) Thanks -D On Fri, Jun 27, 2014 at 4:21 AM, Jason van Zyl ja...@takari.io wrote: What exactly are you seeing? I have several plugins using the maven-plugin packaging and they appear fine. On Jun 26, 2014, at 11:15 PM, Dan Tran dant...@gmail.com wrote: I just try the latest eclipse and try to build exec-mojo-plugin at MOJO, looks like m2e does not recognize maven-plugin-plugin Any one else seeing this? Thanks -D Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Selfish deeds are the shortest path to self destruction. -- The Seven Samuari, Akira Kurosawa Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Three people can keep a secret provided two of them are dead. -- Benjamin Franklin Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io - Our achievements speak for themselves. What we have to keep track of are our failures, discouragements and doubts. We tend to forget the past difficulties, the many false starts, and the painful groping. We see our past achievements as the end result of a clean forward thrust, and our present difficulties as signs of decline and decay. -- Eric Hoffer, Reflections on the Human Condition
Re: Any one in Bay Area ( ~San Jose) with Comcast provider having problem accessing http://central.maven.org/maven2/org/apache/maven/scm/maven-scm-provider-cvsexe/ ?
Works fine for me on Comcast/Bay area. Kalle On Fri, Jun 27, 2014 at 2:12 PM, Dan Tran dant...@gmail.com wrote: I am having a problem[1] accessing http://central.maven.org/maven2/org/apache/maven/scm/maven-scm-provider-cvsexe/ I think it has something to do with CDN close to bayarea with comcast [1] https://issues.sonatype.org/browse/MVNCENTRAL-446 Thanks -Dan
Re: Release plugin release:update-versions ?
mvn versions:use-latest-releases? See http://mojo.codehaus.org/versions-maven-plugin/use-latest-releases-mojo.html. Kalle On Thu, Sep 6, 2012 at 8:43 PM, Billy Newman newman...@gmail.com wrote: I would like to use the release plugin to update versions on some of my projects. However my company does not set SNAPSHOT versions in all projects. I know, I know this is a bad habit but one in which I do not have full control over at the moment :( That being said when I run mvn release:update-versions I get an error saying that my current version is not a SNAPSHOT. Is there a property I can set to override that? I.E. I know its not a snapshot but i would like to run the update all the version #'s anyway. Is this possible? Thanks in advance. Billy - 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
Zero downtime deployment to Tomcat 7 with Maven
As a by-product of some infrastructure work some time ago I hacked together an Ant/Maven script for parallel deployment to Tomcat 7. I just had a discussion about the parallel deployment feature last week with a friend of mine so I figured publishing our script might be of use to somebody: http://tynamo.org/Zero+downtime+deployment+to+Tomcat+7+with+Maven. Enjoy! Kalle - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Release plugin: release project from within subdirectory
On Fri, Jul 20, 2012 at 1:20 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Maven is about doing things the right way, no hacks. Says the purist :P Hacks impede understanding of a project by others (or yourself 6 months later) and are an antipattern What happens when 6 months down the line you need a new feature and decide to upgrade the release plugin? You have relied on the hack, and the hack What happens when you are trying to deliver code but cannot because the tool of the righteous doesn't work for you? Pragmatism always wins. Anyway, to me it looks like a pretty valid use case that you'd have a git repo with associated documentation to go with the code. The canonical example many others before me have mentioned is that you have folders such as documentation/ and development/ at the root your of your git repo. The pomFileName option is there but just doesn't seem to work. Kalle On Friday, 20 July 2012, Kalle Korhonen wrote: Thanks Werdex. Using the release plugin version 2.3.2 and it's still exactly the same, only goalsdeploy -f Sources/pom.xml/goals works when the pom.xml is not in the root, regardless of pomFileName setting. Stephen, isn't that exactly why you want to lock down the plugin versions? I'll take a well-working hack any day over proper but broken. Kalle On Thu, Apr 21, 2011 at 12:23 AM, Stephen Connolly stephen.alan.conno...@gmail.com javascript:; wrote: fyi that is a hack and may not work in future versions when the bug is fixed - 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 20 Apr 2011 15:36, werdex werde...@yahoo.com javascript:; wrote: Hi, The following did trick for me: configuration goalsdeploy -f Sources/pom.xml/goals /configuration -- View this message in context: http://maven-users.828.n2.nabble.com/Release-plugin-release-project-from-within-subdirectory-tp5057222p6290891.html Sent from the maven users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.orgjavascript:; For additional commands, e-mail: users-h...@maven.apache.orgjavascript:; - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org javascript:; For additional commands, e-mail: users-h...@maven.apache.orgjavascript:; - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Release plugin: release project from within subdirectory
Thanks Werdex. Using the release plugin version 2.3.2 and it's still exactly the same, only goalsdeploy -f Sources/pom.xml/goals works when the pom.xml is not in the root, regardless of pomFileName setting. Stephen, isn't that exactly why you want to lock down the plugin versions? I'll take a well-working hack any day over proper but broken. Kalle On Thu, Apr 21, 2011 at 12:23 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: fyi that is a hack and may not work in future versions when the bug is fixed - 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 20 Apr 2011 15:36, werdex werde...@yahoo.com wrote: Hi, The following did trick for me: configuration goalsdeploy -f Sources/pom.xml/goals /configuration -- View this message in context: http://maven-users.828.n2.nabble.com/Release-plugin-release-project-from-within-subdirectory-tp5057222p6290891.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: help needed: problems with eclipse, m2e and wst
On Mon, May 7, 2012 at 12:59 PM, Jason van Zyl ja...@tesla.io wrote: On May 7, 2012, at 3:27 PM, Jörg Hohwiller wrote: Hi Jeff, hi Kalle, thanks for your hints. I will give webby and sysdeo a try. Jetty-run will not help as I need a way to run and debug directly from eclipse including code hot deployment. Webby has fully debugger support, obeys the jetty-maven-plugin configuration for contexts and ports, and support WAR overlays. We don't promote it enough but Webby kicks ass. Combine Webby with JRebel and it's web development nirvana. I thought Tapestry 5 was web development nirvana but to each his own :) For Jetty, I meant http://code.google.com/p/run-jetty-run/. Might need to check out Webby. Kalle - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: help needed: problems with eclipse, m2e and wst
I've always found WTP's generic container support to be too slow and too limiting for me. Sysdeo's Tomcat launcher allows for more explicit control of the classpath, google or see http://tynamo.org/Developing+with+Tomcat+and+Eclipse for more info. run-jetty-run plugin is another good and simple choice. Kalle On Wed, Apr 25, 2012 at 1:43 PM, Jörg Hohwiller jo...@j-hohwiller.de wrote: Hi there, I have problems running/debugging a WAR module out of a maven based multi-module project in Eclipse using WST and Tomcat. The problem is that the classpath is wrong. When I build the WAR and manually deploy to a local tomcat webapps directory all works fine. However in Eclipse I get these ClassNotFoundExceptions. When I expand the JEE sub-modules of the WAR module in servers view, I can see that there are modules missing. If I select the WAR module in Projects view and check Properties Java Build Path Libraries Maven Dependencies everything is there... Maven Update Project... does not help either. Nor removing the WAR module from Tomcat and adding once again. Nor cleaning Tomcat. This lead me to the config file .settings/org.eclipse.wst.common.component When I manually patched this file by adding the missing modules and refreshed the project the problem goes away. Searching the web I found this one: https://issues.sonatype.org/browse/MECLIPSEWTP-146 However this is fixed already in 0.14.0 and I am running m2e 1.1.0.20120130-216 with m2e wtp in 0.14.0.20110928-2045 Anyhow the entries with the JAR including Version still can be found in my org.eclipse.wst.common.component Mybe the fix did not make it into 0.14.0 ? Any ideas but going back to mvn eclipse:eclipse ? I always avoided m2e before and now just started loving it until I ran into these problems... Regards Jörg - 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 - offer anything for runtime?
On Fri, Apr 27, 2012 at 8:40 AM, J.V. jvsr...@gmail.com wrote: I understand how Maven resolves dependencies (and transitive dependencies) at compile time, but does it bring anything to the table at run time? For example, if I have in my application dependency list two versions of log4J (let's say version 8 and version 15), will I deploy both jars/version along with my app on say a tomcat server inside the war? At runtime which one does it choose? If I am executing the code that depends on version 8, how would the correct jar be in the classpath at that point and later log4J version 15 be in my classpath when code that has that dependency executes? Surprised that nobody else mentioned this, but assuming your GA (Group, Artifact) coordinates stay the same, Maven would pick only *one* version of the same artifact to be included in your classpath, as a dependent lib for your WAR or whatever else it is you are building. Google on on Maven nearest version resolution to find out more. There's no need for exclusions (in that case). Kalle At runtime, Maven is out of the picture correct? This is a missing piece for me. thanks J.V. - 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: WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)
Gaah! I just managed to waste an hour hunting down an issue with a suddenly failing release after a parent of a parent was changed to use version 2.2.2 of the release plugin. The worst is that I now recall I saw this thread a week ago. Kalle On Tue, Jan 3, 2012 at 1:20 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: that is because you are using maven-release-plugin 2.2.1 switch to 2.2.2 and see how you feel - 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 3 Jan 2012 20:58, Jesse Farinacci jie...@gmail.com wrote: Greetings, On Tue, Jan 3, 2012 at 3:45 PM, Mark Derricutt m...@talios.com wrote: Surely something as egregious as allowing releases to break should block 3.0.4 from being released tho. As someone who uses GPG in that manner for some of his releases I'd certainly want 3.0.4 to be able to release... It didn't stop the 3.0.3 release, what's the difference with 3.0.4? It's getting rather frustrating at seeing all these relatively solitary or edge-case problems derail the entire release process. I have performed many releases with 3.0.3 and 3.0.4-rcX both, so this is not a problem for me, and I dare say it's a very large majority of users that it is also not a problem for. Stop stopping the presses, please!! It's just a stupid point release! It doesn't have to solve every existing MNG-* out there! This kind of localized Chicken Little behavior is making it harder and harder to get small releases out the door. You're making it worse for all users. *sigh* (the same goes for all the bike shedding whiners about the dependency fetch timeout - you know who you are) -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: UTF-8 Test Mystery
How are you reading in your properties files? By default, latin-1 is assumed. Configure your surefire JVM to read files as UTF-8 with: argLine-Xms256m -Xmx512m -XX:MaxPermSize=128m -ea -Dfile.encoding=UTF-8/argLine Kalle On Mon, Oct 10, 2011 at 3:04 PM, Eric Kolotyluk eric.koloty...@gmail.com wrote: I am having trouble understanding a mystery. I have code that checks my .properties file to make sure that it has not been corrupted after being edited by a non UTF-8 editor. In particular I have a property called lambda = λ and I check to see that it actually does resolve to the correct character. If I run my code from main (my manual unit test) it works. If I run my test from JUnit in Eclipse, it works. But when the same test runs under Maven it fails because lambda = ? When I look in the actual properties file that the test runs with, lambda = λ, but somehow when the code runs it gets lambda = ?. I thought this was maybe a surefire configuration problems so I am using pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.9/version configuration junitArtifactNamejunit:junit/junitArtifactName encodingUTF-8/encoding inputEncodingUTF-8/inputEncoding outputEncodingUTF-8/outputEncoding argLine-Xms256m -Xmx512m -XX:MaxPermSize=128m -ea/argLine /configuration /plugin /plugins /pluginManagement but this makes no difference. Does anyone have any idea why my JUnit test fails running under surefire, but not running under Eclipse? Cheers, Eric - 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: UTF-8 Test Mystery
A whole case? I *love* inflation. Kalle 2011/10/10 Eric Kolotyluk eric.koloty...@gmail.com: Awesome Kalle - thanks. Where should I send the case of beer? Cheers, Eric On 2011-10-10 4:00 PM, Kalle Korhonen wrote: How are you reading in your properties files? By default, latin-1 is assumed. Configure your surefire JVM to read files as UTF-8 with: argLine-Xms256m -Xmx512m -XX:MaxPermSize=128m -ea -Dfile.encoding=UTF-8/argLine Kalle On Mon, Oct 10, 2011 at 3:04 PM, Eric Kolotyluk eric.koloty...@gmail.com wrote: I am having trouble understanding a mystery. I have code that checks my .properties file to make sure that it has not been corrupted after being edited by a non UTF-8 editor. In particular I have a property called lambda = λ and I check to see that it actually does resolve to the correct character. If I run my code from main (my manual unit test) it works. If I run my test from JUnit in Eclipse, it works. But when the same test runs under Maven it fails because lambda = ? When I look in the actual properties file that the test runs with, lambda = λ, but somehow when the code runs it gets lambda = ?. I thought this was maybe a surefire configuration problems so I am using pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.9/version configuration junitArtifactNamejunit:junit/junitArtifactName encodingUTF-8/encoding inputEncodingUTF-8/inputEncoding outputEncodingUTF-8/outputEncoding argLine-Xms256m -Xmx512m -XX:MaxPermSize=128m -ea/argLine /configuration /plugin /plugins /pluginManagement but this makes no difference. Does anyone have any idea why my JUnit test fails running under surefire, but not running under Eclipse? Cheers, Eric - 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: UTF-8 Test Mystery
Different forkMode perhaps? http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#forkMode, e.g: forkModeonce/forkMode Just send the whole keg while you are at it :) Kalle 2011/10/10 Eric Kolotyluk eric.koloty...@gmail.com: Actually - that helped - but it's not a stable solution. For some reason the tests pass when run from m2e, but fail when run from the command line. I'm still trying to figure out what the difference is. Cheers, Eric On 2011-10-10 4:41 PM, Kalle Korhonen wrote: A whole case? I *love* inflation. Kalle 2011/10/10 Eric Kolotylukeric.koloty...@gmail.com: Awesome Kalle - thanks. Where should I send the case of beer? Cheers, Eric On 2011-10-10 4:00 PM, Kalle Korhonen wrote: How are you reading in your properties files? By default, latin-1 is assumed. Configure your surefire JVM to read files as UTF-8 with: argLine-Xms256m -Xmx512m -XX:MaxPermSize=128m -ea -Dfile.encoding=UTF-8/argLine Kalle On Mon, Oct 10, 2011 at 3:04 PM, Eric Kolotyluk eric.koloty...@gmail.com wrote: I am having trouble understanding a mystery. I have code that checks my .properties file to make sure that it has not been corrupted after being edited by a non UTF-8 editor. In particular I have a property called lambda = λ and I check to see that it actually does resolve to the correct character. If I run my code from main (my manual unit test) it works. If I run my test from JUnit in Eclipse, it works. But when the same test runs under Maven it fails because lambda = ? When I look in the actual properties file that the test runs with, lambda = λ, but somehow when the code runs it gets lambda = ?. I thought this was maybe a surefire configuration problems so I am using pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.9/version configuration junitArtifactNamejunit:junit/junitArtifactName encodingUTF-8/encoding inputEncodingUTF-8/inputEncoding outputEncodingUTF-8/outputEncoding argLine-Xms256m -Xmx512m -XX:MaxPermSize=128m -ea/argLine /configuration /plugin /plugins /pluginManagement but this makes no difference. Does anyone have any idea why my JUnit test fails running under surefire, but not running under Eclipse? Cheers, Eric - 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 - 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 dependencies
Since you are including the dependencies in project A, you should declare them with scope provided. Kalle On Tue, Jul 26, 2011 at 11:23 AM, marcelo d2olive...@gmail.com wrote: Hi, I have project A which dependens on 15 jars , when I build project A, I include all dependenices in the jar.. (shade) I have project B which dependes on project A when I build project B, it downloads all dependencies of project A I would like to build project B and have maven just download project A artifact and not all dependencies of project A. thanks, -- View this message in context: http://maven.40175.n5.nabble.com/Maven-dependencies-tp4635814p4635814.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: parent scm
Yes, I have been wishing for the same as well. Kalle On Tue, May 31, 2011 at 10:16 AM, Benson Margulies bimargul...@gmail.com wrote: I have recently been trimming 'unnecessary' scm/ elements out of poms. That is, if the current project is just sitting under it's parent. I'm now wishing that one of the m-p-i-r reports would report the scm locations of the parents. In the case at hand, project 'a' has a parent 'b' that has no explicit scm, because it inherits it from its parent (c), and I wish that the svn location of both b and c was reported somewhere in the site for 'a'. Would this be a reasonable enhancement of the scm report section of m-p-i-r? - 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: One Agile automated CI build
You are abusing the version system by trying to re-deploy different bits as the same version. If you don't release, then you have snapshots even if you preferred a different name for it. Why deploy anywhere else if you just want to make those bits available to other (Maven) users? You can simply use Jenkins as the Maven repository, see http://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Maven+Repository+Server Kalle On Wed, Mar 30, 2011 at 11:24 AM, Bryan Keech bryan.keech.h...@statefarm.com wrote: Can anyone give details on how they have done this? I am running into road blocks. If I leave the version as a non-snapshot, then Hudson deploys to artifactory and overwrites the same version in the repo. I have toyed with using install:install-file goal in the install phase. Thanks, Bryan -Original Message- From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of Anders Hammar Sent: Wednesday, March 30, 2011 1:18 PM To: Maven Users List Subject: Re: One Agile automated CI build No, it's a good idea. /Anders On Wed, Mar 30, 2011 at 18:01, Bryan Keech bryan.keech.h...@statefarm.comwrote: Ok, is this a bad idea? I am wanting to have one ci build. Kind of this flow: Developer checks in, ci build is done on Hudson, build is put on artifactory, build can then be deployed to a dev, test or production server. Guess I am saying I don't want to do snapshot and release builds, but just one automated build. Thanks, Bryan - 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: Local Clone Helpfullness as a possible Maven Plugin
Why do you need to re-release? I typically checkout/clone, build, edit the pom directly and change the version to existingversion-mycompany-1, then take both the pom and the (snapshot) library and deploy them to Nexus. Kalle On Wed, Feb 2, 2011 at 2:17 PM, Benson Margulies bimargul...@gmail.com wrote: Here's something that happens to me frequently. Goal: make a local release off the trunk of some FOSS thing that will be a while releasing a fix that I need. Typical set of activities: 1: git svn clone 2: branch 3: edit poms, change version, scm paths, deploymentRepository 4: run release plugin #3 is rather a fiddly, error prone process. If, on top of this, I also want to make local changes and push them back, it's fiddly to sort out the purely local pom changes. All of this suggests two possible lines of country: 1) more fun in the version plugin to deal with scm and deployment. 2) some sort of a way to 'shadow' a POM with local changes instead of editing them in. Opinions? - 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: Using Apache parent pom
http://www.apache.org/dev/publishing-maven-artifacts.html Kalle On Tue, Feb 1, 2011 at 2:44 PM, Craig L Russell craig.russ...@oracle.com wrote: Hi, I'm using maven2 to build JDO db.apache.org/jdo and would like a pointer to how to use the Apache parent pom. I've searched Google for a while and haven't found a detailed how, why, cookbook description. What I have read is that using this pom will simplify the release process and allow us to use the Nexus staging repository. Any pointers? Please include me in the reply; I'm not subscribed to this list. Thanks, Craig Craig L Russell Secretary, Apache Software Foundation Chair, OpenJPA PMC c...@apache.org http://db.apache.org/jdo - 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: How to migrate Ant obfuscation build to Maven?
http://pyx4me.com/pyx4me-maven-plugins/proguard-maven-plugin/. Obfuscate the jars that go into the war or obfuscate the classes directly before they are packaged into the war. The plugin can do both. Deploy the zip to your repository as well as the war. Kalle On Fri, Jan 28, 2011 at 4:23 PM, Karsten Silz karsten.s...@me.com wrote: Hi, Part of my job is to maintain an Ant build to obfuscate a web app. This happens in four steps: - Ant builds the WAR file on PC - WAR file gets uploaded to a server where it is obfuscated (which - due to class and method renaming - also changes configuration files and accesses the libraries) - obfuscated WAR file and obfuscation log (needed for decoding stack traces) are added to an internal build application on that server - obfuscated WAR file and obfuscation log are downloaded again to PC, obfuscation log is added to version management (just to be on the safe side) The web app was migrated to Maven more than a year ago, and we've just started using the release plugin (we run our own internal Nexus Maven repository). But now we want to change the obfuscation build. Additionally, we want to build a ZIP file as the build result that includes the WAR file, along with database scripts, release notes and such. Now I have these questions: - The Maven Assembly plug-in seems to be the right choice for changing what goes into the WAR file (which we don't want to change), but how can I build the above described ZIP file instead? - How does the obfuscation fit into the Maven lifecylce, since it creates the final artifact, so to speak, but also requires the WAR file to be built, which itself already concludes the packaging phase? Would I need to abuse a later phase (such as verify) to do the obfuscation? - Sine the AntRun plugin got deprecated with Maven 3, is our own custom plugin the best way to trigger the obfuscation process and download its results? - Since the obfuscation should be part of a Maven release (using the release plugin), the release plugin assumes that there is no locally changed file, compared against the source code repository. How could we then update the obfuscation log in the our source code management system as part of the Maven release, if at all? - I read somewhere that deploying a custom ZIP file like the one described aboveto our own Maven repository is frowned upon because the Maven repository doesn't know what to do with such a file, unlike a JAR file, for instance. If that is true, what would we then deploy to our internal Maven repository - just the WAR file? Thank you for your help! Karsten Silz -- View this message in context: http://maven.40175.n5.nabble.com/How-to-migrate-Ant-obfuscation-build-to-Maven-tp3362293p3362293.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: One project per package or multiple packages in same project?
On Tue, Jan 25, 2011 at 8:09 AM, Miguel Almeida migueldealme...@gmail.com wrote: I agree with you. I'm still quite new to advanced Maven topics so it still seems counter-intuitive to store the config file outside the .war - it adds one extra step of deploy the .xml/config file in the installation, but like Mark pointed out it makes the WAR more independent and more agile to configuration changes. If you had a finite number of configurations to support and you really wanted it all in a war, you could also organize your build as a base war module and then have the configurations in their own module and overlay them on top of the base war (google Maven war overlays). Profiles is the wrong tool for this job since there's no way you could release those properly. With an infinite number of configurations to support, the only right way is to externalize the configuration. Kalle - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: License collection
As Wayne mentioned, most of the modules contain an url to a license rather than have it checked in. Perhaps you just need the license report instead? The dependencies report of the mpir plugin has had a license section for quite some time, I use it all the time. See e.g. the dependency report of the mpir plugin itself: http://maven.apache.org/plugins/maven-project-info-reports-plugin/dependencies.html. Kalle On Fri, Jan 21, 2011 at 9:30 AM, Rui Vilão rpvi...@gmail.com wrote: Hi all, I'm trying to automate licensing collection for my product. What I want is simple: collect (i.e. download) all licenses of my dependencies and store them in a folder. Does anyone know if there's a plugin that does what I'm trying to accomplish? I've heard about license-maven-plugin ( http://mojo.codehaus.org/license-maven-plugin/ ) but I couldn't even download it. Thanks in advance, Rui - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Using release plugin with multi-module project
plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-release-plugin/artifactId configuration preparationGoalsclean install/preparationGoals /configuration /plugin Search the list for explanation. Kalle On Tue, Jan 18, 2011 at 1:54 PM, Michael Remijan mjremi...@yahoo.com wrote: I'm trying to use the release plugin for the first time on a multi-module project. Given that my project looks like this: /Parent /Project-A /Project-B (had a dependency on Project-A) the problem I'm having is when the release plugin goes to build Project-B it fails with an error saying it can't find Project-A. The release plugin will successfully take the version of Project-A and remove the -SNAPSHOT so that's OK. Also, the release plugin will successfully alter the pom of Project-B and remove the -SNAPSHOT on the dependency to Project-A. However Project-B still can't find Project-A when it the release plugin tries to build it. Suggestions? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Accessing the version of a dependency
On Wed, Jan 5, 2011 at 9:33 AM, juranta juha.ra...@iki.fi wrote:
Thanks, that's a simple solution that might even work in most of the
situations (perhaps excepting the release plugin, etc).
The release plugin is surprisingly good at dealing with versions
declared in properties, try it, might just work out of the box for
your use case.
Kalle
I also found a more complex way to access the versions of a dependency
using Groovy plugin. For those who are interested:
plugins
plugin
groupIdorg.codehaus.groovy.maven/groupId
artifactIdgmaven-plugin/artifactId
version1.0-rc-5/version
executions
execution
phasevalidate/phase
goals
goalexecute/goal
/goals
configuration
source
print
project.dependencies;
for ( i in
project.dependencies ) {
project.properties[ 'depinfo.' + i['groupId'] + '.' +
i['artifactId'] + '.version' ] = i['version'];
}
/source
/configuration
/execution
/executions
/plugin
Then you can access ${depinfo.mygroup.myartifact.version}... But I'll try to
go with your suggestion.
Juha
Right, and the rest of your build needs to know that version as well,
right? Put that version in a property and use it in the dependency as
well as resource filtering, i.e.
properties
cssversion2/cssversion
/properties
Kalle
--
View this message in context:
http://maven.40175.n5.nabble.com/Accessing-the-version-of-a-dependency-tp3327490p3329171.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
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Accessing the version of a dependency
Assembly plugin can do resource filtering, see
http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/filtering-some-distribution-files.html.
Kalle
On Tue, Jan 4, 2011 at 10:10 AM, juranta juha.ra...@iki.fi wrote:
Hi,
I'm quite new to Maven, so I'm happy with all suggestions.
So, I have an assembly project which creates an assembly of dependencies. It
works fine, but I still miss one piece. I need to get the version of one
particular dependency and use it while filtering some files.
I mean, let's say that in the dependencies there's a module A with version
2. I want to filter some files so that parts of them get replaced with 2.
For instance, if the original file has the string My version is
${version}, it should become My version is 2.
How would I do this in Maven?
I thought of AntRun plugin. Can I access the version of some dependency from
Ant? Is there some other solution? Do I need to write a plugin?
Thanks,
Juha
--
View this message in context:
http://maven.40175.n5.nabble.com/Accessing-the-version-of-a-dependency-tp3327490p3327490.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
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Accessing the version of a dependency
Right, and the rest of your build needs to know that version as well, right? Put that version in a property and use it in the dependency as well as resource filtering, i.e. properties cssversion2/cssversion /properties Kalle On Tue, Jan 4, 2011 at 11:30 AM, juranta juha.ra...@iki.fi wrote: Yes, but my problem is that I need to use the version of one particular dependency while doing the filtering. Thanks, Juha Assembly plugin can do resource filtering, see http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/filtering-some-distribution- files.html. Kalle -- View this message in context: http://maven.40175.n5.nabble.com/Accessing-the-version-of-a-dependency-tp3327490p3327642.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Fail a build if the web application fails to load in Jetty....
TestNG skips rather than fails remaining tests once the first one fails. Tynamo's tests use testng, poke around in the svn and you'll see they are otherwise very similar to JUnit(4). Kalle On Tue, Jan 4, 2011 at 11:10 AM, Nathan Wilhelmi wilhe...@ucar.edu wrote: Hi - HtmlUnit is a simpler solution for what we are trying to test right now. What I am really after is failing fast on the integration tests. If the app didn't start I would rather not run through each test and all setup associated with each one. -Nate Kalle Korhonen wrote: Why not http://docs.codehaus.org/display/TYNAMO/2010/07/30/Full+web+integration+testing+in+a+single+JVM and something like http://svn.codehaus.org/tynamo/trunk/tapestry-model/tapestry-model-test/src/main/java/org/tynamo/test/AbstractContainerTest.java ? With an embedded Jetty, your integration tests would behave just like your unit tests. Kalle On Wed, Dec 29, 2010 at 1:03 PM, Nathan Wilhelmi wilhe...@ucar.edu wrote: Hi - We are working on integrating Jetty deployment into our integration tests. We don't have any selenium type tests yet. Is there any to fail the build if the web application fails to start in Jetty? We would like to use this as first step. Thanks! - 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: Assembly Plugin not seeing local repository
Hmm.. I just mavenized RestFB (http://code.google.com/p/restfb/source/browse/#svn%2Ftrunk%2FRestFB), including an assembly-based distro and I can verify that useAllReactorProjects works as expected and documented. The documentation could be more clear though - I'm not sure it's obvious what the intended use of useAllReactorProjects is (enable creating assemblies in a child module) for new users. Also, as the documentation says, if you are using moduleSets (rather than dependencySets) make sure that your reactor (multi-module) build is actually building those modules, otherwise you run into troubles. Overall, it seems you had pretty much the right approach but unfortunately your stack trace doesn't reveal enough to see if the modules your are trying to include were built as part of that reactor build. Kalle On Thu, Dec 30, 2010 at 9:12 AM, Steve Cohen sco...@javactivity.org wrote: I am giving up trying to understand the mess below. I have tried everything I can. This new approach to moduleset inclusion with useAllReactorProjects isn't working for me and the debugging information isn't helping. I started with very simple requirements: Package a jar, some locally generated dependent jars, and some third party jars into the lib directory of a zip file, and package some other files into a config directory of the same zip file. The syntax that is required by this approach is mind-bogglingly difficult for such simple requirements. I had an almost working version using the old plugin with its old approach. The only problem was that my JUnit tests were running twice. I think perhaps that my experiments here may have shown me a way around this. If not, I can live with it. The new approach must be rated a failure, or else some better documentation needs to be created. What I see clearly does not apply to my situation. Happy New Year, folks. Steve Cohen On 12/29/2010 01:38 PM, Steve Cohen wrote: Here ya go: [DEBUG] (f) mavenSession = org.apache.maven.execution.mavensess...@6691da [DEBUG] (s) outputDirectory = /home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/target [DEBUG] (f) project = MavenProject: com.whatever:bpm-dist:0.0.3-SNAPSHOT @ /home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/pom.xml [DEBUG] (s) reactorProjects = [MavenProject: com.whatever:Module001:0.0.3-SNAPSHOT @ /home/abcdefg/build/20101228-REFACTOR-DEPS/Module001/pom.xml, MavenProject: com.whatever:Module002:0.0.3-SNAPSHOT @ /home/abcdefg/build/20101228-REFACTOR-DEPS/Module002/pom.xml, MavenProject: com.whatever:HibernateWrapper:0.0.3-SNAPSHOT @ /home/abcdefg/build/20101228-REFACTOR-DEPS/HibernateWrapper/pom.xml, MavenProject: com.whatever:Module003:0.0.3-SNAPSHOT @ /home/abcdefg/build/20101228-REFACTOR-DEPS/Module003/pom.xml, MavenProject: com.whatever:WXYZClient:0.0.3-SNAPSHOT @ /home/abcdefg/build/20101228-REFACTOR-DEPS/WXYZClient/pom.xml, MavenProject: com.whatever:BatchProcessManager:0.0.3-SNAPSHOT @ /home/abcdefg/build/20101228-REFACTOR-DEPS/BatchProcessManager/pom.xml, MavenProject: com.whatever:BPM:0.0.3-SNAPSHOT @ /home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/pom.xml, MavenProject: com.whatever:bpm-dist:0.0.3-SNAPSHOT @ /home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/pom.xml] [DEBUG] (f) remoteRepositories = [ id: central url: http://repo1.maven.org/maven2 layout: default snapshots: [enabled = false, update = daily] releases: [enabled = true, update = daily] ] [DEBUG] (f) runOnlyAtExecutionRoot = false [DEBUG] (s) siteDirectory = /home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/target/site [DEBUG] (f) skipAssembly = false [DEBUG] (s) tarLongFileMode = warn [DEBUG] (s) tempRoot = /home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/target/archive-tmp [DEBUG] (f) updateOnly = false [DEBUG] (f) useJvmChmod = false [DEBUG] (s) workDirectory = /home/abcdefg/build/20101228-REFACTOR-DEPS/BPM/bpm-dist/target/assembly/work [DEBUG] -- end configuration -- [INFO] Reading assembly descriptor: ../src/main/assembly/zip.xml [DEBUG] Before assembly is interpolated: ?xml version=1.0 encoding=UTF-8? assembly idBPM/id formats formatzip/format /formats baseDirectorybpm/baseDirectory moduleSets moduleSet useAllReactorProjectstrue/useAllReactorProjects includes includecom.whatever:Module001/include includecom.whatever:Module002/include includecom.whatever:HibernateWrapper/include includecom.whatever:Module003/include includecom.whatever:WXYZClient/include includecom.whatever:BatchProcessManager/include /includes binaries outputDirectorylib/outputDirectory dependencySets dependencySet outputDirectorylib/outputDirectory /dependencySet /dependencySets unpackfalse/unpack /binaries /moduleSet /moduleSets fileSets fileSet outputDirectoryconfig/outputDirectory includes include**/include /includes directory../../BatchProcessManager/unpackaged/config/directory /fileSet /fileSets /assembly [DEBUG] After assembly is
Re: Config resources
src/main/config ? Kalle 2010/12/29 Pazmiño Mazón, Iván Andrés iapm270...@sri.ad: Hello, I'm building a web project and I have some configuration and descriptor files located inside src/main/resources/config which are used during the source preparation phase. Since this location will be loaded to the classpath I think it should be put in a better place. What's the standard for this better place? Or should I exclude the somehow from the resulting target/classes directory? Thanks, IP Clausula de Confidencialidad: La información contenida en el presente mensaje es confidencial, está dirigida exclusivamente a su destinatario y no puede ser vinculante. El Servicio de Rentas Internas no se responsabiliza por su uso y deja expresa constancia que en los registros de la Institución consta la información originalmente enviada. Este mensaje está protegido por la Ley de Propiedad Intelectual, Ley de Comercio Electrónico, Firmas y Mensajes de datos, reglamentos y acuerdos internacionales relacionados. Si usted no es el destinatario de este mensaje, recomendamos su eliminación inmediata. La distribución o copia del mismo, está prohibida y será sancionada de acuerdo al Código Penal y demás normas aplicables. La transmisión de información por correo electrónico, no garantiza que la misma sea segura o esté libre de error, por consiguiente, se recomienda su verificación.Toda solicitud de información requerida de manera oficial al SRI debe ser ingresada por Secretaría General y dirigida a la máxima autoridad de la Institución, conforme a la Ley y demás normas vigentes. - 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: Fail a build if the web application fails to load in Jetty....
Why not http://docs.codehaus.org/display/TYNAMO/2010/07/30/Full+web+integration+testing+in+a+single+JVM and something like http://svn.codehaus.org/tynamo/trunk/tapestry-model/tapestry-model-test/src/main/java/org/tynamo/test/AbstractContainerTest.java ? With an embedded Jetty, your integration tests would behave just like your unit tests. Kalle On Wed, Dec 29, 2010 at 1:03 PM, Nathan Wilhelmi wilhe...@ucar.edu wrote: Hi - We are working on integrating Jetty deployment into our integration tests. We don't have any selenium type tests yet. Is there any to fail the build if the web application fails to start in Jetty? We would like to use this as first step. Thanks! - 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: Reasonable use of profiles?
On Fri, Dec 10, 2010 at 9:20 AM, KARR, DAVID (ATTSI) dk0...@att.com wrote: Another desire I have is to allow for developers not even building most of the modules, and just letting the ear project pull snapshot artifacts from the Nexus repo (built by the release team or continuous integration). I could do this with multiple build projects, including different sets of module elements. That seems messy, however. I wish I had different options for setting that up, perhaps in a profile, but I don't see how that could work. Overall, I'd say this sounds better than trying to (mis-)use profiles. Nothing you said indicates to me that the EARs are functionally equivalent, and therefore I'd create different modules for different EARs. One of the Maven ground rules is one artifact per module. Typically you deviate from that plan only if you need to build different versions of the same module (packaged differently, for different OSes/JVMs etc.) and often you use profiles for the desired effect. I'd further say using profiles should never be your first option. Reserve profiles for the time you really need them. Since you are going to re-work the build, I'd mercilessly refactor it into a modular build now. Since Maven is so good at versioning things, your build doesn't have to be monolithic. Snapshots are ok, but it's far better if you can identify common, stable areas of the codebase and simply release them separately. Then your top-level builds are mostly assembling things together rather than compiling/building them. Personally, I'd put my efforts on making the build modular, automating version migration and doing more continuous integration testing rather than trying to force Maven the same logic as your Ant build. Depending on the size of the project and your team, it would likely be beneficial to pay somebody who really knows Maven to assist you in the migration at this point (if you can get it approved, I know how it is). It would save you from a lot of grief later. Kalle - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Reasonable use of profiles?
Beyond the basics and the core principles, it's difficult to write down the exact instructions for a large scale deployment and use of Maven because the situations are vastly different. Even if one would document the best practices for some particular situations, the issue for the novice is identifying the right case for your situation. Between the company's SCM of choice, preferred branching patterns (release / feature branches), development velocity, maturity of the codebase, the type of software (libraries, service, pre-packaged apps) and programming languages used (plain Java, native libs w/ OS-specific languages, scripting), development methodology etc. there are too many variations to be able to confidently arrive at an optimal solution just by reading about it. For somebody with experience though, it's typically simple to re-organize even larger builds to follow best practices in a matter of few days. However, you often end up spending much much longer in real time, because first, you want to go at it alone and second, you always discount the level of resistance to change. Kalle On Fri, Dec 10, 2010 at 2:19 PM, Peter Schuller peter.schul...@infidyne.com wrote: I very much second Kalle here. Stay away from profiles as much as possible - most often they are used in the wrong way. Also, if you're migrating a large system I would very much recommend that you get someone with good Maven knowledge to help you get things right. I very often come to projects where some senior developer has created a Maven build setup which is just completely wrong. Having to refactor that costs possibly two-three times more than doing it right from the beginning. It often also upsets the developers as they often have to change the way they work. So on that topic, is there good material that covers doing it right? I've read the sonatype maven book and while it's good as far as it goes, it doesn't really cover the intended workflows in various situations and the intent of various abstractions. Googling is kind of problematic because there is a lot of cargo cult information floating around. Is there a book of other material that truly goes through the intended way to deploy Maven in an organization, including not just stuff like here's how you install nexus, but things like release management, the relationship between maven release management and VCS tagging, what to do about multiple branches of development, etc, etc. Suppose you want to build an eco-system of tens or hundreds of projects in an organization and deploy/build them scalably (in terms of administration/build costs) using maven in a clean and maintainable fashion without hacks or non-idiomatic mistakes. What material does one preferably read? -- / Peter Schuller - 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: RE: How to have release management incremental (or release) builds publish to Nexus, but not user builds?
On Wed, Dec 8, 2010 at 9:16 AM, KARR, DAVID (ATTSI) dk0...@att.com wrote: -Original Message- From: Nick Stolwijk [mailto:nick.stolw...@gmail.com] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.5:deploy (default-deploy) on project myproject: Deployment failed: repository element was not specified in the POM inside distributionManagement element or in -DaltDeploymentRepository=id::layout::url parameter - [Help 1] With a command line of this: mvn -P releaseIncremental deploy You don't specify but your latter post suggests that you are trying to configure all of it in your settings. Put at least the the distributionManagement section into your pom as the error message says and it will work. Not that this is an issue yet, but what is the significance of the id element in the server element? Does that value have to correspond to anything? The pom is shared and the settings are yours. The id serves as a bridge between them. So you specify a destination in your pom and the id helps Maven to find the correct credentials for that specific destination. For others about the rest, it's not a choice between using a profile or credentials. Of course you should be forced to properly authenticate for deploying, but if you need multiple distribution locations, profiles are a simple way and natural way to achieve it. Kalle - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: RE: How to have release management incremental (or release) builds publish to Nexus, but not user builds?
On Wed, Dec 8, 2010 at 3:26 PM, KARR, DAVID (ATTSI) dk0...@att.com wrote: -Original Message- What is a destination? What exact field in the pom does the server/id correspond to? Module's deployment destination is specified by the distribution URL. Server id corresponds to the server id in both places, for example see http://www.sonatype.com/books/nexus-book/reference/staging-sect-deployment.html Kalle - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to have release management incremental (or release) builds publish to Nexus, but not user builds?
Of course, developers never need to run deploy goal in the first place. Anyhow, it's a commonly used practice to deploy to different locations. Create a release profile and override the distributionManagement section as needed, for example see http://svn.codehaus.org/tynamo/trunk/tynamo-parent/pom.xml. Kalle On Tue, Dec 7, 2010 at 10:00 AM, KARR, DAVID (ATTSI) dk0...@att.com wrote: I'm working on strategies to convert a large and complex Ant build system to use Maven. I'm assuming that developers who are working on individual modules will do a build that pulls the artifacts of other modules (that they're not working on) from the Nexus repository we have running on an intranet server. These will be both release artifacts and snapshot artifacts. I also assume that incremental builds performed by the release management team will publish snapshot artifacts to the Nexus repository, but builds performed by developers will not publish to the Nexus repository. Is this reasonable? If so, what mechanisms do I have to have in place to make release management builds publish artifacts to Nexus, but not developer builds? - 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: How to have release management incremental (or release) builds publish to Nexus, but not user builds?
The commonness of the practice is hardly the point of this thread so it baffles me why you'd want to start arguing about it, but there is a specific distributionManagement section in the release profiles of Apaches', Codehaus' parent poms and in the parent pom I linked to so I offered a tried and widely used solution to the questioner. There's nothing difficult for users in it. Kalle On Tue, Dec 7, 2010 at 9:49 PM, Anders Hammar and...@hammar.net wrote: Commonly used practice? Really? I don't think so. Are the users supposed to enable different snapshot repos depending on what type of snapshot artifacts the want to use? Seems very complicated and error prone to me and simply just to difficult for the users to get right. /Anders On Tue, Dec 7, 2010 at 19:10, Kalle Korhonen kalle.o.korho...@gmail.comwrote: Of course, developers never need to run deploy goal in the first place. Anyhow, it's a commonly used practice to deploy to different locations. Create a release profile and override the distributionManagement section as needed, for example see http://svn.codehaus.org/tynamo/trunk/tynamo-parent/pom.xml. Kalle On Tue, Dec 7, 2010 at 10:00 AM, KARR, DAVID (ATTSI) dk0...@att.com wrote: I'm working on strategies to convert a large and complex Ant build system to use Maven. I'm assuming that developers who are working on individual modules will do a build that pulls the artifacts of other modules (that they're not working on) from the Nexus repository we have running on an intranet server. These will be both release artifacts and snapshot artifacts. I also assume that incremental builds performed by the release management team will publish snapshot artifacts to the Nexus repository, but builds performed by developers will not publish to the Nexus repository. Is this reasonable? If so, what mechanisms do I have to have in place to make release management builds publish artifacts to Nexus, but not developer builds? - 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: Custom Lifecycle
Why not just use a profile for this? Kalle On Fri, Nov 26, 2010 at 4:50 PM, Greg Akins angryg...@gmail.com wrote: I want to run selenium tests outside of the normal build cycle. They're working right now in the integration-test phase, but I can't allow them to run from the build server (they'll fail). It seems like I'll need to define a custom lifecycle, but I don't completely understand everything I'll need to do to accomplish that. Rather than just running the selenium goals, I'd like to keep the tomcat startup, cargo, junit execution and selenium server start in one tasks.. so I don't think it's enough to just run the selenium task. Thoughts? -- Greg Akins http://insomnia-consulting.org http://www.pghcodingdojo.org http://pittjug.dev.java.net http://twitter.com/akinsgre http://www.linkedin.com/in/akinsgre - 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: Unable to commit files to SVN after new branch has been created with the maven-release plugin
Use regular command prompt, not cygwin when making a release. (If you find a better fix, let me know.) Kalle On Mon, Nov 22, 2010 at 1:00 PM, edgarosy edgar.l...@gmail.com wrote: Question for all maven gurus. Hope you can help me.. I've been using a maven-release plugin for over a year and it has always work perfectly when creating new branch from source (trunk). Ever since our SVN amdin upgraded the SVN server to use version 1.6 instead of 1.4 I have not been able to commit files to svn successfully after the branch has been created. my build servers is a windows 2003 server. I am using Maven version: 2.2.1, and I upgraded the svn client to 1.6.1. [INFO] Executing: cmd.exe /X /C svn --username . --password * --non-interactive commit --file C:\Documents and Settings\triacp\maven-scm-528237796.commit --targets C:\Documents and Settings\triacp\maven-scm-1457486069711445316-targets [INFO] Working directory: D:\build\buildScripts\mvnScripts\branching org.apache.maven.shared.release.scm.ReleaseScmCommandException: Unable to commit files Provider message: The svn command failed. Command output: cygwin warning: MS-DOS style path detected: C:\Documents and Settings\triacp\maven-scm-528237796.commit Preferred POSIX equivalent is: /cygdrive/c/Documents and Settings/triacp/maven-scm-528237796.commit CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames svn: '/cygdrive/d/build/buildScripts/mvnScripts/branching/D:/build/buildScripts/mvnScripts/branching' is not a working copy svn: '/cygdrive/d/build/buildScripts/mvnScripts/branching/D:/build/buildScripts/mvnScripts/branching' does not exist at org.apache.maven.shared.release.phase.ScmCommitPhase.checkin(ScmCommitPhase.java:133) at org.apache.maven.shared.release.phase.ScmCommitPhase.execute(ScmCommitPhase.java:109) at org.apache.maven.shared.release.DefaultReleaseManager.branch(DefaultReleaseManager.java:379) at org.apache.maven.shared.release.DefaultReleaseManager.branch(DefaultReleaseManager.java:350) at org.apache.maven.plugins.release.BranchReleaseMojo.execute(BranchReleaseMojo.java:133) 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.executeStandaloneGoal(DefaultLifecycleExecutor.java:569) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:284) 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(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Unable to commit files Provider message: The svn command failed. Command output: cygwin warning: MS-DOS style path detected: C:\Documents and Settings\triacp\maven-scm-528237796.commit Preferred POSIX equivalent is: /cygdrive/c/Documents and Settings/triacp/maven-scm-528237796.commit CYGWIN environment variable option nodosfilewarning turns off this warning. Consult the user's guide for more details about POSIX paths: http://cygwin.com/cygwin-ug-net/using.html#using-pathnames svn: '/cygdrive/d/build/buildScripts/mvnScripts/branching/D:/build/buildScripts/mvnScripts/branching' is not a working copy svn: '/cygdrive/d/build/buildScripts/mvnScripts/branching/D:/build/buildScripts/mvnScripts/branching' does not exist [INFO]
Re: Maven Release Plugin
The previous replies seem to miss the mark, your set up sounds good to me. The missing configuration you are looking for is: configuration autoVersionSubmodulestrue/autoVersionSubmodules /configuration Kalle On Thu, Sep 16, 2010 at 8:07 AM, Marcus Linke li...@newsaktuell.de wrote: Hello, i 've the following problem releasing a multi-module project with the maven-release-plugin (Version 2.0). The top (parent) pom-style project defines a set of snapshot dependencies that are inherited to all of its submodules. When using the release plugin in interactive mode, the plugin prompts for the new versions of these snapshot dependencies. So far, so good. But when diving into the submodules this is repeated for each module again. This is really annoying me because i have 20 submodules in that project. Is this is a know problem or a type of misconfiguration. Thanks Marcus Linke - 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-gpg-plugin blocked during the execution
You need to specify: mavenExecutorIdforked-path/mavenExecutorId in release plugin configuration. See http://jira.codehaus.org/browse/MGPG-9 Kalle On Fri, Sep 10, 2010 at 9:30 AM, Simone Tripodi simone.trip...@gmail.com wrote: Hi all guys, using the maven-release-plugin and signing artifacts with GnuPG, during the verifying phase, when the gpg-plugin is invoked, the build process is completely stalled. If I don't pass the gpg.passphare I'd expect it would be asked in the prompt, but it doesn't happen :( Follow below my attempts: mvn release:prepare -DdryRun=true -Darguments=-Dgpg.keyname=\ -Dgpg.passphrase= mvn release:prepare -DdryRun=true -Dgpg.passphrase= -PXXX (the keyname is defined as property in the XXX profile) mvn release:prepare -DdryRun=true (tried to insert gpg.passphrase in the prompt) Do you have any idea why? Many thanks in advance, Simo http://people.apache.org/~simonetripodi/ http://www.99soft.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: Deploy goal with maven3?
On Thu, Sep 9, 2010 at 1:35 AM, motes motes mort.mo...@gmail.com wrote: I have build the below MANIFEST first project using maven3 with tycho: Any suggestion on how to deploy a project (like the one at the above link) which consists of: parent -bundle -feature -target definition -update site Do all of it as part of site-deploy? Kalle - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [maven-release-plugin] Is it possible to configure maven-release-plugin to NOT pull in META-INF/LICENSE and NOTICE
Sounds like you are using the Apache super pom as the parent. If you simply name yours LICENSE and NOTICE, they'll overwrite the default ones. Kalle On Fri, Aug 27, 2010 at 7:03 AM, Justin Edelson justinedel...@gmail.com wrote: Nothing in the release plugin will do this automatically; it must be configured somewhere, either in your POM or (more likely from the sound of it) in a parent POM. Justin On 8/27/10 5:27 AM, han hongfang wrote: Hi, Our project uses maven-release-plugin in the release process. We maintain the LICENSE.txt and NOTICE.txt (which contains module specifc statement) for each of our modules in subversion. When we issue mvn release:prepare, standard LICENSE and NOTICE files are pulled into META-INF folder of target artifact. These standard files are duplicated with LICENSE.txt and NOTICE.txt we maintained. Is it possible to configure maven-release-plugin to not pull in these files? If yes, could you show me how to do it? Thanks in advance for your reply! - 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: How to deploy secondary artifacts using deploy plugin
You need to tell Maven about the additional artifacts. Attach them to your module with buildhelper plugin, specifying a different type/classifier. See http://mojo.codehaus.org/build-helper-maven-plugin/usage.html Kalle On Thu, Aug 26, 2010 at 1:02 PM, Victor Calvello vcalve...@gmail.com wrote: Hi guys, I'm trying to deploy to a release nexus repository 2 artifacts with the same GAV but different classifier and packaging using the maven-deploy-plugin. The first one goes well. The problem is that fails when wants to upload or generate the pom for the second artifact because the first artifact uploaded already created it. Is there a way to add secondary artifacts using this plugin? Thanks, Vic - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven release:perform without deploy and calling an external shell script
No, you bind exec:exec to deploy phase, or profile or however you want to set it up and skip the normal deploy. Kalle On Mon, Aug 9, 2010 at 6:22 PM, Sergio Oliveira sergio.souj...@gmail.com wrote: I added: goalsinstall exec:exec/goals But release:perform does not like exec:exec. :-( [INFO] [INFO] [INFO] [INFO] One or more required plugin parameters are invalid/missing for 'exec:exec' [INFO] [INFO] [0] Inside the definition for plugin 'exec-maven-plugin' specify the following: [INFO] [INFO] configuration [INFO] ... [INFO] executableVALUE/executable [INFO] /configuration [INFO] [INFO] -OR- [INFO] [INFO] on the command line, specify: '-Dexec.executable=VALUE' [INFO] On Mon, Aug 9, 2010 at 5:51 PM, Wendy Smoak wsm...@gmail.com wrote: On Mon, Aug 9, 2010 at 8:34 PM, Sergio Oliveira sergio.souj...@gmail.com wrote: I am using the maven release plugin. Problem is simple: I don't want to do a deploy (copy the war somewhere) on release:perform. I actually want to execute a shell script that will do the deploy for me. So I have two things to accomplish: 1 - Somehow disable the default deploy goal from release:perform (i want to build the war, but I don't want to copy it anywhere) 2 - Somehow make release:perform call the exec:exec plugin to execute a shell script that copy my war to my server farm Have you looked at the docs for the release plugin? You can reconfigure the goals it executes for both prepare and perform. See http://maven.apache.org/plugins/maven-release-plugin/perform-mojo.html - goals. You might want install exec:exec there. You could also use the skip parameter of the deploy plugin to stop it from deploying to the Maven repo. -- Wendy - 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 release:perform without deploy and calling an external shell script
Put the exec plugin configuration in a profile, phasedeploy/phase is the configuration you are looking for. See http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html Kalle On Mon, Aug 9, 2010 at 7:20 PM, Sergio Oliveira sergio.souj...@gmail.com wrote: I am trying the approach below, but can you tell me how I execute exec:exec inside a profile? Thanks! It is probably a silly question, so if you want to give me the answer and also advise on where I should have looked for it I would appreciate your help. profile !-- Profile used when the release plugin executes. -- idexecmyson/id activation property !-- This property is automatically defined by the Maven release plugin when executing a release. Thus this profile will be automatically enabled when releasing -- nameperformRelease/name valuetrue/value /property /activation build defaultGoalexec:exec/defaultGoal /build /profile On Mon, Aug 9, 2010 at 6:56 PM, Kalle Korhonen kalle.o.korho...@gmail.comwrote: No, you bind exec:exec to deploy phase, or profile or however you want to set it up and skip the normal deploy. Kalle On Mon, Aug 9, 2010 at 6:22 PM, Sergio Oliveira sergio.souj...@gmail.com wrote: I added: goalsinstall exec:exec/goals But release:perform does not like exec:exec. :-( [INFO] [INFO] [INFO] [INFO] One or more required plugin parameters are invalid/missing for 'exec:exec' [INFO] [INFO] [0] Inside the definition for plugin 'exec-maven-plugin' specify the following: [INFO] [INFO] configuration [INFO] ... [INFO] executableVALUE/executable [INFO] /configuration [INFO] [INFO] -OR- [INFO] [INFO] on the command line, specify: '-Dexec.executable=VALUE' [INFO] On Mon, Aug 9, 2010 at 5:51 PM, Wendy Smoak wsm...@gmail.com wrote: On Mon, Aug 9, 2010 at 8:34 PM, Sergio Oliveira sergio.souj...@gmail.com wrote: I am using the maven release plugin. Problem is simple: I don't want to do a deploy (copy the war somewhere) on release:perform. I actually want to execute a shell script that will do the deploy for me. So I have two things to accomplish: 1 - Somehow disable the default deploy goal from release:perform (i want to build the war, but I don't want to copy it anywhere) 2 - Somehow make release:perform call the exec:exec plugin to execute a shell script that copy my war to my server farm Have you looked at the docs for the release plugin? You can reconfigure the goals it executes for both prepare and perform. See http://maven.apache.org/plugins/maven-release-plugin/perform-mojo.html - goals. You might want install exec:exec there. You could also use the skip parameter of the deploy plugin to stop it from deploying to the Maven repo. -- Wendy - 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: force maven to redownload/refresh released dependencies
On Fri, Aug 6, 2010 at 10:43 AM, Haszlakiewicz, Eric ehas...@transunion.com wrote: -Original Message- I don't (yet) know much about the internals of maven, but is it really that much of an impact on the code? There's already support present for checking for differences in snapshot versions, right? I'm imagining that making it work for release artifacts would be a matter of not distinguishing between release and snapshot artifacts and having the check apply to both. It sounds like you think it'll be harder to do than that; what I am missing? What you are asking is absurd. That's the exact difference between snapshots and releases; snapshots should be updated and releases shouldn't. Why would you insist on removing this differentiation? Wouldn't it be easier for you to just use snapshots if you need to check for updates? Kalle - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: force maven to redownload/refresh released dependencies
So you just want to verify? $ mvn --help usage: mvn [options] [goal(s)] [phase(s)] Options: -am,--also-makeIf project list is specified, also build projects required by the list -amd,--also-make-dependentsIf project list is specified, also build projects that depend on projects on the list -B,--batch-modeRun in non-interactive (batch) mode -C,--strict-checksums Fail the build if checksums don't match -c,--lax-checksums Warn if checksums don't match Kalle On Fri, Aug 6, 2010 at 1:01 PM, Haszlakiewicz, Eric ehas...@transunion.com wrote: -Original Message- From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On On Fri, Aug 6, 2010 at 1:00 PM, Haszlakiewicz, Eric ehas...@transunion.comwrote: Please read the rest of the email thread. The short summary is: Yes, I know what *should* happen, but the world isn't perfect and release artifacts DO sometimes change. It is not absurd to be able to detect and recover from that kind of situation. The solution is to wipe out your local artifact. No one should be updating released artifacts. If they do, they abused what a release means -- hence the problem to begin with. The solution given is the only (correct) one in Maven. I'm AGREEING with you that the solution is to wipe out the local artifact! But you can only do that once you know there is something wrong. How do you detect that the artifact has changed? Maybe you'll get lucky and something is different enough in your artifact that the build process fails. Or maybe you have some regression testing that you'll do so you notice the problem. Having maven compare the checksums seems like a much more reliable way to catch these problems. eric - 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: Custom resource filter
Unless there's a Java version of pngcrush, I wouldn't worry about running it as a plugin. You could just configure exec plugin (http://mojo.codehaus.org/exec-maven-plugin/) to run pngcrush. Kalle On Sat, Jul 24, 2010 at 7:12 AM, Laurent Martelli martellilaur...@gmail.com wrote: Hi there ! I'm working on a webapp project where PNG images are huge because they contain many layers. The layers are useless when running the webapp, but we would like to keep them in our repository because that's the native format for the guy editing them. We all know that Maven can substitute properties in text resources, but how can we filter those binary PNG images through pngcrush or a similar program in order to create a war that is as small as possible ? It looks like plugin configurations are not enough to do this, so I'm getting ready to create a custom plugin. But I don't know what would be the best way to achieve our goal. Thanks in advance for you asnwers ! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: applying finalName of dependencies when project is packaging
Always a good idea to state *why* you might want to do this so people can provide alternatives. AFAIK the answer is no to your question, but if, for example, you just want to use the artifact name and strip out the version info from the filename, you can use outputFileNameMapping (see http://maven.apache.org/plugins/maven-assembly-plugin/component.html). Kalle On Tue, Jul 20, 2010 at 1:26 PM, Shan Syed shan...@gmail.com wrote: I know there is already a lot of discussion around the topic of artifacts not using finalName when they are installed into a repository (remote or local), but is there a way to enforce that the dependencies, when packaged into the using project, are packaged with their finalNames? example: Project A (a POM that ZIPs its WAR dependencies) uses B, C, D, etc.. as dependencies (all WARs) B's finalName is Bee, C's is Cee, etc... by default, when A packages, it creates a ZIP of all its dependencies (using an assembly descriptor), with their fully qualified repository names, as expected is there an easy way to ask maven to use the finalNames for the dependencies instead? S - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: applying finalName of dependencies when project is packaging
Just a suggestion, but sounds to me the pom that drives zipping up the artifacts should also be in control of the final names rather than the individual wars. What would happen if two wars specified the same final names? If you cannot dictate a convention for the artifact names I don't see why you'd be able to do it any better for the final names. Kalle On Tue, Jul 20, 2010 at 2:05 PM, Shan Syed shan...@gmail.com wrote: Hi, We have a very large set of WAR projects (web services, web applications, static websites, etc) as part of a product offering. Various versions and combinations of these are delivered to clients, but there is no immediate understand of who gets what WARs, what versions, etc. So I am using maven to manage this: I have a POM for each delivery, which just has the dependencies listed, and an assembly descriptor that ZIPs them all conveniently, for deployment/DL to various environments. Each developer has specified a finalName for their WAR, but there is no convention, some require just the version info lopped off, some need a totally different name from their artifact, etc.. there is no reliable way to calculate the desired finalName, for various business reasons. So in my ZIPs for each set of packaged goods, I would like the WARs to have their finalNames, as opposed to their fully qualified maven names. Shan On Tue, Jul 20, 2010 at 4:54 PM, Kalle Korhonen kalle.o.korho...@gmail.comwrote: Always a good idea to state *why* you might want to do this so people can provide alternatives. AFAIK the answer is no to your question, but if, for example, you just want to use the artifact name and strip out the version info from the filename, you can use outputFileNameMapping (see http://maven.apache.org/plugins/maven-assembly-plugin/component.html ). Kalle On Tue, Jul 20, 2010 at 1:26 PM, Shan Syed shan...@gmail.com wrote: I know there is already a lot of discussion around the topic of artifacts not using finalName when they are installed into a repository (remote or local), but is there a way to enforce that the dependencies, when packaged into the using project, are packaged with their finalNames? example: Project A (a POM that ZIPs its WAR dependencies) uses B, C, D, etc.. as dependencies (all WARs) B's finalName is Bee, C's is Cee, etc... by default, when A packages, it creates a ZIP of all its dependencies (using an assembly descriptor), with their fully qualified repository names, as expected is there an easy way to ask maven to use the finalNames for the dependencies instead? S - 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-assembly-plugin: How to make the assembly the primary artifact
The pom artifact is always produced regardless. Make your module type
pom and attach the assembly zip as an artifact with the help of
buildhelper plugin:
http://mojo.codehaus.org/build-helper-maven-plugin/usage.html.
Kalle
On Thu, Jul 1, 2010 at 9:56 AM, Andreas Sewe
s...@st.informatik.tu-darmstadt.de wrote:
Hi all,
I have a project which should produce a ZIP, with all contents of
${project.build.outputDirect} put into a base directory within the ZIP. So
far, the maven-assembly-plugin with includeBaseDirectory fits the bill
perfectly.
There is one issue, however, which I haven't been able to solve: I can't get
the plugin to make the produced assembly the *primary* artifact. (There is
only a single assembly per project produced this way.)
Is this possible? Or is there another plugin which I can resort to? (The
org.apache.maven.plugins:maven-zip-plugin does almost what I want, but
seems to be not longer supported in favour of the maven-assembly-plugin.)
Any suggestions?
Best wishes,
Andreas
-
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: Custom metadata in a POM?
On Fri, Jun 4, 2010 at 1:28 PM, Les Hazlewood l...@katasoft.com wrote: Is this possible? So, in addition to stuff like developers, is it possible to add additional metadata? plugins. A Grails plugin is a .zip file, but the Grails environment http://www.grails.org/plugin/home) need to read Grails-specific metadata about that .zip without having to download the .zip first. I'm proposing that the POM could serve that purpose *if* POMs can hold additional metadata somehow. Seems like a potential misuse of the pom.xml. The power of the project object model is that it's standardized and contains the metadata common to all projects (as much as possible). Even if you could do it, why would this custom metadata need to sit in the pom file if it's specific to a particular environment or technology only? Wouldn't be cleaner and simpler to to create a .gpm (Grails Plugin Metadata) with its own schema and whip up a plugin that reads it in from a pre-defined source location, possibly also adding it both to the zip and attaching it as a secondary artifact to the module? If you wanted to specify this metadata as part of the pom, you'd probably still want to create a custom plugin for it. The configuration section for a plugin can carry arbitrary xml data. For example, see jar plugin's manifest customization at http://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html. You could follow the same approach for your custom plugin. Kalle - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Custom metadata in a POM?
On Fri, Jun 4, 2010 at 3:07 PM, Les Hazlewood l...@katasoft.com wrote: It definitely doesn't have to sit in the POM file if that's considered bad practice. The key is that the Plugin Portal would need to download something lightweight to discover the metadata and not the actual plugin. There is already a Grails plugin.xml file that they use for this purpose, but it currently is bundled inside the plugin .zip - not ideal. I'm sure that can be re-used. The main goal though was to have that plugin.xml somewhere external to the plugin .zip so the Plugin Portal can 'know' about the plugin and not need to download it directly. I'll bring up your suggestions - I Sounds like publishing the plugin.xml might be the right path since such a thing exists already. Jar plugin additionally packages the pom file by default into the jar, in this case you'd just need to do the opposite. You could very simply create a prototype configuration with the buildhelper plugin, see Attach additional artifacts to your project section at http://mojo.codehaus.org/build-helper-maven-plugin/usage.html. I'd designate a custom type, such as .gpm for that xml file though to make it easily identifiable. Kalle On Fri, Jun 4, 2010 at 2:10 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: On Fri, Jun 4, 2010 at 1:28 PM, Les Hazlewood l...@katasoft.com wrote: Is this possible? So, in addition to stuff like developers, is it possible to add additional metadata? plugins. Seems like a potential misuse of the pom.xml. The power of the project object model is that it's standardized and contains the metadata common to all projects (as much as possible). Even if you could do it, why would this custom metadata need to sit in the pom file if it's specific to a particular environment or technology only? Wouldn't be cleaner and simpler to to create a .gpm (Grails Plugin Metadata) with its own schema and whip up a plugin that reads it in from a pre-defined source location, possibly also adding it both to the zip and attaching it as a secondary artifact to the module? If you wanted to specify this metadata as part of the pom, you'd probably still want to create a custom plugin for it. The configuration section for a plugin can carry arbitrary xml data. For example, see jar plugin's manifest customization at http://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html. You could follow the same approach for your custom plugin. Kalle - 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: [ANN] Maven Project Info Reports Plugin 2.2 Released
Deeply sorry for the noise - this is Apache Shiro using apache:apache:7 as the parent - I really thought I had verified it's using 2.1 site plugin but alas, it declares 2.0.1. Overrode to 2.1 and all is good. Kalle On Fri, May 21, 2010 at 12:06 AM, Lukas Theussl ltheu...@apache.org wrote: Are you sure you are using site-plugin-2.1? This should already be pulling in doxia-1.1. Also the line number 791 doesn't exist in XhtmlSink in doxia-1.1... it looks like you have an old doxia being mixed in by something else. If you can't track it, please attach a complete test project with error logs at http://jira.codehaus.org/browse/DOXIA. Thanks, -Lukas Kalle Korhonen wrote: Thanks! I tried 2.2 with the site plugin (2.1), but I'm getting: [INFO] Trace java.lang.ArrayIndexOutOfBoundsException: 1 at org.apache.maven.doxia.module.xhtml.XhtmlSink.tableCell(XhtmlSink.java:791) which seems to be caused by: http://jira.codehaus.org/browse/DOXIA-215 Assuming the problem is that the site plugin uses an older version of doxia, is there a way to configure it use doxia 1.1 or is a new release of the site plugin required? Kalle On Thu, May 20, 2010 at 3:04 AM, Olivier Lamyol...@apache.org wrote: Hi, The Maven team is pleased to announce the release of the Maven 2.x Project Info Reports Plugin, version 2.2 NOTE : this version is site plugin 2.1+ required. http://maven.apache.org/plugins/maven-project-info-reports-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-project-info-reports-plugin/artifactId version2.2/version /plugin Release Notes - Maven 2.x Project Info Reports Plugin, version 2.2 Bug : * [MPIR-150] - the dependency report ignores mirrors * [MPIR-159] - ZipException during mvn clean compile site * [MPIR-172] - Be sure that anchor are unique * [MPIR-174] - remove use of container.getLoggerManager() (to be compatible wih maven 3.x) * [MPIR-179] - Dependency File Details and Dependency Repository Locations tables have a border when rendered with maven-site-plugin 2.1 Improvement * [MPIR-137] - Dependency Locations should work with an intranet repository and restricted internet access * [MPIR-186] - Update location for Subversion Home page * [MPIR-189] - Allow configuration of mailing list header text. New Feature * [MPIR-170] - Create a module overview page ala m1 Task * [MPIR-101] - Update to Doxia 1.1 * [MPIR-173] - Review the Doxia Sink calls Enjoy, -- The Maven team - 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: Broken mvn site
Yes, in 2.x reporting plugins don't use the pluginManagement section, I've never understood why. It's stated *somewhere* in the docs but whether you are going to read it before first hitting the issue is probably unlikely. The whole reporting is going to be revamped in 3.x and I'm sure this is one of the issues that will be dealt with, one way or the other. If you just want your stuff to work, I wouldn't wander to 3.x just yet. How I've dealt with the issue is that I mostly configure the reports in the parent pom and then declare properties if I have to provide special configurations for the child poms. Kalle On Wed, May 19, 2010 at 10:05 AM, Tim Fulmer tful...@dslextreme.com wrote: Hello, Yesterday we noticed an error when running mvn site to generate cobertura reports to track down some coverage issues. Turns out this was caused by a snapshot update mandated by the special way Maven handles plugin versioning. Things got even more special when trying to specify a version of org.apache.maven.plugins:maven-project-info-reports-plugin. Turns out plugin management doesn't work for reporting. The version specified in plugin management is ignored in reporting and the current version is used. Even though the current documentation on configuring reporting shows a plugin management configuration. The solution was to spam a version configuration across 20 some odd POM files. I'm sure we missed a few. This isn't the first time we've been bitten by Maven's special plugin versioning and dependency management. Other's have ongoing issues with this as well. My question is why hasn't this been fixed yet? Why is plugin management the one place where Maven's own versioning and dependency management practices are completely ignored in favor of something that's obviously broken? When is it going to be fixed? -- Tim - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] Maven Project Info Reports Plugin 2.2 Released
Thanks! I tried 2.2 with the site plugin (2.1), but I'm getting: [INFO] Trace java.lang.ArrayIndexOutOfBoundsException: 1 at org.apache.maven.doxia.module.xhtml.XhtmlSink.tableCell(XhtmlSink.java:791) which seems to be caused by: http://jira.codehaus.org/browse/DOXIA-215 Assuming the problem is that the site plugin uses an older version of doxia, is there a way to configure it use doxia 1.1 or is a new release of the site plugin required? Kalle On Thu, May 20, 2010 at 3:04 AM, Olivier Lamy ol...@apache.org wrote: Hi, The Maven team is pleased to announce the release of the Maven 2.x Project Info Reports Plugin, version 2.2 NOTE : this version is site plugin 2.1+ required. http://maven.apache.org/plugins/maven-project-info-reports-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-project-info-reports-plugin/artifactId version2.2/version /plugin Release Notes - Maven 2.x Project Info Reports Plugin, version 2.2 Bug : * [MPIR-150] - the dependency report ignores mirrors * [MPIR-159] - ZipException during mvn clean compile site * [MPIR-172] - Be sure that anchor are unique * [MPIR-174] - remove use of container.getLoggerManager() (to be compatible wih maven 3.x) * [MPIR-179] - Dependency File Details and Dependency Repository Locations tables have a border when rendered with maven-site-plugin 2.1 Improvement * [MPIR-137] - Dependency Locations should work with an intranet repository and restricted internet access * [MPIR-186] - Update location for Subversion Home page * [MPIR-189] - Allow configuration of mailing list header text. New Feature * [MPIR-170] - Create a module overview page ala m1 Task * [MPIR-101] - Update to Doxia 1.1 * [MPIR-173] - Review the Doxia Sink calls Enjoy, -- The Maven team - 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: Put applet jar to WAR root
Use the dependency plugin. See http://svn.apache.org/repos/asf/incubator/shiro/trunk/samples/spring/pom.xml for example, doing exactly the same thing for deploying a webstart app to webapp broot. Kalle On Mon, May 17, 2010 at 3:40 AM, Aleksey Didik di...@magenta-technology.ru wrote: Hello all, I need to put the applet jar to my WAR root folder. Applet jar are developed in the same project, just another module. I define applet jar as module dependency, but in this case it was put in WEB-INF/lib. Is at possible to make some mapping to put this jar to root folder? And use outputFileMapping in the same time. I use maven-war-plugin. Thanks, Aleksey. - 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: Deployment of non-jar artifacts
So the deb is a secondary artifact in the same module? Use the buildhelper plugin, see the last example at http://mojo.codehaus.org/build-helper-maven-plugin/usage.html Kalle On Thu, May 13, 2010 at 9:44 AM, Jason Winnebeck jpw...@rit.edu wrote: What is the best way to deploy a non-jar file built with a plugin? I have a jar project I build in Maven, which works nicely to build and deploy jar, javadocs, and sources artifacts. I've written my own plugin that generates a deb into target directory (I'm aware of existing deb plugins, but they didn't meet my needs). But when I install or deploy, the deb doesn't go with the jar files I made. What is the most appropriate way to do this? I've used install:file and deploy:file from command line with 3rd party jars, but I'm really afraid that using the plugins in this way isn't appropriate for this -- it seems to create new metadata/pom files in the actual repository that don't seem right. I think I'm attaching the artifact properly in my plugin code, although it doesn't cause Maven to do anything with it: File output = ...; //the deb file I made projectHelper.attachArtifact( getProject(), deb-archive, output ); Jason - 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: Freaking out: javac works, maven-compiler-plugin does not
Are you absolutely positively sure your command-line javac is of the
same minor version as what Maven uses? 1.5 doesn't implement generics
captures so you'd get these kinds of problems if you tried to compile
the same with 1.6 - source is not version compatible even if binary
is.
Kalle
On Thu, May 6, 2010 at 1:27 PM, Matthew Adams matt...@matthewadams.me wrote:
I have a class that compiles fine using javac, but does not compile
when building with the maven-compiler-plugin.
Here's the class source. Basic java.
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
@Target( { ElementType.METHOD, ElementType.CONSTRUCTOR })
@Retention(RetentionPolicy.RUNTIME)
public @interface RequiresMutability {
boolean value() default true;
Class? extends RuntimeException throws_() default RuntimeException.class;
}
When compiling with the following command, everything works fine:
javac -source 1.6 -target 1.6 src/main/java/.../RequiresMutability.java
When I compile using Maven, it barfs:
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/home/madams/dev/commons-trunk/domain/src/main/java/org/piercecountywa/commons/domain/annotations/RequiresMutability.java:[21,72]
incompatible types
found : java.lang.Classjava.lang.RuntimeException
required: java.lang.Class? extends java.lang.RuntimeException
[INFO] 1error
[INFO] -
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
This project's pom has almost nothing in it besides the declaration of
its parent and a few of dependencies: one on another
application-specific artifact, one on OpenJPA, and one on junit (with
scope of test). Its parent pom configures the maven-compiler-plugin:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.3/version
configuration
source1.6/source
target1.6/target
/configuration
/plugin
Can anyone tell me why maven-compiler-plugin barfs on the class above
but javac likes it just fine?
$ mvn -version
Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700)
Java version: 1.6.0_18
Java home: /home/madams/programs/java/jdk1.6.0_18/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux version: 2.6.32-22-generic arch: amd64 Family: unix
-matthew
-
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: Conveniently switch between settings
Heh, that's old school - you actually have two different machines. I bet many developers today do their work on a single laptop, which leads to the constant need to change settings, especially if you work on multiple projects, some professional, some open source ones. One solution is, if you can, to run your own personal proxy that proxies everything you need and go through that at all times. Kalle On Fri, May 7, 2010 at 7:04 AM, Thiessen, Todd (Todd) tthies...@avaya.com wrote: Hmmm. I don't quite see the issue. At home I have a settings.xml file that defines my environment at home, and at work I have a settings.xml file that defines my environment at work. I can issue the same mvn command at home or at work and at home it doesn't go to a proxy and at work it does. I don't see what issue you are having. There is no need to switch between settings.xml files. Are you perhaps saving your settings.xml file with your project in source control? This may be the problem. All I do is modify the global settings.xml file in the conf folder of my maven install. You could put these changes in your local settings.xml file but I prefer the global settings.xml file as I find configuring which repos to use to be more global in nature. -Original Message- From: Kalpak Gadre [mailto:kalpa...@gmail.com] Sent: Friday, May 07, 2010 2:44 AM To: Maven Users List Subject: Conveniently switch between settings Hi, I use Maven from workplace and home. At workplace we have proxy as well as a maven repository. Where at home I don't need any proxy and don't have a repository. Is there no convenient way to switch between these configurations other than specifying alternate settings file? It would be nice if it was at profile level where I could just say mvn -P home I know that there are lot of issue with that. I hope most of us face this problem. What do you guys do? Thanks, Kalpak - 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: problems with deploying
On Wed, Apr 14, 2010 at 2:06 PM, Justin Lee evancho...@gmail.com wrote:
I'm working on making the grizzly deployments actually work with maven
[INFO] The version could not be updated: ${grizzly-version}
The problem, it seems, is that we use the property grizzly-version defined
in the root pom (https://grizzly.dev.java.net/svn/grizzly/trunk/code/pom.xml)
to specify the intermodule dependencies. Now, I've seen poms that don't
specify the module versions in the deps but when I try that, the pom fails
to validate. So I guess I have two questions:
1. Can we not use the property for the dependency version number like
that? Do we need to hard code the project version?
2. How can we eliminate that version entry from the dependency
altogether? That'd be the simplest way, i think, if it works that way.
Use dependency management section of the parent pom to specify
versions for the child modules. Then don't explicitly specify versions
when referring to any of your own dependencies. You don't have to
hard-code versions in the parent pom for each separately, you can use
properties. You should always use snapshot version when specifying
version for your own modules in development. The release plugin
handles updating the versions from snapshot to release and back. For
example, see various other projects using Maven, such as
http://svn.apache.org/repos/asf/incubator/shiro/trunk/pom.xml
Kalle
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: problems with deploying
That's the best practice. Read about it if you don't believe me.
Kalle
On Wed, Apr 14, 2010 at 2:32 PM, Justin Lee evancho...@gmail.com wrote:
I thought about that (and I plan on moving all our deps to that -- the
current set up is a mess) but it seems a bit of an antipattern to have to
specify intra-project dependencies like that. Seems overly redundant.
On Wed, Apr 14, 2010 at 5:30 PM, Kalle Korhonen
kalle.o.korho...@gmail.comwrote:
On Wed, Apr 14, 2010 at 2:06 PM, Justin Lee evancho...@gmail.com wrote:
I'm working on making the grizzly deployments actually work with maven
[INFO] The version could not be updated: ${grizzly-version}
The problem, it seems, is that we use the property grizzly-version
defined
in the root pom (
https://grizzly.dev.java.net/svn/grizzly/trunk/code/pom.xml)
to specify the intermodule dependencies. Now, I've seen poms that don't
specify the module versions in the deps but when I try that, the pom
fails
to validate. So I guess I have two questions:
1. Can we not use the property for the dependency version number like
that? Do we need to hard code the project version?
2. How can we eliminate that version entry from the dependency
altogether? That'd be the simplest way, i think, if it works that way.
Use dependency management section of the parent pom to specify
versions for the child modules. Then don't explicitly specify versions
when referring to any of your own dependencies. You don't have to
hard-code versions in the parent pom for each separately, you can use
properties. You should always use snapshot version when specifying
version for your own modules in development. The release plugin
handles updating the versions from snapshot to release and back. For
example, see various other projects using Maven, such as
http://svn.apache.org/repos/asf/incubator/shiro/trunk/pom.xml
Kalle
-
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: How to download maven dependencies into a fixed folder, NOT a local repo
http://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-project-dependencies.html Kalle On Tue, Mar 30, 2010 at 11:43 AM, John Eke tone...@yahoo.com wrote: Hi, I have a maven repository that manages dependencies for my projects. Currently in my release environment I am manually doing a wget for all the jars that I depend on. I have my main project jar, but then I also have several other dependent jars I need from maven. I don't want a local repository on released product, so I was wondering if there is a command to get all the dependencies into a fixed folder (eg. thirdparty_libs). Then I can configure my software to add that folder to the CLASSPATH. Thanks a lot for your time and help. - John E - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: New snapshots versus the local repo
On Tue, Mar 16, 2010 at 4:18 AM, Benson Margulies bimargul...@gmail.com wrote: If the answer is, 'always make a branch,' then that's the answer. It is not a popular answer with the developers I'm supporting. I wish there was some alternative involving controlling snapshot updates per g/a instead of per repository. --offline prevents unwanted updates, but it also prevents wanted updates of other, unmodified, things, and new dependencies. Offline is the answer short of a branch. In any maintained and stable build, there should generally be no other snapshot dependencies than your project own ones. Using external snapshot dependencies should be an exception rather than a rule. Kalle On Tue, Mar 16, 2010 at 5:54 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 16 March 2010 04:25, Ron Wheeler rwhee...@artifact-software.com wrote: Benson Margulies wrote: I have this feeling that I'm missing something terribly obvious. 1: grab a tree and make some changes. 2: mvn. Now you've got SNAPSHOT versions in your local repository 3: someone else checks in a change and runs mvn deploy. Now the snapshot repo has jars newer than the local repo. 4: run mvn and download those over top of the local mods. Only if you have the update rule for your snapshot repos set to check every time. If you are working on a branch, then run maven in offline mode to prevent having to worry about picking up other versions that somebody elese has deployed Without patching all the version numbers, is there a best practice or standard mechanism to stay out of this pickle? What is the pickle? You have the latest version which is what you want if the person doing the deploy has done the deploy for a reason. If the version deployed is not better than the version that you have locally, you beat the crap out of the guy who deployed a version when they shouldn't have. If people deploy crap into repositories, you will have a problem eventually. If you put your version into your source management, the other person would have based his mods on yours or at least noticed the conflicts before he deployed. Collaborative software development has to be done collaboratively. Ron - 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: distribution build for non-maven users
On Wed, Mar 10, 2010 at 12:58 AM, Erlend Hamnaberg ngar...@gmail.com wrote: I have project that is on codehaus. For some reason I decided to have a distribution build as an attached artifact. This causes clutter in the repo, which I do not want. Are there any guidelines for how to create a distribution for a maven project for non-maven users? I think there are too many variables and preferred outcomes to suggest guidelines. However, I've done some distributions with the site deploy. You package your thing up as part of site, put it in the site target directory and let it be deployed as part of site-deploy (which in turn is run as part of release:perform). Kalle - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: release:perform from a branch?
You don't need any command line options to release from a branch (I'd even go so far as to say that if you need to specify command line options with mvn release, you haven't configured the plugin correctly) but you *have to* have scm urls pointing to the right location (i.e. not the trunk for the branched versioned). If you created the branch using mvn release:branch, it would manage the scm element for you (again, assuming you've configured the plugin properly in the first place). We do all of our point/bug fix releases from branches. Kalle On Wed, Mar 10, 2010 at 8:51 AM, Steven Hilton mshilt...@gmail.com wrote: Greetings, Can the maven release plugin build a tag from a branch during a release:prepare? Ultimately, I want to do a release:peform from a tag based off a branch where maven never looks at or touches trunk. I've tried a number of different command line options, read some docs at http://maven.apache.org/guides/mini/guide-releasing.html and other places and am not seeing how to do this. Before: * I create a branch * Do development work on the branch, fixing bugs, etc. * Now it's time to release the bug fixes, but we can't merge the changes to trunk. Now: * I check out the branch to a new working location * cd to that working location * mvn -Dtag=myTagName release:prepare When it manipulates the poms, it sets them correctly and commits them to the branch. But then I can't get it to do the svn copy from any place other than trunk, even though I'm operating on branch. I've tried -DconnectionUrl but that seems to be ignored in this context. Afterward, when I do a release:perform, the poms are out of sync, so it fails since the tag it checks out was tagged from trunk. Also, it's using code that doesn't have the bug fixes that are in the branch, which is bad. Is there a configuration option I'm missing? I can't find it anywhere. Thanks for any help. - Steven - 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: Forcing maven-site-plugin to override/replace distributionManagement
Perhaps add a stage profile where you override the distributionManagement/site definition and which you'd activate with site:stage-deploy? Kalle On Wed, Mar 10, 2010 at 10:44 AM, shinsato har...@shinsato.com wrote: I'm having a heck of a time with our build since we've been required to use a parent pom.xml that has it's own distributionManagement section. The plan is to not allow us to define our own distributionManagement - but relying on the parent for our site definition seems to have wreaked all kinds of havoc. I'd hope that the -DstagingDirectory=c:\whatever would enable us to force the build there, but it seems to keep tacking on the site directory, but not as a whole - rather in pieces, and not reliably. Is there some trick to doing a mvn site:stage or mvn site:stage-deploy where I can have complete control over where the site is - overriding the entire site definition in the distributionManagement section of the pom.xml??? -- View this message in context: http://old.nabble.com/Forcing-maven-site-plugin-to-override-replace-distributionManagement-tp27854110p27854110.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Better Maven plugins for Tomcat remote hot deployment?
This might be more of a Tomcat question but then again, I'm mostly interested in Maven plugins for Tomcat. For remote deployment, both Cargo and Tomcat plugin use and integrate with Tomcat's manager application which is dog slow as it can only deploy the full war over http and happily shuts down the context right at the beginning of the upload. Since most of the time, it's only my own application code that changes, I'd like to do two things to minimize downtime of the application: a) Deploy a skinny war and dependent libs separately and b) deploy over scp to a temp dir, then move the war to the right place. So before I go and hack up something together myself, I'll just ask if anybody has done anything similar and/or know of any scripts or plugins that would do this? It wouldn't seem too difficult to write up an Ant script or just plain old Java code to achieve the goals. If there is a similar utility available for Jetty, I wouldn't mind switching. Kalle - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: cobertura jetty
Glad to hear you got things working. Just a note on Cobertura though; we are running our cove coverage for unit and container-based integration tests with Cobertura so it's not the tool per se. Could have been an issue with the version of Cobertura you were using or the configuration but if Emma is working for you and you are happy with it, I wouldn't switch. Kalle On Fri, Mar 5, 2010 at 1:05 AM, Douglas Ferguson doug...@douglasferguson.us wrote: Actually switching to emma got things working.. I just start jetty from the base class of my selenium test. I have a static field that prevents jetty from attempting to start twice. Seems to work great. D/ On Mar 4, 2010, at 11:23 PM, hanasaki wrote: most of what I have found points to using emma to get code coverage in the integration phase using the failsafe plugin and embedded Jetty. Original Message Subject: cobertura jetty From: Douglas Ferguson doug...@douglasferguson.us To: Maven Users List users@maven.apache.org Date: 03/04/2010 10:43 PM So I finally got jetty starting from my test case, but it doesn't impact the code coverage. My BasePage class is at 0% which is confusing. The server is started from the test class which would make you think would be using the instrumented classes and jetty would inherit the same classpath. What am I missing? Douglas - 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: starting jetty during tests and stopping afterwards
Why would you insist on starting it with mvn? How do you run the the
same test in your IDE? Wouldn't it be easier to just use JettyHelper
in your test? For another example of the same concept, perhaps a bit
more evolved, see
http://svn.codehaus.org/tynamo/trunk/tapestry-model/tapestry-model-test/src/main/java/org/tynamo/test/AbstractContainerTest.java
(http://tynamo.org)
Kalle
On Thu, Mar 4, 2010 at 9:38 AM, Douglas Ferguson
doug...@douglasferguson.us wrote:
Hmm.. But how would I start that and stop it with mvn? Looks like you'd need
to have a reference to the instantiated JettyHelp in order to stop it.
D/
On Mar 4, 2010, at 6:07 AM, Stephen Connolly wrote:
public final class JettyHelper {
private JettyHelper() {
throw new IllegalAccessError(Utility class);
}
public static Server createServer(int port, File warFile, String
contextRoot) throws Exception {
Server server = new Server();
Connector connector = new SelectChannelConnector();
connector.setPort(port);
server.addConnector(connector);
WebAppContext context = new WebAppContext(warFile.getAbsolutePath(),
contextRoot);
context.setConfigurationClasses(new String[]{
org.mortbay.jetty.webapp.WebInfConfiguration,
org.mortbay.jetty.plus.webapp.EnvConfiguration,
org.mortbay.jetty.annotations.Configuration,
org.mortbay.jetty.webapp.JettyWebXmlConfiguration,
org.mortbay.jetty.webapp.TagLibConfiguration
});
context.setExtractWAR(false);
context.setCopyWebDir(false);
context.setParentLoaderPriority(true);
server.setHandler(context);
server.start();
return server;
}
public static void destroyServer(Server server) throws Exception {
if (server == null) return;
if (!server.isStopped()) {
server.stop();
server.join();
}
}
}
On 4 March 2010 11:58, Douglas Ferguson doug...@douglasferguson.us wrote:
I've been experimenting with this and have come to find out that the mvn
jetty plugin is not compatible with projects that include jetty in their pom
dependencies.
Now I need to figure out a different way to start up jetty. I have a
Start.java class that could start up jetty but i would need to figure out
how to stop it.
Also, I'm found some information online about a version cobertura plugin
that had a seperate generate-report goal. Anybody know where I could locate
this?
D/
On Mar 4, 2010, at 4:05 AM, Brett Porter wrote:
On 04/03/2010, at 8:49 PM, Douglas Ferguson wrote:
Is there a clean way to start up jetty for the testing and then stopping
git afterwards?
I'd like to include my integration tests for my code coverage.
I'd like to set my code coverage profile to only start up jetty after
cobertura has instrumented the classes
then shut it down after the tests complete.
Could I just start up the jetty in process-test-classes and shut it down
in prepare-package?
Yep.
http://github.com/brettporter/centrepoint/blob/master/centrepoint/modules/selenium-tests/pom.xml
Bear in mind that if the tests fail, the stop won't be run, but
normally they will shut down properly when Maven does anyway.
- Brett
--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/
-
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: starting jetty during tests and stopping afterwards
If it takes a long time, why would you restart for each test? If you
look at the link I sent, you'll see the instance is started only once
per jvm by default.
Kalle
On Thu, Mar 4, 2010 at 10:35 AM, Douglas Ferguson
doug...@douglasferguson.us wrote:
I have 20 tests and the number is growing.
I don't want to start and stop jetty for every test, because hibernate and
guice intialize actually take a little bit of time.
Which would slow down the entire suite..
D/
On Mar 4, 2010, at 12:17 PM, Kalle Korhonen wrote:
Why would you insist on starting it with mvn? How do you run the the
same test in your IDE? Wouldn't it be easier to just use JettyHelper
in your test? For another example of the same concept, perhaps a bit
more evolved, see
http://svn.codehaus.org/tynamo/trunk/tapestry-model/tapestry-model-test/src/main/java/org/tynamo/test/AbstractContainerTest.java
(http://tynamo.org)
Kalle
On Thu, Mar 4, 2010 at 9:38 AM, Douglas Ferguson
doug...@douglasferguson.us wrote:
Hmm.. But how would I start that and stop it with mvn? Looks like you'd
need to have a reference to the instantiated JettyHelp in order to stop it.
D/
On Mar 4, 2010, at 6:07 AM, Stephen Connolly wrote:
public final class JettyHelper {
private JettyHelper() {
throw new IllegalAccessError(Utility class);
}
public static Server createServer(int port, File warFile, String
contextRoot) throws Exception {
Server server = new Server();
Connector connector = new SelectChannelConnector();
connector.setPort(port);
server.addConnector(connector);
WebAppContext context = new WebAppContext(warFile.getAbsolutePath(),
contextRoot);
context.setConfigurationClasses(new String[]{
org.mortbay.jetty.webapp.WebInfConfiguration,
org.mortbay.jetty.plus.webapp.EnvConfiguration,
org.mortbay.jetty.annotations.Configuration,
org.mortbay.jetty.webapp.JettyWebXmlConfiguration,
org.mortbay.jetty.webapp.TagLibConfiguration
});
context.setExtractWAR(false);
context.setCopyWebDir(false);
context.setParentLoaderPriority(true);
server.setHandler(context);
server.start();
return server;
}
public static void destroyServer(Server server) throws Exception {
if (server == null) return;
if (!server.isStopped()) {
server.stop();
server.join();
}
}
}
On 4 March 2010 11:58, Douglas Ferguson doug...@douglasferguson.us wrote:
I've been experimenting with this and have come to find out that the mvn
jetty plugin is not compatible with projects that include jetty in their
pom
dependencies.
Now I need to figure out a different way to start up jetty. I have a
Start.java class that could start up jetty but i would need to figure out
how to stop it.
Also, I'm found some information online about a version cobertura plugin
that had a seperate generate-report goal. Anybody know where I could
locate
this?
D/
On Mar 4, 2010, at 4:05 AM, Brett Porter wrote:
On 04/03/2010, at 8:49 PM, Douglas Ferguson wrote:
Is there a clean way to start up jetty for the testing and then stopping
git afterwards?
I'd like to include my integration tests for my code coverage.
I'd like to set my code coverage profile to only start up jetty after
cobertura has instrumented the classes
then shut it down after the tests complete.
Could I just start up the jetty in process-test-classes and shut it down
in prepare-package?
Yep.
http://github.com/brettporter/centrepoint/blob/master/centrepoint/modules/selenium-tests/pom.xml
Bear in mind that if the tests fail, the stop won't be run, but
normally they will shut down properly when Maven does anyway.
- Brett
--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/
-
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
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe
Re: starting jetty during tests and stopping afterwards
On Thu, Mar 4, 2010 at 11:03 AM, Douglas Ferguson
doug...@douglasferguson.us wrote:
So how does the server get stopped?
Up to you, but typically when the JVM exits.
Kalle
On Mar 4, 2010, at 12:46 PM, Kalle Korhonen wrote:
If it takes a long time, why would you restart for each test? If you
look at the link I sent, you'll see the instance is started only once
per jvm by default.
Kalle
On Thu, Mar 4, 2010 at 10:35 AM, Douglas Ferguson
doug...@douglasferguson.us wrote:
I have 20 tests and the number is growing.
I don't want to start and stop jetty for every test, because hibernate and
guice intialize actually take a little bit of time.
Which would slow down the entire suite..
D/
On Mar 4, 2010, at 12:17 PM, Kalle Korhonen wrote:
Why would you insist on starting it with mvn? How do you run the the
same test in your IDE? Wouldn't it be easier to just use JettyHelper
in your test? For another example of the same concept, perhaps a bit
more evolved, see
http://svn.codehaus.org/tynamo/trunk/tapestry-model/tapestry-model-test/src/main/java/org/tynamo/test/AbstractContainerTest.java
(http://tynamo.org)
Kalle
On Thu, Mar 4, 2010 at 9:38 AM, Douglas Ferguson
doug...@douglasferguson.us wrote:
Hmm.. But how would I start that and stop it with mvn? Looks like you'd
need to have a reference to the instantiated JettyHelp in order to stop
it.
D/
On Mar 4, 2010, at 6:07 AM, Stephen Connolly wrote:
public final class JettyHelper {
private JettyHelper() {
throw new IllegalAccessError(Utility class);
}
public static Server createServer(int port, File warFile, String
contextRoot) throws Exception {
Server server = new Server();
Connector connector = new SelectChannelConnector();
connector.setPort(port);
server.addConnector(connector);
WebAppContext context = new
WebAppContext(warFile.getAbsolutePath(),
contextRoot);
context.setConfigurationClasses(new String[]{
org.mortbay.jetty.webapp.WebInfConfiguration,
org.mortbay.jetty.plus.webapp.EnvConfiguration,
org.mortbay.jetty.annotations.Configuration,
org.mortbay.jetty.webapp.JettyWebXmlConfiguration,
org.mortbay.jetty.webapp.TagLibConfiguration
});
context.setExtractWAR(false);
context.setCopyWebDir(false);
context.setParentLoaderPriority(true);
server.setHandler(context);
server.start();
return server;
}
public static void destroyServer(Server server) throws Exception {
if (server == null) return;
if (!server.isStopped()) {
server.stop();
server.join();
}
}
}
On 4 March 2010 11:58, Douglas Ferguson doug...@douglasferguson.us
wrote:
I've been experimenting with this and have come to find out that the mvn
jetty plugin is not compatible with projects that include jetty in
their pom
dependencies.
Now I need to figure out a different way to start up jetty. I have a
Start.java class that could start up jetty but i would need to figure
out
how to stop it.
Also, I'm found some information online about a version cobertura plugin
that had a seperate generate-report goal. Anybody know where I could
locate
this?
D/
On Mar 4, 2010, at 4:05 AM, Brett Porter wrote:
On 04/03/2010, at 8:49 PM, Douglas Ferguson wrote:
Is there a clean way to start up jetty for the testing and then
stopping
git afterwards?
I'd like to include my integration tests for my code coverage.
I'd like to set my code coverage profile to only start up jetty after
cobertura has instrumented the classes
then shut it down after the tests complete.
Could I just start up the jetty in process-test-classes and shut it
down
in prepare-package?
Yep.
http://github.com/brettporter/centrepoint/blob/master/centrepoint/modules/selenium-tests/pom.xml
Bear in mind that if the tests fail, the stop won't be run, but
normally they will shut down properly when Maven does anyway.
- Brett
--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com/
-
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: Source for maven-jibx-plugin
On Wed, Mar 3, 2010 at 3:00 PM, marilysa maril...@cisco.com wrote: Does anyone know how to get the source code and license information for maven-jibx-plugin? The web site gives a link to the license, but that link is broken. It gives a link to the source code repository, but access to that page is disabled. It gives instructions for using CVS to fetch the source as an anonymous user, but the commands do not work. Several of us here have tried to obtain the sources and license, with no success. It's still in the cvs. The code is browsable via http://jibx.cvs.sourceforge.net/viewvc/jibx/maven-jibx-plugin/ Cvs works, use the Sourceforge project developer page for access details: http://sourceforge.net/projects/jibx/develop My company is using maven-jibx-plugin in building one of our products, and we have strict requirements regarding use of Open Source IP. We are required to have the sources stored in a central IP database, as well as the complete text of the license. jibx is under BSD license. Storing the sources is not required for code under BSD-style licenses (take my word for it :) ) Kalle - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re : Release notification
We use Nexus for RSS feeds, it has a built-in feed for releases. Kalle On Thu, Feb 25, 2010 at 10:06 AM, Wayne Fay wayne...@gmail.com wrote: Is there a way to add notifications (email, RSS, etc.) when a release is performed ? Seems like a feature I'd expect to get from an MRM (Nexus, Artifactory, Archiva) rather than from Maven itself. 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: Maven2/CI Best Practices for Distributed Development
SNAPSHOTs are essential (otherwise developers end up with multiple different versions of platform libs in their local repositories) and you should deploy them automatically if you want to avoid compiling the platform code. @Ron; multiple repositories are needed to distinguish the branched platform versions during the iterations (if the platform branches are not versioned, say platform-1.0-team1-sprint2-SNAPSHOT). However, you'd avoid the merging issues and over-complicating things with multiple snapshot repositories if you could stick with just the trunk version of the platform code and perhaps make one team generally responsible for making the platform changes, other teams acting as customers of the platform team. In addition to doing what you suggested, you should automate making the releases with the release plugin. It may be a bit painful to start with as it's much more rigid process than just randomly hacking away with no regards to versions but should start paying dividends fairly quickly. I would almost insist that teams generally use only released versions of the platform code, thereby reserving SNAPSHOTs only for those times where a client team and the platform team need to co-ordinate their changes and explore the options to get the API right. If the release process is well automated, the platform team can release platform several times even during the iteration and the client teams can pick up new versions at their own pace. Disable javadocs, source code packaging, dependencies repository discovery reports for release to make it go faster - you want the release to go as fast as possible. The reality in a big software company is seldom as pretty as you'd hope it to be. If the platform code isn't very coherent and it's tightly coupled with a specific product implementation, you often need changes on both sides to make some new feature work. If a specific part of platform is highly specific to a particular product or a a group of product, consider mercilessly refactoring that part into its own common module, out of the core platform so they are not force to evolve together. The teams will selfishly choose the easiest path for them, often adding something to the platform that shouldn't be there if given a choice because they are under a constant pressure to deliver. In the long run it's better if you can resist those kind of changes and have somebody look after the evolution of the platform itself. Each product team will likely complain about the sluggish pace of the platform team (if there's a gatekeeper for the platform - and it doesn't mean they have to write the code, just participate and know what changes go into the platform code) but it's the price you have to pay to keep the platform coherent. Kalle On Mon, Feb 15, 2010 at 7:17 AM, Ron Wheeler rwhee...@artifact-software.com wrote: You didn't mention a SCM explicitely but it appears that you have one. That is essential. We have just started using SNAPSHOTs and Nexus and it is a great idea. Whether you deploy SNAPSHOTs automatically or manually probably does not make much difference provided everyone follows the rules. I am a little unclear on the need to separate SNAPSHOT repositories. I would try to make sure that the libraries and projects are sufficiently granular so that teams can be perfectly clear about who is doing what to each artifact so that merging is done in the SCM as the code is developed rather than afterwards once each team completes the testing. Having 2 mysharedartifact-1.8-SNAPSHOT jars and trying to figure out if they are the same from the repository side is only going to add to the confusion. If 2 teams are working on the same artifact, they should be synchronizing frequently or branching so that the status of each library is clear throughout the process and if one team is using 1.8.1-SNAPSHOT and the other team is using 1.9-SNAPSHOT, then there is going to be a step after all the tests are done to get the libraries merged. They can both use the same Nexus repository. I hope that this helps. E. Pregzt wrote: Hi Everyone, I was wandering what are the Maven beast practices for distributed teams working on the same code base. Let me flash out the structure of the teams and the structure of the code base that I've been dealing with. The code base is organized in such a way there is a common platform that consists several artifacts and there are specific products that use the platform components, but also add domain specific logic, screens and so on. There is a several teams working in parallel on both common platform and specific products. For the simplicity lets assume there is the Platform and products P1 and P2 streams and four teams T1 and T2 working on product P1 and the Platform and T3 and T4 working on product P2 and the Platform as well. Teams are following SCRUM method and are working in 2 weeks sprints. For each sprint period each team branches of the code and just
Re: Maven2/CI Best Practices for Distributed Development
On Mon, Feb 15, 2010 at 11:54 AM, E. Pregzt pre...@gmail.com wrote: Unfortunately we don't have a luxury to have a dedicated team or two for platform at this stage. That would be a good think but unrealistic I'm afraid. Furthermore the platform is quite big and comprehensive and in oppose to SDK-style library also contains domain-specific business components/modules used by different product streams, for high reusability. Due to this fact the teams are naturally working on the specific product code and also on parts of the platform code. Ah, the complexities of real world and for-profit software development :) Yes, been there - slowly, the platform will only become bigger and more convoluted if no one is left to maintain the core until it's time to start all over again. In the long run, it would be better if the core is regularly and mercilessly refactored to not allow it to grow uncontrollably while moving the domain-specific parts to smaller supporting libraries (if not in one of the products). But the sad reality is that for the product teams, the dollar earned today if often more important than two dollars tomorrow. I must say that release plugin is something that I'm missing on my list and I have to investigate further how to use that and what would be the impact on the existing build process. But I'd definitely give it a go if that might help to improve the build process. So, you guys have been using similar approach and it worked and worked well? Releases work. The cost for cutting releases every two weeks (after every sprint) is typically too high with traditional build tools (so you resort to using running buildnumber suffixes or timestamps), and while still fundamentally high, they can be reasonable with Maven, assuming you invest enough in automating the releases. Even with snapshots, in a fast-paced free-for-all development environment, you often run into those unexpected test failures, frustrating development teams or team members (if the snapshots are per-team only) causing lost development time. Even if you cannot afford a dedicated platform team, insist that changes to the platform need to be scheduled and scoped for just the same was as the product stories. And ensure that there is some mechanism how the platform stories are prioritized and that teams that don't know exactly what they expect from the platform and/or cannot afford the resources to implement the changes to the platform simply have to wait and stick with a previous version of the platform until they do. Kalle On Mon, Feb 15, 2010 at 5:13 PM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: SNAPSHOTs are essential (otherwise developers end up with multiple different versions of platform libs in their local repositories) and you should deploy them automatically if you want to avoid compiling the platform code. @Ron; multiple repositories are needed to distinguish the branched platform versions during the iterations (if the platform branches are not versioned, say platform-1.0-team1-sprint2-SNAPSHOT). However, you'd avoid the merging issues and over-complicating things with multiple snapshot repositories if you could stick with just the trunk version of the platform code and perhaps make one team generally responsible for making the platform changes, other teams acting as customers of the platform team. In addition to doing what you suggested, you should automate making the releases with the release plugin. It may be a bit painful to start with as it's much more rigid process than just randomly hacking away with no regards to versions but should start paying dividends fairly quickly. I would almost insist that teams generally use only released versions of the platform code, thereby reserving SNAPSHOTs only for those times where a client team and the platform team need to co-ordinate their changes and explore the options to get the API right. If the release process is well automated, the platform team can release platform several times even during the iteration and the client teams can pick up new versions at their own pace. Disable javadocs, source code packaging, dependencies repository discovery reports for release to make it go faster - you want the release to go as fast as possible. The reality in a big software company is seldom as pretty as you'd hope it to be. If the platform code isn't very coherent and it's tightly coupled with a specific product implementation, you often need changes on both sides to make some new feature work. If a specific part of platform is highly specific to a particular product or a a group of product, consider mercilessly refactoring that part into its own common module, out of the core platform so they are not force to evolve together. The teams will selfishly choose the easiest path for them, often adding something to the platform that shouldn't be there if given a choice because they are under a constant pressure to deliver
Re: unit testing archetypes
Good stuff Luke, thanks, I've been pondering what the best approach is
for this myself.
Kalle
On Thu, Feb 11, 2010 at 6:13 AM, Luke Patterson
lukewpatter...@gmail.com wrote:
On Wed, Feb 10, 2010 at 5:37 PM, Max Spring mspr...@cisco.com wrote:
What would be a good approach to test an archetype project?
...
A minimal test would be to instantiate the archetype and to build the
resulting project.
Here's some cut-and-paste that I'm using:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-invoker-plugin/artifactId
executions
execution
idintegration-test/id
goals
goalinstall/goal
goalrun/goal
/goals
/execution
/executions
configuration
cloneProjectsTo${project.build.directory}/it/projects/cloneProjectsTo
goals
goalorg.apache.maven.plugins:maven-archetype-plugin:generate/goal
/goals
localRepositoryPath${project.build.directory}/it/repo/localRepositoryPath
pomIncludes
pomInclude*/pomInclude
/pomIncludes
projectsDirectory${basedir}/src/it/projects/projectsDirectory
properties
archetypeArtifactId${project.artifactId}/archetypeArtifactId
archetypeGroupId${project.groupId}/archetypeGroupId
archetypeRepositorylocal/archetypeRepository
archetypeVersion${project.version}/archetypeVersion
goalsverify/goals
interactiveModefalse/interactiveMode
/properties
streamLogstrue/streamLogs
/configuration
/plugin
then, your archetype will be run during integration-test phase for all
subdirectories of projectsDirectory, a test.properties file will
contain the inputs to the archetype:generate goal, and the verify
phase will be run on each newly generated project
to add a new test, add another directory under projectsDirectory
with a test.properties file
--
e.g.
src/it/projects/firsttest/test.properties with contents:
groupId=com.foo
artifactId=firsttest
version=1.0.0
package=com.foo.firsttest
that will create a firsttest directory under
${project.build.directory}/it/projects/firsttest with the stuff
generated by your archetype, and then run the verify phase on the
newly generated com.foo.firsttest project
--
-
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: unwanted repository, how does maven locate it
I had filed https://issues.apache.org/bugzilla/show_bug.cgi?id=48216 against log4j to mark javamail as optional (and it's still in NEW state) but yes, log4j should mark all those optional dependencies as so. Kalle On Wed, Feb 10, 2010 at 12:24 PM, Reto Bachmann-Gmür r...@gmuer.ch wrote: ok, the evil-doer is http://repo2.maven.org/maven2/log4j/log4j/1.2.15/log4j-1.2.15.pom it was a bit tricky to find as an older harmless version of it showed up in the dependency tree. Others are having the problem as well: http://jira.codehaus.org/browse/MEV-649 Cheers, reto On Wed, Feb 10, 2010 at 7:57 PM, Reto Bachmann-Gmür r...@gmuer.ch wrote: thanks for the reply. I tried looking for this and found that http://repo2.maven.org/maven2/com/hp/hpl/jena/arq/2.8.2/arq-2.8.2.pom references another repo, but its not the dev.java.net one. I assumed for the repository to be used it would have to be defined on the path to the dependency, or can it be just anywhere? an extract from the output of the build process: ... [INFO] snapshot org.apache.clerezza:org.apache.clerezza.rdf.jena.storage:0.5-incubating-SNAPSHOT: checking for updates from ops4j [INFO] snapshot org.apache.clerezza:org.apache.clerezza.rdf.jena.storage:0.5-incubating-SNAPSHOT: checking for updates from apache [WARNING] POM for 'javax.jms:jms:pom:1.1:compile' is invalid. Its dependencies (if any) will NOT be available to the current build. Downloading: http://repository.ops4j.org/mvn-snapshots//com/sun/jmx/jmxri/1.2.1/jmxri-1.2.1.pom [INFO] Unable to find resource 'com.sun.jmx:jmxri:pom:1.2.1' in repository ops4j (http://repository.ops4j.org/mvn-snapshots/) Downloading: http://repository.apache.org/content/groups/snapshots-group/com/sun/jmx/jmxri/1.2.1/jmxri-1.2.1.pom [INFO] Unable to find resource 'com.sun.jmx:jmxri:pom:1.2.1' in repository apache (http://repository.apache.org/content/groups/snapshots-group) Downloading: http://openjena.org/repo/com/sun/jmx/jmxri/1.2.1/jmxri-1.2.1.pom [INFO] Unable to find resource 'com.sun.jmx:jmxri:pom:1.2.1' in repository repo-jena (http://openjena.org/repo) Downloading: http://openjena.org/repo-dev/com/sun/jmx/jmxri/1.2.1/jmxri-1.2.1.pom [INFO] Unable to find resource 'com.sun.jmx:jmxri:pom:1.2.1' in repository repo-jena-dev (http://openjena.org/repo-dev) Downloading: https://maven-repository.dev.java.net/nonav/repository/com.sun.jmx/poms/jmxri-1.2.1.pom 353b downloaded (jmxri-1.2.1.pom) [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'de02d09af9d9fd6ebe64712281899f4765ff4bd7'; remote = '!DOCTYPE' - RETRYING Downloading: https://maven-repository.dev.java.net/nonav/repository/com.sun.jmx/poms/jmxri-1.2.1.pom 353b downloaded (jmxri-1.2.1.pom) [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'de02d09af9d9fd6ebe64712281899f4765ff4bd7'; remote = '!DOCTYPE' - IGNORING [WARNING] POM for 'com.sun.jmx:jmxri:pom:1.2.1:compile' is invalid. Its dependencies (if any) will NOT be available to the current build. [INFO] snapshot org.apache.clerezza:org.apache.clerezza.rdf.core.test:0.13-incubating-SNAPSHOT: checking for updates from ops4j ... any hint on how to locate the evil doing pom? Cheers, reto On Wed, Feb 10, 2010 at 7:45 PM, Todd Thiessen tthies...@avaya.comwrote: A pom you depend on my have defined it in its pom. To be absolutely sure you only reference the repos you want, you would need to mirror all repos to your own trusted local repository using a repo manager. Good discussion about that here: http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/ --- Todd Thiessen -Original Message- From: Reto Bachmann-Gmür [mailto:r...@gmuer.ch] Sent: Wednesday, February 10, 2010 1:40 PM To: Maven Users List Subject: unwanted repository, how does maven locate it hello I have the following problem using maven 2.2.1 (on minerva.apache.org): maven continuos to download a broken jar and pom from https://maven-repository.dev.java.net/nonav/repository/com.sun .jmx/jars/ Th epatch to the dependency is as follows: [INFO] +- com.hp.hpl.jena:tdb:jar:0.8.4:compile [INFO] | \- com.hp.hpl.jena:arq:jar:2.8.2:compile [INFO] | +- org.codehaus.woodstox:wstx-asl:jar:3.2.9:compile [INFO] | | \- stax:stax-api:jar:1.0.1:compile [INFO] | +- org.apache.lucene:lucene-core:jar:2.3.1:compile [INFO] | +- org.slf4j:slf4j-log4j12:jar:1.5.6:compile [INFO] | \- log4j:log4j:jar:1.2.14:compile [INFO] | +- javax.mail:mail:jar:1.4:compile [INFO] | +- javax.jms:jms:jar:1.1:compile [INFO] | +- com.sun.jdmk:jmxtools:jar:1.2.1:compile [INFO] | \- com.sun.jmx:jmxri:jar:1.2.1:compile the dev.java.net repository is neither in my pom, nor its parent nor in a settings.xml file, any idea why maven tries to download artifacts from there? cheers reto
Re: automating maven release plugin tag label
Are you not using standard SVN directory layout or no SVN at all? We
do fully automated releases with mvn -B release:prepare
release:perform and it gets the tagname etc. right without any special
configuration. As a sidenote, pom.version is deprecated, use
project.version instead.
Kalle
On Fri, Jan 29, 2010 at 1:06 PM, JS Bournival j...@jipiju.com wrote:
Hi maven people,
We have projects we want to release using the maven-release-plugin.
Moreover, we want to perform our releases in Hudson, with the help of the
M2release (hudson) plugin. This is a dream come true: perform a release on
a single push of a button (actually, more of a link).
Now, to do this without fiddling with the version number, I need to be able
to rely on conventions:
- releaseVersion is OK (defaults to ex. 1.0.0)
- developmentVersion is OK (defaults to ex. 1.0.1-SNAPSHOT)
- tagBase is OK (I can specify it directly in the POM)
The value causing me trouble is the release tag label. I would have liked to
have it this way:
project ...
version1.0.0-SNAPSHOT/version
...
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-release-plugin/artifactId
configuration
tagrelease-${pom.version}/tag
...
/project
But, this gives me a SCM tag with the '-SNAPSHOT' suffix. Not good. And I
don't want to explicitly mention the version in the Hudson job configuration.
Is there a way I can get the tag label to use the correct release version?
Thank you for your answers.
--
JS.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: maven in ecipse
What's meant by that is that Eclipse by default uses the same target
folder as if you have run Maven from command line. Some people hate it
but for others like me it makes all the sense. Just need to be aware
of consequences - say for example running mvn clean without refreshing
Eclipse.
Kalle
On Wed, Jan 27, 2010 at 1:30 AM, vijay shanker vijay.s...@gmail.com wrote:
Hi Adrian;
What is shared target folder folder. Can you describe it in details; I
have been using M2eclipse for last on years. But have not got this
term popped up to me
Regards,
Vijay Shanker Dubey
On Wed, Jan 27, 2010 at 1:29 PM, Adrian Shum tcs...@taifook.com wrote:
I gotta admit, m2eclipse works like a charm!
Except that you may need to be awared of the 'shared target folder'
issue.
--
Best Regards,
AdRiAN ShUM
-Original Message-
From: vijay shanker [mailto:vijay.s...@gmail.com]
Sent: Wednesday, January 27, 2010 3:45 PM
To: Maven Users List
Subject: Re: maven in ecipse
You should also try using eclipse plugin for maven
To name
- m2eclipse
Regards,
Vijay Shanker Dubey
On Wed, Jan 27, 2010 at 1:11 PM, Balazs Tothfalussy
balazs.tothfalu...@gmail.com wrote:
Hi Brian,
as I understand the problem, yes, you have to define a classpath
variable for this in Eclipse: Window\Preferences\Java\Build
Path\Classpath Variables
- the name of the variable should be M2_REPO and should point to the
Local
Maven Repository (not to the maven home) - by default it is at
${user.home}/.m2/repository.
Best regards,
Balazs
2010/1/27 brian brw...@gmail.com
Hi,
I have a project that I've loaded into eclipse.
Under windows, I already have M2_Home as env variable pointing to
project directory
Description Resource Path Location Type
Unbound classpath variable:
'M2_REPO/junit/junit/3.8.1/junit-3.8.1.jar'
in
project 'jung-api' jung-api Build path Build Path Problem
Do I need to set something in eclipse?
Thanks
Brian
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
This email is confidential. If you are not the intended recipient, please
delete it from your system and notify the sender immediately. Any
unauthorized use, disclosure, dissemination or copying of this email is
prohibited. Taifook Securities Group, its group companies and their content
providers (Parties) shall not be responsible for the accuracy or
completeness of this email or its attachment, if any, which could contain
virus, be corrupted, destroyed, incomplete, intercepted, lost or arrive
late. The Parties do not accept liability for any damage caused by this
email.
-
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: Code Coverage for integration tests
Definitely depends on your definitions for integration test and circumstances. We run our Spring context-based and other long-running tests via a special profile-activated surefire configuration together with plain unit tests to get accurate code coverage counts. Kalle On Wed, Jan 27, 2010 at 11:22 AM, Roland Asmann roland.asm...@adesso.at wrote: Depends on what you call 'integration test'... If it's a couple of tests inside a single module, just use cobertura/clover/something else... If you want an integration-test of several modules, try something like this (working on it myself, not finished, so no guarantees!): -- (the maven-invoker-plugin springs to mind for this) - trigger a new life-cycle for the modules you need, using a profile that packages the modules WITH the cobertura/clover/other classes, so the tests will be run with coverage-classes - have this life-cycle use a separate repository - run all your tests using the artifacts from aforementioned repository - have the cobertura/clover/other report the findings for you As I said, for me it's still a work-in-progress (although I've build 2 projects in a similar fashion, but I wasn't quite satisfied by the number of manual steps still involved), but it's a start... On 27-01-10 18:44, Wendy Smoak wrote: On Wed, Jan 27, 2010 at 10:07 AM, Douglas Ferguson doug...@douglasferguson.us wrote: Is there anyway to get code coverage numbers for integration tests? I'm sure it's technically possible, but as far as I know, no one has done it yet with Maven. It's definitely on my list of things I'd like to see! Let us know if you figure it out. :) -- Roland Asmann Senior Software Engineer adesso Austria Service GmbH Bäckerstrasse 1/2/7 T +43 1 5138877-27 A-1010 Wien F +43 1 5138862 E roland.asm...@adesso.at www.adesso.at - business. people. technology. - - 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 and AspectJ
If you really want to go against the grain you can always hack Maven as needed, but if you just refactored those into two different modules it'd be all much simpler. Kalle On Thu, Jan 14, 2010 at 10:45 AM, vishalmanohar vishalmano...@gmail.com wrote: Hi Kalle, What we need is to build 2 different artifacts, a JAR and a WAR file from the same source folder. The problem is that these artifacts are to be weaved with 2 different set of Aspects. Currently we have 2 profiles for building these artifacts which apply the Aspects on each as needed. But we would like to build these artifacts in a single maven execution. Thanks. Vishal kaosko wrote: Do you mean that you want to weave in compiled aspects to two different modules? If so, that's certainly possible. You are not using aspect terminology which makes it a bit difficult to understand what you actually want to achieve. But assuming I understood you correctly, you'd be using post-compile weaving and you could achieve this by configuring something like: configuration source1.6/source target1.6/target showWeaveInfotrue/showWeaveInfo aspectLibraries aspectLibrary groupIdcom.mycompany/groupId artifactIdmyaspectlib/artifactId /aspectLibrary /aspectLibraries weaveDependencies weaveDependency groupIdcom.mycompany/groupId artifactIdapplyaspectstothislib/artifactId /weaveDependency /weaveDependencies /configuration See http://mojo.codehaus.org/aspectj-maven-plugin/weaveJars.html. You also have the option of doing load-time weaving (see http://www.eclipse.org/aspectj/doc/released/devguide/ltw.html). Either way, if your IDE is Eclipse, it offers decent support for AOP (unsurprisingly since aspectj is their project). You would need to refactor the aspects to a separate module then configure the aspect compiler for the two target modules and make sure that the weaved-in classes are packaged up properly (assuming you use compile-time weaving). Kalle On Tue, Jan 12, 2010 at 2:47 PM, Wendy Smoak wsm...@gmail.com wrote: A project team has a set of classes that need to be instrumented two different ways with AspectJ, one to work within a webapp and the second to work standalone. The classes are kept inside the webapp module, so processing them during the build to produce the war works okay. What's the best way to instrument these same classes the _other_ way for the standalone jar? I've suggested establishing separate modules for the 'different' jars and possibly putting the shared code in a third module, but they say it's not possible, and I don't have enough experience with AspectJ to argue the point. I agree it would probably complicate building in the IDE. At the moment they're doing it with profiles, and executing Maven twice to produce the different artifacts. Any suggestions? -- Wendy - 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 -- View this message in context: http://n2.nabble.com/Maven-and-AspectJ-tp4295057p4394544.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven and AspectJ
On Thu, Jan 14, 2010 at 11:19 AM, Wendy Smoak wsm...@gmail.com wrote: On Thu, Jan 14, 2010 at 11:56 AM, Kalle Korhonen kalle.o.korho...@gmail.com wrote: If you really want to go against the grain you can always hack Maven as needed, but if you just refactored those into two different modules it'd be all much simpler. By two different modules, do you mean the jar and war? We'd still have the problem of needing to process the same code two different ways: once for inclusion in the webapp, and once to make the standalone jar. As I mentioned before, I'd put the aspects into yet another module. Kalle - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven and AspectJ
Do you mean that you want to weave in compiled aspects to two different modules? If so, that's certainly possible. You are not using aspect terminology which makes it a bit difficult to understand what you actually want to achieve. But assuming I understood you correctly, you'd be using post-compile weaving and you could achieve this by configuring something like: configuration source1.6/source target1.6/target showWeaveInfotrue/showWeaveInfo aspectLibraries aspectLibrary groupIdcom.mycompany/groupId artifactIdmyaspectlib/artifactId /aspectLibrary /aspectLibraries weaveDependencies weaveDependency groupIdcom.mycompany/groupId artifactIdapplyaspectstothislib/artifactId /weaveDependency /weaveDependencies /configuration See http://mojo.codehaus.org/aspectj-maven-plugin/weaveJars.html. You also have the option of doing load-time weaving (see http://www.eclipse.org/aspectj/doc/released/devguide/ltw.html). Either way, if your IDE is Eclipse, it offers decent support for AOP (unsurprisingly since aspectj is their project). You would need to refactor the aspects to a separate module then configure the aspect compiler for the two target modules and make sure that the weaved-in classes are packaged up properly (assuming you use compile-time weaving). Kalle On Tue, Jan 12, 2010 at 2:47 PM, Wendy Smoak wsm...@gmail.com wrote: A project team has a set of classes that need to be instrumented two different ways with AspectJ, one to work within a webapp and the second to work standalone. The classes are kept inside the webapp module, so processing them during the build to produce the war works okay. What's the best way to instrument these same classes the _other_ way for the standalone jar? I've suggested establishing separate modules for the 'different' jars and possibly putting the shared code in a third module, but they say it's not possible, and I don't have enough experience with AspectJ to argue the point. I agree it would probably complicate building in the IDE. At the moment they're doing it with profiles, and executing Maven twice to produce the different artifacts. Any suggestions? -- Wendy - 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: Deploying application in a tomcat
http://cargo.codehaus.org/Maven2+plugin Kalle On Thu, Dec 10, 2009 at 8:53 PM, vijay shanker vijay.s...@gmail.com wrote: Hi All, I am planning to use maven to deploy my application in tomcat. My requirement is to deploy on a remote instance of tomcat. Can any one got some pointer/links to start with. Regards, Vijay Shanker Dubey - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: dumb quetsion . . .
There cannot be a single answer to this since applications, application packages and use cases are different. If you are building webapplications and updating your own site, Maven cargo plugin is very effective (google this list for examples, lots of them). If you are developing a client-side application, you want to probably package everything up into a single file (zip, exe, installer package etc.) and make it available to your customers one way or another. In one instance, I used the assembly plugin and deployed that assembly together with Maven site and linked to the file from the index page. Kalle On Mon, Dec 7, 2009 at 10:43 AM, ChadDavis chadmichaelda...@gmail.com wrote: I'm been starting to use Maven for some of my projects. One thing that I've not been able to clear up is how the dependencies get deployed to my deployment environment. For development, I sometimes use the assembly plugin's ability to generate a single Jar with all dependencies included, or I use the jetty plugin to run web apps, and this knows about all of the maven managed dependencies inherently. But what is the best way to deploy and run my app in a production setting? - 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 Install on Mac OS X
I've seen a similar case at work where Internet access is through a proxy. Configuring proxy incorrectly lead to Proxy: not authorized messages and corresponding files stored in local repo. Needless to say, Maven got all confused about it. Kalle On Sun, Dec 6, 2009 at 5:31 AM, Wayne Fay wayne...@gmail.com wrote: read. but, there is one strange thing I noticed. Along with jaxb-api-2.1.jar, there is a corresponding .pom file and both these files have same size 357. huh? Next time, cat the files (or edit them, whatever, just open in text editor) and see what they look like. The JAR file should be binary with a few obvious strings in it, and the pom file should be XML. I would have been interested to know what was in those 357 bytes on your disk -- was the jar a copy of the pom, were both corrupted due to being downloaded from a bad repo, or something else altogether... 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: What is the 'Maven way' to handle multi-artifact code generation from a single model source?
I wouldn't worry *too much* about the true and righteous way. While I agree that the more modular approach is more proper and allows for more flexibility, as with anything else, you need to strike a balance with building for future and practicality. With multiple modules, there comes additional complexity (that Maven arguably handles well) but if you never need the additional flexibility, then it's unnecessary. Regarding classifiers, I think they are fine if you always use them together (say same swf always goes with the same jar). I do completely agree with Maven's one primary artifact per module but depending on your case, the swf could be seen and treated as a secondary artifact, especially if you couldn't even test them separately. If you need to mix and match, perhaps have different release cycles for the swf and the jar, multiple modules is certainly better. Kalle On Wed, Dec 2, 2009 at 11:42 PM, Anders Hammar and...@hammar.net wrote: I'd like to stress that Jesse explains the true Maven way. This is how this should be done if you want to enjoy simple and correct dependency management through Maven. Using classifiers will make your two (for instance) artifacts have the same dependencies. As I've stated before, classifiers are most often NOT the way to go IMO. /Anders On Wed, Dec 2, 2009 at 22:40, Jesse Farinacci jie...@gmail.com wrote: Hi KJ, On Wed, Dec 2, 2009 at 3:19 PM, K J gomm...@gmail.com wrote: Does anyone have any examples or tips about how to handle the generation of multiple artifacts based on a shared model? For example, I have a project which needs to produce both Java and ActionScript code based on a shared UML model. I'm having trouble figuring out how to best setup and manage these types of projects, so that a change to the source project can easily result in the build of all the various generated outputs. Thanks in advance for the help. To go the real Maven way, I think that I'd probably put the shared model data (perhaps some sort of XML?) into a Maven module. Then I'd have more Maven modules for Java and ActionScript, each, that would depend on the model data module. They would use it as a dependency and then generate their source codes accordingly. -jesse - 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 parameter
+ any plugin should publish their plugin documentation, e.g. http://maven.apache.org/plugins/maven-install-plugin/plugin-info.html. Once you know which plugin you want to use, it's almost trivial. Kalle On Thu, Dec 3, 2009 at 10:41 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: these properties are used by plugins. first you need to find what plugins are bound to your project lifecycle then you need to find what goals are used for each plugin then you need to look at the params available for each goal the maven-help-plugin may be able to help you Sent from my [rhymes with tryPod] ;-) On 4 Dec 2009, at 06:31, maven apache apachemav...@gmail.com wrote: Hi: Some maven command like mvn install -Dmaven.test.skip=true have some parameters(here is the maven.test.skip),I want to know which parameter I can use? I mean how do I know there is a parameter I can use? Is there a document ? - 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: What is the 'Maven way' to handle multi-artifact code generation from a single model source?
Since the build artifacts are output of the same source, they should part of the same module. Use classifiers to specify the different artifacts. If you are using custom scripts to produce the output (i.e. not plugins that attach additional artifacts automatically), use buildhelper plugin to attach them (and specify the classifiers) see http://mojo.codehaus.org/build-helper-maven-plugin/usage.html. The actionscript code should be packaged up to produce a single artifact (zip it up if a specific packaging format like swf won't do). Kalle On Wed, Dec 2, 2009 at 12:19 PM, K J gomm...@gmail.com wrote: Does anyone have any examples or tips about how to handle the generation of multiple artifacts based on a shared model? For example, I have a project which needs to produce both Java and ActionScript code based on a shared UML model. I'm having trouble figuring out how to best setup and manage these types of projects, so that a change to the source project can easily result in the build of all the various generated outputs. Thanks in advance for the help. - 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: Deploy unpack artifact to remote target
At least my experience has been that distributing your app to a target system (as opposed to deploying to a standard repo) varies enough on case by case basis that a standard plugin typically cannot offer enough options for customizing the behavior (unless it's a webapp in which case cargo is sufficient). I've successfully used ant scripts plugged into my Maven build (via antrun in a profile) for distribution. Kalle On Fri, Nov 27, 2009 at 8:34 AM, Arnaud Bailly abai...@oqube.com wrote: That's what I was afraid of :-( Not that the plugin would be very complex... Thanks for the answer Arnaud BRIAN FOX-5 wrote: The stage plugin does something similar but it requires scp/ssh to do it. You will have to create your own plugin to do this, I'm not aware of one that does exactly as you need. On Fri, Nov 27, 2009 at 8:58 AM, Arnaud Bailly abai...@oqube.com wrote: Hello, I would like to deploy an artifact to some remote site, maybe using standard deploy plugin to do that, then unpack the artifact at its target site. Is it possible to do that using only plugins? I know how to deploy, I know how to unpack, then I would like to merge the two behaviors, without resorting to writing a plugin. Thanks in advance for your help, Arnaud Bailly -- View this message in context: http://old.nabble.com/Deploy---unpack-artifact-to-remote-target-tp26542731p26542731.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- View this message in context: http://old.nabble.com/Deploy---unpack-artifact-to-remote-target-tp26542731p26544766.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to use a jar as test resource
Make it a (test) dependency of your project, use dependency:copy to copy the jar to a location of choice (see http://maven.apache.org/plugins/maven-dependency-plugin/examples/copying-artifacts.html) before the test phase is executed. Kalle On Fri, Nov 27, 2009 at 2:04 AM, TorstenKarusseit ad...@pilot-blankenfelde.de wrote: I have a unit test which uses a external jar. This jar is executed in a separate vm by the unit test. In eclipse I've to manually build and export the jar into a defined location. Then the unit test with hard-coding this location starts a separate vm and performs it's tests. Now, how to do that with maven ? My guesses: 1. include dependency to the generating pom of that external jar to the project pom 2. include testResource (to testResources) to buid, but how ? It has to download the jar from local repo into the defined location and if not there build it and install it to the location. Any help ? -- View this message in context: http://old.nabble.com/How-to-use-a-jar-as-test-resource-tp26540212p26540212.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-changes-plugin: automatic update for release?
Changes plugin offers Jira and Trac integration. You can filter your changes.xml if you cannot use current version only. Use ci system to run the site and changes report so you know if it'll work or not before the release. Kalle On Wed, Nov 18, 2009 at 12:56 PM, David C. Hicks dhi...@i-hicks.org wrote: Hi folks, I'm using the Changes plugin to both produce a report for my Site and to distribute email announcements of changes. The problem is that if we're not careful to remember to update the changes.xml file itself, then our release build fails because it doesn't find a change set with the right version. I'd really like to find some way to automatically update the changes.xml file during the release build process. Can anyone recommend a plugin that might let me make modifications to this xml file at build time? Or, any other suggestions? Thanks, Dave - 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-changes-plugin: automatic update for release?
On Wed, Nov 18, 2009 at 1:46 PM, David C. Hicks dhi...@i-hicks.org wrote: Of course...the build will break after a release because the new changes.xml won't have a section for the new release version. Come to think of it, will that even work? Since the CI sees a SNAPSHOT version, and the changes.xml doesn't include SNAPSHOT. Depending on which integration you use. Will work at least for jira, read the docs at http://maven.apache.org/plugins/maven-changes-plugin/examples/customizing-jira-report.html Kalle PS. Off-topic but make dependencies report go faster: plugin artifactIdmaven-project-info-reports-plugin/artifactId version2.1/version configuration dependencyLocationsEnabledfalse/dependencyLocationsEnabled /configuration /plugin Maybe even dependencyDetailsEnabled to false if you so wish. David C. Hicks wrote: Good suggestion. I hadn't really thought of using CI to test the changes.xml. That's primarily because I also have the dependencies report generated as part of the Site generation. Under normal circumstances, it takes forever and a day to generate the dependencies report, since it appears to hit the Internet to find all the dependencies, instead of using the local repository. I suppose I can restructure my CI build to exclude the dependencies report and get some useful information about the changes report. Thanks! Kalle Korhonen wrote: Changes plugin offers Jira and Trac integration. You can filter your changes.xml if you cannot use current version only. Use ci system to run the site and changes report so you know if it'll work or not before the release. Kalle On Wed, Nov 18, 2009 at 12:56 PM, David C. Hicks dhi...@i-hicks.org wrote: Hi folks, I'm using the Changes plugin to both produce a report for my Site and to distribute email announcements of changes. The problem is that if we're not careful to remember to update the changes.xml file itself, then our release build fails because it doesn't find a change set with the right version. I'd really like to find some way to automatically update the changes.xml file during the release build process. Can anyone recommend a plugin that might let me make modifications to this xml file at build time? Or, any other suggestions? Thanks, Dave - 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: Best practice for declaring repos in open source projects
Sure, I agree with both of you that there are conflicts in the various repos, but neither of you gave any suggestions/answers for my practical question. Brian others, do you think its better to keep the extra repos in a profile, always use them if build requires some dependencies from the extra repos or insist that users manually resolve the missing dependencies (by running their own proxy and configuring it correctly)? See the second paragraph below. Kalle On Mon, Nov 16, 2009 at 1:39 AM, Jörg Schaible joerg.schai...@gmx.de wrote: Stephen Connolly wrote at Montag, 16. November 2009 09:41: 2009/11/16 Kalle Korhonen kalle.o.korho...@gmail.com: There's been quite a few threads on declaring Maven repos in poms, most of them referring to Brian's blog post http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/. I agree with that 100%, but as you mention Brian, it's not black and white for open source projects. I ran into the same issue again while working on http://bamboo.ci.codehaus.org/browse/TYNAMO-SEEDENTITY-1. The module depends on some artifacts located in Jboss repo. Their repo is not synched to repo1 but artifacts originating from JBoss may or may not be deployed to repo1 depending on version and project. I'm naturally running my own nexus instance for my team's needs but anybody else just checking out the module from svn or a CI system that I'm not in control of (as in this case, it's Codehaus Bamboo instance) will have a problem building this module. To avoid burning the entries forever into my released POMs I figured I could just the declare the repositories in a profile, for example named repositories. Technically they would still be in the pom but wouldn't be used in normal dependency resolution, only if the user specifically activated it. Since I typically never depend on external snapshots, the profile would only be needed roughly once per set-up, and it would also be easy to document and users to use. Brian, others, do you think this would be a good idea for best practice? Better than declaring them by default or not declaring them at all (and thus either trying to strictly use only modules available in repo1, lobbying required libs to be deployed to repo1 or just having to document this for users and lobbying CI administrators to proxy additional Maven repos)? The issue is that some repositories have different versions of artifacts deployed for the same version number. If you download the artifact from repoA it will never be re-downloaded even if repoA is no longer in your list of repositories and repoB has a different binary. This is especially an issue with java.net, but other (non repo1.maven.org) repositories have the same issue. Especially the jboss repos have this issue also, because - as I understood - they build all artifacts themselves from the source i.e. they also publish a lot of stuff not directly originating from them and that is also available in central. While they *should* produce the same things, you actually can never be sure. [snip] - Jörg - 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
Best practice for declaring repos in open source projects
There's been quite a few threads on declaring Maven repos in poms, most of them referring to Brian's blog post http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/. I agree with that 100%, but as you mention Brian, it's not black and white for open source projects. I ran into the same issue again while working on http://bamboo.ci.codehaus.org/browse/TYNAMO-SEEDENTITY-1. The module depends on some artifacts located in Jboss repo. Their repo is not synched to repo1 but artifacts originating from JBoss may or may not be deployed to repo1 depending on version and project. I'm naturally running my own nexus instance for my team's needs but anybody else just checking out the module from svn or a CI system that I'm not in control of (as in this case, it's Codehaus Bamboo instance) will have a problem building this module. To avoid burning the entries forever into my released POMs I figured I could just the declare the repositories in a profile, for example named repositories. Technically they would still be in the pom but wouldn't be used in normal dependency resolution, only if the user specifically activated it. Since I typically never depend on external snapshots, the profile would only be needed roughly once per set-up, and it would also be easy to document and users to use. Brian, others, do you think this would be a good idea for best practice? Better than declaring them by default or not declaring them at all (and thus either trying to strictly use only modules available in repo1, lobbying required libs to be deployed to repo1 or just having to document this for users and lobbying CI administrators to proxy additional Maven repos)? Kalle - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Snapshot Deployment Best Practices
Also, avoid deploying snapshots if nothing's changes. This is easier to accomplish if you have a truly modular build with sub-modules following their independent release cycles rather than a one monolithic multi-module buid. It'll certainly work if you always deploy everything just in case, but especially if your modules are big, you and all your devs end up spending extra unnecessary seconds every day downloading the dependencies even if they haven't changed. Kalle On Fri, Nov 13, 2009 at 9:57 AM, Todd Thiessen thies...@nortel.com wrote: Nexus has a Purge Snapshots job you can schedule. It is pretty flexible. You can decide how many snapshots you wish to keep around. Ideally, you should normally only need the latest, but on the rare occasion you may want to point to an older one. In our environment, the job runs every night and only leaves the last 2 snapshots. Although we are now considering only keeping the latest since I don't think anyone has ever wanted to point to the second latest. --- Todd Thiessen -Original Message- From: Neil Chaudhuri [mailto:nchaudh...@potomacfusion.com] Sent: Friday, November 13, 2009 12:21 PM To: users@maven.apache.org Subject: Snapshot Deployment Best Practices I have figured out how to deploy all my artifacts to my local Nexus repository, and I have even set up my CI tool (TeamCity in my case) to deploy the snapshot artifacts every night. Because I am not at the release stage yet, I have just been deploying snapshot after snapshot. This means that my snapshot page on Nexus for this artifact is getting loaded with entries down the page. My questions relate to the best practices associated with this sort of practice: *Is it OK and desirable to build up artifacts between releases? *If not, is there a way to replace the previous snapshot artifacts with the latest ones? *Are there any steps I am missing? Thanks for your insight. - 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: development methodology
That's the right process, and no, the process itself is not overkill but you need to decide what is the right level between better traceability and release overhead for you. Obviously your process was a lot simpler with Ant because you never/rarely tagged and released your code. If you found an issue, you always went forward, scrambling to fix an issue as quickly as possible. That's certainly agile but unpredictable and with Maven you get more. If you find an issue with a new release, you may have an option to go back to the previous release, thus giving time for your development team to come up with a new release with a proper fix included. Typically though, you don't want to release every little change in your libs.jar separately. If your webapplication still works with an older version of the libs.jar, you stay on that version until you decide to to move the next version (which could have been released way ahead). The release process is supposed to give you better predictability - for example you can have an actual roadmap (these and these features will be implemented in these versions) with expected release dates. It all depends on your needs. If you think you never want to go back to an older released version, there's no point releasing the library jars. You could keep it all in one multi-module build but the issue there probably is that people working on signup webapplication probably don't want to build shop. You can also just keep using snapshots until one of the web projects need to release (or never release if you never need to). I assume you are using the release plugin, in which case your trunk/branch versions for any given module should be a snapshot (it's prepared for development of that version whether or not you are actively working on it). In addition to using release plugin, using versions plugin ( http://mojo.codehaus.org/versions-maven-plugin/) can greatly ease the burden of maintaining the version dependencies. You can for example eagerly update specific dependencies to latest release versions (e.g. versions:use-latest-releaseshttp://mojo.codehaus.org/versions-maven-plugin/use-latest-releases-mojo.html versions:commithttp://mojo.codehaus.org/versions-maven-plugin/commit-mojo.html) and set up a Hudson job just for that. Overall, release process can be taxing to set up for the first time but typically pays dividends later. And whenever you feel you have manual overhead, you should try automate it and minimize the time to make a new release (for example: do you need javadocs, sources, dependency reports when releasing - if not, turn them off). Kalle On Tue, Nov 10, 2009 at 9:53 AM, Eric Moore emo...@nuskin.com wrote: Our development team recently mavenized a couple of our web applications. We are struggling a bit with the new development methodology. A brief description of our artifacts and our setup: We have 2 web applications: shop signup. These 2 web applications are both dependant on 2 jars: content.jar libs.jar. We use IntelliJ for our IDE and Hudson for a CI/build server. Now for our ‘process’: - Suppose we add some new functionality to our libs.jar. We increment the version, let’s say from 1.0.0 to 1.0.1. - Now we release libs version 1.0.1 - Now we update the shop signup web apps to be dependant on libs 1.0.1. And we release both of them - Now QA finds a bug in the libs. - Change the libs.jar pom to be 1.0-SNAPSHOT, indicating development. - The developers change shop signup poms to be dependant on libs 1.0-SNAPSHOT - Develop the fix - Now we increment libs.jar to version 1.0.2 - Update shop signup web apps to be dependant on 1.0.2. Release. - Another bug is found… - Change the libs.jar pom to be 1.0-SNAPSHOT, indicating development - The developers change shop signup poms to be dependant on libs 1.0-SNAPSHOT - Develop the fix… - And so on Now for the question: For a simple setup like this, is Maven overkill? Our development process was quite a bit simpler when we were using ANT and didn’t worry about the versions. Before, everyone just updated from subversion and got the latest code and there was no worrying about updating our pom files with each test/release cycle. We’ve gone the maven route and would like to stick with it. Could anyone comment on our process and maybe point out some ways to improve this constant pom updating? Thanks, Eric
Re: installing src or javadoc into local repository
mvn eclipse:eclipse -DdownloadSources=true -DdownloadJavadocs=true http://maven.apache.org/plugins/maven-eclipse-plugin/examples/attach-library-sources.html Kalle On Tue, Oct 20, 2009 at 8:16 PM, jpswain jpsw...@gmail.com wrote: I looked at the link but I still have these questions: Is there any sane way to simply tell maven, download and install src javadoc for all artifacts in local repository? If not is their at least a way to say, install this jar with javadoc src, AND ALSO the javadoc src of all its transitive dependencies? I'm having a heck of a time with this! Thanks, Jamie Sean Davis-5 wrote: On Fri, Oct 2, 2009 at 8:35 PM, Roland Asmann roland.asm...@cfc.at wrote: Check the install-mojo for this: http://maven.apache.org/plugins/maven-install-plugin/install-file-mojo.html Reinstall the jar into your repository and add the 'javadoc' and 'sources' switches or install them separately with the 'classifier' switch. Thanks, Roland. That is exactly what I needed. I apologize for the naive question in advance. I have installed an external jar file into my local repository--very easy. The jar file was built using ant as part of a third-party project. I would now like to add the source and/or the javadocs to my local repository, also. I have the source (in src/java/) and can generate the javadoc. How can I install these files into my local repository (so that I have the equivalent of the download sources and javadocs)? Thanks, Sean - 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 -- View this message in context: http://www.nabble.com/installing-src-or-javadoc-into-local-repository-tp25724190p25985910.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
