Re: [DISCUSS] Maven 3.8.x and 3.9.x

2021-12-17 Thread Michael Osipov

Am 2021-12-17 um 17:29 schrieb Guillaume Nodet:

Le ven. 17 déc. 2021 à 14:25, Michael Osipov  a écrit :


Am 2021-12-13 um 11:39 schrieb Guillaume Nodet:

In order to progress on a few issues, I'd like to discuss two points.
* merge https://github.com/apache/maven/pull/628 into the 3.8.x

branch

and release 3.8.5 asap.  This is a long-standing issue which had a couple
of trial fixes over the past months.
* create a 3.9.x branch to merge

https://github.com/apache/maven/pull/630

and https://github.com/apache/maven/pull/630

The 3.9.x will be needed in order to progress on
maven-build-cache-extension.  Right now, the tests are done on two

branches

that have to be built (for 3.x and 4.x), forbidding any kind of release
(which I don't propose at this time, we first need to extract it to a
separate repo anyway...)


Several important things to note here:

Maven 3.8.5 should include your fix, granted. I want to include a new
version of Wagon (3.5.0) which will remove JSoup due to several issues
which come along with it.



Ok.  Could you put 3.8.5 as a fixVersion for the jira issues ?


Yes, will create those this weekend.



I have currently a branch open maven-3.8.x-resolver-1.7.x which
basically lifts 3.8.x to Java 8 and adds Resolver 1.7.x



Shouldn't that be part of 3.9.0 instead ?


It will, I started off with 3.8.x since I didn't have anything else. The 
branch will go for maven-3.9.x.



After 3.8.5 has been done I want to rebase my branch onto 3.8.5 and
moved that to 3.9.x, *then* you can start merging your open PRs
regarding API extension for build caching.

Is that acceptable for you?



Yes.


:-)

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



Re: [DISCUSS] Maven 3.8.x and 3.9.x

2021-12-17 Thread Guillaume Nodet
Le ven. 17 déc. 2021 à 14:25, Michael Osipov  a écrit :

> Am 2021-12-13 um 11:39 schrieb Guillaume Nodet:
> > In order to progress on a few issues, I'd like to discuss two points.
> >* merge https://github.com/apache/maven/pull/628 into the 3.8.x
> branch
> > and release 3.8.5 asap.  This is a long-standing issue which had a couple
> > of trial fixes over the past months.
> >* create a 3.9.x branch to merge
> https://github.com/apache/maven/pull/630
> > and https://github.com/apache/maven/pull/630
> >
> > The 3.9.x will be needed in order to progress on
> > maven-build-cache-extension.  Right now, the tests are done on two
> branches
> > that have to be built (for 3.x and 4.x), forbidding any kind of release
> > (which I don't propose at this time, we first need to extract it to a
> > separate repo anyway...)
>
> Several important things to note here:
>
> Maven 3.8.5 should include your fix, granted. I want to include a new
> version of Wagon (3.5.0) which will remove JSoup due to several issues
> which come along with it.
>

Ok.  Could you put 3.8.5 as a fixVersion for the jira issues ?


> I have currently a branch open maven-3.8.x-resolver-1.7.x which
> basically lifts 3.8.x to Java 8 and adds Resolver 1.7.x
>

Shouldn't that be part of 3.9.0 instead ?


> After 3.8.5 has been done I want to rebase my branch onto 3.8.5 and
> moved that to 3.9.x, *then* you can start merging your open PRs
> regarding API extension for build caching.
>
> Is that acceptable for you?
>

Yes.


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

-- 

Guillaume Nodet


[ANN] Apache Maven Doxia Sitetools 1.11.1 released

2021-12-17 Thread Michael Osipov
The Apache Maven team is pleased to announce the release of the Apache 
Maven Doxia Sitetools, version 1.11.1


Doxia Sitetools is an extension of base Doxia component that generates 
either HTML sites, consisting of decoration and content that was 
generated by Doxia, or documents like RTF or PDF.


https://maven.apache.org/doxia/doxia-sitetools/

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

https://maven.apache.org/doxia/doxia-sitetools/download.cgi


Release Notes - Maven Doxia Sitetools - Version 1.11.1

** Improvement
* [DOXIASITETOOLS-234] - improve documentation on site.xml 
inheritance vs interpolation


** Task
* [DOXIASITETOOLS-236] - Deprecate Doxia Sitetools Doc Renderer

** Dependency upgrade
* [DOXIASITETOOLS-237] - Upgrade Maven Doxia to 1.11.1


Enjoy,

-The Apache Maven team

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



[RESULT] [VOTE] Release Apache Maven Doxia Sitetools version 1.11.1

2021-12-17 Thread Michael Osipov

Hi,

The vote has passed with the following result:

+1: Michael Osipov, Hervé Boutemy, Sylwester Lachiewicz, Tamás Cservenák

PMC quorum: reached

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


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



Re: [DISCUSS] Maven 3.8.x and 3.9.x

2021-12-17 Thread Michael Osipov

Am 2021-12-13 um 11:39 schrieb Guillaume Nodet:

In order to progress on a few issues, I'd like to discuss two points.
   * merge https://github.com/apache/maven/pull/628 into the 3.8.x branch
and release 3.8.5 asap.  This is a long-standing issue which had a couple
of trial fixes over the past months.
   * create a 3.9.x branch to merge https://github.com/apache/maven/pull/630
and https://github.com/apache/maven/pull/630

The 3.9.x will be needed in order to progress on
maven-build-cache-extension.  Right now, the tests are done on two branches
that have to be built (for 3.x and 4.x), forbidding any kind of release
(which I don't propose at this time, we first need to extract it to a
separate repo anyway...)


Several important things to note here:

Maven 3.8.5 should include your fix, granted. I want to include a new 
version of Wagon (3.5.0) which will remove JSoup due to several issues 
which come along with it.
I have currently a branch open maven-3.8.x-resolver-1.7.x which 
basically lifts 3.8.x to Java 8 and adds Resolver 1.7.x
After 3.8.5 has been done I want to rebase my branch onto 3.8.5 and 
moved that to 3.9.x, *then* you can start merging your open PRs 
regarding API extension for build caching.


Is that acceptable for you?

Michael

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



Re: Supported versions policy - Maven Plugins

2021-12-17 Thread Romain Manni-Bucau
Hi,

Think we already discussed it partially and said we were in a bad state
because only 3.x is supported/worked but no final release is available and
that 2.x would be best effort only (not even any guarantee about CVE fixes
until somebody does the job like last time).
So 3.0.0 is required, M6 is optional IMHO - several of us want to go final
directly but Tibor can want another milestone maybe?, and a 2.x to handle
potential future work can be desired but others can be dropped I think.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 17 déc. 2021 à 12:55, Slawomir Jaranowski 
a écrit :

> Hi,
>
> On example of the Surefire project I would build some policy /
> documentation / information about which versions are supported and what
> for.
> It can be generally for all maintenanced Maven Plugins by AFS.
>
> =
>
> First topic what version of plugin should be supported, in the Surefire I
> see opened releases in jira [1] for
> - Backlog (???)
> - 3.0
> - 3.0.1
> - 3.0.0-M6
> - 2.22.3
> - 2.21.1
>
> I'm not sure if we can support so many versions at the same time ...
>
> In the Surefire case Tibor's opinion will be very appreciated.
>
> We should should clear message for user which version and with scope is
> supported, eg:
> 3.x - only latest version for bug fixes and new feature
> 2.x - only for security vulnerability
>
> Currently Surefire has reported 269 issues without clear policy it is not
> possible to support them.
>
> =
>
> Second topic - what JDK and Maven Api should be supported by plugins.
> I see that - Since June 2020, Maven Plugin API used by plugins >= 3.1.0 +
> Java 8 prerequisites [2]
>
> But also I see that some of plugin in last time has updated api to 3.2.5
>
> In this topic we should list supported matrix, like
> Maven: 3.2.x, 3.3.x ... JDK: 1.8, 11, 17, ...
> and use the same matrix on CI to be sure
>
> =
>
> After decision taken I think that such information should be on page:
> "Maven Plugins" [3]
>
> Probably the topic was discussed ... but I don't see the result ... so try
> to start again.
>
> [1]
>
> https://issues.apache.org/jira/projects/SUREFIRE?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=unreleased
> [2] https://maven.apache.org/developers/compatibility-plan.html
> [3] https://maven.apache.org/plugins/index.html
>
> --
> Sławomir Jaranowski
>


[GitHub] [maven-artifact-transfer] dependabot[bot] opened a new pull request #55: Bump apiMaven.version from 3.0 to 3.8.4

2021-12-17 Thread GitBox


dependabot[bot] opened a new pull request #55:
URL: https://github.com/apache/maven-artifact-transfer/pull/55


   Bumps `apiMaven.version` from 3.0 to 3.8.4.
   Updates `maven-core` from 3.0 to 3.8.4
   
   Commits
   
   https://github.com/apache/maven/commit/9b656c72d54e5bacbed989b64718c159fe39b537";>9b656c7
 [maven-release-plugin] prepare release maven-3.8.4
   https://github.com/apache/maven/commit/19c3b917b3604f93fef0583a08e70f8695d3a359";>19c3b91
 [MNG-7331] Upgrade Jansi to 2.4.0
   https://github.com/apache/maven/commit/5c36bf5ef78a162cefea47ccdaf0d28e01c1426c";>5c36bf5
 [MNG-7312] Revert ThreadLocal approach from MNG-6843 and MNG-7251
   https://github.com/apache/maven/commit/fb5f3f5b0f36d3232b0193c1d9b33fd0b36b9601";>fb5f3f5
 [MNG-7270] Switch to shell alternative to "which"
   https://github.com/apache/maven/commit/b6186e2c7714158b5a2709f4af9d40b194c53f55";>b6186e2
 Remove swap file
   https://github.com/apache/maven/commit/21e597ec777f0b74eed4e067b58b6eb8b0c9fad4";>21e597e
 [maven-release-plugin] prepare for next development iteration
   https://github.com/apache/maven/commit/ff8e977a158738155dc465c6a97ffaf31982d739";>ff8e977
 [maven-release-plugin] prepare release maven-3.8.3
   https://github.com/apache/maven/commit/0a6bbb8301717d386e6588a7ea32e3e2451c7060";>0a6bbb8
 [MNG-7235] Speed improvements when calculating the sorted project graph
   https://github.com/apache/maven/commit/8882a9c599013182e42f0c7c321396c23b84dbe0";>8882a9c
 [MNG-7164] Add constructor MojoExecutionException(Throwable)
   https://github.com/apache/maven/commit/ab54d17dc2ec355c1e002e8751739edd9a96fcc3";>ab54d17
 [MNG-7253] Display relocation message defined in model
   Additional commits viewable in https://github.com/apache/maven/compare/maven-3.0...maven-3.8.4";>compare 
view
   
   
   
   
   Updates `maven-artifact` from 3.0 to 3.8.4
   
   Commits
   
   https://github.com/apache/maven/commit/9b656c72d54e5bacbed989b64718c159fe39b537";>9b656c7
 [maven-release-plugin] prepare release maven-3.8.4
   https://github.com/apache/maven/commit/19c3b917b3604f93fef0583a08e70f8695d3a359";>19c3b91
 [MNG-7331] Upgrade Jansi to 2.4.0
   https://github.com/apache/maven/commit/5c36bf5ef78a162cefea47ccdaf0d28e01c1426c";>5c36bf5
 [MNG-7312] Revert ThreadLocal approach from MNG-6843 and MNG-7251
   https://github.com/apache/maven/commit/fb5f3f5b0f36d3232b0193c1d9b33fd0b36b9601";>fb5f3f5
 [MNG-7270] Switch to shell alternative to "which"
   https://github.com/apache/maven/commit/b6186e2c7714158b5a2709f4af9d40b194c53f55";>b6186e2
 Remove swap file
   https://github.com/apache/maven/commit/21e597ec777f0b74eed4e067b58b6eb8b0c9fad4";>21e597e
 [maven-release-plugin] prepare for next development iteration
   https://github.com/apache/maven/commit/ff8e977a158738155dc465c6a97ffaf31982d739";>ff8e977
 [maven-release-plugin] prepare release maven-3.8.3
   https://github.com/apache/maven/commit/0a6bbb8301717d386e6588a7ea32e3e2451c7060";>0a6bbb8
 [MNG-7235] Speed improvements when calculating the sorted project graph
   https://github.com/apache/maven/commit/8882a9c599013182e42f0c7c321396c23b84dbe0";>8882a9c
 [MNG-7164] Add constructor MojoExecutionException(Throwable)
   https://github.com/apache/maven/commit/ab54d17dc2ec355c1e002e8751739edd9a96fcc3";>ab54d17
 [MNG-7253] Display relocation message defined in model
   Additional commits viewable in https://github.com/apache/maven/compare/maven-3.0...maven-3.8.4";>compare 
view
   
   
   
   
   Updates `maven-plugin-api` from 3.0.5 to 3.8.4
   
   Commits
   
   https://github.com/apache/maven/commit/9b656c72d54e5bacbed989b64718c159fe39b537";>9b656c7
 [maven-release-plugin] prepare release maven-3.8.4
   https://github.com/apache/maven/commit/19c3b917b3604f93fef0583a08e70f8695d3a359";>19c3b91
 [MNG-7331] Upgrade Jansi to 2.4.0
   https://github.com/apache/maven/commit/5c36bf5ef78a162cefea47ccdaf0d28e01c1426c";>5c36bf5
 [MNG-7312] Revert ThreadLocal approach from MNG-6843 and MNG-7251
   https://github.com/apache/maven/commit/fb5f3f5b0f36d3232b0193c1d9b33fd0b36b9601";>fb5f3f5
 [MNG-7270] Switch to shell alternative to "which"
   https://github.com/apache/maven/commit/b6186e2c7714158b5a2709f4af9d40b194c53f55";>b6186e2
 Remove swap file
   https://github.com/apache/maven/commit/21e597ec777f0b74eed4e067b58b6eb8b0c9fad4";>21e597e
 [maven-release-plugin] prepare for next development iteration
   https://github.com/apache/maven/commit/ff8e977a158738155dc465c6a97ffaf31982d739";>ff8e977
 [maven-release-plugin] prepare release maven-3.8.3
   https://github.com/apache/maven/commit/0a6bbb8301717d386e6588a7ea32e3e2451c7060";>0a6bbb8
 [MNG-7235] Speed improvements when calculating the sorted project graph
   https://github.com/apache/maven/commit/8882a9c599013182e42f0c7c321396c23b84dbe0";>8882a9c
 [MNG-7164] Add constructor MojoExecutionException(Throwable)
   https://github.com/apache/maven/commit/ab54d17dc2ec355c1e002e8751739edd9a96fcc3";>ab54d17
 [MNG-7253] Display relocation message defined in model
   Add

[GitHub] [maven-mvnd] olamy commented on pull request #539: Do not cut sha256 in release workflow

2021-12-17 Thread GitBox


olamy commented on pull request #539:
URL: https://github.com/apache/maven-mvnd/pull/539#issuecomment-996680865


   > > > > Let me check.
   > > > 
   > > > 
   > > > I cannot :/ after the repo moved to ASF.
   > > 
   > > 
   > > what sort of karma do you need?
   > 
   > commitership ? I suppose Peter lost his write access to the code tree 
during the move given he is not a Maven committer.
   
   Ah yes makes sense. 
   I will try to fix that ;) 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[GitHub] [maven-mvnd] gnodet commented on pull request #539: Do not cut sha256 in release workflow

2021-12-17 Thread GitBox


gnodet commented on pull request #539:
URL: https://github.com/apache/maven-mvnd/pull/539#issuecomment-996679641


   > > > Let me check.
   > > 
   > > 
   > > I cannot :/ after the repo moved to ASF.
   > 
   > what sort of karma do you need?
   
   commitership ? I suppose Peter lost his write access to the code tree during 
the move given he is not a Maven committer.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



Re: Using of Travis

2021-12-17 Thread Karl Heinz Marbaise

Hi,

+1 for getting rid of travis...

Kind regards
Karl Heinz Marbaise

On 17.12.21 08:51, Slawomir Jaranowski wrote:

Hi,

As the primary CI environment we use Jenkins.
Now also using GH Actions  ...
I think that those both are enough.

Some projects contain scripts for Travis, like surefire.

Do we want to still use Travis?



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



[GitHub] [maven-mvnd] olamy commented on pull request #539: Do not cut sha256 in release workflow

2021-12-17 Thread GitBox


olamy commented on pull request #539:
URL: https://github.com/apache/maven-mvnd/pull/539#issuecomment-996674704


   > > Let me check.
   > 
   > I cannot :/ after the repo moved to ASF.
   
   what sort of karma do you need?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



Supported versions policy - Maven Plugins

2021-12-17 Thread Slawomir Jaranowski
Hi,

On example of the Surefire project I would build some policy /
documentation / information about which versions are supported and what for.
It can be generally for all maintenanced Maven Plugins by AFS.

=

First topic what version of plugin should be supported, in the Surefire I
see opened releases in jira [1] for
- Backlog (???)
- 3.0
- 3.0.1
- 3.0.0-M6
- 2.22.3
- 2.21.1

I'm not sure if we can support so many versions at the same time ...

In the Surefire case Tibor's opinion will be very appreciated.

We should should clear message for user which version and with scope is
supported, eg:
3.x - only latest version for bug fixes and new feature
2.x - only for security vulnerability

Currently Surefire has reported 269 issues without clear policy it is not
possible to support them.

=

Second topic - what JDK and Maven Api should be supported by plugins.
I see that - Since June 2020, Maven Plugin API used by plugins >= 3.1.0 +
Java 8 prerequisites [2]

But also I see that some of plugin in last time has updated api to 3.2.5

In this topic we should list supported matrix, like
Maven: 3.2.x, 3.3.x ... JDK: 1.8, 11, 17, ...
and use the same matrix on CI to be sure

=

After decision taken I think that such information should be on page:
"Maven Plugins" [3]

Probably the topic was discussed ... but I don't see the result ... so try
to start again.

[1]
https://issues.apache.org/jira/projects/SUREFIRE?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=unreleased
[2] https://maven.apache.org/developers/compatibility-plan.html
[3] https://maven.apache.org/plugins/index.html

-- 
Sławomir Jaranowski


[GitHub] [maven-mvnd] ppalaga commented on pull request #539: Do not cut sha256 in release workflow

2021-12-17 Thread GitBox


ppalaga commented on pull request #539:
URL: https://github.com/apache/maven-mvnd/pull/539#issuecomment-996647121


   > Let me check.
   
   I cannot :/ after the repo moved to ASF.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



Re: [DISCUSS] Maven 3.8.x and 3.9.x

2021-12-17 Thread Tamás Cservenák
There are some open/ongoing issues in there still, some of yours... so
maybe create a 3.8.5 version and start tossing JIRAs onto it?
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.8.x-candidate

T

On Fri, Dec 17, 2021 at 12:13 PM Guillaume Nodet  wrote:

> I've merged https://github.com/apache/maven/pull/627 in *maven-3.8.x*
> branch (and related https://github.com/apache/maven/pull/628) for master.
> Is there anything before we can cut a 3.8.5 release ?
> If not, I can derive a *maven-3.9.x* branch from the *maven-3.8.x* asap and
> start merging #622 and #630.
>
> Thoughts ?
>
> Le lun. 13 déc. 2021 à 11:39, Guillaume Nodet  a écrit
> :
>
> > In order to progress on a few issues, I'd like to discuss two points.
> >   * merge https://github.com/apache/maven/pull/628 into the 3.8.x branch
> > and release 3.8.5 asap.  This is a long-standing issue which had a couple
> > of trial fixes over the past months.
> >   * create a 3.9.x branch to merge
> > https://github.com/apache/maven/pull/630 and
> > https://github.com/apache/maven/pull/630
> >
> > The 3.9.x will be needed in order to progress on
> > maven-build-cache-extension.  Right now, the tests are done on two
> branches
> > that have to be built (for 3.x and 4.x), forbidding any kind of release
> > (which I don't propose at this time, we first need to extract it to a
> > separate repo anyway...)
> >
> > Thoughts ?
> >
> > --
> > 
> > Guillaume Nodet
> >
> >
>
> --
> 
> Guillaume Nodet
>


Re: [DISCUSS] Maven 3.8.x and 3.9.x

2021-12-17 Thread Guillaume Nodet
I've merged https://github.com/apache/maven/pull/627 in *maven-3.8.x*
branch (and related https://github.com/apache/maven/pull/628) for master.
Is there anything before we can cut a 3.8.5 release ?
If not, I can derive a *maven-3.9.x* branch from the *maven-3.8.x* asap and
start merging #622 and #630.

Thoughts ?

Le lun. 13 déc. 2021 à 11:39, Guillaume Nodet  a écrit :

> In order to progress on a few issues, I'd like to discuss two points.
>   * merge https://github.com/apache/maven/pull/628 into the 3.8.x branch
> and release 3.8.5 asap.  This is a long-standing issue which had a couple
> of trial fixes over the past months.
>   * create a 3.9.x branch to merge
> https://github.com/apache/maven/pull/630 and
> https://github.com/apache/maven/pull/630
>
> The 3.9.x will be needed in order to progress on
> maven-build-cache-extension.  Right now, the tests are done on two branches
> that have to be built (for 3.x and 4.x), forbidding any kind of release
> (which I don't propose at this time, we first need to extract it to a
> separate repo anyway...)
>
> Thoughts ?
>
> --
> 
> Guillaume Nodet
>
>

-- 

Guillaume Nodet


[GitHub] [maven-mvnd] gnodet commented on pull request #538: Fastclean extension

2021-12-17 Thread GitBox


gnodet commented on pull request #538:
URL: https://github.com/apache/maven-mvnd/pull/538#issuecomment-996632492


   > Wow! You... are... quick!! :) Thank you so much for taking the time to 
test out the idea.
   > 
   > So I gave it a shot and strangely, despite you spinning up a new thread, 
the maven clean goal didn't finish until the thread completed. I don't really 
understand why. I made some changes to the code by using a ExecutorService 
(might be good to serialize the deletion as well):
   > 
   > `private static ExecutorService executorService = 
Executors.newSingleThreadExecutor();`
   > 
   > and then
   > 
   > `executorService.submit(() -> deleteDir(delDir, retryOnError));`
   > 
   > and then it seem to finish the maven-goal right away (and process the 
delete in the background)
   > 
   > To summarize the results a bit for my specific case (13 projects in build):
   > 
   > **Time spent when using the fastclean plugin:** clean goal: 174 ms total 
build time: 01:51 min (Wall Clock)
   > 
   > **Time spent when using the stock maven clean plugin:** clean goal: 62263 
ms total build time: 02:15 min (Wall Clock)
   > 
   > So approx. 20% reduction in clean&build time! I think that's definitely 
worth something :) Could possibly be sped up further by delaying the deletes 
(or lowering priority of it)
   > 
   > (Using the fastclean plugin in mvn with -T1 it took 536 ms)
   > 
   > So I'm really hopeful this could go somewhere. However, it feels like this 
has to be run within the maven daemon, as opposed to just maven, in order to be 
able to run this properly. Otherwise we'll take the hit during maven shutdown.
   > 
   > Once again, thanks a lot! Atli
   > 
   > ps. btw, I also skipped the tmpDir and renamed directly (instead of moving 
the delDir to the target folder). I did that because if you start a new build 
while the delete is still ongoing, you get into problems:
   > 
   > ```
   > String name = directory.getFileName().toString() + "-" + 
random;
   > Path delDir = directory.resolveSibling(name);
   > try {
   > Files.move(directory, delDir);
   > Files.createDirectory(directory);
   > ```
   > 
   > Some additional numbers from my tests:
   > 
   > [INFO] Plugins in lifecycle Phases: [INFO] [INFO] clean: [INFO] 206 ms: 
org.apache.maven.plugins:maven-clean-plugin:2.5:clean:default-clean [INFO] 2 
ms: org.apache.maven.plugins:maven-clean-plugin:2.5:clean:default-clean [INFO] 
470 ms: org.apache.maven.plugins:maven-clean-plugin:3.1.0:clean:default-clean 
[INFO] 11531 ms: 
org.apache.maven.plugins:maven-clean-plugin:2.5:clean:default-clean [INFO] 9513 
ms: org.apache.maven.plugins:maven-clean-plugin:2.5:clean:default-clean [INFO] 
2 ms: org.apache.maven.plugins:maven-clean-plugin:2.5:clean:default-clean 
[INFO] 12009 ms: 
org.apache.maven.plugins:maven-clean-plugin:2.5:clean:default-clean [INFO] 1926 
ms: org.apache.maven.plugins:maven-clean-plugin:2.5:clean:default-clean [INFO] 
2 ms: org.apache.maven.plugins:maven-clean-plugin:2.5:clean:default-clean 
[INFO] 2377 ms: 
org.apache.maven.plugins:maven-clean-plugin:2.5:clean:default-clean [INFO] 4097 
ms: org.apache.maven.plugins:maven-clean-plugin:2.5:clean:default-clean [INFO] 
2432 ms: org
 .apache.maven.plugins:maven-clean-plugin:2.5:clean:default-clean [INFO] 17696 
ms: org.apache.maven.plugins:maven-clean-plugin:2.5:clean:default-clean
   > 
   > **vs fastclean:**
   > 
   > [INFO] Plugins in lifecycle Phases: [INFO] [INFO] clean: [INFO] 23 ms: 
org.mvndaemon.mvnd:mvnd-fastclean-maven-plugin:0.7.2-SNAPSHOT:clean:default-clean
 [INFO] 19 ms: 
org.mvndaemon.mvnd:mvnd-fastclean-maven-plugin:0.7.2-SNAPSHOT:clean:default-clean
 [INFO] 2 ms: 
org.mvndaemon.mvnd:mvnd-fastclean-maven-plugin:0.7.2-SNAPSHOT:clean:default-clean
 [INFO] 12 ms: 
org.mvndaemon.mvnd:mvnd-fastclean-maven-plugin:0.7.2-SNAPSHOT:clean:default-clean
 [INFO] 20 ms: 
org.mvndaemon.mvnd:mvnd-fastclean-maven-plugin:0.7.2-SNAPSHOT:clean:default-clean
 [INFO] 10 ms: 
org.mvndaemon.mvnd:mvnd-fastclean-maven-plugin:0.7.2-SNAPSHOT:clean:default-clean
 [INFO] 15 ms: 
org.mvndaemon.mvnd:mvnd-fastclean-maven-plugin:0.7.2-SNAPSHOT:clean:default-clean
 [INFO] 13 ms: 
org.mvndaemon.mvnd:mvnd-fastclean-maven-plugin:0.7.2-SNAPSHOT:clean:default-clean
 [INFO] 16 ms: 
org.mvndaemon.mvnd:mvnd-fastclean-maven-plugin:0.7.2-SNAPSHOT:clean:default-clean
 [INFO] 9 ms: org.mvndaemon.mvnd:mvnd-fastclean-maven-plugin:0.7.2-SNAPSHO
 T:clean:default-clean [INFO] 2 ms: 
org.mvndaemon.mvnd:mvnd-fastclean-maven-plugin:0.7.2-SNAPSHOT:clean:default-clean
 [INFO] 16 ms: 
org.mvndaemon.mvnd:mvnd-fastclean-maven-plugin:0.7.2-SNAPSHOT:clean:default-clean
 [INFO] 17 ms: 
org.mvndaemon.mvnd:mvnd-fastclean-maven-plugin:0.7.2-SNAPSHOT:clean:default-clean
   
   It would be worth trying with the modified 
[maven-clean-plugin](https://github.com/apache/maven-clean-plugin/pull/6) .
   I've added a join which cause maven to wait until the deleti

[GitHub] [maven-mvnd] gnodet closed pull request #538: Fastclean extension

2021-12-17 Thread GitBox


gnodet closed pull request #538:
URL: https://github.com/apache/maven-mvnd/pull/538


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



Re: [DISCUSS] Move maven caching to an external repository

2021-12-17 Thread Romain Manni-Bucau
+1

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 17 déc. 2021 à 11:47, Guillaume Nodet  a écrit :

> I've tried various things without any good results.
> Given there's not much history to preserve here, I'd go ahead and just
> create a new repo with the current contents of the branch.
> Any objections?
>
> Le dim. 12 déc. 2021 à 15:43, Jeff Jensen <
> jeffjen...@upstairstechnology.com>
> a écrit :
>
> > I've split git repos before and using filter-branch is the key to keep
> the
> > desired and purge the rest.
> >
> > From my notes, these two posts helped me:
> > *
> >
> >
> https://docs.github.com/en/get-started/using-git/splitting-a-subfolder-out-into-a-new-repository
> > *
> >
> >
> https://support.atlassian.com/bitbucket-cloud/docs/split-a-repository-in-two/
> >
> > These are my shortcut notes for doing so, hope they are clear enough for
> > you and help. In a new repo, locally convert a current source
> subdirectory
> > to the root directory and purge everything else; then push to remote and
> > locally cleanup:
> >
> >1.
> >
> >Make directory for new repo from current repo:
> >
> > git clone current-repo to-new-directory
> >
> >1.
> >
> >Disconnect from current remote immediately to prevent catastrophe and
> >verify none set
> >
> > git remote rm origin
> >
> > git remote -v
> >
> >1.
> >
> >Keep desired dir and move it to top level, remove the rest
> >1.
> >
> >   FOLDER-NAME: which one to keep and move to top level
> >   2.
> >
> >   BRANCH-NAME: which branch to do this on (must exist, e.g. master)
> >
> > git filter-branch --prune-empty --subdirectory-filter FOLDER-NAME
> > BRANCH-NAME
> >
> >1.
> >
> >Setup remote repo and verify set
> >
> > git remote add origin https://githost.com/NEW-REPOSITORY-NAME.git
> > 
> >
> > git remote -v
> >
> >1.
> >
> >Push to new repo
> >
> > git push -u origin BRANCH-NAME
> >
> >1.
> >
> >Further cleanup: delete all tags (locally only (Powershell))
> >
> > git tag | foreach-object -process { git tag -d $_ }
> >
> >1.
> >
> >Further cleanup: remove local unreachable/recyclable commits (remnants
> >of prior)
> >
> > git reflog expire --expire-unreachable=now --all
> >
> > git gc --prune=now
> >
> >
> > On Sun, Dec 12, 2021 at 7:32 AM Hervé BOUTEMY 
> > wrote:
> >
> > > nice work done
> > > I published the result to https://maven.apache.org/ref/caching-LATEST/
> > >
> > > now, on moving source to a separate Git repository, I did a basic test
> > > pushing
> > > to a new repository:
> > > https://github.com/hboutemy/maven-build-cache-extension
> > >
> > > this leads to getting quite a lot of Maven history
> > >
> > > I'm not a Git wizard: is there a way to cut down the history to keep
> only
> > > the
> > > interesting part when the build cache code donation was done?
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le jeudi 9 décembre 2021, 10:39:10 CET Guillaume Nodet a écrit :
> > > > Le jeu. 9 déc. 2021 à 09:52, Hervé BOUTEMY  a
> > > écrit :
> > > > > we have most plugins that are simple with only 1 mono-module build
> > > > > This makes documentation easy in /plugins/maven-*-plugin/:
> > > > > see https://maven.apache.org/components/plugins/ for full list
> > > > >
> > > > > we have a few components that have a plugin as part of a larger
> > > > > multi-module
> > > > > build, like surefire, jxr, archetype, scm, plugin-tools, enforcer,
> > > > > release, and
> > > > > soon wrapper
> > > > >
> > > > > And from experience, it makes documentation harder because there is
> > > always
> > > > > the
> > > > > question of what to write in the plugin pages and what to write in
> > > other
> > > > > modules. Not talking of navigation from /plugins/maven-xxx-plugin
> to
> > > /xxx/
> > > > > maven-xxx-plugin (we have a trick for redirecting...)
> > > > >
> > > > > In caching case, I see that there is only one submodule, that is
> done
> > > for
> > > > > ITs
> > > > > with Surefire: is it necessary? isn't maven-invoker-plugin usable,
> > like
> > > > > for
> > > > > plugins?
> > > >
> > > > Yes, that's actually a good point.  I thought about that when I read
> > > Tamás
> > > > answer.  I'll double check if the integration tests can be merged
> into
> > a
> > > > single module.
> > > >
> > > > > Regards,
> > > > >
> > > > > Hervé
> > > > >
> > > > > Le jeudi 9 décembre 2021, 09:01:13 CET Guillaume Nodet a écrit :
> > > > > > I think the repository name should not contain 'extension',
> similar
> > > to
> > > > > > surefire which provides a plugin, but it a bit more complex
> > > > > > The fact that it is provided as an extension is a technicality i

[GitHub] [maven-mvnd] gnodet commented on issue #540: Can I specify the MVN version?

2021-12-17 Thread GitBox


gnodet commented on issue #540:
URL: https://github.com/apache/maven-mvnd/issues/540#issuecomment-996623423


   No, that's not doable unfortunately as the code is too dependant on maven's 
internals.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[GitHub] [maven-mvnd] gnodet closed issue #540: Can I specify the MVN version?

2021-12-17 Thread GitBox


gnodet closed issue #540:
URL: https://github.com/apache/maven-mvnd/issues/540


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



Re: [DISCUSS] Move maven caching to an external repository

2021-12-17 Thread Guillaume Nodet
I've tried various things without any good results.
Given there's not much history to preserve here, I'd go ahead and just
create a new repo with the current contents of the branch.
Any objections?

Le dim. 12 déc. 2021 à 15:43, Jeff Jensen 
a écrit :

> I've split git repos before and using filter-branch is the key to keep the
> desired and purge the rest.
>
> From my notes, these two posts helped me:
> *
>
> https://docs.github.com/en/get-started/using-git/splitting-a-subfolder-out-into-a-new-repository
> *
>
> https://support.atlassian.com/bitbucket-cloud/docs/split-a-repository-in-two/
>
> These are my shortcut notes for doing so, hope they are clear enough for
> you and help. In a new repo, locally convert a current source subdirectory
> to the root directory and purge everything else; then push to remote and
> locally cleanup:
>
>1.
>
>Make directory for new repo from current repo:
>
> git clone current-repo to-new-directory
>
>1.
>
>Disconnect from current remote immediately to prevent catastrophe and
>verify none set
>
> git remote rm origin
>
> git remote -v
>
>1.
>
>Keep desired dir and move it to top level, remove the rest
>1.
>
>   FOLDER-NAME: which one to keep and move to top level
>   2.
>
>   BRANCH-NAME: which branch to do this on (must exist, e.g. master)
>
> git filter-branch --prune-empty --subdirectory-filter FOLDER-NAME
> BRANCH-NAME
>
>1.
>
>Setup remote repo and verify set
>
> git remote add origin https://githost.com/NEW-REPOSITORY-NAME.git
> 
>
> git remote -v
>
>1.
>
>Push to new repo
>
> git push -u origin BRANCH-NAME
>
>1.
>
>Further cleanup: delete all tags (locally only (Powershell))
>
> git tag | foreach-object -process { git tag -d $_ }
>
>1.
>
>Further cleanup: remove local unreachable/recyclable commits (remnants
>of prior)
>
> git reflog expire --expire-unreachable=now --all
>
> git gc --prune=now
>
>
> On Sun, Dec 12, 2021 at 7:32 AM Hervé BOUTEMY 
> wrote:
>
> > nice work done
> > I published the result to https://maven.apache.org/ref/caching-LATEST/
> >
> > now, on moving source to a separate Git repository, I did a basic test
> > pushing
> > to a new repository:
> > https://github.com/hboutemy/maven-build-cache-extension
> >
> > this leads to getting quite a lot of Maven history
> >
> > I'm not a Git wizard: is there a way to cut down the history to keep only
> > the
> > interesting part when the build cache code donation was done?
> >
> > Regards,
> >
> > Hervé
> >
> > Le jeudi 9 décembre 2021, 10:39:10 CET Guillaume Nodet a écrit :
> > > Le jeu. 9 déc. 2021 à 09:52, Hervé BOUTEMY  a
> > écrit :
> > > > we have most plugins that are simple with only 1 mono-module build
> > > > This makes documentation easy in /plugins/maven-*-plugin/:
> > > > see https://maven.apache.org/components/plugins/ for full list
> > > >
> > > > we have a few components that have a plugin as part of a larger
> > > > multi-module
> > > > build, like surefire, jxr, archetype, scm, plugin-tools, enforcer,
> > > > release, and
> > > > soon wrapper
> > > >
> > > > And from experience, it makes documentation harder because there is
> > always
> > > > the
> > > > question of what to write in the plugin pages and what to write in
> > other
> > > > modules. Not talking of navigation from /plugins/maven-xxx-plugin to
> > /xxx/
> > > > maven-xxx-plugin (we have a trick for redirecting...)
> > > >
> > > > In caching case, I see that there is only one submodule, that is done
> > for
> > > > ITs
> > > > with Surefire: is it necessary? isn't maven-invoker-plugin usable,
> like
> > > > for
> > > > plugins?
> > >
> > > Yes, that's actually a good point.  I thought about that when I read
> > Tamás
> > > answer.  I'll double check if the integration tests can be merged into
> a
> > > single module.
> > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > Le jeudi 9 décembre 2021, 09:01:13 CET Guillaume Nodet a écrit :
> > > > > I think the repository name should not contain 'extension', similar
> > to
> > > > > surefire which provides a plugin, but it a bit more complex
> > > > > The fact that it is provided as an extension is a technicality in
> > this
> > > >
> > > > case
> > > >
> > > > > imho.
> > > > > No big deal though...
> > > > >
> > > > > Le mar. 7 déc. 2021 à 09:53, Tamás Cservenák 
> a
> > > >
> > > > écrit :
> > > > > > Howdy,
> > > > > >
> > > > > > I'd rather group ASF extensions (are there any existing ones
> aside
> > of
> > > > > > caching?),
> > > > > > to be clear... so GH repo could be something like
> > > > > > apache/maven-caching-extension
> > > > > > apache/maven-foobar-extension
> > > > > > etc?
> > > > > >
> > > > > > T
> > > > > >
> > > > > > On Tue, Dec 7, 2021 at 9:48 AM Guillaume Nodet <
> gno...@apache.org>
> > > >
> > > > wrote:
> > > > > > > Following the recent work done to integrate the maven caching /
> > > > > >
> > > > > > incremental
> > > >

Re: Using of Travis

2021-12-17 Thread Benjamin Marwell
+1 to drop

Am Fr., 17. Dez. 2021 um 10:24 Uhr schrieb Romain Manni-Bucau
:
>
> +1 to drop
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | Book
> 
>
>
> Le ven. 17 déc. 2021 à 10:19, Olivier Lamy  a écrit :
>
> > +1 to get rid of travis
> >
> > On Fri, 17 Dec 2021 at 08:52, Slawomir Jaranowski 
> > wrote:
> >
> > > Hi,
> > >
> > > As the primary CI environment we use Jenkins.
> > > Now also using GH Actions  ...
> > > I think that those both are enough.
> > >
> > > Some projects contain scripts for Travis, like surefire.
> > >
> > > Do we want to still use Travis?
> > >
> > > --
> > > Sławomir Jaranowski
> > >
> >

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



[GitHub] [maven-mvnd] feng-sword commented on issue #540: Can I specify the MVN version?

2021-12-17 Thread GitBox


feng-sword commented on issue #540:
URL: https://github.com/apache/maven-mvnd/issues/540#issuecomment-996607366


   I find this project  a moment ago, it‘s interesting,Can I specify the MVN 
version?😃


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[GitHub] [maven-mvnd] feng-sword opened a new issue #540: Can I specify the MVN version?

2021-12-17 Thread GitBox


feng-sword opened a new issue #540:
URL: https://github.com/apache/maven-mvnd/issues/540


   Can I specify the MVN version?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



Re: Using of Travis

2021-12-17 Thread Romain Manni-Bucau
+1 to drop

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book



Le ven. 17 déc. 2021 à 10:19, Olivier Lamy  a écrit :

> +1 to get rid of travis
>
> On Fri, 17 Dec 2021 at 08:52, Slawomir Jaranowski 
> wrote:
>
> > Hi,
> >
> > As the primary CI environment we use Jenkins.
> > Now also using GH Actions  ...
> > I think that those both are enough.
> >
> > Some projects contain scripts for Travis, like surefire.
> >
> > Do we want to still use Travis?
> >
> > --
> > Sławomir Jaranowski
> >
>


Re: Using of Travis

2021-12-17 Thread Olivier Lamy
+1 to get rid of travis

On Fri, 17 Dec 2021 at 08:52, Slawomir Jaranowski 
wrote:

> Hi,
>
> As the primary CI environment we use Jenkins.
> Now also using GH Actions  ...
> I think that those both are enough.
>
> Some projects contain scripts for Travis, like surefire.
>
> Do we want to still use Travis?
>
> --
> Sławomir Jaranowski
>


[GitHub] [maven-mvnd] huxudong commented on issue #537: Does not support the spring-boot-maven-plugin

2021-12-17 Thread GitBox


huxudong commented on issue #537:
URL: https://github.com/apache/maven-mvnd/issues/537#issuecomment-996557168


   > Could you please point us to a minimal reproducer project?
   
   I created a new springboot project and found no problem. Thank you


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



[GitHub] [maven-mvnd] huxudong closed issue #537: Does not support the spring-boot-maven-plugin

2021-12-17 Thread GitBox


huxudong closed issue #537:
URL: https://github.com/apache/maven-mvnd/issues/537


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



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



Re: Using of Travis

2021-12-17 Thread Tamás Cservenák
Howdy,

I think (of course) no. 2 is enough, also Travis went to paid service?

So +1 to root out Travis from all ASF Maven reposes.

HTH
T

On Fri, Dec 17, 2021 at 8:52 AM Slawomir Jaranowski 
wrote:

> Hi,
>
> As the primary CI environment we use Jenkins.
> Now also using GH Actions  ...
> I think that those both are enough.
>
> Some projects contain scripts for Travis, like surefire.
>
> Do we want to still use Travis?
>
> --
> Sławomir Jaranowski
>