Re: Another take on [MRESOLVER-7] Download dependency POMs in parallel

[Ivan Babiankou]

Hi Tibor,

It took a while (and a few attempts :)), but I've prepared a branch
 with a few
independent minimalistic commits. It's still a work in progress(tests and
comments are missing), but I would love to run some thoughts by you before
I spend more time on it.

The code works like a charm, I packaged a local version of Maven with these
changes and tested it on a few projects of different sizes - nothing hangs,
nothing fails.
All tests pass, when an executor with a single thread is used, but with
multiple threads there are failures because due to concurrency (and not
only) the ordering in the dependency tree is not guaranteed. All the
dependencies are there, but the order of the children might change.

I wonder what is the best way to fix those tests:
- Change assertions so that they take into account the fact that order
might differ? - not sure how easy it will be.
- Change DependencyNode to use SortedSet to store children? - IIUC it would
be a breaking change for the public API, so too big of a change, though it
would be nice to guarantee some order for the children.
- Simply sort children before returning? - Might impact performance.
- Something else?

What do you think?
Cheers,
Ivan

On Mon, Oct 18, 2021 at 11:06 AM Ivan Babiankou 
wrote:

> Hi Tibor,
>
> Thanks for getting back to me!
>
> I looked at the reverted changes and it seems that the majority of the
> classes used to pass around data are not really thread safe. Given the size
> of the change I'm a bit reluctant to try to fix that branch because I'm not
> sure all of the changes are needed. Instead I want to give it a try to
> refactor the `DefaultDependencyCollector.processDependency` method to be
> more functional so that it can be easily used in an executor without
> modifying passed in objects. WDYT about this approach?
>
> I'll experiment a bit and once I have something worth sharing and
> discussing I'll send an email ;)
>
> Cheers,
> Ivan
>
> On Sat, Oct 16, 2021 at 10:45 PM Tibor Digana 
> wrote:
>
>> Hi Ivan,
>>
>> Basically the process is simple.
>> You should fork the master to your branch named, e.g. MRESOLVER-7.
>>
>> I think the process is not a big issue right now.
>> The big issue here is the analysis of the code and a proposed fix.
>>
>> It would be fine to split the changes into several independent commits or
>> (branches if possible and necessary) upon the my hints in Jira:
>> 1. root cause of hanging Maven and deadlock of thread-resources
>> starvation,
>> 2. problems with thread-unsafe classes,
>> 3. overrided objects across threads,
>> 4. one unclear part in the algorithm
>>
>> The ideal would be to isolate these four however it is a theory and still
>> keep the build success.
>>
>> You should step into 1 at first, start the code analysis, understand the
>> problem with resource starvation and propose a fix or alternatives in a
>> comment. Then we would make a decision together.
>> Then the code will be changed and the community should check it out by
>> integrating into Maven and ITs. We would be happy if we could not have any
>> regression in each step.
>>
>> If we could isolate the work in 4 or more fixes and Jira tickets, we
>> would have an easier life to bisect the commits and verify them separately
>> while we are in troubles in the future.
>>
>> T
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Oct 16, 2021 at 5:21 PM Ivan Babiankou 
>> wrote:
>>
>>> I would love to prepare decent PR
>>> 
>>> for the MRESOLVER-7 issue, so that it makes it to one of the upcoming
>>> releases. But I could definitely use some guidance, given the history
>>> of the ticket
>>> 
>>> and the fact that it’s my first contribution to Maven and OSS in general.
>>> Is there anyone willing to point me in the right direction (in email or a
>>> quick 15-30min call)?  I would really appreciate it.
>>>
>>> For now I’m reading the general things about contributing to Maven and
>>> looking at the old branch that was merged and then reverted.
>>>
>>>
>>> I see the master branch of Maven Resolver corresponds to v1.7.x, which
>>> requires Maven 4, however I would love to target the current Maven 3.x.
>>> Where should I start my PR off master or  maven-resolver-1.6.x?
>>>
>>> Thanks,
>>> Ivan
>>>
>>>
>>>

Re: reviewing Maven Wrapper before releasing

[Hervé BOUTEMY]

ITs updated to run mvnw
MWRAPPER-22 proven to require to reapply the fix: done
(surprising that nobody found that bug in Wrapper 0.5.6 and previous for more 
than 2 years...)

release ready to be done: I'll launch it tonight

Regards,

Hervé

Le dimanche 12 décembre 2021, 19:05:33 CET Robert Scholte a écrit :
> Jason,
> 
> my point is that i DID write integration tests as part of the donation
> to better understand the code, improve the codebase and its reliability.
> While writing them I did find several issues, some caused because the
> scripts didn't get in sync with the Maven core scripts.
> So it is possible to automate these tests, they are there, somebody just
> has to ported them to the new project.
> Also with the change of strategy how the wrapper should work we need
> integration-tests to confirm it all works.
> We shouldn't gamble, as almost every release people will only test is
> _after_ its vote, which is just too late.
> 
> Robert
> 
> [1]
> https://github.com/apache/maven-integration-testing/tree/master/core-it-suit
> e/src/test/resources/mng-5937%20wrapper
> 
> -- Origineel bericht --
> Van: "Jason van Zyl" 
> Aan: "Maven Developers List" 
> Verzonden: 12-12-2021 13:54:16
> Onderwerp: Re: reviewing Maven Wrapper before releasing
> 
> >Clearly no one here disagrees with the goal of having robust testing for
> >software that is made available to users.
> >
> >As to the timing of that testing being complete for the wrapper, to the
> >satisfaction of those objecting to a release, I will argue.
> >
> >Do we wait four years for adequate testing? I’m not being facetious because
> >we’re rolling up on three years since the initial donation of the wrapper
> >was made. No one can force anyone else to do work here, sometimes things
> >take a while, and there still may be a great deal of time that passes
> >before testing is present that is considered adequate.
> >
> >All else being equal, I think the value of a release to remove the state of
> >limbo the wrapper has been in for years outweighs the current lack of
> >testing. The wrapper has been in use for 8 years, and while more testing
> >is preferred we have reasonable assurances it works as expected. I don’t
> >think we’ll be back to zero if we find issues, they can be fixed and will
> >be accompanied by tests as most things here are. Right now from a user’s
> >perspective the wrapper appears dead at Takari and Apache which is a
> >shame.
> >
> >Would everyone be amenable to an alpha release? And transition to a
> >non-alpha release when everyone agrees the testing is sufficient?
> >
> >jvz
> >
> >>  On Dec 12, 2021, at 5:14 AM, Maarten Mulders 
> >>  wrote:
> >>  
> >>  Chiming in a little late, but here are my 2 cents nevertheless. I would
> >>  not feel confident releasing something that we cannot test in an
> >>  automated way. Not having an integration test suite means we don't know
> >>  for sure if it works. And if we know it works and we change something,
> >>  we're back to zero.
> >>  
> >>  To me, this has nothing to do with a (misplaced) drive for perfection.
> >>  It is all about making sure we ship something to users that we know to
> >>  work, and that we can easily prove to still work after we change it.
> >>  
> >>  Thanks,
> >>  
> >>  Maarten
> >>  
> >>  On 11/12/2021 13:43, Robert Scholte wrote:
> >>>  It was marked for Maven 4, and part of the improvements was test
> >>>  automation, which was now possible because it became part of Maven
> >>>  Core. Even thought the code still exists in Maven Core, is has now
> >>>  become useless. There hasn't been a real need for new releases of
> >>>  Maven Wrapper Plugin until a range of Maven 3.8 started. Maven Wrapper
> >>>  would have been another feature to attract developers to Maven 4. And
> >>>  finally, I see that the donated code has been used as base, ignoring
> >>>  all the effort done to improve that codebase done afterwards. Hence my
> >>>  response that reliability is gone that was added after donation.
> >>>  Robert
> >>>  -- Origineel bericht --
> >>>  Van: "Manfred Moser" 
> >>>  Aan: dev@maven.apache.org
> >>>  Verzonden: 10-12-2021 20:58:33
> >>>  Onderwerp: Re: reviewing Maven Wrapper before releasing
> >>>  
>   I totally agree with finally just shipping this. We got this all
>   donated about two years ago now and there is still nothing shipping.
>   
>   I used to just manually do the testing and thousands of projects are
>   happy. I assume the new project is at least manually testing and
>   works as before or better. Let's not wait nay more and let perfection
>   get into our way. It surely is good enough for a release.
>   
>   The beauty is that if you find an issue.. you just ship again ... no
>   reason to wait.
>   
>   manfred
>   
>   Hervé BOUTEMY wrote on 2021-12-10 04:13 (GMT -08:00):
> >   the current 3.1.0-SNAPSHOT works like 0.5.6 as donated: I confess I
> >   did not

Re: reviewing Maven Wrapper before releasing

[Jason van Zyl]

Robert,

I’m actually not sure what you are implying. Are you saying that you’re going 
to block the release until someone ports your tests over? Or you’re going to 
block the release of the separate wrapper?

I don’t think anyone disagrees that the tests can be fully automated.I don’t 
think it’s absolutely necessary for the first release from Apache. We do the 
best we can, when we can.

As for users only trying releases, does this surprise anyone? I don’t think so. 
It’s something to embrace. If we find a bunch of things wrong with the release 
we’ll fix them, add tests, and release again. The wrapper is now separate so 
this is not hard. Overall the Maven project does an excellent job with testing 
but in this case it’s become a theoretical exercise devoid of user feedback 
which is essential to improving any piece of software. Add your tests back when 
you can, others might get their first or add different tests. We’ll get there.

Let’s just get it into the hands of users.

jvz

> On Dec 12, 2021, at 1:05 PM, Robert Scholte  wrote:
> 
> Jason,
> 
> my point is that i DID write integration tests as part of the donation to 
> better understand the code, improve the codebase and its reliability.
> While writing them I did find several issues, some caused because the scripts 
> didn't get in sync with the Maven core scripts.
> So it is possible to automate these tests, they are there, somebody just has 
> to ported them to the new project.
> Also with the change of strategy how the wrapper should work we need 
> integration-tests to confirm it all works.
> We shouldn't gamble, as almost every release people will only test is _after_ 
> its vote, which is just too late.
> 
> Robert
> 
> [1] 
> https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-5937%20wrapper
> 
> -- Origineel bericht --
> Van: "Jason van Zyl" 
> Aan: "Maven Developers List" 
> Verzonden: 12-12-2021 13:54:16
> Onderwerp: Re: reviewing Maven Wrapper before releasing
> 
>> Clearly no one here disagrees with the goal of having robust testing for 
>> software that is made available to users.
>> 
>> As to the timing of that testing being complete for the wrapper, to the 
>> satisfaction of those objecting to a release, I will argue.
>> 
>> Do we wait four years for adequate testing? I’m not being facetious because 
>> we’re rolling up on three years since the initial donation of the wrapper 
>> was made. No one can force anyone else to do work here, sometimes things 
>> take a while, and there still may be a great deal of time that passes before 
>> testing is present that is considered adequate.
>> 
>> All else being equal, I think the value of a release to remove the state of 
>> limbo the wrapper has been in for years outweighs the current lack of 
>> testing. The wrapper has been in use for 8 years, and while more testing is 
>> preferred we have reasonable assurances it works as expected. I don’t think 
>> we’ll be back to zero if we find issues, they can be fixed and will be 
>> accompanied by tests as most things here are. Right now from a user’s 
>> perspective the wrapper appears dead at Takari and Apache which is a shame.
>> 
>> Would everyone be amenable to an alpha release? And transition to a 
>> non-alpha release when everyone agrees the testing is sufficient?
>> 
>> jvz
>> 
>>> On Dec 12, 2021, at 5:14 AM, Maarten Mulders  wrote:
>>> 
>>> Chiming in a little late, but here are my 2 cents nevertheless. I would not 
>>> feel confident releasing something that we cannot test in an automated way. 
>>> Not having an integration test suite means we don't know for sure if it 
>>> works. And if we know it works and we change something, we're back to zero.
>>> 
>>> To me, this has nothing to do with a (misplaced) drive for perfection. It 
>>> is all about making sure we ship something to users that we know to work, 
>>> and that we can easily prove to still work after we change it.
>>> 
>>> Thanks,
>>> 
>>> Maarten
>>> 
>>> On 11/12/2021 13:43, Robert Scholte wrote:
 It was marked for Maven 4, and part of the improvements was test 
 automation, which was now possible because it became part of Maven Core.
 Even thought the code still exists in Maven Core, is has now become 
 useless.
 There hasn't been a real need for new releases of Maven Wrapper Plugin 
 until a range of Maven 3.8 started.
 Maven Wrapper would have been another feature to attract developers to 
 Maven 4.
 And finally, I see that the donated code has been used as base, ignoring 
 all the effort done to improve that codebase done afterwards.
 Hence my response that reliability is gone that was added after donation.
 Robert
 -- Origineel bericht --
 Van: "Manfred Moser" 
 Aan: dev@maven.apache.org
 Verzonden: 10-12-2021 20:58:33
 Onderwerp: Re: reviewing Maven Wrapper before releasing
> I totally agree with finally just shipping this. We 

Re: reviewing Maven Wrapper before releasing

[Tamás Cservenák]

>
> Yes, that is said, we have seen this with Maven 3.8.x recently, but we
> can't change people. Let's get over with and just push a release. Let it
> soak in and continue with bugfixes.
>
>
+1

Re: reviewing Maven Wrapper before releasing

[Michael Osipov]

Am 2021-12-12 um 19:05 schrieb Robert Scholte:

Jason,

my point is that i DID write integration tests as part of the donation 
to better understand the code, improve the codebase and its reliability.
While writing them I did find several issues, some caused because the 
scripts didn't get in sync with the Maven core scripts.
So it is possible to automate these tests, they are there, somebody just 
has to ported them to the new project.
Also with the change of strategy how the wrapper should work we need 
integration-tests to confirm it all works.
We shouldn't gamble, as almost every release people will only test is 
_after_ its vote, which is just too late.



Yes, that is said, we have seen this with Maven 3.8.x recently, but we 
can't change people. Let's get over with and just push a release. Let it 
soak in and continue with bugfixes.


M


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

Re: [VOTE] Release Apache Maven Doxia Sitetools version 1.11.1

[Sylwester Lachiewicz]

+1

niedz., 12 gru 2021, 19:23 użytkownik Tamás Cservenák 
napisał:

> +1
>
> On Sun, Dec 12, 2021, 18:42 Michael Osipov  wrote:
>
> > Hi,
> >
> > We solved 3 issues:
> >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317320=12351046
> >
> > There are still a couple of issues left in JIRA:
> >
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317320%20AND%20status%20%3D%20Open
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1678
> >
> >
> https://repository.apache.org/content/repositories/maven-1678/org/apache/maven/doxia/doxia-sitetools/1.11.1/doxia-sitetools-1.11.1-source-release.zip
> >
> > Source release checksum(s):
> > doxia-sitetools-1.11.1-source-release.zip
> > sha512:
> >
> >
> e52c646657f7fa14f9ab1051c804d6097e38b4bddf41c2fa123bacb177c1a5a4709a17033c5648988620edd55d2497a2c2a66b4376bfc4fcb2161388951961a2
> >
> > Staging site:
> >
> >
> https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>

Re: [VOTE] Release Apache Maven Doxia Sitetools version 1.11.1

[Tamás Cservenák]

+1

On Sun, Dec 12, 2021, 18:42 Michael Osipov  wrote:

> Hi,
>
> We solved 3 issues:
>
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317320=12351046
>
> There are still a couple of issues left in JIRA:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317320%20AND%20status%20%3D%20Open
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1678
>
> https://repository.apache.org/content/repositories/maven-1678/org/apache/maven/doxia/doxia-sitetools/1.11.1/doxia-sitetools-1.11.1-source-release.zip
>
> Source release checksum(s):
> doxia-sitetools-1.11.1-source-release.zip
> sha512:
>
> e52c646657f7fa14f9ab1051c804d6097e38b4bddf41c2fa123bacb177c1a5a4709a17033c5648988620edd55d2497a2c2a66b4376bfc4fcb2161388951961a2
>
> Staging site:
>
> https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-LATEST/
>
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

Re: [VOTE] Release Apache Maven Doxia Sitetools version 1.11.1

[Michael Osipov]

Am 2021-12-12 um 18:41 schrieb Michael Osipov:

Hi,

We solved 3 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317320=12351046 



There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317320%20AND%20status%20%3D%20Open 



Staging repo:
https://repository.apache.org/content/repositories/maven-1678
https://repository.apache.org/content/repositories/maven-1678/org/apache/maven/doxia/doxia-sitetools/1.11.1/doxia-sitetools-1.11.1-source-release.zip 



Source release checksum(s):
doxia-sitetools-1.11.1-source-release.zip
sha512: 
e52c646657f7fa14f9ab1051c804d6097e38b4bddf41c2fa123bacb177c1a5a4709a17033c5648988620edd55d2497a2c2a66b4376bfc4fcb2161388951961a2 



Staging site:
https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-LATEST/ 



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

Vote open for 72 hours.


+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 Doxia Sitetools version 1.11.1

[Hervé BOUTEMY]

thank you for respinning

this time, no problem found :)

+1

Reproducible Build checked: reference build was done with JDK 8 on Windows

Regards,

Hervé

Le dimanche 12 décembre 2021, 18:41:57 CET Michael Osipov a écrit :
> Hi,
> 
> We solved 3 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317320
> rsion=12351046
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317320%20AND%20
> status%20%3D%20Open
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1678
> https://repository.apache.org/content/repositories/maven-1678/org/apache/mav
> en/doxia/doxia-sitetools/1.11.1/doxia-sitetools-1.11.1-source-release.zip
> 
> Source release checksum(s):
> doxia-sitetools-1.11.1-source-release.zip
> sha512:
> e52c646657f7fa14f9ab1051c804d6097e38b4bddf41c2fa123bacb177c1a5a4709a17033c56
> 48988620edd55d2497a2c2a66b4376bfc4fcb2161388951961a2
> 
> Staging site:
> https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-LATE
> ST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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

Re: reviewing Maven Wrapper before releasing

[Robert Scholte]

Jason,

my point is that i DID write integration tests as part of the donation 
to better understand the code, improve the codebase and its reliability.
While writing them I did find several issues, some caused because the 
scripts didn't get in sync with the Maven core scripts.
So it is possible to automate these tests, they are there, somebody just 
has to ported them to the new project.
Also with the change of strategy how the wrapper should work we need 
integration-tests to confirm it all works.
We shouldn't gamble, as almost every release people will only test is 
_after_ its vote, which is just too late.


Robert

[1] 
https://github.com/apache/maven-integration-testing/tree/master/core-it-suite/src/test/resources/mng-5937%20wrapper


-- Origineel bericht --
Van: "Jason van Zyl" 
Aan: "Maven Developers List" 
Verzonden: 12-12-2021 13:54:16
Onderwerp: Re: reviewing Maven Wrapper before releasing


Clearly no one here disagrees with the goal of having robust testing for 
software that is made available to users.

As to the timing of that testing being complete for the wrapper, to the 
satisfaction of those objecting to a release, I will argue.

Do we wait four years for adequate testing? I’m not being facetious because 
we’re rolling up on three years since the initial donation of the wrapper was 
made. No one can force anyone else to do work here, sometimes things take a 
while, and there still may be a great deal of time that passes before testing 
is present that is considered adequate.

All else being equal, I think the value of a release to remove the state of 
limbo the wrapper has been in for years outweighs the current lack of testing. 
The wrapper has been in use for 8 years, and while more testing is preferred we 
have reasonable assurances it works as expected. I don’t think we’ll be back to 
zero if we find issues, they can be fixed and will be accompanied by tests as 
most things here are. Right now from a user’s perspective the wrapper appears 
dead at Takari and Apache which is a shame.

Would everyone be amenable to an alpha release? And transition to a non-alpha 
release when everyone agrees the testing is sufficient?

jvz


 On Dec 12, 2021, at 5:14 AM, Maarten Mulders  wrote:

 Chiming in a little late, but here are my 2 cents nevertheless. I would not 
feel confident releasing something that we cannot test in an automated way. Not 
having an integration test suite means we don't know for sure if it works. And 
if we know it works and we change something, we're back to zero.

 To me, this has nothing to do with a (misplaced) drive for perfection. It is 
all about making sure we ship something to users that we know to work, and that 
we can easily prove to still work after we change it.

 Thanks,

 Maarten

 On 11/12/2021 13:43, Robert Scholte wrote:

 It was marked for Maven 4, and part of the improvements was test automation, 
which was now possible because it became part of Maven Core.
 Even thought the code still exists in Maven Core, is has now become useless.
 There hasn't been a real need for new releases of Maven Wrapper Plugin until a 
range of Maven 3.8 started.
 Maven Wrapper would have been another feature to attract developers to Maven 4.
 And finally, I see that the donated code has been used as base, ignoring all 
the effort done to improve that codebase done afterwards.
 Hence my response that reliability is gone that was added after donation.
 Robert
 -- Origineel bericht --
 Van: "Manfred Moser" 
 Aan: dev@maven.apache.org
 Verzonden: 10-12-2021 20:58:33
 Onderwerp: Re: reviewing Maven Wrapper before releasing

 I totally agree with finally just shipping this. We got this all donated about 
two years ago now and there is still nothing shipping.

 I used to just manually do the testing and thousands of projects are happy. I 
assume the new project is at least manually testing and works as before or 
better. Let's not wait nay more and let perfection get into our way. It surely 
is good enough for a release.

 The beauty is that if you find an issue.. you just ship again ... no reason to 
wait.

 manfred

 Hervé BOUTEMY wrote on 2021-12-10 04:13 (GMT -08:00):


  the current 3.1.0-SNAPSHOT works like 0.5.6 as donated: I confess I did not
  test, I just did not change anything using the general approach "people were
  happy before, just continue step by step improvements" :)

  reading the mvnw script (*nix), compiling+running the .java is executed only 
if
  neither wget nor curl are available on your machine

  reading the mvnw.cmd, it seems .java is not supported

  looking at Git history confirms:
https://github.com/apache/maven-wrapper/commit/570bc50afe07bff696a097cd7746d01b00e70337


  Don't hesitate to create a Jira issue and corresponding fix to add .java
  support for Windows: future 3.1.0 will have one more fix over previous 0.5.6

  Regards,

  Hervé

  Le vendredi 10 décembre 2021, 10:40:41 CET Robert Scholte a écrit :

  I need more time.

[VOTE] Release Apache Maven Doxia Sitetools version 1.11.1

[Michael Osipov]

Hi,

We solved 3 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317320=12351046

There are still a couple of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317320%20AND%20status%20%3D%20Open

Staging repo:
https://repository.apache.org/content/repositories/maven-1678
https://repository.apache.org/content/repositories/maven-1678/org/apache/maven/doxia/doxia-sitetools/1.11.1/doxia-sitetools-1.11.1-source-release.zip

Source release checksum(s):
doxia-sitetools-1.11.1-source-release.zip
sha512: 
e52c646657f7fa14f9ab1051c804d6097e38b4bddf41c2fa123bacb177c1a5a4709a17033c5648988620edd55d2497a2c2a66b4376bfc4fcb2161388951961a2


Staging site:
https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-LATEST/

Guide to testing staged releases:
https://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: [DISCUSS] Move maven caching to an external repository

[Jeff Jensen]

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 
> > >
> > > wrote:
> > > > > > Following the recent work done to integrate the maven caching /
> > > > >
> > > > > incremental
> > > > >
> > > > > > build system into maven, I think it's now time to discuss where
> we
> > >
> > > want
> > >
> > > > > its
> > > > >
> > > > > > long-term location to be.
> > > > > >
> > > > > > This extension was donated a few months ago and provides local
> and
> > > > > > remote
> > > > > > caching of maven project's output, based on computed hashes of
> the
> > > > >
> > > > > inputs.
> > > > >
> > > > > > It's defined as a maven extension and can be used as a core or
> build
> > > > > > extension.  This avoids building the project and speeds up
> builds a
> > >
> > > lot
> > 

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

[Hervé BOUTEMY]

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 
> > 
> > wrote:
> > > > > Following the recent work done to integrate the maven caching /
> > > > 
> > > > incremental
> > > > 
> > > > > build system into maven, I think it's now time to discuss where we
> > 
> > want
> > 
> > > > its
> > > > 
> > > > > long-term location to be.
> > > > > 
> > > > > This extension was donated a few months ago and provides local and
> > > > > remote
> > > > > caching of maven project's output, based on computed hashes of the
> > > > 
> > > > inputs.
> > > > 
> > > > > It's defined as a maven extension and can be used as a core or build
> > > > > extension.  This avoids building the project and speeds up builds a
> > 
> > lot
> > 
> > > > > !
> > > > > 
> > > > > The current status of this work resides in 3 branches:
> > > > >   * MNG-7129-3.8.x (PR at https://github.com/apache/maven/pull/622)
> > > > >   * MNG-7129-master (PR at https://github.com/apache/maven/pull/607)
> > > > >   * https://github.com/apache/maven/tree/MNG-7129-maven-caching
> > > > > 
> > > > > The two first PRs include the required changes to integrate the
> > > > > extension
> > > > > in maven 3.8.x (or rather 3.9.x) and in master. The last branch is
> > 
> > the
> > 
> > > > one
> > > > 
> > > > > that should be moved to a separate repository and contain the code
> > 
> > for
> > 
> > > > the
> > > > 
> > > > > extension.  The goal is to agree on the location and the final name
> > 
> > for
> > 
> > > > the
> > > > 
> > > > > repository (it can't be changed easily).
> > > > > 
> > > > > I propose maven-caching as the repository / subproject name, but any
> > > > 
> > > > better
> > > > 
> > > > > name is welcomed of course.
> > > > > 
> > > > > --
> > > > > 
> > > > > Guillaume Nodet
> > 
> > -
> > 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: reviewing Maven Wrapper before releasing

[Jason van Zyl]

Clearly no one here disagrees with the goal of having robust testing for 
software that is made available to users.

As to the timing of that testing being complete for the wrapper, to the 
satisfaction of those objecting to a release, I will argue.

Do we wait four years for adequate testing? I’m not being facetious because 
we’re rolling up on three years since the initial donation of the wrapper was 
made. No one can force anyone else to do work here, sometimes things take a 
while, and there still may be a great deal of time that passes before testing 
is present that is considered adequate.

All else being equal, I think the value of a release to remove the state of 
limbo the wrapper has been in for years outweighs the current lack of testing. 
The wrapper has been in use for 8 years, and while more testing is preferred we 
have reasonable assurances it works as expected. I don’t think we’ll be back to 
zero if we find issues, they can be fixed and will be accompanied by tests as 
most things here are. Right now from a user’s perspective the wrapper appears 
dead at Takari and Apache which is a shame. 

Would everyone be amenable to an alpha release? And transition to a non-alpha 
release when everyone agrees the testing is sufficient?

jvz

> On Dec 12, 2021, at 5:14 AM, Maarten Mulders  wrote:
> 
> Chiming in a little late, but here are my 2 cents nevertheless. I would not 
> feel confident releasing something that we cannot test in an automated way. 
> Not having an integration test suite means we don't know for sure if it 
> works. And if we know it works and we change something, we're back to zero.
> 
> To me, this has nothing to do with a (misplaced) drive for perfection. It is 
> all about making sure we ship something to users that we know to work, and 
> that we can easily prove to still work after we change it.
> 
> Thanks,
> 
> Maarten
> 
> On 11/12/2021 13:43, Robert Scholte wrote:
>> It was marked for Maven 4, and part of the improvements was test automation, 
>> which was now possible because it became part of Maven Core.
>> Even thought the code still exists in Maven Core, is has now become useless.
>> There hasn't been a real need for new releases of Maven Wrapper Plugin until 
>> a range of Maven 3.8 started.
>> Maven Wrapper would have been another feature to attract developers to Maven 
>> 4.
>> And finally, I see that the donated code has been used as base, ignoring all 
>> the effort done to improve that codebase done afterwards.
>> Hence my response that reliability is gone that was added after donation.
>> Robert
>> -- Origineel bericht --
>> Van: "Manfred Moser" 
>> Aan: dev@maven.apache.org
>> Verzonden: 10-12-2021 20:58:33
>> Onderwerp: Re: reviewing Maven Wrapper before releasing
>>> I totally agree with finally just shipping this. We got this all donated 
>>> about two years ago now and there is still nothing shipping.
>>> 
>>> I used to just manually do the testing and thousands of projects are happy. 
>>> I assume the new project is at least manually testing and works as before 
>>> or better. Let's not wait nay more and let perfection get into our way. It 
>>> surely is good enough for a release.
>>> 
>>> The beauty is that if you find an issue.. you just ship again ... no reason 
>>> to wait.
>>> 
>>> manfred
>>> 
>>> Hervé BOUTEMY wrote on 2021-12-10 04:13 (GMT -08:00):
>>> 
  the current 3.1.0-SNAPSHOT works like 0.5.6 as donated: I confess I did 
 not
  test, I just did not change anything using the general approach "people 
 were
  happy before, just continue step by step improvements" :)
 
  reading the mvnw script (*nix), compiling+running the .java is executed 
 only if
  neither wget nor curl are available on your machine
 
  reading the mvnw.cmd, it seems .java is not supported
 
  looking at Git history confirms:
 https://github.com/apache/maven-wrapper/commit/570bc50afe07bff696a097cd7746d01b00e70337
  
 
 
  Don't hesitate to create a Jira issue and corresponding fix to add .java
  support for Windows: future 3.1.0 will have one more fix over previous 
 0.5.6
 
  Regards,
 
  Hervé
 
  Le vendredi 10 décembre 2021, 10:40:41 CET Robert Scholte a écrit :
>  I need more time.
> 
>  e.g. it looks like type=source doesn't use the Java sourcefile to
>  download the wrapper.
>  now that the plugin and wrapper are combined in one project, the ITs are
>  incomplete.
>  They should call both the wrapper-goal and something like 'mvnw
>  --version' to ensure it is working (this used to be done in
>  maven-integration-testing)
> 
>  thanks,
>  Robert
> 
>  -- Origineel bericht --
>  Van: "Hervé BOUTEMY" 
>  Aan: "Maven Developers List" 
>  Verzonden: 10-12-2021 08:08:57
>  Onderwerp: Re: reviewing Maven Wrapper before releasing
> 
>  >thank you to everybody who reviewed, 

Re: reviewing Maven Wrapper before releasing

[Hervé BOUTEMY]

sure, having ITs is our best bet for maintenance, particularly with the OS-
dependant scripts

notice that with wrapper releases being back independent from Maven core 
releases, the impact of any issue is not definitive: newer releases of wrapper 
will fix bugs and permit new features for every past and future release of 
Maven core = what Manfred did for years and made Maven Wrapper successful. We 
can safely continue this success history.

Regards,

Hervé

Le dimanche 12 décembre 2021, 11:14:37 CET Maarten Mulders a écrit :
> Chiming in a little late, but here are my 2 cents nevertheless. I would
> not feel confident releasing something that we cannot test in an
> automated way. Not having an integration test suite means we don't know
> for sure if it works. And if we know it works and we change something,
> we're back to zero.
> 
> To me, this has nothing to do with a (misplaced) drive for perfection.
> It is all about making sure we ship something to users that we know to
> work, and that we can easily prove to still work after we change it.
> 
> Thanks,
> 
> Maarten
> 
> On 11/12/2021 13:43, Robert Scholte wrote:
> > It was marked for Maven 4, and part of the improvements was test
> > automation, which was now possible because it became part of Maven Core.
> > Even thought the code still exists in Maven Core, is has now become
> > useless.
> > 
> > There hasn't been a real need for new releases of Maven Wrapper Plugin
> > until a range of Maven 3.8 started.
> > Maven Wrapper would have been another feature to attract developers to
> > Maven 4.
> > 
> > And finally, I see that the donated code has been used as base, ignoring
> > all the effort done to improve that codebase done afterwards.
> > Hence my response that reliability is gone that was added after donation.
> > 
> > Robert
> > 
> > -- Origineel bericht --
> > Van: "Manfred Moser" 
> > Aan: dev@maven.apache.org
> > Verzonden: 10-12-2021 20:58:33
> > Onderwerp: Re: reviewing Maven Wrapper before releasing
> > 
> >> I totally agree with finally just shipping this. We got this all
> >> donated about two years ago now and there is still nothing shipping.
> >> 
> >> I used to just manually do the testing and thousands of projects are
> >> happy. I assume the new project is at least manually testing and works
> >> as before or better. Let's not wait nay more and let perfection get
> >> into our way. It surely is good enough for a release.
> >> 
> >> The beauty is that if you find an issue.. you just ship again ... no
> >> reason to wait.
> >> 
> >> manfred
> >> 
> >> Hervé BOUTEMY wrote on 2021-12-10 04:13 (GMT -08:00):
> >>>  the current 3.1.0-SNAPSHOT works like 0.5.6 as donated: I confess I
> >>> did not
> >>>  test, I just did not change anything using the general approach
> >>> "people were
> >>>  happy before, just continue step by step improvements" :)
> >>> 
> >>>  reading the mvnw script (*nix), compiling+running the .java is
> >>> executed only if
> >>>  neither wget nor curl are available on your machine
> >>> 
> >>>  reading the mvnw.cmd, it seems .java is not supported
> >>> 
> >>>  looking at Git history confirms:
> >>> https://github.com/apache/maven-wrapper/commit/570bc50afe07bff696a097cd7
> >>> 746d01b00e70337
> >>> 
> >>> 
> >>> 
> >>>  Don't hesitate to create a Jira issue and corresponding fix to add
> >>> .java
> >>>  support for Windows: future 3.1.0 will have one more fix over
> >>> previous 0.5.6
> >>> 
> >>>  Regards,
> >>> 
> >>>  Hervé
> >>> 
> >>>  Le vendredi 10 décembre 2021, 10:40:41 CET Robert Scholte a écrit :
>   I need more time.
>  
>   e.g. it looks like type=source doesn't use the Java sourcefile to
>   download the wrapper.
>   now that the plugin and wrapper are combined in one project, the
>  ITs are
>   incomplete.
>   They should call both the wrapper-goal and something like 'mvnw
>   --version' to ensure it is working (this used to be done in
>   maven-integration-testing)
>  
>   thanks,
>   Robert
>  
>   -- Origineel bericht --
>   Van: "Hervé BOUTEMY" 
>   Aan: "Maven Developers List" 
>   Verzonden: 10-12-2021 08:08:57
>   Onderwerp: Re: reviewing Maven Wrapper before releasing
>  
>   >thank you to everybody who reviewed, discussed, contributed
>   >
>   >we now have 16 issues fixed, everything seems stable
>   >
>   >if nobody objects, I'll start a release over the week-end
>   >
>   >Regards,
>   >
>   >Hervé
>   >
>   >Le mardi 7 décembre 2021, 00:07:41 CET Hervé BOUTEMY a écrit :
>   >>  Hi,
>   >>
>   >>  Maven Wrapper has been donated to Apache Maven, imported to
>   >>
>   >>https://github.com/apache/maven-wrapper
>   >>
>   >>  Documentation published to https://maven.apache.org/wrapper/
>   >>
>   >>  Here is the list of fixes from previous 0.5.6 release:
>   

[GitHub] [maven-site-plugin] michael-o closed pull request #62: MSITE-876 require at least Maven 3.6.1

[GitBox]

michael-o closed pull request #62:
URL: https://github.com/apache/maven-site-plugin/pull/62


   


-- 
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: [VOTE] [CANCELED] Release Apache Maven Doxia Sitetools version 1.11

[Michael Osipov]

Am 2021-12-12 um 10:05 schrieb Hervé BOUTEMY:

sorry, -1

this releases pulls Doxia 1.11 instead of 1.11.1

see 
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-doxia-sitetools/job/master/

The good news is that Doxia Sitetools 1.11.1 will use Doxia 1.11.1, which is 
easier to guess


My bad, I will fix and reroll.

Re: reviewing Maven Wrapper before releasing

[Maarten Mulders]

Chiming in a little late, but here are my 2 cents nevertheless. I would 
not feel confident releasing something that we cannot test in an 
automated way. Not having an integration test suite means we don't know 
for sure if it works. And if we know it works and we change something, 
we're back to zero.


To me, this has nothing to do with a (misplaced) drive for perfection. 
It is all about making sure we ship something to users that we know to 
work, and that we can easily prove to still work after we change it.


Thanks,

Maarten

On 11/12/2021 13:43, Robert Scholte wrote:
It was marked for Maven 4, and part of the improvements was test 
automation, which was now possible because it became part of Maven Core.
Even thought the code still exists in Maven Core, is has now become 
useless.


There hasn't been a real need for new releases of Maven Wrapper Plugin 
until a range of Maven 3.8 started.
Maven Wrapper would have been another feature to attract developers to 
Maven 4.


And finally, I see that the donated code has been used as base, ignoring 
all the effort done to improve that codebase done afterwards.

Hence my response that reliability is gone that was added after donation.

Robert

-- Origineel bericht --
Van: "Manfred Moser" 
Aan: dev@maven.apache.org
Verzonden: 10-12-2021 20:58:33
Onderwerp: Re: reviewing Maven Wrapper before releasing

I totally agree with finally just shipping this. We got this all 
donated about two years ago now and there is still nothing shipping.


I used to just manually do the testing and thousands of projects are 
happy. I assume the new project is at least manually testing and works 
as before or better. Let's not wait nay more and let perfection get 
into our way. It surely is good enough for a release.


The beauty is that if you find an issue.. you just ship again ... no 
reason to wait.


manfred

Hervé BOUTEMY wrote on 2021-12-10 04:13 (GMT -08:00):

 the current 3.1.0-SNAPSHOT works like 0.5.6 as donated: I confess I 
did not
 test, I just did not change anything using the general approach 
"people were

 happy before, just continue step by step improvements" :)

 reading the mvnw script (*nix), compiling+running the .java is 
executed only if

 neither wget nor curl are available on your machine

 reading the mvnw.cmd, it seems .java is not supported

 looking at Git history confirms:
https://github.com/apache/maven-wrapper/commit/570bc50afe07bff696a097cd7746d01b00e70337 




 Don't hesitate to create a Jira issue and corresponding fix to add 
.java
 support for Windows: future 3.1.0 will have one more fix over 
previous 0.5.6


 Regards,

 Hervé

 Le vendredi 10 décembre 2021, 10:40:41 CET Robert Scholte a écrit :

 I need more time.

 e.g. it looks like type=source doesn't use the Java sourcefile to
 download the wrapper.
 now that the plugin and wrapper are combined in one project, the 
ITs are

 incomplete.
 They should call both the wrapper-goal and something like 'mvnw
 --version' to ensure it is working (this used to be done in
 maven-integration-testing)

 thanks,
 Robert

 -- Origineel bericht --
 Van: "Hervé BOUTEMY" 
 Aan: "Maven Developers List" 
 Verzonden: 10-12-2021 08:08:57
 Onderwerp: Re: reviewing Maven Wrapper before releasing

 >thank you to everybody who reviewed, discussed, contributed
 >
 >we now have 16 issues fixed, everything seems stable
 >
 >if nobody objects, I'll start a release over the week-end
 >
 >Regards,
 >
 >Hervé
 >
 >Le mardi 7 décembre 2021, 00:07:41 CET Hervé BOUTEMY a écrit :
 >>  Hi,
 >>
 >>  Maven Wrapper has been donated to Apache Maven, imported to
 >>
 >>https://github.com/apache/maven-wrapper
 >>
 >>  Documentation published to https://maven.apache.org/wrapper/
 >>
 >>  Here is the list of fixes from previous 0.5.6 release:
 >>https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12323721; 


 >>ve>>
 >>  rsion=12350068
 >>
 >>
 >>  Please test and review so we can do a release soon
 >>
 >>  Regards,
 >>
 >>  Hervé
 >>
 >>
 >>
 >>  
-

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

 -
 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 Doxia Sitetools version 1.11

[Hervé BOUTEMY]

sorry, -1

this releases pulls Doxia 1.11 instead of 1.11.1

see 
https://ci-maven.apache.org/job/Maven/job/maven-box/job/maven-doxia-sitetools/job/master/

The good news is that Doxia Sitetools 1.11.1 will use Doxia 1.11.1, which is 
easier to guess

Regards,

Hervé

Le vendredi 10 décembre 2021, 22:35:30 CET Michael Osipov a écrit :
> Hi,
> 
> We solved 3 issues:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12317320
> rsion=12350749
> 
> There are still a couple of issues left in JIRA:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%2012317320%20AND%20
> status%20%3D%20Open
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-1677
> https://repository.apache.org/content/repositories/maven-1677/org/apache/mav
> en/doxia/doxia-sitetools/1.11/doxia-sitetools-1.11-source-release.zip
> 
> Source release checksum(s):
> doxia-sitetools-1.11-source-release.zip
> sha512:
> 7b906c0f41dfd15ba5f07d22c1c29636a67820b66c9cfe00d5d7bd8c4b0f4cfd9079ce17055f
> eab1d0974e1139ab9db33e9ead39e3de518c172663766e37958f
> 
> Staging site:
> https://maven.apache.org/doxia/doxia-sitetools-archives/doxia-sitetools-LATE
> ST/
> 
> Guide to testing staged releases:
> https://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org





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