Cargo
  1. Cargo
  2. CARGO-416

JMX deployer currently uses the same path on the local filesystem and on the server one

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.3-maven2
    • Fix Version/s: 1.0.3
    • Component/s: JBoss, Maven2
    • Labels:
      None
    • Complexity:
      Intermediate
    • Tested on JDKs:
      1.5
    • Number of attachments :
      9

      Description

      I have trouble deploying to a remote JBoss server using the cargo-maven2 plugin from my local PC. I have posted on the cargo newsgroup and received this answer:

      "Your configuration looks good. I've just checked the source code the JBoss remote deployer (JBossRemoteDeployer.java class) and there are 2 things:

      • We're using the JBoss JMX deployer which requires the deployable to be deployed to be present on the server filesystem.
      • The location used by our JMX deployer currently uses the same path on the local filesystem and on the server one. This is a bad limitation (I'm surprised nobody raised this before). I'd suggest you create a JIRA issue for this.

      The current solution I can think of would be to create a JBossDeployable class that extends Deployable and adds a setRemoteFile(String) method. For a m2 user this would mean configuring it like this:

      <deployable>
      [...]
      <properties>
      <remoteFile>...</remoteFile>
      </properties>
      </deployable>

      However we really need to find a way to deploy a local file to a remote JBoss server. This would remove the need for this JBossDeployable class and would be much easier.

      Thanks

      -Vincent
      "

      I also think there should be an improvement to this plugin to allow remote deployments from local PCs.

      1. CARGO-416.patch
        28 kB
        Adrian Cole
      2. CARGO-416-V102-CORE.patch
        31 kB
        cedric ghanassia
      3. CARGO-416-V102-CORE.patch
        21 kB
        cedric ghanassia
      4. CARGO-416-V102-EXTENSION.patch
        0.9 kB
        cedric ghanassia
      5. jboss-remote-deploy.patch
        20 kB
        Thor Åge Eldby
      6. JettyHTTPFileServerTest.java
        0.7 kB
        Nicolas Jouanin

        Activity

        Hide
        Anders Hammar added a comment -

        After a moment of thinking, I figure there's another option instead of dynamically adding this artifact in the plugin. That would be to leave it to the user to specify this dependency in the cargo plugin configuration.

        The benefit of this would be if some other artifact, than the one we think, should be used. Mainly this would be the case if using JBoss EAP (JBoss licensed/supported version of the container). There will be a different, EAP-specific, repository with the correct artifact available soon. As a dynamically added dependency can't be removed through configuration (I think), such thing could be a problem for those of us using the EAP.
        The configuration would be a little bit cumbersome, but maybe we could start with this approach? The code would be simpler.

        Here's an example:
        http://www.sonatype.com/people/2008/04/how-to-override-a-plugins-dependency-in-maven/

        Show
        Anders Hammar added a comment - After a moment of thinking, I figure there's another option instead of dynamically adding this artifact in the plugin. That would be to leave it to the user to specify this dependency in the cargo plugin configuration. The benefit of this would be if some other artifact, than the one we think, should be used. Mainly this would be the case if using JBoss EAP (JBoss licensed/supported version of the container). There will be a different, EAP-specific, repository with the correct artifact available soon. As a dynamically added dependency can't be removed through configuration (I think), such thing could be a problem for those of us using the EAP. The configuration would be a little bit cumbersome, but maybe we could start with this approach? The code would be simpler. Here's an example: http://www.sonatype.com/people/2008/04/how-to-override-a-plugins-dependency-in-maven/
        Hide
        Savas Ali Tokmen added a comment -

        OK, so in this case the user needs to manually specify, when using the container, a <dependencies> section under <plugin>. That's OK for me.

        Do we impose the same for Java as well?

        IMO, it's understandeable as long as it is correctly documented.

        Show
        Savas Ali Tokmen added a comment - OK, so in this case the user needs to manually specify, when using the container, a <dependencies> section under <plugin>. That's OK for me. Do we impose the same for Java as well? IMO, it's understandeable as long as it is correctly documented.
        Hide
        Savas Ali Tokmen added a comment -

        Fixed rev. 2430.

        Documentation on: http://cargo.codehaus.org/JBoss+Remote+Deployer

        Happy testing

        Show
        Savas Ali Tokmen added a comment - Fixed rev. 2430. Documentation on: http://cargo.codehaus.org/JBoss+Remote+Deployer Happy testing
        Hide
        Anders Hammar added a comment -

        Regarding dependencies section for the plugin, yes that's how you do it.

        What do you mean "for Java"? Do you mean when using the Cargo API directly?

        I have some comments for r2430 that I'll post to dev list.

        Regarding the doc: Why would one need to define a dependency to cargo-core-tools-jboss-deployer-5.1-and-onwards? As that's within cargo I'd say we should handle that. Anything outside cargo (like jboss-profilesrvice-spi) could justify a user added dependency. What do you think?

        Show
        Anders Hammar added a comment - Regarding dependencies section for the plugin, yes that's how you do it. What do you mean "for Java"? Do you mean when using the Cargo API directly? I have some comments for r2430 that I'll post to dev list. Regarding the doc: Why would one need to define a dependency to cargo-core-tools-jboss-deployer-5.1-and-onwards? As that's within cargo I'd say we should handle that. Anything outside cargo (like jboss-profilesrvice-spi) could justify a user added dependency. What do you think?
        Hide
        Savas Ali Tokmen added a comment -

        Yes, by "Java" I mean the API directly.

        One needs to define a dependency to cargo-core-tools-jboss-deployer-5.1-and-onwards because it could also define a dependency to cargo-core-tools-jboss-deployer-5.0. That's because the API is not method-compatible between JBoss 5.0 / 5.1 and later.

        If you have a better solution, feel free to commit.

        Show
        Savas Ali Tokmen added a comment - Yes, by "Java" I mean the API directly. One needs to define a dependency to cargo-core-tools-jboss-deployer-5.1-and-onwards because it could also define a dependency to cargo-core-tools-jboss-deployer-5.0. That's because the API is not method-compatible between JBoss 5.0 / 5.1 and later. If you have a better solution, feel free to commit.

          People

          • Assignee:
            Savas Ali Tokmen
            Reporter:
            Marie
          • Votes:
            14 Vote for this issue
            Watchers:
            17 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: