Good description, Hervé. One small addition. I believe -Pembedded
enables "auto" mode, where verifier uses "forked" mode for tests that
set environment variables and "embedded" mode for all other cases.
Individual ITs can still force forked mode with verifier.setForkJvm, of
course.

-- 
Regards,
Igor

On Sat, Mar 25, 2017, at 01:02 AM, Hervé BOUTEMY wrote:
> 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-suite/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 <hbout...@apache.org> 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-ITs/3/
> > > > 
> > > > 
> > > > 
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > > > For additional commands, e-mail: dev-h...@maven.apache.org
> > > > 
> > > > --
> > > 
> > > Sent from my phone
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 

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

Reply via email to