Hi Mantas,
The children are dependents, not dependencies - as in human relations. This
isn't really an issue since the three aspects of project aggregation,
configuration inheritance, and dependency management are separate. I hope
you no longer think there's a problem with build order?
I want my projects to look like this
- mineral (jar)
- pyrite (jar)
- gypsum (jar)
- sandstone (jar)
When I build the mineral project, I want the other projects to build -
currently not possible
Id also like the pyrite/gypsum/sandstone projects to inherit configuration
from the mineral project. This should be as easy as setting the parent tag
- currently not possible
A nice to have would be where the child projects inherit an implicit
dependency on the parent. It seems this is actually the case with pom
parents, but it doesn't result in a compile dependency in the resulting
pom. When the parent is a type jar lets say that it should.
I can imagine this would play out as various tickets
- allow project type jar to act as an aggregator
- allow project type jar to act as a parent
- infer a dependency on the project acting as the parent and introduce a
scope tag to make this configurable
I might be talking about changes already considered/implemented in Maven 4
in which case apologies for the noise. But in Maven 3 I have to arrange my
projects like so
- aggregator (pom)
- mineral (pom)
- pyrite (jar)
- gypsum (jar)
- sandstone (jar)
- mineral (jar)
The aggregator is necessary to build the mineral and its dependents AND
have a dependency on the mineral project inherited by the three other
projects. Its ugly as heck.
>From a users point of view, the fact that a project is type pom vs jar is
simply a matter of the lifecycle invoked for the build. And if it's not,
don't you agree that it should be?
Regards,
Delany
On Tue, 1 Feb 2022 at 08:19, Mantas Gridinas <mgridi...@gmail.com> wrote:
> 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
> > >
> > >
> >
>
