Re: Why no mvn daemon?

[Benjamin Marwell]

Add my +1 to Romain's.
As said, it is drop-in replacement most of the times, has a nice TUI, sane
defaults and speeds up your build.

If you haven't tried it yet, definitely do.

As for the resident memory: no software is ever finished, there will always
be something which can be done better. I don't mind, we can make it better
if we want to. That's why we're here in the first place, no? 

Haven't tried it on Jenkins nor GH actions, though. But I don't remember I
built shiro without mvnd. It's just so much faster using 3+ threads (plus
you *will* discover badly isolated tests). It also made me rework projects
at work into mire modules, which also lead to (imho) better design, as we
now have better encapsulated responsibility (and extra API projects for
CDI) PLUS faster builds.

- Ben


On Wed, 31 Mar 2021, 08:52 Romain Manni-Bucau, 
wrote:

> Le mer. 31 mars 2021 à 08:17, Hervé BOUTEMY  a
> écrit :
>
> > I think mvnd is not so well known [1]: I did never test it, I should
> > probably
> > do...
> >
> > and as incremental compilation discussion have started recently, we'll
> > need to
> > have a global discussion on evaluating and eventually mixing differents
> > ways of
> > improving build performance
> >
>
> +10, mvnd is awesome but solves the JVM pitfalls mainly, incremental
> support is per mojo to be optimized and both would be awesome.
> Basically optimizing the JVM + the runtime at the same time.
>
>
> >
> > when evaluating, I think we'll need to keep in mind one key aspect: from
> a
> > user perspective, which deployment and usage complexities does every
> > solution
> > bring for which performance improvement?
> >
>
> I think the main one maven should target is the "local" env (this is why
> mvnd fits so well) - by opposition of a remote server as gradle enterprise
> one which requires some infra, typically maven does not produce nexus byt
> stick on local software and I think it is sane to target it primarly.
>
>
> >
> > I feel that each solution that brings more expected performance
> > improvement
> > comes with at least a deployment complexity, perhaps sometimes use
> > complexity
> > also (per-project configuration, ...)
> >
>
> Hmm, here the only drawback of mvnd is to have the daemon running and
> consume the related memory but it is also why you use it so it is almost
> free for me - at least in usage. It is not like having to setup a server
> and configure the client in maven since launching mvnd instead of mvn you
> launch the mvnd client + the daemon if not already running so in terms of
> user experience you can alias mvn=mvnd and you will not notice the
> difference if you have enough memory.
> My typicall pitfall with 16G of ram is to have idea+chrome+minikube
> launched and mvd preventing a graalvm build (not enough memory)...but it is
> not mainstream too as memory consumption.
> Also there is a ticket about improving mvnd daemon auto-monitoring to kill
> itself if machine memory is too low and it is not used (
> https://github.com/mvndaemon/mvnd/issues/364) so this pitfall can
> disappear
> too.
>
>
> >
> > but currently mvnd is the only free solution publicly available: I should
> > definitely test it to better know it when we'll have more in depth
> > discussions
> > in the future
> >
> > Please keep posting your factual returns on experience: that's definitely
> > useful
> >
> > Regards,
> >
> > Hervé
> >
> > [1] https://github.com/mvndaemon/mvnd
> >
> > Le mardi 30 mars 2021, 22:32:37 CEST Romain Manni-Bucau a écrit :
> > > Le mar. 30 mars 2021 à 22:16, Jochen Wiedmann <
> jochen.wiedm...@gmail.com>
> > a
> > >
> > > écrit :
> > > > On Tue, Mar 30, 2021 at 7:58 PM Benjamin Marwell <
> bmarw...@apache.org>
> > > >
> > > > wrote:
> > > > > Other than that, I use mvnd at work and we never had problems on
> any
> > > > > project. We consistently save time without the need of adding the
> -T
> > > > > parameter manually. Another big question is probably: is there
> enough
> > > > > community demand to merge it into core?
> > > > >
> > > > > Tbh, I expected more mails on this thread.
> > > >
> > > > The question for me: Who's launching this mvnd? I wouldn't want to
> > > > have a dedicated server for that. However, if (for example) m2e would
> > > > launch it automatically when I open Eclipse, and perform a shutdown,
> > > > when Eclipse closes, then I'd be perfectly happy to use it.
> > >
> > > mvnd. As soon as env changes (you launch it from another project)
> daemon
> > is
> > > killed.
> > > Indeed you can kill it manually too - which makes it saner than idea
> > remote
> > > maven server or ide maven server which cant be killed generally and
> > consume
> > > a lot of mem while ide is on.
> > >
> > > Indeed you can bind mvnd --stop on eclipse shutdown which would behave
> as
> > > you expect but working on the cli without any ide specific integ is
> maven
> > > scope, not idea integration IMO (even if a few code enable it but guess
> > it
> > > is legacy now thanks the 

Re: [VOTE] Release Apache Maven version 3.8.1

[Elliotte Rusty Harold]

On Wed, Mar 31, 2021 at 8:11 AM  wrote:
>
> I had the same observation. I *think* it is caused by the fact that you
> manually downloaded the ZIP archive - browsers on macOS set the
> 'quarantine' flag on downloaded files. It also happens if I download
> 3.6.3 manually (i.e., using Firefox).
>

I'm not an expert about this, but I'm not sure that's the root cause
of this issue. I think what needs to happen here is that JANSI needs
to be properly signed to identify the developer.


-- 
Elliotte Rusty Harold
elh...@ibiblio.org

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

Re: [VOTE] Release Apache Maven version 3.8.1

[Arnaud Héritier]

ok, I think it makes sense then.
+1 for me, all my tests are ok

On Wed, Mar 31, 2021 at 10:11 AM  wrote:

> I had the same observation. I *think* it is caused by the fact that you
> manually downloaded the ZIP archive - browsers on macOS set the
> 'quarantine' flag on downloaded files. It also happens if I download
> 3.6.3 manually (i.e., using Firefox).
>
> I think the Homebrew package manager for macOS doesn't have this issue.
> At least, I cannot recall ever having seen that message for Maven
> versions that I installed through Homebrew.
>
> Thanks,
>
> Maarten
>
> On March 31, 2021 at 09:38, Arnaud Héritier wrote:
> > I have a problem on macos that I didn't have with 3.6.3, when I launch
> > maven it I have this error:
> >
> > “libjansi.jnilib” cannot be opened because the developer cannot be
> verified.
> > macOS cannot verify that this app is free from malware.
> > Brave downloaded this file today at 09:25.
> >
> > It's a popup window:
> >
> https://www.dropbox.com/s/tj0yp3hzuerm1ll/Screenshot%202021-03-31%20at%2009.29.06.png?dl=0
> > <
> https://www.dropbox.com/s/tj0yp3hzuerm1ll/Screenshot%202021-03-31%20at%2009.29.06.png?dl=0
> >
> >
> > I manually installed Maven from the zip (in general I use ASDF).
> >
> > I can use the "Allow Anyway" in "Security & Privacy" settings but then I
> > have another message:
> >
> https://www.dropbox.com/s/icgddpm7zfzvjx8/Screenshot%202021-03-31%20at%2009.37.14.png?dl=0
> > <
> https://www.dropbox.com/s/icgddpm7zfzvjx8/Screenshot%202021-03-31%20at%2009.37.14.png?dl=0
> >
> >
> > macOS cannot verify the developer of “libjansi.jnilib”. Are you sure you
> > want to open it?
> > By opening this app, you will be overriding system security which can
> > expose your computer and personal information to malware that may harm
> > your Mac or compromise your privacy.
> > Brave downloaded this file today at 09:25.
> >
> >
> > After this last pop the problem disappears.
> >
> > Not a problem for me but I don't remember to have done this in the past
> > for jansi. Did we change anything ?
> >
> >
> > On Wed, Mar 31, 2021 at 8:46 AM Maarten Mulders  > > wrote:
> >
> > Retried the test that I did on 3.8.0, this time I observe the
> desired /
> > correct behaviour.
> >
> >
> > +1
> >
> >
> > Maarten
> >
> >
> > On March 31, 2021, at 01:46, Mark Derricutt wrote:
> >  > +1 non-binding
> >  >
> >  > - bistro zips are in the /dev/ tree
> >  > - my multi-repo osgi maven tiles weirdo build works fine.
> >  >
> >  >
> >  >
> >  >
> >  > From: Robert Scholte  > >  > >
> >  > Reply: Maven Developers List  > >  > >
> >  > Date: 31 March 2021 at 9:58:56 AM
> >  > To: dev@maven.apache.org 
> > mailto:dev@maven.apache.org>>
> > mailto:dev@maven.apache.org>>
> >  > Subject:  [VOTE] Release Apache Maven version 3.8.1
> >  >
> >  > Hi,
> >  >
> >  > For the details about this release, please read
> >  > https://maven.apache.org/docs/3.8.1/release-notes.html
> > 
> >  > Also please provide feedback on the release notes. (as you know,
> > these are
> >  > published separately from the release, so it doesn't have to
> > block the
> >  > release itself)
> >  >
> >  > We solved 6 issues:
> >  >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12350032=Text
> > <
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12350032=Text
> >
> >  >
> >  > Staging repo:
> >  > https://repository.apache.org/content/repositories/maven-1634/
> > 
> >  >
> >
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.1/binaries/apache-maven-3.8.1-bin.zip
> > <
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.1/binaries/apache-maven-3.8.1-bin.zip
> >
> >  >
> >
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.1/source/apache-maven-3.8.1-src.zip
> > <
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.1/source/apache-maven-3.8.1-src.zip
> >
> >  >
> >  > Source release checksum(s):
> >  > apache-maven-3.8.1-bin.zip sha512:
> >  >
> >
>  
> c585847bfbcf8647aeabfd3e8bf0ac3f67a037bd345545e274766f144c2b978b3457cbc3e31545e62c21ad69e732695de01ec96ea2580e5da67bd85df095c0f4
> >  >
> >  > apache-maven-3.8.1-src.zip
> >  > sha512:
> >
>  
> 893988635349985074c88ce5ef27ac5ccb62fcdf58846209eee8a7ea5515238288b91c202347ca42e201ab336c14d83f3f5fd8194070e57b9366bcce2414614d
> >  >
> >  >
> >  > Knows issues:
> >  > When building with the sources with JDK-16 and above, the unittest
> >  > MavenCliTest#testStyleColors will fail. 

Re: [VOTE] Release Apache Maven version 3.8.1

[mthmulders]

I had the same observation. I *think* it is caused by the fact that you 
manually downloaded the ZIP archive - browsers on macOS set the 
'quarantine' flag on downloaded files. It also happens if I download 
3.6.3 manually (i.e., using Firefox).


I think the Homebrew package manager for macOS doesn't have this issue. 
At least, I cannot recall ever having seen that message for Maven 
versions that I installed through Homebrew.


Thanks,

Maarten

On March 31, 2021 at 09:38, Arnaud Héritier wrote:
I have a problem on macos that I didn't have with 3.6.3, when I launch 
maven it I have this error:


“libjansi.jnilib” cannot be opened because the developer cannot be verified.
macOS cannot verify that this app is free from malware.
Brave downloaded this file today at 09:25.

It's a popup window: 
https://www.dropbox.com/s/tj0yp3hzuerm1ll/Screenshot%202021-03-31%20at%2009.29.06.png?dl=0 



I manually installed Maven from the zip (in general I use ASDF).

I can use the "Allow Anyway" in "Security & Privacy" settings but then I 
have another message: 
https://www.dropbox.com/s/icgddpm7zfzvjx8/Screenshot%202021-03-31%20at%2009.37.14.png?dl=0 



macOS cannot verify the developer of “libjansi.jnilib”. Are you sure you 
want to open it?
By opening this app, you will be overriding system security which can 
expose your computer and personal information to malware that may harm 
your Mac or compromise your privacy.

Brave downloaded this file today at 09:25.


After this last pop the problem disappears.

Not a problem for me but I don't remember to have done this in the past 
for jansi. Did we change anything ?



On Wed, Mar 31, 2021 at 8:46 AM Maarten Mulders > wrote:


Retried the test that I did on 3.8.0, this time I observe the desired /
correct behaviour.


+1


Maarten


On March 31, 2021, at 01:46, Mark Derricutt wrote:
 > +1 non-binding
 >
 >     - bistro zips are in the /dev/ tree
 >     - my multi-repo osgi maven tiles weirdo build works fine.
 >
 >
 >
 >
 > From: Robert Scholte mailto:rfscho...@apache.org>> mailto:rfscho...@apache.org>>
 > Reply: Maven Developers List mailto:dev@maven.apache.org>> mailto:dev@maven.apache.org>>
 > Date: 31 March 2021 at 9:58:56 AM
 > To: dev@maven.apache.org 
mailto:dev@maven.apache.org>>
mailto:dev@maven.apache.org>>
 > Subject:  [VOTE] Release Apache Maven version 3.8.1
 >
 > Hi,
 >
 > For the details about this release, please read
 > https://maven.apache.org/docs/3.8.1/release-notes.html

 > Also please provide feedback on the release notes. (as you know,
these are
 > published separately from the release, so it doesn't have to
block the
 > release itself)
 >
 > We solved 6 issues:
 >

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12350032=Text


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

 >

https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.1/binaries/apache-maven-3.8.1-bin.zip


 >

https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.1/source/apache-maven-3.8.1-src.zip


 >
 > Source release checksum(s):
 > apache-maven-3.8.1-bin.zip sha512:
 >

c585847bfbcf8647aeabfd3e8bf0ac3f67a037bd345545e274766f144c2b978b3457cbc3e31545e62c21ad69e732695de01ec96ea2580e5da67bd85df095c0f4
 >
 > apache-maven-3.8.1-src.zip
 > sha512:

893988635349985074c88ce5ef27ac5ccb62fcdf58846209eee8a7ea5515238288b91c202347ca42e201ab336c14d83f3f5fd8194070e57b9366bcce2414614d
 >
 >
 > Knows issues:
 > When building with the sources with JDK-16 and above, the unittest
 > MavenCliTest#testStyleColors will fail. This will be fix with
MNG-7127[1],
 > but is left out to keep focus on the real purpose of this release.
 >
 > Staging site:
 > https://maven.apache.org/ref/3-LATEST/

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

 >
 > Vote open for at least 72 hours.
 >
 > [ ] +1
 > [ ] +0
 > [ ] -1
 >
 >
   

Re: [VOTE] Release Apache Maven version 3.8.1

[Romain Manni-Bucau]

Except http://rubygems-proxy.torquebox.org/releases/ breaking (and HTTPS
setup is not better) it works as expected +1

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



Le mer. 31 mars 2021 à 09:47, Arnaud Héritier  a
écrit :

> I have a problem on macos that I didn't have with 3.6.3, when I launch
> maven it I have this error:
>
> “libjansi.jnilib” cannot be opened because the developer cannot be
> verified.
> macOS cannot verify that this app is free from malware.
> Brave downloaded this file today at 09:25.
>
> It's a popup window:
>
> https://www.dropbox.com/s/tj0yp3hzuerm1ll/Screenshot%202021-03-31%20at%2009.29.06.png?dl=0
>
> I manually installed Maven from the zip (in general I use ASDF).
>
> I can use the "Allow Anyway" in "Security & Privacy" settings but then I
> have another message:
>
> https://www.dropbox.com/s/icgddpm7zfzvjx8/Screenshot%202021-03-31%20at%2009.37.14.png?dl=0
>
> macOS cannot verify the developer of “libjansi.jnilib”. Are you sure you
> want to open it?
> By opening this app, you will be overriding system security which can
> expose your computer and personal information to malware that may harm your
> Mac or compromise your privacy.
> Brave downloaded this file today at 09:25.
>
>
> After this last pop the problem disappears.
>
> Not a problem for me but I don't remember to have done this in the past for
> jansi. Did we change anything ?
>
>
> On Wed, Mar 31, 2021 at 8:46 AM Maarten Mulders 
> wrote:
>
> > Retried the test that I did on 3.8.0, this time I observe the desired /
> > correct behaviour.
> >
> >
> > +1
> >
> >
> > Maarten
> >
> >
> > On March 31, 2021, at 01:46, Mark Derricutt wrote:
> > > +1 non-binding
> > >
> > > - bistro zips are in the /dev/ tree
> > > - my multi-repo osgi maven tiles weirdo build works fine.
> > >
> > >
> > >
> > >
> > > From: Robert Scholte  
> > > Reply: Maven Developers List  <
> > dev@maven.apache.org>
> > > Date: 31 March 2021 at 9:58:56 AM
> > > To: dev@maven.apache.org  
> > > Subject:  [VOTE] Release Apache Maven version 3.8.1
> > >
> > > Hi,
> > >
> > > For the details about this release, please read
> > > https://maven.apache.org/docs/3.8.1/release-notes.html
> > > Also please provide feedback on the release notes. (as you know, these
> > are
> > > published separately from the release, so it doesn't have to block the
> > > release itself)
> > >
> > > We solved 6 issues:
> > >
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12350032=Text
> > >
> > > Staging repo:
> > > https://repository.apache.org/content/repositories/maven-1634/
> > >
> >
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.1/binaries/apache-maven-3.8.1-bin.zip
> > >
> >
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.1/source/apache-maven-3.8.1-src.zip
> > >
> > > Source release checksum(s):
> > > apache-maven-3.8.1-bin.zip sha512:
> > >
> >
> c585847bfbcf8647aeabfd3e8bf0ac3f67a037bd345545e274766f144c2b978b3457cbc3e31545e62c21ad69e732695de01ec96ea2580e5da67bd85df095c0f4
> > >
> > > apache-maven-3.8.1-src.zip
> > > sha512:
> >
> 893988635349985074c88ce5ef27ac5ccb62fcdf58846209eee8a7ea5515238288b91c202347ca42e201ab336c14d83f3f5fd8194070e57b9366bcce2414614d
> > >
> > >
> > > Knows issues:
> > > When building with the sources with JDK-16 and above, the unittest
> > > MavenCliTest#testStyleColors will fail. This will be fix with
> > MNG-7127[1],
> > > but is left out to keep focus on the real purpose of this release.
> > >
> > > Staging site:
> > > https://maven.apache.org/ref/3-LATEST/
> > >
> > > Guide to testing staged releases:
> > >
> https://maven.apache.org/guides/development/guide-testing-releases.html
> > >
> > > Vote open for at least 72 hours.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > >
> > > ---
> > > [1] https://issues.apache.org/jira/browse/MNG-7127
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
> >
>
> --
> Arnaud Héritier
> Twitter/Skype : aheritier
>

Re: [VOTE] Release Apache Maven version 3.8.1

[Arnaud Héritier]

I have a problem on macos that I didn't have with 3.6.3, when I launch
maven it I have this error:

“libjansi.jnilib” cannot be opened because the developer cannot be verified.
macOS cannot verify that this app is free from malware.
Brave downloaded this file today at 09:25.

It's a popup window:
https://www.dropbox.com/s/tj0yp3hzuerm1ll/Screenshot%202021-03-31%20at%2009.29.06.png?dl=0

I manually installed Maven from the zip (in general I use ASDF).

I can use the "Allow Anyway" in "Security & Privacy" settings but then I
have another message:
https://www.dropbox.com/s/icgddpm7zfzvjx8/Screenshot%202021-03-31%20at%2009.37.14.png?dl=0

macOS cannot verify the developer of “libjansi.jnilib”. Are you sure you
want to open it?
By opening this app, you will be overriding system security which can
expose your computer and personal information to malware that may harm your
Mac or compromise your privacy.
Brave downloaded this file today at 09:25.


After this last pop the problem disappears.

Not a problem for me but I don't remember to have done this in the past for
jansi. Did we change anything ?


On Wed, Mar 31, 2021 at 8:46 AM Maarten Mulders 
wrote:

> Retried the test that I did on 3.8.0, this time I observe the desired /
> correct behaviour.
>
>
> +1
>
>
> Maarten
>
>
> On March 31, 2021, at 01:46, Mark Derricutt wrote:
> > +1 non-binding
> >
> > - bistro zips are in the /dev/ tree
> > - my multi-repo osgi maven tiles weirdo build works fine.
> >
> >
> >
> >
> > From: Robert Scholte  
> > Reply: Maven Developers List  <
> dev@maven.apache.org>
> > Date: 31 March 2021 at 9:58:56 AM
> > To: dev@maven.apache.org  
> > Subject:  [VOTE] Release Apache Maven version 3.8.1
> >
> > Hi,
> >
> > For the details about this release, please read
> > https://maven.apache.org/docs/3.8.1/release-notes.html
> > Also please provide feedback on the release notes. (as you know, these
> are
> > published separately from the release, so it doesn't have to block the
> > release itself)
> >
> > We solved 6 issues:
> >
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12350032=Text
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1634/
> >
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.1/binaries/apache-maven-3.8.1-bin.zip
> >
> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.1/source/apache-maven-3.8.1-src.zip
> >
> > Source release checksum(s):
> > apache-maven-3.8.1-bin.zip sha512:
> >
> c585847bfbcf8647aeabfd3e8bf0ac3f67a037bd345545e274766f144c2b978b3457cbc3e31545e62c21ad69e732695de01ec96ea2580e5da67bd85df095c0f4
> >
> > apache-maven-3.8.1-src.zip
> > sha512:
> 893988635349985074c88ce5ef27ac5ccb62fcdf58846209eee8a7ea5515238288b91c202347ca42e201ab336c14d83f3f5fd8194070e57b9366bcce2414614d
> >
> >
> > Knows issues:
> > When building with the sources with JDK-16 and above, the unittest
> > MavenCliTest#testStyleColors will fail. This will be fix with
> MNG-7127[1],
> > but is left out to keep focus on the real purpose of this release.
> >
> > Staging site:
> > https://maven.apache.org/ref/3-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> > ---
> > [1] https://issues.apache.org/jira/browse/MNG-7127
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

-- 
Arnaud Héritier
Twitter/Skype : aheritier

Re: [VOTE] Release Apache Maven version 3.8.1

[Enrico Olivelli]

+1 (non binding)
I have tested the staged binaries againsts a few projects

I have observed these logs, IIUC this is expected.

[INFO] Reading assembly descriptor: assembly.xml
Downloading from maven-default-http-blocker:
http://0.0.0.0/joda-time/joda-time/maven-metadata.xml
[WARNING] Could not transfer metadata
joda-time:joda-time/maven-metadata.xml from/to
maven-default-http-blocker (http://0.0.0.0/): transfer failed for
http://0.0.0.0/joda-time/joda-time/maven-metadata.xml

Enrico


Il giorno mer 31 mar 2021 alle ore 08:46 Maarten Mulders
 ha scritto:
>
> Retried the test that I did on 3.8.0, this time I observe the desired /
> correct behaviour.
>
>
> +1
>
>
> Maarten
>
>
> On March 31, 2021, at 01:46, Mark Derricutt wrote:
> > +1 non-binding
> >
> > - bistro zips are in the /dev/ tree
> > - my multi-repo osgi maven tiles weirdo build works fine.
> >
> >
> >
> >
> > From: Robert Scholte  
> > Reply: Maven Developers List  
> > Date: 31 March 2021 at 9:58:56 AM
> > To: dev@maven.apache.org  
> > Subject:  [VOTE] Release Apache Maven version 3.8.1
> >
> > Hi,
> >
> > For the details about this release, please read
> > https://maven.apache.org/docs/3.8.1/release-notes.html
> > Also please provide feedback on the release notes. (as you know, these are
> > published separately from the release, so it doesn't have to block the
> > release itself)
> >
> > We solved 6 issues:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12350032=Text
> >
> > Staging repo:
> > https://repository.apache.org/content/repositories/maven-1634/
> > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.1/binaries/apache-maven-3.8.1-bin.zip
> > https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.1/source/apache-maven-3.8.1-src.zip
> >
> > Source release checksum(s):
> > apache-maven-3.8.1-bin.zip sha512:
> > c585847bfbcf8647aeabfd3e8bf0ac3f67a037bd345545e274766f144c2b978b3457cbc3e31545e62c21ad69e732695de01ec96ea2580e5da67bd85df095c0f4
> >
> > apache-maven-3.8.1-src.zip
> > sha512: 
> > 893988635349985074c88ce5ef27ac5ccb62fcdf58846209eee8a7ea5515238288b91c202347ca42e201ab336c14d83f3f5fd8194070e57b9366bcce2414614d
> >
> >
> > Knows issues:
> > When building with the sources with JDK-16 and above, the unittest
> > MavenCliTest#testStyleColors will fail. This will be fix with MNG-7127[1],
> > but is left out to keep focus on the real purpose of this release.
> >
> > Staging site:
> > https://maven.apache.org/ref/3-LATEST/
> >
> > Guide to testing staged releases:
> > https://maven.apache.org/guides/development/guide-testing-releases.html
> >
> > Vote open for at least 72 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> > ---
> > [1] https://issues.apache.org/jira/browse/MNG-7127
> >
>
> -
> 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: Why no mvn daemon?

[Romain Manni-Bucau]

Le mer. 31 mars 2021 à 08:17, Hervé BOUTEMY  a
écrit :

> I think mvnd is not so well known [1]: I did never test it, I should
> probably
> do...
>
> and as incremental compilation discussion have started recently, we'll
> need to
> have a global discussion on evaluating and eventually mixing differents
> ways of
> improving build performance
>

+10, mvnd is awesome but solves the JVM pitfalls mainly, incremental
support is per mojo to be optimized and both would be awesome.
Basically optimizing the JVM + the runtime at the same time.


>
> when evaluating, I think we'll need to keep in mind one key aspect: from a
> user perspective, which deployment and usage complexities does every
> solution
> bring for which performance improvement?
>

I think the main one maven should target is the "local" env (this is why
mvnd fits so well) - by opposition of a remote server as gradle enterprise
one which requires some infra, typically maven does not produce nexus byt
stick on local software and I think it is sane to target it primarly.


>
> I feel that each solution that brings more expected performance
> improvement
> comes with at least a deployment complexity, perhaps sometimes use
> complexity
> also (per-project configuration, ...)
>

Hmm, here the only drawback of mvnd is to have the daemon running and
consume the related memory but it is also why you use it so it is almost
free for me - at least in usage. It is not like having to setup a server
and configure the client in maven since launching mvnd instead of mvn you
launch the mvnd client + the daemon if not already running so in terms of
user experience you can alias mvn=mvnd and you will not notice the
difference if you have enough memory.
My typicall pitfall with 16G of ram is to have idea+chrome+minikube
launched and mvd preventing a graalvm build (not enough memory)...but it is
not mainstream too as memory consumption.
Also there is a ticket about improving mvnd daemon auto-monitoring to kill
itself if machine memory is too low and it is not used (
https://github.com/mvndaemon/mvnd/issues/364) so this pitfall can disappear
too.


>
> but currently mvnd is the only free solution publicly available: I should
> definitely test it to better know it when we'll have more in depth
> discussions
> in the future
>
> Please keep posting your factual returns on experience: that's definitely
> useful
>
> Regards,
>
> Hervé
>
> [1] https://github.com/mvndaemon/mvnd
>
> Le mardi 30 mars 2021, 22:32:37 CEST Romain Manni-Bucau a écrit :
> > Le mar. 30 mars 2021 à 22:16, Jochen Wiedmann 
> a
> >
> > écrit :
> > > On Tue, Mar 30, 2021 at 7:58 PM Benjamin Marwell 
> > >
> > > wrote:
> > > > Other than that, I use mvnd at work and we never had problems on any
> > > > project. We consistently save time without the need of adding the -T
> > > > parameter manually. Another big question is probably: is there enough
> > > > community demand to merge it into core?
> > > >
> > > > Tbh, I expected more mails on this thread.
> > >
> > > The question for me: Who's launching this mvnd? I wouldn't want to
> > > have a dedicated server for that. However, if (for example) m2e would
> > > launch it automatically when I open Eclipse, and perform a shutdown,
> > > when Eclipse closes, then I'd be perfectly happy to use it.
> >
> > mvnd. As soon as env changes (you launch it from another project) daemon
> is
> > killed.
> > Indeed you can kill it manually too - which makes it saner than idea
> remote
> > maven server or ide maven server which cant be killed generally and
> consume
> > a lot of mem while ide is on.
> >
> > Indeed you can bind mvnd --stop on eclipse shutdown which would behave as
> > you expect but working on the cli without any ide specific integ is maven
> > scope, not idea integration IMO (even if a few code enable it but guess
> it
> > is legacy now thanks the ioc mvn has).
> >
> > Feel free to give a try to mvnd, works very well everywhere ;).
> >
> > > Jochen
> > >
> > >
> > >
> > > --
> > >
> > > Look, that's why there's rules, understand? So that you think before
> > > you break 'em.
> > >
> > > -- (Terry Pratchett, Thief of Time)
> > >
> > > -
> > > 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 version 3.8.1

[Maarten Mulders]

Retried the test that I did on 3.8.0, this time I observe the desired / 
correct behaviour.



+1


Maarten


On March 31, 2021, at 01:46, Mark Derricutt wrote:

+1 non-binding

- bistro zips are in the /dev/ tree
- my multi-repo osgi maven tiles weirdo build works fine.




From: Robert Scholte  
Reply: Maven Developers List  
Date: 31 March 2021 at 9:58:56 AM
To: dev@maven.apache.org  
Subject:  [VOTE] Release Apache Maven version 3.8.1

Hi,

For the details about this release, please read
https://maven.apache.org/docs/3.8.1/release-notes.html
Also please provide feedback on the release notes. (as you know, these are
published separately from the release, so it doesn't have to block the
release itself)

We solved 6 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12350032=Text

Staging repo:
https://repository.apache.org/content/repositories/maven-1634/
https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.1/binaries/apache-maven-3.8.1-bin.zip
https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.1/source/apache-maven-3.8.1-src.zip

Source release checksum(s):
apache-maven-3.8.1-bin.zip sha512:
c585847bfbcf8647aeabfd3e8bf0ac3f67a037bd345545e274766f144c2b978b3457cbc3e31545e62c21ad69e732695de01ec96ea2580e5da67bd85df095c0f4

apache-maven-3.8.1-src.zip
sha512: 
893988635349985074c88ce5ef27ac5ccb62fcdf58846209eee8a7ea5515238288b91c202347ca42e201ab336c14d83f3f5fd8194070e57b9366bcce2414614d


Knows issues:
When building with the sources with JDK-16 and above, the unittest
MavenCliTest#testStyleColors will fail. This will be fix with MNG-7127[1],
but is left out to keep focus on the real purpose of this release.

Staging site:
https://maven.apache.org/ref/3-LATEST/

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

Vote open for at least 72 hours.

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


---
[1] https://issues.apache.org/jira/browse/MNG-7127



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

[GitHub] [maven-site] hboutemy commented on pull request #231: Maven 3.3.4

[GitBox]

hboutemy commented on pull request #231:
URL: https://github.com/apache/maven-site/pull/231#issuecomment-810805280


   I suppose this PR was opened by mistake?


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

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] Next release version: 3.6.4, 3.7.0, 3.8.0 or other

[Hervé BOUTEMY]

I don't get the reasoning:
what content do you expect in such a Maven 3.6.4 release compared to 3.8.1? 
for what benefit?

Le mardi 30 mars 2021, 20:16:23 CEST Romain Manni-Bucau a écrit :
> Le mar. 30 mars 2021 à 19:36, Robert Scholte  a
> 
> écrit :
> > I'm preparing the 3.8.1 release
> > So far I see no reason to backport some changes to a possible 3.6.4.
> 
> ...provide a fixed version to at least our most recent+used version to
> enable company policies to be respected with the security fix and avoid a
> ton of forks/custom backports (users/community first).
> I'm fine doing the release (at least the steps I can) but I would be very
> disappointed maven is not able to give any versioning guarantee at all - or
> we need to revise our versioning since for now there is no possible
> anticipation for projects which is an issue for me.
> 
> > Only in case we get enough requests from the community to do so, we might
> > consider creating a partial backport.
> > 
> > thanks,
> > Robert
> > On 30-3-2021 18:53:17, Romain Manni-Bucau  wrote:
> > Ok so seems 3.8.1 gets a lot of votes.
> > Can we still do a 3.6.4/3.6.3.1 or whatever (3.6 branch is the important
> > point as explained).
> > 
> > Romain Manni-Bucau
> > @rmannibucau | Blog
> > 
> > | Old Blog
> > | Github |
> > 
> > LinkedIn | Book
> > 
> > 
> > 
> > Le mar. 30 mars 2021 à 18:50, Arnaud Héritier a
> > 
> > écrit :
> > > Due to the distribution error, I agree that the next release can only be
> > > 3.8.1 today
> > > 
> > > On Tue, Mar 30, 2021 at 6:39 PM TheCakeIsNaOH
> > > 
> > > wrote:
> > > > Hi,
> > > > 
> > > > I am the maintainer of the Maven Chocolatey package.
> > > > 
> > > > Given that I uploaded a 3.8.0 package after seeing the binaries in the
> > > > release
> > > > download area, there are around ~2,400 users which downloaded that
> > > 
> > > version
> > > 
> > > > of the package.
> > > > 
> > > > Therefore, on the Chocolatey side of things, it would be best if the
> > 
> > next
> > 
> > > > version
> > > > is something greater than 3.8.0. That way, the people that downloaded
> > 
> > the
> > 
> > > > 3.8.0 package would upgrade to the actual release, instead of having
> > > > to
> > > > downgrade manually.
> > > > 
> > > > Regards, TheCakeIsNaOH
> > > > 
> > > > On 2021/03/28 09:47:11, Romain Manni-Bucau wrote:
> > > > > Hi all,>
> > > > > 
> > > > > Before we reroll the failed 3.8.0 I'd like we discuss openly the
> > 
> > next>
> > 
> > > > > versioning since it seems we didn't reach a consensus yet and trying
> > 
> > to
> > 
> > > > not>
> > > > 
> > > > > create too much friction for users and in the community.>
> > > > > 
> > > > > As a reminder the only feature the release will get is to prevent
> > 
> > HTTP
> > 
> > > > repo>
> > > > 
> > > > > (in favor of HTTPS ones). In that regard it is a breaking change if
> > > > 
> > > > users>
> > > > 
> > > > > rely on HTTP repo but a security fix (I don't come back on the HTTP
> > 
> > ->>
> > 
> > > > > HTTPS move IT ecosystem got recently here).>
> > > > > 
> > > > > So it seems there are multiple versioning options:>
> > > > > 
> > > > > 1. 3.6.4: seems natural since it is a security fix, enables
> > > > > companies
> > > 
> > > to>
> > > 
> > > > > get this fix respecting a project versioning policy without having
> > 
> > to>
> > 
> > > > > upgrade and avoids us to have to maintain 3.6 + 3.7/3.8 and soon
> > 
> > 4.x.>
> > 
> > > > > Indeed it requires a very well documented paragraph about this
> > > > > change
> > > > 
> > > > and>
> > > > 
> > > > > how to workaround it (local proxy/mirror is a trivial one for
> > 
> > example)
> > 
> > > > but>
> > > > 
> > > > > it will be the case whatever version we pick anyway IMHO.>
> > > > > 2. 3.7.0: since it is a breaking change it can seem natural too (but
> > > 
> > > has>
> > > 
> > > > > the pitfall to likely require a backport in 3.6 anyway, due to the>
> > > > > versioning policies which can prevent some users to upgrade to a
> > 
> > 3.7)>
> > 
> > > > > 3. 3.8.0: was the vote, seems the rational was that originally we>
> > > > > targetting mvnw in 3.7 and since we didn't make it 3.8 was used.
> > > > > Have
> > > 
> > > to>
> > > 
> > > > > admit I'm not sure of this reasoning more than that (cause for me if
> > > 
> > > we>
> > > 
> > > > > don't have a planned feature we can either try to push/wait for it
> > 
> > or>
> > 
> > > > > postpone it but not skip a version due to that) so if anyone wants
> > 
> > to>
> > 
> > > > > complete the reasoning here it would be great.>
> > > > > 
> > > > > Indeed my preference is for 3.6.4 which has the most advantages for>
> > > > > everyone and no additional drawbacks compared to 3.7 or 3.8 options
> > > > 
> > > > until>
> > > > 
> > > > > we try to push to get mvnw in which would mean 3.7 becomes more
> > > 
> > > natural>
> > > 
> > > > > (and likely imply a 3.6.x maintenance version).>
> > > > > 
> > > > > Goal of this thread is to feel the overall trend and see if we can
> > > > 

Re: Why no mvn daemon?

[Hervé BOUTEMY]

I think mvnd is not so well known [1]: I did never test it, I should probably 
do...

and as incremental compilation discussion have started recently, we'll need to 
have a global discussion on evaluating and eventually mixing differents ways of 
improving build performance

when evaluating, I think we'll need to keep in mind one key aspect: from a 
user perspective, which deployment and usage complexities does every solution 
bring for which performance improvement?

I feel that each solution that brings more expected performance improvement 
comes with at least a deployment complexity, perhaps sometimes use complexity 
also (per-project configuration, ...)

but currently mvnd is the only free solution publicly available: I should 
definitely test it to better know it when we'll have more in depth discussions 
in the future

Please keep posting your factual returns on experience: that's definitely 
useful

Regards,

Hervé

[1] https://github.com/mvndaemon/mvnd

Le mardi 30 mars 2021, 22:32:37 CEST Romain Manni-Bucau a écrit :
> Le mar. 30 mars 2021 à 22:16, Jochen Wiedmann  a
> 
> écrit :
> > On Tue, Mar 30, 2021 at 7:58 PM Benjamin Marwell 
> > 
> > wrote:
> > > Other than that, I use mvnd at work and we never had problems on any
> > > project. We consistently save time without the need of adding the -T
> > > parameter manually. Another big question is probably: is there enough
> > > community demand to merge it into core?
> > > 
> > > Tbh, I expected more mails on this thread.
> > 
> > The question for me: Who's launching this mvnd? I wouldn't want to
> > have a dedicated server for that. However, if (for example) m2e would
> > launch it automatically when I open Eclipse, and perform a shutdown,
> > when Eclipse closes, then I'd be perfectly happy to use it.
> 
> mvnd. As soon as env changes (you launch it from another project) daemon is
> killed.
> Indeed you can kill it manually too - which makes it saner than idea remote
> maven server or ide maven server which cant be killed generally and consume
> a lot of mem while ide is on.
> 
> Indeed you can bind mvnd --stop on eclipse shutdown which would behave as
> you expect but working on the cli without any ide specific integ is maven
> scope, not idea integration IMO (even if a few code enable it but guess it
> is legacy now thanks the ioc mvn has).
> 
> Feel free to give a try to mvnd, works very well everywhere ;).
> 
> > Jochen
> > 
> > 
> > 
> > --
> > 
> > Look, that's why there's rules, understand? So that you think before
> > you break 'em.
> > 
> > -- (Terry Pratchett, Thief of Time)
> > 
> > -
> > 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