As promised during the hangout, here is a summary of the situation.
A number of JIRAs were added to create quickstarts using DeltaSpike
features. In a couple of cases, existing quickstarts were modified
rather than creating new quickstarts, resulting in a change in
target from EAP to WFK.
These are a problem because an existing quickstart was modified,
resulting in a change in target product.
- JDF-144: Create a quick start using the deltaspike property
configuration; Pull request sent for modified helloworld-jms
quickstart, changing the target product to WFK.
- JDF-159: Demonstrate usage of Deactivateable from Deltaspike
updating relevant Quickstarts that uses Extension. Pull request
was sent that modifies the cdi-portable-extension quickstart.
These JIRAs are not a problem because new quickstarts were
created.
- JDF-145: Create a quickstart using deltaspike's exception
handling; Pull request sent for new
deltaspike-exception-handling-quickstart
-
JDF-149: Add a quickstart that shows how to use DeltaSpike
BeanManagerProvider to access CDI in a EntityListener; Pull
request sent for new deltaspike-beanmanager quickstart
-
JDF-156: Demonstrate usage of DeltaSpike project stage in a
quickstart, and shows usage of a conditional @Exclude; Pull
request sent for new deltaspike-projectstage quickstart.
This is not a problem because the change introduced JBoss Logging
and did not impact the target product.
- JDF-165: Upgrade i18n (ML) Quickstarts to use JBoss Logging.
Pull request sent, but this doesn't impact the target product.
These JIRAs are not yet done. We need new quickstarts are created
for them:
- JDF-158: Add custom authorization example using
@SecurityBindingType from DeltaSpike
- JDF-165: Upgrade i18n (ML) Quickstarts to use JBoss Logging.
Pull request sent, but this doesn't impact the target product.
- JDF-146: Add Deltaspike version of kitchensink that shows how
to use @Transactional
-
JDF-148: Add a quickstart showing how to create new beans using
DeltaSpike utilities