Re: Packaging JAX-WS service implementation and client API
You could even separate out the wsdl/xsd in its own artifact(s). That's what I normally recommend as it will then allow the client to use whatever ws service and xml binding technology they like. /Anders On Mon, Aug 22, 2011 at 06:50, Asplund Marko marko.aspl...@ixonos.com wrote: Anders Hammar wrote: separate modules! Yes, that's how i ended up solving it. I created X-service API (XSD, WSDL, JAXB classes) and X-service implementation modules. The service implementation module only contains the implementation code and it depends on the service API module and gets the service contract definition from there. The API module is distributed via an artifact repository to allow module development lifecycles to be more effectively separated. marko - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Reactor doesn't build parent poms first?
if the versions do not match, then the reactor does not have a constraint. when relative path is set, you get a warning of a version mismatch (or maybe an error, cannot remember exactly) it is perfectly legal to have a reactor with C depending on the previous release of B - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 21 Aug 2011 22:14, Laird Nelson ljnel...@gmail.com wrote: This is probably some sort of misunderstanding on my part, but I thought I'd check. When executing a multi-module build, it appears that Maven will not detect that certain parent POMs in the project need to be built before an effective project scan can be completed. That is, suppose that you have a project structure with an aggregator, A, a module that is a parent pom, B, and a module that is a child of B (C). So A aggregates B and C; C extends from B. Assume also that (deliberately) the parent stanza does not have its relativePath set. (This is because in a large team with moderately skilled developers, there are all sorts of problems if the developer forgets to svn update B--the relative path of C's parent will pick up the workspace copy of B, not the most recent copy in the Maven repository.) If you run the reactor here it will use the repository copy of B, rather than realizing (as I think it should) that B is something that it can build to get a more recent copy. I would expect there to be a two-part scanning algorithm: first scan all modules and see if their parents are modules in the build. If so, then build those modules first. Then build the other projects in dependency order. Am I missing something? My apologies if so. Best, Laird -- http://about.me/lairdnelson
Re: Multi-Module and differing artifactId
On Thu, 18 Aug 2011 14:00:26 -0500 Wayne Fay wayne...@gmail.com wrote: I guess this has been asked before, but is there any way to gracefully handle situations in a multi-level modular project where the artifactId does not always correspond to the folder name of the module? Maven operates under certain conventions. This is not the convention, thus it is not well supported. parent with /childWithOtherName appended, and there is no way I can force it to use /childB, unless I specify the whole path, which is tedious with large projects. This is the not well supported aspect. I'm not even sure how good of an idea this is. Why can't you just change the artifactId or the module name?? Well, I'll resort to this, but it is quite cumbersome. On artifact level, groupId+artifactId is a unique id, but effectively, only artifactId needs to be unique (resulting filenames are only constructed from the artifactId). So I could have +/ = org.test:parent +/ejb= org.test.parent:ejb +/ejb/common = org.test.parent.ejb:common-ejbs +/war= org.test.parent:war +/war/common = org.test.parent.war:common-wars but I really am forced to use the unique artifactId in the directory as well: +/= org.test:parent +/ejb = org.test.parent:ejb +/ejb/common-ejbs = org.test.parent.ejb:common-ejbs +/war = org.test.parent:war +/war/common-wars = org.test.parent.war:common-wars This is just duplicate information and strange, but that's like it with conventions... Thanks for your comments, Stefan Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- best regards, Stefan Seidel Software developer VUB Printmedia GmbH Chopinstraße 4, 04103 Leipzig tel.+49 (341) 9 60 50 93 fax.+49 (341) 9 60 50 92 mail. ssei...@vub.de web.www.vub.de VUB Printmedia GmbH HRB Köln 24015 GF Dr. A. Preuss Neudorf, Dr. C. Preuss Neudorf - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
ParseException in cobertura with some generics
Hi, I am using the cobertura-maven-plugin (version 2.4) for code test coverage. The compile works. But I get an error when I try to generate the site. Error: [DEBUG] Calling NCSSExecuter with encoding : UTF-8 ParseException in classname.java Encountered at line 83, column 14. Was expecting one of: assert ... IDENTIFIER ... ; ... = ... ++ ... -- ... += ... -= ... *= ... /= ... = ... |= ... ^= ... %= ... = ... = ... = ... Here is the line that the error is coming from: this.SomeDataType foo( pValue ); Has anybody have had the same problem or possible solutions for this problem? I saw, that I can exclude or ignore some files, but that is probably not the best way to handle this error :) Stacktrace: [DEBUG] Trace org.apache.maven.lifecycle.LifecycleExecutionException: Error during page generation at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at hudson.maven.agent.Main.launch(Main.java:173) at hudson.maven.MavenBuilder.call(MavenBuilder.java:164) at hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:974) at hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:905) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:270) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: org.apache.maven.plugin.MojoExecutionException: Error during page generation at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:123) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490) at hudson.maven.agent.PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java:182) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) ... 28 more Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error rendering Maven report: Error while JavaNCSS was executing at org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:171) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:330) at org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:134) at org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:154) at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:118) ... 31 more Caused by: org.apache.maven.reporting.MavenReportException: Error while JavaNCSS was executing at org.codehaus.mojo.javancss.NcssExecuter.execute(NcssExecuter.java:112) at org.codehaus.mojo.javancss.NcssReportMojo.generateSingleReport(NcssReportMojo.java:264) at org.codehaus.mojo.javancss.NcssReportMojo.executeReport(NcssReportMojo.java:180) at org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:98) at
Re: Reactor doesn't build parent poms first?
On Mon, Aug 22, 2011 at 2:45 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: if the versions do not match, then the reactor does not have a constraint. Should have mentioned I was talking about SNAPSHOTs; sorry. Does that change the picture? when relative path is set, you get a warning of a version mismatch (or maybe an error, cannot remember exactly) Right; makes sense when we're talking about release versions. it is perfectly legal to have a reactor with C depending on the previous release of B Sure; thanks. Best, Laird -- http://about.me/lairdnelson
Re: Reactor doesn't build parent poms first?
On 22 August 2011 12:41, Laird Nelson ljnel...@gmail.com wrote: On Mon, Aug 22, 2011 at 2:45 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: if the versions do not match, then the reactor does not have a constraint. Should have mentioned I was talking about SNAPSHOTs; sorry. Does that change the picture? Nope. when relative path is set, you get a warning of a version mismatch (or maybe an error, cannot remember exactly) Right; makes sense when we're talking about release versions. make sense when talking about any version. it is perfectly legal to have a reactor with C depending on the previous release of B Sure; thanks. And you could even be depending on a different -SNAPSHOT version in that same reactor... though personally I cannot think of a good use case for such a reactor. Best, Laird -- http://about.me/lairdnelson - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
NPE with maven-site-plugin:3.0
Hi, after updating to version 3.0 of maven-site-plugin I get a NullPointerException that does not occur with 3.0-beta3. How can I figure out, what causes that? There is not clear error message so I guess it's a bug... Here is the last part of the log: [DEBUG] Multipage report: 0 subreports [DEBUG] Velocimacro : added #link( href name target img position alt border width height ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #image( img alt border width height ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #banner( banner id ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #links( links ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #breadcrumbs( breadcrumbs ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #displayTree( display item ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #menuItem( item ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #mainMenu( menus ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #copyright( ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #publishDate( position publishDate version ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #poweredByLogo( poweredBy ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #googleAnalytics( accountId ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [ERROR] Method calculateLink threw exception for reference $PathTool in template org/apache/maven/doxia/siterenderer/resources/default-site.vm at [2,29] [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 14.407s [INFO] Finished at: Mon Aug 22 14:16:21 CEST 2011 [INFO] Final Memory: 96M/874M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on project mycore-iview2: Error during page generation: Error while generating code. Invocation of method 'calculateLink' in class org.codehaus.plexus.util.PathTool threw exception java.lang.NullPointerException @ org/apache/maven/doxia/siterenderer/resources/default-site.vm[2,39] - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on project mycore-iview2: Error during page generation at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.MojoExecutionException: Error during page generation at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:143) at
Re: NPE with maven-site-plugin:3.0
Please open an issue at http://jira.codehaus.org/browse/MSITE with a reproducible test case. Thanks, -Lukas On 08/22/2011 02:18 PM, Thomas Scheffler wrote: Hi, after updating to version 3.0 of maven-site-plugin I get a NullPointerException that does not occur with 3.0-beta3. How can I figure out, what causes that? There is not clear error message so I guess it's a bug... Here is the last part of the log: [DEBUG] Multipage report: 0 subreports [DEBUG] Velocimacro : added #link( href name target img position alt border width height ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #image( img alt border width height ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #banner( banner id ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #links( links ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #breadcrumbs( breadcrumbs ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #displayTree( display item ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #menuItem( item ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #mainMenu( menus ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #copyright( ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #publishDate( position publishDate version ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #poweredByLogo( poweredBy ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [DEBUG] Velocimacro : added #googleAnalytics( accountId ) : source = org/apache/maven/doxia/siterenderer/resources/default-site.vm [ERROR] Method calculateLink threw exception for reference $PathTool in template org/apache/maven/doxia/siterenderer/resources/default-site.vm at [2,29] [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 14.407s [INFO] Finished at: Mon Aug 22 14:16:21 CEST 2011 [INFO] Final Memory: 96M/874M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on project mycore-iview2: Error during page generation: Error while generating code. Invocation of method 'calculateLink' in class org.codehaus.plexus.util.PathTool threw exception java.lang.NullPointerException @ org/apache/maven/doxia/siterenderer/resources/default-site.vm[2,39] - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on project mycore-iview2: Error during page generation at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.MojoExecutionException: Error during page generation at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:143) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at
Re: Reactor doesn't build parent poms first?
On Mon, Aug 22, 2011 at 7:48 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Should have mentioned I was talking about SNAPSHOTs; sorry. Does that change the picture? Nope. Just to be clear, then: You're saying that in a multimodule project, where my root pom.xmlaggregates several submodules, and where one of those submodules is a pom.xml that serves as a parent to some other submodules--you're saying that even when all these things are declared as version 1.0-SNAPSHOT, Maven will use the repo copy of the parent, even though the very reactor plan it is executing tells it that it should be building the most recent copy? Or, using the same letters that I used in my prior message's example, if A, B and C are all 1.0-SNAPSHOT, and the version of B deployed to the repository is 75 days old, Maven will begin a full build from the root (A) by first scanning the module paths to see what projects are there (A, B and C), and because C references B as a parent, the 75-day-old copy of B will be retrieved from the (local) repo rather than Maven realizing that B is in the reactor plan as a module in its own right? Best, Laird -- http://about.me/lairdnelson
Re: Reactor doesn't build parent poms first?
On 22 August 2011 14:37, Laird Nelson ljnel...@gmail.com wrote: On Mon, Aug 22, 2011 at 7:48 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Should have mentioned I was talking about SNAPSHOTs; sorry. Does that change the picture? Nope. Just to be clear, then: You're saying that in a multimodule project, where my root pom.xmlaggregates several submodules, and where one of those submodules is a pom.xml that serves as a parent to some other submodules--you're saying that even when all these things are declared as version 1.0-SNAPSHOT, Maven will use the repo copy of the parent, even though the very reactor plan it is executing tells it that it should be building the most recent copy? Or, using the same letters that I used in my prior message's example, if A, B and C are all 1.0-SNAPSHOT, and the version of B deployed to the repository is 75 days old, Maven will begin a full build from the root (A) by first scanning the module paths to see what projects are there (A, B and C), and because C references B as a parent, the 75-day-old copy of B will be retrieved from the (local) repo rather than Maven realizing that B is in the reactor plan as a module in its own right? No I am saying that if C references B 0.9-SNAPSHOT as its parent then the reactor will not require B 1.0-SNAPSHOT (from the reactor) to be built before C 1.0-SNAPSHOT. If the parent GAV is present in the reactor, then that is what will be used if the parent GA is present in the reactor only with a different V, then you might be lucky and see a warning if the relativePath points to it, otherwise Maven will not see an issue as long as the requested GAV is in a repo Best, Laird -- http://about.me/lairdnelson - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Reactor doesn't build parent poms first?
According to my own tests, with Maven 3 the parent pom is resolved according to the following algorithm: IF relativePath != THEN IF pom is found at relativePath location and GAV match THEN use this pom as parent ELSE log a warning and useRepo=true ENDIF ELSE useRepo=true ENDIF Maven 3 will never use the pom from the reactor, and the reactor order will not reorder parent before children. See https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ParentPOMResolution Please correct me if I am wrong. Regards, Julien De : Stephen Connolly stephen.alan.conno...@gmail.com À : Maven Users List users@maven.apache.org Envoyé le : Lundi 22 Août 2011 16h16 Objet : Re: Reactor doesn't build parent poms first? On 22 August 2011 14:37, Laird Nelson ljnel...@gmail.com wrote: On Mon, Aug 22, 2011 at 7:48 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Should have mentioned I was talking about SNAPSHOTs; sorry. Does that change the picture? Nope. Just to be clear, then: You're saying that in a multimodule project, where my root pom.xmlaggregates several submodules, and where one of those submodules is a pom.xml that serves as a parent to some other submodules--you're saying that even when all these things are declared as version 1.0-SNAPSHOT, Maven will use the repo copy of the parent, even though the very reactor plan it is executing tells it that it should be building the most recent copy? Or, using the same letters that I used in my prior message's example, if A, B and C are all 1.0-SNAPSHOT, and the version of B deployed to the repository is 75 days old, Maven will begin a full build from the root (A) by first scanning the module paths to see what projects are there (A, B and C), and because C references B as a parent, the 75-day-old copy of B will be retrieved from the (local) repo rather than Maven realizing that B is in the reactor plan as a module in its own right? No I am saying that if C references B 0.9-SNAPSHOT as its parent then the reactor will not require B 1.0-SNAPSHOT (from the reactor) to be built before C 1.0-SNAPSHOT. If the parent GAV is present in the reactor, then that is what will be used if the parent GA is present in the reactor only with a different V, then you might be lucky and see a warning if the relativePath points to it, otherwise Maven will not see an issue as long as the requested GAV is in a repo Best, Laird -- http://about.me/lairdnelson - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Reactor doesn't build parent poms first?
On Mon, Aug 22, 2011 at 10:46 AM, Julien HENRY henr...@yahoo.fr wrote: According to my own tests, with Maven 3 the parent pom is resolved according to the following algorithm: IF relativePath != THEN IF pom is found at relativePath location and GAV match THEN use this pom as parent ELSE log a warning and useRepo=true ENDIF ELSE useRepo=true ENDIF Maven 3 will never use the pom from the reactor, and the reactor order will not reorder parent before children. I'm foggy on one point here. How can the pom in the reactor differ from the pom reached by relative path? Different property substitutions? Or is the issue here the case in which there is no rel path, but it is in the reactor? See https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ParentPOMResolution Please correct me if I am wrong. Regards, Julien De : Stephen Connolly stephen.alan.conno...@gmail.com À : Maven Users List users@maven.apache.org Envoyé le : Lundi 22 Août 2011 16h16 Objet : Re: Reactor doesn't build parent poms first? On 22 August 2011 14:37, Laird Nelson ljnel...@gmail.com wrote: On Mon, Aug 22, 2011 at 7:48 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Should have mentioned I was talking about SNAPSHOTs; sorry. Does that change the picture? Nope. Just to be clear, then: You're saying that in a multimodule project, where my root pom.xmlaggregates several submodules, and where one of those submodules is a pom.xml that serves as a parent to some other submodules--you're saying that even when all these things are declared as version 1.0-SNAPSHOT, Maven will use the repo copy of the parent, even though the very reactor plan it is executing tells it that it should be building the most recent copy? Or, using the same letters that I used in my prior message's example, if A, B and C are all 1.0-SNAPSHOT, and the version of B deployed to the repository is 75 days old, Maven will begin a full build from the root (A) by first scanning the module paths to see what projects are there (A, B and C), and because C references B as a parent, the 75-day-old copy of B will be retrieved from the (local) repo rather than Maven realizing that B is in the reactor plan as a module in its own right? No I am saying that if C references B 0.9-SNAPSHOT as its parent then the reactor will not require B 1.0-SNAPSHOT (from the reactor) to be built before C 1.0-SNAPSHOT. If the parent GAV is present in the reactor, then that is what will be used if the parent GA is present in the reactor only with a different V, then you might be lucky and see a warning if the relativePath points to it, otherwise Maven will not see an issue as long as the requested GAV is in a repo Best, Laird -- http://about.me/lairdnelson - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[jar-plugin] properties not properly expanded in manifestEntries
Hi all guys,
in my pom I added the buildnumber-plugin and defined a set of
properties which contain:
properties
...
maven.build.timestamp.format-MM-dd
HH:mm:ssZ/maven.build.timestamp.format
implementation.buildr${buildNumber};
${maven.build.timestamp}/implementation.build
...
/properties
Problem is that when filtering any textual resource,
${implementation.build} is correctly expanded, i.e. in the README I
put
MyCompany ${project.name} (${implementation.build})
it is expanded as
MyCompany MyProduct (r14934; 2011-08-22 17:23:04+0200)
But when expanding the same property in the jar plugin:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
version2.3.2/version
configuration
archive
manifest
addDefaultImplementationEntriestrue/addDefaultImplementationEntries
addDefaultSpecificationEntriestrue/addDefaultSpecificationEntries
/manifest
manifestEntries
Implementation-Build${implementation.build}/Implementation-Build
X-Compile-Source-JDK${javac.src.version}/X-Compile-Source-JDK
X-Compile-Target-JDK${javac.target.version}/X-Compile-Target-JDK
/manifestEntries
/archive
/configuration
/plugin
The Implementation-Build entry in the MANIFEST.MF is expanded as
Implementation-Build: r${buildNumber}; 2011-08-22 17:23:04+0200
Does someone have an idea why? Any suggestion?
Many thanks in advance, all the best!!!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Reactor doesn't build parent poms first?
On Mon, Aug 22, 2011 at 11:22 AM, Benson Margulies bimargul...@gmail.comwrote: I'm foggy on one point here. How can the pom in the reactor differ from the pom reached by relative path? Different property substitutions? Or is the issue here the case in which there is no rel path, but it is in the reactor? (I'll quickly chime in with my background use case--or at least the reason why I brought up all this stuff initially.) In my organization we have lots of modules. Developers typically only work on a given module at a time. We've set things up in a pretty standard fashion so that they can check that module out and work on it without having to check out the other modules. We've got Nexus proxying various repositories; all artifacts that are depended upon basically get downloaded through that. Standard Maven stuff. Of course, the developers often do have the whole project checked out. That used to cause some weird problems, detailed below. Some of our modules have parents that are other modules. So we have a standard -pomtypes-jpa module, for example, that does some stuff in its build section to do things like generate the list of entity classes that should be included in a persistence.xml during unit/integration testing. Other modules may extend this as their parent to pick up this behavior. Occasionally, we need to make changes to these mid-level modules. Back in the day, we had a bunch of relativePath elements. But developers were getting confused, because if they were working on a JPA module that inherited from this -pomtypes-jpa module, then if they hadn't version-control-updated their -pomtypes-jpa module, the relativePath element would kick in and try to use the working copy in their workspace. Oops. The solution in this case was: if you have the -pomtypes-jpa module checked out, make sure you svn update it religiously so that when relativePath finds it, you're getting the most recent copy from Subversion. OK, fine, so we finally decided, forget this, the relativePath element is kind of a hack anyway (or at least didn't fit our needs at all). So now all pom resolution comes from the repository. That's cool; that's like every other Maven artifact. Smooth sailing. We update the -pomtypes-jpa pom.xml, and all children who extend it pick it up automatically (we're still in SNAPSHOT mode). However, this is kind of odd when we're doing a full build. Suppose one of these developers hasn't done a full build in ages and ages. Or, for that matter, hasn't worked on a JPA module, so hasn't caused Maven to go look for a new SNAPSHOT version of that -pomtypes-jpa project. Now, when we execute that full build right after a global svn update, the full build will go use the (comparatively ancient) 1.0-SNAPSHOT version of -pomtypes-jpa's pom.xml from the local repository (or the remote), which is, of course, the most recent *deployed* version, but might very well not be the most recent version *in Subversion* that they just checked out to their workspace. Really since we're doing a full build, we'd like it to use...well, the one that should be built right now. :-) We would like it to realize that one of the artifacts that a module extends from is actually *in the build plan currently being executed*, so gee, it would be nice if Maven would sort it all the way up in the topologically sorted list of reactor projects. Obviously it could potentially affect property substitution and the like for child poms, so you'd want to make sure this thing was built first. Maybe that's all backwards and wrong-headed, but it's where I was coming from. One customer's input. The workaround for us is to wrap Maven so that we do mvn -o clean install on the parent poms first, in topological order, then run mvn clean install from the root. I was looking for this sort of thing to be handled natively by the reactor. Best, Laird -- http://about.me/lairdnelson
Re: ParseException in cobertura with some generics
Error: [DEBUG] Calling NCSSExecuter with encoding : UTF-8 ParseException in classname.java Encountered at line 83, column 14. Caused by: javancss.parser.ParseException: Encountered at line 774, column 14. Was expecting one of: at javancss.parser.JavaParser.generateParseException(JavaParser.java:10248) Sure looks like a javancss error, and cobertura is using javancss under the covers. I'd go ask whoever produces that tool (javancss) about the error you're getting. Perhaps there's a new version out that properly handles this grammar. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
how generate additional artifacts from one project?
Hi all I'm trying to generate additional artifact flavours for a single project. I checkout the assembly plugin but I'm still not quite sure where to start. Some help is really appreciated. right now I have artifact-sources.jar and artifact-javavdoc.jar. I would like to generate one more something like -resources.jar, which contains public resources to be shared by my build tool. Is the assembly plugin the right place to start? after I generate this flavour, how do I tell maven to deploy / install it along others? thanks -- Sam Jiang | karoshealth (っﾟДﾟ；)っ hidden cat here 7 Father David Bauer Drive, Suite 201 Waterloo, ON, N2L 0A2, Canada www.karoshealth.com
Re: how generate additional artifacts from one project?
On 08/23/2011 01:13 AM, Sam Jiang wrote: Hi all I'm trying to generate additional artifact flavours for a single project. I checkout the assembly plugin but I'm still not quite sure where to start. Some help is really appreciated. right now I have artifact-sources.jar and artifact-javavdoc.jar. I would like to generate one more something like -resources.jar, which contains public resources to be shared by my build tool. Is the assembly plugin the right place to start? after I generate this flavour, how do I tell maven to deploy / install it along others? Assembly plugin. Manos - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: how generate additional artifacts from one project?
You can use the build helper plugin[1] to attach arbitrary artifacts. So you can use any means to produce the artifact you want to attach, say the assembly plugin, and then use the attach-artifact goal[2] of the build helper plugin to have it be installed in your local repository and deployed to the remote repository. Alternatively you can roll your own solution, something like this[3]. The full example is here[4]. [1]: http://mojo.codehaus.org/build-helper-maven-plugin/ [2]: http://mojo.codehaus.org/build-helper-maven-plugin/attach-artifact-mojo.html [3]: https://github.com/jvanzyl/maven-recipes/blob/master/attached-artifact/src/main/java/io/jvz/maven/MojoThatAttachesAnAdditionalArtifact.java [4]: https://github.com/jvanzyl/maven-recipes/tree/master/attached-artifact On Aug 22, 2011, at 6:13 PM, Sam Jiang wrote: Hi all I'm trying to generate additional artifact flavours for a single project. I checkout the assembly plugin but I'm still not quite sure where to start. Some help is really appreciated. right now I have artifact-sources.jar and artifact-javavdoc.jar. I would like to generate one more something like -resources.jar, which contains public resources to be shared by my build tool. Is the assembly plugin the right place to start? after I generate this flavour, how do I tell maven to deploy / install it along others? thanks -- Sam Jiang | karoshealth (っﾟДﾟ；)っ hidden cat here 7 Father David Bauer Drive, Suite 201 Waterloo, ON, N2L 0A2, Canada www.karoshealth.com Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - To do two things at once is to do neither. -—Publilius Syrus, Roman slave, first century B.C.
[ANN] nbm-maven-plugin 3.6, various Mojo Archetypes Released
The Mojo team is pleased to announce the release of the 3.6 version of the NBM Maven plugin, and new versions of a number of archetypes. nbm-maven-plugin http://mojo.codehaus.org/nbm-maven-plugin/ is used to create modules and applications based on the NetBeans Platform. Use org.codehaus.mojo:nbm-maven-plugin:3.6. The new archetypes released cover Java EE and NBM development. Run mvn archetype:generate to use the new archetypes. Plugin release notes: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11293version=17116 EE archetype changes: - introduce new archetypes for application client packaging - do not include empty JUnit test roots - use a more canonical ID for the java.net M2 repo - update maven-ear-plugin to new release that can handle app clients NBM archetype changes: - use RELEASE701 - create new modules without an XML layer - clean up artifactIds and names - use 3.6 plugin - do not override splash icon branding Enjoy, The Mojo team. - Jesse Glick - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Reactor doesn't build parent poms first?
Yes, I've also found that I have to mvn install -N on the first build of a parent (when it does not exist in local or remote repo) otherwise the build fails. If that is what you are experiencing, then me too. I've never looked further, as it happens so infrequently. On Mon, Aug 22, 2011 at 10:38 AM, Laird Nelson ljnel...@gmail.com wrote: On Mon, Aug 22, 2011 at 11:22 AM, Benson Margulies bimargul...@gmail.com wrote: I'm foggy on one point here. How can the pom in the reactor differ from the pom reached by relative path? Different property substitutions? Or is the issue here the case in which there is no rel path, but it is in the reactor? (I'll quickly chime in with my background use case--or at least the reason why I brought up all this stuff initially.) In my organization we have lots of modules. Developers typically only work on a given module at a time. We've set things up in a pretty standard fashion so that they can check that module out and work on it without having to check out the other modules. We've got Nexus proxying various repositories; all artifacts that are depended upon basically get downloaded through that. Standard Maven stuff. Of course, the developers often do have the whole project checked out. That used to cause some weird problems, detailed below. Some of our modules have parents that are other modules. So we have a standard -pomtypes-jpa module, for example, that does some stuff in its build section to do things like generate the list of entity classes that should be included in a persistence.xml during unit/integration testing. Other modules may extend this as their parent to pick up this behavior. Occasionally, we need to make changes to these mid-level modules. Back in the day, we had a bunch of relativePath elements. But developers were getting confused, because if they were working on a JPA module that inherited from this -pomtypes-jpa module, then if they hadn't version-control-updated their -pomtypes-jpa module, the relativePath element would kick in and try to use the working copy in their workspace. Oops. The solution in this case was: if you have the -pomtypes-jpa module checked out, make sure you svn update it religiously so that when relativePath finds it, you're getting the most recent copy from Subversion. OK, fine, so we finally decided, forget this, the relativePath element is kind of a hack anyway (or at least didn't fit our needs at all). So now all pom resolution comes from the repository. That's cool; that's like every other Maven artifact. Smooth sailing. We update the -pomtypes-jpa pom.xml, and all children who extend it pick it up automatically (we're still in SNAPSHOT mode). However, this is kind of odd when we're doing a full build. Suppose one of these developers hasn't done a full build in ages and ages. Or, for that matter, hasn't worked on a JPA module, so hasn't caused Maven to go look for a new SNAPSHOT version of that -pomtypes-jpa project. Now, when we execute that full build right after a global svn update, the full build will go use the (comparatively ancient) 1.0-SNAPSHOT version of -pomtypes-jpa's pom.xml from the local repository (or the remote), which is, of course, the most recent *deployed* version, but might very well not be the most recent version *in Subversion* that they just checked out to their workspace. Really since we're doing a full build, we'd like it to use...well, the one that should be built right now. :-) We would like it to realize that one of the artifacts that a module extends from is actually *in the build plan currently being executed*, so gee, it would be nice if Maven would sort it all the way up in the topologically sorted list of reactor projects. Obviously it could potentially affect property substitution and the like for child poms, so you'd want to make sure this thing was built first. Maybe that's all backwards and wrong-headed, but it's where I was coming from. One customer's input. The workaround for us is to wrap Maven so that we do mvn -o clean install on the parent poms first, in topological order, then run mvn clean install from the root. I was looking for this sort of thing to be handled natively by the reactor. Best, Laird -- http://about.me/lairdnelson
EAR Creation
Hi, I have to create the ear file of an application which consists a war file of the same application. Can you please tell me what entries to write in pom.xml so that it creates the war file of the module and then package the same war file into the ear file. Any help would be greatly appreciated -- View this message in context: http://maven.40175.n5.nabble.com/EAR-Creation-tp4725469p4725469.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: EAR Creation
Well, this seems to me little bit odd. Anyways, I believe you should have multi-module maven structure project. Where, one of the modules/parent has EAR packaging and depends on other modules (one of them then would have war packaging). For example, 1. You have a Parent POM which defines modules may be like: modules moduleModule-EAR/module moduleModule-War/module /modules 2. POM of Module EAR would have packaging as EAR and defines dependency of Module-War. 3. POM of Module War would have packaging as WAR. Regards, Yuvaraj Yuvaraj Vanarase, Lead Technology - Software Phone: +91.20.40262000 Ext 2305|Mobile: +91.9850818870 | http://www.synechron.com SYNECHRON - - Top 10 Best IT Employers for 4 consecutive years (link). - Celebrating 10 Years! -Original Message- From: anamika gupta [mailto:anam...@hcl.com] Sent: Tuesday, August 23, 2011 10:23 AM To: users@maven.apache.org Subject: EAR Creation Hi, I have to create the ear file of an application which consists a war file of the same application. Can you please tell me what entries to write in pom.xml so that it creates the war file of the module and then package the same war file into the ear file. Any help would be greatly appreciated -- View this message in context: http://maven.40175.n5.nabble.com/EAR-Creation-tp4725469p4725469.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: EAR Creation
Yes, you do this as a multi-module project. Anything else is simply wrong (= will cause you problems) in Maven land. /Anders On Tue, Aug 23, 2011 at 07:31, Yuvaraj Vanarase yuvaraj.vanar...@synechron.com wrote: Well, this seems to me little bit odd. Anyways, I believe you should have multi-module maven structure project. Where, one of the modules/parent has EAR packaging and depends on other modules (one of them then would have war packaging). For example, 1. You have a Parent POM which defines modules may be like: modules moduleModule-EAR/module moduleModule-War/module /modules 2. POM of Module EAR would have packaging as EAR and defines dependency of Module-War. 3. POM of Module War would have packaging as WAR. Regards, Yuvaraj Yuvaraj Vanarase, Lead Technology - Software Phone: +91.20.40262000 Ext 2305|Mobile: +91.9850818870 | http://www.synechron.com SYNECHRON - - Top 10 Best IT Employers for 4 consecutive years (link). - Celebrating 10 Years! -Original Message- From: anamika gupta [mailto:anam...@hcl.com] Sent: Tuesday, August 23, 2011 10:23 AM To: users@maven.apache.org Subject: EAR Creation Hi, I have to create the ear file of an application which consists a war file of the same application. Can you please tell me what entries to write in pom.xml so that it creates the war file of the module and then package the same war file into the ear file. Any help would be greatly appreciated -- View this message in context: http://maven.40175.n5.nabble.com/EAR-Creation-tp4725469p4725469.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
