Le mar. 19 déc. 2023 à 18:36, Martin Desruisseaux < [email protected]> a écrit :
> Le 2023-12-19 à 18 h 24, Romain Manni-Bucau a écrit : > > > > compilation: either make things simple or just enable to compile part > > of the code which does not use modules (does not prevent to compile > > with module meta) > > > I'm not sure what "enable to compile part of the code which does not use > modules" means. If parts of the code use module and other parts do not, > it would have to be two separated Maven modules. A single module is > either modular or not. For a single Maven module, the syntax of the > javac command is: > Not today, this only depends how you consume it so you can build it differently from the way it will be consumed (a bit like a SPI will not work on OSGi or graalvm). > > javac [options] [sourcefiles] > > If someone wants to compile a subset of his application, it changes only > the [sourcefiles] part of the command. Nothing change in the [options] > part, which contains the class-path and module-path. > Hmm, this will not enable the described case - and ultimately you still not enable the user to pass the current limitation which is that the dependencies are rigid so not sure I'm following your reasoning. > > > > surefire: you likely want to test both cases > > > The standard case would be the case as configured by the user. If > testing both cases mean testing also a case where everything is put on > the classpath, then maybe that case could be a separated plugin. Or > maybe an option to surefire-plugin. > Hmm, this is where you loose me, this is exactly what we have today so from my small window you are just trying to solve your case keeping the same limitations on maven. Due to the JPMS requests I'm not sure it is that great. To be concrete we have more agent or annot processor feedbacks than JPMS feedbacks and all 3 need exactly the same solution per plugin so I have to admit i'm not sure what I don't understand. > > Martin > >
