[wildfly-dev] WildFly Plugin Core Project

John Mazzitelli mazz at redhat.com
Wed Jun 1 22:18:43 EDT 2016


I'm one of those in desperate need of this. :) James - if you need help, feel free to enlist me to help code this up. Shouldn't be too hard.

For the record, I would like a separate artifact built by a maven module inside wildfly-maven-plugin - all I need is some small third-party library with this functionality and that would fit the bill.

For me, I also need at least two enhancements to the org.wildfly.plugin.deployment.Deployment.Deployment API (or more technically, to its Builder which in turn passes to that object's constructor):

1) Rather than passing in a File, I would need to pass in an InputStream to Deployment() constructor
2) I would need to be able to pass in an "enabled" boolean to the Deployment constructor, and in the places where you now hardcode set the ENABLE attribute to "true", it would need to be that value passed to the constructor (thus, allowing the user to deploy something but not have them automatically enabled).

--John Mazz

----- Original Message -----
> Hello All,
> I've been asked a few times about creating a WildFly Plugin Core project with
> some of the utilities from the wildfly-maven-plugin. Since it came up twice
> today alone I'm wondering if we should have a separate wildfly-plugin-core
> project.
> 
> This would be useful if we wanted to have a Gradle or SBT plugin as well.
> Maybe it's useful for JBoss Tools too. WildFly Arquillian could use it too.
> 
> The idea would be to separate out the code that creates the deployment
> operations as well as the code that creates and launches a container process
> (maybe). Also expose of the helper stuff done to check the status of a
> sever, get all the server groups of a managed domain, etc. It would probably
> be fairly small overall. Essentially just some utilities that create some
> common operations so consumers don't need to know how the operation needs to
> be constructed.
> 
> If it sounds reasonable the next step would be to determine if it should be
> it's own project or just a maven module in the wildfly-maven-plugin. The
> only reason I'd lean towards it's own project is to keep the release stream
> separate from the wildfly-maven-plugin.
> 
> Thoughts?
> 
> --
> James R. Perkins
> JBoss by Red Hat
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


More information about the wildfly-dev mailing list