[EMAIL PROTECTED] escribió:
Tom Schindl schrieb:
I can feel your pain. Thank god I'm using OSGi and can declare my
dependencies explicitly :-)
Yep. Well, it works for those libs that are just internal implementation
details.
I'm not an OSGi expert, but if any exported class contains a public or
protected method that has type T as a parameter or return type, then
aren't you again locked into a single application-wide version of the
lib that provides T?
In OSGi you have a different class loader for each bundle making this
possible. Think of Eclipse (currently I work with Equinox). Bundle
(plugin) X can be using ASM version x.x and Bundle Y can use ASM version
x.y. Unless Bundle Y depends on Bundle X and Bundle X exposes the
conflicting packages of ASM (which is a really bad idea) then you are
safe from the headaches you are talking about. Further on, if you create
two bundles with ASM (version x.x and version x.y) you can specify that
Bundle X uses ASM version x.x and that Bundle Y uses version x.y of ASM
with out any problems.
If so, then OSGi will solve problems for things like ASM which are
usually pure internal details, but will not solve problems for things
like commons libs whose types are commonly part of another lib's
exported API (lang.enums.Enum, lang.math.DoubleRange, etc)...
Obviestly, for java reserved words, this is a dead end. You need to
change package names.
Best regards,
Nacho G. Mac Dowell
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
