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/
