cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <>
Subject Re: OSGi bundles and split packages....
Date Mon, 05 Dec 2011 19:21:59 GMT
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...



On 5 December 2011 17:40, Daniel Kulp <> 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

View raw message