ok, i didn't mean to be noisy. And I didn't know about
servicemix-shared-compat.
I remain of the idea that the component classes should be clearly and
completely
separated from the esb core. I agree it's just a classpath issue, but the
separation helps to clean the design.
Anyway the compat library will be ok. By the way why isn't it distribuited in
maven repository?
bye
Raffaele
Quoting Guillaume Nodet <[EMAIL PROTECTED]>:
All components currently depend on servicemix-shared shared library
which includes all the needed dependencies when deploying inside
ServiceMix. If you want to deploy inside another container, you may want
to build and install servicemix-shared-compat instead (which add a few
jars like servicemix-core).
There's no need to change any code, as this is just a class path issue
which should be easily solved by using the shared library.
Btw, servicemix-soap is already included in servicemix-shared SL.
On 10/9/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
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
--
Cheers,
Guillaume Nodet