[GitHub] maven issue #110: plexus

[ifedorenko]

Github user ifedorenko commented on the issue:

https://github.com/apache/maven/pull/110
  
spam?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

[GitHub] maven pull request #110: plexus

[devopsharish]

GitHub user devopsharish opened a pull request:

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

plexus



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/devopsharish/maven master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven/pull/110.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #110


commit c057d9c6b252f228d506415b41a59538ca5358cd
Author: US\vebalusu 
Date:   2017-03-28T22:11:46Z

plexus




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

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

Re: What to do with the 6 issues left as 3.5.0-candidates?

[Stephen Connolly]

Looked fine to me when I found it just after writing my version!

Merge away!

On Tue 28 Mar 2017 at 20:31, Robert Scholte  wrote:

> I've created a branch for MNG-6185, ready to be merged.
>
> Robert
>
> On Fri, 24 Mar 2017 11:45:14 +0100, Stephen Connolly
>  wrote:
>
> >
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.5.0-candidate%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> >
> > Here is my opinions:
> >
> > https://issues.apache.org/jira/browse/MNG-6167 - it's too late now. punt
> > to
> > 3.5.1
> >
> > https://issues.apache.org/jira/browse/MNG-6168 - If this is available
> and
> > ready quickly (i.e. in the next week), we can review the changes and
> > assess
> > the risk
> >
> > https://issues.apache.org/jira/browse/MNG-6186 - looks like not merged
> > and
> > released upstream yet... punt to 3.5.1
> >
> > https://issues.apache.org/jira/browse/MNG-6188 - it's too late now. punt
> > to
> > 3.5.1 (anyway I see similar issues with other native tooling that uses
> > console colouring)
> >
> > https://issues.apache.org/jira/browse/MNG-6169 - definitely too late.
> > punt
> > to 3.5.1
> >
> > https://issues.apache.org/jira/browse/MNG-6185 - sounds like only a
> > javadoc
> > change. If available quickly should be ok
> >
> > If there is agreement then I will move MNG-6185 and MNG-6168 into fix for
> > 3.5.0 and the rest to 3.5.1-candidates
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: What to do with the 6 issues left as 3.5.0-candidates?

[Robert Scholte]

I've created a branch for MNG-6185, ready to be merged.

Robert

On Fri, 24 Mar 2017 11:45:14 +0100, Stephen Connolly  
 wrote:



https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20fixVersion%20%3D%203.5.0-candidate%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC

Here is my opinions:

https://issues.apache.org/jira/browse/MNG-6167 - it's too late now. punt  
to

3.5.1

https://issues.apache.org/jira/browse/MNG-6168 - If this is available and
ready quickly (i.e. in the next week), we can review the changes and  
assess

the risk

https://issues.apache.org/jira/browse/MNG-6186 - looks like not merged  
and

released upstream yet... punt to 3.5.1

https://issues.apache.org/jira/browse/MNG-6188 - it's too late now. punt  
to

3.5.1 (anyway I see similar issues with other native tooling that uses
console colouring)

https://issues.apache.org/jira/browse/MNG-6169 - definitely too late.  
punt

to 3.5.1

https://issues.apache.org/jira/browse/MNG-6185 - sounds like only a  
javadoc

change. If available quickly should be ok

If there is agreement then I will move MNG-6185 and MNG-6168 into fix for
3.5.0 and the rest to 3.5.1-candidates


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

Re: Review request

[Michael Osipov]

Am 2017-03-27 um 19:58 schrieb Stephen Connolly:

My mng-6195 branch is passing all ITs

https://builds.apache.org/view/Maven/job/maven-3.x-jenkinsfile/job/mng-6195/

Can somebody test it on FreeBSD (check that .mvn folder is resolved
correctly when using -f to specify a path outside the current directory)


Passes all ITs on
FreeBSD bsd10.local 10.3-RELEASE-p11 FreeBSD 10.3-RELEASE-p11 #0: Mon 
Oct 24 18:49:24 UTC 2016 
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64


with
openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-b13)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)


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

Re: Review request

[Stephen Connolly]

Thanks. My analysis was correct on the Windows mvn.cmd then ;-)

On Tue 28 Mar 2017 at 19:09, Robert Scholte  wrote:

> Just to confirm: on Windows in all three cases the tests are skipped when
> following the steps to reproduce MNG-6198
>
> Robert
>
> On Mon, 27 Mar 2017 22:08:06 +0200, Stephen Connolly
>  wrote:
>
> > Found another issue with the shell script: MNG-6198 (would be good if
> > somebody with windows could confirm that `mvn.cmd` is not affected by the
> > bug I have identified in `mvn`)
> >
> > On 27 March 2017 at 18:58, Stephen Connolly
> >  >> wrote:
> >
> >> My mng-6195 branch is passing all ITs
> >>
> >> https://builds.apache.org/view/Maven/job/maven-3.x-
> >> jenkinsfile/job/mng-6195/
> >>
> >> Can somebody test it on FreeBSD (check that .mvn folder is resolved
> >> correctly when using -f to specify a path outside the current directory)
> >>
> >> Can somebody test on Solaris 10 (same test)
> >>
> >> I'll double check on macOS (same test)
> >>
> >> Other test data points welcome
> >> --
> >> Sent from my phone
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
> --
Sent from my phone

Re: Review request

[Robert Scholte]

Just to confirm: on Windows in all three cases the tests are skipped when  
following the steps to reproduce MNG-6198


Robert

On Mon, 27 Mar 2017 22:08:06 +0200, Stephen Connolly  
 wrote:



Found another issue with the shell script: MNG-6198 (would be good if
somebody with windows could confirm that `mvn.cmd` is not affected by the
bug I have identified in `mvn`)

On 27 March 2017 at 18:58, Stephen Connolly  

Re: maven-3.x-jenkinsfile/embedded-ITs - build #3 - UNSTABLE

[Stephen Connolly]

On 28 March 2017 at 11:56, Igor Fedorenko  wrote:

> Good point!
>
> .mvn/maven.config is handled by MavenCli and should not require forked
> execution.
>
> .mvn/jvm.config is handled by mvn shell script and does require forked
> execution. Verifier "auto" mode does not currently consider presence of
> .mvn/jvm.config, so we'll either need fix Verifier or force "forked"
> mode from the affected tests.
>

And as I have found some bugs in how the mvn scripts handle jvm.config we
need to have those tests forked when there is a jvm.config file


>
> --
> Regards,
> Igor
>
> On Tue, Mar 28, 2017, at 03:51 AM, Stephen Connolly wrote:
> > Does it force a fork if there is a .mvn/maven.config file to be picked
> > up?
> >
> > On Tue 28 Mar 2017 at 07:07, Hervé BOUTEMY 
> wrote:
> >
> > > ok, no issue found, then embedded mode merged to master
> > >
> > > later switching back to non-embedded is easy if necessary
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le samedi 25 mars 2017, 17:32:38 CEST Hervé BOUTEMY a écrit :
> > > > thanks for the complements
> > > > FTR, I checked and added pointers to code
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > Le samedi 25 mars 2017, 07:38:30 CET Igor Fedorenko a écrit :
> > > > > Good description, Hervé. One small addition. I believe -Pembedded
> > > > > enables "auto" mode,
> > > >
> > > >
> > > https://github.com/apache/maven-integration-testing/
> blob/master/core-it-suit
> > > > e/ pom.xml#L322
> > > >
> > > > > where verifier uses "forked" mode for tests that
> > > > > set environment variables and "embedded" mode for all other cases.
> > > >
> > > >
> > > https://github.com/apache/maven-shared/blob/trunk/maven-
> verifier/src/main/ja
> > > > va/ org/apache/maven/it/Verifier.java#L1381
> > > >
> > > > > Individual ITs can still force forked mode with
> verifier.setForkJvm, of
> > > > > course.
> > > > >
> > > > > > ok, let's share what I know from embedded ITs (sorry, long
> email, but
> > > > > > IMHO
> > > > > > useful to share some details):
> > > > > >
> > > > > > - by default, Verifier forks for every IT and launches Maven
> with the
> > > > > > shell
> > > > > > script through ForkedLauncher [1]
> > > > > >
> > > > > > - in embedded mode, there is no fork but use of
> > > MavenCli.doMain(String[]
> > > > > > args,
> > > > > > workingDir, stdin, stdout) by Embedded3xLauncher [2], which will
> > > > > > recreate
> > > > > > a
> > > > > > Classworlds classloader context in the current JVM: AFAIK, this
> makes
> > > > > > the
> > > > > > embedded situation really the same as forked one from a
> classloader
> > > > > > point
> > > > > > of
> > > > > > view, with CLI args passed, working dir, stdin and stdout
> > > > > >
> > > > > > - a few ITs require shell script and don't have any meaning
> without
> > > it:
> > > > > > in
> > > > > > this case, even if the build is in embedded mode, the IT forces
> the
> > > > > > Verifier to
> > > > > > used forked execution, for example in mng5889 [3]
> > > > > >
> > > > > > - every IT that we want absolutely not to be embedded has to do
> this
> > > > > > "verifier.setForkJvm( true );" call, or the IT won't be in
> expected
> > > > > > situation:
> > > > > > as you point out, mng4625 currently does not do this call, then
> may
> > > not
> > > > > > be
> > > > > > really effective with the embedded profile. This can be
> considered
> > > as a
> > > > > > bug and
> > > > > > explains why currently this IT fails in my "embedded-ITs" branch
> =>
> > > I'll
> > > > > > improve now the IT to support the embedded profile by forcing
> forked
> > > > > > execution
> > > > > >
> > > > > > :)
> > > > > >
> > > > > > Now that I wrote this, summarizing what I knew and what was
> already
> > > > > > reported
> > > > > > as issues, it looks to me that embedded mode may trigger a few
> > > failures
> > > > > > that
> > > > > > can and should be fixed by forcing forked execution (which won't
> > > change
> > > > > > the
> > > > > > overall effect: most ITs will run embedded then execution time
> will
> > > be a
> > > > > > lot
> > > > > > lower than full forked execution)
> > > > > >
> > > > > > the only risk is that some ITs don't fail when run in embedded
> mode
> > > but
> > > > > > in
> > > > > > fact don't really test what they are supposed to test
> > > > > >
> > > > > > This seems a reasonable risk to take here, given the benefit:
> we'll
> > > > > > improve ITs
> > > > > > if necessary.
> > > > > > If nobody objects, I'll do the merge to master in a few days
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Hervé
> > > > > >
> > > > > > [1]
> > > > > >
> > > http://maven.apache.org/shared/maven-verifier/xref/
> org/apache/maven/it/
> > > > > > ForkedLauncher.html#L60
> > > > > >
> > > > > > [2]
> > > > > >
> > > http://maven.apache.org/ref/3.5.0-beta-1/maven-embedder/
> xref/org/apache/
> > > > > > maven/cli/MavenCli.html#L262
> > > > > >
> > > > > > [3]
> > > > > >
> > 

Re: maven-3.x-jenkinsfile/embedded-ITs - build #3 - UNSTABLE

[Igor Fedorenko]

Good point!

.mvn/maven.config is handled by MavenCli and should not require forked
execution.

.mvn/jvm.config is handled by mvn shell script and does require forked
execution. Verifier "auto" mode does not currently consider presence of
.mvn/jvm.config, so we'll either need fix Verifier or force "forked"
mode from the affected tests.

-- 
Regards,
Igor

On Tue, Mar 28, 2017, at 03:51 AM, Stephen Connolly wrote:
> Does it force a fork if there is a .mvn/maven.config file to be picked
> up?
> 
> On Tue 28 Mar 2017 at 07:07, Hervé BOUTEMY  wrote:
> 
> > ok, no issue found, then embedded mode merged to master
> >
> > later switching back to non-embedded is easy if necessary
> >
> > Regards,
> >
> > Hervé
> >
> > Le samedi 25 mars 2017, 17:32:38 CEST Hervé BOUTEMY a écrit :
> > > thanks for the complements
> > > FTR, I checked and added pointers to code
> > >
> > > Regards,
> > >
> > > Hervé
> > >
> > > Le samedi 25 mars 2017, 07:38:30 CET Igor Fedorenko a écrit :
> > > > Good description, Hervé. One small addition. I believe -Pembedded
> > > > enables "auto" mode,
> > >
> > >
> > https://github.com/apache/maven-integration-testing/blob/master/core-it-suit
> > > e/ pom.xml#L322
> > >
> > > > where verifier uses "forked" mode for tests that
> > > > set environment variables and "embedded" mode for all other cases.
> > >
> > >
> > https://github.com/apache/maven-shared/blob/trunk/maven-verifier/src/main/ja
> > > va/ org/apache/maven/it/Verifier.java#L1381
> > >
> > > > Individual ITs can still force forked mode with verifier.setForkJvm, of
> > > > course.
> > > >
> > > > > ok, let's share what I know from embedded ITs (sorry, long email, but
> > > > > IMHO
> > > > > useful to share some details):
> > > > >
> > > > > - by default, Verifier forks for every IT and launches Maven with the
> > > > > shell
> > > > > script through ForkedLauncher [1]
> > > > >
> > > > > - in embedded mode, there is no fork but use of
> > MavenCli.doMain(String[]
> > > > > args,
> > > > > workingDir, stdin, stdout) by Embedded3xLauncher [2], which will
> > > > > recreate
> > > > > a
> > > > > Classworlds classloader context in the current JVM: AFAIK, this makes
> > > > > the
> > > > > embedded situation really the same as forked one from a classloader
> > > > > point
> > > > > of
> > > > > view, with CLI args passed, working dir, stdin and stdout
> > > > >
> > > > > - a few ITs require shell script and don't have any meaning without
> > it:
> > > > > in
> > > > > this case, even if the build is in embedded mode, the IT forces the
> > > > > Verifier to
> > > > > used forked execution, for example in mng5889 [3]
> > > > >
> > > > > - every IT that we want absolutely not to be embedded has to do this
> > > > > "verifier.setForkJvm( true );" call, or the IT won't be in expected
> > > > > situation:
> > > > > as you point out, mng4625 currently does not do this call, then may
> > not
> > > > > be
> > > > > really effective with the embedded profile. This can be considered
> > as a
> > > > > bug and
> > > > > explains why currently this IT fails in my "embedded-ITs" branch =>
> > I'll
> > > > > improve now the IT to support the embedded profile by forcing forked
> > > > > execution
> > > > >
> > > > > :)
> > > > >
> > > > > Now that I wrote this, summarizing what I knew and what was already
> > > > > reported
> > > > > as issues, it looks to me that embedded mode may trigger a few
> > failures
> > > > > that
> > > > > can and should be fixed by forcing forked execution (which won't
> > change
> > > > > the
> > > > > overall effect: most ITs will run embedded then execution time will
> > be a
> > > > > lot
> > > > > lower than full forked execution)
> > > > >
> > > > > the only risk is that some ITs don't fail when run in embedded mode
> > but
> > > > > in
> > > > > fact don't really test what they are supposed to test
> > > > >
> > > > > This seems a reasonable risk to take here, given the benefit: we'll
> > > > > improve ITs
> > > > > if necessary.
> > > > > If nobody objects, I'll do the merge to master in a few days
> > > > >
> > > > > Regards,
> > > > >
> > > > > Hervé
> > > > >
> > > > > [1]
> > > > >
> > http://maven.apache.org/shared/maven-verifier/xref/org/apache/maven/it/
> > > > > ForkedLauncher.html#L60
> > > > >
> > > > > [2]
> > > > >
> > http://maven.apache.org/ref/3.5.0-beta-1/maven-embedder/xref/org/apache/
> > > > > maven/cli/MavenCli.html#L262
> > > > >
> > > > > [3]
> > > > >
> > https://github.com/apache/maven-integration-testing/blob/master/core-it->
> > > > su
> > > > > ite/src/test/java/org/apache/maven/it/
> > > > > MavenITmng5889CoreExtensionsTest.java#L57
> > > > >
> > > > > Le vendredi 24 mars 2017, 21:29:38 CET Olivier Lamy a écrit :
> > > > > > sure tempting :-)
> > > > > > But is is the same classloader mechanism as a "normal" Maven run?
> > > > > > (should
> > > > > > be really close but not sure exactly so maybe we can miss some
> > cases)
> > > > > >
> > > > > > On Fri, 24 Mar 2017 at 

Re: maven-3.x-jenkinsfile/embedded-ITs - build #3 - UNSTABLE

[Stephen Connolly]

Does it force a fork if there is a .mvn/maven.config file to be picked up?

On Tue 28 Mar 2017 at 07:07, Hervé BOUTEMY  wrote:

> ok, no issue found, then embedded mode merged to master
>
> later switching back to non-embedded is easy if necessary
>
> Regards,
>
> Hervé
>
> Le samedi 25 mars 2017, 17:32:38 CEST Hervé BOUTEMY a écrit :
> > thanks for the complements
> > FTR, I checked and added pointers to code
> >
> > Regards,
> >
> > Hervé
> >
> > Le samedi 25 mars 2017, 07:38:30 CET Igor Fedorenko a écrit :
> > > Good description, Hervé. One small addition. I believe -Pembedded
> > > enables "auto" mode,
> >
> >
> https://github.com/apache/maven-integration-testing/blob/master/core-it-suit
> > e/ pom.xml#L322
> >
> > > where verifier uses "forked" mode for tests that
> > > set environment variables and "embedded" mode for all other cases.
> >
> >
> https://github.com/apache/maven-shared/blob/trunk/maven-verifier/src/main/ja
> > va/ org/apache/maven/it/Verifier.java#L1381
> >
> > > Individual ITs can still force forked mode with verifier.setForkJvm, of
> > > course.
> > >
> > > > ok, let's share what I know from embedded ITs (sorry, long email, but
> > > > IMHO
> > > > useful to share some details):
> > > >
> > > > - by default, Verifier forks for every IT and launches Maven with the
> > > > shell
> > > > script through ForkedLauncher [1]
> > > >
> > > > - in embedded mode, there is no fork but use of
> MavenCli.doMain(String[]
> > > > args,
> > > > workingDir, stdin, stdout) by Embedded3xLauncher [2], which will
> > > > recreate
> > > > a
> > > > Classworlds classloader context in the current JVM: AFAIK, this makes
> > > > the
> > > > embedded situation really the same as forked one from a classloader
> > > > point
> > > > of
> > > > view, with CLI args passed, working dir, stdin and stdout
> > > >
> > > > - a few ITs require shell script and don't have any meaning without
> it:
> > > > in
> > > > this case, even if the build is in embedded mode, the IT forces the
> > > > Verifier to
> > > > used forked execution, for example in mng5889 [3]
> > > >
> > > > - every IT that we want absolutely not to be embedded has to do this
> > > > "verifier.setForkJvm( true );" call, or the IT won't be in expected
> > > > situation:
> > > > as you point out, mng4625 currently does not do this call, then may
> not
> > > > be
> > > > really effective with the embedded profile. This can be considered
> as a
> > > > bug and
> > > > explains why currently this IT fails in my "embedded-ITs" branch =>
> I'll
> > > > improve now the IT to support the embedded profile by forcing forked
> > > > execution
> > > >
> > > > :)
> > > >
> > > > Now that I wrote this, summarizing what I knew and what was already
> > > > reported
> > > > as issues, it looks to me that embedded mode may trigger a few
> failures
> > > > that
> > > > can and should be fixed by forcing forked execution (which won't
> change
> > > > the
> > > > overall effect: most ITs will run embedded then execution time will
> be a
> > > > lot
> > > > lower than full forked execution)
> > > >
> > > > the only risk is that some ITs don't fail when run in embedded mode
> but
> > > > in
> > > > fact don't really test what they are supposed to test
> > > >
> > > > This seems a reasonable risk to take here, given the benefit: we'll
> > > > improve ITs
> > > > if necessary.
> > > > If nobody objects, I'll do the merge to master in a few days
> > > >
> > > > Regards,
> > > >
> > > > Hervé
> > > >
> > > > [1]
> > > >
> http://maven.apache.org/shared/maven-verifier/xref/org/apache/maven/it/
> > > > ForkedLauncher.html#L60
> > > >
> > > > [2]
> > > >
> http://maven.apache.org/ref/3.5.0-beta-1/maven-embedder/xref/org/apache/
> > > > maven/cli/MavenCli.html#L262
> > > >
> > > > [3]
> > > >
> https://github.com/apache/maven-integration-testing/blob/master/core-it->
> > > su
> > > > ite/src/test/java/org/apache/maven/it/
> > > > MavenITmng5889CoreExtensionsTest.java#L57
> > > >
> > > > Le vendredi 24 mars 2017, 21:29:38 CET Olivier Lamy a écrit :
> > > > > sure tempting :-)
> > > > > But is is the same classloader mechanism as a "normal" Maven run?
> > > > > (should
> > > > > be really close but not sure exactly so maybe we can miss some
> cases)
> > > > >
> > > > > On Fri, 24 Mar 2017 at 6:47 pm, Stephen Connolly <
> > > > >
> > > > > stephen.alan.conno...@gmail.com> wrote:
> > > > > > Have we some of the tests running in both modes?
> > > > > >
> > > > > > Specifically at least 4625 as it caught some interesting CLI
> parsing
> > > > > > issues, but there may be a couple more
> > > > > >
> > > > > > On Fri 24 Mar 2017 at 07:15, Hervé Boutemy 
> >
> > wrote:
> > > > > > > as you can see, in embedded mode, core ITs can run in 17
> minutes,
> > > > > > > when
> > > > > > > in
> > > > > > > classic mode they run in 1h30
> > > > > > >
> > > > > > > any objection to merge this embedded mode into master?
> > > > > > >
> > > > > > > Regards,
> > > 

Re: maven-3.x-jenkinsfile/embedded-ITs - build #3 - UNSTABLE

[Hervé BOUTEMY]

ok, no issue found, then embedded mode merged to master

later switching back to non-embedded is easy if necessary

Regards,

Hervé

Le samedi 25 mars 2017, 17:32:38 CEST Hervé BOUTEMY a écrit :
> thanks for the complements
> FTR, I checked and added pointers to code
> 
> Regards,
> 
> Hervé
> 
> Le samedi 25 mars 2017, 07:38:30 CET Igor Fedorenko a écrit :
> > Good description, Hervé. One small addition. I believe -Pembedded
> > enables "auto" mode,
> 
> https://github.com/apache/maven-integration-testing/blob/master/core-it-suit
> e/ pom.xml#L322
> 
> > where verifier uses "forked" mode for tests that
> > set environment variables and "embedded" mode for all other cases.
> 
> https://github.com/apache/maven-shared/blob/trunk/maven-verifier/src/main/ja
> va/ org/apache/maven/it/Verifier.java#L1381
> 
> > Individual ITs can still force forked mode with verifier.setForkJvm, of
> > course.
> > 
> > > ok, let's share what I know from embedded ITs (sorry, long email, but
> > > IMHO
> > > useful to share some details):
> > > 
> > > - by default, Verifier forks for every IT and launches Maven with the
> > > shell
> > > script through ForkedLauncher [1]
> > > 
> > > - in embedded mode, there is no fork but use of MavenCli.doMain(String[]
> > > args,
> > > workingDir, stdin, stdout) by Embedded3xLauncher [2], which will
> > > recreate
> > > a
> > > Classworlds classloader context in the current JVM: AFAIK, this makes
> > > the
> > > embedded situation really the same as forked one from a classloader
> > > point
> > > of
> > > view, with CLI args passed, working dir, stdin and stdout
> > > 
> > > - a few ITs require shell script and don't have any meaning without it:
> > > in
> > > this case, even if the build is in embedded mode, the IT forces the
> > > Verifier to
> > > used forked execution, for example in mng5889 [3]
> > > 
> > > - every IT that we want absolutely not to be embedded has to do this
> > > "verifier.setForkJvm( true );" call, or the IT won't be in expected
> > > situation:
> > > as you point out, mng4625 currently does not do this call, then may not
> > > be
> > > really effective with the embedded profile. This can be considered as a
> > > bug and
> > > explains why currently this IT fails in my "embedded-ITs" branch => I'll
> > > improve now the IT to support the embedded profile by forcing forked
> > > execution
> > > 
> > > :)
> > > 
> > > Now that I wrote this, summarizing what I knew and what was already
> > > reported
> > > as issues, it looks to me that embedded mode may trigger a few failures
> > > that
> > > can and should be fixed by forcing forked execution (which won't change
> > > the
> > > overall effect: most ITs will run embedded then execution time will be a
> > > lot
> > > lower than full forked execution)
> > > 
> > > the only risk is that some ITs don't fail when run in embedded mode but
> > > in
> > > fact don't really test what they are supposed to test
> > > 
> > > This seems a reasonable risk to take here, given the benefit: we'll
> > > improve ITs
> > > if necessary.
> > > If nobody objects, I'll do the merge to master in a few days
> > > 
> > > Regards,
> > > 
> > > Hervé
> > > 
> > > [1]
> > > http://maven.apache.org/shared/maven-verifier/xref/org/apache/maven/it/
> > > ForkedLauncher.html#L60
> > > 
> > > [2]
> > > http://maven.apache.org/ref/3.5.0-beta-1/maven-embedder/xref/org/apache/
> > > maven/cli/MavenCli.html#L262
> > > 
> > > [3]
> > > https://github.com/apache/maven-integration-testing/blob/master/core-it-> 
> > > > > su
> > > ite/src/test/java/org/apache/maven/it/
> > > MavenITmng5889CoreExtensionsTest.java#L57
> > > 
> > > Le vendredi 24 mars 2017, 21:29:38 CET Olivier Lamy a écrit :
> > > > sure tempting :-)
> > > > But is is the same classloader mechanism as a "normal" Maven run?
> > > > (should
> > > > be really close but not sure exactly so maybe we can miss some cases)
> > > > 
> > > > On Fri, 24 Mar 2017 at 6:47 pm, Stephen Connolly <
> > > > 
> > > > stephen.alan.conno...@gmail.com> wrote:
> > > > > Have we some of the tests running in both modes?
> > > > > 
> > > > > Specifically at least 4625 as it caught some interesting CLI parsing
> > > > > issues, but there may be a couple more
> > > > > 
> > > > > On Fri 24 Mar 2017 at 07:15, Hervé Boutemy 
> 
> wrote:
> > > > > > as you can see, in embedded mode, core ITs can run in 17 minutes,
> > > > > > when
> > > > > > in
> > > > > > classic mode they run in 1h30
> > > > > > 
> > > > > > any objection to merge this embedded mode into master?
> > > > > > 
> > > > > > Regards,
> > > > > > 
> > > > > > Hervé
> > > > > > 
> > > > > > Le vendredi 24 mars 2017 04:17:49 CET, vous avez écrit :
> > > > > > > See
> > > > > > 
> > > > > > https://builds.apache.org/job/maven-3.x-jenkinsfile/job/embedded-I
> > > > > > Ts
> > > > > > /3/
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > --
> > > > > > --
> > > > > > -
> > > > > > To