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

[Gustavo Leite de Mendonça Chaves]

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

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

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

[Seth Call]

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

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

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

I don't know what else to do...

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

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

[Gustavo Leite de Mendonça Chaves]

Em 9 de março de 2012 11:15, Gustavo Leite de Mendonça Chaves
 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:

${scm.version}

Then, the plugin could enforce it like this:

  

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

  
enforce-property
validate

  enforce


  

  project.version
  "Please, use -Dscm.version=VERSION to
specify the artifact's version."

  

  

  

  

--
Gustavo

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

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

[Gustavo Leite de Mendonça Chaves]

2012/3/8 Seth Call 
>
> 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  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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

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

[Seth Call]

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

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

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

On Thu, Mar 8, 2012 at 8:59 PM, Seth Call [via Maven] <
ml-node+s40175n5549516...@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  that were set *very* early in the maven process.
>  This should be possible with a plugin!
>
> Thanks for weighing in.  I was wondering if we were alone/rare in our
> desired workflow... hopefully not!
> Seth
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5549516.html
>  To unsubscribe from Is it possible to tie current git branch to project
> version?, click 
> here
> .
> NAML
>


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

[Seth Call]

Hi Gustavo,

Wow, the tagging idea is dead on.

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

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

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

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

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

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

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

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

And still, the fact we have to use the command-line to achieve this
versioning scheme is not OK. On a build server? Sure.  But for developer
usage, not OK.  I still strongly hope Maven could resolve this by allowing
variables in  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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

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

[Gustavo Leite de Mendonça Chaves]

2012/3/8  :
>
> users Digest of: get.126118
>
> Re: Is it possible to tie current git branch to project version?
>        126118 by: Seth Call
>
> Bad smell eh?  Ok, here's my bad smell.  Version numbers.  Stinkier?
> Version *numbers* in source code.  More stinky than that? Version numbers
> in source code for projects that are never released to the public.

Hi Seth,

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

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

The proposal would be along these lines:

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

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

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

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

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

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

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

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

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

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

Now, the drawbacks... and some doubts.

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

Also, I’m not sure about the consequences of not using the maven
standard versioning scheme
[http://www.sonatype.com

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

[Seth Call]

Thanks for replying Stephen.  Inline to your inline!

Seth

On Wed, Mar 7, 2012 at 3:42 PM, stephenconnolly [via Maven] <
ml-node+s40175n5545703...@n5.nabble.com> wrote:

> On 7 March 2012 20:59, Seth Call <[hidden 
> email]>
> wrote:
> > Bad smell eh?  Ok, here's my bad smell.  Version numbers.  Stinkier?
> > Version *numbers* in source code.  More stinky than that? Version
> numbers
> > in source code for projects that are never released to the public.
> >
>
> You are confusing two concepts:
>
> * version names - these are the marketing numbers associated with a
> product
>
> * version numbers - these are the internal development defined version
> numbers
>
> there may be many builds each with a different version number but
> tagged with the same version name... at the end of the day, only one
> of those version numbers will be released, so that the public sees a
> 1:1 but actually behind the scenes there is a N:1


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

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


>


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

(covered already, but just to be clear) I mean the major/minor versioning
described in the maven versioning scheme.
--- 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 t

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

[Stephen Connolly]

On 7 March 2012 20:59, Seth Call  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:
>
> 
> acme
> project-A
> master-SNAPSHOT
> 
>
> 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:
> master-234

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:
> master-local
>
> translation: project-A has a bug or feature I need.  I want to work on it
> in paralle

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

[Seth Call]

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 $branch-SNAPSHOT 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+s40175n5545537...@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
> > >

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

[Seth Call]

Bad smell eh?  Ok, here's my bad smell.  Version numbers.  Stinkier?
Version *numbers* in source code.  More stinky than that? Version numbers
in source code for projects that are never released to the public.

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:


acme
project-A
master-SNAPSHOT


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:
master-234

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:
master-local

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:
master-local, 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 

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

[Matt Walsh]

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:sethc...@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+s40175n5544568...@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 happe

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

[Stephen Connolly]

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

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

[Seth Call]

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+s40175n5544568...@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
> >  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

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

[Seth Call]

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

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

[Matt Walsh]

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:sethc...@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
>  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+s40175n5543915...@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  of a project (unless those variables are
> > hardcoded  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
> >

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

[Stephen Connolly]

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  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
>  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+s40175n5543915...@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]>
>>
>> To: [hidden email] 
>> <[hidden
>> email] >
>> Sent: Tue Mar 06 22:01:07 2012
>> Subject: Is it possible to tie current git branch to project version?
>>
>> Hi there,
>>
>> I've seen indication when searching the internet that it isn't possible to
>> put variables in  of a project (unless those variables are
>> hardcoded  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:
>>
>> 
>> blah
>> blah
>> ${branch}-SNAPSHOT
>> 
>>
>> The reason I want to do this is that I'm realizing, for our internal-only
>> code projects, that a branch is always synonymous with a version of a
>> project, and ideally the act of being of switching branches would be all
>> it
>> takes to switch your maven project's version.
>>
>> Is this possible if I were to make a maven plugin?
>>
>> Thanks!
>> Seth
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5543110.html
>> Sent from the Maven - Users mailing list archive at Nabble.com.
>>
>> -
>> To unsubscribe, e-mail: [hidden 
>> email]
>> For additional commands, e-mail: [hidden 
>> email]
>>
>>
>> -
>> To unsubscribe, e-mail: [hidden 
>> email]
>> For additional commands, e-mail: [hidden 
>> email]
>>
>>
>> --
>>  If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://maven.40

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

[Seth Call]

Hi Roy,

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

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



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

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

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

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

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

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

But if anyone can say definitively that you can not put a variable in the
 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+s40175n5543915...@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]>
>
> To: [hidden email] 
> <[hidden
> email] >
> Sent: Tue Mar 06 22:01:07 2012
> Subject: Is it possible to tie current git branch to project version?
>
> Hi there,
>
> I've seen indication when searching the internet that it isn't possible to
> put variables in  of a project (unless those variables are
> hardcoded  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:
>
> 
> blah
> blah
> ${branch}-SNAPSHOT
> 
>
> The reason I want to do this is that I'm realizing, for our internal-only
> code projects, that a branch is always synonymous with a version of a
> project, and ideally the act of being of switching branches would be all
> it
> takes to switch your maven project's version.
>
> Is this possible if I were to make a maven plugin?
>
> Thanks!
> Seth
>
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5543110.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: [hidden 
> email]
> For additional commands, e-mail: [hidden 
> email]
>
>
> -
> To unsubscribe, e-mail: [hidden 
> email]
> For additional commands, e-mail: [hidden 
> email]
>
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5543915.html
>  To unsubscribe from Is it possible to tie current git branch to project
> version?, click 
> here
> .
> NAML

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

[Lyons, Roy]

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

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


Sent from my Blackberry.

- Original Message -
From: Seth Call 
To: users@maven.apache.org 
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  of a project (unless those variables are
hardcoded  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:


blah
blah
${branch}-SNAPSHOT


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