[Design of JBoss Build System] - Re: [jboss-as-control-plugin] Deploy/Undeploy Mojos
by 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
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4162881#4162881
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4162881
17 years, 9 months