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

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

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