Hi,
Tobias Strasser schrieb:
hi,I would think so. I would greatly appreciate if some more classes would be provided there. For example the ISO8601 class, which additionally might implement the Format interface or even DateFormat abstract class.
as discussed in other threads, there is a need for commons or helper
libraries, containing either JCR related or Jackrabbit related stuff.
for example most of the Value stuff could now be swaped out to a
common jcr helpers lib. further some escaping, formatting and
serializing stuff. The problem is that a lot of those depend on
internal jackrabbit classes like QName, Path and UUID. so those would
also need to go into the common jackrabbit lib.
I see no reason for a Jackrabbit API except perhaps regarding the NodeType Management stuff, which would be nice if it would be available in a way that for example the RMI layer could also provide those without relying on core Jackrabbit.or we should start thinking of a jackrabbit-api. that would contain also those classes.
however:
- what is the general feeling about this?
I providing common API, great care should be taken to create separate libraries for UI (e.g. Servlets) and non-UI (e.g. Path, QName) stuff.
- what would be the names of those libs; is commons-jcr allowed, or isI would definitely say so, otherwise the hole point of reusing common classes would be void.
this reserved to jakarta projects?
- is it ok for jackrabbit core to depend on commons-jackrabbit and commons-jcr ?
Regards Felix
