incubator-odf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan O'Meara <>
Subject Re: Dependency on Clerezza
Date Thu, 15 Aug 2013 19:41:33 GMT
Would this do the same thing, with standard Java libraries? I found it with a quick search


String uriTest2(String uri) {
    String encodedUri = null;
    String encoding = "UTF-8";
    try {
        encodedUri = URLEncoder.encode(uri, encoding);
    } catch (UnsupportedEncodingException e) {
        System.err.println("Unsuported encoding: "+encoding);
    return encodedUri;

-Ryan O'Meara

On Aug 15, 2013, at 3:33 PM, Rob Weir <<>>

On Thu, Aug 15, 2013 at 7:06 AM, Eero Torri <<>>
Odftoolkit seems to have a dependency on the Clerezza project.

Clerezza project says that "Clerezza is a service platform based on OSGi
(Open Services Gateway initiative) which provides a set of functionality
for management of semantically linked data accessible through RESTful Web
Services and in a secured way."

Looking further where  odftoolkit uses clerezza:

odfdom et$ grep -Rin clerezza .
./pkg/rdfa/ org.apache.clerezza.utils.UriException;
./pkg/rdfa/ org.apache.clerezza.utils.UriUtil;

So it uses only the classes called UriException and UriUtil and only in one

Now how are they actually used:

               String ret = sb.toString();
               try {
                       ret = UriUtil.encodePath(ret);
               } catch (UriException e) {

Transform string to another string and do nothing if it blows.

This must be some kind of simple mistake.
I don't see how it would be worth importing a "service platform" just to do
URI path encoding.

+1.   This looks like overkill.  Do you know, is there an equivalent
function that could be substituted in, within one of the existing


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message