RE: [Discussion] CXF migration (branches)
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
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
Re: [Discussion] CXF migration (branches)
On 17.01.2013 10:05, Francesco Chicchiriccò wrote: On 17/01/2013 09:13, Jan Bernhardt wrote: 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)? Hi, I will explain a bit how our team structure is. Andrei, Jan, Christian Schmüling and me are currently working on a large project that will go for several years. So we are a bit separated from normal product development. Still most we do will go into the open source projects. In fact I am only working 50% on the project and 50% in the Apache Team. The rest of our people is either working on the Apache Team or in our TESB Runtime Team. So while we are working on the same projects we have different management and of course slightly different goals. From the apache team your already know Jean Baptiste and Colm. I fully agree that our internal committment (we are doing scrum) is not always in line with community development and we are aware of that. As syncope is community driven our internal plan of course can only be a proposal for the community. During our project we will be active in different communities over time. So we will not always work on syncope but I am pretty sure that over time we will continue to put considerable efforts into syncope. Christian
RE: [Discussion] CXF migration (branches)
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
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? 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? Just take a look at issues opened today... consolidation takes time, especially when keeping making architectural-level refactorings. 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. 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? 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
Re: [Discussion] CXF migration (branches)
Il giorno 16/gen/2013, alle ore 16.08, Francesco Chicchiriccò ha scritto: 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. Completely agree with Francesco: I do think that, all together, we can release 1.1.0 in a very short time with a little effort. Please, let's spend some time to make the current trunk stable as much as possible. Regards, F.
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.
Re: [Discussion] CXF migration (branches)
It sounds good. On my side, I gonna move forward around the OSGi support. Thanks for the update. Regards JB On 01/16/2013 06:47 PM, Christian Schneider wrote: 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. -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com
