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
