3:32 a.m.
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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...