RE: PomStrap v2?
Yes. It's very neat and work perfectly. Notice that not all configuration options are documented on the site. Look in the source code for more options. Gert. -Original Message- From: Wayne Fay [mailto:wayne...@gmail.com] Sent: 24 September 2010 19:17 To: Maven Users List Subject: PomStrap v2? Anyone here using PomStrap? I especially like the Tomcat loader option, but haven't used it yet, just ran across it last night... http://pomstrap.jfluid.com/ PomStrap is a hierarchical Class-Loader based on the Maven's artifact repository model. In a nutshell, it provides a runtime feature to Maven. Maven manages the build of software modules, their documentation, their reporting and the rationalized deployment and storage of the resulting software artifacts. PomStrap is capable - in its simplest form - of loading classes from software artifacts deployed to a Maven repository. It can run embedded within any Java environment that allows the use of custom class-loaders or as primary bootstrap mechanism to run applications ranging from simple command-line applications to complex dynamic enterprise applications. PomStrap can be configured to access software artifacts from a remote Maven repository via HTTP. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Please help Logica to respect the environment by not printing this email / Pour contribuer comme Logica au respect de l'environnement, merci de ne pas imprimer ce mail / Bitte drucken Sie diese Nachricht nicht aus und helfen Sie so Logica dabei, die Umwelt zu sch�tzen. / Por favor ajude a Logica a respeitar o ambiente nao imprimindo este correio electronico. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Re: how to centralize configuration accross multiple modules
On Tue, Oct 5, 2010 at 2:50 PM, emerson wrote: > Hi >... > I would like then to pass a parameter to the mvn command (eg. mvn -Denv=st1) > and it would pick up the appropriate resource file depending on the > environment. > Hi, I don't know whether it is what you want, but configureme supports exactly this kind of configuration: define different, cascading realms, provide the realm you are in as startparameter and the framework decides which value is the proper one in current environment. http://infra.anotheria.net/confluence/display/CONFIGUREME/GettingStarted http://www.configureme.org regards Leon - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Early Bird ends this Friday: Maven Training @ ApacheCon Atlanta
Hi all, A brief reminder that ApacheCon is coming up fast (Nov 1 - 5)! There's still time to register for the early bird rates. Of interest to this group, the following 1-day Maven training is scheduled: Apache Maven: Effective Implementation (http://na.apachecon.com/c/acna2010/sessions/628) Registration: http://guest.cvent.com/d/sdqfjv There is usually also a Maven Meetup scheduled on one of the nights, with several Maven developers in attendance. In addition to the training and BarCamp, the conference has tracks that include NoSQL, Content Technology, Hadoop, Tomcat, Lucene, OSGi, Java Enterprise Development, Business & Community. Hope to see you there! Cheers, 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
maven-site-plugin no longer multi-module?
I am trying to get our build system moved over from maven 2.0.8 to
2.2.1, but we have been having problems with the site plugin. While
converting over, I am supporting a profile that changes the plugin
version. Here is the setup:
...
2.0.1
...
...
org.apache.maven.plugins
maven-site-plugin
${maven.site.plugin.version}
commons-httpclient
commons-httpclient
3.1
commons-logging
commons-logging
...
...
siteFix
false
2.1.1
...
When I execute "mvn site" from the top level pom directory in maven
2.0.8, it builds the site for the top directory and all of the
modules. If I execute "mvn -PsiteFix site" from maven 2.2.1, it does
not build the modules and only builds the site for the current
directory.
Is there a way to get this to function as it did before?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Continuous Build always building against the latest SNAPSHOT version
On 05/10/2010 4:27 PM, Mike Lenner wrote: You just need to bump the dep version in project-2. What about the use case where developers on project-2 don't even know that project-1 has been released? All they know is the next time they check in code to shared-util and check in code to use that in project-2, their CI build breaks. People who check in code without looking at the error messages about conflicts in source version control will get you into all kinds of trouble. If they checked out version 1.0-SNAPSHOT and are checking into version 1.1 releases without seeing that someone else has written conflicting interfaces and classes, that is the problem to tackle. Perhaps shared-util is too big and is more unstable than it should be. We went through this and have refactored our shared libraries to create a better set of functionally organized libraries that are more stable. It also makes it much more obvious that a library will have to change during a development cycle so that everyone anticipates the changes. We have a set of aggregator POMs that are used to build composite jars so that the set of "official" libraries can be referenced without having to know the version of all of the component libraries. Ron Maybe part of the release process of shared-util should be to update some parent pom's dependencyManagement section to the 1.1-SNAPSHOT? On Tue, Oct 5, 2010 at 4:10 PM, Anders Hammar wrote: I don't see that you're doing anything wrong. You just need to bump the dep version in project-2. Or, I guess, you could use version ranges but I'm kind of allergic to them so I'd suggest stay off that path. /Anders On Tue, Oct 5, 2010 at 22:05, Mike Lenner wrote: Any help would be greatly appreciated - I'm trying to figure out how to do this the maven way. I have a shared dependency called shared-util. My team frequently makes changes to our deployable projects along with changes to the shared-util. So, in my continuous build, I'd like each of our projects always building against the latest shared-util. Seems like a perfect situation for a SNAPSHOT dependency. So, project-1 and project-2 each depend on 1.0-SNAPSHOT of shared-util. Continuous Build deploys the current 1.0-SNAPSHOT to our repo after each code commit, and project-1 and project-2 build fine. But then we release project-1. We don't want to do so with SNAPSHOT dependencies, so we release shared-util as well. The maven release plugin updates shared-util to 1.1-SNAPSHOT after the release (as well as project-1's dependency). But now project-2, still dependent on 1.0-SNAPSHOT, is no longer building against the latest shared-util. Future commits to shared-util will not be built against in our Continuous Build for project-2 because project-2 is dependent on a "dead" snapshot. What am I missing / doing wrong here? Seems like snapshots were made for this use case. Thanks, Mike - 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: Continuous Build always building against the latest SNAPSHOT version
what i've done before is use the versions:use-latest-versions goal in an initial maven invocation and then follow up with clean verify and finally a versions:rollback so that the next svn update does not get borked. I'd typically have a couple of jobs on the CI server, one building exactly what is in scm, one building with the latest releases and one building with the very latest. If using hudson, you will have to use a freestyle project (which is IMHO the only way to build maven projects in hudson) and have three maven build steps... versions-maven-plugin modifies the pom and so you need to start a new maven process to see the effects -Stephen On 5 October 2010 21:41, Wendy Smoak wrote: > On Tue, Oct 5, 2010 at 4:27 PM, Mike Lenner wrote: > >> Maybe part of the release process of shared-util should be to update >> some parent pom's dependencyManagement section to the 1.1-SNAPSHOT? > > Or send out a release announcement to their users list, which > project-2's developers should be on? :) > > I believe the versions plugin has a goal that checks for newer > releases of your dependencies, that might be useful. > http://mojo.codehaus.org/versions-maven-plugin/ > > And some of the repository managers (Archiva at least) have feeds you > can watch for updates on artifacts. > > -- > 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: Continuous Build always building against the latest SNAPSHOT version
Why would that break the CI build? It should break in your own environment as soon as you try and use it in project-2. Well before the CI build. This will tell you that project-2 needs to point to the 1.1-SNAPSHOT version of shared-util. What you are doing sounds fine to me. Project-2 need not even know about the released version of shared-util. If project-2 never requires any additionaly functionality from shared-util, it can go happily along its merry way and not even worry about upgrading to the latest version of shared-util. Once project-2 releases, you'd then notice that shared-util has already been released and need only point to the released version of shared-util. The thing you have to be careful of is making non-backwards compatible changes. When you have a shared library like this, be extra careful that once you release something that you don't get rid of any functionality it provides. Or change the name of any public classes/methods. Especially if there are others using that jar that you may not be aware of. An adage of Josua-Bloc comes to mind when designing a shared API like this: when in doubt, leave it out. Make as many of your classes package private that you can. Anyway, I am starting to ramble ;-). > -Original Message- > From: Mike Lenner [mailto:mike.len...@gmail.com] > Sent: Tuesday, October 05, 2010 4:28 PM > To: Maven Users List > Subject: Re: Continuous Build always building against the latest SNAPSHOT > version > > > You just need to bump the dep > > version in project-2. > > What about the use case where developers on project-2 don't even know > that project-1 has been released? All they know is the next time they > check in code to shared-util and check in code to use that in > project-2, their CI build breaks. > > Maybe part of the release process of shared-util should be to update > some parent pom's dependencyManagement section to the 1.1-SNAPSHOT? > > On Tue, Oct 5, 2010 at 4:10 PM, Anders Hammar wrote: > > I don't see that you're doing anything wrong. You just need to bump the > dep > > version in project-2. Or, I guess, you could use version ranges but I'm > kind > > of allergic to them so I'd suggest stay off that path. > > > > /Anders > > On Tue, Oct 5, 2010 at 22:05, Mike Lenner > wrote: > > > >> Any help would be greatly appreciated - I'm trying to figure out how > >> to do this the maven way. > >> > >> I have a shared dependency called shared-util. My team frequently > >> makes changes to our deployable projects along with changes to the > >> shared-util. So, in my continuous build, I'd like each of our > >> projects always building against the latest shared-util. > >> > >> Seems like a perfect situation for a SNAPSHOT dependency. So, > >> project-1 and project-2 each depend on 1.0-SNAPSHOT of shared-util. > >> Continuous Build deploys the current 1.0-SNAPSHOT to our repo after > >> each code commit, and project-1 and project-2 build fine. > >> > >> But then we release project-1. We don't want to do so with SNAPSHOT > >> dependencies, so we release shared-util as well. The maven release > >> plugin updates shared-util to 1.1-SNAPSHOT after the release (as well > >> as project-1's dependency). > >> > >> But now project-2, still dependent on 1.0-SNAPSHOT, is no longer > >> building against the latest shared-util. Future commits to > >> shared-util will not be built against in our Continuous Build for > >> project-2 because project-2 is dependent on a "dead" snapshot. > >> > >> What am I missing / doing wrong here? Seems like snapshots were made > >> for this use case. > >> > >> Thanks, > >> Mike > >> > >> - > >> 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: Continuous Build always building against the latest SNAPSHOT version
On Tue, Oct 5, 2010 at 4:27 PM, Mike Lenner wrote: > Maybe part of the release process of shared-util should be to update > some parent pom's dependencyManagement section to the 1.1-SNAPSHOT? Or send out a release announcement to their users list, which project-2's developers should be on? :) I believe the versions plugin has a goal that checks for newer releases of your dependencies, that might be useful. http://mojo.codehaus.org/versions-maven-plugin/ And some of the repository managers (Archiva at least) have feeds you can watch for updates on artifacts. -- Wendy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: how to centralize configuration accross multiple modules
On Tue, Oct 5, 2010 at 1:07 PM, Anders Hammar wrote: > Yes, but the problem is the "we did this with Ant" mentality... > Yep I suspect thats causing me a lot of problems here -- which is why im asking for suggestions on how else to accomplish the same thing. Most of our binaries are already setup to use external config files. But part of the build (filtered resources) is to generate said external config files. But then some of the binary artifacts have environment specific values in them: --ear file for j2ee deployment has libraryPath defined. --rar file for j2ee deployment has user/password values To be able to run 1 build and generate stuff for all 7 of our environments at the same time would be a serious boon to getting my company to switch to maven. but asking/requiring a major re-architecting of the existing setup and coding will guarantee its not going to happen -- something i dont want to see. But re-arranging/re-formatting config files, or putting the values in different places is no big deal.
Re: Continuous Build always building against the latest SNAPSHOT version
> You just need to bump the dep > version in project-2. What about the use case where developers on project-2 don't even know that project-1 has been released? All they know is the next time they check in code to shared-util and check in code to use that in project-2, their CI build breaks. Maybe part of the release process of shared-util should be to update some parent pom's dependencyManagement section to the 1.1-SNAPSHOT? On Tue, Oct 5, 2010 at 4:10 PM, Anders Hammar wrote: > I don't see that you're doing anything wrong. You just need to bump the dep > version in project-2. Or, I guess, you could use version ranges but I'm kind > of allergic to them so I'd suggest stay off that path. > > /Anders > On Tue, Oct 5, 2010 at 22:05, Mike Lenner wrote: > >> Any help would be greatly appreciated - I'm trying to figure out how >> to do this the maven way. >> >> I have a shared dependency called shared-util. My team frequently >> makes changes to our deployable projects along with changes to the >> shared-util. So, in my continuous build, I'd like each of our >> projects always building against the latest shared-util. >> >> Seems like a perfect situation for a SNAPSHOT dependency. So, >> project-1 and project-2 each depend on 1.0-SNAPSHOT of shared-util. >> Continuous Build deploys the current 1.0-SNAPSHOT to our repo after >> each code commit, and project-1 and project-2 build fine. >> >> But then we release project-1. We don't want to do so with SNAPSHOT >> dependencies, so we release shared-util as well. The maven release >> plugin updates shared-util to 1.1-SNAPSHOT after the release (as well >> as project-1's dependency). >> >> But now project-2, still dependent on 1.0-SNAPSHOT, is no longer >> building against the latest shared-util. Future commits to >> shared-util will not be built against in our Continuous Build for >> project-2 because project-2 is dependent on a "dead" snapshot. >> >> What am I missing / doing wrong here? Seems like snapshots were made >> for this use case. >> >> Thanks, >> Mike >> >> - >> 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: Continuous Build always building against the latest SNAPSHOT version
I don't see that you're doing anything wrong. You just need to bump the dep version in project-2. Or, I guess, you could use version ranges but I'm kind of allergic to them so I'd suggest stay off that path. /Anders On Tue, Oct 5, 2010 at 22:05, Mike Lenner wrote: > Any help would be greatly appreciated - I'm trying to figure out how > to do this the maven way. > > I have a shared dependency called shared-util. My team frequently > makes changes to our deployable projects along with changes to the > shared-util. So, in my continuous build, I'd like each of our > projects always building against the latest shared-util. > > Seems like a perfect situation for a SNAPSHOT dependency. So, > project-1 and project-2 each depend on 1.0-SNAPSHOT of shared-util. > Continuous Build deploys the current 1.0-SNAPSHOT to our repo after > each code commit, and project-1 and project-2 build fine. > > But then we release project-1. We don't want to do so with SNAPSHOT > dependencies, so we release shared-util as well. The maven release > plugin updates shared-util to 1.1-SNAPSHOT after the release (as well > as project-1's dependency). > > But now project-2, still dependent on 1.0-SNAPSHOT, is no longer > building against the latest shared-util. Future commits to > shared-util will not be built against in our Continuous Build for > project-2 because project-2 is dependent on a "dead" snapshot. > > What am I missing / doing wrong here? Seems like snapshots were made > for this use case. > > Thanks, > Mike > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: how to centralize configuration accross multiple modules
Yes, but the problem is the "we did this with Ant" mentality... /Anders On Tue, Oct 5, 2010 at 22:01, Wayne Fay wrote: > > I want to second Wayne here and stress that doing different builds for > each > > environment is NOT the Maven way. I want to stress this as I very often > run > > This isn't just a violation of "the one true Maven way." It really is > a build anti-pattern that must be stopped any time you run into it -- > no matter what build tool you're using, or what kind of app you're > working on. > > Separate the configuration from the binary. > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Continuous Build always building against the latest SNAPSHOT version
Any help would be greatly appreciated - I'm trying to figure out how to do this the maven way. I have a shared dependency called shared-util. My team frequently makes changes to our deployable projects along with changes to the shared-util. So, in my continuous build, I'd like each of our projects always building against the latest shared-util. Seems like a perfect situation for a SNAPSHOT dependency. So, project-1 and project-2 each depend on 1.0-SNAPSHOT of shared-util. Continuous Build deploys the current 1.0-SNAPSHOT to our repo after each code commit, and project-1 and project-2 build fine. But then we release project-1. We don't want to do so with SNAPSHOT dependencies, so we release shared-util as well. The maven release plugin updates shared-util to 1.1-SNAPSHOT after the release (as well as project-1's dependency). But now project-2, still dependent on 1.0-SNAPSHOT, is no longer building against the latest shared-util. Future commits to shared-util will not be built against in our Continuous Build for project-2 because project-2 is dependent on a "dead" snapshot. What am I missing / doing wrong here? Seems like snapshots were made for this use case. Thanks, Mike - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: how to centralize configuration accross multiple modules
> I want to second Wayne here and stress that doing different builds for each > environment is NOT the Maven way. I want to stress this as I very often run This isn't just a violation of "the one true Maven way." It really is a build anti-pattern that must be stopped any time you run into it -- no matter what build tool you're using, or what kind of app you're working on. Separate the configuration from the binary. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: how to centralize configuration accross multiple modules
I want to second Wayne here and stress that doing different builds for each environment is NOT the Maven way. I want to stress this as I very often run into this solution which people have grown used to it and it make it very hard to set up correct Maven environments with a repository. It is an anti-pattern when using Maven - there can be just one flavor of an artifact for a specific version. Sure, you could solve it by using classifiers and create several artifacts for each project. But it is so much better to separate the binary and the configuration. However, I understand that it can sometimes be tricky. Most of your reqs can be accomplished by just reading the config from a properties file. You read the properties file from the classpath and then just make sure the properties file is on the classpath in runtime. I'm sure all containers have a way to do that keeping the file outside of the deployable. I mostly use JBoss and there you put it in the conf folder. Regarding the fact that these config values change, it makes even more sense keeping them outside of the build. So when a db connection string changes, you don't have to roll a new build (which MUST be a new version in the Maven world). /Anders On Tue, Oct 5, 2010 at 20:08, Jon Paynter wrote: > well it was a suggestion - do what you will with it. > > But how would you implement this using the maven way? > > given the following restrictions/requirements: > each environment has its own hostname and number of hosts (dev 1 host, qa 4 > hosts, prod 8 hosts) > each environment has a different db connection string > each environment has its own set of passwords for accounts (db, unix, and > tibco) > each environment has its own set of port numbers fo the various processes. > each environemnt has its own set of webservice urls. > and all of our j2ee processes have other application specific config values > > Add to that, most of the config values change frequently as things evolve > and change. we found its much easier to put all these values into a single > file, edit one file, and run a build. Granted this was with a morass of > ant scripts, but given the volume of changes, the .properties files worked > quite well. > > On Tue, Oct 5, 2010 at 10:27 AM, Wayne Fay wrote: > > > > For property values -- I setup a .properties file for each of our > > > environments with the default being 'dev'. So for a default build, the > > dev > > > properties are used. but when its time to build for QA or Production, > > you > > > add a cmd line argument accordingly: mvn install -DenvType=QA > > > > IMO this is an anti-pattern for Maven usage. You should be able to > > build one single artifact in say Dev and then promote that same > > untouched/changed artifact through your various environments. > > Otherwise the artifact that gets QA'ed is not the same artifact that > > lands in Production... which defeats the purpose of QA. > > > > You should generally deal with these variances in the environments via > > JNDI or other mechanisms available in the platform (JavaSE/JEE or > > whatever container you're deploying into). > > > > Wayne > > > > - > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
Re: [ANN] maven-issues-plugin
On 2010-10-04 19:48, Robert Reiner wrote: > > > Antonio Petrelli wrote: >> >> Cool! But since you already licensed with Apache License v2, why don't >> you donate it to the Maven Changes Plugin? >> > > Hello Antonio, > > thank you for your reply! > > One reason for not trying to contribute to the changes plugin was that this > plugin requires to run on Java 1.4, but the issues plugin uses a Mylyn > library which is based on Java 1.5. There is already a patch for an > unresolved JIRA issue provided by Matthew Beermann [1] of 2007 that has not > been applied. I assume for this reason. Yes, back then 1.4 compatibility was a must. Nowadays it's a different story, which is why I have opened the door for a possible cooperation. > > Kind regards > > Robert > > [1] http://jira.codehaus.org/browse/MCHANGES-58 > -- Dennis Lundberg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: how to centralize configuration accross multiple modules
Each environment identifies itself and your app uses that info to connect to the right properties at runtime. Curt Yanko | Continuous Integration Services | UnitedHealth Group IT Making IT Happen, one build at a time -Original Message- From: Jon Paynter [mailto:kittl...@gmail.com] Sent: Tuesday, October 05, 2010 2:08 PM To: Maven Users List Subject: Re: how to centralize configuration accross multiple modules well it was a suggestion - do what you will with it. But how would you implement this using the maven way? given the following restrictions/requirements: each environment has its own hostname and number of hosts (dev 1 host, qa 4 hosts, prod 8 hosts) each environment has a different db connection string each environment has its own set of passwords for accounts (db, unix, and tibco) each environment has its own set of port numbers fo the various processes. each environemnt has its own set of webservice urls. and all of our j2ee processes have other application specific config values Add to that, most of the config values change frequently as things evolve and change. we found its much easier to put all these values into a single file, edit one file, and run a build. Granted this was with a morass of ant scripts, but given the volume of changes, the .properties files worked quite well. On Tue, Oct 5, 2010 at 10:27 AM, Wayne Fay wrote: > > For property values -- I setup a .properties file for each of our > > environments with the default being 'dev'. So for a default build, > > the > dev > > properties are used. but when its time to build for QA or > > Production, > you > > add a cmd line argument accordingly: mvn install -DenvType=QA > > IMO this is an anti-pattern for Maven usage. You should be able to > build one single artifact in say Dev and then promote that same > untouched/changed artifact through your various environments. > Otherwise the artifact that gets QA'ed is not the same artifact that > lands in Production... which defeats the purpose of QA. > > You should generally deal with these variances in the environments via > JNDI or other mechanisms available in the platform (JavaSE/JEE or > whatever container you're deploying into). > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > > This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: how to centralize configuration accross multiple modules
well it was a suggestion - do what you will with it. But how would you implement this using the maven way? given the following restrictions/requirements: each environment has its own hostname and number of hosts (dev 1 host, qa 4 hosts, prod 8 hosts) each environment has a different db connection string each environment has its own set of passwords for accounts (db, unix, and tibco) each environment has its own set of port numbers fo the various processes. each environemnt has its own set of webservice urls. and all of our j2ee processes have other application specific config values Add to that, most of the config values change frequently as things evolve and change. we found its much easier to put all these values into a single file, edit one file, and run a build. Granted this was with a morass of ant scripts, but given the volume of changes, the .properties files worked quite well. On Tue, Oct 5, 2010 at 10:27 AM, Wayne Fay wrote: > > For property values -- I setup a .properties file for each of our > > environments with the default being 'dev'. So for a default build, the > dev > > properties are used. but when its time to build for QA or Production, > you > > add a cmd line argument accordingly: mvn install -DenvType=QA > > IMO this is an anti-pattern for Maven usage. You should be able to > build one single artifact in say Dev and then promote that same > untouched/changed artifact through your various environments. > Otherwise the artifact that gets QA'ed is not the same artifact that > lands in Production... which defeats the purpose of QA. > > You should generally deal with these variances in the environments via > JNDI or other mechanisms available in the platform (JavaSE/JEE or > whatever container you're deploying into). > > Wayne > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
Re: how to centralize configuration accross multiple modules
> For property values -- I setup a .properties file for each of our > environments with the default being 'dev'. So for a default build, the dev > properties are used. but when its time to build for QA or Production, you > add a cmd line argument accordingly: mvn install -DenvType=QA IMO this is an anti-pattern for Maven usage. You should be able to build one single artifact in say Dev and then promote that same untouched/changed artifact through your various environments. Otherwise the artifact that gets QA'ed is not the same artifact that lands in Production... which defeats the purpose of QA. You should generally deal with these variances in the environments via JNDI or other mechanisms available in the platform (JavaSE/JEE or whatever container you're deploying into). Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: how to centralize configuration accross multiple modules
For property values -- I setup a .properties file for each of our
environments with the default being 'dev'. So for a default build, the dev
properties are used. but when its time to build for QA or Production, you
add a cmd line argument accordingly: mvn install -DenvType=QA
So I something like this in my top level pom:
dev
path to root pom
and then use:
${PomRoot}/${envType}Config.properties
Then create:
devConfig.properties
qaConfig.properties
... or whatever environment names you need
This lets me use environment specific properties anywhere in the build. It
works quite well.
On Tue, Oct 5, 2010 at 5:57 AM, Jesse Farinacci wrote:
> Hi Emerson,
>
> On Tue, Oct 5, 2010 at 8:50 AM, emerson
> wrote:
> >
> > I would like then to pass a parameter to the mvn command (eg. mvn
> -Denv=st1)
> > and it would pick up the appropriate resource file depending on the
> > environment.
> > What would be the best way to implement something on these lines?
>
> You should look at
> http://maven.apache.org/plugins/maven-remote-resources-plugin/ .. you
> could bundle them up in one module, and extract them (via
> property-enabled profile) wherever needed. Then your integration tests
> just need to pick up your properties bundle.
>
> -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: Maven 2 & 3 + Hudson + Nexus
On 5 October 2010 04:09, Benjamin Bentmann wrote: > Hilco Wijbenga wrote: >> >> >> central >> http://central >> >> true >> >> >> true >> >> >> > > From this, it appears to be a bug in Maven 2 since your mirror should be > contacted for snapshots. > >> What would get Maven to "disable repository central"? > > Might be something goes wrong with the override of central which prevents > the snapshots=true policy from being applied. Okay, some more information. I tried it after having removed the entire com/xyz directory: Maven (2.2.1) downloads two POMs, one release and one snapshot before failing to download the test-dependencies-pom again. Note how it first downloads the 0.0.7-SNAPSHOT POM for xyz-project just before logging "Skipping disabled repository central". [DEBUG] Connecting to repository: 'all-mirror' with url: 'http://www.xyz.com/nexus/content/groups/public'. Downloading: http://www.xyz.com/nexus/content/groups/public/com/xyz/lp/xyz-project/0.0.7-SNAPSHOT/xyz-project-0.0.7-20101002.07-2.pom [DEBUG] attempting to create parent directories for destination: xyz-project-0.0.7-20101002.07-2.pom.tmp 4K downloaded (xyz-project-0.0.7-20101002.07-2.pom) [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http [DEBUG] Artifact resolved [DEBUG] Skipping disabled repository central [DEBUG] test-dependencies-pom: using locally installed snapshot [DEBUG] Skipping disabled repository central [DEBUG] Using mirror: http://www.xyz.com/nexus/content/groups/public (id: all-mirror) Maven thinks it has already downloaded test-dependencies-pom? Would "Artifact resolved" refer to test-dependencies-pom or simply to xyz-project? Is this related to Wagon? Or is there "incorrect" metadata in my remote repository (where "incorrect" means, correct for Maven 3 but unpalatable to Maven 2)? + Error stacktraces are turned on. Apache Maven 2.2.1 (r801777; 2009-08-06 11:16:01-0800) Java version: 1.6.0_21 Java home: /opt/sun-jdk-1.6.0.21/jre Default locale: en_CA, platform encoding: UTF-8 OS name: "linux" version: "2.6.35-gentoo-r9" arch: "i386" Family: "unix" [DEBUG] Building Maven user-level plugin registry from: '/home/hilco/.m2/plugin-registry.xml' [DEBUG] Building Maven global-level plugin registry from: '/home/hilco/bin/maven/current/conf/plugin-registry.xml' [INFO] Scanning for projects... [DEBUG] Searching for parent-POM: com.xyz:xyz-pom:pom:7 of project: com.xyz.lp:xyz-project-integration:pom:0.1-SNAPSHOT in relative path: ../pom.xml [DEBUG] Parent-POM: com.xyz:xyz-pom:pom:7 not found in relative path: ../pom.xml [DEBUG] Retrieving parent-POM: com.xyz:xyz-pom:pom:7 for project: com.xyz.lp:xyz-project-integration:pom:0.1-SNAPSHOT from the repository. [DEBUG] Trying repository central [DEBUG] Using mirror: http://www.xyz.com/nexus/content/groups/public (id: all-mirror) [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http [DEBUG] Checking for pre-existing User-Agent configuration. [DEBUG] Adding User-Agent configuration. [DEBUG] Connecting to repository: 'all-mirror' with url: 'http://www.xyz.com/nexus/content/groups/public'. Downloading: http://www.xyz.com/nexus/content/groups/public/com/xyz/xyz-pom/7/xyz-pom-7.pom [DEBUG] attempting to create parent directories for destination: xyz-pom-7.pom.tmp 1/13K 2/13K 5/13K 6/13K 8/13K 9/13K 10/13K 12/13K 13/13K 13K downloaded (xyz-pom-7.pom) [DEBUG] Using Wagon implementation lightweight from default mapping for protocol http [DEBUG] Artifact resolved [DEBUG] Adding extension: org.apache.maven.model.extens...@4b19aed2 [DEBUG] Initialising extension: org.jvnet.wagon-svn:wagon-svn [DEBUG] com.xyz.lp:xyz-project-integration:pom:0.1-SNAPSHOT (selected for null) [DEBUG] org.jvnet.wagon-svn:wagon-svn:jar:1.9:runtime (selected for runtime) [DEBUG] org.jvnet.hudson.svnkit:svnkit:jar:1.1.4-hudson-4:runtime (selected for runtime) [DEBUG] ch.ethz.ganymed:ganymed-ssh2:jar:build210:runtime (selected for runtime) [DEBUG] Retrieving parent-POM: org.codehaus.plexus:plexus:pom:1.0.11 for project: null:plexus-utils:jar:1.4.1 from the repository. [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.4.1:runtime (selected for runtime) [DEBUG] Retrieving parent-POM: org.apache.maven.wagon:wagon:pom:1.0-beta-2 for project: null:wagon-provider-api:jar:1.0-beta-2 from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent:pom:4 for project: org.apache.maven.wagon:wagon:pom:1.0-beta-2 from the repository. [DEBUG] Retrieving parent-POM: org.apache:apache:pom:3 for project: org.apache.maven:maven-parent:pom:4 from the repository. [DEBUG] Adding managed dependencies for unknown:wagon-provider-api [DEBUG] org.apache.maven.wagon:wagon-provider-api:jar:1.0-beta-2 [DEBUG] org.apache.maven.wagon:wagon-provider-test:jar:1.0-beta-2 [DEBUG] org.apache.maven.wagon:wag
Re: Can we pom.xml be written in JSON instead of XML?
> If we don't want to write pom.xml in XML, but JSON. Is it possible? Thanks a > lot. Take a look at Polyglot Maven: http://polyglot.sonatype.org/ Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Can we pom.xml be written in JSON instead of XML?
Dear all, If we don't want to write pom.xml in XML, but JSON. Is it possible? Thanks a lot. Thanks and regards, William
Surefire: empty string in systemPropertyVariables?
I recently changed a systemProperties configuration variable to be systemPropertyVariables. The old systemProperties element was able to deal with empty strings. That is, if you had: testDatabasePassword ...everything worked fine; the test database got an empty string passed to it. I changed this to ...and mvn -X reports that the system property is being set to null. Then I don't see it in the list of system properties handed off to the test. What would be the proper way to use an empty string here? Maven 2.2.1, Surefire 2.6 Thanks, Laird
Re: Failing a build with maven-failsafe-plugin
2010/10/5 Anders Hammar : > Can it be much simpler than a copy 'n' paste example? Anyway, Thomas, here is a working example: http://svn.apache.org/repos/asf/velocity/tools/trunk/velocity-tools-examples/velocity-tools-examples-showcase/ Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Failing a build with maven-failsafe-plugin
Can it be much simpler than a copy 'n' paste example?
But as always, a ticket with an improvement suggestion would be very much
appreciated by the maven team!
/Anders
On Tue, Oct 5, 2010 at 16:27, Thomas Sundberg wrote:
> Hi all!
>
> I am indeed missing the verify goal. I added it so my configuration became:
>
>
>org.apache.maven.plugins
>maven-failsafe-plugin
>2.6
>
>
>integration-test
>
>verify
>
>
>
>none
>
>
>**/integration/**
>
>
>
>
>
>
> and the result became that Maven is failing the build as well as tearing
> down my app server.
>
> My opinion about the docs you point to Anders is that they are not as clear
> as they could have been.
>
> Thanks for the pointers!
> Thomas
>
>
> On Tue, Oct 5, 2010 at 13:58, Anders Hammar wrote:
>
> > I guess you're missing the verify goal:
> >
> > http://maven.apache.org/plugins/maven-failsafe-plugin/usage.html
> >
> > /Anders
> >
> > On Tue, Oct 5, 2010 at 13:46, Thomas Sundberg wrote:
> >
> > > Hi!
> > >
> > > I want to use maven-failsafe-plugin to run some integration tests. I
> want
> > > Maven to run post-integration-test phase to tear down an application
> > > server.
> > > If any test fails, I want Maven to fail the build so my CI server can
> > pick
> > > it up and inform the developer who just made a mistake.
> > >
> > > My failsafe plugin is configured as:
> > >
> > >
> > > org.apache.maven.plugins
> > >maven-failsafe-plugin
> > > 2.6
> > >
> > >
> > >integration-test
> > >
> > >integration-test
> > >
> > >
> > >
> > >none
> > >
> > >
> > > **/integration/**
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > This works fine, my app server gets set up and torn down. My
> integration
> > > tests are executed properly. But when I add a JUnit test like this:
> > >
> > > @Test
> > > public void failingTest(){
> > >fail("Expected to fail");
> > > }
> > >
> > > Maven doesn't fail the build.
> > >
> > > I happily reports:
> > >
> > >
> > >
> > > Tests run: 2, Failures: 1, Errors: 0, Skipped: 0
> > >
> > >
> > >
> > > [INFO] BUILD SUCCESS
> > > [INFO]
> > >
>
> > > [INFO] Total time: 30.828s
> > > [INFO] Finished at: Tue Oct 05 13:08:36 CEST 2010
> > > [INFO] Final Memory: 15M/36M
> > > [INFO]
> > >
>
> > >
> > > Do I need to set any additional property to get the
> maven-failsafe-plugin
> > > to
> > > fail the build if a unit test failed?
> > > Or am I trying to do something that the failsafe-plugin isn't done for?
> > >
> > > I'm running Maven 3.0-RC3
> > >
> > > mvn -version
> > > Apache Maven 3.0-RC3 (r1001464; 2010-09-26 18:14:28+0200)
> > > Java version: 1.6.0_21
> > > Java home: C:\java\jdk1.6.0_21\jre
> > > Default locale: sv_SE, platform encoding: Cp1252
> > > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
> > >
> > > /Thomas
> > >
> > > --
> > > Thomas Sundberg
> > > M. Sc. in Computer Science
> > >
> > > Mobile: +46 70 767 33 15
> > > Blog: http://thomassundberg.wordpress.com/
> > > Twitter: @thomassundberg
> > >
> > > Better software through faster feedback
> > >
> >
>
>
>
> --
> Thomas Sundberg
> M. Sc. in Computer Science
>
> Mobile: +46 70 767 33 15
> Blog: http://thomassundberg.wordpress.com/
> Twitter: @thomassundberg
>
> Better software through faster feedback
>
Re: Failing a build with maven-failsafe-plugin
Hi all!
I am indeed missing the verify goal. I added it so my configuration became:
org.apache.maven.plugins
maven-failsafe-plugin
2.6
integration-test
verify
none
**/integration/**
and the result became that Maven is failing the build as well as tearing
down my app server.
My opinion about the docs you point to Anders is that they are not as clear
as they could have been.
Thanks for the pointers!
Thomas
On Tue, Oct 5, 2010 at 13:58, Anders Hammar wrote:
> I guess you're missing the verify goal:
>
> http://maven.apache.org/plugins/maven-failsafe-plugin/usage.html
>
> /Anders
>
> On Tue, Oct 5, 2010 at 13:46, Thomas Sundberg wrote:
>
> > Hi!
> >
> > I want to use maven-failsafe-plugin to run some integration tests. I want
> > Maven to run post-integration-test phase to tear down an application
> > server.
> > If any test fails, I want Maven to fail the build so my CI server can
> pick
> > it up and inform the developer who just made a mistake.
> >
> > My failsafe plugin is configured as:
> >
> >
> > org.apache.maven.plugins
> >maven-failsafe-plugin
> > 2.6
> >
> >
> >integration-test
> >
> >integration-test
> >
> >
> >
> >none
> >
> >
> > **/integration/**
> >
> >
> >
> >
> >
> >
> >
> > This works fine, my app server gets set up and torn down. My integration
> > tests are executed properly. But when I add a JUnit test like this:
> >
> > @Test
> > public void failingTest(){
> >fail("Expected to fail");
> > }
> >
> > Maven doesn't fail the build.
> >
> > I happily reports:
> >
> >
> >
> > Tests run: 2, Failures: 1, Errors: 0, Skipped: 0
> >
> >
> >
> > [INFO] BUILD SUCCESS
> > [INFO]
> >
> > [INFO] Total time: 30.828s
> > [INFO] Finished at: Tue Oct 05 13:08:36 CEST 2010
> > [INFO] Final Memory: 15M/36M
> > [INFO]
> >
> >
> > Do I need to set any additional property to get the maven-failsafe-plugin
> > to
> > fail the build if a unit test failed?
> > Or am I trying to do something that the failsafe-plugin isn't done for?
> >
> > I'm running Maven 3.0-RC3
> >
> > mvn -version
> > Apache Maven 3.0-RC3 (r1001464; 2010-09-26 18:14:28+0200)
> > Java version: 1.6.0_21
> > Java home: C:\java\jdk1.6.0_21\jre
> > Default locale: sv_SE, platform encoding: Cp1252
> > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
> >
> > /Thomas
> >
> > --
> > Thomas Sundberg
> > M. Sc. in Computer Science
> >
> > Mobile: +46 70 767 33 15
> > Blog: http://thomassundberg.wordpress.com/
> > Twitter: @thomassundberg
> >
> > Better software through faster feedback
> >
>
--
Thomas Sundberg
M. Sc. in Computer Science
Mobile: +46 70 767 33 15
Blog: http://thomassundberg.wordpress.com/
Twitter: @thomassundberg
Better software through faster feedback
Re: Running tests with dynamic file sets
On 10/5/10 10:10 AM, Chris Audley wrote: > I'm writing a POM for a project that needs to run unit tests in two > groups, one with forkMode "once" and the other with forkMode "always". > I understand how to configure two separate executions of the surefire > plugin in the section with separate blocks. > The problem I have is that the files to be run by each execution can't > be defined by file patterns in and elements. > > Our current ant based build system uses annotations included in the > test sources to create two filesets, a junit task is then used to run > each of the filesets separately. I know I can use ant within maven to > create these filesets. Is there a way I can feed these filesets into > the surefire plugin? Not as such. Surefire supports this for TestNG groups. You could probably also do something similar with JUnit test suites, but that wouldn't be exactly the same workflow as you have now. > > Is it better to just forego the surefire plugin and run my unit tests > using an ant based mojo? I think you'd be better off using TestNG groups if they meet your needs. Justin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Running tests with dynamic file sets
I'm writing a POM for a project that needs to run unit tests in two groups, one with forkMode "once" and the other with forkMode "always". I understand how to configure two separate executions of the surefire plugin in the section with separate blocks. The problem I have is that the files to be run by each execution can't be defined by file patterns in and elements. Our current ant based build system uses annotations included in the test sources to create two filesets, a junit task is then used to run each of the filesets separately. I know I can use ant within maven to create these filesets. Is there a way I can feed these filesets into the surefire plugin? Is it better to just forego the surefire plugin and run my unit tests using an ant based mojo? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: first plugin
i have had the sources in src/main/java previously but that didn't
help either :-)
but it works now ;-)
the last thing i'm struggling with now is that hudson is executing my
builds with jre, not jdk, therefore my apt processors do not work.
On Tue, Oct 5, 2010 at 2:52 PM, Wendy Smoak wrote:
> On Tue, Oct 5, 2010 at 7:10 AM, Leon Rosenberg
> wrote:
>> basically add this to my pom
> ...
>> ${project.basedir}/java
>
> Did you add this at the same time? If so, that's what did it...
> without that Maven would expect the classes to be in src/main/java, so
> nothing would have been compiled.
>
> --
> 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: how to centralize configuration accross multiple modules
Hi Emerson, On Tue, Oct 5, 2010 at 8:50 AM, emerson wrote: > > I would like then to pass a parameter to the mvn command (eg. mvn -Denv=st1) > and it would pick up the appropriate resource file depending on the > environment. > What would be the best way to implement something on these lines? You should look at http://maven.apache.org/plugins/maven-remote-resources-plugin/ .. you could bundle them up in one module, and extract them (via property-enabled profile) wherever needed. Then your integration tests just need to pick up your properties bundle. -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: first plugin
On Tue, Oct 5, 2010 at 7:10 AM, Leon Rosenberg wrote:
> basically add this to my pom
...
> ${project.basedir}/java
Did you add this at the same time? If so, that's what did it...
without that Maven would expect the classes to be in src/main/java, so
nothing would have been compiled.
--
Wendy
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
how to centralize configuration accross multiple modules
Hi I have a integration test with several sub-modules. Currently each one has its specific configuration. How can I centralise the configuration in 1 single place? I would like to have 1 single file per environment with: scrum1_team.properties frontend=st1_fe_server backend=st1_be_server ... scrum2_team.properties frontend=st2_fe_server backend=st2_be_server ... And have all modules to use the same file when they need to use some of the properties. I would like then to pass a parameter to the mvn command (eg. mvn -Denv=st1) and it would pick up the appropriate resource file depending on the environment. What would be the best way to implement something on these lines? regards Emerson
Re: multi-module agregated test report
Hi Emerson,
On Tue, Oct 5, 2010 at 5:25 AM, emerson wrote:
> Should I presume there is no equivalent to the aggregated dashboard of M1?
Yes. There is no equivalent for the M1 dashboard. Some report plugins
support aggregation, but that is on a per-plugin basis.
I realize what I'm about to suggest is even more bold than the
statements that an MRM is a necessary component for proper Maven
function in any environment of even minor sophistication (which it
is), but.. You should consider running Hudson with all of the static
code analysis tools, and test reporting, enabled. Hudson handles
proper module {checkstyle, findugs, pmd, test} aggregation on your
behalf, and in a spectacularly useful and easy way.
-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: Failing a build with maven-failsafe-plugin
I guess you're missing the verify goal:
http://maven.apache.org/plugins/maven-failsafe-plugin/usage.html
/Anders
On Tue, Oct 5, 2010 at 13:46, Thomas Sundberg wrote:
> Hi!
>
> I want to use maven-failsafe-plugin to run some integration tests. I want
> Maven to run post-integration-test phase to tear down an application
> server.
> If any test fails, I want Maven to fail the build so my CI server can pick
> it up and inform the developer who just made a mistake.
>
> My failsafe plugin is configured as:
>
>
> org.apache.maven.plugins
>maven-failsafe-plugin
> 2.6
>
>
>integration-test
>
>integration-test
>
>
>
>none
>
>
> **/integration/**
>
>
>
>
>
>
>
> This works fine, my app server gets set up and torn down. My integration
> tests are executed properly. But when I add a JUnit test like this:
>
> @Test
> public void failingTest(){
>fail("Expected to fail");
> }
>
> Maven doesn't fail the build.
>
> I happily reports:
>
>
>
> Tests run: 2, Failures: 1, Errors: 0, Skipped: 0
>
>
>
> [INFO] BUILD SUCCESS
> [INFO]
>
> [INFO] Total time: 30.828s
> [INFO] Finished at: Tue Oct 05 13:08:36 CEST 2010
> [INFO] Final Memory: 15M/36M
> [INFO]
>
>
> Do I need to set any additional property to get the maven-failsafe-plugin
> to
> fail the build if a unit test failed?
> Or am I trying to do something that the failsafe-plugin isn't done for?
>
> I'm running Maven 3.0-RC3
>
> mvn -version
> Apache Maven 3.0-RC3 (r1001464; 2010-09-26 18:14:28+0200)
> Java version: 1.6.0_21
> Java home: C:\java\jdk1.6.0_21\jre
> Default locale: sv_SE, platform encoding: Cp1252
> OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
>
> /Thomas
>
> --
> Thomas Sundberg
> M. Sc. in Computer Science
>
> Mobile: +46 70 767 33 15
> Blog: http://thomassundberg.wordpress.com/
> Twitter: @thomassundberg
>
> Better software through faster feedback
>
Re: Failing a build with maven-failsafe-plugin
Add: verify and make sure you run up until that phase. Cheers, Brett On 05/10/2010, at 10:46 PM, Thomas Sundberg wrote: > integration-test -- 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
Failing a build with maven-failsafe-plugin
Hi!
I want to use maven-failsafe-plugin to run some integration tests. I want
Maven to run post-integration-test phase to tear down an application server.
If any test fails, I want Maven to fail the build so my CI server can pick
it up and inform the developer who just made a mistake.
My failsafe plugin is configured as:
org.apache.maven.plugins
maven-failsafe-plugin
2.6
integration-test
integration-test
none
**/integration/**
This works fine, my app server gets set up and torn down. My integration
tests are executed properly. But when I add a JUnit test like this:
@Test
public void failingTest(){
fail("Expected to fail");
}
Maven doesn't fail the build.
I happily reports:
Tests run: 2, Failures: 1, Errors: 0, Skipped: 0
[INFO] BUILD SUCCESS
[INFO]
[INFO] Total time: 30.828s
[INFO] Finished at: Tue Oct 05 13:08:36 CEST 2010
[INFO] Final Memory: 15M/36M
[INFO]
Do I need to set any additional property to get the maven-failsafe-plugin to
fail the build if a unit test failed?
Or am I trying to do something that the failsafe-plugin isn't done for?
I'm running Maven 3.0-RC3
mvn -version
Apache Maven 3.0-RC3 (r1001464; 2010-09-26 18:14:28+0200)
Java version: 1.6.0_21
Java home: C:\java\jdk1.6.0_21\jre
Default locale: sv_SE, platform encoding: Cp1252
OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows"
/Thomas
--
Thomas Sundberg
M. Sc. in Computer Science
Mobile: +46 70 767 33 15
Blog: http://thomassundberg.wordpress.com/
Twitter: @thomassundberg
Better software through faster feedback
Re: first plugin
Hello Jörg,
basically add this to my pom
${artifactId}-${version}
${project.basedir}/java
org.apache.maven.plugins
maven-compiler-plugin
2.3.2
1.6
1.6
On Tue, Oct 5, 2010 at 11:16 AM, Jörg Schaible wrote:
> Hi Leon,
>
> Leon Rosenberg wrote:
>
>> ok, resolved, my error, i forgot to explicitly include the compile
>> plugin, therefor my plugin was packaged but contained no classes.
>> thanx for the help. now i only need to force the using project to add
>> generated classes to the source dirs ;-)
>
> What do you mean with "include the compile plugin" ?
>
> - 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 2 & 3 + Hudson + Nexus
Hilco Wijbenga wrote: But why would only Maven 2 complain and not Maven 3 then? There's always a chance of a bug. central http://central true true From this, it appears to be a bug in Maven 2 since your mirror should be contacted for snapshots. What would get Maven to "disable repository central"? Might be something goes wrong with the override of central which prevents the snapshots=true policy from being applied. Benjamin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-war-plugin dependentWarExcludes not working when build/outputDirectory specified
Hi list! I use build/outputDirectory to have compile on save work with netbeans. I also want the overlay war to exclude WEB-INF/classes. My problem is that it only works when not specifying build/outputDirectory. Apache Maven 2.2.1 (rdebian-1) Java version: 1.6.0_21 ... myProject org.apache.maven.plugins maven-war-plugin 2.1-beta-1 war WEB-INF/lib/commons-logging-*.jar WEB-INF/classes/** running 'mvn -X ...' gives these relevant lines: working (without outputDirectory): [DEBUG] - WEB-INF/classes/webservice.properties wasn't copied because it has already been packaged for overlay[currentBuild]. not working (with outputDirectory): [DEBUG] + WEB-INF/classes/webservice.properties has been copied. (!and overwrites the original!) Is it a config prolem, or a bug? Thanx Roti - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: multi-module agregated test report
Should I presume there is no equivalent to the aggregated dashboard of M1? On 1 October 2010 18:57, emerson wrote: > Hi > > I used to have in my multiproject in maven1 a dashboard report with a > summary with the test results of each modules. > How can I set up maven so that it will create a similar report like that > in maven 2, with 1 line per module and the total of tests, number of failing > tests, pass rate, etc? > > Regards > Emerson >
Re: first plugin
Hi Leon, Leon Rosenberg wrote: > ok, resolved, my error, i forgot to explicitly include the compile > plugin, therefor my plugin was packaged but contained no classes. > thanx for the help. now i only need to force the using project to add > generated classes to the source dirs ;-) What do you mean with "include the compile plugin" ? - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Company-wide settings
To handle distributionManagement, I define the url as a property that is defined in settings.xml. This allow me to define the whole connectivity from settings.xml. If ever my repository changed, I just need to update settings.xml on my build machines, instead of releasing a new parent and bumping parent version in all projects. 2010/10/5 Siegmann Daniel, NY > Hi Phillip, > > This is easy enough to solve IME. Commit a Maven installation to your > preferred repository (CVS, SVN, etc.), then all your developers can > obtain that installation by checking it out of the repository. If > something is changed you can modify settings.xml and commit to the repo, > then everyone just has to update. > > If you need multiple versions just keep multiple copies in the repo. > > (This is how it works at my company. When Maven 3.0 is released I'll put > it in my local workspace, update the settings.xml to point to our Nexus > installation, and commit everything. Then I'll send out an email letting > everyone know it's there.) > > Note that if you're using m2eclipse you'll want to point it to this > installation (rather than using the embedded installation). > > ~Daniel > > -Original Message- > From: Phillip Hellewell [mailto:ssh...@gmail.com] > Sent: Sunday, October 03, 2010 5:34 PM > To: Maven Users List > Subject: Company-wide settings > > I see that Maven can have a settings.xml at both the "Global Level" > and "User Level". Is there a way to have a settings.xml that can be > referenced (or included) from a pom.xml, whose settings would apply > first but could be overridden by a global or user settings.xml. > > The idea is to have a shared "company-level" settings.xml with settings > like profiles that most developers will want, and to have them > automatically available. The alternative is for everyone to manually > append it to their global or user-level settings.xml. > > Phillip > > - > 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 > > -- Vincent
Re: first plugin
ok, resolved, my error, i forgot to explicitly include the compile
plugin, therefor my plugin was packaged but contained no classes.
thanx for the help. now i only need to force the using project to add
generated classes to the source dirs ;-)
regards
Leon
On Tue, Oct 5, 2010 at 8:11 AM, Leon Rosenberg wrote:
> Hello,
>
> thanks for the help.
>
> the plugin.xml (packaged) looks like follows:
>
>
>
> net.anotheria
> maven-ano-doc-plugin
> 1.0-SNAPSHOT
> ano-doc
> false
> true
>
>
>
> org.apache.maven
> maven-plugin-api
> jar
> 2.0
>
>
>
>
> mvn help:describe fails:
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'help'.
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error building POM (may not be this project's POM).
>
>
> Project ID: org.apache.maven.plugins:maven-help-plugin
>
> Reason: Error getting POM for
> 'org.apache.maven.plugins:maven-help-plugin' from the repository:
> Failed to resolve artifact, possibly due to a repository list that is
> not appropriately equipped for this artifact's metadata.
> org.apache.maven.plugins:maven-help-plugin:pom:2.2-SNAPSHOT
>
> from the specified remote repositories:
> nexus (http://nexus.anotheria.net/nexus/content/groups/public)
>
> for project org.apache.maven.plugins:maven-help-plugin
>
>
>
>
> On Tue, Oct 5, 2010 at 12:21 AM, Justin Edelson
> wrote:
>> Hard to tell from this code. Check the plugin.xml file which is being
>> generated. Also mvn help:describe (which uses the plugin.xml
>> descriptor IIRC).
>>
>> Also, my guess is that you don't actually want to include this line:
>> * @execute phase="generate-sources"
>>
>> But I doubt that's the source of the error below.
>>
>> Justin
>>
>>
>>
>> On Mon, Oct 4, 2010 at 5:50 PM, Leon Rosenberg
>> wrote:
>>> Hello,
>>>
>>> I'm currently writing my first plugin and am struggling with very basics.
>>> From the guide
>>> (http://maven.apache.org/guides/plugin/guide-java-plugin-development.html)
>>> I understood that if I
>>> specify a goal in a javadoc annotation I will able to call it later
>>> directly, but I fail to achieve it. In my plugin I'm annotating the
>>> code with generate:
>>>
>>>
>>> /**
>>> * Generates ano-doc classes.
>>> *
>>> * @goal generate
>>> * @phase generate-sources
>>> * @execute phase="generate-sources"
>>> *
>>> */
>>> public class GeneratorMojo extends AbstractMojo{
>>>
>>> public void execute() throws MojoExecutionException,
>>> MojoFailureException {
>>> getLog().info("Y HEI");
>>>
>>> }
>>>
>>> }
>>>
>>> After the packaging, and installing, and running from the directory I
>>> want to use it:
>>> anot...@colin:~/projects/aos/ano-site$ mvn ano-doc:generate
>>> [INFO] Scanning for projects...
>>> [INFO]
>>>
>>> [ERROR] BUILD FAILURE
>>> [INFO]
>>>
>>> [INFO] Required goal not found: ano-doc:generate in
>>> net.anotheria:maven-ano-doc-plugin:1.0-SNAPSHOT
>>> [INFO]
>>>
>>> [INFO] For more information, run Maven with the -e switch
>>> [INFO]
>>>
>>> [INFO] Total time: < 1 second
>>> [INFO] Finished at: Mon Oct 04 23:48:07 CEST 2010
>>> [INFO] Final Memory: 8M/81M
>>>
>>>
>>> My plugin pom looks like this:
>>>
>>> 4.0.0
>>> net.anotheria
>>> maven-ano-doc-plugin
>>> maven-plugin
>>> 1.0-SNAPSHOT
>>> AnoDoc Generator for Maven
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> org.apache.maven
>>> maven-plugin-api
>>> 2.0
>>>
>>>
>>>
>>>
>>> my pom in which I intend to use the new project :
>>>
>>>
>>>
>>> net.anotheria
>>> maven-ano-doc-plugin
>>> 1.0-SNAPSHOT
>>>
>>>
>>> generate-sources
>>>
>>> generate
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> any help would be greatly appreciated
>>> regards
>>> Leon
>>>
>>> -
>>> 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-issues-plugin
Since Maven has been requiring maven 5 since v 2.2 i don't see why this shouldn't be used as part of this plugin, unless compatibility with earlier maven versions are a requirement. On Mon, Oct 4, 2010 at 7:48 PM, Robert Reiner wrote: > > > Antonio Petrelli wrote: > > > > Cool! But since you already licensed with Apache License v2, why don't > > you donate it to the Maven Changes Plugin? > > > > Hello Antonio, > > thank you for your reply! > > One reason for not trying to contribute to the changes plugin was that this > plugin requires to run on Java 1.4, but the issues plugin uses a Mylyn > library which is based on Java 1.5. There is already a patch for an > unresolved JIRA issue provided by Matthew Beermann [1] of 2007 that has not > been applied. I assume for this reason. > > Kind regards > >Robert > > [1] http://jira.codehaus.org/browse/MCHANGES-58 > > -- > View this message in context: > http://maven.40175.n5.nabble.com/ANN-maven-issues-plugin-tp3046637p3192503.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 > >
Maven reporting plugins do not execute if a unit test failure occurs
Using the latest version (2.6) of maven-surefire-report-plugin in the reporting section of Maven 2.2.1 does not execute if there is a unit test failure. I can't get any of the plugins in the reporting section of Maven to execute if there is a unit test failure. I found that I can set maven.test.failure.ignore=true here - http://jira.codehaus.org/browse/SUREFIRE-247 The problem to this approach is now our hudson builds are successful even if there are unit test failures. I tried to set the reporting plugin maven-surefire-report-plugin to run with the build plugins on a phase but I can't figure out how to get this to work. Is this a valid approach? How can I get the Maven reporting plugins to execute if a unit test failure occurs? Vincen Collins
Maven reporting plugins do not execute if a unit test failure occurs
Using the latest version (2.6) of maven-surefire-report-plugin in the reporting section of Maven 2.2.1 does not execute if there is a unit test failure. I can't get any of the plugins in the reporting section of Maven to execute if there is a unit test failure. I found that I can set maven.test.failure.ignore=true here - http://jira.codehaus.org/browse/SUREFIRE-247 The problem to this approach is now our hudson builds are successful even if there are unit test failures. I tried to set the reporting plugin maven-surefire-report-plugin to run with the build plugins on a phase but I can't figure out how to get this to work. Is this a valid approach? How can I get the Maven reporting plugins to execute if a unit test failure occurs? Vincen Collins
