You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Colm O hEigeartaigh <co...@apache.org> on 2013/07/04 10:52:04 UTC
Re: [DISCUSS] api+rt-core -> core
+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 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?
>>>
>>>
>>
>
>