Jason,
The summary is perfectly correct.
I would add that the author mentions too that your are friends, and
the way the text is written is not offensive.
(The author clearly does not agree with current maven development
process, he would like it be more community driven,
but it looks like
Thanks, Daniel. I kind of felt I was missing a dimension there.
Christian.
On 24-Apr-09, at 02:19 , Daniel Le Berre wrote:
Jason,
The summary is perfectly correct.
I would add that the author mentions too that your are friends, and
the way the text is written is not offensive.
(The
On 23-Apr-09, at 11:19 PM, Daniel Le Berre wrote:
Jason,
The summary is perfectly correct.
I would add that the author mentions too that your are friends, and
the way the text is written is not offensive.
Good thing you translated. From the title and the Google translated
text I read
Hi guys,
The previous translation sounds good, far better that any english I could
write by myself, as you may notice in following lines ;).
First of all, this blog was not expected to be offensive. If you consider it
such please accept my apology, and feel free to attach any comment to expose
answers inside
--- Daniel Kulp dk...@apache.org schrieb am Fr, 24.4.2009:
Von: Daniel Kulp dk...@apache.org
Betreff: Re: Using GIT as the canonical repository for Maven 3.x
An: dev@maven.apache.org
CC: Mark Struberg strub...@yahoo.de
Datum: Freitag, 24. April 2009, 2:51
On Thu April 23
I really have no idea on how Git differs from SVN, so I'd be +0 as I'm still
curious to test a new tool ;)
Just some pragmatic considerations :
- is there command line AND graphical tooling for all OS ? Seems there is a
command line client for windows based on msys, no native win32. Is the EGit
2009/4/24 nicolas de loof nicolas.del...@gmail.com
I really have no idea on how Git differs from SVN, so I'd be +0 as I'm
still
curious to test a new tool ;)
Just some pragmatic considerations :
- is there command line AND graphical tooling for all OS ? Seems there is a
command line client
Here is a more complete summary of why I think GIT, and more
specifically JGIT is the best thing going for the SCM:
http://www.sonatype.com/people/2009/04/git-the-sweetest-scm-around/
On 23-Apr-09, at 10:00 AM, Jason van Zyl wrote:
Hi,
Maven was the first project at Apache to use JIRA and
Hi folks,
Thinking of distributed SCM, why choosing GIT over Mercurial or over Bazaar
?
They use GIT: http://git-scm.com/ (linux kernel)
They use Mercurial:
http://www.selenic.com/mercurial/wiki/index.cgi/ProjectsUsingMercurial(openJDK)
They use Bazaar: http://bazaar-vcs.org/WhoUsesBzr (MySQL)
We have already a long thread with lot of things so I won't repeat some
questions.
I'm +0 to move to GIT but -1 to go outside of the Apache infrastucture.
Emmanuel
On Thu, Apr 23, 2009 at 7:00 PM, Jason van Zyl jvan...@sonatype.com wrote:
Hi,
Maven was the first project at Apache to use JIRA
Svn is up again it seems so you can login to Nexus if you want to look.
On 4/24/2009 1:40 AM, Brett Porter wrote:
Can't access these since Nexus is not responding because SVN is down.
My vote is on the ones in SVN, I'm going to trust they are the same.
+1
On 21/04/2009, at 1:05 PM, Brian Fox
Hi!
I thought in a similar direction. I think we can even let the maven-scm as it
is.
The problematic usecase is if we have a multi-module build and like to release
only one of the sub modules.
John Casey prepared an example for this use case:
$ git-clone
On 24-Apr-09, at 4:24 AM, Raphaël Piéroni wrote:
Hi folks,
Thinking of distributed SCM, why choosing GIT over Mercurial or over
Bazaar
?
For one of the biggest reasons is that there is an extremely good
implementation in Java. The other proof point is that this is
successfully being
Mark Struberg wrote:
Hi!
I thought in a similar direction. I think we can even let the maven-scm as it is.
The problematic usecase is if we have a multi-module build and like to release
only one of the sub modules.
John Casey prepared an example for this use case:
$ git-clone
Do we really need to do a clean checkout from the tag?
I'd strongly recommend it!
The main problems here are files which aren't checked in or ignored but somehow
affect the compile or test outcome. This may imho only be guaranteed by a clean
checkout into a separate directory.
process
On 24-Apr-09, at 10:20 , Paul Gier wrote:
Mark Struberg wrote:
Is sounds like the process used by our release plugin doesn't really
match the way git works, so maybe we can change the way the release
plugin works instead of trying to fit git into our model. Do we
really need to do a
On Fri, Apr 24, 2009 at 3:20 PM, Paul Gier pg...@redhat.com wrote:
Mark Struberg wrote:
Hi!
I thought in a similar direction. I think we can even let the maven-scm as
it is.
The problematic usecase is if we have a multi-module build and like to
release only one of the sub modules.
John
On 24-Apr-09, at 7:36 AM, Robert Burrell Donkin wrote:
Is sounds like the process used by our release plugin doesn't
really match
the way git works, so maybe we can change the way the release
plugin works
instead of trying to fit git into our model. Do we really need to
do a
clean
I have been starting to play with git for the jetty @ eclipse source
base, still backed by svn but just to get a feel for how it
works...and its pretty neat.
that said, I would say that maven3 is the prime mvn target to iron out
the mvn issues with release plugins and all the other core toolchain
On Fri, Apr 24, 2009 at 3:46 PM, Jason van Zyl jvan...@sonatype.com wrote:
On 24-Apr-09, at 7:36 AM, Robert Burrell Donkin wrote:
Is sounds like the process used by our release plugin doesn't really
match
the way git works, so maybe we can change the way the release plugin
works
instead of
On 24-Apr-09, at 7:55 AM, Robert Burrell Donkin wrote:
On Fri, Apr 24, 2009 at 3:46 PM, Jason van Zyl
jvan...@sonatype.com wrote:
On 24-Apr-09, at 7:36 AM, Robert Burrell Donkin wrote:
Is sounds like the process used by our release plugin doesn't
really
match
the way git works, so
On 4/24/09, Jason van Zyl jvan...@sonatype.com wrote:
On 24-Apr-09, at 7:55 AM, Robert Burrell Donkin wrote:
On Fri, Apr 24, 2009 at 3:46 PM, Jason van Zyl
jvan...@sonatype.com wrote:
On 24-Apr-09, at 7:36 AM, Robert Burrell Donkin wrote:
Is sounds like the process used by our release
Contributors - in general - would need to take more care to ensure
that code was only pulled in from sources covered by a license
agreement
Robert, I'm not sure how this differs from a patch someone provides?
Can you please elaborate what you think that the difference is here?
Imho both
Sent from my [rhymes with myPod] ;-)
On 24 Apr 2009, at 14:32, Mark Struberg strub...@yahoo.de wrote:
Hi!
I thought in a similar direction. I think we can even let the maven-
scm as it is.
The problematic usecase is if we have a multi-module build and like
to release only one of the
Brett Porter wrote:
On 24/04/2009, at 12:01 PM, Brian Fox wrote:
On 4/23/2009 9:57 PM, Brett Porter wrote:
On 24/04/2009, at 9:55 AM, Brian Fox wrote:
I agree, if we call it 2.2 because it moves to jdk 1.5 and we fix
the other stuff, great. But lets keep the scope very small and
There is one very important issue with dscm:
To be in line with our goals for Maven in general - especially
reproducibility - the tag created from a release MUST be available for
others to grab and rebuild from. This means that a git push is
absolutely necessary to finish off the release
Yes I agree. Only the canonical code can be used to produce official
maven builds and those tags are pushed back to the master. No different
really than what happens today.
On 4/24/2009 4:53 PM, John Casey wrote:
There is one very important issue with dscm:
To be in line with our goals for
If developers here were truly interested they would ask and I'm
always happy to answer specific questions.
I'd just like to point out one thing: it's not necessarily lack of
interest that can keep developers out of the picture, but also an
inability to keep up. Too much project velocity
On 24-Apr-09, at 11:17 AM, Robert Burrell Donkin wrote:
Correct. The model that Android uses I would say is optimal for an
open source project. People can take real copies and derive all the
benefit from that, but they push to a gatekeeper where submissions
are
vetted. Gerrit represents
Grok GitX - it's awesomeness for Git's level atm :)
http://gitx.frim.nl/seeit.html
I've been using it since September, and git since the beginning of last year
and it's the nicest gui i've seen yet - mind you i havent' played with
idea's stuff yet.
Arnaud HERITIER wrote:
+0I never used GIT
There are some fundamental ways in which git works vs Mercurial that make it
better - i.e. changesets vs snapshots, multiple branches in 1 repo (in hg
last time i looked you have to create a new copy to checkout a different
branch) and others...
Raphaël wrote:
Hi folks,
Thinking of
not true!
git reset --hard
git clean -f
git checkout tag
will ensure an exact match with the tag/branch.
struberg wrote:
Do we really need to do a clean checkout from the tag?
I'd strongly recommend it!
The main problems here are files which aren't checked in or ignored but
32 matches
Mail list logo
