Reviewed patches by Antony attached to http://jira.jboss.com/jira/browse/JBASMP-2 (was: http://jira.jboss.com/jira/browse/JBBUILD-478 ) First off, new issues for JBoss AS Maven Plugins will go here: http://jira.jboss.com/jira/browse/JBASMP Similarly, the Server Manager has its own Project tracking: http://jira.jboss.com/jira/browse/JBASM General Comments There are a lot of suggestions both in the JIRA Comments and on this forum. Once these mature into valid tasks, assign a new JIRA Issue for them, otherwise they'll fall through the cracks due to the noise overload. An example is: http://jira.jboss.com/jira/browse/JBASMP-4, which I pulled from comments in JBASMP-2. Also, JIRA Comments are not the place for discussion. That's why we've got forums. :) So the flow is: Propose/discuss (Forum) > Create JIRA Issue > Assign Each issue should have its own Forum Thread to keep things organized. If need be, we'll open up a JBoss AS Maven Plugins Forum, but let's see if that'll be necessary first. Replies to JIRA Comments "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? /** | * Location of the overlay files | * | * @parameter alias='jboss.overlayLocation' default-value='${basedir}/src/main/resources' | */ | private String overlayLocation; Gradle OK, OK, cool. I get it. But priority 1 of the Roadmap (which doesn't yet exist in any written form aside from my blog, that's a big TODO) is to release the Maven Plugins with a full working set. Then enhance. :) 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. :) 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? * 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/.... 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. 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. maven-jboss-plugins-aggregator-2.patch To be continued... S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4164146#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...