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