RE: CXF REST migration plan
+1 from me. Glad to read that you are all already aligned with this migration plan. I will also take care of testing and committing patches provided from Non-Committers (like Christian and Andrei) for this task. Best regards Jan -Original Message- From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] Sent: Freitag, 21. Dezember 2012 10:10 To: dev@syncope.apache.org Subject: Re: CXF REST migration plan On 21/12/2012 09:59, Christian Schneider wrote: Hi Francesco, it is a good idea to release a 1.1.0 version before we introduce the cxf depdendencies. What parts of our plan do you think can go into trunk and what should wait till after the 1.1.0 release? My proposal is this: On 20.12.2012 17:08, Francesco Chicchiriccò wrote: 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 ) Before 1.1.0 Agreed, especially because SYNCOPE-242 is already fixed ;-) b) Resolve ConnId CXF dependencies problem (https://issues.apache.org/jira/browse/SYNCOPE-251 ) After 1.1.0 Agreed. 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 Before 1.1.0 (if time permits) b) Provide temporary implementation of interfaces (step a) for old spring based rest implementation (based on spring restTemplate). Commit implementations to trunk Before 1.1.0 (if time permits) 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 Before 1.1.0 (if time permits) Agreed only if the whole step 2 (a, b and c) is done at once and if additional dependencies are very limited (only for JAX-RS annotations). Otherwise, the whole step 2 should be moved after 1.1.0. All the rest should be delayed till after 1.1.0 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? Basically my proposal is to put into 1.1.0 all steps that have a low risk and provide some benefits. I think it will be good to convert a lot of the tests beforehand to the interfaces as this will make it easier to backport changes to 1.1.x later. Apart from the above things what is the plan for 1.1.0? Is it feature complete already or do you want to get some more features in? As wrote yesterday, we should review all issues currently targeted to 1.1.0 and decide whether to keep or move to next releases. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: CXF REST migration plan
Hi Francesco, it is a good idea to release a 1.1.0 version before we introduce the cxf depdendencies. What parts of our plan do you think can go into trunk and what should wait till after the 1.1.0 release? My proposal is this: On 20.12.2012 17:08, Francesco Chicchiriccò wrote: 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 ) Before 1.1.0 b) Resolve ConnId CXF dependencies problem (https://issues.apache.org/jira/browse/SYNCOPE-251 ) After 1.1.0 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 Before 1.1.0 (if time permits) b) Provide temporary implementation of interfaces (step a) for old spring based rest implementation (based on spring restTemplate). Commit implementations to trunk Before 1.1.0 (if time permits) 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 Before 1.1.0 (if time permits) All the rest should be delayed till after 1.1.0 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? Basically my proposal is to put into 1.1.0 all steps that have a low risk and provide some benefits. I think it will be good to convert a lot of the tests beforehand to the interfaces as this will make it easier to backport changes to 1.1.x later. Apart from the above things what is the plan for 1.1.0? Is it feature complete already or do you want to get some more features in? Best regards Christian
Re: CXF REST migration plan
On 21/12/2012 09:59, Christian Schneider wrote: Hi Francesco, it is a good idea to release a 1.1.0 version before we introduce the cxf depdendencies. What parts of our plan do you think can go into trunk and what should wait till after the 1.1.0 release? My proposal is this: On 20.12.2012 17:08, Francesco Chicchiriccò wrote: 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 ) Before 1.1.0 Agreed, especially because SYNCOPE-242 is already fixed ;-) b) Resolve ConnId CXF dependencies problem (https://issues.apache.org/jira/browse/SYNCOPE-251 ) After 1.1.0 Agreed. 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 Before 1.1.0 (if time permits) b) Provide temporary implementation of interfaces (step a) for old spring based rest implementation (based on spring restTemplate). Commit implementations to trunk Before 1.1.0 (if time permits) 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 Before 1.1.0 (if time permits) Agreed only if the whole step 2 (a, b and c) is done at once and if additional dependencies are very limited (only for JAX-RS annotations). Otherwise, the whole step 2 should be moved after 1.1.0. All the rest should be delayed till after 1.1.0 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? Basically my proposal is to put into 1.1.0 all steps that have a low risk and provide some benefits. I think it will be good to convert a lot of the tests beforehand to the interfaces as this will make it easier to backport changes to 1.1.x later. Apart from the above things what is the plan for 1.1.0? Is it feature complete already or do you want to get some more features in? As wrote yesterday, we should review all issues currently targeted to 1.1.0 and decide whether to keep or move to next releases. Regards. -- Francesco Chicchiriccò ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member http://people.apache.org/~ilgrosso/
Re: CXF REST migration plan
On 21/12/2012 10:24, Colm O hEigeartaigh wrote: +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 Great to hear this! +1 for SYNCOPE-198 and SYNCOPE-215 (including console adaptation) About SYNCOPE-123, I am not sure: it seems quite an heavy task (also for its pervasive impact), I'd rather move it to 1.2.0; anyway, if you could make it in the timings we are currently discussing, I would be personally very glad ;-) Regards. On Thu, Dec 20, 2012 at 11:05 PM, Andrei Shakirin ashaki...@talend.comwrote: 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
Re: CXF REST migration plan
On 21/12/2012 00:05, Andrei Shakirin 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. Hey, glad to see I've got your plan ;-) 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. Makes sense. Would like to hear opinions from others as well. Definitely me too. Regards. -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
