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 <herve.bout...@free.fr> 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 <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-I > > > > > > > > Ts > > > > > > > > /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 > > > > > > --------------------------------------------------------------------- > > > 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 > > > > -- > Sent from my phone --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org