jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: contrib/jcr-ext proposal
Date Sat, 12 Feb 2005 12:35:53 GMT
hi jukka,

On Sat, 12 Feb 2005 12:31:34 +0200, Jukka Zitting <jukka@zitting.name> wrote:
> Hi all,
> 
> I've just received committer status with Jackrabbit (thanks for the vote
> of confidence), and would be ready to migrate my private contrib/jcr-ext
> work to the Jackrabbit source repository. Before doing that, I'd like to
> clarify some policy issues raised by Roy.
> 
> Roy T.Fielding wrote:
> > More code sounds great, but I don't want to see a big hierarchy
> > of extension directories.  Please just name them
> >
> >     org.apache.jackrabbit.{meaningful-name}
> >
> > and we'll all work on managing that space.
> 
> I understand the requirement. What I was looking for with the .ext space
> was a grouping of packages that have no dependencies from or to the
> Jackrabbit core packages.
> 
> What would be the policy for managing the org.apache.jackrabbit space?
> For example: Each new top-level package should be proposed on
> jackrabbit-dev before creation. The proposal should contain a
> description of the package (could be used also for package.html) and
> information about who will develop and maintain the package.
> 
> > Contrib should only be used for things that are not managed
> > by the jackrabbit project, with the hopeful intention of moving
> > everything into the main project once the contributor has earned
> > commit status.
> 
> How about the JCR-RMI contrib package? If you want, I could now migrate
> the RMI layer to org.apache.jackrabbit.rmi within the main source tree.
> The Jackrabbit jar would then directly contain the RMI layer.
> 
> However, I'd need to setup separate maven goals to create jars
> containing just the RMI client and server classes. These extra jars
> could be used by other JCR implementations without having to include the
> entire Jackrabbit implementation.
> 
> The same dilemma applies also to the decorator, xml, and other general
> packages I proposed for jcr-ext. Any ideas on how these should be
> handled?

i am a little bit worried that moving jcr-rmi & friends to the main source 
tree will make migrating to a newer jcr api version more difficult. it took 
me a couple of days just to get the current source base compile with 
jcr 0.1.6.2 and tobi, marcel and myself are still busy implementing the 
changed semantics. if jcr-rmi would had been in the same source tree 
i would have had to migrate it also or otherwise the jackrabbit build 
would had been broken.

i am not against moving jcr-rmi in general but for the time being,
while the jcr api is still subject to changes (we're currently working
on 0.16.3 ...), it will make upgrading jackrabbit to newer api versions
easier.

cheers
stefan

> 
> Best regards,
> 
> Jukka Zitting
> 
>

Mime
View raw message