On Tuesday, January 31, 2012 8:07:34 AM Christian Schneider wrote: > 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.
Can you add this idea to the list at: http://cxf.apache.org/docs/30-migration-guide.html That list is now a bit out of date. Was able to accomplish much of it for 2.6. :-) Dan > > 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 -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
