Hi,

On Mon, 12 Sept 2022 at 18:05, Ralph Goers <ralph.go...@dslextreme.com> wrote:
> See below.  While I OK with reorganizing the parent pom.xml in release-2.x I 
> am not
> OK with making radical changes to it since it is “stable”.  I also think 
> trying to synchronize
> the two is kind of pointless. Given that one is based on Java 8 and one is 
> Java 11
> and the organization of the projects is different there are going to be 
> significant differences.

I don't plan any radical changes, I would just like a similar
structure to easily compare the dependencies of the two branches. Of
course `master` can have newer dependency versions, but it can not
have older dependencies than `release-2.x`.

> > * removing the scope from `<dependencyManagement>`: this way there
> > will be no difference between BOMs and explicit dependencies. It's
> > more verbose, but we won't risk having JUnit in the compile scope.
>
> I don’t understand. A BOM MUST be <scope>import</scope> to be included 
> properly.
> Why wouldn’t you specify Junit as test scope since it always is, except for 
> test modules
> that deliver a test jar. Those can be overriden.

The problem with BOMs is that they import dependencies in the default
scope. If we use `junit-bom`, we need to specify the `test` scope of
JUnit libraries in all children POMs, while we don't need to do it
with `hamcrest-core` that does not have a BOM. What I propose is to
*always* specify the scope in children POMs, even if it is inherited
from <dependencyManagement>.

> > * removing exclusions from `<dependencyManagement>`: AFAIK they are
> > ignored by Maven. Or we can keep the exclusions as a template for the
> > projects.
>
> Are you sure this is true? I’m not sure it isn’t.

I stand corrected. Regardless of what StackOverflow says, exclusions
in the <dependencyManagement> seem to work (since version 2.0 :-) )

Piotr

Reply via email to