the thing is modules are one example but you also have several plugin related dependencies (living doc one is a common example I hit and I workaround with provided or test but this is wrong, another one can be a generator plugin, but most common ones are assembler plugins where sets enable to toggle features etc...).
It would be neat for example to use in jib sets = layers just by references and link it to the compiler plugin saying compileDeps=dep1+dep2+set1+set2 to give a concrete example. Indeed we would end up with convention (compiler depset is used by default, module depset is used for modulepath, patch is used for patch-module for ex etc). But the mecanism is to think about set of dependencies and compose/reference that instead of being rigid with ~one (two with tests). Indeed you can argue that plugins can take a few <dependencies> blocks and do it themselves, this is true and I would agree if the conclusion is the same for the modules, ie put the conf in compiler, javadoc, ... plugins. If not it just means we need reusable dependencies set we can compose in plugins. It would inherit from the dependency global management (not speaking of the block, more the technical parts) and avoids the interproject issues. I'm not really sure if we have another option until we do something really ad-hoc for modules which means we don't solve the issue and will need something specific for everything. Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le lun. 30 oct. 2023 à 21:15, Henning Schmiedehausen < henn...@schmiedehausen.org> a écrit : > Modules are just regular dependencies that need to end up on the module > path instead of the classpath. Creating a new section in the pom (with all > its pains, because it would not just be "modules" but also > "moduleManagement", akin to "dependencyManagement") is IMHO a really bad > idea. Also, "module" is already taken. ;-) > > -h > > > > On Sat, Oct 28, 2023 at 1:55 PM Tamás Cservenák <ta...@cservenak.net> > wrote: > > > Howdy, > > > > I still see these just as new dependency types: "module", "agent", > > "doclet", and so on. > > > > Also, for "other end" (producing) we'd need new packaging as well: > "module" > > at least for example. > > > > ArtifactHandler would need to be extended as well, or better, complete > > adopt Resolver ArtifactType instead (of limited Maven ArtifactHandler): > > > > > https://github.com/apache/maven-resolver/blob/master/maven-resolver-api/src/main/java/org/eclipse/aether/artifact/ArtifactType.java > > > > And plugins should just do what given Artifact's ArtifactType says, no > > more, no less. > > No heuristic, no "guesswork", or anything like that, just keep the simple > > stupid. > > > > Thanks > > T > > > > > > On Tue, Oct 24, 2023 at 7:42 AM Thomas Reinhardt <tho...@reinhardt.com> > > wrote: > > > > > > > > On 20/10/2023 20:43, Romain Manni-Bucau wrote: > > > > Can be the way to define the lookup, an heuristic will never work by > > > > design...that said, on my side, not sure JPMS will be widely adopted > > > > anytime soon so can be a false problem. > > > This is a chicken and egg problem. My company would love to use JPMS > > > more. But right now it is basically unusable for us and part of it is > > > lacking maven support. The next big maven release should definitely > > > improve the support. One big problem is testing (and all the > > > implications with different classpaths etc) but that deserves its own > > > discussion I think. > > > > > > > > > > > > > > Romain Manni-Bucau > > > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > > > <https://rmannibucau.metawerx.net/> | Old Blog > > > > <http://rmannibucau.wordpress.com> | Github < > > > https://github.com/rmannibucau> | > > > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > > > < > > > > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > > > > > > > > Le ven. 20 oct. 2023 à 20:24, Henning Schmiedehausen < > > > > henn...@schmiedehausen.org> a écrit : > > > > > > > >> I think we will need to start rethinking dependencies more. A > similar > > > >> problem exists with modules; the current heuristics to decide > whether > > a > > > >> dependency goes on module path or classpath will start to become > > > painful in > > > >> the very near future. > > > >> > > > >> -h > > > >> > > > >> > > > >> On Tue, Oct 17, 2023 at 10:05 PM Benjamin Marwell < > > bmarw...@apache.org> > > > >> wrote: > > > >> > > > >>> If you can still use it twice, works for me, too. > > > >>> > > > >>> Either way, you'd need it both as a dependency and as an agent. > > > >>> > > > >>> Another requirement Romain mentioned is the order of agent loading. > > > >> Mockito > > > >>> wants to be first, and others can come later. > > > >>> > > > >>> - Ben > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> On Wed, 18 Oct 2023, 00:11 Tamás Cservenák, <ta...@cservenak.net> > > > wrote: > > > >>> > > > >>>> What about type=java-agent? Basically a new ArtifactHandler? > > > >>>> > > > >>>> See https://maven.apache.org/repositories/artifacts.html > > > >>>> > > > >>>> T > > > >>>> > > > >>>> On Tue, Oct 17, 2023, 23:54 Benjamin Marwell <bmarw...@apache.org > > > > > >>> wrote: > > > >>>> > > > >>>>> Hey all, > > > >>>>> > > > >>>>> In a mockito issue, JDK maintainers suggested to differentiate > > > >> between > > > >>>>> agents and normal dependencies. Starting with JDK 21 already, > this > > > >>> makes > > > >>>> a > > > >>>>> lot of sense: dynamic loading of agents will be a no-go. > > > >>>>> > > > >>>>> One suggestion was: > > > >>>>> > > > >>>>> <dependencies> > > > >>>>> <dependency> > > > >>>>> ... > > > >>>>> </dependency> > > > >>>>> <agents> > > > >>>>> <dependency> > > > >>>>> ... > > > >>>>> </dependency> > > > >>>>> </agents> > > > >>>>> </dependencies> > > > >>>>> > > > >>>>> Not sure if this is the best way, but this is something similar > > might > > > >>> be > > > >>>>> needed. > > > >>>>> Currently, the only way to handle agents is to add them manually > to > > > >> the > > > >>>>> surefire argLine. To make things worse, a deoendency goal is > needed > > > >>> until > > > >>>>> Romains PR is merged: > > > >>>>> https://github.com/apache/maven/pull/1281 > > > >>>>> > > > >>>>> Another issue is that a parent pom might not be able to easily > > define > > > >>>> this > > > >>>>> option. There were some concerns that part of the configuration > > > >> needed > > > >>> to > > > >>>>> be repeated in every module. > > > >>>>> > > > >>>>> So, I wrote Maven 5. > > > >>>>> Maven 4 is the stepping stone to the build/consumer pom. But this > > is > > > >> an > > > >>>>> extension. Not really a breaking change in terms of parsing, but > in > > > >>> terms > > > >>>>> of building a project. Thus, it should go onto the roadmap. > > > >>>>> > > > >>>>> ... unless you want to keep the current status quo, which is also > > an > > > >>>>> option. But before making an argument here, I'd recommend reading > > the > > > >>>>> lengthy (sorry!) discussion on the mockito issue tracker. Since > > Karl > > > >>>> Heinz > > > >>>>> started the issue, I'd love to hear back from you, too. Link: > > > >>>>> https://github.com/mockito/mockito/issues/3037 > > > >>>>> > > > >>>>> If no discussion is needed at this point, let's keep this as a > > > >> reminder > > > >>>> for > > > >>>>> the next Apero and/or Maven 5 then. > > > >>>>> > > > >>>>> - Ben > > > >>>>> > > > >>>> > > > >>> > > > >> > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > > >
