Hi,
I'm again on this topic. I'm working on having my components non dependant on
servicemix implementation. I understand that this is also an objective for
servicemix components.
The assumption is to use the framework provided by servicemix and contained in
servicemix-common to write components more easily. At the moment
servicemix-common is included in a shared library: servicemix-shared, which
also include servicemix-soap. I don't know if servicemix-soap can be considered
part of the component framework so for the moment I'll concentrate on
servimix-common.
A component should rely only on JBI API to be portable. Thanks to classloader
isolation inside the ESB container a component can bring with itself all the
library it needs to work.
Examining the servicemix-common pom to understand its dependecy (subversion
head) the following came out:
servicemix-jbi   : provided
servicemix-core  : provided
commons-logging  : provided
xbean-server     : provided
spring           : provoded
geronimo-jta_1.0.1B_spec : provided
geronimo-j2ee-connector_1.5_spec : provided
activemq-ra      : test

I think that servicemix-core can't be provided because it won't be there in
another ESB container. So for me this entry should disappear or set to test if
needed for testing. commons-logging, xbean.server and spring should instead
should be set to compile because they are needed and we can't be sure they'll
be provided by ESB container.
I think this is the first step to build independent component. I'm afarid this
would have some impact on servicemix-common code so for now I'm going to stop
work and wait for feedback.
The same kind thought could be done on servimix-soap.

thanks
Raffaele



Reply via email to