On 11 Feb 2010, at 20:49, Justin Edelson wrote:
> On 2/11/10 3:12 PM, Ian Boston wrote:
>>> I think we should just update to jcr 2.
>>
>> Ok, I have two questions.
>> How much work is this inside Sling (I am assuming the branch for 2 is there
>> already) and ?
>
> Felix created a branch in SVN a while back. I have a Jackrabbit 2 branch
> at github (http://github.com/justinedelson/sling/tree/jr2) which is
> pretty up-to-date. Latest code review in
> http://codereview.appspot.com/207067
>
>> What will it impact in terms of bundles, just the server bundle or are there
>> changes all over the code base ?
>
> Looks like:
> jcr.base
> jcr.contentloader
> jcr.jackrabbit-accessmanager
> jcr.jackrabbit-server
> jcr.webdav
Assuming that the concepts in ACL dont change, then being totally selfish for a
moment,
I will have to port local modifications to jackrabbit-server and contentloader.
This isnt a big problem, and certainly should not stop this happening, but it
does raise another issue.
AFAICT, there are a number of bundles that haven't been released, and perhaps
before moving to JR2 we should consider doing releases of the above set so
those who cant upgrade for whatever reason has a release they can bind do.
Last releases
jcr.base 2.0.4 14 May 2009
2.1.0 has one open issue (SLING-1366), in reality this should be 2.0.5 is 1366
is reverted.
depends on
jcr.api 2.0.7-SNAPSHOT, would need SLING-1363 reverting to release as
2.0.8
jcr.contentloader 2.0.4 14 May 2009
2.0.6 has no open issues
2.0.8 no issues (at all)
no SNAPSHOT dependencies
jcr.accessmanager 2.0.2 14 May 2009
next release 2.0.4
no open issues
no SNAPSHOT dependencies
jcr.server 14 May 2009
next release 2.0.6
2 open issues (look like they can be closed)
depends on jcr.base 2.0.5-SNAPSHOT (which would be released)
no other SNAPSHOT dependencies
jcr.webdav 2.0.6 14 May 2009
next release 2.0.8
no open issues
no SNAPSHOT dependencies
---------------------------------
If we reverted jcr.base back to the 2.0.6 target (temporarily reverting
SLING-1363 and related), adjusted server, then we could release all of the
above, giving the community a release to bind to before this change. I don't
think its a massive amount of work and I would be willing to do it, or if
someone else has a process setup they might be quicker.
WDYT?
The problem with using x.x.x-SNAPSHOTS is that we are giving the community an
indication of intent to release x.x.x before going to x.x.x+1
Ian
>
> I think the contentloader change is optional.
>
> Justin
>
>>
>> Ian
>
>
>
>>
>>>
>>> Carsten
>>>
>>> --
>>> Carsten Ziegeler
>>> [email protected]
>>
>
