Le lun. 14 oct. 2024 à 10:18, Martin Desruisseaux < [email protected]> a écrit :
> 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. > Fwiw, the Maven 4 API defines a few new scopes, in particular the scopes named compile-only and test-only, see https://github.com/apache/maven/blob/30dc81227bf9c36d36f8549d22ab4c40bce60e77/api/maven-api-core/src/main/java/org/apache/maven/api/DependencyScope.java#L82 > > > > 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? > Not sure we need, but it would be nice, once Maven 4.0.0-beta-5 is out, to progress on the stack migration... > > Martin > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- ------------------------ Guillaume Nodet
