Re: Filtering not working after at sign
merci Olivier ;-)
it works if I do:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-resources-plugin/artifactId
configuration
useDefaultDelimitersfalse/useDefaultDelimiters
delimiters
delimiter${*}/delimiter
/delimiters
/configuration
/plugin
Thanks
Yann
--
View this message in context:
http://maven.40175.n5.nabble.com/Filtering-not-working-after-at-sign-tp5689637p5692884.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
Strange difference between enforcer dependency convergence and dependency tree (hibernate4/jboss-logging)
Hi there, I'm a bit lost. We are using Hibernate4. Unfortunately they mixed up their dependencies a bit, so that we managed them in our pom: dependency groupIdorg.jboss.logging/groupId artifactIdjboss-logging/artifactId version3.1.0.GA/version /dependency The dependency tree looks good. The dependency jboss-logging 3.1.0.CR2 is overwritten by the above definition: [INFO] | \- ourgroup:nic-api:jar:103:compile [INFO] | +- ourgroup:persistence:jar:2.22-Hibernate4:compile [INFO] | | +- org.springframework:spring-test:jar:3.1.1.RELEASE:compile [INFO] | | +- javax.annotation:jsr250-api:jar:1.0:compile [INFO] | | +- (de.hypoport.ef2:ef2-types:jar:2.22-Hibernate4:compile - omitted for duplicate) [INFO] | | +- de.hypoport.ef2:ef2-core:jar:2.22-Hibernate4:compile [INFO] | | | +- (de.hypoport.ef2:ef2-types:jar:2.22-Hibernate4:compile - omitted for duplicate) [INFO] | | | \- org.springframework:spring-context:jar:3.1.1.RELEASE:compile [INFO] | | | +- (org.springframework:spring-beans:jar:3.1.1.RELEASE:compile - omitted for duplicate) [INFO] | | | \- org.springframework:spring-expression:jar:3.1.1.RELEASE:compile [INFO] | | +- org.hibernate:hibernate-core:jar:4.1.2.Final:compile [INFO] | | | +- org.jboss.logging:jboss-logging:jar:3.1.0.GA:compile [INFO] | | | +- org.jboss.spec.javax.transaction:jboss-transaction-api_1.1_spec:jar:1.0.0.Final:compile [INFO] | | | +- dom4j:dom4j:jar:1.6.1:compile [INFO] | | | +- org.hibernate.javax.persistence:hibernate-jpa-2.0-api:jar:1.0.1.Final:compile [INFO] | | | +- org.javassist:javassist:jar:3.15.0-GA:compile [INFO] | | | \- org.hibernate.common:hibernate-commons-annotations:jar:4.0.1.Final:compile [INFO] | | | \- (org.jboss.logging:jboss-logging:jar:3.1.0.CR2:compile - omitted for conflict with 3.1.0.GA) Running the enforcer rule DependencyConvergence results in an error: [ERROR] Dependency convergence error for org.jboss.logging:jboss-logging:3.1.0.GA paths to dependency are: +-ourgroup:rules-assembly:11-SNAPSHOT +-ourgroup:scoring:139 +-ourgroup:nic-api:103 +-ourgroup:persistence:2.22-Hibernate4 +-org.hibernate:hibernate-core:4.1.2.Final +-org.jboss.logging:jboss-logging:3.1.0.GA and +-ourgroup:rules-assembly:11-SNAPSHOT +-ourgroup:scoring:139 +-ourgroup:nic-api:103 +-ourgroup:persistence:2.22-Hibernate4 +-org.hibernate:hibernate-core:4.1.2.Final +-org.hibernate.common:hibernate-commons-annotations:4.0.1.Final +-org.jboss.logging:jboss-logging:3.1.0.CR2 This feels unexpected. Is this a bug, or do I understand s.th. wrong:) Thanks a lot, Leif -- View this message in context: http://maven.40175.n5.nabble.com/Strange-difference-between-enforcer-dependency-convergence-and-dependency-tree-hibernate4-jboss-logg-tp5693140.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: Reducing SNAPSHOT redundancy
How many build plans do you have? If I understood correctly single plan for all modules (perhaps on aggregate pom). Even small change in one module rebuilds all modules :-( Let's consider to define one build plan for each module. In addition define dependencies between build plans to reflect dependencies between maven modules (Bamboo discovers dependencies automatically). For sure, it requires a lot of configuration on continuous server but it works. Only changed module and all dependents will be built and deployed. Marcin On 7 May 2012 23:07, Curtis Rueden ctrue...@wisc.edu wrote: Hi Anders, Thanks for your reply. I believe the common way to handle this is to schedule purging of old snapshots in the repo manager. At least that's how I handle it in my setups. Indeed, our Nexus is set to purge old snapshots daily, deleting any that are more than 7 days old. This works just fine. This is very helpful since it effectively bounds the disk space requirement based on the number of builds that happen in a 7-day window. However, my concern is more regarding the fact that the snapshot binaries cycle all the time. That is, they are being continually replaced with new builds, which may in fact be based on identical source code, every time someone pushes to the Git repository. The unfortunate side effect is that all developers on the project generally have to redownload all submodule JARs once every 24 hours (whenever Maven snapshots are refreshed). Regards, Curtis On Mon, May 7, 2012 at 3:53 PM, Anders Hammar and...@hammar.net wrote: I believe the common way to handle this is to schedule purging of old snapshots in the repo manager. At least that's how I handle it in my setups. /Anders On Mon, May 7, 2012 at 10:31 PM, Curtis Rueden ctrue...@wisc.edu wrote: Hi everyone, I have a question about snapshot deployment. I have a multi-module project with ~30 modules, all in a Git repository on GitHub. Whenever someone pushes to the repository, a GitHub notification hook pings our Jenkins to do a rebuild, which includes a redeploy to our Nexus. This is all great. However, there is a lot of redundancy between snapshot JAR files. Often, a commit will involve only one of the 30 submodules, but all 30 will ultimately be rebuilt and redeployed, resulting in a plethora of snapshot versions. At any point in time, there is nearly always a new version of any given submodule of the project. I was wondering about the best way to reduce this issue. It would be nice to only redeploy snapshots that have actually changed—or better, for Maven (client-side) or Nexus (server-side) to detect identical snapshots and not waste the space creating a superfluous new one. (Of course, for a variety of reasons, comparing binary hashes between the latest snapshot JAR and the new snapshot candidate may not be enough—especially if the build process or CI adds some build-specific information to the JAR. But that is not really Maven's problem...) Alternately, we could do something on the CI side to only do the deploy if the submodule is really known to have changed—probably involving git reflogs etc. But that road could quickly become fraught with peril... So my question is: is there a common Maven best practice to mitigate such redundancy? Or do most people simply live with the proliferation of snapshots that occurs when using a naive deployment scheme? Thanks, Curtis - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven-shade-plugin unziped uber.jar
Is there a way to use the maven-shade-plugin to produce an unzipped uber-jar? I know that this can be done using maven-dependency-plugin, but it seems to be much slower and doesn't have some of the features that shade has (like transformers).
RE: Reducing SNAPSHOT redundancy
In my experience, I notice a certain lifecycle with builds. They start off relatively small but as the releases and years pass, the build grows and evolves. More things get tacked on, more modules get added, and so forth. I find that over time, the earlier modules of the build change less and less. There can be any number of reasons for this (feature content for that area is relatively stable and needs fewer and fewer enhancements, etc..). Whatever the reason, what this tells me is that those modules no longer need to be built over and over again. They can be broken out into their own trunk and built and versioned independently. This would shorten your build time, which is vital in a CI kind of environment where you want to have a change tested and get feedback on the build as quickly as possible. Now 30 modules is still relatively small. I am not sure how long your turn around time is. I start to get a bit concerned once a build approaches 10 minutes. Once it does, I start to ask questions like Are all modules of this build changing constantly? If not, which ones are not and why? Which of these can and should be considered to be pulled out into their own trunk. I find that this line of thinking not only helps to keep all build times fast, but it also helps to keep a healthy high quality code base which promotes re-use. Anyway, that's my 2 cents. -Original Message- From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On Behalf Of Curtis Rueden Sent: Monday, May 07, 2012 4:32 PM To: Maven Users List Cc: Johannes Schindelin Subject: Reducing SNAPSHOT redundancy Hi everyone, I have a question about snapshot deployment. I have a multi-module project with ~30 modules, all in a Git repository on GitHub. Whenever someone pushes to the repository, a GitHub notification hook pings our Jenkins to do a rebuild, which includes a redeploy to our Nexus. This is all great. However, there is a lot of redundancy between snapshot JAR files. Often, a commit will involve only one of the 30 submodules, but all 30 will ultimately be rebuilt and redeployed, resulting in a plethora of snapshot versions. At any point in time, there is nearly always a new version of any given submodule of the project. I was wondering about the best way to reduce this issue. It would be nice to only redeploy snapshots that have actually changed-or better, for Maven (client-side) or Nexus (server-side) to detect identical snapshots and not waste the space creating a superfluous new one. (Of course, for a variety of reasons, comparing binary hashes between the latest snapshot JAR and the new snapshot candidate may not be enough-especially if the build process or CI adds some build-specific information to the JAR. But that is not really Maven's problem...) Alternately, we could do something on the CI side to only do the deploy if the submodule is really known to have changed-probably involving git reflogs etc. But that road could quickly become fraught with peril... So my question is: is there a common Maven best practice to mitigate such redundancy? Or do most people simply live with the proliferation of snapshots that occurs when using a naive deployment scheme? Thanks, Curtis - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Modules in multi-module project being build twice
Hi Guys, I have a multi-module project to which I recently added a new module as the last module. When I build the project it builds all modules but the last module fine and then fails to build the last module and gives the stack trace below. [ERROR] Failed to execute goal org.codehaus.mojo:jaxws-maven-plugin:1.9:wsimport (default) on project : org.apache.xerces.parsers.XML 11Configuration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:jaxws-maven-plugin:1.9:wsimport (default) on projec t regrep-bindings: org.apache.xerces.parsers.XML11Configuration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration 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.MojoExecutor.executeForkedExecutions(MojoExecutor.java:365) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:199) 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:320) 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: org.apache.xerces.parsers.XML11Configuration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration at org.codehaus.mojo.jaxws.WsImportMojo.execute(WsImportMojo.java:204) at org.codehaus.mojo.jaxws.MainWsImportMojo.execute(MainWsImportMojo.java:15) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 23 more Caused by: java.lang.ClassCastException: org.apache.xerces.parsers.XML11Configuration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration at org.apache.xerces.parsers.SAXParser.init(Unknown Source) at org.apache.xerces.parsers.SAXParser.init(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.init(Unknown Source) at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source) at com.sun.org.apache.xml.internal.resolver.readers.SAXCatalogReader.readCatalog(SAXCatalogReader.java:238) at com.sun.org.apache.xml.internal.resolver.Catalog.parseCatalog(Catalog.java:680) at com.sun.xml.ws.util.xml.XmlUtil.createEntityResolver(XmlUtil.java:270) at com.sun.tools.ws.wscompile.WsimportOptions.parseArguments(WsimportOptions.java:207) at com.sun.tools.ws.wscompile.WsimportOptions.parseArguments(WsimportOptions.java:149) at com.sun.tools.ws.wscompile.WsimportTool.run(WsimportTool.java:167) at org.codehaus.mojo.jaxws.WsImportMojo.wsImport(WsImportMojo.java:274) at org.codehaus.mojo.jaxws.WsImportMojo.processLocalWsdlFiles(WsImportMojo.java:236) at org.codehaus.mojo.jaxws.WsImportMojo.execute(WsImportMojo.java:191) ... 26 more The last module is really just to perform an assembly of a zip file from artifacts in various other modules using maven-assembly-plugin. When I inspect the log (with -X option on) I see something strange that I cannot explain.
Re: Reducing SNAPSHOT redundancy
+1 Ron On 08/05/2012 8:39 AM, Thiessen, Todd (Todd) wrote: In my experience, I notice a certain lifecycle with builds. They start off relatively small but as the releases and years pass, the build grows and evolves. More things get tacked on, more modules get added, and so forth. I find that over time, the earlier modules of the build change less and less. There can be any number of reasons for this (feature content for that area is relatively stable and needs fewer and fewer enhancements, etc..). Whatever the reason, what this tells me is that those modules no longer need to be built over and over again. They can be broken out into their own trunk and built and versioned independently. This would shorten your build time, which is vital in a CI kind of environment where you want to have a change tested and get feedback on the build as quickly as possible. Now 30 modules is still relatively small. I am not sure how long your turn around time is. I start to get a bit concerned once a build approaches 10 minutes. Once it does, I start to ask questions like Are all modules of this build changing constantly? If not, which ones are not and why? Which of these can and should be considered to be pulled out into their own trunk. I find that this line of thinking not only helps to keep all build times fast, but it also helps to keep a healthy high quality code base which promotes re-use. Anyway, that's my 2 cents. -Original Message- From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On Behalf Of Curtis Rueden Sent: Monday, May 07, 2012 4:32 PM To: Maven Users List Cc: Johannes Schindelin Subject: Reducing SNAPSHOT redundancy Hi everyone, I have a question about snapshot deployment. I have a multi-module project with ~30 modules, all in a Git repository on GitHub. Whenever someone pushes to the repository, a GitHub notification hook pings our Jenkins to do a rebuild, which includes a redeploy to our Nexus. This is all great. However, there is a lot of redundancy between snapshot JAR files. Often, a commit will involve only one of the 30 submodules, but all 30 will ultimately be rebuilt and redeployed, resulting in a plethora of snapshot versions. At any point in time, there is nearly always a new version of any given submodule of the project. I was wondering about the best way to reduce this issue. It would be nice to only redeploy snapshots that have actually changed-or better, for Maven (client-side) or Nexus (server-side) to detect identical snapshots and not waste the space creating a superfluous new one. (Of course, for a variety of reasons, comparing binary hashes between the latest snapshot JAR and the new snapshot candidate may not be enough-especially if the build process or CI adds some build-specific information to the JAR. But that is not really Maven's problem...) Alternately, we could do something on the CI side to only do the deploy if the submodule is really known to have changed-probably involving git reflogs etc. But that road could quickly become fraught with peril... So my question is: is there a common Maven best practice to mitigate such redundancy? Or do most people simply live with the proliferation of snapshots that occurs when using a naive deployment scheme? Thanks, Curtis - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Some questions about Webby
Hi, today I decided to give Webby a try. Apart from Webby Core I also installed the embedded Jetty 8.x container. So far, so good. Some questions: a) How does Webby deal with dependencies having their scope set to provided? Our applications are mostly WARs / EARs that are deployed into WebSphere Application Server 7.x. Therefore a couple of dependencies such as javax.servlet:servlet-api or javax.mail:mail are specified in the pom.xml's with scope provided. Using such an application with the embedded Jetty container results in ClassNotFoundExceptions; using a local Tomcat 7.x installation (on which I have the necessary jars copied into the lib folder) works, although it seems to me to take a bit longer for startup. b) Can I use Webby to debug web applications via HTTPS? The locally installed Tomcat instance is already configured for accepting SSL connections. This works well as long as I'm debugging my application via Eclipse, WTP and m2eclipse-wtp, but obviously not when using Webby. Creating a run or debug configuration lets me only choose a normal HTTP port, but there's nothing about HTTPS... Regards Thorsten
Re: maven-assembly-plugin causing modules in multi-module project being build twice
I have confirmed that my weird problem of building the multi-module project a second time is happening due to the maven-assembly-plugin. If I configure the pom for last (problem) modules to not bind maven-assembly-plugin to any goal then the build happens once and all is well. So what would cause the maven-assembly-plugin to build my multi-module project again? Note that a few of the sub-modules of the root / parent pom are also dependencies of the module with the maven-assembly-plugin and used in dependencySets of the assembly.xml file. On 05/08/2012 09:21 AM, Farrukh Najmi wrote: Hi Guys, I have a multi-module project to which I recently added a new module as the last module. When I build the project it builds all modules but the last module fine and then fails to build the last module and gives the stack trace below. [ERROR] Failed to execute goal org.codehaus.mojo:jaxws-maven-plugin:1.9:wsimport (default) on project : org.apache.xerces.parsers.XML 11Configuration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:jaxws-maven-plugin:1.9:wsimport (default) on projec t regrep-bindings: org.apache.xerces.parsers.XML11Configuration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration 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.MojoExecutor.executeForkedExecutions(MojoExecutor.java:365) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:199) 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:320) 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: org.apache.xerces.parsers.XML11Configuration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration at org.codehaus.mojo.jaxws.WsImportMojo.execute(WsImportMojo.java:204) at org.codehaus.mojo.jaxws.MainWsImportMojo.execute(MainWsImportMojo.java:15) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 23 more Caused by: java.lang.ClassCastException: org.apache.xerces.parsers.XML11Configuration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration at org.apache.xerces.parsers.SAXParser.init(Unknown Source) at org.apache.xerces.parsers.SAXParser.init(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.init(Unknown Source) at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source) at com.sun.org.apache.xml.internal.resolver.readers.SAXCatalogReader.readCatalog(SAXCatalogReader.java:238) at com.sun.org.apache.xml.internal.resolver.Catalog.parseCatalog(Catalog.java:680) at com.sun.xml.ws.util.xml.XmlUtil.createEntityResolver(XmlUtil.java:270) at com.sun.tools.ws.wscompile.WsimportOptions.parseArguments(WsimportOptions.java:207) at
Re: Strange difference between enforcer dependency convergence and dependency tree (hibernate4/jboss-logging)
I'm a bit lost. We are using Hibernate4. Unfortunately they mixed up their dependencies a bit, so that we managed them in our pom: Perhaps you need to use an exclusion in the project-level hibernate dependency against jboss-logging, then add it back in yourself with a project-level dependency against jboss-logging? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-assembly-plugin causing modules in multi-module project being build twice
So what would cause the maven-assembly-plugin to build my multi-module project again? Note that a few of the sub-modules of the root / parent pom are also dependencies of the module with the maven-assembly-plugin and used in dependencySets of the assembly.xml file. What do your pom.xml and assembly.xml configuration files look like? Post them at Gist and send us a link. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Modules in multi-module project being build twice
You're using the wrong goal of the maven-assembly-plugin in that module. It should be the single goal. /Anders On Tue, May 8, 2012 at 3:21 PM, Farrukh Najmi farr...@wellfleetsoftware.com wrote: Hi Guys, I have a multi-module project to which I recently added a new module as the last module. When I build the project it builds all modules but the last module fine and then fails to build the last module and gives the stack trace below. [ERROR] Failed to execute goal org.codehaus.mojo:jaxws-maven-plugin:1.9:wsimport (default) on project : org.apache.xerces.parsers.XML 11Configuration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:jaxws-maven-plugin:1.9:wsimport (default) on projec t regrep-bindings: org.apache.xerces.parsers.XML11Configuration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration 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.MojoExecutor.executeForkedExecutions(MojoExecutor.java:365) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:199) 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:320) 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: org.apache.xerces.parsers.XML11Configuration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration at org.codehaus.mojo.jaxws.WsImportMojo.execute(WsImportMojo.java:204) at org.codehaus.mojo.jaxws.MainWsImportMojo.execute(MainWsImportMojo.java:15) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 23 more Caused by: java.lang.ClassCastException: org.apache.xerces.parsers.XML11Configuration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration at org.apache.xerces.parsers.SAXParser.init(Unknown Source) at org.apache.xerces.parsers.SAXParser.init(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.init(Unknown Source) at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source) at com.sun.org.apache.xml.internal.resolver.readers.SAXCatalogReader.readCatalog(SAXCatalogReader.java:238) at com.sun.org.apache.xml.internal.resolver.Catalog.parseCatalog(Catalog.java:680) at com.sun.xml.ws.util.xml.XmlUtil.createEntityResolver(XmlUtil.java:270) at com.sun.tools.ws.wscompile.WsimportOptions.parseArguments(WsimportOptions.java:207) at com.sun.tools.ws.wscompile.WsimportOptions.parseArguments(WsimportOptions.java:149) at com.sun.tools.ws.wscompile.WsimportTool.run(WsimportTool.java:167) at org.codehaus.mojo.jaxws.WsImportMojo.wsImport(WsImportMojo.java:274) at org.codehaus.mojo.jaxws.WsImportMojo.processLocalWsdlFiles(WsImportMojo.java:236) at org.codehaus.mojo.jaxws.WsImportMojo.execute(WsImportMojo.java:191) ... 26 more The last module is really just to
How to compile some modules with a specific JDK, the rest with default JDK
Hello Maven users, It is possible to tell maven to compile a specific module with a different JDK than the rest of the project? So say than the master pom has this: . |-- X |-- Y |-- Z Now Y and Z require the new JDK, while X can use the default (there is no dependency between X, Y and Z). So far the documentation I found explains how to override the JDK for the whole project: http://docs.codehaus.org/display/MAVENUSER/Compile+and+Test+with+Different+JDK+Versions Thanks in advance, --Jose ___ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays offers premier investment banking products and services to its clients through Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ___
Re: Reducing SNAPSHOT redundancy
Yet another way of configuring your multi-module build on CI is to NOT just do mvn deploy. The key thing with CI is that you want to verify the build, right? And get quick feedback on errors. Doing mvn dpeloy on a larger multi-module build will not do this for the latter part of the build. So, what you want is mvn test. You will then not waste time creating jars that you don't really need (for verifying the build). That build could then trigger a mvn deploy (possibly with -DskipTests) job to push to the repo. Or even better, a second step of the same job (which will ensure that it's the same code base being used and not a fresh checkout). /Anders On Tue, May 8, 2012 at 3:26 PM, Ron Wheeler rwhee...@artifact-software.com wrote: +1 Ron On 08/05/2012 8:39 AM, Thiessen, Todd (Todd) wrote: In my experience, I notice a certain lifecycle with builds. They start off relatively small but as the releases and years pass, the build grows and evolves. More things get tacked on, more modules get added, and so forth. I find that over time, the earlier modules of the build change less and less. There can be any number of reasons for this (feature content for that area is relatively stable and needs fewer and fewer enhancements, etc..). Whatever the reason, what this tells me is that those modules no longer need to be built over and over again. They can be broken out into their own trunk and built and versioned independently. This would shorten your build time, which is vital in a CI kind of environment where you want to have a change tested and get feedback on the build as quickly as possible. Now 30 modules is still relatively small. I am not sure how long your turn around time is. I start to get a bit concerned once a build approaches 10 minutes. Once it does, I start to ask questions like Are all modules of this build changing constantly? If not, which ones are not and why? Which of these can and should be considered to be pulled out into their own trunk. I find that this line of thinking not only helps to keep all build times fast, but it also helps to keep a healthy high quality code base which promotes re-use. Anyway, that's my 2 cents. -Original Message- From: ctrueden.w...@gmail.com [mailto:ctrueden.w...@gmail.com] On Behalf Of Curtis Rueden Sent: Monday, May 07, 2012 4:32 PM To: Maven Users List Cc: Johannes Schindelin Subject: Reducing SNAPSHOT redundancy Hi everyone, I have a question about snapshot deployment. I have a multi-module project with ~30 modules, all in a Git repository on GitHub. Whenever someone pushes to the repository, a GitHub notification hook pings our Jenkins to do a rebuild, which includes a redeploy to our Nexus. This is all great. However, there is a lot of redundancy between snapshot JAR files. Often, a commit will involve only one of the 30 submodules, but all 30 will ultimately be rebuilt and redeployed, resulting in a plethora of snapshot versions. At any point in time, there is nearly always a new version of any given submodule of the project. I was wondering about the best way to reduce this issue. It would be nice to only redeploy snapshots that have actually changed-or better, for Maven (client-side) or Nexus (server-side) to detect identical snapshots and not waste the space creating a superfluous new one. (Of course, for a variety of reasons, comparing binary hashes between the latest snapshot JAR and the new snapshot candidate may not be enough-especially if the build process or CI adds some build-specific information to the JAR. But that is not really Maven's problem...) Alternately, we could do something on the CI side to only do the deploy if the submodule is really known to have changed-probably involving git reflogs etc. But that road could quickly become fraught with peril... So my question is: is there a common Maven best practice to mitigate such redundancy? Or do most people simply live with the proliferation of snapshots that occurs when using a naive deployment scheme? Thanks, Curtis - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - 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: Reducing SNAPSHOT redundancy
On Tue, May 8, 2012 at 12:05 PM, Anders Hammar and...@hammar.net wrote: Doing mvn dpeloy on a larger multi-module build will not do this for the latter part of the build. So, what you want is mvn test. Dumb, slightly tangential question: will mvn -o clean test on a multi-module build work? My assumption (untested, to be sure) is that it would not. I would think that install is still necessary for tests in a given module that depend on artifacts produced by another module, so that those artifacts are present in the local repo. Best, Laird -- http://about.me/lairdnelson
Re: How to compile some modules with a specific JDK, the rest with default JDK
Should be possible. Just configure this in that module, and not in the parent pom. /Anders On Tue, May 8, 2012 at 6:03 PM, jose.nunez-zul...@barclays.com wrote: Hello Maven users, It is possible to tell maven to compile a specific module with a different JDK than the rest of the project? So say than the master pom has this: . |-- X |-- Y |-- Z Now Y and Z require the new JDK, while X can use the default (there is no dependency between X, Y and Z). So far the documentation I found explains how to override the JDK for the whole project: http://docs.codehaus.org/display/MAVENUSER/Compile+and+Test+with+Different+JDK+Versions Thanks in advance, --Jose ___ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays offers premier investment banking products and services to its clients through Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ___ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Reducing SNAPSHOT redundancy
Don't add -o to this. That's something different not impacting artifacts produced in a multi-module build. install is not required for a multi-module build. (It is sometimes when using Maven 2, but everyone should be using Maven 3 so this is not a problem.) The so-called reactor of a multi-module build will handle the artifact not being present but rather use the content of the target folders. /Anders On Tue, May 8, 2012 at 6:09 PM, Laird Nelson ljnel...@gmail.com wrote: On Tue, May 8, 2012 at 12:05 PM, Anders Hammar and...@hammar.net wrote: Doing mvn dpeloy on a larger multi-module build will not do this for the latter part of the build. So, what you want is mvn test. Dumb, slightly tangential question: will mvn -o clean test on a multi-module build work? My assumption (untested, to be sure) is that it would not. I would think that install is still necessary for tests in a given module that depend on artifacts produced by another module, so that those artifacts are present in the local 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: Reducing SNAPSHOT redundancy
On Tue, May 8, 2012 at 12:13 PM, Anders Hammar and...@hammar.net wrote: Don't add -o to this. That's something different not impacting artifacts produced in a multi-module build. Right; I know; it sets the offline status. I used it here to prove a point: that when present, Maven will not go to remote repositories. I wanted to force readers to think about the fact that no repo other than the local one had the potential of being used. install is not required for a multi-module build. (It is sometimes when using Maven 2, but everyone should be using Maven 3 so this is not a problem.) The so-called reactor of a multi-module build will handle the artifact not being present but rather use the content of the target folders. Aha; that would explain why my maven-dependency-plugin:unpack goal keeps failing on trying to unpack a directory. Some days you just can't win. :-) Thanks for the tip, though! Best, Laird -- http://about.me/lairdnelson
RE: How to compile some modules with a specific JDK, the rest with default JDK
Works like a charm (tested with mvn -X), inside the pom:
project ...
nameX/name
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-compiler-plugin/artifactId
version2.3.2/version
configuration
source1.7/source
target1.7/target
verbosetrue/verbose
forktrue/fork
executable${env.HOME}/myjdkdir/jdk1.7.0/bin/javac/executable
compilerVersion1.7/compilerVersion
/configuration
/plugin
/plugins
/build
/project
-Original Message-
From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of
Anders Hammar
Sent: Tuesday, May 08, 2012 12:11 PM
To: Maven Users List
Subject: Re: How to compile some modules with a specific JDK, the rest with
default JDK
Should be possible. Just configure this in that module, and not in the
parent pom.
/Anders
On Tue, May 8, 2012 at 6:03 PM, jose.nunez-zul...@barclays.com wrote:
Hello Maven users,
It is possible to tell maven to compile a specific module with a different
JDK than the rest of the project?
So say than the master pom has this:
.
|-- X
|-- Y
|-- Z
Now Y and Z require the new JDK, while X can use the default (there is no
dependency between X, Y and Z).
So far the documentation I found explains how to override the JDK for the
whole project:
http://docs.codehaus.org/display/MAVENUSER/Compile+and+Test+with+Different+JDK+Versions
Thanks in advance,
--Jose
___
This e-mail may contain information that is confidential, privileged or
otherwise protected from
disclosure. If you are not an intended recipient of this e-mail, do not
duplicate or redistribute
it by any means. Please delete it and any attachments and notify the sender
that you have received
it in error. Unless specifically indicated, this e-mail is not an offer to
buy or sell or a
solicitation to buy or sell any securities, investment products or other
financial product or
service, an official confirmation of any transaction, or an official
statement of Barclays. Any
views or opinions presented are solely those of the author and do not
necessarily represent those
of Barclays. This e-mail is subject to terms available at the following link:
www.barcap.com/emaildisclaimer.
By messaging with Barclays you consent to the foregoing. Barclays offers
premier investment banking
products and services to its clients through Barclays Bank PLC, a company
registered in England
(number 1026167) with its registered office at 1 Churchill Place, London, E14
5HP. This email may
relate to or be sent from other members of the Barclays Group.
___
-
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: Modules in multi-module project being build twice
Doh! Anders you are absolutely right. That was it and my problem is solved. I wonder if it would make sense to log big fat warnings when using the deprecated goals of plugins. It would save many people at least a day of grief ;-) Thanks again for your kind help. On 05/08/2012 11:57 AM, Anders Hammar wrote: You're using the wrong goal of the maven-assembly-plugin in that module. It should be the single goal. /Anders On Tue, May 8, 2012 at 3:21 PM, Farrukh Najmi farr...@wellfleetsoftware.com wrote: Hi Guys, I have a multi-module project to which I recently added a new module as the last module. When I build the project it builds all modules but the last module fine and then fails to build the last module and gives the stack trace below. [ERROR] Failed to execute goal org.codehaus.mojo:jaxws-maven-plugin:1.9:wsimport (default) on project : org.apache.xerces.parsers.XML 11Configuration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration - [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:jaxws-maven-plugin:1.9:wsimport (default) on projec t regrep-bindings: org.apache.xerces.parsers.XML11Configuration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration 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.MojoExecutor.executeForkedExecutions(MojoExecutor.java:365) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:199) 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:320) 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: org.apache.xerces.parsers.XML11Configuration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration at org.codehaus.mojo.jaxws.WsImportMojo.execute(WsImportMojo.java:204) at org.codehaus.mojo.jaxws.MainWsImportMojo.execute(MainWsImportMojo.java:15) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 23 more Caused by: java.lang.ClassCastException: org.apache.xerces.parsers.XML11Configuration cannot be cast to org.apache.xerces.xni.parser.XMLParserConfiguration at org.apache.xerces.parsers.SAXParser.init(Unknown Source) at org.apache.xerces.parsers.SAXParser.init(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl.init(Unknown Source) at org.apache.xerces.jaxp.SAXParserFactoryImpl.newSAXParser(Unknown Source) at com.sun.org.apache.xml.internal.resolver.readers.SAXCatalogReader.readCatalog(SAXCatalogReader.java:238) at com.sun.org.apache.xml.internal.resolver.Catalog.parseCatalog(Catalog.java:680) at com.sun.xml.ws.util.xml.XmlUtil.createEntityResolver(XmlUtil.java:270) at com.sun.tools.ws.wscompile.WsimportOptions.parseArguments(WsimportOptions.java:207) at com.sun.tools.ws.wscompile.WsimportOptions.parseArguments(WsimportOptions.java:149) at com.sun.tools.ws.wscompile.WsimportTool.run(WsimportTool.java:167) at
Maven Changes Plugin 2.8?
Hi, Any plans for releasing Maven Changes Plugin 2.8? http://jira.codehaus.org/browse/MCHANGES/fixforversion/18463 This version really contains only one but imp fix for Jira 5.X - http://jira.codehaus.org/browse/MCHANGES-281 I really want to avoid using the 2.8-SNAPSHOT. Thx, swapsapar
Re: Maven Changes Plugin 2.8?
We only just released 2.7 days ago. I doubt that anyone has the energy to respin right this minute. On Tue, May 8, 2012 at 1:19 PM, Swapnil Sapar swapsa...@gmail.com wrote: Hi, Any plans for releasing Maven Changes Plugin 2.8? http://jira.codehaus.org/browse/MCHANGES/fixforversion/18463 This version really contains only one but imp fix for Jira 5.X - http://jira.codehaus.org/browse/MCHANGES-281 I really want to avoid using the 2.8-SNAPSHOT. Thx, swapsapar - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Some questions about Webby
today I decided to give Webby a try. Apart from Webby Core I also installed the embedded Jetty 8.x container. So far, so good. I have to imagine that you will have better success with this line of questioning in an Eclipse M2E users list or some Sonatype user list. There may even be a Webby user list somewhere if you dig. Webby has nothing to do with ASF or Apache Maven itself. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: resolver-status.properties read/write warnings
On Thu, Apr 19, 2012 at 7:08 AM, Jason van Zyl ja...@tesla.io wrote: Separate repos work. If you absolutely needed a concurrent safe local repo there's one here: https://github.com/etesla/tesla-concurrent-localrepo Link is not valid anymore Jeff On Apr 18, 2012, at 10:03 PM, Bracewell, Robert wrote: I wasn't aware that a shared local repo wasn't supported. I just switched over all nodes to a local repo throughout the build farm and the warnings did indeed disappear. Version of Java used on this particular OSX node is java version 1.6.0_31 Java(TM) SE Runtime Environment (build 1.6.0_31-b04-415-11M3635) Java HotSpot(TM) 64-Bit Server VM (build 20.6-b01-415, mixed mode) Thanks, Robert On 4/18/12 6:44 PM, Wayne Fay wayne...@gmail.com wrote: farm. The Maven repo is hosted on a net app box that is visible to all my Redhat, Windows and now OSX build nodes via an NFS mount. The build ... It seems you are using a shared local repository which is not supported Agreed on this point. You must use a local repo cache on each machine. And you should ensure that you only have 1 Maven instance access eaching local repo cache at once as well. If you're using Jenkins/Hudson, this is simple to configure. When running any mvn command (tried 3.0.3 and 3.0.4) on OSX Lion I see What version of Java are you running? java.io.IOException: Operation not supported at sun.nio.ch.FileChannelImpl.lock0(Native Method) at sun.nio.ch.FileChannelImpl.lock(FileChannelImpl.java:832) at org.sonatype.aether.impl.internal.TrackingFileManager.lock(TrackingFileM anager.java:209) This stacktrace suggests to me that your OS does not support file locking over NFS? Look at sun.nio.ch.FileChannelImpl for more info. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - We know what we are, but know not what we may be. -- Shakespeare -- Jeff MAURY Legacy code often differs from its suggested alternative by actually working and scaling. - Bjarne Stroustrup http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.twitter.com/jeffmaury
Re: Maven Changes Plugin 2.8?
Right. I understand its only 1 bug since 2.7 but its an imp fix without which plugin fails to work with Jira 5. Is there a way to get the release sooner? Is there a way for me to help in this regard? Thx, swapsapar On Tue, May 8, 2012 at 10:19 AM, Swapnil Sapar swapsa...@gmail.com wrote: Hi, Any plans for releasing Maven Changes Plugin 2.8?
Re: Maven Changes Plugin 2.8?
On Tue, May 8, 2012 at 6:41 PM, Swapnil Sapar swapsa...@gmail.com wrote: Right. I understand its only 1 bug since 2.7 but its an imp fix without which plugin fails to work with Jira 5. Is there a way to get the release sooner? Is there a way for me to help in this regard? I'll tell you what. Could you see if you can reproduce MCHANGES-280? In return, I'll spin another release soon, either right away if you can't or after I figure out a fix if you can. Thx, swapsapar On Tue, May 8, 2012 at 10:19 AM, Swapnil Sapar swapsa...@gmail.com wrote: Hi, Any plans for releasing Maven Changes Plugin 2.8? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Reducing SNAPSHOT redundancy
Dear Todd, On Tue, 8 May 2012, Thiessen, Todd (Todd) wrote: In my experience, I notice a certain lifecycle with builds. They start off relatively small but as the releases and years pass, the build grows and evolves. More things get tacked on, more modules get added, and so forth. I find that over time, the earlier modules of the build change less and less. There can be any number of reasons for this (feature content for that area is relatively stable and needs fewer and fewer enhancements, etc..). Whatever the reason, what this tells me is that those modules no longer need to be built over and over again. They can be broken out into their own trunk and built and versioned independently. This would shorten your build time, which is vital in a CI kind of environment where you want to have a change tested and get feedback on the build as quickly as possible. I am sorry, I disagree here. Breaking this out into different repositories -- when the code is logically one single project -- makes an artificial distinction just for the sake of helping the tools, at the cost of making it more difficult for new developers and thereby constructing a new barrier to entry, incurring a substantial social debt. See, at the moment it is as easy as git clone git://github.com/imagej/imagej cd imagej mvn Done. We would like to retain that ease of developing ImageJ, but on the other hand also reduce the amounts of data downloaded by developers who create projects on top of ImageJ. They should not need to download new snapshot versions every day when nothing might have changed. I appreciate your concern and your help in trying to improve our workflow, but in my opinion, changing the setup just to accomodate the current capabilities of the tools would be the wrong thing. If anybody has a suggestion how to teach Maven to avoid uploading new snapshot versions when nothing changed at all (except for the timestamps in the .jar file, that's all), I would be very grateful. Ciao, Johannes - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven replacer plugin
I want to replace the code snippet between two custom tag (@Start, @End) with
empty tag.
public class MyClass{
private String name;
private String age;
@Start
private String address;
private String phoneNumber;
@End
}
These tags are available in multiple files.
Is it possible using maven ? I was looking at
http://code.google.com/p/maven-replacer-plugin/
which is used for replacing text/value, i don't think this can be used for
replacing content. am i right ?
Regards
Pankaj
--
View this message in context:
http://maven.40175.n5.nabble.com/Maven-replacer-plugin-tp5696070.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: Maven replacer plugin
Hi,
I want to replace the code snippet between two custom tag (@Start, @End) with
empty tag.
public class MyClass{
private String name;
private String age;
@Start
private String address;
private String phoneNumber;
@End
}
These tags are available in multiple files.
Why not. Put the replacer plugin into the generate-sources or
process-sources phase and it should be working. The only problem you
have to which location you put the changed files and get them compiled.
May be you can use the buildhelper-maven-plugin to add a different
location afterwards (for example target/replaced-files)
Kind regards
Karl-Heinz Marbaise
--
SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029
Hauptstrasse 177 USt.IdNr: DE191347579
52146 Würselen http://www.soebes.de
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
circular dependency with common test classes
Hi, I'm a relatively new Maven user. I found an exact description of my problem on StackOverflow, but no solution: http://stackoverflow.com/questions/10174542/resolving-maven-circular-dependencies-between-test-testhelper-and-project-unde One can easily get around the problem by first building the core project with -Dmaven.test.skip=true. But the Eclipse plugin is not so smart and I can't load my projects in Eclipse. I think this a legitimate case that Maven should be able to solve on its own since the common test classes (Atesthelper in the StackOverflow post) are declared as a test scope dependency. Is there any solution available for this problem (splitting the main project in two is not an option, and it would be a terrible hack just to satisfy a Maven limitation)? Any plugin or configuration trick? Thanks much in advance! Boris
