or simply
module org.joda.time {
requires optional module org.joda.convert;
exports ...
}
"optional" means present at compile time and optional at runtime.
Rémi
Le 1 décembre 2015 16:49:52 CET, Stephen Colebourne <scolebou...@joda.org> a
écrit :
>On 1 December 2015 at 15:39, Alan Bateman <alan.bate...@oracle.com>
>wrote:
>> This should be doable but maybe not obvious. Can you say a bit more
>about
>> the Joda-Time optional dependency on Joda-Convert first? In
>particular, are
>> there static references to types in Joda-Convert and maybe a
>reflection
>> guard to check the presence of one of its types?
>>
>> It might be that you have to compile module joda.time with
>> -XaddReads:joda.time=joda.convert. At run-time then you can use
>Module
>> addReads to read module joda.convert when it's in the module graph.
>
>So, there are three variants of dependency in that list.
>
>1) Joda-Time depends on Joda-Convert solely for annotations. Thus, the
>annotations need to be available to compile against. The annotations
>have runtime scope, so must remain in the bytecode. However, only
>those users that want to use Joda-Convert in anger will ever care
>about them. For everyone else, the fact that there is no class file
>for the annotation at runtime is not a problem.
>
>2) The Joda-Convert dependency on Guava is reflection based. If it
>finds the class on the classpath it will enable the conversion logic.
>If it doesn't it won't.
>
>3) The ElSql dependency on Spring is not reflection based. If the user
>uses the class ElSqlBundle, they have to have Spring available. If
>they do not use that class, they do not have to have Spring available.
>
>The Joda-Beans dependencies are a mixture of the second and third
>type..
>
>
>I can see how the compile time flag could work, which is good.
>However, I think that it should be part of the module-info file, since
>the project cannot be compiled without it.
>
>module org.joda.time {
> exports ...
> at-compile-time {
> requires module org.joda.convert;
> }
>}
>
>Stephen
