You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@syncope.apache.org by Jan Bernhardt <jb...@talend.com> on 2013/01/16 15:50:31 UTC
[Discussion] CXF migration (branches)
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?
Best regards.
Jan
Re: [Discussion] CXF migration (branches)
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [Discussion] CXF migration (branches)
Posted by Christian Schneider <ch...@die-schneider.net>.
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)
Posted by Jan Bernhardt <jb...@talend.com>.
>
> Please don't forget that there is people out there using Syncope core
> *without* (or not exclusively via) the admin console.
> Currently, they only needs the syncope-client dependency (+Spring if they
> want to rely upon RestTemplate) in their java apps.
>
> Moreover, some client classes (the exception handler, for example) are not
> just model objects (like as *TO and *Mod).
>
> Give these reasons, I would either leave things as they are (the current client
> module, with current classes inside) or introduce a new common as said
> above.
>
> I actually don't see an option to rename common to client and re-introduce
> client at later stage; besides the rest, it generates some confusion IMHO.
>
OK. I agree with you.
> Regards.
Re: [Discussion] CXF migration (branches)
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 18/01/2013 09:43, Jan Bernhardt wrote:
> Hi Francesco,
>
>> -----Original Message-----
>> From: Francesco Chicchiriccò [mailto:ilgrosso@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.
Fine for me.
> 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?
Please don't forget that there is people out there using Syncope core
*without* (or not exclusively via) the admin console.
Currently, they only needs the syncope-client dependency (+Spring if
they want to rely upon RestTemplate) in their java apps.
Moreover, some client classes (the exception handler, for example) are
not just model objects (like as *TO and *Mod).
Give these reasons, I would either leave things as they are (the current
client module, with current classes inside) or introduce a new common as
said above.
I actually don't see an option to rename common to client and
re-introduce client at later stage; besides the rest, it generates some
confusion IMHO.
Regards.
>>>>>> -----Original Message-----
>>>>>> From: Christian Schneider [mailto:cschneider111@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/
RE: [Discussion] CXF migration (branches)
Posted by Jan Bernhardt <jb...@talend.com>.
Hi Francesco,
> -----Original Message-----
> From: Francesco Chicchiriccò [mailto:ilgrosso@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:cschneider111@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/
Re: [Discussion] CXF migration (branches)
Posted by Francesco Chicchiriccò <il...@apache.org>.
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:cschneider111@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/
RE: [Discussion] CXF migration (branches)
Posted by Jan Bernhardt <jb...@talend.com>.
Hi Francesco,
> -----Original Message-----
> From: Francesco Chicchiriccò [mailto:ilgrosso@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:cschneider111@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/
Re: [Discussion] CXF migration (branches)
Posted by Francesco Chicchiriccò <il...@apache.org>.
On 17/01/2013 12:55, Andrei Shakirin wrote:
> 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.
Clear, every contribution is (more than) welcome.
...but I think that committers and PMC members - not occasional
contributors - should also care about the whole project life (core
features / documentation / release), or not?
Regards.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/
RE: [Discussion] CXF migration (branches)
Posted by Andrei Shakirin <as...@talend.com>.
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:ilgrosso@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:cschneider111@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/
Re: [Discussion] CXF migration (branches)
Posted by Francesco Chicchiriccò <il...@apache.org>.
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:cschneider111@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/
RE: [Discussion] CXF migration (branches)
Posted by Jan Bernhardt <jb...@talend.com>.
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:cschneider111@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.
> >
Re: [Discussion] CXF migration (branches)
Posted by Christian Schneider <ch...@die-schneider.net>.
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)
Posted by Marco Di Sabatino Di Diodoro <ma...@tirasa.net>.
On Jan 16, 2013, at 4:29 PM, Fabio Martelli wrote:
>
> 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.
>
I agree with Fabio and Francesco.
M
> Regards,
> F.
--
Dott. Marco Di Sabatino Di Diodoro
Tel. +39 3939065570
Tirasa S.r.l.
Viale D'Annunzio 267 - 65127 Pescara
Tel +39 0859116307 / FAX +39 0859111173
http://www.tirasa.net
Apache Syncope PMC Member
http://people.apache.org/~mdisabatino
Re: [Discussion] CXF migration (branches)
Posted by Fabio Martelli <fa...@gmail.com>.
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)
Posted by Francesco Chicchiriccò <il...@apache.org>.
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.
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/