+1 to this plan. Also +1 for Christian's points about getting low risk refactoring into 1.1.0.
How about we do a JIRA triage for 1.1.0? Currently we have 21 open tasks for this version. I volunteer for the following tasks: https://issues.apache.org/jira/browse/SYNCOPE-198 https://issues.apache.org/jira/browse/SYNCOPE-123 https://issues.apache.org/jira/browse/SYNCOPE-215 Colm. On Thu, Dec 20, 2012 at 11:05 PM, Andrei Shakirin <ashaki...@talend.com>wrote: > 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/ > > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
