You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-commits@xmlgraphics.apache.org by ma...@apache.org on 2008/08/24 15:12:02 UTC
svn commit: r688508 - in /xmlgraphics/fop/trunk: lib/
src/java/org/apache/fop/apps/ src/java/org/apache/fop/util/
test/java/org/apache/fop/ test/java/org/apache/fop/util/
Author: maxberger
Date: Sun Aug 24 06:12:02 2008
New Revision: 688508
URL: http://svn.apache.org/viewvc?rev=688508&view=rev
Log:
Moved DataURIResolver from FOP to commons; use new URIResolver registry
Removed:
xmlgraphics/fop/trunk/src/java/org/apache/fop/util/DataURIResolver.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/util/DataURLUtil.java
xmlgraphics/fop/trunk/src/java/org/apache/fop/util/WriterOutputStream.java
xmlgraphics/fop/trunk/test/java/org/apache/fop/util/DataURIResolverTestCase.java
Modified:
xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.4svn.jar
xmlgraphics/fop/trunk/src/java/org/apache/fop/apps/FOURIResolver.java
xmlgraphics/fop/trunk/test/java/org/apache/fop/UtilityCodeTestSuite.java
Modified: xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.4svn.jar
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.4svn.jar?rev=688508&r1=688507&r2=688508&view=diff
==============================================================================
Binary files - no diff available.
Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/apps/FOURIResolver.java
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/src/java/org/apache/fop/apps/FOURIResolver.java?rev=688508&r1=688507&r2=688508&view=diff
==============================================================================
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/apps/FOURIResolver.java (original)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/apps/FOURIResolver.java Sun Aug 24 06:12:02 2008
@@ -34,14 +34,12 @@
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
-
import org.apache.xmlgraphics.util.io.Base64EncodeStream;
-
-import org.apache.fop.util.DataURIResolver;
+import org.apache.xmlgraphics.util.uri.CommonURIResolver;
/**
* Provides FOP specific URI resolution. This is the default URIResolver
- * {@link FOUserAgent} will use unless overidden.
+ * {@link FOUserAgent} will use unless overridden.
*
* @see javax.xml.transform.URIResolver
*/
@@ -50,8 +48,8 @@
// log
private Log log = LogFactory.getLog("FOP");
- /** URIResolver for RFC 2397 data URLs */
- private URIResolver dataURIResolver = new DataURIResolver();
+ /** Common URIResolver */
+ private URIResolver commonURIResolver = CommonURIResolver.getInstance();
/** A user settable URI Resolver */
private URIResolver uriResolver = null;
@@ -152,7 +150,7 @@
// data URLs can be quite long so evaluate early and don't try to build a File
// (can lead to problems)
- source = dataURIResolver.resolve(href, base);
+ source = commonURIResolver.resolve(href, base);
// Custom uri resolution
if (source == null && uriResolver != null) {
Modified: xmlgraphics/fop/trunk/test/java/org/apache/fop/UtilityCodeTestSuite.java
URL: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/test/java/org/apache/fop/UtilityCodeTestSuite.java?rev=688508&r1=688507&r2=688508&view=diff
==============================================================================
--- xmlgraphics/fop/trunk/test/java/org/apache/fop/UtilityCodeTestSuite.java (original)
+++ xmlgraphics/fop/trunk/test/java/org/apache/fop/UtilityCodeTestSuite.java Sun Aug 24 06:12:02 2008
@@ -26,7 +26,6 @@
import org.apache.fop.pdf.PDFObjectTestCase;
import org.apache.fop.traits.BorderPropsTestCase;
import org.apache.fop.util.ColorUtilTestCase;
-import org.apache.fop.util.DataURIResolverTestCase;
import org.apache.fop.util.ElementListUtilsTestCase;
import org.apache.fop.util.PDFNumberTestCase;
import org.apache.fop.util.XMLResourceBundleTestCase;
@@ -49,7 +48,6 @@
suite.addTest(new TestSuite(ColorUtilTestCase.class));
suite.addTest(new TestSuite(BorderPropsTestCase.class));
suite.addTest(new TestSuite(ElementListUtilsTestCase.class));
- suite.addTest(new TestSuite(DataURIResolverTestCase.class));
suite.addTest(new TestSuite(BasicEventTestCase.class));
suite.addTest(new TestSuite(XMLResourceBundleTestCase.class));
//$JUnit-END$
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-commits-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-commits-help@xmlgraphics.apache.org
Re: URIResolvers
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
On 25.08.2008 10:33:37 Max Berger wrote:
> Jeremias,
>
> Jeremias Maerki schrieb:
> > (Moving to general as we're talking about code in Commons, not FOP)
> >
> > Thanks for sharing. I have two observations here:
> > 1. CommonURIResolver is final and designed as a Singleton. In my past
> > experience that restricts its usefulness too much.
>
> Noted. I'll make it public and rename the getInstance to getDefault...
Thanks.
> > 2. It should be noted that this approach here only allows "general"
> > resolvers. There's no access to "local" configuration or context
> > information that allows customizing the behaviour. Such URI resolver
> > will still have to be set up by the users.
>
> The URIResolver in FOP will probably have to stay very similar to the
> way it works right now, for that exact reason.
I don't mean to imply that anything should be changed now. I'm just
noting the consequence of the design decision.
> > I'm curious: what kind of URI resolver do you want to add here from a
> > plug-in that motivated you to do this?
>
> One that resolves well-known URIs to embedded URIs. In particular URIs
> such as
> "http://www.w3.org/Math/DTD/mathml2/mathml2.dtd" and
> "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd" would be mapped to
> jar:... for faster (and in particular offline) resolution.
>
> For testing purposes, the xml: URI seems like a very interesting addition.
Ah, makes sense. Thanks. And the W3C web admins will be very happy about
this. ;-)
>
> Max
>
>
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: URIResolvers
Posted by Max Berger <ma...@berger.name>.
Jeremias,
Jeremias Maerki schrieb:
> (Moving to general as we're talking about code in Commons, not FOP)
>
> Thanks for sharing. I have two observations here:
> 1. CommonURIResolver is final and designed as a Singleton. In my past
> experience that restricts its usefulness too much.
Noted. I'll make it public and rename the getInstance to getDefault...
> 2. It should be noted that this approach here only allows "general"
> resolvers. There's no access to "local" configuration or context
> information that allows customizing the behaviour. Such URI resolver
> will still have to be set up by the users.
The URIResolver in FOP will probably have to stay very similar to the
way it works right now, for that exact reason.
> I'm curious: what kind of URI resolver do you want to add here from a
> plug-in that motivated you to do this?
One that resolves well-known URIs to embedded URIs. In particular URIs
such as
"http://www.w3.org/Math/DTD/mathml2/mathml2.dtd" and
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd" would be mapped to
jar:... for faster (and in particular offline) resolution.
For testing purposes, the xml: URI seems like a very interesting addition.
Max
Re: URIResolvers
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
(Moving to general as we're talking about code in Commons, not FOP)
Thanks for sharing. I have two observations here:
1. CommonURIResolver is final and designed as a Singleton. In my past
experience that restricts its usefulness too much. If you look at all
the "registries" in FOP you'll see that they are not singletons but
attached to the FopFactory (which isn't a singleton either). That allows
to have multiple "environments" inside the same JVM/classloader setup if
someone desires that. If someone wants a singleton for a particular
purpose he can always do so easily. But if it's already a singleton you
are locked in. Anyway, I've made it a habit of avoiding singletons
whenever possible.
2. It should be noted that this approach here only allows "general"
resolvers. There's no access to "local" configuration or context
information that allows customizing the behaviour. Such URI resolver
will still have to be set up by the users.
I'm curious: what kind of URI resolver do you want to add here from a
plug-in that motivated you to do this?
On 25.08.2008 08:47:39 Max Berger wrote:
> Jeremias,
>
> my fault again. You are absolutely right, I should provide a
> "deprecated" version of the old classes in all cases, and probably
> discuss the idea.
>
> I'll do the later today, and here's the second one:
>
> Background is this thread [1] which showed a flaw in the way FOP
> resolves URIs.
>
> Current Situation:
> * FOP provides support for 1 Custom Resolver
> * It also adds the data: URI resolver
> * and has a sophisticated resolving method for other URIs which are
> openable through URL.open (better than the JDK default)
>
> Problem:
> A plugin cannot add a URIResolver to FOP, as there is only 1 custom
> resolver, and it is defined by the user.
>
> Main Idea:
> Support a generic "chain" of URIResolvers. All URI resolvers are called
> in order, if one of them can resolve the URI it will return a source,
> otherwise null.
>
> Implementation Idea:
> Need a URIResolver registry, like the ImageLoader registry. It should
> automatically load all URIResolvers declared as service, and provide
> register() and unregister() functionality.
>
> A Generic URI resolver will then try all registered resolvers first, and
> then fall back to the default (which would be the functionality as it is
> in FOP now).
>
> Plugins can then register their own URI resolver, which could either add
> URIs (there are some examples of a XML: URI in commons, which would be
> interesting), or provide mapping for well-known URIs, such as the ones
> of DTDs and entities.
>
> [1]
> http://www.nabble.com/Getting-Batik-to-read-SVG-DTDs-via-catalog-resolver-td18169780.html
>
> Hope this makes sense
>
> Max
>
> Jeremias Maerki schrieb:
> > I'm seeing a new pattern here and I'm not entirely happy about it. I'd
> > prefer at least a short deprecation time (one release) before final
> > removal. Also a short discussion or at least an advance notice about
> > someone's intentions and motivations would be appreciated. But maybe
> > that's only me.
> >
> > On 24.08.2008 15:12:02 maxberger wrote:
> >> Author: maxberger
> >> Date: Sun Aug 24 06:12:02 2008
> >> New Revision: 688508
> >>
> >> URL: http://svn.apache.org/viewvc?rev=688508&view=rev
> >> Log:
> >> Moved DataURIResolver from FOP to commons; use new URIResolver registry
> >>
> >> Removed:
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/DataURIResolver.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/DataURLUtil.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/WriterOutputStream.java
> >> xmlgraphics/fop/trunk/test/java/org/apache/fop/util/DataURIResolverTestCase.java
> >> Modified:
> >> xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.4svn.jar
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/apps/FOURIResolver.java
> >> xmlgraphics/fop/trunk/test/java/org/apache/fop/UtilityCodeTestSuite.java
> >
> >
> > On 20.08.2008 17:13:56 acumiskey wrote:
> >> Author: acumiskey
> >> Date: Wed Aug 20 08:13:56 2008
> >> New Revision: 687369
> >>
> >> URL: http://svn.apache.org/viewvc?rev=687369&view=rev
> >> Log:
> >> * Updated xmlgraphics-commons-14svn.jar to reflect UnitConv additions.
> >> * Removed UnitConv and its unit test case (now resides in commons).
> >> * Updated all fop util package references fpr UnitConv to xmlgraphics commons util package.
> >>
> >> Removed:
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/UnitConv.java
> >> xmlgraphics/fop/trunk/test/java/org/apache/fop/util/UnitConvTestCase.java
> >> Modified:
> >> xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.4svn.jar
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/AbstractGraphics2DAdapter.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/AbstractPathOrientedRenderer.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLGenerator.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLGraphics2D.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLGraphics2DAdapter.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLPageDefinition.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLRenderer.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/txt/TXTRenderer.java
> >> xmlgraphics/fop/trunk/test/java/org/apache/fop/UtilityCodeTestSuite.java
> >
> >
> >
> > Jeremias Maerki
> >
>
>
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org
Re: URIResolvers
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
(Moving to general as we're talking about code in Commons, not FOP)
Thanks for sharing. I have two observations here:
1. CommonURIResolver is final and designed as a Singleton. In my past
experience that restricts its usefulness too much. If you look at all
the "registries" in FOP you'll see that they are not singletons but
attached to the FopFactory (which isn't a singleton either). That allows
to have multiple "environments" inside the same JVM/classloader setup if
someone desires that. If someone wants a singleton for a particular
purpose he can always do so easily. But if it's already a singleton you
are locked in. Anyway, I've made it a habit of avoiding singletons
whenever possible.
2. It should be noted that this approach here only allows "general"
resolvers. There's no access to "local" configuration or context
information that allows customizing the behaviour. Such URI resolver
will still have to be set up by the users.
I'm curious: what kind of URI resolver do you want to add here from a
plug-in that motivated you to do this?
On 25.08.2008 08:47:39 Max Berger wrote:
> Jeremias,
>
> my fault again. You are absolutely right, I should provide a
> "deprecated" version of the old classes in all cases, and probably
> discuss the idea.
>
> I'll do the later today, and here's the second one:
>
> Background is this thread [1] which showed a flaw in the way FOP
> resolves URIs.
>
> Current Situation:
> * FOP provides support for 1 Custom Resolver
> * It also adds the data: URI resolver
> * and has a sophisticated resolving method for other URIs which are
> openable through URL.open (better than the JDK default)
>
> Problem:
> A plugin cannot add a URIResolver to FOP, as there is only 1 custom
> resolver, and it is defined by the user.
>
> Main Idea:
> Support a generic "chain" of URIResolvers. All URI resolvers are called
> in order, if one of them can resolve the URI it will return a source,
> otherwise null.
>
> Implementation Idea:
> Need a URIResolver registry, like the ImageLoader registry. It should
> automatically load all URIResolvers declared as service, and provide
> register() and unregister() functionality.
>
> A Generic URI resolver will then try all registered resolvers first, and
> then fall back to the default (which would be the functionality as it is
> in FOP now).
>
> Plugins can then register their own URI resolver, which could either add
> URIs (there are some examples of a XML: URI in commons, which would be
> interesting), or provide mapping for well-known URIs, such as the ones
> of DTDs and entities.
>
> [1]
> http://www.nabble.com/Getting-Batik-to-read-SVG-DTDs-via-catalog-resolver-td18169780.html
>
> Hope this makes sense
>
> Max
>
> Jeremias Maerki schrieb:
> > I'm seeing a new pattern here and I'm not entirely happy about it. I'd
> > prefer at least a short deprecation time (one release) before final
> > removal. Also a short discussion or at least an advance notice about
> > someone's intentions and motivations would be appreciated. But maybe
> > that's only me.
> >
> > On 24.08.2008 15:12:02 maxberger wrote:
> >> Author: maxberger
> >> Date: Sun Aug 24 06:12:02 2008
> >> New Revision: 688508
> >>
> >> URL: http://svn.apache.org/viewvc?rev=688508&view=rev
> >> Log:
> >> Moved DataURIResolver from FOP to commons; use new URIResolver registry
> >>
> >> Removed:
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/DataURIResolver.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/DataURLUtil.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/WriterOutputStream.java
> >> xmlgraphics/fop/trunk/test/java/org/apache/fop/util/DataURIResolverTestCase.java
> >> Modified:
> >> xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.4svn.jar
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/apps/FOURIResolver.java
> >> xmlgraphics/fop/trunk/test/java/org/apache/fop/UtilityCodeTestSuite.java
> >
> >
> > On 20.08.2008 17:13:56 acumiskey wrote:
> >> Author: acumiskey
> >> Date: Wed Aug 20 08:13:56 2008
> >> New Revision: 687369
> >>
> >> URL: http://svn.apache.org/viewvc?rev=687369&view=rev
> >> Log:
> >> * Updated xmlgraphics-commons-14svn.jar to reflect UnitConv additions.
> >> * Removed UnitConv and its unit test case (now resides in commons).
> >> * Updated all fop util package references fpr UnitConv to xmlgraphics commons util package.
> >>
> >> Removed:
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/UnitConv.java
> >> xmlgraphics/fop/trunk/test/java/org/apache/fop/util/UnitConvTestCase.java
> >> Modified:
> >> xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.4svn.jar
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/AbstractGraphics2DAdapter.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/AbstractPathOrientedRenderer.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLGenerator.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLGraphics2D.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLGraphics2DAdapter.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLPageDefinition.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLRenderer.java
> >> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/txt/TXTRenderer.java
> >> xmlgraphics/fop/trunk/test/java/org/apache/fop/UtilityCodeTestSuite.java
> >
> >
> >
> > Jeremias Maerki
> >
>
>
Jeremias Maerki
URIResolvers (Re: (Re)moving without deprecating?)
Posted by Max Berger <ma...@berger.name>.
Jeremias,
my fault again. You are absolutely right, I should provide a
"deprecated" version of the old classes in all cases, and probably
discuss the idea.
I'll do the later today, and here's the second one:
Background is this thread [1] which showed a flaw in the way FOP
resolves URIs.
Current Situation:
* FOP provides support for 1 Custom Resolver
* It also adds the data: URI resolver
* and has a sophisticated resolving method for other URIs which are
openable through URL.open (better than the JDK default)
Problem:
A plugin cannot add a URIResolver to FOP, as there is only 1 custom
resolver, and it is defined by the user.
Main Idea:
Support a generic "chain" of URIResolvers. All URI resolvers are called
in order, if one of them can resolve the URI it will return a source,
otherwise null.
Implementation Idea:
Need a URIResolver registry, like the ImageLoader registry. It should
automatically load all URIResolvers declared as service, and provide
register() and unregister() functionality.
A Generic URI resolver will then try all registered resolvers first, and
then fall back to the default (which would be the functionality as it is
in FOP now).
Plugins can then register their own URI resolver, which could either add
URIs (there are some examples of a XML: URI in commons, which would be
interesting), or provide mapping for well-known URIs, such as the ones
of DTDs and entities.
[1]
http://www.nabble.com/Getting-Batik-to-read-SVG-DTDs-via-catalog-resolver-td18169780.html
Hope this makes sense
Max
Jeremias Maerki schrieb:
> I'm seeing a new pattern here and I'm not entirely happy about it. I'd
> prefer at least a short deprecation time (one release) before final
> removal. Also a short discussion or at least an advance notice about
> someone's intentions and motivations would be appreciated. But maybe
> that's only me.
>
> On 24.08.2008 15:12:02 maxberger wrote:
>> Author: maxberger
>> Date: Sun Aug 24 06:12:02 2008
>> New Revision: 688508
>>
>> URL: http://svn.apache.org/viewvc?rev=688508&view=rev
>> Log:
>> Moved DataURIResolver from FOP to commons; use new URIResolver registry
>>
>> Removed:
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/DataURIResolver.java
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/DataURLUtil.java
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/WriterOutputStream.java
>> xmlgraphics/fop/trunk/test/java/org/apache/fop/util/DataURIResolverTestCase.java
>> Modified:
>> xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.4svn.jar
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/apps/FOURIResolver.java
>> xmlgraphics/fop/trunk/test/java/org/apache/fop/UtilityCodeTestSuite.java
>
>
> On 20.08.2008 17:13:56 acumiskey wrote:
>> Author: acumiskey
>> Date: Wed Aug 20 08:13:56 2008
>> New Revision: 687369
>>
>> URL: http://svn.apache.org/viewvc?rev=687369&view=rev
>> Log:
>> * Updated xmlgraphics-commons-14svn.jar to reflect UnitConv additions.
>> * Removed UnitConv and its unit test case (now resides in commons).
>> * Updated all fop util package references fpr UnitConv to xmlgraphics commons util package.
>>
>> Removed:
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/UnitConv.java
>> xmlgraphics/fop/trunk/test/java/org/apache/fop/util/UnitConvTestCase.java
>> Modified:
>> xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.4svn.jar
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/AbstractGraphics2DAdapter.java
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/AbstractPathOrientedRenderer.java
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLGenerator.java
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLGraphics2D.java
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLGraphics2DAdapter.java
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLPageDefinition.java
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLRenderer.java
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/txt/TXTRenderer.java
>> xmlgraphics/fop/trunk/test/java/org/apache/fop/UtilityCodeTestSuite.java
>
>
>
> Jeremias Maerki
>
Re: (Re)moving without deprecating?
Posted by Adrian Cumiskey <ad...@gmail.com>.
Jeremias,
My intentions and motivations were simple really, I was making use of the FOP UnitConv class in the
branch work and noticed an identical class (in every way apart from package name) existing in
xmlgraphics commons. So I simply spent 10 mins removing the duplication.
I have now provided a deprecated UnitConv class in FOP to cater for the possibility that someone may
have been using it.
Adrian.
Jeremias Maerki wrote:
> I'm seeing a new pattern here and I'm not entirely happy about it. I'd
> prefer at least a short deprecation time (one release) before final
> removal. Also a short discussion or at least an advance notice about
> someone's intentions and motivations would be appreciated. But maybe
> that's only me.
>
> On 24.08.2008 15:12:02 maxberger wrote:
>> Author: maxberger
>> Date: Sun Aug 24 06:12:02 2008
>> New Revision: 688508
>>
>> URL: http://svn.apache.org/viewvc?rev=688508&view=rev
>> Log:
>> Moved DataURIResolver from FOP to commons; use new URIResolver registry
>>
>> Removed:
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/DataURIResolver.java
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/DataURLUtil.java
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/WriterOutputStream.java
>> xmlgraphics/fop/trunk/test/java/org/apache/fop/util/DataURIResolverTestCase.java
>> Modified:
>> xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.4svn.jar
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/apps/FOURIResolver.java
>> xmlgraphics/fop/trunk/test/java/org/apache/fop/UtilityCodeTestSuite.java
>
>
> On 20.08.2008 17:13:56 acumiskey wrote:
>> Author: acumiskey
>> Date: Wed Aug 20 08:13:56 2008
>> New Revision: 687369
>>
>> URL: http://svn.apache.org/viewvc?rev=687369&view=rev
>> Log:
>> * Updated xmlgraphics-commons-14svn.jar to reflect UnitConv additions.
>> * Removed UnitConv and its unit test case (now resides in commons).
>> * Updated all fop util package references fpr UnitConv to xmlgraphics commons util package.
>>
>> Removed:
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/UnitConv.java
>> xmlgraphics/fop/trunk/test/java/org/apache/fop/util/UnitConvTestCase.java
>> Modified:
>> xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.4svn.jar
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/AbstractGraphics2DAdapter.java
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/AbstractPathOrientedRenderer.java
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLGenerator.java
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLGraphics2D.java
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLGraphics2DAdapter.java
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLPageDefinition.java
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLRenderer.java
>> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/txt/TXTRenderer.java
>> xmlgraphics/fop/trunk/test/java/org/apache/fop/UtilityCodeTestSuite.java
>
>
>
> Jeremias Maerki
>
>
(Re)moving without deprecating?
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
I'm seeing a new pattern here and I'm not entirely happy about it. I'd
prefer at least a short deprecation time (one release) before final
removal. Also a short discussion or at least an advance notice about
someone's intentions and motivations would be appreciated. But maybe
that's only me.
On 24.08.2008 15:12:02 maxberger wrote:
> Author: maxberger
> Date: Sun Aug 24 06:12:02 2008
> New Revision: 688508
>
> URL: http://svn.apache.org/viewvc?rev=688508&view=rev
> Log:
> Moved DataURIResolver from FOP to commons; use new URIResolver registry
>
> Removed:
> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/DataURIResolver.java
> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/DataURLUtil.java
> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/WriterOutputStream.java
> xmlgraphics/fop/trunk/test/java/org/apache/fop/util/DataURIResolverTestCase.java
> Modified:
> xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.4svn.jar
> xmlgraphics/fop/trunk/src/java/org/apache/fop/apps/FOURIResolver.java
> xmlgraphics/fop/trunk/test/java/org/apache/fop/UtilityCodeTestSuite.java
On 20.08.2008 17:13:56 acumiskey wrote:
> Author: acumiskey
> Date: Wed Aug 20 08:13:56 2008
> New Revision: 687369
>
> URL: http://svn.apache.org/viewvc?rev=687369&view=rev
> Log:
> * Updated xmlgraphics-commons-14svn.jar to reflect UnitConv additions.
> * Removed UnitConv and its unit test case (now resides in commons).
> * Updated all fop util package references fpr UnitConv to xmlgraphics commons util package.
>
> Removed:
> xmlgraphics/fop/trunk/src/java/org/apache/fop/util/UnitConv.java
> xmlgraphics/fop/trunk/test/java/org/apache/fop/util/UnitConvTestCase.java
> Modified:
> xmlgraphics/fop/trunk/lib/xmlgraphics-commons-1.4svn.jar
> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/AbstractGraphics2DAdapter.java
> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/AbstractPathOrientedRenderer.java
> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLGenerator.java
> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLGraphics2D.java
> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLGraphics2DAdapter.java
> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLPageDefinition.java
> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/pcl/PCLRenderer.java
> xmlgraphics/fop/trunk/src/java/org/apache/fop/render/txt/TXTRenderer.java
> xmlgraphics/fop/trunk/test/java/org/apache/fop/UtilityCodeTestSuite.java
Jeremias Maerki