Re: Manifest of WAR contains wrong references to SNAPSHOT-versions of EAR-based libaries
Probable you know already the reason why there is a timestamp and a buildnumber being attached to your Manifest classpath but for all those who will have the same issue I will provide a solution: You just have to add the following entry to your manifest configuration bundled with the maven war plguin: Setting the useUniqueVersions flag to false, which is true by default, instructs maven to use the SNAPSHOT-jar in the manifest classpath. -- View this message in context: http://maven.40175.n5.nabble.com/Manifest-of-WAR-contains-wrong-references-to-SNAPSHOT-versions-of-EAR-based-libaries-tp5717908p5724922.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: Manifest of WAR contains wrong references to SNAPSHOT-versions of EAR-based libaries
Just resending the part of Michael's email/post that was eaten by Nabble and not forwarded... You just have to add the following entry to your manifest configuration bundled with the maven war plguin: manifest addClasspathtrue/addClasspath useUniqueVersionsfalse/useUniqueVersions /manifest Wayne On Fri, Oct 5, 2012 at 5:03 AM, Michael Feichtegger mich...@feichtegger.at wrote: Probable you know already the reason why there is a timestamp and a buildnumber being attached to your Manifest classpath but for all those who will have the same issue I will provide a solution: You just have to add the following entry to your manifest configuration bundled with the maven war plguin: Setting the useUniqueVersions flag to false, which is true by default, instructs maven to use the SNAPSHOT-jar in the manifest classpath. -- View this message in context: http://maven.40175.n5.nabble.com/Manifest-of-WAR-contains-wrong-references-to-SNAPSHOT-versions-of-EAR-based-libaries-tp5717908p5724922.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
specifying different dependencies according to versions
Hello all, We recently changed the packaging of some modules in our application : dependency groupIdmy.company/groupId artifactIdmy.artifact.core/artifactId version2.5.0-SNAPSHOT/version /dependency to dependency groupIdmy.company.internal/groupId artifactIdmy.artifact.core/artifactId version2.6.0-SNAPSHOT/version /dependency as this is internal now, we created a new module dependency groupIdmy.company/groupId artifactIdmy.artifact/artifactId version2.6.0-SNAPSHOT/version /dependency I have a maven module that could depend on my.company:my.artifact.core:2.5.0-SNAPSHOT as well as any other following releases, including my.company:my.artifact:2.6.0-SNAPSHOT I could have used a version range such as: version[2.5.0,)/version if only my packaging did not change... My question is : can we tell maven to depend on my.company:my.artifact.core for a certain range of version and depend on my.company:my.artifact for another range of version? Thank you very much for your answers, Anthony - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: specifying different dependencies according to versions
What are you trying to accomplish? Why is your situation different from the normal system development process that everyone else uses. What version do you want to run at run-time? In the pom of the artifact that you are making, set the dependency to the version of artifactIdmy.artifact.core/artifactId that you want to build with. It is hard to see what you are trying to tell us with this as this is internal now, we created a new module dependency groupIdmy.company/groupId artifactIdmy.artifact/artifactId version2.6.0-SNAPSHOT/version /dependency In what POM does this dependency appear? Why? How does this relate to -core. If you followed last weeks discussion about version ranges, you might have noted that they are regarded by most as inherently evil and by others as poorly implemented. In general, you should pick a version of the dependency that you want to build with and identify it with a specific version. A range of SNAPSHOTs makes no sense to me at all. Ron On 05/10/2012 10:00 AM, Anthony Dahanne wrote: Hello all, We recently changed the packaging of some modules in our application : dependency groupIdmy.company/groupId artifactIdmy.artifact.core/artifactId version2.5.0-SNAPSHOT/version /dependency to dependency groupIdmy.company.internal/groupId artifactIdmy.artifact.core/artifactId version2.6.0-SNAPSHOT/version /dependency as this is internal now, we created a new module dependency groupIdmy.company/groupId artifactIdmy.artifact/artifactId version2.6.0-SNAPSHOT/version /dependency I have a maven module that could depend on my.company:my.artifact.core:2.5.0-SNAPSHOT as well as any other following releases, including my.company:my.artifact:2.6.0-SNAPSHOT I could have used a version range such as: version[2.5.0,)/version if only my packaging did not change... My question is : can we tell maven to depend on my.company:my.artifact.core for a certain range of version and depend on my.company:my.artifact for another range of version? Thank you very much for your answers, Anthony - 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
Two mojos of the same plugin: one has all compile source roots, the other hasn't
Hi all, I'm having an issue with a plugin. I have two mojos with the following annotations (yes, I haven't yet moved to Java5 annotations): * @goal run-codeserver * @execute phase=process-classes * @requiresDirectInvocation * @requiresDependencyResolution compile Source: https://github.com/gwt-maven-plugin/gwt-maven-plugin/blob/master/src/main/java/org/codehaus/mojo/gwt/shell/SuperDevModeMojo.java * @goal run * @execute phase=process-classes goal:war:exploded * @requiresDirectInvocation * @requiresDependencyResolution test Source: https://github.com/gwt-maven-plugin/gwt-maven-plugin/blob/master/src/main/java/org/codehaus/mojo/gwt/shell/RunMojo.java They both use the same code to build the classpath to pass to a forked java process, that puts project.getCompileSourceRoots() in that classpath. In a project using that plugin, another mojo is bound to the generate-sources phase and addCompileSourceRoot the folder containing the generated files (nothing fancy). The problem: when running mvn gwt:run, the folder added at the generate-sources phase is correctly added to the constructed classpath, but when using mvn gwt:run-codeserver it only contains src/main/java. What even stranger: the maven-compiler-plugin is invoked with both folders in both cases. Any idea why it behaves that way? Any hint where I could put breakpoints to help debug this? Could the goal:war:exploded added to the @execute annotation be the reason the folder is added to the compile source roots? If one wants to try it: mvn archetype:generate -DarchetypeGroupId=org.codehaus.mojo -DarchetypeArtifactId=gwt-maven-plugin -DarchetypeVersion=2.5.0-rc1 then mvn gwt:run or mvn gwt:run-codeserver Thanks in advance -- Thomas Broyer /tɔ.ma.bʁwa.je/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Incremental build help
What have you tried and what did it do? Did you read up on multi-module builds to see how they are supposed to work and what you need to do to make it happen? Ron On 05/10/2012 10:56 AM, Jan wrote: Hi All, I'm trying to see is there any best way or process to do incremental build using maven? Basically i have multi module project like show below, when i run mvn with -amd command how maven will compile only changed files? For Eg lets say i have - Project A | - Module-A | - Module-B | - Module-C | - Module- D Dependency wise B - A, C - A,B D - A,B,C In this setup when run my root pom from Project a location i expect maven to identify only C Module is changed, so it will compile C D. Will maven automatically finds which module code is updated or we have to pass the changed module as argument for build. Please help -- 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
Re: specifying different dependencies according to versions
Hello Ron, Let me try to explain with other terms what we have and we want to do : we have refactored an artifact, changing his name and even its group name; * from version 1.0.0 to 2.5.0, this artifact was named my.company:my.artifact.core:version * from version 2.5.1 and up , this artifact is named my.company:my.artifact:version We have consumers of this artifact, that may depend on it directly and indirectly. Well, we were afraid of dependency clashes, and this is why we talked about version ranges (imagining a dependency chooses the right version, and other ones, using range versions, just cope with it) instead of specifying directly the right version. Now reading your email, and trying to answer your questions , I finally found out that transitive dependencies clashes can be avoided with exclusion http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html Problem solved :-) Thanks, Anthony On Fri, Oct 5, 2012 at 10:14 AM, Ron Wheeler rwhee...@artifact-software.com wrote: What are you trying to accomplish? Why is your situation different from the normal system development process that everyone else uses. What version do you want to run at run-time? In the pom of the artifact that you are making, set the dependency to the version of artifactIdmy.artifact.core/artifactId that you want to build with. It is hard to see what you are trying to tell us with this as this is internal now, we created a new module dependency groupIdmy.company/groupId artifactIdmy.artifact/artifactId version2.6.0-SNAPSHOT/version /dependency In what POM does this dependency appear? Why? How does this relate to -core. If you followed last weeks discussion about version ranges, you might have noted that they are regarded by most as inherently evil and by others as poorly implemented. In general, you should pick a version of the dependency that you want to build with and identify it with a specific version. A range of SNAPSHOTs makes no sense to me at all. Ron On 05/10/2012 10:00 AM, Anthony Dahanne wrote: Hello all, We recently changed the packaging of some modules in our application : dependency groupIdmy.company/groupId artifactIdmy.artifact.core/artifactId version2.5.0-SNAPSHOT/version /dependency to dependency groupIdmy.company.internal/groupId artifactIdmy.artifact.core/artifactId version2.6.0-SNAPSHOT/version /dependency as this is internal now, we created a new module dependency groupIdmy.company/groupId artifactIdmy.artifact/artifactId version2.6.0-SNAPSHOT/version /dependency I have a maven module that could depend on my.company:my.artifact.core:2.5.0-SNAPSHOT as well as any other following releases, including my.company:my.artifact:2.6.0-SNAPSHOT I could have used a version range such as: version[2.5.0,)/version if only my packaging did not change... My question is : can we tell maven to depend on my.company:my.artifact.core for a certain range of version and depend on my.company:my.artifact for another range of version? Thank you very much for your answers, Anthony - 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: specifying different dependencies according to versions
Sorry for more questions than answers. I am glad that it provided a creative push. We use exclusions extensively in our builds to ensure that we get the right version at run-time and they work as advertised. Ron On 05/10/2012 11:30 AM, Anthony Dahanne wrote: Hello Ron, Let me try to explain with other terms what we have and we want to do : we have refactored an artifact, changing his name and even its group name; * from version 1.0.0 to 2.5.0, this artifact was named my.company:my.artifact.core:version * from version 2.5.1 and up , this artifact is named my.company:my.artifact:version We have consumers of this artifact, that may depend on it directly and indirectly. Well, we were afraid of dependency clashes, and this is why we talked about version ranges (imagining a dependency chooses the right version, and other ones, using range versions, just cope with it) instead of specifying directly the right version. Now reading your email, and trying to answer your questions , I finally found out that transitive dependencies clashes can be avoided with exclusion http://maven.apache.org/guides/introduction/introduction-to-optional-and-excludes-dependencies.html Problem solved :-) Thanks, Anthony On Fri, Oct 5, 2012 at 10:14 AM, Ron Wheeler rwhee...@artifact-software.com wrote: What are you trying to accomplish? Why is your situation different from the normal system development process that everyone else uses. What version do you want to run at run-time? In the pom of the artifact that you are making, set the dependency to the version of artifactIdmy.artifact.core/artifactId that you want to build with. It is hard to see what you are trying to tell us with this as this is internal now, we created a new module dependency groupIdmy.company/groupId artifactIdmy.artifact/artifactId version2.6.0-SNAPSHOT/version /dependency In what POM does this dependency appear? Why? How does this relate to -core. If you followed last weeks discussion about version ranges, you might have noted that they are regarded by most as inherently evil and by others as poorly implemented. In general, you should pick a version of the dependency that you want to build with and identify it with a specific version. A range of SNAPSHOTs makes no sense to me at all. Ron On 05/10/2012 10:00 AM, Anthony Dahanne wrote: Hello all, We recently changed the packaging of some modules in our application : dependency groupIdmy.company/groupId artifactIdmy.artifact.core/artifactId version2.5.0-SNAPSHOT/version /dependency to dependency groupIdmy.company.internal/groupId artifactIdmy.artifact.core/artifactId version2.6.0-SNAPSHOT/version /dependency as this is internal now, we created a new module dependency groupIdmy.company/groupId artifactIdmy.artifact/artifactId version2.6.0-SNAPSHOT/version /dependency I have a maven module that could depend on my.company:my.artifact.core:2.5.0-SNAPSHOT as well as any other following releases, including my.company:my.artifact:2.6.0-SNAPSHOT I could have used a version range such as: version[2.5.0,)/version if only my packaging did not change... My question is : can we tell maven to depend on my.company:my.artifact.core for a certain range of version and depend on my.company:my.artifact for another range of version? Thank you very much for your answers, Anthony - 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 -- 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
Re: Incremental build help
Currently i use buildforge with maven but i do execute them separately for each module, means runs mvn clean install commands from each module. This will basically cleans and compiles everything whether there is change or not. Now i'm trying to make use of incremental build function, so i changed to execute mvn install from parent project itself with the -amd option when i did this even though change is only in Module C it still did compilation on Module A B. I can understand the compilation part of Module D when there is a change in Module C but why A B?. Should i use incremental build instead of -amd option? Basically i just want to compile only changed source code files not everything everytime. On Fri, Oct 5, 2012 at 10:22 AM, Ron Wheeler rwhee...@artifact-software.com wrote: What have you tried and what did it do? Did you read up on multi-module builds to see how they are supposed to work and what you need to do to make it happen? Ron On 05/10/2012 10:56 AM, Jan wrote: Hi All, I'm trying to see is there any best way or process to do incremental build using maven? Basically i have multi module project like show below, when i run mvn with -amd command how maven will compile only changed files? For Eg lets say i have - Project A | - Module-A | - Module-B | - Module-C | - Module- D Dependency wise B - A, C - A,B D - A,B,C In this setup when run my root pom from Project a location i expect maven to identify only C Module is changed, so it will compile C D. Will maven automatically finds which module code is updated or we have to pass the changed module as argument for build. Please help -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Unifying maven-nar-plugin implementations
Greetings maven-nar-plugin hackers! I am writing to gauge interest in a unified implementation of maven-nar-plugin. It seems there are several active (and not-so-active) forks. It seems the original implementation (@duns) is no longer active, but both @GregDomjan and @richardkerr have active forks (the latter forked from the former), and merge improvements from other forks too. Before we were aware of this, my colleague (Johannes Schindelin) I started another fork (@scijava) to address some issues we had. which have since been merged into the @GregDomjan fork (although I could not find a cherry-picked commit... it must have been done in some non-standard way?). I would be happy to deprecate the @scijava fork in favor of the @GregDomjan code, if we can agree to standardize on one officially maintained repository. If we do go that route, it should not be too difficult to start releasing versions to Maven Central. Can all agree to start submitting PRs to Greg for any future patches, rather than silently maintaining our own forks? Greg, what do you think? Others? Apache/Sonatype/Codehaus developers: It appears that there was once a push for Apache to adopt maven-nar-plugin as a core plugin. Is that effort abandoned now? Is a unified GitHub project the best way forward for maven-nar-plugin? Or would it make more sense for one of the big Maven umbrella groups to adopt it instead? Thanks, Curtis On Fri, Sep 14, 2012 at 10:34 AM, Martin Eisengardt martin.eisenga...@gmail.com wrote: The author (@duns) seems to be not actve any more. However I failed contacting him for a while. https://github.com/GregDomjan/maven-nar-plugin And there is a second one being active: https://github.com/richardkerr/maven-nar-plugin (do not know how to contact this guy) However both try to merge the forks being around. And they like any kind of help. If there are some people around that want to give it a new try that would be nice. I guess the original plugin was some kind of sandbox @ sonatype. I do not know if we should simply group up some people that officially will maintain it and I do not know if even sonatype or others are interested. However for being pragmatic I would say to choose one of the active forks, grouping a new team and granting commit rights to the people that want to maintain it. I am able to provide both, a repository and a hudson as long as this is not moved to maven central. However I am personally focused on compiling php/php-extensions and using maven-nar-plugin to access them with maven. Multi-Platform compiles/ Cross-Platform compiles I will come back to the project as soon as our build server knows how to do cross compiles for various platforms. On Fri, Sep 14, 2012 at 5:09 PM, Curtis Rueden ctrue...@wisc.edu wrote: Hi Martin, There is a problem with the [maven-nar-plugin] project because there are tens of orks on github. If you have any questions about it please ask. I have contact to one of the ative authors and we try to merge all the forks. I am guilty of one of those forks. We submitted a PR ( https://github.com/duns/maven-nar-plugin/pull/5) but never heard back, so we had no choice. It looks like the canonical version at duns/maven-nar-plugin has not been updated for nearly two years. Is that going to change? It would be great for this very valuable plugin to be maintained! Thanks, Curtis
Re: Unifying maven-nar-plugin implementations
Hi all, Replying back with defunct email addresses purged, so that any future replies don't keep receiving bounces. -Curtis On Fri, Oct 5, 2012 at 11:09 AM, Curtis Rueden ctrue...@wisc.edu wrote: Greetings maven-nar-plugin hackers! I am writing to gauge interest in a unified implementation of maven-nar-plugin. It seems there are several active (and not-so-active) forks. It seems the original implementation (@duns) is no longer active, but both @GregDomjan and @richardkerr have active forks (the latter forked from the former), and merge improvements from other forks too. Before we were aware of this, my colleague (Johannes Schindelin) I started another fork (@scijava) to address some issues we had. which have since been merged into the @GregDomjan fork (although I could not find a cherry-picked commit... it must have been done in some non-standard way?). I would be happy to deprecate the @scijava fork in favor of the @GregDomjan code, if we can agree to standardize on one officially maintained repository. If we do go that route, it should not be too difficult to start releasing versions to Maven Central. Can all agree to start submitting PRs to Greg for any future patches, rather than silently maintaining our own forks? Greg, what do you think? Others? Apache/Sonatype/Codehaus developers: It appears that there was once a push for Apache to adopt maven-nar-plugin as a core plugin. Is that effort abandoned now? Is a unified GitHub project the best way forward for maven-nar-plugin? Or would it make more sense for one of the big Maven umbrella groups to adopt it instead? Thanks, Curtis On Fri, Sep 14, 2012 at 10:34 AM, Martin Eisengardt martin.eisenga...@gmail.com wrote: The author (@duns) seems to be not actve any more. However I failed contacting him for a while. https://github.com/GregDomjan/maven-nar-plugin And there is a second one being active: https://github.com/richardkerr/maven-nar-plugin (do not know how to contact this guy) However both try to merge the forks being around. And they like any kind of help. If there are some people around that want to give it a new try that would be nice. I guess the original plugin was some kind of sandbox @ sonatype. I do not know if we should simply group up some people that officially will maintain it and I do not know if even sonatype or others are interested. However for being pragmatic I would say to choose one of the active forks, grouping a new team and granting commit rights to the people that want to maintain it. I am able to provide both, a repository and a hudson as long as this is not moved to maven central. However I am personally focused on compiling php/php-extensions and using maven-nar-plugin to access them with maven. Multi-Platform compiles/ Cross-Platform compiles I will come back to the project as soon as our build server knows how to do cross compiles for various platforms. On Fri, Sep 14, 2012 at 5:09 PM, Curtis Rueden ctrue...@wisc.edu wrote: Hi Martin, There is a problem with the [maven-nar-plugin] project because there are tens of orks on github. If you have any questions about it please ask. I have contact to one of the ative authors and we try to merge all the forks. I am guilty of one of those forks. We submitted a PR ( https://github.com/duns/maven-nar-plugin/pull/5) but never heard back, so we had no choice. It looks like the canonical version at duns/maven-nar-plugin has not been updated for nearly two years. Is that going to change? It would be great for this very valuable plugin to be maintained! Thanks, Curtis
Re: Unifying maven-nar-plugin implementations
Hi. However the first topic is to group a team that will be well active and that will be adoting all forks. I suggest to choose one github project and declare it to be the new main project. One fork by one should be merged and than deleted. Maybe we should choose richards or gregs project (that one that is the most recent) and create a wiki. Within the wiki we should dicuss some things because we all have experiences and want to customize maven-nar-plugin. Deploying to maven central or even becoming a core plugin could be the second topic after having an established project group. Let us say we have to do some homework. :) Greg, Richard? Fine for you to choose one of your forks being the official one? So I suggest to sum up the topics for our homeworks. However I do not know the current merge status. But I would like to work on the following three topics: 1) multiple compiles on one invocation (f.e. win-32 plus win-64) 2) cross compilation with gcc 3) adding new platforms after already having a release. Greetings On Fri, Oct 5, 2012 at 6:09 PM, Curtis Rueden ctrue...@wisc.edu wrote: Greetings maven-nar-plugin hackers! I am writing to gauge interest in a unified implementation of maven-nar-plugin. It seems there are several active (and not-so-active) forks. It seems the original implementation (@duns) is no longer active, but both @GregDomjan and @richardkerr have active forks (the latter forked from the former), and merge improvements from other forks too. Before we were aware of this, my colleague (Johannes Schindelin) I started another fork (@scijava) to address some issues we had. which have since been merged into the @GregDomjan fork (although I could not find a cherry-picked commit... it must have been done in some non-standard way?). I would be happy to deprecate the @scijava fork in favor of the @GregDomjan code, if we can agree to standardize on one officially maintained repository. If we do go that route, it should not be too difficult to start releasing versions to Maven Central. Can all agree to start submitting PRs to Greg for any future patches, rather than silently maintaining our own forks? Greg, what do you think? Others? Apache/Sonatype/Codehaus developers: It appears that there was once a push for Apache to adopt maven-nar-plugin as a core plugin. Is that effort abandoned now? Is a unified GitHub project the best way forward for maven-nar-plugin? Or would it make more sense for one of the big Maven umbrella groups to adopt it instead? Thanks, Curtis On Fri, Sep 14, 2012 at 10:34 AM, Martin Eisengardt martin.eisenga...@gmail.com wrote: The author (@duns) seems to be not actve any more. However I failed contacting him for a while. https://github.com/GregDomjan/maven-nar-plugin And there is a second one being active: https://github.com/richardkerr/maven-nar-plugin (do not know how to contact this guy) However both try to merge the forks being around. And they like any kind of help. If there are some people around that want to give it a new try that would be nice. I guess the original plugin was some kind of sandbox @ sonatype. I do not know if we should simply group up some people that officially will maintain it and I do not know if even sonatype or others are interested. However for being pragmatic I would say to choose one of the active forks, grouping a new team and granting commit rights to the people that want to maintain it. I am able to provide both, a repository and a hudson as long as this is not moved to maven central. However I am personally focused on compiling php/php-extensions and using maven-nar-plugin to access them with maven. Multi-Platform compiles/ Cross-Platform compiles I will come back to the project as soon as our build server knows how to do cross compiles for various platforms. On Fri, Sep 14, 2012 at 5:09 PM, Curtis Rueden ctrue...@wisc.edu wrote: Hi Martin, There is a problem with the [maven-nar-plugin] project because there are tens of orks on github. If you have any questions about it please ask. I have contact to one of the ative authors and we try to merge all the forks. I am guilty of one of those forks. We submitted a PR ( https://github.com/duns/maven-nar-plugin/pull/5) but never heard back, so we had no choice. It looks like the canonical version at duns/maven-nar-plugin has not been updated for nearly two years. Is that going to change? It would be great for this very valuable plugin to be maintained! Thanks, Curtis
[ANN] SiteSkinner Maven Plugin 1.0 Released
Hi, The Mojo team is pleased to announce the release of the SiteSkinner Maven Plugin version 1.0. The siteskinner-maven-plugin can update or apply a new skin on published sites generated by Maven without changing its content. http://mojo.codehaus.org/siteskinner-maven-plugin/ To use this update, simply execute the following command in the root of your project: mvn siteskinner:skin or mvn org.codehaus.mojo:siteskinner-maven-plugin:1.0:skin For all the details read http://mojo.codehaus.org/siteskinner-maven-plugin/usage.html Release Notes - Mojo's SiteSkinner Maven Plugin - Version 1.0 Bug [MSITESKIN-2] - Siteskinner includes inherited elements, which can cause duplicate breadcrumbs [MSITESKIN-9] - No skin defined in the current 'site.xml', can't apply a new skin on the old site error with staged 1.0 Improvement [MSITESKIN-6] - use maven-plugin-tools' java 5 annotations [MSITESKIN-8] - Make integration tests [MSITESKIN-10] - Clarify how you can push the original publish date Enjoy, The Mojo team. Robert Scholte
noob confusion about dependencies and repositories
Hey y’all, I am trying to link one project’s jar to another project. I am totally confused and hope someone can take some time to explain. I have been reading the following pages on the site: http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html http://maven.apache.org/guides/getting-started/index.html#How_do_I_create_a_JAR_and_install_it_in_my_local_repository http://maven.apache.org/guides/introduction/introduction-to-repositories.html I have the following tools: a.. eclipse b.. maven c.. git d.. jenkins e.. findbugs f.. pmd my two projects are murmur-events and the other is murmur. Murmur has a dependency to murmur-events. My murmur-events pom has pmd and findbugs and failures in the mojo s preventing installation of the jar. Here is the dependency in the murmur pom: dependency groupIdmurmur-events/groupId artifactIdmurmur-events/artifactId scoperuntime/scope version1.0.1-SNAPSHOT/version /dependency Here are my questions, I suppose: 1.. How can I install murmur-events, even though pmd/findbugs is issuing warnings? The mvn install is failing. 2.. Where is the local repository where these get installed? 3.. Do I need to have a parent pom with two modules, one for each project? Does this impact where my local repository is? 4.. Should I specify the murmur-events-1.0.1-SNAPSHOT.jar, as a dependency in the murmur project, by system file path? 5.. If the jar is named ‘murmur-events-1.0.1-SNAPSHOT.jar’, will the above dependency of the following find it? 6.. What about setting up an internal repository? Would that be a better solution? 7.. If I have the dependency in maven, will eclipse pick it up? Many thanks, Rob
