[jboss-dev-forums] [Design of JBoss Build System] - 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 ;)


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4162659#4162659

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4162659