On 12 Feb 2010, at 09:02, Ian Boston wrote: > > 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?
I have done a patch[1] that reverts the changes and makes a release of all of the above possible. It builds, release:prepare works (but needs base to be released first so that server can bind to 2.0.6) and I have tested it in our custom environment with all our Ruby based integration tests. I might have missed something but there were no errors. I would propose that we apply the patch (might be best if I do this from git->svn so deletes/moves/renames behave), release the items (Carsten?, just because your keys are better signed than mine) and if it looks like the vote is going to pass (ie 3 committers have done validation) then revert the patch (I can do this git->svn) to allow JR2 move to happen. ? Before any of that, someone else might like to check that the patch is good and I haven't missed anything. I reverted the following commits 908956 SLING-1366 : Use dynamic proxy to handle session#impersonate call. 908888 SLING-1363 - We added a new interface so we should increase the minor versio .... 908799 correcting jcr.api package version 908798 SLING-1363 - removing SessionConfigurer interface and moving NamespaceMapper from base to api. Cr... 908780 fixing SLING-1367 908531 SLING-1366 : Readd call to NamespaceMapper 908440 SLING-1363 Must start the session configurer tracker before starting the repository because starting .... 908232 SLING-1363 - adding SessionConfigurer interface in that sequence. Ian 1. http://codereview.appspot.com/206082 > > 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] >>> >> >
