Re: Preparing a release of maven-war-plugin, need assistance

[Dennis Lundberg]

Hi Slawomir,

Thanks for your help with my GitHub problem, much appreciated.

It's great if we can fix some more issues before we make the release. Just
let me know when you are done, or if you need any assistance.

Dennis Lundberg


Den mån 25 apr. 2022 kl 16:07 skrev Slawomir Jaranowski <
s.jaranow...@gmail.com>:

> Hi Dennis
>
> Please wait with release until all issues in 3.4.0 will be resolved.
>  I'm going to resolve the issue assigned to me today or tomorrow.
>
>
>
> pt., 22 kwi 2022 o 11:18 Dennis Lundberg  napisał(a):
>
> > Hi,
> >
> > I am trying to prepare for a release of maven-war-plugin, but I have run
> > into some trouble. After going through the open issues and especially
> those
> > scheduled for the next release, I find myself not being able to merge a
> > pull request for MWAR-444 at
> > https://github.com/apache/maven-war-plugin/pull/20
> >
> > This is somewhat new territory for me, merging pull requests for Maven
> > components on Github. When I look at the repository at GitHub I can't see
> > the "Settings" tab, so it might be that I do not have enough privileges
> on
> > the repo to do a merge. Or it might be that we are using protected
> > branches, but since I cannot access the Settings I can't tell. Perhaps
> the
> > requested reviewers need to do a review before the pull request can be
> > merged?
> >
> > Can someone help to shed some light on this?
> >
> > Dennis Lundberg
> >
>
>
> --
> Sławomir Jaranowski
>

Preparing a release of maven-war-plugin, need assistance

[Dennis Lundberg]

Hi,

I am trying to prepare for a release of maven-war-plugin, but I have run
into some trouble. After going through the open issues and especially those
scheduled for the next release, I find myself not being able to merge a
pull request for MWAR-444 at
https://github.com/apache/maven-war-plugin/pull/20

This is somewhat new territory for me, merging pull requests for Maven
components on Github. When I look at the repository at GitHub I can't see
the "Settings" tab, so it might be that I do not have enough privileges on
the repo to do a merge. Or it might be that we are using protected
branches, but since I cannot access the Settings I can't tell. Perhaps the
requested reviewers need to do a review before the pull request can be
merged?

Can someone help to shed some light on this?

Dennis Lundberg

What is the best way to use SemVer versions with maven-artifact?

[Dennis Lundberg]

Hi all,

When using a CI environments that create a new SemVer-compliant version for
every build. These could use a qualifier like "-build" together with the
build number. Here is an example:

1.2.3-build417

This signifies build number 417 of the not-yet-released version 1.2.3.

The current behavior of maven-artifact is 1.2.3-build417 > 1.2.3.

This is the opposite of what is expected for a SemVer version number. One
way to solve this would be to add an alias for the qualifier "build" which
should equal "snapshot". So when doing version comparisons 1.2.3-build417 <
1.2.3.

I have a feeling though that this might wreck things for people that do not
follow SemVer. What would be the best way to solve this? It would be great
if a user can tell Maven to follow SemVer. I imagine creating a
SemVer-compliant brother to ComparableVersion, in combination with making
the version comparison class configurable in some way.

--
Dennis Lundberg

Re: Need help merging pull requests for maven-site

[Dennis Lundberg]

Den tis 11 aug. 2020 kl 13:46 skrev Olivier Lamy :

> On Tue, 11 Aug 2020 at 19:40, Dennis Lundberg 
> wrote:
>
> > Thanks Olivier,
> >
> > I was just following our release process at
> >
> >
> https://maven.apache.org/developers/release/maven-project-release-procedure.html
>
>
> I do not see anything related to create pull request for such easy change
>

The pull requests are created automatically when you edit the github page.

>
> >
> > Under step 2 of "Promote the release" it says
> > "In case there's an overview table with version (e.g. plugins
> > <https://maven.apache.org/plugins/index.html> and shared
> > <https://maven.apache.org/shared/index.html>) you can directly edit it
> on
> > the github page."
> >
> > Should i change those instructions to push to master if you have those
> > permissions?
>
>
> frankly we are adults we do not need instructions to create pr request for
> such obvious change :)
>

I agree :)

>
>
>
> > --
> > Dennis Lundberg
> >
> >
> > Den tis 11 aug. 2020 kl 13:29 skrev Olivier Lamy :
> >
> > > Hi Dennis
> > > I just merged your pr.
> > > But for those changes just push to master branch you do not really need
> > > approval and it's a bit useless...
> > > (and this will avoid some notifications noise)
> > >
> > > On Tue, 11 Aug 2020 at 19:25, Dennis Lundberg 
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > During the release I've made recently I have updated
> maven-site@github
> > > > with
> > > > the new versions and release dates. These turn into pull requests
> that
> > > have
> > > > now been approved. However I seem to lack some permissions (or
> > knowledge)
> > > > to merge these pull requests from the GitHub UI.
> > > >
> > > > Can someone point me in the right direction, or help me merge these:
> > > > https://github.com/apache/maven-site/pull/189
> > > > https://github.com/apache/maven-site/pull/192
> > > > https://github.com/apache/maven-site/pull/193
> > > >
> > > > Thanks in advance,
> > > > Dennis Lundberg
> > > >
> > >
> > >
> > > --
> > > Olivier Lamy
> > > http://twitter.com/olamy | http://linkedin.com/in/olamy
> > >
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Re: Need help merging pull requests for maven-site

[Dennis Lundberg]

Thanks Olivier,

I was just following our release process at
https://maven.apache.org/developers/release/maven-project-release-procedure.html

Under step 2 of "Promote the release" it says
"In case there's an overview table with version (e.g. plugins
<https://maven.apache.org/plugins/index.html> and shared
<https://maven.apache.org/shared/index.html>) you can directly edit it on
the github page."

Should i change those instructions to push to master if you have those
permissions?

--
Dennis Lundberg


Den tis 11 aug. 2020 kl 13:29 skrev Olivier Lamy :

> Hi Dennis
> I just merged your pr.
> But for those changes just push to master branch you do not really need
> approval and it's a bit useless...
> (and this will avoid some notifications noise)
>
> On Tue, 11 Aug 2020 at 19:25, Dennis Lundberg  wrote:
>
> > Hi,
> >
> > During the release I've made recently I have updated maven-site@github
> > with
> > the new versions and release dates. These turn into pull requests that
> have
> > now been approved. However I seem to lack some permissions (or knowledge)
> > to merge these pull requests from the GitHub UI.
> >
> > Can someone point me in the right direction, or help me merge these:
> > https://github.com/apache/maven-site/pull/189
> > https://github.com/apache/maven-site/pull/192
> > https://github.com/apache/maven-site/pull/193
> >
> > Thanks in advance,
> > Dennis Lundberg
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Need help merging pull requests for maven-site

[Dennis Lundberg]

Hi,

During the release I've made recently I have updated maven-site@github with
the new versions and release dates. These turn into pull requests that have
now been approved. However I seem to lack some permissions (or knowledge)
to merge these pull requests from the GitHub UI.

Can someone point me in the right direction, or help me merge these:
https://github.com/apache/maven-site/pull/189
https://github.com/apache/maven-site/pull/192
https://github.com/apache/maven-site/pull/193

Thanks in advance,
Dennis Lundberg

[ANN] Apache Maven Resources Plugin 3.2.0 Released

[Dennis Lundberg]

The Apache Maven team is pleased to announce the release of the Apache
Maven Resources Plugin, version 3.2.0

 The Resources Plugin handles the copying of project resources to the
output directory.

https://maven.apache.org/plugins/maven-resources-plugin/

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


  org.apache.maven.plugins
  maven-resources-plugin
  3.2.0


You can download the appropriate sources etc. from the download page:

https://maven.apache.org/plugins/maven-resources-plugin/download.cgi


Release Notes - Maven Resources Plugin - Version 3.2.0

** Bug
* [MRESOURCES-171] - ISO8859-1 properties files get changed into UTF-8
when filtered
* [MRESOURCES-210] - copy-resources erases file permissions
* [MRESOURCES-236] - Copying of files with permissions broken
* [MRESOURCES-257] - property from list element in pom model

** Improvement
* [MRESOURCES-251] - Upgrade plexus-interpolation 1.26
* [MRESOURCES-252] - Add m2e lifecycle Metadata to plugin
* [MRESOURCES-256] - make build Reproducible
* [MRESOURCES-258] - Only overwrite filtered resources when contents
differ

** Dependency upgrade
* [MRESOURCES-249] - Upgrade maven-plugins parent to version 32
* [MRESOURCES-255] - Upgrade plexus-utils 3.3.0
* [MRESOURCES-261] - Make Maven 3.1.0 the minimum version
* [MRESOURCES-263] - Update to maven-filtering 3.2.0


Enjoy,

-The Apache Maven team

[ANN] Apache Maven Filtering 3.2.0 Released

[Dennis Lundberg]

The Apache Maven team is pleased to announce the release of the Apache
Maven Filtering, version 3.2.0

This is a shared component for all plugins that need to filter resources.
https://maven.apache.org/shared/maven-filtering/

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


  org.apache.maven.shared
  maven-filtering
  3.2.0


You can download the appropriate sources etc. from the download page:
https://maven.apache.org/shared/maven-filtering/download.cgi

Release Notes - Maven Filtering  - Version 3.2.0

** Bug
* [MSHARED-417] - Infinite loop when loading self-referencing properties
* [MSHARED-599] - Escaping the escape string produces incorrect output.
* [MSHARED-829] - MavenResourcesExecution.copyOf() returns new
instance without properties set

** New Feature
* [MSHARED-934] - Allow using a different encoding when filtering
properties files

** Improvement
* [MSHARED-646] - Removed prerequisites for none maven-plugin project
* [MSHARED-664] - Add ico files to default non-filtered extensions
* [MSHARED-830] - Require Java 7
* [MSHARED-879] - make build Reproducible
* [MSHARED-884] - Only overwrite filtered resources when contents differ
* [MSHARED-946] - Update to maven-shared-utils 3.3.3

** Dependency upgrade
* [MSHARED-575] - Upgrade maven-shared-utils to 3.1.0
* [MSHARED-600] - Upgrade of plexus-interpolation to 1.24.
* [MSHARED-645] - Upgrade to maven-shared-utils 3.2.0
* [MSHARED-667] - plexus-utils 3.0.24 to 3.1.0
* [MSHARED-711] - Upgrade parent to 31
* [MSHARED-712] - Upgrade maven-surefire/failsafe-plugin 2.21.0 for JDK 10
* [MSHARED-755] - Upgrade parent to version 32.
* [MSHARED-756] - Upgrade plexus-interpolation to 1.25
* [MSHARED-757] - Upgrade maven-shared-utils to 3.2.1
* [MSHARED-758] - Upgrade JUnit to 4.12
* [MSHARED-789] - Upgrade maven-shared-components parent to 33
* [MSHARED-790] - Upgrade plexus-utils 3.1.1
* [MSHARED-809] - Upgrade plexus-utils 3.2.0

Enjoy,

-The Apache Maven team

[RESULT] [VOTE] Release Apache Maven Resources Plugin version 3.2.0 and Apache Maven Filtering version 3.2.0

[Dennis Lundberg]

Hi,

The vote has passed with the following result:

+1 : Robert Scholte, Dennis Lundberg, Olivier Lamy, Sylwester Lachiewicz,
Karl Heinz Marbaise

PMC quorum: Robert Scholte, Dennis Lundberg, Olivier Lamy, Karl Heinz
Marbaise

I will promote the artifacts to the central repo.

--
Dennis Lundberg


Den ons 5 aug. 2020 kl 18:22 skrev Dennis Lundberg :

> Hi,
>
> We solved 12 and 23 
> issues:https://issues.apache.org/jira/projects/MRESOURCES/versions/12343158https://issues.apache.org/jira/projects/MSHARED/versions/12338083
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOURCES%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESChttps://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-filtering%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> Staging 
> repo:https://repository.apache.org/content/repositories/maven-1603/https://repository.apache.org/service/local/repositories/maven-1603/content/org/apache/maven/plugins/maven-resources-plugin/3.2.0/maven-resources-plugin-3.2.0-source-release.ziphttps://repository.apache.org/service/local/repositories/maven-1603/content/org/apache/maven/shared/maven-filtering/3.2.0/maven-filtering-3.2.0-source-release.zip
>
> Source release checksum(s):
> maven-resources-plugin-3.2.0-source-release.zip  sha512: 
> ca920a510de6195d563c49617920823562aaa9be56cc8ca8f87fa9473d65814a6f4ce33f32ccdb7c9115162f8a560cded3deb2cc32bd4b8649a8e57ccc4fb020
> maven-filtering-3.2.0-source-release.zip  sha512: 
> 6cb730fbf9d5a2f3dbf951547d3b2720989906001a1844cfd38367a579f7a11d073807d68d4a907d083daa4295154fa135205dabba94f21ab73afca3022fbe7b
>
> Staging 
> site:https://maven.apache.org/plugins-archives/maven-resources-plugin-LATEST/https://maven.apache.org/shared-archives/maven-filtering-LATEST/
>
> Guide to testing staged releases:
>
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> --
>
> Dennis Lundberg
>

Re: [VOTE] Release Apache Maven Resources Plugin version 3.2.0 and Apache Maven Filtering version 3.2.0

[Dennis Lundberg]

+1

--
Dennis Lundberg


Den ons 5 aug. 2020 kl 18:22 skrev Dennis Lundberg :

> Hi,
>
> We solved 12 and 23 
> issues:https://issues.apache.org/jira/projects/MRESOURCES/versions/12343158https://issues.apache.org/jira/projects/MSHARED/versions/12338083
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOURCES%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESChttps://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-filtering%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
>
> Staging 
> repo:https://repository.apache.org/content/repositories/maven-1603/https://repository.apache.org/service/local/repositories/maven-1603/content/org/apache/maven/plugins/maven-resources-plugin/3.2.0/maven-resources-plugin-3.2.0-source-release.ziphttps://repository.apache.org/service/local/repositories/maven-1603/content/org/apache/maven/shared/maven-filtering/3.2.0/maven-filtering-3.2.0-source-release.zip
>
> Source release checksum(s):
> maven-resources-plugin-3.2.0-source-release.zip  sha512: 
> ca920a510de6195d563c49617920823562aaa9be56cc8ca8f87fa9473d65814a6f4ce33f32ccdb7c9115162f8a560cded3deb2cc32bd4b8649a8e57ccc4fb020
> maven-filtering-3.2.0-source-release.zip  sha512: 
> 6cb730fbf9d5a2f3dbf951547d3b2720989906001a1844cfd38367a579f7a11d073807d68d4a907d083daa4295154fa135205dabba94f21ab73afca3022fbe7b
>
> Staging 
> site:https://maven.apache.org/plugins-archives/maven-resources-plugin-LATEST/https://maven.apache.org/shared-archives/maven-filtering-LATEST/
>
> Guide to testing staged releases:
>
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> --
>
> Dennis Lundberg
>

Re: Continued problems releasing components

[Dennis Lundberg]

Okay, answering myself here.

Had a look in JIRA and found 2 issues that are related to my problems:
https://issues.apache.org/jira/browse/MRELEASE-1038
https://issues.apache.org/jira/browse/MRELEASE-1042

I believe that 1038 is what bit me, because now remember seeing a strange
warning in the log:
[WARNING] The requested profile "pom.xml" could not be activated because it
does not exist.

I'm on Windows and the actual Maven execution, does not show up in the log,
like it does for Arnaud on OSX(?) in 1042.

Would the correct work around be to remove all active profiles in
settings.xml?

--
Dennis Lundberg


Den ons 5 aug. 2020 kl 18:42 skrev Dennis Lundberg :

> Hi,
>
> As I mentioned on my release of maven-shared-utils, I had problems with
> the release process.
>
> I have just started the release for Maven Resources Plugin and Maven
> Filtering and have had continued problems. This time I went in and deleted
> the failed release attempt tags from git and started over.
>
> I still haven't figured out where the problem lies, but here's the short
> version of what happened.
>
> This time I used Maven 3.3.9 and OpenJDK 8 from the start to avoid using
> toolchains. Everything went fine up to and including
> maven release:prepare
>
> But when I ran
> mvn release:perform
> things fell apart, again.
>
> Having learned from the previous release failure I had a decent idea about
> what went wrong. The profile activation for Maven Release Plugin does not
> kick in, so no sources jar, no javadoc jar, no source distribution and no
> signatures.
>
> Either there is something with my environment that messes things up, or
> else there are problems in the parent POM chain. Having had a quick look at
> the POMs, I noticed some contradicting configuration for
> maven-release-plugin between Maven parent and Apache parent. I tried the
> same release commands again using Maven 3.6.3, in case there were some POM
> inheritance issues that have been fixed, but the results were the same.
>
> Finally I had to resort to manually trigger the releaseProfiles parameter
> for the plugin and also the Maven profile, so the command that worked for
> me looked like this:
> mvn release:perform -DreleaseProfiles=apache-release -Papache-release
>
> Earlier I tried with only -D, but that didn't work. I haven't tried using
> only -P.
>
> Has anybody else had similar problems?
> Do you have any clue as to what might be wrong?
>
> --
> Dennis Lundberg
>

Continued problems releasing components

[Dennis Lundberg]

Hi,

As I mentioned on my release of maven-shared-utils, I had problems with the
release process.

I have just started the release for Maven Resources Plugin and Maven
Filtering and have had continued problems. This time I went in and deleted
the failed release attempt tags from git and started over.

I still haven't figured out where the problem lies, but here's the short
version of what happened.

This time I used Maven 3.3.9 and OpenJDK 8 from the start to avoid using
toolchains. Everything went fine up to and including
maven release:prepare

But when I ran
mvn release:perform
things fell apart, again.

Having learned from the previous release failure I had a decent idea about
what went wrong. The profile activation for Maven Release Plugin does not
kick in, so no sources jar, no javadoc jar, no source distribution and no
signatures.

Either there is something with my environment that messes things up, or
else there are problems in the parent POM chain. Having had a quick look at
the POMs, I noticed some contradicting configuration for
maven-release-plugin between Maven parent and Apache parent. I tried the
same release commands again using Maven 3.6.3, in case there were some POM
inheritance issues that have been fixed, but the results were the same.

Finally I had to resort to manually trigger the releaseProfiles parameter
for the plugin and also the Maven profile, so the command that worked for
me looked like this:
mvn release:perform -DreleaseProfiles=apache-release -Papache-release

Earlier I tried with only -D, but that didn't work. I haven't tried using
only -P.

Has anybody else had similar problems?
Do you have any clue as to what might be wrong?

--
Dennis Lundberg

[VOTE] Release Apache Maven Resources Plugin version 3.2.0 and Apache Maven Filtering version 3.2.0

[Dennis Lundberg]

Hi,

We solved 12 and 23
issues:https://issues.apache.org/jira/projects/MRESOURCES/versions/12343158https://issues.apache.org/jira/projects/MSHARED/versions/12338083

There are still a couple of issues left in JIRA:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOURCES%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESChttps://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-filtering%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

Staging 
repo:https://repository.apache.org/content/repositories/maven-1603/https://repository.apache.org/service/local/repositories/maven-1603/content/org/apache/maven/plugins/maven-resources-plugin/3.2.0/maven-resources-plugin-3.2.0-source-release.ziphttps://repository.apache.org/service/local/repositories/maven-1603/content/org/apache/maven/shared/maven-filtering/3.2.0/maven-filtering-3.2.0-source-release.zip

Source release checksum(s):
maven-resources-plugin-3.2.0-source-release.zip  sha512:
ca920a510de6195d563c49617920823562aaa9be56cc8ca8f87fa9473d65814a6f4ce33f32ccdb7c9115162f8a560cded3deb2cc32bd4b8649a8e57ccc4fb020
maven-filtering-3.2.0-source-release.zip  sha512:
6cb730fbf9d5a2f3dbf951547d3b2720989906001a1844cfd38367a579f7a11d073807d68d4a907d083daa4295154fa135205dabba94f21ab73afca3022fbe7b

Staging 
site:https://maven.apache.org/plugins-archives/maven-resources-plugin-LATEST/https://maven.apache.org/shared-archives/maven-filtering-LATEST/

Guide to testing staged releases:

https://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for at least 72 hours.

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


--

Dennis Lundberg

[ANN] Apache Maven Shared Utils 3.3.3 Released

[Dennis Lundberg]

The Apache Maven team is pleased to announce the release of the Apache
Maven Shared Utils, version 3.3.3

This project aims to be a functional replacement for plexus-utils in Maven.
https://maven.apache.org/shared/maven-shared-utils/

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


  org.apache.maven.shared
  maven-shared-utils
  3.3.3


You can download the appropriate sources etc. from the download page:
https://maven.apache.org/plugins/maven-shared-utils/download.cgi
Release Notes - Maven Shared Components - Version maven-shared-utils-3.3.3

** Bug
* [MSHARED-297] - Commandline class shell injection vulnerabilities
* [MSHARED-416] - Odd number of quotes in command-line fails
* [MSHARED-431] - # (Hash-Sign) should trigger quoting in BourneShell.java
* [MSHARED-681] - Maven-Shared: Java7Support silently fails
overwriting symlinks
* [MSHARED-749] - Commandline does not thrown CommandLineException
when uneven number of quotation marks used
* [MSHARED-750] - Unbalanced quotes in command with escaped double
quotation mark

** Improvement
* [MSHARED-684] - Upgrade parent to 31
* [MSHARED-748] - Upgrade maven-shared-parent to 32
* [MSHARED-826] - Require Java 7
* [MSHARED-879] - make build Reproducible
* [MSHARED-881] - try with resources in FileUtils

Enjoy,

-The Apache Maven team

[RESULT] [VOTE] Release Apache Maven Shared Utils version 3.3.3

[Dennis Lundberg]

Hi,

The vote has passed with the following result:

+1 : Dennis Lundberg, Hervé Boutemy, Michael Osipov

PMC quorum:  Dennis Lundberg, Hervé Boutemy, Michael Osipov

I will promote the artifacts to the central repo.

--
Dennis Lundberg


Den fre 24 juli 2020 kl 16:08 skrev Dennis Lundberg :

> Hi,
>
> We solved 12 
> issues:https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12342756=Text=12317922=Create_token=A5KQ-2QAV-T4JA-FDED_7bf996098e890abc72bf3628a70b9090574f431d_lin
>
> There are still a couple of issues left in 
> JIRA:https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-shared-utils%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging 
> repo:https://repository.apache.org/content/repositories/maven-1598/https://repository.apache.org/service/local/repositories/maven-1598/content/org/apache/maven/shared/maven-shared-utils/3.3.3/maven-shared-utils-3.3.3-source-release.zip
>
> Source release checksum(s):
>
> maven-shared-utils-3.3.3-source-release.zip sha512: 
> 6085d3bb3d065efaca7ed43f7342c2b71c624235ff38cd1410a06a4c915e39a13cb00e65e8c0cd7203dc5b2d1deeb392eaab2aa0a43bfadb7c9d4286a2b473bc
>
> Staging 
> site:https://maven.apache.org/components/shared-archives/maven-shared-utils-LATEST/
>
> Guide to testing staged 
> releases:https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> As some of you might have noticed we ended up with version 3.3.3 instead
> of the planned 3.3.1. I had some issues with the release process and burned
> 2 releases. I will address that in a JIRA issue shortly. Please let me know
> if I have missed anything.
>
> --
> Dennis Lundberg
>

Re: [VOTE] Release Apache Maven Shared Utils version 3.3.3

[Dennis Lundberg]

Hi,

Do we have one more vote, so that we can get this release out the door?

--
Dennis Lundberg


Den fre 24 juli 2020 kl 16:08 skrev Dennis Lundberg :

> Hi,
>
> We solved 12 
> issues:https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12342756=Text=12317922=Create_token=A5KQ-2QAV-T4JA-FDED_7bf996098e890abc72bf3628a70b9090574f431d_lin
>
> There are still a couple of issues left in 
> JIRA:https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-shared-utils%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging 
> repo:https://repository.apache.org/content/repositories/maven-1598/https://repository.apache.org/service/local/repositories/maven-1598/content/org/apache/maven/shared/maven-shared-utils/3.3.3/maven-shared-utils-3.3.3-source-release.zip
>
> Source release checksum(s):
>
> maven-shared-utils-3.3.3-source-release.zip sha512: 
> 6085d3bb3d065efaca7ed43f7342c2b71c624235ff38cd1410a06a4c915e39a13cb00e65e8c0cd7203dc5b2d1deeb392eaab2aa0a43bfadb7c9d4286a2b473bc
>
> Staging 
> site:https://maven.apache.org/components/shared-archives/maven-shared-utils-LATEST/
>
> Guide to testing staged 
> releases:https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> As some of you might have noticed we ended up with version 3.3.3 instead
> of the planned 3.3.1. I had some issues with the release process and burned
> 2 releases. I will address that in a JIRA issue shortly. Please let me know
> if I have missed anything.
>
> --
> Dennis Lundberg
>

Re: [VOTE] Release Apache Maven Shared Utils version 3.3.3

[Dennis Lundberg]

Hi,

Thanks for the link Hervé. That is an interesting initiative, I was not
aware of it.

Please write down your opinion on toolchains in the JIRA issue I created,
to establish new and updated instructions for our release build process
https://issues.apache.org/jira/browse/MNGSITE-419
I'd like for us to decide whether it is OK to build components, that
require Java 7, using Java 8 during a release or not.

There is already a step in our release instructions that covers checking
Javadoc. You should build the site with reporting turned on. That's what I
did and that's when I realized that the Javadoc for the components was not
compatible with Java 8. So it was detected before I cut the release. This
and the fact that the component requires Java 7 made me decide to use
toolchains for the build.

--
Dennis Lundberg


Den lör 1 aug. 2020 kl 08:28 skrev Hervé BOUTEMY :

> ok, I see: it will be tricky to reproduce...
> I fear I won't be able to publish to "Reproducible Central"
> https://github.com/jvm-repo-rebuild/reproducible-central
>
> for future releases, I think we should avoid such toolchain usage
> It means that before doing a release, checking if javadoc can be built
> should also be done, to avoid discovering issues during the release
>
> Regards,
>
> Hervé
>
> Le vendredi 31 juillet 2020, 08:42:26 CEST Dennis Lundberg a écrit :
> > Thanks Hervé,
> >
> > The build was done using AdoptOpenJdk 8 update 242, but using toolchains.
> > Failed Javadoc was one of the reasons for using toolchains, there were
> just
> > soo many errors. The toolchain itself used Java 7 update 79 from Oracle,
> so
> > the bytecode should be different if you don't use toolchains.
> >
> > You can see more details about my build process and problems in this JIRA
> > issue:
> > https://issues.apache.org/jira/browse/MNGSITE-419
> >
> > --
> > Dennis Lundberg
> >
> > Den tors 30 juli 2020 kl 22:36 skrev Hervé BOUTEMY <
> herve.bout...@free.fr>:
> > > +1
> > >
> > > trying to check reproducible builds, found that reference build was
> done
> > > with
> > > JDK 8 on Windows
> > > But I got 2 issues to reproduce:
> > > 1. javadoc fails with JDK 8
> > > 2. your bytecode is different from mine
> > >
> > > what detailed distribution of JDK did you use, please? Mine is
> > > AdoptOpenJDK
> > > 1.8.0_202
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le vendredi 24 juillet 2020, 16:08:10 CEST Dennis Lundberg a écrit :
> > > > Hi,
> > > >
> > > > We solved 12
> > >
> > > > issues:
> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12342
> > >
> > >
> 756=Text=12317922=Create_token=A5KQ-2QAV-T4
> > > JA>
> > > > -FDED_7bf996098e890abc72bf3628a70b9090574f431d_lin
> > > >
> > > > There are still a couple of issues left in
> > >
> > > > JIRA:
> > >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AN
> > >
> > >
> D%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-shared-u
> > > ti>
> > > > ls%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
> > > >
> > > > Staging
> > >
> > > > repo:
> > > https://repository.apache.org/content/repositories/maven-1598/https://
> > >
> > >
> repository.apache.org/service/local/repositories/maven-1598/content/org/ap
> > > ac
> > >
> > >
> he/maven/shared/maven-shared-utils/3.3.3/maven-shared-utils-3.3.3-source-r
> > > el>
> > > > ease.zip
> > > >
> > > > Source release checksum(s):
> > >
> > > > maven-shared-utils-3.3.3-source-release.zip sha512:
> > >
> 6085d3bb3d065efaca7ed43f7342c2b71c624235ff38cd1410a06a4c915e39a13cb00e65e8
> > > c0>
> > > > cd7203dc5b2d1deeb392eaab2aa0a43bfadb7c9d4286a2b473bc
> > > >
> > > > Staging
> > >
> > > > site:
> > > https://maven.apache.org/components/shared-archives/maven-shared-utils
> > >
> > > > -LATEST/
> > > >
> > > > Guide to testing staged
> > >
> > > > releases:
> > > https://maven.apache.org/guides/development/guide-testing-releases.
> > >
> > > > html
> > > >
> > > > Vote open for at least 72 hours.
> > > >
> > > > [ ] +1
> > > > [ ] +0
> > > > [ ] -1
> > > >
> > > > As some of you might have noticed we ended up with version 3.3.3
> instead
> > >
> > > of
> > >
> > > > the planned 3.3.1. I had some issues with the release process and
> burned
> > >
> > > 2
> > >
> > > > releases. I will address that in a JIRA issue shortly. Please let me
> > > > know
> > > > if I have missed anything.
> > > >
> > > > --
> > > > 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 Shared Utils version 3.3.3

[Dennis Lundberg]

Thanks Hervé,

The build was done using AdoptOpenJdk 8 update 242, but using toolchains.
Failed Javadoc was one of the reasons for using toolchains, there were just
soo many errors. The toolchain itself used Java 7 update 79 from Oracle, so
the bytecode should be different if you don't use toolchains.

You can see more details about my build process and problems in this JIRA
issue:
https://issues.apache.org/jira/browse/MNGSITE-419

--
Dennis Lundberg


Den tors 30 juli 2020 kl 22:36 skrev Hervé BOUTEMY :

> +1
>
> trying to check reproducible builds, found that reference build was done
> with
> JDK 8 on Windows
> But I got 2 issues to reproduce:
> 1. javadoc fails with JDK 8
> 2. your bytecode is different from mine
>
> what detailed distribution of JDK did you use, please? Mine is
> AdoptOpenJDK
> 1.8.0_202
>
> Regards,
>
> Hervé
>
> Le vendredi 24 juillet 2020, 16:08:10 CEST Dennis Lundberg a écrit :
> > Hi,
> >
> > We solved 12
> > issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12342
> >
> 756=Text=12317922=Create_token=A5KQ-2QAV-T4JA
> > -FDED_7bf996098e890abc72bf3628a70b9090574f431d_lin
> >
> > There are still a couple of issues left in
> > JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AN
> >
> D%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-shared-uti
> > ls%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
> >
> > Staging
> > repo:
> https://repository.apache.org/content/repositories/maven-1598/https://
> >
> repository.apache.org/service/local/repositories/maven-1598/content/org/apac
> >
> he/maven/shared/maven-shared-utils/3.3.3/maven-shared-utils-3.3.3-source-rel
> > ease.zip
> >
> > Source release checksum(s):
> >
> > maven-shared-utils-3.3.3-source-release.zip sha512:
> >
> 6085d3bb3d065efaca7ed43f7342c2b71c624235ff38cd1410a06a4c915e39a13cb00e65e8c0
> > cd7203dc5b2d1deeb392eaab2aa0a43bfadb7c9d4286a2b473bc
> >
> > Staging
> > site:
> https://maven.apache.org/components/shared-archives/maven-shared-utils
> > -LATEST/
> >
> > Guide to testing staged
> > releases:
> https://maven.apache.org/guides/development/guide-testing-releases.
> > html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > As some of you might have noticed we ended up with version 3.3.3 instead
> of
> > the planned 3.3.1. I had some issues with the release process and burned
> 2
> > releases. I will address that in a JIRA issue shortly. Please let me know
> > if I have missed anything.
> >
> > --
> > Dennis Lundberg
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Shared Utils version 3.3.3

[Dennis Lundberg]

+1 from me,

Those interested in the improvement of the release process docs are welcome
to discuss it in JIRA:
https://issues.apache.org/jira/browse/MNGSITE-419

Dennis Lundberg


Den fre 24 juli 2020 kl 16:08 skrev Dennis Lundberg :

> Hi,
>
> We solved 12 
> issues:https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12342756=Text=12317922=Create_token=A5KQ-2QAV-T4JA-FDED_7bf996098e890abc72bf3628a70b9090574f431d_lin
>
> There are still a couple of issues left in 
> JIRA:https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-shared-utils%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging 
> repo:https://repository.apache.org/content/repositories/maven-1598/https://repository.apache.org/service/local/repositories/maven-1598/content/org/apache/maven/shared/maven-shared-utils/3.3.3/maven-shared-utils-3.3.3-source-release.zip
>
> Source release checksum(s):
>
> maven-shared-utils-3.3.3-source-release.zip sha512: 
> 6085d3bb3d065efaca7ed43f7342c2b71c624235ff38cd1410a06a4c915e39a13cb00e65e8c0cd7203dc5b2d1deeb392eaab2aa0a43bfadb7c9d4286a2b473bc
>
> Staging 
> site:https://maven.apache.org/components/shared-archives/maven-shared-utils-LATEST/
>
> Guide to testing staged 
> releases:https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for at least 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> As some of you might have noticed we ended up with version 3.3.3 instead
> of the planned 3.3.1. I had some issues with the release process and burned
> 2 releases. I will address that in a JIRA issue shortly. Please let me know
> if I have missed anything.
>
> --
> Dennis Lundberg
>

[VOTE] Release Apache Maven Shared Utils version 3.3.3

[Dennis Lundberg]

Hi,

We solved 12 
issues:https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12342756=Text=12317922=Create_token=A5KQ-2QAV-T4JA-FDED_7bf996098e890abc72bf3628a70b9090574f431d_lin

There are still a couple of issues left in
JIRA:https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-shared-utils%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

Staging 
repo:https://repository.apache.org/content/repositories/maven-1598/https://repository.apache.org/service/local/repositories/maven-1598/content/org/apache/maven/shared/maven-shared-utils/3.3.3/maven-shared-utils-3.3.3-source-release.zip

Source release checksum(s):

maven-shared-utils-3.3.3-source-release.zip sha512:
6085d3bb3d065efaca7ed43f7342c2b71c624235ff38cd1410a06a4c915e39a13cb00e65e8c0cd7203dc5b2d1deeb392eaab2aa0a43bfadb7c9d4286a2b473bc

Staging 
site:https://maven.apache.org/components/shared-archives/maven-shared-utils-LATEST/

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

Vote open for at least 72 hours.

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

As some of you might have noticed we ended up with version 3.3.3 instead of
the planned 3.3.1. I had some issues with the release process and burned 2
releases. I will address that in a JIRA issue shortly. Please let me know
if I have missed anything.

--
Dennis Lundberg

Second MNG-6964 and MNG-6967

[Dennis Lundberg]

Hi,

First up, I'm sorry. I made a commit to maven core on gitbox without
requesting a review first. Thanks to Sylwester for pointing that out. So
here comes a belated request for review.

MNG-6964 describes an edge case where rather unusual version numbers are
not sorted correctly. After investigating the code in maven-artifact I
found that to be true. If a qualifier (something that comes after a dash
'-') starts with "0." and it was being compared to a version without a
qualifier it was deemed to be equal. I changed so that instead of just
checking the first component of the qualifier it checks all of them looking
for any difference. Tests were added and all existing tests pass as well.

https://issues.apache.org/jira/browse/MNG-6964
https://github.com/apache/maven/commit/4f193b3fc26c2ccf2a1b7a34917faccedac1ea0e


When investigating this I found that the command line output from
maven-artifact could be a bit clearer. Also it doesn't match exactly what
is written in the documentation, leading people (myself included) to draw
the wrong conclusions. In MNG-6967 I describe this. The change is purely
cosmetic, but still important.

https://issues.apache.org/jira/browse/MNG-6967
https://github.com/apache/maven/commit/51c0399030dcb0b88080a7f9e50c3d09c6913dda


Thanks,
Dennis Lundberg

Preparing to release maven-filtering and maven-resource-plugin

[Dennis Lundberg]

Hi,

In preparation for a release of maven-filtering and maven-resources-plugin,
I've gone through the open issues in JIRA and closed issues that were
fixed. Here's what's left:

maven-filtering
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20AND%20component%20%3D%20maven-filtering%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

maven-resources-plugin
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOURCES%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC

MRESOURCES-254, looks like it's a works-as-designed.
MRESOURCES-263 will be handled during the release process.

Does anyone have the time and itch to work on any other outstanding issues
now? If so please raise your hand.

--
Dennis Lundberg

Re: Preparing to release maven-shared-utils

[Dennis Lundberg]

Thanks Elliotte,

Ping if I miss any PRs in GitHub, I'm not used to that workflow yet :)

--
Dennis Lundberg

Den mån 20 juli 2020 kl 14:59 skrev Elliotte Rusty Harold <
elh...@ibiblio.org>:

> MSHARED-860 is longterm work that requires several releases. 297 and
> 431 look done and I closed them. I sent you a couple of small PRs but
> there's nothing really blocking this release so far as I know.
>
>
> On Mon, Jul 20, 2020 at 9:28 AM Dennis Lundberg 
> wrote:
> >
> > Hi,
> >
> > In preparation for a release of maven-filtering we need a release of
> > maven-shared-util. I've gone through the currently open issues in JIRA
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20status%20%3D%20Open%20AND%20component%20%3D%20maven-shared-utils
> >
> > I've commented on MSHARED-297,  MSHARED-431 and MSHARED-860, which all
> > seem to be fixed. Looks to me that we just need to close the issues in
> JIRA.
> >
> > Does anyone have the time and itch to work on any of the other
> outstanding
> > issues now? If so please raise your hand.
> >
> > --
> > Dennis Lundberg
>
>
>
> --
> 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
>
>

Re: Which version should maven-shared-utils have?

[Dennis Lundberg]

Den mån 20 juli 2020 kl 14:55 skrev Elliotte Rusty Harold <
elh...@ibiblio.org>:

> On Mon, Jul 20, 2020 at 6:54 AM Dennis Lundberg 
> wrote:
> >
> > Hi,
> >
> > Even though the release of 3.3.0 might have been a failed one, there is a
> > tag in version control for it. Someone could have taken that code and
> built
> > the component themselves, and added it to their own local repository. We
> > could remove the tag from version control now, but apart from being bad
> > practice it would not solve that problem.
>
> That's unlikely and their problem if we did. We haven't yet released
> 3.3.0 and it should be the next release.
>

If you want the next release to be 3.3.0 then someone will have to delete
the tag for 3.3.0 from version control. I don't feel comfortable doing
that, since it might lead to problems down the road. But if someone else
steps up as release manager for maven-shared-utils I will leave the
decision in their hands.

/Dennis


> --
> 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
>
>

Preparing to release maven-shared-utils

[Dennis Lundberg]

Hi,

In preparation for a release of maven-filtering we need a release of
maven-shared-util. I've gone through the currently open issues in JIRA
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20status%20%3D%20Open%20AND%20component%20%3D%20maven-shared-utils

I've commented on MSHARED-297,  MSHARED-431 and MSHARED-860, which all
seem to be fixed. Looks to me that we just need to close the issues in JIRA.

Does anyone have the time and itch to work on any of the other outstanding
issues now? If so please raise your hand.

--
Dennis Lundberg

Re: Which version should maven-shared-utils have?

[Dennis Lundberg]

Hi,

Even though the release of 3.3.0 might have been a failed one, there is a
tag in version control for it. Someone could have taken that code and built
the component themselves, and added it to their own local repository. We
could remove the tag from version control now, but apart from being bad
practice it would not solve that problem.

Besides that version numbers are cheap :)

--
Dennis Lundberg


Den fre 17 juli 2020 kl 20:23 skrev Elliotte Rusty Harold <
elh...@ibiblio.org>:

> I don't think that should be necessary. A failed 3.3.0 release should
> not use up the version number. I think there are instructions on the
> release page for unrolling a failed release, though I haven't had
> cause to use them myself.
>
> On Fri, Jul 17, 2020 at 5:53 AM Dennis Lundberg 
> wrote:
> >
> > Hi again,
> >
> > While I was digging in VCS history I discovered something odd with
> > maven-shared-utils. The current trunk/head in git has version
> > 3.3.0-SNAPSHOT.  But maven-shared-utils 3.3.0 was tagged during a release
> > in 2017...
> >
> https://github.com/apache/maven-shared-utils/tree/029ac4ec7b6636e8c1d3230799be624ba769e4cf/
> >
> > After that release, work was done and a patch version 3.2.1 was released,
> > setting the next version to 3.2.2-SNAPSHOT. However that was recently
> > changed to 3.3.0-SNAPSHOT in
> >
> https://github.com/apache/maven-shared-utils/commit/87da81f880be3ad32080e4d2176e280958aff2d7
> >
> > So, to avoid any potentially failed future release attempts I would like
> to
> > set the version to 3.4.0-SNAPSHOT, unless anyone objects.
> >
> > Someone who has worked on this component should have a look in JIRA, and
> > decide whether to mark the Release maven-shared-utils-3.3.0 as Released.
> > https://issues.apache.org/jira/projects/MSHARED/versions/12342756
> >
> > --
> > Dennis Lundberg
>
>
>
> --
> 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
>
>

Re: Does maven-filtering really require maven-shared-utils 3.3.0-SNAPSHOT?

[Dennis Lundberg]

Den fre 17 juli 2020 kl 13:56 skrev Robert Oxspring :

>
> > On 17 Jul 2020, at 10:42, Dennis Lundberg  wrote:
> >
> > Hi,
> >
> > I'm checking the scope of releasing maven-resources-plugin. There is
> > currently a transitive dependency chain like this:
> > - maven-resources-plugin depends upon
> > - maven-filtering 3.2.0-SNAPSHOT depends upon
> > - maven-shared-utils 3.3.0-SNAPSHOT
> >
> > That last SNAPSHOT was added in
> >
> https://github.com/apache/maven-filtering/commit/17fe0c18929be13fb75b00d76628dc7146f85aec
> > but it does not seem related to the commit message or the other changes
> in
> > the commit. So I'm curious, does maven-filtering really need the latest
> > version of maven-shared-utils? The build with tests succeeds if I turn it
> > back to the latest stable version 3.2.1.
>
> The message of that commit doesn’t make much sense to me but the timing of
> the commit ties in with my recent work! I’d certainly love this chain of
> releases to happen as it would allow MRESOURCES-258 to be closed. I think
> MRESOURCES-236 is in the same position.
>
> maven-shared-utils was modified to fix the underlying issue:
> https://github.com/apache/maven-shared-utils/pull/28
>
> maven-filtering was modified to reuse the matching (but improved) methods
> in maven-shared-utils:
> https://github.com/apache/maven-filtering/pull/6
>
> I didn’t replicate tests for improved behaviour upstream in
> maven-resources-plugin, hence the maven-resources-plugin tests not
> breaking. I can replicate the tests upstream and prove them in the
> maven-resources-plugin context if you’d prefer?
>

I see no need to replicate tests in multiple components. I simply needed
guidance from someone involved in the maven-shared-utils code base.So
thanks for the input :)

> Note that there is also a pending pull request that does away with many,
> > but not all,  usages of maven-shared-utils classes in maven-filtering.
> I'd
> > like for that to be merged and included in the upcoming releases.
> > https://github.com/apache/maven-filtering/pull/13
>
> Is there an implication here that we’re trying to drop dependencies on
> maven-shared-utils?
>

I don't know. It has been a long time since I worked with the Maven code,
so I'm very rusty when it comes to what we do and don't do at this point in
time. When I looked at the pull request it looked good to me, apart from a
minor detail in a test. The changes I saw was replacing calls to
maven-shared-utils with calls to Apache Commons libraries. In my opinion
that is a good change, since the Commons libraries have been around for
ages and have excellent tests. We should not maintain code that does the
exact same things as they do. I do think that some of the code in
maven-shared-utils may somehow be related to the code in Apache Commons, as
in they share a common ancestor way back in time.

If so, I’m happy to revert https://github.com/apache/maven-filtering/pull/6
> and port the https://github.com/apache/maven-shared-utils/pull/28
> directly to maven-filtering. Let me know and I can tackle over the weekend!
> (would love to get this released!)
>

If you or someone else wants to see a release of maven-shared-utils we
should do it.

Thanks,
>
> Rob
>


Thanks,
Dennis

Which version should maven-shared-utils have?

[Dennis Lundberg]

Hi again,

While I was digging in VCS history I discovered something odd with
maven-shared-utils. The current trunk/head in git has version
3.3.0-SNAPSHOT.  But maven-shared-utils 3.3.0 was tagged during a release
in 2017...
https://github.com/apache/maven-shared-utils/tree/029ac4ec7b6636e8c1d3230799be624ba769e4cf/

After that release, work was done and a patch version 3.2.1 was released,
setting the next version to 3.2.2-SNAPSHOT. However that was recently
changed to 3.3.0-SNAPSHOT in
https://github.com/apache/maven-shared-utils/commit/87da81f880be3ad32080e4d2176e280958aff2d7

So, to avoid any potentially failed future release attempts I would like to
set the version to 3.4.0-SNAPSHOT, unless anyone objects.

Someone who has worked on this component should have a look in JIRA, and
decide whether to mark the Release maven-shared-utils-3.3.0 as Released.
https://issues.apache.org/jira/projects/MSHARED/versions/12342756

--
Dennis Lundberg

Does maven-filtering really require maven-shared-utils 3.3.0-SNAPSHOT?

[Dennis Lundberg]

Hi,

I'm checking the scope of releasing maven-resources-plugin. There is
currently a transitive dependency chain like this:
- maven-resources-plugin depends upon
- maven-filtering 3.2.0-SNAPSHOT depends upon
- maven-shared-utils 3.3.0-SNAPSHOT

That last SNAPSHOT was added in
https://github.com/apache/maven-filtering/commit/17fe0c18929be13fb75b00d76628dc7146f85aec
but it does not seem related to the commit message or the other changes in
the commit. So I'm curious, does maven-filtering really need the latest
version of maven-shared-utils? The build with tests succeeds if I turn it
back to the latest stable version 3.2.1.

Note that there is also a pending pull request that does away with many,
but not all,  usages of maven-shared-utils classes in maven-filtering. I'd
like for that to be merged and included in the upcoming releases.
https://github.com/apache/maven-filtering/pull/13

--
Dennis Lundberg

Re: Do we have a policy for minimum Maven version for plugins?

[Dennis Lundberg]

Thanks Anders,

I found the page you mentioned at
https://maven.apache.org/developers/compatibility-plan.html

I've read that and also the technical details wiki page at
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=155749857

The issue in question updates to Maven 3.1.0 dependencies so it can switch
to Eclipse Aether, which is one of the explicitly mentioned reasons in the
docs. I'll go ahead and process that issue.

Dennis Lundberg


Den fre 17 juli 2020 kl 09:13 skrev Anders Hammar :

> There's been some discussion regarding this lately and my take is that
> we've settled on that requiring Maven 3.1.0 is ok for plugins. In the same
> discussion I *think* we settled on that a Java 8 requirement is ok.
> What I don't think we all agreed on is if it's ok to bump the requirements
> without a real code need, or if there needs to be a need before we bump. So
> it's up to each dev to decide when working on a plugin.
>
> There should even be a (draft) page outlining this. Don't have the URL at
> hands right now though but it's in the list archive.
>
> /Anders
>
> On Fri, Jul 17, 2020 at 9:02 AM Dennis Lundberg 
> wrote:
>
> > Hi,
> >
> > Where do we currently stand when it comes to the minimum version of
> > Maven required by our plugins? Can a version 3.x Apache Maven plugin
> > require something newer than Maven 3.0?
> >
> > The reason I ask is this
> > https://issues.apache.org/jira/browse/MSHARED-936
> > which has the consequence that all plugins using maven-filtering will
> need
> > to bump their Maven prerequisite, if I understand correctly.
> >
> > --
> > Dennis Lundberg
> >
>

Re: Depending on snapshot versions at HEAD

[Dennis Lundberg]

Den fre 17 juli 2020 kl 08:55 skrev Olivier Lamy :

> On Fri, 17 Jul 2020 at 16:53, Dennis Lundberg 
> wrote:
>
> > Hi,
> >
> > Given that I've been gone for some time from this list things might have
> > changed. If that's the case I'm sure someone will correct me :)
> >
> > But it used to be the way to do things when you have a chain of related
> > components, which is quite common in Maven. If we take
> > maven-resouces-plugin, which I'm working on right now, it has a
> dependency
> > on maven-filtering which contains all the code for filtering resources.
> > That in turn depends on maven-shared-util, which is specified as a
> SNAPSHOT
> > in maven-filtering. When the time comes to make a release, all these
> > SNAPSHOT dependencies will need to be addressed. So you have a "release
> > train" where you will start with the component furthest down the
> dependency
> > tree, release that and then continue on with the next one until you reach
> > the top. In my example the order will be maven-shared-util,
> maven-filtering
> > and finally maven-resources-plugin.
> >
>
> to make life easy we already did release bulk in such case (which is
> perfectly acceptable)
>

Oh, that's good.
So you would just accumulate all the artifacts into one staging repo in
Nexus?

/Dennis


>
> >
> > Dennis Lundberg
> >
> >
> > Den tors 16 juli 2020 kl 17:04 skrev Elliotte Rusty Harold <
> > elh...@ibiblio.org>:
> >
> > > I happened to notice today that the maven-resources-plugin at HEAD in
> > > the repo (not the released version) depends on the latest SNAPSHOT of
> > > maven-filtering:
> > >
> > > https://github.com/apache/maven-resources-plugin/blob/master/pom.xml
> > >
> > > Is this generally OK? That is can we commit code to a repo that
> > > depends on an unreleased SNAPSHOT version of another plugin/library?
> > > If this is considered kosher, it would help unblock some work on the
> > > maven-dependency-plugin.
> > >
> > >
> > > --
> > > 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
> > >
> > >
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Do we have a policy for minimum Maven version for plugins?

[Dennis Lundberg]

Hi,

Where do we currently stand when it comes to the minimum version of
Maven required by our plugins? Can a version 3.x Apache Maven plugin
require something newer than Maven 3.0?

The reason I ask is this
https://issues.apache.org/jira/browse/MSHARED-936
which has the consequence that all plugins using maven-filtering will need
to bump their Maven prerequisite, if I understand correctly.

--
Dennis Lundberg

Re: Depending on snapshot versions at HEAD

[Dennis Lundberg]

Hi,

Given that I've been gone for some time from this list things might have
changed. If that's the case I'm sure someone will correct me :)

But it used to be the way to do things when you have a chain of related
components, which is quite common in Maven. If we take
maven-resouces-plugin, which I'm working on right now, it has a dependency
on maven-filtering which contains all the code for filtering resources.
That in turn depends on maven-shared-util, which is specified as a SNAPSHOT
in maven-filtering. When the time comes to make a release, all these
SNAPSHOT dependencies will need to be addressed. So you have a "release
train" where you will start with the component furthest down the dependency
tree, release that and then continue on with the next one until you reach
the top. In my example the order will be maven-shared-util, maven-filtering
and finally maven-resources-plugin.

Dennis Lundberg


Den tors 16 juli 2020 kl 17:04 skrev Elliotte Rusty Harold <
elh...@ibiblio.org>:

> I happened to notice today that the maven-resources-plugin at HEAD in
> the repo (not the released version) depends on the latest SNAPSHOT of
> maven-filtering:
>
> https://github.com/apache/maven-resources-plugin/blob/master/pom.xml
>
> Is this generally OK? That is can we commit code to a repo that
> depends on an unreleased SNAPSHOT version of another plugin/library?
> If this is considered kosher, it would help unblock some work on the
> maven-dependency-plugin.
>
>
> --
> 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
>
>

Re: Generating draft release notes for maven-dependency-analyzer 1.11.2

[Dennis Lundberg]

Hi,

Start by making sure you are logged in to JIRA. You can't access Releases
unless you are logged in.

Either click your way to "Releases" (use the boat on the left) or go to
this URL
https://issues.apache.org/jira/projects/MSHARED?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page=unreleased

Find the release you want and click on it.

Click on "Release Notes"

Click on Configure Release Notes and select text as the Style.

The URL I get seems to have the version parameter set to the numerical id
of the version rather than the name we have given it.

--
Dennis Lundberg


Den tors 16 juli 2020 kl 22:25 skrev Elliotte Rusty Harold <
elh...@ibiblio.org>:

> I'm trying to create some draft release notes for
> maven-dependency-analyzer 1.11.2. This is the URL I have:
>
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=MSHARED=maven-dependency-analyzer-1.11.2=Text
>
> However this gives me "The selected version does not exist".
>
> This one might be tricky because there's not a separate JIRA
> component, and in fact the issues are split between two components for
> different projects and separated by labels. Anyone know what the URL
> should be?
>
> --
> 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
>
>

Will be working on Maven Resource Plugin

[Dennis Lundberg]

Hello,

It's been quite a while since I wrote anything on this list. Priorities at
dayjob has meant very little time for Maven work for me. Now we have a
Maven-issue that we need fixed. So I just wanted to let you know that I
will be working on Maven Resource Plugin, more specifically
https://issues.apache.org/jira/browse/MRESOURCES-171
If you have any input on that issue please join me in JIRA to discuss it.

Are there any new things I need to know about, other than that code has
moved to gitbox?

It's good to be back,
Dennis Lundberg

Re: svn commit: r1734070 - /maven/site/trunk/content/apt/guides/mini/guide-using-toolchains.apt

[Dennis Lundberg]

Hi,

I've always used it as an update date. From a user/reader point of view
that is the most interesting thing to know.
Den 9 mar 2016 08:28 skrev "Hervé BOUTEMY" <herve.bout...@free.fr>:

> question to old Doxia developers: is date in title of a Doxia source file
> expected to be *creation* or *update* date
>
> since it seems we use this field inconsistently for these 2 purposes,
> depending on who and when does an update
>
> what is it intended to represent precisely?
> in apt format doc [1], there is documentation about the format but not
> about
> which date it is...
>
>
> Regards,
>
> Hervé
>
>
> [1] http://maven.apache.org/doxia/references/apt-format.html#Title
>
> Le mardi 8 mars 2016 13:06:31 denn...@apache.org a écrit :
> > Author: dennisl
> > Date: Tue Mar  8 13:06:31 2016
> > New Revision: 1734070
> >
> > URL: http://svn.apache.org/viewvc?rev=1734070=rev
> > Log:
> > Update links to ex-codehaus plugins which are now at mojohaus.
> >
> > Modified:
> > maven/site/trunk/content/apt/guides/mini/guide-using-toolchains.apt
> >
> > Modified:
> > maven/site/trunk/content/apt/guides/mini/guide-using-toolchains.apt URL:
> >
> http://svn.apache.org/viewvc/maven/site/trunk/content/apt/guides/mini/guide
> > -using-toolchains.apt?rev=1734070=1734069=1734070=diff
> >
> ===
> > === ---
> maven/site/trunk/content/apt/guides/mini/guide-using-toolchains.apt
> > (original) +++
> > maven/site/trunk/content/apt/guides/mini/guide-using-toolchains.apt Tue
> Mar
> >  8 13:06:31 2016 @@ -5,7 +5,7 @@
> >   Dennis Lundberg
> >   Karl Heinz Marbaise
> >   --
> > - 2015-06-12
> > + 2016-03-08
> >   --
> >
> >  ~~ Licensed to the Apache Software Foundation (ASF) under one
> > @@ -59,15 +59,15 @@ Guide to Using Toolchains
> >
> *-*
> >
> --+-+---
> > -+
> >  | jdk |
> >  | <<<{{{/plugins/maven-surefire-plugin/}maven-surefire-plugin}}>>>
> >  | | 2.5 | Apache Maven
> >
> *-*
> >
> --+-+---
> > -+ -| jdk |
> > <<<{{{
> http://mojo.codehaus.org/animal-sniffer-maven-plugin/}animal-sniffer->
> maven-plugin}}>>> | 1.3 | Codehaus Mojo +| jdk |
> > <<<{{{
> http://www.mojohaus.org/animal-sniffer/animal-sniffer-maven-plugin/}a
> > nimal-sniffer-maven-plugin}}>>> | 1.3   | Codehaus Mojo
> >
> *-*
> >
> --+-+---
> > -+ -| jdk |
> > <<<{{{
> http://mojo.codehaus.org/cassandra-maven-plugin/}cassandra-maven-plug
> > in}}>>>   | 0.7.0-1 | Codehaus Mojo +| jdk
>|
> > <<<{{{
> http://www.mojohaus.org/cassandra-maven-plugin/}cassandra-maven-plugi
> > n}}>>>| 0.7.0-1 | Codehaus Mojo
> >
> *-*
> >
> --+-+---
> > -+ -| jdk |
> > <<<{{{http://www.mojohaus.org/exec-maven-plugin/}exec-maven-plugin}}>>>
> > | 1.1.1   | Codehaus Mojo +| jdk
>  |
> > <<<{{{http://www.mojohaus.org/exec-maven-plugin/}exec-maven-plugin}}>>>
> >  | 1.1.1   | Codehaus Mojo
> >
> *-*
> >
> --+-+---
> > -+ -| jdk |
> > <<<{{{http://www.mojohaus.org/jdiff-maven-plugin/}jdiff-maven-plugin}
> }>>>
> > | 1.0-beta-1-SNAPSHOT | Codehaus Mojo +| jdk
>  |
> > <<<{{{http://www.mojohaus.org/jdiff-maven-plugin/}jdiff-maven-plugin}
> }>>>
> >  | 1.0-beta-1-SNAPSHOT | Codehaus Mojo
> >
> *-*
> >
> --+-

Re: [DISCUSS] MDEPLOY-205: MavenProject with only attachments must have packaging "pom"

[Dennis Lundberg]

+1
Den 11 jan 2016 22:37 skrev "Robert Scholte" :

> this might be the root cause:
>
> MINSTALL-41 [1]:
> I have a project wich I need to build only specifying a classifier (in
> detail: a war project which I need to build with different profiles to
> include different
>  configurations. So I set up different filters and the package produces
> different classified wars).
>
> So IMHO abuse of profiles, not a reason to support attachments without a
> main artifact when packaging is 'war'.
> Instead I would suggest extracting the configuration or if one *really*
> wants to include configuration: use overlays per environment.
>
> thanks,
> Robert
>
> [1] https://issues.apache.org/jira/browse/MINSTALL-41
>
> Op Sat, 09 Jan 2016 18:04:40 +0100 schreef Robert Scholte <
> rfscho...@apache.org>:
>
> Hi,
>>
>> I've created MDEPLOY-205: MavenProject with only attachments must have
>> packaging "pom"[1]
>>
>> If I apply such a change, tests written for MDEPLOY-45 and MDEPLOY-78
>> fail.
>>
>> [ERROR] The following builds failed:
>> [ERROR] *  mdeploy-45-test\pom.xml
>> [ERROR] *  no-main-artifact-1\pom.xml
>> [ERROR] *  no-main-artifact-2\pom.xml
>> [ERROR] *  no-main-artifact-snapshot\pom.xml
>>
>> Original titles:
>> MDEPLOY-45: Classifier not supported by deploy:deploy [2]
>> MDEPLOY-78: Deploy with classifier does not deploy pom [3]
>>
>> Both sound valid as long *as the packaging is pom*
>> For the hygiene of the repository if the packaging says jar there should
>> always an artifactId-version.jar
>>
>> Anyone wants to convince me that I'm wrong?
>>
>> thanks,
>> Robert
>>
>> [1] https://issues.apache.org/jira/browse/MDEPLOY-205
>> [2] https://issues.apache.org/jira/browse/MDEPLOY-45
>> [3] https://issues.apache.org/jira/browse/MDEPLOY-78
>>
>> -
>> 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: Log4j Warning

[Dennis Lundberg]

Hi,

The sometimes heated discussion in this thread shows that there are strong
opinions about logging implementation. That for me is a reason to not
bundle one by default.

Let us focus on making it as simple as possible for our end users to
configure which one they want to use.

I'm not familiar with the extension mechanism. What alternatives do we have
to configure this? Ideally without the user having to download and
installing anything manually - only configuration in some xml file
somewhere.
Den 8 jan 2016 13:38 skrev "Jason van Zyl" :

> Ralph,
>
> The simple fact of the matter is that Log4J2 appears to have little to no
> user traction at all. This suggests to me that the community forked into
> the next generation by way of Logback and Log4J2. The community appears to
> have gone in the direction of Logback. By a very large margin, at least for
> the time being. I just don’t see it as a valuable or practical choice to
> use Log4J2, maybe you don’t see Logback as a valuable or practical choice.
> That said I think what Tamas suggested is fair. We’ll get the extensions to
> work in some form and then it’s convenient for users to choose by
> configuration what they prefer. And it appears we’ll have three choices. I
> think it’s fine they are built in the core to ensure they work, but not
> distributed but deployed to Maven Central for optional use. I am perfectly
> fine with that.
>
> Reasonable?
>
> > On Jan 7, 2016, at 1:47 PM, Ralph Goers 
> wrote:
> >
> > He claims that Log4j 2 isn’t popular enough.  The real reason, as you
> probably know, is that Jason seriously dislikes me, although he would never
> actually say that as his reason.
> >
> > Ralph
> >
> >> On Jan 7, 2016, at 10:56 AM, Jason van Zyl  wrote:
> >>
> >>
> >>> On Jan 7, 2016, at 11:43 AM, Arnaud Héritier 
> wrote:
> >>>
> >>> No problem.
> >>> Let's do what you want (like always).
> >>
> >> Not that I want it, but that’s certainly never been the case. The
> project would most definitely look different if it were. If there is
> agreement on this I’ll be surprised. So...
> >>
> >> If we can make it such that the .mvn/extensions.xml mechanism work for
> logging that would be best but it won’t right now because Igor discovered
> in his journeys that SLF4J can only be initialized once. And by the time
> the extensions load it’s too late. If we can either adjust the CLI such
> that we delay the initialization until after extensions load and live with
> some STDOUT hackery, or ask the SLF4J folks if they can accommodate our
> case and have some lazy initialization or allowable mutation. Then it just
> doesn’t matter and anyone can cleanly use what they wish. Then we’ll likely
> have to figure out global user extensions but that’s ok.
> >>
> >>> I agree we are loosing our time.
> >>>
> >>> Have a good day.
> >>>
> >>>
> >>
> >> Thanks,
> >>
> >> Jason
> >>
> >> --
> >> Jason van Zyl
> >> Founder, Takari and Apache Maven
> >> http://twitter.com/jvanzyl
> >> http://twitter.com/takari_io
> >> -
> >>
> >> 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
> >>
> >>
> >
> >
> >
> > -
> > 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, Takari and Apache Maven
> http://twitter.com/jvanzyl
> http://twitter.com/takari_io
> -
>
> {script:nopre:"/Users/jvanzyl/signature/signature.sh"}
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Question concerning common code for plugins

[Dennis Lundberg]

Hi,

Looking at the list of affected plugins, they are all packaging plugins.
How about maven-shared-packaging?
Den 29 dec 2015 18:40 skrev "Karl Heinz Marbaise" :

> Hi,
>
> currently i have identified several code parts like:
>
> handling of classifier (validation), creation of jar file names (related
> to classifier), includes/excludes handling...may be i find more...
>
> which have identical implementations in in the following plugins (or could
> be replaced by common code instead of reimplementing it):
>
>
> maven-ejb-plugin, maven-jar-plugin, maven-source-plugin, maven-rar-plugin,
> maven-war-plugin, ...
>
>
> So the question is: Is there a good shared component where this kind of
> code belongs to?
>
> Based on the description i have read it does not fit to any of the
> existing components...But starting a new component ?
>
> WDYT ?
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven JAR Utilities version 1.2

[Dennis Lundberg]

If the next version requires Maven 3, then its version number should be
3.0.0
Den 3 jan 2016 12:53 skrev "Michael Osipov" :

> Am 2016-01-03 um 12:37 schrieb Hervé BOUTEMY:
>
>> the site uses old skin, because parent pom was not upgraded to 22: is this
>> intentional?
>>
>
> Yes, this is intentional. Parent 22 requires Java 1.6. I did not want to
> introduce that and wanted to avoid the properties again. Version 2.0 will
> jump on it and be Maven 3 only.
>
> Michael
>
> that does not cause any strong issue, just curiosity :)
>>
>> so here is my +1
>>
>> Regards,
>>
>> Hervé
>>
>> Le jeudi 31 décembre 2015 21:30:30 Michael Osipov a écrit :
>>
>>> Hi,
>>>
>>> We solved 5 issues:
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922
>>> rsion=12334441
>>>
>>> There are still a couple of issues left in JIRA:
>>>
>>> https://issues.apache.org/jira/issues/?jql=component%20%3D%20maven-shared-ja
>>>
>>> r%20AND%20project%20%3D%20MSHARED%20AND%20resolution%20%3D%20Unresolved%20OR
>>> DER%20BY%20priority%20DESC
>>>
>>> Staging repo:
>>> https://repository.apache.org/content/repositories/maven-1242/
>>>
>>> https://repository.apache.org/content/repositories/maven-1242/org/apache/mav
>>> en/shared/maven-shared-jar/1.2/maven-shared-jar-1.2-source-release.zip
>>>
>>> Source release checksum(s):
>>> maven-shared-jar-1.2-source-release.zip sha1:
>>> 0fce6592e9ffc2d31b3ad9e59d6a488af31f78ac
>>>
>>> Staging site:
>>> https://maven.apache.org/shared-archives/maven-shared-jar-LATEST/
>>>
>>> Guide to testing staged releases:
>>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>>
>>> Vote open for 72 hours.
>>>
>>> [ ] +1
>>> [ ] +0
>>> [ ] -1
>>>
>>> -
>>> 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] Retire Maven Application Skin, Maven Classic Skin, Maven Stylus Skin

[Dennis Lundberg]

+1 from me

2015-12-24 23:34 GMT+01:00 Michael Osipov <1983-01...@gmx.net>:
> Hi,
>
> as previously suggested, it makes sense to retire those skins because
> they haven't been updated for a long time and we don't have the resources
> to maintain them properly [1].
>
> Last releases:
> Maven Application Skin: 2012-01-18
> Maven Classic Skin: 2012-01-18
> Maven Stylus Skin: 2012-07-30
>
> I therefore propose that we retire these skins.
>
> If this vote is successful I will make one final release of the skin, making
> it clear on the skin site that it has been retired. After that the source code
> will be moved into the "retired" area in our Subversion repository.
>
> The process for retiring a skin is described here:
> http://maven.apache.org/developers/retirement-plan-plugins.html
> (Though these aren't plugins, the process is universal)
>
> The vote is open for 72 hours.
>
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...
>
> I would ask kindly those who have already cast their vote to revote to make it
> "official".
>
> [1] 
> http://mail-archives.apache.org/mod_mbox/maven-dev/201512.mbox/%3Ctrinity-8ab6577c-ab69-4f9f-86e6-533e0b309a94-1450902628141%403capp-gmx-bs54%3E
>
> Michael
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-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

[RESULT] [VOTE] Release Apache Maven PMD Plugin version 3.6

[Dennis Lundberg]

Hi,

The vote has passed with the following result:

+1 : Karl Heinz Marbaise, Tibor Digana, Dennis Lundberg, Andreas
Gudian, Hervé Boutemy

PMC quorum: Karl Heinz Marbaise, Tibor Digana, Dennis Lundberg,
Andreas Gudian, Hervé Boutemy

I will promote the artifacts to the central repo.


2015-12-13 22:20 GMT+01:00 Dennis Lundberg <denn...@apache.org>:
> Hi,
>
> We solved 4 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317621=12332973
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317621%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1237/
> https://repository.apache.org/content/repositories/maven-1237/org/apache/maven/plugins/maven-pmd-plugin/3.6/maven-pmd-plugin-3.6-source-release.zip
>
> Source release checksum(s):
> [NAME-OF]-source-release.zip sha1: 2a8528d699898612ebbc036a1d4128c30235ce29
>
> Staging site:
> http://maven.apache.org/plugins-archives/maven-pmd-plugin-LATEST/
>
> 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



-- 
Dennis Lundberg

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

[ANN] Apache Maven PMD Plugin 3.6 Released

[Dennis Lundberg]

The Maven team is pleased to announce the release of the Apache Maven PMD 
Plugin, version 3.6

A Maven plugin for the PMD toolkit, that produces a report on both code rule 
violations and detected copy and paste
fragments,
as well as being able to fail the build based on these metrics.

http://maven.apache.org/plugins/maven-pmd-plugin/

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


  org.apache.maven.plugins
  maven-pmd-plugin
  3.6



Release Notes - Apache Maven PMD Plugin - Version 3.6

Bug
* [MPMD-218] Update to PMD 5.3.5
* [MPMD-217] False positive UselessParentheses
* [MPMD-215] FieldDeclarationsShouldBeAtStartOfClass false positive
* [MPMD-186] Class names with slash are omitted from exclusions on pmd:check


Enjoy,

-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 Apache Maven PMD Plugin version 3.6

[Dennis Lundberg]

+1 from me
Den 13 dec 2015 22:20 skrev "Dennis Lundberg" <denn...@apache.org>:

> Hi,
>
> We solved 4 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317621=12332973
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317621%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1237/
>
> https://repository.apache.org/content/repositories/maven-1237/org/apache/maven/plugins/maven-pmd-plugin/3.6/maven-pmd-plugin-3.6-source-release.zip
>
> Source release checksum(s):
> [NAME-OF]-source-release.zip sha1: 2a8528d699898612ebbc036a1d4128c30235ce29
>
> Staging site:
> http://maven.apache.org/plugins-archives/maven-pmd-plugin-LATEST/
>
> 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
>

Re: [DISCUSS] Java version requirement for Mavan 3.4.x

[Dennis Lundberg]

Hi,

Sorry for coming in late to the discussion...

Personally I would prefer to stay on Java 7 for a bit longer. Java 9
looks like its going to be delayed for 6 months:
http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-December/003149.html

As always the opinion of those who work on the code matters more than
the opinion of us who don't though.


2015-11-30 22:18 GMT+01:00 Stephen Connolly <stephen.alan.conno...@gmail.com>:
> Picking up from
> http://mail-archives.apache.org/mod_mbox/maven-dev/201511.mbox/%3CCA%2BnPnMyjogmqRweYbxLuULLB9ve2P6MPcQuH%2BPkxcNn-oN4GPg%40mail.gmail.com%3E
> (and my follow up to that but archive.apache.org is being a tad slow)
>
> Here is our policy:
>
> The development line of Maven core should require a minimum JRE version
>> that is no older than 18 months after the end of Oracle's public updates
>> for that JRE version at the time that the first version of the development
>> line was released, but may require a higher minimum JRE version if other
>> requirements dictate a higher JRE version
>
>
> (Source:
> https://cwiki.apache.org/confluence/display/MAVEN/Version+number+policy)
>
> OK, so it's a draft policy... but we've all been silent on the draft, so
> lazy consensus!
>
> Now in http://www.oracle.com/technetwork/java/javase/eol-135779.html they
> state:
>
> after April 2015, Oracle will not post further updates of Java SE 7 to its
>> public download sites
>
>
> So per our (draft) version number policy, we can keep Java 7 as the
> baseline :-( or we can choose to upgrade code to Java 8 (because we want to
> use lambdas... there's a requirement)
>
>
> So assuming we bump the master branch of Maven core to 3.4.0, what Java
> version do we want to use as the baseline?
>
> There are thankfully only two options:
>
> Java 7
>   + Not actually changing things
>   + May make it easier to drive adoption
>   - Still can't use newer language features in core
>   - Java 7 is EOL and it may get harder for developers to source JDKs to
> test and develop against
>
> Java 8
>   + We're not as old hat any more
>   + We can use lambdas
>   + We can use Nashorn (may make integrating with Node easier... certainly
> could make integrating with JavaScript tooling easier)
>   + EOL for Java 8 is at least Sep 2017 (and may be later)
>   - May be harder to drive adoption in shops that have issues upgrading
> Java (but toolchains and they likely wouldn't upgrade to 3.4.x anyway
> unless there are features dragging their change controlled heels over the
> line)
>
> So...
>
> Let's have a heated debate!
>
> -Stephen
>
> P.S.
>
>   I'm waiting for Chris to chime in about how IBM is still supporting Java
> 1.3 or something like that ;-)



-- 
Dennis Lundberg

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

[VOTE] Release Apache Maven PMD Plugin version 3.6

[Dennis Lundberg]

Hi,

We solved 4 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317621=12332973

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317621%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1237/
https://repository.apache.org/content/repositories/maven-1237/org/apache/maven/plugins/maven-pmd-plugin/3.6/maven-pmd-plugin-3.6-source-release.zip

Source release checksum(s):
[NAME-OF]-source-release.zip sha1: 2a8528d699898612ebbc036a1d4128c30235ce29

Staging site:
http://maven.apache.org/plugins-archives/maven-pmd-plugin-LATEST/

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

Re: maven-shared-utils

[Dennis Lundberg]

Hi,

IIRC maven-shared-utils uses a bunch of Apache Commons components
under the hood. The shading might be to not expose the commons
artifacts to the users of maven-shared-utils.

2015-10-01 22:17 GMT+02:00 Karl Heinz Marbaise <khmarba...@gmx.de>:
> Hi,
>
> just a question on understanding...
>
> Can someone explain me why maven-shared-utils produces a shaded artifact
> instead a usual jar file ?
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> 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

Re: Releasing the assembly plugin

[Dennis Lundberg]

>From what I have read we need to move all of maven-plugins to git in one go.
See the thread "Full migration to Git" for more info

2015-10-04 14:07 GMT+02:00 Benson Margulies <bimargul...@gmail.com>:
> OK, then, I want to move it to git first. Any objections?
>
>
> On Sun, Oct 4, 2015 at 7:27 AM, Karl Heinz Marbaise <khmarba...@gmx.de> wrote:
>> Hi,
>>
>>
>> On 10/4/15 10:58 AM, Robert Scholte wrote:
>>>
>>> Hmm, I see we tried to start with a 3.0.0 version, so not on the trunk.
>>>
>>> Assembly is far from ready as M3-only, so I suggest branching the latest
>>> tag.
>>
>> Yes that's the way to make a fix release...
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>>
>>>
>>> thanks,
>>> Robert
>>>
>>>
>>> Op Fri, 02 Oct 2015 13:26:18 +0200 schreef Benson Margulies
>>> <bimargul...@gmail.com>:
>>>
>>>> Could we do this? I'm waiting on the 'snappy' support.
>>>>
>>
>> -
>> 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

Re: maven-shared-utils

[Dennis Lundberg]

2015-10-04 22:14 GMT+02:00 Tibor Digana <tibor.dig...@googlemail.com>:
> Dennis, is there any issue with incompatibility between versions of Apache
> Commons?

Usually no. Commons takes compatibility issues seriously.

> If there is no such, then maybe normal dependency inheritance would be
> useful.

I didn't do any coding myself, but I recall it being discussed on the
mailing lists. I think Kristian was involved in it. Maybe he can chime
in?

> On Sun, Oct 4, 2015 at 10:03 PM, Dennis Lundberg <denn...@apache.org> wrote:
>
>> Hi,
>>
>> IIRC maven-shared-utils uses a bunch of Apache Commons components
>> under the hood. The shading might be to not expose the commons
>> artifacts to the users of maven-shared-utils.
>>
>> 2015-10-01 22:17 GMT+02:00 Karl Heinz Marbaise <khmarba...@gmx.de>:
>> > Hi,
>> >
>> > just a question on understanding...
>> >
>> > Can someone explain me why maven-shared-utils produces a shaded artifact
>> > instead a usual jar file ?
>> >
>> > Kind regards
>> > Karl Heinz Marbaise
>> >
>> > -----
>> > 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
>>
>>
>
>
> --
> Cheers
> Tibor



-- 
Dennis Lundberg

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

Re: [VOTE] Retire Maven Eclipse Plugin / Donation to Mojohaus

[Dennis Lundberg]

+1 to retire it

2015-10-04 11:18 GMT+02:00 Robert Scholte <rfscho...@apache.org>:
> Hi,
>
> during the latest upgrade of the plugin-parent I faced several issues with
> the maven-eclipse-plugin.
> It will take quite some time to fix these issues, but is it worth
> maintaining it here?
> Nowadays the Maven support for Eclipse is good and stable.
> The maven-eclipse-plugin has a lot of integration tests which should be
> rewritten, because it always launches a new Maven fork and it takes ages to
> complete. This simply blocks good continuous integration of the plugins.
> I know there are still some projects with can't use the Maven Integration of
> Eclipse and depend on this plugin, so the sources need to stay available for
> users so the can extend it for their own usage.
>
> I therefor propose that we retire maven-eclipse-plugin for the Apache Maven
> project and donate it to the Mojohaus project
>
> If this vote is successful I will make one final release of the plugin,
> making
> it clear on the plugin site that it has been retired. After that the source
> code
> will be moved into the "retired" area in Subversion.
>
> The process for retiring a plugin is described here:
> http://maven.apache.org/developers/retirement-plan-plugins.html
>
> The vote is open for 72 hours.
>
> [ ] +1 Yes, it's about time
> [ ] -1 No, because...
>
> -
> 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

Re: Maven Shared Components versioning...

[Dennis Lundberg]

+1

2015-09-30 11:12 GMT+02:00 Karl Heinz Marbaise <khmarba...@gmx.de>:
> Hi,
>
> i would like to suggest to upgrade all maven-shared components versions to
> 3.0.0 if they use Maven 3.0 dependencies and use JDK 1.6...
>
> (Honestly i have to admit that i already started with Maven Archiver in that
> way but coming to Maven Shared utils which is used by maven archiver to
> upgrade as well)...
>
>
> The reason for that is that we have a clear line of shared components which
> use Maven 3.0 dependencies and we a going in accordance with the plugins
> which should have the same version 3.0.0 if the are Maven 3.0 JDK 6 only
> ...based on our discusses roadmap
>
>
> Any objections ? Ideas / Improvements ?
>
> Kind regards
> Karl Heinz Marbaise
>
>
> -
> 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

Re: Releasing Maven Checkstyle Plugin

[Dennis Lundberg]

Hi Michael,

Thanks for pushing this release out!

I have assigned one issue to me, and scheduled it for 2.17. I'll fix
it this weekend.
https://issues.apache.org/jira/browse/MCHECKSTYLE-302


2015-09-30 22:39 GMT+02:00 Michael Osipov <micha...@apache.org>:
> Hi folks,
>
> I am planning to start the vote for version 2.7 [1] somehwere next week.
> Does anyone has something he would like fix for the next release?
>
> Michael
>
> [1]
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317223=12333072
>
> -
> 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

Re: Preventing unnecessary JIRA version managing

[Dennis Lundberg]

That's what I do in such case.
Den 22 jul 2015 17:56 skrev Stephen Connolly 
stephen.alan.conno...@gmail.com:

 Do we not just rename the version number?

 On 22 July 2015 at 15:55, Paul Benedict pbened...@apache.org wrote:

  All,
 
  I noticed that the next set of unresolved tickets are always assigned a
  version number. This leads to unnecessary maintenance when we have to
 burn
  a point release (i.e., you have to re-assign them to the next release) or
  it's just time for a new point release. There's really no point in having
  unresolved issues queued up. I kind of feel bad for Jason as he has to
 keep
  pushing them forward.
 
  I think we should just put all unresolved tickets in the 3.x backlog,
 and,
  as they are resolved, assign them an official version number.
 
  WDYT?
 
  Cheers,
  Paul
 

[RESULT] [VOTE] Release Apache Maven Checkstyle Plugin version 2.16

[Dennis Lundberg]

Hi,

The vote has passed with the following result:

+1 (binding): Hervé Boutemy, Dennis Lundberg, Karl Heinz Marbaise

I will promote the artifacts to the central repo.


On Mon, Jul 13, 2015 at 10:07 PM, Dennis Lundberg denn...@apache.org wrote:
 Hi,

 We solved 8 issues:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317223version=12330406

 Note that this version requires Java 7, due to Checkstyle requirements.

 There are still a couple of issues left in JIRA:
 https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317223%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

 During the release I discovered
 https://issues.apache.org/jira/browse/MCHECKSTYLE-302
 which was highlighted by an IT that was added for an issue that was
 fixed in this release. MCHECKSTYLE-302 is in itself though not due to
 any change in this release, so I have opted not to fix it now. This
 however does make the IT for MCHECHSTYLE-295 fail if you try to build
 with Maven 2.2.1.

 Staging repo:
 https://repository.apache.org/content/repositories/maven-1198/
 https://repository.apache.org/content/repositories/maven-1198/org/apache/maven/plugins/maven-checkstyle-plugin/2.16/maven-checkstyle-plugin-2.16-source-release.zip

 Source release checksum(s):
 maven-checkstyle-plugin-2.16-source-release.zip sha1:
 fc86ced46036ab5d00d341168ac234d895f48d80

 Staging site:
 http://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/

 Note that the staging site does not currently contain any reports, due
 to a circular dependency on the Checkstyle Plugin itself. This in
 combination with the fact that the configuration needs to be changed,
 but cannot be changed until after the release has been made. I will
 however publish a full site including the reports once the release is
 successful.

 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



-- 
Dennis Lundberg

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

[ANN] Apache Maven Checkstyle Plugin 2.16 Released

[Dennis Lundberg]

The Maven team is pleased to announce the release of the Apache Maven 
Checkstyle Plugin, version 2.16

Generates a report on violations of code style and optionally fails the build 
if violations are detected.

http://maven.apache.org/plugins/maven-checkstyle-plugin/

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

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-checkstyle-plugin/artifactId
  version2.16/version
/plugin


Release Notes - Apache Maven Checkstyle Plugin - Version 2.16

Bug
* [MCHECKSTYLE-295] Test resources are not included
* [MCHECKSTYLE-271] checkstyle plugin fails with default ruleset and checkstyle 
6.2

Improvement
* [MCHECKSTYLE-290] add a history table to show which version of Chesktyle is 
used by default in which version of m-checkstyle-p
* [MCHECKSTYLE-284] Remove config/sun_checks.xml and use the one built into 
Checkstyle 6.2+
* [MCHECKSTYLE-272] Upgrade to Checkstyle 6.2

Task
* [MCHECKSTYLE-285] Remove config/maven_checks.xml by removing the dependency 
on maven-shared-resources:2
* [MCHECKSTYLE-278] Require Java 7
* [MCHECKSTYLE-268] Add flag/option to use built-in Google style


Enjoy,

-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 Apache Maven Checkstyle Plugin version 2.16

[Dennis Lundberg]

Hi Karl-Heinz,

Thanks for testing. The issue with Maven 2.2.1 is known, if you read my
vote email. It is not a new issue, so I opted not to attempt to fix it in
this release.
Den 18 jul 2015 12:15 skrev Karl Heinz Marbaise khmarba...@gmx.de:

 Hi,

 i have tested with Maven 2.2.1 which unfortunately produces a failure...in
 MCHECKSTYLE-295 integration test...Created MCHECKSTYLE-303 to report it...

 and furthermore tested with the following Maven versions without any issue:

 Maven 3.0.5, 3.1.1, 3.2.5, 3.3.3

 Based on the above error i would say +0

 Kind regards
 Karl Heinz Marbaise


 On 7/13/15 10:07 PM, Dennis Lundberg wrote:

 Hi,

 We solved 8 issues:

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317223version=12330406

 Note that this version requires Java 7, due to Checkstyle requirements.

 There are still a couple of issues left in JIRA:

 https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317223%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

 During the release I discovered
 https://issues.apache.org/jira/browse/MCHECKSTYLE-302
 which was highlighted by an IT that was added for an issue that was
 fixed in this release. MCHECKSTYLE-302 is in itself though not due to
 any change in this release, so I have opted not to fix it now. This
 however does make the IT for MCHECHSTYLE-295 fail if you try to build
 with Maven 2.2.1.

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

 https://repository.apache.org/content/repositories/maven-1198/org/apache/maven/plugins/maven-checkstyle-plugin/2.16/maven-checkstyle-plugin-2.16-source-release.zip

 Source release checksum(s):
 maven-checkstyle-plugin-2.16-source-release.zip sha1:
 fc86ced46036ab5d00d341168ac234d895f48d80

 Staging site:
 http://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/

 Note that the staging site does not currently contain any reports, due
 to a circular dependency on the Checkstyle Plugin itself. This in
 combination with the fact that the configuration needs to be changed,
 but cannot be changed until after the release has been made. I will
 however publish a full site including the reports once the release is
 successful.

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

 Vote open for 72 hours.

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




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

Re: [VOTE] Release Apache Maven Checkstyle Plugin version 2.16

[Dennis Lundberg]

+1 from me
Den 13 jul 2015 22:07 skrev Dennis Lundberg denn...@apache.org:

 Hi,

 We solved 8 issues:

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317223version=12330406

 Note that this version requires Java 7, due to Checkstyle requirements.

 There are still a couple of issues left in JIRA:

 https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317223%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

 During the release I discovered
 https://issues.apache.org/jira/browse/MCHECKSTYLE-302
 which was highlighted by an IT that was added for an issue that was
 fixed in this release. MCHECKSTYLE-302 is in itself though not due to
 any change in this release, so I have opted not to fix it now. This
 however does make the IT for MCHECHSTYLE-295 fail if you try to build
 with Maven 2.2.1.

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

 https://repository.apache.org/content/repositories/maven-1198/org/apache/maven/plugins/maven-checkstyle-plugin/2.16/maven-checkstyle-plugin-2.16-source-release.zip

 Source release checksum(s):
 maven-checkstyle-plugin-2.16-source-release.zip sha1:
 fc86ced46036ab5d00d341168ac234d895f48d80

 Staging site:
 http://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/

 Note that the staging site does not currently contain any reports, due
 to a circular dependency on the Checkstyle Plugin itself. This in
 combination with the fact that the configuration needs to be changed,
 but cannot be changed until after the release has been made. I will
 however publish a full site including the reports once the release is
 successful.

 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

[VOTE] Release Apache Maven Checkstyle Plugin version 2.16

[Dennis Lundberg]

Hi,

We solved 8 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317223version=12330406

Note that this version requires Java 7, due to Checkstyle requirements.

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317223%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

During the release I discovered
https://issues.apache.org/jira/browse/MCHECKSTYLE-302
which was highlighted by an IT that was added for an issue that was
fixed in this release. MCHECKSTYLE-302 is in itself though not due to
any change in this release, so I have opted not to fix it now. This
however does make the IT for MCHECHSTYLE-295 fail if you try to build
with Maven 2.2.1.

Staging repo:
https://repository.apache.org/content/repositories/maven-1198/
https://repository.apache.org/content/repositories/maven-1198/org/apache/maven/plugins/maven-checkstyle-plugin/2.16/maven-checkstyle-plugin-2.16-source-release.zip

Source release checksum(s):
maven-checkstyle-plugin-2.16-source-release.zip sha1:
fc86ced46036ab5d00d341168ac234d895f48d80

Staging site:
http://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/

Note that the staging site does not currently contain any reports, due
to a circular dependency on the Checkstyle Plugin itself. This in
combination with the fact that the configuration needs to be changed,
but cannot be changed until after the release has been made. I will
however publish a full site including the reports once the release is
successful.

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

[ANN] Apache Maven PMD Plugin 3.5 Released

[Dennis Lundberg]

The Maven team is pleased to announce the release of the Apache Maven PMD 
Plugin, version 3.5

A Maven plugin for the PMD toolkit, that produces a report on both code rule 
violations and detected copy and paste
fragments,
as well as being able to fail the build based on these metrics.

http://maven.apache.org/plugins/maven-pmd-plugin/

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

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-pmd-plugin/artifactId
  version3.5/version
/plugin


Release Notes - Apache Maven PMD Plugin - Version 3.5

Bug
* [MPMD-208] Warning about deprecated Rule name when using rulesets/maven.xml
* [MPMD-205] Javascript violations won't fail the build

Improvement
* [MPMD-211] Upgrade plexus-resources from 1.0-alpha-7 to 1.1
* [MPMD-209] Upgrade to PMD 5.3.2
* [MPMD-206] Make the sourceDirectories configurable

New Feature
* [MPMD-207] Support Javascript and JSP for CPD


Enjoy,

-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 Apache Maven PMD Plugin version 3.5

[Dennis Lundberg]

+1 from me as well

Thank you Robert for finding that bug, I'll go ahead and file an issue
in JIRA for it. I agree with Hervé's evaluation though that it can be
fixed at a later point, as it is not something that was introduced
with the changes for the new version, but rather an old bug.

On Mon, Jul 6, 2015 at 7:34 AM, Hervé BOUTEMY herve.bout...@free.fr wrote:
 +1

 the bug reported by Robert should be fixed later

 Regards,

 Hervé

 Le vendredi 3 juillet 2015 08:46:25 Dennis Lundberg a écrit :
 Hi,

 We solved 6 issues:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317621ve
 rsion=12330969

 There are still a couple of issues left in JIRA:
 https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317621%20AND%20
 status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

 Staging repo:
 https://repository.apache.org/content/repositories/maven-1196/
 https://repository.apache.org/content/repositories/maven-1196/org/apache/mav
 en/plugins/maven-pmd-plugin/3.5/maven-pmd-plugin-3.5-source-release.zip

 Source release checksum(s):
 maven-pmd-plugin-3.5-source-release.zip sha1:
 958e9b805494f1d67c558b36dc223dbf84249b67

 Staging site:
 http://maven.apache.org/plugins-archives/maven-pmd-plugin-LATEST/

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

 Vote open for 72 hours.

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


 -
 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

[RESULT] [VOTE] Release Apache Maven PMD Plugin version 3.5

[Dennis Lundberg]

Hi,

The vote has passed with the following result:

+1 (binding): Jason van Zyl, Hervé Boutemy, Dennis Lundberg
-0 (binding): Robert Scholte

I will promote the artifacts to the central repo.


On Fri, Jul 3, 2015 at 8:46 AM, Dennis Lundberg denn...@apache.org wrote:
 Hi,

 We solved 6 issues:
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317621version=12330969

 There are still a couple of issues left in JIRA:
 https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317621%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

 Staging repo:
 https://repository.apache.org/content/repositories/maven-1196/
 https://repository.apache.org/content/repositories/maven-1196/org/apache/maven/plugins/maven-pmd-plugin/3.5/maven-pmd-plugin-3.5-source-release.zip

 Source release checksum(s):
 maven-pmd-plugin-3.5-source-release.zip sha1:
 958e9b805494f1d67c558b36dc223dbf84249b67

 Staging site:
 http://maven.apache.org/plugins-archives/maven-pmd-plugin-LATEST/

 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



-- 
Dennis Lundberg

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

[VOTE] Release Apache Maven PMD Plugin version 3.5

[Dennis Lundberg]

Hi,

We solved 6 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317621version=12330969

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317621%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1196/
https://repository.apache.org/content/repositories/maven-1196/org/apache/maven/plugins/maven-pmd-plugin/3.5/maven-pmd-plugin-3.5-source-release.zip

Source release checksum(s):
maven-pmd-plugin-3.5-source-release.zip sha1:
958e9b805494f1d67c558b36dc223dbf84249b67

Staging site:
http://maven.apache.org/plugins-archives/maven-pmd-plugin-LATEST/

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

Re: Unable to deploy to repository.apache.org using Java 6 any more

[Dennis Lundberg]

Thanks Bernd,

Unfortunately that property is only available in Java 7 and newer.

On Thu, Jul 2, 2015 at 11:05 PM, Bernd Eckenfels e...@zusammenkunft.net wrote:
 issues.apache.org (JIRA) has the same problem. The 4096bit DHE prime
 is not supported by Java (not even 1.8). It helps to disable DHE
 completely in jre/lib/security/java.security:

 jdk.tls.disabledAlgorithms=MD5, RC4, SSLv3, DSA, RSA keySize  2048, DHE

 Gruss
 Bernd


 Am
 Thu, 25 Jun 2015 20:35:46 +0200 schrieb Dennis Lundberg
 denn...@apache.org:

 Hi

 I finally sat down today to start the release of maven-pmd-plugin.
 Unfortunately I didn't get very far. When I try to mvn deploy the
 latest SNAPSHOT I get this error:

 [ERROR] Failed to execute goal
 org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy
 (default-deploy) on project maven-pmd-plugin: Failed to retrieve
 remote metadata
 org.apache.maven.plugins:maven-pmd-plugin:3.5-SNAPSHOT/maven-metadata.xml:
 Could not transfer metadata
 org.apache.maven.plugins:maven-pmd-plugin:3.5-SNAPSHOT/maven-metadata.xml
 from/to apache.snapshots.https
 (https://repository.apache.org/content/repositories/snapshots): peer
 not authenticated - [Help 1]

 First I checked my credentials and they looked good. After some
 googling I suspected an SSL certificate problem, so I checked the cert
 for repository.apache.org and found that it is relatively new. At
 least more recent than my last release... Then I tried SSLPoke [1]
 which is small and simple to use in such cases. With Java 6 I get this
 error:

 G:\java SSLPoke repository.apache.org 443
 javax.net.ssl.SSLException: java.lang.RuntimeException: Could not
 generate DH keypair
 at
 com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
 at
 com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1747)
 at
 com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1708)
 at
 com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1691)
 at
 com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1617)
 at
 com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:105)
 at
 com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:114)
 at SSLPoke.main(SSLPoke.java:31) Caused by:
 java.lang.RuntimeException: Could not generate DH keypair at
 com.sun.net.ssl.internal.ssl.DHCrypt.init(DHCrypt.java:114) at
 com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:559)
 at
 com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:186)
 at
 com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
 at
 com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
 at
 com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:943)
 at
 com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1188)
 at
 com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:654)
 at
 com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:100) 
 ...
 2 more Caused by: java.security.InvalidAlgorithmParameterException:
 Prime size must be multiple of 64, and can only range from 512 to
 1024 (inclusive) at
 com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..) at
 java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:627)
 at com.sun.net.ssl.internal.ssl.DHCrypt.init(DHCrypt.java:107) ...
 10 more

 and with Java 7 it works fine

 G:\java SSLPoke repository.apache.org 443
 Successfully connected

 One solution that usually works is to copy the cacerts file from a
 more recent Java version, so that you get the most recent list of CA
 certificates. I did that, and got the same error as before.

 So, where does that leave us? Well it seems that the certificate that
 has been deployed to repository.apache.org uses some kind of
 encryption technique that Java 6 cannot handle. See the stack trace
 above for the details, but my guess that the new cert uses a prime
 that is more than 1024 in size.

 AFAICT that means that anyone at the ASF wanting to to a release via
 repository.apahce.org must do so using Java 7. It would be great if
 someone could confirm and even greater if you could reject my
 findings...


 [1]
 https://confluence.atlassian.com/display/FISHKB/PKIX+Path+Building+Failed+-+Cannot+Set+Up+Trusted+Applications+To+SSL+Services



 -
 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

Unable to deploy to repository.apache.org using Java 6 any more

[Dennis Lundberg]

Hi

I finally sat down today to start the release of maven-pmd-plugin.
Unfortunately I didn't get very far. When I try to mvn deploy the
latest SNAPSHOT I get this error:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy
(default-deploy) on project maven-pmd-plugin: Failed to retrieve
remote metadata
org.apache.maven.plugins:maven-pmd-plugin:3.5-SNAPSHOT/maven-metadata.xml:
Could not transfer metadata
org.apache.maven.plugins:maven-pmd-plugin:3.5-SNAPSHOT/maven-metadata.xml
from/to apache.snapshots.https
(https://repository.apache.org/content/repositories/snapshots): peer
not authenticated - [Help 1]

First I checked my credentials and they looked good. After some
googling I suspected an SSL certificate problem, so I checked the cert
for repository.apache.org and found that it is relatively new. At
least more recent than my last release... Then I tried SSLPoke [1]
which is small and simple to use in such cases. With Java 6 I get this
error:

G:\java SSLPoke repository.apache.org 443
javax.net.ssl.SSLException: java.lang.RuntimeException: Could not
generate DH keypair
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:190)
at 
com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1747)
at 
com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1708)
at 
com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1691)
at 
com.sun.net.ssl.internal.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1617)
at 
com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:105)
at 
com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:114)
at SSLPoke.main(SSLPoke.java:31)
Caused by: java.lang.RuntimeException: Could not generate DH keypair
at com.sun.net.ssl.internal.ssl.DHCrypt.init(DHCrypt.java:114)
at 
com.sun.net.ssl.internal.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:559)
at 
com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:186)
at 
com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:593)
at 
com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:529)
at 
com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:943)
at 
com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1188)
at 
com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:654)
at 
com.sun.net.ssl.internal.ssl.AppOutputStream.write(AppOutputStream.java:100)
... 2 more
Caused by: java.security.InvalidAlgorithmParameterException: Prime
size must be multiple of 64, and can only range from 512 to 1024
(inclusive)
at com.sun.crypto.provider.DHKeyPairGenerator.initialize(DashoA13*..)
at 
java.security.KeyPairGenerator$Delegate.initialize(KeyPairGenerator.java:627)
at com.sun.net.ssl.internal.ssl.DHCrypt.init(DHCrypt.java:107)
... 10 more

and with Java 7 it works fine

G:\java SSLPoke repository.apache.org 443
Successfully connected

One solution that usually works is to copy the cacerts file from a
more recent Java version, so that you get the most recent list of CA
certificates. I did that, and got the same error as before.

So, where does that leave us? Well it seems that the certificate that
has been deployed to repository.apache.org uses some kind of
encryption technique that Java 6 cannot handle. See the stack trace
above for the details, but my guess that the new cert uses a prime
that is more than 1024 in size.

AFAICT that means that anyone at the ASF wanting to to a release via
repository.apahce.org must do so using Java 7. It would be great if
someone could confirm and even greater if you could reject my
findings...


[1] 
https://confluence.atlassian.com/display/FISHKB/PKIX+Path+Building+Failed+-+Cannot+Set+Up+Trusted+Applications+To+SSL+Services

-- 
Dennis Lundberg

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

Re: Jira codehaus redirect rules

[Dennis Lundberg]

I'm going to do something similar for Mojohaus now...

On Thu, Jun 4, 2015 at 8:43 AM, Olivier Lamy ol...@apache.org wrote:
 all done.

 Olivier

 On 4 June 2015 at 15:22, Hervé BOUTEMY herve.bout...@free.fr wrote:

 Hi,

 the full list is here: https://issues.apache.org/jira/browse/INFRA-9116

 Regards,

 Hervé

 Le mardi 2 juin 2015 22:02:35 Olivier Lamy a écrit :
  Hi,
  There is a redirect file for jira @ codehaus
 
  See
 
 https://github.com/codehaus/redirector/blob/master/includes/jira.codehaus.or
  g.inc
 
  ATM I only asked for MNG .
  I'm not sure if we have a full list?
 
  Cheers


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




 --
 Olivier Lamy
 http://twitter.com/olamy | http://linkedin.com/in/olamy



-- 
Dennis Lundberg

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

Re: Jira codehaus redirect rules

[Dennis Lundberg]

I've created a pull request for all Maven releated JIRA projects that
are now hosted at ASF:
https://github.com/codehaus/redirector/pull/8


On Thu, Jun 4, 2015 at 7:22 AM, Hervé BOUTEMY herve.bout...@free.fr wrote:
 Hi,

 the full list is here: https://issues.apache.org/jira/browse/INFRA-9116

 Regards,

 Hervé

 Le mardi 2 juin 2015 22:02:35 Olivier Lamy a écrit :
 Hi,
 There is a redirect file for jira @ codehaus

 See
 https://github.com/codehaus/redirector/blob/master/includes/jira.codehaus.or
 g.inc

 ATM I only asked for MNG .
 I'm not sure if we have a full list?

 Cheers


 -
 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

Re: Full migration to Git

[Dennis Lundberg]

On Mon, Jun 1, 2015 at 12:44 PM, Fred Cooke fred.co...@gmail.com wrote:
 Git can generate normal patches that you can simply apply and commit after
 testing.

I have tried both of the diff/patch formats available at GitHub, and
was not able to use any of them to patch my svn working copy.

 Or you could have a Git-SVN repo of your own setup, fetch the git
 commits, cherry pick hem into your SVN based tree, and dcommit them back
 up.

This was the solution I ended up with. The drawback is having to do
your own setup. Especially if it hasn't been documented.

 I use Git-SVN every day at work. It's either that or kill myself as SVN
 is wretched in every way.

 On Mon, Jun 1, 2015 at 9:52 PM, Dennis Lundberg denn...@apache.org wrote:

 I just want to clarify the reason for my struggles, for those who
 might not have read that thread:

 Someone set up a GitHub mirror for maven-plugins, but the canonical
 repo for maven-plugins is in Subversion. That makes it very difficult
 to use the native git tools to handle the contributions, beacuse data
 only ever travels from svn to git in this case IIUC. It also makes our
 contributors think that merging their pull requests is an easy task,
 because it would be if it was all git. When we don't respond to those
 pull requests they might loose interest and stop creating pull
 requests. So it really has nothing to do with technology and has
 everything to do with bad timing.


 On Fri, May 29, 2015 at 1:23 PM, Jason van Zyl ja...@takari.io wrote:
  I think it's time for a full migration of all our repositories to Git. I
 just see the email with Dennis struggling to merge a simple pull request
 and I think it's just time to switch completely. I think someone already
 started a list and we should just move through it. Personally I find SVN is
 just a huge hindrance at this point, especially for contributors.
 
  Thanks,
 
  Jason
 
  --
  Jason van Zyl
  Founder, Takari and Apache Maven
  http://twitter.com/jvanzyl
  http://twitter.com/takari_io
  -
 
  The most dangerous risk: spending your life not doing what you want on
 the bet you can buy yourself freedom to do it later.
 
   -- Randy Komisar
 
 
 
 
 
 
 
 
 
 
 
 
  -
  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





-- 
Dennis Lundberg

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

Re: Full migration to Git

[Dennis Lundberg]

I just want to clarify the reason for my struggles, for those who
might not have read that thread:

Someone set up a GitHub mirror for maven-plugins, but the canonical
repo for maven-plugins is in Subversion. That makes it very difficult
to use the native git tools to handle the contributions, beacuse data
only ever travels from svn to git in this case IIUC. It also makes our
contributors think that merging their pull requests is an easy task,
because it would be if it was all git. When we don't respond to those
pull requests they might loose interest and stop creating pull
requests. So it really has nothing to do with technology and has
everything to do with bad timing.


On Fri, May 29, 2015 at 1:23 PM, Jason van Zyl ja...@takari.io wrote:
 I think it's time for a full migration of all our repositories to Git. I just 
 see the email with Dennis struggling to merge a simple pull request and I 
 think it's just time to switch completely. I think someone already started a 
 list and we should just move through it. Personally I find SVN is just a huge 
 hindrance at this point, especially for contributors.

 Thanks,

 Jason

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

 The most dangerous risk: spending your life not doing what you want on the 
 bet you can buy yourself freedom to do it later.

  -- Randy Komisar












 -
 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

Re: How do I merge pull request on GitHub?

[Dennis Lundberg]

Thanks Stevo,

Interesting read for me that is less than fluent in git. In this case
I unfortunatelly cannot use those instructions as maven-plugins does
not have a git repo at Apache. It is versioned in svn and is probably
using some svn-git mirroring software to end up on the GitHub mirror
at
https://github.com/apache/maven-plugins

Do you know if the Apache GitHub repo is read-only? Would it be
possible to merge the PR at GitHub and get that commit propagated back
to our canonical svn repo?

If I understand your instructions correctly the modifications goes
something like this:
contributor branch@github -- git-wip-us.apache.org -- Apache GitHub mirror

What I think that I need is this:
contributor branch@github -- Apache GitHub mirror -- svn.apache.org


On Fri, May 29, 2015 at 9:38 AM, Stevo Slavić ssla...@gmail.com wrote:
 On Apache Mahout project we have nice docs on the workflow to merge or
 reject PRs submitted to github mirror. Maybe it works for you too.

 Kind regards,
 Stevo Slavic.

 On Fri, May 29, 2015 at 9:27 AM, Dennis Lundberg denn...@apache.org wrote:

 Hi

 I'm going through the issue list in JIRA for maven-pmd-plugin and want
 to apply some patches that have been submitted as pull requests to our
 GitHub mirror. But I cannot find a way to merge the pull requests. On
 the page of the pull request it says:

   This pull request can be automatically merged by project collaborators.
   Only those with write access to this repository can merge pull requests.

 Am I missing some permissions or am I just lacking Git(Hub) knowledge?
 My github id is dennisl. Here is an example:
 https://github.com/apache/maven-plugins/pull/48

 --
 Dennis Lundberg

 -
 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

How do I merge pull request on GitHub?

[Dennis Lundberg]

Hi

I'm going through the issue list in JIRA for maven-pmd-plugin and want
to apply some patches that have been submitted as pull requests to our
GitHub mirror. But I cannot find a way to merge the pull requests. On
the page of the pull request it says:

  This pull request can be automatically merged by project collaborators.
  Only those with write access to this repository can merge pull requests.

Am I missing some permissions or am I just lacking Git(Hub) knowledge?
My github id is dennisl. Here is an example:
https://github.com/apache/maven-plugins/pull/48

-- 
Dennis Lundberg

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

Re: How do I merge pull request on GitHub?

[Dennis Lundberg]

Thanks Tibor,

This will not work in my case, because maven-plugin does not have a
git repo at git-wip-us.apache.org.


On Fri, May 29, 2015 at 12:49 PM, Tibor Digana tibordig...@apache.org wrote:
 These are my commands for surefire plugin. Use your login and pmd project
 links instead.
 Suppose their branch is s2 and master is on git-wip-us-apache.org.
 If you want to push from master to master, freely avoid s2:master.
 You should have RSA key in your user home.

 $ git remote add apache
 https://git-wip-us.apache.org/repos/asf/maven-surefire.git
 $ git fetch apache
 $ git rebase apache/master
 $ git config remote.origin.url
 https://git-wip-us.apache.org/repos/asf/maven-surefire.git
 $ git push -u
 https://tibordig...@git-wip-us.apache.org/repos/asf/maven-surefire.git
 s2:master



 --
 View this message in context: 
 http://maven.40175.n5.nabble.com/How-do-I-merge-pull-request-on-GitHub-tp5836085p5836114.html
 Sent from the Maven Developers mailing list archive at Nabble.com.

 -
 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

Re: How do I merge pull request on GitHub?

[Dennis Lundberg]

Thanks again Tamas,

I have already tried that, but neither the patch nor diff would apply
cleanly to my svn working copy.

Trying another approach checking out from svn using SmartGit, which
keeps a local git repo of sources that come from a remote svn repo.
That way I was able to apply the patch in the format you suggested.
The first commit/push seems to have gone through OK. Now I'm waiting
to see if my closes apache/maven-plugins#NN text in the commit
message will close the GitHub pull request automatically. Does anyone
know the sync delay between svn.apache.org and the GitHub mirror?


On Fri, May 29, 2015 at 1:29 PM, Tamas Cservenak ta...@cservenak.net wrote:
 Sry, I sent the “resolved” URL, here is the real one:

 https://github.com/apache/maven-plugins/pull/48.diff


 --
 Thanks,
 ~t~

 On 29 May 2015 at 13:27:47, Tamas Cservenak (ta...@cservenak.net) wrote:

 Dennis,

 you can take PRs as patches from GH by appending “.patch” or “.diff” to PR 
 URL,
 here is your example:

 https://patch-diff.githubusercontent.com/raw/apache/maven-plugins/pull/48.diff

 Then, apply that patch “manually” to sources and then commit. Is a bit
 hassle but that’s all to it. Having all this in git would be way more simpler.

 HTH

 --
 Thanks,
 ~t~

 On 29 May 2015 at 11:00:59, Dennis Lundberg (denn...@apache.org) wrote:

 Thanks Stevo,

 Interesting read for me that is less than fluent in git. In this case
 I unfortunatelly cannot use those instructions as maven-plugins does
 not have a git repo at Apache. It is versioned in svn and is probably
 using some svn-git mirroring software to end up on the GitHub mirror
 at
 https://github.com/apache/maven-plugins

 Do you know if the Apache GitHub repo is read-only? Would it be
 possible to merge the PR at GitHub and get that commit propagated back
 to our canonical svn repo?

 If I understand your instructions correctly the modifications goes
 something like this:
 contributor branch@github -- git-wip-us.apache.org -- Apache GitHub mirror

 What I think that I need is this:
 contributor branch@github -- Apache GitHub mirror -- svn.apache.org


 On Fri, May 29, 2015 at 9:38 AM, Stevo Slavić ssla...@gmail.com wrote:
 On Apache Mahout project we have nice docs on the workflow to merge or
 reject PRs submitted to github mirror. Maybe it works for you too.

 Kind regards,
 Stevo Slavic.

 On Fri, May 29, 2015 at 9:27 AM, Dennis Lundberg denn...@apache.org wrote:

 Hi

 I'm going through the issue list in JIRA for maven-pmd-plugin and want
 to apply some patches that have been submitted as pull requests to our
 GitHub mirror. But I cannot find a way to merge the pull requests. On
 the page of the pull request it says:

 This pull request can be automatically merged by project collaborators.
 Only those with write access to this repository can merge pull requests.

 Am I missing some permissions or am I just lacking Git(Hub) knowledge?
 My github id is dennisl. Here is an example:
 https://github.com/apache/maven-plugins/pull/48

 --
 Dennis Lundberg

 -
 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




-- 
Dennis Lundberg

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

Re: How do I merge pull request on GitHub?

[Dennis Lundberg]

Thanks Olivier,

I found something similar here:
https://wiki.apache.org/general/GitAtApache

But those instructions doesn't include the clever handling of
pr-branches that you suggested.

On Fri, May 29, 2015 at 1:49 PM, Olivier Lamy ol...@apache.org wrote:
 something not complicated which is convenient with pr

 git clone https://github.com/apache/maven-plugins.git

 now you have to setup git-svn (see the script here:
 https://gist.github.com/olamy/836acac9a113c7830918)

 Now setup you git config to have all pr as branch
 in .git/config add the last line

 [remote origin]
 url = https://github.com/apache/maven-plugins.git
 fetch = +refs/heads/*:refs/remotes/origin/*
 fetch = +refs/pull/*/head:refs/remotes/origin/pr/*

 then git fetch origin
 now you can checkout locally all pr as a branch
 git checkout pr/52
 test etc (maybe commit some modification in the pr/branch)
 git checkout trunk (back to trunk)
 merge the pr: git merge pr/52
 now commit to svn: git svn dcommit







 On 29 May 2015 at 17:27, Dennis Lundberg denn...@apache.org wrote:

 Hi

 I'm going through the issue list in JIRA for maven-pmd-plugin and want
 to apply some patches that have been submitted as pull requests to our
 GitHub mirror. But I cannot find a way to merge the pull requests. On
 the page of the pull request it says:

   This pull request can be automatically merged by project collaborators.
   Only those with write access to this repository can merge pull requests.

 Am I missing some permissions or am I just lacking Git(Hub) knowledge?
 My github id is dennisl. Here is an example:
 https://github.com/apache/maven-plugins/pull/48

 --
 Dennis Lundberg

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




 --
 Olivier Lamy
 http://twitter.com/olamy | http://linkedin.com/in/olamy



-- 
Dennis Lundberg

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

Re: How do I merge pull request on GitHub?

[Dennis Lundberg]

My solution to use SmartGit seems to be working fine. Source code
changes are moving nicely from my local disk to svn, and then on to
the GitHub mirror. Pull requests in GitHub are closed automatically.

Thanks for the help!

On Fri, May 29, 2015 at 2:47 PM, Dennis Lundberg denn...@apache.org wrote:
 Thanks again Tamas,

 I have already tried that, but neither the patch nor diff would apply
 cleanly to my svn working copy.

 Trying another approach checking out from svn using SmartGit, which
 keeps a local git repo of sources that come from a remote svn repo.
 That way I was able to apply the patch in the format you suggested.
 The first commit/push seems to have gone through OK. Now I'm waiting
 to see if my closes apache/maven-plugins#NN text in the commit
 message will close the GitHub pull request automatically. Does anyone
 know the sync delay between svn.apache.org and the GitHub mirror?


 On Fri, May 29, 2015 at 1:29 PM, Tamas Cservenak ta...@cservenak.net wrote:
 Sry, I sent the “resolved” URL, here is the real one:

 https://github.com/apache/maven-plugins/pull/48.diff


 --
 Thanks,
 ~t~

 On 29 May 2015 at 13:27:47, Tamas Cservenak (ta...@cservenak.net) wrote:

 Dennis,

 you can take PRs as patches from GH by appending “.patch” or “.diff” to PR 
 URL,
 here is your example:

 https://patch-diff.githubusercontent.com/raw/apache/maven-plugins/pull/48.diff

 Then, apply that patch “manually” to sources and then commit. Is a bit
 hassle but that’s all to it. Having all this in git would be way more 
 simpler.

 HTH

 --
 Thanks,
 ~t~

 On 29 May 2015 at 11:00:59, Dennis Lundberg (denn...@apache.org) wrote:

 Thanks Stevo,

 Interesting read for me that is less than fluent in git. In this case
 I unfortunatelly cannot use those instructions as maven-plugins does
 not have a git repo at Apache. It is versioned in svn and is probably
 using some svn-git mirroring software to end up on the GitHub mirror
 at
 https://github.com/apache/maven-plugins

 Do you know if the Apache GitHub repo is read-only? Would it be
 possible to merge the PR at GitHub and get that commit propagated back
 to our canonical svn repo?

 If I understand your instructions correctly the modifications goes
 something like this:
 contributor branch@github -- git-wip-us.apache.org -- Apache GitHub mirror

 What I think that I need is this:
 contributor branch@github -- Apache GitHub mirror -- svn.apache.org


 On Fri, May 29, 2015 at 9:38 AM, Stevo Slavić ssla...@gmail.com wrote:
 On Apache Mahout project we have nice docs on the workflow to merge or
 reject PRs submitted to github mirror. Maybe it works for you too.

 Kind regards,
 Stevo Slavic.

 On Fri, May 29, 2015 at 9:27 AM, Dennis Lundberg denn...@apache.org wrote:

 Hi

 I'm going through the issue list in JIRA for maven-pmd-plugin and want
 to apply some patches that have been submitted as pull requests to our
 GitHub mirror. But I cannot find a way to merge the pull requests. On
 the page of the pull request it says:

 This pull request can be automatically merged by project collaborators.
 Only those with write access to this repository can merge pull requests.

 Am I missing some permissions or am I just lacking Git(Hub) knowledge?
 My github id is dennisl. Here is an example:
 https://github.com/apache/maven-plugins/pull/48

 --
 Dennis Lundberg

 -
 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




 --
 Dennis Lundberg



-- 
Dennis Lundberg

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

Re: 3.2.3 not available though http://archive.apache.org/dist/maven/binaries/?

[Dennis Lundberg]

Right, the future proof source for Maven distros should be the central
repo. Primarily because the coordinates will not change.
Den 23 maj 2015 18:53 skrev Hervé BOUTEMY herve.bout...@free.fr:

 notice that with Maven 4, in xxx monthes/years..., we probably will have
 another /dist/ directory, but distribution artifact coordinates in central
 should not change

 Regards,

 Hervé

 Le vendredi 22 mai 2015 15:05:13 Arnaud Héritier a écrit :
  Hi Dennis,
 
No I see no real issue of getting them from several sources.
I want just to be sure that we are agree for the long term to be sure
 to
  not have to update them too often
 
  Arnaud
 
  On Fri, May 22, 2015 at 2:16 PM, Dennis Lundberg denn...@apache.org
 wrote:
   Hi Arnaud,
  
   I stumbled upon that Jenkins issue last week, and had a quick look at
   the pull request available. From what I could tell, the proposed
   solution was to use the (legacy) ASF dist area *and* Central to get
   the best of both worlds. Do you see a problem having 2 data sources
   for the Jenkins crawler?
  
   On Fri, May 22, 2015 at 12:02 AM, Arnaud Héritier aherit...@gmail.com
 
  
   wrote:
Resurrecting this thread.
Having a standardised place to find all versions was a good thing
Because of the change jenkins doesn't propose anything  3.2.2
 because
it
is checking only in http://archive.apache.org/dist/maven/binaries/
And it doesn't see the content of https://dist.apache.org/repos/dist
/release/maven/maven-3/
Sadly no central isn't a better solution
* = 2.0.9 :
http://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/
*  2.0.9 : not available in central AFAIK (yes they are old but ..)
   
Before fixing the Jenkins Catalog (
https://issues.jenkins-ci.org/browse/INFRA-181) I would need to
 have our
feedback to have a long term solution if possible
   
Cheers
   
On Mon, Dec 29, 2014 at 8:48 AM, Jason van Zyl ja...@takari.io
 wrote:
Why do you need it there?
   
The way binaries are kept at Apache is inconsistent. How it evolved
over
time where things disappear from one place to another (official
distribution to archives) I don't find makes much sense but that's
 the
  
   way
  
it is. If you require a distribution in a standard place take it
 from
  
   Maven
  
Central. It will always be in the same place.
   
On Dec 29, 2014, at 12:51 AM, Milos Kleint mkle...@gmail.com
 wrote:
 Hello,

 for some reason 3.2.3 is not available in the archives, is that
   
intentional
   
 or something went wrong with the 3.2.5 release?

 Thanks

 Milos
   
Thanks,
   
Jason
   
--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
http://twitter.com/takari_io
-
   
What matters is not ideas, but the people who have them. Good people
can
fix bad ideas, but good ideas can't save bad people.
   
 -- Paul Graham
   
--
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier
  
   --
   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: 3.2.3 not available though http://archive.apache.org/dist/maven/binaries/ ?

[Dennis Lundberg]

Hi Arnaud,

I stumbled upon that Jenkins issue last week, and had a quick look at
the pull request available. From what I could tell, the proposed
solution was to use the (legacy) ASF dist area *and* Central to get
the best of both worlds. Do you see a problem having 2 data sources
for the Jenkins crawler?

On Fri, May 22, 2015 at 12:02 AM, Arnaud Héritier aherit...@gmail.com wrote:
 Resurrecting this thread.
 Having a standardised place to find all versions was a good thing
 Because of the change jenkins doesn't propose anything  3.2.2 because it
 is checking only in http://archive.apache.org/dist/maven/binaries/
 And it doesn't see the content of https://dist.apache.org/repos/dist
 /release/maven/maven-3/
 Sadly no central isn't a better solution
 * = 2.0.9 :
 http://repo.maven.apache.org/maven2/org/apache/maven/apache-maven/
 *  2.0.9 : not available in central AFAIK (yes they are old but ..)

 Before fixing the Jenkins Catalog (
 https://issues.jenkins-ci.org/browse/INFRA-181) I would need to have our
 feedback to have a long term solution if possible

 Cheers


 On Mon, Dec 29, 2014 at 8:48 AM, Jason van Zyl ja...@takari.io wrote:

 Why do you need it there?

 The way binaries are kept at Apache is inconsistent. How it evolved over
 time where things disappear from one place to another (official
 distribution to archives) I don't find makes much sense but that's the way
 it is. If you require a distribution in a standard place take it from Maven
 Central. It will always be in the same place.

 On Dec 29, 2014, at 12:51 AM, Milos Kleint mkle...@gmail.com wrote:

  Hello,
 
  for some reason 3.2.3 is not available in the archives, is that
 intentional
  or something went wrong with the 3.2.5 release?
 
  Thanks
 
  Milos

 Thanks,

 Jason

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

 What matters is not ideas, but the people who have them. Good people can
 fix bad ideas, but good ideas can't save bad people.

  -- Paul Graham












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



-- 
Dennis Lundberg

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

Feedback wanted on Checktyle plugin ruleset docs

[Dennis Lundberg]

Hi,

I'm trying to visualize which version of the Checkstyle plugin
includes which predefined rulesets. There's are 3 alternatives for you
to look at here:
https://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/config/index.html

Please let me know which alternative you think is the most easy to understand.

-- 
Dennis Lundberg

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

Re: Migrating to maven 3 deps

[Dennis Lundberg]

Not really deps related, but we should make sure that we use the
correct package names when upgrading plugins to require Maven 3. Many
plugins use org.apache.maven.plugin as the package name, but it should
be org.apache.maven.plugins (with an s at the end) to match our
groupId.

On Thu, Apr 30, 2015 at 10:43 PM, Robert Scholte rfscho...@apache.org wrote:
 Not that I'm aware of, but I can think of several steps:
 - compile/runtime should not depend on maven-compat (the
 plugin-testing-harness still requires it, so test-scope is still required,
 though)
 - consider testing with a Maven distribution without maven-compat
 - use the major release to do housekeeping: remove deprecated parameters,
 use direct M3 method calls instead of by reflection.

 I'm working on artifact/dependency related issues for the install, invoker
 and deploy plugins.
 I've created branches for these to give me enough time to fix this
 correctly.

 thanks,
 Robert

 Op Thu, 30 Apr 2015 22:29:18 +0200 schreef Kristian Rosenvold
 kristian.rosenv...@gmail.com:


 Do we have any wiki page describing the migration steps that would be
 recommended to move a plugin from 2.2.1 deps to 3.x deps ?

 I'm thinking *both* in terms of avoiding deprecations and other troubles
 that may arise ?

 Kristian


 -
 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

Problems with Jenkins builds of invoker and assembly plugins

[Dennis Lundberg]

Hi,

After doing some work on the Checkstyle Plugin today, I noticed that
several of our Jenkins jobs for plugins are failing. I looked into it
and found a couple of problems.

1. maven-invoker-plugin is added as a module in two different
profiles; java-6 and maven-3. The first one because it requires Java 6
and thee second one as a workaround for MNG-3814. The problem is that
the invoker plugin gets built if Java 6 OR Maven 3 is used. This fails
some of the Jenkins jobs. Is there a way to require Java 6 AND Maven 3
to activate a profile?

2. maven-assembly-plugin fails on Windows, and it fails for me locally
on Windows as well. This is due to *nix-style absolute path references
in outputDirectory in FileItemAssemblyPhaseTest. Not sure how to solve
this. In my own projects I simply changes from
outputDirectory//outputDirectory to
outputDirectory/outputDirectory, but I dare not change the tests.

-- 
Dennis Lundberg

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

[RESULT] [VOTE] Release Apache Maven Checkstyle Plugin version 2.15

[Dennis Lundberg]

Hi,

The vote has passed with the following result:

+1 (binding): Karl Heinz Marbaise, Dennis Lundberg, Jason van Zyl, Hervé Boutemy

I will promote the artifacts to the central repo.

Thanks to all the voters!


On Sun, Mar 15, 2015 at 8:14 PM, Dennis Lundberg denn...@apache.org wrote:
 Hi,

 We solved 6 issues:
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11127styleName=Htmlversion=20762

 There are still a couple of issues left in JIRA:
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11127status=1

 Staging repo:
 https://repository.apache.org/content/repositories/maven-1153/
 https://repository.apache.org/content/repositories/maven-1153/org/apache/maven/plugins/maven-checkstyle-plugin/2.15/maven-checkstyle-plugin-2.15-source-release.zip

 Source release checksum(s):
 maven-checkstyle-plugin-2.15-source-release.zip sha1:
 8b89a4d671f2046d19bc40412521f30fcc977b7f

 Staging site:
 http://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/

 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



-- 
Dennis Lundberg

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

[ANN] Apache Maven Checkstyle Plugin 2.15 Released

[Dennis Lundberg]

The Maven team is pleased to announce the release of the Apache Maven 
Checkstyle Plugin, version 2.15

Generates a report on violations of code style and optionally fails the build 
if violations are detected.

http://maven.apache.org/plugins/maven-checkstyle-plugin/

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

plugin
  groupIdorg.apache.maven.plugins/groupId
  artifactIdmaven-checkstyle-plugin/artifactId
  version2.15/version
/plugin


Release Notes - Apache Maven Checkstyle Plugin - Version 2.15

Bug
* [MCHECKSTYLE-288] NullPointerException during building a multi-module project
* [MCHECKSTYLE-250] NPE on tying to load LICENSE.txt resource from non-jar 
plugin dependencies

Improvement
* [MCHECKSTYLE-286] Add info on ruleset used in console output
* [MCHECKSTYLE-261] Upgrade to Checkstyle 6.1.1

Task
* [MCHECKSTYLE-277] Require Java 6
* [MCHECKSTYLE-273] Remove Turbine configuration since it is not used any more


Enjoy,

-The Maven team

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

Re: Suggestions User Information about Maven 2.2.1 EoL / Plugins / JDK

[Dennis Lundberg]

It looks good to me

On Thu, Mar 19, 2015 at 8:02 PM, Karl Heinz Marbaise khmarba...@gmx.de wrote:
 Hi,

 nothing more to improve ?

 Kind regards
 Karl Heinz Marbaise
 On 3/18/15 10:21 PM, Karl Heinz Marbaise wrote:

 Hi,

 i have incorporated the suggestions/ideas/improvements

 https://github.com/khmarbaise/maven2eol/blob/master/message.txt


 If you have adds/supplementals/etc. please send a pull request or you
 can create an issue...


 The list of Maven versions / JDK requirements should be listed on the
 download page...IMHO...

 Kind regards
 Karl Heinz Marbaise


 On 3/5/15 7:35 PM, Karl Heinz Marbaise wrote:

 Hi,

 here is my suggestions for the user list announcement regarding Maven
 2.2.1 EoL / Plugins version lift / JDK etc.

 Any enhancement / things which should also be mentioned please reply and
 make appropriate changes / Thinks which i have missed...


 -
 Dear Maven Users,

 based on the End of Life of Maven 2.2.1 (a year ago) now the time has
 come to make the final releases of Apache Maven Plugins which support
 Maven 2.X.

 We have documented the final releases of plugins which support Maven
 2.2.1 in relationship with JDK 1.5

 The complete list can be found here:

 http://maven.apache.org/maven-2.x-eol.html

 The next step on our roadmap is to lift all plugin versions to 3.X to
 make clear those plugins will only work with Maven 3.0+ furthermore the
 Java minimum requirement will lifted to JDK 1.6 as well.

 No rule without exceptions. Here they come:


   * maven-site-plugin (Version 3.4)
 See the docs of the plugin for usage in Maven 2.X

   * maven-compiler-plugin (Version 3.2)
 which works with Maven 2.2.1.

   * maven-plugin-plugin (Version 3.4)
 which works with Maven 2.2.1

   * maven-pmd-plugin (Version 3.4)
 which works with Maven 2.2.1 but needs JDK 1.6


 The following plugins already have the Maven 3.0+ requirement:

 * maven-scm-publish-plugin (Version 1.1)
 * maven-shade-plugin (Version 2.3)


 So to make things more clearer here is an example:

 Currently we have the maven-clean-plugin with version 2.6.1.

 This plugin supports Maven 2.2.1 and JDK 1.5 minimum.

 This plugin will get a new major release with version 3.0 which has the
 Maven minimum 3.0 AND Jave minimum 1.6.


 Kind regards
 The Apache Maven Team



 -
 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

Re: [VOTE] Release Apache Maven Checkstyle Plugin version 2.15

[Dennis Lundberg]

Hi,

We need one more bindning vote...
Den 15 mar 2015 20:14 skrev Dennis Lundberg denn...@apache.org:

 Hi,

 We solved 6 issues:

 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11127styleName=Htmlversion=20762

 There are still a couple of issues left in JIRA:

 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11127status=1

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

 https://repository.apache.org/content/repositories/maven-1153/org/apache/maven/plugins/maven-checkstyle-plugin/2.15/maven-checkstyle-plugin-2.15-source-release.zip

 Source release checksum(s):
 maven-checkstyle-plugin-2.15-source-release.zip sha1:
 8b89a4d671f2046d19bc40412521f30fcc977b7f

 Staging site:
 http://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/

 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

Re: [VOTE] Suggestions User Information about Maven 2.2.1 EoL / Plugins / JDK

[Dennis Lundberg]

Hi,

I like this, and the comments from Hervé an Robert.

Here is another suggestion. We could start using 3-digit version numbers
for all M3-only plugins. I.e. start with 3.0.0 for most of them, except
for those on the exceptions list.
Den 14 mar 2015 14:09 skrev Karl Heinz Marbaise khmarba...@gmx.de:

 Hi,

 would like someone to add/change/enhancements or something to this

 i would suggest to wait the usual 72 hours and if no one will say -1  i
 would prepare to send out this to users list, announcement
 list...twitter...google plus etc. (any supplemtal channels are welcome)...

 I would like to send this out on Thursday 19. march 2015...so we have a
 little bit more time...to give others during the week time to take a look
 on it as well...

  -

 Dear Apache Maven Users,

 Based on the End of Life of Maven 2.2.1 (a year ago), now the time has
 come to make the final releases of Apache Maven Plugins which support
 Maven 2.X: next releases will have Maven 3 as prerequisite.

 We have documented the final releases of plugins which support Maven
 2.2.1 and Java 5: the complete list can be found here:

 http://maven.apache.org/maven-2.x-eol.html

 The next step on our roadmap is to lift all plugin versions to 3.X in
 general
 to make clear those plugins will only work with Maven 3.0+. Furthermore
 the
 Java minimum requirement will be lifted to Java 6 as well.

 No rule without exceptions. Here they come:


* maven-site-plugin: version 3.4 works with Maven 2.X
  Version 3.5 will require Maven 3

* maven-compiler-plugin: version 3.2 works with Maven 2.X
  Version 3.5 will require Maven 3

* maven-plugin-plugin: version 3.4 works with Maven 2.X
  Version 3.5 will require Maven 3

* maven-pmd-plugin: version 3.4  works with Maven 2.X but already
 requires
 Java 6
  Version 3.5 will require Maven 3


 The following plugins already have the Maven 3.0+ requirement without
 following 3.X version pattern:

 * maven-scm-publish-plugin: version 1.1 requires Maven 3, last version
 compatible with Maven 2.x is version 1.0-beta-2

 * maven-shade-plugin: version 2.3 requires Maven 3, last version
 compatible
 with Maven 2.x is version 1.7.1


 So to make things more clear, here is an example:

 Currently, we have the maven-clean-plugin with version 2.6.1.

 This plugin supports Maven 2.2.1 and Java 5 minimum.

 This plugin will get a new major release with version 3.0 which has Maven
 3.0
 AND Java 6 prerequisites.


 Kind regards
 The Apache Maven Team

 -




 Kind regards
 Karl Heinz Marbaise



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

Re: [VOTE] Release Apache Maven Checkstyle Plugin version 2.15

[Dennis Lundberg]

+1 from me

On Sun, Mar 15, 2015 at 8:14 PM, Dennis Lundberg denn...@apache.org wrote:
 Hi,

 We solved 6 issues:
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11127styleName=Htmlversion=20762

 There are still a couple of issues left in JIRA:
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11127status=1

 Staging repo:
 https://repository.apache.org/content/repositories/maven-1153/
 https://repository.apache.org/content/repositories/maven-1153/org/apache/maven/plugins/maven-checkstyle-plugin/2.15/maven-checkstyle-plugin-2.15-source-release.zip

 Source release checksum(s):
 maven-checkstyle-plugin-2.15-source-release.zip sha1:
 8b89a4d671f2046d19bc40412521f30fcc977b7f

 Staging site:
 http://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/

 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



-- 
Dennis Lundberg

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

[VOTE] Release Apache Maven Checkstyle Plugin version 2.15

[Dennis Lundberg]

Hi,

We solved 6 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11127styleName=Htmlversion=20762

There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11127status=1

Staging repo:
https://repository.apache.org/content/repositories/maven-1153/
https://repository.apache.org/content/repositories/maven-1153/org/apache/maven/plugins/maven-checkstyle-plugin/2.15/maven-checkstyle-plugin-2.15-source-release.zip

Source release checksum(s):
maven-checkstyle-plugin-2.15-source-release.zip sha1:
8b89a4d671f2046d19bc40412521f30fcc977b7f

Staging site:
http://maven.apache.org/plugins-archives/maven-checkstyle-plugin-LATEST/

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

Re: What binary repo for plexus?

[Dennis Lundberg]

Thanks,

So currently we deploy to OSSRH?

I'll let the central support staff know that, so that they can at
least prohibit plexus deploys to nexus.codehaus.org.

On Tue, Mar 10, 2015 at 11:45 AM, Kristian Rosenvold
kristian.rosenv...@gmail.com wrote:
 I asked Brian if there was any way to get central publishing rights linked
 to github org membership, much like what we might want for mojo. I did not
 get any specific reply, maybe he'll read this :)

 Kristian


 2015-03-09 23:33 GMT+01:00 Olivier Lamy ol...@apache.org:

 AFAIK we have switched deploying directly to ossrh for long time now :-)


 On 10 March 2015 at 06:01, Dennis Lundberg denn...@apache.org wrote:

  Hi,
 
  What is the intended binary repo for plexus, after the move to the
  codehaus-plexus organization on github?
 
  I requested permissions to deploy to ossrh, which is what it says in the
  parent. They wanted confirmation that we are switching from
  nexus.codehaus.org to ossrh. Are we?
 
  --
  Dennis Lundberg
 



 --
 Olivier Lamy
 http://twitter.com/olamy | http://linkedin.com/in/olamy




-- 
Dennis Lundberg

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

Re: What binary repo for plexus?

[Dennis Lundberg]

HI Brian,

Thanks for the input, but now I'm confused.

The POMs for plexus currently points to OSSRH. Can anyone who has done
a release of a plexus component lately shed some light on where they
go? Either nexus.codehaus.org och OSSRH.


On Tue, Mar 10, 2015 at 6:28 PM, Brian Fox bri...@infinity.nu wrote:
 The current plan is to continue running nexus.codehaus.org and then
 move stuff over to ossrh as needed. The ssl cert was just renewed and
 Bob said the DNS isn't going away immediately. We figure projects have
 enough other stuff to scurry around changing, Nexus doesn't have to be
 part of it at the same time. Moving stuff to OSSRH is pretty straight
 forward when a project is ready to do so.

 On Tue, Mar 10, 2015 at 7:57 AM, Dennis Lundberg denn...@apache.org wrote:
 Thanks,

 So currently we deploy to OSSRH?

 I'll let the central support staff know that, so that they can at
 least prohibit plexus deploys to nexus.codehaus.org.

 On Tue, Mar 10, 2015 at 11:45 AM, Kristian Rosenvold
 kristian.rosenv...@gmail.com wrote:
 I asked Brian if there was any way to get central publishing rights linked
 to github org membership, much like what we might want for mojo. I did not
 get any specific reply, maybe he'll read this :)

 Kristian


 2015-03-09 23:33 GMT+01:00 Olivier Lamy ol...@apache.org:

 AFAIK we have switched deploying directly to ossrh for long time now :-)


 On 10 March 2015 at 06:01, Dennis Lundberg denn...@apache.org wrote:

  Hi,
 
  What is the intended binary repo for plexus, after the move to the
  codehaus-plexus organization on github?
 
  I requested permissions to deploy to ossrh, which is what it says in the
  parent. They wanted confirmation that we are switching from
  nexus.codehaus.org to ossrh. Are we?
 
  --
  Dennis Lundberg
 



 --
 Olivier Lamy
 http://twitter.com/olamy | http://linkedin.com/in/olamy




 --
 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

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

What binary repo for plexus?

[Dennis Lundberg]

Hi,

What is the intended binary repo for plexus, after the move to the
codehaus-plexus organization on github?

I requested permissions to deploy to ossrh, which is what it says in the
parent. They wanted confirmation that we are switching from
nexus.codehaus.org to ossrh. Are we?

--
Dennis Lundberg

What binary repo for plexus?

[Dennis Lundberg]

Hi,

What is the intended binary repo for plexus, after the move to the
codehaus-plexus organization on github?

I requested permissions to deploy to ossrh, which is what it says in the
parent. They wanted confirmation that we are switching from
nexus.codehaus.org to ossrh. Are we?

--
Dennis Lundberg

Re: move maven core to java 7?

[Dennis Lundberg]

On Sat, Mar 7, 2015 at 1:06 PM, Hervé BOUTEMY herve.bout...@free.fr wrote:
 There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0
 on Java 7 in a few weeks.
 what I don't like with this plan is that it is exactly what happened with
 3.1.1 then 3.2.1: we never did any bugfix for 3.1.1, 3.1.1 was a dead branch
 for start. 3.2.2 bugfixes could/should have been backported to 3.1.1, but who
 will ever do that? (not me...)

That is the normal state in open source software. Not many people will
volunteer to backport bugfixes to older release lines. It's a matter
of putting your limited resources where it does most good, and also
where your itch is. Usually this means working on HEAD.

 I agree that the lack of schedule can be a problem if we decide to make the
 release this week-end: but if we take one week to integrate Java 7
 improvements (ie mostly syntax for better maintainability and a few new APIs)
 and take one week after that to test the result, IMHO we get a better plan: a
 new Maven version, with features and the assurance we'll do bugfix releases on
 it (the fact that it has upgraded Java requirement is just a fact on release
 notes)

I'm not concerned that switching to Java 7 will introduce any new bugs
in core, at least not until we start using new Java 7 features.

What we should do is think about what is best for our users. Let's
look at the pros and cons of the two alternatives:

1. Switch to Java 7 for Maven 3.3.0

Bad: Users that are restricted to Java 6 for some reason will not be
able to benefit from the bug fixes and new features in 3.3.0
Good: One less release to make

2. Switch to Java 7 for Maven 3.4.0

Bad: One more release to make
Good: Users that are restricted to Java 6 for some reason will benefit
from the bug fixes and new features in 3.3.0, even though they might
not get any more bugfixes on that release line, because work focus
move to 3.4.0-SNAPSHOT as soon as 3.3.0 has been released


 Regards,

 Hervé

 Le samedi 7 mars 2015 12:04:15 Dennis Lundberg a écrit :
 Hi Kristian,

 Please note that I am not opposed to using Java 7 in the core. What I am
 objecting to is the planning, or rather the lack of it.

 We currently have core ready to be released on Java 6. Then just before it
 is about to be released someone says, hey  lets switch Java version as
 well. IMO that is something you should plan for before work is even started
 on the next release.

 Then there is the agreement we made regarding Java versions and their EOL.

 Switching to Java 7 before the release will mean that a fewer number of
 users will be able to reap the benefits of the bugfixes and features in
 Maven 3.3.0.

 There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0
 on Java 7 in a few weeks.

 Weighing in all of this I don't see any reason to change the Java version
 for 3.3.0.
 Den 6 mar 2015 13:54 skrev Kristian Rosenvold 

 kristian.rosenv...@gmail.com:
  I already have the full jdk7 port in a branch in github, so that
  assumption
  does not hold :)
 
  Kristian
 
  2015-03-06 13:50 GMT+01:00 Dennis Lundberg denn...@apache.org:
   Hi,
  
   If we are going to release 3.3.0 very soon, like this week or the
   next, there won't be any time to start using Java 7 features in the
   3.3.0 release. Therefor I would prefer to go with Java 6 for 3.3.0 and
   announce, in the 3.3.0 release notes, that the 3.3.x line is the last
   line that will work with Java 6. Depending on what the core developers
   want to focus on after the 3.3.0 release is done, the core can either
   go 3.3.1-SNAPSHOT with Java 6 or 3.4.0-SNAPSHOT with Java 7. This
   would also be consistent with our policy [1] for plugins/components
   wanting to move to a higher major Java version, in that we should
   release what we currently have in trunk before upgrading to a higher
   major Java version.
  
   My votes are:
   -1 for Java 7 in 3.3.0
   +1 for Java 7 in 3.4.0
  
  
   [1] http://maven.apache.org/developers/java6.html
  
   On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko i...@ifedorenko.com
  
   wrote:
With maven core version change to 3.3.0 on master, any objections I
change compile source/target to java 7?
   
--
Regards,
Igor
   
-
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

-
To unsubscribe, e-mail: dev-unsubscr

Re: move maven core to java 7?

[Dennis Lundberg]

The breaking thing is the new prerequisite of Java 7 which would
exclude some of our users.

On Sun, Mar 8, 2015 at 12:05 AM, Igor Fedorenko i...@ifedorenko.com wrote:
 How is this a breaking change? All plugins that worked with 3.2.5 are
 expected to work as is. All projects that built with 3.2.5 are expected
 to build.

 --
 Regards,
 Igor


 On 2015-03-07 17:35, Tibor Digana wrote:

 (Replying on this thread from my mail server does not work for me)

 Usually the opensource projects change the major version, to 4.0.0, if
 breaking the commpatibility with previous release.
 So why we don't do that?

 Listing features of Java SE 7 that we may use:

 try-catch-resources

 Strings in switch Statements

 Catching Multiple Exceptions

 @SafeVarargs

 Underscores in Numeric Literals

 Multithreaded Custom Class Loader

 Closing a URLClassLoader (URLClassLoader.close())

 IO and New IO (File Attributes, FileChannel.transferTo())

 isLink() is utils

 Operating on Zip File System Provider

 http://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/zipfilesystemprovider.html

 Memory File System

 http://docs.oracle.com/javase/7/docs/api/java/nio/file/spi/FileSystemProvider.html

 http://docs.oracle.com/javase/8/docs/technotes/guides/io/fsp/filesystemprovider.html

 Remote Direct Memory Access (RDMA)  SDP  AsynchronousSocketChannel
 https://blogs.oracle.com/alanb/entry/sockets_direct_protocol



 --
 View this message in context:
 http://maven.40175.n5.nabble.com/move-maven-core-to-java-7-tp5827988p5828390.html
 Sent from the Maven Developers mailing list archive at Nabble.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




-- 
Dennis Lundberg

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

Re: move maven core to java 7?

[Dennis Lundberg]

Hi Igor,

In my opinion the switch to Java 7 as a prerequisite is a non-risky
thing to do, even though I still argue that we should wait till the
next release to do it.

Making use of the new Java 7 features in the code is the risky bit.
That in my book warrants a minor release bump rather that a patch
version bump.

On Sat, Mar 7, 2015 at 2:45 PM, Igor Fedorenko i...@ifedorenko.com wrote:
 We changed version from 3.2.x to 3.3.x quite late in the release and
 this was the reason I proposed change to java 7. It allows us continue
 3.3.x improvement and use new language features.

 Personally I believe changing compiler configuration to target java 7 is
 very unlikely to introduce regressions in Maven at this point, but I can
 understand if somebody wants to do additional validation.

 Making actual code changes just to show we use java 7 language features
 in 3.3.0 seems unnecessary risk, however. I think it makes more sense to
 release 3.3.0 as is, then do java 7 cleanup in 3.3.1.

 --
 Regards,
 Igor


 On 2015-03-07 7:26, Hervé BOUTEMY wrote:

 Le samedi 7 mars 2015 13:06:26 Hervé BOUTEMY a écrit :

 There is nothing stoping you from releasing 3.3.0 on Java 6 now, and
 3.4.0
 on Java 7 in a few weeks.


 what I don't like with this plan is that it is exactly what happened with
 3.1.1 then 3.2.1:

 and before 2.1.0 vs 2.2.0

 and the only cause (IIRC) is that we had a schedule, then thought it would
 be
 good to upgrade, but didn't change the schedule to have 1 to 2 weeks to
 test

 if we decide to take 2 weeks to integrate some improvements that the
 upgrade
 permits and test, would the upgrade to 3.3.0 be ok?

 Regards,

 Hervé

 we never did any bugfix for 3.1.1, 3.1.1 was a dead branch
 for start. 3.2.2 bugfixes could/should have been backported to 3.1.1, but
 who will ever do that? (not me...)

 I agree that the lack of schedule can be a problem if we decide to make
 the
 release this week-end: but if we take one week to integrate Java 7
 improvements (ie mostly syntax for better maintainability and a few new
 APIs) and take one week after that to test the result, IMHO we get a
 better
 plan: a new Maven version, with features and the assurance we'll do
 bugfix
 releases on it (the fact that it has upgraded Java requirement is just a
 fact on release notes)

 Regards,

 Hervé

 Le samedi 7 mars 2015 12:04:15 Dennis Lundberg a écrit :

 Hi Kristian,

 Please note that I am not opposed to using Java 7 in the core. What I am
 objecting to is the planning, or rather the lack of it.

 We currently have core ready to be released on Java 6. Then just before
 it
 is about to be released someone says, hey  lets switch Java version as
 well. IMO that is something you should plan for before work is even
 started
 on the next release.

 Then there is the agreement we made regarding Java versions and their
 EOL.

 Switching to Java 7 before the release will mean that a fewer number of
 users will be able to reap the benefits of the bugfixes and features in
 Maven 3.3.0.

 There is nothing stoping you from releasing 3.3.0 on Java 6 now, and
 3.4.0
 on Java 7 in a few weeks.

 Weighing in all of this I don't see any reason to change the Java
 version
 for 3.3.0.
 Den 6 mar 2015 13:54 skrev Kristian Rosenvold 

 kristian.rosenv...@gmail.com:

 I already have the full jdk7 port in a branch in github, so that
 assumption
 does not hold :)

 Kristian

 2015-03-06 13:50 GMT+01:00 Dennis Lundberg denn...@apache.org:

 Hi,

 If we are going to release 3.3.0 very soon, like this week or the
 next, there won't be any time to start using Java 7 features in the
 3.3.0 release. Therefor I would prefer to go with Java 6 for 3.3.0 and
 announce, in the 3.3.0 release notes, that the 3.3.x line is the last
 line that will work with Java 6. Depending on what the core developers
 want to focus on after the 3.3.0 release is done, the core can either
 go 3.3.1-SNAPSHOT with Java 6 or 3.4.0-SNAPSHOT with Java 7. This
 would also be consistent with our policy [1] for plugins/components
 wanting to move to a higher major Java version, in that we should
 release what we currently have in trunk before upgrading to a higher
 major Java version.

 My votes are:
 -1 for Java 7 in 3.3.0
 +1 for Java 7 in 3.4.0


 [1] http://maven.apache.org/developers/java6.html

 On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko i...@ifedorenko.com

 wrote:

 With maven core version change to 3.3.0 on master, any objections I
 change compile source/target to java 7?

 --
 Regards,
 Igor

 
 -
 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

Re: move maven core to java 7?

[Dennis Lundberg]

Hi Kristian,

Please note that I am not opposed to using Java 7 in the core. What I am
objecting to is the planning, or rather the lack of it.

We currently have core ready to be released on Java 6. Then just before it
is about to be released someone says, hey  lets switch Java version as
well. IMO that is something you should plan for before work is even started
on the next release.

Then there is the agreement we made regarding Java versions and their EOL.

Switching to Java 7 before the release will mean that a fewer number of
users will be able to reap the benefits of the bugfixes and features in
Maven 3.3.0.

There is nothing stoping you from releasing 3.3.0 on Java 6 now, and 3.4.0
on Java 7 in a few weeks.

Weighing in all of this I don't see any reason to change the Java version
for 3.3.0.
Den 6 mar 2015 13:54 skrev Kristian Rosenvold 
kristian.rosenv...@gmail.com:

 I already have the full jdk7 port in a branch in github, so that assumption
 does not hold :)

 Kristian


 2015-03-06 13:50 GMT+01:00 Dennis Lundberg denn...@apache.org:

  Hi,
 
  If we are going to release 3.3.0 very soon, like this week or the
  next, there won't be any time to start using Java 7 features in the
  3.3.0 release. Therefor I would prefer to go with Java 6 for 3.3.0 and
  announce, in the 3.3.0 release notes, that the 3.3.x line is the last
  line that will work with Java 6. Depending on what the core developers
  want to focus on after the 3.3.0 release is done, the core can either
  go 3.3.1-SNAPSHOT with Java 6 or 3.4.0-SNAPSHOT with Java 7. This
  would also be consistent with our policy [1] for plugins/components
  wanting to move to a higher major Java version, in that we should
  release what we currently have in trunk before upgrading to a higher
  major Java version.
 
  My votes are:
  -1 for Java 7 in 3.3.0
  +1 for Java 7 in 3.4.0
 
 
  [1] http://maven.apache.org/developers/java6.html
 
  On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko i...@ifedorenko.com
  wrote:
   With maven core version change to 3.3.0 on master, any objections I
   change compile source/target to java 7?
  
   --
   Regards,
   Igor
  
   -
   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
 
 

Need help to merge pull request for plexus-resources

[Dennis Lundberg]

Hi,

I've looked into MCHECKSTYLE-250 and MCHECKSTYLE-288 regarding an NPE.
It turned out to be in plexus-resources. So I have created a pull
request for it at
https://github.com/sonatype/plexus-resources/pull/1

I'd appreciate if someone with access to Sonatype's github area could
merge it and deploy a SNAPSHOT, so that the reporters of the above
issues can try out my fix.

-- 
Dennis Lundberg

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

Re: move maven core to java 7?

[Dennis Lundberg]

Hi,

If we are going to release 3.3.0 very soon, like this week or the
next, there won't be any time to start using Java 7 features in the
3.3.0 release. Therefor I would prefer to go with Java 6 for 3.3.0 and
announce, in the 3.3.0 release notes, that the 3.3.x line is the last
line that will work with Java 6. Depending on what the core developers
want to focus on after the 3.3.0 release is done, the core can either
go 3.3.1-SNAPSHOT with Java 6 or 3.4.0-SNAPSHOT with Java 7. This
would also be consistent with our policy [1] for plugins/components
wanting to move to a higher major Java version, in that we should
release what we currently have in trunk before upgrading to a higher
major Java version.

My votes are:
-1 for Java 7 in 3.3.0
+1 for Java 7 in 3.4.0


[1] http://maven.apache.org/developers/java6.html

On Thu, Mar 5, 2015 at 1:19 PM, Igor Fedorenko i...@ifedorenko.com wrote:
 With maven core version change to 3.3.0 on master, any objections I
 change compile source/target to java 7?

 --
 Regards,
 Igor

 -
 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

[ANN] Apache Source Release Assembly Descriptor 1.0.5 Released

[Dennis Lundberg]

The Apache Source Release Assembly Descriptor team is pleased to
announce the apache-source-release-assembly-descriptor-1.0.5 release!

This jar contains a customized source assembly descriptor to produce
Apache compliant source bundles.

http://maven.apache.org/apache-resource-bundles/

Changes in this version include:

o Add pre-defined descriptor in
apache-source-release-assembly-descriptor for tarball-only  Issue:
MASFRES-9.


Have fun!
-Apache Source Release Assembly Descriptor team

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

[RESULT] [VOTE] Release Apache Resource Bundles version 5 and Apache Source Release Assembly Descriptor version 1.0.5

[Dennis Lundberg]

Hi,

The vote has passed with the following result:

+1 (binding): Dennis Lundberg, Karl Heinz Marbaise, Kristian Rosenvold

Thanks for reviewing this release!
I will promote the artifacts to the central repo.


On Sat, Feb 21, 2015 at 8:47 PM, Dennis Lundberg denn...@apache.org wrote:
 Hi,

 We solved 2 issues:
 * Use tarLongFileMode instead of tarLongFileFormat which has never
 worked for maven-assembly-plugin
 * MASFRES-9 Add pre-defined descriptor in
 apache-source-release-assembly-descriptor for tarball-only

 Staging repo:
 https://repository.apache.org/content/repositories/orgapacheapache-1004/
 https://repository.apache.org/content/repositories/orgapacheapache-1004/org/apache/apache/resources/apache-resource-bundles/5/apache-resource-bundles-5-source-release.zip
 https://repository.apache.org/content/repositories/orgapacheapache-1004/org/apache/apache/resources/apache-source-release-assembly-descriptor/1.0.5/apache-source-release-assembly-descriptor-1.0.5-source-release.zip


 Source release checksum(s):
 apache-resource-bundles-5-source-release.zip sha1:
 ad2093ab31d21e352b6f7ab04dd5fff2dee707f8
 apache-source-release-assembly-descriptor-1.0.5-source-release.zip
 sha1: 9a68a8ee30c389af9e1e4c922f8fefcbcb653945

 There are no versioned sites for these components. The current docs
 are part of the main Maven site:
 http://maven.apache.org/apache-resource-bundles/

 I'll update the version number for
 apache-source-release-assembly-descriptor in the site once this vote
 has passed.

 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



-- 
Dennis Lundberg

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

Re: [VOTE] Release Apache Resource Bundles version 5 and Apache Source Release Assembly Descriptor version 1.0.5

[Dennis Lundberg]

+1 from me
Den 21 feb 2015 20:47 skrev Dennis Lundberg denn...@apache.org:

 Hi,

 We solved 2 issues:
 * Use tarLongFileMode instead of tarLongFileFormat which has never
 worked for maven-assembly-plugin
 * MASFRES-9 Add pre-defined descriptor in
 apache-source-release-assembly-descriptor for tarball-only

 Staging repo:
 https://repository.apache.org/content/repositories/orgapacheapache-1004/

 https://repository.apache.org/content/repositories/orgapacheapache-1004/org/apache/apache/resources/apache-resource-bundles/5/apache-resource-bundles-5-source-release.zip

 https://repository.apache.org/content/repositories/orgapacheapache-1004/org/apache/apache/resources/apache-source-release-assembly-descriptor/1.0.5/apache-source-release-assembly-descriptor-1.0.5-source-release.zip


 Source release checksum(s):
 apache-resource-bundles-5-source-release.zip sha1:
 ad2093ab31d21e352b6f7ab04dd5fff2dee707f8
 apache-source-release-assembly-descriptor-1.0.5-source-release.zip
 sha1: 9a68a8ee30c389af9e1e4c922f8fefcbcb653945

 There are no versioned sites for these components. The current docs
 are part of the main Maven site:
 http://maven.apache.org/apache-resource-bundles/

 I'll update the version number for
 apache-source-release-assembly-descriptor in the site once this vote
 has passed.

 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

Re: [DISCUSS] To SemVer or not to SemVer, that is the question

[Dennis Lundberg]

Thanks Robert,

I'll have a look at it.

On Sun, Feb 22, 2015 at 1:00 PM, Robert Scholte rfscho...@apache.org wrote:
 Hi Dennis,

 I've already started to extract some parts of the maven-release-manager to
 an API.
 The project has now 4 modules[1], whereas the maven-release-apis[2] should
 be interesting.
 I've started with a VersionPolicy interface, Simone already started on his
 own implementation of OddEven Policy[3]
 The current version already works with this API and the default
 implementation, so there's only one more step to take: make it settable by
 plugin configuration.
 So you could work on the SemVer policy based on this API. If this confirms
 that the API for version policy is complete, we can expose it.

 thanks,
 Robert

 [1] http://maven.apache.org/maven-release/
 [2]
 http://maven.apache.org/maven-release/maven-release-api/apidocs/index.html
 [3]
 http://maven.apache.org/maven-release/maven-release-policies/maven-release-oddeven-policy/index.html


 Op Sat, 21 Feb 2015 23:05:37 +0100 schreef Dennis Lundberg
 denn...@apache.org:


 Hi,

 Although I strongly feel that SemVer [1] is the way to go when it
 comes to versioning, I still haven't started using it though. That got
 me thinking about why that is the case. I've come to the conclusion
 that I'm lazy :)

 It all comes down to tooling. Being accustomed to, and spoiled by,
 using the Release Plugin, I don't want to do anything manually any
 more. That includes as simple a thing as changing the next version
 (or developmentVersion) manually during the interactive command line
 session when using the Release Plugin. I want it to be the guessed
 correctly for me. Let me outline an example to show you what I mean.
 The vast majority of releases I make, both here and at my day job, are
 minor releases. So I want the Release Plugin to work for me, and not
 against me.


 Not using SemVer

 1.0-SNAPSHOT -- 1.0 -- 1.1-SNAPSHOT

 No problems here, the Release Plugin will correctly guess that
 1.1-SNAPSHOT is the next version that I want to use. Just hit enter
 a couple of times during the release process.


 Using SemVer

 1.0.0-SNAPSHOT -- 1.0.0 -- 1.0.1-SNAPSHOT

 This is not what I want. The Release Plugin will guess that the next
 version should be 1.0.1-SNAPSHOT. To change it I have to type in the
 value that I want on the command line. I'm too lazy for that. Instead
 I want the Release Plugin to do this:

 1.0.0-SNAPSHOT -- 1.0.0 -- 1.1.0-SNAPSHOT


 How can we solve this? The solution that I have come up with is a new
 parameter for release:prepare tentatively called versionIncrement
 that can take the values major, minor and patch, with patch
 being the default value for backwards compatibility.

 In my use case above I would simply set versionIncrement=minor and the
 Release Plugin would then do things my way.

 What are your thoughts on this?

 I would like for us to start using SemVer for all releases in the
 Maven project, not just in core. What do you think?


 [1] http://semver.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