Hello Stephen Le 2024-10-13 à 22 h 57, Stephen Colebourne a écrit :
Problem 1:Services Already a known problem, as there is no command line flag for services. This cannot be automatically derived as described above
Already answered in my previous email: this is one of the few cases where duplicated module-info.java are necessary, and it can be supported with hacks.
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
As mentioned in my previous email, it is expressed by a dependency with <scope>test</scope>. The new compiler plugin already supports that. This is handled in the same way as any other test dependencies such as JUnit. If we mean a dependency needed only at test runtime (not test compile time), we may need to introduce a new type of dependency.
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
The old way to specify additional compiler options is still available. So it is possible to add explicit --add-exports flags there. If developers need to add only special cases such as this one instead of all --add-exports flags, it is still a better situation than the current one.
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.
For testing purpose only? If you mean using a different module-info for tests than the module-info for the main code when testing from a different Maven module, it seems to not be possible at all, unless we put the project upside-down (test become main code and main code become patch), or unless we temporarily replace de module-info.class file. This is doable if there is really a need for that.
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.
Yes, we will need a mechanism for controlling that. But the problem is the same with the current plugins.
Problem 6: Opening for reflection As mentioned in your previous email, some packages may need to be opened for testing.
Yes, as said before this is one of the points where the mechanism is yet to be determined.
In summary, in this list of problems, I think that 2 or them should already works. 2 other require hacks, even with the current plugins, so the proposed work would hopefully be at least an improvements. The last 2 are known open questions, but not blocking as their solution would be some new configuration options somewhere.
The most productive way to resolve those questions may be to have a working prototype and checks which issues are still valid on that prototype. However some issues such as problem 6 are not compiler issues, but Surefire issues. Do we need to have the full stack tested before validating the approach?
Martin --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
