Technically I don't think you are, as you're pushing the 2.12.2 commit directly
to a remote tag, rewriting LOCAL history, and pushing that to master.
At what point in this set of commands is the maven artefact pushed to the
remote repository?
It would seem that poms mentioning 2.12.2 would neve
I'm not rewriting published history. Check the commands again if you
think I am :)
Kristian
Den 22. sep. 2012 kl. 01:55 skrev Mark Derricutt :
> Please NO. Just stop there. Please - for the sake of sanity.
>
> If you've a pushed a commit off site, its generally considered bad form to
> alter hi
Please NO. Just stop there. Please - for the sake of sanity.
If you've a pushed a commit off site, its generally considered bad form to
alter history. Even if its instantaneous and no one will be none the wiser.
It just feels like a bad practise.
On 22/09/2012, at 12:15 AM, Kristian Rosenvold
Do we really want something like that???
Isn't the underlying ethos for maven/releases is that the are cheap and easy?
So, just roll another release...?
-Chris
Sent from my iPhone
On 22/09/2012, at 3:58 AM, "Robert Scholte" wrote:
> So we need something like https://jira.codehaus.org/browse/
The HEAD tag in the SCM section in the Pom?
The Jazz provider doesn't either. I had no need for it. When I was writing it,
the doco was unclear as to what it was for/how it was used. I think that I only
ever saw the CVS one using it. (from memory).
-Chris
Sent from my iPhone
On 22/09/2012, at
:-)
Humorous yes. True too. The recommendation is one CC SCM admin per 20 devs.
And anders is right. Only the larger organizations can afford that overhead.
But, come audit time, it generally saves them too. :-) Or a PIR of a failure...
-Chris
Sent from my iPhone
On 21/09/2012, at 11:34 PM, S
Sent from my iPhone
On 21/09/2012, at 11:11 PM, Stephen Connolly
wrote:
> On 21 September 2012 13:59, Anders Hammar wrote:
>
>>> I have not seen anything other than CVS using the tag but that could
>>> just be ignorance on everyones part ;-)
>>
>> ClearCase uses it. But it's ok to igno
Side effect of r1387714 [1] as source-plugin was using plexus-archiver 2.1.2
I have fixed that.
--
Olivier
[1] http://svn.apache.org/viewvc?view=revision&revision=1387714
2012/9/21 Dennis Lundberg :
> Hi
>
> There are now failing test because of the update of maven-archiver.
> Can you please have
So we need something like https://jira.codehaus.org/browse/MRELEASE-430 ?
Op Fri, 21 Sep 2012 13:41:14 +0200 schreef Arnaud Héritier
:
I agree to not create releases from master but from a dedicated release
branch which will be merged after the vote at the same time we release
the
stagin
Hi
There are now failing test because of the update of maven-archiver.
Can you please have a look at why that is?
https://builds.apache.org/job/maven-plugins/1035/
On 2012-09-11 15:36, ol...@apache.org wrote:
> Author: olamy
> Date: Tue Sep 11 13:36:02 2012
> New Revision: 1383409
>
> URL: http
call it bad luck, but SVN is really the only SCM that does NOT use it I think ;)
LieGrue,
strub
- Original Message -
> From: Stephen Connolly
> To: Maven Developers List
> Cc:
> Sent: Friday, September 21, 2012 3:34 PM
> Subject: Re: Scm, Surefire, Wagon migrate to git (please check
It would appear that my attempt at humour was lost on you!
On 21 September 2012 14:15, Anders Hammar wrote:
> Unfortunately it's a fair amount of larger organizations that use it.
> So it can't be ignored in reality IMHO.
>
> /Anders
>
> On Fri, Sep 21, 2012 at 3:11 PM, Stephen Connolly
> wrote
Unfortunately it's a fair amount of larger organizations that use it.
So it can't be ignored in reality IMHO.
/Anders
On Fri, Sep 21, 2012 at 3:11 PM, Stephen Connolly
wrote:
> On 21 September 2012 13:59, Anders Hammar wrote:
>
>> > I have not seen anything other than CVS using the tag but
On 21 September 2012 13:59, Anders Hammar wrote:
> > I have not seen anything other than CVS using the tag but that could
> > just be ignorance on everyones part ;-)
>
> ClearCase uses it. But it's ok to ignore that scm...:-)
>
>
is it an SCM? I though it was an excuse to hire a bunch of IBM
> I have not seen anything other than CVS using the tag but that could
> just be ignorance on everyones part ;-)
ClearCase uses it. But it's ok to ignore that scm...:-)
/Anders
>
> Also I don't think that using "tag" to convey a git branch is a good
> plan... put perhaps setting it for the r
2012/9/21 Kristian Rosenvold :
>> Are we d'accord that we must _not_ do releases on master but always create a
>> temporary branch for each release (and then merge back to master after the
>> vote passed) ?
>
> Now it's getting interesting:
>
> git clone git://git.apache.org/maven-surefire.git
>
A few colleagues of mine had the big "aha" experience with git when I
showed them gitk --all
That's when they realized the *big* difference ;)
Kristian
2012/9/21 Stephen Connolly :
> yes it's showing up with that... I am not a heavy gitk user... intellij has
> me spoiled
>
> On 21 September 2
yes it's showing up with that... I am not a heavy gitk user... intellij has
me spoiled
On 21 September 2012 13:29, Kristian Rosenvold wrote:
> Remember to always use --all option to gitk :O
>
> Kristian
>
> 2012/9/21 Stephen Connolly :
> > Actually this might be even better (no assuming a tag)
>
Well currently I've only ever seen the release plugin create the kind
of tags you prefer, Mark. So you're in luck ;)
I still don't see why your argument actually changes anything: If
you're just firing off a quick rc release,
you can just keep the version number on trunk unchanged (hence you'd
hav
Remember to always use --all option to gitk :O
Kristian
2012/9/21 Stephen Connolly :
> Actually this might be even better (no assuming a tag)
>
> # update poms
> $ git commit -m "[maven-release-plugin] prepare release surefire-2.12.2"
> $ git commit --allow-empty -m "[maven-release-plugin] copy t
I'd rather have the 'release' commit (the one inbetween without the -SNAPSHOT)
in the history.
Reason is that the snapshot versions might be completely different than the
others.
We have this e.g. if you have
1.0-SNAPSHOT
then you release a
1.0-rc3
and continue with
1.0-SNAPSHOT
again.
Well the "prepare" commit is really just not needed. Viewing "master"
as a linear history the commits can go directly from
"2.12-SNAPSHOT" to "2.13-SNAPSHOT", since 2.12 can be on its own
mini-branch, like the asf repos do.
Now of course dropping the tag would also imply reverting the commit
versi
> Also I don't think that using "tag" to convey a git branch is a good
plan...
> put perhaps setting it for the releases and clearing after
would be a "good thing"
I'm not sure where ScmTag get it's info from. But I used this excessively in
maven-scm-providers-git. Guess this hasn't change
Actually this might be even better (no assuming a tag)
# update poms
$ git commit -m "[maven-release-plugin] prepare release surefire-2.12.2"
$ git commit --allow-empty -m "[maven-release-plugin] copy tag for
surefire-2.12.2"
$ git tag surefire-2.12.2
$ git reset --hard HEAD^1
# update poms
$ git
On 21 September 2012 13:00, Mark Struberg wrote:
> If I remember correctly the section has also a element.
>
>
I have not seen anything other than CVS using the tag but that could
just be ignorance on everyones part ;-)
Also I don't think that using "tag" to convey a git branch is a good
p
On 21 September 2012 12:58, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:
>
>
> On 21 September 2012 12:40, Kristian Rosenvold <
> kristian.rosenv...@gmail.com> wrote:
>
>> > Are we d'accord that we must _not_ do releases on master but always
>> create a temporary branch for each rele
If I remember correctly the section has also a element.
This stuff was initially used for CVS which is pretty similar to GIT from a
user pov when it comes to branches and tags.
It has not been used for a long time though and I'm not sure if some SVN
'fixes' (dynamic url change, anyone?) cras
On 21 September 2012 12:40, Kristian Rosenvold wrote:
> > Are we d'accord that we must _not_ do releases on master but always
> create a temporary branch for each release (and then merge back to master
> after the vote passed) ?
>
> Now it's getting interesting:
>
> git clone git://git.apache.org
On 21 September 2012 12:01, Benson Margulies wrote:
> On Thu, Sep 20, 2012 at 10:13 PM, Hervé BOUTEMY
> wrote:
> > Le jeudi 20 septembre 2012 11:03:54 Benson Margulies a écrit :
> >> > The doco is generated by the release. The release is tagged. The links
> >> > point to the tag.
> >> >
> >> > I
I agree to not create releases from master but from a dedicated release
branch which will be merged after the vote at the same time we release the
staging repository
Arnaud
On Fri, Sep 21, 2012 at 1:22 PM, Mark Struberg wrote:
> Ok, we need to figure how this works together with all the auto-mi
> Are we d'accord that we must _not_ do releases on master but always create a
> temporary branch for each release (and then merge back to master after the
> vote passed) ?
Now it's getting interesting:
git clone git://git.apache.org/maven-surefire.git
cd maven-surefire
gitk --all &
git clone
Ok, we need to figure how this works together with all the auto-mirrors around
(github/asf/maven, etc).
Are we d'accord that we must _not_ do releases on master but always create a
temporary branch for each release (and then merge back to master after the vote
passed) ?
LieGrue,
strub
On Fri, Sep 21, 2012 at 7:01 AM, Benson Margulies wrote:
> On Thu, Sep 20, 2012 at 10:13 PM, Hervé BOUTEMY wrote:
>> Le jeudi 20 septembre 2012 11:03:54 Benson Margulies a écrit :
>>> > The doco is generated by the release. The release is tagged. The links
>>> > point to the tag.
>>> >
>>> > It i
On Thu, Sep 20, 2012 at 10:13 PM, Hervé BOUTEMY wrote:
> Le jeudi 20 septembre 2012 11:03:54 Benson Margulies a écrit :
>> > The doco is generated by the release. The release is tagged. The links
>> > point to the tag.
>> >
>> > It is as it should be; it makes perfect sense.
>>
>> There are (poten
Hi Stuart!
I'm currently debugging through a maven plugin hack I do atm. The underlying
problem I had was not a guice problem but misinterpretation about what is
available in the contexts. I wrongly assumed that all @Component injectable
stuff of a Mojo is also available for injection inside ot
And if you can share more details about the problem you're debugging, you might
want to post them to the upstream guice list at
http://groups.google.com/group/google-guice in case it's already been fixed in
trunk.
--
Cheers, Stuart
On 21 Sep 2012, at 08:41, Mark Struberg wrote:
>
>
> Hi!
>
You don't really "crash" anything, but if the tag is rewritten you
have to delete the local tag to actually get the updated reference to
the tag.
The authorative repo is correct, but there may be some clones out
there that are unaware of the failed release and the moved tag.
I still think the ben
Which version are you using? The line numbers match for me locally. Also
remember that there is a no-AOP flavour of guice which has the AOP code
stripped out - in this case the line numbers in the bytecode will still match
exactly with the sources attachment, it just doesn't have the AOP lines a
Hi!
I need to debug through sisu-guice as I'm searching for a bug.
Problem I face is that the source and binary of e.g.
com.google.inject.internal.MembersInjectorImpl
doesn't fit together (debugger hitting empty lines and is completely
off-method).
I already dropped the jars off my loc
39 matches
Mail list logo
