Hi Francesco, > -----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@.
This is what I did yesterday, but unfortunately I could also not receive the confirmation mail from nabble... > > > 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. > I don't see a conflict with community-driven development. The community can provide new features and extensions in topics they have a special interest and skillset in. Of course including these new features in a release (or trunk) needs to be aligned with other community members. But I think it is rather common that companies get engaged in Apache projects and that they focus on providing some extensions they need in their business. As long as the community agrees that these features are valuable; I don't see a problem here. > 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. I can understand your worries. And no, we will not disappear once CXF migration is done. But of course we will spend less time in Syncope topics as currently. The last few weeks I was working more or less every day with syncope topics. This was fine, since Syncope topics matched with our current project goals. But talend understands that a committership requires continues activity within these projects. Thus I'll be able to continue working on Syncope topics (not aligned with project topics), once CXF migration is done. Of course not 5 days a week. > > 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)? No. Our product team has not really started working with syncope. We just told them, that they should, because Syncope has already some nice features and an even greater potential. ;-) > > > 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. Yes, Spring MVC interfaces will not be affected. > > 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. When do you expect the 1.1.0 release? Since CXF related task will be done until end of this month, why do you think that this will delay the 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 > > 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 Almost all classes in client module are not specific to the client, but rather needed on client and server side, since they contain classes for exchanging data between client and server. Hence "client" module could better be renamed to "common" module. There is a JIRA ticket to eventually have a rich client in syncope, but currently I can only see a client in the "console" module in package org.apache.syncope.console.rest. 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/
