jar aggregator projects

[Delany <de...@gmail.com>]

Hi. Why can I only have pom aggregator projects and not jar aggregator
projects?
Is this still the case in Maven 4?

Thanks,
Delany

Re: jar aggregator projects

[Delany <de...@gmail.com>]

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 <mg...@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 <lu...@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 <ln...@gmail.com> wrote:
> > >
> > >> I'm curious about the usecase of this.
> > >>
> > >> Thai Le
> > >>
> > >> On Fri, Nov 4, 2022, 09:30 Delany <de...@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-unsubscribe@maven.apache.org
> > For additional commands, e-mail: users-help@maven.apache.org
> >
> >
>

Re: jar aggregator projects

[Mantas Gridinas <mg...@gmail.com>]

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 <lu...@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 <ln...@gmail.com> wrote:
> >
> >> I'm curious about the usecase of this.
> >>
> >> Thai Le
> >>
> >> On Fri, Nov 4, 2022, 09:30 Delany <de...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: jar aggregator projects

[Łukasz Dywicki <lu...@code-house.org>]

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 <ln...@gmail.com> wrote:
> 
>> I'm curious about the usecase of this.
>>
>> Thai Le
>>
>> On Fri, Nov 4, 2022, 09:30 Delany <de...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: jar aggregator projects

[Thai Le <ln...@gmail.com>]

In your first example (one webserver as parent with 4 child components), if
the feature-a declares webserver as <parent> (so the child can inherits all
the properties and dependencies from the parent) then logically, then the
webserver must be built before feature-a. However, according to the
structure and intention, feature-a is a component of webserver; therefore
feature-a must be built before webserver. Now we have a conflict.
In your 2nd example, actual-server can still be the <parent> of feature-a
and thus be built first. However, the feature-a is now no longer a
component of actual-server thus it has no problem being built after
actual-server

Note that in both example, we are not explicitly declare feature-a as
dependency of webserver.

Thai

On Mon, 7 Nov 2022 at 12:53, Delany <de...@gmail.com> 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 <ln...@gmail.com> wrote:
>
> > I'm curious about the usecase of this.
> >
> > Thai Le
> >
> > On Fri, Nov 4, 2022, 09:30 Delany <de...@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
> > >
> >
>


-- 
Where there is will, there is a way

Re: jar aggregator projects

[Delany <de...@gmail.com>]

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 <ln...@gmail.com> wrote:

> I'm curious about the usecase of this.
>
> Thai Le
>
> On Fri, Nov 4, 2022, 09:30 Delany <de...@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
> >
>

Re: jar aggregator projects

[Thai Le <ln...@gmail.com>]

I'm curious about the usecase of this.

Thai Le

On Fri, Nov 4, 2022, 09:30 Delany <de...@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
>