Re: [maven-eclipse-plugin] and .aj AspectJ files.
Hi, I've not used aspectj so I'm just guessing what you are trying to do. Can you explain why you want non-java files on the classpath? I haven't used AspectJ for myself, but AFAIK .aj files are the sources for AspectJ. They must be included in the classpath so that the AspectJ compiler can compile them. Does the aspectj builder work with these files and need the *.aj on the classpath to work. Yes. Regards Thorsten PGP.sig Description: Signierter Teil der Nachricht
how to ship all license.txt files
Hi, when we ship our product, we have to ship also all used 3rdParty licenses. Is there a way to detect the license.txt files automatically? Extract those files from all dependencies, for example? Or do I have to enumerate all licenses in my pom.xml licenses license name/name url./url /license /licenses These plugins are NOT what I´m looking for: 1) http://code.google.com/p/maven-license-plugin/ 2) http://mojo.codehaus.org/rat-maven-plugin/ thanx for any advice, Torsten
Soft dependency versions combined with repeatable builds
I've tried hard to archive reproducable builds combined with soft versions in maven. But I now believe it is not possible. Here is what I want: I've got a project A and many Projects depending on it. All Project shalls be build by a CI Tool. A Build of A will trigger a build of all the other projects and those should pick up the changes from A. Each of this build should be reproducable. That is, each artifact produced should carry a unique version and for each build I've to be able to tell which artifacts have been used. I've searched Mailinglists and google and I'm surprised few people have the some problem. However there are some Documents with related Issues: Laurent Perez describes the same problem but wihtout ci a few weeks ago at this list: http://www.mail-archive.com/users@maven.apache.org/msg95719.html Looks like Dan Fabulich had related problem back in 2006, unfortunately there are no new updates. http://darkforge.blogspot.com/2006/12/compass-as-compared-with-mavens.html http://docs.codehaus.org/display/MAVENUSER/BEA+Maven+Requirement+Documents There is a ticket for the release plugin asking for dynamic version replacement: http://jira.codehaus.org/browse/MRELEASE-399 I've already posted to this list asking for dynamic version replacement: http://www.nabble.com/Replace-Dynamic-Revisions-during-td22331577.html#a22346378 I've tried the solution from this post: - Change the preparationGoals of the relase plugin to be versions:update-properties invoker:run and configure the invoker plugin to run clean verify Problems: This does span a new maven instance and thus fails for multimodule builds with dependencies among the childs. (The release plugin does some magic to allow dependencies between childs, this magic seems to fail in the new maven instance) Another (partial) solution: - have a global parent pom that list the current version of all modules in the depMang. section. This just moves to problem of missing soft versions to the parent section: The Projects would need to update there parent section after each build. [0,) or RELEASE dont's work in the parent section. Maven leaks a robust mechanism for soft (or dynamic) revisions that get replaced during release with concrete Versions. Any Ideas are welcome. Best regards, Martin
Providing multiply source directories ..
Hi Folks ..
This one is supposed to be an easy one .
build
defaultGoalinstall/defaultGoal
directorytarget/directory
outputDirectorytarget/classes/outputDirectory
finalName${project.artifactId}-${project.version}
/finalName
testOutputDirectorytarget/test-classes
/testOutputDirectory
sourceDirectorysrc/main/java/sourceDirectory
scriptSourceDirectorysrc/main/scripts
/scriptSourceDirectory
testSourceDirectorysrc/test/java/testSourceDirectory
/build
Any idea how do i provide multiply source folders ?
I have some code also under src/main/java-gen ...
Thanks in advance.
Roman
Re: Providing multiply source directories ..
The easy answer is the maven-helper-plugin: http://mojo.codehaus.org/build-helper-maven-plugin/add-source-mojo.html. src/main/java-gen probably means that your sources are generated by someone. If this someone is a Maven plugin, then it probably does the job of adding the source directory to your POM (which may not be what you want, but that is not point now). If you generate the sources using the AntRun plugin, you can add *one* extra source directory. And if you care (this is a convention): generated sources are placed under target/generated-sources, and never under src. __ Diese E-Mail kann vertrauliche und geschuetzte Informationen enthalten. Wenn diese E-Mail nicht für Sie bestimmt ist, bitten wir Sie, uns unverzueglich zu informieren und sie zu loeschen. This e-mail message may contain information, which is confidential and protected. If you are not the intended recipient of this message, we ask you to inform us immediately and delete the message afterwards. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Providing multiply source directories ..
Thanks for the fast answer I do care about it and i want to do it the standart way. The sources i generate are created by my maven plugin, and i need them to be generated before compiling the project itself, since i refer to them from my code. I would like also to see the gen sources in eclipse , so i have just added the src/main/java-gen to the sources folders in eclipse. i think if i will put them in to target/genereated-sources eclipse will get nuts and wont recognize that i have them att all. Any idea how to do this the best way ? Thanks On Wed, Mar 25, 2009 at 11:41 AM, clovis.seragio...@raibau.at wrote: The easy answer is the maven-helper-plugin: http://mojo.codehaus.org/build-helper-maven-plugin/add-source-mojo.html. src/main/java-gen probably means that your sources are generated by someone. If this someone is a Maven plugin, then it probably does the job of adding the source directory to your POM (which may not be what you want, but that is not point now). If you generate the sources using the AntRun plugin, you can add *one* extra source directory. And if you care (this is a convention): generated sources are placed under target/generated-sources, and never under src. __ Diese E-Mail kann vertrauliche und geschuetzte Informationen enthalten. Wenn diese E-Mail nicht für Sie bestimmt ist, bitten wir Sie, uns unverzueglich zu informieren und sie zu loeschen. This e-mail message may contain information, which is confidential and protected. If you are not the intended recipient of this message, we ask you to inform us immediately and delete the message afterwards. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Providing multiply source directories ..
If your Maven plugin generate source files in a new folder then it is the responsability of your Maven plugin to add this directories into the list of source directories once the source have been generated (through the project object that may be injected to your plugin by Maven). Jeff MAURY On Wed, Mar 25, 2009 at 10:49 AM, Roman Kournjaev kournj...@gmail.comwrote: Thanks for the fast answer I do care about it and i want to do it the standart way. The sources i generate are created by my maven plugin, and i need them to be generated before compiling the project itself, since i refer to them from my code. I would like also to see the gen sources in eclipse , so i have just added the src/main/java-gen to the sources folders in eclipse. i think if i will put them in to target/genereated-sources eclipse will get nuts and wont recognize that i have them att all. Any idea how to do this the best way ? Thanks On Wed, Mar 25, 2009 at 11:41 AM, clovis.seragio...@raibau.at wrote: The easy answer is the maven-helper-plugin: http://mojo.codehaus.org/build-helper-maven-plugin/add-source-mojo.html. src/main/java-gen probably means that your sources are generated by someone. If this someone is a Maven plugin, then it probably does the job of adding the source directory to your POM (which may not be what you want, but that is not point now). If you generate the sources using the AntRun plugin, you can add *one* extra source directory. And if you care (this is a convention): generated sources are placed under target/generated-sources, and never under src. __ Diese E-Mail kann vertrauliche und geschuetzte Informationen enthalten. Wenn diese E-Mail nicht für Sie bestimmt ist, bitten wir Sie, uns unverzueglich zu informieren und sie zu loeschen. This e-mail message may contain information, which is confidential and protected. If you are not the intended recipient of this message, we ask you to inform us immediately and delete the message afterwards. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- La mélancolie c’est communiste Tout le monde y a droit de temps en temps La mélancolie n’est pas capitaliste C’est même gratuit pour les perdants La mélancolie c’est pacifiste On ne lui rentre jamais dedans La mélancolie oh tu sais ça existe Elle se prend même avec des gants La mélancolie c’est pour les syndicalistes Il faut juste sa carte de permanent Miossec (2006) http://www.jeffmaury.com http://riadiscuss.jeffmaury.com http://www.lastfm.fr/listen/user/jeffmaury/personal
Re: Re: Providing multiply source directories ..
Eclipse doesn't care about target/generated-sources being a source folder (as long as it is not also the output folder, but the output folder is usually target/classes). If, when you say that the sources ... are created by my maven plugin, you mean that you wrote the maven plugin yourself, then your change your maven plugin so that it adds as many extra source directories as you want. And finally: mvn eclipse:eclipse can generate the eclipse project files for you, and it will include all source directories added/injected up to the phase generate-sources. __ Diese E-Mail kann vertrauliche und geschuetzte Informationen enthalten. Wenn diese E-Mail nicht für Sie bestimmt ist, bitten wir Sie, uns unverzueglich zu informieren und sie zu loeschen. This e-mail message may contain information, which is confidential and protected. If you are not the intended recipient of this message, we ask you to inform us immediately and delete the message afterwards. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Davs or Webdavs wagon support?
Hi, I successfully used davs:// with Maven 2.1.0. Thanks a lot. Mickael Dan Tran a écrit : i think you need maven 2.1.0 -D On Tue, Mar 24, 2009 at 9:46 AM, Mickael Istria mickael.ist...@openwide.fr wrote: Hi all, I'm trying to use a davs:// address as a repository to deploy artifacts. I've tried using wagon-webdav, and wagon-webdav-jackrabbit. * All those ones (except webdav-jackrabbit 1.0-beta-5) tell me that davs:// is not supported. * webdav-jackrabbit 1.0-beta-5, it crashes with an exception, This commit (http://svn.apache.org/viewvc?view=revrevision=662092) tells that davs:// is supported. Is this support available somewhere? (on a snapshot or incubation repository that is stable enough to be used?) Thanks in advance. Mickael - 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
RE: Show maven plug-in configuration options?
Very nice! Thanks! -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: Tuesday, March 24, 2009 3:13 PM To: Maven Users List Subject: RE: Show maven plug-in configuration options? Lookup mvn help:describe on the maven-help-plugin page, that will get you the info that normally shows on a plugin's website. -Original Message- From: Will Hoover [mailto:java.whoo...@gmail.com] Sent: Tuesday, March 24, 2009 2:50 PM To: 'Maven Users List' Subject: Show maven plug-in configuration options? Does anyone know of a way to show a maven plugin configuration options from the mvn command? - 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
RE: Show maven plug-in configuration options?
Worked very nicely... Thanks! -Original Message- From: Dennis Lundberg [mailto:denn...@apache.org] Sent: Tuesday, March 24, 2009 3:31 PM To: Maven Users List Subject: Re: Show maven plug-in configuration options? You can use the Help Plugin for this. Here's an example for the WAR plugin: mvn help:describe -Dplugin=war Or this one if you want *all* the info: mvn help:describe -Dplugin=war -Dfull=true Will Hoover wrote: Does anyone know of a way to show a maven plugin configuration options from the mvn command? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Dennis Lundberg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] Maven 2.1.0 Released
Do jar-packaged projects now execute the new prepare-package phase? Have just tried the new version out, hoping that my project with jar packaging would execute the new phase, to which one of my plug-in goals declares itself as being bound, but it appears not to. Thanks, 2009/3/22 John Casey jdca...@apache.org The Maven team is pleased to announce the release of Maven 2.1.0. Maven is a software project management and comprehension tool. Based on the concept of a project object model (POM), Maven can manage a project's build, reporting and documentation from a central piece of information. You can download the new version at: http://maven.apache.org/download.html You can find release notes for this version below, or at: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500styleName=Htmlversion=14587 Enjoy, -The Maven team -- Rob, Lafros.com
Re: [ANN] Maven 2.1.0 Released
On 25/03/2009, at 10:07 PM, Rob Dickens wrote: Do jar-packaged projects now execute the new prepare-package phase? Have just tried the new version out, hoping that my project with jar packaging would execute the new phase, to which one of my plug-in goals declares itself as being bound, but it appears not to. All packaging types will if you properly bind to the phase, but there is no default binding in any of the mojos yet. How have you constructed your execution block? Cheers, Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] Maven 2.1.0 Released
As in a pluginspluginexecutionsexecution block in the pom.xml of the jar-packaged project? There isn't one, since the plugin's mojo has a '@phase prepare-package'. 2009/3/25 Brett Porter br...@apache.org On 25/03/2009, at 10:07 PM, Rob Dickens wrote: Do jar-packaged projects now execute the new prepare-package phase? Have just tried the new version out, hoping that my project with jar packaging would execute the new phase, to which one of my plug-in goals declares itself as being bound, but it appears not to. All packaging types will if you properly bind to the phase, but there is no default binding in any of the mojos yet. How have you constructed your execution block? Cheers, Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Transitive behavior fo types
Hi, is there any possibility to change the transitive behavior of some types? I'd like to stop artifacts of type zip to provide their transitive deps. For me they should behave like e.g. an artifact of type ear. I've searched through the different plexus/*.xml files contained in the Maven uber jar, but I could not find any declaration for ZIPs. Are they using some general default? Is it possible to change the behavior e.g. by declaring an extension with a component.xml that declares the includesDependencies for zip artifacts? - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
tricky cyclic dependency issue
hi, I have the following setup: ProjectX-API: pure abstract layer (depends on TestCommon at test scope) ProjectX-Core: main implementations (depends on API and also on TestCommon at test scope) ProjectX-TestCommon: offers common testing facilities to all ProjectX sub-modules, but also to clients of ProjectX and it also acts as single entry point for all test-scoped dependencies e.g. JUnit 4.x Now the problem is that while I need TestCommon for implementing the test suites in API and Core modules, TestCommon needs to depend on API and eventually on the Core module too. e.g. ProjectX-TestCommon defines a reusable AbstractTestSingleton to test Singleton types. ProjectX-API defines the ISingleton abstraction and also defines some concrete Singleton instances. AbstractTestSingleton that resides in ProjectX-TestCommon needs to depend on ProjectX-API and JUnit 4.x at the same time. Possibilities: - Moving AbstractTestSingleton to ProjectX-API is not possible because ProjectX-API should not depend on anything else, especially not on JUnit 4.x that AbstractTestSingleton requires (it extends TestCase) - Having module ProjectX-TestCommon depend on ProjectX-API does not work because ProjectX-API already depends on ProjectX-TestCommon (to test the concrete Singletons and more) and Maven reports a cyclic dependency. I tried many alternatives e.g. exclusion (excluding ProjectX-API when ProjectX-API declares dependency on ProjectX-TestCommon), changing scope to provided, etc. Any other ideas how to resolve this? TIA, Best regards, Giovanni -- View this message in context: http://www.nabble.com/tricky-cyclic-dependency-issue-tp22700195p22700195.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
tricky cyclic dependency issue ...
hi, I have the following setup: ProjectX-API: pure abstract layer (depends on TestCommon at test scope) ProjectX-Core: main implementations (depends on API and also on TestCommon at test scope) ProjectX-TestCommon: offers common testing facilities to all ProjectX sub-modules, but also to clients of ProjectX and it also acts as single entry point for all test-scoped dependencies e.g. JUnit 4.x Now the problem is that while I need TestCommon for implementing the test suites in API and Core modules, TestCommon needs to depend on API and eventually on the Core module too. e.g. ProjectX-TestCommon defines a reusable AbstractTestSingleton to test Singleton types. ProjectX-API defines the ISingleton abstraction and also defines some concrete Singleton instances. AbstractTestSingleton that resides in ProjectX-TestCommon needs to depend on ProjectX-API and JUnit 4.x at the same time. Possibilities: - Moving AbstractTestSingleton to ProjectX-API is not possible because ProjectX-API should not depend on anything else, especially not on JUnit 4.x that AbstractTestSingleton requires (it extends TestCase) - Having module ProjectX-TestCommon depend on ProjectX-API does not work because ProjectX-API already depends on ProjectX-TestCommon (to test the concrete Singletons and more) and Maven reports a cyclic dependency. I tried many alternatives e.g. exclusion (excluding ProjectX-API when ProjectX-API declares dependency on ProjectX-TestCommon), changing scope to provided, etc. Any other ideas how to resolve this? TIA, Best regards, Giovanni - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: tricky cyclic dependency issue ...
Move the concrete impls of your API interfaces into a seperate module. The only solution to cyclical dependencies is not to have them. Justin On Mar 25, 2009, at 8:21 AM, Giovanni Azua brave...@hotmail.com wrote: hi, I have the following setup: ProjectX-API: pure abstract layer (depends on TestCommon at test scope) ProjectX-Core: main implementations (depends on API and also on TestCommon at test scope) ProjectX-TestCommon: offers common testing facilities to all ProjectX sub-modules, but also to clients of ProjectX and it also acts as single entry point for all test-scoped dependencies e.g. JUnit 4.x Now the problem is that while I need TestCommon for implementing the test suites in API and Core modules, TestCommon needs to depend on API and eventually on the Core module too. e.g. ProjectX-TestCommon defines a reusable AbstractTestSingleton to test Singleton types. ProjectX-API defines the ISingleton abstraction and also defines some concrete Singleton instances. AbstractTestSingleton that resides in ProjectX-TestCommon needs to depend on ProjectX-API and JUnit 4.x at the same time. Possibilities: - Moving AbstractTestSingleton to ProjectX-API is not possible because ProjectX-API should not depend on anything else, especially not on JUnit 4.x that AbstractTestSingleton requires (it extends TestCase) - Having module ProjectX-TestCommon depend on ProjectX-API does not work because ProjectX-API already depends on ProjectX-TestCommon (to test the concrete Singletons and more) and Maven reports a cyclic dependency. I tried many alternatives e.g. exclusion (excluding ProjectX-API when ProjectX-API declares dependency on ProjectX- TestCommon), changing scope to provided, etc. Any other ideas how to resolve this? TIA, Best regards, Giovanni - 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
tricky cyclic dependency issue ...
hi, I have the following setup: ProjectX-API: pure abstract layer (depends on TestCommon) ProjectX-Core: main implementations (depends on API and transitively on TestCommon) ProjectX-TestCommon: offers common testing facilities to all ProjectX sub-modules, but also to clients of ProjectX and it also acts as single entry point for all test-scoped dependencies e.g. JUnit 4.x Now the problem is that while I need TestCommon for implementing the test suites in API and Core modules, TestCommon needs to depend on API and eventually on the Core module too. e.g. ProjectX-TestCommon defines a reusable AbstractTestSingleton to test Singleton types. ProjectX-API defines the ISingleton abstraction and also defines some concrete Singleton instances. AbstractTestSingleton that resides in ProjectX-TestCommon needs to depend on ProjectX-API and JUnit 4.x at the same time. Possibilities: - Moving AbstractTestSingleton to ProjectX-API is not possible because ProjectX-API should not depend on anything else, especially not on JUnit 4.x that AbstractTestSingleton requires (it extends TestCase) - Having module ProjectX-TestCommon depend on ProjectX-API does not work because ProjectX-API already depends on ProjectX-TestCommon (to test the concrete Singletons and more) and Maven reports a cyclic dependency. I tried many alternatives e.g. exclusion (excluding ProjectX-API when ProjectX-API declares dependency on ProjectX-TestCommon), changing scope to provided, etc. Any other ideas how to resolve this? TIA, Best regards, Giovanni - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
tricky cyclic dependency issue ...
hi, I have the following setup: ProjectX-API: pure abstract layer (depends on TestCommon at test scope) ProjectX-Core: main implementations (depends on API and also on TestCommon at test scope) ProjectX-TestCommon: offers common testing facilities to all ProjectX sub-modules, but also to clients of ProjectX and it also acts as single entry point for all test-scoped dependencies e.g. JUnit 4.x Now the problem is that while I need TestCommon for implementing the test suites in API and Core modules, TestCommon needs to depend on API and eventually on the Core module too. e.g. ProjectX-TestCommon defines a reusable AbstractTestSingleton to test Singleton types. ProjectX-API defines the ISingleton abstraction and also defines some concrete Singleton instances. AbstractTestSingleton that resides in ProjectX-TestCommon needs to depend on ProjectX-API and JUnit 4.x at the same time. Possibilities: - Moving AbstractTestSingleton to ProjectX-API is not possible because ProjectX-API should not depend on anything else, especially not on JUnit 4.x that AbstractTestSingleton requires (it extends TestCase) - Having module ProjectX-TestCommon depend on ProjectX-API does not work because ProjectX-API already depends on ProjectX-TestCommon (to test the concrete Singletons and more) and Maven reports a cyclic dependency. I tried many alternatives e.g. exclusion (excluding ProjectX-API when ProjectX-API declares dependency on ProjectX-TestCommon), changing scope to provided, etc. Any other ideas how to resolve this? TIA, Best regards, Giovanni - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
profiles activation - how does it work ?
Hello, I have switched into Maven 2.1.0 hoping that it will be possible to use AND operator for defined activation criteria - it seems that it is still OR am I right ? Anyway I made some tests and with the configuration: activation os familiywindows/family /os property namebuild/name valueclient/value /property /activation Regarless of how build property is set, profile is activated on windows machine. Ok, it is decided to use OR - is it some workaround to use AND ? Another question: Is it possible to use more than one property in activation section? Thank you in advance! Tomasz -- View this message in context: http://www.nabble.com/profiles-activation---how-does-it-work---tp22701927p22701927.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
Find updates to versioned dependencies and plugins
Hi, this might be a silly question but I did a lot of googling and failed to find the answer: How can I get a list of all outdated dependencies of my project, that is, dependencies and plugins for which there are newer versions in remote repositories than specified in my pom.xml ? Thanks. PS. Please CC me when responding as I'm not subscribed. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Test built jar
Hi All, I trying to have some IT tests (or look-like) on my jar file only. I was thinking that the phase verify will give me that chance but not. Here is my problem. I have a jar where some directory has to be parsed on a file pattern = I use the JarFile class, then parse it to retrieve what I need (some XML files). This code must be tested (a lot !) but I can figure out how to have my tests' classpath running on the generated test and not on target/classses. (a maven -X shows me that target/classes are used while my It test are executed using the surfire conf in the verify phase) Ideas someone ? Thanks a lot. ap - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Find updates to versioned dependencies and plugins
Google for the versions-maven-plugin -Original Message- From: Marcin Wiśnicki [mailto:mwisni...@gmail.com] Sent: Wednesday, March 25, 2009 9:27 AM To: users@maven.apache.org Subject: Find updates to versioned dependencies and plugins Hi, this might be a silly question but I did a lot of googling and failed to find the answer: How can I get a list of all outdated dependencies of my project, that is, dependencies and plugins for which there are newer versions in remote repositories than specified in my pom.xml ? Thanks. PS. Please CC me when responding as I'm not subscribed. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
XHTML to PDF with doxia-maven-plugin, ignore some tags
I've got a xhtml with an anchor before a section : ..l txt1 div class=section.. /div How indicate to doxia plugin to ignore this anchor ? I don't want that it appears in the generated pdf. Thanks ! -- View this message in context: http://www.nabble.com/XHTML-to-PDF-with-doxia-maven-plugin%2C-ignore-some-tags-tp22702451p22702451.html Sent from the Doxia - Users mailing list archive at Nabble.com.
setting surefire reports directory
Hallo, we are using maven-projects and use luntbuild for continuous integration. So, we want to set the Surefire report directory while calling maven. While reading the documentation I expected that calling maven via mvn -DreportsDirectory=/our/report/dir test would do the job. But unfortunately, the argument -DreportsDirectory=/our/report/dir seems to have no impact at all, i.e. the reports are still placed inside I have tried a couple of things but found no solution. Can anybody help me? How can I configure the destination directory of surefire? What I really want is the following possibility: Calling mvn without any special arguments, the surefire-reports should be placed in the standard directory. But it should be possible to set the surefire report directory by using any argument while calling maven. Yours, Norbert Sensen
Re: XHTML to PDF with doxia-maven-plugin, ignore some tags
Not sure I understand but if you don't want an anchor, why not just remove it? Anyway, you can't tell a parser to ignore one tag and not the other. HTH, -Lukas niamande wrote: I've got a xhtml with an anchor before a section : ..l txt1 div class=section.. /div How indicate to doxia plugin to ignore this anchor ? I don't want that it appears in the generated pdf. Thanks !
Re: setting surefire reports directory
Luntbuild sets the system property artifactsDir which you can use. Add
the following property to your pom:
artifactsDir${project.build.directory}/artifactsDir
Add the following to your surefire plugin configuration:
reportsDirectory${artifactsDir}/surefire-reports/reportsDirectory
For a multi-module project you could do:
reportsDirectory${artifactsDir}/surefire-reports/${artifactId}/reportsDirectory
Luntbuild overrides the property in your pom, so that the reports end up
in the right place.
Reinhard
Norbert Sensen schrieb:
Hallo,
we are using maven-projects and use luntbuild for continuous integration.
So, we want to set the Surefire report directory while calling maven.
While reading the documentation I expected that calling maven via
mvn -DreportsDirectory=/our/report/dir test
would do the job.
But unfortunately, the argument -DreportsDirectory=/our/report/dir seems
to have no impact at all,
i.e. the reports are still placed inside
I have tried a couple of things but found no solution.
Can anybody help me? How can I configure the destination directory of
surefire?
What I really want is the following possibility:
Calling mvn without any special arguments, the surefire-reports should be
placed in the standard directory.
But it should be possible to set the surefire report directory by using any
argument while calling maven.
Yours,
Norbert Sensen
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Davs or Webdavs wagon support?
2.0.10 may have fixed it as well On Wed, Mar 25, 2009 at 3:22 AM, Mickael Istria mickael.ist...@openwide.fr wrote: Hi, I successfully used davs:// with Maven 2.1.0. Thanks a lot. Mickael Dan Tran a écrit : i think you need maven 2.1.0 -D On Tue, Mar 24, 2009 at 9:46 AM, Mickael Istria mickael.ist...@openwide.fr wrote: Hi all, I'm trying to use a davs:// address as a repository to deploy artifacts. I've tried using wagon-webdav, and wagon-webdav-jackrabbit. * All those ones (except webdav-jackrabbit 1.0-beta-5) tell me that davs:// is not supported. * webdav-jackrabbit 1.0-beta-5, it crashes with an exception, This commit (http://svn.apache.org/viewvc?view=revrevision=662092) tells that davs:// is supported. Is this support available somewhere? (on a snapshot or incubation repository that is stable enough to be used?) Thanks in advance. Mickael - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Davs or Webdavs wagon support?
No, wagon was not upgraded in 2.0.10 in the end. - Brett On 26/03/2009, at 2:04 AM, Dan Tran wrote: 2.0.10 may have fixed it as well On Wed, Mar 25, 2009 at 3:22 AM, Mickael Istria mickael.ist...@openwide.fr wrote: Hi, I successfully used davs:// with Maven 2.1.0. Thanks a lot. Mickael Dan Tran a écrit : i think you need maven 2.1.0 -D On Tue, Mar 24, 2009 at 9:46 AM, Mickael Istria mickael.ist...@openwide.fr wrote: Hi all, I'm trying to use a davs:// address as a repository to deploy artifacts. I've tried using wagon-webdav, and wagon-webdav-jackrabbit. * All those ones (except webdav-jackrabbit 1.0-beta-5) tell me that davs:// is not supported. * webdav-jackrabbit 1.0-beta-5, it crashes with an exception, This commit (http://svn.apache.org/viewvc? view=revrevision=662092) tells that davs:// is supported. Is this support available somewhere? (on a snapshot or incubation repository that is stable enough to be used?) Thanks in advance. Mickael - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] Maven 2.1.0 Released
Okay, my mistake - although it was indeed the 2.1.0 mvn which was in my path, I had forgotten to change the value of my M2_HOME environment variable. Therefore, it was actually 2.0.10 which was being executed, which was why my goal was being ignored. And anyway, I had wrongly assumed that adding the '@phase prepare-package' annotation to the mojo was enough to trigger the goal's execution - you still have to add a pluginexecutions...goal to the pom, and I can confirm that this works fine. Many thanks to Brett for asistance. Rob 2009/3/25 Rob Dickens arctic@googlemail.com As in a pluginspluginexecutionsexecution block in the pom.xml of the jar-packaged project? There isn't one, since the plugin's mojo has a '@phase prepare-package'. 2009/3/25 Brett Porter br...@apache.org On 25/03/2009, at 10:07 PM, Rob Dickens wrote: Do jar-packaged projects now execute the new prepare-package phase? Have just tried the new version out, hoping that my project with jar packaging would execute the new phase, to which one of my plug-in goals declares itself as being bound, but it appears not to. All packaging types will if you properly bind to the phase, but there is no default binding in any of the mojos yet. How have you constructed your execution block? Cheers, Brett -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Find updates to versioned dependencies and plugins
FYI, working on getting ready for th 1.0-alpha-3 which fixes a lot of issues but it looks like it will be second week in april before it's ready 2009/3/25 Brian E. Fox bri...@reply.infinity.nu Google for the versions-maven-plugin -Original Message- From: Marcin Wiśnicki [mailto:mwisni...@gmail.com] Sent: Wednesday, March 25, 2009 9:27 AM To: users@maven.apache.org Subject: Find updates to versioned dependencies and plugins Hi, this might be a silly question but I did a lot of googling and failed to find the answer: How can I get a list of all outdated dependencies of my project, that is, dependencies and plugins for which there are newer versions in remote repositories than specified in my pom.xml ? Thanks. PS. Please CC me when responding as I'm not subscribed. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
archetype:generate gives Desired archetype does not exist
Using Maven 2.0.10, if I do: mvn -e archetype:generate then press Enter when it prompts me for a number, I get errors: [WARNING] repository metadata for: 'artifact org.apache.maven.archetypes:maven-archetype-quickstart' could not be retrieved from repository: central due to an error: Error transferring file [INFO] Repository 'central' will be blacklisted . . . org.apache.maven.BuildFailureException: The desired archetype does not exist (org.apache.maven.archetypes:maven-archetype-quickstart:RELEASE) at org .apache .maven .lifecycle .DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java: 580) at org .apache .maven .lifecycle .DefaultLifecycleExecutor .executeStandaloneGoal(DefaultLifecycleExecutor.java:513) at org .apache .maven .lifecycle .DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:483) at org .apache .maven .lifecycle .DefaultLifecycleExecutor .executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331) at org .apache .maven .lifecycle .DefaultLifecycleExecutor .executeTaskSegments(DefaultLifecycleExecutor.java:228) at org .apache .maven .lifecycle .DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:301) 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 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java: 430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoFailureException: The desired archetype does not exist (org.apache.maven.archetypes:maven-archetype- quickstart:RELEASE) at org .apache .maven .archetype .mojos .CreateProjectFromArchetypeMojo .execute(CreateProjectFromArchetypeMojo.java:201) at org .apache .maven .plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:453) at org .apache .maven .lifecycle .DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java: 559) ... 16 more Any suggestions? Thanks, Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Exclude resources during jar generation
Hello, I use Maven 2 to package my solution which contains several projects. I am in the project A which have dependencies with B and C projects. In my pom.Xml for A project that I wish package I have mentionned an assembly file which lets me to generate a global zip archive containing : - libs/ directory containing jar from B and C projects - libs/libsext directory containing externals jar that are in dependency - resources/ directory containing resources from A project which are containing in src/main/resources on this project When I generate jar from A project, I would like to exclude these resources (containing in src/main/resources) from my jar. For the moment, I haven't found a solution. There is a possibility to make that ? Thanks for your help. Sylvain -- View this message in context: http://www.nabble.com/Exclude-resources-during-jar-generation-tp22707492p22707492.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: setting surefire reports directory
Luntbuild overrides the property in your pom, so that the reports end up in the right place. I certainly hope this is documented somewhere in the Luntbuild site. And if it is, I have to ask Norbert why he didn't see it. ;-) If it is not, this is pretty clearly a failure in their docs. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Duplicate name in parent and current
Hi, I have a situation in which the dir names are same. Example: /base /base/modA /base/modA/modA I get the following error while trying to run mvn compile. The code for 2 POM's is below. What should I change in the parent to make this work ? Thanks, Reason: Parent element is a duplicate of the current project for project com.co.t3:modA [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Parent element is a duplicate of the current project for project com.co.t3:modA at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.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 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) /base/modA/pom.xml parent groupIdcom.co.t3/groupId artifactIdt3/artifactId version1.0-SNAPSHOT/version relativePath../base/pom.xml/relativePath /parent name modA /name groupIdcom.co.t3/groupId artifactIdmodA/artifactId packagingpom/packaging version1.0-SNAPSHOT/version /base/modA/modA/pom.xml parent groupIdcom.co.t3/groupId artifactIdmodA/artifactId version1.0-SNAPSHOT/version /parent groupIdcom.co.t3/groupId artifactIdmodA/artifactId packagingjar/packaging version1.0-SNAPSHOT/version -- View this message in context: http://www.nabble.com/Duplicate-name-in-parent-and-current-tp22707830p22707830.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
Possible problem when multiple developers depend on SNAPSHOT versions
Consider this scenario: Alice and Bob are working independently on two different applications, AppA and AppB. Both applications depend on an in-house shared library, Foo, that Alice and Bob are working on together. They have both checked out Foo's trunk and are regularly committing changes to it. Because Foo is undergoing heavy development, AppA and AppB depend on Foo 2.1-SNAPSHOT, but now Foo is looking pretty stable, and Alice's AppA needs some of the features scheduled for Foo 2.2, so she decides to perform a release of Foo 2.1 and does the usual release procedure: 1) Changes Foo's version from 2.1-SNAPSHOT to 2.1 and checks it into the trunk 2) Deploys Foo 2.1 to the company's internal repository 3) Tags the Foo trunk as the 2.1 release branch 4) Changes Foo's version from 2.1 to 2.2-SNAPSHOT and checks it into the trunk 5) Changes AppA's dependency to point to Foo 2.2-SNAPSHOT But what about Bob? He's still working with Foo 2.1-SNAPSHOT for his AppB. If he updates his working copy of Foo's source code, any changes he makes to Foo will be built as a 2.2-SNAPSHOT release, since Foo's trunk is now 2.2-SNAPSHOT. This is a major problem because his AppB has a dependency on 2.1-SNAPSHOT, so the next time he tests AppB, it will pick up the old Foo 2.1-SNAPSHOT, ignoring any changes Bob makes in Foo. He will probably waste a lot of time debugging, at least until he happens to notice that Foo's version has changed. What can be done to prevent Bob's problem? Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
JSP Precompile and WebSphere
I have a project where we need to precompile JSPs. I have followed the instructions here: http://mojo.codehaus.org/jspc-maven-plugin/usage.html We are servlet spec 2.4, JDK 1.5. Works great. Deploys and runs under my local Tomcat without problems. Under WebSphere however is where we encounter an issue. SRVE0206E: This error typically implies that the servlet was originally compiled with classes which cannot be located by the server. SRVE0187E: Check your classpath to ensure that all classes required by the servlet are present.SRVE0210I: This problem can be debugged by recompiling the servlet using only the classes in the application's runtime classpath SRVE0234I: Application classpath=[...]... Unfortunately, it doesn't tell me what file it is missing. Right now, I'm going down the route that the generated source is different than what would have been generated by WebSphere. I'm trying to get a generated JSP from our dev server from a prior deployment now to compare Generated from Maven2 project... public final class error_jsp extends org.apache.jasper.runtime.HttpJspBase implements org.apache.jasper.runtime.JspSourceDependent I'm suspecting I need to include a Jasper jar or somehow change what is generated during the build process. While I'm in limbo, just thought I would reach out and see if anyone else encountered this situation before. Thanks. The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
Re: archetype:generate gives Desired archetype does not exist
On Mar 25, 2009, at 1:34 PM, Trevor Harmon wrote: Using Maven 2.0.10, if I do: mvn -e archetype:generate then press Enter when it prompts me for a number, I get errors: Found the problem. I'm using a local installation of Nexus as a mirror of central, but the local installation was down. After removing the mirror entry in my settings.xml, the error went away. Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Possible problem when multiple developers depend on SNAPSHOT versions
the bane of all Projects is a tug-of-war on the codebase the solution is for bob to install version control such as cvs/perforce/SourceSafe which would allow merge of his and/or her codebase to trunk OR someone is assigned mainline of code and someone-else assigned a branch (this happens when core is heavily customised for a customer's needs where the user-specific mods will be integrated by merge-branch later on) BTW be careful to not allow (untested) deltas to overwrite 'blessed codebase' HTH! Martin __ Disclaimer and confidentiality note This message is confidential and may be privileged. If you are not the intended recipient, we kindly ask you to please inform the sender. Any unauthorised dissemination or copying hereof is prohibited. This message serves for information purposes only and shall not have any legally binding effect. Given that e-mails can easily be subject to manipulation, we can not accept any liability for the content provided. From: tre...@vocaro.com To: users@maven.apache.org Subject: Possible problem when multiple developers depend on SNAPSHOT versions Date: Wed, 25 Mar 2009 15:10:47 -0400 Consider this scenario: Alice and Bob are working independently on two different applications, AppA and AppB. Both applications depend on an in-house shared library, Foo, that Alice and Bob are working on together. They have both checked out Foo's trunk and are regularly committing changes to it. Because Foo is undergoing heavy development, AppA and AppB depend on Foo 2.1-SNAPSHOT, but now Foo is looking pretty stable, and Alice's AppA needs some of the features scheduled for Foo 2.2, so she decides to perform a release of Foo 2.1 and does the usual release procedure: 1) Changes Foo's version from 2.1-SNAPSHOT to 2.1 and checks it into the trunk 2) Deploys Foo 2.1 to the company's internal repository 3) Tags the Foo trunk as the 2.1 release branch 4) Changes Foo's version from 2.1 to 2.2-SNAPSHOT and checks it into the trunk 5) Changes AppA's dependency to point to Foo 2.2-SNAPSHOT But what about Bob? He's still working with Foo 2.1-SNAPSHOT for his AppB. If he updates his working copy of Foo's source code, any changes he makes to Foo will be built as a 2.2-SNAPSHOT release, since Foo's trunk is now 2.2-SNAPSHOT. This is a major problem because his AppB has a dependency on 2.1-SNAPSHOT, so the next time he tests AppB, it will pick up the old Foo 2.1-SNAPSHOT, ignoring any changes Bob makes in Foo. He will probably waste a lot of time debugging, at least until he happens to notice that Foo's version has changed. What can be done to prevent Bob's problem? Trevor - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org _ Hotmail® is up to 70% faster. Now good news travels really fast. http://windowslive.com/online/hotmail?ocid=TXT_TAGLM_WL_HM_70faster_032009
RE: Possible problem when multiple developers depend on SNAPSHOT versions
What can be done to prevent Bob's problem? This is more of an SCM/svn question so you may want to take the question there. Bob should work on a branch. IMHO if any work is taking a long time and you can't commit it to trunk in a timely manner, then do that work on a branch so you can commit often and still take specific control over when Alice's changes get merged to Bob's branch so he can test the merge thoroughly before putting his changes in trunk. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible problem when multiple developers depend on SNAPSHOT versions
On Wed, Mar 25, 2009 at 8:10 PM, Trevor Harmon tre...@vocaro.com wrote: What can be done to prevent Bob's problem? An easy solution is: When Alice prepares the release, she says Hey Bob, I'm doing a release of Foo. Henry - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Possible problem when multiple developers depend on SNAPSHOT versions
Hello All, I am using maven assembly and would like to add a dll to the classpath entry of the manifest file .How do I that using the maven assembly plugin .I see examples with only Jars being added to the classpath entry inside the manifest file. Any help is appreciated Thanks sangeetha STATEMENT OF CONFIDENTIALITY: The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify WHI Solutions immediately at g...@whisolutions.com, and destroy all copies of this message and any attachments. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven assembly problem
Hello All, I am using maven assembly and would like to add a dll to the classpath entry of the manifest file .How do I that using the maven assembly plugin .I see examples with only Jars being added to the classpath entry inside the manifest file. Any help is appreciated Thanks sangeetha STATEMENT OF CONFIDENTIALITY: The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify WHI Solutions immediately at g...@whisolutions.com, and destroy all copies of this message and any attachments. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Possible problem when multiple developers depend on SNAPSHOT versions
What can be done to prevent Bob's problem? Evidence to the contrary that Bob and Alice are working independently is they share development on single artifact Foo. Ensure Alice and Bob communicate daily on the development plan, schedule and status. Unless they are married..in which case you're stuffed ;-) -Original Message- From: Trevor Harmon [mailto:tre...@vocaro.com] Sent: Wednesday, March 25, 2009 12:11 PM To: Maven Users List Subject: Possible problem when multiple developers depend on SNAPSHOT versions Consider this scenario: Alice and Bob are working independently on two different applications, AppA and AppB. Both applications depend on an in-house shared library, Foo, that Alice and Bob are working on together. They have both checked out Foo's trunk and are regularly committing changes to it. Because Foo is undergoing heavy development, AppA and AppB depend on Foo 2.1-SNAPSHOT, but now Foo is looking pretty stable, and Alice's AppA needs some of the features scheduled for Foo 2.2, so she decides to perform a release of Foo 2.1 and does the usual release procedure: 1) Changes Foo's version from 2.1-SNAPSHOT to 2.1 and checks it into the trunk 2) Deploys Foo 2.1 to the company's internal repository 3) Tags the Foo trunk as the 2.1 release branch 4) Changes Foo's version from 2.1 to 2.2-SNAPSHOT and checks it into the trunk 5) Changes AppA's dependency to point to Foo 2.2-SNAPSHOT But what about Bob? He's still working with Foo 2.1-SNAPSHOT for his AppB. If he updates his working copy of Foo's source code, any changes he makes to Foo will be built as a 2.2-SNAPSHOT release, since Foo's trunk is now 2.2-SNAPSHOT. This is a major problem because his AppB has a dependency on 2.1-SNAPSHOT, so the next time he tests AppB, it will pick up the old Foo 2.1-SNAPSHOT, ignoring any changes Bob makes in Foo. He will probably waste a lot of time debugging, at least until he happens to notice that Foo's version has changed. What can be done to prevent Bob's problem? Trevor - 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: JSP Precompile and WebSphere
Here is what I found for Websphere documentation for JSPCBuild.xml
/**WINDOWS***/
Windows: ant -Dwas.home=%WAS_HOME% -Dear.path=%EAR_PATH%
-Dextract.dir=%EXTRACT_DIR%
Windows: ant jspc2 -Dwas.home=%WAS_HOME% -Dapp.name=%APP_NAME%
-Dwebmodule.name=%MOD_NAME%
Windows: ant jspc3 -Dwas.home=%WAS_HOME% -Dapp.name=%APP_NAME%
-Dwebmodule.name=%MOD_NAME% -Ddir.name=%DIR_NAME%
/UNIX***/
Unix: ant -Dwas.home=$WAS_HOME -Dear.path=$EAR_PATH
-Dextract.dir=$EXTRACT_DIR
Unix: ant jspc2 -Dwas.home=$WAS_HOME -Dapp.name=$APP_NAME
-Dwebmodule.name=$MOD_NAME
Unix: ant jspc3 -Dwas.home=$WAS_HOME -Dapp.name=$APP_NAME
-Dwebmodule.name=$MOD_NAME -Ddir.name=$DIR_NAME
/*JSPCBuild.xml from websphere displayed for your edification**/
!-- JspCBuild.xml - sample build.xml for the public WebSphere Ant task JspC.
JspC is included in--
!-- WebSphere Application Server and is found in the jar wsanttasks.jar.
--
!-- JspC is an Ant front-end to the JSP Batch Compiler. Descriptions of the
attributes can --
!-- be found in the Information Center, and in the file
batchcompiler.properties.default which --
!-- is found in {WAS_HOME}/bin.
--
!--
--
!-- JspC Attribute Equivalent
Batch Compiler Parameter --
!-- ==
=== --
!-- earPath -ear.path
--
!-- warPath -war.path
--
!-- src
--
!-- Same as warPath, for backward compatibility -war.path
--
!-- enterpriseAppName
-enterpriseapp.name --
!-- responseFile
-response.file --
!-- webmoduleName
-webmodule.name --
!-- fileName-filename
--
!-- configRoot
-config.root --
!-- cellName-cell.name
--
!-- nodeName-node.name
--
!-- serverName
-server.name --
!-- extractToDir
-extractToDir--
!-- compileToDir
-compileToDir--
!-- toDir
--
!-- same as compileToDir, for backward compatibility
-compileToDir--
!-- compileToWebInf
-compileToWebInf --
!-- jspCompileClasspath
-jspCompileClasspath --
!-- compilerOptions
-compilerOptions --
!-- recurse -recurse
--
!-- removeTempDir
-removeTempDir --
!-- translate -translate
--
!-- compile -compile
--
!-- forceCompilation
-forceCompilation--
!-- useFullPackageNames
-useFullPackageNames --
!-- trackDependencies
-trackDependencies --
!-- createDebugClassfiles
-createDebugClassfiles --
!-- keepgenerated
-keepgenerated --
!-- keepGeneratedclassfiles
-keepGeneratedclassfiles --
!-- usePageTagPool
Re: Re: Possible problem when multiple developers depend on SNAPSHOT versions
+1 Communication: the only solution that fits into any case. Get used to it. :-) On Mar 25, 2009 4:36pm, Heinrich Nirschl heinrich.nirs...@gmail.com wrote: On Wed, Mar 25, 2009 at 8:10 PM, Trevor Harmon tre...@vocaro.com wrote: What can be done to prevent Bob's problem? An easy solution is: When Alice prepares the release, she says Hey Bob, I'm doing a release of Foo. Henry - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Possible problem when multiple developers depend on SNAPSHOT versions
pick up the old Foo 2.1-SNAPSHOT, ignoring any changes Bob makes in Foo. He will probably waste a lot of time debugging, at least until he happens to notice that Foo's version has changed. Do we assume that bob is unable to see that the version he currently works on and compiles, tests, installs and maybe deploys has 2.2-snapshot written all over it? Maybe bob shouldn't be writing code ;-) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible problem when multiple developers depend on SNAPSHOT versions
But if Alice churns out releases of Foo every week, it gets old pretty quick. The other solution offered, branching is fine as long as that's what you want (maintain separate versions), but if Bob really just wants to always use the the latest Foo (even at the expense of possibly breaking Bob's build), he can set it to auto-integrate using Versions plugin ( http://mojo.codehaus.org/versions-maven-plugin/). We have a few modules like that (typically separate functional testing modules). We use a little script that invokes the version plugin and checks in the pom.xml if versions were updated. Hudson runs the update script nightly. Kalle On Wed, Mar 25, 2009 at 12:36 PM, Heinrich Nirschl heinrich.nirs...@gmail.com wrote: On Wed, Mar 25, 2009 at 8:10 PM, Trevor Harmon tre...@vocaro.com wrote: What can be done to prevent Bob's problem? An easy solution is: When Alice prepares the release, she says Hey Bob, I'm doing a release of Foo. Henry - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible problem when multiple developers depend on SNAPSHOT versions
With all due respect to others' responses, the scenario described below is not due to misuse or lack of version control. Indeed, the scenario below clearly describes version control *working as designed*. Bob finds himself unwittingly building snapshots of 2.2, while his project continues to depend on snapshots of 2.1, so he doesn't see his own changes. The problem, however, is neither source control nor maven: it's lack of communication. Something like cutting a release needs to be coordinated among the developers working on a component. Alice and Bob need to talk to each other about library Foo, particularly with respect to cutting a release. There's no way around this. // ben On Wed, Mar 25, 2009 at 20:10, Trevor Harmon tre...@vocaro.com wrote: Consider this scenario: Alice and Bob are working independently on two different applications, AppA and AppB. Both applications depend on an in-house shared library, Foo, that Alice and Bob are working on together. They have both checked out Foo's trunk and are regularly committing changes to it. Because Foo is undergoing heavy development, AppA and AppB depend on Foo 2.1-SNAPSHOT, but now Foo is looking pretty stable, and Alice's AppA needs some of the features scheduled for Foo 2.2, so she decides to perform a release of Foo 2.1 and does the usual release procedure: 1) Changes Foo's version from 2.1-SNAPSHOT to 2.1 and checks it into the trunk 2) Deploys Foo 2.1 to the company's internal repository 3) Tags the Foo trunk as the 2.1 release branch 4) Changes Foo's version from 2.1 to 2.2-SNAPSHOT and checks it into the trunk 5) Changes AppA's dependency to point to Foo 2.2-SNAPSHOT But what about Bob? He's still working with Foo 2.1-SNAPSHOT for his AppB. If he updates his working copy of Foo's source code, any changes he makes to Foo will be built as a 2.2-SNAPSHOT release, since Foo's trunk is now 2.2-SNAPSHOT. This is a major problem because his AppB has a dependency on 2.1-SNAPSHOT, so the next time he tests AppB, it will pick up the old Foo 2.1-SNAPSHOT, ignoring any changes Bob makes in Foo. He will probably waste a lot of time debugging, at least until he happens to notice that Foo's version has changed. What can be done to prevent Bob's problem? Trevor - 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: how to ship all license.txt files
This could help maybe: http://docs.atlassian.com/maven-licenses-plugin/0.2/project-summary.html SaM On Wed, Mar 25, 2009 at 7:23 PM, torsten.reinh...@gi-de.com wrote: Hi, when we ship our product, we have to ship also all used 3rdParty licenses. Is there a way to detect the license.txt files automatically? Extract those files from all dependencies, for example? Or do I have to enumerate all licenses in my pom.xml licenses license name/name url./url /license /licenses These plugins are NOT what I´m looking for: 1) http://code.google.com/p/maven-license-plugin/ 2) http://mojo.codehaus.org/rat-maven-plugin/ thanx for any advice, Torsten - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Possible problem when multiple developers depend on SNAPSHOT versions
Trevor Harmon wrote: Consider this scenario: Alice and Bob are working independently on two different applications, AppA and AppB. Both applications depend on an in-house shared library, Foo, that Alice and Bob are working on together. They have both checked out Foo's trunk and are regularly committing changes to it. Because Foo is undergoing heavy development, AppA and AppB depend on Foo 2.1-SNAPSHOT, but now Foo is looking pretty stable, and Alice's AppA needs some of the features scheduled for Foo 2.2, so she decides to perform a release of Foo 2.1 and does the usual release procedure: 1) Changes Foo's version from 2.1-SNAPSHOT to 2.1 and checks it into the trunk 2) Deploys Foo 2.1 to the company's internal repository 3) Tags the Foo trunk as the 2.1 release branch 4) Changes Foo's version from 2.1 to 2.2-SNAPSHOT and checks it into the trunk 5) Changes AppA's dependency to point to Foo 2.2-SNAPSHOT But what about Bob? He's still working with Foo 2.1-SNAPSHOT for his AppB. If he updates his working copy of Foo's source code, any changes he makes to Foo will be built as a 2.2-SNAPSHOT release, since Foo's trunk is now 2.2-SNAPSHOT. This is a major problem because his AppB has a dependency on 2.1-SNAPSHOT, so the next time he tests AppB, it will pick up the old Foo 2.1-SNAPSHOT, ignoring any changes Bob makes in Foo. He will probably waste a lot of time debugging, at least until he happens to notice that Foo's version has changed. What can be done to prevent Bob's problem? Use an inhouse global POM that is used as parent everywhere and define the versions used there in a depMgmt section. - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Duplicate name in parent and current
I think it's the duplicated artifactId's that is causing the problem. Maybe the artifactId of the pom in the subdirectory modA/modA should be set to modA-modA or something like that. huser wrote: Hi, I have a situation in which the dir names are same. Example: /base /base/modA /base/modA/modA I get the following error while trying to run mvn compile. The code for 2 POM's is below. What should I change in the parent to make this work ? Thanks, Reason: Parent element is a duplicate of the current project for project com.co.t3:modA [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Parent element is a duplicate of the current project for project com.co.t3:modA at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.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 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) /base/modA/pom.xml parent groupIdcom.co.t3/groupId artifactIdt3/artifactId version1.0-SNAPSHOT/version relativePath../base/pom.xml/relativePath /parent name modA /name groupIdcom.co.t3/groupId artifactIdmodA/artifactId packagingpom/packaging version1.0-SNAPSHOT/version /base/modA/modA/pom.xml parent groupIdcom.co.t3/groupId artifactIdmodA/artifactId version1.0-SNAPSHOT/version /parent groupIdcom.co.t3/groupId artifactIdmodA/artifactId packagingjar/packaging version1.0-SNAPSHOT/version - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANNOUCEMENT] Archiva 1.2 Released!
The Apache Archiva team is pleased to announce the release of Archiva 1.2 Apache Archiva is an extensible repository management software that helps taking care of your own personal or enterprise-wide build artifact repository. It is the perfect companion for build tools such as Maven, Continuum, and ANT. Archiva offers several capabilities, amongst which remote repository proxying, security access management, build artifact storage, delivery, browsing, indexing and usage reporting, extensible scanning functionality... and many more! The latest release is now available here: http://archiva.apache.org/download.html If you have any questions, please consult: - the web site: http://archiva.apache.org - the archiva-user mailing list: http://archiva.apache.org/mail-lists.html Change Log for Archiva 1.2 - ** Sub-task * [MRM-1038] - merge versions in search results * [MRM-1039] - remove metadata files from search results * [MRM-1040] - for snapshots in search results just show SNAPSHOT, not timestamps * [MRM-1041] - artifact version list should show basic shared project information rather than having to drill into one version * [MRM-1042] - snapshot should go to a page that shows a list of versions (go to latest, but list previous snapshots) * [MRM-1043] - improve appearance and flexibility of Advanced search (maybe change to add term buttons on the default search) * [MRM-1044] - class/package search is still flaky * [MRM-1046] - Write some decent tests for SearchAction ** Bug * [MRM-609] - Search results contains links with \ characters in them on Windows * [MRM-616] - When running on IBM JDK 1.5: java.security.NoSuchProviderException: no such provider: SUN * [MRM-731] - variable in url pom are not replaced. * [MRM-836] - The organization is incorrect when displaying an artifacts's Info via browsing or searching. * [MRM-842] - Issue tracker is incorrect when displaying an artifacts's Info via browsing or searching. * [MRM-901] - Repository groups does not display groups that have the same groupId * [MRM-921] - user management role does not display the user management menu * [MRM-922] - access to upload page with managed repository role * [MRM-933] - Incorrect search results hit count (ex. Hits: -6 to 23 of 39) for bytecode search * [MRM-962] - Upload Artifact action should trim its fields * [MRM-989] - download-type-javadoc.png is missing * [MRM-996] - HttpProxyTransferTest fails on Windows * [MRM-1000] - AdministrationServiceImplTest fails on Windows * [MRM-1004] - RepositoryServlet tests fail intermittently on Windows * [MRM-1011] - Organisation link on logo points to somewhere * [MRM-1013] - Fresh installation of Archiva with LDAP authentication does not survive restart of the servlet container * [MRM-1020] - Fix the crazy alpaca on Windows * [MRM-1027] - Indices are not cleaned up when deleting artifact via web services * [MRM-1028] - Find Artifact doesn't show up in the navigation menu after migration to struts 2 * [MRM-1032] - Pick Report - Repository Statistics: End Date can be set earlier than Start Date * [MRM-1034] - Browse artifact error does not show correct error message * [MRM-1047] - Archiva allows deployment by user with expired password * [MRM-1050] - Unable to remove user * [MRM-1057] - Archiva user-admin should be able to view useredit after logging in from Security Alert page * [MRM-1062] - Find Artifact broken * [MRM-1073] - Errors on when upgrading from v1.1.3 to v1.2-M1 * [MRM-1075] - Error 500 when accessing repository url * [MRM-1076] - NPE in NexusIndexConsumer when executed when an artifact is deployed in the Archiva repository * [MRM-1092] - Typo in Search results page * [MRM-1095] - Archiva keeps scanning repositories, even if scanning disabled in the web UI * [MRM-1096] - No icon for maven-plugin on artifact-details view. * [MRM-1101] - Audit log shows user guest when deploying files from Maven * [MRM-1105] - Legacy artifact path not properly stored when entered from Archiva UI * [MRM-1106] - NPE when starting Archiva * [MRM-1108] - empty logoLocation can be set for the organisation, but does not show the default logo * [MRM-1109] - environment checks do not indicate which caused a violation * [MRM-1110] - some redback log statements are not visible in Archiva logs * [MRM-1117] - move advanced search out of the 'info' popup on the quick search page * [MRM-1121] - NPE in browse at artifact level * [MRM-1122] - reduce verbosity of logging during scanning * [MRM-1133] - delete artifact role not added on upgrade from previous version * [MRM-1135] - Cannot remove a whitelist entry containing backslashes * [MRM-1136] - Archiva don't want to download a snapshot of a maven plugin (merged metadata are empty) * [MRM-1137] - Cannot upload artifact
Re: Duplicate name in parent and current
You cannot have two modules in the reactor with the same groupId and artifactId... from your pom snippets it looks like this is the case... consider changing either the groupId or the artifactId of one of the modA's (Note that the artifactId does not have to be the same as the directory name... it's just that it's nicer if it is ;-) ) -Stephen 2009/3/25 huser mpinj...@atxg.com Hi, I have a situation in which the dir names are same. Example: /base /base/modA /base/modA/modA I get the following error while trying to run mvn compile. The code for 2 POM's is below. What should I change in the parent to make this work ? Thanks, Reason: Parent element is a duplicate of the current project for project com.co.t3:modA [INFO] [INFO] Trace org.apache.maven.reactor.MavenExecutionException: Parent element is a duplicate of the current project for project com.co.t3:modA at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.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 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) /base/modA/pom.xml parent groupIdcom.co.t3/groupId artifactIdt3/artifactId version1.0-SNAPSHOT/version relativePath../base/pom.xml/relativePath /parent name modA /name groupIdcom.co.t3/groupId artifactIdmodA/artifactId packagingpom/packaging version1.0-SNAPSHOT/version /base/modA/modA/pom.xml parent groupIdcom.co.t3/groupId artifactIdmodA/artifactId version1.0-SNAPSHOT/version /parent groupIdcom.co.t3/groupId artifactIdmodA/artifactId packagingjar/packaging version1.0-SNAPSHOT/version -- View this message in context: http://www.nabble.com/Duplicate-name-in-parent-and-current-tp22707830p22707830.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
maven-install-plugin-2.3 is missing from main Maven repository at repo1.maven.org
Hi, We've just had a problem with a build that was looking for the latest maven-install-plugin, which is 2.3. [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] A required plugin was not found: Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.maven.plugins -DartifactId=maven-install-plugin -Dversion=2.3 -Dpackaging=maven-plugin -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.maven.plugins -DartifactId=maven-install-plugin -Dversion=2.3 -Dpackaging=maven-plugin -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] org.apache.maven.plugins:maven-install-plugin:maven-plugin:2.3 I've looked at http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plugin/2.3/ and the jar file isn't there. The sources and javadoc jar files are present. Are these files being uploaded manually or automatically? Was it just mistakenly deleted? Thanks for your help, Ellecer - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
hibernate byte code instrumentation
I am using maven-ant-run plugin to call hibernate byte code insturmentation , i also have maven jetty plugin , every time i run jetty plugin first all modified java files gets complied and then test cases and finally deployed , but this ant-run plugin for hibernate byte code instrumentation does not get called , please tell me how to call hibernate byte code automatically ? -- View this message in context: http://www.nabble.com/hibernate-byte-code-instrumentation-tp22714675p22714675.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-install-plugin-2.3 is missing from main Maven repository at repo1.maven.org
We're trying to recover the release artifact that seems to have been lost in transit. To work around this, you should add maven-install-plugin to your POM with the previous version (2.2). This is a good practice for reproducibility regardless, and in place by default in Maven 2.0.9+. Cheers, Brett On 26/03/2009, at 11:01 AM, Ellecer Valencia wrote: Hi, We've just had a problem with a build that was looking for the latest maven-install-plugin, which is 2.3. [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] A required plugin was not found: Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.maven.plugins -DartifactId=maven-install-plugin -Dversion=2.3 -Dpackaging=maven-plugin -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.maven.plugins -DartifactId=maven-install-plugin -Dversion=2.3 -Dpackaging=maven-plugin -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] org.apache.maven.plugins:maven-install-plugin:maven-plugin:2.3 I've looked at http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plugin/2.3/ and the jar file isn't there. The sources and javadoc jar files are present. Are these files being uploaded manually or automatically? Was it just mistakenly deleted? Thanks for your help, Ellecer - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
How to perform a deploy only
Hello all, I have several components all built from a top level pom. This works great for accelerating users to be able to build a lot of stuff quickly but is giving me some fits when trying to deploy. Up to this point I have been using deploy:deploy-file to get built components into our local repository after a full build is successful, but this is labor intensive. I would like to be able to run some variation of mvn deploy from the top level. I have figured out how to skip things using the FAQ here: http://maven.apache.org/plugins/maven-deploy-plugin/faq.html#skip But I do NOT want it to do anything other than deploy. I have googled for this but have not turned up anything useful. I was surprised that the documentation does not suggest how to do this. This is the correct deploy documentation I think. http://maven.apache.org/plugins/maven-deploy-plugin/ Anyway, any help would be appreciated. Thanks! -Jim - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Possible problem when multiple developers depend on SNAPSHOT versions
+10 From: B Smith-Mannschott [mailto:bsmith.o...@gmail.com] Sent: Wed 3/25/2009 5:49 PM To: Maven Users List Subject: Re: Possible problem when multiple developers depend on SNAPSHOT versions With all due respect to others' responses, the scenario described below is not due to misuse or lack of version control. Indeed, the scenario below clearly describes version control *working as designed*. Bob finds himself unwittingly building snapshots of 2.2, while his project continues to depend on snapshots of 2.1, so he doesn't see his own changes. The problem, however, is neither source control nor maven: it's lack of communication. Something like cutting a release needs to be coordinated among the developers working on a component. Alice and Bob need to talk to each other about library Foo, particularly with respect to cutting a release. There's no way around this. // ben On Wed, Mar 25, 2009 at 20:10, Trevor Harmon tre...@vocaro.com wrote: Consider this scenario: Alice and Bob are working independently on two different applications, AppA and AppB. Both applications depend on an in-house shared library, Foo, that Alice and Bob are working on together. They have both checked out Foo's trunk and are regularly committing changes to it. Because Foo is undergoing heavy development, AppA and AppB depend on Foo 2.1-SNAPSHOT, but now Foo is looking pretty stable, and Alice's AppA needs some of the features scheduled for Foo 2.2, so she decides to perform a release of Foo 2.1 and does the usual release procedure: 1) Changes Foo's version from 2.1-SNAPSHOT to 2.1 and checks it into the trunk 2) Deploys Foo 2.1 to the company's internal repository 3) Tags the Foo trunk as the 2.1 release branch 4) Changes Foo's version from 2.1 to 2.2-SNAPSHOT and checks it into the trunk 5) Changes AppA's dependency to point to Foo 2.2-SNAPSHOT But what about Bob? He's still working with Foo 2.1-SNAPSHOT for his AppB. If he updates his working copy of Foo's source code, any changes he makes to Foo will be built as a 2.2-SNAPSHOT release, since Foo's trunk is now 2.2-SNAPSHOT. This is a major problem because his AppB has a dependency on 2.1-SNAPSHOT, so the next time he tests AppB, it will pick up the old Foo 2.1-SNAPSHOT, ignoring any changes Bob makes in Foo. He will probably waste a lot of time debugging, at least until he happens to notice that Foo's version has changed. What can be done to prevent Bob's problem? Trevor - 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: maven-install-plugin-2.3 is missing from main Maven repository at repo1.maven.org
The jar is now on central and is being pushed again to all 1st level mirrors. -Original Message- From: Brett Porter [mailto:br...@apache.org] Sent: Wednesday, March 25, 2009 9:48 PM To: Maven Users List Subject: Re: maven-install-plugin-2.3 is missing from main Maven repository at repo1.maven.org We're trying to recover the release artifact that seems to have been lost in transit. To work around this, you should add maven-install-plugin to your POM with the previous version (2.2). This is a good practice for reproducibility regardless, and in place by default in Maven 2.0.9+. Cheers, Brett On 26/03/2009, at 11:01 AM, Ellecer Valencia wrote: Hi, We've just had a problem with a build that was looking for the latest maven-install-plugin, which is 2.3. [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] A required plugin was not found: Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.maven.plugins -DartifactId=maven-install-plugin -Dversion=2.3 -Dpackaging=maven-plugin -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.maven.plugins -DartifactId=maven-install-plugin -Dversion=2.3 -Dpackaging=maven-plugin -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] org.apache.maven.plugins:maven-install-plugin:maven-plugin:2.3 I've looked at http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plu gin/2.3/ and the jar file isn't there. The sources and javadoc jar files are present. Are these files being uploaded manually or automatically? Was it just mistakenly deleted? Thanks for your help, Ellecer - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - 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: How to perform a deploy only
I'm not 100% sure I understand, but mvn deploy:deploy will do what I think you are describing. Justin From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wed 3/25/2009 10:17 PM To: 'users@maven.apache.org' Subject: How to perform a deploy only Hello all, I have several components all built from a top level pom. This works great for accelerating users to be able to build a lot of stuff quickly but is giving me some fits when trying to deploy. Up to this point I have been using deploy:deploy-file to get built components into our local repository after a full build is successful, but this is labor intensive. I would like to be able to run some variation of mvn deploy from the top level. I have figured out how to skip things using the FAQ here: http://maven.apache.org/plugins/maven-deploy-plugin/faq.html#skip But I do NOT want it to do anything other than deploy. I have googled for this but have not turned up anything useful. I was surprised that the documentation does not suggest how to do this. This is the correct deploy documentation I think. http://maven.apache.org/plugins/maven-deploy-plugin/ Anyway, any help would be appreciated. Thanks! -Jim - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Possible problem when multiple developers depend on SNAPSHOT versions
The only way to accomplish this is called version control but since you do not want to use version control .. how do you achieve intelligent merging *on the same component codebase* without version control ? Martin __ Verzicht und Vertraulichkeitanmerkung / Disclaimer and confidentiality note Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. This message is confidential and may be privileged. If you are not the intended recipient, we kindly ask you to please inform the sender. Any unauthorised dissemination or copying hereof is prohibited. This message serves for information purposes only and shall not have any legally binding effect. Given that e-mails can easily be subject to manipulation, we can not accept any liability for the content provided. Subject: RE: Possible problem when multiple developers depend on SNAPSHOT versions Date: Wed, 25 Mar 2009 22:18:53 -0400 From: justin.edel...@mtvstaff.com To: users@maven.apache.org +10 From: B Smith-Mannschott [mailto:bsmith.o...@gmail.com] Sent: Wed 3/25/2009 5:49 PM To: Maven Users List Subject: Re: Possible problem when multiple developers depend on SNAPSHOT versions With all due respect to others' responses, the scenario described below is not due to misuse or lack of version control. Indeed, the scenario below clearly describes version control *working as designed*. Bob finds himself unwittingly building snapshots of 2.2, while his project continues to depend on snapshots of 2.1, so he doesn't see his own changes. The problem, however, is neither source control nor maven: it's lack of communication. Something like cutting a release needs to be coordinated among the developers working on a component. Alice and Bob need to talk to each other about library Foo, particularly with respect to cutting a release. There's no way around this. // ben On Wed, Mar 25, 2009 at 20:10, Trevor Harmon tre...@vocaro.com wrote: Consider this scenario: Alice and Bob are working independently on two different applications, AppA and AppB. Both applications depend on an in-house shared library, Foo, that Alice and Bob are working on together. They have both checked out Foo's trunk and are regularly committing changes to it. Because Foo is undergoing heavy development, AppA and AppB depend on Foo 2.1-SNAPSHOT, but now Foo is looking pretty stable, and Alice's AppA needs some of the features scheduled for Foo 2.2, so she decides to perform a release of Foo 2.1 and does the usual release procedure: 1) Changes Foo's version from 2.1-SNAPSHOT to 2.1 and checks it into the trunk 2) Deploys Foo 2.1 to the company's internal repository 3) Tags the Foo trunk as the 2.1 release branch 4) Changes Foo's version from 2.1 to 2.2-SNAPSHOT and checks it into the trunk 5) Changes AppA's dependency to point to Foo 2.2-SNAPSHOT But what about Bob? He's still working with Foo 2.1-SNAPSHOT for his AppB. If he updates his working copy of Foo's source code, any changes he makes to Foo will be built as a 2.2-SNAPSHOT release, since Foo's trunk is now 2.2-SNAPSHOT. This is a major problem because his AppB has a dependency on 2.1-SNAPSHOT, so the next time he tests AppB, it will pick up the old Foo 2.1-SNAPSHOT, ignoring any changes Bob makes in Foo. He will probably waste a lot of time debugging, at least until he happens to notice that Foo's version has changed. What can be done to prevent Bob's problem? Trevor - 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 _ Windows Live™ SkyDrive: Get 25 GB of free online storage. http://windowslive.com/online/skydrive?ocid=TXT_TAGLM_WL_skydrive_032009
RE: How to perform a deploy only
This really isn't a supported use case. Deploy is a phase and by definition all earlier phases run before the one you've asked for. Why would you not want to build before you deploy? -Original Message- From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wednesday, March 25, 2009 10:17 PM To: 'users@maven.apache.org' Subject: How to perform a deploy only Hello all, I have several components all built from a top level pom. This works great for accelerating users to be able to build a lot of stuff quickly but is giving me some fits when trying to deploy. Up to this point I have been using deploy:deploy-file to get built components into our local repository after a full build is successful, but this is labor intensive. I would like to be able to run some variation of mvn deploy from the top level. I have figured out how to skip things using the FAQ here: http://maven.apache.org/plugins/maven-deploy-plugin/faq.html#skip But I do NOT want it to do anything other than deploy. I have googled for this but have not turned up anything useful. I was surprised that the documentation does not suggest how to do this. This is the correct deploy documentation I think. http://maven.apache.org/plugins/maven-deploy-plugin/ Anyway, any help would be appreciated. Thanks! -Jim - 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: How to perform a deploy only
I have a whole bunch of components that are mostly interrelated but consumable individually by downstream builds. If I run deploy it basically starts deploying as it goes, so if a downstream component breaks for some reason then I am left with half of the components updated in the maven repo and half not. That's not really what we want. So ideally, we would run a build/test, make sure it all gets through completely, then deploy the resulting artifacts. -Jim -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: Wednesday, March 25, 2009 9:20 PM To: Maven Users List Subject: RE: How to perform a deploy only This really isn't a supported use case. Deploy is a phase and by definition all earlier phases run before the one you've asked for. Why would you not want to build before you deploy? -Original Message- From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wednesday, March 25, 2009 10:17 PM To: 'users@maven.apache.org' Subject: How to perform a deploy only Hello all, I have several components all built from a top level pom. This works great for accelerating users to be able to build a lot of stuff quickly but is giving me some fits when trying to deploy. Up to this point I have been using deploy:deploy-file to get built components into our local repository after a full build is successful, but this is labor intensive. I would like to be able to run some variation of mvn deploy from the top level. I have figured out how to skip things using the FAQ here: http://maven.apache.org/plugins/maven-deploy-plugin/faq.html#skip But I do NOT want it to do anything other than deploy. I have googled for this but have not turned up anything useful. I was surprised that the documentation does not suggest how to do this. This is the correct deploy documentation I think. http://maven.apache.org/plugins/maven-deploy-plugin/ Anyway, any help would be appreciated. Thanks! -Jim - 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
RE: How to perform a deploy only
Hi Justin, Thanks for the suggestion. I just tried your suggestion and got this error: [INFO] [deploy:deploy] [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The packaging for this project did not assign a file to the build artifact I guess it's not getting enough data from the rest of the Maven phases as Brian suggests in his other message to get all the data it needs on which files to deploy. -Jim -Original Message- From: Edelson, Justin [mailto:justin.edel...@mtvstaff.com] Sent: Wednesday, March 25, 2009 9:21 PM To: Maven Users List Subject: RE: How to perform a deploy only I'm not 100% sure I understand, but mvn deploy:deploy will do what I think you are describing. Justin From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wed 3/25/2009 10:17 PM To: 'users@maven.apache.org' Subject: How to perform a deploy only Hello all, I have several components all built from a top level pom. This works great for accelerating users to be able to build a lot of stuff quickly but is giving me some fits when trying to deploy. Up to this point I have been using deploy:deploy-file to get built components into our local repository after a full build is successful, but this is labor intensive. I would like to be able to run some variation of mvn deploy from the top level. I have figured out how to skip things using the FAQ here: http://maven.apache.org/plugins/maven-deploy-plugin/faq.html#skip But I do NOT want it to do anything other than deploy. I have googled for this but have not turned up anything useful. I was surprised that the documentation does not suggest how to do this. This is the correct deploy documentation I think. http://maven.apache.org/plugins/maven-deploy-plugin/ Anyway, any help would be appreciated. Thanks! -Jim - 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: How to perform a deploy only
Brian can pitch his own stuff far better than I can, but this kind of transactional deployment can be done with Nexus' Staging feature. I realized after I sent my deploy:deploy suggestion that it probably wouldn't work without running at least the package phase, sorry to give you bad info. I'm reasonably confident with some light hacking you could write a plugin that essentially faked the build, but if the below is your use case and you can afford Nexus Pro, it's probably a better solution. Justin From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wed 3/25/2009 10:37 PM To: 'Maven Users List' Subject: RE: How to perform a deploy only I have a whole bunch of components that are mostly interrelated but consumable individually by downstream builds. If I run deploy it basically starts deploying as it goes, so if a downstream component breaks for some reason then I am left with half of the components updated in the maven repo and half not. That's not really what we want. So ideally, we would run a build/test, make sure it all gets through completely, then deploy the resulting artifacts. -Jim -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: Wednesday, March 25, 2009 9:20 PM To: Maven Users List Subject: RE: How to perform a deploy only This really isn't a supported use case. Deploy is a phase and by definition all earlier phases run before the one you've asked for. Why would you not want to build before you deploy? -Original Message- From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wednesday, March 25, 2009 10:17 PM To: 'users@maven.apache.org' Subject: How to perform a deploy only Hello all, I have several components all built from a top level pom. This works great for accelerating users to be able to build a lot of stuff quickly but is giving me some fits when trying to deploy. Up to this point I have been using deploy:deploy-file to get built components into our local repository after a full build is successful, but this is labor intensive. I would like to be able to run some variation of mvn deploy from the top level. I have figured out how to skip things using the FAQ here: http://maven.apache.org/plugins/maven-deploy-plugin/faq.html#skip But I do NOT want it to do anything other than deploy. I have googled for this but have not turned up anything useful. I was surprised that the documentation does not suggest how to do this. This is the correct deploy documentation I think. http://maven.apache.org/plugins/maven-deploy-plugin/ Anyway, any help would be appreciated. Thanks! -Jim - 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
RE: How to perform a deploy only
Thanks for the suggestion. I have been trying to avoid using repository managers for a number of reasons that are beyond the scope of this thread. I may have to break down eventually... I'm surprised no one has needed this sort of feature, or maybe they have and that's why Nexus has the features that it does. I was hoping to find a Maven native (whatever native means in a highly pluggable architecture) way to do this that would not take much additional work. mvn -DdoNothingButDeploy=true deploy That would be about perfect. :) Would this even be consider for an enhancement request if I opened it? Perhaps I am the only one interested in such a thing. Thanks! -Jim -Original Message- From: Edelson, Justin [mailto:justin.edel...@mtvstaff.com] Sent: Wednesday, March 25, 2009 9:55 PM To: Maven Users List Subject: RE: How to perform a deploy only Brian can pitch his own stuff far better than I can, but this kind of transactional deployment can be done with Nexus' Staging feature. I realized after I sent my deploy:deploy suggestion that it probably wouldn't work without running at least the package phase, sorry to give you bad info. I'm reasonably confident with some light hacking you could write a plugin that essentially faked the build, but if the below is your use case and you can afford Nexus Pro, it's probably a better solution. Justin From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wed 3/25/2009 10:37 PM To: 'Maven Users List' Subject: RE: How to perform a deploy only I have a whole bunch of components that are mostly interrelated but consumable individually by downstream builds. If I run deploy it basically starts deploying as it goes, so if a downstream component breaks for some reason then I am left with half of the components updated in the maven repo and half not. That's not really what we want. So ideally, we would run a build/test, make sure it all gets through completely, then deploy the resulting artifacts. -Jim -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: Wednesday, March 25, 2009 9:20 PM To: Maven Users List Subject: RE: How to perform a deploy only This really isn't a supported use case. Deploy is a phase and by definition all earlier phases run before the one you've asked for. Why would you not want to build before you deploy? -Original Message- From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wednesday, March 25, 2009 10:17 PM To: 'users@maven.apache.org' Subject: How to perform a deploy only Hello all, I have several components all built from a top level pom. This works great for accelerating users to be able to build a lot of stuff quickly but is giving me some fits when trying to deploy. Up to this point I have been using deploy:deploy-file to get built components into our local repository after a full build is successful, but this is labor intensive. I would like to be able to run some variation of mvn deploy from the top level. I have figured out how to skip things using the FAQ here: http://maven.apache.org/plugins/maven-deploy-plugin/faq.html#skip But I do NOT want it to do anything other than deploy. I have googled for this but have not turned up anything useful. I was surprised that the documentation does not suggest how to do this. This is the correct deploy documentation I think. http://maven.apache.org/plugins/maven-deploy-plugin/ Anyway, any help would be appreciated. Thanks! -Jim - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[Vote] findbugs-maven-plugin v 2.0 release
The Maven Findbugs team would like to release Maven Findbugs Plugin version 2.0 This plugin allows the developer to run Findbugs analysis against a Maven project and produce site output in HTML to match other site reports. There are option to produce other XML outputs which are used by other plugins. Issues fixed in this release: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truefixfor=14335pid=11701status=6sorter/field=issuekeysorter/order=DESCsorter/field=issuetypesorter/order=DESC More information can be found at the plugin site: http://mojo.codehaus.org/findbugs-maven-plugin/ Issues Can be registered in JIRA at: http://jira.codehaus.org/browse/MFINDBUGS More information on FindBugs http://findbugs.sourceforge.net/index.html You can test the Maven Findbugs Plugin in your own project by adding the following dependency: dependency groupIdorg.codehaus.mojo/groupId artifactIdfindbugs-maven-plugin/artifactId version2.0-SNAPSHOT/version /dependency *NOTE* Version 2.0 and greater of the Maven Findbugs plugin will require Maven to be run with a minimum of Java 5. This is consistent with Findbugs requirement for their versions of 1.3.X and greater. Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 -- Regards, Garvin LeClaire garvin.lecla...@gmail.com
Re: how to ship all license.txt files
Perhaps the remote resources plugin, although its documentation is rather opaque; I think apache projects use it to include license files. I thought they had an example of how they did their license inclusion but now I can't find it. Perhaps it's in the source distribution for maven and I read about that somewhere. http://maven.apache.org/plugins/maven-remote-resources-plugin/index.html torsten.reinh...@gi-de.com wrote: Hi, when we ship our product, we have to ship also all used 3rdParty licenses. Is there a way to detect the license.txt files automatically? Extract those files from all dependencies, for example? Or do I have to enumerate all licenses in my pom.xml licenses license name/name url./url /license /licenses These plugins are NOT what I´m looking for: 1) http://code.google.com/p/maven-license-plugin/ 2) http://mojo.codehaus.org/rat-maven-plugin/ thanx for any advice, Torsten - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to perform a deploy only
Hudson has a feature to deploy all after successful build rather than module-by-module with native Maven. Kalle On Wed, Mar 25, 2009 at 8:25 PM, Jim McCaskey jim.mccas...@pervasive.comwrote: Thanks for the suggestion. I have been trying to avoid using repository managers for a number of reasons that are beyond the scope of this thread. I may have to break down eventually... I'm surprised no one has needed this sort of feature, or maybe they have and that's why Nexus has the features that it does. I was hoping to find a Maven native (whatever native means in a highly pluggable architecture) way to do this that would not take much additional work. mvn -DdoNothingButDeploy=true deploy That would be about perfect. :) Would this even be consider for an enhancement request if I opened it? Perhaps I am the only one interested in such a thing. Thanks! -Jim -Original Message- From: Edelson, Justin [mailto:justin.edel...@mtvstaff.com] Sent: Wednesday, March 25, 2009 9:55 PM To: Maven Users List Subject: RE: How to perform a deploy only Brian can pitch his own stuff far better than I can, but this kind of transactional deployment can be done with Nexus' Staging feature. I realized after I sent my deploy:deploy suggestion that it probably wouldn't work without running at least the package phase, sorry to give you bad info. I'm reasonably confident with some light hacking you could write a plugin that essentially faked the build, but if the below is your use case and you can afford Nexus Pro, it's probably a better solution. Justin From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wed 3/25/2009 10:37 PM To: 'Maven Users List' Subject: RE: How to perform a deploy only I have a whole bunch of components that are mostly interrelated but consumable individually by downstream builds. If I run deploy it basically starts deploying as it goes, so if a downstream component breaks for some reason then I am left with half of the components updated in the maven repo and half not. That's not really what we want. So ideally, we would run a build/test, make sure it all gets through completely, then deploy the resulting artifacts. -Jim -Original Message- From: Brian E. Fox [mailto:bri...@reply.infinity.nu] Sent: Wednesday, March 25, 2009 9:20 PM To: Maven Users List Subject: RE: How to perform a deploy only This really isn't a supported use case. Deploy is a phase and by definition all earlier phases run before the one you've asked for. Why would you not want to build before you deploy? -Original Message- From: Jim McCaskey [mailto:jim.mccas...@pervasive.com] Sent: Wednesday, March 25, 2009 10:17 PM To: 'users@maven.apache.org' Subject: How to perform a deploy only Hello all, I have several components all built from a top level pom. This works great for accelerating users to be able to build a lot of stuff quickly but is giving me some fits when trying to deploy. Up to this point I have been using deploy:deploy-file to get built components into our local repository after a full build is successful, but this is labor intensive. I would like to be able to run some variation of mvn deploy from the top level. I have figured out how to skip things using the FAQ here: http://maven.apache.org/plugins/maven-deploy-plugin/faq.html#skip But I do NOT want it to do anything other than deploy. I have googled for this but have not turned up anything useful. I was surprised that the documentation does not suggest how to do this. This is the correct deploy documentation I think. http://maven.apache.org/plugins/maven-deploy-plugin/ Anyway, any help would be appreciated. Thanks! -Jim - 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Install Plugin 2.3 Released
The Maven team is pleased to announce the release of the Maven Install Plugin, version 2.3 The Install Plugin is used during the install phase to add artifact(s) to the local repository. http://maven.apache.org/plugins/maven-install-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-install-plugin/artifactId version2.3/version /plugin Release Notes - Maven 2.x Install Plugin - Version 2.3 ** Bug * [MINSTALL-18] - Bad algorithm to decide if the main artifact is to be installed or not * [MINSTALL-41] - Install with classifier does not install pom * [MINSTALL-55] - install-file fails to grab version inhertied from parent * [MINSTALL-56] - No checksums installed for project with packaging POM ** Improvement * [MINSTALL-44] - add XML encoding support for POM reading/writing * [MINSTALL-48] - Don't create checksums for gpg signature files * [MINSTALL-57] - Default generatePom to true * [MINSTALL-59] - Validate artifact id ** New Feature * [MINSTALL-49] - install-file with javadoc and sources * [MINSTALL-60] - Support updateReleaseInfo for install-file ** Task * [MINSTALL-46] - remove copy of plexus-utils' XML encoding support sources * [MINSTALL-61] - Remove parameter localRepositoryId Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-install-plugin-2.3 is missing from main Maven repository at repo1.maven.org
Great, thanks guys! I'll try to move all of our stuff to start using maven 2.0.9 or higher. On Thu, Mar 26, 2009 at 1:18 PM, Brian E. Fox bri...@reply.infinity.nu wrote: The jar is now on central and is being pushed again to all 1st level mirrors. -Original Message- From: Brett Porter [mailto:br...@apache.org] Sent: Wednesday, March 25, 2009 9:48 PM To: Maven Users List Subject: Re: maven-install-plugin-2.3 is missing from main Maven repository at repo1.maven.org We're trying to recover the release artifact that seems to have been lost in transit. To work around this, you should add maven-install-plugin to your POM with the previous version (2.2). This is a good practice for reproducibility regardless, and in place by default in Maven 2.0.9+. Cheers, Brett On 26/03/2009, at 11:01 AM, Ellecer Valencia wrote: Hi, We've just had a problem with a build that was looking for the latest maven-install-plugin, which is 2.3. [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] A required plugin was not found: Plugin could not be found - check that the goal name is correct: Unable to download the artifact from any repository Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.apache.maven.plugins -DartifactId=maven-install-plugin -Dversion=2.3 -Dpackaging=maven-plugin -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.maven.plugins -DartifactId=maven-install-plugin -Dversion=2.3 -Dpackaging=maven-plugin -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] org.apache.maven.plugins:maven-install-plugin:maven-plugin:2.3 I've looked at http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plu gin/2.3/ and the jar file isn't there. The sources and javadoc jar files are present. Are these files being uploaded manually or automatically? Was it just mistakenly deleted? Thanks for your help, Ellecer - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Brett Porter br...@apache.org http://blogs.exist.com/bporter/ - 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
