Oh, make no mistake I use aggregator POMs for that reason. But I ALSO have many aggregators that are just containers with <modules>. They need their own artifactId, and their own directory (technically not a requirement, but in practice no-one wants 2 poms in one directory). Delany
On Tue, 8 Nov 2022 at 15:23, Mantas Gridinas <mgridi...@gmail.com> wrote: > I think the reasoning makes sense. I would rather have a strong primitive > using which I could build my own process, rather than fight an exact > implementation. Current structure of an aggregator being its own packaging > type is that primitive. > > Why do you consider having "glue boilerplate" bad, delany? I think its a > great place to put all thr project's verbose declarations, such as > dependency management, repository, plugin management blocks without > litering the actual working modules. > > On Tue, Nov 8, 2022, 14:00 Łukasz Dywicki <l...@code-house.org> wrote: > > > Hello Delany, > > Number of combinations in which people would like to assembly their > > software is larger than hours maven maintainers can provide to support > > all of them equally well. I remember that a lot of initial "hate" maven > > received was caused by assembly plugin which was not covering all edge > > cases people had. > > Probably there are more reasons which come from initial assumptions made > > when designing Maven, thus maybe someone closer to the core will explain > > why its not possible. > > > > Best, > > Łukasz > > > > On 7.11.2022 18:52, Delany wrote: > > > Let me answer that with another question. How often does a project > > include > > > a core component/module with a bunch of other components that depend on > > it? > > > I would guess quite often. > > > So why cant I have a directory structure that looks like: > > > > > > webserver > > > ├── feature-a > > > ├── feature-b > > > ├── skin-1 > > > └── skin-2 > > > > > > Instead I have to come up with an aggregation project to ties them all > > > together > > > > > > aggregation-webserver > > > ├── actual-webserver > > > ├── feature-a > > > ├── feature-b > > > ├── skin-1 > > > └── skin-2 > > > > > > This aggregation project is just extra glue that must be built, > deployed, > > > downloaded. > > > > > > What about the declaration of the webserver dependency. In the first > case > > > it could be an implicit effect of having <parent> type jar, but in the > > > second I have to write it out in the aggregation-webserver. > > > > > > I just don't see the point. Why have 6 projects when 5 will do? > > > > > > I do see the point of aggregation poms if it was 5 unrelated > components, > > > but there is an obvious hierarchy here. > > > I also see the potential pitfall of plugin configuration meant only for > > the > > > webserver being inherited by its children. But if I make customizations > > > inappropriate for the children then I'll abstract them into an > > aggregation > > > pom when the need arises. Most plugin configuration I have applies to > all > > > my modules. > > > > > > Kind regards, > > > Delany > > > > > > > > > On Fri, 4 Nov 2022 at 16:08, Thai Le <lnthai2...@gmail.com> wrote: > > > > > >> I'm curious about the usecase of this. > > >> > > >> Thai Le > > >> > > >> On Fri, Nov 4, 2022, 09:30 Delany <delany.middle...@gmail.com> wrote: > > >> > > >>> Hi. Why can I only have pom aggregator projects and not jar > aggregator > > >>> projects? > > >>> Is this still the case in Maven 4? > > >>> > > >>> Thanks, > > >>> Delany > > >>> > > >> > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > > For additional commands, e-mail: users-h...@maven.apache.org > > > > >
