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. 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? Best regards. Jan > 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/
