Hi Francesco, > 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.
I understand your point. From other side my experience with other Apache projects is that, if people or companies are interesting in some specific project features and discuss/align them with community - patches and contributions are always welcome, even if those features are not in roadmap. > I hope this does not mean that you will disappear once the CXF migration is > done, it would be very bad for Syncope. Actually, I can invest my working time in CXF migration. Afterwards, I will work with Syncope mostly in my free time. >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. +1. Seems we have agreed about it. Regards, Andrei. > -----Original Message----- > From: Francesco Chicchiriccò [mailto:ilgro...@apache.org] > Sent: Donnerstag, 17. Januar 2013 10:05 > To: dev@syncope.apache.org > Subject: Re: [Discussion] CXF migration (branches) > > 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/
