maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <>
Subject Re: Reactor safe/rally points
Date Mon, 06 Nov 2017 07:30:05 GMT
On Mon 6 Nov 2017 at 01:48, Charles Honton <> wrote:

> Both these use cases sound like adding incredible complexity to support
> less than 1% situations, and worse, encouraging monolithic builds.
> In the first case, the module creating a shaded jar can mark its
> constituent jars as optional; preventing the transitive dependencies.

Ha! That does not do what you think it does.

Optional dependencies are still there but only as a version constraint that
gets applied if something else brings the dependency into the tree in as a
non-optional dependency.

Normally you need a complex deep tree to see the effect (as most people use
version hints rather than specifications... and with hints, closest wins,
whereas specifications are globally merged)

Provided scope is more correct, but shade doesn’t operate on provided
scope... and anyway iirc that also pushes the constraint as transitive.

With shade, the dependency is removed.

> In the second case, It would be better for the plugin be an independent
> build to encourage re-use of that plugin.

Yes it would, but socially people don’t do that... and anyway, there are
legitimate use cases, eg tomee has (or had if they gave up fighting and
moved it out of reactor) a plugin that was tied to the container version.
To allow integration tests in the same reactor as the main codebase, it is
reasonable to want the plugin built at the same time.

If we don’t allow people to build the plugin in the same reactor, they just
fight us and add scripts or move to other build tools... both of which
removes the benefits of Maven.

This would provide a better path, and eventually they will “see sense”
(translation, find other projects that need the same functionality) and
pull the plugin into its own reactor.

> > There are two sets of problems that, assuming we want to fix, both need
> > some way to rally a concurrent multimodule build at.
> >
> > 1. There is the shade like class of problems, where a plugin wants to
> > modify the effective transitive dependencies of a module.
> >
> > 2. There is the extensibility class of problems, where people want to
> build
> > a plugin and consume the same plugin in one reactor.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
> --
Sent from my phone

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message