Yes, having an Apache Ant task for the validator would be very nice.
Tattletale have solved many of the same problems, so you may want to look at how that project have integrated Ant and Maven.
Also something we should consider is, if the time has come to put the validator into its own module. That will introduce some dependency issues, that we need to look into.
So for now, take a look at Tattletale's way of doing this - and post your ideas for the design.
I think that we should extract the validator code from deployers/ into its own module (validator/).
Then have only
The jboss-jca-validator-*.jar could then depend on jboss-jca-common-impl.jar as the annotation / metadata classes would move to the common/ module.
The validator should be refactored into org.jboss.jca.validator -- and sub-packages.
The validator/ module should of course be built before deployers/ - as the deployers would depend on it.
The validator/ module should have
- jboss-jca-validator.jar (framework)
- jboss-jca-validator-cli.jar (standalone)
- jboss-jca-validator-ant.jar (Ant task)
- jboss-jca-validator-maven.jar (Maven plugin)
Let me know what you think.
Yes, I think to extract validator code from deployer module is very good idea.
And maybe we create new tools module, include validator and codegerate that we will add later, and maybe more tools.
And in validator, we can generate framework.jar, -cli.jar, -ant.jar, -maven.jar files. For code-genarate, we can do the same.
And use properties to pass some value into ant environment like output directory and rar filename.
The output and archive name should just use the java.io.File handle -- you can see an example of that in the Tattletale Ant task too.
The other properties should have their "natural" value -- I think it would be a good idea to add "failOnWarn" and "failOnError" as boolean properties (just like Tattletale). That way the developers environment would bail if there is an error -- and they could look in the log file for a detailed description.