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

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

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