Jackrabbit 1.5.1 release plan

[Jukka Zitting <ju...@gmail.com>]

Hi,

We already have some fixes for 1.5.0 and I'd like to push them out
quite soon as some of them (most notably the RMI behaviour of the
standalone server) affect the documentation I'm about to write.

Please let me know of any favourite fixes you'd like to see in 1.5.1
by tagging them appropriately in Jira by the end of this week. I'll
target to do the release next week.

BR,

Jukka Zitting

Re: Jackrabbit 1.5.1 release plan

[Felix Meschberger <fm...@gmail.com>]

Felix Meschberger schrieb:
> Hi,
> 
> Jukka Zitting schrieb:
>> Hi,
>>
>> On Tue, Jan 6, 2009 at 12:24 PM, Felix Meschberger <fm...@gmail.com> wrote:
>>> Over in the Sling project more and more people come ask for Access
>>> Control Support. Since we moved to Jackrabbit 1.5 last week, this
>>> functioanlity is basically there (right ?) but some external API is missing.
>>>
>>> So I wonder, whether it would be possible to backport some of the
>>> Security API implementation stuff of JCR-1588 of Rev. 712984 back to the
>>> Jackrabbit 1.5 branch ? Actually part of the JCR-1588 implementation is
>>> already included in the 1.5 branch, so this would probably just be
>>> complimentary, right ?
>> I'd rather only include bug fixes in 1.5.1. Introducing these changes
>> in the 1.5 branch would cause some valid client code to compile and
>> run against 1.5.1 but not against 1.5.0, which may well cause
>> unexpected issues down the line.
> 
> Ok, got it.
> 
> One might of course argue, that not having the
> JackrabbitSession.getAccessManager() and docuemnting on the list to cast
> Session to SessionImpl to get the AccessManager is kind of a bug ;-)

I was just notified by Angela, that this is about
o.a.j.jsr283.Session.getAccessControlManager(). Sorry for the confusion.

Regards
Felix

> 
>> However, I wouldn't mind doing a 1.6.0 release already pretty soon
>> (during Q1). Would that work for Sling?
> 
> Probably, yes, since we have a working work-around right now.
> 
> Regards
> Felix
> 

Re: Jackrabbit 1.5.1 release plan

[Angela Schreiber <an...@day.com>]

> JackrabbitSession.getAccessManager() and docuemnting on the list to cast
> Session to SessionImpl to get the AccessManager is kind of a bug ;-)

just to avoid misunderstandings:

- there is no jackrabbit API interface called AccessManager.
   instead the interface is called *AccessControlManager* and it is
   in the package org.apache.jackrabbit.api.jsr283.security

- the public method to access this manager is called
   *getAccessControlManager()* and it is located on
   *org.apache.jackrabbit.api.jsr283.Session*

- there is no method JackrabbitSession.getAccessManager()
   and there are no plans whatsoever to add it.

regards
angela

Re: Jackrabbit 1.5.1 release plan

[Felix Meschberger <fm...@gmail.com>]

Hi,

Jukka Zitting schrieb:
> Hi,
> 
> On Tue, Jan 6, 2009 at 12:24 PM, Felix Meschberger <fm...@gmail.com> wrote:
>> Over in the Sling project more and more people come ask for Access
>> Control Support. Since we moved to Jackrabbit 1.5 last week, this
>> functioanlity is basically there (right ?) but some external API is missing.
>>
>> So I wonder, whether it would be possible to backport some of the
>> Security API implementation stuff of JCR-1588 of Rev. 712984 back to the
>> Jackrabbit 1.5 branch ? Actually part of the JCR-1588 implementation is
>> already included in the 1.5 branch, so this would probably just be
>> complimentary, right ?
> 
> I'd rather only include bug fixes in 1.5.1. Introducing these changes
> in the 1.5 branch would cause some valid client code to compile and
> run against 1.5.1 but not against 1.5.0, which may well cause
> unexpected issues down the line.

Ok, got it.

One might of course argue, that not having the
JackrabbitSession.getAccessManager() and docuemnting on the list to cast
Session to SessionImpl to get the AccessManager is kind of a bug ;-)

> 
> However, I wouldn't mind doing a 1.6.0 release already pretty soon
> (during Q1). Would that work for Sling?

Probably, yes, since we have a working work-around right now.

Regards
Felix

Re: Jackrabbit 1.5.1 release plan

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Tue, Jan 6, 2009 at 12:24 PM, Felix Meschberger <fm...@gmail.com> wrote:
> Over in the Sling project more and more people come ask for Access
> Control Support. Since we moved to Jackrabbit 1.5 last week, this
> functioanlity is basically there (right ?) but some external API is missing.
>
> So I wonder, whether it would be possible to backport some of the
> Security API implementation stuff of JCR-1588 of Rev. 712984 back to the
> Jackrabbit 1.5 branch ? Actually part of the JCR-1588 implementation is
> already included in the 1.5 branch, so this would probably just be
> complimentary, right ?

I'd rather only include bug fixes in 1.5.1. Introducing these changes
in the 1.5 branch would cause some valid client code to compile and
run against 1.5.1 but not against 1.5.0, which may well cause
unexpected issues down the line.

However, I wouldn't mind doing a 1.6.0 release already pretty soon
(during Q1). Would that work for Sling?

BR,

Jukka Zitting

Re: Jackrabbit 1.5.1 release plan

[Felix Meschberger <fm...@gmail.com>]

Hi,

So here is my wish ;-)

Over in the Sling project more and more people come ask for Access
Control Support. Since we moved to Jackrabbit 1.5 last week, this
functioanlity is basically there (right ?) but some external API is missing.

So I wonder, whether it would be possible to backport some of the
Security API implementation stuff of JCR-1588 of Rev. 712984 back to the
Jackrabbit 1.5 branch ? Actually part of the JCR-1588 implementation is
already included in the 1.5 branch, so this would probably just be
complimentary, right ?

[Background info: The getAccessManager method is currently only
available from the Jackrabbit SessionImpl. Since we don't have this
class in Sling, I have implemented a utility method to use reflection to
find and call the method... Having the proper API, would be much better.]

Thanks and Regards
Felix

Jukka Zitting schrieb:
> Hi,
> 
> We already have some fixes for 1.5.0 and I'd like to push them out
> quite soon as some of them (most notably the RMI behaviour of the
> standalone server) affect the documentation I'm about to write.
> 
> Please let me know of any favourite fixes you'd like to see in 1.5.1
> by tagging them appropriately in Jira by the end of this week. I'll
> target to do the release next week.
> 
> BR,
> 
> Jukka Zitting
> 

Re: Jackrabbit 1.5.1 release plan

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Thu, Jan 8, 2009 at 8:04 PM, Felix Meschberger <fm...@gmail.com> wrote:
> Jukka Zitting schrieb:
>> I'm inclined to upgrade all the dependent components so that the 1.5.1
>> build will not end up referring to two different versions of the same
>> component.
>
> No, I would neither upgrade nor release any dependent component. This
> would be very confusing and not worth the effort.

It looks like at least jackrabbit-webdav needs to be bumped to 1.5.1
with the upgraded jcr-commons dependency as it is affected by the
JCR-1926 issue.

The components that are not changed since 1.5.0 (in the 1.5 branch)
and not affected by JCR-1926 are: classloader, jcr-rmi, jcr2spi,
spi-commons and spi2jcr.

I guess we have more people looking at the Maven repository and
wondering whether they should upgrade their dependencies than we have
people looking at the source build and wondering why these components
are pulling in an earlier version of jcr-commons when a more recent
one is right there to be used.

Well, at least the proposed new subproject will help avoid similar
issues in future by giving many of these components their own
independent release cycles.

BR,

Jukka Zitting

Re: Jackrabbit 1.5.1 release plan

[Felix Meschberger <fm...@gmail.com>]

Hi,

Jukka Zitting schrieb:
> Hi,
> 
> Here's a tricky question: Now that we have a fix to
> jackrabbit-jcr-commons that's scheduled for 1.5.1 (JCR-1926), should
> all the components in the 1.5 branch that depend on jcr-commons also
> be updated?
> 
> For example, jackrabbit-classloader 1.5.0 depends on
> jackrabbit-jcr-commons 1.5.0. Should we update the classloader
> component in Jackrabbit 1.5.1 to depend on jcr-commons 1.5.1, or
> should it remain at version 1.5.0 with the old dependency. Note that
> AFAIK the classloader component does not even use the method fixed in
> JCR-1926.
> 
> I'm inclined to upgrade all the dependent components so that the 1.5.1
> build will not end up referring to two different versions of the same
> component.

No, I would neither upgrade nor release any dependent component. This
would be very confusing and not worth the effort.

Regards
Felix

Re: Jackrabbit 1.5.1 release plan

[Jukka Zitting <ju...@gmail.com>]

Hi,

Here's a tricky question: Now that we have a fix to
jackrabbit-jcr-commons that's scheduled for 1.5.1 (JCR-1926), should
all the components in the 1.5 branch that depend on jcr-commons also
be updated?

For example, jackrabbit-classloader 1.5.0 depends on
jackrabbit-jcr-commons 1.5.0. Should we update the classloader
component in Jackrabbit 1.5.1 to depend on jcr-commons 1.5.1, or
should it remain at version 1.5.0 with the old dependency. Note that
AFAIK the classloader component does not even use the method fixed in
JCR-1926.

I'm inclined to upgrade all the dependent components so that the 1.5.1
build will not end up referring to two different versions of the same
component.

BR,

Jukka Zitting