One additional note:

Modularity is good, but....

I find the number of Batik jars confusing enough that for runtime usage I just include them all.

For build/compilation purposes I'd due the same if I could use wildcards, but in the case of many types of tooling (e.g. typical Ant usage) you end up having to list each jar individually -- at which point I end up adding exactly what I need to get things to build. It's not that I /want/ to express this granularity of dependency, though -- I'd rather just express a dependency on "batik" and be done.

--
Jess Holle

On 3/27/2015 11:42 AM, Jess Holle wrote:
P.S. Thanks for the quick and effective help.

I would like to point out, however, that moving a public API between packages:

 1. Breaks binary compatibility and therefore should be avoided if at
    all possible (perhaps mashing the jars together would have been
    better)
 2. Should really be explicitly noted in the release notes to avoid
    such confusion

--
Jess Holle

On 3/27/2015 11:31 AM, Jess Holle wrote:
We don't read SVGs from our users, /but/ most security folk just see a security vulnerability and expect that a fixed version be used, period.

They don't care that you'll never actually trigger it in your library usage -- they don't bother mincing such fine details.

On 3/27/2015 11:26 AM, Robert Marcano wrote:
On 03/27/2015 11:46 AM, Luis Bernardo wrote:

...
>
Note that unless you need to use CMYK colors or you face some of few
bugs that have been fixed since 1.7 there is no need to upgrade. Batik
has been mostly inactive since 1.7 and the main developments in Batik
(except for CMYK) are only likely to be noticeable if you use FOP.

There is security vulnerability on 1.7 (CVE-2015-0250). Unless a 7.1.1 is released with the fix, a migration to 1.8 is a must if you read SVGs from users


On 3/27/15 4:51 PM, Jess Holle wrote:
Batik 1.8 seems to have removed the
org.apache.batik.dom.svg.SVGDOMImplementation class, whereas this
class is present in 1.7.

Yet the Batik site itself provides examples using this class.

So what's the story here?

I ask as I am trying to move to Batik 1.8, but we have a class which
is using SVGDOMImplementation (for its SVG_NAMESPACE_URI constant and
its getDOMImplementation() method) and thus cannot currently move to 1.8.

I am mystified as to how I am supposed to be able to move to 1.8 --
and why this API change is not clearly noted in the release notes.

--
Jess Holle


---------------------------------------------------------------------
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]



---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]





Reply via email to