Java EE and WildFly Integration

Initial WildFly integration branch and pull request (not merged):

• https://github.com/chengfang/wildfly/tree/WFLY-508-WFLY-1680
• https://github.com/wildfly/wildfly/pull/4812

Based on feedback and reviews from the initial integration attemp, the following changes and features are needed in project JBeret:

• replace jaxb with stax parsing code and associated object model.
• replaced the use of scanotation with CDI.
• create a set of SPI to abstract out environment-dependent services (e.g., transaction, concurrency, classloader, batch configuration, etc)

Things to fix in the next integration:

• package names have changed, added or removed in JBeret, so need to update jberet package names in wildfly/build/pom.xml
• remove scanotation dependency from wildfly/pom.xml, wildfly/batch, wildfly/build, wildfly/build/src/main/resources
• transitive dependencies of jberet-core have been declared as optional in project jberet, so no need to exclude them in wildfly/pom.xml
• implement SPI (jberet-core/src/main/java/org/jberet/spi) for Java EE environment. The Java SE impls are in jberet-se/src/main/java/org/jberet/se and jberet-se/src/main/resources/META-INF/services/org.jberet.spi.BatchEnvironment

Bugs and Issues:

• Umbrella issue for batch integration: https://issues.jboss.org/browse/WFLY-508
• Track issue for running CTS batch tests: https://issues.jboss.org/browse/WFLY-1588
• CTS batch tests bugs against Oracle:
  • CTS-114 (Batch API test archives include beans.xml inferring a dependency on CDI not required by the Specification)
  • CTS-115 (Batch TCK test archives include default TCK SPI implementation preventing us to use our own)
  • CTS-116 (JDBC resource reference not declared in Batch test archives which is not portable)