Re: [orbit-dev] Fwd: [cross-project-issues-dev] Classloading issue when

[David M Williams <david_williams@xxxxxxxxxx>]

Thanks Stephan, 

Regarding the message to cross-project
list, 
http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg10077.html
I'll reply here to orbit-dev, because
its a good opportunity for me, as project lead, to remind us Orbit committers
of a few things. 

A. Orbit is all about providing exemplary,
third-party, OSGi bundles. Combing two "independent" packages
into one bundle just to avoid class loading issues, is never an exemplary
use of OSGi. So, I would object to that solution based on that reason alone.
Plus, I know some clients want us to "decouple" some of the Batik
bundles even more then they are now, so that'd be another reason I would
object. 

B. The problems with Batik 1.7 (in Orbit)
are deep and are multifaceted (i.e. there are at least 5 bugs open on "the
set", the original committers no longer active, and it was never used
for its originally intended purpose (GMF), so is not well tested in complex
scenarios (as far as I know). It is only by someone offering to "take
them over" that they will ever be improved and "finished".
Volunteers welcome! But, we existing committers in Orbit are under no obligation
to take over bundles someone has "left behind" -- especially
to apply a fix that is doubtful. I think we all enjoy helping the community,
which is why I spent half the day coming up with my suggestions in the
bug ... but ... that's not a scalable solution for all of Batik 1.7's Orbit
problems.  I hope someone needs it badly enough they will offer to
"take it over" and fix and finish it for Luna. Otherwise, may
have to put an "unfinished" note on download page, or something.


C. Most of all, that message to cross-project
list gives me a chance to say I share the frustration. I understand the
urge for a "quick and dirty" easy fix completely. In hindsight,
I suspect that "Batik 1.7" probably should not have been "released"
into Orbit, since it was never really finished or tested in its intended
context. As far as I know, its the first time that has happened in Orbit,
and just so happens to be one of the most complex, confusing and tangled
up set of bundles I've ever seen!  (Which, may explain why it was
never finished and used by originally requesting project?) While this one
case wouldn't justify a complex change in rules, if committers have suggestions
on how to avoid this type of "unfinished" case in the future,
let me know. 

If anyone knows "Batik" or
"OSGi" well, any suggestions in Bug 421553,
or comments on my proposed solutions there, would be most helpful. 
Otherwise, we'll wait for Ken and Stephan to test the
suggestions I made for their Scout project. I hope they work to fix their
use-case. 

Thanks, 








From:      
 Stephan Leicht Vogt
<stephan.leicht@xxxxxxxxx>
To:      
 Orbit Developer discussion
<orbit-dev@xxxxxxxxxxx>, 
Date:      
 12/05/2013 12:24 PM
Subject:    
   [orbit-dev]
Fwd: [cross-project-issues-dev] Classloading issue when using Batik 1.7
SVG toolkit
Sent by:    
   orbit-dev-bounces@xxxxxxxxxxx

---

Hi

For your information.

Greetings
Stephan

---

Stephan Leicht Vogt
Senior Software Architect

BSI Business Systems Integration AG
Täfernstrasse 16a, CH-5405 Baden
Phone (direct): +41 56 484 19 47
www.bsiag.com

Forwarded message:

From: Ken Lee Ken.Lee@xxxxxxxxx
To: cross-project-issues-dev@xxxxxxxxxxx cross-project-issues-dev@xxxxxxxxxxx
Subject: [cross-project-issues-dev] Classloading issue when using Batik 1.7 SVG toolkit
Date: Thu, 5 Dec 2013 16:56:45 +0000

I would like to discuss a potential solution the a classloading issue that we encountered in bug [1].
In summary, we use the Batik 1.7 SVG toolkit by using the bundles [2] and [3] from the latest Orbit-S.
Bundle [3] imports the package "org.w3c.dom" without specifying a version constraint and bundle [2] exports the package "org.w3c.dom.events" in version 3.0.0. There's also a package "org.w3c.dom.events" in the JRE. Due to the missing package constraint in [3], the event classes are always loaded from the JRE. However, Batik 1.7 requires the event classes loaded from [2] which leads to a Linkage Error.

Our proposal is to create a new bundle that contains both packages in [2] and [3]. In this case, the event classes will be loaded inside the new bundle and not from the JRE anymore.
Furthermore, [2] contains part of Batik SVG toolkit 1.7 whereas [3] contains Batik SVG toolkit 1.6 sources. The new bundle shouldn't mix the different versioned Batik SVG sources. We might consider to create 2 bundles, one with Batik SVG 1.6 sources and one with SVG 1.7 sources.

Any recommendations or objections?

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=421553
[2] org.w3c.dom.events3.0.0.draft20060413v201105210656
[3] org.w3c.dom.svg_1.1.0.v201011041433

---

cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev[attachment "smime.p7s" deleted by David M Williams/Raleigh/IBM] _______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev