You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@servicemix.apache.org by rs...@imolinfo.it on 2006/09/27 15:25:29 UTC
servicemix-jsr181 doesn't get boundled in install package
My binding component is depending on servicemix-jsr181 because it needs
JBITransport (see issue SM-602). So I declare this dependency in the pom.xml:
<dependency>
<groupId>org.apache.servicemix</groupId>
<artifactId>servicemix-jsr181</artifactId>
<version>3.0-incubating</version>
<scope>compile</scope>
</dependency>
When I build the install package with version 3.0-incubating the
servicemix-jsr181 doesn't get included so I get a ClassNotFoundException at
deploy time.
I didn't have this behaviour before is this a new packaging rule?
It looks like that the only way I have left is to cut and paste the JBITransport
class in my project, any advice?
thanks
Raffaele
Re: servicemix-jsr181 doesn't get boundled in install package
Posted by robottaway <ro...@musiciansfriend.com>.
gnodet wrote:
>
> The reinstallation of the shared library should have no effect on
> already installed artifacts. Components should be shut down
> and restarted just after that. What kind of problems do you
> experience ?
>
> Anyway, you're right. Update of pre-installed dependencies
> should be optional, i guess. Could you raise a JIRA
>
>
I have created a feature request under the 'tooling' component:
https://issues.apache.org/activemq/browse/SM-605
As for the problem with the shared library I mentioned above:
Here is the returned error from the plugin tool:
<?xml version="1.0" encoding="UTF-8"?>
<jbi-task xmlns="http://java.sun.com/xml/ns/jbi/management-message"
version="1.0">
<jbi-task-result>
<frmwk-task-result>
<frmwk-task-result-details>
<task-result-details>
<task-id>uninstallSharedLibrary</task-id>
<task-result>FAILED</task-result>
<message-type>ERROR</message-type>
<task-status-msg>
<msg-loc-info>
<loc-token/>
<loc-message>Shared library 'servicemix-shared' is used by component
'servicemix-eip'.</loc-message>
</msg-loc-info>
</task-status-msg>
</task-result-details>
</frmwk-task-result-details>
</frmwk-task-result>
</jbi-task-result>
</jbi-task>
And here is the output from Smix itself:
INFO - ServiceAssemblyLifeCycle - Stopping service assembly:
SmixMavenDealo-sa
INFO - ServiceAssemblyLifeCycle - Shutting down service assembly:
SmixMavenDealo-sa
INFO - ServiceUnitLifeCycle - Shutting down service unit:
SmixMavenDealo-jms-su
INFO - ServiceAssemblyLifeCycle - Shutting down service assembly:
SmixMavenDealo-sa
INFO - DeploymentService - UnDeployed ServiceUnit
SmixMavenDealo-jms-su from Component: servicemix-jms
INFO - ComponentMBeanImpl - Stopping component: servicemix-jms
INFO - ComponentMBeanImpl - Shutting down component:
servicemix-jms
INFO - ServiceAssemblyLifeCycle - Shutting down service assembly:
bridge-sa
INFO - ServiceUnitLifeCycle - Shutting down service unit:
bridge-http-su
INFO - ServiceUnitLifeCycle - Shutting down service unit:
bridge-eip-su
INFO - ServiceUnitLifeCycle - Shutting down service unit:
bridge-xslt-su
INFO - ServiceUnitLifeCycle - Shutting down service unit:
bridge-jms-su
INFO - JBIContainer - Deactivating component
servicemix-jms
INFO - EnvironmentContext - Removed directory structure for
component [version]: servicemix-jms [servicemix-jms]
--
View this message in context: http://www.nabble.com/servicemix-jsr181-doesn%27t-get-boundled-in-install-package-tf2345068.html#a6535085
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: servicemix-jsr181 doesn't get boundled in install package
Posted by Guillaume Nodet <gn...@gmail.com>.
The reinstallation of the shared library should have no effect on
already installed artifacts. Components should be shut down
and restarted just after that. What kind of problems do you
experience ?
Anyway, you're right. Update of pre-installed dependencies
should be optional, i guess. Could you raise a JIRA ?
On 9/27/06, robottaway <ro...@musiciansfriend.com> wrote:
>
> Would it be possible with the current plugin to specify the exact
> dependencies that you want deployed when using the 'mvn jbi:projectDeploy'
> goal? This maybe could solve the problem that stems from the maven goal
> trying to remove share libraries that are in use on the running Smix
> instance. Maybe it would be easier to just allow excluding of the ones you
> wouldn't want to be deployed, or even a command line list passed as a
> parameter to the plugin.
>
> What about the possiblity of having the plugin check for usage of the shared
> component before it tries to remove it. If it is installed and in use could
> it just skip trying to remove it?
>
>
> gnodet wrote:
> >
> > I guess this comes from some modifications in the jbi-maven-plugin
> > for handling shared libraries. It only includes artifacts with a "jar"
> > packaging type, and components are "jbi-components".
> > Could you try modifying the jbi-maven-plugin and remove the check
> > for "jar" (in GenerateComponentMojo.java, line 191) and see if it
> > works better ?
> >
>
> --
> View this message in context: http://www.nabble.com/servicemix-jsr181-doesn%27t-get-boundled-in-install-package-tf2345068.html#a6528611
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
Re: servicemix-jsr181 doesn't get boundled in install package
Posted by robottaway <ro...@musiciansfriend.com>.
Would it be possible with the current plugin to specify the exact
dependencies that you want deployed when using the 'mvn jbi:projectDeploy'
goal? This maybe could solve the problem that stems from the maven goal
trying to remove share libraries that are in use on the running Smix
instance. Maybe it would be easier to just allow excluding of the ones you
wouldn't want to be deployed, or even a command line list passed as a
parameter to the plugin.
What about the possiblity of having the plugin check for usage of the shared
component before it tries to remove it. If it is installed and in use could
it just skip trying to remove it?
gnodet wrote:
>
> I guess this comes from some modifications in the jbi-maven-plugin
> for handling shared libraries. It only includes artifacts with a "jar"
> packaging type, and components are "jbi-components".
> Could you try modifying the jbi-maven-plugin and remove the check
> for "jar" (in GenerateComponentMojo.java, line 191) and see if it
> works better ?
>
--
View this message in context: http://www.nabble.com/servicemix-jsr181-doesn%27t-get-boundled-in-install-package-tf2345068.html#a6528611
Sent from the ServiceMix - User mailing list archive at Nabble.com.
Re: servicemix-jsr181 doesn't get boundled in install package
Posted by Guillaume Nodet <gn...@gmail.com>.
I guess this comes from some modifications in the jbi-maven-plugin
for handling shared libraries. It only includes artifacts with a "jar"
packaging type, and components are "jbi-components".
Could you try modifying the jbi-maven-plugin and remove the check
for "jar" (in GenerateComponentMojo.java, line 191) and see if it
works better ?
On 9/27/06, rspazzoli@imolinfo.it <rs...@imolinfo.it> wrote:
> My binding component is depending on servicemix-jsr181 because it needs
> JBITransport (see issue SM-602). So I declare this dependency in the pom.xml:
> <dependency>
> <groupId>org.apache.servicemix</groupId>
> <artifactId>servicemix-jsr181</artifactId>
> <version>3.0-incubating</version>
> <scope>compile</scope>
> </dependency>
>
> When I build the install package with version 3.0-incubating the
> servicemix-jsr181 doesn't get included so I get a ClassNotFoundException at
> deploy time.
> I didn't have this behaviour before is this a new packaging rule?
>
> It looks like that the only way I have left is to cut and paste the JBITransport
> class in my project, any advice?
>
> thanks
> Raffaele
>
>
--
Cheers,
Guillaume Nodet