+1. Thanks for your input. Yes, I am trying to raise the issue that
"requires public" needs more power. Developers need complete control over
dependency management. I've advocated several times that module authors
cannot absolutely be the dictators. They can recommend what they need, but
developers must have the power to override. You cannot simply trust just
because an author says it needs X, Y, Z, that is really the case. There can
be impact to your systems that they cannot have foreseen. The final say
must be the project that is consuming the modules.
Cheers,
Paul
On Wed, Jul 27, 2016 at 10:55 AM, Stephen Colebourne <scolebou...@joda.org>
wrote:
> I find "requires public" to be sensible enough and a useful tool. I
> agree that there may be cases where it would be desirable to block
> such dependencies. There may already be a command line flag to do
> that, but an addition to module-info may also make sense.
>
> Stephen
>
>
> On 26 July 2016 at 19:35, Paul Benedict <pbened...@apache.org> wrote:
> > In a modularized world, I don't see "requires public" delivering the
> value
> > it should.
> >
> > Let's take this example:
> > module java.sql {
> > requires public java.logging;
> > requires public java.xml;
> > exports java.sql;
> > exports javax.sql;
> > exports javax.transaction.xa;
> > }
> >
> > Given a theoretical Maven POM representing the "java.sql" module, the POM
> > would have to list out the other two modules so that my project compiles
> > against all declared modules. It is considered bad practice to compile
> > against artifacts I did not declare in my POM. There are three artifacts
> > here.
> >
> > Would any Maven experts here disagree? I see the positive of "requires
> > public" to be negated in build systems. Given what I just found, I do not
> > like the idea of public transitive dependencies in the Module Descriptor.
> > For developers using build systems, I believe "requires public" should be
> > avoided.
> >
> > Cheers,
> > Paul
>
