You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-users@xmlgraphics.apache.org by Jess Holle <je...@ptc.com> on 2015/03/27 16:51:28 UTC
SVGDOMImplementation vs. 1.8?
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: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: SVGDOMImplementation vs. 1.8?
Posted by Jess Holle <je...@ptc.com>.
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:
>>>>> batik-users-unsubscribe@xmlgraphics.apache.org
>>>>> For additional commands, e-mail:
>>>>> batik-users-help@xmlgraphics.apache.org
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
>>>> For additional commands, e-mail:
>>>> batik-users-help@xmlgraphics.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
>>> For additional commands, e-mail:
>>> batik-users-help@xmlgraphics.apache.org
>>>
>>>
>>
>
Re: SVGDOMImplementation vs. 1.8?
Posted by Jess Holle <je...@ptc.com>.
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: batik-users-unsubscribe@xmlgraphics.apache.org
>>>> For additional commands, e-mail:
>>>> batik-users-help@xmlgraphics.apache.org
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
>>> For additional commands, e-mail:
>>> batik-users-help@xmlgraphics.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>>
>>
>
Re: SVGDOMImplementation vs. 1.8?
Posted by Jess Holle <je...@ptc.com>.
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: batik-users-unsubscribe@xmlgraphics.apache.org
>>> For additional commands, e-mail:
>>> batik-users-help@xmlgraphics.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
>
Re: SVGDOMImplementation vs. 1.8?
Posted by Robert Marcano <ro...@marcanoonline.com>.
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: batik-users-unsubscribe@xmlgraphics.apache.org
>> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
Re: SVGDOMImplementation vs. 1.8?
Posted by Luis Bernardo <lm...@gmail.com>.
The class was not removed but moved to a different package
(o.a.batik.anim.dom). The reason was
https://issues.apache.org/jira/browse/BATIK-1098, which has been fixed
in 1.8. The option was either to aggregate some jars or to move some
classes to different packages and the latter was chosen.
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.
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: batik-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org