an optional
dependency originally omitted when creating the image.
2017-02-17 10:46 GMT+01:00 Alan Bateman :
> On 17/02/2017 08:45, Gunnar Morling wrote:
>
>> Hi,
>>
>> How can I exclude optional dependencies when creating a runtime image
>> using jlink?
>>
>>
On 17/02/2017 08:45, Gunnar Morling wrote:
Hi,
How can I exclude optional dependencies when creating a runtime image
using jlink?
In more detail, I have a module A which declares an optional
dependency to another module B via "requires static". I'd like to
create a runtime i
Hi,
How can I exclude optional dependencies when creating a runtime image
using jlink?
In more detail, I have a module A which declares an optional
dependency to another module B via "requires static". I'd like to
create a runtime image which only contains A.
When running jl
uot;requires B" (say a root application module directly or a
transitive dependency)
- adding -addmods B command line option
- deployment descriptor of a .mwar application says so
I can certainly say that this is backward compatible in code. The
code stays the same.
I&#
That doesn't bode well for frameworks that must run in JDK 8 and 9 --
either in classpath mode or module mode. That means the addReads() call
will have to be reflective so it can work in both worlds. That's just
another hack.
Cheers,
Paul
On Fri, Dec 18, 2015 at 11:33 AM, Neil Bartlett
wrote:
>
I do not see any statement in the Module System Requirements document
(http://openjdk.java.net/projects/jigsaw/spec/reqs/) such that Java 9 is
required to be backwards compatible, except where code runs in “classpath mode”
(aka the unnamed module).
Therefore it is an acceptable solution — at le
for your comments. I differ in that I don't
see any problems with optional dependencies. Right now,
like in Spring, optional features are enabled with a
Class.forName() runtime check; if ClassNotFoundException
is captured, the feature is u
that is already a part of configuration "requires B"
> (say a root application module directly or a transitive dependency)
> - adding -addmods B command line option
> - deployment descriptor of a .mwar application says so
>
>
> I can certainly say that this is backw
ation "requires B"
(say a root application module directly or a transitive dependency)
- adding -addmods B command line option
- deployment descriptor of a .mwar application says so
I can certainly say that this is backward compatible in code. The code
stays the same.
I'm al
e are not in disagreement. We are just talking of slightly
>> different things. So let me answer your concerns...
>>
>> On 12/17/2015 06:14 PM, Paul Benedict wrote:
>>
>>> Peter, thanks for your comments. I differ in that I don't see any
>>> problems wi
Hi Paul,
I think we are not in disagreement. We are just talking of
slightly different things. So let me answer your concerns...
On 12/17/2015 06:14 PM, Paul Benedict wrote:
Peter, thanks for your comments. I differ in that I don't see
any problems with op
Adding read edges at runtime is not a backward compatible solution. Jigsaw
should automatically allow you to read anything your Module Descriptor
gives you access to -- required or optional.
Cheers,
Paul
On Fri, Dec 18, 2015 at 10:02 AM, Peter Levart
wrote:
>
>
> On 12/18/2015 04:49 PM, Peter L
t;
> I think we are not in disagreement. We are just talking of slightly
> different things. So let me answer your concerns...
>
> On 12/17/2015 06:14 PM, Paul Benedict wrote:
>
>> Peter, thanks for your comments. I differ in that I don't see any
>> problems with opt
On 12/18/2015 04:49 PM, Peter Levart wrote:
You can check whether the optional module is included in a runtime
configuration or not with a simple Class.forName() check even if you
don't depend on the module (i.e. don't list it in "requires"
descriptor at runtime). The visibility of classes is
Hi Paul,
I think we are not in disagreement. We are just talking of slightly
different things. So let me answer your concerns...
On 12/17/2015 06:14 PM, Paul Benedict wrote:
Peter, thanks for your comments. I differ in that I don't see any
problems with optional dependencies. Right now,
Peter, thanks for your comments. I differ in that I don't see any problems
with optional dependencies. Right now, like in Spring, optional features
are enabled with a Class.forName() runtime check; if ClassNotFoundException
is captured, the feature is unavailable. I expect that coding patte
Hi,
On 12/17/2015 12:03 PM, Stephen Colebourne wrote:
And here are the threads for Joda projects, which also need optional
dependencies:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-December/005462.html
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-December/005638.html
Note
And here are the threads for Joda projects, which also need optional
dependencies:
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-December/005462.html
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2015-December/005638.html
Note, I do not consider command line flags to be acceptable as
As I already mentioned, we also have the need for this in Ceylon, for
the same reasons. Dependencies are required at compile-time but optional
at run-time, based on detection: if it's there fine, if not then no problem.
d for optional dependencies from
Spring's perspective:
Our module arrangement in the Spring Framework project has been pretty
stable for about 10 years, splitting the core framework into ~20 modules
with a maximum size of ~1 MB each (some are much smaller). The module split
is largely based
On 07/12/2015 08:42, Philippe Marschall wrote:
On 04.12.15 17:53, Stephen Colebourne wrote:
I've been pondering whether -addReads is sufficient for this use case.
What's not clear to me is does -addReads only work for the default
(base?) layer or also any layer that is created programmatica
On 04.12.15 17:53, Stephen Colebourne wrote:
I've been pondering whether -addReads is sufficient for this use case.
What's not clear to me is does -addReads only work for the default
(base?) layer or also any layer that is created programmatically?
Cheers
Philippe
On 06/12/2015 22:31, Stephen Colebourne wrote:
:
However taking a step back, in order to support this type of release,
command line flags are not an option. Since Joda-Beans is an OSS
library, developers need to be able to "just use it". Telling
developers that if they use this library they have
+1
On Mon, Dec 7, 2015 at 2:01 AM, Stephen Colebourne
wrote:
> On 5 December 2015 at 09:49, Alan Bateman wrote:
> > Yes, that's right, there is enough to support all the scenarios. The
> > use-guava-if-it-happens-to-be-there scenario is somewhat awkward though
> as
> > it would means using -add
On 5 December 2015 at 09:49, Alan Bateman wrote:
> Yes, that's right, there is enough to support all the scenarios. The
> use-guava-if-it-happens-to-be-there scenario is somewhat awkward though as
> it would means using -addmods. On the other hand, the
> use-guava-if-someone-hands-me-a-guava-type
On 5 December 2015 at 09:49, Alan Bateman wrote:
>
> On 04/12/2015 19:10, Peter Levart wrote:
>>
>> :
>>
>> You would have to invoke jodaBeansModule.addRead(guavaModule); from your
>> org.joda.beans code before 1st use of any guava type. In Addition, you would
>> have to ensure guava is part of ru
On 04/12/2015 19:10, Peter Levart wrote:
:
You would have to invoke jodaBeansModule.addRead(guavaModule); from
your org.joda.beans code before 1st use of any guava type. In
Addition, you would have to ensure guava is part of runtime
configuration - either implicitly by some module in your co
On 12/04/2015 06:07 PM, Ali Ebrahimi wrote:
Hi,
On Fri, Dec 4, 2015 at 8:23 PM, Stephen Colebourne
wrote:
I've been pondering whether -addReads is sufficient for this use case.
While type 1 of my classification below (annotations) would work using
compile-time -addReads, I don't think type
setup, it seems to me that -addReads at compile time
is insufficient to meet the requirement of optional dependencies.
You would have to invoke jodaBeansModule.addRead(guavaModule); from your
org.joda.beans code before 1st use of any guava type. In Addition, you
would have to ensure guava
Hi,
On Fri, Dec 4, 2015 at 8:23 PM, Stephen Colebourne
wrote:
> I've been pondering whether -addReads is sufficient for this use case.
>
> While type 1 of my classification below (annotations) would work using
> compile-time -addReads, I don't think types 2 and 3 would. (Type 2 is
> reflection b
sufficient to meet the requirement of optional dependencies.
IMO, adding syntax to the module-info for optional dependencies would
allow the connection between the modules to be recorded properly. With
that information, the module system could grant the implied
readability link from Joda-Bean
Syntactic detail, but if you use "import" instead of "requires" then
"import optional" or "import public" both make sense ;)
Perhaps just 'optional module module.name;' ?
--Reinier Zwitserloot
On Tue, Dec 1, 2015 at 9:48 PM, Paul Benedict wrote:
> There is certain irony in seeing "requires optional" :-) Two contradictory
> terms side-by-side.
>
> Cheers,
> Paul
>
> On Tue, Dec 1, 2015 at 2:40 PM, Rémi Forax wrote:
There is certain irony in seeing "requires optional" :-) Two contradictory
terms side-by-side.
Cheers,
Paul
On Tue, Dec 1, 2015 at 2:40 PM, Rémi Forax wrote:
> or simply
>
> module org.joda.time {
> requires optional module org.joda.convert;
> exports ...
> }
>
> "optional" means present at
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 a
écrit :
>On 1 December 2015 at 15:39, Alan Bateman
>wrote:
>> This shoul
On 1 December 2015 at 15:39, Alan Bateman 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
On 01/12/2015 15:08, Stephen Colebourne wrote:
:
The real problem here is that the variants of each of these projects
are not really significant. I want users to depend on the concept of
Joda-Time, and for them to pickup the benefits of Joda-Convert if they
decide to refer to the module directl
I have reviewed the dependencies of the Open Source projects I
release, and a number of them have optional dependencies. It seems
that Jigsaw currently provides no easy way to convert these projects
to modular jar files:
Joda-Beans
http://www.joda.org/joda-beans/dependencies.html
4 optional
38 matches
Mail list logo
