Hi Francesco, > I guess you have already shared this plan with Jan - I would expect that since > most of issues mentioned above are assigned to him as "in charge" > of this CXF refactoring as discussed in this mailing list [1].
Yep, we have created this plan together with Jan and Christian and would like to discuss/align it with Syncope community. > Correct me if I am wrong, but the whole idea is to not directly merge the > current CXF branch [2] into the trunk, but to keep it for a while as a "source > of refactoring" for modifications to be applied to the trunk. Correct. CXF branch is basically just POC. Perhaps we will reuse some code from there, but more important for migration is principles and approaches there. > Once most of such modifications are in place into the trunk, making it still > running Spring MVC but with all ingredients ready for CXF, a proper 'cxf- > migration' branch will be created. Correct. > The purpose of this second branch will be to remove any residual Spring MVC > dependency / code / configuration and to empower CXF for the REST > interface, in all components (including the admin console, of course). Yep. And of course resolve possible problems, makes all tests green. > > When ready, this 'cxf-migration' branch will me merged into the trunk and > disappear. Correct. > This fact would push a 1.1.0 release, but if we do so, I don't see as > particularly > clean adding 'useless' dependencies and code (the ready-to-run-but-not- > yet-running CXF stuff) to a new release. I see your point. > Hence my proposal: let's take a look at issues still open for 1.1.0 [4], do > some > pruning by moving any non strictly necessary or complex issue to > 1.2.0 and do release 1.1.0. > In my opinion, we should be able to complete this at most before the end of > January. > > At that point, with trunk set to 1.2.0-SNAPSHOT, we can start with the plan > you propose above. > WDYT? Personally I agree with your arguments. Perhaps in this case it makes sense for us to start preparations before end of January (not in trunk). Then steps (a) - (e) will be committed to 1.2.0-SNAPSHOT trunk as soon as 1.1.0 will be released. Would like to hear opinions from others as well. Cheers, Andrei. > -----Original Message----- > From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] > Sent: Donnerstag, 20. Dezember 2012 17:09 > To: dev@syncope.apache.org > Subject: Re: CXF REST migration plan > > On 20/12/2012 16:44, Andrei Shakirin wrote: > > Hi, > > > > We just finished CXF migration POC for users and roles: it is successful and > we approximately know how much efforts we need for complete migration. > > I would like to discuss the steps we are going to do for complete migration > in next year. > > > > > > 1. Prerequisites > > > > a) Finishing persistence refactoring > (https://issues.apache.org/jira/browse/SYNCOPE-241, > https://issues.apache.org/jira/browse/SYNCOPE-242 ) > > > > b) Resolve ConnId CXF dependencies problem > (https://issues.apache.org/jira/browse/SYNCOPE-251 ) > > > > > > > > 2. Steps > > > > a) Introduce interfaces for all controllers in > org.apache.syncope.core.rest.controller (the same way as for user and role > in cxf branch). Interfaces will contain JAX-RS annotations. Commit interfaces > to trunk > > > > b) Provide temporary implementation of interfaces (step a) for "old" > spring based rest implementation (based on spring restTemplate). Commit > implementations to trunk > > > > c) Refactor core rest integration tests to use controller interfaces > > instead > restTemplate. All rest tests must be successful. Commit refactored tests to > trunk. This step helps to prepare tests to be used with CXF without breaking > them > > > > d) Add CXF dependencies, CXF Rest service configuration, exception > mappers and jaxb/json providers, but do not activate them. Commit them to > trunk > > > > e) Update TO classes for JAXB marshalling (if necessary) and keep > > spring > marshalling working with the same TO classes. Commit it to trunk. If keeping > JAXB marshalling parallel to spring is too complicate, this step will be > done in > cxf-migration branch after step (f) > > > > f) Create cxf-migration branch > > > > g) Activate using CXF Rest for controller interfaces instead temporary > spring based implementation created on step (b). Fix possible problems > > > > h) Update console to use CXF Rest. Fix possible problems > > > > i) Merge cxf-migration branch with trunk > > > > Our idea is to keep cxf-migration branch possibly short time, split > > migration > on some small steps and keep the tests and whole system running in > between. > > Does this plan make sense? Any other suggestions / ideas? > > Hi Andrei, > I guess you have already shared this plan with Jan - I would expect that since > most of issues mentioned above are assigned to him as "in charge" > of this CXF refactoring as discussed in this mailing list [1]. > > Correct me if I am wrong, but the whole idea is to not directly merge the > current CXF branch [2] into the trunk, but to keep it for a while as a "source > of refactoring" for modifications to be applied to the trunk. > > Once most of such modifications are in place into the trunk, making it still > running Spring MVC but with all ingredients ready for CXF, a proper 'cxf- > migration' branch will be created. > The purpose of this second branch will be to remove any residual Spring MVC > dependency / code / configuration and to empower CXF for the REST > interface, in all components (including the admin console, of course). > > When ready, this 'cxf-migration' branch will me merged into the trunk and > disappear. > > Is this correct? > > ===== > > Generally speaking, this plan makes sense to me. > Only, I am a bit concerned about timing, especially considering that the > current trunk is already full of new features (compared to 1_0_X) [3]. > > This fact would push a 1.1.0 release, but if we do so, I don't see as > particularly > clean adding 'useless' dependencies and code (the ready-to-run-but-not- > yet-running CXF stuff) to a new release. > > Hence my proposal: let's take a look at issues still open for 1.1.0 [4], do > some > pruning by moving any non strictly necessary or complex issue to > 1.2.0 and do release 1.1.0. > In my opinion, we should be able to complete this at most before the end of > January. > > At that point, with trunk set to 1.2.0-SNAPSHOT, we can start with the plan > you propose above. > > WDYT? > > [1] http://markmail.org/message/jgxe5tt47l636wc3 > [2] https://svn.apache.org/repos/asf/syncope/branches/cxf > [3] > https://issues.apache.org/jira/issues/?jql=project+%3D+SYNCOPE+AND+fix > Version+%3D+%221.1.0%22+AND+status+%3D+Resolved+ORDER+BY+priorit > y+DESC > [4] > https://issues.apache.org/jira/issues/?jql=project%20%3D%20SYNCOPE%20 > AND%20fixVersion%20%3D%20%221.1.0%22%20AND%20status%20%3D%20 > Open%20ORDER%20BY%20priority%20DESC > > -- > Francesco Chicchiriccò > > ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member > http://people.apache.org/~ilgrosso/
