Tobias Bocanegra wrote:
it seems, that the majority wants to switch back to the old structure.
before moving the files, i suggest to think about the repackaging as
suggested by roy.
commons will go to: org.apache.jackrabbit.util.*
to me this change does not add any additional meaning to the package.
util says as much / little as commons. I suggest to mostly keep the
package naming for classes we currently have in commons. e.g. classes
that deal with values are in package value. This makes perfectly sense
to me, and I don't see why we should move all that to o.a.j.util.value.
Another discussion is how we name the artifact resulting from those
classes. jackrabbit-commons.jar or jackrabbit-util.jar, both are fine
with me.
core will go to: org.apache.jackrabbit.jcr.*
I think this actually weakens the meaning of what this package contains,
since jackrabbit is per definition an implementation of jcr. The first
sentence on the jackrabbit site is: "The Jackrabbit Project has been
formed to develop an open source implementation of the Content
Repository for Java Technology API (JCR)..."
To me 'core' is currently as close as we can get to describe what the
packages are about. It's the core of jackrabbit, which implements the
JCR standard. But I'm always open to better names ;)
I know this is a weak argument, but still, there are numerous jakarta
projects that use core as a package name.
api would go to: org.apache.jackrabbit.* but is currently empty.
i'm not happy with the api packaging, but i can't come up with a
better solution.
dito.
please note, that the refactoring will break all existing
configurations, since the class names (eg of the persistence managers)
are referenced in the xmls. maybe we could provide a backward
compatibility mapping in the config reader which logs a deprecation
warning. on the other hand, 1.0 is not released yet, and we should not
respect backward compatibility too much.
+1 to not care about backward compatibility at this point.
regards
marcel
