Re: maven dashboard plugin problem
Hi, can you do a mvn dashboard:persist -e -Xmaven.log and send the log as attachment ? it's possible that the hibernate version (3.2.2) used in the dashboard is not compatible with Oracle XE pdurbha wrote: Hi, I am trying to use the maven-dashboard-plugin to store and display build metrics on the dashboard application from an Oracle XE database..but the metrics are not getting stored in the OracleXE database.. Isn't the maven-dashboard-pulgin compatible with the Oracle XE database? The architecture in the link below doesn't specify the kind of database.. http://mojo.codehaus.org/dashboard-maven-plugin/ Please advise. Thanks -- View this message in context: http://www.nabble.com/maven-dashboard-plugin-problem-tp20909443p20910353.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Creating a dependency pack jar
Hello Lilianne, I think you're right in thinking you need to use assembly, this link will probably help you move forwards: http://maven.apache.org/plugins/maven-assembly-plugin/descriptor-refs.html#jar-with-dependencies HTH, w On Tue, Dec 9, 2008 at 8:55 AM, Lilianne E. Blaze [EMAIL PROTECTED] wrote: Hello, First, I'm still pretty new to Maven, so it's quite possible I'm missing something obvious here. I have the following scenario (simplified) : one project/POM for the application, AppPom, one project which doesn't contain any sources, just declares dependencies, DepsPom, and a number of 3rd party dependencies. I need to have two jars, one for the application, one for all the dependencies - I need DepsPom to contain all the declared dependencies, unpacked and repacked into a single jar. I tried using Shade, the resulting jar looks fine, but it somehow messes up code completion in NetBeans. I'm guessing I need to use either Shade, or Assembly, but at the moment I'm pretty much stuck. Seeing as Maven is about convention over configuration, there must be some standard way of doing it? Could you please give me an example minimal .pom which takes two other libraries and merges them into one jar? Greetings, thanks in advance, L - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: Build fails for an empty test-jar with maven-jar-plugin 2.2
Did you even try looking for yourself... hint: it's on this page: http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html 2008/12/9 [EMAIL PROTECTED] ...and what´s the parameters name and options? Thanx, Torsten Stephen Connolly [EMAIL PROTECTED] 08.12.2008 12:52 Bitte antworten an Maven Users List users@maven.apache.org An Maven Users List users@maven.apache.org Kopie Thema Re: Build fails for an empty test-jar with maven-jar-plugin 2.2 afaik there is a parameter you can set to allow empty jars 2008/12/8 [EMAIL PROTECTED] Hi, I have a parent pom.xml with packaging pom and some child modules in the modules section, defining: build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId version2.2/version configuration archive addMavenDescriptorfalse/addMavenDescriptor /archive /configuration executions execution goals goaltest-jar/goal /goals /execution /executions /plugin When I switch from 2.1 to 2.2 to get rid of http://jira.codehaus.org/browse/MJAR-30, I now get [ERROR] BUILD ERROR [INFO] [INFO] Error assembling JAR Embedded error: You must set at least one file. [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error assembling JAR at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:583) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) 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:585) 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.MojoExecutionException: Error assembling JAR at org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:225) at org.apache.maven.plugin.jar.AbstractJarMojo.execute(AbstractJarMojo.java:237) at org.apache.maven.plugin.jar.TestJarMojo.execute(TestJarMojo.java:85) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) ... 16 more Caused by: org.codehaus.plexus.archiver.ArchiverException: You must set at least one file. at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:260) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:242) at org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:673) at org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:421) at org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:218) ... 20 more I guess this is the same issue mentioned in http://jira.codehaus.org/browse/MJAR-105 - except for the packaging type and the goal? Will there a fix be available, soon ? Or at least a workaround in the meantime ? Thanx very much, Torsten
Keep version when doing a release
Hi, I have a multi module project that I want to make a release for. Some of the modules changes frequently and they are marked as SNAPSHOTS. Some modules are very stable and have a fixed version. I run maven 2 release plug-in 2.0-beta-7 with the --batch-mode parameter. The problem is that the stable modules will also have there version upgraded. Is there any way to tell the plug-in to only change version for SNAPSHOT modules? /Gunnar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven lifecycle - Is there a run-only-once-in-a-lifetime phase?
I am using Maven-2.0.9. In my project, i have a parent pom and n child poms. Something like this: Parent POM: modules modulechild-one/module modulechild-two/module /modules build plugin artifactIdmaven-antrun-plugin/artifactId executions execution iddoSomething/id !-- Do something here -- phaseinstall/phase configuration tasks /tasks /configuration goals goalrun/goal /goals /execution /executions /plugin /build Note the execution which will be run during install phase of each module (child-one, child-two etc...). I am looking for a phase which will be run only once during the lifetime of the maven build process. Or is there some way i can make the plugin run only once during the build, even if the child modules inherit them? -- View this message in context: http://www.nabble.com/Maven-lifecycle---Is-there-a-%22run-only-once-in-a-lifetime%22-phase--tp20913469p20913469.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keep version when doing a release
You will run into problems having non-SNAPSHOT versions... You do know that Maven will refuse to re-deploy non-SNAPSHOT versions... and it refuses silently... so any changes to a non-SNAPSHOT module will not actually be picked up by any build on another machine... or to put it another way: Danger! Will Robinson! Danger! 2008/12/9 [EMAIL PROTECTED] Hi, I have a multi module project that I want to make a release for. Some of the modules changes frequently and they are marked as SNAPSHOTS. Some modules are very stable and have a fixed version. I run maven 2 release plug-in 2.0-beta-7 with the --batch-mode parameter. The problem is that the stable modules will also have there version upgraded. Is there any way to tell the plug-in to only change version for SNAPSHOT modules? /Gunnar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keep version when doing a release
Hi You need a trunk to each module you want to release individually /Anders On 09/12/2008, at 11.02, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi, I have a multi module project that I want to make a release for. Some of the modules changes frequently and they are marked as SNAPSHOTS. Some modules are very stable and have a fixed version. I run maven 2 release plug-in 2.0-beta-7 with the --batch-mode parameter. The problem is that the stable modules will also have there version upgraded. Is there any way to tell the plug-in to only change version for SNAPSHOT modules? /Gunnar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keep version when doing a release
[EMAIL PROTECTED] wrote: I have a multi module project that I want to make a release for. Some of the modules changes frequently and they are marked as SNAPSHOTS. Some modules are very stable and have a fixed version. I run maven 2 release plug-in 2.0-beta-7 with the --batch-mode parameter. The problem is that the stable modules will also have there version upgraded. Is there any way to tell the plug-in to only change version for SNAPSHOT modules? Break up your multi module project into a smaller set of multi module projects. I had a project like this a while back, and I defined some variables in the super pom of multi module project B to point at the version number of multi module project A. This eliminated confusion over what relied on what, and ensured that the dependency was defined in just one place only. The more code you release at one time, the more difficult it is to tell where a bug might lie. Spin off the stable stuff into their own release cycles, and your troubleshooting problems will become significantly less, as a problem will most likely be caused by a smaller subset of newly released code. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Testing an archetype during build process
Hi all, in my Magma Apache Lab I'm building some Maven archetypes during the main build process, and everything is working fine. Anyway, from time to time, an archetype stops working properly due to a refactoring, like a class or package name change, or some other similar event. What I'd like to do is to test these archetypes during the build process. The first and easier test would be to actually use them to create a mock project and see it build properly, even eventually testing itself and propagating the failure to the main build process. I found in this mailing list only one thread dealing with archetype testing, and it was invoking another mvn command, on a temporary directory i suppose. Also, they were suggesting to use the Shitty plugin, which actually builds some other projects to run integration tests. I think a possible solution could be to use the maven-embedder called from a Junit test. This would give all the flexibility to run even more than one build cycle (for example with different parameters) and/or to perform more checks after the project has been created or built. What I'd like to know from you all is : - have you found any other nice way of testing an archetype? - is there an interest in this or am I the only paranoid searching for such a solution? :D - would it make sense to you to make at least the build-it test the default test phase during archetype build? (I'm planning a contribution here :) ) Let me know what you think about it. Simone -- Simone GianniCEO Semeru s.r.l. Apache Committer http://www.simonegianni.it/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven lifecycle - Is there a run-only-once-in-a-lifetime phase?
On Tue, Dec 9, 2008 at 7:07 AM, Jaikiran [EMAIL PROTECTED] wrote: Note the execution which will be run during install phase of each module (child-one, child-two etc...). I am looking for a phase which will be run only once during the lifetime of the maven build process. Or is there some way i can make the plugin run only once during the build, even if the child modules inherit them? Try plugininheritedfalse/inherited... http://maven.apache.org/ref/2.0.9/maven-model/maven.html#class_plugin -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Release Plugin Question
I would like some confirmation as to if my expectations as to how the release plugin is supposed work are correct. I expect the release plugin to change the version number in the dependency section for snapshots when it asks me to resolve the dependencies and I answer yes. Let me try to give you a concrete example. Take the following pom.xml for project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdcom.xco/groupId artifactIdmain-jar/artifactId version1.0-SNAPSHOT/version packagingjar/packaging namemainjar/name descriptionThis is the main jar./description scm connectionscm:svn:http://svn-server/repos/productA/trunk/main/main-jar/connection developerConnectionscm:svn:http://svn-server/repos/productA/trunk/main/main-jar/developerConnection tagHEAD/tag urlhttp://svn-server/websvn/listing.php?repname=repos/url /scm dependencies dependency groupIdxml-apis/groupId artifactIdxml-apis/artifactId version1.3.03/version scopecompile/scope /dependency dependency groupIdcom.abc/groupId artifactIddependent-jar-a/artifactId version1.0-SNAPSHOT/version scopecompile/scope /dependency dependency groupIdcom.abc/groupId artifactIddependent-jar-b/artifactId version1.0-SNAPSHOT/version /dependency /dependencies /project by running mvn release:prepare I would expect the pom.xml in the tagged location and in the trunk location to look like the following after it asks me to resolve the dependencies. Tagged pom.xml project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdcom.xco/groupId artifactIdmain-jar/artifactId version1.0/version packagingjar/packaging namemainjar/name descriptionThis is the main jar./description scm connectionscm:svn:http://svn-server/repos/productA/trunk/main/main-jar/connection developerConnectionscm:svn:http://svn-server/repos/productA/trunk/main/main-jar/developerConnection tagHEAD/tag urlhttp://svn-server/websvn/listing.php?repname=repos/url /scm dependencies dependency groupIdxml-apis/groupId artifactIdxml-apis/artifactId version1.3.03/version scopecompile/scope /dependency dependency groupIdcom.abc/groupId artifactIddependent-jar-a/artifactId version1.0/version scopecompile/scope /dependency dependency groupIdcom.abc/groupId artifactIddependent-jar-b/artifactId version1.0/version /dependency /dependencies /project Trunk Pom.xml project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd; modelVersion4.0.0/modelVersion groupIdcom.xco/groupId artifactIdmain-jar/artifactId version1.1-SNAPSHOT/version packagingjar/packaging namemainjar/name descriptionThis is the main jar./description scm connectionscm:svn:http://svn-server/repos/productA/trunk/main/main-jar/connection developerConnectionscm:svn:http://svn-server/repos/productA/trunk/main/main-jar/developerConnection tagHEAD/tag urlhttp://svn-server/websvn/listing.php?repname=repos/url /scm dependencies dependency groupIdxml-apis/groupId artifactIdxml-apis/artifactId version1.3.03/version scopecompile/scope /dependency dependency groupIdcom.abc/groupId artifactIddependent-jar-a/artifactId version1.1-SNAPSHOT/version scopecompile/scope /dependency dependency groupIdcom.abc/groupId artifactIddependent-jar-b/artifactId version1.1-SNAPSHOT/version /dependency /dependencies /project Are my assumptions about the release plugin correct or do I have to change the dependencies manually? Thanks Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Plugin Question
On Tue, Dec 9, 2008 at 9:40 AM, Thomas Jackson [EMAIL PROTECTED] wrote: I expect the release plugin to change the version number in the dependency section for snapshots when it asks me to resolve the dependencies and I answer yes. Let me try to give you a concrete example. Unfortunately - and everyone who learns the release plugin ends up having to learn this the hard way - a large part of the 'resolve these dependencies' bit does not work so well. Browsing the release plugin's open defects will convince you of this fact. I hope to spend some time next year trying to help out with some of this myself, because it's frustrating. The release plugin will happily keep snapshot dependencies up to date, assuming they are dependencies on artifacts you're -also releasing within the same lifecycle-. Otherwise - it is best to resolve them by hand for now. (My usual procedure is to run release:prepare, and if it finds any SNAPSHOT dependencies left unresolved, Ctrl-C, mvn release:clean, resolve them by hand, repeat as necessary. You also need to check the file for the word SNAPSHOT anyway, because there's a known problem where it does not detect SNAPSHOT plugin-level dependencies.) - John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[MASSEMBLY-285] duplicates in JAR
Hi everyone, I tried to use this plugin (2.2-beta2 I believe, also tried 2.2-beta3-SNAPSHOT, wouldn't resolve all depenencies :-( ) recently and ran into the same problems as mentioned in the referenced JIRA issue (some artifacts end up twice in JAR). This is not only a minor bug to me, because after the assembly goal I try to sign the resulting JAR, which momentarily always fails. It doesn't allow duplicate files at all. So, I'm stuck. Any suggestions? Please! Thanks Stephan -- View this message in context: http://www.nabble.com/-MASSEMBLY-285--duplicates-in-JAR-tp20917947p20917947.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: Re: Re: Build fails for an empty test-jar with maven-jar-plugin 2.2
Hi, I looked for myself - otherwise i would not adress to the mailing-list or and I wouldn´t have found the JIRA issues concerning that problem... Thanx for your hint - but there´s nothing about empty jar on this page - i guess you mean forceCreation - but that doesn´t change the behaviour. = So again - is there a solution, please ? Thanx, Torsten Stephen Connolly [EMAIL PROTECTED] 09.12.2008 10:08 Bitte antworten an Maven Users List users@maven.apache.org An Maven Users List users@maven.apache.org Kopie Thema Re: Re: Build fails for an empty test-jar with maven-jar-plugin 2.2 Did you even try looking for yourself... hint: it's on this page: http://maven.apache.org/plugins/maven-jar-plugin/test-jar-mojo.html 2008/12/9 [EMAIL PROTECTED] ...and what´s the parameters name and options? Thanx, Torsten Stephen Connolly [EMAIL PROTECTED] 08.12.2008 12:52 Bitte antworten an Maven Users List users@maven.apache.org An Maven Users List users@maven.apache.org Kopie Thema Re: Build fails for an empty test-jar with maven-jar-plugin 2.2 afaik there is a parameter you can set to allow empty jars 2008/12/8 [EMAIL PROTECTED] Hi, I have a parent pom.xml with packaging pom and some child modules in the modules section, defining: build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId version2.2/version configuration archive addMavenDescriptorfalse/addMavenDescriptor /archive /configuration executions execution goals goaltest-jar/goal /goals /execution /executions /plugin When I switch from 2.1 to 2.2 to get rid of http://jira.codehaus.org/browse/MJAR-30, I now get [ERROR] BUILD ERROR [INFO] [INFO] Error assembling JAR Embedded error: You must set at least one file. [INFO] [INFO] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error assembling JAR at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:583) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) 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:585) 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.MojoExecutionException: Error assembling JAR at org.apache.maven.plugin.jar.AbstractJarMojo.createArchive(AbstractJarMojo.java:225) at org.apache.maven.plugin.jar.AbstractJarMojo.execute(AbstractJarMojo.java:237) at org.apache.maven.plugin.jar.TestJarMojo.execute(TestJarMojo.java:85) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558) ... 16 more Caused by: org.codehaus.plexus.archiver.ArchiverException: You must set at least one file. at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.createArchiveMain(AbstractZipArchiver.java:260) at org.codehaus.plexus.archiver.zip.AbstractZipArchiver.execute(AbstractZipArchiver.java:242) at
Re: Reusing assembly descriptors aka. sharing them between projects
Excellent John!! That's exactly what I was looking for. I definitely need to read through the Sonatype book completely. John Stoneham wrote: Off the top of my head the only viable idea I have is to deploy it in a zip to the Maven repo and use dependency plugin to resolve and unpack before assembly step. Any caveats to that idea? None that I am aware of. This is the approach generally used for sharing configurations for Checkstyle etc across projects, so I think it makes sense to use in this case as well. Make a standard JAR project, and put the descriptor in src/main/resources/assemblies. (The 'assemblies' bit is important.) Build. Add that artifact as a plugin-level dependency of the assembly plugin for your project. Now, you can use it as a descriptorRef, just like jar-with-dependencies. http://books.sonatype.com/maven-book/reference/assemblies.html#d0e16265 has step-by-step instructions. - John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Reusing-assembly-descriptors-aka.-sharing-them-between-projects-tp20905611p20918021.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Deploying a multi-module bundle without including the bundle's dependencies...
Thanks. That did the trick. The optional dependency example in the book implied that *one* of the optional dependencies is required by the upstream project - so did not think it would solve my problem. Thanks again. -Original Message- From: Dan Tran [mailto:[EMAIL PROTECTED] Sent: Saturday, December 06, 2008 2:24 AM To: Maven Users List Subject: Re: Deploying a multi-module bundle without including the bundle's dependencies... My problem is that using the bundle jar or bundle test jar as a dependency in another project will pull in not only the bundle jar but all of the individual jars that are part of the bundle jar. Make the dependencies of the bundle project optional ( ie optinaltrue/optional -D On Fri, Dec 5, 2008 at 4:12 PM, Brian Whipple [EMAIL PROTECTED] wrote: I have a multi-module project parent project that contains multiple child projects. I want to distribute a single jar that is a bundle or aggregation of all the child project Java classes. In addition, I want to distribute a test jar that is a bundle or aggregation of all the child project test Java classes. I have used Maven: The Definitive Guide Chapter 12 Maven Assemblies - Best Practices as a template and have created two custom assembly descriptors and two child bundle projects. One bundles all the peer projects with Java classes as dependencies and the other all the peer projects with test Java classes as dependencies. So now my maven release releases all the child projects and the two bundle projects that contain correctly assembled jars. My problem is that using the bundle jar or bundle test jar as a dependency in another project will pull in not only the bundle jar but all of the individual jars that are part of the bundle jar. I need to remove the individual child projects as dependencies for the deployed bundle artifact. What is the best way to accomplish this? To re-word the question: if I want to create a single library (jar) from a multi-module maven project how can I prevent the child modules from being duplicated dependencies of the bundle library? Chapter 12 seems to show an example of this scenario under Distribution (Aggregating) Assemblies. In that example, how can you distribute the app-distribution project without pulling in the bundled artifacts (app-core, app-web, app-addons) as separate individual artifacts? Thanks in advance for any help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven Jaxb plugin?
I searched for a maven jaxb plugin and found xjc-maven-plugin but it is not documented. Does anyone have an example of generating an xsd from xml and then the java objects from xsd? Does anyone know why this plugin is not documented? -- View this message in context: http://www.nabble.com/Maven-Jaxb-plugin--tp20918118p20918118.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Plugin Question
:( bummer... I think there should be a notice somewhere in this plugin site. I think this plugin is one of the best maven seller. I have a big multi-module project and was counting on this feature when performing a release (fault's on me for not trying first, I will try later today if possible, just to be sure). On Tuesday 09 December 2008 11:10:23 John Stoneham wrote: On Tue, Dec 9, 2008 at 9:40 AM, Thomas Jackson [EMAIL PROTECTED] wrote: I expect the release plugin to change the version number in the dependency section for snapshots when it asks me to resolve the dependencies and I answer yes. Let me try to give you a concrete example. Unfortunately - and everyone who learns the release plugin ends up having to learn this the hard way - a large part of the 'resolve these dependencies' bit does not work so well. Browsing the release plugin's open defects will convince you of this fact. I hope to spend some time next year trying to help out with some of this myself, because it's frustrating. The release plugin will happily keep snapshot dependencies up to date, assuming they are dependencies on artifacts you're -also releasing within the same lifecycle-. Otherwise - it is best to resolve them by hand for now. (My usual procedure is to run release:prepare, and if it finds any SNAPSHOT dependencies left unresolved, Ctrl-C, mvn release:clean, resolve them by hand, repeat as necessary. You also need to check the file for the word SNAPSHOT anyway, because there's a known problem where it does not detect SNAPSHOT plugin-level dependencies.) - John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- David Ojeda
RE: Maven Jaxb plugin?
Try http://mojo.codehaus.org/jaxb2-maven-plugin/index.html For example: plugin groupIdorg.codehaus.mojo/groupId artifactIdjaxb2-maven-plugin/artifactId executions execution goals goalxjc/goal /goals /execution /executions configuration packageNamecom.acme/packageName /configuration /plugin -Original Message- From: CheapLisa [mailto:[EMAIL PROTECTED] Sent: 09 December 2008 16:33 To: users@maven.apache.org Subject: Maven Jaxb plugin? I searched for a maven jaxb plugin and found xjc-maven-plugin but it is not documented. Does anyone have an example of generating an xsd from xml and then the java objects from xsd? Does anyone know why this plugin is not documented? -- View this message in context: http://www.nabble.com/Maven-Jaxb-plugin--tp20918118p20918118.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Release Plugin Question
Is there still active development going on with this plugin? The potential of this plugin is very high but it doesn't seem to be quite there yet. --- Todd Thiessen -Original Message- From: David Ojeda [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 09, 2008 11:35 AM To: users@maven.apache.org Subject: Re: Release Plugin Question :( bummer... I think there should be a notice somewhere in this plugin site. I think this plugin is one of the best maven seller. I have a big multi-module project and was counting on this feature when performing a release (fault's on me for not trying first, I will try later today if possible, just to be sure). On Tuesday 09 December 2008 11:10:23 John Stoneham wrote: On Tue, Dec 9, 2008 at 9:40 AM, Thomas Jackson [EMAIL PROTECTED] wrote: I expect the release plugin to change the version number in the dependency section for snapshots when it asks me to resolve the dependencies and I answer yes. Let me try to give you a concrete example. Unfortunately - and everyone who learns the release plugin ends up having to learn this the hard way - a large part of the 'resolve these dependencies' bit does not work so well. Browsing the release plugin's open defects will convince you of this fact. I hope to spend some time next year trying to help out with some of this myself, because it's frustrating. The release plugin will happily keep snapshot dependencies up to date, assuming they are dependencies on artifacts you're -also releasing within the same lifecycle-. Otherwise - it is best to resolve them by hand for now. (My usual procedure is to run release:prepare, and if it finds any SNAPSHOT dependencies left unresolved, Ctrl-C, mvn release:clean, resolve them by hand, repeat as necessary. You also need to check the file for the word SNAPSHOT anyway, because there's a known problem where it does not detect SNAPSHOT plugin-level dependencies.) - John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- David Ojeda - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Plugin Question
On Tue, Dec 9, 2008 at 12:14 PM, Todd Thiessen [EMAIL PROTECTED] wrote: Is there still active development going on with this plugin? The potential of this plugin is very high but it doesn't seem to be quite there yet. Certainly it's still active, but plugin dev tends to go in cycles. Someone will get interested in one, knock out some issues, attract some other devs with the activity, and then we'll have a release, after which that one goes quiet for a while. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Plugin Question
IMO, if you have one of the dependencies that is SNAPSHOT and which is not part of you whole Maven build, the release plugin should complain and stop. Jeff MAURY On Tue, Dec 9, 2008 at 7:08 PM, Wendy Smoak [EMAIL PROTECTED] wrote: On Tue, Dec 9, 2008 at 12:14 PM, Todd Thiessen [EMAIL PROTECTED] wrote: Is there still active development going on with this plugin? The potential of this plugin is very high but it doesn't seem to be quite there yet. Certainly it's still active, but plugin dev tends to go in cycles. Someone will get interested in one, knock out some issues, attract some other devs with the activity, and then we'll have a release, after which that one goes quiet for a while. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- La mélancolie c'est communiste Tout le monde y a droit de temps en temps La mélancolie n'est pas capitaliste C'est même gratuit pour les perdants La mélancolie c'est pacifiste On ne lui rentre jamais dedans La mélancolie oh tu sais ça existe Elle se prend même avec des gants La mélancolie c'est pour les syndicalistes Il faut juste sa carte de permanent Miossec (2006) http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.lastfm.fr/listen/user/jeffmaury/personal Mes CDs à récupérer: http://spreadsheets.google.com/ccc?key=pNeg4Doa_oCsh7CepKPaPTAhl=en
RE: Maven Jaxb plugin?
thanks! I was able to get a little further but got this error message: [ERROR] null[-1,-1] java.io.FileNotFoundException: project_home\jaxb\first\src\main\xsd (The system cannot find the file specified) I do not have a directory called /src/main/xsd/ I do have /src/main/resources/xsd. Is there a way to specify to the plugin where the xsd files are? I have a directory structure that I can not change. Adam Leggett wrote: Try http://mojo.codehaus.org/jaxb2-maven-plugin/index.html For example: plugin groupIdorg.codehaus.mojo/groupId artifactIdjaxb2-maven-plugin/artifactId executions execution goals goalxjc/goal /goals /execution /executions configuration packageNamecom.acme/packageName /configuration /plugin -Original Message- From: CheapLisa [mailto:[EMAIL PROTECTED] Sent: 09 December 2008 16:33 To: users@maven.apache.org Subject: Maven Jaxb plugin? I searched for a maven jaxb plugin and found xjc-maven-plugin but it is not documented. Does anyone have an example of generating an xsd from xml and then the java objects from xsd? Does anyone know why this plugin is not documented? -- View this message in context: http://www.nabble.com/Maven-Jaxb-plugin--tp20918118p20918118.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Maven-Jaxb-plugin--tp20918118p20920566.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven Jaxb plugin?
Another question, is there a maven2 plugin that will generate an XSD from XML ? thanks Lisa Adam Leggett wrote: Try http://mojo.codehaus.org/jaxb2-maven-plugin/index.html For example: plugin groupIdorg.codehaus.mojo/groupId artifactIdjaxb2-maven-plugin/artifactId executions execution goals goalxjc/goal /goals /execution /executions configuration packageNamecom.acme/packageName /configuration /plugin -Original Message- From: CheapLisa [mailto:[EMAIL PROTECTED] Sent: 09 December 2008 16:33 To: users@maven.apache.org Subject: Maven Jaxb plugin? I searched for a maven jaxb plugin and found xjc-maven-plugin but it is not documented. Does anyone have an example of generating an xsd from xml and then the java objects from xsd? Does anyone know why this plugin is not documented? -- View this message in context: http://www.nabble.com/Maven-Jaxb-plugin--tp20918118p20918118.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Maven-Jaxb-plugin--tp20918118p20920625.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Plugin Question
the versions maven plugin can help somewhat... though in this case, perhaps not perfectly Sent from my iPod On 9 Dec 2008, at 14:40, Thomas Jackson [EMAIL PROTECTED] wrote: I would like some confirmation as to if my expectations as to how the release plugin is supposed work are correct. I expect the release plugin to change the version number in the dependency section for snapshots when it asks me to resolve the dependencies and I answer yes. Let me try to give you a concrete example. Take the following pom.xml for project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd modelVersion4.0.0/modelVersion groupIdcom.xco/groupId artifactIdmain-jar/artifactId version1.0-SNAPSHOT/version packagingjar/packaging namemainjar/name descriptionThis is the main jar./description scm connectionscm:svn:http://svn-server/repos/productA/trunk/main/main-jar /connection developerConnectionscm:svn:http://svn-server/repos/productA/trunk/main/main-jar /developerConnection tagHEAD/tag urlhttp://svn-server/websvn/listing.php?repname=repos/url /scm dependencies dependency groupIdxml-apis/groupId artifactIdxml-apis/artifactId version1.3.03/version scopecompile/scope /dependency dependency groupIdcom.abc/groupId artifactIddependent-jar-a/artifactId version1.0-SNAPSHOT/version scopecompile/scope /dependency dependency groupIdcom.abc/groupId artifactIddependent-jar-b/artifactId version1.0-SNAPSHOT/version /dependency /dependencies /project by running mvn release:prepare I would expect the pom.xml in the tagged location and in the trunk location to look like the following after it asks me to resolve the dependencies. Tagged pom.xml project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd modelVersion4.0.0/modelVersion groupIdcom.xco/groupId artifactIdmain-jar/artifactId version1.0/version packagingjar/packaging namemainjar/name descriptionThis is the main jar./description scm connectionscm:svn:http://svn-server/repos/productA/trunk/main/main-jar /connection developerConnectionscm:svn:http://svn-server/repos/productA/trunk/main/main-jar /developerConnection tagHEAD/tag urlhttp://svn-server/websvn/listing.php?repname=repos/url /scm dependencies dependency groupIdxml-apis/groupId artifactIdxml-apis/artifactId version1.3.03/version scopecompile/scope /dependency dependency groupIdcom.abc/groupId artifactIddependent-jar-a/artifactId version1.0/version scopecompile/scope /dependency dependency groupIdcom.abc/groupId artifactIddependent-jar-b/artifactId version1.0/version /dependency /dependencies /project Trunk Pom.xml project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd modelVersion4.0.0/modelVersion groupIdcom.xco/groupId artifactIdmain-jar/artifactId version1.1-SNAPSHOT/version packagingjar/packaging namemainjar/name descriptionThis is the main jar./description scm connectionscm:svn:http://svn-server/repos/productA/trunk/main/main-jar /connection developerConnectionscm:svn:http://svn-server/repos/productA/trunk/main/main-jar /developerConnection tagHEAD/tag urlhttp://svn-server/websvn/listing.php?repname=repos/url /scm dependencies dependency groupIdxml-apis/groupId artifactIdxml-apis/artifactId version1.3.03/version scopecompile/scope /dependency dependency groupIdcom.abc/groupId artifactIddependent-jar-a/artifactId version1.1-SNAPSHOT/version scopecompile/scope /dependency dependency groupIdcom.abc/groupId artifactIddependent-jar-b/artifactId version1.1-SNAPSHOT/version /dependency /dependencies /project Are my assumptions about the release plugin correct or do I have to change the dependencies manually? Thanks Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Testing an archetype during build process
2008/12/9 Simone Gianni [EMAIL PROTECTED]: Hi all, in my Magma Apache Lab I'm building some Maven archetypes during the main build process, and everything is working fine. Anyway, from time to time, an archetype stops working properly due to a refactoring, like a class or package name change, or some other similar event. What I'd like to do is to test these archetypes during the build process. The first and easier test would be to actually use them to create a mock project and see it build properly, even eventually testing itself and propagating the failure to the main build process. Can you please explain me like toa child what you try to do. during, your build, you have some sample projects that you turn into archetype using the create-from-project goal, and would like to run these archetype into new projects an then run some tests on theses new projects in order to check that your archetypes are in sync with your libraries ? Raphaël I found in this mailing list only one thread dealing with archetype testing, and it was invoking another mvn command, on a temporary directory i suppose. Also, they were suggesting to use the Shitty plugin, which actually builds some other projects to run integration tests. I think a possible solution could be to use the maven-embedder called from a Junit test. This would give all the flexibility to run even more than one build cycle (for example with different parameters) and/or to perform more checks after the project has been created or built. What I'd like to know from you all is : - have you found any other nice way of testing an archetype? - is there an interest in this or am I the only paranoid searching for such a solution? :D - would it make sense to you to make at least the build-it test the default test phase during archetype build? (I'm planning a contribution here :) ) Let me know what you think about it. Simone -- Simone GianniCEO Semeru s.r.l. Apache Committer http://www.simonegianni.it/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JavaDocs for Artifacts in repositories
Hi all! I am trying to understand a Best Behavior question. It is best illustrated by example. Here goes... 1) Let's say I am going to create a little test application (multi-module) that uses Spring. 2) I Create a directory ... MyTestSpringApplication.. and change to the command line. 3) While in the MyTestSpringApplication directory I run mvn archetype:generate. I do NOT even choose a number (default). My groupId is my.test. The packageName is the same, and the artifactId is springtest. 4) After a successful build I delete the src directory and change the packaging to pom in the created pom file. And cd to the springtest directory.. 5) In this directory I will run the mvn archetype:generate command twice. Once creating a default (jar) project named nonwebexamples. And then one for webapplications named webexamples. 6) I import these modules into my IDE (in this case INTELLIJ) and add to the parent pom the following: dependency groupIdorg.springframework/groupId artifactIdspring/artifactId version2.5.6/version /dependency 7)At this point both child modules are dependent on spring and JUnit 3.8.1(for testing). 8) Now for my QUESTION. Neither Spring NOR JUnit have imported the Javadoc jar for their artifacts (for download) so the IDEs could be configured easily. Obviously I could configure my IDE easily, but in a large project this would grow exponentially. Is there any way, to use maven to create the javadocs on the fly for my local repository, or some better way to handle this situation that I do not know of? Thanks in advance and sorry if this is a silly oft-answered question.. Mike Clovis -- View this message in context: http://www.nabble.com/JavaDocs-for-Artifacts-in-repositories-tp20921600p20921600.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [MASSEMBLY-285] duplicates in JAR
We have run into the same problems (duplicates causing failed attempts
at a signed JAR) and we ended up using excludes in an assembly.xml
descriptor file. It seemed as if the duplicates were from the .class
files and the created JAR of the current project both being included.
So we had something like this:
assembly
idjar-with-dependencies/id
formats
formatjar/format
/formats
includeBaseDirectoryfalse/includeBaseDirectory
dependencySets
dependencySet
unpacktrue/unpack
scoperuntime/scope
excludes
excludecom.mobilvox.upl:${project.artifactId}/exclude
/excludes
/dependencySet
/dependencySets
fileSets
fileSet
directorytarget/classes/directory
outputDirectory//outputDirectory
/fileSet
/fileSets
/assembly
Hope this helps,
Adam
On Tue, Dec 9, 2008 at 11:22 AM, stephanos [EMAIL PROTECTED] wrote:
Hi everyone,
I tried to use this plugin (2.2-beta2 I believe, also tried
2.2-beta3-SNAPSHOT, wouldn't resolve all depenencies :-( ) recently and ran
into the same problems as mentioned in the referenced JIRA issue (some
artifacts end up twice in JAR). This is not only a minor bug to me, because
after the assembly goal I try to sign the resulting JAR, which momentarily
always fails. It doesn't allow duplicate files at all.
So, I'm stuck. Any suggestions? Please!
Thanks
Stephan
--
View this message in context:
http://www.nabble.com/-MASSEMBLY-285--duplicates-in-JAR-tp20917947p20917947.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Plugin Question
To continue with the ideas/brainstorming, I think that it should ask for the stable version or complain and stop but there should be a separate goal that saves us the trouble of finding and replacing SNAPSHOT in poms... David On Tuesday 09 December 2008 13:49:31 Jeff MAURY wrote: IMO, if you have one of the dependencies that is SNAPSHOT and which is not part of you whole Maven build, the release plugin should complain and stop. Jeff MAURY On Tue, Dec 9, 2008 at 7:08 PM, Wendy Smoak [EMAIL PROTECTED] wrote: On Tue, Dec 9, 2008 at 12:14 PM, Todd Thiessen [EMAIL PROTECTED] wrote: Is there still active development going on with this plugin? The potential of this plugin is very high but it doesn't seem to be quite there yet. Certainly it's still active, but plugin dev tends to go in cycles. Someone will get interested in one, knock out some issues, attract some other devs with the activity, and then we'll have a release, after which that one goes quiet for a while. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- David Ojeda
Re: JavaDocs for Artifacts in repositories
8) Now for my QUESTION. Neither Spring NOR JUnit have imported the Javadoc jar for their artifacts (for download) so the IDEs could be configured easily. Obviously I could configure my IDE easily, but in a large project this would grow exponentially. Is there any way, to use maven to create the javadocs on the fly for my local repository, or some better way to handle this situation that I do not know of? You are free to download the Javadoc jar (or create it from the source code for the various dependencies) and use mvn install (or better, mvn deploy it to your corporate repo) to make the Javadoc available. Also, you can/should file bugs with the projects so they include Javadocs with their releases in the Maven repo in the future. Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Manifest Class-Path in WAR
Per the maven war plugin docs [1], I normally don't want a jar in both the manifest classpath and the WEB-INF/lib. This is true. I want the jars in WEB-INF/lib to specifically NOT be in the Class-Path of my war's MANIFEST.MF So I did what the documentation told me, built my war and the WEB-INF/lib dependencies *were* included in the manifest's Class-Path. On the doc page [1] it explicitly states Note that no way is shown to include a dependency in WEB-INF/lib but not the manifest classpath. Why and/or what am I doing wrong? Having WEB-INF/lib jars listed in a war's manifest Class-Path is redundant and could be problematic for oddly implemented or buggy app servers. Per my experience, it appears to be impossible to keep a jar included in WEB-INF/lib from having a manifest entry in the class path if you're actually generating the manifest class-path. Am I doing it wrong? Thanks Mykel [1] http://maven.apache.org/plugins/maven-war-plugin/examples/war-manifest-guide.html
How to run JUnit tests in sub-modules without surefire reference?
I want to run JUnit tests in every module and sub-module (some 5 deep), but I do not want to put a reference to the surefire plugin in every pom.xml in every module and sub-module (some 5 deep). How do I make this work? --- More Info I have a top level pom for all modules and use the parent tag in every module and sub-module (some 5 deep). In the top level pom, I have a reference to the surefire plugin, but this strategy does not seem to work. This is what I have: dir structure project_root/pom.xml = this is my parent pom project_root/module/sub_module/../pom.xml In this pom.xml (and in every sub-module pom - some 5 deep) I have: !-- reference to parent-pom in every sub-module - some 5 deep -- parent groupIdcom.acme/groupId artifactIdmy-parent-pom/artifactId version1.0/version /parent ... and later in the parent pome mentioned above I have the following: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId configuration haltOnFailuretrue/haltOnFailure skiptrue/skip useFilefalse/useFile /configuration /plugin I do not want this plugin section in every pom.xml in every sub-module (some 5 deep) How do I do this to make it go? -- View this message in context: http://www.nabble.com/How-to-run-JUnit-tests-in-sub-modules-without-surefire-reference--tp20924140p20924140.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Testing an archetype during build process
Hi Raphael, I have some archetypes. They are not generated during build, they are already there, made using the create-from-project originally and then updated and expanded by hand from time to time. Sometimes we do some refactoring here and there in the code, and while all other artifacts gets compiled before being installed/deployed, and the compiler warns if something is wrong, the archetypes are only packaged, so no check is performed to see if the sample java classes (and other stuff in them) are still valid. Then, from time time, some users tell us hey, I used the archetype to create a new project, but nothing is working, and we recall that we didn't updated the archetypes when we renamed that class, or that package, or that archetype, or whatever (we are still a lab, we still can change stuff pretty radically :D ) So, my idea is simply this, during the build, I could use the archetype to create a new project (in /tmp/ for example :D ), then try to build it, and see what the user see when they use our archetype. This way, at least the is a project produced using this archetype still working? question would be solved at every build. I already tried to do this invoking maven from inside the archetype pom, but I was thinking about using the maven embedder to run the archetype:create to generate the mock project, and then the compile or even the test goal to see if everything goes right. Afterall, I'm trying to determine if the final user of my archetype will be able to generate something functional out of it, or if I forgot something (a dependency, a refactoring, etc..). Moving it a step further, it would be nice if I could drive this from a junit test, making it simpler (we are all used to writing test, aren't we?) and giving me the flexibility to do whatever checks I want on the produced /tmp/ project. Basically I would make the lifecycle of the packaging archetype something like : - Generate the archetype - Generate e temp mock project using the archetype (run mvn archetype:create ) - Try to run mvn on the generated project (run at least mvn compile, but could even be mvn test or mvn install or anything the developer expects the user to do with the generated project) - Make sure the two steps above went ok :) - Then package it and install and deploy and everything Or, as an alternative : - Generate the archetype - Run junit tests - Give the developer a simple way to generate a temp mock project, see its content, run mvn on it, from the junit using the embedder or whatever else - Make sure junits went ok - Then package it and install and deploy and everything Or even both :) Simone Raphaël Piéroni wrote: 2008/12/9 Simone Gianni [EMAIL PROTECTED]: Hi all, in my Magma Apache Lab I'm building some Maven archetypes during the main build process, and everything is working fine. Anyway, from time to time, an archetype stops working properly due to a refactoring, like a class or package name change, or some other similar event. What I'd like to do is to test these archetypes during the build process. The first and easier test would be to actually use them to create a mock project and see it build properly, even eventually testing itself and propagating the failure to the main build process. Can you please explain me like toa child what you try to do. during, your build, you have some sample projects that you turn into archetype using the create-from-project goal, and would like to run these archetype into new projects an then run some tests on theses new projects in order to check that your archetypes are in sync with your libraries ? Raphaël I found in this mailing list only one thread dealing with archetype testing, and it was invoking another mvn command, on a temporary directory i suppose. Also, they were suggesting to use the Shitty plugin, which actually builds some other projects to run integration tests. I think a possible solution could be to use the maven-embedder called from a Junit test. This would give all the flexibility to run even more than one build cycle (for example with different parameters) and/or to perform more checks after the project has been created or built. What I'd like to know from you all is : - have you found any other nice way of testing an archetype? - is there an interest in this or am I the only paranoid searching for such a solution? :D - would it make sense to you to make at least the build-it test the default test phase during archetype build? (I'm planning a contribution here :) ) Let me know what you think about it. Simone -- Simone GianniCEO Semeru s.r.l. Apache Committer http://www.simonegianni.it/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Simone GianniCEO Semeru s.r.l. Apache Committer
Re: Testing an archetype during build process
2008/12/9 Simone Gianni [EMAIL PROTECTED]: Hi Raphael, I have some archetypes. They are not generated during build, they are already there, made using the create-from-project originally and then updated and expanded by hand from time to time. Is it possible to have a sample project and create the archetype on the fly or did you use some tricks, the goal can't do? Sometimes we do some refactoring here and there in the code, and while all other artifacts gets compiled before being installed/deployed, and the compiler warns if something is wrong, the archetypes are only packaged, so no check is performed to see if the sample java classes (and other stuff in them) are still valid. Then, from time time, some users tell us hey, I used the archetype to create a new project, but nothing is working, and we recall that we didn't updated the archetypes when we renamed that class, or that package, or that archetype, or whatever (we are still a lab, we still can change stuff pretty radically :D ) So, my idea is simply this, during the build, I could use the archetype to create a new project (in /tmp/ for example :D ), then try to build it, and see what the user see when they use our archetype. This way, at least the is a project produced using this archetype still working? question would be solved at every build. I already tried to do this invoking maven from inside the archetype pom, but I was thinking about using the maven embedder to run the archetype:create to generate the mock project, and then the compile or even the test goal to see if everything goes right. Afterall, I'm trying to determine if the final user of my archetype will be able to generate something functional out of it, or if I forgot something (a dependency, a refactoring, etc..). in the FilesetArchetypeCreator, i use the invoker to call package or install goal on the archetype newly generated project given you manage to create the tested project using the archetype, you can call whatever goal you like on that project with InvocationRequest internalRequest = new DefaultInvocationRequest(); internalRequest.setPomFile( pomFile ); internalRequest.setGoals( Collections.singletonList( test ) ); Invoker invoker = new DefaultInvoker(); invoker.execute(internalRequest); To create new project from archetype, in my tests, i directly the plexus components used by the plugin, i know the API ;-) In ArchetypeGenerationTest ArchetypeCatalog catalog = archetype.getLocalCatalog( new File( getBasedir(), target/test-classes/repositories/central ).getAbsolutePath() ); org.apache.maven.archetype.catalog.Archetype selection = (org.apache.maven.archetype.catalog.Archetype) catalog.getArchetypes().get( catalog.getArchetypes().size() - 1 ); ArchetypeGenerationRequest agr = new ArchetypeGenerationRequest( selection ) .setOutputDirectory( outputDirectory.getAbsolutePath() ) .setLocalRepository( localRepository ) .setGroupId( groupId ) .setArtifactId( artifactId ) .setVersion( version ) .setPackage( packageName ); Properties archetypeRequiredProperties = new Properties(); archetypeRequiredProperties.setProperty( property-without-default-1, some-value-1 ); agr.setProperties( archetypeRequiredProperties ); ArchetypeGenerationResult result = archetype.generateProjectFromArchetype( agr ); This is the usage of the hilevel api, there is also a low level api which don't require repository or catalog, only a jar file. Moving it a step further, it would be nice if I could drive this from a junit test, making it simpler (we are all used to writing test, aren't we?) and giving me the flexibility to do whatever checks I want on the produced /tmp/ project. Basically I would make the lifecycle of the packaging archetype something like : - Generate the archetype - Generate e temp mock project using the archetype (run mvn archetype:create ) - Try to run mvn on the generated project (run at least mvn compile, but could even be mvn test or mvn install or anything the developer expects the user to do with the generated project) - Make sure the two steps above went ok :) - Then package it and install and deploy and everything Or, as an alternative : - Generate the archetype - Run junit tests - Give the developer a simple way to generate a temp mock project, see its content, run mvn on it, from the junit using the embedder or whatever else - Make sure junits went ok - Then package it and install and deploy and everything Or even both :) Simone Do that fill some questions? Raphaël Raphaël Piéroni wrote: 2008/12/9 Simone Gianni [EMAIL PROTECTED]: Hi all, in my Magma Apache Lab I'm building some Maven archetypes during the main build process, and everything is working fine. Anyway, from time to
Re: How to run JUnit tests in sub-modules without surefire reference?
I do not want this plugin section in every pom.xml in every sub-module (some 5 deep) How do I do this to make it go? Generally, you should configure plugins like this in the pluginManagement section in the top parent, and then when you declare the plugin in each child, it will inherit the configuration from the parent. So the parent has the big configuration section in pluginMgmt, and the children just have: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId /plugin Of course, surefire is already declared in the super pom, so you shouldn't even need to include that in the children. Check mvn help:effective-pom in a child once you've added that configuration to the top parent -- it should show up. Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release aggregating parent poms
You can use the -N comand line option in the release plugin options and in the command line to not call the release for modules. The problem is that it will tag the parent pom and all submodules, which can be very long. Arnaud On Fri, Dec 5, 2008 at 12:36 PM, jallen [EMAIL PROTECTED] wrote: Could someone from the dev team possibly explain their process of releasing parent poms such as the maven-plugins. i see that the trunk of this includes modules for everything. However the release versions have this commented out. I presume this change is made just before a release is performed preventing the release plugin from processing the modules, which are not the things being 'released'. And then added again to the new SNAPSHOT version. Does this mean that the modules section in that pom is just developer aid and not a real part of the nature of that project., i.e. if we checkout a released version of maven-plugins we do not repeat the build that the trunk performs. I alsways get confused between the relationship and 'integration' of a parent, the indepence of children that can inherit from on older versions of the parent and the SCM domain (i.e. SVN will be copying all the child directories into the tag, even though they're not being released). couldnt find anything on the net explaining these kinds of scenarios and my head hurts from trying to anticipate the various pom relationships and ther overall dev and release lifecycle. Cheers, John -- View this message in context: http://www.nabble.com/Release-aggregating-parent-poms-tp20852139p20852139.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- .. Arnaud HERITIER 12 guidelines to boost your productivity with a Java software factory - http://tinyurl.com/56s9tw .. OCTO Technology - aheritier AT octo DOT com www.octo.com | blog.octo.com .. ASF - aheritier AT apache DOT org www.apache.org | maven.apache.org ...
Re: Testing an archetype during build process
I forgot, if you can always the archetype from the build with create-from-archetype, you can first call test on the project and trust the archetype plugin has not too much bugs (but it has some) Raphaël 2008/12/9 Raphaël Piéroni [EMAIL PROTECTED]: 2008/12/9 Simone Gianni [EMAIL PROTECTED]: Hi Raphael, I have some archetypes. They are not generated during build, they are already there, made using the create-from-project originally and then updated and expanded by hand from time to time. Is it possible to have a sample project and create the archetype on the fly or did you use some tricks, the goal can't do? Sometimes we do some refactoring here and there in the code, and while all other artifacts gets compiled before being installed/deployed, and the compiler warns if something is wrong, the archetypes are only packaged, so no check is performed to see if the sample java classes (and other stuff in them) are still valid. Then, from time time, some users tell us hey, I used the archetype to create a new project, but nothing is working, and we recall that we didn't updated the archetypes when we renamed that class, or that package, or that archetype, or whatever (we are still a lab, we still can change stuff pretty radically :D ) So, my idea is simply this, during the build, I could use the archetype to create a new project (in /tmp/ for example :D ), then try to build it, and see what the user see when they use our archetype. This way, at least the is a project produced using this archetype still working? question would be solved at every build. I already tried to do this invoking maven from inside the archetype pom, but I was thinking about using the maven embedder to run the archetype:create to generate the mock project, and then the compile or even the test goal to see if everything goes right. Afterall, I'm trying to determine if the final user of my archetype will be able to generate something functional out of it, or if I forgot something (a dependency, a refactoring, etc..). in the FilesetArchetypeCreator, i use the invoker to call package or install goal on the archetype newly generated project given you manage to create the tested project using the archetype, you can call whatever goal you like on that project with InvocationRequest internalRequest = new DefaultInvocationRequest(); internalRequest.setPomFile( pomFile ); internalRequest.setGoals( Collections.singletonList( test ) ); Invoker invoker = new DefaultInvoker(); invoker.execute(internalRequest); To create new project from archetype, in my tests, i directly the plexus components used by the plugin, i know the API ;-) In ArchetypeGenerationTest ArchetypeCatalog catalog = archetype.getLocalCatalog( new File( getBasedir(), target/test-classes/repositories/central ).getAbsolutePath() ); org.apache.maven.archetype.catalog.Archetype selection = (org.apache.maven.archetype.catalog.Archetype) catalog.getArchetypes().get( catalog.getArchetypes().size() - 1 ); ArchetypeGenerationRequest agr = new ArchetypeGenerationRequest( selection ) .setOutputDirectory( outputDirectory.getAbsolutePath() ) .setLocalRepository( localRepository ) .setGroupId( groupId ) .setArtifactId( artifactId ) .setVersion( version ) .setPackage( packageName ); Properties archetypeRequiredProperties = new Properties(); archetypeRequiredProperties.setProperty( property-without-default-1, some-value-1 ); agr.setProperties( archetypeRequiredProperties ); ArchetypeGenerationResult result = archetype.generateProjectFromArchetype( agr ); This is the usage of the hilevel api, there is also a low level api which don't require repository or catalog, only a jar file. Moving it a step further, it would be nice if I could drive this from a junit test, making it simpler (we are all used to writing test, aren't we?) and giving me the flexibility to do whatever checks I want on the produced /tmp/ project. Basically I would make the lifecycle of the packaging archetype something like : - Generate the archetype - Generate e temp mock project using the archetype (run mvn archetype:create ) - Try to run mvn on the generated project (run at least mvn compile, but could even be mvn test or mvn install or anything the developer expects the user to do with the generated project) - Make sure the two steps above went ok :) - Then package it and install and deploy and everything Or, as an alternative : - Generate the archetype - Run junit tests - Give the developer a simple way to generate a temp mock project, see its content, run mvn on it, from the junit using the embedder or whatever else - Make sure junits went ok - Then package it and install and deploy and everything Or even both :) Simone
Re: Release aggregating parent poms
You can use the -N comand line option in the release plugin options and in the command line to not call the release for modules. The problem is that it will tag the parent pom and all submodules, which can be very long. When I did this my problem was that release:perform didn't pass -N through to the subinvocation. - John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Release Plugin Question
IMO, if you have one of the dependencies that is SNAPSHOT and which is not part of you whole Maven build, the release plugin should complain and stop. Well, it does. It just then gives you a misleading, broken option to continue. I'd imagine the best fix, currently, might be to disable the pieces that don't work, and do exactly what you're saying. I can imagine some long email threads on maven-dev trying to decide precisely how it ought to be fixed. - John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Up-to-date release
Hi. We heavily use the Maven release plugin. Following scenario: * Developers update from SVN * Developer 1 commits a change * Developer 2 commits a change and releases (mvn release:prepare) Because developer 2 does not explicitly update from SVN, the change from developer 1 will not be in the release. Hard to track down, hard to detect. I've attempted adding stategies to check if the releasing developer (developer 2) is up-to-date, using buildnumber-maven-plugin. Unsuccessful, since release plugin does its own local modifications prior to running the buildnumber plugin. I know I can make a nice shell script to check this, but I would like to configure it in Maven, to make things mandatory and reproducible. Thanks for your ideas! Sander. -- View this message in context: http://www.nabble.com/Up-to-date-release-tp20925759p20925759.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Up-to-date release
Use Subversion 1.5 the release plugin is broken with svn 1.5 and will not make a release if the entire workspace is not 100% up to date ;-) (may be fixed in svn 1.5.4) 2008/12/9 sverhagen [EMAIL PROTECTED] Hi. We heavily use the Maven release plugin. Following scenario: * Developers update from SVN * Developer 1 commits a change * Developer 2 commits a change and releases (mvn release:prepare) Because developer 2 does not explicitly update from SVN, the change from developer 1 will not be in the release. Hard to track down, hard to detect. I've attempted adding stategies to check if the releasing developer (developer 2) is up-to-date, using buildnumber-maven-plugin. Unsuccessful, since release plugin does its own local modifications prior to running the buildnumber plugin. I know I can make a nice shell script to check this, but I would like to configure it in Maven, to make things mandatory and reproducible. Thanks for your ideas! Sander. -- View this message in context: http://www.nabble.com/Up-to-date-release-tp20925759p20925759.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Repo failover scenario
Hi, there. A while back we rendered our single internal repository (running Artifactory at the moment) basically unusable due to an expired certificate. That was a big scare. We had all developers do not much for a whole business day. Now looking for alternatives. I read that you can have repositories be each other's proxy. I suppose you put both repository servers in the list of mirrors that developers use. And I see how you could achieve failover for retrieving artifacts. But what about deploying new artifacts? We release anywhere between three and twenty components on a daily basis. I can't define mirrors for distributionManagement, which is fair enough, but how can Maven ever handle the distributionManagement server going down? Your help is appreciated. Thanks. Sander. -- View this message in context: http://www.nabble.com/Repo-failover-scenario-tp20925903p20925903.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Up-to-date release
On Tue, Dec 9, 2008 at 6:07 PM, sverhagen [EMAIL PROTECTED] wrote: Hi. We heavily use the Maven release plugin. Following scenario: * Developers update from SVN * Developer 1 commits a change * Developer 2 commits a change and releases (mvn release:prepare) Because developer 2 does not explicitly update from SVN, the change from developer 1 will not be in the release. Hard to track down, hard to detect. Have you actually had this happen? I'm pretty sure it's going to complain that the working copy isn't up to date when it tries to tag... Yep, it does: $ mvn release:prepare ... [INFO] Checking in modified POMs... [INFO] Executing: svn --non-interactive commit --file /tmp/maven-scm-1832181566.commit --targets /tmp/maven-scm-10681-targets [INFO] Working directory: /private/tmp/hello1 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Unable to commit files Provider message: The svn command failed. Command output: svn: Commit failed (details follow): svn: Your file or directory 'pom.xml' is probably out-of-date svn: resource out of date; try updating This is with Subversion 1.4.4 on OS X. Still, I'd suggest: Developer A communicates that a release is in progress/code freeze. Developer B holds commits, or one of them works on a branch. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Up-to-date release
Stephen Connolly-2 wrote: Use Subversion 1.5 the release plugin is broken with svn 1.5 and will not make a release if the entire workspace is not 100% up to date Hi, Stephen. Thanks for your prompt reply, but I tend to disagree. I am having exactly the problems that I described while being on 1.5.0 (see below). There is some regression in Subversion, I suppose, I have had people downgrade back to 1.5.0 for not being to able to release. Would you have the JIRA issue for what you're referring to? Thanks, Sander. svn --version svn, version 1.5.0 (r31699) compiled Jun 23 2008, 12:59:48 -- View this message in context: http://www.nabble.com/Up-to-date-release-tp20925759p20925991.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Up-to-date release
Thanks for your quick response. Wendy Smoak-3 wrote: [ERROR] BUILD FAILURE [INFO] [INFO] Unable to commit files Provider message: The svn command failed. Command output: svn: Commit failed (details follow): svn: Your file or directory 'pom.xml' is probably out-of-date svn: resource out of date; try updating Yours fails on inconsistent pom.xml. In my scenario I can tell you that the POM did not change due to the work of either one of the developers; the sources changed. Also, yours fails on commiting something to the trunk, rather than making the tag. I ended up with an issue being fixed in a revision before a release, the release being on the production system, and the fix missing from the production system. I am *very* concerned about this opportunity for errors. Except for the release tag, my whole scenario plays on trunk. Wendy Smoak-3 wrote: Still, I'd suggest: Developer A communicates that a release is in progress/code freeze. Developer B holds commits, or one of them works on a branch. Their work was sequential in time, not parallel. If the release plugin would've been bullet proof in this regard, as I always expected it to be (until now), communication would not have been necessary. (I agree that it would have been, when they'd been working on the same thing at the same time. No argument.) -- View this message in context: http://www.nabble.com/Up-to-date-release-tp20925759p20926113.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Up-to-date release
On Tue, Dec 9, 2008 at 6:31 PM, sverhagen [EMAIL PROTECTED] wrote: Yours fails on inconsistent pom.xml. In my scenario I can tell you that the POM did not change due to the work of either one of the developers; the sources changed. Also, yours fails on commiting something to the trunk, rather than making the tag. Thanks for pointing that out-- making a change to the pom instead of the code wasn't a good test. I re-did it after making a change to the code from a different checkout, and release:prepare succeeded. I still tend to favor communication and a quiet period when a release is going on, as well as keeping a close eye on the commits list to make sure nothing slips in (or slips _by_, as in this case.) Still it's a good one to be aware of and to put in JIRA, if it's not already there. -- Wendy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Up-to-date release
sverhagen schrieb: Hi. We heavily use the Maven release plugin. Following scenario: * Developers update from SVN * Developer 1 commits a change * Developer 2 commits a change and releases (mvn release:prepare) Because developer 2 does not explicitly update from SVN, the change from developer 1 will not be in the release. Hard to track down, hard to detect. The maven-scm-plugin may be helpful. http://maven.apache.org/scm/maven-scm-plugin/update-mojo.html -- Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven Jaxb plugin?
In the past I've used the maven-exec-plugin with xbeans. Not sure if that helps. On Dec 9, 2008, at 1:31 PM, CheapLisa [EMAIL PROTECTED] wrote: Another question, is there a maven2 plugin that will generate an XSD from XML ? thanks Lisa Adam Leggett wrote: Try http://mojo.codehaus.org/jaxb2-maven-plugin/index.html For example: plugin groupIdorg.codehaus.mojo/groupId artifactIdjaxb2-maven-plugin/artifactId executions execution goals goalxjc/goal /goals /execution /executions configuration packageNamecom.acme/packageName /configuration /plugin -Original Message- From: CheapLisa [mailto:[EMAIL PROTECTED] Sent: 09 December 2008 16:33 To: users@maven.apache.org Subject: Maven Jaxb plugin? I searched for a maven jaxb plugin and found xjc-maven-plugin but it is not documented. Does anyone have an example of generating an xsd from xml and then the java objects from xsd? Does anyone know why this plugin is not documented? -- View this message in context: http://www.nabble.com/Maven-Jaxb-plugin--tp20918118p20918118.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Maven-Jaxb-plugin--tp20918118p20920625.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] Wagon Maven Plugin 1.0-beta-1 released
The Mojo team is pleased to announce the release of the Wagon Maven Plugin version 1.0-beta-1 http://mojo.codehaus.org/wagon-maven-plugin This is the first beta release, so feedbacks are greatly appreciated Regards, Dan T. Tran - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [ANN] Wagon Maven Plugin 1.0-beta-1 released
Awesome work Dan :) The plugin looks great! James On Tue, 2008-12-09 at 20:11 -0800, Dan Tran wrote: The Mojo team is pleased to announce the release of the Wagon Maven Plugin version 1.0-beta-1 http://mojo.codehaus.org/wagon-maven-plugin This is the first beta release, so feedbacks are greatly appreciated Regards, Dan T. Tran - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Up-to-date release
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm subscribed to this bug: http://jira.codehaus.org/browse/SCM-406 Lots of people are complaining, but sadly there are no answers so far. The problem seems to be that when doinf releaase:prepare, the release plugin tries to commit the current working copy as a tag, instead of copying a remote URL. SVN 1.5 allows this, SVN 1.5.x apparently does not. There's bound to be a workaround. Someone suggested locking the trunk while the release plugin runs; I have no idea how feasible that would be. sverhagen wrote: Stephen Connolly-2 wrote: Use Subversion 1.5 the release plugin is broken with svn 1.5 and will not make a release if the entire workspace is not 100% up to date Hi, Stephen. Thanks for your prompt reply, but I tend to disagree. I am having exactly the problems that I described while being on 1.5.0 (see below). There is some regression in Subversion, I suppose, I have had people downgrade back to 1.5.0 for not being to able to release. Would you have the JIRA issue for what you're referring to? Thanks, Sander. svn --version svn, version 1.5.0 (r31699) compiled Jun 23 2008, 12:59:48 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEUEARECAAYFAkk/R68ACgkQ0GFaTS4nYxsnTACXWccUsTP0D7DPnN8fxTOgJE07 PgCfQjLqI5xMbRpfhMn/Zac5ktQnJhw= =enWc -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Is Maven / JUnit 4.x broken (annotations)
I have JUnit 4.5 as a dependency in my maven pom and I have imported annotations into my test case but it is not recognizing the @Test and @Ignore annotations. I still have to preface the method name with test and the @Ignore tests get executed. Is something broken? What do I need to do to get this to work like expected and to take advantage of JUnit 4.x which has over a year of release now. thanks Lisa -- View this message in context: http://www.nabble.com/Is-Maven---JUnit-4.x-broken-%28annotations%29-tp20929389p20929389.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to run JUnit tests in sub-modules without surefire reference?
thanks, so there is absolutely no way to rid every single pom.xml with some reference to junit for example? Lisa Wayne Fay wrote: I do not want this plugin section in every pom.xml in every sub-module (some 5 deep) How do I do this to make it go? Generally, you should configure plugins like this in the pluginManagement section in the top parent, and then when you declare the plugin in each child, it will inherit the configuration from the parent. So the parent has the big configuration section in pluginMgmt, and the children just have: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId /plugin Of course, surefire is already declared in the super pom, so you shouldn't even need to include that in the children. Check mvn help:effective-pom in a child once you've added that configuration to the top parent -- it should show up. Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/How-to-run-JUnit-tests-in-sub-modules-without-surefire-reference--tp20924140p20929409.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] cbuilds 1.0-alpha-6 released
CBUILDS version 1.0-alpha-6 has been released. Fixes pathOf() expansion for shell-maven-plugin with Maven 2.0.9 http://mojo.codehaus.org/cbuild-parent/ Change report http://mojo.codehaus.org/cbuild-parent/changes-report.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
surefire does not generate TESTS-TestSuites.xml
Hi all, Before I used ant to generate junit test report by ant task junitreport, along with a bunch of the TEST-FOO.BAR.X.Y.ZTest.xml there will be an all-in-one test report named TESTS-TestSuties.xml. However with surefire plugin, maven2 does not generate this one, and this one is very important for me (eg, to generate cruise control build result notification). So does anybody know how to generate this one in Maven2 surefire plugin? -- Thanks Regards, Daniel
Re: How to run JUnit tests in sub-modules without surefire reference?
You could add junit as a test dependency to your parent pom... that is a dependency not dependencyManagement Might cause more problems than it fixes though! -Stephen 2008/12/10 CheapLisa [EMAIL PROTECTED] thanks, so there is absolutely no way to rid every single pom.xml with some reference to junit for example? Lisa Wayne Fay wrote: I do not want this plugin section in every pom.xml in every sub-module (some 5 deep) How do I do this to make it go? Generally, you should configure plugins like this in the pluginManagement section in the top parent, and then when you declare the plugin in each child, it will inherit the configuration from the parent. So the parent has the big configuration section in pluginMgmt, and the children just have: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId /plugin Of course, surefire is already declared in the super pom, so you shouldn't even need to include that in the children. Check mvn help:effective-pom in a child once you've added that configuration to the top parent -- it should show up. Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/How-to-run-JUnit-tests-in-sub-modules-without-surefire-reference--tp20924140p20929409.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Creating a dependency pack jar
Lilianne E. Blaze wrote: Hello, I did manage to get it working, using Shade plugin with the following options: createSourcesJartrue/createSourcesJar keepDependenciesWithProvidedScopetrue/keepDependenciesWithProvidedScope promoteTransitiveDependenciestrue/promoteTransitiveDependencies It creates jars which look ok, work ok when used in another Maven project, but for some reason they confuse Netbeans? Netbeans simply does not see the packages and classes inside the jar. That is, they are visible in Project Explorer, but when typing import xxx.xxx there are errors package xxx.xxx does not exist. The funny thing is, it compiles correctly, with both external and internal Maven. Any suggestions? Greetings, Lilianne I submitted a bug report at http://www.netbeans.org/issues/show_bug.cgi?id=155091 At this point I'm not sure if it's my fault, Netbeans' or Maven's, please take a look at the project I attached to the report and tell me if there are any errors inside. Greetings, L - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to run JUnit tests in sub-modules without surefire reference?
thanks, so there is absolutely no way to rid every single pom.xml with some reference to junit for example? I guess I still don't know what your objective is. Surefire is in the super pom (in Maven's jars), so *all* poms will have a reference to it, directly or inherited. If you make a new project with a nearly empty pom and try mvn help:effective-pom, you'll see Surefire in it. As for JUnit, Surefire knows how to run JUnit tests, but it doesn't explicitly depend on JUnit, so you'll need to include a reference to it at least in the top parent's pom files and it should be inherited by the children. So no, you don't need to include junit in every single pom.xml. I think you need to make some sample projects and play around with help:effective-pom to see how it all works, then come back with specific questions if you have any. Wayne - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Keep version when doing a release
Hi, I have a multi module project that I want to make a release for. Some of the modules changes frequently and they are marked as SNAPSHOTS. Some modules are very stable and have a fixed version. I run maven 2 release plug-in 2.0-beta-7 with the --batch-mode parameter. The problem is that the stable modules will also have there version changed. Is there any way to tell the plug-in to only change version for SNAPSHOT modules? /Gunnar - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
