incubator-odf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eero Torri ...@torri.be>
Subject Re: Dependency on Clerezza
Date Wed, 11 Sep 2013 21:03:01 GMT
Hey great,

I've been incredibly busy with some other things but I sure will check this
out this weekend.

My little hobby project is about adding ODF support to a CMS module which
writes metadata of the system into documents
https://code.google.com/r/et-alfresco-metadata-writer/

I thought it would be a nice feature if CMS could push metadata like title,
subject, version number, author into ODF documents and perhaps even be able
to update a change log table within a document with the data from CMS. IMHO
that kind of things would be beneficial for ODF.

Thanks,

--et



On Wed, Sep 11, 2013 at 9:15 PM, Svante Schubert
<svante.schubert@gmail.com>wrote:

> Decided to commit now, so the review/test is easier for you and I do not
> have pending obligations for the week-end..
>
> Svante
>
> Am 11.09.2013 17:56, schrieb Svante Schubert:
> > Hi Eero,
> >
> > Thanks for the problem analysis you offered and sorry for the late
> > reply, as I had been busy to catch some dead lines about to pass by..
> >
> > The dependency you refer to was added by our Google Summer of Code
> > student last year, who had added RDF metadata support to the ODF toolkit.
> >
> > I share your opinion on the dependency that it should be avoided, the
> > method usage should be replaced.
> > The original used method was:
> >
> http://incubator.apache.org/clerezza/mvn-site/utils/apidocs/org/apache/clerezza/utils/UriUtil.html#encodePath(java.lang.String)
> > <
> http://incubator.apache.org/clerezza/mvn-site/utils/apidocs/org/apache/clerezza/utils/UriUtil.html#encodePath%28java.lang.String%29
> >
> >
> > Instead we should use the JDK URI class (since JDK 1.4) with
> > toASCIIString() method, see
> >
> http://docs.oracle.com/javase/6/docs/api/java/net/URI.html#toASCIIString()
> >
> > Therefore became:
> >         try {
> >             ret = new URI(ret).toASCIIString();
> >         } catch (URISyntaxException ex) {
> >             Logger.getLogger(Util.class.getName()).log(Level.SEVERE,
> > null, ex);
> >         }
> >
> > BTW I could not find any further dependency to clerezza via "mvn
> > dependency:tree -Dverbose"
> > Nevertheless as Rob stated already, there are other usages, as the
> > rdf.rdfa package is a SAX-based java RDFa parser.
> > Still I was able to change the dependency from
> >         <dependency>
> >             <groupId>org.apache.clerezza</groupId>
> >             <artifactId>rdf.rdfa</artifactId>
> >             <version>0.1-incubating</version>
> >         </dependency>
> > to
> >         <dependency>
> >             <groupId>net.rootdev</groupId>
> >             <artifactId>java-rdfa</artifactId>
> >             <version>0.4.2</version>
> >         </dependency>
> >
> > The latter has a BSD license and should work out fine.
> >
> > After that I had only to adjust in the GRDDLTest.java, where the
> > Assert, which was strangely set to
> > import com.ibm.icu.impl.Assert;
> > and switched it into
> > import org.junit.Assert;
> >
> > and the build & tests worked out fine under Windows building with "mvn
> > clean install -Ppedantic".
> >
> > If there is no further protest or other suggestions on it, I would
> > commit the changes over the week-end.
> >
> > Best regards,
> > Svante
> >
> > Am 15.08.2013 13:06, schrieb 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/Util.java:28:import org.apache.clerezza.utils.UriException;
> >> ./pkg/rdfa/Util.java:29:import org.apache.clerezza.utils.UriUtil;
> >>
> >> So it uses only the classes called UriException and UriUtil and only in
> one
> >> file
> >>
> >>
> >> 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.
> >>
> >
>
>

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