commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Bourg <>
Subject Re: [RNG] modules vs projects
Date Fri, 30 Sep 2016 07:41:44 GMT
Le 29/09/2016 à 13:59, Gilles a écrit :

> What you are arguing here is that if "some-lib" is
> upgraded, then the JDK must change version too!
> Does that (extreme) comparison make the issue clearer?

No, because it isn't comparable to our situation. rng-core and rng-utils
are developed by the same team and target the same field (random number
generation and its direct applications). The JDK and "some-lib" are
completely unrelated.

> I agree that the mixing of versions, even if allowed,
> is not the best choice; that's why I've argued from the
> outset that such loosely coupled modules must in fact
> be different components!
> The result will be that, indeed, users must choose from
> compatible versions.  Anything new under the Sun?

As mentioned by Stian this is how work httpcore and httpclient, and this
can be confusing and error prone. If the modules are all aligned on the
same version the users have only one version to update (typically with a
Maven/Gradle property) and there is no risk of version mismatch.

> Can we please go away from the monolithic culture (and
> look at what other libraries do, and at what IIUC the
> JDK is going to do in the next major release)?

By definition a modular structure isn't monolithic, that's exactly what
other libraries do. And it isn't incompatible with the Java 9 modules.

> It seems like the number of components were a limited
> resource.  This kind of conversation is truly wasting
> valuable time that could have been better spent in setting
> up "rng-utils".
> It seems like folks here are happy to make things more
> complex than they intrinsically are.

Let's talk about complexity. Separate projects mean:
- Extra work for the infra team to setup the project
- Users must carefully pick the compatible versions for the projects
- JIRA reports are likely to be mixed (RNG issues reported in RNGUTILS
and vice versa)
- Extra release management work
- Extra project maintenance (parent and dependencies updates, etc)
- Extra filter rules to setup for the people subscribed to the ML
- No immediate Jenkins feedback if a rng-core change breaks rng-utils

That doesn't look easier than one multi-module project to me.

Emmanuel Bourg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message