You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Seth Call <se...@gmail.com> on 2012/03/07 05:01:07 UTC
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
using per-branch group repo [Was: Is it possible to tie current git
branch to project version?]
Posted by Max Spring <m2...@springdot.org>.
Has someone tried to approach this problem by using different group repositories, one for each branch?
In particular when using a repository manager like Nexus, one could have for each SCM branch a snapshot repo, a release repo and a repo group combining them (plus other third party repos).
I could imagine a Maven plugin setting the repository URLs accordingly.
In a CI build one would have a private local repository, of course.
Developers would need to be careful, though, when working with multiple branches on the same local repository. Or maybe the local repo would be per-branch, too?
When pulling a new branch, the repositories on the repository manager could be created automatically.
Thoughts?
-Max
On 03/06/2012 08:01 PM, Seth Call wrote:
> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Is it possible to tie current git branch to project version?
Posted by Seth Call <se...@gmail.com>.
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] <
ml-node+s40175n5545537h24@n5.nabble.com> 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]<http://user/SendEmail.jtp?type=node&node=5545537&i=0>]
>
> > Sent: Wednesday, March 07, 2012 12:41 PM
> > To: [hidden email]<http://user/SendEmail.jtp?type=node&node=5545537&i=1>
> > 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] <http://user/SendEmail.jtp?type=node&node=5545537&i=2>>
> 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]<http://user/SendEmail.jtp?type=node&node=5545537&i=3>
> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5545537&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-tp5543110p5545537.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=unsubscribe_by_code&node=5543110&code=c2V0aGNhbGxAZ21haWwuY29tfDU1NDMxMTB8LTU5NTg4MjI5Nw==>
> .
> 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-tp5543110p5545583.html
Sent from the Maven - Users mailing list archive at Nabble.com.
RE: Is it possible to tie current git branch to project version?
Posted by Matt Walsh <mw...@chartwelltechnology.com>.
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:sethcall@gmail.com]
> Sent: Wednesday, March 07, 2012 12:41 PM
> To: users@maven.apache.org
> 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] <
> ml-node+s40175n5544568h85@n5.nabble.com> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Is it possible to tie current git branch to project version?
Posted by Seth Call <se...@gmail.com>.
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] <
ml-node+s40175n5544568h85@n5.nabble.com> 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=unsubscribe_by_code&node=5543110&code=c2V0aGNhbGxAZ21haWwuY29tfDU1NDMxMTB8LTU5NTg4MjI5Nw==>
> .
> 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-tp5543110p5545345.html
Sent from the Maven - Users mailing list archive at Nabble.com.
RE: Is it possible to tie current git branch to project version?
Posted by Matt Walsh <mw...@chartwelltechnology.com>.
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:sethcall@gmail.com]
> Sent: Wednesday, March 07, 2012 8:19 AM
> To: users@maven.apache.org
> 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] <
> ml-node+s40175n5543915h42@n5.nabble.com> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Is it possible to tie current git branch to project version?
Posted by Seth Call <se...@gmail.com>.
Thanks for replying Stephen. Inline to your inline!
Seth
On Wed, Mar 7, 2012 at 3:42 PM, stephenconnolly [via Maven] <
ml-node+s40175n5545703h70@n5.nabble.com> wrote:
> On 7 March 2012 20:59, Seth Call <[hidden email]<http://user/SendEmail.jtp?type=node&node=5545703&i=0>>
> 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.
--- http://docs.codehaus.org/display/MAVEN/Versioning
'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] <http://user/SendEmail.jtp?type=node&node=5545703&i=1>>
> 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]<http://user/SendEmail.jtp?type=node&node=5545703&i=2>
> For additional commands, e-mail: [hidden email]<http://user/SendEmail.jtp?type=node&node=5545703&i=3>
>
>
>
> ------------------------------
> 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<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5543110&code=c2V0aGNhbGxAZ21haWwuY29tfDU1NDMxMTB8LTU5NTg4MjI5Nw==>
> .
> 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-tp5543110p5545887.html
Sent from the Maven - Users mailing list archive at Nabble.com.
Re: Is it possible to tie current git branch to project version?
Posted by Stephen Connolly <st...@gmail.com>.
On 7 March 2012 20:59, Seth Call <se...@gmail.com> 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] <
> ml-node+s40175n5545366h23@n5.nabble.com> 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<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5543110&code=c2V0aGNhbGxAZ21haWwuY29tfDU1NDMxMTB8LTU5NTg4MjI5Nw==>
>> .
>> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Is it possible to tie current git branch to project version?
Posted by Seth Call <se...@gmail.com>.
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] <
ml-node+s40175n5545366h23@n5.nabble.com> 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<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5543110&code=c2V0aGNhbGxAZ21haWwuY29tfDU1NDMxMTB8LTU5NTg4MjI5Nw==>
> .
> 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.
Re: Is it possible to tie current git branch to project version?
Posted by Stephen Connolly <st...@gmail.com>.
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 <se...@gmail.com> 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: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: Is it possible to tie current git branch to project version?
Posted by Seth Call <se...@gmail.com>.
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Is it possible to tie current git branch to project version?
Posted by Stephen Connolly <st...@gmail.com>.
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 <se...@gmail.com> 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] <
> ml-node+s40175n5543915h42@n5.nabble.com> 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=unsubscribe_by_code&node=5543110&code=c2V0aGNhbGxAZ21haWwuY29tfDU1NDMxMTB8LTU5NTg4MjI5Nw==>
>> .
>> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Is it possible to tie current git branch to project version?
Posted by Seth Call <se...@gmail.com>.
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] <
ml-node+s40175n5543915h42@n5.nabble.com> 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=unsubscribe_by_code&node=5543110&code=c2V0aGNhbGxAZ21haWwuY29tfDU1NDMxMTB8LTU5NTg4MjI5Nw==>
> .
> 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.
Re: Is it possible to tie current git branch to project version?
Posted by Gustavo Leite de Mendonça Chaves <gu...@cpqd.com.br>.
2012/3/10 Seth Call <se...@gmail.com>
>
> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Is it possible to tie current git branch to project version?
Posted by Seth Call <se...@gmail.com>.
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...
--
View this message in context: http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5552264.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Is it possible to tie current git branch to project version?
Posted by Gustavo Leite de Mendonça Chaves <gu...@cpqd.com.br>.
Em 9 de março de 2012 11:15, Gustavo Leite de Mendonça Chaves
<gu...@cpqd.com.br> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Is it possible to tie current git branch to project version?
Posted by Gustavo Leite de Mendonça Chaves <gu...@cpqd.com.br>.
2012/3/8 Seth Call <se...@gmail.com>
>
> 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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Is it possible to tie current git branch to project version?
Posted by Seth Call <se...@gmail.com>.
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] <
ml-node+s40175n5549516h73@n5.nabble.com> 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<http://maven.40175.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5543110&code=c2V0aGNhbGxAZ21haWwuY29tfDU1NDMxMTB8LTU5NTg4MjI5Nw==>
> .
> 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-tp5543110p5549518.html
Sent from the Maven - Users mailing list archive at Nabble.com.
Re: Is it possible to tie current git branch to project version?
Posted by Seth Call <se...@gmail.com>.
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
--
View this message in context: http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5549516.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org