Am 2022-03-19 um 15:17 schrieb Slawomir Jaranowski:
Hi
We have three projects:
- maven-verifier
- maven-invoker
- maven-invoker-plugin
They are similar ... current situation
maven-verifier
- can execute Maven in forked and embedded mode
- have assertions to verify executing result
- simply Maven configuration by api
- use own implementation for Maven executing
maven-invoker
- can execute Maven only in fork mode
- only status code of executed Maven is reported
- many method for configure almost all Maven cli options by api
maven-invoker-plugin
- discover Maven projects to execute
- possibility to execute verification by groovy or bsh scripts
- possibility to execute Maven project in parallel
- use maven-invoker for executing Maven
So we see that some of the code is duplicated by maven-verifier and
maven-invoker.
Proposition:
- implements embedded mode in maven-invoker - maven-invoker-plugin can
consume it for speed up test executing
- use maven-invoker in maven-verifier - we can remove duplicated code by
projects
Short term plan:
- release maven-invoker 3.2.0 - there are many improvements [1]
- finish and release maven-invoker-plugin 3.3.0 [2]
Long term plan:
- add embedded mode for maven-invoker
- possibility to use embedded mode in maven-invoker-plugin
- refactor maven-invoker .... for many dedicated cli options ... it can
break compatibility
- use maven-invoker in maven-verifier - after 1.8 can be used in verifier
... Maven Core its
- refactor maven-verifier, add more verification method, remove dependency
to JUnit4 - can break compatibility
Any other propositions, idea how those projects should be connected?
Any other requirements, use case ...
Slawomir,
first of all I'd like to raise a *huge thank you* for getting involved
into this complex and messy topic. I also mostly agree with all of your
current observations.
I like to sketch my vague imagination of a proper amalgamation of all
current modules/projects:
* Properly support of running full blown Maven projects on top of either
embedded or forked Maven with a this as possibe layer, e.g., not arg
parsing as done now, proper notifying of cases not possible with
embedded or fork more, e.g, settings JVM options only on fork mode.
* Obtaining exit code and obtain in a easy fashion
* Be usable in Core ITs, components and plugins alike.
* Ability to run verification code either direct in Java or abstracted,
as you noted, in whatever JSR supports, mostly Groovy or BeanShell.
* Proper separation between system propeties and user properties which
is not present in Maven currently
I have no opinion on the JUnit breakage, but moving all of our tests to
JUnit 5 is a huge undertaking and given that we have a lot of topic
makes it even harder.
My basic understanding what components should do:
* Maven Invoker: Simply invokes Maven with all requires args
* Maven Verifier: Verifies the outcome of this invocation.
* Maven Verifier Plugin: Wraps all of that
For me, invocation is not necessarify verification.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
