Re: [VOTE] Release Maven Resolver version 1.3.0

[Tibor Digana]

+1

On Sun, Oct 7, 2018 at 12:01 AM Michael Osipov  wrote:

> Hi,
>
> We solved 14 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628&version=12342803
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/projects/MRESOLVER/issues?filter=allopenissues
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1454/
>
> https://repository.apache.org/content/repositories/maven-1454/org/apache/maven/resolver/maven-resolver/1.3.0/maven-resolver-1.3.0-source-release.zip
>
> Source release checksum(s):
> maven-resolver-1.3.0-source-release.zip
> sha512:
>
> 9d13195149c162d7186e37d1cb1a8b257a50d171c4e562e083cfd7d16fca1ae183273671595f3b633b06eee481fd13b5d4f6e52866871f02ed90beaa60428523
>
> Staging site:
> https://maven.apache.org/resolver-archives/resolver-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
>
>

Re: I am wandering how you do guys debug maven?

[Tibor Digana]

In IntelliJ IDEA it is "Remote", see Select Run/Debug Configurations >
Remote, change the port to 8000.
Run command *mvnDebug test* and then start "Remote" in IDEA.

On Tue, Oct 9, 2018 at 6:16 AM Romain Manni-Bucau 
wrote:

> Hello
>
> Not sure the question was about test classes - you got answers for that ;)
> - or maven and plugins themselves. If the last one, just replace "mvn" by
> "mvnDebug" in any command and remote debug on port 8000 in your IDE.
>
> Side note: if you check mvn script you will see maven has a main class so
> can be remote debugged as any java software ;)
>
> Le mar. 9 oct. 2018 05:44, Olivier Lamy  a écrit :
>
> > an other option is to use command line and the surefire option:
> > -Dmaven.surefire.debug=true
> > then you can have debug on port 5005 (look at your ide to start a remote
> > debug)
> >
> > On Tue, 9 Oct 2018 at 08:45, Enrico Olivelli 
> wrote:
> >
> > > Il lun 8 ott 2018, 23:23 Jeff MAURY  ha scritto:
> > >
> > > > M2e takes care of everything
> > > >
> > >
> > > Same for Apache Netbeans :)
> > >
> > > Enrico
> > >
> > >
> > > > Jeff
> > > >
> > > > Le lun. 8 oct. 2018 à 23:09, Simon Sheng  a
> > > écrit :
> > > >
> > > > > Hi,
> > > > >
> > > > > I am bringing this baby question since Maven load all it's classes
> by
> > > > > ClassWorlds. Which means it doesn't have "main method". instead we
> > > debug
> > > > > everything by log, do we have other way like debug with any IDE:
> > > Eclipse,
> > > > > Intellij etc. put breakpoints and debug step by step ?
> > > > >
> > > > > Thanks
> > > > >
> > > > > Simon(ChengHong) Sheng
> > > > >
> > > >
> > > --
> > >
> > >
> > > -- Enrico Olivelli
> > >
> >
> >
> > --
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
> >
>

Re: [VOTE] Release Apache Maven Surefire Plugin version 2.22.1

[Tibor Digana]

+1
Thx all for participating.

On Mon, Oct 8, 2018 at 10:22 AM Tibor Digana  wrote:

> Hi,
>
> We solved 17 issues:
> https://issues.apache.org/jira/projects/SUREFIRE/versions/12343425
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SUREFIRE%20AND%20status%20%3D%20Open%20ORDER%20BY%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1455/
>
> https://repository.apache.org/content/repositories/maven-1455/org/apache/maven/surefire/surefire/2.22.1/surefire-2.22.1-source-release.zip
>
> Source release checksum(s):
> surefire-2.22.1-source-release.zip sha512:
> 4a3561aae3478f4eefe0d0d6f8575ace746bbf267663f5361733b382f51d290672c61100d8d15e8b734607c63edfc33b4e61b4e1ddae10af0f2dfc04d20f38a4
> surefire-2.22.1-source-release.zip sha1:
> 13ed29cbba215ef7f383985024a0e8be274ba41f
>
> Staging site:
> http://maven.apache.org/surefire-archives/surefire-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
>
> --
> Cheers
> Tibor
>

Re: [VOTE] Release Apache Maven Resolver version 1.3.1

[Tibor Digana]

+1

On Thu, Oct 11, 2018 at 11:06 PM Karl Heinz Marbaise 
wrote:

> Hi,
>
> We solved 1 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12320628&version=12344286
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRESOLVER%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1457
>
> https://repository.apache.org/content/repositories/maven-1457/org/apache/maven/resolver/maven-resolver/1.3.1/maven-resolver-1.3.1-source-release.zip
>
> Source release checksum(s):
> maven-resolver-1.3.1-source-release.zip sha512:
>
> 720b527130c6380cea988d9b2c664db1f31107b9abd2e8e08bc7296eeb38557994b3bbee9770f80a5211b350a660cb8e9173b4998867287602414eb9ae201828
>
> Staging site:
> https://maven.apache.org/resolver-archives/resolver-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
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

[RESULT] [VOTE] Release Maven Surefire Plugin version 2.22.1

[Tibor Digana]

Hi,

The vote has passed with the following result:

+1: Karl Heinz Marbaise, Akira Ajisaka, Dejan Stojadinović, Enrico
Olivelli, Hervé BOUTEMY, Olivier Lamy, Tibor Digana

PMC quorum: reached

I will promote the artifacts to the central repo, the source release ZIP
file and add this release the board report.

BR
Tibor Digana

[ANN] Apache Maven Surefire Plugin version 2.22.1 Released

[Tibor Digana]

The Apache Maven team is pleased to announce the release of the Apache
Maven Surefire Plugin, version 2.22.1

The release contains 17 bug fixes.
Again we received contributions from the community in form of bug reports
and bug fixes.
Thank you and keep them coming!

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

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


  org.apache.maven.plugins
  maven-surefire-plugin
  2.22.1


or for failsafe:


  org.apache.maven.plugins
  maven-failsafe-plugin
  2.22.1


or for surefire-report:


  org.apache.maven.plugins
  maven-surefire-report-plugin
  2.22.1



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

Release Notes - Maven Surefire - Version 2.22.1

Bug

[SUREFIRE-1532] - MIME type for javascript is now officially
application/javascript
[SUREFIRE-1535] - Surefire unable to run testng suites in parallel
[SUREFIRE-1538] - Git considers PNG files as changed although there is
no change
[SUREFIRE-1550] - The surefire XSD published on maven site lacks of
some rerun element
[SUREFIRE-1559] - XML Report elements rerunError, rerunFailure,
flakyFailure, flakyError should contain element stackTrace and should not
be simpleContent.
[SUREFIRE-1561] - Logs in Parallel Tests are mixed up when
forkMode=never or forkCount=0
[SUREFIRE-1564] - Can't override platform version through
project/plugin dependencies
[SUREFIRE-1579] - Forks mixed up characters in standard output

Improvement

[SUREFIRE-1552] - Nil element "failureMessage" in failsafe-summary.xml
should have self closed tag
[SUREFIRE-1554] - Fix old test resources TEST-*.xml in favor of
continuing with SUREFIRE-1550
[SUREFIRE-1555] - Elapsed time in XML Report should satisfy pattern in
XSD.
[SUREFIRE-1562] - Support Java 11
[SUREFIRE-1565] - Surefire should support parameterized reportsDirectory

Task

[SUREFIRE-1569] - m-invoker-p:3.1.0 attempts to reolve
maven-surefire-common:jar:2.22.1-SNAPSHOT from remote repo
'apache.snapshots'
[SUREFIRE-1578] - Remove obsolete module
surefire-setup-integration-tests

Dependency upgrade

[SUREFIRE-1540] - Upgrade maven-plugins parent to version 32
[SUREFIRE-1571] - Upgrade maven-plugins parent to version 33

Enjoy,

-The Apache Maven team

Re: [VOTE] Requests to add to scheduled Maven CORE Release

[Tibor Digana]

Let's schedule the release day, no objections,  but there are still two
open issues https://issues.apache.org/jira/projects/MNG/versions/12338966
which have not been discussed yet.

On Sun, Oct 21, 2018 at 8:11 PM Karl Heinz Marbaise 
wrote:

> Hi to all Devs,
>
> * https://issues.apache.org/jira/browse/MNG-6492 review ok
>
>To be honstest I see only a question about the details of it
>by Michael Osipov. Nor do I see any implemented
>code changes etc.
>
>From my point of view no reason to postpone the release.
>
>In the end: -1 postpone to next release
>
> * https://issues.apache.org/jira/browse/MNG-6490 Karl, can You review?
>
>I would like to have the opinion of other devs as well.
>
>From my point view Ok to merge: +1 from me.
>
> * https://issues.apache.org/jira/browse/MNG-6069 also for review
>
>Unfortunately the IT's tell us there are issues also
>on the fix/MNG-6096 branch which tells me it is not
>that simple as expected.
>
>From my point of view: -1 postpone to next release
>
> * https://issues.apache.org/jira/browse/MNG-5693 code for review
>+ few ITs failed to changed output [2] ITs needs to be adjusted.
>
>@Sylwester: Can you can create an appropriate branch in IT's
>so we check if eveything works as expected.
>
> * https://issues.apache.org/jira/browse/MNG-6481
>
>From my point of view -1 cause for the release not critical.
>
>This means to postpone it to the next release.
>
>More important if core is working fine with JDK11 which is
>the case.
>
> * quote from Sylwester: I also verified release with Synk.io
>and we have only one report to upgrade Guava [4] to
>version 24.1.1 or above (now with Guice 4.2 we use 23.6)
>
>I have created MNG-6497 for this.
>See what IT's etc. will tell us.
>
>If all IT's are Ok I will VOTE: +1 for that.
>
>If I read the description I would say it is not really
>important for Maven Core cause as far as I know we don't
>do any serialization etc.
>
>
> Kind regards
> Karl Heinz Marbaise
>
> [4]: https://app.snyk.io/vuln/SNYK-JAVA-COMGOOGLEGUAVA-32236
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Apache Maven Pmd Plugin 3.11.0

[Tibor Digana]

I have computed SHA512 of the source release zip matching given hash

7aa3eef7a6c91793c2f7697b41a6edd6ed0dd002eb746c0fa86503a4c6391c85558878c7c7f2945a10a26caed5230d0088392f2bacb370995a3c7342aa43a2a4

+1

Cheers
Tibor

On Wed, Oct 24, 2018 at 8:48 PM Robert Scholte  wrote:

> Let's do this with the template[1], so all expected info is there (I hope
> the sha512 is correct):
>
> ---
> We solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317621&version=12343406&styleName=Text
>
> 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-1458/
>
> https://repository.apache.org/content/repositories/maven-1458/org/apache/maven/plugins/maven-pmd-plugin/3.11.0/maven-pmd-plugin-3.11.0-source-release.zip
>
> Source release checksum(s):
> maven-pmd-plugin-3.11.0-source-release.zip sha512:
>
> 7AA3EEF7A6C91793C2F7697B41A6EDD6ED0DD002EB746C0FA86503A4C6391C85558878C7C7F2945A10A26CAED5230D0088392F2BACB370995A3C7342AA43A2A4
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-pmd-plugin-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> ---
>
> Local runs are successful
> https://builds.apache.org/job/maven-box/job/maven-pmd-plugin/job/master/
> is stable
>
> +1
>
> Robert
>
> [1]
>
> https://maven.apache.org/developers/release/maven-project-release-procedure.html#Call_the_vote
>
>
> On Tue, 23 Oct 2018 08:37:31 +0200, Olivier Lamy  wrote:
>
> > Hi,
> > I'd like to release Pmd plugin 3.11.0
> > We fixed 5 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317621&version=12343406
> > Staging repository:
> > https://repository.apache.org/content/repositories/maven-1458/
> > Staging website:
> > http://maven.apache.org/plugins-archives/maven-pmd-plugin-LATEST/
> >
> > Vote open for 72H:
> > +1
> > 0
> > -1
> >
> > Cheers
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Jarsigner version 3.0.0

[Tibor Digana]

+1

On Fri, Oct 26, 2018 at 3:23 PM Robert Scholte  wrote:

> Hi,
>
> We solved 12 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12335540&styleName=Text
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317922%20AND%20component%20%3D%20maven-jarsigner%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1460/
>
> https://repository.apache.org/content/repositories/maven-1460/org/apache/maven/shared/maven-jarsigner/3.0.0/maven-jarsigner-3.0.0-source-release.zip
>
> Source release checksum(s):
> maven-jarsigner-3.0.0-source-release.zip sha512:
>
> 36dfd963ed1e3b3f646b03ade29452422bd0d0aabb6fccb480498ebf9ce2234e2b560332cb20c4fff76e11e39da82816fa652b81c6ebad9e650cfd4b75a15486
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-jarsigner-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
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven 3.6.0

[Tibor Digana]

+1

On Wed, Oct 24, 2018 at 9:50 PM Karl Heinz Marbaise 
wrote:

> Hi,
>
> We have solved 26 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922&version=12338966
>
> There are issues left in JIRA for Maven core:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1459
>
> The distributable binaries and sources can be found here:
>
> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/
>
> Specifically the zip, tarball and source archives can be found here:
>
>
> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-bin.zip
>
> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-bin.tar.gz
>
>
> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-src.zip
>
> https://repository.apache.org/content/repositories/maven-1459/org/apache/maven/apache-maven/3.6.0/apache-maven-3.6.0-src.tar.gz
>
> The release artifacts are staged for distribution in:
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.5.4
>
> Source release checksum(s):
> apache-maven-3.6.0-src.tar.gz
>
>sha1: 255d8057b7f014222e96137001d4f4aa05d4a7cb
> sha512:
>
> 5b4b5ca569d5476f9d6a2b8080927f58da9ca10a04c593df3d8c012e60fdcf7dcf70c4bc5db0d068b3a36785ede62a55fd1778b22ecadcf787485681ddc758a8
>
> apache-maven-3.6.0-src.zip:
>
>sha1: 6149f259489acf36e2c04ec0dd713f99336b3346
> sha512:
>
> c5794a6723d8d0fc8ff447b42e5a8c13524a44f8508a305d463f811c8039c7e9166d709077c8373d3cf980ce24feaebb2431cb50fb274933ab3bc2a90355
>
> Git tag:
>
> https://gitbox.apache.org/repos/asf?p=maven.git;a=commit;h=97c98ec64a1fdfee7767ce5ffb20918da4f719f3
>
> Staging site:
> https://maven.apache.org/components/ref/3-LATEST/
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> 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 Remote Resources Plugin version 1.6.0

[Tibor Digana]

+1
We plan also version 3.0?

On Sun, Oct 28, 2018 at 5:35 PM Hervé BOUTEMY  wrote:

> Hi,
>
> We solved 30 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317825&version=12331230&styleName=Text
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MRRESOURCES%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1461/
>
> https://repository.apache.org/content/repositories/maven-1461/org/apache/maven/plugins/maven-remote-resources-plugin/1.6.0/maven-remote-resources-plugin-1.6.0-source-release.zip
>
> Source release checksum(s):
> maven-remote-resources-plugin-1.6.0-source-release.zip sha512:
> 75b0840478e20986bcb6133778f666e63c5670a885cc63adac1824a138ba3954f344c0336289f8c7799e413570e943ff60e9fa1fd67c710a0cd355dd1e4f400c
>
> Staging site:
>
> https://maven.apache.org/plugins-archives/maven-remote-resources-plugin-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
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Maven Plugin Tools 3.6.0

[Tibor Digana]

+1
On Mon, Oct 29, 2018 at 5:34 AM Olivier Lamy  wrote:
>
> Hi
> I'd like to release Maven plugin Tools 3.6.0
> We solved 5 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12343309&styleName=Text&projectId=12317820
>
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/projects/MPLUGIN/issues/MPLUGIN-9?filter=allopenissues
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1462
> https://repository.apache.org/content/repositories/maven-1462/org/apache/maven/plugin-tools/maven-plugin-tools/3.6.0/maven-plugin-tools-3.6.0-source-release.zip
>
> Source release checksum(s):
>
> maven-plugin-tools-3.6.0-source-release.zip.sha512 :
> d0028acaf5a9a083230272fa49a93c1acb9a6f8677d5609649bb95e4f27340d692b14e1987b0ddba218bc7afbd38652d04660607a97b6a932d3e4b36734dfbc3
> Staging site:
> http://maven.apache.org/plugin-tools-archives/plugin-tools-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
>
> Cheers
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy

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

Killing Jenkins job of maven-pmd-plugin

[Tibor Digana]

The job [1] hangs after previous shutdown and it is blocking Jenkins CI.
The job is trying to recover over half day and has no progress
according to the logs.

I will kill it and start it manually again.

[1] https://builds.apache.org/job/maven-box/job/maven-pmd-plugin/job/master/67/


-- 
Cheers
Tibor

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

Can we add sub-version JDK 1.8.0_192 or JDK 1.8.0_192 to maven-jenkins-env?

[Tibor Digana]

Can we add sub-version JDK 1.8.0_192 or JDK 1.8.0_192 to
maven-jenkins-env [1]? Is this JDK already installed on Jenkins by
Infra team?

Latest version should be independent of subversion, but I mean a new
label named "JDK 1.8 (181)" with concrete subversion.

We can introduce an integration test for [2] but without this JDK it
won't be possible.

[1] https://gitbox.apache.org/repos/asf?p=maven-jenkins-env.git
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911925
-- 
Cheers
Tibor

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

[VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M1

[Tibor Digana]

Hi,

We solved 4 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12342871

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/i#issues/?jql=project+%3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1463/
https://repository.apache.org/content/repositories/maven-1463/org/apache/maven/surefire/surefire/3.0.0-M1/surefire-3.0.0-M1-source-release.zip

Source release checksum(s):
surefire-3.0.0-M1-source-release.zip sha512:
fc6efb02d04da557f0932877ba44b39e68f421d62fc7e8cbffbc55b9487f2b9d0201fc3c147b70e15208cc48588f8b98ab84102a739f0e267679a7fbb56d56e9
surefire-3.0.0-M1-source-release.zip sha1:
50bce813d6b384fc1e1cdea4f8f7a1733fafee66

Staging site:
http://maven.apache.org/surefire-archives/surefire-LATEST/

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

Vote open for 72 hours.

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

Cheers
Tibor

Re: [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M1

[Tibor Digana]

Hi Tamas, we are too fast ;-)
I think we have to cancel the Vote. Please check the GitHub issues, I will
post there. Thx.

On Fri, Nov 2, 2018 at 5:15 PM Tamás Cservenák  wrote:

> +1 (binding) works OK on system/openjdk that initially made me report
> SUREFIRE-1588 in the first place.
>
> On Fri, Nov 2, 2018 at 5:00 PM Tibor Digana 
> wrote:
>
> > Hi,
> >
> > We solved 4 issues:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12342871
> >
> > There are still a couple of issues left in JIRA:
> >
> >
> https://issues.apache.org/jira/i#issues/?jql=project+%3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1463/
> >
> >
> https://repository.apache.org/content/repositories/maven-1463/org/apache/maven/surefire/surefire/3.0.0-M1/surefire-3.0.0-M1-source-release.zip
> >
> > Source release checksum(s):
> > surefire-3.0.0-M1-source-release.zip sha512:
> >
> >
> fc6efb02d04da557f0932877ba44b39e68f421d62fc7e8cbffbc55b9487f2b9d0201fc3c147b70e15208cc48588f8b98ab84102a739f0e267679a7fbb56d56e9
> > surefire-3.0.0-M1-source-release.zip sha1:
> > 50bce813d6b384fc1e1cdea4f8f7a1733fafee66
> >
> > Staging site:
> > http://maven.apache.org/surefire-archives/surefire-LATEST/
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > Cheers
> > Tibor
> >
>

[CANCELLED] [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M1 VOTE 1

[Tibor Digana]

I am cancelling the first vote due to failed build and we can continue with
second vote. Sorry for that.

Re: [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M1

[Tibor Digana]

 I am cancelling the first vote due to failed build and we can continue
with second vote. Sorry for that.

On Fri, Nov 2, 2018 at 5:00 PM Tibor Digana  wrote:

> Hi,
>
> We solved 4 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12342871
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/i#issues/?jql=project+%3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1463/
>
> https://repository.apache.org/content/repositories/maven-1463/org/apache/maven/surefire/surefire/3.0.0-M1/surefire-3.0.0-M1-source-release.zip
>
> Source release checksum(s):
> surefire-3.0.0-M1-source-release.zip sha512:
> fc6efb02d04da557f0932877ba44b39e68f421d62fc7e8cbffbc55b9487f2b9d0201fc3c147b70e15208cc48588f8b98ab84102a739f0e267679a7fbb56d56e9
> surefire-3.0.0-M1-source-release.zip sha1:
> 50bce813d6b384fc1e1cdea4f8f7a1733fafee66
>
> Staging site:
> http://maven.apache.org/surefire-archives/surefire-LATEST/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Cheers
> Tibor
>

Re: [VOTE] Release Apache Maven Jarsigner Plugin version 3.0.0

[Tibor Digana]

+1

On Sat, Nov 3, 2018 at 11:32 AM Robert Scholte  wrote:

> Hi,
>
> We solved 8 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317528&version=12330856&styleName=Text
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317528%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-maven-1465/
>
> https://repository.apache.org/content/repositories/maven-1465/org/apache/maven/plugins/maven-jarsigner-plugin/3.0.0/maven-jarsigner-plugin-3.0.0-source-release.zip
>
> Source release checksum(s):
> maven-jarsigner-plugin-3.0.0-source-release.zip sha512:
>
> d02b69c2190a5d2360e317bb17393134b4d78a86aec66732a5534baa069afed6a6c4314697238b74badc53ed5beb88fdf6a811474923a30bb554a9b3404d5588
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-jarsigner-plugin-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
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Jarsigner Plugin version 3.0.0

[Tibor Digana]

It was a component [1] but now it is a plugin [2].

[1]: https://github.com/apache/maven-jarsigner
[2]: https://github.com/apache/maven-jarsigner-plugin


On Sat, Nov 3, 2018 at 6:32 PM Eric Lilja  wrote:

> If one just reads the list, it's hard to understand why this is voted on
> again after this announcement [1] (but I can see it didn't make it to
> Maven central). Seems some off-list communication have taken place here...
>
> [1]
>
> https://mail-archives.apache.org/mod_mbox/maven-dev/201810.mbox/%3Cop.zrrhydlkkdkhrr%40desktop-2khsk44.dynamic.ziggo.nl%3E
>
> - Eric L
>
> On 2018-11-03 13:58, Sylwester Lachiewicz wrote:
> > +1
> >
> > sob., 3.11.2018, 13:45: Tibor Digana 
> napisał(a):
> >
> >> +1
> >>
> >> On Sat, Nov 3, 2018 at 11:32 AM Robert Scholte 
> >> wrote:
> >>
> >>> Hi,
> >>>
> >>> We solved 8 issues:
> >>>
> >>>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317528&version=12330856&styleName=Text
> >>> There are still a couple of issues left in JIRA:
> >>>
> >>>
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317528%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
> >>> Staging repo:
> >>> https://repository.apache.org/content/repositories/maven-maven-1465/
> >>>
> >>>
> >>
> https://repository.apache.org/content/repositories/maven-1465/org/apache/maven/plugins/maven-jarsigner-plugin/3.0.0/maven-jarsigner-plugin-3.0.0-source-release.zip
> >>> Source release checksum(s):
> >>> maven-jarsigner-plugin-3.0.0-source-release.zip sha512:
> >>>
> >>>
> >>
> d02b69c2190a5d2360e317bb17393134b4d78a86aec66732a5534baa069afed6a6c4314697238b74badc53ed5beb88fdf6a811474923a30bb554a9b3404d5588
> >>> Staging site:
> >>>
> https://maven.apache.org/plugins-archives/maven-jarsigner-plugin-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
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>> For additional commands, e-mail: dev-h...@maven.apache.org
> >>>
> >>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

[VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M1 - TAKE 2

[Tibor Digana]

Hi,

We solved 4 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12342871

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/i#issues/?jql=project+%3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1466/
https://repository.apache.org/content/repositories/maven-1466/org/apache/maven/surefire/surefire/3.0.0-M1/surefire-3.0.0-M1-source-release.zip

Source release checksum(s):
surefire-3.0.0-M1-source-release.zip sha512:
2817639681b8597a58c38dbb5616c481c263f04b722f6fafcbc3f33c17f5d4b165572c38a83789ed80097047601505b339df015617603f754319dfadf3089b94
surefire-3.0.0-M1-source-release.zip sha1:
72830b8d82bd068ab7da5eaeb4da8a66b8ea600d

Staging site:
http://maven.apache.org/surefire-archives/surefire-LATEST/

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

Vote open for 72 hours.

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

Cheers
Tibor

Re: [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M1 - TAKE 2

[Tibor Digana]

One important remark regarding testing with JDK 9+.
The Surefire project runs itself tests within maven-surefire-plugin:2.12.4
which properly isolates project classes and plugin's classes.
Next version 3.0.0-M2 should load user's classes in IsolatedClassLoader
(configured by parameter in POM).
Due to we do not have this possibility now, we are able to test only with
such Java Specification Version which is 3 characters long at least, i.e.
9.0.1.


On Sun, Nov 4, 2018 at 11:48 AM Tibor Digana  wrote:

> Hi,
>
> We solved 4 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12342871
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/i#issues/?jql=project+%3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1466/
>
> https://repository.apache.org/content/repositories/maven-1466/org/apache/maven/surefire/surefire/3.0.0-M1/surefire-3.0.0-M1-source-release.zip
>
> Source release checksum(s):
> surefire-3.0.0-M1-source-release.zip sha512:
> 2817639681b8597a58c38dbb5616c481c263f04b722f6fafcbc3f33c17f5d4b165572c38a83789ed80097047601505b339df015617603f754319dfadf3089b94
> surefire-3.0.0-M1-source-release.zip sha1:
> 72830b8d82bd068ab7da5eaeb4da8a66b8ea600d
>
> Staging site:
> http://maven.apache.org/surefire-archives/surefire-LATEST/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Cheers
> Tibor
>

Re: [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M1 - TAKE 2

[Tibor Digana]

Well, yes there should be two repos.
One is Maven Central and the second is the staging because the ASF staging
Nexus is not a copy of Central. There are only our Apache artifacts
deployed.

On Sun, Nov 4, 2018 at 5:12 PM Eric Lilja  wrote:

> +1 (non-binding)
>
> When testing on my personal projects, I did see one JUnit test failure
> on some very old code, a test which didn't have any problems on surefire
> 2.18.1-2.22.1. I examined the test and came to the conclusion that is
> was misbehaved as it tried to treat a classpath resource as a file
> system resource. I re-wrote the test and now it works on both both
> 3.0.0-M1 and older versions. But I guess others will see similar
> failures if they have poorly written code like I had in that testcase.
>
> I tested using a clean .m2 and ran a script which builds all my projects
> in dependency order. I noticed the process took a lot longer than usual
> after adding the staging repo, but I solved that by adding the default
> plugin repo as well.
>
> By the way, there were five issues closed, not four, which is not a bad
> thing, just a tiny error in the vote email text :)
>
> - Eric Lilja
>
> On 2018-11-04 11:48, Tibor Digana wrote:
> > Hi,
> >
> > We solved 4 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12342871
> >
> > There are still a couple of issues left in JIRA:
> >
> https://issues.apache.org/jira/i#issues/?jql=project+%3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1466/
> >
> https://repository.apache.org/content/repositories/maven-1466/org/apache/maven/surefire/surefire/3.0.0-M1/surefire-3.0.0-M1-source-release.zip
> >
> > Source release checksum(s):
> > surefire-3.0.0-M1-source-release.zip sha512:
> >
> 2817639681b8597a58c38dbb5616c481c263f04b722f6fafcbc3f33c17f5d4b165572c38a83789ed80097047601505b339df015617603f754319dfadf3089b94
> > surefire-3.0.0-M1-source-release.zip sha1:
> > 72830b8d82bd068ab7da5eaeb4da8a66b8ea600d
> >
> > Staging site:
> > http://maven.apache.org/surefire-archives/surefire-LATEST/
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > Cheers
> > Tibor
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M1 - TAKE 2

[Tibor Digana]

+1, we need to have more participants in the Vote.

On Sun, Nov 4, 2018 at 11:48 AM Tibor Digana  wrote:

> Hi,
>
> We solved 4 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12342871
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/i#issues/?jql=project+%3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1466/
>
> https://repository.apache.org/content/repositories/maven-1466/org/apache/maven/surefire/surefire/3.0.0-M1/surefire-3.0.0-M1-source-release.zip
>
> Source release checksum(s):
> surefire-3.0.0-M1-source-release.zip sha512:
> 2817639681b8597a58c38dbb5616c481c263f04b722f6fafcbc3f33c17f5d4b165572c38a83789ed80097047601505b339df015617603f754319dfadf3089b94
> surefire-3.0.0-M1-source-release.zip sha1:
> 72830b8d82bd068ab7da5eaeb4da8a66b8ea600d
>
> Staging site:
> http://maven.apache.org/surefire-archives/surefire-LATEST/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Cheers
> Tibor
>

Re: [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M1 - TAKE 2

[Tibor Digana]

The vote has passed with the following result:

+1 : Eric Lilja, Enrico Olivelli, Christian Stein, Tamás Cservenák, Olivier
Lamy, Tibor Digana, Sylwester Lachiewicz, Karl Heinz Marbaise
 0 : none
-1 : none.

PMC quorum: accomplished.


On Sun, Nov 4, 2018 at 11:48 AM Tibor Digana  wrote:

> Hi,
>
> We solved 4 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12342871
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/i#issues/?jql=project+%3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1466/
>
> https://repository.apache.org/content/repositories/maven-1466/org/apache/maven/surefire/surefire/3.0.0-M1/surefire-3.0.0-M1-source-release.zip
>
> Source release checksum(s):
> surefire-3.0.0-M1-source-release.zip sha512:
> 2817639681b8597a58c38dbb5616c481c263f04b722f6fafcbc3f33c17f5d4b165572c38a83789ed80097047601505b339df015617603f754319dfadf3089b94
> surefire-3.0.0-M1-source-release.zip sha1:
> 72830b8d82bd068ab7da5eaeb4da8a66b8ea600d
>
> Staging site:
> http://maven.apache.org/surefire-archives/surefire-LATEST/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Cheers
> Tibor
>

[RESULT] [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M1 - TAKE 2

[Tibor Digana]

 The vote has passed with the following result:

+1 : Eric Lilja, Enrico Olivelli, Christian Stein, Tamás Cservenák, Olivier
Lamy, Tibor Digana, Sylwester Lachiewicz, Karl Heinz Marbaise
 0 : none
-1 : none.

PMC quorum: accomplished.
I will promote the artifacts to the central repo.

-- 
Cheers
Tibor

Re: [VOTE] Release Apache Maven Shade Plugin version 3.2.1

[Tibor Digana]

+1

On Thu, Nov 8, 2018 at 6:25 AM Olivier Lamy  wrote:

> Hi,
>
> We solved 4 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12344059&styleName=Text&projectId=12317921
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/projects/MSHADE/issues/MSHADE-259?filter=allopenissues
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1467
>
> https://repository.apache.org/content/repositories/maven-1467/org/apache/maven/plugins/maven-shade-plugin/3.2.1/maven-shade-plugin-3.2.1-source-release.zip
>
> Source release checksum(s):
> maven-shade-plugin-3.2.1-source-release.zip.sha512:
>
>
> 6916f93db460b6c8e87dcc10a9f12fe789bfb6c81f7f77365bdcfad9c2fb04139808ca6bf2d56d160de0d29a01393cb3cfd233cace88f83dc6db978c14bc3f86
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-shade-plugin-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--
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

[ANN] Apache Maven Surefire Plugin 3.0.0-M1 Released

[Tibor Digana]

The Apache Maven team is pleased to announce the release of the Apache
Maven Surefire Plugin, version 3.0.0-M1

The release contains 5 bug fixes.
Again we received contributions from the community in form of bug reports
and bug fixes.
Thank you and keep them coming!

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

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


  org.apache.maven.plugins
  maven-surefire-plugin
  3.0.0-M1


or for failsafe:


  org.apache.maven.plugins
  maven-failsafe-plugin
  3.0.0-M1


or for surefire-report:


  org.apache.maven.plugins
  maven-surefire-report-plugin
  3.0.0-M1



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

Release Notes - Maven Surefire - Version 3.0.0-M1

Bug

[SUREFIRE-1466] - Surefire fails on a dummy:dummy dependency with a
authenticating proxy
[SUREFIRE-1588] - Surefire manifest jar classloading broken on latest
Debian/Ubuntu Java8

New Feature

[SUREFIRE-1493] - Maven Plugin API 3.0

Improvement

[SUREFIRE-1212] - @Component is deprecated. @Parameter should be used
instead.
[SUREFIRE-1474] - Java 1.7 as minimum

Enjoy,
-The Apache Maven team

Re: [VOTE] Release Apache Maven Shade Plugin version 3.2.1

[Tibor Digana]

+1
I do not see the previous history in this vote.

On Sat, Nov 10, 2018 at 2:34 PM Robert Scholte  wrote:

> +1
>
> On Thu, 08 Nov 2018 06:25:21 +0100, Olivier Lamy  wrote:
>
> > Hi,
> >
> > We solved 4 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12344059&styleName=Text&projectId=12317921
> >
> > There are still a couple of issues left in JIRA:
> >
> https://issues.apache.org/jira/projects/MSHADE/issues/MSHADE-259?filter=allopenissues
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1467
> >
> https://repository.apache.org/content/repositories/maven-1467/org/apache/maven/plugins/maven-shade-plugin/3.2.1/maven-shade-plugin-3.2.1-source-release.zip
> >
> > Source release checksum(s):
> > maven-shade-plugin-3.2.1-source-release.zip.sha512:
> >
> >
> 6916f93db460b6c8e87dcc10a9f12fe789bfb6c81f7f77365bdcfad9c2fb04139808ca6bf2d56d160de0d29a01393cb3cfd233cace88f83dc6db978c14bc3f86
> >
> > Staging site:
> > https://maven.apache.org/plugins-archives/maven-shade-plugin-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--
> > Olivier Lamy
> > http://twitter.com/olamy | http://linkedin.com/in/olamy
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: maven and java11

[Tibor Digana]

Hi Romain,

Which class could not be loaded?
JAXB or CDI class?
Some class from Maven dist or another one?

BR,
Tibor

On Tue, Nov 13, 2018 at 5:35 PM Romain Manni-Bucau 
wrote:

> Hi guys,
>
> did you plan to fix and upgrade classworlds to support java11?
>
> The trick is in org.codehaus.plexus.classworlds.realm.ClassRealm#findClass.
> This method assumes it can't be called outside loadClass(String[,boolean])
> but in j11 there is loadClass(String, String) defaulting to it as well so
> it just fails and breaks a lot of mojo. One lib using that feature is jaxb
> >= 2.3.0 so any mojo relying on jaxb 2.3 is broken.
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn  | Book
> <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
>

Re: [maven-surefire] 01/01: [SUREFIRE-1531] Option to disable Java 9 modules

[Tibor Digana]

Hi Robert,
Sorry I have not seen your email before.
" useModulePath " sounds good. I will rename the property if no objections.

BR
Tibor

On Sat, Nov 17, 2018 at 1:00 PM Robert Scholte  wrote:

> On Sat, 17 Nov 2018 11:34:43 +0100,  wrote:
>
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > tibordigana pushed a commit to branch SUREFIRE-1531
> > in repository https://gitbox.apache.org/repos/asf/maven-surefire.git
> >
> > commit f333b7d9e89ddfe086fd1cb930df0f77a0edbc96
> > Author: Lukas Krecan 
> > AuthorDate: Sun Jul 1 08:54:22 2018 +0200
> >
> > [SUREFIRE-1531] Option to disable Java 9 modules
> > ---
> >  .../maven/plugin/failsafe/IntegrationTestMojo.java | 23 ++
> >  .../plugin/surefire/AbstractSurefireMojo.java  | 53
> > +++---
> >  .../AbstractSurefireMojoJava7PlusTest.java | 12 +
> >  .../plugin/surefire/AbstractSurefireMojoTest.java  | 12 +
> >  .../maven/plugin/surefire/MojoMocklessTest.java| 12 +
> >  .../maven/plugin/surefire/SurefirePlugin.java  | 23 ++
> >  6 files changed, 119 insertions(+), 16 deletions(-)
> >
> > diff --git
> >
> a/maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java
>
> >
> b/maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java
> > index 52f9052..42b4cc6 100644
> > ---
> >
> a/maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java
> > +++
> >
> b/maven-failsafe-plugin/src/main/java/org/apache/maven/plugin/failsafe/IntegrationTestMojo.java
> > @@ -370,6 +370,17 @@ public class IntegrationTestMojo
> >  @Parameter( property = "failsafe.shutdown", defaultValue =
> > "testset" )
> >  private String shutdown;
> > +/**
> > + * Disables Jigsaw (Java 9) modular path even if
> > module-info.java is used in project.
> > + * 
> > + * Enabled by default.
> > + * If enabled, module-info.java exists and executes with
> JDK
> > 9+, modular path is used.
> > + *
> > + * @since 3.0.0-M2
> > + */
> > +@Parameter( property = "failsafe.useJigsawModules", defaultValue =
> > "true" )
> > +private boolean useJigsawModules;
> > +
>
>
> I think we should avoid referring to Jigsaw, that was the name of the
> project.
> I'd prefer useJavaModules instead, or maybe even useModulePath.
>
>
> >  @Override
> >  protected int getRerunFailingTestsCount()
> >  {
> > @@ -801,6 +812,18 @@ public class IntegrationTestMojo
> >  }
> > @Override
> > +protected boolean useJigsawModules()
> > +{
> > +return useJigsawModules;
> > +}
> > +
> > +@Override
> > +protected void setUseJigsawModules( boolean useJigsawModules )
> > +{
> > +this.useJigsawModules = useJigsawModules;
> > +}
> > +
> > +@Override
> >  protected final List suiteXmlFiles()
> >  {
> >  return hasSuiteXmlFiles() ? Arrays.asList( suiteXmlFiles ) :
> > Collections.emptyList();
> > diff --git
> >
> a/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
>
> >
> b/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
> > index 319f21d..4a1a213 100644
> > ---
> >
> a/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
> > +++
> >
> b/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java
> > @@ -104,6 +104,7 @@ import java.util.SortedSet;
> >  import java.util.TreeSet;
> >  import java.util.concurrent.ConcurrentHashMap;
> > +import static java.lang.Boolean.TRUE;
> >  import static java.lang.Thread.currentThread;
> >  import static java.util.Arrays.asList;
> >  import static java.util.Collections.addAll;
> > @@ -728,6 +729,9 @@ public abstract class AbstractSurefireMojo
> >  @Parameter( property = "dependenciesToScan" )
> >  private String[] dependenciesToScan;
> > +/**
> > + *
> > + */
> >  @Component
> >  private ToolchainManager toolchainManager;
> > @@ -787,6 +791,10 @@ public abstract class AbstractSurefireMojo
> > protected abstract String getReportSchemaLocation();
> > +protected abstract boolean useJigsawModules();
> > +
> > +protected abstract void setUseJigsawModules( boolean
> > useJigsawModules );
> > +
> >  /**
> >   * This plugin MOJO artifact.
> >   *
> > @@ -954,7 +962,7 @@ public abstract class AbstractSurefireMojo
> >  if ( !getTestClassesDirectory().exists()
> >  && ( getDependenciesToScan() == null ||
> > getDependenciesToScan().length == 0 ) )
> >  {
> > -if ( Boolean.TRUE.equals( getFailIfNoTests() ) )
> > +if ( TRUE.equals( getFailIfNoTests() ) )
> >  {
> >  throw new MojoFailureException( "No tests to run!" );
> >  }
> > @@ -1123,17 +1131,18 @@ public abstract class AbstractSurefireMoj

Relative paths to module are not resolved to absolute paths.

[Tibor Digana]

Here is a command launched by our user

mvn test --file ./integration-tests/pom.xml


We have the following issue in Surefire but I think the root cause is in
Maven core.
https://github.com/apache/maven-surefire/pull/204

We can make a workaround in Surefire but is that right to do?

I am convinced that the issue should be fixed in Maven and absolute paths
should be set in Mojo, see this field:

https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L716

Do we have such issues reported in Maven?
Any objections that the first place for fix is in Maven?

Cheers
Tibor

Re: Relative paths to module are not resolved to absolute paths.

[Tibor Digana]

It seems to be a trivial fix.
Can we assign MNG-6071[1][2] to the version 3.6.1[3] ?
Any objections?
[1]: https://github.com/apache/maven/pull/198
[2]: https://builds.apache.org/job/maven-box/job/maven/job/MNG-6520
[3]: https://jira.apache.org/jira/projects/MNG/versions/12344378



On Sun, Dec 2, 2018 at 1:31 PM Sylwester Lachiewicz 
wrote:

> Hi Tribor, I think it can be MNG-6071
> <https://jira.apache.org/jira/browse/MNG-6071> i made fix some time ago.
> BR
> Sylwester
>
>
> niedz., 2 gru 2018 o 11:11 Tibor Digana 
> napisał(a):
>
> > Here is a command launched by our user
> >
> > mvn test --file ./integration-tests/pom.xml
> >
> >
> > We have the following issue in Surefire but I think the root cause is in
> > Maven core.
> > https://github.com/apache/maven-surefire/pull/204
> >
> > We can make a workaround in Surefire but is that right to do?
> >
> > I am convinced that the issue should be fixed in Maven and absolute paths
> > should be set in Mojo, see this field:
> >
> >
> >
> https://github.com/apache/maven-surefire/blob/master/maven-surefire-common/src/main/java/org/apache/maven/plugin/surefire/AbstractSurefireMojo.java#L716
> >
> > Do we have such issues reported in Maven?
> > Any objections that the first place for fix is in Maven?
> >
> > Cheers
> > Tibor
> >
>

[VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M2

[Tibor Digana]

Hi,

We solved 15 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12344396

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/i#issues/?jql=project+%3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1472/
https://repository.apache.org/service/local/repositories/maven-1472/content/org/apache/maven/surefire/surefire/3.0.0-M2/surefire-3.0.0-M2-source-release.zip

Source release checksum(s):
surefire-3.0.0-M2-source-release.zip sha1:
421f6fda2367d128007b84b213690db348a8b2c6
surefire-3.0.0-M2-source-release.zip sha512:
ed02ac46eec7f632180e00487f65901420908ea5afc0e507350c2fa529a6278f73f32f915bcd1dee0bcdffbf391d045b9f3cfe557003d02af9e2dc91ddb31212

Staging site:
http://maven.apache.org/surefire-archives/surefire-LATEST/

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

Vote open for 72 hours.

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

BR
Tibor

Re: parallelise not overlapping tasks

[Tibor Digana]

In my projects, the most plugins use single execution.
External projects also have this kind of principle.
Thus we should have a look in those possibilities where the most plugins
can gain the performance.
Usually the compiler and tests take long.
I know that maven-compiler-plugin:3.8.1 will be incremental which is good
of course but we should perhaps continue with gaining the build performance.
If somebody has an idea on how to develop a compiler which partially
compiles a module depending on SCM changes, feel free to bring it to our
mailing list. The same with tests where the set of tests is changed
depending on SCM changes.

Cheers
Tibor


On Fri, Jan 19, 2018 at 2:21 PM Romain Manni-Bucau 
wrote:

> Hi guys,
>
> there is no way to parallelize not conflicting tasks for a same phase at
> the moment right? Any way it gets under the radar?
>
> A common example is to run all code analyzis concurrently (findbugs, pmd,
> checkstyle, ...) at the same time without waiting for one then the other
> etc since all can be very long.
>
> It could be nice an fancy to define part of the reactor parallelisablity in
> the pom, like:
>
> 
> 
> process-sources
> 
> 
>   ...
>   ...
>   ...
>   ...
> 
> 
>   ...
>   ...
>   ...
>   ...
> 
> 
> 
> 
>
> anything to enhance it?
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn 
>

Re: plugin:descriptor fails with java.util.NoSuchElementException

[Tibor Digana]

I do not think it can be such JVM issue with string concatenations, otherwise
all the world has the same problem.
This type of issue is usually caused by multiple writes from multiple
threads.
Try to log every method with Thread id and we should see multiple ids.
The java.io is supposed to be synchronized and thread safe. Therefore
PrintWriter is a wrapper of thread safe implementations.
We should use ConcurrentLinkedList and identify large functionality. If
large methods changes status at multiple lines, then this is a critical
section and the class must be synchronized.

Cheers
Tibor




--
Sent from: http://maven.40175.n5.nabble.com/Maven-Developers-f142166.html

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

Re: plugin:descriptor fails with java.util.NoSuchElementException

[Tibor Digana]

PluginDescriptorGenerator.writeDescriptor does not use Threads so it must
be the problem that the number of calls "endElement" is greater than calls
"startElement".
https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java


On Sat, Dec 8, 2018 at 11:46 AM Tibor Digana  wrote:

> I do not think it can be such JVM issue with string concatenations,
> otherwise
> all the world has the same problem.
> This type of issue is usually caused by multiple writes from multiple
> threads.
> Try to log every method with Thread id and we should see multiple ids.
> The java.io is supposed to be synchronized and thread safe. Therefore
> PrintWriter is a wrapper of thread safe implementations.
> We should use ConcurrentLinkedList and identify large functionality. If
> large methods changes status at multiple lines, then this is a critical
> section and the class must be synchronized.
>
> Cheers
> Tibor
>
>
>
>
> --
> Sent from: http://maven.40175.n5.nabble.com/Maven-Developers-f142166.html
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M2

[Tibor Digana]

@Eric Lilja
You use Pax. I guess you are refering to the problem with standard input
and standard output stream. The plugin says that the stream is corrupted.
Am I right?

Did you see the documentation here in this Vote? See the roadmap on the
front page
http://maven.apache.org/surefire-archives/surefire-LATEST/maven-surefire-plugin/index.html

This is long standing problem but it can be changed in new major version.
But I still think that Pax and Felix could provide some kind of abstraction
layer of these streams in testing purposes.

Cheers
Tibor





On Sat, Dec 8, 2018 at 7:20 PM Eric Lilja  wrote:

> +1 (non-binding)
>
> M2 is looking good on my projects, and I can't wait for the upcoming M3
> after M2, which I believe will solve the long-standing problems running
> Pax Exam tests (in the organization I work in we use 2.18.1 of surefire
> for Pax-Exam tests particularly, as no version of Surefire higher than
> that works well with it)
>
> - Eric L
>
> On 2018-12-05 23:26, Tibor Digana wrote:
> > Hi,
> >
> > We solved 15 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12344396
> >
> > There are still a couple of issues left in JIRA:
> >
> https://issues.apache.org/jira/i#issues/?jql=project+%3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1472/
> >
> https://repository.apache.org/service/local/repositories/maven-1472/content/org/apache/maven/surefire/surefire/3.0.0-M2/surefire-3.0.0-M2-source-release.zip
> >
> > Source release checksum(s):
> > surefire-3.0.0-M2-source-release.zip sha1:
> > 421f6fda2367d128007b84b213690db348a8b2c6
> > surefire-3.0.0-M2-source-release.zip sha512:
> >
> ed02ac46eec7f632180e00487f65901420908ea5afc0e507350c2fa529a6278f73f32f915bcd1dee0bcdffbf391d045b9f3cfe557003d02af9e2dc91ddb31212
> >
> > Staging site:
> > http://maven.apache.org/surefire-archives/surefire-LATEST/
> >
> > Guide to testing staged releases:
> > http://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > BR
> > Tibor
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M2

[Tibor Digana]

Perhaps it is the issue where JVM passed ASCII 0x04 == EOT to the stream
when we called System.exit in the fork. This has corrupted the stream too.
Is there any Jira issue refering to your problem?
https://en.wikipedia.org/wiki/End-of-Transmission_character
https://en.wikipedia.org/wiki/ASCII

On Sat, Dec 8, 2018 at 8:56 PM Eric Lilja  wrote:

> Hi, Tibor, yes I saw the milestone roadmap, that's why I am excited for
> M2 (which I tested both on private projects and at work), since it
> brings us closer to M3, which introduces changes which will be
> beneficial for Pax Exam (communicating with child processes through
> sockets).
> The problems with Pax Exam and surefire (for surefire version greater
> than 2.18.1), has varied over the versions (of surefire since 2.18.1).
> Before tests would often crash, now things work better but you often get
> this 30s timeout at the end. That's why we stayed with 2.18.1 in our
> organization.
>
> Great work on M2, looking forward to see it release and even more
> excited about M3!
>
> I didn't mean to hijack the vote email thread, and this will be last
> message on this thread about this topic. I was just excited about M2
> since it brings us a lot closer to M3, which I am even more excited
> about for the reason described above, and I wanted to share that
> excitement.
>
> Great work!
>
> - Eric L
>
> On 2018-12-08 19:40, Tibor Digana wrote:
> > @Eric Lilja
> > You use Pax. I guess you are refering to the problem with standard input
> > and standard output stream. The plugin says that the stream is corrupted.
> > Am I right?
> >
> > Did you see the documentation here in this Vote? See the roadmap on the
> > front page
> >
> http://maven.apache.org/surefire-archives/surefire-LATEST/maven-surefire-plugin/index.html
> >
> > This is long standing problem but it can be changed in new major version.
> > But I still think that Pax and Felix could provide some kind of
> abstraction
> > layer of these streams in testing purposes.
> >
> > Cheers
> > Tibor
> >
> >
> >
> >
> >
> > On Sat, Dec 8, 2018 at 7:20 PM Eric Lilja  wrote:
> >
> >> +1 (non-binding)
> >>
> >> M2 is looking good on my projects, and I can't wait for the upcoming M3
> >> after M2, which I believe will solve the long-standing problems running
> >> Pax Exam tests (in the organization I work in we use 2.18.1 of surefire
> >> for Pax-Exam tests particularly, as no version of Surefire higher than
> >> that works well with it)
> >>
> >> - Eric L
> >>
> >> On 2018-12-05 23:26, Tibor Digana wrote:
> >>> Hi,
> >>>
> >>> We solved 15 issues:
> >>>
> >>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12344396
> >>> There are still a couple of issues left in JIRA:
> >>>
> >>
> https://issues.apache.org/jira/i#issues/?jql=project+%3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC
> >>> Staging repo:
> >>> https://repository.apache.org/content/repositories/maven-1472/
> >>>
> >>
> https://repository.apache.org/service/local/repositories/maven-1472/content/org/apache/maven/surefire/surefire/3.0.0-M2/surefire-3.0.0-M2-source-release.zip
> >>> Source release checksum(s):
> >>> surefire-3.0.0-M2-source-release.zip sha1:
> >>> 421f6fda2367d128007b84b213690db348a8b2c6
> >>> surefire-3.0.0-M2-source-release.zip sha512:
> >>>
> >>
> ed02ac46eec7f632180e00487f65901420908ea5afc0e507350c2fa529a6278f73f32f915bcd1dee0bcdffbf391d045b9f3cfe557003d02af9e2dc91ddb31212
> >>> Staging site:
> >>> http://maven.apache.org/surefire-archives/surefire-LATEST/
> >>>
> >>> Guide to testing staged releases:
> >>> http://maven.apache.org/guides/development/guide-testing-releases.html
> >>>
> >>> Vote open for 72 hours.
> >>>
> >>> [ ] +1
> >>> [ ] +0
> >>> [ ] -1
> >>>
> >>> BR
> >>> Tibor
> >>>
> >>
> >> -
> >> 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 Surefire Plugin version 3.0.0-M2

[Tibor Digana]

+1

On Wed, Dec 5, 2018 at 11:26 PM Tibor Digana  wrote:

> Hi,
>
> We solved 15 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12344396
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/i#issues/?jql=project+%3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1472/
>
> https://repository.apache.org/service/local/repositories/maven-1472/content/org/apache/maven/surefire/surefire/3.0.0-M2/surefire-3.0.0-M2-source-release.zip
>
> Source release checksum(s):
> surefire-3.0.0-M2-source-release.zip sha1:
> 421f6fda2367d128007b84b213690db348a8b2c6
> surefire-3.0.0-M2-source-release.zip sha512:
> ed02ac46eec7f632180e00487f65901420908ea5afc0e507350c2fa529a6278f73f32f915bcd1dee0bcdffbf391d045b9f3cfe557003d02af9e2dc91ddb31212
>
> Staging site:
> http://maven.apache.org/surefire-archives/surefire-LATEST/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> BR
> Tibor
>

Re: [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M2

[Tibor Digana]

Thank You!
PMC quorum reached: Krystian Nowak,Romain Manni-Bucau, Enrico Olivelli,
Olivier Lamy, Karl Heinz Marbaise, Francois Papon, Eric Lilja, Christian
Stein, Tibor Digana.

On Sun, Dec 9, 2018 at 10:28 AM Tibor Digana  wrote:

> +1
>
> On Wed, Dec 5, 2018 at 11:26 PM Tibor Digana 
> wrote:
>
>> Hi,
>>
>> We solved 15 issues:
>>
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12344396
>>
>> There are still a couple of issues left in JIRA:
>>
>> https://issues.apache.org/jira/i#issues/?jql=project+%3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-1472/
>>
>> https://repository.apache.org/service/local/repositories/maven-1472/content/org/apache/maven/surefire/surefire/3.0.0-M2/surefire-3.0.0-M2-source-release.zip
>>
>> Source release checksum(s):
>> surefire-3.0.0-M2-source-release.zip sha1:
>> 421f6fda2367d128007b84b213690db348a8b2c6
>> surefire-3.0.0-M2-source-release.zip sha512:
>> ed02ac46eec7f632180e00487f65901420908ea5afc0e507350c2fa529a6278f73f32f915bcd1dee0bcdffbf391d045b9f3cfe557003d02af9e2dc91ddb31212
>>
>> Staging site:
>> http://maven.apache.org/surefire-archives/surefire-LATEST/
>>
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> BR
>> Tibor
>>
>

[RESULT] [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M2

[Tibor Digana]

Hi,

The vote has passed with the following result:

+1 :  Krystian Nowak,Romain Manni-Bucau, Enrico Olivelli, Olivier Lamy,
Karl Heinz Marbaise, Francois Papon, Eric Lilja, Christian Stein, Tibor
Digana.

PMC quorum reached.

I will promote the artifacts to the central repo.

Cheers
Tibor Digana

Re: [VOTE] Release Apache Maven JAR Plugin version 3.1.1

[Tibor Digana]

+1
both checksums match, build success from src-zip.

On Sat, Dec 8, 2018 at 1:02 PM Karl Heinz Marbaise 
wrote:

> Hi,
>
> We solved 7 issues:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317526%20AND%20fixVersion%20%3D%2012343046%20ORDER%20BY%20priority%20DESC%2C%20key%20ASC
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MJAR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1473
>
>
> https://repository.apache.org/content/repositories/maven-1473/org/apache/maven/plugins/maven-jar-plugin/3.1.1/maven-jar-plugin-3.1.1-source-release.zip
>
> Source release checksum(s):
> maven-jar-plugin-3.1.1-source-release.zip sha1:
> 391b98c141182f79a0577d94ddaa2cef8a33d0ba
>
> maven-jar-plugin-3.1.1-source-release.zip sha512:
>
> 92eedaee200c747c6a533562ae6b0bae03b6a39d47bee8e13c96149280b6fd728021c218b37433f3a6a321210575b5e50cb2fd871a7aa9a427f2a5120fbdf36a
>
> Staging site:
> http://maven.apache.org/plugins-archives/maven-jar-plugin-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
>
> 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 Help Plugin version 3.1.1

[Tibor Digana]

 +1
both checksums match, build success from src-zip.

On Sat, Dec 8, 2018 at 1:24 PM Karl Heinz Marbaise 
wrote:

> Hi,
>
> We solved 6 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317522&version=12343422&styleName=text
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MPH%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC%2C%20updated%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1474
>
> https://repository.apache.org/content/repositories/maven-1474/org/apache/maven/plugins/maven-help-plugin/3.1.1/maven-help-plugin-3.1.1-source-release.zip
>
> Source release checksum(s):
> maven-help-plugin-3.1.1-source-release.zip sha1:
> 634d625cef141bd6f79477d1d8f41226ec96c4a6
>
> maven-help-plugin-3.1.1-source-release.zip sha512:
>
> 286a81f0c86078fc7233f8eaf46bed9de7aa2358a4a8752b5926564c1adde6c73f5fd29ab8198441cae02ddd5e0862090a06c25482c089744b2f1af7a107f396
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-help-plugin-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
>
> 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 Shared Component: Maven Dependency Analyzer 1.11.0

[Tibor Digana]

 +1
both checksums match, build success from src-zip.

On Sat, Dec 8, 2018 at 1:40 PM Karl Heinz Marbaise 
wrote:

> Hi,
>
> We solved 4 issues:
> https://issues.apache.org/jira/projects/MSHARED/versions/12344434
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20XX%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1475/
>
>
> https://repository.apache.org/content/repositories/maven-1475/org/apache/maven/shared/maven-dependency-analyzer/1.11.0/maven-dependency-analyzer-1.11.0-source-release.zip
>
> Source release checksum(s):
> maven-dependency-analyzer-1.11.0-source-release.zip sha1:
> b60b75d2950f7dbf7716a0adbf0bc4ea482933f9
> maven-dependency-analyzer-1.11.0-source-release.zip sha512:
>
> 82c26f2279e0fb3fa99315c2236e777beaf880d7f57c9641a99d89327eef7f152991423488a6de01affd393ee6c370edeea4626df4f58eca59e54b32e25fc8c1
>
> Staging site:
> https://maven.apache.org/shared-archives/maven-dependency-analyzer-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
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Cheers
Tibor

Re: plugin:descriptor fails with java.util.NoSuchElementException

[Tibor Digana]

Is the issue found on Oracle Jira or bug report?
This might to do with some build version in Java 1.7. Usually they fix it
right after since this bug hits the JVM stability and Oracle is paying an
attention to JIT stability.



On Sun, Dec 9, 2018 at 4:36 PM Robert Scholte  wrote:

> I have to admit that it still looks weird, but the open and close tags
> are
> balanced.
> Also notice that only Java 7 (sometimes) hits this issue.
> Gabriel was able to provide a test that always fails on Java 7, not on
> the
> other JDKs.
> It must have to do with optimization when the JVM is warmed up.
>
> Anyway, the provided patch takes away the failures and the writing to the
> stream is now cleaner too.
> You might want to dive into this, but I wonder if it is worth it.
> Issue will be resolved with the next release.
>
> thanks,
> Robert
>
> On Sat, 08 Dec 2018 12:44:40 +0100, Enrico Olivelli 
>
> wrote:
>
> > +1 for Tibor's explanation.
> > Enrico
> >
> > Il sab 8 dic 2018, 12:29 Tibor Digana  ha
> > scritto:
> >
> >> PluginDescriptorGenerator.writeDescriptor does not use Threads so it
> >> must
> >> be the problem that the number of calls "endElement" is greater than
> >> calls
> >> "startElement".
> >>
> >>
> https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java
> >>
> >>
> >> On Sat, Dec 8, 2018 at 11:46 AM Tibor Digana 
> >> wrote:
> >>
> >> > I do not think it can be such JVM issue with string concatenations,
> >> > otherwise
> >> > all the world has the same problem.
> >> > This type of issue is usually caused by multiple writes from multiple
> >> > threads.
> >> > Try to log every method with Thread id and we should see multiple ids.
> >> > The java.io is supposed to be synchronized and thread safe. Therefore
> >> > PrintWriter is a wrapper of thread safe implementations.
> >> > We should use ConcurrentLinkedList and identify large functionality.
> >> If
> >> > large methods changes status at multiple lines, then this is a
> >> critical
> >> > section and the class must be synchronized.
> >> >
> >> > Cheers
> >> > Tibor
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Sent from:
> >> http://maven.40175.n5.nabble.com/Maven-Developers-f142166.html
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> > For additional commands, e-mail: dev-h...@maven.apache.org
> >> >
> >> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: plugin:descriptor fails with java.util.NoSuchElementException

[Tibor Digana]

I have checked everything, including the commit hash, the change, trigger
and log.
It's undeterministic run as you said.
What happens if you simply use ArrayDeque instead of LinkedList?
How can we identify it's the problem of strings conc and List impl?
Perhaps only by giving a try several times and avoid influence after these
tests.


On Sun, Dec 9, 2018 at 6:29 PM Robert Scholte  wrote:

> For your interest, just hit it again:
>
>
> https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/MJAVADOC-543/
>
> First run only fails for Build windows-jdk7-m3.2.x_build, with the
> j.u.NoSuchElementException
> A rerun without any changes,now it luckily succeeds.
>
> Robert
>
> On Sun, 09 Dec 2018 17:35:45 +0100, Tibor Digana 
>
> wrote:
>
> > Is the issue found on Oracle Jira or bug report?
> > This might to do with some build version in Java 1.7. Usually they fix it
> > right after since this bug hits the JVM stability and Oracle is paying an
> > attention to JIT stability.
> >
> >
> >
> > On Sun, Dec 9, 2018 at 4:36 PM Robert Scholte 
> > wrote:
> >
> >> I have to admit that it still looks weird, but the open and close tags
> >> are
> >> balanced.
> >> Also notice that only Java 7 (sometimes) hits this issue.
> >> Gabriel was able to provide a test that always fails on Java 7, not on
> >> the
> >> other JDKs.
> >> It must have to do with optimization when the JVM is warmed up.
> >>
> >> Anyway, the provided patch takes away the failures and the writing to
> >> the
> >> stream is now cleaner too.
> >> You might want to dive into this, but I wonder if it is worth it.
> >> Issue will be resolved with the next release.
> >>
> >> thanks,
> >> Robert
> >>
> >> On Sat, 08 Dec 2018 12:44:40 +0100, Enrico Olivelli
> >> 
> >>
> >> wrote:
> >>
> >> > +1 for Tibor's explanation.
> >> > Enrico
> >> >
> >> > Il sab 8 dic 2018, 12:29 Tibor Digana  ha
> >> > scritto:
> >> >
> >> >> PluginDescriptorGenerator.writeDescriptor does not use Threads so it
> >> >> must
> >> >> be the problem that the number of calls "endElement" is greater than
> >> >> calls
> >> >> "startElement".
> >> >>
> >> >>
> >>
> https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java
> >> >>
> >> >>
> >> >> On Sat, Dec 8, 2018 at 11:46 AM Tibor Digana  >
> >> >> wrote:
> >> >>
> >> >> > I do not think it can be such JVM issue with string concatenations,
> >> >> > otherwise
> >> >> > all the world has the same problem.
> >> >> > This type of issue is usually caused by multiple writes from
> >> multiple
> >> >> > threads.
> >> >> > Try to log every method with Thread id and we should see multiple
> >> ids.
> >> >> > The java.io is supposed to be synchronized and thread safe.
> >> Therefore
> >> >> > PrintWriter is a wrapper of thread safe implementations.
> >> >> > We should use ConcurrentLinkedList and identify large
> >> functionality.
> >> >> If
> >> >> > large methods changes status at multiple lines, then this is a
> >> >> critical
> >> >> > section and the class must be synchronized.
> >> >> >
> >> >> > Cheers
> >> >> > Tibor
> >> >> >
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Sent from:
> >> >> http://maven.40175.n5.nabble.com/Maven-Developers-f142166.html
> >> >> >
> >> >> >
> >> -
> >> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> >> > For additional commands, e-mail: dev-h...@maven.apache.org
> >> >> >
> >> >> >
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: plugin:descriptor fails with java.util.NoSuchElementException

[Tibor Digana]

One more hint. What if the start element was added as NULL by an accident?
What if the impl of LinkedList ignores such element and then there are N -
1 elements to remove.
Adding an asset may help to find it.

On Sun, Dec 9, 2018 at 8:00 PM Tibor Digana  wrote:

> I have checked everything, including the commit hash, the change, trigger
> and log.
> It's undeterministic run as you said.
> What happens if you simply use ArrayDeque instead of LinkedList?
> How can we identify it's the problem of strings conc and List impl?
> Perhaps only by giving a try several times and avoid influence after these
> tests.
>
>
> On Sun, Dec 9, 2018 at 6:29 PM Robert Scholte 
> wrote:
>
>> For your interest, just hit it again:
>>
>>
>> https://builds.apache.org/job/maven-box/job/maven-javadoc-plugin/job/MJAVADOC-543/
>>
>> First run only fails for Build windows-jdk7-m3.2.x_build, with the
>> j.u.NoSuchElementException
>> A rerun without any changes,now it luckily succeeds.
>>
>> Robert
>>
>> On Sun, 09 Dec 2018 17:35:45 +0100, Tibor Digana 
>>
>> wrote:
>>
>> > Is the issue found on Oracle Jira or bug report?
>> > This might to do with some build version in Java 1.7. Usually they fix
>> it
>> > right after since this bug hits the JVM stability and Oracle is paying
>> an
>> > attention to JIT stability.
>> >
>> >
>> >
>> > On Sun, Dec 9, 2018 at 4:36 PM Robert Scholte 
>> > wrote:
>> >
>> >> I have to admit that it still looks weird, but the open and close tags
>> >> are
>> >> balanced.
>> >> Also notice that only Java 7 (sometimes) hits this issue.
>> >> Gabriel was able to provide a test that always fails on Java 7, not on
>> >> the
>> >> other JDKs.
>> >> It must have to do with optimization when the JVM is warmed up.
>> >>
>> >> Anyway, the provided patch takes away the failures and the writing to
>> >> the
>> >> stream is now cleaner too.
>> >> You might want to dive into this, but I wonder if it is worth it.
>> >> Issue will be resolved with the next release.
>> >>
>> >> thanks,
>> >> Robert
>> >>
>> >> On Sat, 08 Dec 2018 12:44:40 +0100, Enrico Olivelli
>> >> 
>> >>
>> >> wrote:
>> >>
>> >> > +1 for Tibor's explanation.
>> >> > Enrico
>> >> >
>> >> > Il sab 8 dic 2018, 12:29 Tibor Digana  ha
>> >> > scritto:
>> >> >
>> >> >> PluginDescriptorGenerator.writeDescriptor does not use Threads so it
>> >> >> must
>> >> >> be the problem that the number of calls "endElement" is greater than
>> >> >> calls
>> >> >> "startElement".
>> >> >>
>> >> >>
>> >>
>> https://github.com/apache/maven-plugin-tools/blob/master/maven-plugin-tools-generators/src/main/java/org/apache/maven/tools/plugin/generator/PluginDescriptorGenerator.java
>> >> >>
>> >> >>
>> >> >> On Sat, Dec 8, 2018 at 11:46 AM Tibor Digana <
>> tibordig...@apache.org>
>> >> >> wrote:
>> >> >>
>> >> >> > I do not think it can be such JVM issue with string
>> concatenations,
>> >> >> > otherwise
>> >> >> > all the world has the same problem.
>> >> >> > This type of issue is usually caused by multiple writes from
>> >> multiple
>> >> >> > threads.
>> >> >> > Try to log every method with Thread id and we should see
>> multiple
>> >> ids.
>> >> >> > The java.io is supposed to be synchronized and thread safe.
>> >> Therefore
>> >> >> > PrintWriter is a wrapper of thread safe implementations.
>> >> >> > We should use ConcurrentLinkedList and identify large
>> >> functionality.
>> >> >> If
>> >> >> > large methods changes status at multiple lines, then this is a
>> >> >> critical
>> >> >> > section and the class must be synchronized.
>> >> >> >
>> >> >> > Cheers
>> >> >> > Tibor
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Sent from:
>> >> >> http://maven.40175.n5.nabble.com/Maven-Developers-f142166.html
>> >> >> >
>> >> >> >
>> >> -
>> >> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> >> >> > For additional commands, e-mail: dev-h...@maven.apache.org
>> >> >> >
>> >> >> >
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> >> For additional commands, e-mail: dev-h...@maven.apache.org
>> >>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>

Re: [VOTE] Release Apache Maven Archetype Bundles version 1.4

[Tibor Digana]

Hi Herve

I have executed the build (mvn verify -P run-its) from the src zip but the
build failed:
Archetype IT 'it-basic' failed: Some content are not equals

Can you check it in the logs attached?

Thx

On Sun, Dec 9, 2018 at 4:48 PM Hervé BOUTEMY  wrote:

> Hi,
>
> We solved 3 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317123&version=12343035&styleName=Text
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MARCHETYPES%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1476/
>
> https://repository.apache.org/content/repositories/maven-1476/org/apache/maven/archetypes/maven-archetype-bundles/1.4/maven-archetype-bundles-1.4-source-release.zip
>
> Source release checksum(s):
> maven-archetype-bundles-1.4-source-release.zip sha512:
> 7afb337cfa33b2e827d4e97bdcc687c8aee708974504c134d972ddd9a356ac13c36f8acceac128815905ef30e4939a25dc3721f4465f4f81f0c9dc0966aa5cb9
>
> Staging site:
> https://maven.apache.org/archetypes-archives/archetypes-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
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] 
[INFO] Reactor Build Order:
[INFO] 
[INFO] Apache Maven Archetypes
[INFO] Maven Archetype Archetype
[INFO] Maven Simple J2EE Archetype
[INFO] Maven Plugin Archetype
[INFO] Maven Plugin Site Archetype
[INFO] Maven Portlet Archetype
[INFO] Maven Quickstart Archetype
[INFO] Maven Simple Project Archetype
[INFO] Maven Site Archetype
[INFO] Maven Archetype for Simple Site
[INFO] Maven Site Skin Archetype
[INFO] Maven Webapp Archetype
[INFO] 
[INFO] 
[INFO] Building Apache Maven Archetypes 1.4
[INFO] 
[INFO] 
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-version) @ 
maven-archetype-bundles ---
[INFO] 
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-bytecode-version) @ 
maven-archetype-bundles ---
[INFO] 
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (ban-known-bad-maven-versions) @ 
maven-archetype-bundles ---
[INFO] 
[INFO] --- apache-rat-plugin:0.12:check (rat-check) @ maven-archetype-bundles 
---
[INFO] RAT will not execute since it is configured to be skipped via system 
property 'rat.skip'.
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (process-resource-bundles) 
@ maven-archetype-bundles ---
[INFO] 
[INFO] --- maven-site-plugin:3.7.1:attach-descriptor (attach-descriptor) @ 
maven-archetype-bundles ---
[INFO] Attaching 'src\site\site.xml' site descriptor with classifier 'site'.
[INFO] 
[INFO] --- maven-checkstyle-plugin:3.0.0:check (checkstyle-check) @ 
maven-archetype-bundles ---
[INFO] 
[INFO] 
[INFO] Building Maven Archetype Archetype 1.4
[INFO] 
[INFO] 
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-maven-version) @ 
maven-archetype-archetype ---
[INFO] 
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (enforce-bytecode-version) @ 
maven-archetype-archetype ---
[INFO] 
[INFO] --- maven-enforcer-plugin:1.4.1:enforce (ban-known-bad-maven-versions) @ 
maven-archetype-archetype ---
[INFO] 
[INFO] --- apache-rat-plugin:0.12:check (rat-check) @ maven-archetype-archetype 
---
[INFO] RAT will not execute since it is configured to be skipped via system 
property 'rat.skip'.
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.5:process (process-resource-bundles) 
@ maven-archetype-archetype ---
[INFO] 
[INFO] --- maven-resources-plugin:3.1.0:resources (default-resources) @ 
maven-archetype-archetype ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 6 resources
[INFO] Copying 2 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-resources-plugin:3.1.0:testResources (default-testResources) @ 
maven-archetype-archetype ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 2 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-archetype-plugin:3.0.1:jar (default-jar) @ 
maven-archetype-archetype ---
[INFO] Building archetype jar: 
D:\vcs\release\maven-archetype-bundles-1.4\maven-archetype-archetype\target\maven-archetype-ar

[ANN] Apache Maven Surefire Plugin 3.0.0-M2 Released

[Tibor Digana]

The Apache Maven team is pleased to announce the release of the Apache
Maven Surefire Plugin, version 3.0.0-M2.

The release contains 15 bug fixes.
Again we received contributions from the community in form of bug reports
and bug fixes.
Thank you and keep them coming!

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

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


  org.apache.maven.plugins
  maven-surefire-plugin
  3.0.0-M2


or for failsafe:


  org.apache.maven.plugins
  maven-failsafe-plugin
  3.0.0-M2


or for surefire-report:


  org.apache.maven.plugins
  maven-surefire-report-plugin
  3.0.0-M2



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

Release Notes - Maven Surefire - Version 3.0.0-M2

Bug

   - [SUREFIRE-1568 ]
   - Versions 2.21 and higher doesn't work with junit-platform for Java 9
   module
   - [SUREFIRE-1593 ]
   - 3.0.0-M1 produces invalid code sources on Windows
   - [SUREFIRE-1602 ]
   - Surefire fails loading class ForkedBooter when using a sub-directory pom
   file and a local maven repo
   - [SUREFIRE-1605 ]
   - NoClassDefFoundError (RunNotifier) with JDK 11
   - [SUREFIRE-1606 ]
   - maven-shared-utils must not be on provider's classpath

New Feature

   - [SUREFIRE-1531 ]
   - Option to switch-off Java 9 modules

Improvement

   - [SUREFIRE-1590 ]
   - Deploy multiple versions of Report XSD
   - [SUREFIRE-1591 ]
   - Java 1.7 feature Diamonds replaced Generics
   - [SUREFIRE-1594 ]
   - Java 1.7 feature try-catch - multiple exceptions in one catch
   - [SUREFIRE-1595 ]
   - Java 1.7 feature System.lineSeparator()
   - [SUREFIRE-1597 ]
   - ModularClasspathForkConfiguration with debug logs (@args file and its
   path on file system)

Test

   - [SUREFIRE-1596 ]
   - Unnecessary check JAVA_RECENT == JAVA_1_7 in unit tests
   - [SUREFIRE-1598 ]
   - Fixed typo in assertion statement in integration test
   Surefire855AllowFailsafeUseArtifactFileIT

Task

   - [SUREFIRE-1600 ]
   - Surefire Project using surefire:2.12.4 is not fully able to work with JDK
   10+ on internal build system. Therefore surefire-shadefire should go with
   Surefire:3.0.0-M2.
   - [SUREFIRE-1607 ]
   - Roadmap on Project Site



Enjoy,

-The Apache Maven team

Re: [VOTE] Release Apache Maven Archetype Bundles version 1.4

[Tibor Digana]

+1: here is mine

On Sun, Dec 9, 2018 at 4:48 PM Hervé BOUTEMY  wrote:

> Hi,
>
> We solved 3 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317123&version=12343035&styleName=Text
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MARCHETYPES%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1476/
>
> https://repository.apache.org/content/repositories/maven-1476/org/apache/maven/archetypes/maven-archetype-bundles/1.4/maven-archetype-bundles-1.4-source-release.zip
>
> Source release checksum(s):
> maven-archetype-bundles-1.4-source-release.zip sha512:
> 7afb337cfa33b2e827d4e97bdcc687c8aee708974504c134d972ddd9a356ac13c36f8acceac128815905ef30e4939a25dc3721f4465f4f81f0c9dc0966aa5cb9
>
> Staging site:
> https://maven.apache.org/archetypes-archives/archetypes-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
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Archetype Bundles version 1.4

[Tibor Digana]

+1

On Wed, Dec 12, 2018 at 5:49 PM Karl Heinz Marbaise 
wrote:

> Hi,
>
> here is my +1
>
> Kind regards
> Karl Heinz Marbaise
> On 09/12/18 16:41, Hervé BOUTEMY wrote:
> > Hi,
> >
> > We solved 3 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317123&version=12343035&styleName=Text
> >
> > There are still a couple of issues left in JIRA:
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MARCHETYPES%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1476/
> >
> https://repository.apache.org/content/repositories/maven-1476/org/apache/maven/archetypes/maven-archetype-bundles/1.4/maven-archetype-bundles-1.4-source-release.zip
> >
> > Source release checksum(s):
> > maven-archetype-bundles-1.4-source-release.zip sha512:
> 7afb337cfa33b2e827d4e97bdcc687c8aee708974504c134d972ddd9a356ac13c36f8acceac128815905ef30e4939a25dc3721f4465f4f81f0c9dc0966aa5cb9
> >
> > Staging site:
> > https://maven.apache.org/archetypes-archives/archetypes-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
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Artifact Transfer version 0.10.1

[Tibor Digana]

+1

On Sun, Dec 16, 2018 at 1:13 PM Robert Scholte  wrote:

> Hi,
>
> We solved 5 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12343568&styleName=Text
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317922%20AND%20component%20%3D%20maven-artifact-transfer%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1478
>
> https://repository.apache.org/content/repositories/maven-1478/org/apache/maven/shared/maven-artifact-transfer/0.10.1/maven-artifact-transfer-0.10.1-source-release.zip
>
> Source release checksum(s):
> maven-artifact-transfer-0.10.1-source-release.zip sha512:
>
> 725da8d7e9dfcb8e243424fc6cf655a07846e71d44d06250966063035ed694dce8c0133259f5f0b6a5350dae1b7259e90cbbcf0464552a30e8b8610b54da8a72
>
> Staging site:
> https://maven.apache.org/shared-archives\maven-artifact-transfer-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
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Common Artifact Filters version 3.1.0

[Tibor Digana]

+1

On Sat, Dec 15, 2018 at 12:44 PM Robert Scholte 
wrote:

> Hi,
>
> We solved 2 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12338638&styleName=Text
>
> There are NO MORE issues left in JIRA (the only one left is doing this
> release):
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317922%20AND%20component%20%3D%20maven-common-artifact-filters%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1477/
>
> https://repository.apache.org/content/repositories/maven-1477/org/apache/maven/shared/maven-common-artifact-filters/3.1.0/maven-common-artifact-filters-3.1.0-source-release.zip
>
> Source release checksum(s):
> maven-common-artifact-filters-3.1.0-source-release.zip sha512:
>
> 650ebbd08ff7160d82f80890a78722adf36fb424fdf0005891417ae0276d178b8e1ea9cfa22f49e76bea552fc43b698b21261dac2945c6801fac237cc483f4f0
>
> Staging site:
>
> https://maven.apache.org/shared-archives\maven-common-artifact-filters-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
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: GitHub "merge button" is active ?

[Tibor Digana]

Try and you will see what happens.
I do not use it because I am the old school using IDEA and command line. I
need to see the code in IDE because this Diff in GitHub does not show me
the changes as good as IDEA does.

On Wed, Dec 19, 2018 at 6:01 PM Enrico Olivelli  wrote:

> self anwsered:
> just read the docs here:
> https://gitbox.apache.org/
>
> All repositories present on gitbox are available on GitHub with
> write-access enabled, including rights to open/close/merge pull
> requests and address issue
>
>
> So back to the questionshould I use the "merge button" ?
>
> Enrico
>
> Il giorno mer 19 dic 2018 alle ore 17:59 Enrico Olivelli
>  ha scritto:
> >
> >  t"
> >
> > Il giorno mer 19 dic 2018 alle ore 17:56 Karl Heinz Marbaise
> >  ha scritto:
> > >
> > > Hi,
> > >
> > > On 19/12/18 17:10, Enrico Olivelli wrote:
> > > > Is github the primary "source of truth" ?
> > > > I was thinking that it is a mirror for ASF repo.
> > > >
> > > > If github is the primary repo that things are really easier.
> > > >
> > > > So which is the 'official' position ? I did not find it on
> "Committers guide"
> > >
> > > The offical truth are the git repositories at gitbox.apache.org/...
> > >
> > > GitHub are only mirrors...
> >
> > Karl,
> > So how the 'merge button' can work ?
> >
> > for instance on Apache BookKeeper we have switched to github and the
> > "Merge button" works as expected.
> > If in Maven we are not using github as primary we should not "allow" it.
> >
> > Something is not clear to me "gitbox.apache.org" is the new repository
> > for projects with the new github based flow.
> > So are you sure that gitbox.apache.org is not the mirror and/or there
> > is no magic multi-master sync setup ?
> >
> >
> > Enrico
> >
> > >
> > > Kind regards
> > > Karl Heinz Marbaise
> > > >
> > > > Enrico
> > > >
> > > >
> > > >
> > > > Il giorno mer 19 dic 2018 alle ore 17:08 Christian Stein
> > > >  ha scritto:
> > > >>
> > > >> I do use the button now and then.
> > > >>
> > > >> I'd vote to install https://github.com/apps/wip which disables the
> button
> > > >> on GitHub ... "allow authors of pull requests to set status to
> pending
> > > >> while still working on it."
> > > >>
> > > >> Cheers,
> > > >> Christian
> > > >>
> > > >> On Wed, Dec 19, 2018 at 3:57 PM Enrico Olivelli <
> eolive...@gmail.com> wrote:
> > > >>
> > > >>> Hi,
> > > >>> I see that on github we have the 'Merge Button"
> > > >>>
> > > >>> like here:
> > > >>> https://github.com/apache/maven-shade-plugin/pull/12
> > > >>>
> > > >>> We are not using that tool, aren't we ?
> > > >>>
> > > >>> Can we ask INFRA to hide it ?
> > > >>>
> > > >>> Enrico
> > > >>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

[VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M3

[Tibor Digana]

Hi,

We solved 6 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12342872

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/i#issues/?jql=project+%3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC

Staging repo:
https://repository.apache.org/content/repositories/maven-1479
https://repository.apache.org/content/repositories/maven-1479/org/apache/maven/surefire/surefire/3.0.0-M3/surefire-3.0.0-M3-source-release.zip

Source release checksum(s):
surefire-3.0.0-M3-source-release.zip sha1:
4d1187b9c1f1922d13ac25d4538f30225ea8e27a
surefire-3.0.0-M3-source-release.zip sha512:
c13d24c10ec59278113f862702538770fccf1f816a7803dc7adaaa9f90ab0a76bad0d83526cd4ce80d3891e9364f4079020b70478dede0e330f98f8f79afae54

Staging site:
http://maven.apache.org/surefire-archives/surefire-LATEST/

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

Vote open for 72 hours.

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

Cheers
Tibor

Re: [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M3

[Tibor Digana]

Thx Enrico, Christian for testing.
This is not an ideal time for the release since it's Christmas season.
I hope we will get some PMC members and common users in this Vote as well.

Cheers
Tibor

On Fri, Dec 21, 2018 at 1:16 PM Enrico Olivelli  wrote:

> +1 (non binding)
> built from source, all its are passing on my Linux
>
> Enrico
>
> Il giorno gio 20 dic 2018 alle ore 11:35 Christian Stein
>  ha scritto:
> >
> > +1
> >
> > Cheers,
> > Christian
> >
> > Simple project using Surefire 3.0.0-M3:
> >
> https://github.com/junit-team/junit5-samples/commit/a8660d636058a52fc68f7a9d6a5a11b42ee44303
> > Result: https://travis-ci.org/junit-team/junit5-samples/jobs/470432909
> >
> > On Thu, Dec 20, 2018 at 10:48 AM Tibor Digana 
> > wrote:
> >
> > > Hi,
> > >
> > > We solved 6 issues:
> > >
> > >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12342872
> > >
> > > There are still a couple of issues left in JIRA:
> > >
> > >
> https://issues.apache.org/jira/i#issues/?jql=project+%3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/maven-1479
> > >
> > >
> https://repository.apache.org/content/repositories/maven-1479/org/apache/maven/surefire/surefire/3.0.0-M3/surefire-3.0.0-M3-source-release.zip
> > >
> > > Source release checksum(s):
> > > surefire-3.0.0-M3-source-release.zip sha1:
> > > 4d1187b9c1f1922d13ac25d4538f30225ea8e27a
> > > surefire-3.0.0-M3-source-release.zip sha512:
> > >
> > >
> c13d24c10ec59278113f862702538770fccf1f816a7803dc7adaaa9f90ab0a76bad0d83526cd4ce80d3891e9364f4079020b70478dede0e330f98f8f79afae54
> > >
> > > Staging site:
> > > http://maven.apache.org/surefire-archives/surefire-LATEST/
> > >
> > > Guide to testing staged releases:
> > > http://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open for 72 hours.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > > Cheers
> > > Tibor
> > >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M3

[Tibor Digana]

+1

On Thu, Dec 20, 2018 at 10:47 AM Tibor Digana 
wrote:

> Hi,
>
> We solved 6 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12342872
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/i#issues/?jql=project+%3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1479
>
> https://repository.apache.org/content/repositories/maven-1479/org/apache/maven/surefire/surefire/3.0.0-M3/surefire-3.0.0-M3-source-release.zip
>
> Source release checksum(s):
> surefire-3.0.0-M3-source-release.zip sha1:
> 4d1187b9c1f1922d13ac25d4538f30225ea8e27a
> surefire-3.0.0-M3-source-release.zip sha512:
> c13d24c10ec59278113f862702538770fccf1f816a7803dc7adaaa9f90ab0a76bad0d83526cd4ce80d3891e9364f4079020b70478dede0e330f98f8f79afae54
>
> Staging site:
> http://maven.apache.org/surefire-archives/surefire-LATEST/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Cheers
> Tibor
>
>

Re: [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M3

[Tibor Digana]

Hi,

The vote has passed with the following result:

+1 : Christian Stein, Enrico Olivelli, Eric Lilja, Olivier Lamy, Karl Heinz
Marbaise, Tibor Digana

PMC quorum: reached

I will promote the artifacts to the central repo.
I will add the release to the next board report.


Cheers
Tibor

On Thu, Dec 20, 2018 at 10:47 AM Tibor Digana 
wrote:

> Hi,
>
> We solved 6 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317927&version=12342872
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/i#issues/?jql=project+%3D+SUREFIRE+AND+status+%3D+Open+ORDER+BY+priority+DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1479
>
> https://repository.apache.org/content/repositories/maven-1479/org/apache/maven/surefire/surefire/3.0.0-M3/surefire-3.0.0-M3-source-release.zip
>
> Source release checksum(s):
> surefire-3.0.0-M3-source-release.zip sha1:
> 4d1187b9c1f1922d13ac25d4538f30225ea8e27a
> surefire-3.0.0-M3-source-release.zip sha512:
> c13d24c10ec59278113f862702538770fccf1f816a7803dc7adaaa9f90ab0a76bad0d83526cd4ce80d3891e9364f4079020b70478dede0e330f98f8f79afae54
>
> Staging site:
> http://maven.apache.org/surefire-archives/surefire-LATEST/
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Cheers
> Tibor
>
>

[RESULT] [VOTE] Release Apache Maven Surefire Plugin version 3.0.0-M3

[Tibor Digana]

Hi,

The vote has passed with the following result:

+1 : Christian Stein, Enrico Olivelli, Eric Lilja, Olivier Lamy, Karl Heinz
Marbaise, Tibor Digana

PMC quorum: reached

I will promote the artifacts to the central repo.
I will add the release to the next board report.


Cheers
Tibor

[ANN] Apache Maven Surefire Plugin 3.0.0-M3 Released

[Tibor Digana]

The Apache Maven team is pleased to announce the release of the Apache
Maven Surefire Plugin, version 3.0.0-M3.

The release contains 6 bug fixes.
Again we received contributions from the community in form of bug reports
and bug fixes.
Thank you and keep them coming!

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

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


  org.apache.maven.plugins
  maven-surefire-plugin
  3.0.0-M3


or for failsafe:


  org.apache.maven.plugins
  maven-failsafe-plugin
  3.0.0-M3


or for surefire-report:


  org.apache.maven.plugins
  maven-surefire-report-plugin
  3.0.0-M3



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

Release Notes - Maven Surefire - Version 3.0.0-M3

Bug

[SUREFIRE-1613] - maven-surefire-report-plugin fails on JDK 11
[SUREFIRE-1614] - JUnit Runner that writes to System.out corrupts
Surefire's STDOUT when using JUnit's Vintage Engine
[SUREFIRE-1616] - Smart stacktrace in test summary should not print
JUnit5 assertion exception type

Improvement

[SUREFIRE-1608] - dump error paths with the same root cause in Boot
Manifest-JAR only once without stacktrace

Task

[SUREFIRE-1609] - Use ShadeFire 3.0.0-M2 in the internal tests
[SUREFIRE-1611] - Deprecate skipTests in Failsafe Plugin


Enjoy,
-The Apache Maven team

Re: [VOTE] Release Apache Maven Shared Component: Maven Dependecy Analyzer Version 1.11.1

[Tibor Digana]

+1

On Tue, Dec 25, 2018 at 11:28 PM Karl Heinz Marbaise 
wrote:

> Hi,
>
> We solved 1 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12344667
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20XX%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1480/
>
> https://repository.apache.org/content/repositories/maven-1480/org/apache/maven/shared/maven-dependency-analyzer/1.11.1/maven-dependency-analyzer-1.11.1-source-release.zip
>
> Source release checksum(s):
> maven-dependency-analyzer-1.11.1-source-release.zip sha512:
>
> 7d8880bac7cfb5f9f01f0b82e6d1dc1b9a4e0f79e0c76f9d807182fcad5e3e8c57c0c019cb1177b87a1e85f92aff3770585422be691f5cfafb529e633af35600
>
> Staging site:
> http://maven.apache.org/shared-archives/maven-dependency-analyzer-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
>
> 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: Drop Java 9 and 10 from asfMavenTlpStdBuild()

[Tibor Digana]

Does it mean that combinations of Maven and JDK reached the disk limit?
I am using JDK 7, 8, 11, 12 and Maven 3.2, 3.3 and 3.5.
So 12 combinations altogether.
Each makes cleanup, and the archiver stores totally 240 Mega Bytes per
build.
We have 10 surefire builds which makes 2.4 GB per Linux. Windows is a bit
smaller.
If I could remove JDK 12, we would save only 25% on the disk.
Sometimes the archived ZIP files are investigated and often a lost
connection is found.

T

On Tue, Dec 25, 2018 at 8:38 PM Robert Scholte  wrote:

> Java 9 and 10 have the same status as Java 1.7 right now.
> Knowing that the majority of Java projects/developers will go from 1.8 to
> 11 (because this is in the first LTS for some vendors) it probably makes
> sense to drop these versions by default.
> I'll remove them.
>
> Robert
>
> On Tue, 25 Dec 2018 19:16:11 +0100, Michael Osipov 
> wrote:
>
> > Friends,
> >
> > can someone drop those version from the Jenkins config? They aren't
> > supported anymore and were short term releases anyway.
> >
> > Michael
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: VOTE] Release Maven Wagon version 3.3.0

[Tibor Digana]

+1

On Thu, Dec 27, 2018 at 11:21 PM Michael Osipov  wrote:

> Hi,
>
> We solved 4 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122&version=12344436
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20WAGON%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1481/
>
> https://repository.apache.org/content/repositories/maven-1481/org/apache/maven/wagon/wagon/3.3.0/wagon-3.3.0-source-release.zip
>
> Source release checksum(s):
> wagon-3.3.0-source-release.zip
> sha512:
>
> c467bf8d9f5b54602f53ed34e117753f48cf25b611c79dbbba55706ce34a6bb0dec65447a84d6dc5122615147fe4ce19102a94a37d4a0b3a15382aa7fdba7560
>
> Staging site:
> https://maven.apache.org/wagon-archives/wagon-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
>
>

Re: Building Javadocs and site on CI

[Tibor Digana]

These errors with JavaDoc in source code can be effectively avoided with
adding a JDK8 Profile in pom.xml and a config of compiler.
You do not need to wait for making a release when the Site is generated.
Even the contributor will fails his build when compiling and testing
project in his own:


  org.apache.maven.plugins
  maven-compiler-plugin
  
true

  -Xdoclint:all

  



On Mon, Dec 31, 2018 at 11:14 AM Robert Scholte 
wrote:

> On Sun, 30 Dec 2018 23:55:20 +0100, Chris Graham 
> wrote:
>
> > I am used to running mvn clean install site on my Jenkins build jobs
> and
> > then let the Jenkins checkstyle, find bugs etc plugins display the
> > results/trends over builds.
>
> This should work with a simple 'mvn verify site' too.
>
> >
> > And I thought the ASF Jenkins used to have this feature.
>
> It all depends on the Job configuration, but we're using the multibranch
> plugin, so we are in full control.
>
> >
> > Are there any plans to restore this?
>
> See
>
> https://lists.apache.org/thread.html/541a493c12879fc4e218602b5745afea08706700f264f4d647390ffc@%3Cdev.maven.apache.org%3E
>
> >
> > Also, I attempted to build all of the asf maven tepid yesterday, under
> > JDK 7, and some failed, e.g. Surefire needed JDK 8.
>
> Surefire is a special case. IIRC it requires JDK8 to build, but it
> delivers JDK7 compatible code.
>
> >
> > Have we moved from a minimum of JDK 7?
>
> Will probably happen soonish
>
> >
> >
> >
> > Sent from my iPhone
> >
> >> On 30 Dec 2018, at 9:47 pm, Robert Scholte 
> wrote:
> >>
> >>> On Sat, 29 Dec 2018 13:12:36 +0100, Hervé BOUTEMY
> >>>  wrote:
> >>>
> >>> Le samedi 29 décembre 2018, 11:29:53 CET Robert Scholte a écrit :
>  I've already introduces the concept of "plans"[1][2], which also
>  include
>  'site' for documentation and 'release' to verify if the project is
>  releasable (should probably change that name to prevent confusion).
> >>> +1 to change the name of "release" to something like "check-release"
> >>
> >> or release-dryRun
> >>
> >>>
>  The jobs are getting more stable, so we might give it a try soon. Just
>  need to be aware that the 'site' plan doesn't seem to work for
>  multimodule
>  projects yet. Better fix that first.
> >>> why doesn't it work? what does "don't work" mean? fail?
> >>>
> >>> I just see "site:stage" missing to have multi-module assembled: would
> >>> not
> >>> cause any harm for non-multi-modules
> >>
> >> That might be the reason, I'll add that.
> >>
> >>>
> >>> additional question: once the site is build on Jenkins, can it be
> >>> browsed?
> >>
> >> I guess so.
> >>
> >> Once INFRA-17514 is fixed I'll enable the site-plan too.
> >>
> >> thanks,
> >> Robert
> >>
> >> [1] https://issues.apache.org/jira/browse/INFRA-17514
> >>
> >>>
> >>> Regards,
> >>>
> >>> Hervé
> >>>
> 
>  thanks,
>  Robert
> 
>  [1]
> 
> https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=blob;f=vars/as
> 
> fMavenTlpPlgnBuild.groovy;h=6502fe80819c873757e339a0f1b3186fd14303b9;hb=HEAD
>  #l63 [2]
> 
> https://gitbox.apache.org/repos/asf?p=maven-jenkins-lib.git;a=blob;f=vars/as
> 
> fMavenTlpPlgnBuild.groovy;h=6502fe80819c873757e339a0f1b3186fd14303b9;hb=HEAD
>  #l132
> 
> 
>  On Sat, 29 Dec 2018 09:14:27 +0100, Enrico Olivelli
>  
> 
>  wrote:
>  > Hi guys,
>  > I am trying to release Maven Assembly Plugin and I see that there
>  are
>  > a few showstoppers due to javadocs and site generation.
>  > Isn't it possible to run  "javadoc:javadoc site" on CI ?
>  >
>  > This way we won't commit broken/unreleasable stuff
>  >
>  > Enrico
>  >
>  >
>  -
>  > 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
> >>
> >> -
> >> 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: Building Javadocs and site on CI

[Tibor Digana]

The fork is, I think, because of the "compilerArgs", but pls check it in
the Maven compiler's documentation.
IMHo the profile activated by JDK8 can be added to "maven-parent" pom and
the new release version 34 can already have it.
If it helps the all Maven projects will have this possibility on CI as well.

On Tue, Jan 1, 2019 at 1:07 PM Enrico Olivelli  wrote:

> Good idea!
> Why fork=true?
>
> In general I see that new java versions have always stricter validation of
> javadocs
> It would be better to have a CI job with jdk11 (12 next quarter...and so
> on)
> We already have tests over every supported platform, so Tibor's idea of
> adding doclint option whill enable us to have good coverage at every build
>
> Enrico
>
> Il mar 1 gen 2019, 13:03 Tibor Digana  ha scritto:
>
> > These errors with JavaDoc in source code can be effectively avoided with
> > adding a JDK8 Profile in pom.xml and a config of compiler.
> > You do not need to wait for making a release when the Site is generated.
> > Even the contributor will fails his build when compiling and testing
> > project in his own:
> >
> > 
> >   org.apache.maven.plugins
> >   maven-compiler-plugin
> >   
> > true
> > 
> >   -Xdoclint:all
> > 
> >   
> > 
> >
> >
> > On Mon, Dec 31, 2018 at 11:14 AM Robert Scholte 
> > wrote:
> >
> > > On Sun, 30 Dec 2018 23:55:20 +0100, Chris Graham  >
> > > wrote:
> > >
> > > > I am used to running mvn clean install site on my Jenkins build jobs
> > > and
> > > > then let the Jenkins checkstyle, find bugs etc plugins display the
> > > > results/trends over builds.
> > >
> > > This should work with a simple 'mvn verify site' too.
> > >
> > > >
> > > > And I thought the ASF Jenkins used to have this feature.
> > >
> > > It all depends on the Job configuration, but we're using the
> multibranch
> > > plugin, so we are in full control.
> > >
> > > >
> > > > Are there any plans to restore this?
> > >
> > > See
> > >
> > >
> >
> https://lists.apache.org/thread.html/541a493c12879fc4e218602b5745afea08706700f264f4d647390ffc@%3Cdev.maven.apache.org%3E
> > >
> > > >
> > > > Also, I attempted to build all of the asf maven tepid yesterday,
> under
> > > > JDK 7, and some failed, e.g. Surefire needed JDK 8.
> > >
> > > Surefire is a special case. IIRC it requires JDK8 to build, but it
> > > delivers JDK7 compatible code.
> > >
> > > >
> > > > Have we moved from a minimum of JDK 7?
> > >
> > > Will probably happen soonish
> > >
> > > >
> > > >
> > > >
> > > > Sent from my iPhone
> > > >
> > > >> On 30 Dec 2018, at 9:47 pm, Robert Scholte 
> > > wrote:
> > > >>
> > > >>> On Sat, 29 Dec 2018 13:12:36 +0100, Hervé BOUTEMY
> > > >>>  wrote:
> > > >>>
> > > >>> Le samedi 29 décembre 2018, 11:29:53 CET Robert Scholte a écrit :
> > > >>>> I've already introduces the concept of "plans"[1][2], which also
> > > >>>> include
> > > >>>> 'site' for documentation and 'release' to verify if the project is
> > > >>>> releasable (should probably change that name to prevent
> confusion).
> > > >>> +1 to change the name of "release" to something like
> "check-release"
> > > >>
> > > >> or release-dryRun
> > > >>
> > > >>>
> > > >>>> The jobs are getting more stable, so we might give it a try soon.
> > Just
> > > >>>> need to be aware that the 'site' plan doesn't seem to work for
> > > >>>> multimodule
> > > >>>> projects yet. Better fix that first.
> > > >>> why doesn't it work? what does "don't work" mean? fail?
> > > >>>
> > > >>> I just see "site:stage" missing to have multi-module assembled:
> would
> > > >>> not
> > > >>> cause any harm for non-multi-modules
> > > >>
> > > >> That might be the reason, I'll add that.
> > > >>
> > > >>>
> > > >>> additional quest

Re: Building Javadocs and site on CI

[Tibor Digana]

Enrico, there is one problem with maven-help-plugin which generates
"HelpMojo.java" with the problematic "".
First the plugin should be fixed and released and the maven-parent;
otherwise all plugins would end up with complicated configuration of
maven-compiler-plugin as Surefire has.

On Tue, Jan 1, 2019 at 1:07 PM Enrico Olivelli  wrote:

> Good idea!
> Why fork=true?
>
> In general I see that new java versions have always stricter validation of
> javadocs
> It would be better to have a CI job with jdk11 (12 next quarter...and so
> on)
> We already have tests over every supported platform, so Tibor's idea of
> adding doclint option whill enable us to have good coverage at every build
>
> Enrico
>
> Il mar 1 gen 2019, 13:03 Tibor Digana  ha scritto:
>
> > These errors with JavaDoc in source code can be effectively avoided with
> > adding a JDK8 Profile in pom.xml and a config of compiler.
> > You do not need to wait for making a release when the Site is generated.
> > Even the contributor will fails his build when compiling and testing
> > project in his own:
> >
> > 
> >   org.apache.maven.plugins
> >   maven-compiler-plugin
> >   
> > true
> > 
> >   -Xdoclint:all
> > 
> >   
> > 
> >
> >
> > On Mon, Dec 31, 2018 at 11:14 AM Robert Scholte 
> > wrote:
> >
> > > On Sun, 30 Dec 2018 23:55:20 +0100, Chris Graham  >
> > > wrote:
> > >
> > > > I am used to running mvn clean install site on my Jenkins build jobs
> > > and
> > > > then let the Jenkins checkstyle, find bugs etc plugins display the
> > > > results/trends over builds.
> > >
> > > This should work with a simple 'mvn verify site' too.
> > >
> > > >
> > > > And I thought the ASF Jenkins used to have this feature.
> > >
> > > It all depends on the Job configuration, but we're using the
> multibranch
> > > plugin, so we are in full control.
> > >
> > > >
> > > > Are there any plans to restore this?
> > >
> > > See
> > >
> > >
> >
> https://lists.apache.org/thread.html/541a493c12879fc4e218602b5745afea08706700f264f4d647390ffc@%3Cdev.maven.apache.org%3E
> > >
> > > >
> > > > Also, I attempted to build all of the asf maven tepid yesterday,
> under
> > > > JDK 7, and some failed, e.g. Surefire needed JDK 8.
> > >
> > > Surefire is a special case. IIRC it requires JDK8 to build, but it
> > > delivers JDK7 compatible code.
> > >
> > > >
> > > > Have we moved from a minimum of JDK 7?
> > >
> > > Will probably happen soonish
> > >
> > > >
> > > >
> > > >
> > > > Sent from my iPhone
> > > >
> > > >> On 30 Dec 2018, at 9:47 pm, Robert Scholte 
> > > wrote:
> > > >>
> > > >>> On Sat, 29 Dec 2018 13:12:36 +0100, Hervé BOUTEMY
> > > >>>  wrote:
> > > >>>
> > > >>> Le samedi 29 décembre 2018, 11:29:53 CET Robert Scholte a écrit :
> > > >>>> I've already introduces the concept of "plans"[1][2], which also
> > > >>>> include
> > > >>>> 'site' for documentation and 'release' to verify if the project is
> > > >>>> releasable (should probably change that name to prevent
> confusion).
> > > >>> +1 to change the name of "release" to something like
> "check-release"
> > > >>
> > > >> or release-dryRun
> > > >>
> > > >>>
> > > >>>> The jobs are getting more stable, so we might give it a try soon.
> > Just
> > > >>>> need to be aware that the 'site' plan doesn't seem to work for
> > > >>>> multimodule
> > > >>>> projects yet. Better fix that first.
> > > >>> why doesn't it work? what does "don't work" mean? fail?
> > > >>>
> > > >>> I just see "site:stage" missing to have multi-module assembled:
> would
> > > >>> not
> > > >>> cause any harm for non-multi-modules
> > > >>
> > > >> That might be the reason, I'll add that.
> > > >>
> > > >>>
> > > >>> additional question: once the site is bui

Re: New Committers - community

[Tibor Digana]

I already lost the point of this thread.
Still the disk space problem on Windows executors in ASF Jenkins?
If it's this issue, then why the workspace is not investigated directly on
the system with remote access?
Jenkins is very good tool and I do not want to use Travis but Travis is one
step after finding the root cause.
T

On Thu, Jan 3, 2019 at 8:39 PM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On Thu 3 Jan 2019 at 18:03, Enrico Olivelli  wrote:
>
> > Il gio 3 gen 2019, 17:38 Mickael Istria  ha scritto:
> >
> > > Hi,
> > >
> > > I think this discussion is diverging into "trying TravisCI for some
> > > plugins" and is loosing focus on the initial question of how to improve
> > the
> > > build+test flow to get faster feedback as a contributor or as a
> reviewer.
>
>
> Travis will get the build+test flow faster for non-committers.
>
>
> > > Can the GitHub PR builder plugin be enabled on Maven Core ?
>
>
> No, it’s not compatible with how we build, as currently we only build from
> gitbox not from GitHub so there is no link for Jenkins to see
>
>
> Committers
> > > would be allowed to trigger a test with a single comment once they
> > checked
> > > it doesn't cause a security flaw.
> > >
> >
> > It turns out that it is not simple as it could seem because we have
> custom
> > Jenkins plugins to scan all the repos and have a common configuration, so
> > in order to achieve such goal we need to enhance that plugin, please
> > Stephen correct me if I am wrong.
>
>
> Yep I need to enhance the plugin a little... just trying to clear stuff off
> my plate
>
>
> > Travis jumped on this train because it is easy to enable and it is very
> > widespread, and it leaves security problems out of ASF infra.
> > But a check with Travis won't ever cover all jobs we are actually
> starting
> > per-branch.
> > It can be a good compromise to start, but if we have resources to improve
> > current integration this will be the best choice for the mid term.
> >
> > Enrico
> >
> > >
> > > Cheers,
> > >
> > --
> >
> >
> > -- Enrico Olivelli
> >
> --
> Sent from my phone
>

Re: New Committers - community

[Tibor Digana]

Why the build cannot be triggered on GitHub or PR?
It's only a URL.
If you see the frequency of PRs in Surefire, 1 or 2 PRs/month, this should
not be a problem since the Windows build takes 1.5 hour and Linux 1 hour.
Taking JDK 7 and 11, and one Maven version (3.5) is usually enough on Git
branches and should be fine for PRs as well.

On Thu, Jan 3, 2019 at 10:19 PM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On Thu 3 Jan 2019 at 20:52, Tibor Digana  wrote:
>
> > I already lost the point of this thread.
> > Still the disk space problem on Windows executors in ASF Jenkins?
> > If it's this issue, then why the workspace is not investigated directly
> on
> > the system with remote access?
> > Jenkins is very good tool and I do not want to use Travis but Travis is
> one
> > step after finding the root cause.
>
>
> We’re not going to be able to use Travis for Surefire (unless we have a
> “fast” suite of tests)
>
> That doesn’t mean we cannot use Travis for the 90 other repos we have in
> order to get test results of PRs from non-committers.
>
>
> > T
> >
> > On Thu, Jan 3, 2019 at 8:39 PM Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > On Thu 3 Jan 2019 at 18:03, Enrico Olivelli 
> wrote:
> > >
> > > > Il gio 3 gen 2019, 17:38 Mickael Istria  ha
> > scritto:
> > > >
> > > > > Hi,
> > > > >
> > > > > I think this discussion is diverging into "trying TravisCI for some
> > > > > plugins" and is loosing focus on the initial question of how to
> > improve
> > > > the
> > > > > build+test flow to get faster feedback as a contributor or as a
> > > reviewer.
> > >
> > >
> > > Travis will get the build+test flow faster for non-committers.
> > >
> > >
> > > > > Can the GitHub PR builder plugin be enabled on Maven Core ?
> > >
> > >
> > > No, it’s not compatible with how we build, as currently we only build
> > from
> > > gitbox not from GitHub so there is no link for Jenkins to see
> > >
> > >
> > > Committers
> > > > > would be allowed to trigger a test with a single comment once they
> > > > checked
> > > > > it doesn't cause a security flaw.
> > > > >
> > > >
> > > > It turns out that it is not simple as it could seem because we have
> > > custom
> > > > Jenkins plugins to scan all the repos and have a common
> configuration,
> > so
> > > > in order to achieve such goal we need to enhance that plugin, please
> > > > Stephen correct me if I am wrong.
> > >
> > >
> > > Yep I need to enhance the plugin a little... just trying to clear stuff
> > off
> > > my plate
> > >
> > >
> > > > Travis jumped on this train because it is easy to enable and it is
> very
> > > > widespread, and it leaves security problems out of ASF infra.
> > > > But a check with Travis won't ever cover all jobs we are actually
> > > starting
> > > > per-branch.
> > > > It can be a good compromise to start, but if we have resources to
> > improve
> > > > current integration this will be the best choice for the mid term.
> > > >
> > > > Enrico
> > > >
> > > > >
> > > > > Cheers,
> > > > >
> > > > --
> > > >
> > > >
> > > > -- Enrico Olivelli
> > > >
> > > --
> > > Sent from my phone
> > >
> >
> --
> Sent from my phone
>

Re: New Committers - community

[Tibor Digana]

I am doing #2.
This means I create a GitBox branch or I run it on my own PC. Not a problem
at all because usually the contributor does not complete it and I have to
add some test or clarify the change in documentation. Sometime I have to
rework the PR even if the idea was good, and I have to squash the commits.
So I am quite patient while triggering the CI via a branch but I cannot
represent the colleagues of course. Running PRs automatically would be
really a good idea.
T

On Thu, Jan 3, 2019 at 10:45 PM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On Thu 3 Jan 2019 at 21:37, Tibor Digana  wrote:
>
> > Why the build cannot be triggered on GitHub or PR?
> > It's only a URL.
> > If you see the frequency of PRs in Surefire, 1 or 2 PRs/month, this
> should
> > not be a problem since the Windows build takes 1.5 hour and Linux 1 hour.
> > Taking JDK 7 and 11, and one Maven version (3.5) is usually enough on Git
> > branches and should be fine for PRs as well.
>
>
> 1. The current branch source only discovers branches in gitbox, it doesn’t
> discover PRs on GitHub.
>
> 2. PRs on GitHub can have “untrusted” code, which shouldn’t be run within
> the ASF hardware without review by a committer.
>
> #1 can be solved by me enhancing the Jenkins plugin we use
>
> #2 either means asking committers to trigger builds after reviewing (which
> is a manual step and manual steps get forgotten)
>
> So instead we get Travis to do a first round CI for the PRs on GitHub. Then
> we can still have #1 and #2 as final pre-merge confirmation... but Travis
> gives the contributor immediate feedback on their contribution and that
> helps grow the community.
>
>
> >
> > On Thu, Jan 3, 2019 at 10:19 PM Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> > > On Thu 3 Jan 2019 at 20:52, Tibor Digana 
> wrote:
> > >
> > > > I already lost the point of this thread.
> > > > Still the disk space problem on Windows executors in ASF Jenkins?
> > > > If it's this issue, then why the workspace is not investigated
> directly
> > > on
> > > > the system with remote access?
> > > > Jenkins is very good tool and I do not want to use Travis but Travis
> is
> > > one
> > > > step after finding the root cause.
> > >
> > >
> > > We’re not going to be able to use Travis for Surefire (unless we have a
> > > “fast” suite of tests)
> > >
> > > That doesn’t mean we cannot use Travis for the 90 other repos we have
> in
> > > order to get test results of PRs from non-committers.
> > >
> > >
> > > > T
> > > >
> > > > On Thu, Jan 3, 2019 at 8:39 PM Stephen Connolly <
> > > > stephen.alan.conno...@gmail.com> wrote:
> > > >
> > > > > On Thu 3 Jan 2019 at 18:03, Enrico Olivelli 
> > > wrote:
> > > > >
> > > > > > Il gio 3 gen 2019, 17:38 Mickael Istria  ha
> > > > scritto:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I think this discussion is diverging into "trying TravisCI for
> > some
> > > > > > > plugins" and is loosing focus on the initial question of how to
> > > > improve
> > > > > > the
> > > > > > > build+test flow to get faster feedback as a contributor or as a
> > > > > reviewer.
> > > > >
> > > > >
> > > > > Travis will get the build+test flow faster for non-committers.
> > > > >
> > > > >
> > > > > > > Can the GitHub PR builder plugin be enabled on Maven Core ?
> > > > >
> > > > >
> > > > > No, it’s not compatible with how we build, as currently we only
> build
> > > > from
> > > > > gitbox not from GitHub so there is no link for Jenkins to see
> > > > >
> > > > >
> > > > > Committers
> > > > > > > would be allowed to trigger a test with a single comment once
> > they
> > > > > > checked
> > > > > > > it doesn't cause a security flaw.
> > > > > > >
> > > > > >
> > > > > > It turns out that it is not simple as it could seem because we
> have
> > > > > custom
> > > > > > Jenkins plugins to scan all the repos and have a common
> > > configuration,
> > > > so
> > > > > > in order to achieve such goal we need to enhance that plugin,
> > please
> > > > > > Stephen correct me if I am wrong.
> > > > >
> > > > >
> > > > > Yep I need to enhance the plugin a little... just trying to clear
> > stuff
> > > > off
> > > > > my plate
> > > > >
> > > > >
> > > > > > Travis jumped on this train because it is easy to enable and it
> is
> > > very
> > > > > > widespread, and it leaves security problems out of ASF infra.
> > > > > > But a check with Travis won't ever cover all jobs we are actually
> > > > > starting
> > > > > > per-branch.
> > > > > > It can be a good compromise to start, but if we have resources to
> > > > improve
> > > > > > current integration this will be the best choice for the mid
> term.
> > > > > >
> > > > > > Enrico
> > > > > >
> > > > > > >
> > > > > > > Cheers,
> > > > > > >
> > > > > > --
> > > > > >
> > > > > >
> > > > > > -- Enrico Olivelli
> > > > > >
> > > > > --
> > > > > Sent from my phone
> > > > >
> > > >
> > > --
> > > Sent from my phone
> > >
> >
> --
> Sent from my phone
>

Re: Enable Travis on Maven Scripting Plugin

[Tibor Digana]

@Stephen Connolly 
 After such a big investment, especially made on your side, in Jenkins
plugin you developed you do not want to support the GitHub PRs and you just
let be to go with TravisCI just like that? I do not think so!
T


On Fri, Jan 4, 2019 at 7:22 PM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> +1 from me
>
> On Fri 4 Jan 2019 at 18:21, Enrico Olivelli  wrote:
>
> > Hi,
> > I would like to try out Travis on this small plugin:
> > https://github.com/apache/maven-scripting-plugin
> >
> > I have pushed a minimal configuration file
> > I need to ask to Infra, but I need approval from the community and
> PMCs...
> >
> > Can I proceed ?
> >
> > Enrico
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> > --
> Sent from my phone
>

Re: Enable Travis on Maven Scripting Plugin

[Tibor Digana]

Manfred, did you see my comment on Slack?
Shortly, let's have dedicated machines just only for Maven project with
Infra support and one person from our team with Infra permissions just on
these machines. There are 6 Windows machine. So 4 Win/Ubuntu for us.
all: WDYT?

Cheers
Tibor

On Sat, Jan 5, 2019 at 12:11 AM Manfred Moser 
wrote:

> I agree with Tibor. I would rather not have to deal with two different CI
> systems...
>
> Manfred
>
> Tibor Digana wrote on 2019-01-04 14:00:
>
> > @Stephen Connolly 
> > After such a big investment, especially made on your side, in Jenkins
> > plugin you developed you do not want to support the GitHub PRs and you
> just
> > let be to go with TravisCI just like that? I do not think so!
> > T
> >
> >
> > On Fri, Jan 4, 2019 at 7:22 PM Stephen Connolly <
> > stephen.alan.conno...@gmail.com> wrote:
> >
> >> +1 from me
> >>
> >> On Fri 4 Jan 2019 at 18:21, Enrico Olivelli 
> wrote:
> >>
> >> > Hi,
> >> > I would like to try out Travis on this small plugin:
> >> > https://github.com/apache/maven-scripting-plugin
> >> >
> >> > I have pushed a minimal configuration file
> >> > I need to ask to Infra, but I need approval from the community and
> >> PMCs...
> >> >
> >> > Can I proceed ?
> >> >
> >> > Enrico
> >> >
> >> > -
> >> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> > For additional commands, e-mail: dev-h...@maven.apache.org
> >> >
> >> > --
> >> Sent from my phone
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Wagon version 3.3.1

[Tibor Digana]

+1

On Thu, Jan 3, 2019 at 2:28 PM Michael Osipov  wrote:

> Hi,
>
> We solved 6 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122&version=12344772
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20WAGON%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1483/
>
> https://repository.apache.org/content/repositories/maven-1483/org/apache/maven/wagon/wagon/3.3.1/wagon-3.3.1-source-release.zip
>
> Source release checksum(s):
> wagon-3.3.1-source-release.zip
> sha512:
>
> 398d8d028cbaff4fdc6380a105af8c2111915931db9c46f404e96c6de82b713995f3842ffd32b61e1a0b6c4249973af69a6256c160babf2d3acf7cff5417a649
>
> Staging site:
> https://maven.apache.org/wagon-archives/wagon-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
>
>

Re: Jenkins ASF + Pull Requests + webhooks

[Tibor Digana]

Regarding "pull/1234/head" refs and the security, I think allowing only the
permission to Maven Central IP address is needed and nowhere else.
This can be accomplished by the java policy in JRE.
WDYT?

On Sun, Jan 6, 2019 at 11:09 AM Hervé BOUTEMY  wrote:

> I didn't know about these special "pull/1234/head" refs, that are not real
> branches: if these pseudo-branches were synchronized to Gitbox like any
> branch, the Gitpubsub mechanism could happen at Apache
> of course, the security implications of running code from these PR
> branches
> would still have to be managed...
>
> notice: there is a discussion on this on builds@apache [1]
>
> Regards,
>
> Hervé
>
> [1] https://lists.apache.org/list.html?bui...@apache.org
>
> Le samedi 5 janvier 2019, 12:34:24 CET Enrico Olivelli a écrit :
> > Hi Stephen,
> > I am not a Jenkins expert, but I want to share this idea, maybe it can
> help.
> > Can we use GitHub webhooks in order to trigger the creation of a Job
> inside
> > Maven-Box ?
> > This way we don't have to continuously use Github API.
> > When an user creates/updates a PR we can import the PR and create the
> > Job, having as repository not gitbox.apache.org but github.com
> >
> > In github you have this special refs "pull/1234/head" which points to
> > the branch on remote fork
> >
> > just an idea
> >
> > Enrico
> >
> > -
> > 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: Jenkins ASF + Pull Requests + webhooks

[Tibor Digana]

@Stephen Connolly 
I meant Bitcoins. Without network access bitcoins can be loaded but nobody
can use them. An access to Workspace and archived artifacts should be
disabled for users.


On Sun, Jan 6, 2019 at 5:51 PM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> That is not the problem you think it is. Bitcoin mining is the current
> issue. And through Jenkinsfile or Process.exec you can bypass JVM
> permissions
>
> On Sun 6 Jan 2019 at 16:44, Tibor Digana  wrote:
>
> > Regarding "pull/1234/head" refs and the security, I think allowing only
> the
> > permission to Maven Central IP address is needed and nowhere else.
> > This can be accomplished by the java policy in JRE.
> > WDYT?
> >
> > On Sun, Jan 6, 2019 at 11:09 AM Hervé BOUTEMY 
> > wrote:
> >
> > > I didn't know about these special "pull/1234/head" refs, that are not
> > real
> > > branches: if these pseudo-branches were synchronized to Gitbox like any
> > > branch, the Gitpubsub mechanism could happen at Apache
> > > of course, the security implications of running code from these PR
> > > branches
> > > would still have to be managed...
> > >
> > > notice: there is a discussion on this on builds@apache [1]
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > [1] https://lists.apache.org/list.html?bui...@apache.org
> > >
> > > Le samedi 5 janvier 2019, 12:34:24 CET Enrico Olivelli a écrit :
> > > > Hi Stephen,
> > > > I am not a Jenkins expert, but I want to share this idea, maybe it
> can
> > > help.
> > > > Can we use GitHub webhooks in order to trigger the creation of a Job
> > > inside
> > > > Maven-Box ?
> > > > This way we don't have to continuously use Github API.
> > > > When an user creates/updates a PR we can import the PR and create the
> > > > Job, having as repository not gitbox.apache.org but github.com
> > > >
> > > > In github you have this special refs "pull/1234/head" which points to
> > > > the branch on remote fork
> > > >
> > > > just an idea
> > > >
> > > > Enrico
> > > >
> > > > -
> > > > 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
> > >
> > >
> >
> --
> Sent from my phone
>

Re: Jenkins ASF + Pull Requests + webhooks

[Tibor Digana]

disabled logs, workspace and artifacts for anonymous Jenkins users, but
available for PMC and Maven committers.

On Sun, Jan 6, 2019 at 8:41 PM Mickael Istria  wrote:

> On Sun, Jan 6, 2019 at 8:32 PM Tibor Digana 
> wrote:
>
> > I meant Bitcoins. Without network access bitcoins can be loaded but
> nobody
> > can use them. An access to Workspace and archived artifacts should be
> > disabled for users.
>
>
> That would be sad since those are actually super helpful when trying to
> debug issues that are only happening in some environments and CI reproduces
> when they can hardly reproduce them locally.
>

Update versions of all plugins in default-bindings.xml

[Tibor Digana]

Why we use old versions in default-bindings.xml?
Can we update all versions in 3.6.1 release?

Here is MNG-6557 which is related to Surefire but I guess this Jira issue
can be freely related to all plugins.

WDYT?
Any objections to update all plugins and assign this issue in 3.6.1?

Cheers
Tibor

Re: Update versions of all plugins in default-bindings.xml

[Tibor Digana]

ok, Herve, the fact is that these plugins have been updated from time to
time.
How can we be on safe side with these updates? What is mandatory to do for
such upgrade?

On Fri, Jan 11, 2019 at 7:41 AM Hervé BOUTEMY  wrote:

> As I wrote in many Jira issues over years on this topic, I'm not in favor
> of
> that
>
> To me, staying with the same default plugins versions from Maven version
> to
> Maven version is a feature: nobody should expect to change his Maven
> version
> to change the plugins versions
> The best practice is to define plugins versions in your pom.xml (or
> parent).
> Getting very old versions of plugins by default is the best additional
> feature
> we have after the WARN "plugin version not defined"
>
> Then IMHO, upgrading default plugins versions is a bad idea, is a bad
> message
> = "you can continue to ignore the WARN on plugins versions and still get
> newest and latest plugins"
>
> this leads IMHO to one (bad) reason for people to require Maven Wrapper
>
>
> I know, this is counter intuitive, that's why it is required to really
> take a
> moment to think about it
>
> Regards,
>
> Hervé
>
> Le jeudi 10 janvier 2019, 17:08:57 CET Tibor Digana a écrit :
> > Why we use old versions in default-bindings.xml?
> > Can we update all versions in 3.6.1 release?
> >
> > Here is MNG-6557 which is related to Surefire but I guess this Jira issue
> > can be freely related to all plugins.
> >
> > WDYT?
> > Any objections to update all plugins and assign this issue in 3.6.1?
> >
> > Cheers
> > Tibor
>
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: Update versions of all plugins in default-bindings.xml

[Tibor Digana]

yes Michael, exactly, expected this answer.
That's probably the best we can do? Or more?
Perhaps we can cut a beta version of 3.7.0 in prior which is also an option?
What else?
Testing in our private commercial projects.
..


On Fri, Jan 11, 2019 at 1:00 PM Michael Osipov  wrote:

> Am 2019-01-11 um 12:55 schrieb Tibor Digana:
> > ok, Herve, the fact is that these plugins have been updated from time to
> > time.
> > How can we be on safe side with these updates? What is mandatory to do
> for
> > such upgrade?
>
> Testing...just like I do. See comments MNG-6555. I have found the very
> first issue. MDEPLOY seems to be broken too.
>
> > On Fri, Jan 11, 2019 at 7:41 AM Hervé BOUTEMY 
> wrote:
> >
> >> As I wrote in many Jira issues over years on this topic, I'm not in
> favor
> >> of
> >> that
> >>
> >> To me, staying with the same default plugins versions from Maven version
> >> to
> >> Maven version is a feature: nobody should expect to change his Maven
> >> version
> >> to change the plugins versions
> >> The best practice is to define plugins versions in your pom.xml (or
> >> parent).
> >> Getting very old versions of plugins by default is the best additional
> >> feature
> >> we have after the WARN "plugin version not defined"
> >>
> >> Then IMHO, upgrading default plugins versions is a bad idea, is a bad
> >> message
> >> = "you can continue to ignore the WARN on plugins versions and still get
> >> newest and latest plugins"
> >>
> >> this leads IMHO to one (bad) reason for people to require Maven Wrapper
> >>
> >>
> >> I know, this is counter intuitive, that's why it is required to really
> >> take a
> >> moment to think about it
> >>
> >> Regards,
> >>
> >> Hervé
> >>
> >> Le jeudi 10 janvier 2019, 17:08:57 CET Tibor Digana a écrit :
> >>> Why we use old versions in default-bindings.xml?
> >>> Can we update all versions in 3.6.1 release?
> >>>
> >>> Here is MNG-6557 which is related to Surefire but I guess this Jira
> issue
> >>> can be freely related to all plugins.
> >>>
> >>> WDYT?
> >>> Any objections to update all plugins and assign this issue in 3.6.1?
> >>>
> >>> Cheers
> >>> Tibor
> >>
> >>
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >>
> >
>
>
>

cannot delete workspace ... invoker-reports/BUILD-***.xml

[Tibor Digana]

I think we should downgrade maven-shared-utils to 3.1.0 in the m-invoker-p
because we found the same problem in surefire:3.0.0-M1.
We did not have time to fix it and I have realized the connection to the
Invoker just now.
Faster than a release is to deploy SNAPSHOT version of the Invoker and use
it in JAR plugin and we will see again fully working Jenkins build
https://builds.apache.org/job/maven-box/job/maven-jar-plugin/job/MJAR-238/
The precondition is to ask the INFRA to restart all Windows or kill all
Java processes.
T

Re: cannot delete workspace ... invoker-reports/BUILD-***.xml

[Tibor Digana]

Such a drastic change?
First we should get the confidence using Jenkins CI for a long time run.

On Sat, Jan 12, 2019 at 11:20 AM Enrico Olivelli 
wrote:

> Can't we rollback to the previous version instead of a snapshot?
>
> Enrico
>
> Il sab 12 gen 2019, 09:23 Tibor Digana  ha
> scritto:
>
> > I think we should downgrade maven-shared-utils to 3.1.0 in the
> m-invoker-p
> > because we found the same problem in surefire:3.0.0-M1.
> > We did not have time to fix it and I have realized the connection to the
> > Invoker just now.
> > Faster than a release is to deploy SNAPSHOT version of the Invoker and
> use
> > it in JAR plugin and we will see again fully working Jenkins build
> >
> https://builds.apache.org/job/maven-box/job/maven-jar-plugin/job/MJAR-238/
> > The precondition is to ask the INFRA to restart all Windows or kill all
> > Java processes.
> > T
> >
> --
>
>
> -- Enrico Olivelli
>

Re: cannot delete workspace ... invoker-reports/BUILD-***.xml

[Tibor Digana]

>> which commit could have broken shared utils ?

I have picked up three candidate commits:

362805fbf6341523edfdf509905812acb42f6a97
fd082c077c78f8ce83fce2a92f0265e83599a42f
f2246e0653b185297451902ee278e6aec1ff470e

Those devs who have Windows should run the build of maven-jar-plugin (mvn
verify -P run-its) and list all Java processes after the build.
This process should repeat with maven-shared-utils:3.1.0 and again list all
Java processes.
Logically there should not be any Java processes alive after the build has
completed.

Then we can decide whether we will find the commit and release a new
version of maven-shared-utils or we will downgrade it in all
usages/projects/branches together with testing on Jenkins.
Cheers
T




On Sat, Jan 12, 2019 at 11:50 AM Enrico Olivelli 
wrote:

> Il giorno sab 12 gen 2019 alle ore 11:45 Enrico Olivelli
>  ha scritto:
> >
> >
> >
> > Il sab 12 gen 2019, 11:39 Tibor Digana  ha
> scritto:
> >>
> >> Such a drastic change?
> >
> >
> > If that version is buggy we should fix it or drop it.
> >
> > Do we have already released that buggy version to users?
> >
> >
> > How did you see our processes on Jenkins slave? Do you have access to
> slaves console?
> >
>
> b.q.
> which commit could have broken shared utils ?
> https://github.com/apache/maven-shared-utils/commits/master
>
>
> Enrico
>
>
> > Enrico
> >
> >
> >> First we should get the confidence using Jenkins CI for a long time run.
> >>
> >> On Sat, Jan 12, 2019 at 11:20 AM Enrico Olivelli 
> >> wrote:
> >>
> >> > Can't we rollback to the previous version instead of a snapshot?
> >> >
> >> > Enrico
> >> >
> >> > Il sab 12 gen 2019, 09:23 Tibor Digana  ha
> >> > scritto:
> >> >
> >> > > I think we should downgrade maven-shared-utils to 3.1.0 in the
> >> > m-invoker-p
> >> > > because we found the same problem in surefire:3.0.0-M1.
> >> > > We did not have time to fix it and I have realized the connection
> to the
> >> > > Invoker just now.
> >> > > Faster than a release is to deploy SNAPSHOT version of the Invoker
> and
> >> > use
> >> > > it in JAR plugin and we will see again fully working Jenkins build
> >> > >
> >> >
> https://builds.apache.org/job/maven-box/job/maven-jar-plugin/job/MJAR-238/
> >> > > The precondition is to ask the INFRA to restart all Windows or kill
> all
> >> > > Java processes.
> >> > > T
> >> > >
> >> > --
> >> >
> >> >
> >> > -- Enrico Olivelli
> >> >
> >
> > --
> >
> >
> > -- Enrico Olivelli
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Cheers
Tibor

Re: Update versions of all plugins in default-bindings.xml

[Tibor Digana]

I have a strong reason to update Surefire due to new JRE versions have been
updated too many times last two years.
They required a fix done within a few days and some of them are shaking on
the chair...
Our Maven Core is stable and Java 9+ ready but the obsolete plugins are not.
I want only the same compatibility with default plugins because people do
not see these plugins as a distinct community. They are both Maven and
plugins from us Apache, so they most probably would expect it consistent
altogether.
Makes sense?

On Sat, Jan 12, 2019 at 7:24 PM Bernd Eckenfels 
wrote:

> I think that’s a real bad idea if you have to do local modifications to
> get to a working build environment. Maven is all about not requiring you to
> do that (anymore). So even requiring a certain Maven Version does not fit
> in that pattern (although unavoidable if you do not want to work with
> wrappers).
>
> So this means: keep old standard versions and overwrite them always in
> poms. (And it means the amount of default versions should be reduced or at
> least not add new ones)
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
>
> 
> Von: Robert Scholte 
> Gesendet: Samstag, Januar 12, 2019 5:07 PM
> An: Maven Developers List
> Betreff: Re: Update versions of all plugins in default-bindings.xml
>
> I had chats with both Adam Bien and Sebastian Daschner asking for a better
> way to work with a simple high-speed throw-away development pom.
>
> They are both working a lot with Java EE applications and want to rely on
> defaults as much as possible.
> So in a way they don't care about plugin versions.
> They only case about things in poms that does matter (unique to that
> project): dependencies
> However, with Java 9+ stuff they are forced to specify plugins with more
> recent versions right now.
>
> So here comes the idea of extensions: you can put it in your maven/lib/ext
> ONCE and your pom is again as clean as possible.
>
> This seems to be a common way of work for some kind of developers and it
> would make sense if Maven could support this.
>
> To me default plugin versions are bound to a minor Maven release, not a
> major.
> When starting with Maven and create your first hello world, it should work
> out of the box.
> Right now if you are using Java 11, you'll probably hit issues because
> some defaults won't work anymore.
> That's a bad thing to me and a valid reason to upgrade the plugins.
>
> I do understand Hervé concerns. We should motivate people to lock their
> plugins in their pom.
> Most of all the packaging-plugin is important. AFAIK all 3.0+ versions
> contain plugin bindings, in which case it should be good enough if that
> plugin is at least specified.
>
> thanks,
> Robert
>
> On Sat, 12 Jan 2019 16:24:31 +0100, Hervé BOUTEMY 
> wrote:
>
> > original idea, let's try to evaluate :)
> >
> > IMHO this could work for packaging plugins in default lifecycle, that are
> > defined in default-bindings.xml, but would not for other lifecycles that
> > are
> > configured in components.xml (without copy/pasting content not related to
> > plugins)
> >
> > I don't think an extension would be easier to use than a pom.xml, it's
> > even
> > IMHO worse since you have to create a new file in a new directory.
> >
> > one question is: is there a use case that an extension would permit that
> > a
> > parent pom would not?
> > the only case I see is if a user does not want to change his parent pom
> > (or
> > cannot): since we don't have "pluginManagement import" (like we have for
> > dependency management).
> >
> >
> > I think for the moment that a parent pom would be more classical, easier
> > to
> > explain: I don't really see a clear benefit to do the job as an extension
> > instead, this would IMHO make the change harder for users
> >
> > Regards,
> >
> > Hervé
> >
> > Le samedi 12 janvier 2019, 15:42:57 CET Robert Scholte a écrit :
> >> Just wondering, can this be solved by an extension?
> >>
> >> So instead of changing this in Maven Core itself, people can add an
> >> extension to Maven with the latest+stable releases.
> >>
> >> Hervé and I already discovered that current focus is mainly on plugins
> >> right now. We should also work on extensions.
> >>
> >> Robert
> >>
> >> On Sat, 12 Jan 2019 15:37:23 +0100, Hervé BOUTEMY
> >> 
> >>
> >> wrote:
> >> > Le vendredi 11 janvier 2019, 12:55:03 CET Tibor Digana a écrit :
> >> >> ok, Herve, 

Re: Update versions of all plugins in default-bindings.xml

[Tibor Digana]

Robert, your email still was not totally concrete.
I understand it like this; the warnings proposed by Herve been introduced
in the nearest version 3.6.x, and an update of default bindings in 3.7.0.
Do we understand it in the same roadmap?

In my experiences, developers do not read warnings because they do not have
time and they expect Maven been an executor which should "just work". Even
nobody cares in the log at all except the end, whether it is BUILD SUCCESS
or failure. And then the people track failed tests or compilations errors,
but never the log or warnings on the top, never.

T


On Sun, Jan 13, 2019 at 11:37 AM Robert Scholte 
wrote:

> This is indeed a good approach.
> The first group doesn't care about this warning, the second one should.
>
> Hervé, can you confirm that in case of *only* specifying the latest
> maven-jar-plugin or maven-war-plugin or other packaging plugin, you won't
> get these warnings.
> It really matters where the default lifecycle bindings are comings from:
> maven-core or packaging plugin.
>
> All this is an interesting feature worth for 3.7.0
>
> thanks,
> Robert
>
> On Sun, 13 Jan 2019 04:39:15 +0100, Hervé BOUTEMY 
>
> wrote:
>
> > we have 2 opposite objectives:
> > - make default near-empty pom work at best,
> > - but force people to have defined plugins versions (then not really
> > empty pom) to get stable build
> >
> > and I checked about the warning message: I was wrong, there is no
> > warning message when plugins without versions are injected by default
> > lifecycle bindings
> >
> > Just test for yourself following pom.xml from any beginner:
> >   
> > 4.0.0
> > com.mycompany.app
> > my-app
> > 1.0-SNAPSHOT
> >   
> >
> > it works = what we expect to ease newcomers experience
> > but there is no warning...
> >
> > IMHO, this is where we need to improve the tool, by adding a warning:
> > I worked on a PoC of DefaultLifecycleBindingsInjector improvement that
> > displays:
> > [WARNING]
> > [WARNING] Some problems were encountered while building the effective
> > model for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
> > [WARNING] Using default plugins versions from bindings:
> > [org.apache.maven.plugins:maven-clean-plugin,
> > org.apache.maven.plugins:maven-install-plugin,
> > org.apache.maven.plugins:maven-resources-plugin,
> > org.apache.maven.plugins:maven-surefire-plugin,
> > org.apache.maven.plugins:maven-compiler-plugin,
> > org.apache.maven.plugins:maven-jar-plugin,
> > org.apache.maven.plugins:maven-deploy-plugin,
> > org.apache.maven.plugins:maven-site-plugin]
> > [WARNING]
> > [WARNING] It is highly recommended to fix these problems because they
> > threaten the stability of your build.
> > [WARNING]
> > [WARNING] For this reason, future Maven versions might no longer
> support
> > building such malformed projects.
> > [WARNING]
> >
> > With this warning, and a parent pom to have an easy fix (instead of 8
> > plugins versions definition), IMHO, we have what we strongly need.
> >
> > And even better, with this warning in place to avoid people to continue
> > to rely on default plugins versions (because of the nasty warning), I
> > could find upgrading default plugins versions not an issue any more!!!
> >
> > Should we try to go this route?
> >
> > Regards,
> >
> > Hervé
> >
> > Le dimanche 13 janvier 2019, 00:15:38 CET Stephen Connolly a écrit :
> >> The original plan was to make plugin version mandatory. Perhaps 3.7.0 is
> >> the time to do that, with a CLI option (to be removed after 3.7.x) to
> >> pull
> >> in the 3.6.x default versions if your pom is missing plugin versions.
> >>
> >> The warning has been there long enough. Let’s pull the trigger.
> >>
> >> On Sat 12 Jan 2019 at 21:34, Tibor Digana 
> >> wrote:
> >> > I have a strong reason to update Surefire due to new JRE versions have
> >> > been
> >> > updated too many times last two years.
> >> > They required a fix done within a few days and some of them are
> >> shaking on
> >> > the chair...
> >> > Our Maven Core is stable and Java 9+ ready but the obsolete plugins
> >> are
> >> > not.
> >> > I want only the same compatibility with default plugins because
> >> people do
> >> > not see these plugins as a distinct community. They are both Maven and
> >> > plugins from us Apache, so they most probably would expect it
> >> consisten

Re: Update versions of all plugins in default-bindings.xml

[Tibor Digana]

Herve, and only those two plugins would appear in the Warning?
Reading StephenC email, this reminds me to think of an algorithm which
downloads the latest version for these two plugins from Maven Central. Here
the question is; Do we need to use default bindings in lifecycle plugin
online builds?

On Sun, Jan 13, 2019 at 6:48 PM Hervé BOUTEMY  wrote:

> Le dimanche 13 janvier 2019, 11:37:43 CET Robert Scholte a écrit :
> > This is indeed a good approach.
> > The first group doesn't care about this warning, the second one should.
> >
> > Hervé, can you confirm that in case of *only* specifying the latest
> > maven-jar-plugin or maven-war-plugin or other packaging plugin, you won't
> > get these warnings.
> I don't understand why you are talking about "latest": this has to do with
> versions injected from default lifecycle plugin bindings, whatever the
> version
> is
> And it perfectly detects if on the 8 plugins benefiting from default
> lifecycle
> plugin binding, 6 have a versions defined but only 2 have not then inherit
> the
> version form the default lifecycle plugin bindings
>
> > It really matters where the default lifecycle bindings are comings from:
> > maven-core or packaging plugin.
> currently, they come from default-bindings.xml in core
>
> I'll prepare a Jira issue and a branch for review
>
> Regards,
>
> Hervé
>
> >
> > All this is an interesting feature worth for 3.7.0
> >
> > thanks,
> > Robert
> >
> > On Sun, 13 Jan 2019 04:39:15 +0100, Hervé BOUTEMY  >
> >
> > wrote:
> > > we have 2 opposite objectives:
> > > - make default near-empty pom work at best,
> > > - but force people to have defined plugins versions (then not really
> > > empty pom) to get stable build
> > >
> > > and I checked about the warning message: I was wrong, there is no
> > > warning message when plugins without versions are injected by default
> > > lifecycle bindings
> > >
> > > Just test for yourself following pom.xml from any beginner:
> > >   
> > >
> > > 4.0.0
> > > com.mycompany.app
> > > my-app
> > > 1.0-SNAPSHOT
> > >
> > >   
> > >
> > > it works = what we expect to ease newcomers experience
> > > but there is no warning...
> > >
> > > IMHO, this is where we need to improve the tool, by adding a warning:
> > > I worked on a PoC of DefaultLifecycleBindingsInjector improvement that
> > > displays:
> > > [WARNING]
> > > [WARNING] Some problems were encountered while building the effective
> > > model for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
> > > [WARNING] Using default plugins versions from bindings:
> > > [org.apache.maven.plugins:maven-clean-plugin,
> > > org.apache.maven.plugins:maven-install-plugin,
> > > org.apache.maven.plugins:maven-resources-plugin,
> > > org.apache.maven.plugins:maven-surefire-plugin,
> > > org.apache.maven.plugins:maven-compiler-plugin,
> > > org.apache.maven.plugins:maven-jar-plugin,
> > > org.apache.maven.plugins:maven-deploy-plugin,
> > > org.apache.maven.plugins:maven-site-plugin]
> > > [WARNING]
> > > [WARNING] It is highly recommended to fix these problems because they
> > > threaten the stability of your build.
> > > [WARNING]
> > > [WARNING] For this reason, future Maven versions might no longer
> support
> > > building such malformed projects.
> > > [WARNING]
> > >
> > > With this warning, and a parent pom to have an easy fix (instead of 8
> > > plugins versions definition), IMHO, we have what we strongly need.
> > >
> > > And even better, with this warning in place to avoid people to continue
> > > to rely on default plugins versions (because of the nasty warning), I
> > > could find upgrading default plugins versions not an issue any more!!!
> > >
> > > Should we try to go this route?
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le dimanche 13 janvier 2019, 00:15:38 CET Stephen Connolly a écrit :
> > >> The original plan was to make plugin version mandatory. Perhaps 3.7.0
> is
> > >> the time to do that, with a CLI option (to be removed after 3.7.x) to
> > >> pull
> > >> in the 3.6.x default versions if your pom is missing plugin versions.
> > >>
> > >> The warning has been there long enough. Let’s pull the trigger.
> > >>
> > >> On Sat 

Re: Update versions of all plugins in default-bindings.xml

[Tibor Digana]

; > displays:
> > > > > [WARNING]
> > > > > [WARNING] Some problems were encountered while building the
> effective
> > > > > model for com.mycompany.app:my-app:jar:1.0-SNAPSHOT
> > > > > [WARNING] Using default plugins versions from bindings:
> > > > > [org.apache.maven.plugins:maven-clean-plugin,
> > > > > org.apache.maven.plugins:maven-install-plugin,
> > > > > org.apache.maven.plugins:maven-resources-plugin,
> > > > > org.apache.maven.plugins:maven-surefire-plugin,
> > > > > org.apache.maven.plugins:maven-compiler-plugin,
> > > > > org.apache.maven.plugins:maven-jar-plugin,
> > > > > org.apache.maven.plugins:maven-deploy-plugin,
> > > > > org.apache.maven.plugins:maven-site-plugin]
> > > > > [WARNING]
> > > > > [WARNING] It is highly recommended to fix these problems because
> they
> > > > > threaten the stability of your build.
> > > > > [WARNING]
> > > > > [WARNING] For this reason, future Maven versions might no longer
> > support
> > > > > building such malformed projects.
> > > > > [WARNING]
> > > > >
> > > > > With this warning, and a parent pom to have an easy fix (instead
> of 8
> > > > > plugins versions definition), IMHO, we have what we strongly need.
> > > > >
> > > > > And even better, with this warning in place to avoid people to
> > continue
> > > > > to rely on default plugins versions (because of the nasty
> warning), I
> > > > > could find upgrading default plugins versions not an issue any
> > more!!!
> > > > >
> > > > > Should we try to go this route?
> > > > >
> > > > > Regards,
> > > > >
> > > > > Hervé
> > > > >
> > > > > Le dimanche 13 janvier 2019, 00:15:38 CET Stephen Connolly a écrit
> :
> > > > >> The original plan was to make plugin version mandatory. Perhaps
> > 3.7.0
> > > > >> is
> > > > >> the time to do that, with a CLI option (to be removed after 3.7.x)
> > to
> > > > >> pull
> > > > >> in the 3.6.x default versions if your pom is missing plugin
> > versions.
> > > > >>
> > > > >> The warning has been there long enough. Let’s pull the trigger.
> > > > >>
> > > > >> On Sat 12 Jan 2019 at 21:34, Tibor Digana  >
> > > > >>
> > > > >> wrote:
> > > > >> > I have a strong reason to update Surefire due to new JRE
> versions
> > > > >> > have
> > > > >> > been
> > > > >> > updated too many times last two years.
> > > > >> > They required a fix done within a few days and some of them are
> > > > >>
> > > > >> shaking on
> > > > >>
> > > > >> > the chair...
> > > > >> > Our Maven Core is stable and Java 9+ ready but the obsolete
> > plugins
> > > > >>
> > > > >> are
> > > > >>
> > > > >> > not.
> > > > >> > I want only the same compatibility with default plugins because
> > > > >>
> > > > >> people do
> > > > >>
> > > > >> > not see these plugins as a distinct community. They are both
> Maven
> > > > >> > and
> > > > >> > plugins from us Apache, so they most probably would expect it
> > > > >>
> > > > >> consistent
> > > > >>
> > > > >> > altogether.
> > > > >> > Makes sense?
> > > > >> >
> > > > >> > On Sat, Jan 12, 2019 at 7:24 PM Bernd Eckenfels
> > > > >>
> > > > >> 
> > > > >>
> > > > >> > wrote:
> > > > >> > > I think that’s a real bad idea if you have to do local
> > > > >>
> > > > >> modifications to
> > > > >>
> > > > >> > > get to a working build environment. Maven is all about not
> > > > >>
> > > > >> requiring you
> > > > >>
> > > > >> > to
> > > > >> >
> > > > >> > > do 

Re: Releasing Maven enforcer plugin

[Tibor Digana]

To lookup easy or fast fixes, and +1 to perform a release then.
T

On Wed, Jan 16, 2019 at 1:56 PM Enrico Olivelli  wrote:

> An user is asking for a release of the enforcer plugin
>
> https://github.com/apache/maven-enforcer/pull/36#issuecomment-447238729
>
> I can prepare the release
>
> Thoughts?
> Enrico
> --
>
>
> -- Enrico Olivelli
>

Re: [VOTE] Release Apache Maven Invoker Plugin version 3.2.0

[Tibor Digana]

+1

On Fri, Jan 18, 2019 at 4:01 PM Robert Scholte  wrote:

> Hi,
>
> We solved 6 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317525&version=12343368&styleName=Text
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317525%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1484/
>
> https://repository.apache.org/content/repositories/maven-1484/org/apache/maven/plugins/maven-invoker-plugin/3.2.0/maven-invoker-plugin-3.2.0-source-release.zip
>
> Source release checksum(s):
> maven-invoker-plugin-3.2.0-source-release.zip sha512:
>
> ae34fb33038d4b6b7b1001883a33f8bb2e0137ea15e33a03401c30585d60943f142e735673b3927998f10af4fd9c4c2a944607cdf9dfbdaf13baa01da4df4cc0
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-invoker-plugin-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
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Maven Wagon version 3.3.2

[Tibor Digana]

+1

On Tue, Feb 5, 2019 at 12:15 AM Michael Osipov  wrote:

> Hi,
>
> We solved 12 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12318122&version=12344885
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20WAGON%20AND%20resolution%20%3D%20Unresolved
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1485/
>
> https://repository.apache.org/content/repositories/maven-1485/org/apache/maven/wagon/wagon/3.3.2/wagon-3.3.2-source-release.zip
>
> Source release checksum(s):
> wagon-3.3.2-source-release.zip
> sha512:
>
> 48505538ee4eec686dea90a45cb683624a16baf899c3f0372a09520dc7a2bac7c3b92d8caf569a4ad4a7efff1b617824125dc2d3a632ee4fafd5b963d0f9a5cb
>
> Staging site:
> https://maven.apache.org/wagon-archives/wagon-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
>
>

Re: [SUREFIRE] maven-metadata.xml does not point to latest snapshot

[Tibor Digana]

Is it so a big problem to keep both versions? This is our internal Nexus
server anyway.

On Wed, Feb 13, 2019 at 1:27 PM Benedikt Ritter  wrote:

> Hello,
>
> Am Di., 12. Feb. 2019 um 08:39 Uhr schrieb Benedikt Ritter <
> brit...@apache.org>:
>
> > Hello,
> >
> > Am Mo., 11. Feb. 2019 um 18:39 Uhr schrieb Enrico Olivelli <
> > eolive...@gmail.com>:
> >
> >> In maven coordinates 3.0.0 is different from 3.0.0-M4 (you already
> knew),
> >> so they can coexist.
> >>
> >
> > Yes, but the question is, what is latest available snapshot? The
> > 3.0.0-SNAPSHOT has been deployed sometime last June.
> >
> >
> >>
> >> How are you referring to surefire in your project?
> >>
> >
> > We have some end to end tests that determine the latest snapshots of some
> > plugins so we can run tests against them. We do this by analyzing the
> > maven-metadata.xml so we don't have to hard code all the versions.
> >
> >
> >>
> >> Btw I will check and try to deploy current master
> >>
> >
> > I checked, it didn't help. Maybe the master branch should have
> > 3.0.0-SNAPSHOT as version and only be updated to a milestone version for
> a
> > milestone release.
> >
>
> the problem is still present. I suspect maven can not deal with milestone
> snapshot version. My suggestion is to change the version on the master
> branch to 3.0.0-SNAPSHOT and create milestone releases without having an
> explicit milestone snapshot first. This would fix the metadata in that the
> latest version would again be the latest deployment from the master branch.
>
> Regards,
> Benedikt
>
>
> >
> > Thank you!
> > Benedikt
> >
> >
> >>
> >> Enrico
> >>
> >> Il giorno lun 11 feb 2019, 14:59 Benedikt Ritter 
> ha
> >> scritto:
> >>
> >> > Hi,
> >> >
> >> > I just realized that the maven-metadata.xml for Surefire in the
> snapshot
> >> > repository [1] does not point to the latest Surefire snapshot. It says
> >> that
> >> > 3.0.0-SNAPSHOT is the latest version but 3.0.0-M4-SNAPSHOT is actually
> >> the
> >> > latest available snapshot. Is it possible to correct this?
> >> >
> >> > Thanks,
> >> > Benedikt
> >> >
> >> > [1]
> >> >
> >> >
> >>
> https://repository.apache.org/content/groups/snapshots/org/apache/maven/plugins/maven-surefire-plugin/maven-metadata.xml
> >> >
> >>
> >
>

Re: [SUREFIRE] maven-metadata.xml does not point to latest snapshot

[Tibor Digana]

Why you change POM if there is no problem?
If the problem is in deploy-plugin then it should be fixed.

On Thu, Feb 14, 2019 at 11:57 AM Olivier Lamy  wrote:

> makes sense for me. I will update master branch with correct version
>
> On Thu, 14 Feb 2019 at 20:42, Benedikt Ritter  wrote:
>
> > Am Mi., 13. Feb. 2019 um 17:48 Uhr schrieb Tibor Digana <
> > tibordig...@apache.org>:
> >
> > > Is it so a big problem to keep both versions? This is our internal
> Nexus
> > > server anyway.
> > >
> >
> > From my PoV the metadata is incorrect. Latest should point to the latest
> > available build. At the moment it does not. The Snapshot repository is
> not
> > an internal Nexus server. It is a public artifact repository for trying
> out
> > new things. I think the Maven project should get its own metadata
> right...
> > Why are you resisting? Do you see problems when updating master to
> > 3.0.0-SNAPSHOT?
> >
> > Benedikt
> >
> >
> > >
> > > On Wed, Feb 13, 2019 at 1:27 PM Benedikt Ritter 
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > Am Di., 12. Feb. 2019 um 08:39 Uhr schrieb Benedikt Ritter <
> > > > brit...@apache.org>:
> > > >
> > > > > Hello,
> > > > >
> > > > > Am Mo., 11. Feb. 2019 um 18:39 Uhr schrieb Enrico Olivelli <
> > > > > eolive...@gmail.com>:
> > > > >
> > > > >> In maven coordinates 3.0.0 is different from 3.0.0-M4 (you already
> > > > knew),
> > > > >> so they can coexist.
> > > > >>
> > > > >
> > > > > Yes, but the question is, what is latest available snapshot? The
> > > > > 3.0.0-SNAPSHOT has been deployed sometime last June.
> > > > >
> > > > >
> > > > >>
> > > > >> How are you referring to surefire in your project?
> > > > >>
> > > > >
> > > > > We have some end to end tests that determine the latest snapshots
> of
> > > some
> > > > > plugins so we can run tests against them. We do this by analyzing
> the
> > > > > maven-metadata.xml so we don't have to hard code all the versions.
> > > > >
> > > > >
> > > > >>
> > > > >> Btw I will check and try to deploy current master
> > > > >>
> > > > >
> > > > > I checked, it didn't help. Maybe the master branch should have
> > > > > 3.0.0-SNAPSHOT as version and only be updated to a milestone
> version
> > > for
> > > > a
> > > > > milestone release.
> > > > >
> > > >
> > > > the problem is still present. I suspect maven can not deal with
> > milestone
> > > > snapshot version. My suggestion is to change the version on the
> master
> > > > branch to 3.0.0-SNAPSHOT and create milestone releases without having
> > an
> > > > explicit milestone snapshot first. This would fix the metadata in
> that
> > > the
> > > > latest version would again be the latest deployment from the master
> > > branch.
> > > >
> > > > Regards,
> > > > Benedikt
> > > >
> > > >
> > > > >
> > > > > Thank you!
> > > > > Benedikt
> > > > >
> > > > >
> > > > >>
> > > > >> Enrico
> > > > >>
> > > > >> Il giorno lun 11 feb 2019, 14:59 Benedikt Ritter <
> > brit...@apache.org>
> > > > ha
> > > > >> scritto:
> > > > >>
> > > > >> > Hi,
> > > > >> >
> > > > >> > I just realized that the maven-metadata.xml for Surefire in the
> > > > snapshot
> > > > >> > repository [1] does not point to the latest Surefire snapshot.
> It
> > > says
> > > > >> that
> > > > >> > 3.0.0-SNAPSHOT is the latest version but 3.0.0-M4-SNAPSHOT is
> > > actually
> > > > >> the
> > > > >> > latest available snapshot. Is it possible to correct this?
> > > > >> >
> > > > >> > Thanks,
> > > > >> > Benedikt
> > > > >> >
> > > > >> > [1]
> > > > >> >
> > > > >> >
> > > > >>
> > > >
> > >
> >
> https://repository.apache.org/content/groups/snapshots/org/apache/maven/plugins/maven-surefire-plugin/maven-metadata.xml
> > > > >> >
> > > > >>
> > > > >
> > > >
> > >
> >
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>

Re: [SUREFIRE] maven-metadata.xml does not point to latest snapshot

[Tibor Digana]

Benedikt, it does not mean that something with public IP is for public use.
We made only a compromise for some users to verify some functionality.

On Thu, Feb 14, 2019 at 11:42 AM Benedikt Ritter  wrote:

> Am Mi., 13. Feb. 2019 um 17:48 Uhr schrieb Tibor Digana <
> tibordig...@apache.org>:
>
> > Is it so a big problem to keep both versions? This is our internal Nexus
> > server anyway.
> >
>
> From my PoV the metadata is incorrect. Latest should point to the latest
> available build. At the moment it does not. The Snapshot repository is not
> an internal Nexus server. It is a public artifact repository for trying out
> new things. I think the Maven project should get its own metadata right...
> Why are you resisting? Do you see problems when updating master to
> 3.0.0-SNAPSHOT?
>
> Benedikt
>
>
> >
> > On Wed, Feb 13, 2019 at 1:27 PM Benedikt Ritter 
> > wrote:
> >
> > > Hello,
> > >
> > > Am Di., 12. Feb. 2019 um 08:39 Uhr schrieb Benedikt Ritter <
> > > brit...@apache.org>:
> > >
> > > > Hello,
> > > >
> > > > Am Mo., 11. Feb. 2019 um 18:39 Uhr schrieb Enrico Olivelli <
> > > > eolive...@gmail.com>:
> > > >
> > > >> In maven coordinates 3.0.0 is different from 3.0.0-M4 (you already
> > > knew),
> > > >> so they can coexist.
> > > >>
> > > >
> > > > Yes, but the question is, what is latest available snapshot? The
> > > > 3.0.0-SNAPSHOT has been deployed sometime last June.
> > > >
> > > >
> > > >>
> > > >> How are you referring to surefire in your project?
> > > >>
> > > >
> > > > We have some end to end tests that determine the latest snapshots of
> > some
> > > > plugins so we can run tests against them. We do this by analyzing the
> > > > maven-metadata.xml so we don't have to hard code all the versions.
> > > >
> > > >
> > > >>
> > > >> Btw I will check and try to deploy current master
> > > >>
> > > >
> > > > I checked, it didn't help. Maybe the master branch should have
> > > > 3.0.0-SNAPSHOT as version and only be updated to a milestone version
> > for
> > > a
> > > > milestone release.
> > > >
> > >
> > > the problem is still present. I suspect maven can not deal with
> milestone
> > > snapshot version. My suggestion is to change the version on the master
> > > branch to 3.0.0-SNAPSHOT and create milestone releases without having
> an
> > > explicit milestone snapshot first. This would fix the metadata in that
> > the
> > > latest version would again be the latest deployment from the master
> > branch.
> > >
> > > Regards,
> > > Benedikt
> > >
> > >
> > > >
> > > > Thank you!
> > > > Benedikt
> > > >
> > > >
> > > >>
> > > >> Enrico
> > > >>
> > > >> Il giorno lun 11 feb 2019, 14:59 Benedikt Ritter <
> brit...@apache.org>
> > > ha
> > > >> scritto:
> > > >>
> > > >> > Hi,
> > > >> >
> > > >> > I just realized that the maven-metadata.xml for Surefire in the
> > > snapshot
> > > >> > repository [1] does not point to the latest Surefire snapshot. It
> > says
> > > >> that
> > > >> > 3.0.0-SNAPSHOT is the latest version but 3.0.0-M4-SNAPSHOT is
> > actually
> > > >> the
> > > >> > latest available snapshot. Is it possible to correct this?
> > > >> >
> > > >> > Thanks,
> > > >> > Benedikt
> > > >> >
> > > >> > [1]
> > > >> >
> > > >> >
> > > >>
> > >
> >
> https://repository.apache.org/content/groups/snapshots/org/apache/maven/plugins/maven-surefire-plugin/maven-metadata.xml
> > > >> >
> > > >>
> > > >
> > >
> >
>

Re: Surefire maintenance release

[Tibor Digana]

Stephane, the problem is with Spring upgrade policy as I have understood.

What about releasing RC4 for you?
Do you really need to have SUREFIRE-1546 done? We do not want to enable it
implicitly as it is done in master right now, and therefore M4 needs to
take more time to enable this feature via configuration.

I see that the policy is against itself. If you concentrate only on
policies with project dependencies, you won't break anything.
We made a big investment (SUREFIRE-1614, ...) to not to break current
users. So please let us continue our work and let you and yourself use
3.0.0-M3 and continue whatever it means with Spring policies.Our plan is to
not to break backwards compatibility till 3.0.0-M5.

There is reason that you use Surefire in your project and provide us with
feedback. We can always release milestones or RCs (which don't have
different meaning for me).

Meanwhile, please check it out with version 3.0.0-M4-SNAPSHOT from
https://repository.apache.org/content/groups/snapshots/org/apache/maven/plugins/maven-surefire-plugin/
(plugin repository) and let us know with the feedback.

Is RC4 legal for your policies?

Cheers
Tibor


On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll 
wrote:

> Hi everyone,
>
> It's great to see the progress on Surefire 3.0 and I wanted to reach out to
> discuss a practicable problem with the 2.x line. There are a number of
> fixes for JUnit 5 that are only available in the 3.x line that isn't GA
> yet. [1][2]
>
> Putting my Spring Boot hat for a min, this actually prevents us from
> upgrading our test support to JUnit 5: our plan is to offer maximum
> flexibility by providing the vintage engine (so that users can keep their
> tests and migrate at their own pace).
>
> We can't upgrade to a milestone as our upgrade policy prevents that
> (regardless of how stable this is and especially since backward
> incompatible changes have been pushed to the latest milestone). So we're
> kind of stuck.
>
> Would there be an appetite to backport those fixes and release a 2.22.2?
>
> Thanks,
> S.
>
> [1] https://issues.apache.org/jira/browse/SUREFIRE-1614
> [2] https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546
>

Re: Surefire maintenance release

[Tibor Digana]

Sorry, in normal circumstances projects release BOM with
dependencyManagement but not the pluginManagement.
We did not break current users and so we split the entire work into
multiple stages. The naming convention really is not a problem as you can
see and Stephane confirmed it.
So we made welcome compromises on our side in ASF and now your steps in
Spring should be to make compromise in your internal policies.

Cheers
Tibor

On Mon, Feb 25, 2019 at 11:44 AM Stephane Nicoll 
wrote:

> Thanks for the reply. See my feedback below
>
> On Mon, Feb 25, 2019 at 11:20 AM Tibor Digana 
> wrote:
>
> > Stephane, the problem is with Spring upgrade policy as I have understood.
> >
> > What about releasing RC4 for you?
> >
>
> It does not matter how you call it. We don't want to be in a position where
> our users get plugin management for a given version of surefire that:
>
> 1. is not GA
> 2. subsequent milestone/RC/release will break backward compatibility
>
>
>
> > Do you really need to have SUREFIRE-1546 done? We do not want to enable
> it
> > implicitly as it is done in master right now, and therefore M4 needs to
> > take more time to enable this feature via configuration.
> >
>
> I think we do.
>
> A minor release of Spring Boot cannot require users to write their tests
> using the JUnit 5 API as it would be a breaking change for every test
> they’ve written using JUnit 4. On the other hand, we know that users want
> to be able to use JUnit 5 and we’re holding them back at the moment.
>
> The way the JUnit team has dealt with the migration is the use of the
> vintage engine that we would provide by default. Users that have migrated
> their tests can exclude the vintage engine while users that are in the
> process of migrating can benefit from a setup where they can start
> migrating while keeping some of their tests unchanged.
>
> We need surefire to support that scenario and the 2.x line does not.
>
>
> >
> > I see that the policy is against itself. If you concentrate only on
> > policies with project dependencies, you won't break anything.
> > We made a big investment (SUREFIRE-1614, ...) to not to break current
> > users. So please let us continue our work and let you and yourself use
> > 3.0.0-M3 and continue whatever it means with Spring policies.Our plan is
> to
> > not to break backwards compatibility till 3.0.0-M5.
> >
>
> As I've indicated, we cannot upgrade to a version and then be stuck on
> milestones because a later one introduces backward incompatible changes.
>
>
> >
> > There is reason that you use Surefire in your project and provide us with
> > feedback. We can always release milestones or RCs (which don't have
> > different meaning for me).
> >
>
> To be fair, we use surefire because Spring Boot supports Maven (as it
> should). JUnit 5 was released 18 months ago so a full support in the
> current GA would be very much appreciated.
>
>
>
> >
> > Meanwhile, please check it out with version 3.0.0-M4-SNAPSHOT from
> >
> >
> https://repository.apache.org/content/groups/snapshots/org/apache/maven/plugins/maven-surefire-plugin/
> > (plugin repository) and let us know with the feedback.
> >
> > Is RC4 legal for your policies?
> >
>
> No it isn't. The name is not the problem by the way as I've hopefully
> indicated above.
>
> Thanks,
> S.
>
>
>
>
> >
> > Cheers
> > Tibor
> >
> >
> > On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll <
> stephane.nic...@gmail.com
> > >
> > wrote:
> >
> > > Hi everyone,
> > >
> > > It's great to see the progress on Surefire 3.0 and I wanted to reach
> out
> > to
> > > discuss a practicable problem with the 2.x line. There are a number of
> > > fixes for JUnit 5 that are only available in the 3.x line that isn't GA
> > > yet. [1][2]
> > >
> > > Putting my Spring Boot hat for a min, this actually prevents us from
> > > upgrading our test support to JUnit 5: our plan is to offer maximum
> > > flexibility by providing the vintage engine (so that users can keep
> their
> > > tests and migrate at their own pace).
> > >
> > > We can't upgrade to a milestone as our upgrade policy prevents that
> > > (regardless of how stable this is and especially since backward
> > > incompatible changes have been pushed to the latest milestone). So
> we're
> > > kind of stuck.
> > >
> > > Would there be an appetite to backport those fixes and release a
> 2.22.2?
> > >
> > > Thanks,
> > > S.
> > >
> > > [1] https://issues.apache.org/jira/browse/SUREFIRE-1614
> > > [2]
> > https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546
> > >
> >
>

Re: Surefire maintenance release

[Tibor Digana]

Stephane,
I have been quite busy with other JUnit5 work - SUREFIRE-1585.
Can you join us in the chat on Slack "the-asf.slack.com"?
You will find the Channel named "surefire".
Ping us as soon as you are ready and we will find some way.
I am glad!

Cheers
Tibor

On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll 
wrote:

> Hi everyone,
>
> It's great to see the progress on Surefire 3.0 and I wanted to reach out to
> discuss a practicable problem with the 2.x line. There are a number of
> fixes for JUnit 5 that are only available in the 3.x line that isn't GA
> yet. [1][2]
>
> Putting my Spring Boot hat for a min, this actually prevents us from
> upgrading our test support to JUnit 5: our plan is to offer maximum
> flexibility by providing the vintage engine (so that users can keep their
> tests and migrate at their own pace).
>
> We can't upgrade to a milestone as our upgrade policy prevents that
> (regardless of how stable this is and especially since backward
> incompatible changes have been pushed to the latest milestone). So we're
> kind of stuck.
>
> Would there be an appetite to backport those fixes and release a 2.22.2?
>
> Thanks,
> S.
>
> [1] https://issues.apache.org/jira/browse/SUREFIRE-1614
> [2] https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546
>

Re: Surefire maintenance release

[Tibor Digana]

Hi  Stephane,

We are talking only about these two commits [1]?
Notice that 001e807 modifies file names to the verbose one which breaks
backwards compatibility and this should not forcibly (by default) happen in
your version/branch.
Try to fork the project, make a local branch and then reset HEAD to [2],
i.e. git reset --hard 19006aa70f36705f399b8c105a16f636904f00f3
And then cherrypick both commits [1].
Make sure the order is correct but it won't be so straightforward. The
tests have to pass (mvn install -P run-its).

[1]:
https://github.com/apache/maven-surefire/commit/f517d349ede0e15229e3c48f45d10dabc72a3fc9
https://github.com/apache/maven-surefire/commit/001e8075b8db7861aaefb5af4c256d919a9b2e7a

[2]:
https://github.com/apache/maven-surefire/commit/19006aa70f36705f399b8c105a16f636904f00f3

Cheers
Tibor

On Mon, Feb 25, 2019 at 8:54 AM Stephane Nicoll 
wrote:

> Hi everyone,
>
> It's great to see the progress on Surefire 3.0 and I wanted to reach out to
> discuss a practicable problem with the 2.x line. There are a number of
> fixes for JUnit 5 that are only available in the 3.x line that isn't GA
> yet. [1][2]
>
> Putting my Spring Boot hat for a min, this actually prevents us from
> upgrading our test support to JUnit 5: our plan is to offer maximum
> flexibility by providing the vintage engine (so that users can keep their
> tests and migrate at their own pace).
>
> We can't upgrade to a milestone as our upgrade policy prevents that
> (regardless of how stable this is and especially since backward
> incompatible changes have been pushed to the latest milestone). So we're
> kind of stuck.
>
> Would there be an appetite to backport those fixes and release a 2.22.2?
>
> Thanks,
> S.
>
> [1] https://issues.apache.org/jira/browse/SUREFIRE-1614
> [2] https://issues.apache.org/jira/projects/SUREFIRE/issues/SUREFIRE-1546
>

Re: [VOTE] Release Apache Maven Artifact Transfer Version 0.11.0

[Tibor Digana]

+1

On Sun, Feb 24, 2019 at 9:34 PM Karl Heinz Marbaise 
wrote:

> Hi to all,
>
> We solved 3 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12344643
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20component%20%3D%20maven-artifact-transfer
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1489
>
>
> https://repository.apache.org/content/repositories/maven-1489/org/apache/maven/shared/maven-artifact-transfer/0.11.0/maven-artifact-transfer-0.11.0-source-release.zip
>
> Source release checksum(s):
> maven-artifact-transfer-0.11.0-source-release.zip sha1:
> c8c60ebb6046450ff75bfb60f64af415b3b5ea72
>
> maven-artifact-transfer-0.11.0-source-release.zip sha512:
>
> daccd4844ebc389d8e269be41b59c0754a473da9b447c86556b6c80b0208f3b08bc822372d4c6055a09b4130665cb7803b807e427daf160bc29d20d026c85963
>
> Staging site:
> http://maven.apache.org/shared-archives/maven-artifact-transfer-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
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> 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 Javadoc Plugin version 3.1.0

[Tibor Digana]

+1

On Fri, Mar 1, 2019 at 2:57 PM Robert Scholte  wrote:

> Hi,
>
> We solved 46(!) issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317529&version=12343313&styleName=Text
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%12317529%20AND%20status%20%3D%20Open%20ORDER%20BY%20key%20DESC%2C%20priority%20DESC
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1490
>
> https://repository.apache.org/content/repositories/maven-1490/org/apache/maven/plugins/maven-javadoc-plugin/3.1.0/maven-javadoc-plugin-3.1.0-source-release.zip
>
> Source release checksum(s):
> maven-javadoc-plugin-3.1.0-source-release.zip sha512:
> d0a801b22d7b16d34bae881a56cace60a91266e49c519eb05209e923c670c064dd7e0eaca9a1bd542a02bbb3d59ef3739c96fbcf1c2802b4836149c259f44906
>
> Staging site:
> https://maven.apache.org/plugins-archives/maven-javadoc-plugin-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

Re: [VOTE] Release Apache Maven Artifact Transfer Version 0.11.0

[Tibor Digana]

Hi Karl,
How you want to continue with this? The release plugin made commits to the
Git history. Do you want to complete it with deployment?

On Sun, Feb 24, 2019 at 9:34 PM Karl Heinz Marbaise 
wrote:

> Hi to all,
>
> We solved 3 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317922&version=12344643
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MSHARED%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20component%20%3D%20maven-artifact-transfer
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1489
>
>
> https://repository.apache.org/content/repositories/maven-1489/org/apache/maven/shared/maven-artifact-transfer/0.11.0/maven-artifact-transfer-0.11.0-source-release.zip
>
> Source release checksum(s):
> maven-artifact-transfer-0.11.0-source-release.zip sha1:
> c8c60ebb6046450ff75bfb60f64af415b3b5ea72
>
> maven-artifact-transfer-0.11.0-source-release.zip sha512:
>
> daccd4844ebc389d8e269be41b59c0754a473da9b447c86556b6c80b0208f3b08bc822372d4c6055a09b4130665cb7803b807e427daf160bc29d20d026c85963
>
> Staging site:
> http://maven.apache.org/shared-archives/maven-artifact-transfer-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
>
> Kind regards
> Karl Heinz Marbaise
>
> -
> 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
>
>

Release maven-compiler-plugin:3.8.1

[Tibor Digana]

Hi,

All the issues for maven-compiler-plugin:3.8.1 is fixed.
https://issues.apache.org/jira/projects/MCOMPILER/versions/12343484

Can we agree on cutting the release version?
Do you see any reason to wait?

I am very happy to see a new incremental compiler, see
https://issues.apache.org/jira/browse/MCOMPILER-349

Cheers
Tibor