Le dim. 29 oct. 2023 à 21:21, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit :
> Le 2023-10-29 à 20 h 58, Romain Manni-Bucau a écrit : > > > > Is it really different since part of options are related so either we > > align on the jvm making using maven location mapping easier or we > > fully integrate but means we must detect errors in options which is > > for me a hard task > > > Why do we need to detect errors in options, isn't the Java error message > sufficient? The Java error messages are already quite informative > regarding those options (after we learned the philosophy). > Well not really, some libraires complain about it. After it depends which cases but several can be cryptic after some refactoring. > > Those options indeed apply only for <type>module</type>. But the way I > envision that would be a separated block in <dependency> for saying "if > this dependency is added on the module-path, then add those > --add-exports options". It would be used mostly for the JUnit or TestNG > dependency. In this proposal, this element would be independent to > <type>, except that it would be ignored (or raise an error) if the type > is JAR. > Then you are back to the dependency set solution which is not the type solution and in this option the type is fully useless. > > > > side note: please think about transitivity, here with the proposal you > > must define *all* your transitive deps in your consumer pom. > > Completely changes the maven philosophy. > > > Why would we need to declare all transitive dependencies? The > <type>module</type> element in the pom.xml of each dependency would apply. > Cause your transitive deps are then jars, not modules (that said the opposite is wrong too for most libs) > > Martin > >
