On 17/01/2013 09:13, Jan Bernhardt wrote:
Hi syncoper,
Our mail system is working again :)
Nice: next time please also consider Nabble [1] to post to this ML -
only remember to register with the same e-mail address you are
subscribed to dev@.
As Christian already stated, we have 4 developers currently with time & budged
to get the CXF migration done. We cannot delay this task without massive
re-planning time constrains...
Sorry Jan, I don't think this fact is inline with community-driven
development.
This community discussed and established a roadmap with some releases
[2]: this roadmap can be reviewed over time, of course, but it remains
the driver for this project's activities, indeed.
In the roadmap, the release 1.1.0 comes *before* 1.2.0, and we have
currently agreed to proceed to the final CXF migration in the latter.
Unfortunately, however, there is still plenty of issues to be closed for
1.1.0.
I am personally happy that people is interested in making Syncope
working with CXF and OSGi but I am sincerely worried of the fact that
the actual core features - i.e. what Syncope does, not how it
communicates with external or how it is deployed - and related
documentation are left behind.
I am also worried about the sentence reported by Christian below: "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."
I hope this does not mean that you will disappear once the CXF migration
is done, it would be very bad for Syncope.
And, for my curiosity: who is the "normal product development team"? Are
you part of it? Are the people from this team already part of this
project (Syncope)?
But the good news is, that I found a way how we could solve this dilemma ;-)
The main problem (as mentioned earlier) with SVN is merging of renamed files.
So my proposal would be to not rename any classes within a development branch.
But instead leaving Controller classes as they are, and introducing new
*ServiceImpl classes in addition to that. The current implementation of those
*ServiceImpl classes would be to call matching methods of Controller classes
(basically same idea for server side as we already applied on client side with
SpringServiceProxy classes). Once we all agree with new ServiceInterfaces and
switching from Spring webservices to CXF we can copy code from controller
classes and place this code in *ServiceImpl classes and then delete controller
classes.
The advantage of this proposal is, that we can make all REST Services run in
CXF and Spring at the same time, without any conflicts!
If other syncope committers agree we could even make these changes in trunk and
release this as an early preview in 1.1.0. But even if not, we can get the
migration done in a branch and then merge branch back to trunk after 1.1.0
release.
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.
In this way we will have a very "fat" 1.1.0 release, but at least we
will be free to make a release when we feel it's ready. Later than
currently expected, of course.
However some changes could be done in trunk anyway, like removing client in
package names:
org.apache.syncope.client.mod --> org.apache.syncope.mod
org.apache.syncope.client.report --> org.apache.syncope.report
org.apache.syncope.client.search --> org.apache.syncope.search
org.apache.syncope.client.to --> org.apache.syncope.to
org.apache.syncope.client.validation --> org.apache.syncope.validation
Could you please give a rationale for this? Currently, any submodule's
root package reflects its own name: e.g. org.apache.syncope.core /
org.apache.syncope.console / org.apache.syncope.client
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/
