On 8 September 2011 21:36, Greg Brown <gk_br...@verizon.net> wrote: >> I have only scanned this thread quickly and haven't examined the code, >> but couldn't the SVG stuff be moved into a separate JAR as Sandro >> suggested, after modifying the relevant >> BXMLSerializer/Image/Drawing/whatever classes to find the SVG jar via >> Pivot/Java service loaders? > > The actual SVG stuff is already in a separate JAR (svgSalamander-tiny.jar), > which isn't included with the distribution. The only Pivot class that has a > dependency on it is Drawing, but if an app doesn't use the Drawing class, > then the SVG Salamander classes aren't loaded. So there's no need to use a > service provider - the JVM already takes care of that.
I just looked at the source of the Drawing class and see that it is *ONLY* used for SVGs. The name suggested a much more generic class. Drawing has a dependency on the SVG classes, and then Image references it, and Image is referenced in a lot of places. I meant using a service loader to find a service (Image implementation provider) that could handle SVGs and return an Image. org.apache.pivot.wtk.media.Image.LoadTask.execute() currently instantiates a new Drawing if the extension is 'svg'. That extension could be the basis of a service lookup, which would find the service that might use Drawing (or any other SVG 'provider'). i.e. Don't hard code a reference to the Drawing class into Image. Support for additional Image formats could easily be added by dropping more 'image provider services' jars into the classpath.
