You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Daniel Kulp <dk...@apache.org> on 2013/07/03 20:39:33 UTC
[DISCUSS] api+rt-core -> core
For 3.0, I'd like to combine both cxf-api and cxf-rt-core into a single jar/bundle. I'd likely just call it cxf-core, but I'm open to other suggestions (cxf-kernel?).
We originally tried to have a separate jar for "api" to make javadoc generation easier, but it pretty much doesn't work. Many of the classes (like the Service Factories and client factories and JAX-RS client things and much much more) that you really would need are not part of api and thus don't appear in the "api" javadoc anyway. Thus, that reason is pointless and not working.
API is also WAY WAY more than just "API" now. There are interceptors, data binding things, all kinds of concrete utility things, etc… API is about 1MB whereas "core" is about 270K. Kind of shows where the real "core" stuff is.
As it is, right now, you cannot really have api without rt-core anyway. By combining them, we can get rid of some of the dynamic import things and such in OSGi (to find the Bus factory). One less jar to deal with as well. The jaxrs basic sample would be down to cxf-core, cxf-transports-http, cxf-rt-frontend-jaxrs, and the related 3rd party deps.
Thoughts?
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] api+rt-core -> core
Posted by Christian Schneider <ch...@die-schneider.net>.
I would prefer to have a small api that other parts of cxf can depend on.
As this is not going to happen I am fine with combining both.
We should start to think about what parts of core are api and what parts
are impl though.
Ideally this should be per package. We can then at least mark these
packages so people know to not use the impls.
Any ideas how to achieve this? Normally I would propose to introduce the
eclipse naming conventions of impl or internal for impl packages. This
would lead to bigger incompatibilites though. So I am not sure if it would
make sense.
In any case we should not export any impl packages for OSGi.
Christian
2013/7/5 Andrei Shakirin <as...@talend.com>
> +1 from me
>
> > -----Original Message-----
> > From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> > Sent: Donnerstag, 4. Juli 2013 10:55
> > To: dev@cxf.apache.org
> > Subject: Re: [DISCUSS] api+rt-core -> core
> >
> > Hi
> >
> > Sounds good
> >
> > Thanks, Sergey
> > On 04/07/13 10:52, Colm O hEigeartaigh wrote:
> > > +1.
> > >
> > > Colm.
> > >
> > >
> > > On Thu, Jul 4, 2013 at 3:54 AM, Dennis Sosnoski <dm...@sosnoski.com>
> > wrote:
> > >
> > >> +1
> > >>
> > >> - Dennis
> > >>
> > >>
> > >> On 07/04/2013 06:39 AM, Daniel Kulp wrote:
> > >>
> > >>> For 3.0, I'd like to combine both cxf-api and cxf-rt-core into a
> single
> > >>> jar/bundle. I'd likely just call it cxf-core, but I'm open to other
> > >>> suggestions (cxf-kernel?).
> > >>>
> > >>> We originally tried to have a separate jar for "api" to make javadoc
> > >>> generation easier, but it pretty much doesn't work. Many of the
> classes
> > >>> (like the Service Factories and client factories and JAX-RS client
> > >>> things and much much more) that you really would need are not part of
> > api and thus
> > >>> don't appear in the "api" javadoc anyway. Thus, that reason is
> pointless
> > >>> and not working.
> > >>>
> > >>> API is also WAY WAY more than just "API" now. There are
> interceptors,
> > >>> data binding things, all kinds of concrete utility things, etc...
> API is
> > >>> about 1MB whereas "core" is about 270K. Kind of shows where the
> real
> > >>> "core" stuff is.
> > >>>
> > >>> As it is, right now, you cannot really have api without rt-core
> anyway.
> > >>> By combining them, we can get rid of some of the dynamic import
> > things and
> > >>> such in OSGi (to find the Bus factory). One less jar to deal with
> as
> > >>> well. The jaxrs basic sample would be down to cxf-core,
> > >>> cxf-transports-http, cxf-rt-frontend-jaxrs, and the related 3rd party
> > deps.
> > >>>
> > >>> Thoughts?
> > >>>
> > >>>
> > >>
> > >
> > >
>
>
RE: [DISCUSS] api+rt-core -> core
Posted by Andrei Shakirin <as...@talend.com>.
+1 from me
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin@gmail.com]
> Sent: Donnerstag, 4. Juli 2013 10:55
> To: dev@cxf.apache.org
> Subject: Re: [DISCUSS] api+rt-core -> core
>
> Hi
>
> Sounds good
>
> Thanks, Sergey
> On 04/07/13 10:52, Colm O hEigeartaigh wrote:
> > +1.
> >
> > Colm.
> >
> >
> > On Thu, Jul 4, 2013 at 3:54 AM, Dennis Sosnoski <dm...@sosnoski.com>
> wrote:
> >
> >> +1
> >>
> >> - Dennis
> >>
> >>
> >> On 07/04/2013 06:39 AM, Daniel Kulp wrote:
> >>
> >>> For 3.0, I'd like to combine both cxf-api and cxf-rt-core into a single
> >>> jar/bundle. I'd likely just call it cxf-core, but I'm open to other
> >>> suggestions (cxf-kernel?).
> >>>
> >>> We originally tried to have a separate jar for "api" to make javadoc
> >>> generation easier, but it pretty much doesn't work. Many of the classes
> >>> (like the Service Factories and client factories and JAX-RS client
> >>> things and much much more) that you really would need are not part of
> api and thus
> >>> don't appear in the "api" javadoc anyway. Thus, that reason is pointless
> >>> and not working.
> >>>
> >>> API is also WAY WAY more than just "API" now. There are interceptors,
> >>> data binding things, all kinds of concrete utility things, etc... API is
> >>> about 1MB whereas "core" is about 270K. Kind of shows where the real
> >>> "core" stuff is.
> >>>
> >>> As it is, right now, you cannot really have api without rt-core anyway.
> >>> By combining them, we can get rid of some of the dynamic import
> things and
> >>> such in OSGi (to find the Bus factory). One less jar to deal with as
> >>> well. The jaxrs basic sample would be down to cxf-core,
> >>> cxf-transports-http, cxf-rt-frontend-jaxrs, and the related 3rd party
> deps.
> >>>
> >>> Thoughts?
> >>>
> >>>
> >>
> >
> >
Re: [DISCUSS] api+rt-core -> core
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
Sounds good
Thanks, Sergey
On 04/07/13 10:52, Colm O hEigeartaigh wrote:
> +1.
>
> Colm.
>
>
> On Thu, Jul 4, 2013 at 3:54 AM, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>
>> +1
>>
>> - Dennis
>>
>>
>> On 07/04/2013 06:39 AM, Daniel Kulp wrote:
>>
>>> For 3.0, I'd like to combine both cxf-api and cxf-rt-core into a single
>>> jar/bundle. I'd likely just call it cxf-core, but I'm open to other
>>> suggestions (cxf-kernel?).
>>>
>>> We originally tried to have a separate jar for "api" to make javadoc
>>> generation easier, but it pretty much doesn't work. Many of the classes
>>> (like the Service Factories and client factories and JAX-RS client things
>>> and much much more) that you really would need are not part of api and thus
>>> don't appear in the "api" javadoc anyway. Thus, that reason is pointless
>>> and not working.
>>>
>>> API is also WAY WAY more than just "API" now. There are interceptors,
>>> data binding things, all kinds of concrete utility things, etc… API is
>>> about 1MB whereas "core" is about 270K. Kind of shows where the real
>>> "core" stuff is.
>>>
>>> As it is, right now, you cannot really have api without rt-core anyway.
>>> By combining them, we can get rid of some of the dynamic import things and
>>> such in OSGi (to find the Bus factory). One less jar to deal with as
>>> well. The jaxrs basic sample would be down to cxf-core,
>>> cxf-transports-http, cxf-rt-frontend-jaxrs, and the related 3rd party deps.
>>>
>>> Thoughts?
>>>
>>>
>>
>
>
Re: [DISCUSS] api+rt-core -> core
Posted by Colm O hEigeartaigh <co...@apache.org>.
+1.
Colm.
On Thu, Jul 4, 2013 at 3:54 AM, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> +1
>
> - Dennis
>
>
> On 07/04/2013 06:39 AM, Daniel Kulp wrote:
>
>> For 3.0, I'd like to combine both cxf-api and cxf-rt-core into a single
>> jar/bundle. I'd likely just call it cxf-core, but I'm open to other
>> suggestions (cxf-kernel?).
>>
>> We originally tried to have a separate jar for "api" to make javadoc
>> generation easier, but it pretty much doesn't work. Many of the classes
>> (like the Service Factories and client factories and JAX-RS client things
>> and much much more) that you really would need are not part of api and thus
>> don't appear in the "api" javadoc anyway. Thus, that reason is pointless
>> and not working.
>>
>> API is also WAY WAY more than just "API" now. There are interceptors,
>> data binding things, all kinds of concrete utility things, etc… API is
>> about 1MB whereas "core" is about 270K. Kind of shows where the real
>> "core" stuff is.
>>
>> As it is, right now, you cannot really have api without rt-core anyway.
>> By combining them, we can get rid of some of the dynamic import things and
>> such in OSGi (to find the Bus factory). One less jar to deal with as
>> well. The jaxrs basic sample would be down to cxf-core,
>> cxf-transports-http, cxf-rt-frontend-jaxrs, and the related 3rd party deps.
>>
>> Thoughts?
>>
>>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: [DISCUSS] api+rt-core -> core
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
+1
- Dennis
On 07/04/2013 06:39 AM, Daniel Kulp wrote:
> For 3.0, I'd like to combine both cxf-api and cxf-rt-core into a single jar/bundle. I'd likely just call it cxf-core, but I'm open to other suggestions (cxf-kernel?).
>
> We originally tried to have a separate jar for "api" to make javadoc generation easier, but it pretty much doesn't work. Many of the classes (like the Service Factories and client factories and JAX-RS client things and much much more) that you really would need are not part of api and thus don't appear in the "api" javadoc anyway. Thus, that reason is pointless and not working.
>
> API is also WAY WAY more than just "API" now. There are interceptors, data binding things, all kinds of concrete utility things, etc… API is about 1MB whereas "core" is about 270K. Kind of shows where the real "core" stuff is.
>
> As it is, right now, you cannot really have api without rt-core anyway. By combining them, we can get rid of some of the dynamic import things and such in OSGi (to find the Bus factory). One less jar to deal with as well. The jaxrs basic sample would be down to cxf-core, cxf-transports-http, cxf-rt-frontend-jaxrs, and the related 3rd party deps.
>
> Thoughts?
>
Re: [DISCUSS] api+rt-core -> core
Posted by Freeman Fang <fr...@gmail.com>.
+1 for it.
And cxf-core is good for the name
－－－－－－－－－－－－－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: @Freeman小屋
On 2013-7-4, at 上午2:39, Daniel Kulp wrote:
>
> For 3.0, I'd like to combine both cxf-api and cxf-rt-core into a single jar/bundle. I'd likely just call it cxf-core, but I'm open to other suggestions (cxf-kernel?).
>
> We originally tried to have a separate jar for "api" to make javadoc generation easier, but it pretty much doesn't work. Many of the classes (like the Service Factories and client factories and JAX-RS client things and much much more) that you really would need are not part of api and thus don't appear in the "api" javadoc anyway. Thus, that reason is pointless and not working.
>
> API is also WAY WAY more than just "API" now. There are interceptors, data binding things, all kinds of concrete utility things, etc… API is about 1MB whereas "core" is about 270K. Kind of shows where the real "core" stuff is.
>
> As it is, right now, you cannot really have api without rt-core anyway. By combining them, we can get rid of some of the dynamic import things and such in OSGi (to find the Bus factory). One less jar to deal with as well. The jaxrs basic sample would be down to cxf-core, cxf-transports-http, cxf-rt-frontend-jaxrs, and the related 3rd party deps.
>
> Thoughts?
>
> --
> Daniel Kulp
> dkulp@apache.org - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
>
Re: [DISCUSS] api+rt-core -> core
Posted by Alessio Soldano <as...@redhat.com>.
Generally speaking I agree on this. The api jar has always been actually
quite "fat" for an "api" thing.
One question that pops up in mind though is how we're going to deal with
api changes in micro releases in the future. My understanding is that so
far, any non backward compatible change to the cxf-api would have
required at least a minor (e.g. 2.5 -> 2.6) version bump. How will that
change with the new cxf-core? Are we going to offer any "stability
guarantee" among micro releases here (e.g. 3.0.0 -> 3.0.1)?
Cheers
Alessio
On 07/03/2013 08:39 PM, Daniel Kulp wrote:
>
> For 3.0, I'd like to combine both cxf-api and cxf-rt-core into a single jar/bundle. I'd likely just call it cxf-core, but I'm open to other suggestions (cxf-kernel?).
>
> We originally tried to have a separate jar for "api" to make javadoc generation easier, but it pretty much doesn't work. Many of the classes (like the Service Factories and client factories and JAX-RS client things and much much more) that you really would need are not part of api and thus don't appear in the "api" javadoc anyway. Thus, that reason is pointless and not working.
>
> API is also WAY WAY more than just "API" now. There are interceptors, data binding things, all kinds of concrete utility things, etc… API is about 1MB whereas "core" is about 270K. Kind of shows where the real "core" stuff is.
>
> As it is, right now, you cannot really have api without rt-core anyway. By combining them, we can get rid of some of the dynamic import things and such in OSGi (to find the Bus factory). One less jar to deal with as well. The jaxrs basic sample would be down to cxf-core, cxf-transports-http, cxf-rt-frontend-jaxrs, and the related 3rd party deps.
>
> Thoughts?
>
--
Alessio Soldano
Web Service Lead, JBoss