10:34 a.m.
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
9:11 a.m.
On 12 Dec 2012, at 17:34, Sande Gilda wrote:
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.
Hmm, tricky one. DeltaSpike property config is something Java EE is missing, and the QS
did manually before.
• 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.
This is probably ok IMO. DeltaSpike is about creating portable extensions, we do recommend
it's usage for any portable extension.
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
This is delayed anyway.
• 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
This is fine.
• JDF-148: Add a quickstart showing how to create new beans using
DeltaSpike utilities
This is fine.
12:37 p.m.
On 12/13/2012 10:11 AM, Pete Muir wrote:
On 12 Dec 2012, at 17:34, Sande Gilda wrote:
> 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.
Hmm, tricky one. DeltaSpike property config is something Java EE is missing, and the QS
did manually before.
I already copied this modified version, renamed it to
deltaspike-helloworld-jms, and issued a pull,
https://github.com/jboss-jdf/jboss-as-quickstart/pull/377
> • 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.
This is probably ok IMO. DeltaSpike is about creating portable extensions, we do
recommend it's usage for any portable extension.
So you are saying we don't
want or need to ship a cdi-portable-extension
quickstart with EAP 6.x, correct?
> 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
This is delayed anyway.
> • 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
This is fine.
> • JDF-148: Add a quickstart showing how to create new beans using DeltaSpike
utilities
This is fine.
2:31 p.m.
Em 13-12-2012 16:37, Sande Gilda escreveu:
On 12/13/2012 10:11 AM, Pete Muir wrote:
> On 12 Dec 2012, at 17:34, Sande Gilda wrote:
>
>> 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.
> Hmm, tricky one. DeltaSpike property config is something Java EE is missing, and the
QS did manually before.
>
I already copied this modified version, renamed it to
deltaspike-helloworld-jms, and issued a pull,
https://github.com/jboss-jdf/jboss-as-quickstart/pull/377
I checked that Pull
Request and it's ready, but since the original code
was produced by me, I think that other than me should
review/handle/merge this pull request.
<https://github.com/jboss-jdf/jboss-as-quickstart/pull/377>
>> . 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.
> This is probably ok IMO. DeltaSpike is about creating portable extensions, we do
recommend it's usage for any portable extension.
So you are saying we don't want or need to ship a
cdi-portable-extension quickstart with EAP 6.x, correct?
Based on Jason comments
https://issues.jboss.org/browse/JDF-159?focusedCommentId=12740757&pag...
<https://issues.jboss.org/browse/JDF-159?focusedCommentId=12740757&pag...
and on Docs
https://cwiki.apache.org/confluence/display/DeltaSpike/Temporary+Document...
' This helper is*not*intended to be used by users. DeltaSpike (and CDI
extensions can) use/s it to check if a given class is activated."
I think that the pull request that modifies cdi-portable-extension and
cdi-veto should be discarded and maybe I'm wrong or don't having the
complete vision, but I don't think we need a quickstart that shows only
how to disable (deactivate) an existing extension.
>> 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
> This is delayed anyway.
JDF-145, JDF-149, JDF-156 and JDF-165 are ready for
review.
JDF-158 - I'm working on it at the moment
>
>> . 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
> This is fine.
>
>> . JDF-148: Add a quickstart showing how to create new beans using DeltaSpike
utilities
> This is fine.
Pete, since you added "cdi-add-interceptor-binding" quickstart, I'm
wondering if we really need a quickstart that shows BeanBuilder to quit
JDF-148? It is being hard to find a good use case to add to your
existing quickstart or even a good one that justifies having another
quickstart.
_______________________________________________
jdf-dev mailing list
jdf-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jdf-dev
9:17 a.m.
On 13 Dec 2012, at 20:31, Rafael Benevides wrote:
>>>
>>> • 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
>>>
>> This is fine.
>>
>>
>>> • JDF-148: Add a quickstart showing how to create new beans using DeltaSpike
utilities
>>>
>> This is fine.
>
Pete, since you added "cdi-add-interceptor-binding" quickstart, I'm
wondering if we really need a quickstart that shows BeanBuilder to quit JDF-148? It is
being hard to find a good use case to add to your existing quickstart or even a good one
that justifies having another quickstart.
Yes, we definitely need it.
There are some good use cases, for example you can scan injection points, and based on
what you find, create a bean to satisfy an injection point.
Here is a good example,
https://github.com/droolsjbpm/drools/blob/master/drools-compiler/src/main...
of this use case, but needs to be a lot simpler for our example.
7:31 a.m.
On 13 Dec 2012, at 18:37, Sande Gilda wrote:
On 12/13/2012 10:11 AM, Pete Muir wrote:
> On 12 Dec 2012, at 17:34, Sande Gilda wrote:
>
>
>> 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.
>>
> Hmm, tricky one. DeltaSpike property config is something Java EE is missing, and the
QS did manually before.
>
>
I already copied this modified version, renamed it to deltaspike-helloworld-jms, and
issued a pull, https://github.com/jboss-jdf/jboss-as-quickstart/pull/377
>>
>> • 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.
>>
> This is probably ok IMO. DeltaSpike is about creating portable extensions, we do
recommend it's usage for any portable extension.
So you are saying we don't want or need to ship a cdi-portable-extension quickstart
with EAP 6.x, correct?
I am.
>
>> 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
>>
> This is delayed anyway.
>
>
>> • 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
>>
> This is fine.
>
>
>> • JDF-148: Add a quickstart showing how to create new beans using DeltaSpike
utilities
>>
> This is fine.
4203
days inactive
4205
days old
5 comments
3 participants
participants (3)
-
Pete Muir -
Rafael Benevides -
Sande Gilda