Hello,
I think svn/git are most interesting, as AFAIK all core-plugins reside in
these SCMs :-).[1]
Being able to easily review the code diff between several takes or releases
has a value of it's own IMO. With websvn, gitweb or github e.g., it is
quite trivial to create a link which shows the com
Hi Jason,
Ok, I'll do it tonight.
Regards,
Hervé
Le vendredi 28 juin 2013 14:12:34 Jason van Zyl a écrit :
> Hervé,
>
> Can you please stage the site for 3.1.0?
>
> I'm going to put 3.1.0 up for vote.
>
> Thanks,
>
> Jason
>
> --
> Ja
Moreover, the discussion is very SVN/GIT centric. The release plugin and
continuum (as far as I know) are the primary users of the SCM api. The
entire scm api is an abstraction layer that is very cvs/svn centric (for
historical reasons) but an abstraction layer all the same, and abstraction
layers
+1
Op Tue, 25 Jun 2013 22:23:13 +0200 schreef Robert Scholte
:
Hi,
We solved 15 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530&version=19011
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11530&s
I had that idea too. 'Static' is the easy solution, 'suggest' the next
improved one :)
Robert
Op Fri, 28 Jun 2013 20:40:58 +0200 schreef Kristian Rosenvold
:
Yup, or the prepare goal actually has some kind of "auto suggest
tagname" option; which involves scanning for existing tags accordi
Revisions are not important for the pom.xml and should not be registered
there.
It is only important within the artifact to trace back its origins.
One location would be the Manifest file[1] by the buildnumber-maven-plugin
And you might want to patch the pom.xml which is bundled with the artifac
Yup, or the prepare goal actually has some kind of "auto suggest
tagname" option; which involves scanning for existing tags according
and proposing a new tag according to the same algorithm.
So when you say you want to release foobar-1.2, it'll actually look
for foobar-1.2§1 and auto-suggest fooba
What we could do is adding some sort of stageTagName to the prepare goal
of maven-release-plugin.
The project will initially be tagged with this value, but the pom.xml
still contains the final tag location.
A new goal could be introduced where you only have to specify the
stagingScmUrl. The p
Hervé,
Can you please stage the site for 3.1.0?
I'm going to put 3.1.0 up for vote.
Thanks,
Jason
--
Jason van Zyl
Founder & CTO, Sonatype
Founder, Apache Maven
http://twitter.com/jvanzyl
-
I'll accept any separator as long as we standardize, but I do not
think mixing internal project process (dealing with tags, votes and
failed internal release attempts) with the final produced artifact. So
IMO the project could decide to *stage* and publish foobar-1.0-rc1
(which it actually promotes
Kristian,
# could lead to a lot of problems when used with dereferencing
http-proxies, because it separates the http-url fragment[1]. AFAIK
Debian packages use ~ (tilde) as separator for beta packages which has
no special semantics AFAIK in URLs.
[1] http://en.wikipedia.org/wiki/Fragment_identifi
2013/6/28 Fred Cooke
> Someone else already covered that. The tag can live forever as it always
> was in the POM. In the SVN version you can either lie before or after, in
> the Git version you can use final or RC and they'll end up pointing at the
> same commit. Having said that, I never underst
Someone else already covered that. The tag can live forever as it always
was in the POM. In the SVN version you can either lie before or after, in
the Git version you can use final or RC and they'll end up pointing at the
same commit. Having said that, I never understood why that was done anyway.
M
On Friday, 28 June 2013, Fred Cooke wrote:
> For git the unique hash is sufficient, you don't really need the tag at
> all, they simply point to the unique hash (or another tag, in a chain). If
> Git was the SCM of choice, I'd use RCX tags, and then not retag for final,
> but rather point the fina
@ Chris Graham email 1
If you had, you'd have seen that the release plugin
> uses a svn copy to create the tag. A tag, in this instance is a lebel, or
> sym link for a revision.
>
These two sentences together are pure comedy gold. The second one is purely
false. A tag in SVN is nothing more than
On Jun 28, 2013, at 7:05, Fred Cooke wrote:
For git the unique hash is sufficient, you don't really need the tag at
all, they simply point to the unique hash (or another tag, in a chain). If
Git was the SCM of choice, I'd use RCX tags, and then not retag for final,
but rather point the final tag
On Fri, Jun 28, 2013 at 9:04 PM, Fred Cooke wrote:
> In terms of current SVN usage, the "SVN mv" command is probably a good
> choice, as already discussed. You could argue that a "cp" would be better,
> but this creates wholesale duplication, which is never good.
>
>
The SVN SCM provider uses the
On Fri, Jun 28, 2013 at 8:35 PM, sebb wrote:
> The re-use of tags is a side-issue to this thread, though I'm glad to
> see some support for using immutable tags, whatever route is chosen
> Please start a new thread to continue that discussion.
>
>
We had that discussion, as already noted here, ab
For git the unique hash is sufficient, you don't really need the tag at
all, they simply point to the unique hash (or another tag, in a chain). If
Git was the SCM of choice, I'd use RCX tags, and then not retag for final,
but rather point the final tag AT the last, accepted RC tag.
For example
ar
The re-use of tags is a side-issue to this thread, though I'm glad to
see some support for using immutable tags, whatever route is chosen
Please start a new thread to continue that discussion.
The vote e-mail must have the revision and tag name/trunk URL in it
else it is not complete.
Just as Mav
fixed.
Thanks for reporting.
2013/6/28 sebb :
> The file
>
> http://www.apache.org/dist/maven/KEYS
>
> has two entries for F0E309FF - Vincent Massol
>
> One of them should be deleted.
>
> -
> To unsubscribe, e-mail: dev-unsubscr..
The Apache Maven team is pleased to announce the release of the Maven
Javadoc Plugin, version 2.9.1
The Javadoc Plugin uses the Javadoc tool to generate javadocs for the
specified project.
This version contains the code to fix the javadoc security issue after
the javadoc generation.
http://maven
+1 to change our tags convention if it solves this issue by avoiding to
reuse tag names to give a better visibility from where a release was done
On Fri, Jun 28, 2013 at 7:58 AM, Kristian Rosenvold <
kristian.rosenv...@gmail.com> wrote:
> This suggestion is much like what we came up with the las
On Thu, Jun 27, 2013 at 4:39 PM, Jason van Zyl wrote:
> Agreed.
>
> Our tooling and policy is embodied in the release plugin. I am personally
> fine with any policy changes that are required, but would argue anything we
> have is grandfathered in because we've been doing it so long. If changes a
24 matches
Mail list logo
