I've written the servicemix-shared-compat module when trying to integrate the components inside Petal some time ago. Unfortunately, at that time, Petal was missing some JBI specified features, so I stopped the experiments.
Btw, we need to refactor the source tree (see http://goopen.org/confluence/display/SM/Source+Structure). At that time, I'd like to have a module which would contain the ServiceMix specific APIs that components could use to access ServiceMix specific features. This API should help having a clean separation between the core container and the components. Also, it will certainly lead to a new library containing commonly used classes (expressions, jaxp sources, etc...) On 10/9/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
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
-- Cheers, Guillaume Nodet
