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 <[email protected]>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. > >> > > > >
