5 Replies Latest reply on Jul 17, 2008 12:53 AM by alrubinger

    [jboss-as-control-plugin] Deploy/Undeploy Mojos

    alrubinger

      This is to outline a task for community contributor Tony Stubbs.

      A set of Maven Mojos called the "JBoss AS Control Plugin" is currently in its infancy and would benefit from some development and an initial release. Currently holding this up is a small wrapper to install a specified deployable unit via delegation to functions already in place in org.jboss.jbossas:jboss-server-manager.

      Relevant JIRA is:

      http://jira.jboss.com/jira/browse/JBBUILD-478

      (Aside: Paul, let's touch base about getting a new JIRA Project for AS Plugins as to not pollute JBBUILD)

      SVN Locations of affected projects are noted in the ticket; this Thread is for the discussion of issues encountered during development.

      This is a good excuse to resurrect some interest in this arena; I've gotten several private emails on this topic from the community asking for more attention here.

      S,
      ALR

        • 1. Re: [jboss-as-control-plugin] Deploy/Undeploy Mojos
          astubbs

          Good evening,

          Regarding your comments before about not using the Cargo Maven plugin - I read your elaboration of the topic on your blog. Of course, it would be great to later on send the improvements over cargo's way - but why not start off improving cargo from the beginning?

          Just to be sure - there is no existing deployment logic in the jboss-server-manager project correct? You say on the forum post "via delegation to functions already in place" in jboss server manager, but I could not find any deployment in code there. You must be referring to the empty class file WarDeployer? That is where I have put the deployment logic.

          The functionality is of course simple local deployment - are we going to address remote deployment with JMX like the cargo jboss pluin?

          It also only deploys a simple war or ear file vs an exploded war.

          Why is maven-jboss-deploy-plugin module commented out in the agregator pom?
          Did you intend for the deployment mojo's to be kept in a project of that name?
          if so - why not keep them in the control plugin? For the moment, as per your comment on the issue, they have been added to the maven-jboss-as-control-plugin module.

          Why aren't we using log4j directly instead of using the AbstractMojo#getLog() mojo logger?

          If both the start and deploy goals execution phase is 'pre-integration-test' - how can we assure that the start goal runs before deploy? Simply ordering the execution tasks so that 'start' is before 'deploy' appears to work, but it doesn't ensure the order.

          I think I may have found a potential error in the start/stop mojo with spaces in the exec command string.
          I could not get it to work, until I setup debug and saw that the following string was being used to execute
          C:\Program Files\Java\jdk1.6.0_10\bin\java -cp C:\jboss-5.0.0.CR1\bin\run.jar;C:\Program Files\Java\jdk1.6.0_10\lib\tools.jar org.jboss.Main -c true -b localhost
          The problem being that there is a space in the class path argument, and in the path to the java executable. I reckon this was preventing the command from even running - the error was i was getting was 'unable to start as - check the logs' and of course the logs were empty.
          I submitted a patch here:
          http://jira.jboss.com/jira/browse/JBBUILD-480?watch=true

          Has the artefact name of jboss-as-server-manager officially changed to jboss-server-manager as of 0.1.1 ? In order to continue with my work, I upgraded the dependencies to 0.1.1 version and changed the name to jboss-server-manager - this will have to be resolved longer term.

          The basic strategy was to ensure that the plugin is run at the right phase so that the packaged artefact is available. We grab the location and simply copy it into the hot deploy directory of the chosen server profile and jboss picks it up and deploys it. Deleting it causes jboss to undeploy it.

          What version of the JRE are we supposed to be writing to btw? I suppose it's 1.4 but I've been using 1.6. I don't think in this case it will make a difference though.

          With methods like ServerManager#startServer - why are we passing string server names instead of server instance variables? Is it because in some cases you only the name? I have used the actual server instance where I can.

          If we continue with the deployment method I used, but still want to put the deployment logic into the jboss-server-manager project, we need to introduce the commons-io dependency. This is what I have done.

          During development, debugging the mojo's in eclipse worked very well, except sometimes I would get caught with this error:
          "The PluginDescriptor for the plugin" "was not found. Should have been in realm: ClassRealm"
          It was very finicky and would sometimes disappear, but I couldn't nail down what was causing it.
          At one point, doing an eclipse clean and doing a mvn install on the projects caused it to start occurring again. At this point I still haven't gotten the goals working from inside eclipse. Note, they work fine from the cli.
          If you're interested in the problem I can post more info.

          Feature decision: should we allow the user to deploy to a server location which isn't running? Atm, the plugin will throw a build error after it deploys (should be before?), if it cannot contact the server.

          As you mentioned delegating the deployment functionality into jboss-server-manager, I have moved most of it there, and added the commons-io dependency. However, the majority of the file operations for generating a server configuration are in jboss-as-common - why is that code not in server-manager as well?

          Also, adding the commons-io to jboss-server-manager forces me to duplicate the version number from maven-jboss-as-build:
          <version.org.apache.commons_commons.io>1.3.2</version.org.apache.commons_commons.io>

          Regarding the constants,
          JbossAsBaseDelegate.JBOSS_SERVER_CONFIG_DIR_NAME
          JbossAsBaseDelegate.JBOSS_SERVER_DEPLOY_DIR_NAME
          It seems to me that it would make sense that these would be public constants that live in the server-manager project under the Server class. What are your thoughts on that? They are not specific settings to maven or the mojo's.
          I have moved them to Server for now.

          Why in ServerController#stopServer (and other places) are we using sysout instead of a proper logger?
          In order to stick with the current convention, I have also used sysout in ServerController.

          The currently deployment functionality is very minimalist but it works. Further enhancements can be made when a more substantial list of functional requirements is available.

          The next thing would be to write some unit tests for the mojo.

          Potentially, should there be some more complex deployment method that can actually discover if the AS deployed the artefact correctly? Something like making an http request to the target context path, and checking for 404? - except that that's not guaranteed of course as there's no requirement for a default page.

          All in all, the simple mechanism used turned out to be pretty straight forward. What took up most of the time was coming up to speed with JBoss AS, how it uses hot deployment, setting up mojo development environments and coming up to speed with mojo development.

          I have submitted the patches to the issue page and look forward to hearing from you.

          P.s. apologies if that was too much rant ;)

          • 2. Re: [jboss-as-control-plugin] Deploy/Undeploy Mojos
            alrubinger

             

            "astubbs" wrote:
            Regarding your comments before about not using the Cargo Maven plugin - I read your elaboration of the topic on your blog. Of course, it would be great to later on send the improvements over cargo's way - but why not start off improving cargo from the beginning?


            Remember that this whole project was conceived out of need for a Mavenized JBoss EJB3 Integration TestSuite, and it was simply easier to take the existing Ant extensions (which were taskdefs bound into jboss-test), break them out into their own component (jboss-server-manager), and then use the newly-centralized logic from both jboss-test and the new Maven plugins. The main priority was to get the EJB3 Integration Plugins working, and as an added benefit I started up the JBossAS Control Plugin set, with the intention of expanding upon these for Embedded and remote deployments in the future.

            I've got absolutely nothing against Cargo, but every small side project we undertake is a distraction from the real goal of an AS5 release. :) If you want to dedicate some time to integrating back with Cargo, by all means take the bull by the horns.

            "astubbs" wrote:
            Just to be sure - there is no existing deployment logic in the jboss-server-manager project correct? You say on the forum post "via delegation to functions already in place" in jboss server manager, but I could not find any deployment in code there. You must be referring to the empty class file WarDeployer? That is where I have put the deployment logic.


            Ah, looks like some more stuff is hanging around jboss-test that hasn't made it into jboss-server-manager. Check out repos/jbossas/projects/test/trunk/src/main/java/org/jboss/test/JBossTestServices.java#deploy. This does JMX local URL deploy only.

            "astubbs" wrote:
            The functionality is of course simple local deployment - are we going to address remote deployment with JMX like the cargo jboss pluin?


            Absolutely, I want to address this once we've exposed all the tasks presently available via Ant. For this one we'll have to discuss on "Design of POJO Server" the addition of a hook in JMX to accept a byte array (via some mechanism) for deployment.

            "astubbs" wrote:
            It also only deploys a simple war or ear file vs an exploded war.


            Might have to look at enhancements needed on the AS/JMX side to support this.

            "astubbs" wrote:
            Why is maven-jboss-deploy-plugin module commented out in the agregator pom?
            Did you intend for the deployment mojo's to be kept in a project of that name?
            if so - why not keep them in the control plugin? For the moment, as per your comment on the issue, they have been added to the maven-jboss-as-control-plugin module.


            No idea; twas months ago before we've resurrected this now. :). This brings up a good opportunity to discuss whether these should be in a separate plugin, or simply a Mojo within AS Control. At the moment I'm leaning towards a Deploy Plugin with Mojos for local, remote, exploded, etc. Your thoughts?

            "astubbs" wrote:
            Why aren't we using log4j directly instead of using the AbstractMojo#getLog() mojo logger?


            AbstractMojo already defines a logging mechanism, so why add another? This is also what's used by the Maven Plugins like Surefire, etc. Aside from accepting "CharSequence" as an argument, I don't know why this design was chosen; this question was unanswered for me on Codehaus #maven and I never pursued it.

            "astubbs" wrote:
            If both the start and deploy goals execution phase is 'pre-integration-test' - how can we assure that the start goal runs before deploy? Simply ordering the execution tasks so that 'start' is before 'deploy' appears to work, but it doesn't ensure the order.


            More generically: "How do I ensure proper order when two goals are tied to the same lifecycle phase?". The order of definition in the POM is the deciding factor here, though I've been advised to rely on this at a minimum. Had some talks today w/ Maven devs to see if placing a new "ordinal" field on the execution makes sense to play tiebreaker in these cases. Apparently the addition of new lifecycles is already on a wishlist somewhere (like MC does. :) ).

            "astubbs" wrote:
            I think I may have found a potential error in the start/stop mojo with spaces in the exec command string.
            I could not get it to work, until I setup debug and saw that the following string was being used to execute
            C:\Program Files\Java\jdk1.6.0_10\bin\java -cp C:\jboss-5.0.0.CR1\bin\run.jar;C:\Program Files\Java\jdk1.6.0_10\lib\tools.jar org.jboss.Main -c true -b localhost
            The problem being that there is a space in the class path argument, and in the path to the java executable. I reckon this was preventing the command from even running - the error was i was getting was 'unable to start as - check the logs' and of course the logs were empty.
            I submitted a patch here:
            http://jira.jboss.com/jira/browse/JBBUILD-480?watch=true


            A good catch, I haven't yet put these through the wringer on Win32.

            "astubbs" wrote:
            Has the artefact name of jboss-as-server-manager officially changed to jboss-server-manager as of 0.1.1 ? In order to continue with my work, I upgraded the dependencies to 0.1.1 version and changed the name to jboss-server-manager - this will have to be resolved longer term.


            Looks like Dimitris changed this in r72107. I assume he figured the groupId of org.jboss.jbossas was sufficient, so we'll use the new artifactId going forward. I'll yell at him later for breaking the dependencies. :)

            "astubbs" wrote:
            What version of the JRE are we supposed to be writing to btw? I suppose it's 1.4 but I've been using 1.6. I don't think in this case it will make a difference though.


            Let's say, "compile on 1.5, can run on 1.4 or 1.6". Java6 is not quite a priority yet as AS itself isn't completely compatible with that JDK yet. And as this isn't a supported product yet, Sun JDKs alone should suffice.

            "astubbs" wrote:
            With methods like ServerManager#startServer - why are we passing string server names instead of server instance variables? Is it because in some cases you only the name? I have used the actual server instance where I can.

            If we continue with the deployment method I used, but still want to put the deployment logic into the jboss-server-manager project, we need to introduce the commons-io dependency. This is what I have done.


            This is part of the legacy code I'd ported over, so I can't comment on the *why* of the design. :) From the looks of it, using String arguments allows the caller to use the same theory done via the CLI - you want to start a named instance, and the "getServer" method handles the implementation of locating the proper server object for you. And sure, I can envision cases where the caller won't have access to the underlying Server, just the name of the configuration.

            Soon as I'm done replying to this *book* of a forum post, I'll bring in your patches and we'll discuss. :)

            "astubbs" wrote:
            During development, debugging the mojo's in eclipse worked very well, except sometimes I would get caught with this error:
            "The PluginDescriptor for the plugin" "was not found. Should have been in realm: ClassRealm"
            It was very finicky and would sometimes disappear, but I couldn't nail down what was causing it.
            At one point, doing an eclipse clean and doing a mvn install on the projects caused it to start occurring again. At this point I still haven't gotten the goals working from inside eclipse. Note, they work fine from the cli.
            If you're interested in the problem I can post more info.


            I haven't come across this; perhaps related to class files falling out of sync within Eclipse during development of the Plugin itself (ie. Wouldn't be seen by users)?. Yes, hang onto this, and if we need to file a bug we'll do so in a new JIRA Project for the Plugins.

            "astubbs" wrote:
            Feature decision: should we allow the user to deploy to a server location which isn't running? Atm, the plugin will throw a build error after it deploys (should be before?), if it cannot contact the server.


            Sounds like a good feature, but would only work for hard-deploy (ie. non-JMX) on local machines (unless the remote machine had some other mechanism available through which we could copy, like SFTP).

            "astubbs" wrote:
            As you mentioned delegating the deployment functionality into jboss-server-manager, I have moved most of it there, and added the commons-io dependency. However, the majority of the file operations for generating a server configuration are in jboss-as-common - why is that code not in server-manager as well?


            Because server-manager works already with the Ant taskdefs, I wanted to minimize the impact made to this project. For enhancements and additions, we should be able to move things in there, but I'd like to avoid touching existing, working code.

            "astubbs" wrote:
            Also, adding the commons-io to jboss-server-manager forces me to duplicate the version number from maven-jboss-as-build:
            <version.org.apache.commons_commons.io>1.3.2</version.org.apache.commons_commons.io>


            Yup.

            "astubbs" wrote:
            Regarding the constants,
            JbossAsBaseDelegate.JBOSS_SERVER_CONFIG_DIR_NAME
            JbossAsBaseDelegate.JBOSS_SERVER_DEPLOY_DIR_NAME
            It seems to me that it would make sense that these would be public constants that live in the server-manager project under the Server class. What are your thoughts on that? They are not specific settings to maven or the mojo's.
            I have moved them to Server for now.


            This follows on the theme of not wanting to touch the server-manager component. The addition of these won't impact backwards-compatibility, so OK.

            "astubbs" wrote:
            Why in ServerController#stopServer (and other places) are we using sysout instead of a proper logger?
            In order to stick with the current convention, I have also used sysout in ServerController.


            Don't know, the author has since retired JBoss. :)

            "astubbs" wrote:
            The currently deployment functionality is very minimalist but it works. Further enhancements can be made when a more substantial list of functional requirements is available.


            It's time for me to fire up a Roadmap Wiki, proper JIRA project, etc.

            "astubbs" wrote:
            The next thing would be to write some unit tests for the mojo.


            Yup.

            "astubbs" wrote:
            Potentially, should there be some more complex deployment method that can actually discover if the AS deployed the artefact correctly? Something like making an http request to the target context path, and checking for 404? - except that that's not guaranteed of course as there's no requirement for a default page.


            This gets tricky; there's nothing guaranteeing that Tomcat/JBossWeb will even be deployed within AS. Also, the deployment mechanisms for AS 4 and 5 have changed. This should be one for the roadmap.

            "astubbs" wrote:
            All in all, the simple mechanism used turned out to be pretty straight forward. What took up most of the time was coming up to speed with JBoss AS, how it uses hot deployment, setting up mojo development environments and coming up to speed with mojo development.


            That was the idea. :D

            "astubbs" wrote:
            I have submitted the patches to the issue page and look forward to hearing from you.


            Will post my impressions back here.

            "astubbs" wrote:
            P.s. apologies if that was too much rant ;)


            BS. You'd do it all over again.

            S,
            ALR

            • 3. Re: [jboss-as-control-plugin] Deploy/Undeploy Mojos
              alrubinger

              Reviewed patches by Antony attached to
              http://jira.jboss.com/jira/browse/JBASMP-2
              (was: http://jira.jboss.com/jira/browse/JBBUILD-478 )

              First off, new issues for JBoss AS Maven Plugins will go here:

              http://jira.jboss.com/jira/browse/JBASMP

              Similarly, the Server Manager has its own Project tracking:

              http://jira.jboss.com/jira/browse/JBASM

              General Comments

              There are a lot of suggestions both in the JIRA Comments and on this forum. Once these mature into valid tasks, assign a new JIRA Issue for them, otherwise they'll fall through the cracks due to the noise overload. An example is: http://jira.jboss.com/jira/browse/JBASMP-4, which I pulled from comments in JBASMP-2.

              Also, JIRA Comments are not the place for discussion. That's why we've got forums. :)

              So the flow is:

              Propose/discuss (Forum) > Create JIRA Issue > Assign

              Each issue should have its own Forum Thread to keep things organized. If need be, we'll open up a JBoss AS Maven Plugins Forum, but let's see if that'll be necessary first.

              Replies to JIRA Comments

              "astubbs" wrote:
              Another proposal regarding is IMO JbossAsControlCreateConfigurationMojo should copy the configuration from resources/jbossasconf (or something of that nature) vs resources/conf as conf as ambiguous.


              This is configurable by way of the "overlayLocation" property that may be passed to the Mojo. "src/main/resources" seemed an intelligent default, no?

              /**
               * Location of the overlay files
               *
               * @parameter alias='jboss.overlayLocation' default-value='${basedir}/src/main/resources'
               */
               private String overlayLocation;


              Gradle

              OK, OK, cool. I get it. But priority 1 of the Roadmap (which doesn't yet exist in any written form aside from my blog, that's a big TODO) is to release the Maven Plugins with a full working set. Then enhance. :)

              Groovy Mojos

              See above, Gradle. I'll keep these configurations posted as patched, but each patch should try to address one issue alone; this makes reverts and tracking much easier. Already we're biting off too much in terms of scope - release early, release often. :)

              jboss-server-manager-2.patch

              I've committed the change provided to fix spaces in Win32 classpaths:

              http://jira.jboss.com/jira/browse/JBASM-2

              Regarding the WarDeployer, this isn't the mechanism I'd had in mind.

              * This class is a simple File copy utility/wrapper for Commons FileUtils. What makes this specific to WAR Deployment?
              * I'd been incorrect in mentioning "existing logic in jboss-server-manager". What I'd been thinking of is within the jboss-test project, JBossTestServices.deploy(), which invokes upon the JMX Bus to Deploy a URL. @see http://anonsvn.jboss.org/repos/jbossas/projects/test/trunk/src/main/java/org/jboss/test/JBossTestServices.java.

              So what I'd prefer to see is the Deploy Mojo to delegate to this kind of code. Because the Maven Plugins should not rely on jboss-test, we'd either have to rewrite this logic elsewhere or port it to server-manager, where both the Plugins and jboss-test could call upon it.

              maven-jboss-as-control-example alternate pom.patch

              Good use of Profiles here to make a more user-friendly POM that's adaptable to different start/stop/deploy scenarios. However, the idea behind this project is simply to be self-documenting (and a free test mechanism to make sure the plugins work). Let's discuss this one more, I'd like to be convinced further why you believe we should change the "mvn clean install does everything" approach already in place. True users are going to be adapting our Plugins into their own POMs, remember, so I want this to be KISS and low barrier to entry for new users (who may also be new to Maven).

              Perhaps instead of replacing the existing POM, we add a profile-based one as well. Users then have some boilerplate better suited to real-world usage in addition to the simple startup provided by the original POM.

              maven-jboss-plugins-aggregator-2.patch

              To be continued...

              S,
              ALR

              • 4. Re: [jboss-as-control-plugin] Deploy/Undeploy Mojos
                astubbs

                Forum reply:

                "ALRubinger" wrote:

                "astubbs" wrote:
                Why is maven-jboss-deploy-plugin module commented out in the aggregator pom?
                Did you intend for the deployment mojo's to be kept in a project of that name?
                if so - why not keep them in the control plugin? For the moment, as per your comment on the issue, they have been added to the maven-jboss-as-control-plugin module.


                No idea; twas months ago before we've resurrected this now. :). This brings up a good opportunity to discuss whether these should be in a separate plugin, or simply a Mojo within AS Control. At the moment I'm leaning towards a Deploy Plugin with Mojos for local, remote, exploded, etc. Your thoughts?

                Well I suppose it all depends how complex the deployment code is going to get. But if it will eventually support all the things' you've mentioned, and undoubtedly more, then yes I would be inclined to agree with you.
                Plus you've already created a new component for it in Jira anyway ;)

                "ALRubinger" wrote:

                "astubbs" wrote:
                Why aren't we using log4j directly instead of using the AbstractMojo#getLog() mojo logger?


                AbstractMojo already defines a logging mechanism, so why add another? This is also what's used by the Maven Plugins like Surefire, etc. Aside from accepting "CharSequence" as an argument, I don't know why this design was chosen; this question was unanswered for me on Codehaus #maven and I never pursued it.

                Sorry, that should have read why *are* (not aren't). Of course you are correct, but there are places where log4j has been used instead of AbstractMojo's.
                "ALRubinger" wrote:

                "astubbs" wrote:
                If both the start and deploy goals execution phase is 'pre-integration-test' - how can we assure that the start goal runs before deploy? Simply ordering the execution tasks so that 'start' is before 'deploy' appears to work, but it doesn't ensure the order.


                More generically: "How do I ensure proper order when two goals are tied to the same lifecycle phase?". The order of definition in the POM is the deciding factor here, though I've been advised to rely on this at a minimum. Had some talks today w/ Maven devs to see if placing a new "ordinal" field on the execution makes sense to play tiebreaker in these cases. Apparently the addition of new lifecycles is already on a wishlist somewhere (like MC does. :) ).

                cool.

                "ALRubinger" wrote:

                "astubbs" wrote:
                During development, debugging the mojo's in eclipse worked very well, except sometimes I would get caught with this error:
                "The PluginDescriptor for the plugin" "was not found. Should have been in realm: ClassRealm"
                It was very finicky and would sometimes disappear, but I couldn't nail down what was causing it.
                At one point, doing an eclipse clean and doing a mvn install on the projects caused it to start occurring again. At this point I still haven't gotten the goals working from inside eclipse. Note, they work fine from the cli.
                If you're interested in the problem I can post more info.


                I haven't come across this; perhaps related to class files falling out of sync within Eclipse during development of the Plugin itself (ie. Wouldn't be seen by users)?. Yes, hang onto this, and if we need to file a bug we'll do so in a new JIRA Project for the Plugins.

                According to the #maven guys it's a bug, and I upgraded to the development m2eclipse version and it's seems to have mostly disappeared.

                "ALRubinger" wrote:

                "astubbs" wrote:
                Feature decision: should we allow the user to deploy to a server location which isn't running? Atm, the plugin will throw a build error after it deploys (should be before?), if it cannot contact the server.


                Sounds like a good feature, but would only work for hard-deploy (ie. non-JMX) on local machines (unless the remote machine had some other mechanism available through which we could copy, like SFTP).

                Right. It was useful during the development of the hard deploy method of course, but wouldn't work otherwise. Although, come to think of it, a normal user wouldn't be deploying to jbossAS without having it running anyway - pretty useless. But none the less, some people might want it.

                I suppose this is going to depend on the mechanism for deploying in different ways. Perhaps the plugin could only allow it for hard deploys.

                "ALRubinger" wrote:

                "astubbs" wrote:
                Why in ServerController#stopServer (and other places) are we using sysout instead of a proper logger?
                In order to stick with the current convention, I have also used sysout in ServerController.


                Don't know, the author has since retired JBoss. :)

                Ah right then - this is something that I should fix.
                "ALRubinger" wrote:
                "astubbs" wrote:
                P.s. apologies if that was too much rant ;)


                BS. You'd do it all over again.

                ;)

                "ALRubinger" wrote:
                "astubbs" wrote:
                Another proposal regarding is IMO JbossAsControlCreateConfigurationMojo should copy the configuration from resources/jbossasconf (or something of that nature) vs resources/conf as conf as ambiguous.


                This is configurable by way of the "overlayLocation" property that may be passed to the Mojo. "src/main/resources" seemed an intelligent default, no?

                IMHO, no because the resources directory is meant for "Application/Library resources". So say you have a web application with a Spring configuration file or message files, you would put those in the resources directory - but of course you don't want that included in your jboss overlay, so you would put your jboss overlay somewhere else.

                I know it's configurable, but the most common use case would be having project resources and _not_ having a custom configuration overlay, thus resources should be reserved for actual application resources.

                "ALRubinger" wrote:

                Groovy Mojos

                See above, Gradle. I'll keep these configurations posted as patched, but each patch should try to address one issue alone; this makes reverts and tracking much easier. Already we're biting off too much in terms of scope - release early, release often. :)

                I know, I just wanted to include all that stuff to show you as apart of the *ahem* _review_ process.

                "ALRubinger" wrote:

                jboss-server-manager-2.patch

                I've committed the change provided to fix spaces in Win32 classpaths:

                http://jira.jboss.com/jira/browse/JBASM-2

                Regarding the WarDeployer, this isn't the mechanism I'd had in mind.

                * This class is a simple File copy utility/wrapper for Commons FileUtils. What makes this specific to WAR Deployment?

                Yes, that's why the code started off being a simple method inside the ServerController class :)

                "ALRubinger" wrote:
                * I'd been incorrect in mentioning "existing logic in jboss-server-manager". What I'd been thinking of is within the jboss-test project, JBossTestServices.deploy(), which invokes upon the JMX Bus to Deploy a URL. @see http://anonsvn.jboss.org/repos/jbossas/projects/test/trunk/src/main/java/org/jboss/test/JBossTestServices.java.

                So what I'd prefer to see is the Deploy Mojo to delegate to this kind of code. Because the Maven Plugins should not rely on jboss-test, we'd either have to rewrite this logic elsewhere or port it to server-manager, where both the Plugins and jboss-test could call upon it.

                Ah yes I see that now.

                The refactoring of that test code to the new dedicated deployer project should probably be apart of the same issue, or at least have a new issue created under the test project and linked.

                +1 porting to server-manager to start with.

                "ALRubinger" wrote:

                maven-jboss-as-control-example alternate pom.patch

                Good use of Profiles here to make a more user-friendly POM that's adaptable to different start/stop/deploy scenarios. However, the idea behind this project is simply to be self-documenting (and a free test mechanism to make sure the plugins work). Let's discuss this one more, I'd like to be convinced further why you believe we should change the "mvn clean install does everything" approach already in place. True users are going to be adapting our Plugins into their own POMs, remember, so I want this to be KISS and low barrier to entry for new users (who may also be new to Maven).

                Perhaps instead of replacing the existing POM, we add a profile-based one as well. Users then have some boilerplate better suited to real-world usage in addition to the simple startup provided by the original POM.


                For this case, I don't think we should change the current approach, I vote for reverting to the old pom, adding deploy / undeploy tasks to the plugin configuration (as is the 'full' profile now), and replace the 'deploy/undeploy' profiles with proper integration tests in the project.

                I look forward to hearing from you.

                Regards,
                Antony.

                • 5. Re: [jboss-as-control-plugin] Deploy/Undeploy Mojos
                  alrubinger

                   

                  "astubbs" wrote:
                  "ALRubinger" wrote:
                  "astubbs" wrote:
                  Why is maven-jboss-deploy-plugin module commented out in the aggregator pom?

                  At the moment I'm leaning towards a Deploy Plugin with Mojos for local, remote, exploded, etc. Your thoughts?

                  yes I would be inclined to agree with you.
                  Plus you've already created a new component for it in Jira anyway ;)


                  OK, we'll move forward then with JBASMP-7.

                  "astubbs" wrote:
                  there are places where log4j has been used instead of AbstractMojo's.


                  JBASMP-8.

                  "astubbs" wrote:
                  "astubbs" wrote:
                  Feature decision: should we allow the user to deploy to a server location which isn't running? Atm, the plugin will throw a build error after it deploys (should be before?), if it cannot contact the server.

                  I suppose this is going to depend on the mechanism for deploying in different ways. Perhaps the plugin could only allow it for hard deploys.


                  Go ahead and open a Feature Request. :)

                  "astubbs" wrote:
                  Why in ServerController#stopServer (and other places) are we using sysout instead of a proper logger?
                  "astubbs" wrote:
                  Ah right then - this is something that I should fix.


                  I'd hold off on that unless we've got good reason to need a logger. Generally, JBoss as an organization/codebase is very big, and we don't make a habit of changing code written by others without a real need. Specifically, I wonder if System.out was used because the Ant tasks that share this code work better under that setup.

                  "astubbs" wrote:
                  Another proposal regarding is IMO JbossAsControlCreateConfigurationMojo should copy the configuration from resources/jbossasconf (or something of that nature) vs resources/conf as conf as ambiguous.
                  "ALRubinger" wrote:

                  This is configurable by way of the "overlayLocation" property that may be passed to the Mojo. "src/main/resources" seemed an intelligent default, no?

                  IMHO, no because the resources directory is meant for "Application/Library resources". So say you have a web application with a Spring configuration file or message files, you would put those in the resources directory - but of course you don't want that included in your jboss overlay, so you would put your jboss overlay somewhere else.

                  I know it's configurable, but the most common use case would be having project resources and _not_ having a custom configuration overlay, thus resources should be reserved for actual application resources.


                  Right, this is a good point. So let's go with your proposal to simply change the default overlay location to "src/jbossas/resources" in keeping with something that looks and feels like a Maven convention.

                  JBASMP-9.

                  "astubbs" wrote:
                  I know, I just wanted to include all that (Groovy) stuff to show you as apart of the *ahem* _review_ process.


                  You get no points for one-upping your reviewer in terms of the latest fad technology. :)

                  "astubbs" wrote:
                  +1 porting (JMX Deployment Code) to server-manager to start with.


                  JBASM-6.

                  Also, there's no "+1" or votes at JBoss. As a matter of principle, decisions should be made based on merit (@see Wikipedia Meritocracy), and I've been chewed out in public forums for voting before. Word to the wise.

                  The flip side to this, of course, is who gets to define merit. :)

                  "astubbs" wrote:
                  For this case, I don't think we should change the current approach, I vote for reverting to the old pom, adding deploy / undeploy tasks to the plugin configuration (as is the 'full' profile now), and replace the 'deploy/undeploy' profiles with proper integration tests in the project.


                  For now, OK. Maybe we'll add a profile-driven POM as an alternative later.

                  S,
                  ALR