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; 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/
