Hi syncoper,

Our mail system is working again :)

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...

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.

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

WDYT?

Best regards.
Jan

> -----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.
> >

Reply via email to