I think I will move it to core for now but not yet change the package name.
So we stay compatible and still have one less module. For 3.0 I plan to
move many of the Features to a new position.
We can then decide how to group them into jars.
For compatibility and the architecture the package name is more
important than the jar anyway. A good design of the packages will allow
us the freedom to arrrange them into jars as we need. So we should
discuss that soon to make a good decision for 3.0.
What is already really good with the gzip feature is that feature and
interceptors are in the same package. I will try to do that for all
features.
Currently many of the basic features are in the feature package while
their interceptors are in the interceptor package. This is not so good
as it does not allow
us to move them anywhere without breaking compatiblity or having split
packages.
Christian
Am 30.01.2012 23:33, schrieb Sergey Beryozkin:
Hi
On 30/01/12 19:29, Daniel Kulp wrote:
On Monday, January 30, 2012 11:56:06 AM Christian Schneider wrote:
We could of course also have a spearate module for gzip.
The reason why I think about moving it to core is that it just contains
3 classes and does not have additional dependencies.
Basically I like the idea to separate modules on the architecture
level.
On the runtime level I doubt though that any user would mind having
these classes
available every time.
About a prefix for the gzip classes. I also thought about what could be
suitable. Of course gzip is kind of on the transport level but it is no
transport. So perhaps it is a kind of a transformation or encoding.
I really have some mixed opinions on this. In "API" we have some
similar
features similar to the gzip feature that really could be grouped
into this,
but we have that split-package issue. For example, the
FastInfosetFeature
kind of falls into the same basic idea and could likely be grouped
into a
separate "features" bundle, but because we stuck it in
org.apache.cxf.feature,
I have to leave it API. :-( (and the fact that the implementation
of the
feature lives in org.apache.cxf.interceptor, also in API)
One positive from dropping this module is that we will have 1 less
module, and as Christian pointed out it won't affect users directly.
I guess it means the simpler config of features too...
Possible cons is that rt/core will start accumulating some more or
less common transport-specific code - but may be indeed some more
material is needed before getting a transport-specific module created
for good...
Not sure :-). Whatever makes it better for 2.6 is good for me :-)
Cheers, Sergey
Dan
Christian
Am 30.01.2012 11:43, schrieb Sergey Beryozkin:
Hi Christian
On 30/01/12 10:34, Christian Schneider wrote:
We currently have a transports/common project that only contains the
gzip feature.
As this feature is even used from core I propose we move it there and
remove the whole transports/common module.
As far as I recall the gzip feature was in transports/http originally
and then there was a demand for GZIP be supported at the JMS level...
I proposed to move it to transports/common as opposed to rt/core, it
does not seem to belong to the core really, as it's a very transport
specific feature
I would like to change the package name from
org.apache.cxf.transport.common.gzip to org.apache.cxf.gzip. To
remain
compatible I would leave a copy of the classes
in the old package with @Deprecated annotation.
I'd still propose to scope 'gzip', may be not with 'common' but with
something else
Cheers, Sergey
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
