On Fri, 11 Oct 2024 at 10:43, Martin Desruisseaux
<martin.desruisse...@geomatys.com> wrote:
> > 1) Classpath testing with one (main) module-info.java file. IIUC, this
> > is what you are planning for maven-compiler-plugin and
> > maven-surefire-plugin to support. It tests with the main code on the
> > modulepath and the test code on the classpath.
> >
> No, this is not what I plan to do. My plan is to test everything on the
> module path (for modular projects), with a single module-info specified
> in the main code. The test-only dependencies are handled by
> --add-modules and --add-reads options added automatically by Maven based
> on what is declared in POM <dependencies> section (so developers have
> control). The test classes in the same packages as the main classes are
> handled by --path-modules options added automatically by Maven. JUnit
> execution needs --add-opens options to be added by automatically by
> Maven too (the way to keep that part under developer's control has not
> been determined yet). So there is usually no need to overwrite the
> module-info in the test code.
>
> There are a few cases where overwriting module-info in test code may be
> necessary. For example, I'm not aware of any Java option for adding or
> removing services (the "provides" clause in module-info). So this is a
> case where overwriting module-info may be necessary, but it should be a
> minority of cases, to use in last resort only. And as said above, for
> those cases, hacks are still possible.
I understand what you are trying to do, but I think it will be
insufficient in a lot more cases than you think it will. Plus, it
suffers from a cliff-edge problem. As soon as it doesn't work
developers are faced with a hard problem to solve.
Of the projects I've converted so far, I think only 1 out of 4 would
work with the mechanism you propose.
Problem 1:Services
Already a known problem, as there is no command line flag for
services. This cannot be automatically derived as described above
Problem 2: Extra dependencies
One of my projects depends on java.desktop in testing, but not in
prod. Since this cannot be expressed in <dependencies>, it cannot be
automatically derived as described above
Problem 3: Extra packages
One of my projects has a package in the tests that is not present in
the main code. Classes in that package need to be exported (to another
module) in order for the tests to pass. This cannot be automatically
derived as described above
Problem 4: Export to all
Problem 3 involved exporting an additional package to a specific
module, which is possible via command line flags. However, there are
no doubt cases where the additional package needs to be exported to
all module, something which cannot be done via a command line flag.
Problem 5: Optional dependencies
Various of my projects have optional module dependencies (requires
static). It is desirable to test both with and without the optional
dependency (multiple runs of surefire). If the optional dependency is
always added, that could be problematic.
Problem 6: Opening for reflection
As mentioned in your previous email, some packages may need to be
opened for testing.
> > 3) Whitebox testing with two module-info.java files. This has yet to
> > achieve an agreed approach in the community, despite JPMS being out
> > for many years.
> If the two module-info files declares the same module name with the
> intend that the test one overwrite the main one, we can do with a hack
> different than the current one (without putting the project
> upside-down). But it should be a deprecated practice, to use in last
> resort only. For the majority of cases, we don't need two module-info
> for whitebox testing with everything on the module path (see point 1 above).
Hopefully my point is coming across. It can't be a deprecated
practice, because it will be significantly more common than you think.
In fact, I suspect that most projects have difficult use cases like
I've described.
As such, I think the opposite approach should be taken - that
specifying a whitebox module-info.java file should be a normal, fully
supported thing. (Great if Maven can do it automatically for the
simple cases, but there needs to be an obvious alternative for the
non-simple cases).
FWIW, I don't think the approach of putting the tests ahead of the
main code ("upside down") is a bad one at all. Given my experience, I
simply don't think command line flags are sufficient to meet the
requirements users of Maven will have.
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
