+1
Regards,
Hervé
Le mardi 25 juin 2013 11:48:55 Olivier Lamy a écrit :
Hi,
I'd like to release Apache Maven Javadoc Plugin 2.9.1.
This version contains the code to fix the javadoc security issue after
the javadoc generation.
Since previous try I fix the @since for applying the javadoc
+1
Regards,
Hervé
Le mardi 25 juin 2013 22:23:13 Robert Scholte a écrit :
Hi,
We solved 15 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530version=190
11
There are still a couple of issues left in JIRA:
+1
2013/6/25 Olivier Lamy ol...@apache.org:
Hi,
I'd like to release Apache Maven Javadoc Plugin 2.9.1.
This version contains the code to fix the javadoc security issue after
the javadoc generation.
Since previous try I fix the @since for applying the javadoc security fix.
We fixed 6
Hi,
The vote has passed with the following result:
+1 (binding): Kristian, Ralph, Robert, Hervé, Olivier
+1 (non binding): Tony
-1 (non binding): Fred Cooke
Will finish release complete.
--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy
On Thu, Jun 27, 2013 at 4:39 PM, Jason van Zyl ja...@tesla.io 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
+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 last
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.
fixed.
Thanks for reporting.
2013/6/28 sebb seb...@gmail.com:
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:
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
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
On Fri, Jun 28, 2013 at 8:35 PM, sebb seb...@gmail.com 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
On Fri, Jun 28, 2013 at 9:04 PM, Fred Cooke fred.co...@gmail.com 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
On Jun 28, 2013, at 7:05, Fred Cooke fred.co...@gmail.com 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
@ 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 a
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 final
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.
2013/6/28 Fred Cooke fred.co...@gmail.com
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
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]
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
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
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
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
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
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
kristian.rosenv...@gmail.com:
Yup, or the prepare goal actually has some kind of auto suggest
tagname option; which involves
+1
Op Tue, 25 Jun 2013 22:23:13 +0200 schreef Robert Scholte
rfscho...@apache.org:
Hi,
We solved 15 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530version=19011
There are still a couple of issues left in JIRA:
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
26 matches
Mail list logo
