activeProfiles

[Eric Kolotyluk]

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  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

Re: mvn release using local git repository

[Robert Scholte]

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:

  
${alternativeDeveloperConnection}
  


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  
:



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

Re: I need to run 2 profiles to deploy to 2 seperate Nexus repositories

[Tonio Caputo]

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  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
>
>

Parent Project Links Broken In Modules In Sub-Directory

[Ryan Baxter]

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: Git settings for maven release plugin...

[Mirko Friedenhagen]

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"  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  section but I think I'm
> following the pattern correctly based on
> http://maven.apache.org/scm/git.html .  Here are my settings.
>
>
> 
>
>   scm:git:ssh://g...@github.com:
> MyOrg/apps-thor.git
>
>   scm:git:ssh://g...@github.com:
> MyOrg/apps-thor.git
>
>   g...@github.com:MyOrg/apps-thor.git
>
> 
>
>
> Am I missing something obvious?
>
>
> Regards!
>
>
> --
>
> Jeff Vincent
> See my LinkedIn profile at:
> http://www.linkedin.com/in/rjeffreyvincent
> I ♥ DropBox  !!
>

maven-compiler-plugin, fork, and Windows classpath length

[Laird Nelson]

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: maven deploy artifacts to Nexus repository

[Baptiste MATHUS]

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 

> 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:
> 
> 
> releases
> scp://maven-vm1/srv/maven/releases
> 
> 
> 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:
> 
>   
> releases
> http://maven-vm1:8080/nexus/content/repositories/releases
> 
>   
>
>
> 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.com

Re: maven deploy artifacts to Nexus repository

[Wayne Fay]

> 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

maven deploy artifacts to Nexus repository

[DJViking]

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:


releases
scp://maven-vm1/srv/maven/releases


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:

  
releases
http://maven-vm1:8080/nexus/content/repositories/releases
  
   

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 additional commands, e-mail: users-h...@maven.apache.org

Re: Multiple build arguments

[Stephane-3]

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

Re: I need to run 2 profiles to deploy to 2 seperate Nexus repositories

[Wayne Fay]

> 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

I need to run 2 profiles to deploy to 2 seperate Nexus repositories

[DK]

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: My view on the relative merits of different ways to unpack jars into target/classes

[Martin Hoeller]

On 22 Mär 2013, Stephen Connolly wrote:
> On 22 March 2013 08:12, Martin Höller  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  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
> *)

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

[ANN] extra-enforcer-rules 1.0-alpha-4 Released

[Baptiste MATHUS]

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:


org.apache.maven.plugins
maven-enforcer-plugin
1.2

  
...
  


  
org.codehaus.mojo
extra-enforcer-rules
1.0-alpha-4
  

  

*Bug*

[MOJO-1775 ] -
BanDuplicateClasses should skip any artifacts not of type jar
[MOJO-1840 ] - Non-well-formed
XML in sample project configuration on site
[MOJO-1841 ] - Contrary to
documentation requiredRoles are not always valid
[MOJO-1853 ] -
requirePropertyDiverges: NPE when plugin is configured in pluginManagement
and not in plugin section

*Improvement*

[MOJO-1909 ] - don't log all
classes in classpath at info level

*New Feature*

[MOJO-1860 ] - New feature to
ban circular dependencies
[MOJO-1912 ] - Rule to check
the bytecode version used in dependencies

See
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11062&version=18450for
reference.

Enjoy,

The Mojo team.
-- 
Baptiste

Re: My view on the relative merits of different ways to unpack jars into target/classes

[Tamás Cservenák]

+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 ;-)
>
>

Re: My view on the relative merits of different ways to unpack jars into target/classes

[Stephen Connolly]

On 22 March 2013 08:12, Martin Höller  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  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
*)

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/
>

mvn release using local git repository

[Bernhard Friedreich]

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

[Martin Höller]

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  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

Re: Git settings for maven release plugin...

[Anders Lindgren]

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:git:ssh://g...@github.com:MyOrg/apps-thor.git
>   
> scm:git:ssh://g...@github.com:MyOrg/apps-thor.git
>   g...@github.com:MyOrg/apps-thor.git
> 
> Am I missing something obvious?
> 
> 
> Regards!
> 
>