Seems reasonable to be honest. I would make a guess that aggregators with their own sources would need to decide what to do with their children: should they be treated as additional dependencies, what should be the build order of such module. But if you treat children as dependencies then you introduce circle in dependency graph because children already inherit the parent, so should they become pseudo fat jars where they contain the binaries of a parent?
Im all up for what ever decision streamlines the process so that there would be less "thinking" (read: guessing) whats going to happen under such configuration and that is especially important when you're using an implicit tool like maven. At least this is my speculative take. On Tue, Feb 1, 2022, 07:56 Delany <delany.middle...@gmail.com> wrote: > Yes but why? Why should I have to make separate projects just for the > purpose of aggregating other projects? This isn't the case in g*****. > Delany > > > On Tue, 1 Feb 2022 at 00:47, Nils Breunese <n...@breun.nl> wrote: > > > You can create a multi-module project, with one of the modules using its > > sibling modules as dependencies. The parent pom.xml would be of type > ‘pom’ > > and contain the list of all modules in the project of type ‘jar’. > > > > Nils. > > > > > Op 31 jan. 2022 om 13:58 heeft Delany <delany.middle...@gmail.com> het > > volgende geschreven: > > > > > > Can someone remind me why a type JAR project can't have modules? > > > Is it unreasonable to expect a JAR project to produce its own JAR > > artifact, > > > and then act as an aggregator of other projects? > > > > > > Thanks, > > > Delany > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
