On 18/01/2013 09:43, Jan Bernhardt wrote:
Hi Francesco,
-----Original Message-----
From: Francesco Chicchiriccò [mailto:ilgro...@apache.org]
Sent: Donnerstag, 17. Januar 2013 17:47
To: dev@syncope.apache.org
Subject: Re: [Discussion] CXF migration (branches)
On 17/01/2013 10:54, Jan Bernhardt wrote:
Hi Francesco,
[...]
If, as it seems there is no other way out, I'd propose to move back
the CXF migration to 1.1.0 (as actually OSGi is still there) so that
no additional branch is created. This is valid as long as Spring MVC
interfaces are still working as now, as you said above.
Yes, Spring MVC interfaces will not be affected.
Fine, as written elsewhere by Andrei in this mail thread "it seems we
have agreed about it": would you please adjust JIRA issues accordingly?
I will take care of this.
Ok then why not introducing this new "common" maven submodule (as said
in the past) with root package org.apache.syncope.common and then start
moving away packages from client?
+1
Supposed that no one disagrees, I will create a Jira ticket for this task and
take care of this. Since this refactoring will effect most classes. I would do
this Monday morning. So all committers could use the time until Sunday to get
their changes committed and thus avoiding a bigger merging effort after this
refactoring.
Fine for me.
But rather than introducing a new module I would like to rename "client" module to "common"
(including "client" to "common" in package names).
When I did my CXF PoC (see CXF branch), I noticed that all packages except for
"org.apache.syncope.client.http" are needed in common.
Syncope-150 will introduce a rich client library. My proposal would be to move
"org.apache.syncope.client.http" to console, since "org.apache.syncope.console.rest" is in console
and also "rich client" related. Once we take care of Syncope-150 we can (re)create a "client"
module and then move both packages to this module.
Does this sound reasonable?
Please don't forget that there is people out there using Syncope core
*without* (or not exclusively via) the admin console.
Currently, they only needs the syncope-client dependency (+Spring if
they want to rely upon RestTemplate) in their java apps.
Moreover, some client classes (the exception handler, for example) are
not just model objects (like as *TO and *Mod).
Give these reasons, I would either leave things as they are (the current
client module, with current classes inside) or introduce a new common as
said above.
I actually don't see an option to rename common to client and
re-introduce client at later stage; besides the rest, it generates some
confusion IMHO.
Regards.
-----Original Message-----
From: Christian Schneider [mailto:cschneider...@gmail.com] On Behalf Of
Christian Schneider
Sent: Mittwoch, 16. Januar 2013 18:48
To: dev@syncope.apache.org
Subject: Re: [Discussion] CXF migration (branches)
Jan contacted me that the E-Mail Server in the Bonn office is
currently down so he can not reply himself at the moment.
So I am replying what he wrote me via Skype:
We currently have the plan to finish the CXF migration during the
next
1.5 weeks with 4 developers. The issue is a little urgent as from
february on our normal product development team would like to take
over and focus on making Syncope work nicely in OSGi. At this point
we should have finished the CXF migration. Of course we can delay
things a little but not too much without affecting our whole planning.
Christian
On 16.01.2013 16:08, Francesco Chicchiriccò wrote:
On 16/01/2013 15:50, Jan Bernhardt wrote:
Hi Syncopers,
all preparation tasks are more or less done for CXF migration, so
next we would like to start with actual CXF migration.
Since we are planning to release Syncope 1.1.0 soon I can see two
reasonable solutions to continue.
1. Creating a release branch for 1.1.0 and making sure this
branch is stable and give it some time for additional test before
official "stable" release will take place. CXF migration would
start directly in trunk.
2. Creating a CXF branch and continue working on trunk for
1.1.0 release.
I would prefer option 1 best. I think having a release branch prior
to office release is a good practice in general.
I expect quite some refactoring during CXF migration (which is not
mandatory in all cases but expedient), for example renaming some
packages (removing client from Types, TOs, ... since they are
rather common classes used on server and client site than specific
only to the client) and I would also like to rename *Controller
classes to *ServiceImpl since these classes do not act as
controller for a workflow or GUI but rather offer some REST
services. SVN has some limitations to handle renamed files when it comes to
merging updates.
Thus it could be quite painful to keep a cxf branch in sync with trunk.
WDYT? Could we start a release branch?
Hi Jan,
I generally agree with (1) even though I am not sure whether Syncope
1.1.0 release can actually happen soon: there is still a
considerable number of issues to be solved (~20) and many changes
introduced by
SYNCOPE-241 SYNCOPE-259 SYNCOPE-268 (all still open) need to
consolidate a bit.
From the other side, 46+ issues have already been resolved in 1.1.0
and this would instead suggest pushing 1.1.0 for releasing soon.
Finally, please consider that even with option (1) there will be
some bugfixing in the 1_1_X branch (i.e. the current trunk) for long
time; this will push a consistent and constant merge work to be done
between 1_1_X and new trunk.
Given this situation, I would personally suggest to devote as much
energy as possible towards 1.1.0 release, possibly putting the CXF
migration on hold for a while.
Regards.
[1] http://syncope-dev.1063484.n5.nabble.com/
[2] https://cwiki.apache.org/confluence/display/SYNCOPE/Roadmap
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
