Re: Git settings for maven release plugin...
http://www.sonatype.com/people/2009/09/maven-tips-and-tricks-using-github/ using scm:git:git should do the trick. /Anders On Fri, 2013-03-22 at 00:10 +0100, Jeff wrote: scm connectionscm:git:ssh://g...@github.com:MyOrg/apps-thor.git/connection developerConnectionscm:git:ssh://g...@github.com:MyOrg/apps-thor.git/developerConnection urlg...@github.com:MyOrg/apps-thor.git/url /scm Am I missing something obvious? Regards!
Re: My view on the relative merits of different ways to unpack jars into target/classes
Hi! On 21 Mär 2013, Stephen Connolly wrote: I think mailing lists are not the best way to explain why different solutions are to be preferred when ranking against what is best for the Maven ecosystem as a whole. So I wrote a blog post to explain my views on what are good ways and what are bad ways. http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html Really good post, but... ;-) There is one thing that is IMHO not clearly (enough) stated in your post: it is in general a bad idea to add repositories to your POMs [1]. Section 2. Get the external jars into a public Maven repository adds an additional repository to the pom.xml. This is usually bad pratice and should be avoided. Brian Fox wrote a detailed blog post [1] about this. Maybe you could link to this post and mentione, that putting the additional repo in your settings.xml is an alternative. Thanks for your efforts for the maven community and hth, - martin [1] http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/ signature.asc Description: PGP signature
mvn release using local git repository
Hi! I'm having a problem with releasing one of our projects (multimodule). We've got the following structure: github: repository (no commit access) fork on github: forked repository (commit access) local server: git clone (bare) of fork on github local development machine: git clone of the repo on local server (Reason for this approach is that the whole team is using the same development version) As we want to be able to push changes from our local server back to github (through a pull request) we can not change the settings of the pom (the project on github uses different developerconnections, scmconnections, ...). Although we must be able to create new releases of our clone. I theory this should work with something like this if I understood the docs correctly: mvn release:prepare -Dproject.scm.developerConnection=scm:git:git@localserver:/home/git/repositories/ourproject -Dproject.scm.connection=scm:git:git@localserver :/home/git/repositories/ourproject This doesn't change the pom.xml though and doesn't seem to work as at the end it tries to push to github. I would guess that the pom.xml should be modified to the provided arguments in the created tag - but they are not. Please help.. Thanks :) Best regards, Bernhard Friedreich
Re: My view on the relative merits of different ways to unpack jars into target/classes
On 22 March 2013 08:12, Martin Höller mar...@xss.co.at wrote: Hi! On 21 Mär 2013, Stephen Connolly wrote: I think mailing lists are not the best way to explain why different solutions are to be preferred when ranking against what is best for the Maven ecosystem as a whole. So I wrote a blog post to explain my views on what are good ways and what are bad ways. http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html Really good post, but... ;-) There is one thing that is IMHO not clearly (enough) stated in your post: it is in general a bad idea to add repositories to your POMs [1]. Section 2. Get the external jars into a public Maven repository adds an additional repository to the pom.xml. This is usually bad pratice and should be avoided. Brian Fox wrote a detailed blog post [1] about this. Maybe you could link to this post and mentione, that putting the additional repo in your settings.xml is an alternative. Well if you put them into your settings.xml, then those extra repositories are applied for *every single project that you build* If you put them in your pom.xml, then those extra repositories are only applied for that project and *every single project that lists that project as a transitive dependency* Also putting them in your settings.xml means you cannot just checkout and build, putting them in your pom.xml allows most others to just checkout and build (except for those of us behind a corporate proxy with a mandated mirrorOf*/mirrorOf) Finally, putting them in your settings.xml allows reacting to repository location changes when building old builds, putting them in your pom.xml may mean that 1 year from now, checking out the tag will not build without modifying the pom.xml (or even worse, depending on the 1 year old version in a project your are building - you might want to verify a regression in behaviour for example - won't work because that version's pom.xml has invalid repository URLs) For all the above reasons, pushing OSS projects to central is the recommended practice, but getting them into any public Maven repository is better than not having them in a public Maven repository. TL;DR pushing open source projects to a repository other than Central (at least for the moment given how Maven works) is bad practice. Arguing over whether it is better to reference those other repositories from settings.xml or from pom.xml is very much like two fleas arguing over who will get squashed first when the building collapses and flattens the dog they live on ;-) Thanks for your efforts for the maven community and hth, - martin [1] http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
Re: My view on the relative merits of different ways to unpack jars into target/classes
+1 Nailed. It's not all black-or-white. On Fri, Mar 22, 2013 at 10:19 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Finally, putting them in your settings.xml allows reacting to repository location changes when building old builds, putting them in your pom.xml may mean that 1 year from now, checking out the tag will not build without modifying the pom.xml (or even worse, depending on the 1 year old version in a project your are building - you might want to verify a regression in behaviour for example - won't work because that version's pom.xml has invalid repository URLs) For all the above reasons, pushing OSS projects to central is the recommended practice, but getting them into any public Maven repository is better than not having them in a public Maven repository. TL;DR pushing open source projects to a repository other than Central (at least for the moment given how Maven works) is bad practice. Arguing over whether it is better to reference those other repositories from settings.xml or from pom.xml is very much like two fleas arguing over who will get squashed first when the building collapses and flattens the dog they live on ;-)
[ANN] extra-enforcer-rules 1.0-alpha-4 Released
Hi, The Mojo team is pleased to announce the release of the extra-enforcer-rules version 1.0-alpha-4. Extra Enforcer Rules is a project containing extra rules for Apache Maven's Enforcer Plugin. http://mojo.codehaus.org/extra-enforcer-rules/ To get this update, simply specify the version in your project's maven-enforcer-plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-enforcer-plugin/artifactId version1.2/version executions execution ... /execution /executions dependencies dependency groupIdorg.codehaus.mojo/groupId artifactIdextra-enforcer-rules/artifactId version1.0-alpha-4/version /dependency /dependencies /plugin *Bug* [MOJO-1775 https://jira.codehaus.org/browse/MOJO-1775] - BanDuplicateClasses should skip any artifacts not of type jar [MOJO-1840 https://jira.codehaus.org/browse/MOJO-1840] - Non-well-formed XML in sample project configuration on site [MOJO-1841 https://jira.codehaus.org/browse/MOJO-1841] - Contrary to documentation requiredRoles are not always valid [MOJO-1853 https://jira.codehaus.org/browse/MOJO-1853] - requirePropertyDiverges: NPE when plugin is configured in pluginManagement and not in plugin section *Improvement* [MOJO-1909 https://jira.codehaus.org/browse/MOJO-1909] - don't log all classes in classpath at info level *New Feature* [MOJO-1860 https://jira.codehaus.org/browse/MOJO-1860] - New feature to ban circular dependencies [MOJO-1912 https://jira.codehaus.org/browse/MOJO-1912] - Rule to check the bytecode version used in dependencies See https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11062version=18450for reference. Enjoy, The Mojo team. -- Baptiste
Re: My view on the relative merits of different ways to unpack jars into target/classes
On 22 Mär 2013, Stephen Connolly wrote: On 22 March 2013 08:12, Martin Höller mar...@xss.co.at wrote: Hi! On 21 Mär 2013, Stephen Connolly wrote: I think mailing lists are not the best way to explain why different solutions are to be preferred when ranking against what is best for the Maven ecosystem as a whole. So I wrote a blog post to explain my views on what are good ways and what are bad ways. http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html Really good post, but... ;-) There is one thing that is IMHO not clearly (enough) stated in your post: it is in general a bad idea to add repositories to your POMs [1]. Section 2. Get the external jars into a public Maven repository adds an additional repository to the pom.xml. This is usually bad pratice and should be avoided. Brian Fox wrote a detailed blog post [1] about this. Maybe you could link to this post and mentione, that putting the additional repo in your settings.xml is an alternative. Well if you put them into your settings.xml, then those extra repositories are applied for *every single project that you build* If you put them in your pom.xml, then those extra repositories are only applied for that project and *every single project that lists that project as a transitive dependency* Good point. Also putting them in your settings.xml means you cannot just checkout and build, putting them in your pom.xml allows most others to just checkout and build (except for those of us behind a corporate proxy with a mandated mirrorOf*/mirrorOf) On the other hand putting them in pom.xml might bring you artifacts into your build from this repo without one noticing they are not coming from central. But I have to admit, in the scenario described by your post the pom.xml might be the better choice. However, a word of warning and a link to Brian's post would not hurt and would hopefully further educate maven users. best regards, - martin signature.asc Description: PGP signature
I need to run 2 profiles to deploy to 2 seperate Nexus repositories
Hi, How can I get Maven to run 2 separate Profiles to deploy the build artifacts to 2 separate Nexus repos? I have tried the following but only the second profile deploys to its Nexus repo. mvn clean deploy -P nexus-one,nexus-two Note: the settings file passed doesn't contain any profiles. -- View this message in context: http://maven.40175.n5.nabble.com/I-need-to-run-2-profiles-to-deploy-to-2-seperate-Nexus-repositories-tp5751508.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: I need to run 2 profiles to deploy to 2 seperate Nexus repositories
How can I get Maven to run 2 separate Profiles to deploy the build artifacts to 2 separate Nexus repos? I have tried the following but only the second profile deploys to its Nexus repo. Instead of this approach, I suggest asking how to achieve your end goal on the Nexus lists. Surely there are better ways to get this done using Nexus-specific functionality. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Multiple build arguments
Thank you Andreas ! It solved the issue. -- View this message in context: http://maven.40175.n5.nabble.com/Multiple-build-arguments-tp5750700p5751511.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 deploy artifacts to Nexus repository
Building my project with Jenkins. The workspace is on a jenkins slave node. This slave node happens to be the same server which is running the Sonatype Nexus Repository. Jenkins master is running on user called jenkins. The slave node is configured for the user called build on that slave, but I don't think thats a problem. I'm not sure where the connection happens from, From the jenkins master server machine to the server machine running Nexus and the slave node, or if it is trying to run scp from the slave node to the same slave node. Maven distribution management is configured like this: distributionManagement repository idreleases/id urlscp://maven-vm1/srv/maven/releases/url /repository /distributionManagement This directory has chmod 775, where user build is owner and user jenkins has group access. So access should not be a problem while trying to deploy the artifacts. While on Nexus release repository summary section it uses an http URL for uploading: distributionManagement repository idreleases/id urlhttp://maven-vm1:8080/nexus/content/repositories/releases/url /repository /distributionManagement I want to use SCP for the transfer... *Errormessage from maven:* message : Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project myApp: Failed to deploy artifacts: Could not transfer artifact com.company:myApp:jar:2.4.0 from/to releases (scp://maven-vm1/srv/maven/releases): Cannot connect. Reason: Auth fail cause : Failed to deploy artifacts: Could not transfer artifact com.company:myApp:jar:2.4.0 from/to releases (scp://maven-vm1/srv/maven/releases): Cannot connect. Reason: Auth fail Stack trace : org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project myApp: Failed to deploy artifacts: Could not transfer artifact com.company:myApp:jar:2.4.0 from/to releases (scp://maven-vm1/srv/maven/releases): Cannot connect. Reason: Auth fail at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239) at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158) at hudson.maven.Maven3Builder.call(Maven3Builder.java:100) at hudson.maven.Maven3Builder.call(Maven3Builder.java:66) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) Caused by: org.apache.maven.plugin.MojoExecutionException: Failed to deploy artifacts: Could not transfer artifact com.company:myApp:jar:2.4.0 from/to releases (scp://maven-vm1/srv/maven/releases): Cannot connect. Reason: Auth fail -- View this message in context: http://maven.40175.n5.nabble.com/maven-deploy-artifacts-to-Nexus-repository-tp5751512.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For
Re: maven deploy artifacts to Nexus repository
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project myApp: Failed to deploy artifacts: Could not transfer artifact com.company:myApp:jar:2.4.0 from/to releases (scp://maven-vm1/srv/maven/releases): Cannot connect. Reason: Auth fail Auth fail suggests a failure to authenticate. Check the username, password, etc. Maybe check some logs on the machine you are trying to connect to with scp. Are you sure your ssh keys and known_hosts etc are set up properly? Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven deploy artifacts to Nexus repository
Not sure using scp is possible, but answering this precise point would be more a nexus ML question. Have you tried using HTTP even temporarily to see if this works? This would help reduce the hypothesis of where the issue lies, isn't it? Btw, I think the most often used protocol is http. Maybe if you want security you could try just using https? Cheers 2013/3/22 DJViking sverre@gmail.com Building my project with Jenkins. The workspace is on a jenkins slave node. This slave node happens to be the same server which is running the Sonatype Nexus Repository. Jenkins master is running on user called jenkins. The slave node is configured for the user called build on that slave, but I don't think thats a problem. I'm not sure where the connection happens from, From the jenkins master server machine to the server machine running Nexus and the slave node, or if it is trying to run scp from the slave node to the same slave node. Maven distribution management is configured like this: distributionManagement repository idreleases/id urlscp://maven-vm1/srv/maven/releases/url /repository /distributionManagement This directory has chmod 775, where user build is owner and user jenkins has group access. So access should not be a problem while trying to deploy the artifacts. While on Nexus release repository summary section it uses an http URL for uploading: distributionManagement repository idreleases/id urlhttp://maven-vm1:8080/nexus/content/repositories/releases /url /repository /distributionManagement I want to use SCP for the transfer... *Errormessage from maven:* message : Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project myApp: Failed to deploy artifacts: Could not transfer artifact com.company:myApp:jar:2.4.0 from/to releases (scp://maven-vm1/srv/maven/releases): Cannot connect. Reason: Auth fail cause : Failed to deploy artifacts: Could not transfer artifact com.company:myApp:jar:2.4.0 from/to releases (scp://maven-vm1/srv/maven/releases): Cannot connect. Reason: Auth fail Stack trace : org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on project myApp: Failed to deploy artifacts: Could not transfer artifact com.company:myApp:jar:2.4.0 from/to releases (scp://maven-vm1/srv/maven/releases): Cannot connect. Reason: Auth fail at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239) at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158) at hudson.maven.Maven3Builder.call(Maven3Builder.java:100) at hudson.maven.Maven3Builder.call(Maven3Builder.java:66) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) Caused by: org.apache.maven.plugin.MojoExecutionException:
maven-compiler-plugin, fork, and Windows classpath length
I am using maven-compiler-plugin version 3.0. We use fork=true. We are seeing (I am pretty certain; haven't sorted through the boatloads of -X output yet) that the classpath being supplied to the maven-compiler-plugin is too long for Windows. (We're getting some weird errors out of the underlying compiler, then when we shorten the root path where we have the project the errors go away.) I didn't see any way to have Maven supply the classpath to the maven-compiler-plugin as a file, or any other way to bypass the Windows path length limitation. Is this a known issue? I also didn't see it when I did a classpath search in Jira under the MCOMPILER project, but there were lots of entries so I might have missed it. Thanks, Best, Laird -- http://about.me/lairdnelson
Re: Git settings for maven release plugin...
You may try replacing the colon between host and orgname with a slash /. Regards Mirko -- Sent from my mobile On Mar 22, 2013 12:11 AM, Jeff predato...@gmail.com wrote: My release:prepare is failing when it tries the following: git push ssh://g...@github.com:MyOrg/apps-thor.git releaseBranch:releaseBranch With the following error: ssh: Could not resolve hostname github.com:MyOrg: Name or service not known It also fails on the command line. If i remove the ssh:// it works. I think it is one of the values in my scm/ section but I think I'm following the pattern correctly based on http://maven.apache.org/scm/git.html . Here are my settings. scm connectionscm:git:ssh://g...@github.com: MyOrg/apps-thor.git/connection developerConnectionscm:git:ssh://g...@github.com: MyOrg/apps-thor.git/developerConnection urlg...@github.com:MyOrg/apps-thor.git/url /scm Am I missing something obvious? Regards! -- Jeff Vincent See my LinkedIn profile at: http://www.linkedin.com/in/rjeffreyvincent I ♥ DropBox http://db.tt/9O6LfBX !!
Parent Project Links Broken In Modules In Sub-Directory
I have a multiple module site that has 2 modules in a subdirectory in the parent project. When I stage the site the links back up to the parent project from the two modules in the subdirectory are broken. However the links back to the parent project from the other module sites work fine. Here is the structure... parent +module1 +pom.xml +mydir +module2 +pom.xml +module3 +pom.xml +module4 +pom.xml +pom.xml The site directory structure when it is staged looks like site +module1 +index.html +module2 +index.html +module3 +index.html +module4 +index.html +index.html Like I said above the links back to the parent site from the sites for modules 1 4 work fine, the links from module 3 4 are broken. To my surprise the sites for modules 3 4 are not in a subdirectory however the links back to the parent index.html look like ../../index.html making me think they should be. How can I correct this? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: I need to run 2 profiles to deploy to 2 seperate Nexus repositories
A kind of dummy idea, Why not copy the deployed artifacts using wagon plugin from repository one to repository two ? Not sure if wagon plugin works for nexus, but it might. Hope it helps somehow tonio On Fri, Mar 22, 2013 at 11:25 AM, Wayne Fay wayne...@gmail.com wrote: How can I get Maven to run 2 separate Profiles to deploy the build artifacts to 2 separate Nexus repos? I have tried the following but only the second profile deploys to its Nexus repo. Instead of this approach, I suggest asking how to achieve your end goal on the Nexus lists. Surely there are better ways to get this done using Nexus-specific functionality. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mvn release using local git repository
Hi,
mvn release:prepare
-Dproject.scm.developerConnection=scm:git:git@localserver:/home/git/repositories/ourproject
-Dproject.scm.connection=scm:git:git@localserver
:/home/git/repositories/ourproject
Is this exactly how you execute it? You can't fill pom.xml entries like
this.
If you need something like this, you should try:
project
scm
developerConnection${alternativeDeveloperConnection}/developerConnection
/scm
/project
and run mvn release:prepare
-DalternativeDeveloperConnection=scm:git:git@localserver:/home/git/repositories/ourproject
There's no need to specify both connections: if both are specified the
developerConnection is used.
Robert
Op Fri, 22 Mar 2013 09:30:26 +0100 schreef Bernhard Friedreich
fries...@gmail.com:
Hi!
I'm having a problem with releasing one of our projects (multimodule).
We've got the following structure:
github: repository (no commit access)
fork on github: forked repository (commit access)
local server: git clone (bare) of fork on github
local development machine: git clone of the repo on local server
(Reason for this approach is that the whole team is using the same
development version)
As we want to be able to push changes from our local server back to
github
(through a pull request) we can not change the settings of the pom (the
project on github uses different developerconnections, scmconnections,
...).
Although we must be able to create new releases of our clone.
I theory this should work with something like this if I understood the
docs
correctly:
mvn release:prepare
-Dproject.scm.developerConnection=scm:git:git@localserver:/home/git/repositories/ourproject
-Dproject.scm.connection=scm:git:git@localserver
:/home/git/repositories/ourproject
This doesn't change the pom.xml though and doesn't seem to work as at the
end it tries to push to github. I would guess that the pom.xml should be
modified to the provided arguments in the created tag - but they are not.
Please help.. Thanks :)
Best regards,
Bernhard Friedreich
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
activeProfiles
I have two development environments: work and personal. I am trying to set up my projects so that the POM knows which profile to activate, but it seems you cannot put activeProfiles in a POM, only in a settings.xml file. Is there some reason for this? Is there some other Maven way to do what I want to do? How do other people separate work development from personal development? Cheers, Eric - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
