Le lun. 17 mars 2025 à 14:27, Martin Desruisseaux < martin.desruisse...@geomatys.com> a écrit :
> Le 2025-03-17 à 13 h 42, Romain Manni-Bucau a écrit : > > (about <scope> being closely related to which plugin us it): > > > This is a quite dangerous target cause you will end up with scope = > > plugin to keep it useable. > Not necessarily. This is only a convenience for a common pattern. > Plugins can filter the dependencies based on the scope when convenient, > but they don't have to. > Which means we are worse than today where we stack commonly 4-5 filters in plugins quite commonly whereas we designed a built-in filter by design (single filter impl in plugins), guess we missed the overall solution if that's what we reach. > > > > This is why i think just having a group flag and being able to request > > groups, potentially alias a set of groups for easiness is sufficent > > moving forward and embracing all the work you started to do. > Participants of the module-tooling initiative [1] noted that this > approach requires plugins to parse the group or type identifier as a > dash-separated string. For example, "modular-processor" requires to > separate the "processor" part for identifying that it applies to > annotation processor, then the "modular" part for identifying how to use > it. The separation between <type> and <scope> avoid the need to parse > the string, thus making easier for plugins to filter the dependencies. > The filtering condition is up to plugins — there is no "scope = plugin" > requirement — the proposal only makes the task easier while fitting > nicely in existing Maven model. > This is just the convention used for built-in scope but parsing is not intended to work cause we know we'll need way more types as per previous discussions and some specific to plugins so it is literally a set of dependencies (theorically not even "type" cause we do not want all plugins to register a zip or tar type). This is where the dataset design came from originally and I'm still unclear how using type and now mixing it with scope doesn't just add mess on top of current limitations. At least it doesn't enable new usages but it makes more confusions for end users from my window/personal tests/colleague discussions so hope we refine it to make it easier to consume for our users. > > Martin > > [1]https://github.com/nipafx/module-tooling/discussions/2 >
