On 11.06.14 08:07, David M Williams wrote:
My main question is ... is this required for Luna? (I assume not, that
it shows up in e4 incubator? so could wait to SR1 if we find a safe,
non-breaking change? Or Mars if breaking?)
No I don't think we can fix the problem in Luna at all.
Second, I've only barely read the details (they make my head spin) but
wondering if it is reasonable for resolver.problem to require Java 8
AND javax.annotaion 1.0.0? That seems quite a mix of old and new? I
assume this is an attempt to be compatible with older bundles that
require javax.annotation 1.0?
The problem is that resolver.problem e.g. makes use of it like this:
class MyPart {
@PostConstruct
public void initUI(Composite comp) {
}
}
and because resolver.problem requires JavaSE-8 it could live without
any javax.annotation import itself and wire to the JRE but the problem
is that this annotation is read by the e4 DI-Container
(org.eclipse.e4.core.di) who himself requires javax.annotation 1.0.0 so
if my bundle gets wired against the JRE and core.di against 1.0.0 it
will of course *not* find my @PostConstruct resulting in the method not
called at all.
My current thinking is that we at e4/platform made the bad choice of not
requireing JavaSE-1.6 2 years ago when we made Eclipse 4 generally
available and so remove the need for javax.annotation bundle.
If it helps, and if you haven't already, you might want to read
https://bugs.eclipse.org/bugs/show_bug.cgi?id=424909#c0and what it
points to, https://bugs.eclipse.org/bugs/show_bug.cgi?id=422981#c5
Now for some wild ideas to show my ignorance ... which helps
occasionally :) ...
I notice in Orbit, all our javax.annotation bundles follow the import
what you export pattern that's good, such as
*Export-Package*: javax.annotation;/version/=1.2.0,
javax.annotation.security;/version/=1.2.0,
javax.annotation.sql;/version/=1.2.0
*Import-Package*: javax.annotation;/version/=1.2.0,
javax.annotation.security;/version/=1.2.0,
javax.annotation.sql;/version/=1.2.0
BUT, in this case, I wonder if we should be so restrictive about what
we import? Would the following be better?
*Export-Package*: javax.annotation;/version/=1.2.0,
javax.annotation.security;/version/=1.2.0,
javax.annotation.sql;/version/=1.2.0
*Import-Package*: javax.annotation,
javax.annotation.security,
javax.annotation.sql
I suppose that's about the same as requiring system.bundle? Just mix
in with what ever in in running JRE? (Which, from
https://bugs.eclipse.org/bugs/show_bug.cgi?id=422981#c5sounds like it
would work, in this case ... that is, high degree of similarity, except
for new things?
I'm just throwing this out as an idea ... only the experts could say if
it makes sense.
As for your suggestion
b) guava does import javax.annotation;1.0.0 instead
I'm assuming our Orbit guava version is what they (the third party)
provides (which is what we always strive for) so you might work with
them, to find out if there's a reason they did it the way they did, if
they'd be willing to change, etc.
I don't think so because from their point of view they are requireing
JavaSE-1.6 and so they can wire to javax.annotation without packages.
They could remove the javax.annotation import completely because they
anyways require JavaSE-1.6
Tom
___
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
