Mike,
I'm with you fully.
This thread is a suggestion I made based on tying versioning to concepts
within the SCM very tightly.
In short, I was trying to provide three types of versioning:
* I want the latest official build, *of a branch*, for a particular
dependency (say, master-SNAPSHOT, o
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-
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 M
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,
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]<http://user/SendEmail.jtp?type=node&node=5545703&
ck 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
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 C
> 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&
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 getti
t 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 som
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
cu
It's not specific to Maven, but solving it is very much a developer workflow
problem, and the trick is to find what's the lowest-impact way that Maven
lets me solve this problem :)
--
View this message in context:
http://maven.40175.n5.nabble.com/Preferring-local-repository-over-remote-for-work-s
The http://mojo.codehaus.org/versions-maven-plugin/ is very close to the
power tool I need, thanks for drawing my attention to it.
The only thing I'm struggling with after reading that is this...
I consider the 'locked' dependencies a developer-only pattern (
http://mojo.codehaus.org/versions-ma
13 matches
Mail list logo
