commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: [RNG] modules vs projects
Date Fri, 30 Sep 2016 16:13:44 GMT
Hi All,

[Note my careful use of the terms "project", "component", and "module"]

Pardon my jumping in late... If some of this is leading to more than one
commons-rng component within Apache Commons, I would be against that; Maven
modules are a perfect match for this concept.

Please allow me to relate my experience with Apache Log4j 2 where we have
one project with 26 modules (granted there are 8 non-production modules:
samples and benchmarks). For most releases, there are interesting and
significant changes in only one module (log4j-core). A Log4j 2 release
means a release of all modules and a guarantee that all modules work
together (of course).

Another example is Apache HttpComponets where there are several components
and some components have several modules. This is not a trivial environment
to set up as a project developer (unless I made a mess of my own personal
set up, not unlikely! ;-)

So far, Commons-RNG is a small and focused component related in theme to
Commons-Math but these are not dependent on each other, so we have to keep
that explanation clear.

I would think that it would be better to have modules potentially come,
morph, go, within one component.


On Fri, Sep 30, 2016 at 8:45 AM, Brent Worden <>

> On Fri, Sep 30, 2016 at 10:02 AM, Gilles <>
> wrote:
> > On Fri, 30 Sep 2016 09:41:44 +0200, Emmanuel Bourg wrote:
> >
> >>
> >>  - No immediate Jenkins feedback if a rng-core change breaks rng-utils
> >
> > I'm not sure I got that one.
> > If it means to copy the new "rng-core" over to some place for use
> > by the build of "rng-utils", can't this be done by a "post-build"
> > script?
> The lack of immediate feedback is the same risk we have with other commons
> components being dependencies of other projects, Apache or otherwise.  I
> think with the level that commons projects are policed through unit tests,
> code reviews, backwards compatibility checks, and release candidate reviews
> this risk is mitigated to a very acceptable level.
> In the past when the commons project changes did cause unintended upstream
> problems, I feel we have done a good job reacting in a timely fashion to
> address these issues and make process improvements if warranted.  I do see
> how we'd be any different, or need to be any different, with these two
> components.
> If this is something we want more risk mitigation, we could set up both
> components in Gump.
> > If that is not obvious to you, but are willing to trust other
> > members here (me in this case), you could agree to make the
> > experiment! :-)
> > Then when we see more code, more users, more contributors,
> > more opinions, and we see that there is merit in merging the
> > two components, we'll just do it.
> > [And I'll apologize to the INFRA people for the time they wasted
> > in setting up the project.]
> >
> >
> > Gilles
> >
> >
> I was just thinking the same thing.  Let's try one way and see it works to
> satisfaction.  If it does, great.  If it proves to be burdensome or the
> benefits are not realized, we can try another approach.
> Another thing I was thinking if we wanted to test drive the multi-project
> route, what about setting up rng-utils in the sandbox?  Process-wise it
> would be a lot like a proper project thus, giving us the opportunity to see
> how it would actually function.  One benefit of using the sandbox is that
> the work can begin immediately as it does not require infrastructure
> changes.
> Brent

E-Mail: |
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition <>
Spring Batch in Action <>

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