Re: [VOTE] Apache Maven Javadoc Plugin 2.9.1 (take 2)
I will try to fix that. (as I remember changes plugin need to be upgraded with new jira version) So I can try redeploy the site with the fix. 2013/6/25 Ralph Goers : > KEYS file - http://svn.apache.org/repos/asf/maven/project/KEYS > > svn tag - > http://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1 > > +1 on the release however it is odd that the Release Notes page is empty. > > Ralph > > On Jun 24, 2013, at 7:15 PM, sebb wrote: > >> On 25 June 2013 02:48, Olivier Lamy wrote: >>> 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 issues: >>> https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18843&styleName=Text&projectId=11138&Create=Create >>> >>> Staging repository: >>> https://repository.apache.org/content/repositories/maven-066/ >> >> The NOTICE file still has a spurious blank line at the start; it >> should be removed before the next release candidate. >> >>> Staging site: >>> http://maven.apache.org/plugins-archives/maven-javadoc-plugin-2.9.1/ >> >> The release notes page is empty, as before. >> Given that this release has a vital change in it, that is very unfortunate. >> >> SVN tag and revision? >> Without them, how can reviewers determine the provenance of the source >> files in the source release? >> >> KEYS file? >> How can we check the sigs? >> >>> Vote open for 72H >>> >>> [+1] >>> [0] >>> [-1] >>> >>> Thanks, >>> -- >>> Olivier Lamy >>> Ecetera: http://ecetera.com.au >>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven Javadoc Plugin 2.9.1 (take 2)
KEYS file - http://svn.apache.org/repos/asf/maven/project/KEYS svn tag - http://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1 +1 on the release however it is odd that the Release Notes page is empty. Ralph On Jun 24, 2013, at 7:15 PM, sebb wrote: > On 25 June 2013 02:48, Olivier Lamy wrote: >> 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 issues: >> https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18843&styleName=Text&projectId=11138&Create=Create >> >> Staging repository: >> https://repository.apache.org/content/repositories/maven-066/ > > The NOTICE file still has a spurious blank line at the start; it > should be removed before the next release candidate. > >> Staging site: >> http://maven.apache.org/plugins-archives/maven-javadoc-plugin-2.9.1/ > > The release notes page is empty, as before. > Given that this release has a vital change in it, that is very unfortunate. > > SVN tag and revision? > Without them, how can reviewers determine the provenance of the source > files in the source release? > > KEYS file? > How can we check the sigs? > >> Vote open for 72H >> >> [+1] >> [0] >> [-1] >> >> Thanks, >> -- >> Olivier Lamy >> Ecetera: http://ecetera.com.au >> http://twitter.com/olamy | http://linkedin.com/in/olamy >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org >
Re: [VOTE] Apache Maven Javadoc Plugin 2.9.1 (take 2)
+1 Sources at https://repository.apache.org/content/repositories/maven-066/org/apache/maven/plugins/maven-javadoc-plugin/2.9.1/maven-javadoc-plugin-2.9.1-sources.jar, based on r1496317 Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven Javadoc Plugin 2.9.1 (take 2)
On 25 June 2013 02:48, Olivier Lamy wrote: > 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 issues: > https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18843&styleName=Text&projectId=11138&Create=Create > > Staging repository: > https://repository.apache.org/content/repositories/maven-066/ The NOTICE file still has a spurious blank line at the start; it should be removed before the next release candidate. > Staging site: > http://maven.apache.org/plugins-archives/maven-javadoc-plugin-2.9.1/ The release notes page is empty, as before. Given that this release has a vital change in it, that is very unfortunate. SVN tag and revision? Without them, how can reviewers determine the provenance of the source files in the source release? KEYS file? How can we check the sigs? > Vote open for 72H > > [+1] > [0] > [-1] > > Thanks, > -- > Olivier Lamy > Ecetera: http://ecetera.com.au > http://twitter.com/olamy | http://linkedin.com/in/olamy > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Apache Maven Javadoc Plugin 2.9.1 (take 2)
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 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18843&styleName=Text&projectId=11138&Create=Create Staging repository: https://repository.apache.org/content/repositories/maven-066/ Staging site: http://maven.apache.org/plugins-archives/maven-javadoc-plugin-2.9.1/ Vote open for 72H [+1] [0] [-1] Thanks, -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1496315 - /maven/sandbox/trunk/plugins/maven-digest-plugin/src/main/java/org/apache/maven/plugins/digest/DigestMojo.java
Great.
Quick note have a look at
http://maven.apache.org/developers/conventions/code.html
:-)
2013/6/25 :
> Author: sebb
> Date: Tue Jun 25 00:51:03 2013
> New Revision: 1496315
>
> URL: http://svn.apache.org/r1496315
> Log:
> Allow list of digests to be provided on command-line
> Allow extension name to be overridden
>
> Modified:
>
> maven/sandbox/trunk/plugins/maven-digest-plugin/src/main/java/org/apache/maven/plugins/digest/DigestMojo.java
>
> Modified:
> maven/sandbox/trunk/plugins/maven-digest-plugin/src/main/java/org/apache/maven/plugins/digest/DigestMojo.java
> URL:
> http://svn.apache.org/viewvc/maven/sandbox/trunk/plugins/maven-digest-plugin/src/main/java/org/apache/maven/plugins/digest/DigestMojo.java?rev=1496315&r1=1496314&r2=1496315&view=diff
> ==
> ---
> maven/sandbox/trunk/plugins/maven-digest-plugin/src/main/java/org/apache/maven/plugins/digest/DigestMojo.java
> (original)
> +++
> maven/sandbox/trunk/plugins/maven-digest-plugin/src/main/java/org/apache/maven/plugins/digest/DigestMojo.java
> Tue Jun 25 00:51:03 2013
> @@ -69,10 +69,19 @@ public class DigestMojo extends Abstract
> private String files;
>
> /**
> + * List of digests (algorithms) to create, comma-separated (intended for
> command-line usage).
> + * Overrides algorithms; uses same syntax
> + */
> +@Parameter (property="maven.digest.digests")
> +private String digests;
> +
> +/**
> * The list of algorithm names with which to create digests.
> * If none specified, the default is {@code MD5} and {@code SHA1}.
> * By default the file extension is assumed to be the algorithm name
> * converted to lower-case, and any "-" characters removed.
> + * The extension name can be provided by suffixing the algorithm name
> + * with ">" followed by the extension, for example: "SHA-1>sha".
> */
> @Parameter
> private Set algorithms;
> @@ -87,8 +96,15 @@ public class DigestMojo extends Abstract
> String files[] = scanForSources();
> Log log = getLog();
> if (files.length == 0) {
> -log.warn("No files found. Please configure at least one
> item or use -Ddigest.files");
> +log.warn("No files found. Please configure at least one
> item or use -Dmaven.digest.files");
> } else {
> +if (digests != null && digests.length() > 0) {
> +String [] digest = digests.split(",");
> +algorithms = new HashSet(digest.length);
> +for (String d : digest) {
> + algorithms.add(d);
> +}
> +}
> if (algorithms == null || algorithms.size() == 0) {
> algorithms = new HashSet(2);
> algorithms.add("MD5");
> @@ -97,7 +113,7 @@ public class DigestMojo extends Abstract
> try {
> for(String file : files) {
> for(String algorithm : algorithms) {
> -String[] parts = algorithm.split("|");
> +String[] parts = algorithm.split(">");
> String extension;
> if (parts.length == 2) {
> algorithm = parts[0];
> @@ -126,10 +142,12 @@ public class DigestMojo extends Abstract
> }
>
> private void createDigest(String algorithm, String extension, String
> file) throws Exception {
> +// Unfortunately DigestUtils.getDigest is not public
> +// Do this before opening file in case not found
> +MessageDigest digest = MessageDigest.getInstance(algorithm);
> FileInputStream is = new FileInputStream(file);
> PrintWriter pw = new PrintWriter(file+extension, "UTF-8");
> -// Unfortunately DigestUtils.getDigest is not public
> -pw.print(digestHex(MessageDigest.getInstance(algorithm), is));
> +pw.print(digestHex(digest, is));
> if (appendFilename) {
> pw.println(" *" + file);
> } else {
>
>
--
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1496295 - /maven/plugins/trunk/maven-javadoc-plugin/pom.xml
On 25 June 2013 00:26, wrote: > Author: olamy > Date: Mon Jun 24 23:26:16 2013 > New Revision: 1496295 > > URL: http://svn.apache.org/r1496295 > Log: > fix name > > Modified: > maven/plugins/trunk/maven-javadoc-plugin/pom.xml > > Modified: maven/plugins/trunk/maven-javadoc-plugin/pom.xml > URL: > http://svn.apache.org/viewvc/maven/plugins/trunk/maven-javadoc-plugin/pom.xml?rev=1496295&r1=1496294&r2=1496295&view=diff > == > --- maven/plugins/trunk/maven-javadoc-plugin/pom.xml (original) > +++ maven/plugins/trunk/maven-javadoc-plugin/pom.xml Mon Jun 24 23:26:16 2013 > @@ -33,7 +33,7 @@ under the License. >2.9.1-SNAPSHOT >maven-plugin > > - Maven Javadoc Plugin > + Apache Maven Javadoc Plugin > > The Maven Javadoc Plugin is a plugin that uses the javadoc tool for Here too please! > generating javadocs for the specified project. > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [VOTE] Apache Maven Javadoc Plugin 2.9.1
+1 to release from somebody outside (but provided the frame injection patch)! Just a funny detail: The maven-javadoc-plugin-2.9.1-javadoc.jar on the staging repository of course have the frame injection bug! Somehow a chicken-egg problem. :-) Theoretically the pom.xml of the plugin should use its own version to create its own javadocs! But of course later versions of the plugin can then rely on 2.9.1. I don't think this should hold the release, because the frame injection bug is only critical if you publish the javadocs on a web server which is not the case for this plugin (right?). On a local eclipse displaying javadocs embedded, it does not matter at all if they are vulnerable. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Olivier Lamy [mailto:ol...@apache.org] > Sent: Monday, June 24, 2013 2:05 PM > To: Maven Developers List > Subject: [VOTE] Apache Maven Javadoc Plugin 2.9.1 > > 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. > > We fixed 6 issues: > https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18843&styleNa > me=Text&projectId=11138&Create=Create > > Staging repository: > https://repository.apache.org/content/repositories/maven-062 > > Staging site: http://maven.apache.org/plugins-archives/maven-javadoc- > plugin-2.9.1/ > > Vote open for 72H > > [+1] > [0] > [-1] > > Thanks, > -- > Olivier Lamy > Ecetera: http://ecetera.com.au > http://twitter.com/olamy | http://linkedin.com/in/olamy > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional > commands, e-mail: dev-h...@maven.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven Javadoc Plugin 2.9.1
On 24 June 2013 23:58, Olivier Lamy wrote: > 2013/6/25 sebb : >> On 24 June 2013 13:04, Olivier Lamy wrote: >>> 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. >>> >>> We fixed 6 issues: >>> https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18843&styleName=Text&projectId=11138&Create=Create >>> >>> Staging repository: >>> https://repository.apache.org/content/repositories/maven-062 >>> >>> Staging site: >>> http://maven.apache.org/plugins-archives/maven-javadoc-plugin-2.9.1/ >> >> SVN tag? > > It's a bit implicit if you know our sources tree Yes, but it helps to have the URL and especially the revision quoted in the e-mail. Tags are supposed to be immutable but frequently are not, so the revision is necessary. >> >> KEYS file? > > I believe it's available as most of ASF project at > svn.a.o/repos/asf/$tlp/project/KEYS Please quote whatever KEYS file is listed on the source download page and/or ASF dist directory. It's important that reviewers can check that end-users have access to the keys they need to check downloads. >> >>> Vote open for 72H >>> >>> [+1] >>> [0] >>> [-1] >> >> The parameter applyJavadocSecurityFix in the class >> AbstractJavadocMojo is documented as being @since 2.10. > Argh good catch I will fix that >> >> The Release Notes page on the site is empty. > ? >> >> There's no NOTICE and LICENSE in SVN at the level of the plugin. > Those files are in the voted artifacts. >> >> The NOTICE file looks wrong to me. >> It has a spurious blank line at the start. >> The next line says: >> Maven Javadoc Plugin >> This should be >>Apache Maven Javadoc Plugin > Easy to fix >> >> The index.html file in the javadoc jar appears to have the frame bug; >> certainly it does not contain a "function validURL(url)" line. > Chicken and egg issue as I need the fix but I'm build the fix. Or just use Java 1.7.0_25 for the build and Java 1.6 for the compile/test. > So this will be probably the last javadoc jar we publish :-). At least > the most (public website has been generated with the fix). > > BTW I cancel the release. > >> >> Sorry, but I would have to vote -1 if mine were binding. >> >>> Thanks, >>> -- >>> Olivier Lamy >>> Ecetera: http://ecetera.com.au >>> http://twitter.com/olamy | http://linkedin.com/in/olamy >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >>> For additional commands, e-mail: dev-h...@maven.apache.org >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > > > -- > Olivier Lamy > Ecetera: http://ecetera.com.au > http://twitter.com/olamy | http://linkedin.com/in/olamy > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven Javadoc Plugin 2.9.1
2013/6/25 sebb : > On 24 June 2013 13:04, Olivier Lamy wrote: >> 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. >> >> We fixed 6 issues: >> https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18843&styleName=Text&projectId=11138&Create=Create >> >> Staging repository: >> https://repository.apache.org/content/repositories/maven-062 >> >> Staging site: >> http://maven.apache.org/plugins-archives/maven-javadoc-plugin-2.9.1/ > > SVN tag? It's a bit implicit if you know our sources tree > > KEYS file? I believe it's available as most of ASF project at svn.a.o/repos/asf/$tlp/project/KEYS > >> Vote open for 72H >> >> [+1] >> [0] >> [-1] > > The parameter applyJavadocSecurityFix in the class > AbstractJavadocMojo is documented as being @since 2.10. Argh good catch I will fix that > > The Release Notes page on the site is empty. ? > > There's no NOTICE and LICENSE in SVN at the level of the plugin. Those files are in the voted artifacts. > > The NOTICE file looks wrong to me. > It has a spurious blank line at the start. > The next line says: > Maven Javadoc Plugin > This should be >Apache Maven Javadoc Plugin Easy to fix > > The index.html file in the javadoc jar appears to have the frame bug; > certainly it does not contain a "function validURL(url)" line. Chicken and egg issue as I need the fix but I'm build the fix. So this will be probably the last javadoc jar we publish :-). At least the most (public website has been generated with the fix). BTW I cancel the release. > > Sorry, but I would have to vote -1 if mine were binding. > >> Thanks, >> -- >> Olivier Lamy >> Ecetera: http://ecetera.com.au >> http://twitter.com/olamy | http://linkedin.com/in/olamy >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [CANCEL] [VOTE] Release Maven Enforcer version 1.3
Voted canceled
If too many external rules depend on the signatures of the standard rules,
then I have to cancel it.
Some dirty things were done with the exposed fields and of course
checkstyle complained about it. It's a shame it has become impossible to
remove this kind of "bugs".
If these signatures are such a real issue, we have some huge challenges
for 2.0.
And we're bound to the package, because of the way Plexus uses it to
initiate the Rules.
So for now I'll restore the visibility of the fields, mark them as
deprecated and refer to their getters and setters.
thanks,
Robert
Op Mon, 24 Jun 2013 11:22:31 +0200 schreef Baptiste MATHUS
:
+1 on that one: going onto a major version change like 2.x could be
better
here imo.
I'm totally OK with releasing things that are more correct (not working
correctly about artifact resolution here).
But since this is likely to break a lot of internal rules (for example,
it's gonna break 50% of the extra-enforcer-rules rules), it should be
conveyed very clearly that it's an important upgrade.
Cheers
2013/6/23 Mirko Friedenhagen
Hello,
I did the tests wrongly for extra-enforcer-rules, the new version of
enforcer is backwards incompatible:
org.apache.maven.plugins.enforcer.AbstractStandardEnforcerRule had a
public message field in 1.2, this is now (1.3) private and uses
getMessage and setMessage methods.
This would mean a major update IMO.
I can imagine this would mean a lot of private rules to break, so I
withdraw my +1 and make it
-1 (non-binding).
Regards
Mirko
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/
On Sun, Jun 23, 2013 at 3:33 PM, Baptiste MATHUS
wrote:
> Hi,
>
> No problem, I'll see how I can fix that.
>
> FWIW, I've just run the ITs of mojo's extra-enforcer-rules project
with
> m-enforcer-p:1.3.
> This gives:
> [ERROR] The following builds failed:
> [ERROR] * enforce-bytecode-version-jdkVersionOption\pom.xml
> [ERROR] * enforce-bytecode-version-with-banned-deps\pom.xml
> [ERROR] * enforce-bytecode-version-wo-banned-deps\pom.xml
> [ERROR] * mojo-1682\pom.xml
> [ERROR] * mojo-1731\pom.xml
> [ERROR] * mojo-1744\pom.xml
> [ERROR] * mojo-1769\pom.xml
> [ERROR] * mojo-1853\pom.xml
> [ERROR] * mojo-1929\pom.xml
> [ERROR] * require-property-diverges\pom.xml
> [ERROR] * smokes\pom.xml
>
> So, to sum up, the impacted rules are:
>
>- enforceBytecodeVersion
>- banDuplicateClasses
>- requirePropertyDiverges
>
>
> Cheers
>
>
>
> 2013/6/23 Robert Scholte
>
>> Hi Baptiste,
>>
>> you're hitting the result of the changes due to MENFORCER-42[1]
>> Up until 1.2 the dependencies were resolved instead of calculated.
>> So if you run 'mvn validate' you can't use the results of the
reactor,
>> since those files aren't available yet. So the build will fail or it
will
>> use artifacts from an older run. IMO both are wrong.
>>
>> The EnforceBytecodeVersion is an example of a rule which needs to be
bound
>> after compilation.
>> My suggestion is to rewrite the rule and let it depend on a
DependencyTree
>> instead of a DependencyGraph[2]
>>
>> I noticed that the extra-enforcer-rules depend on the (standard)
>> enforcer-rules. I think that could be improved by extracting abstract
>> classes to a separate module. That way we have a better separation on
>> concerns. That would be something for a next release.
>>
>> I'm not going to cancel the vote for this reason.
>>
>> Robert
>>
>> ps. Thanks for testing!
>>
>> [1] http://jira.codehaus.org/**browse/MENFORCER-42<
http://jira.codehaus.org/browse/MENFORCER-42>
>> [2] http://maven.apache.org/**shared/maven-dependency-tree/<
http://maven.apache.org/shared/maven-dependency-tree/>
>>
>>
>> Op Sun, 23 Jun 2013 11:45:30 +0200 schreef Baptiste MATHUS <
>> bmat...@batmat.net>:
>>
>> -0.9 (non binding).
>>>
>>> I just tested on a local project, codehaus mojo
EnforceBytecodeVersion
>>> fails with an NPE with m-enforcer-p 1.3 but correctly thows an
>>> EnforcerRuleException with 1.2.
>>> That is, as I am the one who wrote that rule, that's perfectly
possible
>>> I'm
>>> doing something stooopid in the code that gets revealed with this
new
>>> enforcer-p version.
>>>
>>> I've pasted the stack trace here: http://pastebin.com/3sHY0Fvf
>>>
>>> After a quick dive in the code, from the stack trace, seems like the
>>> following code:
>>> *private boolean isBadArtifact( Artifact a )** throws
>>> EnforcerRuleException*
>>> *{*
>>> *File f = a.getFile();*
>>> *if ( !f.getName().endsWith( ".jar" ) )*
>>> *{*
>>>
>>>
>>> fails because the returned File is null.
>>>
>>> Is this something that should always work. If you feel this is
correct
>>> code, then just let me know and I'll file the corresponding JIRA.
>>>
>>> Cheers
>>>
>>>
>>> 2013/6/23 Olivier Lamy
>>>
>>> +1
2013/6/22 Robert Scholte :
> Hi,
>
> We solved 15 issues:
>
http://
Re: [VOTE] Apache Maven Javadoc Plugin 2.9.1
On 24 June 2013 13:04, Olivier Lamy wrote: > 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. > > We fixed 6 issues: > https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18843&styleName=Text&projectId=11138&Create=Create > > Staging repository: > https://repository.apache.org/content/repositories/maven-062 > > Staging site: > http://maven.apache.org/plugins-archives/maven-javadoc-plugin-2.9.1/ SVN tag? KEYS file? > Vote open for 72H > > [+1] > [0] > [-1] The parameter applyJavadocSecurityFix in the class AbstractJavadocMojo is documented as being @since 2.10. The Release Notes page on the site is empty. There's no NOTICE and LICENSE in SVN at the level of the plugin. The NOTICE file looks wrong to me. It has a spurious blank line at the start. The next line says: Maven Javadoc Plugin This should be Apache Maven Javadoc Plugin The index.html file in the javadoc jar appears to have the frame bug; certainly it does not contain a "function validURL(url)" line. Sorry, but I would have to vote -1 if mine were binding. > Thanks, > -- > Olivier Lamy > Ecetera: http://ecetera.com.au > http://twitter.com/olamy | http://linkedin.com/in/olamy > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: [VOTE] Apache Maven Javadoc Plugin 2.9.1
+1 (non binding) Both testapidoc and apidoc contains the fixed javascript. Regards -Message d'origine- De : Olivier Lamy [mailto:ol...@apache.org] Envoyé : lundi 24 juin 2013 14:05 À : Maven Developers List Objet : [VOTE] Apache Maven Javadoc Plugin 2.9.1 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. We fixed 6 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18843&styleName=Te xt&projectId=11138&Create=Create Staging repository: https://repository.apache.org/content/repositories/maven-062 Staging site: http://maven.apache.org/plugins-archives/maven-javadoc-plugin-2.9.1/ Vote open for 72H [+1] [0] [-1] Thanks, -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Apache Maven Javadoc Plugin 2.9.1
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. We fixed 6 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18843&styleName=Text&projectId=11138&Create=Create Staging repository: https://repository.apache.org/content/repositories/maven-062 Staging site: http://maven.apache.org/plugins-archives/maven-javadoc-plugin-2.9.1/ Vote open for 72H [+1] [0] [-1] Thanks, -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Enforcer version 1.3
+1 on that one: going onto a major version change like 2.x could be better
here imo.
I'm totally OK with releasing things that are more correct (not working
correctly about artifact resolution here).
But since this is likely to break a lot of internal rules (for example,
it's gonna break 50% of the extra-enforcer-rules rules), it should be
conveyed very clearly that it's an important upgrade.
Cheers
2013/6/23 Mirko Friedenhagen
> Hello,
>
> I did the tests wrongly for extra-enforcer-rules, the new version of
> enforcer is backwards incompatible:
> org.apache.maven.plugins.enforcer.AbstractStandardEnforcerRule had a
> public message field in 1.2, this is now (1.3) private and uses
> getMessage and setMessage methods.
>
> This would mean a major update IMO.
>
> I can imagine this would mean a lot of private rules to break, so I
> withdraw my +1 and make it
> -1 (non-binding).
>
>
> Regards
> Mirko
> Regards Mirko
> --
> http://illegalstateexception.blogspot.com/
> https://github.com/mfriedenhagen/
> https://bitbucket.org/mfriedenhagen/
>
>
> On Sun, Jun 23, 2013 at 3:33 PM, Baptiste MATHUS
> wrote:
> > Hi,
> >
> > No problem, I'll see how I can fix that.
> >
> > FWIW, I've just run the ITs of mojo's extra-enforcer-rules project with
> > m-enforcer-p:1.3.
> > This gives:
> > [ERROR] The following builds failed:
> > [ERROR] * enforce-bytecode-version-jdkVersionOption\pom.xml
> > [ERROR] * enforce-bytecode-version-with-banned-deps\pom.xml
> > [ERROR] * enforce-bytecode-version-wo-banned-deps\pom.xml
> > [ERROR] * mojo-1682\pom.xml
> > [ERROR] * mojo-1731\pom.xml
> > [ERROR] * mojo-1744\pom.xml
> > [ERROR] * mojo-1769\pom.xml
> > [ERROR] * mojo-1853\pom.xml
> > [ERROR] * mojo-1929\pom.xml
> > [ERROR] * require-property-diverges\pom.xml
> > [ERROR] * smokes\pom.xml
> >
> > So, to sum up, the impacted rules are:
> >
> >- enforceBytecodeVersion
> >- banDuplicateClasses
> >- requirePropertyDiverges
> >
> >
> > Cheers
> >
> >
> >
> > 2013/6/23 Robert Scholte
> >
> >> Hi Baptiste,
> >>
> >> you're hitting the result of the changes due to MENFORCER-42[1]
> >> Up until 1.2 the dependencies were resolved instead of calculated.
> >> So if you run 'mvn validate' you can't use the results of the reactor,
> >> since those files aren't available yet. So the build will fail or it
> will
> >> use artifacts from an older run. IMO both are wrong.
> >>
> >> The EnforceBytecodeVersion is an example of a rule which needs to be
> bound
> >> after compilation.
> >> My suggestion is to rewrite the rule and let it depend on a
> DependencyTree
> >> instead of a DependencyGraph[2]
> >>
> >> I noticed that the extra-enforcer-rules depend on the (standard)
> >> enforcer-rules. I think that could be improved by extracting abstract
> >> classes to a separate module. That way we have a better separation on
> >> concerns. That would be something for a next release.
> >>
> >> I'm not going to cancel the vote for this reason.
> >>
> >> Robert
> >>
> >> ps. Thanks for testing!
> >>
> >> [1] http://jira.codehaus.org/**browse/MENFORCER-42<
> http://jira.codehaus.org/browse/MENFORCER-42>
> >> [2] http://maven.apache.org/**shared/maven-dependency-tree/<
> http://maven.apache.org/shared/maven-dependency-tree/>
> >>
> >>
> >> Op Sun, 23 Jun 2013 11:45:30 +0200 schreef Baptiste MATHUS <
> >> bmat...@batmat.net>:
> >>
> >> -0.9 (non binding).
> >>>
> >>> I just tested on a local project, codehaus mojo EnforceBytecodeVersion
> >>> fails with an NPE with m-enforcer-p 1.3 but correctly thows an
> >>> EnforcerRuleException with 1.2.
> >>> That is, as I am the one who wrote that rule, that's perfectly possible
> >>> I'm
> >>> doing something stooopid in the code that gets revealed with this new
> >>> enforcer-p version.
> >>>
> >>> I've pasted the stack trace here: http://pastebin.com/3sHY0Fvf
> >>>
> >>> After a quick dive in the code, from the stack trace, seems like the
> >>> following code:
> >>> *private boolean isBadArtifact( Artifact a )** throws
> >>> EnforcerRuleException*
> >>> *{*
> >>> *File f = a.getFile();*
> >>> *if ( !f.getName().endsWith( ".jar" ) )*
> >>> *{*
> >>>
> >>>
> >>> fails because the returned File is null.
> >>>
> >>> Is this something that should always work. If you feel this is correct
> >>> code, then just let me know and I'll file the corresponding JIRA.
> >>>
> >>> Cheers
> >>>
> >>>
> >>> 2013/6/23 Olivier Lamy
> >>>
> >>> +1
>
> 2013/6/22 Robert Scholte :
> > Hi,
> >
> > We solved 15 issues:
> >
> http://jira.codehaus.org/**secure/ReleaseNote.jspa?**
> projectId=11530&version=19011<
> 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&status=1<
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11530&status=
Re: Maven 3.1.0-beta-1
+1 on going 3.1.0. At least, alphas is surely a too "frightening" name for many people to try it. Maybe RC would be more seen as already usable by a larger part of the community, but not sure it's worth the effort/debate. Cheers 2013/6/24 Sievers, Jan > >Almost zero people have given feedback > > tycho has recently adapted to the changes in maven 3.1.0-alpha-1 with > version 0.19.0-SNAPSHOT [1] > > All our ITs are passing with maven 3.1.0-alpha-1 and we didn't get tycho > bugs reported w.r.t. maven 3.1.0-alpha-1 > Not sure how many people are using it though so you may be right that > maven 3.1.x needs more advertising in order to to find the remaining issues. > > Regards, > Jan > > [1] http://wiki.eclipse.org/Tycho/Release_Notes/0.19 > > -Original Message- > From: Jason van Zyl [mailto:ja...@tesla.io] > Sent: Sonntag, 23. Juni 2013 17:08 > To: Maven Developers List > Subject: Re: Maven 3.1.0-beta-1 > > I'm just going to cut the 3.1.0. Almost zero people have given feedback > and I don't think anyone is going to look at this until it's released and > then I think all sort of issues are going to surface and I will prepare to > fix those. I believe there will be many issues but this process isn't going > to find them. > > On Jun 22, 2013, at 7:20 AM, Vincent Latombe > wrote: > > > OK, thanks for the clarification. > > Vincent > > > > > > 2013/6/22 Jason van Zyl : > >> > >> On Jun 21, 2013, at 11:48 PM, Vincent Latombe < > vincent.lato...@gmail.com> wrote: > >> > >>> Hello, > >>> > >>> I have a question about the alpha-1 release. I see that Aether has > >>> been updated to 0.9.0 M2. > >>> Does it implies that issue MNG-2802 (Concurrent-safe access to local > >>> Maven repository) is now implemented ? > >>> > >> > >> No, it does not. > >> > >>> If this is the case, then IMHO this should be mentioned, even > >>> highlighted in the release notes. I think this kind of improvement is > >>> very expected for all people doing CI, as this would allow a major > >>> speed up and reduce storage for local repositories in this kind of > >>> environment. > >>> > >>> Cheers, > >>> > >>> Vincent > >>> > >>> > >>> 2013/6/21 Jörg Schaible > > Hi Jason, > > first, thanks that you actually take your time to look into it! > > Jason van Zyl wrote: > > > I unpacked your example and ran your preparation script and it fails > in > > 2.2.1 as well: > > > > https://gist.github.com/jvanzyl/5824206 > > The submodules are independent projects, you have to run "clean > install". > See the following session (I have modified the POMs of the children by > adding a "" element, the original example is now ~2 > years > old): > > https://gist.github.com/joehni/6aa8516bd5408144ec53 > > Note, that after a successful run with M221, the build with M3x will > no > longer fail, but pack stale snapshots. To raise an error, you have to > clean > the repo from snapshots in /bugs/maven. > > > What's the overall usecase? You have a build with snapshots and you > find > > you need to go back to a release so you lock down to a previous > release > > and want to use that? > > The final distribution of our product or projects typically consists > of > hundreds of artifacts, where most of them have individual release > cycles. In > the HEAD revision those are linked in a nested directory structure > using > "builder POMs" i.e. POMs that have only modules declared, but get > never > released themselves (like the POM in the root of the example). The > versions > of the individual artifact are managed in a shared parent POM. In > HEAD those > are typically all snapshot versions. > > This changes after a major release of the overall product, then all > those > versions become final, the shared parent is released first followed > by all > other artifacts in dependency order using this released parent. This > works > all fine. > > Now we get into maintenance mode of that major release. Due to the > independence of the artifacts we have to branch only the affected > projects > in case of bugs. Say we have JAR artifacts JAR-A to JAR-Z and we > develop bug > fixes for JAR-C and JAR-S. This means we branch the shared parent, > set JAR-C > and JAR-S to snapshot and also the artifacts that will assemble those > to two > jars, say WAR-X and DIST-ZIP. Then we create a builder for the > maintenance > branch that contains those jars, the war and the distribution zip as > module. > Building this we should get a war that contains JAR-C and JAR-S as > snapshot > and all the others as release and the distribution contains the > affected > WAR-X as snapshot and all other stuff as released version - the > perfect > situation to test the fix. > > Unfortunately M3 fails here, because it is under some circumstance > n
RE: Maven 3.1.0-beta-1
>Almost zero people have given feedback tycho has recently adapted to the changes in maven 3.1.0-alpha-1 with version 0.19.0-SNAPSHOT [1] All our ITs are passing with maven 3.1.0-alpha-1 and we didn't get tycho bugs reported w.r.t. maven 3.1.0-alpha-1 Not sure how many people are using it though so you may be right that maven 3.1.x needs more advertising in order to to find the remaining issues. Regards, Jan [1] http://wiki.eclipse.org/Tycho/Release_Notes/0.19 -Original Message- From: Jason van Zyl [mailto:ja...@tesla.io] Sent: Sonntag, 23. Juni 2013 17:08 To: Maven Developers List Subject: Re: Maven 3.1.0-beta-1 I'm just going to cut the 3.1.0. Almost zero people have given feedback and I don't think anyone is going to look at this until it's released and then I think all sort of issues are going to surface and I will prepare to fix those. I believe there will be many issues but this process isn't going to find them. On Jun 22, 2013, at 7:20 AM, Vincent Latombe wrote: > OK, thanks for the clarification. > Vincent > > > 2013/6/22 Jason van Zyl : >> >> On Jun 21, 2013, at 11:48 PM, Vincent Latombe >> wrote: >> >>> Hello, >>> >>> I have a question about the alpha-1 release. I see that Aether has >>> been updated to 0.9.0 M2. >>> Does it implies that issue MNG-2802 (Concurrent-safe access to local >>> Maven repository) is now implemented ? >>> >> >> No, it does not. >> >>> If this is the case, then IMHO this should be mentioned, even >>> highlighted in the release notes. I think this kind of improvement is >>> very expected for all people doing CI, as this would allow a major >>> speed up and reduce storage for local repositories in this kind of >>> environment. >>> >>> Cheers, >>> >>> Vincent >>> >>> >>> 2013/6/21 Jörg Schaible Hi Jason, first, thanks that you actually take your time to look into it! Jason van Zyl wrote: > I unpacked your example and ran your preparation script and it fails in > 2.2.1 as well: > > https://gist.github.com/jvanzyl/5824206 The submodules are independent projects, you have to run "clean install". See the following session (I have modified the POMs of the children by adding a "" element, the original example is now ~2 years old): https://gist.github.com/joehni/6aa8516bd5408144ec53 Note, that after a successful run with M221, the build with M3x will no longer fail, but pack stale snapshots. To raise an error, you have to clean the repo from snapshots in /bugs/maven. > What's the overall usecase? You have a build with snapshots and you find > you need to go back to a release so you lock down to a previous release > and want to use that? The final distribution of our product or projects typically consists of hundreds of artifacts, where most of them have individual release cycles. In the HEAD revision those are linked in a nested directory structure using "builder POMs" i.e. POMs that have only modules declared, but get never released themselves (like the POM in the root of the example). The versions of the individual artifact are managed in a shared parent POM. In HEAD those are typically all snapshot versions. This changes after a major release of the overall product, then all those versions become final, the shared parent is released first followed by all other artifacts in dependency order using this released parent. This works all fine. Now we get into maintenance mode of that major release. Due to the independence of the artifacts we have to branch only the affected projects in case of bugs. Say we have JAR artifacts JAR-A to JAR-Z and we develop bug fixes for JAR-C and JAR-S. This means we branch the shared parent, set JAR-C and JAR-S to snapshot and also the artifacts that will assemble those to two jars, say WAR-X and DIST-ZIP. Then we create a builder for the maintenance branch that contains those jars, the war and the distribution zip as module. Building this we should get a war that contains JAR-C and JAR-S as snapshot and all the others as release and the distribution contains the affected WAR-X as snapshot and all other stuff as released version - the perfect situation to test the fix. Unfortunately M3 fails here, because it is under some circumstance not able to calculate the proper build order (maybe it does no longer take attached snapshot artifacts into account ?!?) and will either pack a stale snapshot from the local repository or fail, because the snapshot is built at a later time. > If you want to iteratively work on it together put it in a github repo. If you bear with me, may day-to-day work is with svn only and my learning curve with git/github is still steep, e.g. I did n
