• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

Overwrite SCM connection URL for Maven release plugin

 
Sheriff
Posts: 21805
104
Eclipse IDE Spring VI Editor Chrome Java Ubuntu Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a project where there are two teams working on the code, and each team has its own Git repository (which are synced through hooks). The other team is the "main" team so their Git repository should be configured as the (developer) connection in the POMs. However, we don't have direct access to their Git repository. We should still be able to perform releases on our own Git repository (which will then be pushed to their Git repository).

OK, that sounds a bit cryptic, so let's make it a bit clearer.
The POM contains the following part:
When we need to perform a release we need to change XXXX into YYYY without changing the POM.

I've already tried specifying -Dproject.scm.developerConnection=scm:git:YYYY and -Dscm.url=scm:git:YYYY but all have failed so far. The Maven release plugin won't use anything other than scm:git:XXXX. I can always clearly see this value in release.properties, and the plugin keeps giving errors because it can't connect to XXXX.

Is it possible to override the SCM developer connection in the way we want? I know I can get it to work with a property, but our project lead doesn't want an "ugly" variable in the developer connection.
 
Rancher
Posts: 2759
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Have you tried just specifying the scm tag in your local maven settings xml?

In your MAVEN_HOME/conf/ folder there is a settings.xml. The settings.xml looks more or less like a pom.xml. ANything you put in there will "override" what is in pom.xml. I think you should be able to specify your scm in your settings.xml, and it should override the one in pom.xml

 
Rob Spoor
Sheriff
Posts: 21805
104
Eclipse IDE Spring VI Editor Chrome Java Ubuntu Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This isn't the only project we're working on; I'm on at least 4 or 5 projects myself. If we put the SCM URL in the global Maven settings then other projects would use the same URL, and that's something we can't have.
 
Jayesh A Lalwani
Rancher
Posts: 2759
32
Eclipse IDE Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You could have a profile for this project
 
Rob Spoor
Sheriff
Posts: 21805
104
Eclipse IDE Spring VI Editor Chrome Java Ubuntu Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You can't define any SCM settings in a profile. I did try to set properties project.scm.developerConnection and even scm.url (which is what's being added to release.properties) in the profile, but neither solved the issue.
 
Rob Spoor
Sheriff
Posts: 21805
104
Eclipse IDE Spring VI Editor Chrome Java Ubuntu Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've gone over this with the project lead, and because all other options weren't working we decided to go with properties instead.
 
Saloon Keeper
Posts: 21133
134
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What you're asking defies the uniqueness characteristic that is one of the pillars of Maven. The idea that any copy of the project anywhere in the world should build an identical product.

It's OK to have mirrors of the dependency repositories and/or to use a proxy (e.g., Nexus) so that you don't have to rely solely on a single failure-prone repository. The source code, however is a bit touchier. Building snapshots allows you to work with local products, but once a release is finalized (assigned a fixed version number), that's supposed to be it.

I have had to do some tricks myself because at one time, the server identities I was working with looked different on my LAN than they did to the people over in Belarus. but I think there were some kinks in the mechanism. Since then I've managed to get rid of a lot of the warts in my LAN configuration so that I have a more normalized infrastructure regardless of whether you're in-house or not.

If you are doing local builds, I'd think probably something like this would be appropriate:

1. Set up a Nexus server so that when you do a snapshot build, it goes to a common repository shared with your team. Among the upstream servers would be your master team's Nexus server.

2. Set up a "push" management system so that when you get serious, your source gets pushed to the master repo before you build the numbered release.

3. Possibly install one or more proxy servers to hide any remaining differences.

Under item #2, something like Jenkins would probably be a good idea. You could flip a switch that tried to push the mods to the master git repo (and halted if there were conflicts!), then did a pull/build/deploy to your local Nexus repo plus maybe sends a trigger event to a Jenkins server at the master location so that it could do likewise.

Anyway, based on stuff I've done, that's the direction I'd aim. It should eliminate the need to mutate the pom (which is something Maven doesn't like). Your Mileage May Vary.
 
Rob Spoor
Sheriff
Posts: 21805
104
Eclipse IDE Spring VI Editor Chrome Java Ubuntu Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's not the releases that need to be synced, it's the entire repository. The only thing we really use the Maven release plugin for is automatically version control (e.g. going from 0.0.1-SNAPSHOT through 0.0.1 to 0.0.2-SNAPSHOT) and automatic tagging (creating a tag for the 0.0.1 commit).

Ideally we would have access to the remote ("main") repository, or have the other team perform all releases, but unfortunately that's not possible. (In fact, we had a deployment yesterday that the other team couldn't get right, so I had to take over and finish.)
 
author & internet detective
Posts: 39538
778
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rob,
Are you using Jenkins or is this something that has to work in pure Maven?
 
Tim Holloway
Saloon Keeper
Posts: 21133
134
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hmmm. Snapshot releases are the "escape hatch" for Maven because they allow intermediate sub-versions of a product and relax the absolute versioning requirements somewhat. Because of that, a lot of the formality involved in non-snapshot releases doesn't apply.

Personally, I consider a snapshot to be a more or less local test. If I want something shared with my friends in Belarus, I'd do a maven release goal to commit my source and nail an absolute number for the source to the product. Then again, we're both using the same svn archive. For the upstream push a system like Jenkins could step in. I note that the maven 2.5.2 release:prepare goal can do an upstream git push as an option though.
 
Rob Spoor
Sheriff
Posts: 21805
104
Eclipse IDE Spring VI Editor Chrome Java Ubuntu Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We are using Jenkins, and I think the other team as well, but I'm not quite sure.
 
Jeanne Boyarsky
author & internet detective
Posts: 39538
778
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Rob Spoor wrote:We are using Jenkins, and I think the other team as well, but I'm not quite sure.


It doesn't matter what the other team is using because they have the "luxury" of having the POM set up the way they need.

The easiest way to do this would be to get the other team to give Jenkins write access to their git repo so Jenkins can run proper releases without individual developers being able to able commit. Let's assume the other team are inflexible gits and said no. [Couldn't resist the pun]

Jenkins gives you the option of specifying pre/post build steps. Which means you could set up a build to:

1) Pre-build step: Use a shell script or Groovy script to do a search/replace in the checked out pom and point to your repository. This is safe because the only place the change exists is the local workspace of that Jenkins job
2) Pre-build step: Commit the change from step 1 to your git repo (I'm assuming that's where this build checked out from in the first place)
3) Run your normal release build via Maven
4) Post-build step: Repeat steps 1 and 2 in reverse to put the repo back to XXX/
 
Rob Spoor
Sheriff
Posts: 21805
104
Eclipse IDE Spring VI Editor Chrome Java Ubuntu Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Jeanne Boyarsky wrote:

Rob Spoor wrote:We are using Jenkins, and I think the other team as well, but I'm not quite sure.


It doesn't matter what the other team is using because they have the "luxury" of having the POM set up the way they need.


How could they have a different POM if commits in our repository are synced with their repository, and their repository is synced with ours as well? If we change the POM in our repository, they will get our POM. If they change the POM in their repository, we get their POM. With the current setup (and that's not going to change anytime soon) both teams will have the exact same code base.

The easiest way to do this would be to get the other team to give Jenkins write access to their git repo so Jenkins can run proper releases without individual developers being able to able commit. Let's assume the other team are inflexible gits and said no. [Couldn't resist the pun]

Jenkins gives you the option of specifying pre/post build steps. Which means you could set up a build to:

1) Pre-build step: Use a shell script or Groovy script to do a search/replace in the checked out pom and point to your repository. This is safe because the only place the change exists is the local workspace of that Jenkins job
2) Pre-build step: Commit the change from step 1 to your git repo (I'm assuming that's where this build checked out from in the first place)
3) Run your normal release build via Maven
4) Post-build step: Repeat steps 1 and 2 in reverse to put the repo back to XXX/


I'm not sure our project lead would want all these POM changes all the time, as it pollutes the Git history. We could perhaps setup our Jenkins to write release to their repository (we have some access to it, as our commits are synced to their repository), but I'm not sure the project lead thinks that, with the current workaround, it's worth the time. (To be honest, I'm quite sure he thinks it isn't...)
 
Jeanne Boyarsky
author & internet detective
Posts: 39538
778
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Rob Spoor wrote:How could they have a different POM if commits in our repository are synced with their repository, and their repository is synced with ours as well? If we change the POM in our repository, they will get our POM. If they change the POM in their repository, we get their POM. With the current setup (and that's not going to change anytime soon) both teams will have the exact same code base.


Understood. I meant that the latest committed POM is the one they need. (except for the short time it isn't).

I'm not sure our project lead would want all these POM changes all the time, as it pollutes the Git history.


Then I think your only choice is to "manually" release. You'd have to keep update the snapshot -> release and release -> next snapshot in the POM and tag. Both of these could be build steps if you were so moved.

By the way, this set up sounds ridiculous.
 
Saloon Keeper
Posts: 10671
228
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Have you tried -DconnectionUrl=scm:git:YYYY ?
 
Rob Spoor
Sheriff
Posts: 21805
104
Eclipse IDE Spring VI Editor Chrome Java Ubuntu Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, and -Dproject.scm.connection, -Dproject.scm.developerConnection and -Dscm.url (as it's stored in release.properties) as well.
 
Stephan van Hulst
Saloon Keeper
Posts: 10671
228
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, instead of using the release:prepare goal, would it be worth modifying the release.properties file manually (and not storing it in source control)?
 
Rob Spoor
Sheriff
Posts: 21805
104
Eclipse IDE Spring VI Editor Chrome Java Ubuntu Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Doesn't release:prepare also handle the version changes, tagging, etc?

But as far as the company is concerned, this issue is already solved by using a property for the developer connection:

Rob Spoor wrote:I've gone over this with the project lead, and because all other options weren't working we decided to go with properties instead.

 
Stephan van Hulst
Saloon Keeper
Posts: 10671
228
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm sorry, I was confused. I thought release:perform did this. Yes, my suggestion won't work.

With the properties route, make sure the properties are defined in the same POM as where the SCM is declared. A build should be able to be reproduced using just the POM.
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've also been looking hard to find out how to do this.
Seems to be not possible because project.scm.developerConnection is property of Model class and such a properties can not be overriden. You only can override user-defined properties.

See
http://stackoverflow.com/questions/13876165/how-to-override-maven-property-in-command-line#comment19176210_13877971
 
When I was younger I felt like a man trapped inside a woman’s body. Then I was born. My twin is a tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!