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 2011/12/05 18:40:30 UTC
OSGi bundles and split packages....
I kind of did a little audit this morning to try and figure out how hard it
will be to split the big bundle into little bundles to allow for smaller OSGi
footprints and such by just loading the desired functionality into OSGi
instead of the entire big bundle (and all it's deps).
At this point, we have 25 packages that are split across multiple jars. 16
of the 25 are split between common-utilities, api, and rt-core. At this
point, I'd likely just say make those 3 fragments of each other. In the
future, then figure out how to split that "big" bundle up a bit better. Some
of the 16 are "easy" (like cxf/phase) but not really worth spending time on if
all of them cannot be resolved.
Of the remaining 9, 5 are easy to resolve, 2 are "medium", and 2 are hard and
would have a big impact.
Here is my analysis:
"Big 3" packages:
org/apache/cxf/binding cxf-api cxf-rt-core
org/apache/cxf/buslifecycle cxf-api cxf-rt-core
org/apache/cxf/clustering cxf-api cxf-rt-core
org/apache/cxf/configuration cxf-api cxf-common-utilities cxf-rt-core
org/apache/cxf/configuration/spring cxf-common-utilities cxf-rt-core
org/apache/cxf/endpoint cxf-api cxf-rt-core
org/apache/cxf/feature cxf-api cxf-rt-core
org/apache/cxf/headers cxf-api cxf-rt-core
org/apache/cxf/interceptor cxf-api cxf-rt-core
org/apache/cxf/io cxf-api cxf-rt-core
org/apache/cxf/phase cxf-api cxf-rt-core
org/apache/cxf/service cxf-api cxf-rt-core
org/apache/cxf/service/invoker cxf-api cxf-rt-core
org/apache/cxf/transport cxf-api cxf-rt-core
org/apache/cxf/workqueue cxf-api cxf-rt-core
org/apache/cxf/wsdl cxf-api cxf-rt-core
Not easy:
org/apache/cxf/jaxb cxf-common-utilities cxf-rt-databinding-jaxb
Classes from both are used all over the place. Big user impact.
We COULD consider JAXB databinding a "core" thing and fragment it
in since JAXB is pretty much required for any usage of CXF.
org/apache/cxf/service/factory cxf-rt-core cxf-rt-frontend-simple
Couple classes in rt-core used by JAX-RS and thus not really pushable into
frontend-simple without pulling more deps for JAX-RS. Changing package
name in either place would affect users. (changing package for
classes in rt-core would affect a LOT less users though)
Medium:
org/apache/cxf/ws/policy cxf-api cxf-rt-ws-policy
Move impls and interceptors to private package. May impact users if
referencing the impls/interceptors directly.
Push abstract and basic stuff up to cxf-api
Couple other issues to resolve (like WSPolicyFeature requires Spring)
org/apache/cxf/ws/addressing cxf-api cxf-rt-ws-addr
Moving all the classes from api to ws-addr can be done. Users would need
to depend on cxf-rt-ws-addr in addition to cxf-api if using the classes.
The main one is the AddressingProperties interface. Some internal CXF
classes will need to be updated and fixed, but nothing major. The only
"hard" one would be AbstractMultiplexDestination's call into the
AddressingProperties, but that's all of 2 lines of code and could likely be
handled better by have ws-add save the "TO" EPR on the message/exchange
directly.
Easy:
org/apache/cxf/frontend cxf-rt-core cxf-rt-frontend-simple
Move from rt-core to sub-module (not used elsewhere anyway):
org/apache/cxf/management cxf-common-utilities cxf-rt-management
Change package for generated type. No impact to users.
org/apache/cxf/transport/http cxf-rt-core cxf-rt-transports-http
Impl in "core" moved to private package, utility class moved to common
Possible impact to users as the utility class would move.
org/apache/cxf/tools/common cxf-api cxf-tools-common
Move to tools-common and update refs or replace with constants
org/apache/cxf/tools/validator cxf-api cxf-tools-validator
Move to tools-validator and adjust dependencies and set optional imports
Anyway, what are people's thoughts on the above? Is it worth pursing more
closely for 2.6? Other than the JAXB one above that still needs a good
solution, the impact isn't very large and could easily be documented in the
migration guides.
Dan
Re: OSGi bundles and split packages....
Posted by Daniel Kulp <dk...@apache.org>.
On Tuesday, December 06, 2011 10:42:41 AM Sergey Beryozkin wrote:
> Hi
>
> On 05/12/11 19:37, Daniel Kulp wrote:
> > On Monday, December 05, 2011 7:21:59 PM David Bosschaert wrote:
> >> Big +1 from me on this (obviously). The fragment approach seems like a
> >> sensible idea to me as a migration strategy.
> >
> > Another approach COULD be to create a "cxf-core" (not cxf-rt-core)
> > bundle that is a shade/bundle of the 3 (or 4 if we include jaxb).
> > Plus's and minus's both ways. I think LONG term, I'd like a single
> > cxf-core, but I think that it would be better to do that AFTER we kind
> > of go through all 3 jars and figure out what should really be in there
> > and what could be pulled out into separate bundles. For example, all
> > the WSDL stuff in rt-core could likely be pulled into a specific
> > ws-core bundle or something that isn't needed by jaxrs. Some of the
> > interceptors are really ws specific. Etc... But moving all of THAT
> > stuff around would be very problematic. Easily a 3.0 type thing.
> >
> > The stuff I was trying to describe below can likely be done for a 2.6
> > type things as it's mostly compatible with small, targetted, relatively
> > document- able changes where required.
>
> How many bundles are we thinking of ?
>
> rt-core(possibly with jaxb)
Just that one, but even likely NOT that one by having commons/api/rt-core/jaxb
as fragment bundles.
Basically, those four would become one bundle when deployed to OSGi, but all
the other jars we build would become individual bundles that could be deployed
individually. Thus, the big bundle jars would no longer be needed.
>From a karaf standpoint, the features.xml could then have a "cxf-core" feature
which would be the above 4 jars (plus deps) and then we can have features for
the major things people care about that would install the required little
jars. For example, a cxf-jaxws feature would include cxf-rt-frontend-jaxws,
frontend-simple, bindings-soap, ws-addr, etc... A "cxf-ws-security" would
add the rt-ws-security modules. We could keep a "cxf" feature which would
be the "install everything" option like we have now.
Dan
> jaxws
> ws-addr
> ws-sec
> ws-pol
> jaxrs
>
> This is may not be the best way forward, but what about creating a few
> more 'big' bundles, ex, cxf-jaxws (simple jaxws) and cxf-ws (similar to
> cxf-all or cxf-minimal but without jaxrs) - so we'd have
>
> cxf (with non-opt jaxrs deps)
> cxf-minimal (with non-opt jaxrs deps)
> cxf-ws (no jaxrs, but with jaxws + ws*)
> cxf-jaxws (jaxws-only)
> cxf-jaxrs (jaxrs-only)
>
> May be we can do it and continue on the path of gradually creating
> OSGI-friendly individual modules for 2.6. and beyond
>
> Cheers, Sergey
>
> > One more area that may be super problematic is the /schemas directory.
> > Haven't had a chance to look at that yet, but a bunch of the jars expose
> > schemas from there and you obviously cannot have a bunch of bundles
> > exposing the same schemas dir like that. That's another huge issue.
> >
> >> WRT to changing packages, if you are really worried about backward
> >> compatibility but would like to refactor the split packages out you
> >> *could* consider renaming the package and creating a compatibility
> >> bundle or fragment that contains the 'old' split packages and
> >> delegates to the new ones. The users can slowly migrate. Non-migrated
> >> users would need the compat bundle. Migrated ones will not need it...
> >> It's not always practical, but it's an option to consider...
> >
> > Doesn't really work for CXF, at least of the areas I looked at. For
> > the most part, the stuff that needs to move are interfaces that the
> > impls' would need to implement. Thus, without some complex weaving to
> > add the interfaces onto the impls at runtime, it would be a bit more
> > difficult.
> >
> > Dan
> >
> >> Cheers,
> >>
> >> David
> >>
> >> On 5 December 2011 17:40, Daniel Kulp<dk...@apache.org> wrote:
> >>> I kind of did a little audit this morning to try and figure out how
> >>> hard it will be to split the big bundle into little bundles to
> >>> allow for smaller OSGi footprints and such by just loading the
> >>> desired
> >>> functionality into OSGi instead of the entire big bundle (and all
> >>> it's
> >>> deps).
> >>>
> >>> At this point, we have 25 packages that are split across multiple
> >>> jars.
> >>>
> >>> 16 of the 25 are split between common-utilities, api, and
> >>> rt-core.
> >>>
> >>> At this point, I'd likely just say make those 3 fragments of each
> >>> other. In the future, then figure out how to split that "big"
> >>> bundle
> >>> up a bit better. Some of the 16 are "easy" (like cxf/phase) but
> >>> not
> >>> really worth spending time on if all of them cannot be resolved.
> >>>
> >>> Of the remaining 9, 5 are easy to resolve, 2 are "medium", and 2 are
> >>> hard and would have a big impact.
> >>>
> >>>
> >>> Here is my analysis:
> >>>
> >>> "Big 3" packages:
> >>> org/apache/cxf/binding cxf-api cxf-rt-core
> >>> org/apache/cxf/buslifecycle cxf-api cxf-rt-core
> >>> org/apache/cxf/clustering cxf-api cxf-rt-core
> >>> org/apache/cxf/configuration cxf-api cxf-common-utilities
> >>> cxf-rt-core
> >>> org/apache/cxf/configuration/spring cxf-common-utilities
> >>> cxf-rt-core
> >>> org/apache/cxf/endpoint cxf-api cxf-rt-core
> >>> org/apache/cxf/feature cxf-api cxf-rt-core
> >>> org/apache/cxf/headers cxf-api cxf-rt-core
> >>> org/apache/cxf/interceptor cxf-api cxf-rt-core
> >>> org/apache/cxf/io cxf-api cxf-rt-core
> >>> org/apache/cxf/phase cxf-api cxf-rt-core
> >>> org/apache/cxf/service cxf-api cxf-rt-core
> >>> org/apache/cxf/service/invoker cxf-api cxf-rt-core
> >>> org/apache/cxf/transport cxf-api cxf-rt-core
> >>> org/apache/cxf/workqueue cxf-api cxf-rt-core
> >>> org/apache/cxf/wsdl cxf-api cxf-rt-core
> >>>
> >>>
> >>> Not easy:
> >>> org/apache/cxf/jaxb cxf-common-utilities cxf-rt-databinding-jaxb
> >>>
> >>> Classes from both are used all over the place. Big user
> >>> impact.
> >>> We COULD consider JAXB databinding a "core" thing and
> >>> fragment it
> >>> in since JAXB is pretty much required for any usage of CXF.
> >>>
> >>> org/apache/cxf/service/factory cxf-rt-core cxf-rt-frontend-simple
> >>>
> >>> Couple classes in rt-core used by JAX-RS and thus not really
> >>> pushable>>>
> >>> into frontend-simple without pulling more deps for JAX-RS.
> >>> Changing
> >>> package name in either place would affect users. (changing package
> >>> for
> >>> classes in rt-core would affect a LOT less users though)
> >>>
> >>>
> >>>
> >>> Medium:
> >>> org/apache/cxf/ws/policy cxf-api cxf-rt-ws-policy
> >>>
> >>> Move impls and interceptors to private package. May impact
> >>> users if
> >>>
> >>> referencing the impls/interceptors directly.
> >>>
> >>> Push abstract and basic stuff up to cxf-api
> >>> Couple other issues to resolve (like WSPolicyFeature requires
> >>> Spring)>>>
> >>> org/apache/cxf/ws/addressing cxf-api cxf-rt-ws-addr
> >>>
> >>> Moving all the classes from api to ws-addr can be done. Users
> >>> would
> >>>
> >>> need to depend on cxf-rt-ws-addr in addition to cxf-api if using the
> >>> classes. The main one is the AddressingProperties interface. Some
> >>> internal CXF classes will need to be updated and fixed, but nothing
> >>> major. The only "hard" one would be AbstractMultiplexDestination's
> >>> call into the AddressingProperties, but that's all of 2 lines of
> >>> code
> >>> and could likely be handled better by have ws-add save the "TO" EPR
> >>> on
> >>> the message/exchange directly.
> >>>
> >>> Easy:
> >>> org/apache/cxf/frontend cxf-rt-core cxf-rt-frontend-simple
> >>>
> >>> Move from rt-core to sub-module (not used elsewhere anyway):
> >>> org/apache/cxf/management cxf-common-utilities cxf-rt-management
> >>>
> >>> Change package for generated type. No impact to users.
> >>>
> >>> org/apache/cxf/transport/http cxf-rt-core cxf-rt-transports-http
> >>>
> >>> Impl in "core" moved to private package, utility class moved
> >>> to
> >>>
> >>> common
> >>>
> >>> Possible impact to users as the utility class would move.
> >>>
> >>> org/apache/cxf/tools/common cxf-api cxf-tools-common
> >>>
> >>> Move to tools-common and update refs or replace with
> >>> constants
> >>>
> >>> org/apache/cxf/tools/validator cxf-api cxf-tools-validator
> >>>
> >>> Move to tools-validator and adjust dependencies and set
> >>> optional
> >>>
> >>> imports
> >>>
> >>>
> >>> Anyway, what are people's thoughts on the above? Is it worth
> >>> pursing
> >>> more closely for 2.6? Other than the JAXB one above that still
> >>> needs
> >>> a good solution, the impact isn't very large and could easily be
> >>> documented in the migration guides.
> >>>
> >>>
> >>> Dan
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: OSGi bundles and split packages....
Posted by Sergey Beryozkin <sb...@gmail.com>.
On 06/12/11 10:42, Sergey Beryozkin wrote:
> Hi
>
> On 05/12/11 19:37, Daniel Kulp wrote:
>> On Monday, December 05, 2011 7:21:59 PM David Bosschaert wrote:
>>> Big +1 from me on this (obviously). The fragment approach seems like a
>>> sensible idea to me as a migration strategy.
>>
>> Another approach COULD be to create a "cxf-core" (not cxf-rt-core)
>> bundle that
>> is a shade/bundle of the 3 (or 4 if we include jaxb). Plus's and minus's
>> both ways. I think LONG term, I'd like a single cxf-core, but I think
>> that
>> it would be better to do that AFTER we kind of go through all 3 jars and
>> figure out what should really be in there and what could be pulled out
>> into
>> separate bundles. For example, all the WSDL stuff in rt-core could
>> likely be
>> pulled into a specific ws-core bundle or something that isn't needed
>> by jaxrs.
>> Some of the interceptors are really ws specific. Etc... But moving all of
>> THAT stuff around would be very problematic. Easily a 3.0 type thing.
>>
>> The stuff I was trying to describe below can likely be done for a 2.6
>> type
>> things as it's mostly compatible with small, targetted, relatively
>> document-
>> able changes where required.
>
> How many bundles are we thinking of ?
>
> rt-core(possibly with jaxb)
> jaxws
> ws-addr
> ws-sec
> ws-pol
> jaxrs
>
> This is may not be the best way forward, but what about creating a few
> more 'big' bundles, ex, cxf-jaxws (simple jaxws) and cxf-ws (similar to
> cxf-all or cxf-minimal but without jaxrs) - so we'd have
>
> cxf (with non-opt jaxrs deps)
> cxf-minimal (with non-opt jaxrs deps)
> cxf-ws (no jaxrs, but with jaxws + ws*)
> cxf-jaxws (jaxws-only)
> cxf-jaxrs (jaxrs-only)
>
> May be we can do it and continue on the path of gradually creating
> OSGI-friendly individual modules for 2.6. and beyond
May be we should just continue on the OSGI-fication path instead of
introducing two more big bundles...
I thought that adding those extra bundles can 'cover' most of what CXF
users do with CXF in the short to medium term, but I'm getting a bit
concerned if making a JAXRS dep non-optional for the cxf-bundle can
affect somehow the existing SOAP-only cxf-bundle consumers. May be this
concern is not founded but you never know :-)
Anyway, making major individual modules OSGI-friendly is a good/right
idea on its own
Sergey
>>
>> One more area that may be super problematic is the /schemas directory.
>> Haven't had a chance to look at that yet, but a bunch of the jars expose
>> schemas from there and you obviously cannot have a bunch of bundles
>> exposing
>> the same schemas dir like that. That's another huge issue.
>>
>>
>>> WRT to changing packages, if you are really worried about backward
>>> compatibility but would like to refactor the split packages out you
>>> *could* consider renaming the package and creating a compatibility
>>> bundle or fragment that contains the 'old' split packages and
>>> delegates to the new ones. The users can slowly migrate. Non-migrated
>>> users would need the compat bundle. Migrated ones will not need it...
>>> It's not always practical, but it's an option to consider...
>>
>> Doesn't really work for CXF, at least of the areas I looked at. For
>> the most
>> part, the stuff that needs to move are interfaces that the impls'
>> would need
>> to implement. Thus, without some complex weaving to add the interfaces
>> onto
>> the impls at runtime, it would be a bit more difficult.
>>
>> Dan
>>
>>
>>>
>>> Cheers,
>>>
>>> David
>>>
>>> On 5 December 2011 17:40, Daniel Kulp<dk...@apache.org> wrote:
>>>> I kind of did a little audit this morning to try and figure out how
>>>> hard
>>>> it will be to split the big bundle into little bundles to allow for
>>>> smaller OSGi footprints and such by just loading the desired
>>>> functionality into OSGi instead of the entire big bundle (and all it's
>>>> deps).
>>>>
>>>> At this point, we have 25 packages that are split across multiple jars.
>>>> 16 of the 25 are split between common-utilities, api, and rt-core.
>>>> At this point, I'd likely just say make those 3 fragments of each
>>>> other. In the future, then figure out how to split that "big" bundle
>>>> up a bit better. Some of the 16 are "easy" (like cxf/phase) but not
>>>> really worth spending time on if all of them cannot be resolved.
>>>>
>>>> Of the remaining 9, 5 are easy to resolve, 2 are "medium", and 2 are
>>>> hard and would have a big impact.
>>>>
>>>>
>>>> Here is my analysis:
>>>>
>>>> "Big 3" packages:
>>>> org/apache/cxf/binding cxf-api cxf-rt-core
>>>> org/apache/cxf/buslifecycle cxf-api cxf-rt-core
>>>> org/apache/cxf/clustering cxf-api cxf-rt-core
>>>> org/apache/cxf/configuration cxf-api cxf-common-utilities cxf-rt-core
>>>> org/apache/cxf/configuration/spring cxf-common-utilities cxf-rt-core
>>>> org/apache/cxf/endpoint cxf-api cxf-rt-core
>>>> org/apache/cxf/feature cxf-api cxf-rt-core
>>>> org/apache/cxf/headers cxf-api cxf-rt-core
>>>> org/apache/cxf/interceptor cxf-api cxf-rt-core
>>>> org/apache/cxf/io cxf-api cxf-rt-core
>>>> org/apache/cxf/phase cxf-api cxf-rt-core
>>>> org/apache/cxf/service cxf-api cxf-rt-core
>>>> org/apache/cxf/service/invoker cxf-api cxf-rt-core
>>>> org/apache/cxf/transport cxf-api cxf-rt-core
>>>> org/apache/cxf/workqueue cxf-api cxf-rt-core
>>>> org/apache/cxf/wsdl cxf-api cxf-rt-core
>>>>
>>>>
>>>> Not easy:
>>>> org/apache/cxf/jaxb cxf-common-utilities cxf-rt-databinding-jaxb
>>>> Classes from both are used all over the place. Big user impact.
>>>> We COULD consider JAXB databinding a "core" thing and fragment it
>>>> in since JAXB is pretty much required for any usage of CXF.
>>>>
>>>> org/apache/cxf/service/factory cxf-rt-core cxf-rt-frontend-simple
>>>> Couple classes in rt-core used by JAX-RS and thus not really pushable
>>>> into frontend-simple without pulling more deps for JAX-RS. Changing
>>>> package name in either place would affect users. (changing package for
>>>> classes in rt-core would affect a LOT less users though)
>>>>
>>>>
>>>>
>>>> Medium:
>>>> org/apache/cxf/ws/policy cxf-api cxf-rt-ws-policy
>>>> Move impls and interceptors to private package. May impact users if
>>>> referencing the impls/interceptors directly.
>>>> Push abstract and basic stuff up to cxf-api
>>>> Couple other issues to resolve (like WSPolicyFeature requires Spring)
>>>>
>>>> org/apache/cxf/ws/addressing cxf-api cxf-rt-ws-addr
>>>> Moving all the classes from api to ws-addr can be done. Users would
>>>> need to depend on cxf-rt-ws-addr in addition to cxf-api if using the
>>>> classes. The main one is the AddressingProperties interface. Some
>>>> internal CXF classes will need to be updated and fixed, but nothing
>>>> major. The only "hard" one would be AbstractMultiplexDestination's
>>>> call into the AddressingProperties, but that's all of 2 lines of code
>>>> and could likely be handled better by have ws-add save the "TO" EPR on
>>>> the message/exchange directly.
>>>>
>>>> Easy:
>>>> org/apache/cxf/frontend cxf-rt-core cxf-rt-frontend-simple
>>>> Move from rt-core to sub-module (not used elsewhere anyway):
>>>> org/apache/cxf/management cxf-common-utilities cxf-rt-management
>>>> Change package for generated type. No impact to users.
>>>> org/apache/cxf/transport/http cxf-rt-core cxf-rt-transports-http
>>>> Impl in "core" moved to private package, utility class moved to
>>>> common
>>>> Possible impact to users as the utility class would move.
>>>> org/apache/cxf/tools/common cxf-api cxf-tools-common
>>>> Move to tools-common and update refs or replace with constants
>>>> org/apache/cxf/tools/validator cxf-api cxf-tools-validator
>>>> Move to tools-validator and adjust dependencies and set optional
>>>> imports
>>>>
>>>>
>>>> Anyway, what are people's thoughts on the above? Is it worth pursing
>>>> more closely for 2.6? Other than the JAXB one above that still needs
>>>> a good solution, the impact isn't very large and could easily be
>>>> documented in the migration guides.
>>>>
>>>>
>>>> Dan
>
>
Re: OSGi bundles and split packages....
Posted by Sergey Beryozkin <sb...@gmail.com>.
Hi
On 05/12/11 19:37, Daniel Kulp wrote:
> On Monday, December 05, 2011 7:21:59 PM David Bosschaert wrote:
>> Big +1 from me on this (obviously). The fragment approach seems like a
>> sensible idea to me as a migration strategy.
>
> Another approach COULD be to create a "cxf-core" (not cxf-rt-core) bundle that
> is a shade/bundle of the 3 (or 4 if we include jaxb). Plus's and minus's
> both ways. I think LONG term, I'd like a single cxf-core, but I think that
> it would be better to do that AFTER we kind of go through all 3 jars and
> figure out what should really be in there and what could be pulled out into
> separate bundles. For example, all the WSDL stuff in rt-core could likely be
> pulled into a specific ws-core bundle or something that isn't needed by jaxrs.
> Some of the interceptors are really ws specific. Etc... But moving all of
> THAT stuff around would be very problematic. Easily a 3.0 type thing.
>
> The stuff I was trying to describe below can likely be done for a 2.6 type
> things as it's mostly compatible with small, targetted, relatively document-
> able changes where required.
How many bundles are we thinking of ?
rt-core(possibly with jaxb)
jaxws
ws-addr
ws-sec
ws-pol
jaxrs
This is may not be the best way forward, but what about creating a few
more 'big' bundles, ex, cxf-jaxws (simple jaxws) and cxf-ws (similar to
cxf-all or cxf-minimal but without jaxrs) - so we'd have
cxf (with non-opt jaxrs deps)
cxf-minimal (with non-opt jaxrs deps)
cxf-ws (no jaxrs, but with jaxws + ws*)
cxf-jaxws (jaxws-only)
cxf-jaxrs (jaxrs-only)
May be we can do it and continue on the path of gradually creating
OSGI-friendly individual modules for 2.6. and beyond
Cheers, Sergey
>
> One more area that may be super problematic is the /schemas directory.
> Haven't had a chance to look at that yet, but a bunch of the jars expose
> schemas from there and you obviously cannot have a bunch of bundles exposing
> the same schemas dir like that. That's another huge issue.
>
>
>> WRT to changing packages, if you are really worried about backward
>> compatibility but would like to refactor the split packages out you
>> *could* consider renaming the package and creating a compatibility
>> bundle or fragment that contains the 'old' split packages and
>> delegates to the new ones. The users can slowly migrate. Non-migrated
>> users would need the compat bundle. Migrated ones will not need it...
>> It's not always practical, but it's an option to consider...
>
> Doesn't really work for CXF, at least of the areas I looked at. For the most
> part, the stuff that needs to move are interfaces that the impls' would need
> to implement. Thus, without some complex weaving to add the interfaces onto
> the impls at runtime, it would be a bit more difficult.
>
> Dan
>
>
>>
>> Cheers,
>>
>> David
>>
>> On 5 December 2011 17:40, Daniel Kulp<dk...@apache.org> wrote:
>>> I kind of did a little audit this morning to try and figure out how hard
>>> it will be to split the big bundle into little bundles to allow for
>>> smaller OSGi footprints and such by just loading the desired
>>> functionality into OSGi instead of the entire big bundle (and all it's
>>> deps).
>>>
>>> At this point, we have 25 packages that are split across multiple jars.
>>> 16 of the 25 are split between common-utilities, api, and rt-core.
>>> At this point, I'd likely just say make those 3 fragments of each
>>> other. In the future, then figure out how to split that "big" bundle
>>> up a bit better. Some of the 16 are "easy" (like cxf/phase) but not
>>> really worth spending time on if all of them cannot be resolved.
>>>
>>> Of the remaining 9, 5 are easy to resolve, 2 are "medium", and 2 are
>>> hard and would have a big impact.
>>>
>>>
>>> Here is my analysis:
>>>
>>> "Big 3" packages:
>>> org/apache/cxf/binding cxf-api cxf-rt-core
>>> org/apache/cxf/buslifecycle cxf-api cxf-rt-core
>>> org/apache/cxf/clustering cxf-api cxf-rt-core
>>> org/apache/cxf/configuration cxf-api cxf-common-utilities cxf-rt-core
>>> org/apache/cxf/configuration/spring cxf-common-utilities cxf-rt-core
>>> org/apache/cxf/endpoint cxf-api cxf-rt-core
>>> org/apache/cxf/feature cxf-api cxf-rt-core
>>> org/apache/cxf/headers cxf-api cxf-rt-core
>>> org/apache/cxf/interceptor cxf-api cxf-rt-core
>>> org/apache/cxf/io cxf-api cxf-rt-core
>>> org/apache/cxf/phase cxf-api cxf-rt-core
>>> org/apache/cxf/service cxf-api cxf-rt-core
>>> org/apache/cxf/service/invoker cxf-api cxf-rt-core
>>> org/apache/cxf/transport cxf-api cxf-rt-core
>>> org/apache/cxf/workqueue cxf-api cxf-rt-core
>>> org/apache/cxf/wsdl cxf-api cxf-rt-core
>>>
>>>
>>> Not easy:
>>> org/apache/cxf/jaxb cxf-common-utilities cxf-rt-databinding-jaxb
>>> Classes from both are used all over the place. Big user impact.
>>> We COULD consider JAXB databinding a "core" thing and fragment it
>>> in since JAXB is pretty much required for any usage of CXF.
>>>
>>> org/apache/cxf/service/factory cxf-rt-core cxf-rt-frontend-simple
>>> Couple classes in rt-core used by JAX-RS and thus not really pushable
>>> into frontend-simple without pulling more deps for JAX-RS. Changing
>>> package name in either place would affect users. (changing package for
>>> classes in rt-core would affect a LOT less users though)
>>>
>>>
>>>
>>> Medium:
>>> org/apache/cxf/ws/policy cxf-api cxf-rt-ws-policy
>>> Move impls and interceptors to private package. May impact users if
>>> referencing the impls/interceptors directly.
>>> Push abstract and basic stuff up to cxf-api
>>> Couple other issues to resolve (like WSPolicyFeature requires Spring)
>>>
>>> org/apache/cxf/ws/addressing cxf-api cxf-rt-ws-addr
>>> Moving all the classes from api to ws-addr can be done. Users would
>>> need to depend on cxf-rt-ws-addr in addition to cxf-api if using the
>>> classes. The main one is the AddressingProperties interface. Some
>>> internal CXF classes will need to be updated and fixed, but nothing
>>> major. The only "hard" one would be AbstractMultiplexDestination's
>>> call into the AddressingProperties, but that's all of 2 lines of code
>>> and could likely be handled better by have ws-add save the "TO" EPR on
>>> the message/exchange directly.
>>>
>>> Easy:
>>> org/apache/cxf/frontend cxf-rt-core cxf-rt-frontend-simple
>>> Move from rt-core to sub-module (not used elsewhere anyway):
>>> org/apache/cxf/management cxf-common-utilities cxf-rt-management
>>> Change package for generated type. No impact to users.
>>> org/apache/cxf/transport/http cxf-rt-core cxf-rt-transports-http
>>> Impl in "core" moved to private package, utility class moved to
>>> common
>>> Possible impact to users as the utility class would move.
>>> org/apache/cxf/tools/common cxf-api cxf-tools-common
>>> Move to tools-common and update refs or replace with constants
>>> org/apache/cxf/tools/validator cxf-api cxf-tools-validator
>>> Move to tools-validator and adjust dependencies and set optional
>>> imports
>>>
>>>
>>> Anyway, what are people's thoughts on the above? Is it worth pursing
>>> more closely for 2.6? Other than the JAXB one above that still needs
>>> a good solution, the impact isn't very large and could easily be
>>> documented in the migration guides.
>>>
>>>
>>> Dan
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
Re: OSGi bundles and split packages....
Posted by David Bosschaert <da...@gmail.com>.
>> WRT to changing packages, if you are really worried about backward
>> compatibility but would like to refactor the split packages out you
>> *could* consider renaming the package and creating a compatibility
>> bundle or fragment that contains the 'old' split packages and
>> delegates to the new ones. The users can slowly migrate. Non-migrated
>> users would need the compat bundle. Migrated ones will not need it...
>> It's not always practical, but it's an option to consider...
>
> Doesn't really work for CXF, at least of the areas I looked at. For the most
> part, the stuff that needs to move are interfaces that the impls' would need
> to implement. Thus, without some complex weaving to add the interfaces onto
> the impls at runtime, it would be a bit more difficult.
You could probably achieve some results with java.lang.reflect.Proxy,
but either way this would not be much fun.
I might be a possibility if you're only talking about a small number
of problematic cases...
Cheers,
David
Re: OSGi bundles and split packages....
Posted by Daniel Kulp <dk...@apache.org>.
On Monday, December 05, 2011 7:21:59 PM David Bosschaert wrote:
> Big +1 from me on this (obviously). The fragment approach seems like a
> sensible idea to me as a migration strategy.
Another approach COULD be to create a "cxf-core" (not cxf-rt-core) bundle that
is a shade/bundle of the 3 (or 4 if we include jaxb). Plus's and minus's
both ways. I think LONG term, I'd like a single cxf-core, but I think that
it would be better to do that AFTER we kind of go through all 3 jars and
figure out what should really be in there and what could be pulled out into
separate bundles. For example, all the WSDL stuff in rt-core could likely be
pulled into a specific ws-core bundle or something that isn't needed by jaxrs.
Some of the interceptors are really ws specific. Etc... But moving all of
THAT stuff around would be very problematic. Easily a 3.0 type thing.
The stuff I was trying to describe below can likely be done for a 2.6 type
things as it's mostly compatible with small, targetted, relatively document-
able changes where required.
One more area that may be super problematic is the /schemas directory.
Haven't had a chance to look at that yet, but a bunch of the jars expose
schemas from there and you obviously cannot have a bunch of bundles exposing
the same schemas dir like that. That's another huge issue.
> WRT to changing packages, if you are really worried about backward
> compatibility but would like to refactor the split packages out you
> *could* consider renaming the package and creating a compatibility
> bundle or fragment that contains the 'old' split packages and
> delegates to the new ones. The users can slowly migrate. Non-migrated
> users would need the compat bundle. Migrated ones will not need it...
> It's not always practical, but it's an option to consider...
Doesn't really work for CXF, at least of the areas I looked at. For the most
part, the stuff that needs to move are interfaces that the impls' would need
to implement. Thus, without some complex weaving to add the interfaces onto
the impls at runtime, it would be a bit more difficult.
Dan
>
> Cheers,
>
> David
>
> On 5 December 2011 17:40, Daniel Kulp <dk...@apache.org> wrote:
> > I kind of did a little audit this morning to try and figure out how hard
> > it will be to split the big bundle into little bundles to allow for
> > smaller OSGi footprints and such by just loading the desired
> > functionality into OSGi instead of the entire big bundle (and all it's
> > deps).
> >
> > At this point, we have 25 packages that are split across multiple jars.
> > 16 of the 25 are split between common-utilities, api, and rt-core.
> > At this point, I'd likely just say make those 3 fragments of each
> > other. In the future, then figure out how to split that "big" bundle
> > up a bit better. Some of the 16 are "easy" (like cxf/phase) but not
> > really worth spending time on if all of them cannot be resolved.
> >
> > Of the remaining 9, 5 are easy to resolve, 2 are "medium", and 2 are
> > hard and would have a big impact.
> >
> >
> > Here is my analysis:
> >
> > "Big 3" packages:
> > org/apache/cxf/binding cxf-api cxf-rt-core
> > org/apache/cxf/buslifecycle cxf-api cxf-rt-core
> > org/apache/cxf/clustering cxf-api cxf-rt-core
> > org/apache/cxf/configuration cxf-api cxf-common-utilities cxf-rt-core
> > org/apache/cxf/configuration/spring cxf-common-utilities cxf-rt-core
> > org/apache/cxf/endpoint cxf-api cxf-rt-core
> > org/apache/cxf/feature cxf-api cxf-rt-core
> > org/apache/cxf/headers cxf-api cxf-rt-core
> > org/apache/cxf/interceptor cxf-api cxf-rt-core
> > org/apache/cxf/io cxf-api cxf-rt-core
> > org/apache/cxf/phase cxf-api cxf-rt-core
> > org/apache/cxf/service cxf-api cxf-rt-core
> > org/apache/cxf/service/invoker cxf-api cxf-rt-core
> > org/apache/cxf/transport cxf-api cxf-rt-core
> > org/apache/cxf/workqueue cxf-api cxf-rt-core
> > org/apache/cxf/wsdl cxf-api cxf-rt-core
> >
> >
> > Not easy:
> > org/apache/cxf/jaxb cxf-common-utilities cxf-rt-databinding-jaxb
> > Classes from both are used all over the place. Big user impact.
> > We COULD consider JAXB databinding a "core" thing and fragment it
> > in since JAXB is pretty much required for any usage of CXF.
> >
> > org/apache/cxf/service/factory cxf-rt-core cxf-rt-frontend-simple
> > Couple classes in rt-core used by JAX-RS and thus not really pushable
> > into frontend-simple without pulling more deps for JAX-RS. Changing
> > package name in either place would affect users. (changing package for
> > classes in rt-core would affect a LOT less users though)
> >
> >
> >
> > Medium:
> > org/apache/cxf/ws/policy cxf-api cxf-rt-ws-policy
> > Move impls and interceptors to private package. May impact users if
> > referencing the impls/interceptors directly.
> > Push abstract and basic stuff up to cxf-api
> > Couple other issues to resolve (like WSPolicyFeature requires Spring)
> >
> > org/apache/cxf/ws/addressing cxf-api cxf-rt-ws-addr
> > Moving all the classes from api to ws-addr can be done. Users would
> > need to depend on cxf-rt-ws-addr in addition to cxf-api if using the
> > classes. The main one is the AddressingProperties interface. Some
> > internal CXF classes will need to be updated and fixed, but nothing
> > major. The only "hard" one would be AbstractMultiplexDestination's
> > call into the AddressingProperties, but that's all of 2 lines of code
> > and could likely be handled better by have ws-add save the "TO" EPR on
> > the message/exchange directly.
> >
> > Easy:
> > org/apache/cxf/frontend cxf-rt-core cxf-rt-frontend-simple
> > Move from rt-core to sub-module (not used elsewhere anyway):
> > org/apache/cxf/management cxf-common-utilities cxf-rt-management
> > Change package for generated type. No impact to users.
> > org/apache/cxf/transport/http cxf-rt-core cxf-rt-transports-http
> > Impl in "core" moved to private package, utility class moved to
> > common
> > Possible impact to users as the utility class would move.
> > org/apache/cxf/tools/common cxf-api cxf-tools-common
> > Move to tools-common and update refs or replace with constants
> > org/apache/cxf/tools/validator cxf-api cxf-tools-validator
> > Move to tools-validator and adjust dependencies and set optional
> > imports
> >
> >
> > Anyway, what are people's thoughts on the above? Is it worth pursing
> > more closely for 2.6? Other than the JAXB one above that still needs
> > a good solution, the impact isn't very large and could easily be
> > documented in the migration guides.
> >
> >
> > Dan
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: OSGi bundles and split packages....
Posted by David Bosschaert <da...@gmail.com>.
Big +1 from me on this (obviously). The fragment approach seems like a
sensible idea to me as a migration strategy.
WRT to changing packages, if you are really worried about backward
compatibility but would like to refactor the split packages out you
*could* consider renaming the package and creating a compatibility
bundle or fragment that contains the 'old' split packages and
delegates to the new ones. The users can slowly migrate. Non-migrated
users would need the compat bundle. Migrated ones will not need it...
It's not always practical, but it's an option to consider...
Cheers,
David
On 5 December 2011 17:40, Daniel Kulp <dk...@apache.org> wrote:
>
> I kind of did a little audit this morning to try and figure out how hard it
> will be to split the big bundle into little bundles to allow for smaller OSGi
> footprints and such by just loading the desired functionality into OSGi
> instead of the entire big bundle (and all it's deps).
>
> At this point, we have 25 packages that are split across multiple jars. 16
> of the 25 are split between common-utilities, api, and rt-core. At this
> point, I'd likely just say make those 3 fragments of each other. In the
> future, then figure out how to split that "big" bundle up a bit better. Some
> of the 16 are "easy" (like cxf/phase) but not really worth spending time on if
> all of them cannot be resolved.
>
> Of the remaining 9, 5 are easy to resolve, 2 are "medium", and 2 are hard and
> would have a big impact.
>
>
> Here is my analysis:
>
> "Big 3" packages:
> org/apache/cxf/binding cxf-api cxf-rt-core
> org/apache/cxf/buslifecycle cxf-api cxf-rt-core
> org/apache/cxf/clustering cxf-api cxf-rt-core
> org/apache/cxf/configuration cxf-api cxf-common-utilities cxf-rt-core
> org/apache/cxf/configuration/spring cxf-common-utilities cxf-rt-core
> org/apache/cxf/endpoint cxf-api cxf-rt-core
> org/apache/cxf/feature cxf-api cxf-rt-core
> org/apache/cxf/headers cxf-api cxf-rt-core
> org/apache/cxf/interceptor cxf-api cxf-rt-core
> org/apache/cxf/io cxf-api cxf-rt-core
> org/apache/cxf/phase cxf-api cxf-rt-core
> org/apache/cxf/service cxf-api cxf-rt-core
> org/apache/cxf/service/invoker cxf-api cxf-rt-core
> org/apache/cxf/transport cxf-api cxf-rt-core
> org/apache/cxf/workqueue cxf-api cxf-rt-core
> org/apache/cxf/wsdl cxf-api cxf-rt-core
>
>
> Not easy:
> org/apache/cxf/jaxb cxf-common-utilities cxf-rt-databinding-jaxb
> Classes from both are used all over the place. Big user impact.
> We COULD consider JAXB databinding a "core" thing and fragment it
> in since JAXB is pretty much required for any usage of CXF.
>
> org/apache/cxf/service/factory cxf-rt-core cxf-rt-frontend-simple
> Couple classes in rt-core used by JAX-RS and thus not really pushable into
> frontend-simple without pulling more deps for JAX-RS. Changing package
> name in either place would affect users. (changing package for
> classes in rt-core would affect a LOT less users though)
>
>
>
> Medium:
> org/apache/cxf/ws/policy cxf-api cxf-rt-ws-policy
> Move impls and interceptors to private package. May impact users if
> referencing the impls/interceptors directly.
> Push abstract and basic stuff up to cxf-api
> Couple other issues to resolve (like WSPolicyFeature requires Spring)
>
> org/apache/cxf/ws/addressing cxf-api cxf-rt-ws-addr
> Moving all the classes from api to ws-addr can be done. Users would need
> to depend on cxf-rt-ws-addr in addition to cxf-api if using the classes.
> The main one is the AddressingProperties interface. Some internal CXF
> classes will need to be updated and fixed, but nothing major. The only
> "hard" one would be AbstractMultiplexDestination's call into the
> AddressingProperties, but that's all of 2 lines of code and could likely be
> handled better by have ws-add save the "TO" EPR on the message/exchange
> directly.
>
> Easy:
> org/apache/cxf/frontend cxf-rt-core cxf-rt-frontend-simple
> Move from rt-core to sub-module (not used elsewhere anyway):
> org/apache/cxf/management cxf-common-utilities cxf-rt-management
> Change package for generated type. No impact to users.
> org/apache/cxf/transport/http cxf-rt-core cxf-rt-transports-http
> Impl in "core" moved to private package, utility class moved to common
> Possible impact to users as the utility class would move.
> org/apache/cxf/tools/common cxf-api cxf-tools-common
> Move to tools-common and update refs or replace with constants
> org/apache/cxf/tools/validator cxf-api cxf-tools-validator
> Move to tools-validator and adjust dependencies and set optional imports
>
>
> Anyway, what are people's thoughts on the above? Is it worth pursing more
> closely for 2.6? Other than the JAXB one above that still needs a good
> solution, the impact isn't very large and could easily be documented in the
> migration guides.
>
>
> Dan
>