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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev