Il giorno 21/dic/2012, alle ore 00.05, Andrei Shakirin ha scritto: > 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.
Hi guys, I like very much CXF migration plan but I agree with Francesco about the release plan: 1. plan completion seems to take long (1.1.0 release wold be delayed too much without any good reason) 2. CXF interface is something completely new (not yet planned in roadmap - it should be updated asap) Regards, F. > > Cheers, > Andrei. > >> -----Original Message----- >> From: Francesco Chicchiriccò [mailto:[email protected]] >> Sent: Donnerstag, 20. Dezember 2012 17:09 >> To: [email protected] >> 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/ >
