Please remove me
Hi, As much as I enjoy getting the emails from this list every day, I would really like to get off of it. I've tried sending an email to users-unsubscr...@maven.apache.org, to users-unsubscribe-jnhagelb=us.ibm.com, users-unsubscribe-jnhagelberg=us.ibm.com. As far as I can tell, these emails seem to be going into a black hole. Is there a way someone can manually remove me? I believe I am subscribed using the email address jnhagelb...@us.ibm.com. Interestingly, users-h...@us.ibm.com appears to be a black hole as well. I'm wondering if our firewall and mail filters are keeping the confirmation messages from reaching me. Thanks! Jeffrey Hagelberg, Software Engineer XMeta Development IBM Software Group Phone: 978-899-2055 T/L:276-2055) Email:jnhag...@us.ibm.com
Clearcase with maven release plugin
Hi, I'm wondering if anyone has been able to successfully use clearcase with the maven release plugin. We're trying to figure out how to do it and investigating the various options. If you've been able get this to work, could you please share how you were able to make it work? Thanks, -Jeff Jeffrey Hagelberg, Software Engineer XMeta Development IBM Software Group Phone: 978-899-2055 T/L:276-2055) Email:jnhag...@us.ibm.com
Re: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released.
Well, We have a multi-project build. What we do is define a url in the parent project and leave out the s in all of the other poms. When we do this, the maven generated site correctly links the parent projects to the child projects. It kind of sounds like you may be overriding some of the default directories, and that may be causing the maven site plugin to become confused. If that is the case, you probably need to set generatedSiteDirectory in the configuration for the maven-site-plugin in . There are also properties for other plugins you will likely need to set. I hope this helps. -Jeff Jeffrey Hagelberg, Software Engineer XMeta Development IBM Software Group Phone: 978-899-2055 T/L:276-2055) Email:jnhag...@us.ibm.com From: Stephen Connolly To: Maven Users List Cc: Maven Users List Date: 05/26/2009 04:13 PM Subject:Re: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released. and you'd probably want an integration-test scope as well for dependencies used for integration testing, and you'd need to add an integrationTestSources element to the build, as well as integrationTestResources that is if you want to do things properly. and I am not opposed to such changes. the failsafe plugin provides a mostly clean solution *now*. I am fed up waiting for try... finally phases (which are why failing the build in the integration-test phase is *bad*)... I am fed up having a big mad configuration section with multiple executions in my maven-surefire-plugin plugin, which scares project newcomers, just the get integration tests running correctly... I am fed up with a separate module for integration tests (of only one module) because you only really see the failures when it comes time to release... with failsafe, it's part of the standard build for that module. if the developers want to skip the its mvn package or mvn verify -DskipITs if they just run mvn install or mvn deploy then the integration tests will have run. if they've bugs in unit tests mvn test -Dmaven.surefire.debug=... if they've bugs in integration tests mvn verify -Dmaven.failsafe.debug=... and all I'd added is a simple short snippet to the pom... no execution hacks, no profile hacks don't get me wrong, if somebody has a better solution *pretty please with catnip on top* show it to us *now* ;-) -Stephen Sent from my [rhymes with myPod] ;-) On 26 May 2009, at 20:33, Jason Chaffee wrote: > Yes, it would basically force Maven to adopt it as a standard and it > would might mean even adding a itest-compile phase, etc. > > Not sure if I prefer this idea over the current protocol, but I do > think the FailSafe plugin is very good and clever approach to > integration tests with the way things currently work in Maven. > > I am just throwing it out there as idea for the sake of discussion. > > Jason > > -Original Message- > From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] > Sent: Tuesday, May 26, 2009 12:27 PM > To: Maven Users List > Cc: Maven Users List > Subject: Re: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released. > > but that looses source folder config in ide setup, and hacks with > test- > compile > > Sent from my [rhymes with myPod] ;-) > > On 26 May 2009, at 20:22, Jason Chaffee > wrote: > >> One way around the excludes hack is to adopt a different directory >> structure for it tests and unit tests. For example >> >> src/test --> unit tests >> >> src/itest --> integration tests >> >> Jason >> >> -Original Message- >> From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] >> Sent: Tuesday, May 26, 2009 12:12 PM >> To: Maven Users List >> Cc: Maven Users List >> Subject: Re: [ANN] Failsafe Maven Plugin 2.4.3-alpha-1 released. >> >> I am not opposed to doing so. the block for me is my lack of Apache >> commit access. >> >> there are valid arguments for keeping these as separate plugins >> though, eg the none hack that people used to >> configure surefire for multiple executions; debugging tests from an >> IDE; skipping one type of tests, etc >> >> but at the end of the day, if we can find a way to combine to one >> plugin, I'm fine with that >> >> Sent from my [rhymes with myPod] ;-) >> >> On 26 May 2009, at 19:58, Paul Benedict wrote: >> >>> Will there be an effort to add the integration testing features to >>> the >>> original? I would like to not have multiple testing plugins. >>> >>> On Tue, May 26, 2009 at 1:54 PM, Stephen Connolly >>>
Re: Anyone have a plugin to check if the surefire tests pass?
We've got one. It uses the SurefireReportParser from the maven-surefire-report-plugin to parse the reports. I'll have to get permission from my manager to send it, but that's the basic idea. -Jeff Jeffrey Hagelberg, Software Engineer XMeta Development IBM Software Group Phone: 978-899-2055 T/L:276-2055) Email:jnhag...@us.ibm.com From: Kalle Korhonen To: Maven Users List Date: 05/18/2009 04:00 PM Subject:Re: Anyone have a plugin to check if the surefire tests pass? Why don't you just write a unit test base class that runs Jetty embedded? If you store the server in a static attribute and start it in @BeforeClass (or similar) conditionally if hasn't been started before, you'll save the restart costs between each test. As a bonus, these integration tests are easily runnable from your IDE. This is exactly what I do. Kalle On Mon, May 18, 2009 at 9:16 AM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > Hey, before you think this guy is crazy, surefire will do that for you... > > pre-integration-test: jetty:run daemon=true > integration-test: surefire:test testFailureIgnore=true > post-integration-test: jetty:stop > verify: __:__ > > so that I can run my integration tests and tidy-up afterwards and then fail > the build after the tidy-up... > > yes, yes, yes I know about putting the tests in a separate module and all > that jazz... but this is in some ways a bit cleaner > > -Stephen >
Custom Lifecycle
Hello, We are trying to define a custom lifecycle for our nightly build. We basically want it to have the following phases: 1. run-build 2. process-build-results 3. report-build-results The idea is that we will have a separate nightly build maven project that runs the nightly build. In "run-build", we would use the maven invoker plugin to run "mvn deploy" on another project. In "process-build-results" we would parse the test results and put them in format suitable for emailing. In "report-build-results" we would send out an email with the test results and generate and deploy the maven site. I've tried doing this by creating a lifecycle.xml and components.xml in my nightly build plugin and enabling extensions for the plugin in my nightly build project. However, it does not seem to be working. It seems like I must be missing something, but I'm not sure what it is. Do you have any idea what it might be? I really could not find much documentation on how to create a custom lifecycle. I tried to follow what's in http://www.sonatype.com/books/maven-book/reference/writing-plugins-sect-custom-lifecycle.html . I've attached watered-down versions of the projects for the plugin and the nightly build, including their pom.xml files and the lifecycle.xml and components.xml. The error I am seeing is: >mvn com.ibm.mmi:mmi-nightly-build-plugin:nightly-build [INFO] Scanning for projects... [INFO] [INFO] Building nightly_build [INFO]task-segment: [com.ibm.mmi:mmi-nightly-build-plugin:nightly-build] [INFO] [INFO] Preparing mmi-nightly-build:nightly-build [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Unable to find lifecycle for phase 'report-build-results' [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Mon May 18 15:18:43 EDT 2009 [INFO] Final Memory: 4M/20M [INFO] Stack trace: [INFO] Trace org.apache.maven.BuildFailureException: Unable to find lifecycle for phase 'repo rt-build-results' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getLifecycleForPh ase(DefaultLifecycleExecutor.java:1185) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkProjectLifecy cle(DefaultLifecycleExecutor.java:1028) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.forkLifecycle(Def aultLifecycleExecutor.java:1009) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:627) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone Goal(DefaultLifecycleExecutor.java:553) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:523) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:371) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:332) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:181) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:356) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:137) at org.apache.maven.cli.MavenCli.main(MavenCli.java:356) We're using maven 2.1.0 with Java 1.5.0 Thanks for any help you can provide. Jeffrey Hagelberg, Software Engineer XMeta Development IBM Software Group Phone: 978-899-2055 T/L:276-2055) Email:jnhag...@us.ibm.com
Re: Dynamically Modifying the Classpath
Hmm. That might wok, although we really don't need these artifacts to be installed and deployed. We just need them as dependencies. Ideally, though, we'd want the list to be computed dynamically. It is quite big, and we don't have a whole lot of control over it. We don't want to have to update the pom.xml every time it changes. There's still the question of getting directories on the classpath. The directory we need is created during the pre-integration-test phase, so I don't think that adding it as a test resource would work, since the resource copying would happen before the directory is created. Any ideas about that? -Jeff Jeffrey Hagelberg, Software Engineer XMeta Development IBM Software Group Phone: 978-899-2055 T/L:276-2055) Email:jnhag...@us.ibm.com From: Kalle Korhonen To: Maven Users List Date: 05/09/2009 04:16 AM Subject:Re: Dynamically Modifying the Classpath On Fri, May 8, 2009 at 6:56 PM, Jeffrey N Hagelberg wrote: > We are trying to find a way to add some jars that are generated during the > pre-integration-test phase to the class path when the integration tests > run. There is also a folder with configuration files that is created at > the same time that we also need to add to the class path. The jar and > directory are both built programatically by another plugin, and maven does > not know anything about them. Does anyone know a way to do this? Instead of making things more complicated, why wouldn't you just let Maven know about these secondary artifacts with the help of build-helper plugin ( http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.html )? Kalle > I have an idea about how to do this, but it is rather convoluted. My idea > is to create a plugin that basically calls "mvn install:install-file" on > each jar to put it in the local maven repository and then programatically > add the jars as a dependencies of the project by adding artifacts for them > to the list returned by project.getDependencies(). My plan is to make the > plugin invoke the install:install-file plugin by doing something similar to > what the maven invoker plugin does. I don't think we can do this by using > install:install-file plugin directly because we don't know ahead of time > what the exact set of jars will be. We want to add jars in a certain > directory whose name matches a certain pattern. There's also the fact that > it would have to happen during the pre-integration-test phase, and as far > as I know the execution order is undefined for goals executing in different > execution groups within the same phase. That is, I don't think you can't > tell whether the executions for plugin1 or plugin2 will happen first if > they are both in the same phase. We can't have this run before the jars > are generated! I'd love to find out I'm wrong about this, though. > > As for adding the directory to the classpath, I am somewhat at a loss. If > the folder was created earler, I think we could add it as a test resource. > However, I think that the copying happens before the pre-integration-test > phase. Right now, the only thing I can think of is to manually copy the > contents of the folder into the test-classes directory where the compiled > classes are. Does anyone have any other ideas? > > Does anyone know to do these things or if what I suggested above will work? > > We're using maven 2.1.0. > > Thanks in advance for any help you can provide. > > -Jeff > > Jeffrey Hagelberg, Software Engineer > XMeta Development > IBM Software Group > Phone: 978-899-2055 T/L:276-2055) > Email:jnhag...@us.ibm.com
Dynamically Modifying the Classpath
Hi, We are trying to find a way to add some jars that are generated during the pre-integration-test phase to the class path when the integration tests run. There is also a folder with configuration files that is created at the same time that we also need to add to the class path. The jar and directory are both built programatically by another plugin, and maven does not know anything about them. Does anyone know a way to do this? I have an idea about how to do this, but it is rather convoluted. My idea is to create a plugin that basically calls "mvn install:install-file" on each jar to put it in the local maven repository and then programatically add the jars as a dependencies of the project by adding artifacts for them to the list returned by project.getDependencies(). My plan is to make the plugin invoke the install:install-file plugin by doing something similar to what the maven invoker plugin does. I don't think we can do this by using install:install-file plugin directly because we don't know ahead of time what the exact set of jars will be. We want to add jars in a certain directory whose name matches a certain pattern. There's also the fact that it would have to happen during the pre-integration-test phase, and as far as I know the execution order is undefined for goals executing in different execution groups within the same phase. That is, I don't think you can't tell whether the executions for plugin1 or plugin2 will happen first if they are both in the same phase. We can't have this run before the jars are generated! I'd love to find out I'm wrong about this, though. As for adding the directory to the classpath, I am somewhat at a loss. If the folder was created earler, I think we could add it as a test resource. However, I think that the copying happens before the pre-integration-test phase. Right now, the only thing I can think of is to manually copy the contents of the folder into the test-classes directory where the compiled classes are. Does anyone have any other ideas? Does anyone know to do these things or if what I suggested above will work? We're using maven 2.1.0. Thanks in advance for any help you can provide. -Jeff Jeffrey Hagelberg, Software Engineer XMeta Development IBM Software Group Phone: 978-899-2055 T/L:276-2055) Email:jnhag...@us.ibm.com
Jeffrey N Hagelberg is out of the office.
I will be out of the office starting 10/02/2008 and will not return until 10/14/2008.
Jeffrey N Hagelberg is out of the office.
I will be out of the office starting 10/02/2008 and will not return until 10/14/2008. I am on vacation for the holidays. I will respond to your message when I return. If it is something urgent, call my cell phone at 530-902-7638.
Cannot Get Reports for Surefire Report Plugin
Hello everyone, When I execute, mvn site -Dmaven.test.skip=true -e for the top-level project, I get the following: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error getting reports from the plugin 'org.apache.maven.plugins:maven-surefire-report-plugin': Unable to find the mojo 'org.apache.maven.plugins:maven-surefire-report-plugin:2.4.2:report' in the plugin 'org.apache.maven.plugins:maven-surefire-report-plugin' Component descriptor cannot be found in the component repository: org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-surefire-report-plugin:2.4.2:report. [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error getting reports from the plugin 'org.apache.maven.plugins:maven-surefire-report-plugin': Unable to find the mojo 'org.apache.maven.plugins:maven-surefire-report-plugin:2.4.2:report' in the plugin 'org.apache.maven.plugins:maven-surefire-report-plugin' at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports (DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports (DefaultLifecycleExecutor.java:642) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals (DefaultLifecycleExecutor.java:517) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle (DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal (DefaultLifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures (DefaultLifecycleExecutor.java:311): at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments (DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLifecycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126) at org.apache.maven.cli.MavenCli.main(MavenCli.java:282) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:79) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:618) 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) Caused by: org.apache.maven.plugin.PluginManagerException: Unable to find the mojo 'org.apache.maven.plugins:maven-surefire-report-plugin:2.4.2:report' in the plugin 'org.apache.maven.plugins:maven-surefire-report-plugin' at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo (DefaultPluginManager.java:575) at org.apache.maven.plugin.DefaultPluginManager.getReport (DefaultPluginManager.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getReports (DefaultLifecycleExecutor.java:683) ... 18 more Caused by: org.codehaus.plexus.component.repository.exception.ComponentLookupException: Component descriptor cannot be found in the component repository: org.apache.maven.plugin.Mojoorg.apache.maven.plugins:maven-surefire-report-plugin:2.4.2:report. at org.codehaus.plexus.DefaultPlexusContainer.lookup (DefaultPlexusContainer.java:323): at org.codehaus.plexus.DefaultPlexusContainer.lookup (DefaultPlexusContainer.java:312): at org.codehaus.plexus.DefaultPlexusContainer.lookup (DefaultPlexusContainer.java:440): at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo (DefaultPluginManager.java:566) ... 20 more This causes maven to fail. The failure actually happens in the first subproject encountered that has junit tests in it. That is, the site actually is generated for some of the projects. None of those projects have any junit tests in them, though. I've tried wiping out %USERPROFILE%/.m2/repository, but the result is always the same. I have also removed the use of our own maven respository in the hope that would help. All of the plugins were downloaded from the default maven repository, http://repo1.maven.org/maven2. The only thing I can think of that might cause this is that in one of the subprojects we have a dependency on version 2.4.2 of maven-surefire-report-plugin. We are using this to parse the XML junit test reports in order to format them into a concise format that can be emailed out as part of our nightly build. (If you know of a better way to parse the xml, I would love to hear it. I'm very hesitant to remove th
Failure Detection within Plugin?
Hi, I am working on writing a Mojo that works as part of our nightly build. This plugin needs to be able to detect if there were any previous build failures and send out an email if there were. I'm trying to determine how do detect whether or not there were previous build failures. It looks like this information is stored in the ReactorManager, but I don't know how to get at that (or if it is even possible). Does anyone know how to get at it or a better way to know if any of the previous plugins that were run generated exceptions? Thanks, Jeff Hagelberg Jeffrey Hagelberg, Software Engineer Metadata Server (WMDSEE) IBM Software Group Phone:(508)599-7425(T/L:518-7425) Email:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
