Quantcast

Is it possible to tie current git branch to project version?

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Is it possible to tie current git branch to project version?

Seth Call
Hi there,

I've seen indication when searching the internet that it isn't possible to put variables in <version> of a project (unless those variables are hardcoded <properties> or provided at the command line), but I thought I'd ask the list ...

Say there was a plugin that would invoke 'git branch' to determine the current branch, and to then make that available to the project as a variable; call it ${branch}.   I'd like to use this variable then in the version tag:

<project>
<groupId>blah</groupId>
<artifactId>blah</artifactId>
<version>${branch}-SNAPSHOT</version>
</project>

The reason I want to do this is that I'm realizing, for our internal-only code projects, that a branch is always synonymous with a version of a project, and ideally the act of being of switching branches would be all it takes to switch your maven project's version.

Is this possible if I were to make a maven plugin?

Thanks!
Seth


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it possible to tie current git branch to project version?

Lyons, Roy
:-) we tag our repo with "branchname!RP-BL-mavenlabel" to help in location.  Rp is for release prepare and bl is for baseline (carryover from clearcase terminology)

Just remember that in git a hash doesn't belong to a branch, it is simply attached to a linked list of hashes.  A "branch" is simply a tag pointing to a hash being designated as a "head".  You can just as easily use the tag created by the release plugin to checkout, and then make some bugfix branch from that location.


Sent from my Blackberry.

----- Original Message -----
From: Seth Call <[hidden email]>
To: [hidden email] <[hidden email]>
Sent: Tue Mar 06 22:01:07 2012
Subject: Is it possible to tie current git branch to project version?

Hi there,

I've seen indication when searching the internet that it isn't possible to
put variables in <version> of a project (unless those variables are
hardcoded <properties> or provided at the command line), but I thought I'd
ask the list ...

Say there was a plugin that would invoke 'git branch' to determine the
current branch, and to then make that available to the project as a
variable; call it ${branch}.   I'd like to use this variable then in the
version tag:

<project>
<groupId>blah</groupId>
<artifactId>blah</artifactId>
<version>${branch}-SNAPSHOT</version>
</project>

The reason I want to do this is that I'm realizing, for our internal-only
code projects, that a branch is always synonymous with a version of a
project, and ideally the act of being of switching branches would be all it
takes to switch your maven project's version.

Is this possible if I were to make a maven plugin?

Thanks!
Seth




--
View this message in context: http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5543110.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it possible to tie current git branch to project version?

Seth Call
Hi Roy,

I don't understand what 'tagging our repo' means.  Is this a feature of your remote repository?  Sorry... I googled but I don't know what you are saying...

But aside from that, I really don't care about git hash in this question... let me explain what I'm trying to acheive...



As a developer:
* If I'm on branch master, I want my project version to be master-SNAPSHOT

* If I'm on branch development, I want my project version to be development-SNAPSHOT

I'd like that to happen automatically when I make the branch; I know this is rather dynamic so I assume a plugin at a minimum is required.   I'm also not interested in using git local hooks if at all avoidable because they have their own drawbacks.

This versioning scheme is very important; making a branch is making a new version.  So, downstream projects that depend on my project:master-SNAPSHOT should *not* pickup my new branch's build artifact-not unless, of course, I go to that downstream project and change it's dependency version to say project:development-SNAPSHOT.

In summary, they are different versions, and so if you don't version your project as you make a branch, then you will now have indeterminate build resolution because 'the-last-branch-you-build-will-win' sort of problems.  Also, all of this should work locally (not require a build server), so I'm limiting myself to maven-only techniques...

Any help is greatly appreciated.  I hope there is some way to achieve this that I'm just not thinking of...

But if anyone can say definitively that you can not put a variable in the <version> tag of an artifact, then I at least know a plugin-based solution is not an option.

Regards,
Seth

On Wed, Mar 7, 2012 at 6:00 AM, Lyons, Roy [via Maven] <[hidden email]> wrote:
:-) we tag our repo with "branchname!RP-BL-mavenlabel" to help in location.  Rp is for release prepare and bl is for baseline (carryover from clearcase terminology)

Just remember that in git a hash doesn't belong to a branch, it is simply attached to a linked list of hashes.  A "branch" is simply a tag pointing to a hash being designated as a "head".  You can just as easily use the tag created by the release plugin to checkout, and then make some bugfix branch from that location.


Sent from my Blackberry.

----- Original Message -----
From: Seth Call <[hidden email]>
To: [hidden email] <[hidden email]>
Sent: Tue Mar 06 22:01:07 2012
Subject: Is it possible to tie current git branch to project version?

Hi there,

I've seen indication when searching the internet that it isn't possible to
put variables in <version> of a project (unless those variables are
hardcoded <properties> or provided at the command line), but I thought I'd
ask the list ...

Say there was a plugin that would invoke 'git branch' to determine the
current branch, and to then make that available to the project as a
variable; call it ${branch}.   I'd like to use this variable then in the
version tag:

<project>
<groupId>blah</groupId>
<artifactId>blah</artifactId>
<version>${branch}-SNAPSHOT</version>
</project>

The reason I want to do this is that I'm realizing, for our internal-only
code projects, that a branch is always synonymous with a version of a
project, and ideally the act of being of switching branches would be all it
takes to switch your maven project's version.

Is this possible if I were to make a maven plugin?

Thanks!
Seth




--
View this message in context: http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5543110.html
Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



If you reply to this email, your message will be added to the discussion below:
http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5543915.html
To unsubscribe from Is it possible to tie current git branch to project version?, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it possible to tie current git branch to project version?

stephenconnolly
properties cannot be used where they will affect the build plan.

Therefore the following xpaths are not allowed (it may appear to work,
but it will blow up in your face when you are not looking)

/project/parent/*
/project/groupId
/project/artifactId
/project/version

almost anywhere else is fair game

On 7 March 2012 15:18, Seth Call <[hidden email]> wrote:

> Hi Roy,
>
> I don't understand what 'tagging our repo' means.  Is this a feature of
> your remote repository?  Sorry... I googled but I don't know what you are
> saying...
>
> But aside from that, I really don't care about git hash in this question...
> let me explain what I'm trying to acheive...
>
>
>
> As a developer:
> * If I'm on branch master, I want my project version to be master-SNAPSHOT
>
> * If I'm on branch development, I want my project version to be
> development-SNAPSHOT
>
> I'd like that to happen automatically when I make the branch; I know this
> is rather dynamic so I assume a plugin at a minimum is required.   I'm also
> not interested in using git local hooks if at all avoidable because they
> have their own drawbacks.
>
> This versioning scheme is very important; making a branch is making a new
> version.  So, downstream projects that depend on my project:master-SNAPSHOT
> should *not* pickup my new branch's build artifact-not unless, of course, I
> go to that downstream project and change it's dependency version to say
> project:development-SNAPSHOT.
>
> In summary, they are different versions, and so if you don't version your
> project as you make a branch, then you will now have indeterminate build
> resolution because 'the-last-branch-you-build-will-win' sort of problems.
>  Also, all of this should work locally (not require a build server), so I'm
> limiting myself to maven-only techniques...
>
> Any help is greatly appreciated.  I hope there is some way to achieve this
> that I'm just not thinking of...
>
> But if anyone can say definitively that you can not put a variable in the
> <version> tag of an artifact, then I at least know a plugin-based solution
> is not an option.
>
> Regards,
> Seth
>
> On Wed, Mar 7, 2012 at 6:00 AM, Lyons, Roy [via Maven] <
> [hidden email]> wrote:
>
>> :-) we tag our repo with "branchname!RP-BL-mavenlabel" to help in
>> location.  Rp is for release prepare and bl is for baseline (carryover from
>> clearcase terminology)
>>
>> Just remember that in git a hash doesn't belong to a branch, it is simply
>> attached to a linked list of hashes.  A "branch" is simply a tag pointing
>> to a hash being designated as a "head".  You can just as easily use the tag
>> created by the release plugin to checkout, and then make some bugfix branch
>> from that location.
>>
>>
>> Sent from my Blackberry.
>>
>> ----- Original Message -----
>> From: Seth Call <[hidden email]<http://user/SendEmail.jtp?type=node&node=5543915&i=0>>
>>
>> To: [hidden email] <http://user/SendEmail.jtp?type=node&node=5543915&i=1><[hidden
>> email] <http://user/SendEmail.jtp?type=node&node=5543915&i=2>>
>> Sent: Tue Mar 06 22:01:07 2012
>> Subject: Is it possible to tie current git branch to project version?
>>
>> Hi there,
>>
>> I've seen indication when searching the internet that it isn't possible to
>> put variables in <version> of a project (unless those variables are
>> hardcoded <properties> or provided at the command line), but I thought I'd
>> ask the list ...
>>
>> Say there was a plugin that would invoke 'git branch' to determine the
>> current branch, and to then make that available to the project as a
>> variable; call it ${branch}.   I'd like to use this variable then in the
>> version tag:
>>
>> <project>
>> <groupId>blah</groupId>
>> <artifactId>blah</artifactId>
>> <version>${branch}-SNAPSHOT</version>
>> </project>
>>
>> The reason I want to do this is that I'm realizing, for our internal-only
>> code projects, that a branch is always synonymous with a version of a
>> project, and ideally the act of being of switching branches would be all
>> it
>> takes to switch your maven project's version.
>>
>> Is this possible if I were to make a maven plugin?
>>
>> Thanks!
>> Seth
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5543110.html
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5543915&i=3>
>> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5543915&i=4>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5543915&i=5>
>> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5543915&i=6>
>>
>>
>> ------------------------------
>>  If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5543915.html
>>  To unsubscribe from Is it possible to tie current git branch to project
>> version?, click here<
>> .
>> NAML<
http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5544417.html
> Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Is it possible to tie current git branch to project version?

walshmatt
In reply to this post by Seth Call
Seth.

I tried doing something similar to this using the
buildnumber-maven-plugin. It returns the branch and revision number (I
use Subversion, not Git), but looks like you're trying something
similar.

The problem I encountered (at least how I interpreted it) is that the
plugin doesn't run soon enough - the pom has already been interpreted
before the plugin is called, so the ${branch} wasn't resolved when I
needed it. I wasn't trying to change the version, but I was trying to
use the property somewhere else. I think you'd have the same issue with
version though.

You can use the maven-release-plugin to create your branch. It prompts
for a new version and updates and commits your poms automatically (at
least for SVN). When/if you merge your changes back to the master
branch, you'd probably need to update your versions again, but that can
be accomplished with the versions plugin.

HTH,
Matt

> -----Original Message-----
> From: Seth Call [mailto:[hidden email]]
> Sent: Wednesday, March 07, 2012 8:19 AM
> To: [hidden email]
> Subject: Re: Is it possible to tie current git branch to project
> version?
>
> Hi Roy,
>
> I don't understand what 'tagging our repo' means.  Is this a feature
of

> your remote repository?  Sorry... I googled but I don't know what you
> are
> saying...
>
> But aside from that, I really don't care about git hash in this
> question...
> let me explain what I'm trying to acheive...
>
>
>
> As a developer:
> * If I'm on branch master, I want my project version to be master-
> SNAPSHOT
>
> * If I'm on branch development, I want my project version to be
> development-SNAPSHOT
>
> I'd like that to happen automatically when I make the branch; I know
> this
> is rather dynamic so I assume a plugin at a minimum is required.   I'm
> also
> not interested in using git local hooks if at all avoidable because
> they
> have their own drawbacks.
>
> This versioning scheme is very important; making a branch is making a
> new
> version.  So, downstream projects that depend on my project:master-
> SNAPSHOT
> should *not* pickup my new branch's build artifact-not unless, of
> course, I
> go to that downstream project and change it's dependency version to
say
> project:development-SNAPSHOT.
>
> In summary, they are different versions, and so if you don't version
> your
> project as you make a branch, then you will now have indeterminate
> build
> resolution because 'the-last-branch-you-build-will-win' sort of
> problems.
>  Also, all of this should work locally (not require a build server),
so

> I'm
> limiting myself to maven-only techniques...
>
> Any help is greatly appreciated.  I hope there is some way to achieve
> this
> that I'm just not thinking of...
>
> But if anyone can say definitively that you can not put a variable in
> the
> <version> tag of an artifact, then I at least know a plugin-based
> solution
> is not an option.
>
> Regards,
> Seth
>
> On Wed, Mar 7, 2012 at 6:00 AM, Lyons, Roy [via Maven] <
> [hidden email]> wrote:
>
> > :-) we tag our repo with "branchname!RP-BL-mavenlabel" to help in
> > location.  Rp is for release prepare and bl is for baseline
> (carryover from
> > clearcase terminology)
> >
> > Just remember that in git a hash doesn't belong to a branch, it is
> simply
> > attached to a linked list of hashes.  A "branch" is simply a tag
> pointing
> > to a hash being designated as a "head".  You can just as easily use
> the tag
> > created by the release plugin to checkout, and then make some bugfix
> branch
> > from that location.
> >
> >
> > Sent from my Blackberry.
> >
> > ----- Original Message -----
> > From: Seth Call <[hidden
> email]<http://user/SendEmail.jtp?type=node&node=5543915&i=0>>
> >
> > To: [hidden email]
> <http://user/SendEmail.jtp?type=node&node=5543915&i=1><[hidden
> > email] <http://user/SendEmail.jtp?type=node&node=5543915&i=2>>
> > Sent: Tue Mar 06 22:01:07 2012
> > Subject: Is it possible to tie current git branch to project
version?

> >
> > Hi there,
> >
> > I've seen indication when searching the internet that it isn't
> possible to
> > put variables in <version> of a project (unless those variables are
> > hardcoded <properties> or provided at the command line), but I
> thought I'd
> > ask the list ...
> >
> > Say there was a plugin that would invoke 'git branch' to determine
> the
> > current branch, and to then make that available to the project as a
> > variable; call it ${branch}.   I'd like to use this variable then in
> the
> > version tag:
> >
> > <project>
> > <groupId>blah</groupId>
> > <artifactId>blah</artifactId>
> > <version>${branch}-SNAPSHOT</version>
> > </project>
> >
> > The reason I want to do this is that I'm realizing, for our
internal-
> only
> > code projects, that a branch is always synonymous with a version of
a

> > project, and ideally the act of being of switching branches would be
> all
> > it
> > takes to switch your maven project's version.
> >
> > Is this possible if I were to make a maven plugin?
> >
> > Thanks!
> > Seth
> >
> >
> >
> >
> > --
> > View this message in context:
> > http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-
> branch-to-project-version-tp5543110p5543110.html
> > Sent from the Maven - Users mailing list archive at Nabble.com.
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=5543915&i=3>
> > For additional commands, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=5543915&i=4>
> >
> >
> >
---------------------------------------------------------------------

> > To unsubscribe, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=5543915&i=5>
> > For additional commands, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=5543915&i=6>
> >
> >
> > ------------------------------
> >  If you reply to this email, your message will be added to the
> discussion
> > below:
> >
> > http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-
> branch-to-project-version-tp5543110p5543915.html
> >  To unsubscribe from Is it possible to tie current git branch to
> project
> > version?, click
>
here<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=un
>
subscribe_by_code&node=5543110&code=c2V0aGNhbGxAZ21haWwuY29tfDU1NDMxMTB
> 8LTU5NTg4MjI5Nw==>
> > .
> >
>
NAML<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=ma
>
cro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.names
> paces.BasicNamespace-nabble.view.web.template.NabbleNamespace-
>
nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%2

> 1nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-
> send_instant_email%21nabble%3Aemail.naml>
> >
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/Is-it-
> possible-to-tie-current-git-branch-to-project-version-
> tp5543110p5544417.html
> Sent from the Maven - Users mailing list archive at Nabble.com.

______________________________________________________________________
This message, including any attachments, is confidential and contains information intended only for the person(s) named above. Any other distribution, copying or disclosure is strictly prohibited. If you are not the intended recipient or have received this message in error, please notify us immediately by reply email and permanently delete the original transmission from all of your systems and hard drives, including any attachments, without making a copy.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it possible to tie current git branch to project version?

Seth Call
In reply to this post by stephenconnolly
Hi Stephen,

Thank you for clarifying.  That tells me what constraints I have to work with,  which is a big help.

Is there any intent to change these restrictions?  I don't think anyone wants to change version mid-run (I've seen in other threads where you mention something about the reactor getting confused if the version were to change mid-run?), but I think there is a desire to change it 'at the start' of maven process execution in a more dynamic-yet-friendly way than just 'pass it in via command line'.

The desire here, to be clear, is to give developers a correct default behavior when they type 'mvn clean install', and to never force them to type -Dproject.version = something-wrong

Matt (posted after you) wanted to do something similiar point with the buildnumber plugin, too.

Seth




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it possible to tie current git branch to project version?

Seth Call
In reply to this post by walshmatt
Hi Matt, 

Thanks for the pointer to the release plugin.  My desire is to not control the process of making branches or changing versions through plugins.  I want developers to be able to use git for things branch related, and use maven for compile/build related.

I think the release-plugin is trying to do too much (unless of course you want maven to do *everything* :) )  Regardless of my opinion, though, you are a big help.  I'll still try to find the route I'm trying to take...

Seth

On Wed, Mar 7, 2012 at 10:03 AM, walshmatt [via Maven] <[hidden email]> wrote:
Seth.

I tried doing something similar to this using the
buildnumber-maven-plugin. It returns the branch and revision number (I
use Subversion, not Git), but looks like you're trying something
similar.

The problem I encountered (at least how I interpreted it) is that the
plugin doesn't run soon enough - the pom has already been interpreted
before the plugin is called, so the ${branch} wasn't resolved when I
needed it. I wasn't trying to change the version, but I was trying to
use the property somewhere else. I think you'd have the same issue with
version though.

You can use the maven-release-plugin to create your branch. It prompts
for a new version and updates and commits your poms automatically (at
least for SVN). When/if you merge your changes back to the master
branch, you'd probably need to update your versions again, but that can
be accomplished with the versions plugin.

HTH,
Matt

> -----Original Message-----
> From: Seth Call [mailto:[hidden email]]
> Sent: Wednesday, March 07, 2012 8:19 AM
> To: [hidden email]
> Subject: Re: Is it possible to tie current git branch to project
> version?
>
> Hi Roy,

>
> I don't understand what 'tagging our repo' means.  Is this a feature
of

> your remote repository?  Sorry... I googled but I don't know what you
> are
> saying...
>
> But aside from that, I really don't care about git hash in this
> question...
> let me explain what I'm trying to acheive...
>
>
>
> As a developer:
> * If I'm on branch master, I want my project version to be master-
> SNAPSHOT
>
> * If I'm on branch development, I want my project version to be
> development-SNAPSHOT
>
> I'd like that to happen automatically when I make the branch; I know
> this
> is rather dynamic so I assume a plugin at a minimum is required.   I'm
> also
> not interested in using git local hooks if at all avoidable because
> they
> have their own drawbacks.
>
> This versioning scheme is very important; making a branch is making a
> new
> version.  So, downstream projects that depend on my project:master-
> SNAPSHOT
> should *not* pickup my new branch's build artifact-not unless, of
> course, I
> go to that downstream project and change it's dependency version to
say
> project:development-SNAPSHOT.
>
> In summary, they are different versions, and so if you don't version
> your
> project as you make a branch, then you will now have indeterminate
> build
> resolution because 'the-last-branch-you-build-will-win' sort of
> problems.
>  Also, all of this should work locally (not require a build server),
so

> I'm
> limiting myself to maven-only techniques...
>
> Any help is greatly appreciated.  I hope there is some way to achieve
> this
> that I'm just not thinking of...
>
> But if anyone can say definitively that you can not put a variable in
> the
> <version> tag of an artifact, then I at least know a plugin-based
> solution
> is not an option.
>
> Regards,
> Seth
>
> On Wed, Mar 7, 2012 at 6:00 AM, Lyons, Roy [via Maven] <
> [hidden email]> wrote:

>
> > :-) we tag our repo with "branchname!RP-BL-mavenlabel" to help in
> > location.  Rp is for release prepare and bl is for baseline
> (carryover from
> > clearcase terminology)
> >
> > Just remember that in git a hash doesn't belong to a branch, it is
> simply
> > attached to a linked list of hashes.  A "branch" is simply a tag
> pointing
> > to a hash being designated as a "head".  You can just as easily use
> the tag
> > created by the release plugin to checkout, and then make some bugfix
> branch
> > from that location.
> >
> >
> > Sent from my Blackberry.
> >
> > ----- Original Message -----
> > From: Seth Call <[hidden
> > Sent: Tue Mar 06 22:01:07 2012

> > Subject: Is it possible to tie current git branch to project
version?

> >
> > Hi there,
> >
> > I've seen indication when searching the internet that it isn't
> possible to
> > put variables in <version> of a project (unless those variables are
> > hardcoded <properties> or provided at the command line), but I
> thought I'd
> > ask the list ...
> >
> > Say there was a plugin that would invoke 'git branch' to determine
> the
> > current branch, and to then make that available to the project as a
> > variable; call it ${branch}.   I'd like to use this variable then in
> the
> > version tag:
> >
> > <project>
> > <groupId>blah</groupId>
> > <artifactId>blah</artifactId>
> > <version>${branch}-SNAPSHOT</version>
> > </project>
> >
> > The reason I want to do this is that I'm realizing, for our
internal-
> only
> > code projects, that a branch is always synonymous with a version of
a

> > project, and ideally the act of being of switching branches would be
> all
> > it
> > takes to switch your maven project's version.
> >
> > Is this possible if I were to make a maven plugin?
> >
> > Thanks!
> > Seth
> >
> >
> >
> >
> > --
> > View this message in context:
> > http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-
> branch-to-project-version-tp5543110p5543110.html
> > Sent from the Maven - Users mailing list archive at Nabble.com.
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=5543915&i=3>
> > For additional commands, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=5543915&i=4>
> >
> >
> >
---------------------------------------------------------------------

> > To unsubscribe, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=5543915&i=5>
> > For additional commands, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=5543915&i=6>
> >
> >
> > ------------------------------
> >  If you reply to this email, your message will be added to the

> discussion
> > below:
> >
> > http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-
> branch-to-project-version-tp5543110p5543915.html
> >  To unsubscribe from Is it possible to tie current git branch to
> project
> > version?, click
>
here<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=un
>
subscribe_by_code&node=5543110&code=c2V0aGNhbGxAZ21haWwuY29tfDU1NDMxMTB
> 8LTU5NTg4MjI5Nw==>
> > .
> >
>
NAML<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=ma
>
cro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.names
> paces.BasicNamespace-nabble.view.web.template.NabbleNamespace-
>
nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%2

> 1nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-
> send_instant_email%21nabble%3Aemail.naml>
> >
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/Is-it-
> possible-to-tie-current-git-branch-to-project-version-
> tp5543110p5544417.html
> Sent from the Maven - Users mailing list archive at Nabble.com.

______________________________________________________________________
This message, including any attachments, is confidential and contains information intended only for the person(s) named above. Any other distribution, copying or disclosure is strictly prohibited. If you are not the intended recipient or have received this message in error, please notify us immediately by reply email and permanently delete the original transmission from all of your systems and hard drives, including any attachments, without making a copy.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




If you reply to this email, your message will be added to the discussion below:
http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5544568.html
To unsubscribe from Is it possible to tie current git branch to project version?, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it possible to tie current git branch to project version?

stephenconnolly
In reply to this post by Seth Call
My view is that there are places where stuff can be inferred, such as
groupId and version of children can be inferred *if and only if* the child
is always checked out with the parent (at the specified relative path)...
There are plans to tackle those cases.

There is, though a bit of a dual purpose to the Pom... One which may have
to be split... On the one hand the deployed Pom should be fully resolved,
and properties at those xpaths won't work... On the other hand, for
inheritance to work we need the deployed Pom to be fully unresolved...

From my point of view, those xpaths should never allow property expansion,
but more smarts in inferring based on other Pom files would be good...
Version numbers coming from a SCM branch name is a bad smell to me... So I
would not favour without a very good case being made

On Wednesday, 7 March 2012, Seth Call <[hidden email]> wrote:
> Hi Stephen,
>
> Thank you for clarifying.  That tells me what constraints I have to work
> with,  which is a big help.
>
> Is there any intent to change these restrictions?  I don't think anyone
> wants to change version mid-run (I've seen in other threads where you
> mention something about the reactor getting confused if the version were
to
> change mid-run?), but I think there is a desire to change it 'at the
start'
> of maven process execution in a more dynamic-yet-friendly way than just
> 'pass it in via command line'.
>
> The desire here, to be clear, is to give developers a correct default
> behavior when they type 'mvn clean install', and to never force them to
type

> -Dproject.version = something-wrong
>
> Matt (posted after you) wanted to do something similiar point with the
> buildnumber plugin, too.
>
> Seth
>
>
>
>
>
>
> --
> View this message in context:
http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5545298.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Is it possible to tie current git branch to project version?

walshmatt
In reply to this post by Seth Call
Just a little anecdote here on the pitfalls of branching maven projects
without some kind of control.

We have a SNAPSHOT version for trunk. We use the maven-release-plugin to
create our maintenance branches at release time. The plugin, by default,
uses the current dev version on trunk as the branch version, and prompts
for a new trunk version. Perfect. That's exactly what we want.

A developer cut a dev branch from trunk several months ago, just using
the normal svn copy, and didn't think about changing the version. He
also created a Jenkins project for it. The dev branch sat untouched for
a couple of months, then a checkin triggered a new build. Later, we were
scratching our heads as to why another build dependent the trunk version
of that same artifact was failing. Turns out it was using the artifact
built from old code on the dev branch.

After some investigation, the developer was able to pinpoint the code,
which pointed to the maven artifact causing the problem.
We put the branch and revision from the buildnumber-maven-plugin into
the manifest, so we could see the artifact in question was built from
this rarely touched dev branch. From that we were able to track the
issue to the Jenkins build.

A reason to control branch versions. An argument to use project-specific
local repositories in Jenkins (see the "Maven concurrent builds" thread
from earlier today). A good use of the manifest. And possibly even an
argument in support of what you are looking for.

Matt

> -----Original Message-----
> From: Seth Call [mailto:[hidden email]]
> Sent: Wednesday, March 07, 2012 12:41 PM
> To: [hidden email]
> Subject: Re: Is it possible to tie current git branch to project
> version?
>
> Hi Matt,
>
> Thanks for the pointer to the release plugin.  My desire is to not
> control
> the process of making branches or changing versions through plugins.
I
> want developers to be able to use git for things branch related, and
> use
> maven for compile/build related.
>
> I think the release-plugin is trying to do too much (unless of course
> you
> want maven to do *everything* :) )  Regardless of my opinion, though,
> you
> are a big help.  I'll still try to find the route I'm trying to
take...

>
> Seth
>
> On Wed, Mar 7, 2012 at 10:03 AM, walshmatt [via Maven] <
> [hidden email]> wrote:
>
> > Seth.
> >
> > I tried doing something similar to this using the
> > buildnumber-maven-plugin. It returns the branch and revision number
> (I
> > use Subversion, not Git), but looks like you're trying something
> > similar.
> >
> > The problem I encountered (at least how I interpreted it) is that
the
> > plugin doesn't run soon enough - the pom has already been
interpreted
> > before the plugin is called, so the ${branch} wasn't resolved when I
> > needed it. I wasn't trying to change the version, but I was trying
to
> > use the property somewhere else. I think you'd have the same issue
> with
> > version though.
> >
> > You can use the maven-release-plugin to create your branch. It
> prompts
> > for a new version and updates and commits your poms automatically
(at

> > least for SVN). When/if you merge your changes back to the master
> > branch, you'd probably need to update your versions again, but that
> can
> > be accomplished with the versions plugin.
> >
> > HTH,
> > Matt
> >
> > > -----Original Message-----
> > > From: Seth Call [mailto:[hidden
> email]<http://user/SendEmail.jtp?type=node&node=5544568&i=0>]
> >
> > > Sent: Wednesday, March 07, 2012 8:19 AM
> > > To: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=5544568&i=1>
> > > Subject: Re: Is it possible to tie current git branch to project
> > > version?
> > >
> > > Hi Roy,
> > >
> > > I don't understand what 'tagging our repo' means.  Is this a
> feature
> > of
> >
> > > your remote repository?  Sorry... I googled but I don't know what
> you
> > > are
> > > saying...
> > >
> > > But aside from that, I really don't care about git hash in this
> > > question...
> > > let me explain what I'm trying to acheive...
> > >
> > >
> > >
> > > As a developer:
> > > * If I'm on branch master, I want my project version to be master-
> > > SNAPSHOT
> > >
> > > * If I'm on branch development, I want my project version to be
> > > development-SNAPSHOT
> > >
> > > I'd like that to happen automatically when I make the branch; I
> know
> > > this
> > > is rather dynamic so I assume a plugin at a minimum is required.
> I'm
> > > also
> > > not interested in using git local hooks if at all avoidable
because
> > > they
> > > have their own drawbacks.
> > >
> > > This versioning scheme is very important; making a branch is
making
> a
> > > new
> > > version.  So, downstream projects that depend on my
project:master-
> > > SNAPSHOT
> > > should *not* pickup my new branch's build artifact-not unless, of
> > > course, I
> > > go to that downstream project and change it's dependency version
to

> > say
> > > project:development-SNAPSHOT.
> > >
> > > In summary, they are different versions, and so if you don't
> version
> > > your
> > > project as you make a branch, then you will now have indeterminate
> > > build
> > > resolution because 'the-last-branch-you-build-will-win' sort of
> > > problems.
> > >  Also, all of this should work locally (not require a build
> server),
> > so
> >
> > > I'm
> > > limiting myself to maven-only techniques...
> > >
> > > Any help is greatly appreciated.  I hope there is some way to
> achieve
> > > this
> > > that I'm just not thinking of...
> > >
> > > But if anyone can say definitively that you can not put a variable
> in
> > > the
> > > <version> tag of an artifact, then I at least know a plugin-based
> > > solution
> > > is not an option.
> > >
> > > Regards,
> > > Seth
> > >
> > > On Wed, Mar 7, 2012 at 6:00 AM, Lyons, Roy [via Maven] <
> > > [hidden email]
> <http://user/SendEmail.jtp?type=node&node=5544568&i=2>>
> > wrote:
> > >
> > > > :-) we tag our repo with "branchname!RP-BL-mavenlabel" to help
in

> > > > location.  Rp is for release prepare and bl is for baseline
> > > (carryover from
> > > > clearcase terminology)
> > > >
> > > > Just remember that in git a hash doesn't belong to a branch, it
> is
> > > simply
> > > > attached to a linked list of hashes.  A "branch" is simply a tag
> > > pointing
> > > > to a hash being designated as a "head".  You can just as easily
> use
> > > the tag
> > > > created by the release plugin to checkout, and then make some
> bugfix
> > > branch
> > > > from that location.
> > > >
> > > >
> > > > Sent from my Blackberry.
> > > >
> > > > ----- Original Message -----
> > > > From: Seth Call <[hidden
> > > email]<http://user/SendEmail.jtp?type=node&node=5543915&i=0>>
> > > >
> > > > To: [hidden email]
> > > <http://user/SendEmail.jtp?type=node&node=5543915&i=1><[hidden
> > > > email] <http://user/SendEmail.jtp?type=node&node=5543915&i=2>>
> > > > Sent: Tue Mar 06 22:01:07 2012
> > > > Subject: Is it possible to tie current git branch to project
> > version?
> >
> > > >
> > > > Hi there,
> > > >
> > > > I've seen indication when searching the internet that it isn't
> > > possible to
> > > > put variables in <version> of a project (unless those variables
> are
> > > > hardcoded <properties> or provided at the command line), but I
> > > thought I'd
> > > > ask the list ...
> > > >
> > > > Say there was a plugin that would invoke 'git branch' to
> determine
> > > the
> > > > current branch, and to then make that available to the project
as
> a
> > > > variable; call it ${branch}.   I'd like to use this variable
then

> in
> > > the
> > > > version tag:
> > > >
> > > > <project>
> > > > <groupId>blah</groupId>
> > > > <artifactId>blah</artifactId>
> > > > <version>${branch}-SNAPSHOT</version>
> > > > </project>
> > > >
> > > > The reason I want to do this is that I'm realizing, for our
> > internal-
> > > only
> > > > code projects, that a branch is always synonymous with a version
> of
> > a
> >
> > > > project, and ideally the act of being of switching branches
would

> be
> > > all
> > > > it
> > > > takes to switch your maven project's version.
> > > >
> > > > Is this possible if I were to make a maven plugin?
> > > >
> > > > Thanks!
> > > > Seth
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > View this message in context:
> > > > http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-
> git-
> > > branch-to-project-version-tp5543110p5543110.html
> > > > Sent from the Maven - Users mailing list archive at Nabble.com.
> > > >
> > > >
> >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden
> > > email]<http://user/SendEmail.jtp?type=node&node=5543915&i=3>
> > > > For additional commands, e-mail: [hidden
> > > email]<http://user/SendEmail.jtp?type=node&node=5543915&i=4>
> > > >
> > > >
> > > >
> >
---------------------------------------------------------------------

> >
> > > > To unsubscribe, e-mail: [hidden
> > > email]<http://user/SendEmail.jtp?type=node&node=5543915&i=5>
> > > > For additional commands, e-mail: [hidden
> > > email]<http://user/SendEmail.jtp?type=node&node=5543915&i=6>
> > > >
> > > >
> > > > ------------------------------
> > > >  If you reply to this email, your message will be added to the
> > > discussion
> > > > below:
> > > >
> > > > http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-
> git-
> > > branch-to-project-version-tp5543110p5543915.html
> > > >  To unsubscribe from Is it possible to tie current git branch to
> > > project
> > > > version?, click
> > >
> >
>
here<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=un
> > >
> >
>
subscribe_by_code&node=5543110&code=c2V0aGNhbGxAZ21haWwuY29tfDU1NDMxMTB
> > > 8LTU5NTg4MjI5Nw==>
> > > > .
> > > >
> > >
> >
>
NAML<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=ma
> > >
> >
>
cro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.names
> > > paces.BasicNamespace-nabble.view.web.template.NabbleNamespace-
> > >
> >
>
nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%2

> >
> > > 1nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-
> > > send_instant_email%21nabble%3Aemail.naml>
> > > >
> > >
> > >
> > > --
> > > View this message in context: http://maven.40175.n5.nabble.com/Is-
> it-
> > > possible-to-tie-current-git-branch-to-project-version-
> > > tp5543110p5544417.html
> > > Sent from the Maven - Users mailing list archive at Nabble.com.
> >
> >
> ______________________________________________________________________
> > This message, including any attachments, is confidential and
contains
> > information intended only for the person(s) named above. Any other
> > distribution, copying or disclosure is strictly prohibited. If you
> are not
> > the intended recipient or have received this message in error,
please
> > notify us immediately by reply email and permanently delete the
> original
> > transmission from all of your systems and hard drives, including any
> > attachments, without making a copy.
> >
> >
---------------------------------------------------------------------

> > To unsubscribe, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=5544568&i=3>
> > For additional commands, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=5544568&i=4>
> >
> >
> >
> > ------------------------------
> >  If you reply to this email, your message will be added to the
> discussion
> > below:
> >
> > http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-
> branch-to-project-version-tp5543110p5544568.html
> >  To unsubscribe from Is it possible to tie current git branch to
> project
> > version?, click
>
here<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=un
>
subscribe_by_code&node=5543110&code=c2V0aGNhbGxAZ21haWwuY29tfDU1NDMxMTB
> 8LTU5NTg4MjI5Nw==>
> > .
> >
>
NAML<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=ma
>
cro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.names
> paces.BasicNamespace-nabble.view.web.template.NabbleNamespace-
>
nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%2

> 1nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-
> send_instant_email%21nabble%3Aemail.naml>
> >
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/Is-it-
> possible-to-tie-current-git-branch-to-project-version-
> tp5543110p5545345.html
> Sent from the Maven - Users mailing list archive at Nabble.com.

______________________________________________________________________
This message, including any attachments, is confidential and contains information intended only for the person(s) named above. Any other distribution, copying or disclosure is strictly prohibited. If you are not the intended recipient or have received this message in error, please notify us immediately by reply email and permanently delete the original transmission from all of your systems and hard drives, including any attachments, without making a copy.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it possible to tie current git branch to project version?

Seth Call
In reply to this post by stephenconnolly
Bad smell eh?  Ok, here's my bad smell.  Version numbers.  Stinkier? Version *numbers* in source code.  More stinky than that? Version numbers in source code for projects that are never released to the public.

I care most about the development process, and much less about the release process.  If the release process is hard, that's an OK trade-off if the day-to-day development process is easy (1 release guy, 15 developers).   Also, I'd argue that version numbers are usually entirely artificial, and are actually a marketing/end-user construct, and having nothing to do with source code. (ideally, they can be applied at a packaging phase, but having nothing to do with compiling/building day-to-day).    Firefox went from 'normal versioning' to a major-release-every-month because they *can*.  It has no tie in to anything in reality other than user expectations.  

I'm a git user, and because git allows branching so easily, it allows expression of version in a very developer-friendly; through their branch.  If you are using git, every time you branch, you have just said, 'I made a version'. And if your poms don't reflect that, then you have interesting new problems arise (like a build server that tracks two branchs with the same version in the pom, meaning 'last-build-of-either-branch-wins' for SNAPSHOT.  That's no good, right?).   


To be clear, when I talk about 'version numbers', I'm not talking about build numbers. 

So in my ultimate desired versioning scheme, I'd like to version every last one of our projects this way, expressed as artifact names:


Remote Repository (Artifactory, etc) would only have artifacts named:

$company:$git-repository:$branch-$buildnumber
$company:$git-repository:$branch-SNAPSHOT

example:
acme:project-A:master-234
acme:project-A:master-SNAPSHOT
acme:project-B:master-100
acme:project-B:master-SNAPSHOT

Local Repository would only have artifacts named:
$company:$git-repository:$branch-local

example:
acme:project-A:master-local
acme:project-B:master-local



Now how would I use this scheme? 

Usage 1) I'm a project-B developer, and I *haven't checked* out project-A. I don't want to force developers to check out code that I don't need to complete a task.  Project-B depends on project-A.  Most of the time, I want my dependency to look like this:

<dependency>
<groupId>acme</groupId>
<artifactId>project-A</artifactId>
<version>master-SNAPSHOT</version>
</dependency>

translation: whatever the latest build on master is, I want it from the remote repository.  I want to have project-B float forward with project-A, and I don't want to actively maintain that relationship.  

Usage 2) If I want to use a particular build:
<version>master-234</version>

translation:  someone broke project-A:master-235 and above. I need to pin my version to avoid this bug.  Or maybe I'm working on a release variant of project-B, and I need to pin my project-A dependency. In either case, I'm still using the remote repository to resolve project-A artifacts.


Usage 3) If I want to checkout project-B, make a local-only code change, 'mvn install' it, then I can use MY version by updating my dependency to:
<version>master-local</version>

translation: project-A has a bug or feature I need.  I want to work on it in parallel with my changes to project-B without depending on a build server generating a project-A artifact, so I need a way to depend on project-A:master-local temporarily.


So, releasing is entirely orthogonal to this versioning scheme. I've uniquely tracked and built all of my artifacts; and that's good enough to hand off to someone else now.  A release team has all they need to go then try out builds, tag a build in SCM, or whatever else they want to do to release.


With all that said, I've come to realize that the versions:lock-snapshot plugin is the next best thing to having a 'local' dependency concept baked into maven (or into our workflow, as I'm trying to do)  It's a very good plugin and really works to the way maven wants you to, but I'd argue that maven needs more versioning conventions/capabilities.  Pinning to latest SNAPSHOT is clever, but that's not what i really care about. I want to pin to local; and so far have never wanted 'latest in time across both repositories'.

I *think* I can do what I want with this versioning scheme in maven.  The main way forward is to hardcode the version in the POM to something like:
<version>master-local</version>, and to override that in a build-server context with -Dproject.version=master-$BUILD_NUMBER. 

 The two challenges I have at the moment are:
1) dynamically changing version on branch (looks like I need git local hooks installed on every developer machine. not how i want to solve this at all). I believe the build system (maven) could and should allow this.
2) making sure I can publish both a master-SNAPSHOT artifact and a master-BUILDNUMBER artifact as the result of the same build (I'm assuming I can find a way.  I don't care if it's ugly because it'll be build-server only). 



By the way, super-poms are generally not something I want to use as a pattern.  The smaller the project, the better.  Large projects create a lot of  problems (higher SCM collisions, longer build times, bigger code bases which == scarier to new progammers).  While I know I can solve *some* versioning problems through super-poms, I am actively trying to avoid using those if I can help it.

Well, I hope I made a convincing enough use-case.  
Thanks!
Seth

On Wed, Mar 7, 2012 at 1:54 PM, stephenconnolly [via Maven] <[hidden email]> wrote:
My view is that there are places where stuff can be inferred, such as
groupId and version of children can be inferred *if and only if* the child
is always checked out with the parent (at the specified relative path)...
There are plans to tackle those cases.

There is, though a bit of a dual purpose to the Pom... One which may have
to be split... On the one hand the deployed Pom should be fully resolved,
and properties at those xpaths won't work... On the other hand, for
inheritance to work we need the deployed Pom to be fully unresolved...

From my point of view, those xpaths should never allow property expansion,
but more smarts in inferring based on other Pom files would be good...
Version numbers coming from a SCM branch name is a bad smell to me... So I
would not favour without a very good case being made

On Wednesday, 7 March 2012, Seth Call <[hidden email]> wrote:
> Hi Stephen,
>
> Thank you for clarifying.  That tells me what constraints I have to work
> with,  which is a big help.
>
> Is there any intent to change these restrictions?  I don't think anyone
> wants to change version mid-run (I've seen in other threads where you
> mention something about the reactor getting confused if the version were
to
> change mid-run?), but I think there is a desire to change it 'at the
start'
> of maven process execution in a more dynamic-yet-friendly way than just
> 'pass it in via command line'.
>
> The desire here, to be clear, is to give developers a correct default
> behavior when they type 'mvn clean install', and to never force them to
type

> -Dproject.version = something-wrong
>
> Matt (posted after you) wanted to do something similiar point with the
> buildnumber plugin, too.
>
> Seth
>
>
>
>
>
>
> --
> View this message in context:
http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5545298.html

> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>



If you reply to this email, your message will be added to the discussion below:
http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5545366.html
To unsubscribe from Is it possible to tie current git branch to project version?, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it possible to tie current git branch to project version?

Seth Call
In reply to this post by walshmatt
Matt, yes, thank you.

This is *exactly* what we encountered, too.  Branching *is* an expression of versioning; you have to reflect that in your pom, though, if some build system is building all these various branches and pushing these artifacts somewhere central.  I referred to this problem in previous post as the 'latest-branch-to-build-wins' problem.  

This is why I want to do <version>$branch-SNAPSHOT</version> or some such; if I can *declare* that, then I *know* the risk of failure is much less. I want to trust maven to resolving this variable, not the user. 

And as I'm sure you found out, tracking these sorts of issues are really really hard, and cause real head scratching moments. It's much harder when the versions are different only by a day; nothing hugely different stands out to make you think... Oh my gosh I'm somehow using a very old build!

A minor epiphany: a build-number is versioning for build servers, and branches are versioning for developers!  
Seth



On Wed, Mar 7, 2012 at 2:57 PM, walshmatt [via Maven] <[hidden email]> wrote:
Just a little anecdote here on the pitfalls of branching maven projects
without some kind of control.

We have a SNAPSHOT version for trunk. We use the maven-release-plugin to
create our maintenance branches at release time. The plugin, by default,
uses the current dev version on trunk as the branch version, and prompts
for a new trunk version. Perfect. That's exactly what we want.

A developer cut a dev branch from trunk several months ago, just using
the normal svn copy, and didn't think about changing the version. He
also created a Jenkins project for it. The dev branch sat untouched for
a couple of months, then a checkin triggered a new build. Later, we were
scratching our heads as to why another build dependent the trunk version
of that same artifact was failing. Turns out it was using the artifact
built from old code on the dev branch.

After some investigation, the developer was able to pinpoint the code,
which pointed to the maven artifact causing the problem.
We put the branch and revision from the buildnumber-maven-plugin into
the manifest, so we could see the artifact in question was built from
this rarely touched dev branch. From that we were able to track the
issue to the Jenkins build.

A reason to control branch versions. An argument to use project-specific
local repositories in Jenkins (see the "Maven concurrent builds" thread
from earlier today). A good use of the manifest. And possibly even an
argument in support of what you are looking for.

Matt

> -----Original Message-----
> From: Seth Call [mailto:[hidden email]]
> Sent: Wednesday, March 07, 2012 12:41 PM
> To: [hidden email]
> Subject: Re: Is it possible to tie current git branch to project
> version?
>
> Hi Matt,

>
> Thanks for the pointer to the release plugin.  My desire is to not
> control
> the process of making branches or changing versions through plugins.
I
> want developers to be able to use git for things branch related, and
> use
> maven for compile/build related.
>
> I think the release-plugin is trying to do too much (unless of course
> you
> want maven to do *everything* :) )  Regardless of my opinion, though,
> you
> are a big help.  I'll still try to find the route I'm trying to
take...

>
> Seth
>
> On Wed, Mar 7, 2012 at 10:03 AM, walshmatt [via Maven] <
> [hidden email]> wrote:

>
> > Seth.
> >
> > I tried doing something similar to this using the
> > buildnumber-maven-plugin. It returns the branch and revision number
> (I
> > use Subversion, not Git), but looks like you're trying something
> > similar.
> >
> > The problem I encountered (at least how I interpreted it) is that
the
> > plugin doesn't run soon enough - the pom has already been
interpreted
> > before the plugin is called, so the ${branch} wasn't resolved when I
> > needed it. I wasn't trying to change the version, but I was trying
to
> > use the property somewhere else. I think you'd have the same issue
> with
> > version though.
> >
> > You can use the maven-release-plugin to create your branch. It
> prompts
> > for a new version and updates and commits your poms automatically
(at

> > least for SVN). When/if you merge your changes back to the master
> > branch, you'd probably need to update your versions again, but that
> can
> > be accomplished with the versions plugin.
> >
> > HTH,
> > Matt
> >
> > > -----Original Message-----
> > > From: Seth Call [mailto:[hidden
> email]<http://user/SendEmail.jtp?type=node&node=5544568&i=0>]
> >
> > > Sent: Wednesday, March 07, 2012 8:19 AM
> > > To: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=5544568&i=1>
> > > Subject: Re: Is it possible to tie current git branch to project

> > > version?
> > >
> > > Hi Roy,
> > >
> > > I don't understand what 'tagging our repo' means.  Is this a
> feature
> > of
> >
> > > your remote repository?  Sorry... I googled but I don't know what
> you
> > > are
> > > saying...
> > >
> > > But aside from that, I really don't care about git hash in this
> > > question...
> > > let me explain what I'm trying to acheive...
> > >
> > >
> > >
> > > As a developer:
> > > * If I'm on branch master, I want my project version to be master-
> > > SNAPSHOT
> > >
> > > * If I'm on branch development, I want my project version to be
> > > development-SNAPSHOT
> > >
> > > I'd like that to happen automatically when I make the branch; I
> know
> > > this
> > > is rather dynamic so I assume a plugin at a minimum is required.
> I'm
> > > also
> > > not interested in using git local hooks if at all avoidable
because
> > > they
> > > have their own drawbacks.
> > >
> > > This versioning scheme is very important; making a branch is
making
> a
> > > new
> > > version.  So, downstream projects that depend on my
project:master-
> > > SNAPSHOT
> > > should *not* pickup my new branch's build artifact-not unless, of
> > > course, I
> > > go to that downstream project and change it's dependency version
to

> > say
> > > project:development-SNAPSHOT.
> > >
> > > In summary, they are different versions, and so if you don't
> version
> > > your
> > > project as you make a branch, then you will now have indeterminate
> > > build
> > > resolution because 'the-last-branch-you-build-will-win' sort of
> > > problems.
> > >  Also, all of this should work locally (not require a build
> server),
> > so
> >
> > > I'm
> > > limiting myself to maven-only techniques...
> > >
> > > Any help is greatly appreciated.  I hope there is some way to
> achieve
> > > this
> > > that I'm just not thinking of...
> > >
> > > But if anyone can say definitively that you can not put a variable
> in
> > > the
> > > <version> tag of an artifact, then I at least know a plugin-based
> > > solution
> > > is not an option.
> > >
> > > Regards,
> > > Seth
> > >
> > > On Wed, Mar 7, 2012 at 6:00 AM, Lyons, Roy [via Maven] <
> > > [hidden email]
> <http://user/SendEmail.jtp?type=node&node=5544568&i=2>>
> > wrote:

> > >
> > > > :-) we tag our repo with "branchname!RP-BL-mavenlabel" to help
in

> > > > location.  Rp is for release prepare and bl is for baseline
> > > (carryover from
> > > > clearcase terminology)
> > > >
> > > > Just remember that in git a hash doesn't belong to a branch, it
> is
> > > simply
> > > > attached to a linked list of hashes.  A "branch" is simply a tag
> > > pointing
> > > > to a hash being designated as a "head".  You can just as easily
> use
> > > the tag
> > > > created by the release plugin to checkout, and then make some
> bugfix
> > > branch
> > > > from that location.
> > > >
> > > >
> > > > Sent from my Blackberry.
> > > >
> > > > ----- Original Message -----
> > > > From: Seth Call <[hidden
> > > email]<http://user/SendEmail.jtp?type=node&node=5543915&i=0>>
> > > >
> > > > To: [hidden email]
> > > <http://user/SendEmail.jtp?type=node&node=5543915&i=1><[hidden
> > > > email] <http://user/SendEmail.jtp?type=node&node=5543915&i=2>>
> > > > Sent: Tue Mar 06 22:01:07 2012
> > > > Subject: Is it possible to tie current git branch to project
> > version?
> >
> > > >
> > > > Hi there,
> > > >
> > > > I've seen indication when searching the internet that it isn't
> > > possible to
> > > > put variables in <version> of a project (unless those variables
> are
> > > > hardcoded <properties> or provided at the command line), but I
> > > thought I'd
> > > > ask the list ...
> > > >
> > > > Say there was a plugin that would invoke 'git branch' to
> determine
> > > the
> > > > current branch, and to then make that available to the project
as
> a
> > > > variable; call it ${branch}.   I'd like to use this variable
then

> in
> > > the
> > > > version tag:
> > > >
> > > > <project>
> > > > <groupId>blah</groupId>
> > > > <artifactId>blah</artifactId>
> > > > <version>${branch}-SNAPSHOT</version>
> > > > </project>
> > > >
> > > > The reason I want to do this is that I'm realizing, for our
> > internal-
> > > only
> > > > code projects, that a branch is always synonymous with a version
> of
> > a
> >
> > > > project, and ideally the act of being of switching branches
would

> be
> > > all
> > > > it
> > > > takes to switch your maven project's version.
> > > >
> > > > Is this possible if I were to make a maven plugin?
> > > >
> > > > Thanks!
> > > > Seth
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > View this message in context:
> > > > http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-
> git-
> > > branch-to-project-version-tp5543110p5543110.html
> > > > Sent from the Maven - Users mailing list archive at Nabble.com.
> > > >
> > > >
> >
---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: [hidden
> > > email]<http://user/SendEmail.jtp?type=node&node=5543915&i=3>
> > > > For additional commands, e-mail: [hidden
> > > email]<http://user/SendEmail.jtp?type=node&node=5543915&i=4>
> > > >
> > > >
> > > >
> >
---------------------------------------------------------------------

> >
> > > > To unsubscribe, e-mail: [hidden
> > > email]<http://user/SendEmail.jtp?type=node&node=5543915&i=5>
> > > > For additional commands, e-mail: [hidden
> > > email]<http://user/SendEmail.jtp?type=node&node=5543915&i=6>
> > > >
> > > >
> > > > ------------------------------
> > > >  If you reply to this email, your message will be added to the
> > > discussion
> > > > below:
> > > >
> > > > http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-
> git-
> > > branch-to-project-version-tp5543110p5543915.html
> > > >  To unsubscribe from Is it possible to tie current git branch to
> > > project
> > > > version?, click
> > >
> >
>
here<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=un
> > >
> >
>
subscribe_by_code&node=5543110&code=c2V0aGNhbGxAZ21haWwuY29tfDU1NDMxMTB
> > > 8LTU5NTg4MjI5Nw==>
> > > > .
> > > >
> > >
> >
>
NAML<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=ma
> > >
> >
>
cro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.names
> > > paces.BasicNamespace-nabble.view.web.template.NabbleNamespace-
> > >
> >
>
nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%2

> >
> > > 1nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-
> > > send_instant_email%21nabble%3Aemail.naml>
> > > >
> > >
> > >
> > > --
> > > View this message in context: http://maven.40175.n5.nabble.com/Is-
> it-
> > > possible-to-tie-current-git-branch-to-project-version-
> > > tp5543110p5544417.html
> > > Sent from the Maven - Users mailing list archive at Nabble.com.
> >
> >
> ______________________________________________________________________
> > This message, including any attachments, is confidential and
contains
> > information intended only for the person(s) named above. Any other
> > distribution, copying or disclosure is strictly prohibited. If you
> are not
> > the intended recipient or have received this message in error,
please
> > notify us immediately by reply email and permanently delete the
> original
> > transmission from all of your systems and hard drives, including any
> > attachments, without making a copy.
> >
> >
---------------------------------------------------------------------

> > To unsubscribe, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=5544568&i=3>
> > For additional commands, e-mail: [hidden
> email]<http://user/SendEmail.jtp?type=node&node=5544568&i=4>
> >
> >
> >
> > ------------------------------
> >  If you reply to this email, your message will be added to the
> discussion
> > below:
> >
> > http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-
> branch-to-project-version-tp5543110p5544568.html
> >  To unsubscribe from Is it possible to tie current git branch to
> project
> > version?, click
>
here<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=un
>
subscribe_by_code&node=5543110&code=c2V0aGNhbGxAZ21haWwuY29tfDU1NDMxMTB
> 8LTU5NTg4MjI5Nw==>
> > .
> >
>
NAML<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=ma
>
cro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.names
> paces.BasicNamespace-nabble.view.web.template.NabbleNamespace-
>
nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%2

> 1nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-
> send_instant_email%21nabble%3Aemail.naml>
> >
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/Is-it-
> possible-to-tie-current-git-branch-to-project-version-
> tp5543110p5545345.html
> Sent from the Maven - Users mailing list archive at Nabble.com.

______________________________________________________________________
This message, including any attachments, is confidential and contains information intended only for the person(s) named above. Any other distribution, copying or disclosure is strictly prohibited. If you are not the intended recipient or have received this message in error, please notify us immediately by reply email and permanently delete the original transmission from all of your systems and hard drives, including any attachments, without making a copy.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




If you reply to this email, your message will be added to the discussion below:
http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5545537.html
To unsubscribe from Is it possible to tie current git branch to project version?, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it possible to tie current git branch to project version?

stephenconnolly
In reply to this post by Seth Call
On 7 March 2012 20:59, Seth Call <[hidden email]> wrote:
> Bad smell eh?  Ok, here's my bad smell.  Version numbers.  Stinkier?
> Version *numbers* in source code.  More stinky than that? Version numbers
> in source code for projects that are never released to the public.
>

You are confusing two concepts:

* version names - these are the marketing numbers associated with a product

* version numbers - these are the internal development defined version numbers

there may be many builds each with a different version number but
tagged with the same version name... at the end of the day, only one
of those version numbers will be released, so that the public sees a
1:1 but actually behind the scenes there is a N:1

> I care most about the development process, and much less about the release
> process.  If the release process is hard, that's an OK trade-off if the
> day-to-day development process is easy (1 release guy, 15 developers).
> Also, I'd argue that version numbers are usually entirely artificial, and
> are actually a marketing/end-user construct, and having nothing to do with
> source code.

That is version names you are thinking of.

> (ideally, they can be applied at a packaging phase, but having
> nothing to do with compiling/building day-to-day).    Firefox went from
> 'normal versioning' to a major-release-every-month because they *can*.  It
> has no tie in to anything in reality other than user expectations.
>
> I'm a git user, and because git allows branching so easily, it allows
> expression of version in a very developer-friendly; through their branch.
>  If you are using git, every time you branch, you have just said, 'I made a
> version'. And if your poms don't reflect that, then you have interesting
> new problems arise (like a build server that tracks two branchs with the
> same version in the pom, meaning 'last-build-of-either-branch-wins' for
> SNAPSHOT.  That's no good, right?).

Well here is the rub... say you checkout 1a2b3c4d

build that... according to you that would be version
1a2b3c4d-SNAPSHOT? or would it be 1a2b3c4d

modify some one file and don't check in... build it again... what is
it now? it's not 1a2b3c4d because you cannot reproduce it... so it
would have to be 1a2b3c4d-SNAPSHOT.... except it's not that either,
because -SNAPSHOT implies it will eventually become 1a2b3c4d which it
cannot as you are working on the next revision which is likely
9f8e7d6c only we cannot know that...

and in git both branches and tags are completely mutable and just
pointers... can't use them...

I think you need to think about this a little more.
>
>
> To be clear, when I talk about 'version numbers', I'm not talking about
> build numbers.

Never thought you were.

>
> So in my ultimate desired versioning scheme, I'd like to version every last
> one of our projects this way, expressed as artifact names:
>
>
> Remote Repository (Artifactory, etc) would only have artifacts named:
>
> $company:$git-repository:$branch-$buildnumber
> $company:$git-repository:$branch-SNAPSHOT
>

I suspect that you don't fully understand how git branches work... but
I am willing to be proved wrong ;-)

branch names are not canonical... I can call it anything I like on my side...

git push -u origin trunk:master

oh look locally my branch is called trunk because I don't like calling
it master...

oh look fred's local name for the master branch is called fubar

totally mutable

> example:
> acme:project-A:master-234
> acme:project-A:master-SNAPSHOT
> acme:project-B:master-100
> acme:project-B:master-SNAPSHOT
>
> Local Repository would only have artifacts named:
> $company:$git-repository:$branch-local
>
> example:
> acme:project-A:master-local
> acme:project-B:master-local
>
>
>
> Now how would I use this scheme?
>
> Usage 1) I'm a project-B developer, and I *haven't checked* out project-A.
> I don't want to force developers to check out code that I don't need to
> complete a task.  Project-B depends on project-A.  Most of the time, I want
> my dependency to look like this:
>
> <dependency>
> <groupId>acme</groupId>
> <artifactId>project-A</artifactId>
> <version>master-SNAPSHOT</version>
> </dependency>
>
> translation: whatever the latest build on master is, I want it from the
> remote repository.  I want to have project-B float forward with project-A,
> and I don't want to actively maintain that relationship.
>
> Usage 2) If I want to use a particular build:
> <version>master-234</version>

git tags do not increase as they are hashes, so you cannot use the
hash to determine sequencing.

>
> translation:  someone broke project-A:master-235 and above. I need to pin
> my version to avoid this bug.  Or maybe I'm working on a release variant of
> project-B, and I need to pin my project-A dependency. In either case, I'm
> still using the remote repository to resolve project-A artifacts.
>
>
> Usage 3) If I want to checkout project-B, make a local-only code change,
> 'mvn install' it, then I can use MY version by updating my dependency to:
> <version>master-local</version>
>
> translation: project-A has a bug or feature I need.  I want to work on it
> in parallel with my changes to project-B without depending on a build
> server generating a project-A artifact, so I need a way to depend on
> project-A:master-local temporarily.
>
>
> So, releasing is entirely orthogonal to this versioning scheme. I've
> uniquely tracked and built all of my artifacts; and that's good enough to
> hand off to someone else now.  A release team has all they need to go then
> try out builds, tag a build in SCM, or whatever else they want to do to
> release.
>
>
> With all that said, I've come to realize that the versions:lock-snapshot
> plugin is the next best thing to having a 'local' dependency concept baked
> into maven (or into our workflow, as I'm trying to do)  It's a very good
> plugin and really works to the way maven wants you to, but I'd argue that
> maven needs more versioning conventions/capabilities.  Pinning to latest
> SNAPSHOT is clever, but that's not what i really care about. I want to pin
> to local; and so far have never wanted 'latest in time across both
> repositories'.
>
> I *think* I can do what I want with this versioning scheme in maven.  The
> main way forward is to hardcode the version in the POM to something like:
> <version>master-local</version>, and to override that in a build-server
> context with -Dproject.version=master-$BUILD_NUMBER.
>
>  The two challenges I have at the moment are:
> 1) dynamically changing version on branch (looks like I need git local
> hooks installed on every developer machine. not how i want to solve this at
> all). I believe the build system (maven) could and should allow this.
> 2) making sure I can publish both a master-SNAPSHOT artifact and a
> master-BUILDNUMBER artifact as the result of the same build (I'm assuming I
> can find a way.  I don't care if it's ugly because it'll be build-server
> only).
>
>
>
> By the way, super-poms are generally not something I want to use as a
> pattern.  The smaller the project, the better.  Large projects create a lot
> of  problems (higher SCM collisions, longer build times, bigger code bases
> which == scarier to new progammers).  While I know I can solve *some*
> versioning problems through super-poms, I am actively trying to avoid using
> those if I can help it.
>
> Well, I hope I made a convincing enough use-case.
> Thanks!
> Seth
>
> On Wed, Mar 7, 2012 at 1:54 PM, stephenconnolly [via Maven] <
> [hidden email]> wrote:
>
>> My view is that there are places where stuff can be inferred, such as
>> groupId and version of children can be inferred *if and only if* the child
>> is always checked out with the parent (at the specified relative path)...
>> There are plans to tackle those cases.
>>
>> There is, though a bit of a dual purpose to the Pom... One which may have
>> to be split... On the one hand the deployed Pom should be fully resolved,
>> and properties at those xpaths won't work... On the other hand, for
>> inheritance to work we need the deployed Pom to be fully unresolved...
>>
>> From my point of view, those xpaths should never allow property expansion,
>> but more smarts in inferring based on other Pom files would be good...
>> Version numbers coming from a SCM branch name is a bad smell to me... So I
>> would not favour without a very good case being made
>>
>> On Wednesday, 7 March 2012, Seth Call <[hidden email]<http://user/SendEmail.jtp?type=node&node=5545366&i=0>>
>> wrote:
>> > Hi Stephen,
>> >
>> > Thank you for clarifying.  That tells me what constraints I have to work
>> > with,  which is a big help.
>> >
>> > Is there any intent to change these restrictions?  I don't think anyone
>> > wants to change version mid-run (I've seen in other threads where you
>> > mention something about the reactor getting confused if the version were
>> to
>> > change mid-run?), but I think there is a desire to change it 'at the
>> start'
>> > of maven process execution in a more dynamic-yet-friendly way than just
>> > 'pass it in via command line'.
>> >
>> > The desire here, to be clear, is to give developers a correct default
>> > behavior when they type 'mvn clean install', and to never force them to
>> type
>>
>> > -Dproject.version = something-wrong
>> >
>> > Matt (posted after you) wanted to do something similiar point with the
>> > buildnumber plugin, too.
>> >
>> > Seth
>> >
>> >
>> >
>> >
>> >
>> >
>> > --
>> > View this message in context:
>>
>> http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5545298.html
>>
>> > Sent from the Maven - Users mailing list archive at Nabble.com.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5545366&i=1>
>> > For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5545366&i=2>
>> >
>> >
>>
>>
>> ------------------------------
>>  If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5545366.html
>>  To unsubscribe from Is it possible to tie current git branch to project
>> version?, click here<
>> .
>> NAML<
http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5545543.html
> Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it possible to tie current git branch to project version?

Seth Call
Thanks for replying Stephen.  Inline to your inline!

Seth

On Wed, Mar 7, 2012 at 3:42 PM, stephenconnolly [via Maven] <[hidden email]> wrote:
On 7 March 2012 20:59, Seth Call <[hidden email]> wrote:
> Bad smell eh?  Ok, here's my bad smell.  Version numbers.  Stinkier?
> Version *numbers* in source code.  More stinky than that? Version numbers
> in source code for projects that are never released to the public.
>

You are confusing two concepts:

* version names - these are the marketing numbers associated with a product

* version numbers - these are the internal development defined version numbers

there may be many builds each with a different version number but
tagged with the same version name... at the end of the day, only one
of those version numbers will be released, so that the public sees a
1:1 but actually behind the scenes there is a N:1 

I'll try to be more clear; I think I'm just not coming across. I don't care about the major/minor version numbers found in the maven versioning scheme for internal projects.  If I pick a number, I have to make an effort to coerce that into meaning something, and communicate that to the team.  No need to do that.  Branches, however, often have meaning to people.  master often means 'stable' in git.  'development' might be a noisier branch.  I might make a branch per JIRA bug.  Whatever; let the team decide, ala: http://nvie.com/posts/a-successful-git-branching-model/.   But point is, the team would or should agree to their meaning.  Making a branch called 'abeouaeou' is also just noise; I'd discourage that, but I don't think I'd have to.  If I *do* have to enforce branch naming, i can do it with server-side git hooks; something that I find reasonable.

ALso, specific to your point about version numbers and version names--I'd say *both* have no meaning to me for internal projects.  
 
 

> I care most about the development process, and much less about the release
> process.  If the release process is hard, that's an OK trade-off if the
> day-to-day development process is easy (1 release guy, 15 developers).
> Also, I'd argue that version numbers are usually entirely artificial, and
> are actually a marketing/end-user construct, and having nothing to do with
> source code.

That is version names you are thinking of.

(covered already, but just to be clear) I mean the major/minor versioning described in the maven versioning scheme. 

 'Branch', 'build number', and 'locally built' are the only 3 concepts I care about in terms of constructing a versioning scheme, and supporting the idea of 'latest' on a branch is important too.

> (ideally, they can be applied at a packaging phase, but having
> nothing to do with compiling/building day-to-day).    Firefox went from
> 'normal versioning' to a major-release-every-month because they *can*.  It
> has no tie in to anything in reality other than user expectations.
>
> I'm a git user, and because git allows branching so easily, it allows
> expression of version in a very developer-friendly; through their branch.
>  If you are using git, every time you branch, you have just said, 'I made a
> version'. And if your poms don't reflect that, then you have interesting
> new problems arise (like a build server that tracks two branchs with the
> same version in the pom, meaning 'last-build-of-either-branch-wins' for
> SNAPSHOT.  That's no good, right?).
Well here is the rub... say you checkout 1a2b3c4d

build that... according to you that would be version
1a2b3c4d-SNAPSHOT? or would it be 1a2b3c4d

modify some one file and don't check in... build it again... what is
it now? it's not 1a2b3c4d because you cannot reproduce it... so it
would have to be 1a2b3c4d-SNAPSHOT.... except it's not that either,
because -SNAPSHOT implies it will eventually become 1a2b3c4d which it
cannot as you are working on the next revision which is likely
9f8e7d6c only we cannot know that...

and in git both branches and tags are completely mutable and just
pointers... can't use them...

I think you need to think about this a little more.

I don't care to have a git hash in a build artifact; sorry if that was how I came across (I assume you are making hashes).  

When I write master-234, I mean branch + build_number_from_build_server.  If I could shoe-horn the hash in the build artifact after getting all the rest of this to work for build-server built projects, then I will, because it helps you correlate to build-number-to-git-hash, but it's not a requirement.
 
>
>
> To be clear, when I talk about 'version numbers', I'm not talking about
> build numbers.

Never thought you were.

>
> So in my ultimate desired versioning scheme, I'd like to version every last
> one of our projects this way, expressed as artifact names:
>
>
> Remote Repository (Artifactory, etc) would only have artifacts named:
>
> $company:$git-repository:$branch-$buildnumber
> $company:$git-repository:$branch-SNAPSHOT
>
I suspect that you don't fully understand how git branches work... but
I am willing to be proved wrong ;-)

branch names are not canonical... I can call it anything I like on my side...

git push -u origin trunk:master

oh look locally my branch is called trunk because I don't like calling
it master...

oh look fred's local name for the master branch is called fubar

totally mutable


Good point, but not an issue.  If you really want to make your own-named branch locally correlated to a different-named branch in the origin repository, that is a total non-issue until something else *locally* needs to  *depend* on the artifact that is created as a result of your local build.  When that happens, you have to now change this  project's dependency in the downstream project.  I'd consider that acceptable, because, if you already have to write 'master-local' in the version field of a downstream project manually when you want to use a locally built artifact on a particular branch, then I don't mind you having to instead write 'mymaster-local' because I got creative with my local branch name.  The 'changing dependency version manually' egg has already been broken in my scheme; it doesn't matter to what extent it's broken to me.

> example:

> acme:project-A:master-234
> acme:project-A:master-SNAPSHOT
> acme:project-B:master-100
> acme:project-B:master-SNAPSHOT
>
> Local Repository would only have artifacts named:
> $company:$git-repository:$branch-local
>
> example:
> acme:project-A:master-local
> acme:project-B:master-local
>
>
>
> Now how would I use this scheme?
>
> Usage 1) I'm a project-B developer, and I *haven't checked* out project-A.
> I don't want to force developers to check out code that I don't need to
> complete a task.  Project-B depends on project-A.  Most of the time, I want
> my dependency to look like this:
>
> <dependency>
> <groupId>acme</groupId>
> <artifactId>project-A</artifactId>
> <version>master-SNAPSHOT</version>
> </dependency>
>
> translation: whatever the latest build on master is, I want it from the
> remote repository.  I want to have project-B float forward with project-A,
> and I don't want to actively maintain that relationship.
>
> Usage 2) If I want to use a particular build:
> <version>master-234</version>
git tags do not increase as they are hashes, so you cannot use the
hash to determine sequencing.

That  -234 is a build-server originated number, not git hash.  I don't want developer machines to ever make build-number containing artifacts for any reason.  The build server is the only source of that.  It will be always increasing. Or had better! :)

>
> translation:  someone broke project-A:master-235 and above. I need to pin
> my version to avoid this bug.  Or maybe I'm working on a release variant of
> project-B, and I need to pin my project-A dependency. In either case, I'm
> still using the remote repository to resolve project-A artifacts.
>
>
> Usage 3) If I want to checkout project-B, make a local-only code change,
> 'mvn install' it, then I can use MY version by updating my dependency to:
> <version>master-local</version>
>
> translation: project-A has a bug or feature I need.  I want to work on it
> in parallel with my changes to project-B without depending on a build
> server generating a project-A artifact, so I need a way to depend on
> project-A:master-local temporarily.
>
>
> So, releasing is entirely orthogonal to this versioning scheme. I've
> uniquely tracked and built all of my artifacts; and that's good enough to
> hand off to someone else now.  A release team has all they need to go then
> try out builds, tag a build in SCM, or whatever else they want to do to
> release.
>
>
> With all that said, I've come to realize that the versions:lock-snapshot
> plugin is the next best thing to having a 'local' dependency concept baked
> into maven (or into our workflow, as I'm trying to do)  It's a very good
> plugin and really works to the way maven wants you to, but I'd argue that
> maven needs more versioning conventions/capabilities.  Pinning to latest
> SNAPSHOT is clever, but that's not what i really care about. I want to pin
> to local; and so far have never wanted 'latest in time across both
> repositories'.
>
> I *think* I can do what I want with this versioning scheme in maven.  The
> main way forward is to hardcode the version in the POM to something like:
> <version>master-local</version>, and to override that in a build-server
> context with -Dproject.version=master-$BUILD_NUMBER.
>
>  The two challenges I have at the moment are:
> 1) dynamically changing version on branch (looks like I need git local
> hooks installed on every developer machine. not how i want to solve this at
> all). I believe the build system (maven) could and should allow this.
> 2) making sure I can publish both a master-SNAPSHOT artifact and a
> master-BUILDNUMBER artifact as the result of the same build (I'm assuming I
> can find a way.  I don't care if it's ugly because it'll be build-server
> only).
>
>
>
> By the way, super-poms are generally not something I want to use as a
> pattern.  The smaller the project, the better.  Large projects create a lot
> of  problems (higher SCM collisions, longer build times, bigger code bases
> which == scarier to new progammers).  While I know I can solve *some*
> versioning problems through super-poms, I am actively trying to avoid using
> those if I can help it.
>
> Well, I hope I made a convincing enough use-case.
> Thanks!
> Seth
>
> On Wed, Mar 7, 2012 at 1:54 PM, stephenconnolly [via Maven] <
> [hidden email]> wrote:

>
>> My view is that there are places where stuff can be inferred, such as
>> groupId and version of children can be inferred *if and only if* the child
>> is always checked out with the parent (at the specified relative path)...
>> There are plans to tackle those cases.
>>
>> There is, though a bit of a dual purpose to the Pom... One which may have
>> to be split... On the one hand the deployed Pom should be fully resolved,
>> and properties at those xpaths won't work... On the other hand, for
>> inheritance to work we need the deployed Pom to be fully unresolved...
>>
>> From my point of view, those xpaths should never allow property expansion,
>> but more smarts in inferring based on other Pom files would be good...
>> Version numbers coming from a SCM branch name is a bad smell to me... So I
>> would not favour without a very good case being made
>>
>> On Wednesday, 7 March 2012, Seth Call <[hidden email]<http://user/SendEmail.jtp?type=node&node=5545366&i=0>>
>> wrote:

>> > Hi Stephen,
>> >
>> > Thank you for clarifying.  That tells me what constraints I have to work
>> > with,  which is a big help.
>> >
>> > Is there any intent to change these restrictions?  I don't think anyone
>> > wants to change version mid-run (I've seen in other threads where you
>> > mention something about the reactor getting confused if the version were
>> to
>> > change mid-run?), but I think there is a desire to change it 'at the
>> start'
>> > of maven process execution in a more dynamic-yet-friendly way than just
>> > 'pass it in via command line'.
>> >
>> > The desire here, to be clear, is to give developers a correct default
>> > behavior when they type 'mvn clean install', and to never force them to
>> type
>>
>> > -Dproject.version = something-wrong
>> >
>> > Matt (posted after you) wanted to do something similiar point with the
>> > buildnumber plugin, too.
>> >
>> > Seth
>> >
>> >
>> >
>> >
>> >
>> >
>> > --
>> > View this message in context:
>>
>> http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5545298.html
>>
>> > Sent from the Maven - Users mailing list archive at Nabble.com.
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5545366&i=1>
>> > For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5545366&i=2>
>> >
>> >
>>
>>
>> ------------------------------
>>  If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5545366.html
>>  To unsubscribe from Is it possible to tie current git branch to project
>> version?, click here<
>> .
>> NAML<
http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>>
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5545543.html

> Sent from the Maven - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




If you reply to this email, your message will be added to the discussion below:
http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5545703.html
To unsubscribe from Is it possible to tie current git branch to project version?, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it possible to tie current git branch to project version?

Gustavo Leite de Mendonça Chaves
In reply to this post by Seth Call
2012/3/8  <[hidden email]>:
>
> users Digest of: get.126118
>
> Re: Is it possible to tie current git branch to project version?
>        126118 by: Seth Call
>
> Bad smell eh?  Ok, here's my bad smell.  Version numbers.  Stinkier?
> Version *numbers* in source code.  More stinky than that? Version numbers
> in source code for projects that are never released to the public.

Hi Seth,

I think you hit the nail in the head when you questioned the semantics
of artifact versions yesterday.
I was researching this same problem and it came as a nice surprise to
see that your suggestion of
tying versions with branch names is exactly the one I was coming to.

I’d like to go a little bit further in your proposal and see what you
think. (I may be missing something
trivial because I’m not a Java programmer, but I do support a few
dozens of them by maintaining
their tool chain: Subversion, JIRA, Jenkins, Sonar, Maven, Nexus, etc.
Please, bear with me.)

The proposal would be along these lines:

* The POM artifact version tag could be specified something like this:
<version>${scm.version}</version>

* There should be a maven plugin that could derive the artifact
version from the SCM in the following way:

** If there is a tag associated with the current revision and it
complies with a specific syntax
(which would default to something like /^v(\d+\.\d+\.\d+)$/, but which
could be redefined by configuration)
then the ${scm.version} property would be taken from the tag name as
the group inside the parenthesis.
(E.g., if the tag is “v1.1.2” the version would be “1.1.2”.)

** Otherwise, the ${scm.version} property would be the current branch
name suffixed with “-SNAPSHOT”.
(E.g., “master-SNAPSHOT”.)

What benefits this would bring? Mainly, you would not need to ever
edit artifact version numbers again.

As it is now, when you create a release branch you have to edit the
POMs in the branch (to strip the
-SNAPSHOT suffix) and also edit the POMs in the trunk/master (to bump
the version number) in order
to differentiate versions and avoid the risk of collisions in
deployment. This can be made easier by the
Maven Release Plugin, but the amount of work it does to make all this
editing is a bad smell to me.

Feature branches are even worse. (I suspect that this is one of the
reasons why feature branches are
despised by some people
[http://martinfowler.com/bliki/FeatureBranch.html]. But they are wrong
[http://jamesmckay.net/2011/07/why-does-martin-fowler-not-understand-feature-branches/],
and I digress.)
Since it’s not for a release it doesn’t make much sense to change
version “numbers” in any POM.
However, you’re forced to come up with an artificial new version in
the POMs either in the branch
or in master so that you don’t run the risk of collisions in
deployment. Being forced to make-up
versions are another bad smell to me.

Moreover, since feature branches are frequently rebased with master,
whenever master changes
versions they are carried over in the next rebase and you have to be
very careful to manually accept,
reject or fix conflicts in the merge. Of course, when the branch is
ready for the reintegration merge to
master, this will happen again, only more so because reintegration
merges done wrong have bigger
implications.

Now, with this new scheme in place you don’t have to bother anymore
with version editing, because
all versions are automatically derived from the SCM context, which is
the authoritative place where
you manage your product versions anyway.

I had one minor epiphany too while thinking about this. There are good
reasons to use the semantic
versioning scheme [http://semver.org/] for released code. One of them
is that you need to be able to
order versions sequentially. In particular, you need it to be able to
specify dependencies from version
ranges. However, as you pointed out, branches are “development
versions”. And these development
versions don’t need to be ordered, just uniquely identified. For
instance, when I create a feature branch
it doesn’t matter what was the most recent released version number nor
how many releases will be cut
until the branch it is reintegrated. All that matters is that this
branch is developing a unique version which
is different from all other branches and releases. Usually, I want to
use the latest artifact built from it,
i.e., its SNAPSHOT.

Now, the drawbacks... and some doubts.

I understand that currently no such plugin can be implemented for
maven due to a restriction on the
expansion of variables in the version tag. However, since it’s
possible to specify a version in the
command line, it’s at least feasible to try the scheme to see how it
works. I did it in a small example
and it worked fine as far as I could tell. I was able to install the
artifact by calling maven with the
option “-Dscm.version=branch-SNAPSHOT” and it installed it correctly.

Also, I’m not sure about the consequences of not using the maven
standard versioning scheme
[http://www.sonatype.com/books/mvnref-book/reference/pom-relationships-sect-pom-syntax.html]
while deploying MRMs, like Nexus. In my small test I was able to
deploy the branch-SNAPSHOT
version successfully. Can you foresee any problem?

Inferring branch and tag names from a Subversion working copy
necessarily involves adherence to
conversions (/trunk, /tags, /branches). But in Git or Mercurial it is trivial.


It’s interesting to notice that this scheme is not completely new. In
the Perl development community,
Dist::Zilla [http://dzil.org/] is a tool performing similar
functionality as Maven does for Java. One of the
things it does quite well is to manage package version numbers automatically
[http://dzil.org/tutorial/versioning.html]. As far as I know it does
not have the equivalent of versioning
by branch name. But it has an equivalent of the Maven Release Plugin
that can infer the release
version number from the tags it finds in the SCM. It works
particularly well with the ::Git::NextVersion
plugin [http://search.cpan.org/dist/Dist-Zilla-Plugin-Git/lib/Dist/Zilla/Plugin/Git/NextVersion.pm].

So, what do you think?

Gustavo.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it possible to tie current git branch to project version?

Seth Call
Hi Gustavo,

Wow, the tagging idea is dead on.

With what I proposed, I didn't really address or solve how something was released..  I just assumed when you took a build from your build server to production, you could just tag the build in your branch for record keeping, and away you go.

However, I like what you suggestion a great deal, because it allows this flow:

1) Developer is working on 'develop' branch.  
2) Developer merges into master. Commits.
3) Build server builds master-26. (To bo clear, I assume the  build server dual publishes master-26 along with master-SNAPSHOT... same artifact, but different versions, so that I have a trail of builds as well as supporting snapshot versioning).
4) QA verifies master-26, tells ops 'this is a good build'.
5**) OPS tags master-26 with tag, '1.1.2'
6**) OPS manually starts build on that specific commit using build server.  
7**) 1.1.2 tag is incorporated into version; artifact is labeled: 1.1.2.
8**) OPS deploys 1.1.2.

(instead of 5-8 being a sloppier 'I stuck master-26 into production, and tagged after the fact)

Previous to your post, I just thought of a tag helping one track/correlate what you released.  But your tag workflow encourages one to tag up front and *then* build, ensuring that the act of tagging occurred; and it also encourages a tag scheme that makes sense for your 'external' versioning scheme.  Also, I like that changes to the SCM *have* to occur *before* hand-offs to the next phase. Developer has to commit; a publisher has to tag.  Consistent.  You have to actually express your intent into the SCM before you get what you want.

You could even enforce the tag convention by only doing some important part of the build to make the artifact a 'release build' or 'activated' in some way that non-tagged builds aren't.

This particular 'scm as versioning truth' scheme, coupled with a build server,  allows a very natural hand-off between developer/qa/ops, and all teams communicate what actually happened with one technology; the SCM.  The SCM conveys what happened throughout the entire lifecycle, and the versioning of everything built is also tightly coupled to the SCM.  (well, one gap; I would like to shoe-horn the git hash next to the build number for build-server artifacts, but only if it doesn't affect all my other goals).

But the critical question you ask... is maven OK with this versioning.  I also have seen that maven seems OK with this versioning in my tests. But I fear my simple tests haven't found a big 'oh no'.  I hope someone else could weigh in who has a deep understanding of maven internally.

And still, the fact we have to use the command-line to achieve this versioning scheme is not OK. On a build server? Sure.  But for developer usage, not OK.  I still strongly hope Maven could resolve this by allowing variables in <version> that were set *very* early in the maven process.  This should be possible with a plugin!

Thanks for weighing in.  I was wondering if we were alone/rare in our desired workflow... hopefully not!
Seth
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it possible to tie current git branch to project version?

Seth Call
Ugh. Should have proof-read better. Step 5 should read:

OPS tags **the specific git commit associated with master-26** with the tag, '1.1.2' 

(so it's clear that -26 is a build number, and not a poorly written git hash example)
Seth

On Thu, Mar 8, 2012 at 8:59 PM, Seth Call [via Maven] <[hidden email]> wrote:
Hi Gustavo,

Wow, the tagging idea is dead on.

With what I proposed, I didn't really address or solve how something was released..  I just assumed when you took a build from your build server to production, you could just tag the build in your branch for record keeping, and away you go.

However, I like what you suggestion a great deal, because it allows this flow:

1) Developer is working on 'develop' branch.  
2) Developer merges into master. Commits.
3) Build server builds master-26. (To bo clear, I assume the  build server dual publishes master-26 along with master-SNAPSHOT... same artifact, but different versions, so that I have a trail of builds as well as supporting snapshot versioning).
4) QA verifies master-26, tells ops 'this is a good build'.
5**) OPS tags master-26 with tag, '1.1.2'
6**) OPS manually starts build on that specific commit using build server.  
7**) 1.1.2 tag is incorporated into version; artifact is labeled: 1.1.2.
8**) OPS deploys 1.1.2.

(instead of 5-8 being a sloppier 'I stuck master-26 into production, and tagged after the fact)

Previous to your post, I just thought of a tag helping one track/correlate what you released.  But your tag workflow encourages one to tag up front and *then* build, ensuring that the act of tagging occurred; and it also encourages a tag scheme that makes sense for your 'external' versioning scheme.  Also, I like that changes to the SCM *have* to occur *before* hand-offs to the next phase. Developer has to commit; a publisher has to tag.  Consistent.  You have to actually express your intent into the SCM before you get what you want.

You could even enforce the tag convention by only doing some important part of the build to make the artifact a 'release build' or 'activated' in some way that non-tagged builds aren't.

This particular 'scm as versioning truth' scheme, coupled with a build server,  allows a very natural hand-off between developer/qa/ops, and all teams communicate what actually happened with one technology; the SCM.  The SCM conveys what happened throughout the entire lifecycle, and the versioning of everything built is also tightly coupled to the SCM.  (well, one gap; I would like to shoe-horn the git hash next to the build number for build-server artifacts, but only if it doesn't affect all my other goals).

But the critical question you ask... is maven OK with this versioning.  I also have seen that maven seems OK with this versioning in my tests. But I fear my simple tests haven't found a big 'oh no'.  I hope someone else could weigh in who has a deep understanding of maven internally.

And still, the fact we have to use the command-line to achieve this versioning scheme is not OK. On a build server? Sure.  But for developer usage, not OK.  I still strongly hope Maven could resolve this by allowing variables in <version> that were set *very* early in the maven process.  This should be possible with a plugin!

Thanks for weighing in.  I was wondering if we were alone/rare in our desired workflow... hopefully not!
Seth


If you reply to this email, your message will be added to the discussion below:
http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5549516.html
To unsubscribe from Is it possible to tie current git branch to project version?, click here.
NAML

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it possible to tie current git branch to project version?

Gustavo Leite de Mendonça Chaves
In reply to this post by Seth Call
2012/3/8 Seth Call <[hidden email]>
>
> Hi Gustavo,
>
> Wow, the tagging idea is dead on.

I'm glad that you liked it.

> However, I like what you suggestion a great deal, because it allows this flow:

Which seems very reasonable to me. Even more so because you wouldn't
have to deal with POM editing and spurious merge conflicts anymore!
Smooth and simple...

> Previous to your post, I just thought of a tag helping one track/correlate
> what you released.  But your tag workflow encourages one to tag up front
> and *then* build, ensuring that the act of tagging occurred; and it also
> encourages a tag scheme that makes sense for your 'external' versioning
> scheme.  Also, I like that changes to the SCM *have* to occur *before*
> hand-offs to the next phase. Developer has to commit; a publisher has to
> tag.  Consistent.  You have to actually express your intent into the SCM
> before you get what you want.

Good points.

They don't preclude the automatization of the release process by a
simpler Maven Release plugin, though. I mean, we still can have a
plugin to grok the next release version and to perform the tag
automatically. Dist::Zilla::Plugin::Git::NextVersion
[http://search.cpan.org/perldoc?Dist::Zilla::Plugin::Git::NextVersion]
does exactly that when I run "dzil release". It groks all tags
matching a regex (/^v(.+)$/ by default, order them, takes the most
recent one, and create a new tag incrementing it by one. (The new tag
can be specified by the user in case you want to bump the minor or the
major version, but most of the time it does the right thing, much like
the actual Maven Release plugin.) It would be simpler because there
would be no need to edit POMs.

> This particular 'scm as versioning truth' scheme, coupled with a build
> server,  allows a very natural hand-off between developer/qa/ops, and all
> teams communicate what actually happened with one technology; the SCM.
> The SCM conveys what happened throughout the entire lifecycle, and the
> versioning of everything built is also tightly coupled to the SCM.  (well,
> one gap; I would like to shoe-horn the git hash next to the build number
> for build-server artifacts, but only if it doesn't affect all my other goals).

Yes. The core principle here is DRY. Use the SCM to manage versions
and let maven figure out the current version from the SCM context,
avoiding the need to manually keep the SCM versions and the POM
versions in sync.

> But the critical question you ask... is maven OK with this versioning.  I
> also have seen that maven seems OK with this versioning in my tests. But I
> fear my simple tests haven't found a big 'oh no'.  I hope someone else
> could weigh in who has a deep understanding of maven internally.

So do I.

> And still, the fact we have to use the command-line to achieve this
> versioning scheme is not OK. On a build server? Sure.  But for developer
> usage, not OK.  I still strongly hope Maven could resolve this by allowing
> variables in <version> that were set *very* early in the maven process.
> This should be possible with a plugin!

So far this seems to be the major roadblock to this. The risk is to
let developers do builds without specifying the version and have them
deployed with version "${scm.version}" instead. But, perhaps, we could
at least detect it by implementing a plugin to validate the artifact
version in the validate phase of the default lifecycle. It could abort
the build early on if the artifact version contains an unexpanded
property, for instance.

> Thanks for weighing in.  I was wondering if we were alone/rare in our
> desired workflow... hopefully not!

Let's hope.

During my googling in the last days I found lots of discussions around
the messiness which is the housekeeping of artifact versions in POMs.
So far as I can tell, the main issues plaguing almost everybody are
these:

* There isn't a standard method to differentiate versions in feature
branches. Some people simply don't bother and run the risk of
deployment collisions. Some people manually change the artifact's
groupid, putting the branch name in it. Others tend to insert the
branch name in the version classifier. I couldn't find anyone (except
you) thinking about using the branch name as the version.

* Merges carry on the version editions performed in the POMs. These
changes must be carefully screened out manually, which is error prone
and potentially disastrous.

By having maven infer the version from the SCM seems to simplify very
much the whole process.

Gustavo.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it possible to tie current git branch to project version?

Gustavo Leite de Mendonça Chaves
Em 9 de março de 2012 11:15, Gustavo Leite de Mendonça Chaves
<[hidden email]> escreveu:
>
> But, perhaps, we could at least detect it by implementing a plugin to validate the artifact
> version in the validate phase of the default lifecycle. It could abort
> the build early on if the artifact version contains an unexpanded
> property, for instance.

This can be checked with the
http://maven.apache.org/plugins/maven-enforcer-plugin/. For instance,
if the artifact's version is defined like this:

    <version>${scm.version}</version>

Then, the plugin could enforce it like this:

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-enforcer-plugin</artifactId>
        <version>1.0.1</version>
        <executions>
          <execution>
            <id>enforce-property</id>
            <phase>validate</phase>
            <goals>
              <goal>enforce</goal>
            </goals>
            <configuration>
              <rules>
                <requireProperty>
                  <property>project.version</property>
                  <message>"Please, use -Dscm.version=VERSION to
specify the artifact's version."</message>
                </requireProperty>
              </rules>
            </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>

--
Gustavo

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it possible to tie current git branch to project version?

Seth Call
There seem to be a good deal of issues open related directly to this.

http://jira.codehaus.org/browse/MNG-2971

I'll link to this thread in the JIRA bug as a use-case for fixing it.

I don't know what else to do...
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Is it possible to tie current git branch to project version?

Gustavo Leite de Mendonça Chaves
2012/3/10 Seth Call <[hidden email]>
>
> There seem to be a good deal of issues open related directly to this.
>
> http://jira.codehaus.org/browse/MNG-2971
>
> I'll link to this thread in the JIRA bug as a use-case for fixing it.

Very good.

That issue depends on http://jira.codehaus.org/browse/MINSTALL-50,
which is about something I haven't realized yet: even though we can
specify a property in the command line (e.g. -Dscm.version=1.0.0), the
maven install plugin will install the original POM, with the property
unexpanded.

In MINSTALL-50 they are discussing a way to specify some properties
that should be expanded before installation by the install plugin.
Makes sense to me. I've also commented on that issue.

--
Gustavo

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12
Loading...