Weakness of "requires public"

[Malachi de Ælfweald]

I would not expect to specify any transitive dependency.  I would not
expect any user of my API to have to manually specify any transitive
dependencies I used in my public API (return types for example).  If they
did - that completely breaks the point of me specifying transitive
dependencies in the first place.



Malachi de Ælfweald
http://www.google.com/profiles/malachid

On Tue, Jul 26, 2016 at 11:35 AM, Paul Benedict <pbenedict at 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
>