On 18/01/16 17:28, Paul Sandoz wrote:
> Assuming the JodaTime library is not publicly exported (types in the
> dependent API) and used in a manner that is amenable to maintaining
> separate classes then i guess it (and it’s dependencies) would have
> tag along with a "one unit, one set of depende
> On 18 Jan 2016, at 17:01, Stephane Epardaud wrote:
>
> Hi,
>
> Well, I can think of at least one use-case where a JDK10 version of a
> module would have different dependencies than JDK9: if the module used
> an external lib for X in JDK9, and then JDK10 incorporated that
> functionality X so
Hi,
Well, I can think of at least one use-case where a JDK10 version of a
module would have different dependencies than JDK9: if the module used
an external lib for X in JDK9, and then JDK10 incorporated that
functionality X so that import would no longer be required but the
module would then impo
Hi Paul,
A jar file can be considered a unit of release, and a modular-jar is no
different in that respect e.g. either kind might have a maven pom and be
published to maven central. The strong expectation is a unit of release has one
set of dependencies.
Changing that expectation will i think
Thanks Alan. A poor-man's solution may be optional module dependencies.
Cheers,
Paul
On Wed, Jan 13, 2016 at 11:08 AM, Alan Bateman
wrote:
>
> On 13/01/2016 16:55, Paul Benedict wrote:
>
>> With multi-release JARs, there is a directory structure to partition out
>> the class files for the desti
On 13/01/2016 16:55, Paul Benedict wrote:
With multi-release JARs, there is a directory structure to partition out
the class files for the destined versions of the Java runtime.
With modules, the module-info.class sits in the root of the JAR.
How will these two requirements be reconciled? Are
