Re: Replacement proposal for

[sebb]

Minor correction: the classes method will necessarily *detect* added
sources, because they won't have a class file.
What occurs as a result is another matter./
It might be worth considering forcing a full build as an option in
such cases if there is any way that adding a new source file can
affect the compilation of others.

On Mon, 22 Apr 2024 at 13:52, Martin Desruisseaux
 wrote:
>
> Hello all
>
> The Maven compiler plugin has an  boolean
> parameter with `true` as the default value. This parameter has issues
> discussed in MCOMPILER-209 [1], which has 61 votes. In short, builds are
> much faster when this parameter is set to `false`, which is
> counter-intuitive. During the refactoring for the Maven 4 compiler
> plugin, by looking at the source code, I saw the following issues with
> the current implementation:
>
>   * When  is enabled (which is the default),
> the plugin compares the list of source files in the current build
> with a list saved after the previous build in order to detect
> changes. But it seems to me that the plugin uses relative paths in
> one case, and absolute paths in the other cases. Consequently, the
> paths do not match and the plugin always thinks that all source
> files changed. I did not double-checked or tested (maybe I missed
> some `toAbsoluteFile()` calls). But if confirmed, it would explain
> the MCOMPILER-209 issue.
>   * The ways that the two lists are compared has a performance cost of
> O(N²). It could easily be O(N) instead by replacing one list by an
> hash set.
>   * The plugin tries to detect changes in dependencies, but the
> algorithm works only if the compilation never fail. Consider the
> following scenario:
>   o One project has 3 modules: A, B and C.
>   o Module B and C depends on A.
>   o Developer makes a change in A and run `mvn install`.
>   o Module A compiles successfully, but B fails because of the
> change in A.
>   o Developer fixes the build failure in B and run `mvn install`
> again. In this scenario, the incremental compilation will not
> see that C also needs to be rebuilt, because when
>  is enabled, the plugin compares the
> JAR timestamps with the build start time. In this scenario, the
> second build start time is after the `A.jar` creation time.
> Maybe this issue was unnoticed because the issue explained in
> the first bullet point caused the plugin to always recompile
> everything anyway.
>
> I propose to deprecate  in Maven 4 and
> replace it by a new parameter: . Its value would
> be a comma-separated list of values instead of a single boolean flag.
> Those values specify which methods to use for deciding which files to
> recompile:
>
>   * "sources": check for changes in source files, including whether a
> file has been deleted. This method uses a file saved by the previous
> build in the "target/maven-status"  directory (as done by the
> current implementation).
>   * "classes": check whether the source file is more recent than the
> class file. This method does not need any "maven-status" file from
> the previous build, but does not detect whether a file has been
> added or removed.
>   * "dependencies": check whether a dependency has changed (using a more
> robust algorithm than the current one).
>   * "modules": do not specify any file to the compiler and use the
> `--module` option instead, in which case the compiler will scan the
> directories itself and decides itself which files to recompile based
> on their timestamp. This option is available for modular projects only.
>
> The current  boolean flag maps to above
> proposal as below:
>
>   * `true` is approximately equivalent to "sources,dependencies", except
> that I propose to not rebuild everything when a file is added (it is
> usually not needed).
>   * `false` is equivalent to "classes".
>
> As seen from above, the current  actually
> mixes two aspects that could be treated separately: whether to check if
> a dependency changed, and whether to use a list saved from the previous
> build for checking if a source file changed. The comma-separated value
> proposal would allow users to control those aspects independently.
>
>  Martin
>
> [1]https://issues.apache.org/jira/browse/MCOMPILER-209

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Notes on maven-compiler-plugin work

[sebb]

On Mon, 18 Mar 2024 at 07:50, Romain Manni-Bucau  wrote:
>
> Hi Martin,
>
> Since we'll go v4 and really change the impl I guess we can drop all the
> compiler args from properties and the not relevant options.

It would be helpful if there was a migration page that explained to
users how to handle settings that are no longer supported. This could
be quoted in the relevant error message.

> Ultimately the only options would be:
>
> * fork options
> * compiler args
> * log/outputs options
>
> Anything else brings confusion and prevents us to validate properly the
> command before it is executed (as of today).
>
> +1 to not "preparePaths" and just let the compilation be native.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
>
>
> Le lun. 18 mars 2024 à 00:31, Martin Desruisseaux <
> martin.desruisse...@geomatys.com> a écrit :
>
> > Hello all
> >
> > I'm not yet ready to submit a pull request for the reworked
> > maven-compiler-plugin, but I would like to report some details about
> > changes that would come, if accepted. This work is for Maven 4 only, the
> > plugin for Maven 3 will stay unaffected.
> >
> > As proposed on GitHub comment [1], I'm modifying the implementation for
> > using the standard javax.tools.JavaCompiler interface instead of the
> > Plexus compiler. That interface is part of standard JDK since Java 6. It
> > seems that the Eclipse compiler provides also an implementation of that
> > interface, so compiler independence should be preserved. Forked
> > compilation is handled by a custom implementation of that interface. The
> > javax.tools.JavaCompiler interface has some methods needed for Java
> > modules, for which I saw no direct equivalence in Plexus API. The gap
> > may grow larger if future Java versions bring more evolution to the
> > compiler API. The standard interface also has a cache mechanism that may
> > bring performance improvements (to be verified) when compiling more than
> > one set of sources, e.g. for multi-versions. It also opens the door for
> > handling source and classes that are not files, for example by doing
> > everything in memory (I have no plan to use this features now, but it
> > become a possibility for the future).
> >
> > The way to handle compiler options has been modified. Previously, the
> > Maven plugin validated some options before to pass them to the compiler.
> > For example, if the  value contains anything else than
> > "lines", "vars" or "source", the plugin raised an error. The intend was
> > to provide more informative message. But in the javax.tools.JavaCompiler
> > interface, there is an API telling us whether an option is supported.
> > Therefor, the new plugin version first asks to the compiler whether the
> > option is supported, and only if the compiler said "no", the validation
> > is performed for producing the error message. Consequently, if the
> > compiler claims to support the "-g:foo" option, then the plugin will no
> > longer block the use of the "foo" value in  even if the
> > plugin does not know that value.
> >
> > The set of plugin parameters is the same as before: no addition and no
> > removal, but there is some deprecation. Of course, what to deprecate or
> > not is open to discussion. In the current state of work, the following
> > parameters are deprecated but are still working:
> >
> >   *  (a single String): already replaced by
> >  (a list of Strings) since Maven 3.1.
> >   * : replaced by ordinary dependencies with
> > proc, a new artifact type introduced in Maven 4-alpha13.
> >
> > The following parameters are marked as deprecated for removal in the
> > current state of work. They all became no-op in the new plugin:
> >
> >   * : the documentation is not really explicit,
> > but it seems to be about forcing the use of java.lang.Compiler
> > instead of javax.tools.JavaCompiler (it does not seem to be about
> > the javac command). The java.lang.Compiler class was deprecated
> > since Java 9 and no longer exists in Java 21.
> >   * : bundling many class files into a single file can
> > be considered as the task of separated plugins, for example the JAR
> > plugin. Furthermore, this parameter does not fit well in the context
> > of Module Source Hierarchy, because the output is not a single JAR.
> >   * : the way that the javax.tools.JavaCompiler
> > API is designed, this parameter does not seem relevant to instances
> > of that interface. The parameter may be partially relevant to some
> > objects used by JavaCompiler, but not fully (e.g. the "reuseSame"
> > parameter value stay inapplicable). I suggest to let those decisions
> > as plugin implementation details.
> >  

Re: User friendly release notes

[sebb]

On Thu, 14 Mar 2024 at 08:18, Tamás Cservenák  wrote:
>
> Howdy,
>
> What I usually do is copy-paste JIRA release notes to GH release notes:
> https://github.com/apache/maven-gpg-plugin/releases/tag/maven-gpg-plugin-3.2.0
>
> As this contains links to issues, but our JIRA does require account, so for
> people "just looking around" is not simple to collect them, agreed.

Huh?
Most Jira projects can be viewed without needing an account.
Of course an account is needed to contribute.

> Sometimes (if I don't forget) usually copy the public link to release notes
> as well, like here:
> https://github.com/apache/maven-resolver/releases/tag/maven-resolver-2.0.0-alpha-8
>
> Thanks
> T
>
>
> On Thu, Mar 14, 2024 at 6:57 AM Richard Eckart de Castilho 
> wrote:
>
> > Hi,
> >
> > > On 13. Mar 2024, at 23:58, Slawomir Jaranowski 
> > wrote:
> > >
> > > It looks as most usable will be to manage release notes also in GitHub at
> > > least as link to jira public url for release notes.
> > > Yes I know we don't have (or have old one like maven-changes-plugin)
> > > perfect tools to help with this process.
> >
> > The changes plugin isn't maintained anymore and is buggy wrt. GitHub.
> >
> > For that reason, in Apache UIMA, we have switched to using the `gh` command
> > line to tool to generate release notes.
> >
> >  https://github.com/apache/uima-parent-pom/blob/main/pom.xml#L1036-L1087
> >
> > This one is *not* based on commit messages and therefore does not require
> > strong discipline.
> >
> > It is rather based on PR titles which can also be changed if necessary
> > shortly before a release.
> >
> > The output is (currently) still manually post-processed to make it a bit
> > nicer
> > (e.g. with emojis) and embed it into a larger release notes document...
> > but the
> > plan is to eventually automate that away as well.
> >
> > Here is an example raw output from the tool:
> >
> >
> > https://svn.apache.org/repos/asf/uima/site/archive/docs/d/uimaj-3.5.0/issuesFixed/github-report.md
> >
> > Here is an example release note from UIMA:
> >
> >  https://github.com/apache/uima-uimaj/releases/tag/rel%2Fuimaj-3.5.0
> >
> > Cheers,
> >
> > -- Richard
> >
> >
> > -
> > 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: [DISCUSS] Java version for Maven

[sebb]

On Tue, 27 Feb 2024 at 17:01, Benjamin Marwell  wrote:
>
> > Compiling for Java 8 with
> > Java 17 -release 8 is not the same as compiling with javac from JDK 8.
> > They do not produce the same byte code. There is a need to compile
> > *with* JDK 8, not just compile *for* JDK 8.
>
> And when would that be needed?

Isn't that needed for reproducible builds?

>
> On Tue, 27 Feb 2024, 13:33 Elliotte Rusty Harold, 
> wrote:
>
> > On Mon, Feb 26, 2024 at 7:24 PM Benjamin Marwell 
> > wrote:
> > >
> > > > 1. The Java version required by the project being built. That is, the
> > > byte code and API level of the project.
> > > > 2. The Java version used to compile the project.
> > > > 3. The Java version used to run Maven.
> > > > 4. The Java version used to compile and build Maven itself.
> > >
> > > > For #1, it is mandatory to support Java 8.
> > >
> > > You can compile Java 8 bytecode with a Java 8 JDK from a Maven running
> > > Java 17+ using toolchains
> > > or with the -release flag from any version 9+.
> > >
> > > > For #2, reproducible builds mean we have to be able to support what
> > > > customers are using and that can be anything from Java 8 - 21. It is
> > > > not sufficient to say Java 21 can compile to Java 8 since that does
> > > > not produce the same byte code as compiling with Java 8.
> > >
> > > That is the point.
> > > If you built the project with JDK 21 using the -release=8, you can get
> > > the same (reproducible) output with a similar OS and JDK 21.
> > >
> >
> > No, that's not the point. You are claiming that #1 and #2 are the
> > same. I do not believe they are the same. Compiling for Java 8 with
> > Java 17 -release 8 is not the same as compiling with javac from JDK 8.
> > They do not produce the same byte code. There is a need to compile
> > *with* JDK 8, not just compile *for* JDK 8.
> >
> > Toolchains support using JDK 8 to compile even though JDK 17 is
> > executing Maven, which does handle this. Unfortunately toolchains are
> > poorly designed, badly documented, and not widely understood within
> > the community. I'm trying to improve some of the docs for toolchains,
> > but that only goes so far. There's a fundamental problem that
> > toolchains are incompatible with a hermetic, one click build.
> >
> > --
> > Elliotte Rusty Harold
> > elh...@ibiblio.org
> >
> > -
> > 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: Replacement for Ant Mojo Extractor

[sebb]

On Sun, 8 Oct 2023 at 14:42, Slawomir Jaranowski  wrote:
>
> niedz., 8 paź 2023 o 12:57 sebb  napisał(a):
>
> > Is there a replacement for the Ant Mojo Extractor?
> > I understand this will be dropped in Maven 4.
> >
> > The Commons project uses it in the build-plugin, which is a helper
> > plugin to create various text files from the POM.
> >
> > Is there a plugin that can be used to generate arbitrary text files
> > from templates?
> >
>
> Looks like Maven Remote Resources Plugin [1] can do such a job for you.
> As example of sharing templates you can see Apache Resource Bundles [2]

Thanks, but AFAICT these are used to generate predefined files and add
them to output jars.
In the Commons case, some of the files are to be added to the site,
and some are used as templates for emails.

>
>
> >
> > Sebb
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
> [1]
> https://maven.apache.org/plugins/maven-remote-resources-plugin/index.html
> [2] https://maven.apache.org/apache-resource-bundles/index.html
>
> --
> Sławomir Jaranowski

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Replacement for Ant Mojo Extractor

[sebb]

Is there a replacement for the Ant Mojo Extractor?
I understand this will be dropped in Maven 4.

The Commons project uses it in the build-plugin, which is a helper
plugin to create various text files from the POM.

Is there a plugin that can be used to generate arbitrary text files
from templates?

Sebb

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Removal of plugin scripting support in Maven 4 needs better docn

[sebb]

https://maven.apache.org/plugin-tools/maven-script/ mentions in
passing that scripting support is deprecated and will be dropped in
Maven 4.

This is a major change, and should be made much more obvious. For
example, put it in its own paragraph, maybe make it bold.

Also the release notes for Maven 4 don't appear to mention this breaking change:
 https://maven.apache.org/docs/4.0.0-alpha-7/release-notes.html

Sebb

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [ANN] Apache Maven Archiver 3.4.0 released

[sebb]

On Sun, 24 Feb 2019 at 21:54, Michael Osipov  wrote:
>
> The Apache Maven team is pleased to announce the release of the Apache
> Maven Archiver, version 3.4.0.
>
> https://maven.apache.org/shared/maven-archiver/

This mail is sent to multiple mailing lists.
Not all recipients will be familiar with what all the various plugins do.

It would be helpful to include a short paragraph on what the purpose
of the plugin is.

> You should specify the version in your project's dependency configuration:
>
> 
>org.apache.maven
>maven-archiver
>3.4.0
> 
>
>
> Release Notes - Apache Maven Archiver - Version 3.4.0
>
> ** Bug
>  * [MSHARED-588] - User supplied Class-Path entry does not go first
>  * [MSHARED-782] - Deprecated option classpathMavenRepositoryLayout
> not marked as deprecated in the documentation
>  * [MSHARED-783] - Archiver documentation issue tracker 404
>
> ** New Feature
>  * [MSHARED-787] - Add optional buildEnvironment information to the
> manifest
>  * [MSHARED-798] - Add addDefaultEntries option (true by default)
>
> ** Improvement
>  * [MSHARED-362] - Support removing default manifest entries with
> Maven Archiver
>  * [MSHARED-777] - Remove deprecated main attributes from generated
> manifest
>  * [MSHARED-799] - Change "Created-By" manifest entry value to be
> reproducible
>  * [MSHARED-800] - Remove Maven version from pom.properties
>
>
> ** Wish
>  * [MSHARED-661] - Remove manifest entry "Built-By: " for
> reproducible builds
>  * [MSHARED-796] - use java.specification.version instead of
> java.version in Build-Jdk manifest entry
>
> ** Task
>  * [MSHARED-797] - Move current Build-Jdk manifest entry to
> Build-Jdk-Spec
>
>
> Enjoy,
>
> -The Apache Maven team

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [ANN] Apache Maven 3.5.4 Released

[sebb]

I notice that Maven release announcements are no longer sent to the
ASF general announce list (announce@a.o)
The last one I found was 3.0.5 in 2013 [1]

Whilst it is unnecessary (and a bit noisy) to announce all plugin
updates on the ASF list, IMO new Maven releases should be announced.

[1] 
https://lists.apache.org/thread.html/f94bb1eae148ed2aec8d0aba5e5b4bb784d1953ea2487334427059de@1361631534@%3Cannounce.apache.org%3E

On 22 June 2018 at 10:25, Stephen Connolly  wrote:
> The Apache Maven team is pleased to announce the release of the Apache
> Maven 3.5.4.
>
> Apache Maven is a software project management and comprehension tool. Based
> on the concept of a project object model (POM), Maven can manage a
> project's build, reporting and documentation from a central piece of
> information.
>
> You can find out more about Apache Maven at https://maven.apache.org
>
> You can download the appropriate sources etc. from the download page:
> https://maven.apache.org/download.cgi
>
> Contributors
> 
> The Apache Maven value community before code and so firstly the team would
> like to thank the following contributors, without whom this release would
> not have been possible:
>
> Code contributors:
>
> - https://github.com/eis
> - Florian Brunner
> - Łukasz Dywicki
> - Sylwester Lachiewicz
>
> Issue reporters:
>
> - Falko Modler
> - Jarkko Rantavuori
> - Łukasz Dywicki
> - Mike Kelly
> - Sylwester Lachiewicz
>
> Community testers participating in voting for this release:
>
> - Dejan Stojadinovic
> - Enrico Olivelli
> - Romain Manni-Bucau
>
> Thank you all for your time and feedback (and apologies if we have missed
> anyone)
>
> Release Notes - Maven - Version 3.5.4
> =
>
> Bug:
> * [MNG-6370] - ConcurrencyDependencyGraph#getNumberOfBuilds() does not
> remove finished projects from unfinished ones
> * [MNG-6372] - On Windows Maven can output spurious ANSI escapes such
> as [0m [0m
> * [MNG-6382] - JANSI fails frequently with NumberFormatException when
> building in parallel
> * [MNG-6386] - ${project.baseUri} is not a valid URI (according to RFC
> 3986)
> * [MNG-6388] - Error Fetching Artifacts: "[B cannot be cast to
> java.lang.String"
> * [MNG-6403] - Artifact#VERSION_FILE_PATTERN does not escape period
> between date and time
> * [MNG-6410] - Add groupId to --resume-from suggestion if artifactId is
> not unique in reactor
>
> Improvement:
> * [MNG-5756] - Java home output in mvn -v is misleading
> * [MNG-5940] - Change the maven-source-plugin jar goal into jar-no-fork
> in Maven Super POM
> * [MNG-6362] - Add documentation information for GitHub
> * [MNG-6363] - Remove secret thread configuration property from code
> * [MNG-6364] - Enhanced Jenkinsfile to test Core with JDK 9
> * [MNG-6411] - Improve readability of project list returned when
> --resume-from option value is invalid
>
> Task:
> * [MNG-6377] - switch from Git-WIP to Gitbox
>
> Dependency upgrade:
> * [MNG-6344] - Upgrade Guice to 4.2.0
> * [MNG-6423] - Upgrade to Wagon 3.1.0
>
> Share and Enjoy,
>
> -The Apache Maven team

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Fwd: Error when processing doap file https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob_plain;f=doap_Maven.rdf;hb=HEAD:

[sebb]

Looks like the DOAP has moved. Please update the projects.xml file accordingly.


-- Forwarded message --
From: Projects 
Date: 21 March 2018 at 02:00
Subject: Error when processing doap file
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob_plain;f=doap_Maven.rdf;hb=HEAD:
To: Site Development 


https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob_plain;f=doap_Maven.rdf;hb=HEAD

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [ANN] Apache Maven 3.5.3 Released

[sebb]

What is the project about? Why should I be interested in it?
[rhetorical questions]

The Announce emails are sent to people not on the developer or user lists.
Most will have no idea what the project is about.

So the e-mails should contain at least brief details of what the
product does, and some info on why the new release might be of
interest to them.

Readers should not have to click a link to find out the basic information
(although of course it is useful to have such links for further detail).

(In this case there are no URLs ...)

Please can you add that information to future announce mails?

Thanks.


On 8 March 2018 at 12:31, Stephen Connolly  wrote:
> The Apache Maven team is pleased to announce the release of the Apache
> Maven 3.5.2
>
> You can download the appropriate sources etc. from the download page

URL?

> Contributors
> 
> The Apache Maven team would like to thank the following contributors,
> without whom this release would not have been possible:
>
> Code contributors:
>
> - Sylwester Lachiewicz
> - Bengt Söderberg
> - Robin Müller
> - Romain Manni-Bucau
>
> Issue reporters:
>
> - Ryan Heaton
> - Ryan J McDonough
> - Andreas Kurth
> - Ben Caradoc-Davies
> - Romain Manni-Bucau
> - Robin Müller
> - Dejan Stojadinović
> - Andrew Kennedy
> - Sylwester Lachiewicz
> - Andy Wilkinson
> - Eugene Pliskin
> - Tony Guan
>
> Community testers participating in voting for this release:
>
> - Sylwester Lachiewicz
> - Grzegorz Grzybek
>
> Thank you for your time and feedback.
>
>
> Release Notes - Maven - Version 3.5.3
>
> ***Known issues***:
>* [MNG-6372] - On Windows with -T option, Maven can output spurious ANSI
> escapes such as [0m [0m
>
> Bug:
> * [MNG-6188] - Console color not properly reset when interrupting build
> process
> * [MNG-6255] - Maven script cannot parse jvm.config with CRLF
> * [MNG-6282] - Console output has no colors in shell (both Git Bash and
> Cygwin) [regression in Jansi 1.16 / Maven 3.5.1]
> * [MNG-6296] - New option -Dstyle.color is not working
> * [MNG-6298] - 3.5.2: ClassNotFoundException: javax.annotation.security.
> RolesAllowed
> * [MNG-6300] - Multi module release creates empty directories in war
> file instead of jars
> * [MNG-6305] - Validation of CI friendly version incorrect
> * [MNG-6320] - Apparently wrong encoding of non-ascii java class
> filename in error messages in the maven log
> * [MNG-6323] - Deadlock in multithreaded dependency resolution
> * [MNG-6330] - [regression] Parents relativePath not verified anymore
>
> New Feature:
> * [MNG-6302] - Provide some "progress" hints
>
> Improvement:
> * [MNG-5992] - Git passwords are exposed as the Super POM still uses
> Maven Release Plugin 2.3.2
> * [MNG-6306] - Replace use of Guava in maven-resolver-provider with a
> lighter weight alternative
> * [MNG-6308] - display packaging & groupId:artifactId when building a
> module
> * [MNG-6332] - Cleaned up mvn.cmd Script
> * [MNG-6340] - [Performance]To make System.gc() call configurable in
> target summary code
> * [MNG-6342] - Emit a WARNING about LATEST/RELEASE in parent
> * [MNG-6352] - Printout version information at the end of the build
>
> Task:
> * [MNG-6331] - Remove maven-bundle-pugin from build pluginManagement
>
> Dependency upgrade:
> * [MNG-6312] - Update Maven Wagon dependency
> * [MNG-6335] - Update test framework Mockito from 1.10 to 2.12
> * [MNG-6353] - Upgrade maven-shared-utils to 3.2.1
>
> Enjoy,
>
> -The Apache Maven team

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Download links

[sebb]

On 17 November 2017 at 11:27, Robert Scholte <rfscho...@apache.org> wrote:
> This topic deserves a separate mailthread.
>
> Quoting Sebb on a different thread:
> "The download link points to the top-level of the ASF mirror system.
>
> This makes it very hard to use."
>
> AFAIK the ASF says there should be a download button for every released
> product.

Yes.

> In case of Maven we're talking about a lot of projects, and downloads should
> be redirected via a mirror.
>
> I don't think it is possible to do a deeplink to a specific folder.

Yes it is possible.

See
http://www.apache.org/dev/release-download-pages.html#closer
et seq.

In this case, you could use:

http://www.apache.org/dyn/closer.cgi/maven/plugins/

to at least show the correct directory.

and

http://www.apache.org/dyn/closer.cgi/maven/plugins/maven-jdeprscan-plugin-3.0.0-alpha-1-source-release.zip

to link to the file.

There are various other options; see the page quoted above.


> Also, in case of Maven plugins and other dependencies (all excluding the
> Maven distribution itself) it is kind of strange to provide a download link
> when we could assume that they only want to have the plugin/dependency XML
> fragment.
>
> I agree that the link is kind of useless right now, but also the best we can
> do when providing a direct download link.
> If there's no way to do a deeplink, I'd prefer to remove it from the pages
> and announcements.

The ASF mission is to produce open SOURCE software and links to the
source artifacts are required.

> thanks,
> Robert

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [ANN] Apache Maven JDeprScan Plugin 3.0.0-alpha-1 Released

[sebb]

On 17 November 2017 at 09:27, Robert Scholte  wrote:
> The Apache Maven team is pleased to announce the first release of the Apache
> Maven JDeprScan Plugin, version 3.0.0-alpha-1
>
> The Maven JDeprScan plugin is used to scan class files for uses of
> deprecated API elements. It uses the jdeprscan tool as provided with Java 9.
>
> https://maven.apache.org/plugins/maven-jdeprscan-plugin/
>
> You should specify the version in your project's plugin configuration:
>
> 
>   org.apache.maven.plugins
>   maven-jdeprscan-plugin
>   3.0.0-alpha-1
> 
>
> You can download the appropriate sources etc. from the download page:
>
> https://maven.apache.org/plugins/maven-jdeprscan-plugin/download.cgi

The download link points to the top-level of the ASF mirror system.

This makes it very hard to use.

> Enjoy,

Looking for the needle in the haystack?

> -The Apache Maven team

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [ANN] Apache Maven 3.5.0 Released

[sebb]

What is the project about? Why should I be interested in it?
[rhetorical questions]

The Announce emails are sent to people not on the developer or user lists.
Many will have no idea what the project is about.

So the e-mails should contain at least brief details of what the
product does, and some info on why the new release might be of
interest to them.

Readers should not have to click the link to find out the basic information
(although of course it is useful to have such links for further detail).

Please can you add that information to future announce mails?

Thanks.

I realise that Maven is a lot better known than some other ASF
projects, however that does not mean it is universally known.

HTTPD, Tomcat and Ant all include a summary of their project in Announce mails.

On 7 April 2017 at 22:07, Stephen Connolly  wrote:
> The Apache Maven team would like to announce the release of Apache Maven
> 3.5.0.
>
> You can download the appropriate sources etc. from the download page
>
> http://maven.apache.org/download.cgi
>
> Notable changes
> ===
>
> - ANSI colors added to the console output
> - Fix various bugs in mvn scripts regarding spaces, quotations, special
> characters, etc. also in combination with .mvn/ -files
> - Switch from Eclipse Aether to Maven Artifact Resolver
>
> What happened to Maven 3.4.0?
> =
>
> After Maven 3.3.9 was released, the Eclipse Aether project was retired and
> the code base was migrated to the Apache Maven project.
>
> The original goal for the 3.4.0 release was to replace Aether with the
> exact same code after migration to the Apache Maven project and then
> proceed with bug fixes to the resolver code as well as other areas of Maven.
>
> The migration of the code between the two foundations took longer than
> expected and as a result there were other changes committed to Maven core
> that were outside the scope of intent for 3.4.0.
>
> In order to refocus on the original intent for 3.4.0, the decision was
> taken to revert the Maven core history to the point of the 3.3.9 release
> and merge in the desired changes one at a time.
>
> Because there had been a lot of communication about different features
> being delivered and bugs fixed in Maven 3.4.0 and the new history may not
> contain them in the first release, the decision was taken to forever burn
> the 3.4.x release line.
>
> More detail on this decision can be read in the mailing list archive[1].
>
> Contributors
> 
>
> The Apache Maven team would like to thank the following contributors,
> without whom this release would not have been possible:
>
> Code contributors:
>
> - Alex Henrie
> - Andriy
> - Archimedes Trajano
> - Arlo Louis O'Keeffe
> - August Shi
> - Christoph Böhme
> - Harald Wellmann
> - Jason Dillon
> - Joseph Walton
> - Josh Soref
> - Miriam Lee
> - Nemo Chen
> - Sébastian Le Merdy
> - Stuart McCulloch
> - Tobias Oberlies
> - Robert Patrick
>
> Issue reporters:
>
> - Alex Henrie
> - Andreas Sewe
> - Andrew Haines
> - Andriy
> - Anthony Whitford
> - Archimedes Trajano
> - August Shi
> - Ben Caradoc-Davies
> - Christoph Böhme
> - Daniel Spilker
> - Falko Modler
> - Fred Bricon
> - Harald Wellmann
> - Jeffrey Alexander
> - Josh Soref
> - Kengo TODA
> - Konrad Windszus
> - Laird Nelson
> - Larry Singer
> - Meytal Genah
> - Mike Drob
> - Miriam Lee
> - Nemo Chen
> - Peter Kjær Guldbæk
> - Rahul Thakur
> - Richard Raumberger
> - Stuart McCulloch
> - Tobias Oberlies
> - Zac Thompson
>
> Community testers participating in voting for this release series:
>
> -  Grzegorz Grzybek
> -  Petr Široký
> -  Mark Derricutt,
> -  Dejan Stojadinović
> -  Thomas Collignon
> -  Fred Cooke
> -  Raphael Ackermann
> -  Elliot Metsger
> -  Chas Honton
> -  Dennis Kieselhorst
>
> The Apache Maven Project Management Committee would also like to thank all
> the committers to the project for their efforts during the chaos that was
> the great reset when the 3.4.x release lines were burned.
>
> Release Notes - Maven - Version 3.5.0
> =
>
> Bugs:
>
> * [MNG-5297] - Site should tell 'prerequisites.maven is deprecated'
> * [MNG-5368] - UnsupportedOperationException thrown when version range
> is not correct in dependencyManagement definitions
> * [MNG-5629] - ClosedChannelException from
> DefaultUpdateCheckManager.read
> * [MNG-5815] - "mvn.cmd" does not indicate failure properly when using
> "&&"
> * [MNG-5823] - mvnDebug doesn't work with M2_HOME with spaces - missing
> quotes
> * [MNG-5829] - mvn shell script fails with syntax error on Solaris 10
> * [MNG-5836] - logging config is overridden by $M2_HOME/lib/ext/*.jar
> * [MNG-5852] - mvn shell script invokes /bin/sh but requires Bash
> functions
> * [MNG-5895] - Problem with CI friendly usage of ${..} which is already
> defined via property in pom file.
> * [MNG-5958] - java.lang.String cannot be cast to
> 

Re: [ANN] Apache Maven quarterly report

[sebb]

On 31 January 2015 at 01:33, Hervé Boutemy hbout...@apache.org wrote:
 As every ASF project, Apache Maven regularly reports to the Apache board about
 the status of the project. Our latest report (January 21st, 2014) is shown
 below:

 Apache Maven is a widely-used project build tool, targeting mainly Java
 development. Apache Maven promotes the use of dependencies via a
 standardized coordinate system, binary plugins, and a standard build
 lifecycle.

 * General Information

   * Work on plugin releases to define common 2.2.1 minimum Maven version
 and Java 5 requirements continues: we created an automated report [1]
 that shows 33 plugins are ready from 49. Once finished, we expect to
 start 3.x line of plugins with Maven 3 and Java 6 minimum requirements.

   * There was a contest to create a new Maven logo and create a mascot:
 the winning logo is [2] and the winning mascot (officially christened)
 The Maven Owl [3]. Work is now in progress to integrate it to the Maven
 site.

   * We're studying Jira migration from Codehaus to Apache for better end-users
 consistency, since we've got feedback about users lost when requiring to
 create a Jira account at Codehaus.

   * Compliance with ASF source header policy

 We enabled rat check on every build in maven-parent POM 25 to ensure full
 compliance from now on.
 Issue closed: this report is the last one with status on this topic.

 * Community

   * No new committer this quarter (last added on 2014-08-25)

   * No new committer this quarter (last added on 2014-03-17)

The above two lines cannot both be true.

I expect one was meant to be about PMC members rather than committers.


   * Mailing List activity
Oct..Dec 2013Jul..Sep 2014Oct..Dec 2014
 User List: 959  723  680
 Developers List:   704  980 1506

 Users mailing list activity has been reduced a little bit in the last
 three months whereas the developers mailing list activity has
 strongly increased within the same time frame.

 * Releases

   Core

   * Maven 3.2.5 (2014-12-20)

   Plugins

   * Maven Compiler Plugin 3.2 (2014-10-13)
   * Maven Assembly Plugin 2.5 (2014-10-26)
   * Maven Clean Plugin 2.6.1 (2014-10-26)
   * Maven Surefire Plugin 2.18 (2014-11-01)
   * Maven Failsafe Plugin 2.18 (2014-11-01)
   * Maven JXR Plugin 2.5 (2014-11-02)
   * Maven Assembly Plugin 2.5.1 (2014-11-04)
   * Maven Toolchains Plugin 1.1 (2014-11-11)
   * Maven PMD Plugin 3.3 (2014-11-14)
   * Maven Assembly Plugin 2.5.2 (2014-11-21)
   * Maven Ant Plugin 2.4 (2014-12-15)
   * Maven Assembly Plugin 2.5.3 (2014-12-17)
   * Maven AntRun Plugin 1.8 (2014-12-26)
   * Maven Surefire Plugin 2.18.1 (2014-12-28)
   * Maven Failsafe Plugin 2.18.1 (2014-12-28)
   * Maven EAR Plugin 2.10 (2014-12-31)
   * Maven Plugin Plugin 3.4 (2015-01-04)
   * Maven Project Info Reports Plugin 2.8 (2015-01-10)
   * Maven WAR Plugin 2.6 (2015-01-11)
   * Maven EJB Plugin 2.5 (2015-01-15)
   * Maven GPG Plugin 1.6 (2015-01-19)

   Other

   * Maven Shared Utils 0.7 (2014-10-17)
   * Maven Shared Filtering 1.3 (2014-10-18)
   * Maven Parent POM 25 (2014-10-22)
   * Maven Plugins Parent POM 26 (2014-10-22)
   * Maven Shared Parent POM 21 (2014-10-22)
   * Maven Skins Parent POM 10 (2014-10-22)
   * Maven Archiver 2.6 (2014-10-31)
   * Maven Repository Builder 1.0 (2014-11-13)
   * ASF Parent POM 16 (2014-11-16)
   * Maven Parent POM 26 (2014-11-16)
   * Maven Plugins Parent POM 27 (2014-11-16)
   * Maven Wagon 2.8 (2014-11-16)
   * Apache Maven Plugin Testing 3.3.0 (2014-12-30)
   * Maven Plugin Tools 3.4 (2015-01-04)

 [1] 
 https://builds.apache.org/job/dist-tool-plugin/site/dist-tool-prerequisites.html

 [2] http://maven.apache.org/images/maven-logo-black-on-white.png

 [3] http://maven.apache.org/images/mascot-large.png


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [ANN] Apache Common POM Version 16 Released

[sebb]

On 17 November 2014 19:57, Karl Heinz Marbaise khmarba...@apache.org wrote:
 The Apache Maven team is pleased to announce the release of the
 Apache Common POM, version 16.

 This POM (org.apache:apache) configures common Maven settings for
 projects to use ASF infrastructure.

 Documentation live at: http://maven.apache.org/poms/asf.

 To use this parent, you should specify the version in your project's
 plugin configuration:

 parent
   groupIdorg.apache/groupId
   artifactIdapache/artifactId
   version16/version
 /parent

 Changes since previous release:

 http://svn.apache.org/viewvc/maven/pom/tags/apache-16/pom.xml?view=markup

The above URL is wrong; it does NOT show the differences.

 Enjoy,

 -The Apache Maven team

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [ANN] Apache Common POM version 15 released

[sebb]

On 28 September 2014 12:17, Benson Margulies bimargul...@apache.org wrote:
 The Apache Maven team is pleased to announce the release of the Apache
 Common POM, version 15.

 This POM (org.apache:apache) configures common Maven settings for
 projects to use ASF infrastructure.

 Documentation live at: http://maven.apache.org/poms/asf.

Does not exist

 To use this parent, you should specify the version in your project's
 plugin configuration:

 parent
   groupIdorg.apache/groupId
   artifactIdapache/artifactId
   version15/version
 /parent

 Changes since previous release:

 http://svn.apache.org/viewvc/maven/pom/tags/apache-15/pom.xml?view=markup

Does not show changes.

 Enjoy,

 -The Apache Maven team

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Operating system requirement

[sebb]

On 28 March 2014 12:09, Anders Hammar and...@hammar.net wrote:
 The requirements also says:

 Disk No minimum requirement. Approximately 100MB will be used for
 your local repository, however this will vary depending on usage ...

 AFAICT there _is_ a minimum requirement which is needed to store a
 basic set of plugins.
 And of course there is the Maven application itself, though that is
 tiny (under 6Mb for 3.0.5)

 100MB is quite a small repository; they can easily grow to 1GB or more.


 So you think we should change to for example:
 Approximately 10MB is required for the Maven installation itself. In
 addition to that, additional disk space will be used for your local Maven
 repository. The size of your local repository will vary depending on usage
 but calculate for at least 500MB.

 Maven 3.2.1 is around 8MB, but Maven 3.0 is around 3.5MB and 2.x is even
 smaller. Stating approx 10MB will give us some space.

 My local repo is 1.5GB so I'm guessing an average dev would need at least
 500MB.

 ok?

+1

 /Anders



  /Anders
 
  [1] http://maven.apache.org/download.cgi#Requirements

 -
 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: Operating system requirement

[sebb]

On 25 March 2014 21:42, Anders Hammar and...@hammar.net wrote:
 Under requirements [1], we're stating the following:

 No minimum requirement. On Windows, Windows NT and above or Cygwin is
 required for the startup scripts. Tested on Windows XP, Fedora Core and Mac
 OS X.

 What exactly are we trying to say with the On Windows, Windows NT and
 above or Cygwin is required for the startup scripts. sentence? is it just
 me or is the English weird?

 Also, what is tested on WinXP, Fedora and Mac? Is it Maven which is tested
 on these platforms, or the startup scripts? AFAIK we have no CI IT builds
 on Fedora. But we have it on Ubuntu. Also, should we state Mac even though
 we don't have CI IT builds on Mac? I know we're several devs on Mac though.

The requirements also says:

Disk No minimum requirement. Approximately 100MB will be used for
your local repository, however this will vary depending on usage ...

AFAICT there _is_ a minimum requirement which is needed to store a
basic set of plugins.
And of course there is the Maven application itself, though that is
tiny (under 6Mb for 3.0.5)

100MB is quite a small repository; they can easily grow to 1GB or more.

 /Anders

 [1] http://maven.apache.org/download.cgi#Requirements

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Convert everything to Git

[sebb]

AIUI, SVN is still required by Infra because of svnpubsub:

- for the dist repo (that is not a big deal)
- for websites (might cause some grief)

On 13 February 2014 03:37, Jason van Zyl ja...@tesla.io wrote:
 Can we start the process of converting everything to Git. I don't really see 
 any benefit in using Subversion any longer.

 If so then we should just get together for a day and convert them and then 
 get infra to use what we converted to do the flip.

 Jason (who would be happy to never execute svn again)
 -
 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: [ANN] Apache Maven SCM Publish Plugin 1.0 Released

[sebb]

On 6 February 2014 22:01, Hervé BOUTEMY herve.bout...@free.fr wrote:
 yes, the change was intentional, to fix
 http://jira.codehaus.org/browse/MSCMPUB-10 you issued :)

Thanks for the info.
I'm surprised this required M3, because I have written an M2 plugin
which uses the user/password info. It was not difficult.

 Adding a note on the website and announce is a good idea.
 Too late this time for announce, but I'll modify site

Thanks.

 And perhaps add something in the announce template

Please.

 Regards,

 Hervé

 Le mercredi 5 février 2014 13:09:39 sebb a écrit :
 On 4 February 2014 07:23, Hervé Boutemy hbout...@apache.org wrote:
  The Apache Maven team is pleased to announce the release of the Apache
  Maven SCM Publish Plugin, version 1.0

 It looks as though the plugin now requires Maven 3, whereas 1.0-beta2 did
 not.

 Was that change intentional?

 If so, it ought to have been mentioned in the release notes (and on the
 website)
  The maven-scm-publish-plugin is a utility plugin to allow publishing Maven
  website to any supported SCM. The primary goal was to have an utility
  plugin to allow Apache projects to publish Maven websites via the ASF
  svnpubsub system. The plugin has been tested with git scm too and by
  example can push content for github pages.
 
  http://maven.apache.org/plugins/maven-scm-publish-plugin/
 
  You should specify the version in your project's plugin configuration:
 
  plugin
 
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-scm-publish-plugin/artifactId
version1.0/version
 
  /plugin
 
 
  Release Notes - maven-scm-publish-plugin - Version 1.0
 
  ** Improvement
 
  * [MSCMPUB-6] - when creating a directory in svn, if checkout fails,
  wait
 
  a few seconds and retry
 
  * [MSCMPUB-7] - Add timestamp when commit starts (and ends)
  * [MSCMPUB-10] - Pick up SCM credentials from settings.xml server
  section
  * [MSCMPUB-11] - display content size (number of directories, files,
  and
 
  size)
 
  ** Story
 
  * [MSCMPUB-4] - Need a working example for GitHub/gh-pages, preferably
 
  naturally linked to natural site lifecycle, and multi-module
 
  ** Task
 
  * [MSCMPUB-3] - Upgrade to SCM-1.9
 
  Enjoy,
 
  -The Apache Maven team

 -
 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


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [ANN] Apache Maven SCM Publish Plugin 1.0 Released

[sebb]

On 4 February 2014 07:23, Hervé Boutemy hbout...@apache.org wrote:
 The Apache Maven team is pleased to announce the release of the Apache Maven
 SCM Publish Plugin, version 1.0

It looks as though the plugin now requires Maven 3, whereas 1.0-beta2 did not.

Was that change intentional?

If so, it ought to have been mentioned in the release notes (and on the website)

 The maven-scm-publish-plugin is a utility plugin to allow publishing Maven
 website to any supported SCM. The primary goal was to have an utility plugin
 to allow Apache projects to publish Maven websites via the ASF svnpubsub
 system. The plugin has been tested with git scm too and by example can push
 content for github pages.

 http://maven.apache.org/plugins/maven-scm-publish-plugin/

 You should specify the version in your project's plugin configuration:

 plugin
   groupIdorg.apache.maven.plugins/groupId
   artifactIdmaven-scm-publish-plugin/artifactId
   version1.0/version
 /plugin


 Release Notes - maven-scm-publish-plugin - Version 1.0

 ** Improvement
 * [MSCMPUB-6] - when creating a directory in svn, if checkout fails, wait
 a few seconds and retry
 * [MSCMPUB-7] - Add timestamp when commit starts (and ends)
 * [MSCMPUB-10] - Pick up SCM credentials from settings.xml server section
 * [MSCMPUB-11] - display content size (number of directories, files, and
 size)

 ** Story
 * [MSCMPUB-4] - Need a working example for GitHub/gh-pages, preferably
 naturally linked to natural site lifecycle, and multi-module

 ** Task
 * [MSCMPUB-3] - Upgrade to SCM-1.9

 Enjoy,

 -The Apache Maven team

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Boy have we got a broken webpage

[sebb]

On 16 November 2013 21:02, Hervé BOUTEMY herve.bout...@free.fr wrote:
 ouch, strange: 'r' were replaced by 'n'

Perhaps a botched attempt at changing line endings from (CR) to (LF) ?

 I just had a look at archive content, and it does not have the problem

 so I just copied archive content into actual plugin documentation location:
 another reason why a svn copy on staged documentation (which was voted on) is
 better than regenerating a new documentation

 Regards,

 Hervé

 Le samedi 16 novembre 2013 14:32:00 Benson Margulies a écrit :
 http://maven.apache.org/plugins/maven-scm-publish-plugin/examples/one-module
 -configuration.html

 -
 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


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Converting site documentation to Markdown

[sebb]

Regarding automatic conversion to Markdown:

The main ASF site was converted from xdoc to Markdown. Some tools werr
written for this, but they were not 100% accurate; we were still
finding conversion issues a year or so later. [We've probably not
found them all yet] Whether these conversion issues are important is
another matter, but there are certainly some area such as the license
pages where it is vital that the conversion is accurate -- and
problems were found there.

AFAIR, Markdown still has some areas where it is weak - for example
numeric lists, which was one of the license page issues.

The existing HTML documentation is presumably all in SCM, so it should
be possible to compare the new with the old if necessary.
And if layout etc problems are detected later, the originals should be
available.

Might be worth creating tags for the source and generated HTML just
before and after conversion to make it easier to dig into the history
later.


On 6 October 2013 10:13, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
 2013/10/6 Stephen Connolly stephen.alan.conno...@gmail.com:
 IMHO

 Betamax == AsciiDoc
 VHS == MarkDown

 Being a bunch of old geezers, we all know which was technically superior.

 I had to teach my oldest kid how to operate a non-mobile phone the
 other day (she dialled number before lifting the handset)

 Kristian

 -
 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] Release Maven 3.1.1

[sebb]

On 22 September 2013 08:13, Mark Derricutt m...@talios.com wrote:
 On 22/09/2013, at 9:28 AM, Jason van Zyl ja...@tesla.io wrote:

 A check is performed to ensure that each file in the source archive is
 present in the release revision


 Should that not be the other way around? That every file in the git clone
 should be in the source archive?  Or vice versa, that should be neither
 more, or less files?

The point of checking the source archive against the SCM tag is to
ensure that all the files in the source release have got the correct
license clearance.
It is assumed that license conditions are checked when content is
added to SCM, because that is in the CLA signed by committers.

If there are files in the SCM tag that are not in the source release,
that is generally not a problem as far as licensing is concerned
(thought it's possible that the NOTICE/LICENSE files might need
adjusting to take account of the missing files).

Of course the missing files may be important for the functioning of
the code - that is a separate matter.

Ideally the two file sets agree, with the possible exception of some
files that only belong in SCM, e.g. .gitignore is not needed in the
source archive, and it does not make much sense to release a DOAP
file. There may be some other SCM-only files. But I agree any
discrepancies need to be investigated.

 Mark

 --
 Mark Derricutt — twitter — podcast — blog — google+


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven 3.1.1

[sebb]

On 22 September 2013 05:03, Jason van Zyl ja...@tesla.io wrote:

 On Sep 21, 2013, at 7:44 PM, sebb seb...@gmail.com wrote:

 On 22 September 2013 03:09, Jason van Zyl ja...@tesla.io wrote:
 On Sep 21, 2013, at 6:16 PM, sebb seb...@gmail.com wrote:

 On 21 September 2013 23:09, Jason van Zyl ja...@tesla.io wrote:

 It would still be automated.
 However the source data would come form the vote e-mail, which makes
 more sense to me.


 If it were generated I would agree. Manually making an email is not 
 automated or consistent.

 I don't care how the e-mail is created; it can be automated.

 What matters is that the content is understandable and complete.


 Ok, then we agree. We should try to keep the vote email threads for the 
 votes. I think what you asked for was the impetus for the tool I made and it 
 helped do a more complete audit than I've ever done manually. But the SCM 
 coordinates are not a requirement for the release email currently and if 
 we're going to discuss that then we probably shouldn't hijack the vote 
 threads which we both just did.

I don't believe it's hijacking the vote e-mail to point out that it is
missing vital information.
But the subsequent discussion has certainly veered off-topic.

 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -








-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: rules for Apache release and tooling to help cheking compliance

[sebb]

On 22 September 2013 09:49, Hervé BOUTEMY herve.bout...@free.fr wrote:
 Starting a separate thread to not pollute any vote.

 Isn't Apache Creadur the right place to:
 1. discuss and refine Apache requirements

No.

 2. work on tooling

Possibly.

 Regards,

 Hervé

 -
 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] Release Maven 3.1.1

[sebb]

On 21 September 2013 22:28, Jason van Zyl ja...@tesla.io wrote:
 You will now be infamous :-)

 https://github.com/jvanzyl/sebbalizer

 If you don't like the name, happy to change it. I thought it was appropriate 
 and meant as a compliment for being thorough.

Thanks, but no thanks.
Sorry, but I don't like the association.

 With a given staging URL, groupId, artifact, and version it will retrieve the 
 source archive, and binary archive and the corresponding SHA1s and validates 
 the SHA1s are right. It unpacks both the archives, digs into the binary 
 archive to find the maven-core JAR to retrieve the build.properties which 
 contains the SHA1 of the release revision from which the source archive was 
 made. A git clone is performed and moved to the release revision. A check is 
 performed to ensure that each file in the source archive is present in the 
 release revision and that the SHA1 of the each file in the source archive 
 matches the SHA1 of the file from the corresponding release revision.

 So for this release using the Sebbalizer I only found the DEPENDENCIES file 
 to not exist in the release revision, every other file I consider valid and 
 verified. I believe that for this release no errant files slipped in and it's 
 good.

 People should review the code. I spent an hour on this by yanking a bunch of 
 stuff together so it might very well have errors. I have one hardcoded url 
 for the Git repository but I'll pull that out of the POM and then hopefully 
 it can be used generally to validate source archives for releases.

The general procedure seems fine, but the SCM coordinates still need
to be in the release vote in order to tie everything together for the
release vote, and for the historical record.

Rather than pick out the details from the maven-core jar, the
information should be taken from the release vote e-mail.
That can then be used to ensure that the artifacts match the release
vote, and that the sources match the SCM tag.
The build.properties entry should be checked to ensure it is the same
as the value from the release vote mail.

 On Sep 20, 2013, at 5:40 PM, sebb seb...@gmail.com wrote:

 On 17 September 2013 16:39, Jason van Zyl ja...@tesla.io wrote:
 Hi,

 Maven Core ITs are good, and the license/notice issue has been resolved so 
 I'm rolling 3.1.1 again.

 Here is a link to Jira with 6 issues resolved:
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18968

 Staging repo:
 https://repository.apache.org/content/repositories/maven-065/

 The distributable binaries and sources for testing can be found here:
 https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/

 Specifically the zip, tarball, and source archives can be found here:
 https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip
 https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.tar.gz
 https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.zip
 https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.tar.gz

 Source release checksum(s):
 apache-maven-3.1.1-src.zip sha1: 2251357aa47129674df578e787504b72cd57ed4d

 The full scm coordinates are needed.
 The pom includes the git URL and tag, but that is not immutable.
 Exactly the same tag was used for the previous vote.

 To identify the source archive uniquely, additional info such as a
 hash is needed, so the hash is now included in the vote e-mail.
 The same applies to the SCM tag.

 Staging site:
 http://people.apache.org/~jvanzyl/maven-3.1.1/

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

 Thanks,

 The Maven Team
 Thanks,







 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -








-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven 3.1.1

[sebb]

On 21 September 2013 23:09, Jason van Zyl ja...@tesla.io wrote:

 On Sep 21, 2013, at 2:51 PM, sebb seb...@gmail.com wrote:

 On 21 September 2013 22:28, Jason van Zyl ja...@tesla.io wrote:
 You will now be infamous :-)

 https://github.com/jvanzyl/sebbalizer

 If you don't like the name, happy to change it. I thought it was 
 appropriate and meant as a compliment for being thorough.

 Thanks, but no thanks.
 Sorry, but I don't like the association.


 No problem.

 https://github.com/jvanzyl/source-release-validator

Thanks.

 With a given staging URL, groupId, artifact, and version it will retrieve 
 the source archive, and binary archive and the corresponding SHA1s and 
 validates the SHA1s are right. It unpacks both the archives, digs into the 
 binary archive to find the maven-core JAR to retrieve the build.properties 
 which contains the SHA1 of the release revision from which the source 
 archive was made. A git clone is performed and moved to the release 
 revision. A check is performed to ensure that each file in the source 
 archive is present in the release revision and that the SHA1 of the each 
 file in the source archive matches the SHA1 of the file from the 
 corresponding release revision.

 So for this release using the Sebbalizer I only found the DEPENDENCIES file 
 to not exist in the release revision, every other file I consider valid and 
 verified. I believe that for this release no errant files slipped in and 
 it's good.

 People should review the code. I spent an hour on this by yanking a bunch 
 of stuff together so it might very well have errors. I have one hardcoded 
 url for the Git repository but I'll pull that out of the POM and then 
 hopefully it can be used generally to validate source archives for releases.

 The general procedure seems fine, but the SCM coordinates still need
 to be in the release vote in order to tie everything together for the
 release vote, and for the historical record.

 Rather than pick out the details from the maven-core jar, the
 information should be taken from the release vote e-mail.

 No, I think an automated way is better.

It would still be automated.
However the source data would come form the vote e-mail, which makes
more sense to me.

 As part of the release the release revision should be made available for use 
 in the email.

I agree the release revision needs to be part of the e-mail; that is
what I have been requesting all along.

 That can then be used to ensure that the artifacts match the release
 vote, and that the sources match the SCM tag.
 The build.properties entry should be checked to ensure it is the same
 as the value from the release vote mail.

 I want to go in the direction of automation and to generate this as part of 
 the release so it will contain the revision.

+1

 Going from a manually generated email is not a good solution.

I disagree; so long as the e-mail has a reasonably standard format, it
should be easy enough to extract the data to to the checks.

 I can see the need for a secondary reference but I'm going to fully automate 
 it.

It's not a secondary reference.
The vote e-mail is the primary reference.

 If I turn this tool into a Nexus Plugin I can potentially just generate the 
 email.

Again, I think that's backwards.

The point is that any reviewer needs to be able to check the release.

 At any rate, I understand your concern to make sure there are no errant files 
 and I believe this tool addresses those concerns.

The problem is that without the SCM coordinates it's not possible for
a reviewer to independently check the source contents.
They may use your tool to do so, or they may use other methods; that
is up to them.
The point is that it must be possible to independently audit the source release.

The vote e-mail chain is the official means by which releases are sanctioned.
Therefore the vote e-mail needs to contain all the required
information; it should not be necessary for the reviewer to go digging
for the information.

 I think at this point with this it's not really necessary to put the release 
 revision in the email template but that's for the PMC to decide. I'll 
 continue to use the official template but I will also run this tool as part 
 of the core releases.


 On Sep 20, 2013, at 5:40 PM, sebb seb...@gmail.com wrote:

 On 17 September 2013 16:39, Jason van Zyl ja...@tesla.io wrote:
 Hi,

 Maven Core ITs are good, and the license/notice issue has been resolved 
 so I'm rolling 3.1.1 again.

 Here is a link to Jira with 6 issues resolved:
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18968

 Staging repo:
 https://repository.apache.org/content/repositories/maven-065/

 The distributable binaries and sources for testing can be found here:
 https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/

 Specifically the zip, tarball, and source archives can be found here:
 https://repository.apache.org/content

Re: [VOTE] Release Maven 3.1.1

[sebb]

On 22 September 2013 03:09, Jason van Zyl ja...@tesla.io wrote:
 On Sep 21, 2013, at 6:16 PM, sebb seb...@gmail.com wrote:

 On 21 September 2013 23:09, Jason van Zyl ja...@tesla.io wrote:

 It would still be automated.
 However the source data would come form the vote e-mail, which makes
 more sense to me.


 If it were generated I would agree. Manually making an email is not automated 
 or consistent.

I don't care how the e-mail is created; it can be automated.

What matters is that the content is understandable and complete.

 As part of the release the release revision should be made available for 
 use in the email.

 I agree the release revision needs to be part of the e-mail; that is
 what I have been requesting all along.

 That can then be used to ensure that the artifacts match the release
 vote, and that the sources match the SCM tag.
 The build.properties entry should be checked to ensure it is the same
 as the value from the release vote mail.

 I want to go in the direction of automation and to generate this as part of 
 the release so it will contain the revision.

 +1

 Going from a manually generated email is not a good solution.

 I disagree; so long as the e-mail has a reasonably standard format, it
 should be easy enough to extract the data to to the checks.

 Well, we'll just agree to disagree. Nothing made by a human is never going to 
 be as consistent as an automated process.

I did not say that.
However if a human uses an email template (as at present) the result
should be sufficiently consistent that parsing would not be too
difficult.

 If I can get the sha1 for the release in an automated way, I'm not going to 
 cut and paste it from somewhere. I already grabbed the wrong one already in 
 one of the releases. There is no way you're going to convince me that once a 
 tool has been validated to yield the correct information that making a manual 
 email is better.

Again, I don't care how the e-mail is created, so long as it contains
all the required information in a readable format.


 I can see the need for a secondary reference but I'm going to fully 
 automate it.

 It's not a secondary reference.
 The vote e-mail is the primary reference.

 If I turn this tool into a Nexus Plugin I can potentially just generate the 
 email.

 Again, I think that's backwards.

 The point is that any reviewer needs to be able to check the release.

 At any rate, I understand your concern to make sure there are no errant 
 files and I believe this tool addresses those concerns.

 The problem is that without the SCM coordinates it's not possible for
 a reviewer to independently check the source contents.
 They may use your tool to do so, or they may use other methods; that
 is up to them.
 The point is that it must be possible to independently audit the source 
 release.


 You have the SCM coordinates now.

I'm not sure what you mean by that.

 Is the issue not addressed with the tool I made?

Does the tool ensure that the SCM coordinates are included in the vote email?

 There is no way that you will be able manually review the release as 
 accurately as the tool.

When I review a release I don't only check files and sigs and hashes.
I use a combination of tools and visual inspection.
Sometimes the inspection turns up oddities that can then be added to
the automated tooling.

 You think it's useful to go file by file and manually check all the files?

No, but it can pay to inspect some files.

 That you are going to do it consistently and accurately without tooling?

No, I never said that.

 If you want to, all the information will be there in the releases I do from 
 now on from the report I'm generating and it's accurate and not susceptible 
 to my cut/paste errors.

So long as the required information is in the vote e-mail, that's all I require.

 If from the staging process the email is emitted along with the report then 
 you can do anything manually you wish but everything to that point will have 
 been created in a consistent, repeatable way that can be performed by someone 
 else (at least when I'm done).

I'll just point out that there have been several plugin releases using
the standard release process that added errant files to the source
archive.
Which is one reason why independent audits are needed.

 The vote e-mail chain is the official means by which releases are sanctioned.

 I have no issue sending an email.

 Therefore the vote e-mail needs to contain all the required
 information; it should not be necessary for the reviewer to go digging
 for the information.


 Are you manually going to go through each of our releases file by file?

No, but I may inspect some files.

 If you are I will ask to put the revision in the template.

Thanks, that's part of what I'm asking; the SCM URL is also needed.

 After looking, and making the tool I don't think it's necessary.

You seem to be missing the point that the vote e-mail should be
capable of independent audit.
And should contain

Re: [VOTE] Release Maven 3.1.1

[sebb]

On 17 September 2013 16:39, Jason van Zyl ja...@tesla.io wrote:
 Hi,

 Maven Core ITs are good, and the license/notice issue has been resolved so 
 I'm rolling 3.1.1 again.

 Here is a link to Jira with 6 issues resolved:
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18968

 Staging repo:
 https://repository.apache.org/content/repositories/maven-065/

 The distributable binaries and sources for testing can be found here:
 https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/

 Specifically the zip, tarball, and source archives can be found here:
 https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip
 https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.tar.gz
 https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.zip
 https://repository.apache.org/content/repositories/maven-065/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.tar.gz

 Source release checksum(s):
 apache-maven-3.1.1-src.zip sha1: 2251357aa47129674df578e787504b72cd57ed4d

The full scm coordinates are needed.
The pom includes the git URL and tag, but that is not immutable.
Exactly the same tag was used for the previous vote.

To identify the source archive uniquely, additional info such as a
hash is needed, so the hash is now included in the vote e-mail.
The same applies to the SCM tag.

 Staging site:
 http://people.apache.org/~jvanzyl/maven-3.1.1/

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

 Thanks,

 The Maven Team
 Thanks,







-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: What is the top level of the source tree and what exactly is an Apache distribution?

[sebb]

On 16 September 2013 10:50, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 In an effort to get to a definitive answer for
 http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201309.mbox/%3CCA%2BnPnMwUvmaoOuBJ7dpVj9qAmwVnbfcxTid7UZgc6EdEL7%2BOpg%40mail.gmail.com%3EI
 did some searching...

 The ASF Licensing How To includes this helpful simple snippet:

 http://www.apache.org/dev/licensing-howto.html#source-tree-location

 # Location Within the Source Tree



 LICENSE and NOTICE belong at the [top level of the source tree][1]. They
 may be named LICENSE.txt and NOTICE.txt, but the bare names are preferred.


   [1]:  http://www.apache.org/legal/src-headers.html#notice


 If we wander over to that link:

 http://www.apache.org/legal/src-headers.html#notice

 # NOTICE file



 0. Every Apache distribution should include a NOTICE file in the top
 directory, along with the standard LICENSE file.

AIUI a distribution is not the same as a release.

 1. The top of each NOTICE file should include the following text, suitably
 modified to reflect the product name and year(s) of distribution of the
 current and past versions of the product:
   Apache [PRODUCT_NAME]
   Copyright [] The Apache Software Foundation
   This product includes software developed at
   The Apache Software Foundation (http://www.apache.org/).
 2. The remainder of the NOTICE file is to be used for required third-party
 notices.
 3. The NOTICE file may also include copyright notices moved from source
 files submitted to the ASF.
 4. See also Modifications to NOTICE


 Now that is mostly OK but it does beg the following questions:

 1. What exactly is the top level of the source tree? Is it the tree in
 SCM or is it the tree in the .zip or .tar.gz files that end up in the /dist
 directory. The text I have seen would seep to imply that the phrase refers
 to the top level of the source tree in an Apache distribution... which
 brings us to..

 2. What exactly is an Apache distribution? To the best of my knowledge
 this is just the .zip or .tar.gz files that end up in the /dist directory.

AIUI a distribution is where the source is distributed to the general public.
As such, that includes formal releases, as well as SCM.

 I know that other people have opinions that things like SCM also are Apache
 distributions, but it would seem to me that the two links I cited above
 would be *very clear* in stating that SCM is viewed as a distribution if it
 was the official view of the ASF (and perhaps it is... in which case please
 fix the website)

+1 to making website clearer.

 By way of some concrete examples, and because real world examples are much
 much better than abstract hypotheticals.

 Consider the Apache Maven project. We are a top level project with many
 things that we release. We have Maven Core itself and we have many plugins
 and other shared components that have their own release lifecycles... we
 also have some components in our Subversion repository and others in GIT
 repositories.

 Case 1
 --

 For technical reasons, i.e. given the way GIT works, it is easiest to put
 any group of things that get released as an atomic unit into a single GIT
 repository. Thus we have Maven Core (with the 12 modules that are used to
 build Maven Core) at
 https://git-wip-us.apache.org/repos/asf?p=maven.git;a=tree Now as it
 happens the top level of that group of 12 modules is the root of that GIT
 repository and we have LICENSE and NOTICE files there. As part of our
 release process we produce a source distribution of that tree and hence the
 LICENSE and NOTICE files will be at the root of the
 apache-maven-x.y.x-src.tar.gz and apache-maven-x.y.x-src.zip files that end
 up in the /dist directory. So in this case it does not matter whether an
 Apache distribution is only the apache-maven-x.y.x-src.tar.gz files or also
 includes the https://git-wip-us.apache.org/repos/asf?p=maven.git GIT
 repository. In this case we have the files at the root of both source trees.

 Case 2
 --

 Now let us consider a different set of atomically released modules.
 Surefire consists of again 12 modules that all get released at the same
 time. The source tree in SCM is
 https://git-wip-us.apache.org/repos/asf?p=maven-surefire.git;a=tree as
 again that is a separate source repository from our other stuff. Our most
 recent source release of Surefire is
 http://www.apache.org/dist/maven/surefire/surefire-2.16-source-release.zipand
 if we look at that file

 $ unzip -l ~/Downloads/surefire-2.16-source-release.zip */LICENSE */NOTICE
 Archive:  /Users/stephenc/Downloads/surefire-2.16-source-release.zip
   Length Date   TimeName
     
   108  08-11-13 16:57
 surefire-2.16/surefire-api/src/main/appended-resources/META-INF/NOTICE
 11358  08-11-13 16:57   surefire-2.16/LICENSE
   178  08-11-13 16:57   surefire-2.16/NOTICE
     ---
 11644

Re: Leaving Maven Core POMs at major.minor-SNAPSHOT

[sebb]

Some other ASF PMCs have no qualms about skipping version numbers.

For example AIUI Tomcat creates a release candidate, and if the vote
fails, they bump the patch version.
For example they released 7.0.30 and 7.0.32; there is no 7.0.31.

The other point I would make is that bumping the way the release
plugin currently works has some problems.
It should not update trunk until the release succeeds.
There would then be no need to fix up trunk if a release vote fails.
See MRELEASE-721


On 15 September 2013 13:49, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 Another data point is exactly how many times have we got patch release .0 
 right?

 2.1.0 - seriously borked use 2.2.1
 2.2.0 - seriously borked use 2.2.1
 3.0.0-3.0.2 - not recommended for use
 3.0.3 - ok but has issues with release plugin
 3.0.4 - first 3.x that could be considered stable
 3.1.0 - borked enough to recommend not for production IMHO

 From experience I, as a PMC member, do not recommend my day job picking up a 
 x.y.0 from Maven... So why should we hold patch numbers as special enough 
 that they must increase by 1 between blessed releases *when we cannot even 
 guarantee that a blessed release is ready for production?*

 Maybe we should split this into another DISCUSS thread, though I am conscious 
 that this subject is distracting from actually getting releases out the 
 door... OTOH allowing skips in patch release numbers would allow work on core 
 to continue without having to coordinate a nobody commit to master while 
 vote in play policy which seems completely against how one should use GIT

 Sent from my iPhone

 On 15 Sep 2013, at 12:30, Fred Cooke fred.co...@gmail.com wrote:

 Exactly! :-)


 On Sun, Sep 15, 2013 at 1:29 PM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 But you asked the wrong jump then.

 It would be 3.0.5 to 4.0.4... There's no way we'd skip 4.0.x to go to 4.1.x
 if we have not had a 4.0.x released at all.

 My point is patch version people are perfectly fine with skips Minor
 version skips would be bad, but there is zero need for them.

 On Sunday, 15 September 2013, Robert Scholte wrote:

 That someone might have been me.
 I did an internal poll to ask if people would understand if Maven would
 jump from 3.0.5 to 4.1.3.
 None of them did, they all wondered what happened to the missing
 versions.
 Sure they understand that 4.1.3 is newer than 3.0.5, these aren't morons.

 One major difference is that Maven can't update itself to the latest
 version. If that would be the case, then versions are only interesting to
 reproduce issues and people often wouldn't see/matter the version.

 *If* we would allow gaps, we should also introduce LTS releases.

 For now, I'd prefer reusing versions and no gaps. I don't mind deleting
 tags, otherwise I'd prefer the usage of RCx during votes.

 Robert

 Op Sun, 15 Sep 2013 02:05:55 +0200 schreef Fred Cooke 
 fred.co...@gmail.com:

 Last time someone asked this I went straight to central and found two
 examples. There are plenty out there. I'm not doing it again, you're more
 than capable. Also note, it's not much different to go from 3.1.2 to
 3.1.4
 than it is from 3.1.5 to 3.2.0; you still miss out versions, an infinite
 number of them, in fact.

 Preferring not to have gaps is a choice and one I was aware you lot would
 make. That's why I didn't bring it up in the first place despite
 preferring
 to just straight miss them. Or just straight publish all releases (as is
 normal mvn practice since forever) and direct users to the ones that
 work... I *think* this is what Stephen is trying to say, but if I'm
 honest
 I missed out a lot of what he wrote. Forgive me, it's 2am here.


 On Sun, Sep 15, 2013 at 2:00 AM, Jason van Zyl ja...@tesla.io wrote:

 The users may well be developers, but I don't think that warrants
 changing
 a normal pattern. Maybe only I consider this a normal pattern, but I
 don't
 know of any examples, personally, where externally represented versions
 have gaps in them. I'd ask you the same question I asked Stephen as to
 whether you know of any projects, or products, that do this? Just because
 we can skip versions isn't a good reason to do so. If lots of projects do
 it then it's worth considering. Have any examples on hand?

 For now while I'm doing the core releases, I would prefer not to have
 gaps. Call me provincial, but I'd like to do what we've always done since
 the inception of the project unless there is a compelling reason to do
 otherwise.

 On Sep 14, 2013, at 7:48 PM, Fred Cooke fred.co...@gmail.com wrote:

 Jason, PLEASE understand that you do NOT have a single user. Not even
 one.
 Nada. Zilch. You have developers. Developers, by definition, are not
 *completely* stupid (though some try to fool us!). They can handle
 missing
 versions. If you released firefox 12 after firefox 10 it would be
 confusing
 for millions, maven 3.1.5 after maven 3.1.1, ONLY a complete and utter
 moron would be confused by 

Re: [VOTE] Release Maven 3.1.1

[sebb]

On 14 September 2013 11:19, Baptiste Mathus bmat...@batmat.net wrote:
 Le 13 sept. 2013 19:00, sebb seb...@gmail.com a écrit :

 On 12 September 2013 21:52, Baptiste Mathus m...@batmat.net wrote:
  2013/9/12 sebb seb...@gmail.com
 
  On 12 September 2013 14:52, Arnaud Héritier aherit...@gmail.com
 wrote:
   On Thu, Sep 12, 2013 at 3:44 PM, sebb seb...@gmail.com wrote:
  
   On 10 September 2013 16:33, Daniel Kulp dk...@apache.org wrote:
   

   Like we already say I think we aren't convinced about this because it
  will
   imply to recopy these files across ~50 projects (plugins, shared
 libs)
  and
   thus update them the day we'll decide/need to do it. That's why we
 always
   prefered to bundle them at build time.
 
  The point is:
  the NL files should be at the top-level of SCM.
  That is because SCM URLs are published, so the readers need to know
  the what the license conditions are.
 
 
  Wasn't it explained that SCM is actually a convenience, and that only
 the
  released source tarballs would actually matter here?

 It's not the case that SCM is only a convenience; the SCM locations
 are published to end-users on the web-site and in the POMs.

 And the SCM is anyway public.

 Well, according to this thread
 http://mail-archives.apache.org/mod_mbox/maven-dev/201308.mbox/%3CCA+nPnMwE=ON4AfAmFq3dvnpMdcsKt0u3G=RYvQWiZsmL=ea...@mail.gmail.com%3E

That thread was about including the SCM details in the VOTE e-mail.

 and Stephen's answer, that was my understanding and I don't remember
 someone pointing to somewhere at apache docs stating this is actually wrong.

  In this case, Arnaud's point about only adding them at build time is
 really
  valid here.

 Not sure what you are referring to here, but the build is not relevant
 to this discussion.

 Once again, in the above linked thread, my readings make me think there
 were already answers from pmc that you would then have to agree to
 disagree on this point.
 And this is also the understanding I have from last Arnaud's answer above.

There is a thread active currently on legal-discuss; at least one of
the ASF legal types thinks that SCM trees should have NL files.

 
  The fact that having the NL files there would likely have ensured
  they were in the source archive is an added bonus; it's not the
  primary reason for having them at the top-level of SCM.
 
 
  In the source, but possibly different in many places and having to
 maintain
  their sameness, that's again Arnaud's point.
 
  As an external observer and a developer, not duplicating files in many
  places as they should really be the same seem quite a sound PMC choice to
  me.

 -
 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] Release Maven 3.1.1

[sebb]

On 12 September 2013 21:52, Baptiste Mathus m...@batmat.net wrote:
 2013/9/12 sebb seb...@gmail.com

 On 12 September 2013 14:52, Arnaud Héritier aherit...@gmail.com wrote:
  On Thu, Sep 12, 2013 at 3:44 PM, sebb seb...@gmail.com wrote:
 
  On 10 September 2013 16:33, Daniel Kulp dk...@apache.org wrote:
  
   -1
  
   The src.tar.gz and src.zip files have lost their top level NOTICE and
  LICENSE files.   This is a regression from 3.1.0 (and 3.0.5).   That
  definitely needs to be fixed.  I don't have time today to look into
 that,
  but might tomorrow if someone doesn't beat me to it.
 
  The NL files should also be present at the top-level of SCM.
  That is not a release-blocker per se, however if they had been there
  they would likely also be in the source archives at the top-level,
  which is a release blocker IMO.
 
 
 
  Like we already say I think we aren't convinced about this because it
 will
  imply to recopy these files across ~50 projects (plugins, shared libs)
 and
  thus update them the day we'll decide/need to do it. That's why we always
  prefered to bundle them at build time.

 The point is:
 the NL files should be at the top-level of SCM.
 That is because SCM URLs are published, so the readers need to know
 the what the license conditions are.


 Wasn't it explained that SCM is actually a convenience, and that only the
 released source tarballs would actually matter here?

It's not the case that SCM is only a convenience; the SCM locations
are published to end-users on the web-site and in the POMs.

And the SCM is anyway public.

 In this case, Arnaud's point about only adding them at build time is really
 valid here.

Not sure what you are referring to here, but the build is not relevant
to this discussion.



 The fact that having the NL files there would likely have ensured
 they were in the source archive is an added bonus; it's not the
 primary reason for having them at the top-level of SCM.


 In the source, but possibly different in many places and having to maintain
 their sameness, that's again Arnaud's point.

 As an external observer and a developer, not duplicating files in many
 places as they should really be the same seem quite a sound PMC choice to
 me.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven 3.1.1

[sebb]

On 10 September 2013 16:33, Daniel Kulp dk...@apache.org wrote:

 -1

 The src.tar.gz and src.zip files have lost their top level NOTICE and LICENSE 
 files.   This is a regression from 3.1.0 (and 3.0.5).   That definitely needs 
 to be fixed.  I don't have time today to look into that, but might tomorrow 
 if someone doesn't beat me to it.

The NL files should also be present at the top-level of SCM.
That is not a release-blocker per se, however if they had been there
they would likely also be in the source archives at the top-level,
which is a release blocker IMO.

 Ran a couple builds with the result of building the source and things look OK.

 I checked the rest of the contents with the tag and everything looks OK.
 There are three files in the git repo that aren't part of the release 
 (/.gitignore, /.gitattributes, and /apache-maven/src/bin/.gitattributes), but 
 those files really are specific to our scm and thus don't need to be in the 
 source release.

 Most likely, the doap_Maven.rdf shouldn't be part of the release either.  
 Probalby shouldn't be in the main maven git repo.   Definitely not a big deal.

 Dan



 On Sep 8, 2013, at 9:07 AM, Jason van Zyl ja...@tesla.io wrote:

 Hi,

 Here is a link to Jira with 6 issues resolved:
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18968

 Staging repo:
 https://repository.apache.org/content/repositories/maven-016/

 The distributable binaries and sources for testing can be found here:
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/

 Specifically the zip, tarball, and source archives can be found here:
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.tar.gz
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.zip
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.tar.gz

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

 Thanks,

 The Maven Team








 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com


 -
 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] Release Maven 3.1.1

[sebb]

On 12 September 2013 14:52, Arnaud Héritier aherit...@gmail.com wrote:
 On Thu, Sep 12, 2013 at 3:44 PM, sebb seb...@gmail.com wrote:

 On 10 September 2013 16:33, Daniel Kulp dk...@apache.org wrote:
 
  -1
 
  The src.tar.gz and src.zip files have lost their top level NOTICE and
 LICENSE files.   This is a regression from 3.1.0 (and 3.0.5).   That
 definitely needs to be fixed.  I don't have time today to look into that,
 but might tomorrow if someone doesn't beat me to it.

 The NL files should also be present at the top-level of SCM.
 That is not a release-blocker per se, however if they had been there
 they would likely also be in the source archives at the top-level,
 which is a release blocker IMO.



 Like we already say I think we aren't convinced about this because it will
 imply to recopy these files across ~50 projects (plugins, shared libs) and
 thus update them the day we'll decide/need to do it. That's why we always
 prefered to bundle them at build time.

The point is:
the NL files should be at the top-level of SCM.
That is because SCM URLs are published, so the readers need to know
the what the license conditions are.

The fact that having the NL files there would likely have ensured
they were in the source archive is an added bonus; it's not the
primary reason for having them at the top-level of SCM.

 Arnaud

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: git commit: Add a LICENSE/NOTICE that can be picked up for the src assembly

[sebb]

On 11 September 2013 21:40,  dk...@apache.org wrote:
 Updated Branches:
   refs/heads/master 02d124230 - eb2f2b1ac


 Add a LICENSE/NOTICE that can be picked up for the src assembly

Thanks, that also sorts out the top-level SCM NL files.


 Project: http://git-wip-us.apache.org/repos/asf/maven/repo
 Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/eb2f2b1a
 Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/eb2f2b1a
 Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/eb2f2b1a

 Branch: refs/heads/master
 Commit: eb2f2b1acdeade6f3e4b2ca5f771ba3a03e3f7b9
 Parents: 02d1242
 Author: Daniel Kulp dk...@apache.org
 Authored: Wed Sep 11 16:39:30 2013 -0400
 Committer: Daniel Kulp dk...@apache.org
 Committed: Wed Sep 11 16:39:30 2013 -0400

 http://git-wip-us.apache.org/repos/asf/maven/blob/eb2f2b1a/NOTICE
 --
 diff --git a/NOTICE b/NOTICE
 new file mode 100644
 index 000..bb189f8
 --- /dev/null
 +++ b/NOTICE
 @@ -0,0 +1,7 @@
 +Apache Maven
 +Copyright 2001-2013 The Apache Software Foundation
 +
 +This product includes software developed at
 +The Apache Software Foundation (http://www.apache.org/).
 +
 +

Trivial nit: there's one extra blank line at the end of the file.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven 3.1.1

[sebb]

On 12 September 2013 18:20, Arnaud Héritier aherit...@gmail.com wrote:

 The point is:
 the NL files should be at the top-level of SCM.
 That is because SCM URLs are published, so the readers need to know
 the what the license conditions are.


 For the License when you are reading some code hosted on apache.org I think
 nobody should have a doubt about it.

Not all code included in our SCM is necessarily AL-licensed.
Obviously it has to be AL-compatible so the project as a whole is AL,
but parts can be non-AL.



 The fact that having the NL files there would likely have ensured
 they were in the source archive is an added bonus; it's not the
 primary reason for having them at the top-level of SCM.

  Arnaud

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




 --
 -
 Arnaud Héritier
 http://aheritier.net
 Mail/GTalk: aheritier AT gmail DOT com
 Twitter/Skype : aheritier

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven 3.1.1

[sebb]

I've just realised that you said the hash is in the maven core jar.
That is a binary artifact, and has no direct relationship with the
source artifact on which people are supposed to be voting.

I don't think it's possible to tie the SCM tag to this vote thread
for the record without the hash (and git repo) being provided in
this e-mail.

Also, I don't think the quoted hash is correct.

Are you sure that

c9950d777c7368e51431500c29aecf1e11e3d2c6

is the hash for the build?

On 10 September 2013 09:19, Karl Heinz Marbaise khmarba...@gmx.de wrote:
 +1 [non-binding]

 Tested with
 * appassembler-maven-plugin (trunk: r18705)

 * maven-invoker-plugin (trunk: r1521365),

 * iterator-maven-plugin (git: 07ddf1a6a8fe4b60dbb84ce944c3a4f7828bff3e
 https://github.com/khmarbaise/iterator-maven-plugin),

 * several of my own projects worked like a charm.



 On 9/8/13 3:07 PM, Jason van Zyl wrote:

 Hi,

 Here is a link to Jira with 6 issues resolved:

 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18968

 Staging repo:
 https://repository.apache.org/content/repositories/maven-016/

 The distributable binaries and sources for testing can be found here:

 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/

 Specifically the zip, tarball, and source archives can be found here:

 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip

 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.tar.gz

 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.zip

 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.tar.gz

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

 Thanks,

 The Maven Team










 Mit freundlichem Gruß
 Karl-Heinz Marbaise
 --
 SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
 Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029
 Hauptstrasse 177 USt.IdNr: DE191347579
 52146 Würselen   http://www.soebes.de


 -
 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] Release Maven 3.1.1

[sebb]

On 10 September 2013 14:23, Jason van Zyl ja...@tesla.io wrote:

 On Sep 10, 2013, at 7:53 AM, sebb seb...@gmail.com wrote:

 I've just realised that you said the hash is in the maven core jar.
 That is a binary artifact, and has no direct relationship with the
 source artifact on which people are supposed to be voting.


 It is supposed to be the SHA1 of the release from which the build was made.

 I don't think it's possible to tie the SCM tag to this vote thread
 for the record without the hash (and git repo) being provided in
 this e-mail.


 Well, I'm going to leave it out for now. I'll do what's strictly in the 
 template here:

 http://maven.apache.org/developers/release/maven-project-release-procedure.html#Call_the_vote

Which as I have argued all along is insufficient.
- the vote email does not have vital information for the record
- indeed in the case of this vote, neither the vote e-mail nor the
source archive (on which people are supposed to be voting) has the
information.

I note that no-one who has voted so far has stated that the contents
of the source archives are all present and correct and that no files
are missing from the release and more importantly that there are no
files in the source archive that should not be there.

IMO this is the most important part of the release vote, along with
the NL contents.


 Also, I don't think the quoted hash is correct.


 It doesn't look correct, it appears to take the parent commit. This has 
 probably been
 the case for quite some time, in that the mvn -v command doesn't actually 
 tell you
 what commit it came from. I don't know if it's generally wrong, but this this 
 case
 c9950d777c7368e51431500c29aecf1e11e3d2c6 is the parent of

Where did you get the above hash from?
It does not seem to be the same as the one in the binary archive I downloaded.

On the git page:

https://git-wip-us.apache.org/repos/asf?p=maven.git;a=summary

the c995... hash seems to be associated with

[MNG-5509] org.apache.maven.repository.legacy.DefaultWa...

This happens to be the line after

[maven-release-plugin] prepare release maven-3.1.1  yellowmaven-3.1.1/yellow

which seems to have the following hash:

 892b464683645bcdc1d28febf0bf3cc1c3181350 which is the SHA1 for the release.

Also the above hash is the one I just found in build.properties.

And it agrees with mvn -v

Apache Maven 3.1.1 (892b464683645bcdc1d28febf0bf3cc1c3181350;
2013-09-05 18:04:21+0100)

So I don't think there's a problem with the build process, but there
is still a major problem with the vote e-mail contents.


 I assumed someone actually tested this, or maybe it's being used in the 
 release for something it wasn't intended for. I'll take a look at the code. 
 But for now I will make the template from:

 http://maven.apache.org/developers/release/maven-project-release-procedure.html#Call_the_vote


 Are you sure that

 c9950d777c7368e51431500c29aecf1e11e3d2c6

 is the hash for the build?

 On 10 September 2013 09:19, Karl Heinz Marbaise khmarba...@gmx.de wrote:
 +1 [non-binding]

 Tested with
 * appassembler-maven-plugin (trunk: r18705)

 * maven-invoker-plugin (trunk: r1521365),

 * iterator-maven-plugin (git: 07ddf1a6a8fe4b60dbb84ce944c3a4f7828bff3e
 https://github.com/khmarbaise/iterator-maven-plugin),

 * several of my own projects worked like a charm.



 On 9/8/13 3:07 PM, Jason van Zyl wrote:

 Hi,

 Here is a link to Jira with 6 issues resolved:

 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18968

 Staging repo:
 https://repository.apache.org/content/repositories/maven-016/

 The distributable binaries and sources for testing can be found here:

 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/

 Specifically the zip, tarball, and source archives can be found here:

 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip

 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.tar.gz

 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.zip

 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.tar.gz

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

 Thanks,

 The Maven Team










 Mit freundlichem Gruß
 Karl-Heinz Marbaise
 --
 SoftwareEntwicklung Beratung SchulungTel.: +49 (0) 2405 / 415 893
 Dipl.Ing.(FH) Karl-Heinz MarbaiseICQ#: 135949029
 Hauptstrasse 177 USt.IdNr: DE191347579
 52146 Würselen   http://www.soebes.de


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven 3.1.1

[sebb]

On 10 September 2013 15:11, Jason van Zyl ja...@tesla.io wrote:

 On Sep 10, 2013, at 9:58 AM, sebb seb...@gmail.com wrote:

 On 10 September 2013 14:23, Jason van Zyl ja...@tesla.io wrote:

 On Sep 10, 2013, at 7:53 AM, sebb seb...@gmail.com wrote:

 I've just realised that you said the hash is in the maven core jar.
 That is a binary artifact, and has no direct relationship with the
 source artifact on which people are supposed to be voting.


 It is supposed to be the SHA1 of the release from which the build was made.

 I don't think it's possible to tie the SCM tag to this vote thread
 for the record without the hash (and git repo) being provided in
 this e-mail.


 Well, I'm going to leave it out for now. I'll do what's strictly in the 
 template here:

 http://maven.apache.org/developers/release/maven-project-release-procedure.html#Call_the_vote

 Which as I have argued all along is insufficient.
 - the vote email does not have vital information for the record
 - indeed in the case of this vote, neither the vote e-mail nor the
 source archive (on which people are supposed to be voting) has the
 information.

 I note that no-one who has voted so far has stated that the contents
 of the source archives are all present and correct and that no files
 are missing from the release and more importantly that there are no
 files in the source archive that should not be there.

 IMO this is the most important part of the release vote, along with
 the NL contents.

 Get the PMC to agree and put it in the template and I'll use what's in the 
 template.



 Also, I don't think the quoted hash is correct.


 It doesn't look correct, it appears to take the parent commit. This has 
 probably been
 the case for quite some time, in that the mvn -v command doesn't actually 
 tell you
 what commit it came from. I don't know if it's generally wrong, but this 
 this case
 c9950d777c7368e51431500c29aecf1e11e3d2c6 is the parent of

 Where did you get the above hash from?
 It does not seem to be the same as the one in the binary archive I 
 downloaded.


 There's the argument for automation!

It's actually an argument for quoting the hash in the vote e-mail and
for people to actually check it.

I find it strange that none of the reviewers noticed the problem.
That suggests to me that none of the reviewers are actually interested
in doing due diligence on the source archive contents.

 I didn't open up the JAR from the checked out build. So this is probably the 
 best way right now and you've verified the right hash is available from the 
 build itself so that's probably what you need.

No, as I already wrote, that is not suitable.

Voting is on source archives; it's no good having the hash buried away
in an indirectly related binary archive.

 On the git page:

 https://git-wip-us.apache.org/repos/asf?p=maven.git;a=summary

 the c995... hash seems to be associated with

 [MNG-5509] org.apache.maven.repository.legacy.DefaultWa...

 This happens to be the line after

 [maven-release-plugin] prepare release maven-3.1.1  
 yellowmaven-3.1.1/yellow

 which seems to have the following hash:

 892b464683645bcdc1d28febf0bf3cc1c3181350 which is the SHA1 for the release.

 Also the above hash is the one I just found in build.properties.

 And it agrees with mvn -v

 Apache Maven 3.1.1 (892b464683645bcdc1d28febf0bf3cc1c3181350;
 2013-09-05 18:04:21+0100)

 So I don't think there's a problem with the build process, but there
 is still a major problem with the vote e-mail contents.


 I assumed someone actually tested this, or maybe it's being used in the 
 release for something it wasn't intended for. I'll take a look at the code. 
 But for now I will make the template from:

 http://maven.apache.org/developers/release/maven-project-release-procedure.html#Call_the_vote


 Are you sure that

 c9950d777c7368e51431500c29aecf1e11e3d2c6

 is the hash for the build?

 On 10 September 2013 09:19, Karl Heinz Marbaise khmarba...@gmx.de wrote:
 +1 [non-binding]

 Tested with
 * appassembler-maven-plugin (trunk: r18705)

 * maven-invoker-plugin (trunk: r1521365),

 * iterator-maven-plugin (git: 07ddf1a6a8fe4b60dbb84ce944c3a4f7828bff3e
 https://github.com/khmarbaise/iterator-maven-plugin),

 * several of my own projects worked like a charm.



 On 9/8/13 3:07 PM, Jason van Zyl wrote:

 Hi,

 Here is a link to Jira with 6 issues resolved:

 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18968

 Staging repo:
 https://repository.apache.org/content/repositories/maven-016/

 The distributable binaries and sources for testing can be found here:

 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/

 Specifically the zip, tarball, and source archives can be found here:

 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip

 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache

Re: [VOTE] Release Maven 3.1.1

[sebb]

On 10 September 2013 16:33, Daniel Kulp dk...@apache.org wrote:

 -1

 The src.tar.gz and src.zip files have lost their top level NOTICE and LICENSE 
 files.   This is a regression from 3.1.0 (and 3.0.5).   That definitely needs 
 to be fixed.  I don't have time today to look into that, but might tomorrow 
 if someone doesn't beat me to it.

 Ran a couple builds with the result of building the source and things look OK.

 I checked the rest of the contents with the tag and everything looks OK.
 There are three files in the git repo that aren't part of the release 
 (/.gitignore, /.gitattributes, and /apache-maven/src/bin/.gitattributes), but 
 those files really are specific to our scm and thus don't need to be in the 
 source release.

OK, so is it necessary to check the release against the tag?
Or is that just your personal take on what a reviewer should do?

If it is necessary (for at least one reviewer) to do, then the SCM
coordinates need to be provided in a transparent manner so any
reviewer can do it, and the coordinates need to be part of the vote
e-mail for the public record.

 Most likely, the doap_Maven.rdf shouldn't be part of the release either.  
 Probalby shouldn't be in the main maven git repo.   Definitely not a big deal.

 Dan



 On Sep 8, 2013, at 9:07 AM, Jason van Zyl ja...@tesla.io wrote:

 Hi,

 Here is a link to Jira with 6 issues resolved:
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18968

 Staging repo:
 https://repository.apache.org/content/repositories/maven-016/

 The distributable binaries and sources for testing can be found here:
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/

 Specifically the zip, tarball, and source archives can be found here:
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.tar.gz
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.zip
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.tar.gz

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

 Thanks,

 The Maven Team








 --
 Daniel Kulp
 dk...@apache.org - http://dankulp.com/blog
 Talend Community Coder - http://coders.talend.com


 -
 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] Release Maven 3.1.1

[sebb]

On 9 September 2013 20:56, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 On 8 September 2013 18:51, Jason van Zyl ja...@tesla.io wrote:


 On Sep 8, 2013, at 1:12 PM, sebb seb...@gmail.com wrote:

  I thought you were going to include the SCM coordinates used to create
  the tarballs?
 

 Sorry, not intentional. I forgot.

  It's particularly important here, because AFAICT the SCM coordinates
  are not present in the POM.
  If true, then it's not possible to verify the files in the source
 tarballs.
 

 I hash is always in the distribution, it's how we show where it comes from
 when you type mvn -v. It's in the build properties in the core JAR and
 the hash in there is:

 c9950d777c7368e51431500c29aecf1e11e3d2c6


 Is that the SHA1 of the src.zip and src.tar.gz or is it the SHA1 of the git
 commit.

 What we are looking for on the vote emails is the SHA1 and MD5 of the
 src.zip and src.tar.gz so that interested parties can verify that the vote
 was against the source distribution that ends up in dist and central. Since
 the staging repository is deleted as part of the release process, and since
 what the PMC is voting on is the source bundles, we need the vote email to
 specify the hashes of the source bundle *for the record*...

+1, especially for the record

 Of course this is really easy to do as Maven helpfully uploads the hashes
 to the staging repository, but since it didn't happen if it wasn't on a
 mailing list (stephenc rolls his eyes) we need the release manager to
 ensure that the vote has this required information.

+1, especially idhiiwoaml

 Note: The commit hash is really nice to have, but is not part of the
 minimum set of required information, and we are trying to stick to minimum
 procedure. So we don't look for that *even* if other people think we should.


Part of the due diligence that should be performed by the reviewers is
to check that the source archives only contain files with the
appropriate licensing.
By far the easiest way to do this is to compare the source archive(s)
with the SCM tag, since it is assumed that due diligence has been
performed on the SCM contents.

This is critical information and needs to be readily available to the
reviewer, and for the record needs to be in the vote e-mail.
Otherwise it did not happen on the mailing list.



  Also, AFAIK, the PMC agreed to include hashes of the tarballs in vote
 e-mails?
 
  On 8 September 2013 14:07, Jason van Zyl ja...@tesla.io wrote:
  Hi,
 
  Here is a link to Jira with 6 issues resolved:
 
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18968
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-016/
 
  The distributable binaries and sources for testing can be found here:
 
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/
 
  Specifically the zip, tarball, and source archives can be found here:
 
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip
 
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.tar.gz
 
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.zip
 
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.tar.gz
 
  Vote open for 72 hours.
 
  [ ] +1
  [ ] +0
  [ ] -1
 
  Thanks,
 
  The Maven Team
 
 
 
 
 
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 

 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -









-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven 3.1.1

[sebb]

I thought you were going to include the SCM coordinates used to create
the tarballs?

It's particularly important here, because AFAICT the SCM coordinates
are not present in the POM.
If true, then it's not possible to verify the files in the source tarballs.

Also, AFAIK, the PMC agreed to include hashes of the tarballs in vote e-mails?

On 8 September 2013 14:07, Jason van Zyl ja...@tesla.io wrote:
 Hi,

 Here is a link to Jira with 6 issues resolved:
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18968

 Staging repo:
 https://repository.apache.org/content/repositories/maven-016/

 The distributable binaries and sources for testing can be found here:
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/

 Specifically the zip, tarball, and source archives can be found here:
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.tar.gz
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.zip
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.tar.gz

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

 Thanks,

 The Maven Team








-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven 3.1.1

[sebb]

On 8 September 2013 18:51, Jason van Zyl ja...@tesla.io wrote:

 On Sep 8, 2013, at 1:12 PM, sebb seb...@gmail.com wrote:

 I thought you were going to include the SCM coordinates used to create
 the tarballs?


 Sorry, not intentional. I forgot.

 It's particularly important here, because AFAICT the SCM coordinates
 are not present in the POM.
 If true, then it's not possible to verify the files in the source tarballs.


 I hash is always in the distribution, it's how we show where it comes from 
 when you type mvn -v. It's in the build properties in the core JAR and the 
 hash in there is:

 c9950d777c7368e51431500c29aecf1e11e3d2c6

Not exactly easy to find!

In order to actually find the sources that correspond with the hash,
additional information is needed, which also needs to be in the vote
e-mail.

 Also, AFAIK, the PMC agreed to include hashes of the tarballs in vote 
 e-mails?

According to [1], the vote email should have the following contents:


Source release checksum(s):
[NAME-OF]-source-release.zip sha1: [SHA1SUM] md5: [MD5SUM]


[1] 
http://maven.apache.org/developers/release/maven-project-release-procedure.html#Call_the_vote


 On 8 September 2013 14:07, Jason van Zyl ja...@tesla.io wrote:
 Hi,

 Here is a link to Jira with 6 issues resolved:
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18968

 Staging repo:
 https://repository.apache.org/content/repositories/maven-016/

 The distributable binaries and sources for testing can be found here:
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/

 Specifically the zip, tarball, and source archives can be found here:
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.zip
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-bin.tar.gz
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.zip
 https://repository.apache.org/content/repositories/maven-016/org/apache/maven/apache-maven/3.1.1/apache-maven-3.1.1-src.tar.gz

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

 Thanks,

 The Maven Team








 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -








-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven Model Converter version 2.3

[sebb]

On 16 August 2013 08:10, Dennis Lundberg denn...@apache.org wrote:
 On Fri, Aug 16, 2013 at 1:20 AM, sebb seb...@gmail.com wrote:

 On 15 August 2013 20:57, Dennis Lundberg denn...@apache.org wrote:
  On Thu, Aug 15, 2013 at 9:27 PM, sebb seb...@gmail.com wrote:
 
  On 15 August 2013 14:16, Jason van Zyl ja...@tesla.io wrote:
   What Sebb is doing is perfectly reasonable.
 
 
  I agree. Checking that the source bundle is correct is good release
 review
  practice.
 
  Thank you!
 
   He's trying to assert that everything in the source ball actually
 comes
  from source control and that no errant files have made their way into
 the
  distribution. Right now we cannot assert that the assembly plugin has
 not
  wandered outside the checkout and pulled something else in, or that
 someone
  didn't accidentally put something else in the distribution. I think this
  unlikely but we can't assert otherwise right now which I believe is
 Sebb's
  point.
 
  It *has* already happened several times that I am aware of.
 
  The last few releases of the War plugin (various RMs  voters)
  included at least one spurious file.
  So it was not just a one-off packaging - and review - failure.
  [See separate thread(s) for all the details; they are not germane here.]
 
  The message is that mistakes happen even in automated processes.
  Which is why independent comparison of input and output is valuable.
 
   If we can embed the revision from which the assembly was made in the
  assembly itself (and maybe the build number plugin is doing this
 already),
  then a tool can be made to unpack the assembly, checkout the revision
 and
  assert that everything in the source distribution comes from source
 control.
  
   If we can also assert that as part of each build all the license files
  are intact and headers are in place then I believe we're done with
  provenance.
   Licenses are present, all files have valid license headers, all files
  present in the source distribution come from source control, all
  contributions to source control are from bonafide CLA carrying Apache
  committers because you don't get access to commit until the CLA is on
 file.
  
   Sebb, reasonably accurate?
 
  Yes.
 
  One other point I made already is that I think the vote e-mail needs
  to be transparent to all, not just those on the PMC.
  Links to the output from the release process are obviously already in
  the mail; what is missing is the input to the process, e.g.. SCM
  coords.
  Yes, it may be possible to dig out the details from the archive, but
  that's not trivial.
 
 
  I disagree.
 
  If we focus first on a normal release, one that succeeds on the first
  attempt, without a respin or deleting of tags.
  To check provenance you would do this:
 
  1. download the source bundle
  2. unpack the source bundle
  3. checkout the corresponding source code from the SCM
  4. compare the two trees
 
  Right so far?
 
  What you want, if I understand you correctly, is to have the SCM URL in
 the
  vote email. So that you can give that to your SCM client in step 3.

 Yes.

  With the process we use here at the Maven project, the SCM URL is in the
  pom.xml file that sits in the root directory of the unpacked source
 bundle.
  All you need to do is open the file and copy the URL from there. I still
  fail to see how that is so much harder than to copy the URL from an
 email.
 
  That is if you don't know the conventions that we use, by way of the
  Release Plugin. The tag will always be in the format
  ${project.artifactId}-${project.version}
 

 My point is that it should be completely transparent, even to outside
 reviewers.


 I guess that this is the point that we'll have to agree to disagree on. My
 view is that if someone wants to to review a release from the Maven
 project, they'd have to have a basic understanding of how Maven works and
 how we do releases in the Maven project. That includes what the Release
 Plugin is and how it works.

Why does the release tool matter?
It's still an ASF release.
It should not matter how the source release artifacts are generated.
The process of checking them is still the same.

Of course if things go wrong, then it's important to know how the SCM
input was assembled into the source archives in order to fix the
process.
But the release tool is completely irrelevant to the process of
checking the contents of the source archives.

 Most people have their own checklist of stuff they do when reviewing a
 release. Would it be a good idea if we aggregate all those points on a page
 on the Maven web site, under the development section? That would also serve
 as a guide for outside reviewers.

Yes, though that is a separate issue.


  Now, for a respun release thing are trickier. Here it might be a good
 idea
  to include the revision number or hash, or whatever is unique in the SCM
  being used.

 And how do you know from a vote e-mail that it is respun?


 It should always say so in the subject of the vote email

Re: [VOTE] Release Apache Maven Model Converter version 2.3

[sebb]

On 16 August 2013 09:32, Dennis Lundberg denn...@apache.org wrote:
 On Fri, Aug 16, 2013 at 9:52 AM, sebb seb...@gmail.com wrote:

 On 16 August 2013 08:10, Dennis Lundberg denn...@apache.org wrote:
  On Fri, Aug 16, 2013 at 1:20 AM, sebb seb...@gmail.com wrote:
 
  On 15 August 2013 20:57, Dennis Lundberg denn...@apache.org wrote:
   On Thu, Aug 15, 2013 at 9:27 PM, sebb seb...@gmail.com wrote:
  
   On 15 August 2013 14:16, Jason van Zyl ja...@tesla.io wrote:
What Sebb is doing is perfectly reasonable.
  
  
   I agree. Checking that the source bundle is correct is good release
  review
   practice.
  
   Thank you!
  
He's trying to assert that everything in the source ball actually
  comes
   from source control and that no errant files have made their way into
  the
   distribution. Right now we cannot assert that the assembly plugin has
  not
   wandered outside the checkout and pulled something else in, or that
  someone
   didn't accidentally put something else in the distribution. I think
 this
   unlikely but we can't assert otherwise right now which I believe is
  Sebb's
   point.
  
   It *has* already happened several times that I am aware of.
  
   The last few releases of the War plugin (various RMs  voters)
   included at least one spurious file.
   So it was not just a one-off packaging - and review - failure.
   [See separate thread(s) for all the details; they are not germane
 here.]
  
   The message is that mistakes happen even in automated processes.
   Which is why independent comparison of input and output is valuable.
  
If we can embed the revision from which the assembly was made in
 the
   assembly itself (and maybe the build number plugin is doing this
  already),
   then a tool can be made to unpack the assembly, checkout the revision
  and
   assert that everything in the source distribution comes from source
  control.
   
If we can also assert that as part of each build all the license
 files
   are intact and headers are in place then I believe we're done with
   provenance.
Licenses are present, all files have valid license headers, all
 files
   present in the source distribution come from source control, all
   contributions to source control are from bonafide CLA carrying Apache
   committers because you don't get access to commit until the CLA is on
  file.
   
Sebb, reasonably accurate?
  
   Yes.
  
   One other point I made already is that I think the vote e-mail needs
   to be transparent to all, not just those on the PMC.
   Links to the output from the release process are obviously already in
   the mail; what is missing is the input to the process, e.g.. SCM
   coords.
   Yes, it may be possible to dig out the details from the archive, but
   that's not trivial.
  
  
   I disagree.
  
   If we focus first on a normal release, one that succeeds on the
 first
   attempt, without a respin or deleting of tags.
   To check provenance you would do this:
  
   1. download the source bundle
   2. unpack the source bundle
   3. checkout the corresponding source code from the SCM
   4. compare the two trees
  
   Right so far?
  
   What you want, if I understand you correctly, is to have the SCM URL
 in
  the
   vote email. So that you can give that to your SCM client in step 3.
 
  Yes.
 
   With the process we use here at the Maven project, the SCM URL is in
 the
   pom.xml file that sits in the root directory of the unpacked source
  bundle.
   All you need to do is open the file and copy the URL from there. I
 still
   fail to see how that is so much harder than to copy the URL from an
  email.
  
   That is if you don't know the conventions that we use, by way of the
   Release Plugin. The tag will always be in the format
   ${project.artifactId}-${project.version}
  
 
  My point is that it should be completely transparent, even to outside
  reviewers.
 
 
  I guess that this is the point that we'll have to agree to disagree on.
 My
  view is that if someone wants to to review a release from the Maven
  project, they'd have to have a basic understanding of how Maven works and
  how we do releases in the Maven project. That includes what the Release
  Plugin is and how it works.

 Why does the release tool matter?


 It is not the tool itself that matters, but rather what the tools does.
 Since the Release plugin automates a lot of the tasks involved when doing a
 release, it can appear to make things less transparent. Therefor a
 knowledge about what it does is needed to make it transparent.

That really is not the point.

It's possible to create the same outputs from the same inputs using
all sorts of methods, manual or automated.

The fact that it is a Maven release should not matter as far as the
source checking is concerned, except insofar as the staging area may
be different.

Only the source release archives matter.

 It's still an ASF release.


 Yes, and we must adhere to all the requirements of an ASF release. There
 are however

Re: [VOTE] Release Apache Maven Model Converter version 2.3

[sebb]

On 16 August 2013 13:08, Fred Cooke fred.co...@gmail.com wrote:
 They're deployed as a set, so what I want is the SHA1 or even MD5 of any
 one of the set of uploaded files, such that I can confirm that the set is
 the set that I am supposed to be looking at. I don't see importance in
 which, but I've not thought about it much. I think *all* would be huge
 overkill.

It's only really needed for source archives, which are the ones being
officially voted on.

This is something I've long thought is necessary to be able to tie the
vote mail to the artifacts.

And it could be very useful to have the hash in the mail archive.

 On Sat, Aug 17, 2013 at 12:00 AM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 That sounds like you are looking for the SHA1 sum of the source bundle to
 be included in the vote email. Which would seem perfectly reasonable to me.

Yes please!





 On 16 August 2013 12:31, Fred Cooke fred.co...@gmail.com wrote:

  Dennis, of course source bundles will contain URLs and hashes and
 revisions
  and so forth, and the chance of those being mismatched is approximately
  zero. That's not the point.
 
  The point (for me, at least) is what did you INTEND to release, and does
  THAT match what is actually found in the bundle (including URLs and
 hashes
  etc matching).
 
  Releasing is a fundamentally human process that consists of is this
  ready? and pull trigger. Some binaries and bundles end up on server of
  some type somewhere. I want to know the checksum of one of the set of
 items
  (so I KNOW (not guess) that I'm looking at what you want me to), and I
 want
  to know what SCM or tarball+patchset you think you released it from. This
  is human information that can't be automated. The bundle someone goes and
  finds could have anything in it, and they won't know if it's what you
  wanted it to have in it, or not.
 
  Fred.
 
  On Fri, Aug 16, 2013 at 11:25 PM, Dennis Lundberg denn...@apache.org
  wrote:
 
   On Fri, Aug 16, 2013 at 11:24 AM, sebb seb...@gmail.com wrote:
  
On 16 August 2013 09:32, Dennis Lundberg denn...@apache.org wrote:
 On Fri, Aug 16, 2013 at 9:52 AM, sebb seb...@gmail.com wrote:

 On 16 August 2013 08:10, Dennis Lundberg denn...@apache.org
  wrote:
  On Fri, Aug 16, 2013 at 1:20 AM, sebb seb...@gmail.com wrote:
 
  On 15 August 2013 20:57, Dennis Lundberg denn...@apache.org
   wrote:
   On Thu, Aug 15, 2013 at 9:27 PM, sebb seb...@gmail.com
  wrote:
  
   On 15 August 2013 14:16, Jason van Zyl ja...@tesla.io
  wrote:
What Sebb is doing is perfectly reasonable.
  
  
   I agree. Checking that the source bundle is correct is good
   release
  review
   practice.
  
   Thank you!
  
He's trying to assert that everything in the source ball
actually
  comes
   from source control and that no errant files have made their
  way
into
  the
   distribution. Right now we cannot assert that the assembly
   plugin
has
  not
   wandered outside the checkout and pulled something else in,
 or
that
  someone
   didn't accidentally put something else in the distribution.
 I
think
 this
   unlikely but we can't assert otherwise right now which I
  believe
is
  Sebb's
   point.
  
   It *has* already happened several times that I am aware of.
  
   The last few releases of the War plugin (various RMs 
 voters)
   included at least one spurious file.
   So it was not just a one-off packaging - and review -
 failure.
   [See separate thread(s) for all the details; they are not
   germane
 here.]
  
   The message is that mistakes happen even in automated
  processes.
   Which is why independent comparison of input and output is
valuable.
  
If we can embed the revision from which the assembly was
  made
   in
 the
   assembly itself (and maybe the build number plugin is doing
  this
  already),
   then a tool can be made to unpack the assembly, checkout the
revision
  and
   assert that everything in the source distribution comes from
source
  control.
   
If we can also assert that as part of each build all the
   license
 files
   are intact and headers are in place then I believe we're
 done
   with
   provenance.
Licenses are present, all files have valid license
 headers,
   all
 files
   present in the source distribution come from source control,
  all
   contributions to source control are from bonafide CLA
 carrying
Apache
   committers because you don't get access to commit until the
  CLA
is on
  file.
   
Sebb, reasonably accurate?
  
   Yes.
  
   One other point I made already is that I think the vote
 e-mail
needs
   to be transparent to all, not just those on the PMC.
   Links to the output from the release

Re: [VOTE] Release Apache Maven Model Converter version 2.3

[sebb]

On 16 August 2013 13:44, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 r1514680

 Does that, coupled with the knowledge that our source release bundles are
 *supposed to* include the tag details that they were built from resolve
 your issue?

Sorry, but no.

As I see it, release votes should be independent of the tooling and
project layout etc.

What's important is that the source release can be demonstrated to be
derived entirely from approved sources.

So any ASF vote email should contain:

+ Pointer to the approved original source files, i.e. unique SCM coordinates

+ Pointer to the release candidate source archive(s), plus hash(es) to
make the instance unique and traceable

+ Pointer to the KEYS file so sigs can be checked.

+ Pointers to binary (and javadoc) archives, if any.
These are not part of a formal ASF release, but if they are provided
then their NL files must be present and correct.

Reviewers should not be required to understand the release tooling or
even how to build or test the application.
These are not necessary for the the parts of the review which only
look at provenance and licensing.

Of course the PMC does have an interest in additional aspects of the
release, such as documentation, does it build and test OK.
For those parts of the review of course more detailed knowledge of the
project is needed.

For the requirements of ASF releases, a reviewer only needs to know how to:
- obtain the approved source files
- inspect the release candidate archives so the contents can be
checked and compared as necessary.
- check sigs and hashes

 (Obviously there is more tooling we can add... for instance I suspect that
 for GIT we are not including the git hash that release:perform is running
 from... which is something I think we can address)


 On 16 August 2013 13:17, sebb seb...@gmail.com wrote:

 On 16 August 2013 13:08, Fred Cooke fred.co...@gmail.com wrote:
  They're deployed as a set, so what I want is the SHA1 or even MD5 of any
  one of the set of uploaded files, such that I can confirm that the set is
  the set that I am supposed to be looking at. I don't see importance in
  which, but I've not thought about it much. I think *all* would be huge
  overkill.

 It's only really needed for source archives, which are the ones being
 officially voted on.

 This is something I've long thought is necessary to be able to tie the
 vote mail to the artifacts.

 And it could be very useful to have the hash in the mail archive.

  On Sat, Aug 17, 2013 at 12:00 AM, Stephen Connolly 
  stephen.alan.conno...@gmail.com wrote:
 
  That sounds like you are looking for the SHA1 sum of the source bundle
 to
  be included in the vote email. Which would seem perfectly reasonable to
 me.

 Yes please!

 
 
 
 
  On 16 August 2013 12:31, Fred Cooke fred.co...@gmail.com wrote:
 
   Dennis, of course source bundles will contain URLs and hashes and
  revisions
   and so forth, and the chance of those being mismatched is
 approximately
   zero. That's not the point.
  
   The point (for me, at least) is what did you INTEND to release, and
 does
   THAT match what is actually found in the bundle (including URLs and
  hashes
   etc matching).
  
   Releasing is a fundamentally human process that consists of is this
   ready? and pull trigger. Some binaries and bundles end up on
 server of
   some type somewhere. I want to know the checksum of one of the set of
  items
   (so I KNOW (not guess) that I'm looking at what you want me to), and I
  want
   to know what SCM or tarball+patchset you think you released it from.
 This
   is human information that can't be automated. The bundle someone goes
 and
   finds could have anything in it, and they won't know if it's what you
   wanted it to have in it, or not.
  
   Fred.
  
   On Fri, Aug 16, 2013 at 11:25 PM, Dennis Lundberg denn...@apache.org
   wrote:
  
On Fri, Aug 16, 2013 at 11:24 AM, sebb seb...@gmail.com wrote:
   
 On 16 August 2013 09:32, Dennis Lundberg denn...@apache.org
 wrote:
  On Fri, Aug 16, 2013 at 9:52 AM, sebb seb...@gmail.com wrote:
 
  On 16 August 2013 08:10, Dennis Lundberg denn...@apache.org
   wrote:
   On Fri, Aug 16, 2013 at 1:20 AM, sebb seb...@gmail.com
 wrote:
  
   On 15 August 2013 20:57, Dennis Lundberg 
 denn...@apache.org
wrote:
On Thu, Aug 15, 2013 at 9:27 PM, sebb seb...@gmail.com
   wrote:
   
On 15 August 2013 14:16, Jason van Zyl ja...@tesla.io
   wrote:
 What Sebb is doing is perfectly reasonable.
   
   
I agree. Checking that the source bundle is correct is
 good
release
   review
practice.
   
Thank you!
   
 He's trying to assert that everything in the source
 ball
 actually
   comes
from source control and that no errant files have made
 their
   way
 into
   the
distribution. Right now we cannot assert that the
 assembly
plugin
 has

Re: [VOTE] Release Apache Maven Model Converter version 2.3

[sebb]

On 15 August 2013 10:08, Chris Graham chrisgw...@gmail.com wrote:
 What sebb does not appear to have understood or accepted, as Stephen has
 endlessly pointed out, is that we vote on the source bundle, not a scm
 revision, and that, strictly speaking a SCM is not even required (however
 sensible it is to use one).

 He wants a tree and a revision so that we can compare between releases,
 where what he should be doing, strictly speaking, is comparing source tar
 balls, as that is what we really are voting on.

I agree that what is released (and voted on) are the source tarballs.
And any such tarballs should be identical (barring possibly different
EOL settings for text files).

However, that is only one of the checks that need to be made.

The PMC also needs to ensure that the files are being released under
the correct license.

I contend that the only practical way to check the licences is to
compare the source tarball(s) with the files in SCM.

[The files should only be added to SCM if the license is OK, so the
SCM tag acts as a database of validated source files.]

The SVN revision / Git hash are needed to ensure uniqueness.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven Model Converter version 2.3

[sebb]

On 15 August 2013 14:16, Jason van Zyl ja...@tesla.io wrote:
 What Sebb is doing is perfectly reasonable.

Thank you!

 He's trying to assert that everything in the source ball actually comes from 
 source control and that no errant files have made their way into the 
 distribution. Right now we cannot assert that the assembly plugin has not 
 wandered outside the checkout and pulled something else in, or that someone 
 didn't accidentally put something else in the distribution. I think this 
 unlikely but we can't assert otherwise right now which I believe is Sebb's 
 point.

It *has* already happened several times that I am aware of.

The last few releases of the War plugin (various RMs  voters)
included at least one spurious file.
So it was not just a one-off packaging - and review - failure.
[See separate thread(s) for all the details; they are not germane here.]

The message is that mistakes happen even in automated processes.
Which is why independent comparison of input and output is valuable.

 If we can embed the revision from which the assembly was made in the assembly 
 itself (and maybe the build number plugin is doing this already), then a tool 
 can be made to unpack the assembly, checkout the revision and assert that 
 everything in the source distribution comes from source control.

 If we can also assert that as part of each build all the license files are 
 intact and headers are in place then I believe we're done with provenance.
 Licenses are present, all files have valid license headers, all files present 
 in the source distribution come from source control, all contributions to 
 source control are from bonafide CLA carrying Apache committers because you 
 don't get access to commit until the CLA is on file.

 Sebb, reasonably accurate?

Yes.

One other point I made already is that I think the vote e-mail needs
to be transparent to all, not just those on the PMC.
Links to the output from the release process are obviously already in
the mail; what is missing is the input to the process, e.g.. SCM
coords.
Yes, it may be possible to dig out the details from the archive, but
that's not trivial.
Publishing the SCM coordinates in the mail is trivial to do, and shows
that the input is an important part of the review process.
Having the information in the mail thread is also useful for the archives.

 On Aug 15, 2013, at 9:01 AM, Chris Graham chrisgw...@gmail.com wrote:



 Sent from my iPhone

 On 15/08/2013, at 10:05 PM, sebb seb...@gmail.com wrote:

 On 15 August 2013 10:08, Chris Graham chrisgw...@gmail.com wrote:
 What sebb does not appear to have understood or accepted, as Stephen has
 endlessly pointed out, is that we vote on the source bundle, not a scm
 revision, and that, strictly speaking a SCM is not even required (however
 sensible it is to use one).

 He wants a tree and a revision so that we can compare between releases,
 where what he should be doing, strictly speaking, is comparing source tar
 balls, as that is what we really are voting on.

 I agree that what is released (and voted on) are the source tarballs.
 And any such tarballs should be identical (barring possibly different
 EOL settings for text files).

 However, that is only one of the checks that need to be made.

 The PMC also needs to ensure that the files are being released under
 the correct license.

 Are not the licenses in the source that is in the source tarball?

 If so, can not the rat plugin or similar be used to check the compliance?

 I contend that the only practical way to check the licences is to
 compare the source tarball(s) with the files in SCM.

 [The files should only be added to SCM if the license is OK, so the
 SCM tag acts as a database of validated source files.]

 The SVN revision / Git hash are needed to ensure uniqueness.

 -
 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


 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -

 There's no sense in being precise when you don't even know what you're 
 talking about.

  -- John von Neumann







-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven Model Converter version 2.3

[sebb]

On 15 August 2013 20:57, Dennis Lundberg denn...@apache.org wrote:
 On Thu, Aug 15, 2013 at 9:27 PM, sebb seb...@gmail.com wrote:

 On 15 August 2013 14:16, Jason van Zyl ja...@tesla.io wrote:
  What Sebb is doing is perfectly reasonable.


 I agree. Checking that the source bundle is correct is good release review
 practice.

 Thank you!

  He's trying to assert that everything in the source ball actually comes
 from source control and that no errant files have made their way into the
 distribution. Right now we cannot assert that the assembly plugin has not
 wandered outside the checkout and pulled something else in, or that someone
 didn't accidentally put something else in the distribution. I think this
 unlikely but we can't assert otherwise right now which I believe is Sebb's
 point.

 It *has* already happened several times that I am aware of.

 The last few releases of the War plugin (various RMs  voters)
 included at least one spurious file.
 So it was not just a one-off packaging - and review - failure.
 [See separate thread(s) for all the details; they are not germane here.]

 The message is that mistakes happen even in automated processes.
 Which is why independent comparison of input and output is valuable.

  If we can embed the revision from which the assembly was made in the
 assembly itself (and maybe the build number plugin is doing this already),
 then a tool can be made to unpack the assembly, checkout the revision and
 assert that everything in the source distribution comes from source control.
 
  If we can also assert that as part of each build all the license files
 are intact and headers are in place then I believe we're done with
 provenance.
  Licenses are present, all files have valid license headers, all files
 present in the source distribution come from source control, all
 contributions to source control are from bonafide CLA carrying Apache
 committers because you don't get access to commit until the CLA is on file.
 
  Sebb, reasonably accurate?

 Yes.

 One other point I made already is that I think the vote e-mail needs
 to be transparent to all, not just those on the PMC.
 Links to the output from the release process are obviously already in
 the mail; what is missing is the input to the process, e.g.. SCM
 coords.
 Yes, it may be possible to dig out the details from the archive, but
 that's not trivial.


 I disagree.

 If we focus first on a normal release, one that succeeds on the first
 attempt, without a respin or deleting of tags.
 To check provenance you would do this:

 1. download the source bundle
 2. unpack the source bundle
 3. checkout the corresponding source code from the SCM
 4. compare the two trees

 Right so far?

 What you want, if I understand you correctly, is to have the SCM URL in the
 vote email. So that you can give that to your SCM client in step 3.

Yes.

 With the process we use here at the Maven project, the SCM URL is in the
 pom.xml file that sits in the root directory of the unpacked source bundle.
 All you need to do is open the file and copy the URL from there. I still
 fail to see how that is so much harder than to copy the URL from an email.

 That is if you don't know the conventions that we use, by way of the
 Release Plugin. The tag will always be in the format
 ${project.artifactId}-${project.version}


My point is that it should be completely transparent, even to outside reviewers.

 Now, for a respun release thing are trickier. Here it might be a good idea
 to include the revision number or hash, or whatever is unique in the SCM
 being used.

And how do you know from a vote e-mail that it is respun?

 Even though the code under review will always be under the
 latest tag in the above format (at least for Subversion).

Until the next respin.

If there is a respin, and reviewers are not following the e-mails very
carefully, it would be quite easy to overlook an updated tag.

This is all about making sure that it is really obvious what the vote is about.


 Publishing the SCM coordinates in the mail is trivial to do, and shows
 that the input is an important part of the review process.
 Having the information in the mail thread is also useful for the archives.


 As others have said before, we aim to automate the release process as much
 as possible. Therefor even a seemingly minor addition will be questioned,
 as you have noticed, before it is included in our process.

 Can you explain why the information is useful for the archives? I've seen
 you mentioned that before. Isn't that moot once the release is approved?
 The tag will be in Subversion for the forseable future and noone will touch
 it. What am I missing?

Why would a release need to be revisited?
Perhaps someone is complaining that one of our releases contains code
it should not.
If that is the case, it helps to have the evidence of the release vote
in plain sight.



  On Aug 15, 2013, at 9:01 AM, Chris Graham chrisgw...@gmail.com wrote:
 
 
 
  Sent from my iPhone

Re: svn commit: r1512672 - /maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/AbstractGpgSigner.java

[sebb]

On 13 August 2013 18:53, Dennis Lundberg denn...@apache.org wrote:
 Hi

 Yeah, that was my @home new file template that kicked in.
 I've removed the @version tags now.

@version is OK; just don't use $Date$.

However just noticed that the code uses @author.

The @author tag is deprecated in ASF code [1]. Briefly:
- ASF is about community, not individuals
- too difficult to maintain accurately

Credit should be given elsewhere, e.g. in pom developer or contributor sections.

[1] 
http://www.apache.org/foundation/records/minutes/2004/board_minutes_2004_09_22.txt
section 7 F

 On Tue, Aug 13, 2013 at 12:48 PM, sebb seb...@gmail.com wrote:
 On 10 August 2013 13:27,  denn...@apache.org wrote:
 Author: dennisl
 Date: Sat Aug 10 12:27:41 2013
 New Revision: 1512672

 URL: http://svn.apache.org/r1512672
 Log:
 Add subversion keywords.

 Modified:
 
 maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/AbstractGpgSigner.java
(contents, props changed)

 Modified: 
 maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/AbstractGpgSigner.java
 URL: 
 http://svn.apache.org/viewvc/maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/AbstractGpgSigner.java?rev=1512672r1=1512671r2=1512672view=diff
 ==
 --- 
 maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/AbstractGpgSigner.java
  (original)
 +++ 
 maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/AbstractGpgSigner.java
  Sat Aug 10 12:27:41 2013
 @@ -31,7 +31,7 @@ import org.apache.maven.project.MavenPro
   * A base class for all classes that implements signing of files.
   *
   * @author Dennis Lundberg
 - * @version $Revision: 1.1 $ $Date: 2004/07/28 09:48:35 2013-08-10 14:10 $
 + * @version $Revision$ $Date$

 Date causes problems.
 The value and format depends on the user's locale, so source archives
 will vary depending on where they were created.

 If you really need a timestamp (why?), use $Id$ instead.

   * @since 1.5
   */
  public abstract class AbstractGpgSigner

 Propchange: 
 maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/AbstractGpgSigner.java
 --
 svn:keywords = Date Revision Author Id



 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




 --
 Dennis Lundberg

 -
 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] Release Apache Maven Model Converter version 2.3

[sebb]

On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote:
 On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote:
 On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote:


 I have now read the threads that are referring to, and have not found
 a single link to any ASF rule stating that we need to include these
 things in a VOTE thread.

 So how do you propose that reviewers check the provenance of the files
 in the source release?

 Are you looking for files that are in a distribution that didn't come from 
 source control? Everything else as far as provenance goes is covered. 
 Errant content is a potential problem, but everything in a distribution 
 should come from source control which no one has access to until they have 
 a signed CLA on file.

 Yes. That is where the whole saga started.

 Proving provenance is why the SCM coordinates are needed for the vote.

 The SCM details may also be useful to discover files accidentally
 omitted from the source archive.

 You want to compare the contents of the *-source-release.zip with
 something from SCM, to make nothing bad has crept into the source
 bundle. So you need to know where in SCM you can find it. Have I
 understood you correctly?

It's vital to be able to link the files in the source release
archive(s) to their origin in SCM.

The provenance of any source files the ASF releases must be clearly traceable.

 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -








 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




 --
 Dennis Lundberg

 -
 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] Release Apache Maven Model Converter version 2.3

[sebb]

On 14 August 2013 10:23, Stephen Connolly steph...@apache.org wrote:
 On 14 August 2013 09:47, sebb seb...@gmail.com wrote:

 On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote:
  On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote:
  On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote:
 
 
  I have now read the threads that are referring to, and have not found
  a single link to any ASF rule stating that we need to include these
  things in a VOTE thread.
 
  So how do you propose that reviewers check the provenance of the files
  in the source release?
 
  Are you looking for files that are in a distribution that didn't come
 from source control? Everything else as far as provenance goes is covered.
 Errant content is a potential problem, but everything in a distribution
 should come from source control which no one has access to until they have
 a signed CLA on file.
 
  Yes. That is where the whole saga started.
 
  Proving provenance is why the SCM coordinates are needed for the vote.
 
  The SCM details may also be useful to discover files accidentally
  omitted from the source archive.
 
  You want to compare the contents of the *-source-release.zip with
  something from SCM, to make nothing bad has crept into the source
  bundle. So you need to know where in SCM you can find it. Have I
  understood you correctly?

 It's vital to be able to link the files in the source release
 archive(s) to their origin in SCM.


 Simply not true. It is a nice convenience for somebody tracing the
 provenance of files in a source release, but it is by no means vital.


What other means do you suggest then?



 The provenance of any source files the ASF releases must be clearly
 traceable.


 Being able to link the files in the source release archive(s) to their
 origin in SCM is certainly one way to make the provenance of source files
 the ASF releases easily traceable, but there is *no* foundation requirement
 for such.

Is there any other way to check provenance?

 As I understand it, we *could*, as a project, decide to abandon SCM
 entirely for some specific module - something I would be strongly against -
 and we would be within our rights to do so.

 All that the foundation requires is that the PMC have verified the
 provenance of the files in the source releases they vote on.

Which is not currently possible with the information provided in the
vote e-mail.

 If you feel that individual members of the PMC are voting without having
 taken their required due diligence into account then I suggest you take
 that up with those individual members.

I just want to make sure that the reviewers have the information they
need to be able to do the due diligence.
At present that is not possible from the information provided in the
vote e-mails.

 -Stephen



  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  -
 
 
 
 
 
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 
 
  --
  Dennis Lundberg
 
  -
  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



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven Model Converter version 2.3

[sebb]

On 14 August 2013 11:13, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 On 14 August 2013 10:45, sebb seb...@gmail.com wrote:

 On 14 August 2013 10:23, Stephen Connolly steph...@apache.org wrote:
  On 14 August 2013 09:47, sebb seb...@gmail.com wrote:
 
  On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote:
   On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote:
   On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote:
  
  
   I have now read the threads that are referring to, and have not
 found
   a single link to any ASF rule stating that we need to include
 these
   things in a VOTE thread.
  
   So how do you propose that reviewers check the provenance of the
 files
   in the source release?
  
   Are you looking for files that are in a distribution that didn't
 come
  from source control? Everything else as far as provenance goes is
 covered.
  Errant content is a potential problem, but everything in a distribution
  should come from source control which no one has access to until they
 have
  a signed CLA on file.
  
   Yes. That is where the whole saga started.
  
   Proving provenance is why the SCM coordinates are needed for the
 vote.
  
   The SCM details may also be useful to discover files accidentally
   omitted from the source archive.
  
   You want to compare the contents of the *-source-release.zip with
   something from SCM, to make nothing bad has crept into the source
   bundle. So you need to know where in SCM you can find it. Have I
   understood you correctly?
 
  It's vital to be able to link the files in the source release
  archive(s) to their origin in SCM.
 
 
  Simply not true. It is a nice convenience for somebody tracing the
  provenance of files in a source release, but it is by no means vital.
 

 What other means do you suggest then?


 That is not *your problem*. That is the *reviewers* problem. If the PMC
 reviewers decide that determining the provenance of files (which is a
 necessary part of their review) is too difficult because they are missing
 information that would assist them, then *they* will drive adding that
 information.

As a member of the ASF, I do think it's my problem if software is
being released in the name of the ASF.

The ASF is about transparency - if it did not happen on a public
mailing list then it did not happen.

It should be possible for anyone to review a release and provide
feedback to the PMC.

At present the process is not transparent.


 
 
  The provenance of any source files the ASF releases must be clearly
  traceable.
 
 
  Being able to link the files in the source release archive(s) to their
  origin in SCM is certainly one way to make the provenance of source files
  the ASF releases easily traceable, but there is *no* foundation
 requirement
  for such.

 Is there any other way to check provenance?


 It is up to each individual PMC to put in place the procedure by which they
 check the provenance of the files they release, thus if a PMC decides to
 forgo SCM and return to the original HTTPD model of just releasing tarballs
 then the Foundation will require that they determine a method through which
 they can establish the provenance of the files they are releasing.



  As I understand it, we *could*, as a project, decide to abandon SCM
  entirely for some specific module - something I would be strongly
 against -
  and we would be within our rights to do so.
 
  All that the foundation requires is that the PMC have verified the
  provenance of the files in the source releases they vote on.

 Which is not currently possible with the information provided in the
 vote e-mail.


 The PMC members do not see a problem.



  If you feel that individual members of the PMC are voting without having
  taken their required due diligence into account then I suggest you take
  that up with those individual members.

 I just want to make sure that the reviewers have the information they
 need to be able to do the due diligence.
 At present that is not possible from the information provided in the
 vote e-mails.


 Again, the PMC are the reviewers that are required to perform their due
 diligence and do not see an issue with the email content.

 We see that we have all the information we require, we also do not want to
 add extra information than is required by us.

 -Stephen



  -Stephen
 
 
 
   Thanks,
  
   Jason
  
   --
   Jason van Zyl
   Founder,  Apache Maven
   http://twitter.com/jvanzyl
   -
  
  
  
  
  
  
  
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
   For additional commands, e-mail: dev-h...@maven.apache.org
  
  
  
  
   --
   Dennis Lundberg
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

Re: [VOTE] Release Maven Remote Resources Plugin 1.5

[sebb]

On 14 August 2013 13:45, Jason van Zyl ja...@tesla.io wrote:
 Hi,

 We solved 5 issues:
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11391version=18924

 Staging repo:
 https://repository.apache.org/content/repositories/maven-093/

 Subversion Revision: r1508060

Thanks.

However the SVN revision is not sufficient to identify the source,
especially since the ASF uses multiple shared SVN repos. An
appropriate base directory is also needed to identify which part of
the tree was used.

Since the tag is what is used in the POM scm entry, please specify
the SVN tag name along with its revision.

 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

 (NOTE: the cms wasn't responding this morning for publishing so if someone 
 else wants to publish the site go for it. If it's required)






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven Remote Resources Plugin 1.5

[sebb]

On 14 August 2013 14:08, Jason van Zyl ja...@tesla.io wrote:
 Here you go: 
 https://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-resources-plugin-1.5/

Thanks again, however that was last updated:

Last Changed Author: jvanzyl
Last Changed Rev: 1513840
Last Changed Date: 2013-08-14 13:25:11 +0100 (Wed, 14 Aug 2013)

which unfortunately does not agree with the originally stated revision:

 Subversion Revision: r1508060

 I'll put it in the template for next time.

Thanks, that would save a lot of hassle for everyone.

 On Aug 14, 2013, at 9:00 AM, sebb seb...@gmail.com wrote:

 On 14 August 2013 13:45, Jason van Zyl ja...@tesla.io wrote:
 Hi,

 We solved 5 issues:
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11391version=18924

 Staging repo:
 https://repository.apache.org/content/repositories/maven-093/

 Subversion Revision: r1508060

 Thanks.

 However the SVN revision is not sufficient to identify the source,
 especially since the ASF uses multiple shared SVN repos. An
 appropriate base directory is also needed to identify which part of
 the tree was used.

 Since the tag is what is used in the POM scm entry, please specify
 the SVN tag name along with its revision.

 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

 (NOTE: the cms wasn't responding this morning for publishing so if someone 
 else wants to publish the site go for it. If it's required)






 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -








-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Maven Remote Resources Plugin 1.5

[sebb]

On 14 August 2013 14:18, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 On 14 August 2013 14:14, sebb seb...@gmail.com wrote:

 On 14 August 2013 14:08, Jason van Zyl ja...@tesla.io wrote:
  Here you go:
 https://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-resources-plugin-1.5/

 Thanks again, however that was last updated:

 Last Changed Author: jvanzyl
 Last Changed Rev: 1513840
 Last Changed Date: 2013-08-14 13:25:11 +0100 (Wed, 14 Aug 2013)

 which unfortunately does not agree with the originally stated revision:


 However
 https://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-resources-plugin-1.5/
 @1508060

 is a perfectly valid immutable coordinate for the source code upon which
 this was created...


That may be so, but it's not obvious without comparing the trees, as
there were several changes to files between the revisions.


  Subversion Revision: r1508060

  I'll put it in the template for next time.

 Thanks, that would save a lot of hassle for everyone.

  On Aug 14, 2013, at 9:00 AM, sebb seb...@gmail.com wrote:
 
  On 14 August 2013 13:45, Jason van Zyl ja...@tesla.io wrote:
  Hi,
 
  We solved 5 issues:
 
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11391version=18924
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-093/
 
  Subversion Revision: r1508060
 
  Thanks.
 
  However the SVN revision is not sufficient to identify the source,
  especially since the ASF uses multiple shared SVN repos. An
  appropriate base directory is also needed to identify which part of
  the tree was used.
 
  Since the tag is what is used in the POM scm entry, please specify
  the SVN tag name along with its revision.
 
  Guide to testing staged releases:
  http://maven.apache.org/guides/development/guide-testing-releases.html
 
  Vote open for 72 hours.
 
  [ ] +1
  [ ] +0
  [ ] -1
 
  (NOTE: the cms wasn't responding this morning for publishing so if
 someone else wants to publish the site go for it. If it's required)
 
 
 
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  -
 
 
 
 
 
 
 

 -
 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] Release Apache Maven Model Converter version 2.3

[sebb]

On 14 August 2013 21:21, Dennis Lundberg denn...@apache.org wrote:
 On Wed, Aug 14, 2013 at 10:47 AM, sebb seb...@gmail.com wrote:

 On 13 August 2013 18:58, Dennis Lundberg denn...@apache.org wrote:
  On Tue, Aug 13, 2013 at 12:30 AM, sebb seb...@gmail.com wrote:
  On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote:
 
 
  I have now read the threads that are referring to, and have not found
  a single link to any ASF rule stating that we need to include these
  things in a VOTE thread.
 
  So how do you propose that reviewers check the provenance of the files
  in the source release?
 
  Are you looking for files that are in a distribution that didn't come
 from source control? Everything else as far as provenance goes is covered.
 Errant content is a potential problem, but everything in a distribution
 should come from source control which no one has access to until they have
 a signed CLA on file.
 
  Yes. That is where the whole saga started.
 
  Proving provenance is why the SCM coordinates are needed for the vote.
 
  The SCM details may also be useful to discover files accidentally
  omitted from the source archive.
 
  You want to compare the contents of the *-source-release.zip with
  something from SCM, to make nothing bad has crept into the source
  bundle. So you need to know where in SCM you can find it. Have I
  understood you correctly?

 It's vital to be able to link the files in the source release
 archive(s) to their origin in SCM.

 The provenance of any source files the ASF releases must be clearly
 traceable.


 This information is clearly traceable and available to anyone who wants to
 review a release made by the Maven project. Our process uses the Release
 Plugin, which will put the POM from the SCM tag in the staging directory
 along with the source-release.zip. In that POM wou will find the URL to the
 original sources in SCM.


As has already been pointed out, SVN tags are not immutable, so the
tag name alone is not sufficient.



  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  -
 
 
 
 
 
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 
 
  --
  Dennis Lundberg
 
  -
  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

 --
 Dennis Lundberg 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: svn commit: r1512672 - /maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/AbstractGpgSigner.java

[sebb]

On 10 August 2013 13:27,  denn...@apache.org wrote:
 Author: dennisl
 Date: Sat Aug 10 12:27:41 2013
 New Revision: 1512672

 URL: http://svn.apache.org/r1512672
 Log:
 Add subversion keywords.

 Modified:
 
 maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/AbstractGpgSigner.java
(contents, props changed)

 Modified: 
 maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/AbstractGpgSigner.java
 URL: 
 http://svn.apache.org/viewvc/maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/AbstractGpgSigner.java?rev=1512672r1=1512671r2=1512672view=diff
 ==
 --- 
 maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/AbstractGpgSigner.java
  (original)
 +++ 
 maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/AbstractGpgSigner.java
  Sat Aug 10 12:27:41 2013
 @@ -31,7 +31,7 @@ import org.apache.maven.project.MavenPro
   * A base class for all classes that implements signing of files.
   *
   * @author Dennis Lundberg
 - * @version $Revision: 1.1 $ $Date: 2004/07/28 09:48:35 2013-08-10 14:10 $
 + * @version $Revision$ $Date$

Date causes problems.
The value and format depends on the user's locale, so source archives
will vary depending on where they were created.

If you really need a timestamp (why?), use $Id$ instead.

   * @since 1.5
   */
  public abstract class AbstractGpgSigner

 Propchange: 
 maven/plugins/trunk/maven-gpg-plugin/src/main/java/org/apache/maven/plugin/gpg/AbstractGpgSigner.java
 --
 svn:keywords = Date Revision Author Id



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven Model Converter version 2.3

[sebb]

On 11 August 2013 15:02, Dennis Lundberg denn...@apache.org wrote:
 On Thu, Jul 25, 2013 at 8:03 PM, Dennis Lundberg
 dennisl.apa...@gmail.com wrote:
 On Thu, Jul 25, 2013 at 7:15 PM, sebb seb...@gmail.com wrote:
 On 25 July 2013 17:50, Dennis Lundberg denn...@apache.org wrote:
 On Thu, Jul 25, 2013 at 6:34 PM, sebb seb...@gmail.com wrote:
 On 25 July 2013 16:55, Dennis Lundberg denn...@apache.org wrote:
 Den 25 jul 2013 16:08 skrev sebb seb...@gmail.com:

 On 23 July 2013 20:45, Dennis Lundberg denn...@apache.org wrote:
  Hi,
 
  This will be the final release of this shared component. After this
  release it will retire from the Apache Maven project and move to the
  Apache Archiva project. See separate vote thread about that.
 
  We solved 6 issues:
 
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=14389
 
  There are no issues left in JIRA (except for the one to retire, which
  I'll close later):
 
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11761component=13272status=1
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-010/
 
 https://repository.apache.org/content/repositories/maven-010/org/apache/maven/shared/maven-model-converter/2.3/maven-model-converter-2.3-source-release.zip
 
  Staging site (not synced yet):
  http://maven.apache.org/shared-archives/maven-model-converter-2.3/
 
  Guide to testing staged releases:
  http://maven.apache.org/guides/development/guide-testing-releases.html

 What are the unique SCM coordinates?

 The SCM URL can be found in the pom file at the staging repo.

 As already mentioned in another thread, the staging repo URL is
 temporary (and in fact can be reused for something completely
 different).

 Nor does it uniquely identify the code in SCM, as the revision is missing.

 So it is not suitable for documenting the SCM coordinates.

 In the normal case, where a release is approved on the first round,
 there is only ever one tag in SVN and it will not be changed. In these
 cases I do not see the value of including the revision number at all.

 If a release fails on the first attempt, we reuse the tag. This means
 that the tag will exist at multiple revisions. If you are an
 archealogist and find out the revision number of an ancient vote, you
 can look at the date/time of the vote mail and compare that to the
 revision dates in SVN. Still I do not see the value of this. The last
 tag standing is the one that got approved.

 Provided that the tag is not accidentally or deliberately changed 
 subsequently.

 It is not. That is how we work. The only time we ever manually touch a
 tag is when we respin a release.

 Is there an ASF requirement to include the SCM revision number in a
 release vote? I can't find one.

 This was all discussed at great length already; please see my other
 postings on the subject.

 I'm sorry, but I'm drowning in email at the moment, and have not read
 up on all threads.
 A simple yes or no answer will suffice for the moment.

 I have now read the threads that are referring to, and have not found
 a single link to any ASF rule stating that we need to include these
 things in a VOTE thread.

So how do you propose that reviewers check the provenance of the files
in the source release?


 --
 Dennis Lundberg


  Vote open for 72 hours.
 
  [ ] +1
  [ ] +0
  [ ] -1
 
  --
  Dennis Lundberg
 
  -
  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


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




 --
 Dennis Lundberg

 -
 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




 --
 Dennis Lundberg



 --
 Dennis Lundberg

 -
 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] Release Apache Maven Model Converter version 2.3

[sebb]

On 12 August 2013 20:10, Jason van Zyl ja...@tesla.io wrote:


 I have now read the threads that are referring to, and have not found
 a single link to any ASF rule stating that we need to include these
 things in a VOTE thread.

 So how do you propose that reviewers check the provenance of the files
 in the source release?

 Are you looking for files that are in a distribution that didn't come from 
 source control? Everything else as far as provenance goes is covered. Errant 
 content is a potential problem, but everything in a distribution should come 
 from source control which no one has access to until they have a signed CLA 
 on file.

Yes. That is where the whole saga started.

Proving provenance is why the SCM coordinates are needed for the vote.

The SCM details may also be useful to discover files accidentally
omitted from the source archive.

 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -








-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Release Maven 3.1.1

[sebb]

On 29 July 2013 17:18, Jason van Zyl ja...@tesla.io wrote:
 I was referring to the remote resources plugin which is associated with the 
 3.1.1 release.

 I have not attempted to release 3.1.1 and I have not sent out any release 
 vote. I do intend to add what Sebb suggested by adding the revision.

Thanks very much; that's very good news.

 On Jul 29, 2013, at 12:02 PM, Fred Cooke fred.co...@gmail.com wrote:

 Jason, there seems to be no trace of either the new or old tag for 3.1.1 on
 either ASF server or github. Did you push it? Did you not push it on
 purpose?

 What are your plans for tags until the release plugin is updated to allow
 creation of suffixed tags during the release to be supplemented by a final
 tag at publish time as discussed previously?

 I was hoping to document the hash of the new tag such that if it fails
 again, I can diff between old and new next time to avoid reviewing more
 than necessary or potentially missing something. Removing old tags (without
 having published the hash of them) breaks anyone's ability to do that in a
 secure and reliable way.

 I see no sign of the latest release of 3.1.1 in either the github mirror or
 the upstream @ ASF. Not on master, nor in a branch. Have you published the
 commits from the 3.1.1 release process at all?

 And to top it off, the github repo still has the 3.1 and 3.1.0 tags in it.
 I now have both here locally, which is a lot better than I can say for
 3.1.1, but a bit of a clue about the whole tag deleting thing... once
 published, they're out there, don't mess with them.

 Please advise on what you've been doing and what you plan to do. I don't
 grok it and can't find the source at all.

 Regards,

 Rot13:vroo AKA rot13:froo AKA Fred. [1][2]

 [1] http://www.urbandictionary.com/define.php?term=Froodefid=4078003
 [2] You're hilarious, Stephen! :-p :-)

 On Mon, Jul 29, 2013 at 3:37 PM, Jason van Zyl ja...@tesla.io wrote:

 Tag deleted, repository dropped, and now re-released and restaged.

 https://repository.apache.org/content/repositories/maven-034/

 On Jul 29, 2013, at 9:22 AM, Dennis Lundberg denn...@apache.org wrote:

 Yes, the loss of Maven 2.2.1 compatibility is critical IMO.

 On Mon, Jul 29, 2013 at 3:10 PM, Jason van Zyl ja...@tesla.io wrote:
 Is this critical for this release? I staged the release already?

 On Jul 29, 2013, at 5:39 AM, Dennis Lundberg denn...@apache.org
 wrote:

 Hi Jason

 I had a fix for MRRESOURCES-61 that I have committed to trunk now.

 When testing out the sample project that is in that issue I first had
 problems running it with maven-remote-resources-plugin 1.5-SNAPSHOT on
 Maven 2.2.1. After adding a missing dependency I got it working again.
 It works fine with 1.4 though, so for that reason I think we need to
 respin the release for maven-remote-resources-plugin. If you want to I
 can take care of it.


 The error I got was this:

 this realm =
 app0.child-container[org.apache.maven.plugins:maven-remote-resources-plugin:1.5-SNAPSHOT]
 urls[0] =
 file:/C:/Users/dlg01/.m2/repository/org/apache/maven/plugins/maven-remote-resources-plugin/1.5-SNAPSHOT/maven-remote-resources-plugin-1.5-SNAPSHOT.jar
 urls[1] =
 file:/C:/Users/dlg01/.m2/repository/org/codehaus/plexus/plexus-utils/1.1/plexus-utils-1.1.jar
 ...

 [INFO] Internal error in the plugin manager executing goal

 'org.apache.maven.plugins:maven-remote-resources-plugin:1.5-SNAPSHOT:process':
 Unable to load the mojo

 'org.apache.maven.plugins:maven-remote-resources-plugin:1.5-SNAPSHOT:process'
 in the plugin 'org.apache.maven.plugins:maven-remote-resources-plugin'.
 A required class is missing: org/codehaus/plexus/util/Scanner

 The Scanner class wasn't added to plexus-utils until version 1.5.8, so
 using the default version 1.1 won't work.


 On Mon, Jul 29, 2013 at 1:04 AM, Jason van Zyl ja...@tesla.io wrote:
 I staged a release of the remote resources plugin for anyone who
 wants to try:

 https://repository.apache.org/content/repositories/maven-030/

 How about we do a simultaneous release vote for the core and the
 remote resources plugin?

 On Jul 28, 2013, at 3:56 PM, Dennis Lundberg denn...@apache.org
 wrote:

 Hi,

 There is currently a SNAPSHOT dependency on
 maven-remote-resources-plugin.
 This was done in this commit by Daniel to improve the LICENCE file:

 https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=b4dc8931f2cc7b56302df78c03a7db57211cd3a7

 The question is whether we need to push out a release of that plugin
 prior to releasing Maven 3.1.1?


 I just made a small commit, adding a missing license header in a test
 xml file. Since I don't speak git very well yet, could someone make
 sure I did it correctly?

 https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=a58b91819c42c0a5a8616dc5562ba42287fa0f24

 On Sun, Jul 28, 2013 at 6:08 PM, Jason van Zyl ja...@tesla.io
 wrote:
 I'd like to release Maven 3.1.1 and try to get the cadence revived
 for minor version releases by trying to release minor versions

Re: Git resources was Re: [2/2] git commit: o change the scope of org.eclipse.sisu to test in the maven-aether-provider to prevent it from leaking out to clients.

[sebb]

On 27 July 2013 23:31, Fred Cooke fred.co...@gmail.com wrote:
 Yes, I've been guilty of it from time to time, as most have been,
 especially years ago ;-)

 Did you find any of the above useful? I hope so :-)

I don't know (yet), but I do know that it would be a lot easier to
reference as a web (e.g. Wiki) page ;-)

 Coincidental-Fred.

 On Sun, Jul 28, 2013 at 12:26 AM, Barrie Treloar baerr...@gmail.com wrote:

 On 28 July 2013 07:45, Fred Cooke fred.co...@gmail.com wrote:
  [1] http://pragprog.com/the-pragmatic-programmer/extracts/coincidence

 Ahh I see they are using you as an example :)

 -
 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] Release Apache Maven IDEA Plugin version 2.2.1

[sebb]

On 23 July 2013 19:23, Dennis Lundberg dennisl.apa...@gmail.com wrote:
 Hi,

 This is the final release of this plugin. After this release it will
 be retired, see separate vote thread for more info on that.

 We solved 1 issue:
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11135styleName=Htmlversion=14478

 There are still a couple of issues left in JIRA:
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11135status=1

 Staging repo:
 https://repository.apache.org/content/repositories/maven-008/
 https://repository.apache.org/content/repositories/maven-008/org/apache/maven/plugins/maven-idea-plugin/2.2.1/maven-idea-plugin-2.2.1-source-release.zip

 For those interested, the SCM URL can be found in the pom.xml that is
 in the staging repo.

I'm afraid that is all but useless, as the staging repo URL is transitory

Besides, does the POM also contain the revision number? Neither the
Maven PMC nor SVN guarantee immutable tags.

For the benefit of the mailing archives (and completeness of the vote
request), I assume you mean

https://svn.apache.org/repos/asf/maven/plugins/tags/maven-idea-plugin-2.2.1/
(r1506193)

 Staging site:
 http://maven.apache.org/plugins-archives/maven-idea-plugin-2.2.1/

 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

 --
 Dennis Lundberg

 -
 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] Release Apache Maven Model Converter version 2.3

[sebb]

On 23 July 2013 20:45, Dennis Lundberg denn...@apache.org wrote:
 Hi,

 This will be the final release of this shared component. After this
 release it will retire from the Apache Maven project and move to the
 Apache Archiva project. See separate vote thread about that.

 We solved 6 issues:
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=14389

 There are no issues left in JIRA (except for the one to retire, which
 I'll close later):
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11761component=13272status=1

 Staging repo:
 https://repository.apache.org/content/repositories/maven-010/
 https://repository.apache.org/content/repositories/maven-010/org/apache/maven/shared/maven-model-converter/2.3/maven-model-converter-2.3-source-release.zip

 Staging site (not synced yet):
 http://maven.apache.org/shared-archives/maven-model-converter-2.3/

 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html

What are the unique SCM coordinates?

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

 --
 Dennis Lundberg

 -
 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] Release Apache Maven Model Converter version 2.3

[sebb]

On 25 July 2013 16:55, Dennis Lundberg denn...@apache.org wrote:
 Den 25 jul 2013 16:08 skrev sebb seb...@gmail.com:

 On 23 July 2013 20:45, Dennis Lundberg denn...@apache.org wrote:
  Hi,
 
  This will be the final release of this shared component. After this
  release it will retire from the Apache Maven project and move to the
  Apache Archiva project. See separate vote thread about that.
 
  We solved 6 issues:
 
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=14389
 
  There are no issues left in JIRA (except for the one to retire, which
  I'll close later):
 
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11761component=13272status=1
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-010/
 
 https://repository.apache.org/content/repositories/maven-010/org/apache/maven/shared/maven-model-converter/2.3/maven-model-converter-2.3-source-release.zip
 
  Staging site (not synced yet):
  http://maven.apache.org/shared-archives/maven-model-converter-2.3/
 
  Guide to testing staged releases:
  http://maven.apache.org/guides/development/guide-testing-releases.html

 What are the unique SCM coordinates?

 The SCM URL can be found in the pom file at the staging repo.

As already mentioned in another thread, the staging repo URL is
temporary (and in fact can be reused for something completely
different).

Nor does it uniquely identify the code in SCM, as the revision is missing.

So it is not suitable for documenting the SCM coordinates.

 --
 Dennis Lundberg


  Vote open for 72 hours.
 
  [ ] +1
  [ ] +0
  [ ] -1
 
  --
  Dennis Lundberg
 
  -
  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


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven Model Converter version 2.3

[sebb]

On 25 July 2013 17:50, Dennis Lundberg denn...@apache.org wrote:
 On Thu, Jul 25, 2013 at 6:34 PM, sebb seb...@gmail.com wrote:
 On 25 July 2013 16:55, Dennis Lundberg denn...@apache.org wrote:
 Den 25 jul 2013 16:08 skrev sebb seb...@gmail.com:

 On 23 July 2013 20:45, Dennis Lundberg denn...@apache.org wrote:
  Hi,
 
  This will be the final release of this shared component. After this
  release it will retire from the Apache Maven project and move to the
  Apache Archiva project. See separate vote thread about that.
 
  We solved 6 issues:
 
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=14389
 
  There are no issues left in JIRA (except for the one to retire, which
  I'll close later):
 
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11761component=13272status=1
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-010/
 
 https://repository.apache.org/content/repositories/maven-010/org/apache/maven/shared/maven-model-converter/2.3/maven-model-converter-2.3-source-release.zip
 
  Staging site (not synced yet):
  http://maven.apache.org/shared-archives/maven-model-converter-2.3/
 
  Guide to testing staged releases:
  http://maven.apache.org/guides/development/guide-testing-releases.html

 What are the unique SCM coordinates?

 The SCM URL can be found in the pom file at the staging repo.

 As already mentioned in another thread, the staging repo URL is
 temporary (and in fact can be reused for something completely
 different).

 Nor does it uniquely identify the code in SCM, as the revision is missing.

 So it is not suitable for documenting the SCM coordinates.

 In the normal case, where a release is approved on the first round,
 there is only ever one tag in SVN and it will not be changed. In these
 cases I do not see the value of including the revision number at all.

 If a release fails on the first attempt, we reuse the tag. This means
 that the tag will exist at multiple revisions. If you are an
 archealogist and find out the revision number of an ancient vote, you
 can look at the date/time of the vote mail and compare that to the
 revision dates in SVN. Still I do not see the value of this. The last
 tag standing is the one that got approved.

Provided that the tag is not accidentally or deliberately changed subsequently.

 Is there an ASF requirement to include the SCM revision number in a
 release vote? I can't find one.

This was all discussed at great length already; please see my other
postings on the subject.


 --
 Dennis Lundberg


  Vote open for 72 hours.
 
  [ ] +1
  [ ] +0
  [ ] -1
 
  --
  Dennis Lundberg
 
  -
  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


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




 --
 Dennis Lundberg

 -
 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: svn commit: r1506890 - /maven/enforcer/trunk/maven-enforcer-plugin/src/main/java/org/apache/maven/plugins/enforcer/AbstractEnforceMojo.java

[sebb]

On 25 July 2013 12:17,  ol...@apache.org wrote:
 Author: olamy
 Date: Thu Jul 25 11:17:41 2013
 New Revision: 1506890

 URL: http://svn.apache.org/r1506890
 Log:
 Use Apache formatting rules.

pedantic mode
Strictly speaking, these are the Apache Maven formatting rules.
These rules are not the same for all Apache products (thankfully)

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: svn commit: r1507123 - in /maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install: AbstractInstallMojo.java InstallFileMojo.java InstallMojo.java

[sebb]

On 25 July 2013 21:54,  rfscho...@apache.org wrote:
 Author: rfscholte
 Date: Thu Jul 25 20:54:43 2013
 New Revision: 1507123

 URL: http://svn.apache.org/r1507123
 Log:
 apply generics

 Modified:
 
 maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/AbstractInstallMojo.java
 
 maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallFileMojo.java
 
 maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallMojo.java

 Modified: 
 maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/AbstractInstallMojo.java
 URL: 
 http://svn.apache.org/viewvc/maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/AbstractInstallMojo.java?rev=1507123r1=1507122r2=1507123view=diff
 ==
 --- 
 maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/AbstractInstallMojo.java
  (original)
 +++ 
 maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/AbstractInstallMojo.java
  Thu Jul 25 20:54:43 2013
 @@ -19,6 +19,10 @@ package org.apache.maven.plugin.install;
   * under the License.
   */

 +import java.io.File;
 +import java.io.IOException;
 +import java.util.Collection;
 +
  import org.apache.maven.artifact.Artifact;
  import org.apache.maven.artifact.factory.ArtifactFactory;
  import org.apache.maven.artifact.installer.ArtifactInstaller;
 @@ -32,11 +36,6 @@ import org.codehaus.plexus.digest.Digest
  import org.codehaus.plexus.digest.DigesterException;
  import org.codehaus.plexus.util.FileUtils;

 -import java.io.File;
 -import java.io.IOException;
 -import java.util.Collection;
 -import java.util.Iterator;
 -
  /**
   * Common fields for installation mojos.
   *
 @@ -126,7 +125,7 @@ public abstract class AbstractInstallMoj
   *must not be codenull/code.
   * @throws MojoExecutionException If the checksums could not be 
 installed.
   */
 -protected void installChecksums( Artifact artifact, Collection 
 metadataFiles )
 +protected void installChecksums( Artifact artifact, CollectionFile 
 metadataFiles )
  throws MojoExecutionException
  {
  if ( !createChecksum )
 @@ -137,12 +136,12 @@ public abstract class AbstractInstallMoj
  File artifactFile = getLocalRepoFile( artifact );
  installChecksums( artifactFile );

 -Collection metadatas = artifact.getMetadataList();
 +@SuppressWarnings( unchecked )

Why is it safe to ignore the unchecked warning?
This should be documented in an inline comment, e.g.
@SuppressWarnings( unchecked ) // safe because ...

If it's not true that the warning can be safely ignored, then either
leave the warning, or document under what circumstances the code can
fail

 +CollectionArtifactMetadata metadatas = artifact.getMetadataList();
  if ( metadatas != null )
  {
 -for ( Iterator it = metadatas.iterator(); it.hasNext(); )
 +for ( ArtifactMetadata metadata : metadatas )
  {
 -ArtifactMetadata metadata = (ArtifactMetadata) it.next();
  File metadataFile = getLocalRepoFile( metadata );
  metadataFiles.add( metadataFile );
  }
 @@ -155,12 +154,11 @@ public abstract class AbstractInstallMoj
   * @param metadataFiles The collection of metadata files to install 
 checksums for, must not be codenull/code.
   * @throws MojoExecutionException If the checksums could not be 
 installed.
   */
 -protected void installChecksums( Collection metadataFiles )
 +protected void installChecksums( CollectionFile metadataFiles )
  throws MojoExecutionException
  {
 -for ( Iterator it = metadataFiles.iterator(); it.hasNext(); )
 +for ( File metadataFile : metadataFiles )
  {
 -File metadataFile = (File) it.next();
  installChecksums( metadataFile );
  }
  }

 Modified: 
 maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallFileMojo.java
 URL: 
 http://svn.apache.org/viewvc/maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallFileMojo.java?rev=1507123r1=1507122r2=1507123view=diff
 ==
 --- 
 maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallFileMojo.java
  (original)
 +++ 
 maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallFileMojo.java
  Thu Jul 25 20:54:43 2013
 @@ -153,7 +153,7 @@ public class InstallFileMojo
   * Map that contains the repository layouts.
   */
  @Component( role = ArtifactRepositoryLayout.class )
 -private Map repositoryLayouts;
 +

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

[sebb]

On 25 July 2013 22:55, Paul Benedict pbened...@apache.org wrote:
 Agreed. I'll tip my hand and give my opinion: PMC members should have an
 Apache first mentality. They are gatekeepers and guardians of their
 project. Spinning off critical code to other OSS organizations should be
 frowned upon -- it splits the development and wider community into smaller
 pieces.

+1

 NB: My original response was just criticism of the commitment wording. It's
 nice to say what commitments PMC members should have, but if there's no way
 to enforce it, it puts into question why the commitments are even expected.
 AFAIK, merit at Apache is forever -- you can't have it undone. If someone
 loses their Apache first spirit and begins critical development
 elsewhere, what can be done about it? Are there any practical recourses? I
 don't think there is which is why Maven development has that problem today.

Surely the PMC can vote to remove individuals from the PMC if necessary?

If the PMC as a whole agrees to a particular code of conduct, then
anyone who does not conform should be politely reminded (on the
private@ list) of their responsibilities. Only if the non-conforming
behaviour persists should further action be taken.



 On Thu, Jul 25, 2013 at 4:36 PM, John Casey jdca...@commonjava.org wrote:

 On 7/25/13 4:17 PM, Paul Benedict wrote:

 Stephen, those are great questions. Yet, I think these questions are
 riding
 an assumption that PMC members are solely volunteering at Apache, because
 the emphasis (as I interpret your words) is to place the Apache project
 first/above other external contributions. Isn't that the heart of this
 debate? A person who solely contributes to Apache and no other OS
 organizations has no divided loyalties -- they do all their work here. But
 what happens when contributions are here and elsewhere? I ask
 rhetorically,
 to solicit answers, of course... and I see where this is going and what
 historical processes within Maven are being addressed.



 I don't think it's about whether you contribute elsewhere or not. It's
 about whether you expect to do a ton of work outside the community here,
 outside the commit logs and the review, in order to avoid the discussion
 and potential for veto.

 Working in this way opens the possibility for changing the rules for who
 gets to contribute, especially when code diverges for long periods then
 gets reconciled with a massive rebase.

 ASF is supposed to be about more than code. We're supposed to be working
 together on this project. I feel like the above hamstrings that whole
 process.

 And note: I'm only suggesting that the PMC - who is supposed to have the
 long-term interests of *this* project at heart - be held to a higher
 standard, to provide an example for the rest of the project. This is not
 saying you're stuck working solely within Maven just because you're on the
 PMC; it's saying that you should promote the health of the community by
 making sure the processes in place work as well as possible.

 ASF membership is supposed to be reserved for those who get the Apache
 Way, and I've heard it said that PMC membership should imply ASF
 membership. IMO, working for extended periods outside of the venues for our
 community is not consistent with having the best interests of this project
 in mind.




 On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly 
 stephen.alan.connolly@gmail.**com stephen.alan.conno...@gmail.com
 wrote:

  Perhaps we could reframe the question a little then (as people seem to be
 testing hung up on the committed wording)...

 Should the PMC encourage people experimenting on new improvements to
 Maven
 to do that work at the ASF? And if so, should they then practice what
 they
 preach, and ensure that any experiments with Maven take place on the ASF
 SCM servers (at least once such experiments become semi-serious or
 progress
 enough not to cause egg-on-face syndrome)?

 Shoud the PMC promote other Apache projects, or moving non-Apache
 projects
 to Apache? (Right now, to work on an issue in core and effect the change
 yourself you may need to establish merit with: Apache Maven, Eclipse
 Sisu,
 Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
 fine with half of these at Eclipse and the ther half here... Or maybe
 not... But that is a lot of projects where you need to establish merit
 and
 perhaps maintain merit just to be able to commit directly (which
 sometimes
 is the only way to effect the type of cross system changes that some of
 our
 more obscure bugs may require... GIT makes this less of a requirement, as
 patches on SVN are a PITA, though) )

 These types of questions need resolution as they will, further down the
 road, rise up again and cause wounds... Eg logback vs log4j2 is one that
 simmers at the edge (any time anyone mentioned coloured loggers)

 -Stephen

 On Thursday, 25 July 2013, Paul Benedict wrote:

  I don't think it is possible to force volunteer efforts and/or limit
 development 

Re: svn commit: r1505129 - in /maven/plugins/trunk/maven-install-plugin: LICENSE NOTICE

[sebb]

On 21 July 2013 11:48, Olivier Lamy ol...@apache.org wrote:
 Damned there are plenty of Apache projects which don't do that :-)

They will have to be fixed over time.

 But in this case the plugin maven-remote-resources-plugin doesn't have
 to be used anymore?
 Because now we can have duplicate NL with possible different content.
 As one will be maintained manually which mean we can miss to add content 
 etc...

AIUI remote resources does not automagically update the NL files; it
also has to be manually configured by using appended resources.
About the only thing RR does do is insert the year and project name details.
And only the year might need changing once the correct NL files have
been set up initially.
[And I have seen projects where the autoconfig of project name causes
problems - e.g. if the project uses a separate module to build the
dist archives]

AFAICT both approaches require manual configuration of the same
information - it's just held in different places.

 But so


 2013/7/21 Robert Scholte rfscho...@apache.org:
 From http://www.apache.org/dev/licensing-howto.html#source-tree-location

 Location Within the Source Tree

 LICENSE and NOTICE belong at the top level of the source tree. They may be
 named LICENSE.txt and NOTICE.txt, but the bare names are preferred.

 If you consider a release root as the top level of the source tree, then
 they need to be placed here.
 And yes, I'm aware that they are already bundled with the binairy, but these
 lines are quite clear where these files are expected.

 Robert

 Op Sun, 21 Jul 2013 08:57:28 +0200 schreef Olivier Lamy ol...@apache.org:


 why?
 Is it mandatory? If yes I'd like to have some links.
 AFAIK those files are generated.
 This mean we will have to add those files for all artifacts we produce.
 If one day the content change we will have to change all files in the
 scm instead of only the plugin which generate that.

 Seriously?

 2013/7/20  rfscho...@apache.org:

 Author: rfscholte
 Date: Sat Jul 20 12:58:34 2013
 New Revision: 1505129

 URL: http://svn.apache.org/r1505129
 Log:
 Add LICENSE and NOTICE files

 Added:
 maven/plugins/trunk/maven-install-plugin/LICENSE
 maven/plugins/trunk/maven-install-plugin/NOTICE

 Added: maven/plugins/trunk/maven-install-plugin/LICENSE
 URL:
 http://svn.apache.org/viewvc/maven/plugins/trunk/maven-install-plugin/LICENSE?rev=1505129view=auto

 ==
 --- maven/plugins/trunk/maven-install-plugin/LICENSE (added)
 +++ maven/plugins/trunk/maven-install-plugin/LICENSE Sat Jul 20 12:58:34
 2013
 @@ -0,0 +1,202 @@
 +
 + Apache License
 +   Version 2.0, January 2004
 +http://www.apache.org/licenses/
 +
 +   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
 +
 +   1. Definitions.
 +
 +  License shall mean the terms and conditions for use,
 reproduction,
 +  and distribution as defined by Sections 1 through 9 of this
 document.
 +
 +  Licensor shall mean the copyright owner or entity authorized by
 +  the copyright owner that is granting the License.
 +
 +  Legal Entity shall mean the union of the acting entity and all
 +  other entities that control, are controlled by, or are under
 common
 +  control with that entity. For the purposes of this definition,
 +  control means (i) the power, direct or indirect, to cause the
 +  direction or management of such entity, whether by contract or
 +  otherwise, or (ii) ownership of fifty percent (50%) or more of the
 +  outstanding shares, or (iii) beneficial ownership of such entity.
 +
 +  You (or Your) shall mean an individual or Legal Entity
 +  exercising permissions granted by this License.
 +
 +  Source form shall mean the preferred form for making
 modifications,
 +  including but not limited to software source code, documentation
 +  source, and configuration files.
 +
 +  Object form shall mean any form resulting from mechanical
 +  transformation or translation of a Source form, including but
 +  not limited to compiled object code, generated documentation,
 +  and conversions to other media types.
 +
 +  Work shall mean the work of authorship, whether in Source or
 +  Object form, made available under the License, as indicated by a
 +  copyright notice that is included in or attached to the work
 +  (an example is provided in the Appendix below).
 +
 +  Derivative Works shall mean any work, whether in Source or
 Object
 +  form, that is based on (or derived from) the Work and for which
 the
 +  editorial revisions, annotations, elaborations, or other
 modifications
 +  represent, as a whole, an original work of authorship. For the
 purposes
 +  of this License, Derivative Works shall not include works that
 remain
 +  separable from, or merely link (or bind by name) to the 

Re: svn commit: r1505129 - in /maven/plugins/trunk/maven-install-plugin: LICENSE NOTICE

[sebb]

On 21 July 2013 12:39, Robert Scholte rfscho...@apache.org wrote:
 Having a copy here does indeed mean we have to maintain it, unless we use
 svn:externals (but better not do that).
 If I'm correct, both files contain custom 'fields', referring to the name of
 the project and/or a year or date.

both files - which files are those?

 Also, I'm always having trouble with year
 ranges: suppose the range is 2005-2013, what does this mean in 2014?

The way the range has often been interpreted is inceptionYear-currentYear.
I think the idea is that the copyright year is changed whenever there
is a substantial change to the collective work (i.e. to which the
Copyright applies)
That normally means the latest year is updated to the year of the release.
But given that copyright lasts a long time, it may not matter if it is
not always updated.

 Anyhow, sounds like another enforcer-rule is required, maybe a specific
 ASF-ruleset

 Robert


 Op Sun, 21 Jul 2013 13:03:18 +0200 schreef sebb seb...@gmail.com:


 On 21 July 2013 11:48, Olivier Lamy ol...@apache.org wrote:

 Damned there are plenty of Apache projects which don't do that :-)


 They will have to be fixed over time.

 But in this case the plugin maven-remote-resources-plugin doesn't have
 to be used anymore?
 Because now we can have duplicate NL with possible different content.
 As one will be maintained manually which mean we can miss to add content
 etc...


 AIUI remote resources does not automagically update the NL files; it
 also has to be manually configured by using appended resources.
 About the only thing RR does do is insert the year and project name
 details.
 And only the year might need changing once the correct NL files have
 been set up initially.
 [And I have seen projects where the autoconfig of project name causes
 problems - e.g. if the project uses a separate module to build the
 dist archives]

 AFAICT both approaches require manual configuration of the same
 information - it's just held in different places.

 But so


 2013/7/21 Robert Scholte rfscho...@apache.org:

 From http://www.apache.org/dev/licensing-howto.html#source-tree-location

 Location Within the Source Tree

 LICENSE and NOTICE belong at the top level of the source tree. They may
 be
 named LICENSE.txt and NOTICE.txt, but the bare names are preferred.

 If you consider a release root as the top level of the source tree, then
 they need to be placed here.
 And yes, I'm aware that they are already bundled with the binairy, but
 these
 lines are quite clear where these files are expected.

 Robert

 Op Sun, 21 Jul 2013 08:57:28 +0200 schreef Olivier Lamy
 ol...@apache.org:


 why?
 Is it mandatory? If yes I'd like to have some links.
 AFAIK those files are generated.
 This mean we will have to add those files for all artifacts we produce.
 If one day the content change we will have to change all files in the
 scm instead of only the plugin which generate that.

 Seriously?

 2013/7/20  rfscho...@apache.org:


 Author: rfscholte
 Date: Sat Jul 20 12:58:34 2013
 New Revision: 1505129

 URL: http://svn.apache.org/r1505129
 Log:
 Add LICENSE and NOTICE files

 Added:
 maven/plugins/trunk/maven-install-plugin/LICENSE
 maven/plugins/trunk/maven-install-plugin/NOTICE

 Added: maven/plugins/trunk/maven-install-plugin/LICENSE
 URL:

 http://svn.apache.org/viewvc/maven/plugins/trunk/maven-install-plugin/LICENSE?rev=1505129view=auto


 ==
 --- maven/plugins/trunk/maven-install-plugin/LICENSE (added)
 +++ maven/plugins/trunk/maven-install-plugin/LICENSE Sat Jul 20
 12:58:34
 2013
 @@ -0,0 +1,202 @@
 +
 + Apache License
 +   Version 2.0, January 2004
 +http://www.apache.org/licenses/
 +
 +   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
 +
 +   1. Definitions.
 +
 +  License shall mean the terms and conditions for use,
 reproduction,
 +  and distribution as defined by Sections 1 through 9 of this
 document.
 +
 +  Licensor shall mean the copyright owner or entity authorized
 by
 +  the copyright owner that is granting the License.
 +
 +  Legal Entity shall mean the union of the acting entity and
 all
 +  other entities that control, are controlled by, or are under
 common
 +  control with that entity. For the purposes of this definition,
 +  control means (i) the power, direct or indirect, to cause the
 +  direction or management of such entity, whether by contract or
 +  otherwise, or (ii) ownership of fifty percent (50%) or more of
 the
 +  outstanding shares, or (iii) beneficial ownership of such
 entity.
 +
 +  You (or Your) shall mean an individual or Legal Entity
 +  exercising permissions granted by this License.
 +
 +  Source form shall mean the preferred form for making
 modifications,
 +  including but not limited to software source code

Re: svn commit: r1505129 - in /maven/plugins/trunk/maven-install-plugin: LICENSE NOTICE

[sebb]

On 21 July 2013 13:09, Dennis Lundberg denn...@apache.org wrote:
 Hi

 Has anyone asked if we can use generated files instead?

 Many of the ASF rules are written by people that have not concidered the
 fact that things such as these can be automated. Therefore many of these
 rules are stated in a way that does not fit directly into the Maven way of
 doing things.

And some things are not readily automateable - AFAIK there is no
accuratate data from which to automate this.
How do you track code imports with copyright statements? There are
several different ways to treat these.
Also, different licenses have different attribution requirements, and
for ones that do require attribution it has to be determined from the
license, which does not have a fixed format.

Also, the files change relatively rarely once set up.
Addition of 3rd party source or binaries to the archives is the main
reason to change the NL files.

 We do include these files in every Apache distribution we make. It's just
 that we do not store them in SCM.

 --
 Dennis Lundberg
 Den 21 jul 2013 11:13 skrev Robert Scholte rfscho...@apache.org:

 From http://www.apache.org/dev/**licensing-howto.html#source-**
 tree-locationhttp://www.apache.org/dev/licensing-howto.html#source-tree-location

 Location Within the Source Tree

 LICENSE and NOTICE belong at the top level of the source tree. They may be
 named LICENSE.txt and NOTICE.txt, but the bare names are preferred.

 If you consider a release root as the top level of the source tree, then
 they need to be placed here.
 And yes, I'm aware that they are already bundled with the binairy, but
 these lines are quite clear where these files are expected.

 Robert

 Op Sun, 21 Jul 2013 08:57:28 +0200 schreef Olivier Lamy ol...@apache.org
 :

  why?
 Is it mandatory? If yes I'd like to have some links.
 AFAIK those files are generated.
 This mean we will have to add those files for all artifacts we produce.
 If one day the content change we will have to change all files in the
 scm instead of only the plugin which generate that.

 Seriously?

 2013/7/20  rfscho...@apache.org:

 Author: rfscholte
 Date: Sat Jul 20 12:58:34 2013
 New Revision: 1505129

 URL: http://svn.apache.org/r1505129
 Log:
 Add LICENSE and NOTICE files

 Added:
 maven/plugins/trunk/maven-**install-plugin/LICENSE
 maven/plugins/trunk/maven-**install-plugin/NOTICE

 Added: maven/plugins/trunk/maven-**install-plugin/LICENSE
 URL: http://svn.apache.org/viewvc/**maven/plugins/trunk/maven-**
 install-plugin/LICENSE?rev=**1505129view=autohttp://svn.apache.org/viewvc/maven/plugins/trunk/maven-install-plugin/LICENSE?rev=1505129view=auto
 ==**==**
 ==
 --- maven/plugins/trunk/maven-**install-plugin/LICENSE (added)
 +++ maven/plugins/trunk/maven-**install-plugin/LICENSE Sat Jul 20
 12:58:34 2013
 @@ -0,0 +1,202 @@
 +
 + Apache License
 +   Version 2.0, January 2004
 +
 http://www.apache.org/**licenses/http://www.apache.org/licenses/
 +
 +   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
 +
 +   1. Definitions.
 +
 +  License shall mean the terms and conditions for use,
 reproduction,
 +  and distribution as defined by Sections 1 through 9 of this
 document.
 +
 +  Licensor shall mean the copyright owner or entity authorized by
 +  the copyright owner that is granting the License.
 +
 +  Legal Entity shall mean the union of the acting entity and all
 +  other entities that control, are controlled by, or are under
 common
 +  control with that entity. For the purposes of this definition,
 +  control means (i) the power, direct or indirect, to cause the
 +  direction or management of such entity, whether by contract or
 +  otherwise, or (ii) ownership of fifty percent (50%) or more of the
 +  outstanding shares, or (iii) beneficial ownership of such entity.
 +
 +  You (or Your) shall mean an individual or Legal Entity
 +  exercising permissions granted by this License.
 +
 +  Source form shall mean the preferred form for making
 modifications,
 +  including but not limited to software source code, documentation
 +  source, and configuration files.
 +
 +  Object form shall mean any form resulting from mechanical
 +  transformation or translation of a Source form, including but
 +  not limited to compiled object code, generated documentation,
 +  and conversions to other media types.
 +
 +  Work shall mean the work of authorship, whether in Source or
 +  Object form, made available under the License, as indicated by a
 +  copyright notice that is included in or attached to the work
 +  (an example is provided in the Appendix below).
 +
 +  Derivative Works shall mean any work, whether in Source or
 Object
 +  form, that is based on (or derived from) the Work and for which
 

Re: svn commit: r1505129 - in /maven/plugins/trunk/maven-install-plugin: LICENSE NOTICE

[sebb]

On 21 July 2013 13:22, Robert Scholte rfscho...@apache.org wrote:
 Op Sun, 21 Jul 2013 14:10:12 +0200 schreef sebb seb...@gmail.com:


 On 21 July 2013 12:39, Robert Scholte rfscho...@apache.org wrote:

 Having a copy here does indeed mean we have to maintain it, unless we use
 svn:externals (but better not do that).
 If I'm correct, both files contain custom 'fields', referring to the name
 of
 the project and/or a year or date.


 both files - which files are those?


 LICENSE and NOTICE


The LICENSE file is fixed - it should contain the text of AL 2.0,
which does not have configurable dates/project names.
Don't be misled by the bit at the bottom after the license proper -
that is a template for 3rd parties to use; it should not be
pre-configured by the ASF project.
It could (should?) probably be omitted.


 Also, I'm always having trouble with year
 ranges: suppose the range is 2005-2013, what does this mean in 2014?


 The way the range has often been interpreted is inceptionYear-currentYear.
 I think the idea is that the copyright year is changed whenever there
 is a substantial change to the collective work (i.e. to which the
 Copyright applies)
 That normally means the latest year is updated to the year of the release.
 But given that copyright lasts a long time, it may not matter if it is
 not always updated.


 If currentYear has no meaningful value for the copyright, why not drop it?

I did not say it had no meaning, only that it does not have to be 100%
up to date.

 Now it reads like the copyright only covers the range, that's not true.

Not sure what you mean by that.


 Anyhow, sounds like another enforcer-rule is required, maybe a specific
 ASF-ruleset


 Robert


 Op Sun, 21 Jul 2013 13:03:18 +0200 schreef sebb seb...@gmail.com:


 On 21 July 2013 11:48, Olivier Lamy ol...@apache.org wrote:


 Damned there are plenty of Apache projects which don't do that :-)



 They will have to be fixed over time.

 But in this case the plugin maven-remote-resources-plugin doesn't have
 to be used anymore?
 Because now we can have duplicate NL with possible different content.
 As one will be maintained manually which mean we can miss to add
 content
 etc...



 AIUI remote resources does not automagically update the NL files; it
 also has to be manually configured by using appended resources.
 About the only thing RR does do is insert the year and project name
 details.
 And only the year might need changing once the correct NL files have
 been set up initially.
 [And I have seen projects where the autoconfig of project name causes
 problems - e.g. if the project uses a separate module to build the
 dist archives]

 AFAICT both approaches require manual configuration of the same
 information - it's just held in different places.

 But so


 2013/7/21 Robert Scholte rfscho...@apache.org:


 From
 http://www.apache.org/dev/licensing-howto.html#source-tree-location

 Location Within the Source Tree

 LICENSE and NOTICE belong at the top level of the source tree. They
 may
 be
 named LICENSE.txt and NOTICE.txt, but the bare names are preferred.

 If you consider a release root as the top level of the source tree,
 then
 they need to be placed here.
 And yes, I'm aware that they are already bundled with the binairy, but
 these
 lines are quite clear where these files are expected.

 Robert

 Op Sun, 21 Jul 2013 08:57:28 +0200 schreef Olivier Lamy
 ol...@apache.org:


 why?
 Is it mandatory? If yes I'd like to have some links.
 AFAIK those files are generated.
 This mean we will have to add those files for all artifacts we
 produce.
 If one day the content change we will have to change all files in the
 scm instead of only the plugin which generate that.

 Seriously?

 2013/7/20  rfscho...@apache.org:



 Author: rfscholte
 Date: Sat Jul 20 12:58:34 2013
 New Revision: 1505129

 URL: http://svn.apache.org/r1505129
 Log:
 Add LICENSE and NOTICE files

 Added:
 maven/plugins/trunk/maven-install-plugin/LICENSE
 maven/plugins/trunk/maven-install-plugin/NOTICE

 Added: maven/plugins/trunk/maven-install-plugin/LICENSE
 URL:


 http://svn.apache.org/viewvc/maven/plugins/trunk/maven-install-plugin/LICENSE?rev=1505129view=auto



 ==
 --- maven/plugins/trunk/maven-install-plugin/LICENSE (added)
 +++ maven/plugins/trunk/maven-install-plugin/LICENSE Sat Jul 20
 12:58:34
 2013
 @@ -0,0 +1,202 @@
 +
 + Apache License
 +   Version 2.0, January 2004
 +http://www.apache.org/licenses/
 +
 +   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
 +
 +   1. Definitions.
 +
 +  License shall mean the terms and conditions for use,
 reproduction,
 +  and distribution as defined by Sections 1 through 9 of this
 document.
 +
 +  Licensor shall mean the copyright owner or entity
 authorized
 by
 +  the copyright owner that is granting

Re: svn commit: r1505129 - in /maven/plugins/trunk/maven-install-plugin: LICENSE NOTICE

[sebb]

On 21 July 2013 13:30, Robert Scholte rfscho...@apache.org wrote:
 Also, the files change relatively rarely once set up.

 I thought you strongly believed in Murphy's Law...

Not sure how that is relevant.


 I agree with Dennis: let's ask for the *facts* why these files are required
 here.

Robert already quoted this earlier in the thread:
From http://www.apache.org/dev/licensing-howto.html#source-tree-location

If you think that's wrong, it needs to be take up with Infra.

 If it is because they need to be included in the source-release file,
 then add them additionally instead of maintaining them per project.

No, they need to be included in SCM as well.

Since the SCM tree is basically what becomes the source archive, the
same files will do for both.
It's trivial to include the files in the source assembly descriptor so
they become part of the source archive.


 Op Sun, 21 Jul 2013 14:17:12 +0200 schreef sebb seb...@gmail.com:

 On 21 July 2013 13:09, Dennis Lundberg denn...@apache.org wrote:

 Hi

 Has anyone asked if we can use generated files instead?

 Many of the ASF rules are written by people that have not concidered the
 fact that things such as these can be automated. Therefore many of these
 rules are stated in a way that does not fit directly into the Maven way
 of
 doing things.


 And some things are not readily automateable - AFAIK there is no
 accuratate data from which to automate this.
 How do you track code imports with copyright statements? There are
 several different ways to treat these.
 Also, different licenses have different attribution requirements, and
 for ones that do require attribution it has to be determined from the
 license, which does not have a fixed format.

 Also, the files change relatively rarely once set up.
 Addition of 3rd party source or binaries to the archives is the main
 reason to change the NL files.

 We do include these files in every Apache distribution we make. It's
 just
 that we do not store them in SCM.

 --
 Dennis Lundberg
 Den 21 jul 2013 11:13 skrev Robert Scholte rfscho...@apache.org:

 From http://www.apache.org/dev/**licensing-howto.html#source-**

 tree-locationhttp://www.apache.org/dev/licensing-howto.html#source-tree-location

 Location Within the Source Tree

 LICENSE and NOTICE belong at the top level of the source tree. They may
 be
 named LICENSE.txt and NOTICE.txt, but the bare names are preferred.

 If you consider a release root as the top level of the source tree, then
 they need to be placed here.
 And yes, I'm aware that they are already bundled with the binairy, but
 these lines are quite clear where these files are expected.

 Robert

 Op Sun, 21 Jul 2013 08:57:28 +0200 schreef Olivier Lamy
 ol...@apache.org
 :

  why?

 Is it mandatory? If yes I'd like to have some links.
 AFAIK those files are generated.
 This mean we will have to add those files for all artifacts we produce.
 If one day the content change we will have to change all files in the
 scm instead of only the plugin which generate that.

 Seriously?

 2013/7/20  rfscho...@apache.org:

 Author: rfscholte
 Date: Sat Jul 20 12:58:34 2013
 New Revision: 1505129

 URL: http://svn.apache.org/r1505129
 Log:
 Add LICENSE and NOTICE files

 Added:
 maven/plugins/trunk/maven-**install-plugin/LICENSE
 maven/plugins/trunk/maven-**install-plugin/NOTICE

 Added: maven/plugins/trunk/maven-**install-plugin/LICENSE
 URL: http://svn.apache.org/viewvc/**maven/plugins/trunk/maven-**

 install-plugin/LICENSE?rev=**1505129view=autohttp://svn.apache.org/viewvc/maven/plugins/trunk/maven-install-plugin/LICENSE?rev=1505129view=auto
 ==**==**
 ==
 --- maven/plugins/trunk/maven-**install-plugin/LICENSE (added)
 +++ maven/plugins/trunk/maven-**install-plugin/LICENSE Sat Jul 20
 12:58:34 2013
 @@ -0,0 +1,202 @@
 +
 + Apache License
 +   Version 2.0, January 2004
 +
 http://www.apache.org/**licenses/http://www.apache.org/licenses/
 +
 +   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
 +
 +   1. Definitions.
 +
 +  License shall mean the terms and conditions for use,
 reproduction,
 +  and distribution as defined by Sections 1 through 9 of this
 document.
 +
 +  Licensor shall mean the copyright owner or entity authorized
 by
 +  the copyright owner that is granting the License.
 +
 +  Legal Entity shall mean the union of the acting entity and
 all
 +  other entities that control, are controlled by, or are under
 common
 +  control with that entity. For the purposes of this definition,
 +  control means (i) the power, direct or indirect, to cause the
 +  direction or management of such entity, whether by contract or
 +  otherwise, or (ii) ownership of fifty percent (50%) or more of
 the
 +  outstanding shares, or (iii) beneficial ownership of such
 entity.
 +
 +  You (or Your) shall mean

Re: svn commit: r1505129 - in /maven/plugins/trunk/maven-install-plugin: LICENSE NOTICE

[sebb]

On 21 July 2013 13:38, Daniel Kulp dk...@apache.org wrote:

 Also keep in mind, there is likely a large difference between the 
 LICENSE/NOTICE files that would go into a source release than would go into 
 the binary convenience releases.   90% of the source NOTICE/LICESE files are 
 just plain Apache License and the simple 4 line NOTICE.

Agreed.

pedantModethere are 4 non-blank lines; there is another blank line
in the middle/pedantMode

 For the binary, the LICENSE  needs links to the license of all the other jars 
 shipped in the package.   It also MAY need extra notices in the NOTICE.   The 
 RR plugin certainly can help with the first part of that.

But remember that only bits that are actually included in the binary
archive should be mentioned in NL.
Unless a dependency is actually bundled in the archive, it does not
count as far as the NL are concerned.

 Dan


 On Jul 21, 2013, at 8:09 AM, Dennis Lundberg denn...@apache.org wrote:

 Hi

 Has anyone asked if we can use generated files instead?

 Many of the ASF rules are written by people that have not concidered the
 fact that things such as these can be automated. Therefore many of these
 rules are stated in a way that does not fit directly into the Maven way of
 doing things.

 We do include these files in every Apache distribution we make. It's just
 that we do not store them in SCM.

 --
 Dennis Lundberg
 Den 21 jul 2013 11:13 skrev Robert Scholte rfscho...@apache.org:

 From http://www.apache.org/dev/**licensing-howto.html#source-**
 tree-locationhttp://www.apache.org/dev/licensing-howto.html#source-tree-location

 Location Within the Source Tree

 LICENSE and NOTICE belong at the top level of the source tree. They may be
 named LICENSE.txt and NOTICE.txt, but the bare names are preferred.

 If you consider a release root as the top level of the source tree, then
 they need to be placed here.
 And yes, I'm aware that they are already bundled with the binairy, but
 these lines are quite clear where these files are expected.

 Robert

 Op Sun, 21 Jul 2013 08:57:28 +0200 schreef Olivier Lamy ol...@apache.org
 :

 why?
 Is it mandatory? If yes I'd like to have some links.
 AFAIK those files are generated.
 This mean we will have to add those files for all artifacts we produce.
 If one day the content change we will have to change all files in the
 scm instead of only the plugin which generate that.

 Seriously?

 2013/7/20  rfscho...@apache.org:

 Author: rfscholte
 Date: Sat Jul 20 12:58:34 2013
 New Revision: 1505129

 URL: http://svn.apache.org/r1505129
 Log:
 Add LICENSE and NOTICE files

 Added:
maven/plugins/trunk/maven-**install-plugin/LICENSE
maven/plugins/trunk/maven-**install-plugin/NOTICE

 Added: maven/plugins/trunk/maven-**install-plugin/LICENSE
 URL: http://svn.apache.org/viewvc/**maven/plugins/trunk/maven-**
 install-plugin/LICENSE?rev=**1505129view=autohttp://svn.apache.org/viewvc/maven/plugins/trunk/maven-install-plugin/LICENSE?rev=1505129view=auto
 ==**==**
 ==
 --- maven/plugins/trunk/maven-**install-plugin/LICENSE (added)
 +++ maven/plugins/trunk/maven-**install-plugin/LICENSE Sat Jul 20
 12:58:34 2013
 @@ -0,0 +1,202 @@
 +
 + Apache License
 +   Version 2.0, January 2004
 +
 http://www.apache.org/**licenses/http://www.apache.org/licenses/
 +
 +   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
 +
 +   1. Definitions.
 +
 +  License shall mean the terms and conditions for use,
 reproduction,
 +  and distribution as defined by Sections 1 through 9 of this
 document.
 +
 +  Licensor shall mean the copyright owner or entity authorized by
 +  the copyright owner that is granting the License.
 +
 +  Legal Entity shall mean the union of the acting entity and all
 +  other entities that control, are controlled by, or are under
 common
 +  control with that entity. For the purposes of this definition,
 +  control means (i) the power, direct or indirect, to cause the
 +  direction or management of such entity, whether by contract or
 +  otherwise, or (ii) ownership of fifty percent (50%) or more of the
 +  outstanding shares, or (iii) beneficial ownership of such entity.
 +
 +  You (or Your) shall mean an individual or Legal Entity
 +  exercising permissions granted by this License.
 +
 +  Source form shall mean the preferred form for making
 modifications,
 +  including but not limited to software source code, documentation
 +  source, and configuration files.
 +
 +  Object form shall mean any form resulting from mechanical
 +  transformation or translation of a Source form, including but
 +  not limited to compiled object code, generated documentation,
 +  and conversions to other media types.
 +
 +  Work shall mean the work of authorship, whether in Source or
 +  Object 

Re: svn commit: r1505129 - in /maven/plugins/trunk/maven-install-plugin: LICENSE NOTICE

[sebb]

On 21 July 2013 14:05, Olivier Lamy ol...@apache.org wrote:
 2013/7/21 sebb seb...@gmail.com:
 On 21 July 2013 13:30, Robert Scholte rfscho...@apache.org wrote:
 Also, the files change relatively rarely once set up.

 I thought you strongly believed in Murphy's Law...

 Not sure how that is relevant.


 I agree with Dennis: let's ask for the *facts* why these files are required
 here.

 Robert already quoted this earlier in the thread:
 From http://www.apache.org/dev/licensing-howto.html#source-tree-location

 If you think that's wrong, it needs to be take up with Infra.

 why infra? they decide about our licensing mode?

They are responsible for the dev/ pages.


 If it is because they need to be included in the source-release file,
 then add them additionally instead of maintaining them per project.

 No, they need to be included in SCM as well.

 Since the SCM tree is basically what becomes the source archive, the
 same files will do for both.
 It's trivial to include the files in the source assembly descriptor so
 they become part of the source archive.


 Op Sun, 21 Jul 2013 14:17:12 +0200 schreef sebb seb...@gmail.com:

 On 21 July 2013 13:09, Dennis Lundberg denn...@apache.org wrote:

 Hi

 Has anyone asked if we can use generated files instead?

 Many of the ASF rules are written by people that have not concidered the
 fact that things such as these can be automated. Therefore many of these
 rules are stated in a way that does not fit directly into the Maven way
 of
 doing things.


 And some things are not readily automateable - AFAIK there is no
 accuratate data from which to automate this.
 How do you track code imports with copyright statements? There are
 several different ways to treat these.
 Also, different licenses have different attribution requirements, and
 for ones that do require attribution it has to be determined from the
 license, which does not have a fixed format.

 Also, the files change relatively rarely once set up.
 Addition of 3rd party source or binaries to the archives is the main
 reason to change the NL files.

 We do include these files in every Apache distribution we make. It's
 just
 that we do not store them in SCM.

 --
 Dennis Lundberg
 Den 21 jul 2013 11:13 skrev Robert Scholte rfscho...@apache.org:

 From http://www.apache.org/dev/**licensing-howto.html#source-**

 tree-locationhttp://www.apache.org/dev/licensing-howto.html#source-tree-location

 Location Within the Source Tree

 LICENSE and NOTICE belong at the top level of the source tree. They may
 be
 named LICENSE.txt and NOTICE.txt, but the bare names are preferred.

 If you consider a release root as the top level of the source tree, then
 they need to be placed here.
 And yes, I'm aware that they are already bundled with the binairy, but
 these lines are quite clear where these files are expected.

 Robert

 Op Sun, 21 Jul 2013 08:57:28 +0200 schreef Olivier Lamy
 ol...@apache.org
 :

  why?

 Is it mandatory? If yes I'd like to have some links.
 AFAIK those files are generated.
 This mean we will have to add those files for all artifacts we produce.
 If one day the content change we will have to change all files in the
 scm instead of only the plugin which generate that.

 Seriously?

 2013/7/20  rfscho...@apache.org:

 Author: rfscholte
 Date: Sat Jul 20 12:58:34 2013
 New Revision: 1505129

 URL: http://svn.apache.org/r1505129
 Log:
 Add LICENSE and NOTICE files

 Added:
 maven/plugins/trunk/maven-**install-plugin/LICENSE
 maven/plugins/trunk/maven-**install-plugin/NOTICE

 Added: maven/plugins/trunk/maven-**install-plugin/LICENSE
 URL: http://svn.apache.org/viewvc/**maven/plugins/trunk/maven-**

 install-plugin/LICENSE?rev=**1505129view=autohttp://svn.apache.org/viewvc/maven/plugins/trunk/maven-install-plugin/LICENSE?rev=1505129view=auto
 ==**==**
 ==
 --- maven/plugins/trunk/maven-**install-plugin/LICENSE (added)
 +++ maven/plugins/trunk/maven-**install-plugin/LICENSE Sat Jul 20
 12:58:34 2013
 @@ -0,0 +1,202 @@
 +
 + Apache License
 +   Version 2.0, January 2004
 +
 http://www.apache.org/**licenses/http://www.apache.org/licenses/
 +
 +   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
 +
 +   1. Definitions.
 +
 +  License shall mean the terms and conditions for use,
 reproduction,
 +  and distribution as defined by Sections 1 through 9 of this
 document.
 +
 +  Licensor shall mean the copyright owner or entity authorized
 by
 +  the copyright owner that is granting the License.
 +
 +  Legal Entity shall mean the union of the acting entity and
 all
 +  other entities that control, are controlled by, or are under
 common
 +  control with that entity. For the purposes of this definition,
 +  control means (i) the power, direct or indirect, to cause the
 +  direction or management of such entity, whether by contract

Re: RAT setup

[sebb]

On 21 July 2013 19:47, Jason van Zyl ja...@tesla.io wrote:

 On Jul 21, 2013, at 2:29 PM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 Revert my change upping to RAT 0.9

 Stupid plugin has major regression in performance, but 0.8 needs excludes
 for git


 Yup, just noticed that as well. After trying to attempt to release my 
 distribution 4 times and the RAT plugin blowing up 4 times. For the record 
 that's just the wrong phase to check something in. I don't want to wait after 
 all my tests to see a license violation report. Additionally it's running in 
 the release:perform but not anywhere else which is doubly annoying. So if 
 falling back to 0.8 fixes all that awesome.


AFAIK, the plugin has always bound to the phase verify by default.

RAT 0.9 added some extra syntax checks which perform very badly when
used on large files without AL headers.
RAT 0.8 is also slow on the same large files, but had fewer analysers,
so the issue was not so noticeable.
So you need to exclude large files that aren't supposed to have
headers, e.g. log files, Javadoc.
Both run much faster when only given input files with valid AL headers.

The performance problem has been fixed for the next release.

 Thanks for rolling that back.

 If I'd had notice I'd have reverted it my self but on a phone so no access
 to revert it... Once they get a proper usable release we *should* be ok...
 Though they don't seem to know how to cut releases with Maven... Like wtf
 is the deal with only -SNAPSHOT docs being public!!!

I agree that's wrong, but Creadur is not the only TLP which
regenerates site documentation from trunk.
Some people argue that it's important to publish the latest docs (even
if they apply to code that is not available - I don't subscribe to
that)

In the case of RAT, I don't think there's much difference - if any -
between 0.9 and 0.9-SNAPSHOT docs.


 On Sunday, 21 July 2013, Jason van Zyl wrote:

 I just tried to cut a distribution using the existing Maven POM and it let
 me get through the release:prepare phase without any issues and then failed
 during the release:perform phase. I have no idea how RAT works, or who set
 it up but that behavior is sub-optimal. Would probably be all right to be
 on all the time in the validate phase. Certainly preferable to letting me
 cut a tag and then blowing up while trying to release.

 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -

 Script timed out








 --
 Sent from my phone

 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -

 Script timed out







-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: svn commit: r1505380 - in /maven/resources/trunk: apache-jar-resource-bundle/src/main/resources/META-INF/NOTICE.vm apache-jar-txt-resource-bundle/src/main/resources/META-INF/NOTICE.txt.vm pom.xml

[sebb]

On 21 July 2013 14:39,  denn...@apache.org wrote:
 Author: dennisl
 Date: Sun Jul 21 13:39:23 2013
 New Revision: 1505380

 URL: http://svn.apache.org/r1505380
 Log:
 Remove spurious blank lines in generated NOTICE file.

 Modified:
 
 maven/resources/trunk/apache-jar-resource-bundle/src/main/resources/META-INF/NOTICE.vm
 
 maven/resources/trunk/apache-jar-txt-resource-bundle/src/main/resources/META-INF/NOTICE.txt.vm
 maven/resources/trunk/pom.xml
 maven/resources/trunk/resources-bundles-sample/pom.xml

 Modified: 
 maven/resources/trunk/apache-jar-resource-bundle/src/main/resources/META-INF/NOTICE.vm
 URL: 
 http://svn.apache.org/viewvc/maven/resources/trunk/apache-jar-resource-bundle/src/main/resources/META-INF/NOTICE.vm?rev=1505380r1=1505379r2=1505380view=diff
 ==
 --- 
 maven/resources/trunk/apache-jar-resource-bundle/src/main/resources/META-INF/NOTICE.vm
  (original)
 +++ 
 maven/resources/trunk/apache-jar-resource-bundle/src/main/resources/META-INF/NOTICE.vm
  Sun Jul 21 13:39:23 2013
 @@ -18,7 +18,6 @@
  ##
  ## $Id$
  ##
 -
  #if ($projectName)$projectName#else${project.name}#end

  Copyright ${projectTimespan}#if($project.organization.name) 
 $project.organization.name#else The Apache Software Foundation#end
 @@ -26,5 +25,3 @@ Copyright ${projectTimespan}#if($project

  This product includes software developed at
  The Apache Software Foundation (http://www.apache.org/).
 -
 -

 Modified: 
 maven/resources/trunk/apache-jar-txt-resource-bundle/src/main/resources/META-INF/NOTICE.txt.vm
 URL: 
 http://svn.apache.org/viewvc/maven/resources/trunk/apache-jar-txt-resource-bundle/src/main/resources/META-INF/NOTICE.txt.vm?rev=1505380r1=1505379r2=1505380view=diff
 ==
 --- 
 maven/resources/trunk/apache-jar-txt-resource-bundle/src/main/resources/META-INF/NOTICE.txt.vm
  (original)
 +++ 
 maven/resources/trunk/apache-jar-txt-resource-bundle/src/main/resources/META-INF/NOTICE.txt.vm
  Sun Jul 21 13:39:23 2013
 @@ -18,7 +18,6 @@
  ##
  ## $Id: NOTICE.vm 638319 2008-03-18 11:10:09Z vsiveton $
  ##
 -
  #if ($projectName)$projectName#else${project.name}#end

  Copyright ${projectTimespan}#if($project.organization.name) 
 $project.organization.name#else The Apache Software Foundation#end
 @@ -26,5 +25,3 @@ Copyright ${projectTimespan}#if($project

  This product includes software developed at
  The Apache Software Foundation (http://www.apache.org/).
 -
 -

 Modified: maven/resources/trunk/pom.xml
 URL: 
 http://svn.apache.org/viewvc/maven/resources/trunk/pom.xml?rev=1505380r1=1505379r2=1505380view=diff
 ==
 --- maven/resources/trunk/pom.xml (original)
 +++ maven/resources/trunk/pom.xml Sun Jul 21 13:39:23 2013
 @@ -37,7 +37,7 @@
inceptionYear2012/inceptionYear

properties
 -
 apache-jar-resource-bundle-version1.4/apache-jar-resource-bundle-version
 +
 apache-jar-resource-bundle-version1.5-SNAPSHOT/apache-jar-resource-bundle-version
  
 apache-jar-txt-resource-bundle-version1.5-SNAPSHOT/apache-jar-txt-resource-bundle-version
  
 apache-incubator-disclaimer-resource-bundle-version1.2-SNAPSHOT/apache-incubator-disclaimer-resource-bundle-version
  
 apache-source-release-assembly-descriptor-version1.0.3/apache-source-release-assembly-descriptor-version

 Modified: maven/resources/trunk/resources-bundles-sample/pom.xml
 URL: 
 http://svn.apache.org/viewvc/maven/resources/trunk/resources-bundles-sample/pom.xml?rev=1505380r1=1505379r2=1505380view=diff
 ==
 --- maven/resources/trunk/resources-bundles-sample/pom.xml (original)
 +++ maven/resources/trunk/resources-bundles-sample/pom.xml Sun Jul 21 
 13:39:23 2013
 @@ -41,7 +41,7 @@

dependencies
  dependency
 -  groupIdorg.apache/groupId
 +  groupIdorg.apache.apache.resources/groupId

apache.apache ?

Should that be: org.apache.maven.resources ?

artifactIdapache-jar-resource-bundle/artifactId
version${apache-jar-resource-bundle-version}/version
  /dependency
 @@ -73,7 +73,7 @@
  configuration
resourceBundles
  !-- Will generate META-INF/DEPENDENCIES META-INF/LICENSE 
 META-INF/NOTICE --
 -
 resourceBundleorg.apache:apache-jar-resource-bundle:${apache-jar-resource-bundle-version}/resourceBundle
 +
 resourceBundleorg.apache.apache.resources:apache-jar-resource-bundle:${apache-jar-resource-bundle-version}/resourceBundle

Ditto ?

  !-- Will generate META-INF/DEPENDENCIES.txt 
 META-INF/LICENSE.txt META-INF/NOTICE.txt --
  
 resourceBundleorg.apache.apache.resources:apache-jar-txt-resource-bundle:${apache-jar-txt-resource-bundle-version}/resourceBundle
  !-- Will generate 

Re: RAT setup

[sebb]

On 21 July 2013 21:23, Jason van Zyl ja...@tesla.io wrote:

 On Jul 21, 2013, at 3:14 PM, sebb seb...@gmail.com wrote:

 On 21 July 2013 19:47, Jason van Zyl ja...@tesla.io wrote:

 On Jul 21, 2013, at 2:29 PM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 Revert my change upping to RAT 0.9

 Stupid plugin has major regression in performance, but 0.8 needs excludes
 for git


 Yup, just noticed that as well. After trying to attempt to release my 
 distribution 4 times and the RAT plugin blowing up 4 times. For the record 
 that's just the wrong phase to check something in. I don't want to wait 
 after all my tests to see a license violation report. Additionally it's 
 running in the release:perform but not anywhere else which is doubly 
 annoying. So if falling back to 0.8 fixes all that awesome.


 AFAIK, the plugin has always bound to the phase verify by default.


 Poor choice of phase. Possibly the person who made it got validate and verify 
 mixed up. It's not that expensive so do it up-front, but right now it runs at 
 the worst of all possible times. Right at the end of the release process 
 having it go Ha ha! I pulled your pants down! is not very helpful.

Do you want to file a bug against it?

https://issues.apache.org/jira/browse/RAT

 RAT 0.9 added some extra syntax checks which perform very badly when
 used on large files without AL headers.
 RAT 0.8 is also slow on the same large files, but had fewer analysers,
 so the issue was not so noticeable.
 So you need to exclude large files that aren't supposed to have
 headers, e.g. log files, Javadoc.
 Both run much faster when only given input files with valid AL headers.

 The performance problem has been fixed for the next release.

 Thanks for rolling that back.

 If I'd had notice I'd have reverted it my self but on a phone so no access
 to revert it... Once they get a proper usable release we *should* be ok...
 Though they don't seem to know how to cut releases with Maven... Like wtf
 is the deal with only -SNAPSHOT docs being public!!!

 I agree that's wrong, but Creadur is not the only TLP which
 regenerates site documentation from trunk.
 Some people argue that it's important to publish the latest docs (even
 if they apply to code that is not available - I don't subscribe to
 that)

 In the case of RAT, I don't think there's much difference - if any -
 between 0.9 and 0.9-SNAPSHOT docs.


 On Sunday, 21 July 2013, Jason van Zyl wrote:

 I just tried to cut a distribution using the existing Maven POM and it let
 me get through the release:prepare phase without any issues and then 
 failed
 during the release:perform phase. I have no idea how RAT works, or who set
 it up but that behavior is sub-optimal. Would probably be all right to be
 on all the time in the validate phase. Certainly preferable to letting me
 cut a tag and then blowing up while trying to release.

 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -

 Script timed out








 --
 Sent from my phone

 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -

 Script timed out







 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -

 Script timed out







-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: svn commit: r1505079 - /maven/site/trunk/content/apt/docs/history.apt

[sebb]

On 20 July 2013 03:46,  ol...@apache.org wrote:
 Author: olamy
 Date: Sat Jul 20 02:46:30 2013
 New Revision: 1505079

 URL: http://svn.apache.org/r1505079
 Log:
 document date format

 Modified:
 maven/site/trunk/content/apt/docs/history.apt

 Modified: maven/site/trunk/content/apt/docs/history.apt
 URL: 
 http://svn.apache.org/viewvc/maven/site/trunk/content/apt/docs/history.apt?rev=1505079r1=1505078r2=1505079view=diff
 ==
 --- maven/site/trunk/content/apt/docs/history.apt [UTF-8] (original)
 +++ maven/site/trunk/content/apt/docs/history.apt [UTF-8] Sat Jul 20 02:46:30 
 2013
 @@ -27,6 +27,8 @@ Hervé Boutemy

  Maven Releases History

 +  Date format is: -MM-DD
 +

Excellent idea.

  * Maven 3

* 2013-07-15 3.1.0 {{{/ref/3.1.0/} reference documentation}},
 @@ -167,4 +169,4 @@ Maven Releases History

* 2002-03-30 1.0-beta-2 
 {{{http://jakarta.apache.org/site/news/news-2002.html#0330.1} announce}}

 -  []
 +  []
 \ No newline at end of file



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: svn commit: r1504937 - /maven/site/trunk/content/site.xml

[sebb]

On 19 July 2013 17:54,  hbout...@apache.org wrote:
 Author: hboutemy
 Date: Fri Jul 19 16:54:44 2013
 New Revision: 1504937

 URL: http://svn.apache.org/r1504937
 Log:
 point to ASF license page instead of MPIR copy


Thank you!

 Modified:
 maven/site/trunk/content/site.xml

 Modified: maven/site/trunk/content/site.xml
 URL: 
 http://svn.apache.org/viewvc/maven/site/trunk/content/site.xml?rev=1504937r1=1504936r2=1504937view=diff
 ==
 --- maven/site/trunk/content/site.xml (original)
 +++ maven/site/trunk/content/site.xml Fri Jul 19 16:54:44 2013
 @@ -47,7 +47,7 @@ under the License.
item name=Release Notes (${currentStableVersion}) 
 href=/docs/${currentStableVersion}/release-notes.html/
item name=Release Notes (${current22xVersion}) 
 href=/docs/${current22xVersion}/release-notes.html/
item name=Release Notes (${current20xVersion}) 
 href=/docs/${current20xVersion}/release-notes.html/
 -  item name=License href=/license.html/
 +  item name=License href=http://www.apache.org/licenses//
item name=Security href=/security.html/
  /menu




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.1.0 class loading error with Swagger Maven Plugin

[sebb]

On 18 July 2013 09:36, Stuart McCulloch mccu...@gmail.com wrote:
 On 18 Jul 2013, at 05:41, Brett Porter br...@apache.org wrote:

 Hi,

 I've got a regression here using the Swagger Maven Plugin [1] that looks 
 different to the Aether one. Before I go poking around further, I was 
 wondering if anyone can tell me if it's a regression on the Maven (and 
 dependencies) end, or something expected to be updated in the plugin?

 The converter code (part of the plexus adapter layer) was clean-roomed when 
 it moved to eclipse and this particular legacy constructor was missed.

 I'll fix this and stage a container update - note that the call to register 
 the realm converter isn't strictly necessary and could also be removed from 
 the plugin.

Might be worth flagging the legacy constructor as deprecated?
With Javadoc comment to say what to do instead?

 --
 Cheers, Stuart

 [ERROR] Failed to execute goal 
 com.github.kongchen:swagger-maven-plugin:1.1.1:generate (default) on project 
 maestro-webapp: An API incompatibility was encountered during configuration 
 of mojo com.github.kongchen:swagger-maven-plugin:1.1.1:generate: 
 java.lang.NoSuchMethodError: 
 org.codehaus.plexus.component.configurator.converters.special.ClassRealmConverter.init(Lorg/codehaus/classworlds/ClassRealm;)V
 [ERROR] -
 [ERROR] realm =plugincom.github.kongchen:swagger-maven-plugin:1.1.1
 [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
 [ERROR] urls[0] = 
 file:/Users/brett/.m2/repository/com/github/kongchen/swagger-maven-plugin/1.1.1/swagger-maven-plugin-1.1.1.jar
 [ERROR] urls[1] = 
 file:/Users/brett/.m2/repository/org/codehaus/plexus/plexus-utils/1.5.15/plexus-utils-1.5.15.jar

 It seems to be the same error that was fixed in an 3.0 RC [2].

 Anyone seen this before?

 - Brett

 [1] https://github.com/kongchen/swagger-maven-plugin
 [2] http://jira.codehaus.org/browse/MNG-4832

 --
 Brett Porter
 br...@apache.org
 http://brettporter.wordpress.com/
 http://au.linkedin.com/in/brettporter
 http://twitter.com/brettporter

 -
 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: Maven 3.1.0 class loading error with Swagger Maven Plugin

[sebb]

On 18 July 2013 15:22, Arnaud Héritier aherit...@gmail.com wrote:
 On Thu, Jul 18, 2013 at 3:32 PM, Jason van Zyl ja...@tesla.io wrote:

 When Sisu with this fix is released I'll cut a 3.1.1.


 +1

Now would be a good time to start fixing the NOTICE and LICENSE files.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.1.0 class loading error with Swagger Maven Plugin

[sebb]

On 18 July 2013 16:35, Arnaud Héritier aherit...@gmail.com wrote:
 There are open issues with the detail of changes to do ?

Create NL files for the top-level of SCM.
As the source archive must be created from SCM, these NL files will
be suitable for the source archive assuming nothing significant is
added or omitted.

The License file for the binary archive can start with the source
License as presumably everything in source is compiled or copied to
the binary.
In addition, the License file will need to be adjusted to take account
of any additional bundled software, e.g. 3rd party jars
In some cases, the Notice file will also need to be adjusted, but note
the following:

http://www.apache.org/dev/licensing-howto.html#mod-notice

It's possible that the same NOTICE file will do for both source and
binary archives.
It's very unlikely that the same LICENSE file is suitable.

Once the appropriate NL files have been created, they will only need
to change if the bundled software is changed - or if some source code
is imported.

Note that the NL files must only relate to the bundled bits, so
individual jars are likely to need the same NL files as the source.


 On Thu, Jul 18, 2013 at 5:33 PM, sebb seb...@gmail.com wrote:

 On 18 July 2013 15:22, Arnaud Héritier aherit...@gmail.com wrote:
  On Thu, Jul 18, 2013 at 3:32 PM, Jason van Zyl ja...@tesla.io wrote:
 
  When Sisu with this fix is released I'll cut a 3.1.1.
 
 
  +1

 Now would be a good time to start fixing the NOTICE and LICENSE files.

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




 --
 -
 Arnaud Héritier
 http://aheritier.net
 Mail/GTalk: aheritier AT gmail DOT com
 Twitter/Skype : aheritier

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.1.0 class loading error with Swagger Maven Plugin

[sebb]

Which JIRA would that be?

On 18 July 2013 17:24, Stephen Connolly stephen.alan.conno...@gmail.com wrote:
 If it's not in JIRA it doesn't exist


 On 18 July 2013 17:18, sebb seb...@gmail.com wrote:

 On 18 July 2013 16:35, Arnaud Héritier aherit...@gmail.com wrote:
  There are open issues with the detail of changes to do ?

 Create NL files for the top-level of SCM.
 As the source archive must be created from SCM, these NL files will
 be suitable for the source archive assuming nothing significant is
 added or omitted.

 The License file for the binary archive can start with the source
 License as presumably everything in source is compiled or copied to
 the binary.
 In addition, the License file will need to be adjusted to take account
 of any additional bundled software, e.g. 3rd party jars
 In some cases, the Notice file will also need to be adjusted, but note
 the following:

 http://www.apache.org/dev/licensing-howto.html#mod-notice

 It's possible that the same NOTICE file will do for both source and
 binary archives.
 It's very unlikely that the same LICENSE file is suitable.

 Once the appropriate NL files have been created, they will only need
 to change if the bundled software is changed - or if some source code
 is imported.

 Note that the NL files must only relate to the bundled bits, so
 individual jars are likely to need the same NL files as the source.

 
  On Thu, Jul 18, 2013 at 5:33 PM, sebb seb...@gmail.com wrote:
 
  On 18 July 2013 15:22, Arnaud Héritier aherit...@gmail.com wrote:
   On Thu, Jul 18, 2013 at 3:32 PM, Jason van Zyl ja...@tesla.io
 wrote:
  
   When Sisu with this fix is released I'll cut a 3.1.1.
  
  
   +1
 
  Now would be a good time to start fixing the NOTICE and LICENSE files.
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 
 
 
  --
  -
  Arnaud Héritier
  http://aheritier.net
  Mail/GTalk: aheritier AT gmail DOT com
  Twitter/Skype : aheritier

 -
 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: Maven 3.1.0 class loading error with Swagger Maven Plugin

[sebb]

On 18 July 2013 17:58, Jason van Zyl ja...@tesla.io wrote:
 If it's important to do than just do it.

It is important, but it's not something I can do.
I have no experience of Git or the process used to build Maven itself
so the best I can do is state what I think needs to happen to fix the
problems.

 I think you're getting these types of responses because it comes across like 
 you're telling others what to do. Again, if you deem it more important than 
 anything you're doing I'd preempt the writing of longish emails and just do 
 it.

Well, I was asked what changes were needed, so I did ny best to
provide a description.

 On Jul 18, 2013, at 10:39 AM, sebb seb...@gmail.com wrote:

 Which JIRA would that be?

 On 18 July 2013 17:24, Stephen Connolly stephen.alan.conno...@gmail.com 
 wrote:
 If it's not in JIRA it doesn't exist


 On 18 July 2013 17:18, sebb seb...@gmail.com wrote:

 On 18 July 2013 16:35, Arnaud Héritier aherit...@gmail.com wrote:
 There are open issues with the detail of changes to do ?

 Create NL files for the top-level of SCM.
 As the source archive must be created from SCM, these NL files will
 be suitable for the source archive assuming nothing significant is
 added or omitted.

 The License file for the binary archive can start with the source
 License as presumably everything in source is compiled or copied to
 the binary.
 In addition, the License file will need to be adjusted to take account
 of any additional bundled software, e.g. 3rd party jars
 In some cases, the Notice file will also need to be adjusted, but note
 the following:

 http://www.apache.org/dev/licensing-howto.html#mod-notice

 It's possible that the same NOTICE file will do for both source and
 binary archives.
 It's very unlikely that the same LICENSE file is suitable.

 Once the appropriate NL files have been created, they will only need
 to change if the bundled software is changed - or if some source code
 is imported.

 Note that the NL files must only relate to the bundled bits, so
 individual jars are likely to need the same NL files as the source.


 On Thu, Jul 18, 2013 at 5:33 PM, sebb seb...@gmail.com wrote:

 On 18 July 2013 15:22, Arnaud Héritier aherit...@gmail.com wrote:
 On Thu, Jul 18, 2013 at 3:32 PM, Jason van Zyl ja...@tesla.io
 wrote:

 When Sisu with this fix is released I'll cut a 3.1.1.


 +1

 Now would be a good time to start fixing the NOTICE and LICENSE files.

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




 --
 -
 Arnaud Héritier
 http://aheritier.net
 Mail/GTalk: aheritier AT gmail DOT com
 Twitter/Skype : aheritier

 -
 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


 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -

 You are never dedicated to something you have complete confidence in.
 No one is fanatically shouting that the sun is going to rise tomorrow.
 They know it is going to rise tomorrow. When people are fanatically
 dedicated to political or religious faiths or any other kind of
 dogmas or goals, it's always because these dogmas or
 goals are in doubt.

   -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance







-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: tags maven-3.1 vs maven-3.1.0

[sebb]

On 16 July 2013 09:44, Fred Cooke fred.co...@gmail.com wrote:
 On Tue, Jul 16, 2013 at 8:14 AM, Chris Graham chrisgw...@gmail.com wrote:

 Michael's point about omiting the trailing .0 is valid, and introducing it
 now does not follow the established convention.
 Is it going to be cleaned up?


 I sincerely hope not! That would involve potential for confusion should
 anyone have fetched the old and now deleted (only in the apache copy!)
 tag. Let the sleeping dog lie and improve the process to avoid it in future.


+1

Now that it is published, you have to live with it.

Is the versioning convention documented anywhere?

 -Chris


 On Tue, Jul 16, 2013 at 6:42 AM, Arnaud Héritier aherit...@gmail.com
 wrote:

  lol
 
 
  On Mon, Jul 15, 2013 at 10:40 PM, Hervé BOUTEMY herve.bout...@free.fr
  wrote:
 
   uh, another bot?
  
   Le lundi 15 juillet 2013 22:28:26 Fred Cooke a écrit :
What was the hash for future reference? This is why sebb is sooo
 right.
   If
you have a unique coordinate, you're good for life, no matter what
 gets
done to the SCM. (more or less)
   
On Mon, Jul 15, 2013 at 9:53 PM, Arnaud Héritier 
 aherit...@gmail.com
   wrote:
 done

 On Mon, Jul 15, 2013 at 9:36 PM, Jason van Zyl ja...@tesla.io
  wrote:
  Sure, drop the older one.
 
  On Jul 15, 2013, at 2:57 PM, Arnaud Héritier 
 aherit...@gmail.com

 wrote:
   Hi Jason,
  
It seems we have 2 tags in Git for maven 3.1 : maven-3.1 and

 maven-3.1.0

I think that the the right one to keep is the second one
  (893ca28
   -

 28th

   June) ?
  
I suppose we need to drop the old maven-3.1 tag ?
  
   Cheers,
  
   -
   Arnaud Héritier
   http://aheritier.net
   Mail/GTalk: aheritier AT gmail DOT com
   Twitter/Skype : aheritier
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder,  Apache Maven
  http://twitter.com/jvanzyl
  -
 
  Simplex sigillum veri. (Simplicity is the seal of truth.)

 --
 -
 Arnaud Héritier
 http://aheritier.net
 Mail/GTalk: aheritier AT gmail DOT com
 Twitter/Skype : aheritier
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
   For additional commands, e-mail: dev-h...@maven.apache.org
  
  
 
 
  --
  -
  Arnaud Héritier
  http://aheritier.net
  Mail/GTalk: aheritier AT gmail DOT com
  Twitter/Skype : aheritier
 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.1 - Stable ?

[sebb]

On 16 July 2013 22:37, Jason van Zyl ja...@tesla.io wrote:
 Typo on my part. There are 48 things to change when updating a release.

 I updated and triggered the publish an hour ago. I'm not sure when/how it 
 updates.

Should be immediate (within a few seconds), assuming svnpubsub is
running normally.

 On Jul 16, 2013, at 5:34 PM, Arnaud Héritier aherit...@gmail.com wrote:

 Hi,

  Do we consider the 3.1.0 as the latest stable ?

  On the download page there is a typo (?)
 http://maven.apache.org/download.cgi
 Maven 3.1.0 :This is the future of Maven (alpha status).

  On the homepage we always have the Get Maven 3.0.5 on the right
 http://maven.apache.org/index.html

  We also have an ad for ApacheCon NA 2013 that was in february

 -
 Arnaud Héritier
 http://aheritier.net
 Mail/GTalk: aheritier AT gmail DOT com
 Twitter/Skype : aheritier

 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -

 To do two things at once is to do neither.

  -- Publilius Syrus, Roman slave, first century B.C.







-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.1 - Stable ?

[sebb]

On 16 July 2013 23:45, Jason van Zyl ja...@tesla.io wrote:

 On Jul 16, 2013, at 5:42 PM, sebb seb...@gmail.com wrote:

 On 16 July 2013 22:37, Jason van Zyl ja...@tesla.io wrote:
 Typo on my part. There are 48 things to change when updating a release.

 I updated and triggered the publish an hour ago. I'm not sure when/how it 
 updates.

 Should be immediate (within a few seconds), assuming svnpubsub is
 running normally.


 I've not found that to be the case generally.

In that case, maybe what you think is publishing is not actually publishing.

I don't know how the Maven site is set up, but certainly the main ASF
site is visible a few seconds - at most a minute - after making a
update.
The EU site sometimes takes a bit longer to catch up.

The sites are directly checked out from the live SVN, and this happens
very soon after checkin.

If anything takes more than 5 minutes to become visible, either the
system is down, or the change was not published to it.
[Of course, remember to clear your browser cache]

You can of course check the the file in SVN history to see what has happened.

 On Jul 16, 2013, at 5:34 PM, Arnaud Héritier aherit...@gmail.com wrote:

 Hi,

 Do we consider the 3.1.0 as the latest stable ?

 On the download page there is a typo (?)
 http://maven.apache.org/download.cgi
 Maven 3.1.0 :This is the future of Maven (alpha status).

 On the homepage we always have the Get Maven 3.0.5 on the right
 http://maven.apache.org/index.html

 We also have an ad for ApacheCon NA 2013 that was in february

 -
 Arnaud Héritier
 http://aheritier.net
 Mail/GTalk: aheritier AT gmail DOT com
 Twitter/Skype : aheritier

 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -

 To do two things at once is to do neither.

 -- Publilius Syrus, Roman slave, first century B.C.







 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -

 the course of true love never did run smooth ...

  -- Shakespeare







-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [08/50] git commit: Add ASL license header

[sebb]

On 15 July 2013 23:26,  aherit...@apache.org wrote:
 Add ASL license header


Trivial nit: it's the AL header, i.e. Apache License header.

It's not a Software license per se.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [12/50] git commit: Replace package.html with package-info.java

[sebb]

On 15 July 2013 23:26,  aherit...@apache.org wrote:
 Replace package.html with package-info.java

Warning: this will cause unnecessary compilations unless/until
https://jira.codehaus.org/browse/MCOMPILER-205 is fixed.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [16/50] git commit: fix typo and use names from their respective POMs

[sebb]

On 15 July 2013 23:26,  aherit...@apache.org wrote:
 fix typo and use names from their respective POMs


 Project: http://git-wip-us.apache.org/repos/asf/maven/repo
 Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/2fea34f7
 Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/2fea34f7
 Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/2fea34f7

 Branch: refs/heads/slf4j-logback
 Commit: 2fea34f701041befbcbe9a64dab103c2e7d5f3de
 Parents: b0a83f6
 Author: Brett Porter br...@apache.org
 Authored: Tue May 28 21:22:22 2013 -0700
 Committer: Brett Porter br...@apache.org
 Committed: Tue May 28 21:22:22 2013 -0700

 --
  apache-maven/NOTICE.txt | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 --


 http://git-wip-us.apache.org/repos/asf/maven/blob/2fea34f7/apache-maven/NOTICE.txt
 --
 diff --git a/apache-maven/NOTICE.txt b/apache-maven/NOTICE.txt
 index cd7e583..e911104 100644
 --- a/apache-maven/NOTICE.txt
 +++ b/apache-maven/NOTICE.txt
 @@ -16,7 +16,8 @@ The Eclipse Foundation (http://eclipse.org/).
  This product includes software (Plexus and Classworlds) developed by
  The Codehaus Foundation (http://www.codehaus.org/).

 -This product includes software (Spice, Plexus Ciper and Sec Dispatcher) 
 developed by
 +This product includes software (Spice, Plexus Cipher and Plexus Security
 +Dispatcher) developed by
  Sonatype Inc. (http://www.sonatype.org/).

  This product includes software (NekoHTML) developed by


Note that the license docs were recently clarified - it may not be
necessary to add as much to NOTICE as has been traditional.
It looks like having the notice in the included LICENSE file may be
enough to satisfy the requirements.

See:

http://www.apache.org/dev/licensing-howto.html#mod-notice

I assume questions should be directed to Infra - they look after the
dev/ site - and/or Legal-Discuss

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [25/50] git commit: Code cleanup - Maven requires Java 5+ : Remove unnecessary boxing

[sebb]

On 15 July 2013 23:26,  aherit...@apache.org wrote:
 Code cleanup - Maven requires Java 5+ : Remove unnecessary boxing

Not sure that's a good idea.

I've found quite a few bugs related to boxing in other projects.

For example, auto-unboxing a field that can sometimes be null may
cause an unexpected NPE; it's not always obvious what is causing the
NPE if it's implicit.
Or code that is using Integer when it should be using int - or vice versa.

If you remove all the explicit boxing there are usually too many
compiler warnings to wade through.
And using @SuppressWarning where the auto-boxing is justified is more
work than keeping the explicit boxing/unboxing.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [32/50] git commit: Code cleanup - Maven requires Java 5+ : Replace for and while loops by for each

[sebb]

On 15 July 2013 23:26,  aherit...@apache.org wrote:
 Code cleanup - Maven requires Java 5+ : Replace for and while loops by for 
 each


 Project: http://git-wip-us.apache.org/repos/asf/maven/repo
 Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/d92746dc
 Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/d92746dc
 Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/d92746dc

 Branch: refs/heads/slf4j-logback
 Commit: d92746dc25bdce073571cf6fd8f78d6573fe75f0
 Parents: 1f84f8f
 Author: Arnaud Héritier aherit...@apache.org
 Authored: Tue Jun 11 22:21:54 2013 +0200
 Committer: Arnaud Héritier aherit...@apache.org
 Committed: Tue Jun 11 22:21:54 2013 +0200

 --
  .../maven/profiles/DefaultProfileManager.java   | 12 ++---
  .../maven/profiles/ProfilesConversionUtils.java | 12 ++---
  .../DefaultModelInheritanceAssembler.java   | 13 ++---
  .../StringSearchModelInterpolator.java  | 50 +++-
  .../project/path/DefaultPathTranslator.java |  4 +-
  .../usability/plugin/ExpressionDocumenter.java  | 18 +++
  .../maven/artifact/testutils/MockManager.java   | 12 ++---
  .../apache/maven/project/ModelUtilsTest.java|  4 +-
  .../maven/project/ProjectClasspathTest.java |  3 +-
  .../inheritance/t04/ProjectInheritanceTest.java | 12 +++--
  .../inheritance/t05/ProjectInheritanceTest.java | 13 ++---
  .../inheritance/t07/ProjectInheritanceTest.java | 15 +++---
  .../resolver/DefaultArtifactCollectorTest.java  | 12 ++---
  .../apache/maven/execution/ReactorManager.java  |  8 ++--
  .../DefaultLifecycleBindingsInjector.java   |  9 ++--
  .../org/apache/maven/project/MavenProject.java  | 18 +++
  .../java/DefaultJavaToolchainFactory.java   | 15 +++---
  .../project/DefaultMavenProjectBuilderTest.java |  4 +-
  .../java/org/apache/maven/cli/CLIManager.java   |  4 +-
  .../java/org/apache/maven/cli/MavenCli.java | 12 ++---
  20 files changed, 120 insertions(+), 130 deletions(-)
 --


 http://git-wip-us.apache.org/repos/asf/maven/blob/d92746dc/maven-compat/src/main/java/org/apache/maven/profiles/DefaultProfileManager.java
 --
 diff --git 
 a/maven-compat/src/main/java/org/apache/maven/profiles/DefaultProfileManager.java
  
 b/maven-compat/src/main/java/org/apache/maven/profiles/DefaultProfileManager.java
 index 740c2cd..bfade80 100644
 --- 
 a/maven-compat/src/main/java/org/apache/maven/profiles/DefaultProfileManager.java
 +++ 
 b/maven-compat/src/main/java/org/apache/maven/profiles/DefaultProfileManager.java
 @@ -141,9 +141,9 @@ public class DefaultProfileManager
  */
  public void explicitlyActivate( List profileIds )
  {
 -for ( Iterator it = profileIds.iterator(); it.hasNext(); )
 +for ( Object profileId1 : profileIds )
  {
 -String profileId = (String) it.next();
 +String profileId = (String) profileId1;

 explicitlyActivate( profileId );
 }


If the code were updated to use Java 5 generics, the cast would disappear too:

public void explicitlyActivate( ListString profileIds )
{
for ( String profileId : profileIds )
{
explicitlyActivate( profileId );
}
}

But maybe that is already planned.

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Next release for master

[sebb]

Commit
Then
Review

On 16 July 2013 00:15, Barrie Treloar baerr...@gmail.com wrote:
 On 16 July 2013 08:39, Stephen Connolly stephen.alan.conno...@gmail.com 
 wrote:
 Remember folks, we are CTR not RTC so we shouldn't be holding up getting
 stuff done

 I think I should be able to grok that, but google isn't helping me.
 Are you making up your own acronyms :)

 -
 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: [RESULT] [VOTE] Apache 3.1.0

[sebb]

On 13 July 2013 14:54, Jason van Zyl ja...@tesla.io wrote:
 The vote has passed with the following:

 +1 Binding: Arnaud, Stephen, Olivier, Hervé
 +1 Non-binding: Stevo, Anders, Tony, Tamas, Baptiste, Mark, Mirko

I voted -1 (non-binding) because of the invalid NOTICE file (amongst
other reasons).


 I'll promote the release in Nexus and update the docs and announce Monday 
 when it's all done.

 On Jun 30, 2013, at 3:00 PM, Jason van Zyl ja...@tesla.io wrote:

 Here are the release bits for 3.1.0:

 Release notes:
 https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=18967

 Staging repository:
 https://repository.apache.org/content/repositories/maven-084/

 Staged distribution:
 https://repository.apache.org/content/repositories/maven-084/org/apache/maven/apache-maven/3.1.0/

 Staged Site:
 http://maven.apache.org/ref/3.1.0

 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -

 There's no sense in being precise when you don't even know what you're 
 talking about.

 -- John von Neumann






 Thanks,

 Jason

 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -

 People develop abstractions by generalizing from concrete examples.
 Every attempt to determine the correct abstraction on paper without
 actually developing a running system is doomed to failure. No one
 is that smart. A framework is a resuable design, so you develop it by
 looking at the things it is supposed to be a design of. The more examples
 you look at, the more general your framework will be.

   -- Ralph Johnson  Don Roberts, Patterns for Evolving Frameworks







-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org