Create a scheme for delivering the "SE-configured" flavor of the RI (currently deploying the "EE-configured" variant to Maven central).

WASdev / standards.jsr352.jbatch

Home of 'jbatch', a compatible implementation of the Jakarta Batch specification (and the former Reference Implementation for the JSR 352, Batch Applications for the Java Platform specification).

Other

21 stars 18 forks source link

Create a scheme for delivering the "SE-configured" flavor of the RI (currently deploying the "EE-configured" variant to Maven central). #16

Closed scottkurz closed 9 years ago

scottkurz commented 10 years ago

Not to make too big a deal about this.. just wondering if there are any patterns out there for dealing with something like this. We have potentially two artifacts (the SE and EE), the com.ibm.jbatch.container-.jar that are 99% the same, except for the config.

I assume it would be nice to be able to download the SE variant and immediately use it in Maven without having to tweak it with the SE config (like you need to do with the EE variant published today).

scottkurz commented 10 years ago

Maybe we could ask the Glassfish integrators of batch to use Steve's new SPI method registerBatchContainerOverrideProperties() to configure jbatch in Glassfish, so the properties files could be used exclusively to set up the SE config, and in Glassfish the equivalent config could be done by a separate module.

scottkurz commented 9 years ago

Resolved with commit 329a56d.
This continues to allow the existing properties files to be used to configure jbatch by overriding the hard-coded defaults. Then the new SPI registerBatchContainerOverrideProperties() will override again. Then finally a set of System properties will override again.