Build a virtual machine using maven? A realistic idea?
Hi, Recently I have been doing some work with a virtual machine (Ubuntu) with some specific programs installed. But what I am starting to realise is that we don't have a good documentation on exactly what is on this machine, and what changes has been made since it first was created, especially since it wasn't even created by me. At the same time I am working alot with web applications, and use Maven, Subversion, CI etc on a daily basis. But all these wonderful tools can't be used when I work with virtual machines, even though it would be so great if that could work. In the best of worlds I would be able to build a VM (in standard OVF format) just as easily as I now build a war- or ear-file. All our specific files and configuration would be under version control in SVN, and I would just add a dependency to a vanilla virtual machine (like Ubunto-64 version 9.10) and it would insert our file structure into the VM, almost like war-overlay works for web applications. And maybe some specific programs could be installed by the means of defining other dependencies. The advantages are obvious. One would now have complete controll of the content of the virtual machine, and not have to worry about some forgotten data in some database or file for example. And if one decided to switch from Ubuntu to say OpenSUSE it would idealy be a simple change of dependencies. Maybe even a change from Linux to Windows would be possible in the same simple manner, given that the proper license exists. What do you guys think about this idea? Is it realistic? Or maybe such a solution, or similar, already exists or is planned? /Jimi Hullegård - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Problem with https
Hello, I have tried to connect maven with repositories via https but it wasn't successful. My environment : - server is Centos 5.4 64 bit with jre 6u19 - nexus is running in Glassfish v3. - firewall is disabled - client is Fedora 12 64 bit - maven is in version 2.2.1 My steps : 1) Import security certificate from glassfish (via program import-ssl.jar) to keystore /usr/java/latest/jre/lib/security/cacerts 2) Try if security certificate is working (with java program SSLPoke) - it works 3) Config repositories : repositories repository idcatseye/id urlhttps://catseye.cpce.net:8181/nexus/content/groups/public//url layoutdefault/layout /repository /repositories pluginRepositories pluginRepository idcatseye/id urlhttps://catseye.cpce.net:8181/nexus/content/groups/public//url /pluginRepository /pluginRepositories 4) Run maven with command mvn compile. It shows these errors : Downloading: https://catseye.cpce.net:8181/nexus/content/groups/public//org/apache/felix/maven-bundle-plugin/2.0.1 /maven-bundle-plugin-2.0.1.pom [WARNING] Unable to get resource 'org.apache.felix:maven-bundle-plugin:pom:2.0.1' from repository catseye (https://dev.net:8181/nexus/content/groups/public/): Error transferring file: java.security.cert.CertificateException: No name matching catseye.cpce.net found 5) Rerun the same command with debug option mvn -Djavax.net.debug=ssl compile(see attachment) 6) Open link with firefox is ok (of course I had to accept self-signed certificate) Only for control, if Nexus is correctly configured, I have switched to http listener and everything works correctly. Is there a bug in maven or something in my configuration is missing? Thanks for any ideas. best regards jakub [INFO] Scanning for projects... [INFO] Reactor build order: [INFO] MyTest Downloading: https://catseye.cpce.net:8181/nexus/content/groups/public//org/apache/felix/maven-bundle-plugin/2.0.1/maven-bundle-plugin-2.0.1.jar keyStore is : keyStore type is : jks keyStore provider is : init keystore init keymanager of type SunX509 trustStore is: /usr/java/jdk1.6.0_19/jre/lib/security/cacerts trustStore type is : jks trustStore provider is : init truststore adding as trusted cert: Subject: CN=SwissSign Platinum CA - G2, O=SwissSign AG, C=CH Issuer: CN=SwissSign Platinum CA - G2, O=SwissSign AG, C=CH Algorithm: RSA; Serial number: 0x4eb200670c035d4f Valid from Wed Oct 25 10:36:00 CEST 2006 until Sat Oct 25 10:36:00 CEST 2036 adding as trusted cert: Subject: emailaddress=i...@valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 1 Policy Validation Authority, O=ValiCert, Inc., L=ValiCert Validation Network Issuer: emailaddress=i...@valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 1 Policy Validation Authority, O=ValiCert, Inc., L=ValiCert Validation Network Algorithm: RSA; Serial number: 0x1 Valid from Sat Jun 26 00:23:48 CEST 1999 until Wed Jun 26 00:23:48 CEST 2019 adding as trusted cert: Subject: CN=thawte Primary Root CA, OU=(c) 2006 thawte, Inc. - For authorized use only, OU=Certification Services Division, O=thawte, Inc., C=US Issuer: CN=thawte Primary Root CA, OU=(c) 2006 thawte, Inc. - For authorized use only, OU=Certification Services Division, O=thawte, Inc., C=US Algorithm: RSA; Serial number: 0x344ed55720d5edec49f42fce37db2b6d Valid from Fri Nov 17 01:00:00 CET 2006 until Thu Jul 17 01:59:59 CEST 2036 adding as trusted cert: Subject: CN=Entrust Root Certification Authority, OU=(c) 2006 Entrust, Inc., OU=www.entrust.net/CPS is incorporated by reference, O=Entrust, Inc., C=US Issuer: CN=Entrust Root Certification Authority, OU=(c) 2006 Entrust, Inc., OU=www.entrust.net/CPS is incorporated by reference, O=Entrust, Inc., C=US Algorithm: RSA; Serial number: 0x456b5054 Valid from Mon Nov 27 21:23:42 CET 2006 until Fri Nov 27 21:53:42 CET 2026 adding as trusted cert: Subject: CN=KEYNECTIS ROOT CA, OU=ROOT, O=KEYNECTIS, C=FR Issuer: CN=KEYNECTIS ROOT CA, OU=ROOT, O=KEYNECTIS, C=FR Algorithm: RSA; Serial number: 0x1121bc276c5547af584eefd4ced629b2a285 Valid from Tue May 26 02:00:00 CEST 2009 until Tue May 26 02:00:00 CEST 2020 adding as trusted cert: Subject: CN=Global Chambersign Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU Issuer: CN=Global Chambersign Root - 2008, O=AC Camerfirma S.A., SERIALNUMBER=A82743287, L=Madrid (see current address at www.camerfirma.com/address), C=EU Algorithm: RSA; Serial number: 0xc9cdd3e9d57d23ce Valid from Fri Aug 01 14:31:40 CEST 2008 until Sat Jul 31 14:31:40 CEST 2038 adding as trusted cert: Subject: CN=America Online Root Certification Authority 2, O=America Online Inc., C=US Issuer: CN=America Online Root Certification Authority 2, O=America Online Inc., C=US Algorithm: RSA; Serial number: 0x1 Valid from Tue May 28 08:00:00
release:prepare ignores preparationGoals configuration in child of multi module project
if I have a project structure like below: project-root + --- project-a + --- project-b + --- project-c and in project-root I have plugin artifactIdmaven-release-plugin/artifactId /plugin and in project-b I have plugin artifactIdmaven-release-plugin/artifactId configuration preparationGoalsclean install/preparationGoals /configuration /plugin when I run mvn release:prepare (mvn 2.2.1) in the project-root directory I see [INFO] [INFO] Building project-b [INFO] [INFO]task-segment: [clean, verify] and the build fails because project-c needs an artifact that gets generated in project-b's install phase. If I change the setup and add the configuration of the clean install preparation goals into the parent pom project-root plugin artifactIdmaven-release-plugin/artifactId configuration preparationGoalsclean install/preparationGoals /configuration /plugin I can see the following output: [INFO] [INFO] Building project-b [INFO] [INFO]task-segment: [clean, install] and the project builds successfully. I would like to only build one child module with clean install to save time. Does the release plugin ignore all configuration in child modules and only uses the configuration from the module where it is run from? Or do I need to add some other configuration? Raphael - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
What MavenProject.getCollectedProjects() return
Hi All, Can somebody point me the location/link where I can have doc for this method : MavenProject.getCollectedProjects() Thanks, Amaresh
Dynamic archetype
Hi folks, I'm looking for a way of dynamically specifying dependencies in my archetype. Why, you ask? Well, I run a code kata site ( http://codingkata.org codingkata.org ) and for advanced katas I'm planning to include e.g. database access and messaging queues. If I create my archetypes the usual way I would have to create one for every language I support (6) with every combination of libraries - which would soon end in hundreds of combinations. That's why I'd have to 'dynamically' insert the library dependencies. But I can't figure out how that would work, any ideas? Cheers, stephanos -- View this message in context: http://old.nabble.com/Dynamic-archetype-tp28253601p28253601.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: Build a virtual machine using maven? A realistic idea?
If you write a maven-plugin to do what you describe you will be a hero! See inline for notes 2010/4/15 Jimi Hullegård jimi.hulleg...@mogul.com Hi, Recently I have been doing some work with a virtual machine (Ubuntu) with some specific programs installed. But what I am starting to realise is that we don't have a good documentation on exactly what is on this machine, and what changes has been made since it first was created, especially since it wasn't even created by me. At the same time I am working alot with web applications, and use Maven, Subversion, CI etc on a daily basis. But all these wonderful tools can't be used when I work with virtual machines, even though it would be so great if that could work. In the best of worlds I would be able to build a VM (in standard OVF format) just as easily as I now build a war- or ear-file. All our specific files and configuration would be I see no issues in creating the OVF file from a maven plugin, ovf is just XML under version control in SVN, and I would just add a dependency to a vanilla virtual machine (like Ubunto-64 version 9.10) and it would insert our file structure into So the maven plugin would understand the on-disk format of all operating systems and be able to make changes to the on-disk format... not realistic... esp given that the VM disk format is still not standardised. OVF only standardises the metadata about VMs, not the VM virtual disk format, let alone the virtual OS's disk format. I could see interaction with (when I get back to it) vcc-maven-plu...@mojowhereby you could deploy an OVF based VM to a virtual machine host, then you could use other maven plugins to connect to the VM and install what ever you require, and finally use vcc-m-p to take a snapshot/image to package back up again... but even that is a bit of stretch. You might also want to look into the stuff RedHat is doing on virtual disk format conversion -Stephen the VM, almost like war-overlay works for web applications. And maybe some specific programs could be installed by the means of defining other dependencies. The advantages are obvious. One would now have complete controll of the content of the virtual machine, and not have to worry about some forgotten data in some database or file for example. And if one decided to switch from Ubuntu to say OpenSUSE it would idealy be a simple change of dependencies. Maybe even a change from Linux to Windows would be possible in the same simple manner, given that the proper license exists. What do you guys think about this idea? Is it realistic? Or maybe such a solution, or similar, already exists or is planned? /Jimi Hullegård - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Maven 2.0.10 with two plugins with custom packaging types
Hi Maven users, I'm having problems with two plugins, which both define a custom packaging type. The packaging types are source-plugin and binary-plugin, which are defined in a private maven plugin and warpath, which is defined in the warpath plugin. If I run the project with both plugins defined, only the first plugin seems to be taken into account. E.g. if our private plugin is defined above the warputh plugin, source-plugin and binary-plugin can be resolved and warpath cannot be resolved. Same thing vice versa, if the warputh plugin is defined above out plugin, warpath can be resolved, source-plugin and binary-plugin not. Plugins are defined this way: plugin groupIdcom.company/groupId artifactIdmaven-rcpbuild-plugin/artifactId version1.0.3/version extensionstrue/extensions /plugin plugin groupIdorg.appfuse/groupId artifactIdmaven-warpath-plugin/artifactId version2.0.2/version extensionstrue/extensions executions execution goals goaladd-classes/goal /goals /execution /executions /plugin Running the project with our plugin and without the warpath plugin works and vice versa. If I run the same configuration with maven 2.2.1, it works as expected. Also the plugin order is irrelevant. Is this a limitation of maven 2.0.*, or a bug or am I doing something wrong? I'm lost with this problem. Any hints are appreciated. Let me know, if some relevant information is missing. Thanks in advance, Henrik - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 2.0.10 with two plugins with custom packaging types
Hi Henrik, Henrik Niehaus wrote: Hi Maven users, I'm having problems with two plugins, which both define a custom packaging type. The packaging types are source-plugin and binary-plugin, which are defined in a private maven plugin and warpath, which is defined in the warpath plugin. If I run the project with both plugins defined, only the first plugin seems to be taken into account. E.g. if our private plugin is defined above the warputh plugin, source-plugin and binary-plugin can be resolved and warpath cannot be resolved. Same thing vice versa, if the warputh plugin is defined above out plugin, warpath can be resolved, source-plugin and binary-plugin not. Plugins are defined this way: plugin groupIdcom.company/groupId artifactIdmaven-rcpbuild-plugin/artifactId version1.0.3/version extensionstrue/extensions /plugin plugin groupIdorg.appfuse/groupId artifactIdmaven-warpath-plugin/artifactId version2.0.2/version extensionstrue/extensions executions execution goals goaladd-classes/goal /goals /execution /executions /plugin Running the project with our plugin and without the warpath plugin works and vice versa. If I run the same configuration with maven 2.2.1, it works as expected. Also the plugin order is irrelevant. Is this a limitation of maven 2.0.*, or a bug or am I doing something wrong? I'm lost with this problem. Any hints are appreciated. Let me know, if some relevant information is missing. Please look into the POMs of the plugins and tell whether they declare a dependency to another plugin themselves. If yes, which ones? - Jörg - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Build a virtual machine using maven? A realistic idea?
What you could do is wrap vagrantup as a maven plugin: http://vagrantup.com/ Or implement a native java version, basically vagrant is a tool for creating virtual machine images from a base image, and can then provision artifacts inside the image using opscode chef. I've only been looking at the tool for a week or so but I'm already head over heals in love with it - now I just need to work out how to best utilize it :) Mark -- Pull me down under... 2010/4/15 Jimi Hullegård jimi.hulleg...@mogul.com: In the best of worlds I would be able to build a VM (in standard OVF format) just as easily as I now build a war- or ear-file. All our specific files and configuration would be under version control in SVN, and I would just add a dependency to a vanilla virtual machine (like Ubunto-64 version 9.10) and it would insert our file structure into the VM, almost like war-overlay works for web applications. And maybe some specific programs could be installed by the means of defining other dependencies. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
finalName in Ear plugin
What is the purpose of the finalName tag in the Ear plugin? Tim McGinnis 717 720-1962 Web Development AES/PHEAA == This message contains privileged and confidential information intended for the above addressees only. If you receive this message in error please delete or destroy this message and/or attachments. The sender of this message will fully cooperate in the civil and criminal prosecution of any individual engaging in the unauthorized use of this message. ==
Re: release:prepare ignores preparationGoals configuration in child of multi module project
The DefaultReleaseManager is a part of the maven-release-manager, if you look at the code in prepare(), you'll notice that it does not take preparationGoals from anything other than the root project into account.If you are looking at DefaultReleaseManager.java from the 2.0 branch the relevant line numbers are 203 and 199. So the answer is no, you can't customize in a submodule. I'm sure, with some effort you might be able to hack something into the ReleasePhase logic, but there's no point. Just configure the root project with clean install. Tim On Thu, Apr 15, 2010 at 4:28 AM, Raphael Ackermann raphael.ackerm...@gmail.com wrote: if I have a project structure like below: project-root + --- project-a + --- project-b + --- project-c and in project-root I have plugin artifactIdmaven-release-plugin/artifactId /plugin and in project-b I have plugin artifactIdmaven-release-plugin/artifactId configuration preparationGoalsclean install/preparationGoals /configuration /plugin when I run mvn release:prepare (mvn 2.2.1) in the project-root directory I see [INFO] [INFO] Building project-b [INFO] [INFO] task-segment: [clean, verify] and the build fails because project-c needs an artifact that gets generated in project-b's install phase. If I change the setup and add the configuration of the clean install preparation goals into the parent pom project-root plugin artifactIdmaven-release-plugin/artifactId configuration preparationGoalsclean install/preparationGoals /configuration /plugin I can see the following output: [INFO] [INFO] Building project-b [INFO] [INFO] task-segment: [clean, install] and the project builds successfully. I would like to only build one child module with clean install to save time. Does the release plugin ignore all configuration in child modules and only uses the configuration from the module where it is run from? Or do I need to add some other configuration? Raphael - 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 2.0.10 with two plugins with custom packaging types
Am 15.04.2010 14:54, schrieb Jörg Schaible:
Hi Henrik,
Henrik Niehaus wrote:
Hi Maven users,
I'm having problems with two plugins, which both define a custom
packaging type. The packaging types are source-plugin and binary-plugin,
which are defined in a private maven plugin and warpath, which is
defined in the warpath plugin.
If I run the project with both plugins defined, only the first plugin
seems to be taken into account. E.g. if our private plugin is defined
above the warputh plugin, source-plugin and binary-plugin can be
resolved and warpath cannot be resolved. Same thing vice versa, if the
warputh plugin is defined above out plugin, warpath can be resolved,
source-plugin and binary-plugin not.
Plugins are defined this way:
plugin
groupIdcom.company/groupId
artifactIdmaven-rcpbuild-plugin/artifactId
version1.0.3/version
extensionstrue/extensions
/plugin
plugin
groupIdorg.appfuse/groupId
artifactIdmaven-warpath-plugin/artifactId
version2.0.2/version
extensionstrue/extensions
executions
execution
goals
goaladd-classes/goal
/goals
/execution
/executions
/plugin
Running the project with our plugin and without the warpath plugin works
and vice versa.
If I run the same configuration with maven 2.2.1, it works as expected.
Also the plugin order is irrelevant.
Is this a limitation of maven 2.0.*, or a bug or am I doing something
wrong? I'm lost with this problem. Any hints are appreciated.
Let me know, if some relevant information is missing.
Please look into the POMs of the plugins and tell whether they declare a
dependency to another plugin themselves. If yes, which ones?
- Jörg
Hi Jörg,
thanks for your answer. A colleague of mine seems to have better google
skills than me and found ticket MNG-3506 a minute ago, which seems to be
my problem. I have to wait until JIRA is back online to test the
attached projects, but I think that is the problem.
Nevertheless here are the plugin dependencies:
warpath dependencies:
* org.apache.maven:maven-plugin-api:2.0.4
* org.apache.maven:maven-project:2.0.4
* org.apache.maven:maven-artifact:2.0.4
* org.apache.maven:maven-core:2.0.4
* org.codehaus.plexus:plexus-utils:1.1
* org.codehaus.plexus:plexus-utils:1.4.1
* junit:junit:${junit.version}:test
* maven-plugin-plugin (for reporting)
private plugin:
* org.apache.maven:maven-project:2.0.10
* org.apache.maven:maven-archiver:2.2
* ant:ant:1.6.5
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 2.0.10 with two plugins with custom packaging types
Hi Henrik,
Henrik Niehaus wrote:
Am 15.04.2010 14:54, schrieb Jörg Schaible:
[snip]
Please look into the POMs of the plugins and tell whether they declare a
dependency to another plugin themselves. If yes, which ones?
- Jörg
Hi Jörg,
thanks for your answer. A colleague of mine seems to have better google
skills than me and found ticket MNG-3506 a minute ago, which seems to be
my problem. I have to wait until JIRA is back online to test the
attached projects, but I think that is the problem.
Nevertheless here are the plugin dependencies:
warpath dependencies:
* org.apache.maven:maven-plugin-api:2.0.4
* org.apache.maven:maven-project:2.0.4
* org.apache.maven:maven-artifact:2.0.4
* org.apache.maven:maven-core:2.0.4
* org.codehaus.plexus:plexus-utils:1.1
* org.codehaus.plexus:plexus-utils:1.4.1
* junit:junit:${junit.version}:test
* maven-plugin-plugin (for reporting)
private plugin:
* org.apache.maven:maven-project:2.0.10
* org.apache.maven:maven-archiver:2.2
* ant:ant:1.6.5
I'd expect such effects also from plugins that derive from other ones.
However, that's not the case here. As workaround for MNG-3506 you might
simply share a common parent POM (note, that does not have to be physically
located in a parent directory, but is an artifact on its own), that declares
both plugins in the depMgmt section.
- Jörg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 2.0.10 with two plugins with custom packaging types
Am 15.04.2010 15:40, schrieb Jörg Schaible:
Hi Henrik,
Henrik Niehaus wrote:
Am 15.04.2010 14:54, schrieb Jörg Schaible:
[snip]
Please look into the POMs of the plugins and tell whether they declare a
dependency to another plugin themselves. If yes, which ones?
- Jörg
Hi Jörg,
thanks for your answer. A colleague of mine seems to have better google
skills than me and found ticket MNG-3506 a minute ago, which seems to be
my problem. I have to wait until JIRA is back online to test the
attached projects, but I think that is the problem.
Nevertheless here are the plugin dependencies:
warpath dependencies:
* org.apache.maven:maven-plugin-api:2.0.4
* org.apache.maven:maven-project:2.0.4
* org.apache.maven:maven-artifact:2.0.4
* org.apache.maven:maven-core:2.0.4
* org.codehaus.plexus:plexus-utils:1.1
* org.codehaus.plexus:plexus-utils:1.4.1
* junit:junit:${junit.version}:test
* maven-plugin-plugin (for reporting)
private plugin:
* org.apache.maven:maven-project:2.0.10
* org.apache.maven:maven-archiver:2.2
* ant:ant:1.6.5
I'd expect such effects also from plugins that derive from other ones.
However, that's not the case here. As workaround for MNG-3506 you might
simply share a common parent POM (note, that does not have to be physically
located in a parent directory, but is an artifact on its own), that declares
both plugins in the depMgmt section.
Could you please describe this more detailed? Which artifacts have to
have a common parent pom with depMgmt section?
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: release:prepare ignores preparationGoals configuration in child of multi module project
Thanks for the answer. How could I have found out from the existing documentation on [1] It says Attributes: Requires a Maven 2.0 project to be executed. Executes as an aggregator plugin. Does the Executes as an aggregator plugin means that it will only take the root project into account? If so, that should be made clearer as this doesn't mean much to me. googling I found many plugins with this Executes as an aggregator plugin. attribute, but I couldn't find information on what it means. There is also no reference to an aggregator plugin in the maven-by-example or maven-complete-reference pdf books. [1] http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html Raphael On Thu, Apr 15, 2010 at 15:16, Tim O'Brien tobr...@discursive.com wrote: The DefaultReleaseManager is a part of the maven-release-manager, if you look at the code in prepare(), you'll notice that it does not take preparationGoals from anything other than the root project into account. If you are looking at DefaultReleaseManager.java from the 2.0 branch the relevant line numbers are 203 and 199. So the answer is no, you can't customize in a submodule. I'm sure, with some effort you might be able to hack something into the ReleasePhase logic, but there's no point. Just configure the root project with clean install. Tim On Thu, Apr 15, 2010 at 4:28 AM, Raphael Ackermann raphael.ackerm...@gmail.com wrote: if I have a project structure like below: project-root + --- project-a + --- project-b + --- project-c and in project-root I have plugin artifactIdmaven-release-plugin/artifactId /plugin and in project-b I have plugin artifactIdmaven-release-plugin/artifactId configuration preparationGoalsclean install/preparationGoals /configuration /plugin when I run mvn release:prepare (mvn 2.2.1) in the project-root directory I see [INFO] [INFO] Building project-b [INFO] [INFO] task-segment: [clean, verify] and the build fails because project-c needs an artifact that gets generated in project-b's install phase. If I change the setup and add the configuration of the clean install preparation goals into the parent pom project-root plugin artifactIdmaven-release-plugin/artifactId configuration preparationGoalsclean install/preparationGoals /configuration /plugin I can see the following output: [INFO] [INFO] Building project-b [INFO] [INFO] task-segment: [clean, install] and the project builds successfully. I would like to only build one child module with clean install to save time. Does the release plugin ignore all configuration in child modules and only uses the configuration from the module where it is run from? Or do I need to add some other configuration? Raphael - 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: release:prepare ignores preparationGoals configuration in child of multi module project
On Thu, Apr 15, 2010 at 9:06 AM, Raphael Ackermann raphael.ackerm...@gmail.com wrote: Thanks for the answer. How could I have found out from the existing documentation on [1] Right, you couldn't, that's why I had to go look at the ReleaseManager source code to verify. In general, the Release plugin is very useful, but the documentation doesn't do it justice. I sense that the frustration quotient* for the Release Plugin is very high. *Frustration Quotient is defined by (promise of plugin * necessity of plugin) / (amount of sane documentation) It says Attributes: Requires a Maven 2.0 project to be executed. Executes as an aggregator plugin. Does the Executes as an aggregator plugin means that it will only take the root project into account? If so, that should be made clearer as this doesn't mean much to me. googling I found many plugins with this Executes as an aggregator plugin. attribute, but I couldn't find information on what it means. There is also no reference to an aggregator plugin in the maven-by-example or maven-complete-reference pdf books. I'll file a JIRA for those two books... there WTF is an aggregator plugin? - https://issues.sonatype.org/browse/MVNREF-144 [1] http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html Raphael On Thu, Apr 15, 2010 at 15:16, Tim O'Brien tobr...@discursive.com wrote: The DefaultReleaseManager is a part of the maven-release-manager, if you look at the code in prepare(), you'll notice that it does not take preparationGoals from anything other than the root project into account. If you are looking at DefaultReleaseManager.java from the 2.0 branch the relevant line numbers are 203 and 199. So the answer is no, you can't customize in a submodule. I'm sure, with some effort you might be able to hack something into the ReleasePhase logic, but there's no point. Just configure the root project with clean install. Tim On Thu, Apr 15, 2010 at 4:28 AM, Raphael Ackermann raphael.ackerm...@gmail.com wrote: if I have a project structure like below: project-root + --- project-a + --- project-b + --- project-c and in project-root I have plugin artifactIdmaven-release-plugin/artifactId /plugin and in project-b I have plugin artifactIdmaven-release-plugin/artifactId configuration preparationGoalsclean install/preparationGoals /configuration /plugin when I run mvn release:prepare (mvn 2.2.1) in the project-root directory I see [INFO] [INFO] Building project-b [INFO] [INFO] task-segment: [clean, verify] and the build fails because project-c needs an artifact that gets generated in project-b's install phase. If I change the setup and add the configuration of the clean install preparation goals into the parent pom project-root plugin artifactIdmaven-release-plugin/artifactId configuration preparationGoalsclean install/preparationGoals /configuration /plugin I can see the following output: [INFO] [INFO] Building project-b [INFO] [INFO] task-segment: [clean, install] and the project builds successfully. I would like to only build one child module with clean install to save time. Does the release plugin ignore all configuration in child modules and only uses the configuration from the module where it is run from? Or do I need to add some other configuration? Raphael - 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: Maven 2.0.10 with two plugins with custom packaging types
Hi Henrik,
Henrik Niehaus wrote:
Am 15.04.2010 15:40, schrieb Jörg Schaible:
Hi Henrik,
Henrik Niehaus wrote:
Am 15.04.2010 14:54, schrieb Jörg Schaible:
[snip]
Please look into the POMs of the plugins and tell whether they declare
a dependency to another plugin themselves. If yes, which ones?
- Jörg
Hi Jörg,
thanks for your answer. A colleague of mine seems to have better google
skills than me and found ticket MNG-3506 a minute ago, which seems to be
my problem. I have to wait until JIRA is back online to test the
attached projects, but I think that is the problem.
Nevertheless here are the plugin dependencies:
warpath dependencies:
* org.apache.maven:maven-plugin-api:2.0.4
* org.apache.maven:maven-project:2.0.4
* org.apache.maven:maven-artifact:2.0.4
* org.apache.maven:maven-core:2.0.4
* org.codehaus.plexus:plexus-utils:1.1
* org.codehaus.plexus:plexus-utils:1.4.1
* junit:junit:${junit.version}:test
* maven-plugin-plugin (for reporting)
private plugin:
* org.apache.maven:maven-project:2.0.10
* org.apache.maven:maven-archiver:2.2
* ant:ant:1.6.5
I'd expect such effects also from plugins that derive from other ones.
However, that's not the case here. As workaround for MNG-3506 you might
simply share a common parent POM (note, that does not have to be
physically located in a parent directory, but is an artifact on its own),
that declares both plugins in the depMgmt section.
Could you please describe this more detailed? Which artifacts have to
have a common parent pom with depMgmt section?
Sorry, I mean in this case the pluginMgmt section.
Typically you define one parent POM for your complete project where you use
the depenencyManagement section to define the versions (and standard scopes)
of all your dependencies and a pluginManagement section with all plugins
used in this project again with versions and configuration shared everywhere
they are in use. This project POM is directly or indirectly inherited by all
your POMs within this project. Then you do not have to define anywhere a
version for a plugin (well, not for the plugins in the report sections, but
that's a different story) or dependency.
In the pluginManagement section you will also define any additional
dependency for the individual plugins (e.g. custom tasks for the antrun-
plugin or additional wagon providers) and also set the extension flag for
the plugins with custom extensions. Remember, each plugin can be loaded only
once and the first activation will also define its classpath.
- Jörg
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: [ANN] New repository search site - srchmvn.com
Justin, I'm actually rsync'ing *.pom off one of the mirrors (I think I used ibiblio). I'm not running the rsync very often at the moment as performance seems to fluctuate quite a bit. I'm open to any suggestions/ideas about improving this, but this seemed like the easiest way to get going at the time. chetan On Fri, Apr 9, 2010 at 9:26 AM, Justin Edelson justinedel...@gmail.com wrote: Chetan- One thing I noticed in the blog entry is that you ran into trouble parsing the POM file. This indicates that you are crawling central. Is this true? Justin On 4/8/10 11:38 PM, Chetan Sarva wrote: Yep, it's just the central repo for now. Haven't needed to use any others in my last few projects, but I could add support if people requested it. Showing some more info in various places is on my todo list though. chetan On Thu, Apr 8, 2010 at 8:58 AM, Adam Leggett adam.legg...@upco.co.uk wrote: Nice one. Can never have too many web-based Maven repository search apps :). Are you just searching the central repo? If not, a brief google-esque summary attached to each search result item indicating where the artefact is located would be handy. Regards Adam On Thu, 2010-04-08 at 08:44 -0400, Chetan Sarva wrote: Hey all, I've just launched yet another Maven repository search app at http://srchmvn.com/ It tries to return more relevant results than the other versions I've seen out there. You can find more details in this blog post if you're interested - http://www.chetanislazy.com/blog/2010/03/30/launching-srchmvn/ I'd very much appreciate any and all feedback. regards, chetan - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Adam Leggett Chief Architect Mike CI - Hosted Continuous Integration http://mikeci.com https://twitter.com/builtbyadam - 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
Cannot find wagon... for ftp
Hi, Please reply directly as I'm not subscribed; thanks. I've read a hundred web postings and I'm still stuck. I just established an ftp repository and can't access it. My pom includes: build extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-ftp/artifactId /extension /extensions And later: dependencies dependency groupIdcom.mysql.clusterj/groupId artifactIdclusterj-api/artifactId version7.1.3/version scopecompile/scope /dependency I put this into my settings.xml: profile idmysql-repo/id activationactiveByDefaulttrue/activeByDefault/ activation repositories repository idMySQL FTP/id urlftp://ftp.mysql.com/pub/mysql/maven-repo/url /repository /repositories /profile From the above, I downloaded the wagon-ftp which I guess is still in beta release: repository metadata for: 'artifact org.apache.maven.wagon:wagon-ftp' could not be retrieved from repository: MySQL FTP due to an error: Unsupported Protocol: 'ftp': Cannot find wagon which supports the requested protocol: ftp [INFO] Repository 'MySQL FTP' will be blacklisted [INFO] artifact org.apache.maven.wagon:wagon-ftp: checking for updates from central Downloading: http://repo1.maven.org/maven2/org/apache/maven/wagon/wagon-ftp/1.0-beta-6/wagon-ftp-1.0-beta-6.pom Downloading: http://repo1.maven.org/maven2/org/apache/maven/wagon/wagon-providers/1.0-beta-6/wagon-providers-1.0-beta-6.pom Downloading: http://repo1.maven.org/maven2/commons-net/commons-net/2.0/commons-net-2.0.pom Downloading: http://repo1.maven.org/maven2/commons-net/commons-net/2.0/commons-net-2.0.jar Downloading: http://repo1.maven.org/maven2/org/apache/maven/wagon/wagon-ftp/1.0-beta-6/wagon-ftp-1.0-beta-6.jar But after downloading wagon-ftp and its dependency it still fails. So I copied the two jars to ~/.m2/lib and it still fails. clr% ls -l ~/.m2/lib total 16 lrwxr-xr-x 1 clr staff 61 Apr 15 14:49 commons-net-2.0.jar - ../ repository/commons-net/commons-net/2.0/commons-net-2.0.jar lrwxr-xr-x 1 clr staff 82 Apr 15 14:47 wagon-ftp-1.0-beta-6.jar - ../repository/org/apache/maven/wagon/wagon-ftp/1.0-beta-6/wagon- ftp-1.0-beta-6.jar clr% mvn install [INFO] Scanning for projects... [INFO] artifact org.apache.maven.wagon:wagon-ftp: checking for updates from MySQL FTP [WARNING] repository metadata for: 'artifact org.apache.maven.wagon:wagon-ftp' could not be retrieved from repository: MySQL FTP due to an error: Unsupported Protocol: 'ftp': Cannot find wagon which supports the requested protocol: ftp [INFO] Repository 'MySQL FTP' will be blacklisted [INFO] [INFO] Building ClusterJ Core [INFO]task-segment: [install] [INFO] Downloading: http://repo1.maven.org/maven2/com/mysql/clusterj/clusterj-api/7.1.3/clusterj-api-7.1.3.pom [INFO] Unable to find resource 'com.mysql.clusterj:clusterj-api:pom: 7.1.3' in repository central (http://repo1.maven.org/maven2) Downloading: http://repo1.maven.org/maven2/com/mysql/clusterj/clusterj-api/7.1.3/clusterj-api-7.1.3.jar [INFO] Unable to find resource 'com.mysql.clusterj:clusterj-api:jar: 7.1.3' in repository central (http://repo1.maven.org/maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. So I took out the extensions from the build to avoid blacklisting my MySQL FTP repository and still get this: clr% mvn install [INFO] Scanning for projects... [INFO] [INFO] Building ClusterJ Core [INFO]task-segment: [install] [INFO] [WARNING] Unable to get resource 'com.mysql.clusterj:clusterj-api:pom: 7.1.3' from repository MySQL FTP (ftp://ftp.mysql.com/pub/mysql/maven-repo ): Unsupported Protocol: 'ftp': Cannot find wagon which supports the requested protocol: ftp Downloading: http://repo1.maven.org/maven2/com/mysql/clusterj/clusterj-api/7.1.3/clusterj-api-7.1.3.pom [INFO] Unable to find resource 'com.mysql.clusterj:clusterj-api:pom: 7.1.3' in repository central (http://repo1.maven.org/maven2) [WARNING] Unable to get resource 'com.mysql.clusterj:clusterj-api:jar: 7.1.3' from repository MySQL FTP (ftp://ftp.mysql.com/pub/mysql/maven-repo ): Unsupported Protocol: 'ftp': Cannot find wagon which supports the requested protocol: ftp Downloading: http://repo1.maven.org/maven2/com/mysql/clusterj/clusterj-api/7.1.3/clusterj-api-7.1.3.jar [INFO] Unable to find resource 'com.mysql.clusterj:clusterj-api:jar: 7.1.3' in repository central
Re: Cannot find wagon... for ftp
oro-2.0.8.jar I think you need that as well -Dan On Thu, Apr 15, 2010 at 4:27 PM, Craig L Russell craig.russ...@oracle.com wrote: Hi, Please reply directly as I'm not subscribed; thanks. I've read a hundred web postings and I'm still stuck. I just established an ftp repository and can't access it. My pom includes: build extensions extension groupIdorg.apache.maven.wagon/groupId artifactIdwagon-ftp/artifactId /extension /extensions And later: dependencies dependency groupIdcom.mysql.clusterj/groupId artifactIdclusterj-api/artifactId version7.1.3/version scopecompile/scope /dependency I put this into my settings.xml: profile idmysql-repo/id activationactiveByDefaulttrue/activeByDefault/activation repositories repository idMySQL FTP/id urlftp://ftp.mysql.com/pub/mysql/maven-repo/url /repository /repositories /profile From the above, I downloaded the wagon-ftp which I guess is still in beta release: repository metadata for: 'artifact org.apache.maven.wagon:wagon-ftp' could not be retrieved from repository: MySQL FTP due to an error: Unsupported Protocol: 'ftp': Cannot find wagon which supports the requested protocol: ftp [INFO] Repository 'MySQL FTP' will be blacklisted [INFO] artifact org.apache.maven.wagon:wagon-ftp: checking for updates from central Downloading: http://repo1.maven.org/maven2/org/apache/maven/wagon/wagon-ftp/1.0-beta-6/wagon-ftp-1.0-beta-6.pom Downloading: http://repo1.maven.org/maven2/org/apache/maven/wagon/wagon-providers/1.0-beta-6/wagon-providers-1.0-beta-6.pom Downloading: http://repo1.maven.org/maven2/commons-net/commons-net/2.0/commons-net-2.0.pom Downloading: http://repo1.maven.org/maven2/commons-net/commons-net/2.0/commons-net-2.0.jar Downloading: http://repo1.maven.org/maven2/org/apache/maven/wagon/wagon-ftp/1.0-beta-6/wagon-ftp-1.0-beta-6.jar But after downloading wagon-ftp and its dependency it still fails. So I copied the two jars to ~/.m2/lib and it still fails. clr% ls -l ~/.m2/lib total 16 lrwxr-xr-x 1 clr staff 61 Apr 15 14:49 commons-net-2.0.jar - ../repository/commons-net/commons-net/2.0/commons-net-2.0.jar lrwxr-xr-x 1 clr staff 82 Apr 15 14:47 wagon-ftp-1.0-beta-6.jar - ../repository/org/apache/maven/wagon/wagon-ftp/1.0-beta-6/wagon-ftp-1.0-beta-6.jar clr% mvn install [INFO] Scanning for projects... [INFO] artifact org.apache.maven.wagon:wagon-ftp: checking for updates from MySQL FTP [WARNING] repository metadata for: 'artifact org.apache.maven.wagon:wagon-ftp' could not be retrieved from repository: MySQL FTP due to an error: Unsupported Protocol: 'ftp': Cannot find wagon which supports the requested protocol: ftp [INFO] Repository 'MySQL FTP' will be blacklisted [INFO] [INFO] Building ClusterJ Core [INFO] task-segment: [install] [INFO] Downloading: http://repo1.maven.org/maven2/com/mysql/clusterj/clusterj-api/7.1.3/clusterj-api-7.1.3.pom [INFO] Unable to find resource 'com.mysql.clusterj:clusterj-api:pom:7.1.3' in repository central (http://repo1.maven.org/maven2) Downloading: http://repo1.maven.org/maven2/com/mysql/clusterj/clusterj-api/7.1.3/clusterj-api-7.1.3.jar [INFO] Unable to find resource 'com.mysql.clusterj:clusterj-api:jar:7.1.3' in repository central (http://repo1.maven.org/maven2) [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. So I took out the extensions from the build to avoid blacklisting my MySQL FTP repository and still get this: clr% mvn install [INFO] Scanning for projects... [INFO] [INFO] Building ClusterJ Core [INFO] task-segment: [install] [INFO] [WARNING] Unable to get resource 'com.mysql.clusterj:clusterj-api:pom:7.1.3' from repository MySQL FTP (ftp://ftp.mysql.com/pub/mysql/maven-repo): Unsupported Protocol: 'ftp': Cannot find wagon which supports the requested protocol: ftp Downloading: http://repo1.maven.org/maven2/com/mysql/clusterj/clusterj-api/7.1.3/clusterj-api-7.1.3.pom [INFO] Unable to find resource 'com.mysql.clusterj:clusterj-api:pom:7.1.3' in repository central (http://repo1.maven.org/maven2) [WARNING] Unable to get resource 'com.mysql.clusterj:clusterj-api:jar:7.1.3' from repository MySQL FTP (ftp://ftp.mysql.com/pub/mysql/maven-repo): Unsupported Protocol: 'ftp': Cannot find wagon which supports the requested protocol: ftp Downloading:
Re: Cannot find wagon... for ftp
On 16/04/2010, at 9:27 AM, Craig L Russell wrote: From the above, I downloaded the wagon-ftp which I guess is still in beta release: repository metadata for: 'artifact org.apache.maven.wagon:wagon-ftp' could not be retrieved from repository: MySQL FTP due to an error: Unsupported Protocol: 'ftp': Cannot find wagon which supports the requested protocol: ftp [INFO] Repository 'MySQL FTP' will be blacklisted I think there is a known JIRA issue for this, at least in 2.2.1. It's always going to look for the release metadata from that repository, fail because the wagon isn't set up yet, then blacklist it. Chicken and egg. So two questions: 1. Is ftp support for repositories planned to be a standard feature (no special wagons needed) at some point? I really don't want to have to explain to every user out there how to configure an ftp wagon. No, demand has been very low for it as far as I can tell. 2. What did I do wrong? If you add the wagon version to the POM, the build will work fine. - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Cannot find wagon... for ftp
On Apr 15, 2010, at 4:27 PM, Craig L Russell wrote: So two questions: 1. Is ftp support for repositories planned to be a standard feature (no special wagons needed) at some point? I really don't want to have to explain to every user out there how to configure an ftp wagon. No. The last time we asked users it was ~98%+ HTTP/S. It's not worth supporting any other transport. P2 at Eclipse is also all HTTP/S. If you need it internally just ship it with an internal distribution of Maven and you should be good. 2. What did I do wrong? Thanks, Craig Craig L Russell Architect, Oracle http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@oracle.com P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --
