Re: Maven Release Plugin
Hello again. In my usecase all submodules SHOULD include a common set of dependencies. The submodules have no dependencies to other submodules. Thats why declaring the dependencies in the parent pom. The configuration option autoVersionSubmodulestrue/autoVersionSubmodules is only responsible to auto update the parent of all submodules. Independent from whether declaring the dependencies in the parent or in the submodules the plugin should reuse dependency version mappings once entered by the user for all subsequent/dependent modules. If it finds a unmapped artifact/version in a module it can prompt the user for it and reuse this mapping for the whole process without prompting again. This behavior should work for all usecases, shouln't it? Marcus Maven Users List users@maven.apache.org writes: The previous replies seem to miss the mark, your set up sounds good to me. The missing configuration you are looking for is: configuration autoVersionSubmodulestrue/autoVersionSubmodules /configuration Kalle On Thu, Sep 16, 2010 at 8:07 AM, Marcus Linke li...@newsaktuell.de wrote: Hello, i 've the following problem releasing a multi-module project with the maven-release-plugin (Version 2.0). The top (parent) pom-style project defines a set of snapshot dependencies that are inherited to all of its submodules. When using the release plugin in interactive mode, the plugin prompts for the new versions of these snapshot dependencies. So far, so good. But when diving into the submodules this is repeated for each module again. This is really annoying me because i have 20 submodules in that project. Is this is a know problem or a type of misconfiguration. Thanks Marcus Linke - 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 Mit freundlichen Grüßen Marcus Linke -- Softwareentwicklung, IT news aktuell GmbH - Ein Unternehmen der dpa-Gruppe Mittelweg 144, 20148 Hamburg Tel: +49 (0)40-4113-2588 Fax: +49 (0)40-4113-2595 www.newsaktuell.de www.presseportal.de www.newsaktuell.de/blog www.twitter.com/newsaktuell www.youtube.com/newsaktuell www.facebook.com/pages/newsaktuell/152372075544 www.friendfeed.com/newsaktuell -- Registergericht: Hamburg, Registernummer: HRB 42 738 Umsatzsteuer-Identifikationsnummer gemäß § 27 a Umsatzsteuergesetz: DE118617411 Vertretungsberechtigte Personen: Carl-Eduard Meyer (Geschäftsführer), Frank Stadthoewer (Geschäftsführer) - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Help in build multiple source folder and placing it under respective parent strucutre in /target/classes
Dear All, I am just a beginner with maven 2.0. I am trying to build a maven project with some customized folder. .i.e As follows Simple - pom.xml - src - main - java - org - simple - com - test.java - folder1 -folder2 - hello.java I want maven to build these files and place them to the respective classes directory - Target - classes - org - simple - com - test.class - folder1 -folder2 -hello.class Can anyone please help me on this. Thanks in advance.
Re: How to put classes in a directory of your choice in a jar
Laurent, This was very useful. Can you help me out in placing classes to a directory same as parent under target/classes Say i have src/main/java/com/company/app/a.java to be placed under target/classes/com/company/app/a.class I can work out for anything under app but what if i have the below src/main/java/newfolder/company/java/b.java When i try to include the former source path it throws an error duplicate tag build. Can you please help me out. I am not build and release engineer and new to maven. -- View this message in context: http://maven.40175.n5.nabble.com/How-to-put-classes-in-a-directory-of-your-choice-in-a-jar-tp2256100p2842745.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: Help in build multiple source folder and placing it under respective parent strucutre in /target/classes
I don't understand what you want to customize, but I want to advice you to don't fight Maven. Use the standards and your development life will be so much easier. /Anders On Thu, Sep 16, 2010 at 20:03, Amit Moses ami...@hotmail.com wrote: Dear All, I am just a beginner with maven 2.0. I am trying to build a maven project with some customized folder. .i.e As follows Simple - pom.xml - src - main - java - org - simple - com - test.java - folder1 -folder2 - hello.java I want maven to build these files and place them to the respective classes directory - Target - classes - org - simple - com - test.class - folder1 -folder2 -hello.class Can anyone please help me on this. Thanks in advance.
Re: Buildmanagement-Strategy
Nayan Hajratwala wrote: On Sep 16, 2010, at 12:31 PM, Stefan Schulze wrote: Sadly it's not simply done by the proper maven strategy - it has to correlate to the SCM and some internal processes. :( Ahh -- the infamous internal processes. Perhaps you might find some help with that part of it over on the Scrum Development list http://groups.yahoo.com/group/scrumdevelopment/ :-) I think these processes are just the smaller part of the problem. The big one is the integration with the SCM, I think. Maven is a great tool to fullfill the first requirement, but the SCM is another important tool. And this is, what I'm worried about. :-) Stefan -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [PLEASE TEST] Apache Maven 3.0-RC1
Hi guys, so far so good, but I've found something little odd. I have reporting plugins preconfigured in pluginManagement section of parent pom and I've noticed that this configuration is used only when building parent and is not inherited into child projects and has to be configured explicitly again. Version of plugin is inherited. Is it intentional? Martin - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Maven dependency library versioning issue
Thanks Nayan. I used Maven2 plugin inside eclipse Helios which gives you an option 'Use Maven dependencies' and that is how I came to know that POI 2.5 is coming from JBPM. I used the mentioned exclusions syntax so that JBPM won't download the POI jar file but it does. So I wanted to confirm if I am using it in a right way or not. Please take a look at my pom.xml syntax in my last post and let me know if I am wrong. - Pradnya -Original Message- From: Nayan Hajratwala [mailto:na...@chikli.com] Sent: Thursday, September 16, 2010 5:32 PM To: Maven Users List Subject: Re: Maven dependency library versioning issue you might be getting POI from somewhere else. Check your dependency tree by running mvn dependency:tree. This will show you what transitive dependency POI is coming from. --- Nayan Hajratwala http://agileshrugged.com http://twitter.com/nhajratw 734.658.6032 On Sep 16, 2010, at 3:06 PM, Pradnya Gawade wrote: Thanks Antonio. I have tried following but it still it download POI 2.5 when compile my project. Is following correct for what I want to do? Is version needs to be mentioned some where? dependency groupIdorg.jbpm.jbpm3/groupId artifactIdjbpm-jpdl/artifactId version3.3.1.GA/version scopecompile/scope exclusions exclusion groupIdorg.apache.poi/groupId !-- Exclude apache poi -- artifactIdpoi/artifactId /exclusion /exclusions /dependency - Pradnya -Original Message- From: Antonio Petrelli [mailto:antonio.petre...@gmail.com] Sent: Thursday, September 16, 2010 2:28 PM To: Maven Users List Subject: Re: Maven dependency library versioning issue 2010/9/16 Pradnya Gawade pgaw...@akazaresearch.com: How can I make JBPM not to download POI 2.5 or how can make my application to use POI 3.5.6 and not POI 2.5? Use dependency exclusion: http://maven.apache.org/guides/introduction/introduction-to-optional-and -excludes-dependencies.html Antonio - 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 dependency library versioning issue
2010/9/17 Pradnya Gawade pgaw...@akazaresearch.com: Thanks Nayan. I used Maven2 plugin inside eclipse Helios which gives you an option I suppose you're using m2eclipse. Ensure you installed the Maven POM Editor so you can see the dependency graph. You can even exclude the dependency from the graph. It's a life-saver IMO :-) Antonio - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: Buildmanagement-Strategy
I can't help but feel that you have completely obfuscated a relatively basic need. It's like you have the right tools but the wrong implementation. Why doesn't storing your artifacts in Nexus also along with Maven POMs to specify the dependencies for each project work for you? Curt Yanko | Continuous Integration Services | UnitedHealth Group IT Making IT Happen, one build at a time -Original Message- From: Stefan Schulze [mailto:algr...@gmx.de] Sent: Thursday, September 16, 2010 10:49 AM To: users@maven.apache.org Subject: Buildmanagement-Strategy Hi, My problem is not really only about Maven, but more about a general buildmanagement-strategy using Maven. I didn't found a mailinglist or newsgroup dedicated for general buildmanagement-topics, so try to post my issue in this list. I'm quite new to buildmanagement and have to think about a concept to support the evolutionary architecture (or better evolutionary development of the architecture) we want to employ in the future of our product. After hours and days of considering and contemplating we found two possible solutions. Because both has serious drawbacks, I hope that anybody of you already knows this scenario/requirements (I think it's not too unusual) or has any suggestions to improve our solutions. The requirements: 1) It is neccessary to support different modules (WARs) depending on the same module (JAR) in different versions: For example, first we developed a module booking in version 1. Some common stuff is implemented in core (version 1, too), where booking-1 depends on. Some time after release our customer wants to have an reporting-module, so wie develop reporting-1 and implement some improvements to core (because during the last project and in the meantime we saw, that there some decisions weren't ideal). So reporting-1 depends on core-2. We do not want to upgrade booking-1 to use core-2, because in this case, booking would have to pass QA again (and the customer wouldn't pay this - there is no new feature). 2) It is neccessary, that it's possible to fix booking-1 or even core-1 (a bug in booking-1 is in core-1, in truth), although core-2 is the current version of core and booking-1 wouldn't even compile against core-2. The infrastructure: 1) We use Synergy/CM for version-control. For this case it's similar to Subversion with release-branch strategy. In opposite to Subversion, cheap and/or history-preserving copies are not supported. 2) We use Maven2 with an own Nexus-repository. Currently we use Maven and Nexus just to serve third-party-libs and to give the developers the possibility not to have to checkout the full source, but only these parts, they work with. So the repository isn't really part of releasing a new version of our system - we not even create a Release-version of our snapshots. The (possible) solutions: 1) In each module are additional directories for the different versions. Each version-directory contains quite the same code (differing only in the changes made between the versions): core- |-1-src-... |-2-src-... ... This doesn't feel rights. It's somehow ugly, we copy code and we have to merge bugfixes manually from one version to all others. But it's a quite simple solution to solve both requirements. 2) Each release-branch contains only the current version of code. The other versions are taken from the Maven-repository (in this case we have to use release-version and all the stuff). If a bugfix is core-1 is neccessary, a developer check-out the release-branch 1, implement the bugfix, start the build and calls a build- or release-manager to deploy the release-version to the repository. If it's time to go live with a new version, an appropriate assembly is built, which contains in parts of fresh compiled code and in parts of artifacts out of the the Maven-repository. At the detail, this is a quite complex approach. I don't really like, that we don't have a release-branch containing the full production-code - instead we would release a mixture of different release-branches. If any of you has some experience with similar requirements, has an idea for a different solution or an suggestion to improve the one or the other solution, I would really appreciate your ideas and comments. Thanks for reading all of this quite long mail. :-) Stefan -- GMX DSL SOMMER-SPECIAL: Surf Phone Flat 16.000 für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is
Re: Maven dependency library versioning issue
On Sep 17, 2010, at 9:27 AM, Pradnya Gawade wrote: Thanks Nayan. I used Maven2 plugin inside eclipse Helios which gives you an option 'Use Maven dependencies' and that is how I came to know that POI 2.5 is coming from JBPM. I used the mentioned exclusions syntax so that JBPM won't download the POI jar file but it does. but my point is that POI might be a transitive dependency of something else as well. run mvn dependency:tree from the command line to find out. You can also use the m2eclipse tools as Antonio points out, but I prefer to debug problems like this from the command line. So I wanted to confirm if I am using it in a right way or not. Please take a look at my pom.xml syntax in my last post and let me know if I am wrong. Your syntax looks fine, which is why i'm suggesting other ideas. Good luck! --- Nayan Hajratwala http://agileshrugged.com http://twitter.com/nhajratw 734.658.6032 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [PLEASE TEST] Apache Maven 3.0-RC1
Still not seeing the promised speed up when on a mac (and actually always a bit slower). But definitely seeing the improved times on a linux box (Linux 2.6.32-24-server #41-Ubuntu x86_64 GNU/Linux ) So it seems that if you are on a mac then be aware that upgrading to mvn 3 could at best give you the same build times as mvn 2 and at worst be a tad slower out of the box. If you run with -T options it seems to deliver on performance. The typical build times with mvn 2 are: Linux: Total time: 57 seconds (always 1m) Mac: Total time: 1 minute 11 seconds (usually around this time +-5 seconds) Initial build times using Apache Maven 3.0-RC1 (r997478; 2010-09-15 14:57:55-0500) Linux: Total time: 1:53.554s Mac: Total time: 1:56.945s Subsequent build times: Linux: Total time: 48.646s Mac: Total time: 1:20.053s I'm only added the last run of 3 from each since the runs were all pretty close. This was tested on 2 different macs but only 1 linux box (which is a hefty box so the times are a bit unfair towards the linux box). Running with -T 1c brings the mac builds under a minute (2 cores on the macs). Mac: Total time: 58.675s (Wall Clock) And an astounding 1/2 time builds on the linux box (8 cores) Linux: Total time: 32.193s (Wall Clock) On Wed, Sep 15, 2010 at 3:34 PM, Benjamin Bentmann benjamin.bentm...@udo.edu wrote: Hi, in preparation for the release of Apache Maven 3.0, the Maven team is seeking your help to discover regressions since Maven 2.x. Everybody interested in taking a preview of the upcoming release for a test drive can get source and binary bundles from this URL: https://repository.apache.org/content/repositories/maven-030/org/apache/maven/apache-maven/3.0-RC1/ Before reporting any issues found during testing, please be sure to have a close look at the compatibility notes for Maven 3.x: https://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Compatibility+Notes If you encounter unexpected build issues, please fill a report in JIRA that provides sufficient information to reproduce and analyze the issue: http://jira.codehaus.org/browse/MNG The fixes contained in this release candidate since the 3.0-beta-3 release can also be seen in JIRA: http://jira.codehaus.org/secure/ReleaseNote.jspa?atl_token=PRIR5ueW-iversion=13142styleName=TextprojectId=10500Create=Create Thanks, -The Maven team - 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
Update a BOM programmatically
Hello, I want to scan my scm repository, find new maven project and update another maven project used as BOM. What's the best way to add a new dependency management entry in an existing pom ? The purpose should fit with polyglot pom (but not mandatory). Thanks in advance Best regards, Vincent Hardion - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Res: Buildmanagement-Strategy
Hi Folks, That's a very intersting conversation. Regarding internal process, do you have such things as internal releases and external releases? If so, how do you manage your maven releases of releases and snapshots during the qualification cycles? Regards, Felipe Roos http://www.linkedin.com/in/feliperoos Achar desculpas para os nossos defeitos não nos torna melhores - Mensagem original De: Nayan Hajratwala na...@chikli.com Para: Maven Users List users@maven.apache.org Enviadas: Quinta-feira, 16 de Setembro de 2010 13:39:16 Assunto: Re: Buildmanagement-Strategy On Sep 16, 2010, at 12:31 PM, Stefan Schulze wrote: Sadly it's not simply done by the proper maven strategy - it has to correlate to the SCM and some internal processes. :( Ahh -- the infamous internal processes. Perhaps you might find some help with that part of it over on the Scrum Development list http://groups.yahoo.com/group/scrumdevelopment/ :-) Good luck! - 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
Maven3 RC1: Executing MojoExecutions with PluginManager
Hello, I developed a mojo that can be used to execute executions by id with their individual configuration. This is needed to execute plugins seperately if they are configured twice (i.e. the sql execute plugin) in a project. With maven 3 this is now broken because of an UnsupportedOperationException of the deprecated PluginManager. Here's what I do: - I run maven in a project, passing the execution ids to my mojo - the mojo is checking the project's plugins for their configured executions - If the plugin has an execution configured I want to execute: I retrieve the plugin descriptor using the PluginManager (verifyPlugin()) and the Configuration from the Execution and create a MojoExecution - I execute the MojoExecution(s) with the PluginManager (executeMojo()). And BAAM! this is throwing the UnsupportedOperationException Is there a way introduced by Maven3 to execute executions by id (so I can get rid of my own plugin)? Is there an alternative way to execute the MojoExecution? I tried BuildPluginManager but this just won't do either. Thanks, Steffen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [PLEASE TEST] Apache Maven 3.0-RC1
So now I've found most likely bug in site plugins configuration
In parent pom.xml
build.pluginManagement.plugins.plugin[maven-site-plugin].reportPlugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-changes-plugin/artifactId
reports
reportchanges-report/report
/reports
configuration
xmlPath${basedir}/src/changes.xml/xmlPath
/configuration
/plugin
plugin
groupIdde.smartics.maven.plugin/groupId
artifactIdmaven-buildmetadata-plugin/artifactId
reports
reportbuildmetadata-report/report
/reports
/plugin
If in child pom.xml
build.pluginManagement.plugins.plugin[maven-site-plugin].reportPlugins
plugin
groupIdde.smartics.maven.plugin/groupId
artifactIdmaven-buildmetadata-plugin/artifactId
!--
reports
reportbuildmetadata-report/report
/reports
--
/plugin
same maven-buildmetadata-plugin is without
reportbuildmetadata-report/report mvn site will fail
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-2:site
(default-site) on project komix-common: failed to
get Reports: Could not find goal changes-report in plugin
de.smartics.maven.plugin:maven-buildmetadata-plugin:1.1.0 among
available goals bu
ildmetadata-report, provide-buildmetadata, build-point - [Help 1]
So it tries to generate report from another plugin...
It fails in combinations:
parent in build.pluginManagement child in build.pluginManagement
parent in build.pluginManagement child in build.plugins
parent in build.plugins child in build.plugins
So it only works when:
parent in build.plugins child in build.pluginManagement because child
build.pluginManagement is completely ignored (and it is inherited) for
site plugin
Hi guys,
so far so good, but I've found something little odd.
I have reporting plugins preconfigured in pluginManagement section of
parent pom and I've noticed that this configuration is used only when
building parent and is not inherited into child projects and has to be
configured explicitly again. Version of plugin is inherited. Is it
intentional?
Martin
-
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: Maven3 RC1: Executing MojoExecutions with PluginManager
Hi, You can have a look at the site plugin 3.x branch [1] to understand how to do it. In the class DefaultMavenReportExecutor.java, you will see how to setup/prepare a mojo. [1] http://svn.apache.org/repos/asf/maven/plugins/branches/maven-site-plugin-3.x/ 2010/9/17 Steffen steffen.grunwald+so...@gmail.com: Hello, I developed a mojo that can be used to execute executions by id with their individual configuration. This is needed to execute plugins seperately if they are configured twice (i.e. the sql execute plugin) in a project. With maven 3 this is now broken because of an UnsupportedOperationException of the deprecated PluginManager. Here's what I do: - I run maven in a project, passing the execution ids to my mojo - the mojo is checking the project's plugins for their configured executions - If the plugin has an execution configured I want to execute: I retrieve the plugin descriptor using the PluginManager (verifyPlugin()) and the Configuration from the Execution and create a MojoExecution - I execute the MojoExecution(s) with the PluginManager (executeMojo()). And BAAM! this is throwing the UnsupportedOperationException Is there a way introduced by Maven3 to execute executions by id (so I can get rid of my own plugin)? Is there an alternative way to execute the MojoExecution? I tried BuildPluginManager but this just won't do either. Thanks, Steffen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Olivier http://twitter.com/olamy http://www.linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [PLEASE TEST] Apache Maven 3.0-RC1
Hi,
Here it's more a site plugin issue (looks related to
http://jira.codehaus.org/browse/MSITE-504 but needs to be more
investigated)
Can you record an issue with a simple project to reproduce ?
Thanks,
2010/9/17 Martin Vaněk antha...@post.cz:
So now I've found most likely bug in site plugins configuration
In parent pom.xml
build.pluginManagement.plugins.plugin[maven-site-plugin].reportPlugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-changes-plugin/artifactId
reports
reportchanges-report/report
/reports
configuration
xmlPath${basedir}/src/changes.xml/xmlPath
/configuration
/plugin
plugin
groupIdde.smartics.maven.plugin/groupId
artifactIdmaven-buildmetadata-plugin/artifactId
reports
reportbuildmetadata-report/report
/reports
/plugin
If in child pom.xml
build.pluginManagement.plugins.plugin[maven-site-plugin].reportPlugins
plugin
groupIdde.smartics.maven.plugin/groupId
artifactIdmaven-buildmetadata-plugin/artifactId
!--
reports
reportbuildmetadata-report/report
/reports
--
/plugin
same maven-buildmetadata-plugin is without
reportbuildmetadata-report/report mvn site will fail
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-2:site (default-site) on
project komix-common: failed to
get Reports: Could not find goal changes-report in plugin
de.smartics.maven.plugin:maven-buildmetadata-plugin:1.1.0 among available
goals bu
ildmetadata-report, provide-buildmetadata, build-point - [Help 1]
So it tries to generate report from another plugin...
It fails in combinations:
parent in build.pluginManagement child in build.pluginManagement
parent in build.pluginManagement child in build.plugins
parent in build.plugins child in build.plugins
So it only works when:
parent in build.plugins child in build.pluginManagement because child
build.pluginManagement is completely ignored (and it is inherited) for site
plugin
Hi guys,
so far so good, but I've found something little odd.
I have reporting plugins preconfigured in pluginManagement section of
parent pom and I've noticed that this configuration is used only when
building parent and is not inherited into child projects and has to be
configured explicitly again. Version of plugin is inherited. Is it
intentional?
Martin
-
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
--
Olivier
http://twitter.com/olamy
http://www.linkedin.com/in/olamy
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
RE: Deploy with SFTP tries to cd to parent too many times
I can't help wondering if this entire discussion is continuing because of semantics. I think you are talking about two uses of the word deploy. For a Maven Deploy a standard Maven repository is probably best. For a Production Deploy we must use whatever the production environment provides. If you are 'deploying' an artifact to be acquired by another Maven project then it is a Maven Deploy. If you are 'deploying' a product into a production environment (where it will execute, for example) it is a Production deploy. How can we de-obfuscate the word deploy that was overloaded by the Maven use? Also, consider the other overloaded words: package, install, validate, verify, etc. I suppose, on a Maven forum, the words should be used the Maven way. But ,then how do you ask about the other contexts? !-- Frank Gorham-Engard → Be kinder than necessary. Everyone is fighting some kind of battle. -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, September 06, 2010 5:12 PM To: users@maven.apache.org Subject: Re: Deploy with SFTP tries to cd to parent too many times On 06/09/2010 2:19 PM, Trevor Harmon wrote: On Sep 6, 2010, at 6:48 AM, Ron Wheeler wrote: Get Nexus up and running and start to enjoy using Maven. I'm sensing a theme here. Anybody reminded of that old joke? Doctor, it hurts when I move my arm like this. Doctor: Then don't move your arm like that. It is free. It is easy to install and configure. ... We are a small team of 3 but it was well worth the time to get it up and running. That you are a small team of 3 is very likely the reason why you found it easy to install and configure. I'm assuming one of you 3 set up the server yourself, correct? And had root access to it? Correct You probably didn't have to expose Nexus outside the firewall, either. No. We are a distributed operation. These are all advantages I'm lacking. I'm working remotely as an external contractor and have no control over the company's servers. And it doesn't help that I'm the only person using Maven in an all-Microsoft shop. Probably more trouble than its worth. Stick with Ant or use the Microsoft tools They'd have to integrate the Nexus server's user account management with Microsoft Active Directory. (Is that even possible?) And they'd also have to configure their firewall just for me so that I may access Nexus from the outside. They should know how to do this. I am not sure why you would bother with Active Directory for 1 person. Just use Nexus' authentication. This is a company with thousands of employees and a full-time IT security engineer; punching holes in their walls is not something they take lightly. In short, installing Nexus is by no means easy. But the company already happens to have a web server with SFTP access outside the firewall. They've given me an account on it. I'm simply trying to piggyback on this as a repository and use SFTP for deployment, since SFTP is a supported deployment method. So they do know how to expose services safely within their environment. Please correct me if I'm wrong about that. 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
[ANN] Maven Antrun Plugin 1.5 Released
The Maven team is pleased to announce the release of the Maven Antrun
Plugin, version 1.5
This plugin allows Ant tasks to be run within a Maven build. See the
plugin's site for more details:
http://maven.apache.org/plugins/maven-antrun-plugin/
You should specify the version in your project's plugin configuration:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-XXX-plugin/artifactId
version1.5/version
/plugin
Enjoy,
-The Maven team
Release Notes - Maven 2.x Antrun Plugin - Version 1.5
** Bug
* [MANTRUN-119] - copy task does not respect failonerror=false
* [MANTRUN-140] - project.build.outputDirectory property is invalid
* [MANTRUN-143] - Regression: 1.4 does not resolve
$(settings.localRepository} or ${localRepository}
** Improvement
* [MANTRUN-132] - Allow the antrun plugin to set the namespace for
the built in tasks.
* [MANTRUN-141] - Merge the AbstractAntMojo with the AntRunMojo
* [MANTRUN-142] - Refactor the tasks parameter to simplify
integration with Ant
* [MANTRUN-144] - Debug info being thrown in System.out.println
* [MANTRUN-145] - Rename ITs so that they describe what they test
* [MANTRUN-146] - Some refactoring seems to have broken the plugin
with Maven 3
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Deploy with SFTP tries to cd to parent too many times
I make the distinction where Maven deploys and putting something in production is provisioning. On Sep 17, 2010, at 2:25 PM, Gorham-Engard, Frank wrote: I can't help wondering if this entire discussion is continuing because of semantics. I think you are talking about two uses of the word deploy. For a Maven Deploy a standard Maven repository is probably best. For a Production Deploy we must use whatever the production environment provides. If you are 'deploying' an artifact to be acquired by another Maven project then it is a Maven Deploy. If you are 'deploying' a product into a production environment (where it will execute, for example) it is a Production deploy. How can we de-obfuscate the word deploy that was overloaded by the Maven use? Also, consider the other overloaded words: package, install, validate, verify, etc. I suppose, on a Maven forum, the words should be used the Maven way. But ,then how do you ask about the other contexts? !-- Frank Gorham-Engard → Be kinder than necessary. Everyone is fighting some kind of battle. -Original Message- From: Ron Wheeler [mailto:rwhee...@artifact-software.com] Sent: Monday, September 06, 2010 5:12 PM To: users@maven.apache.org Subject: Re: Deploy with SFTP tries to cd to parent too many times On 06/09/2010 2:19 PM, Trevor Harmon wrote: On Sep 6, 2010, at 6:48 AM, Ron Wheeler wrote: Get Nexus up and running and start to enjoy using Maven. I'm sensing a theme here. Anybody reminded of that old joke? Doctor, it hurts when I move my arm like this. Doctor: Then don't move your arm like that. It is free. It is easy to install and configure. ... We are a small team of 3 but it was well worth the time to get it up and running. That you are a small team of 3 is very likely the reason why you found it easy to install and configure. I'm assuming one of you 3 set up the server yourself, correct? And had root access to it? Correct You probably didn't have to expose Nexus outside the firewall, either. No. We are a distributed operation. These are all advantages I'm lacking. I'm working remotely as an external contractor and have no control over the company's servers. And it doesn't help that I'm the only person using Maven in an all-Microsoft shop. Probably more trouble than its worth. Stick with Ant or use the Microsoft tools They'd have to integrate the Nexus server's user account management with Microsoft Active Directory. (Is that even possible?) And they'd also have to configure their firewall just for me so that I may access Nexus from the outside. They should know how to do this. I am not sure why you would bother with Active Directory for 1 person. Just use Nexus' authentication. This is a company with thousands of employees and a full-time IT security engineer; punching holes in their walls is not something they take lightly. In short, installing Nexus is by no means easy. But the company already happens to have a web server with SFTP access outside the firewall. They've given me an account on it. I'm simply trying to piggyback on this as a repository and use SFTP for deployment, since SFTP is a supported deployment method. So they do know how to expose services safely within their environment. Please correct me if I'm wrong about that. 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 Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl - In short, man creates for himself a new religion of a rational and technical order to justify his work and to be justified in it. -- Jacques Ellul, The Technological Society
Issue with release:perform
On release:perform (after a successful release:prepare), two curious things happen with my multi-module project: *Every tag and branch and trunk item gets downloaded to my machine. Thus it takes a while. All I want is for the tag I just created to get released. *After everything is downloaded, a file called checkout is created in C:\myproject\parent\target, and this is the working directory. However, the release fails with this message, [INFO] [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xml, but the build is not using one. That's true of course because there is no pom in the target directory, but there can't be. The parent pom is in C:\myproject\parent\target\checkout\trunk\parent. How can I get release:perform to work faster and work with the structure I have described? Thanks.
Re: Issue with release:perform
Sounds like your probably a) using subversion and b) have your developerConection/ pom element pointing to say http://svn/myproject; rather than http://svn/myproject/trunk; this will then get maven to checkout TRUNK ( which should contain the pom.xml in its root directory ) and you should be good to go. -- Pull me down under... On Sat, Sep 18, 2010 at 10:38 AM, Neil Chaudhuri nchaudh...@potomacfusion.com wrote: On release:perform (after a successful release:prepare), two curious things happen with my multi-module project: *Every tag and branch and trunk item gets downloaded to my machine. Thus it takes a while. All I want is for the tag I just created to get released. *After everything is downloaded, a file called checkout is created in C:\myproject\parent\target, and this is the working directory. However, the release fails with this message, [INFO] [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xml, but the build is not using one. That's true of course because there is no pom in the target directory, but there can't be. The parent pom is in C:\myproject\parent\target\checkout\trunk\parent. How can I get release:perform to work faster and work with the structure I have described? Thanks.
RE: Issue with release:perform
You are correct on both counts. Before I run this, I have two questions: 1) Why do I want to append trunk when the version I want to release is in the tag I just prepared? 2) My parent pom is actually in a directory called parent beneath pom? So I presume I should do /svn/myproject/trunk/parent? Thanks. -Original Message- From: Mark Derricutt [mailto:m...@talios.com] Sent: Friday, September 17, 2010 6:45 PM To: Maven Users List Subject: Re: Issue with release:perform Sounds like your probably a) using subversion and b) have your developerConection/ pom element pointing to say http://svn/myproject; rather than http://svn/myproject/trunk; this will then get maven to checkout TRUNK ( which should contain the pom.xml in its root directory ) and you should be good to go. -- Pull me down under... On Sat, Sep 18, 2010 at 10:38 AM, Neil Chaudhuri nchaudh...@potomacfusion.com wrote: On release:perform (after a successful release:prepare), two curious things happen with my multi-module project: *Every tag and branch and trunk item gets downloaded to my machine. Thus it takes a while. All I want is for the tag I just created to get released. *After everything is downloaded, a file called checkout is created in C:\myproject\parent\target, and this is the working directory. However, the release fails with this message, [INFO] [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xml, but the build is not using one. That's true of course because there is no pom in the target directory, but there can't be. The parent pom is in C:\myproject\parent\target\checkout\trunk\parent. How can I get release:perform to work faster and work with the structure I have described? Thanks.
Dependency error when building ear file
-- Apologies in advance if this is a duplicate -- Hi -- ive been tasked with looking to see if maven will work to replace our current ant build. Since our company makes extensive use of j2ee and OC4J components, that was one of the first thingsI tackled after getting some basic modules to compile. In keeping with our existing ant build structure I setup the following tree structure: OC4J pom.xml | |--- OC4J.ear | |--- OC4J.rar | |--- OC4J.war The ear is setup with a dependancy on the war file. If goto the top level folder and run: mvn compile -- all is fine. no errors. but when I goto the top level folder and run: mvn package I get an error when building the ear file saying it cant find the war file: [ERROR] Failed to execute goal on project OC4J.ear: Could not resolve dependencies for project cdrive:OC4J.ear:ear:1.0: The following artifacts could not be resolved: cdrive:OC4J.war:war:1.0: Failure to find cdrive:OC4J.war:war:1.0 in http://repo1.maven.org/maven2 was cached in the local repository. Resolution will not be reattempted until the update interval of central has elapsed or updates are forced. - [Help 1] I started this endevor using maven 2.2.1 but I had the same problems with ear generation. searching led me to a post back from 2007 where somebody had the exact same problem, but there was no resolution posted. I was hoping maven 3.0 would fix the issue, but it just gives different error messages. So my questions are as follows: 1) Is there a better way to do this? -- if so it needs to scale well, the project has about 20 OC4J components. 2) if not, how do I fix the dependancies so this will work? 3) if neither... will this be fixed in maven 3.0?
RE: Issue with release:perform
I ended up trying both (/trunk and /trunk/parent), and I get the same result. I would imagine this is because: [INFO] Working directory: C:\myproject\parent\target That directory never has a pom in it. That just has the checkout directory in there, and then it is inside there all the fun starts. I am sure it is a small thing that remains for me to do, but I would love to know what that is. Thanks. -Original Message- From: Mark Derricutt [mailto:m...@talios.com] Sent: Friday, September 17, 2010 6:45 PM To: Maven Users List Subject: Re: Issue with release:perform Sounds like your probably a) using subversion and b) have your developerConection/ pom element pointing to say http://svn/myproject; rather than http://svn/myproject/trunk; this will then get maven to checkout TRUNK ( which should contain the pom.xml in its root directory ) and you should be good to go. -- Pull me down under... On Sat, Sep 18, 2010 at 10:38 AM, Neil Chaudhuri nchaudh...@potomacfusion.com wrote: On release:perform (after a successful release:prepare), two curious things happen with my multi-module project: *Every tag and branch and trunk item gets downloaded to my machine. Thus it takes a while. All I want is for the tag I just created to get released. *After everything is downloaded, a file called checkout is created in C:\myproject\parent\target, and this is the working directory. However, the release fails with this message, [INFO] [INFO] Cannot execute mojo: clean. It requires a project with an existing pom.xml, but the build is not using one. That's true of course because there is no pom in the target directory, but there can't be. The parent pom is in C:\myproject\parent\target\checkout\trunk\parent. How can I get release:perform to work faster and work with the structure I have described? Thanks.
