jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: [VOTE] Revert the great split
Date Mon, 12 Sep 2005 08:19:45 GMT
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.


> 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.


View raw message