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 > > > > >
