hi @ all,
i created [1] for collecting the suggestions.
if you don't like one of the mentioned conventions, add your own suggestion.
i'll start a vote about it on monday.
regards,
gerhard
[1] https://issues.apache.org/jira/browse/DELTASPIKE-12
2011/12/12 Jason Porter lightguard...@gmail.com
- Original Message -
From: Gerhard Petracek gerhard.petra...@gmail.com
To: deltaspike-dev@incubator.apache.org
Cc:
Sent: Wednesday, December 14, 2011 8:28 PM
Subject: [DISCUSS] [DELTASPIKE-3] BeanManagerProvider
hi @ all,
fyi: please check [1
hi mark,
that's very similar to the idea implemented by manila :)
regards,
gerhard
2011/12/17 Jason Porter lightguard...@gmail.com
I like the idea, however, that would be a very core change to both core
arquillian and the containers. I don't think we'll get that anytime soon.
Maybe a
hi @ all,
fyi: please check [1] before you answer.
[2] provides a short introduction as well as the basic usage.
[3] provides a short overview about implementing and using a custom
(type-safe) project-stage
the basic concept:
the basic idea is to provide type-safe but extensible project-stages.
+1
(we could think about a different name)
regards,
gerhard
2011/12/19 Gerhard Petracek gerhard.petra...@gmail.com
hi @ all,
fyi: please check [1] before you answer.
[2] provides a short introduction as well as the basic usage.
the basic concept:
via the annotation
+0.5 e.g. for the name @ActivatedOnProjectStage, if we can also agree on
@ActivatedOnExpression for [1].
regards,
gerhard
[1] http://s.apache.org/MeX
2011/12/19 Gerhard Petracek gerhard.petra...@gmail.com
+1
(we could think about a different name)
regards,
gerhard
2011/12/19 Gerhard
hi @ all,
feel free to add your suggestions to [1].
regards,
gerhard
[1]
https://cwiki.apache.org/confluence/display/DeltaSpike/Suggested+Git+Workflows
hi antoine,
imo we need at least a short but correct description as well as a clear
vision (e.g. at least one real-world use-case which shows that there is a
real benefit for users).
@seam-social:
it's nice that you could use it there, but currently i can't see the need
to use it (compared to
i agree with mark.
regards,
gerhard
2011/12/21 Mark Struberg strub...@yahoo.de
As I see it we have 3 different options:
1.) .api.* + .impl.* because it's more easy to 'grab' any api package in
e.g. an Arquillian test. If we don't have the modulename.api package name,
then we cannot do
On 2011-12-19, at 2:49 PM, Gerhard Petracek wrote:
hi @ all,
fyi: please check [1] before you answer.
[2] provides a short introduction as well as the basic usage.
the basic concept:
pre-configured cdi artifacts (like implementations of
javax.enterprise.inject.spi.Extension
hi @ all,
fyi: please check [1] before you answer.
[2] is the implementation used in owb. i suggest to start with it (instead
of the version of codi), because the version of codi provides additional
mechanisms we might need later on (if we include the corresponding
features).
the basic concept:
+1
regards,
gerhard
2011/12/21 Gerhard Petracek gerhard.petra...@gmail.com
hi @ all,
fyi: please check [1] before you answer.
[2] shows how to provide custom config-values in a type-safe manner.
the basic concept:
CodiConfig itself is just a marker interface to find all config classes
+1
regards,
gerhard
2011/12/21 Gerhard Petracek gerhard.petra...@gmail.com
hi @ all,
fyi: please check [1] before you answer.
[2] is the implementation used in owb. i suggest to start with it (instead
of the version of codi), because the version of codi provides additional
mechanisms
hi @ all,
fyi: please check [1] before you answer.
the basic concept:
in myfaces codi all names for named beans (@Named of cdi) are placed as
variables in an interface (one per module). to find such interfaces easily
they implement a marker interface called BeanNames (see e.g. [2])
please send
+1
regards,
gerhard
2011/12/21 Gerhard Petracek gerhard.petra...@gmail.com
hi @ all,
fyi: please check [1] before you answer.
the basic concept:
in myfaces codi all names for named beans (@Named of cdi) are placed as
variables in an interface (one per module). to find such interfaces
hi @ all,
fyi: please check [1] before you answer.
the basic concept:
during the startup of an application myfaces codi writes information about
the current environment to the log.
(e.g. the values configured via [2] and the detected version and
implementation of cdi and other modules do the
+1
regards,
gerhard
2011/12/21 Gerhard Petracek gerhard.petra...@gmail.com
hi @ all,
fyi: please check [1] before you answer.
the basic concept:
during the startup of an application myfaces codi writes information about
the current environment to the log.
(e.g. the values configured
an easy topic.
regards,
gerhard
2011/12/22 Mark Struberg strub...@yahoo.de
-0.8 I just don't see the benefit. Never used that in Codi.
LieGrue,
strub
- Original Message -
From: Gerhard Petracek gerhard.petra...@gmail.com
To: deltaspike-dev@incubator.apache.org
Cc:
Sent
...@gmail.com
Gerhard,
I am
John Ament (Independent contributor)
- John
On Thu, Dec 22, 2011 at 11:23 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi john,
you are still listed as initial committer (- ppmc member) at [1].
regards,
gerhard
[1] http://wiki.apache.org
SPI classes which are to be
implemented/overwritten in a customer project to configure the provided
functionality.
LieGrue,
strub
- Original Message -
From: Gerhard Petracek gerhard.petra...@gmail.com
To: deltaspike-dev@incubator.apache.org
Cc:
Sent
i would suggest that we start with an approach which is available right
now and to refactor the tests later on (as soon as the mentioned approach
is available in arquillian).
@dan:
yes - the basic idea is very similar to manila.
+1 for adding the basic approach to arquillian itself and using it.
+0.5 for @Skip
as mentioned in the original thread @Veto is accurate from a technical
perspective, but it sounds strange for users who aren't aware of the
mechanism behind.
if we are talking only about @Veto vs @Skip and not about the other
alternatives: +1 for @Skip
regards,
gerhard
hi arne,
would be also ok for me - +1
regards,
gerhard
2011/12/23 Arne Limburg arne.limb...@openknowledge.de
What about @Exclude?
Cheers,
Arne
-Ursprüngliche Nachricht-
Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
Gesendet: Freitag, 23. Dezember 2011 21:28
and provide that on github.
then we play around with it and if it turns out to be good, then we can
just push this branch to ds.asf:master
wdyt?
LieGrue,
strub
- Original Message -
From: Gerhard Petracek gerhard.petra...@gmail.com
To: deltaspike-dev@incubator.apache.org
Cc:
Sent
+1
regards,
gerhard
2011/12/25 Mark Struberg strub...@yahoo.de
+1 for org.apache.deltaspike.core.test
+1 for test structure.
LieGrue,
strub
- Original Message -
From: Jason Porter lightguard...@gmail.com
To: deltaspike-dev@incubator.apache.org
Cc:
Sent: Sunday,
/incubator/DeltaSpikeProposal#line-175
2011/12/24 John D. Ament john.d.am...@gmail.com
+1
How about SpikeConfig?
On Fri, Dec 23, 2011 at 3:27 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
+1 for a new name.
(initially it was a bit more. we reduced the functionality later
these are the names that were suggested:
@Veto
@Skip
@Exclude
@Deactivate
@Ignore
2011/12/23 Gerhard Petracek gerhard.petra...@gmail.com:
hi arne,
would be also ok for me - +1
regards,
gerhard
2011/12/23 Arne Limburg arne.limb...@openknowledge.de
What about @Exclude
to
ProcessAnnotatedType.veto(), which is precisely what happens to such
annotated types. I have mixed feelings about @Exclude - I'd rather not
introduce a new term, especially one that does not immediately make you
think of CDI processing.
On 2011-12-26, at 6:41 PM, Gerhard Petracek wrote:
it looks like
represents the default
implementation of the bean, correct? so an app developer can create a
manual producer... right?
On Tue, Dec 27, 2011 at 7:24 PM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
+1 for @Unmanaged
(+1 for @Exclude if it's the only alternative we can agree on)
regards
hi @ all,
mark added some additional suggestions to the wiki [1].
besides that we have to discuss further topics like:
- file encoding
- line-endings
- usage of special characters
regards,
gerhard
[1]
https://cwiki.apache.org/confluence/display/DeltaSpike/Suggested+Git+Workflows
the easiest way in this case is a formal vote about @Veto vs @Exclude vs
@Unmanaged/@NotManaged
regards,
gerhard
2011/12/30 Dan Allen dan.j.al...@gmail.com
On Wed, Dec 28, 2011 at 11:55, Marius Bogoevici
marius.bogoev...@gmail.comwrote:
I suggested @Unmanaged (or even @NotManaged, or
ok - thx jakob.
regards,
gerhard
2011/12/30 Jakob Korherr jakob.korh...@gmail.com
Hi,
I just created http://incubator.apache.org/projects/deltaspike.html,
following the instructions at [1]. It should be available soon (after
the sync is finished).
I added all the basic information
outcome.
Sent from my iPhone
On Jan 1, 2012, at 18:08, Gerhard Petracek gerhard.petra...@gmail.com
wrote:
hi mark,
you are right - however, that's also only a basic agreement
(see NarrowingBeanBuilder and AnnotatedTypeBuilder)
regards,
gerhard
2012/1/2 Mark Struberg strub
the name, I think anything -ed makes sense for CDI integration,
so
+1 for ProjectStageActivated
On Sun, Jan 1, 2012 at 7:55 PM, Gerhard Petracek
gerhard.petra...@gmail.com
wrote:
hi,
christian sent his opinion about the name.
@others:
please also send your
Porter lightguard...@gmail.com
wrote:
+1 for @ActivatedOnExpression. It reads better which goes a long
way
for
easy to use, self documenting code.
Sent from my iPhone
On Jan 1, 2012, at 17:57, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi,
please send your
hi @ all,
we came up with a new idea to merge @Veto, @ProjectStageActivated and
@ExpressionActivated.
arne combined [1] some of the previous suggestions and the result would
solve the @Veto naming discussion as well.
if we merge those features, we would get something like:
@Exclude
as discussed with mark we could think about details like inProjectStage vs
ifProjectStage, however, basically +1
regards,
gerhard
2012/1/3 Gerhard Petracek gerhard.petra...@gmail.com
hi @ all,
we came up with a new idea to merge @Veto, @ProjectStageActivated and
@ExpressionActivated
forward merges when
you commit your branch back to master. As long as your rebase your branch
onto the latest from master before your merge you'll be fine.
On Tue, Jan 3, 2012 at 16:58, Gerhard Petracek
gerhard.petra...@gmail.comwrote:
the idea/s of this proposal:
the commit history should
hi @ all,
we should also add ppmc members to the page.
regards,
gerhard
2011/12/30 Gerhard Petracek gerhard.petra...@gmail.com
ok - thx jakob.
regards,
gerhard
2011/12/30 Jakob Korherr jakob.korh...@gmail.com
Hi,
I just created http://incubator.apache.org/projects
hi lincoln,
yes - we will need it. that's usually part of the invitation mail.
however, since you are aware of this vote (that isn't the case usually),
you can send it at any time.
regards,
gerhard
2012/1/8 Lincoln Baxter, III lincolnbax...@gmail.com
Thanks guys. Do you need an apache ID or
short addition:
this thread isn't a vote - it's just a discussion, but the rest doesn't
change.
regards,
gerhard
2012/1/8 Gerhard Petracek gerhard.petra...@gmail.com
hi lincoln,
yes - we will need it. that's usually part of the invitation mail.
however, since you are aware of this vote
Message -
From: Gerhard Petracek gerhard.petra...@gmail.com
To: deltaspike-dev@incubator.apache.org
Cc:
Sent: Saturday, January 7, 2012 9:55 PM
Subject: Re: Please review DELTASPIKE-45
hi jason,
the only alternative which comes to my mind right now is to move the impl
classes
hi @ all,
plans changed and our great infra team created the official mirror [1]
sooner.
(fyi: it will be migrated to the new approach as soon as it is available.)
regards,
gerhard
[1] https://github.com/apache/incubator-deltaspike
2012/1/12 Gerhard Petracek gerhard.petra...@gmail.com
hi
welcome!
regards,
gerhard
2012/1/13 Mark Struberg strub...@yahoo.de
Hi!
The DeltaSpike team is happy to welcome Dan Allen and Lincoln Baxter III
as new committers to our project.
Welcome folks, and we hope you enjoy being part of this community!
the Apache DeltaSpike PPMC
hi @ all,
we resolved over 30 jira-tickets and we finished (agreement +
import/implementation) ~10 mechanisms/features.
imo:
we should release early and often + it would be nice to start with the
first steps for a release and start with the release of v0.1 in about 1-2
weeks.
(the first release
here we really just talk about the better default (which can be changed
easily - in both cases).
the following part is just important for projects which use both - jndi and
system properties for the same low-level config-entry (e.g. the
project-stage)
from the perspective of our users:
the
hi @ all,
as we have seen the suggestion of christian works pretty well and at least
for contributions via patches, we should use it imo (it's better than the
typical thx to [name of contributor] in the commit message).
@christian:
if there are no objections, it would be nice if you add it to
hi matt,
imo we have to care about it in case of other external contributions we are
going to get quite soon.
however, in case of seam3 i don't see any issue at all.
#1 redhat has a ccla on file
#2 they contacted us [1] to join forces (and they found out that the asf is
also a great place for
hi @ all,
today i reviewed it. my findings:
#1:
imo we shouldn't have public impl classes in the api module if we can
avoid it. i made a small refactoring to reduce the visibility of those
classes and i attached a patch which shows the suggestion at [1].
#2:
i had a short talk with pete about
/17 Gerhard Petracek gerhard.petra...@gmail.com:
hi @ all,
as we have seen the suggestion of christian works pretty well and at
least
for contributions via patches, we should use it imo (it's better than the
typical thx to [name of contributor] in the commit message).
@christian
hi @ all,
while reviewing DELTASPIKE-45 i saw that some literal implementations for
std. cdi annotations got into deltaspike as well.
in myfaces codi we also have some literal implementations. esp. for
DELTASPIKE-45 they make a lot of sense imo.
- i created DELTASPIKE-53 and since there is just
hi @ all,
like DELTASPIKE-53 this ticket is also related to DELTASPIKE-45. for users
it might be useful to use: SimpleLiteral.of(MySimpleAnnotation.class) in
combination with the builder methods instead of implementing literals
manually (just for using them with the default values).
at [1] you
want to add the XML stuff
soon I think?
On 18 Jan 2012, at 17:27, Gerhard Petracek wrote:
no - it's just that simple. ok - i'll edit the issue to review and
discuss AnnotationInstanceProvider.
thx regards,
gerhard
2012/1/18 Pete Muir pm...@redhat.com
+1. Solder offers
as mentioned by pete (earlier), the additional features (DELTASPIKE-54 vs
DELTASPIKE-55) aren't type-safe.
- +0.5 afaik we will need it for further features which need such a
generic approach (no +1 because we haven't discussed them so far)
regards,
gerhard
2012/1/18 Jason Porter
hi rudy,
nice - thx for the info!
regards,
gerhard
2012/1/19 Rudy De Busscher rdebussc...@gmail.com
Hi All,
I started with a prototype for the Jboss forge plugin for DeltaSpike. (1)
For the moment, it just adds the dependencies to the POM. More
functionality follows in the next
...@redhat.com wrote:
+1
On 18 Jan 2012, at 16:47, Gerhard Petracek wrote:
hi @ all,
while reviewing DELTASPIKE-45 i saw that some literal implementations for
std. cdi annotations got into deltaspike as well.
in myfaces codi we also have some literal implementations. esp. for
DELTASPIKE-45
hi mark,
thx for starting the release-review as well.
@a)
imo that doesn't make sense at all. this mechanism is only for users and
add-ons and won't be used by deltaspike itself.
if something gets deactivated by one of both, it doesn't make sense to
re-activate it again because that would cause
i know why you did it in this case - but in general: -1 for committing such
large changes in case of an ongoing discussion.
some hours ago i added a suggestion to [1] exactly for such cases.
regards,
gerhard
[1] http://s.apache.org/oo
2012/1/22 strub...@apache.org
Updated Branches:
we can do
this even better.
LieGrue,
strub
- Original Message -
From: Gerhard Petracek gerhard.petra...@gmail.com
To: deltaspike-dev@incubator.apache.org
Cc:
Sent: Sunday, January 22, 2012 3:23 PM
Subject: Re: git commit: DELTASPIKE-24 rework Deactivation logic
i know
. Nontheless, it was easy to add and doesn't harm to have
it.
Re the spi stuff. Means we gonna move only the ClassDeactivation to the
spi package?
LieGrue,
strub
- Original Message -
From: Gerhard Petracek gerhard.petra...@gmail.com
To: deltaspike-dev@incubator.apache.org
Cc
+1
imo we should add the corresponding hints to the wiki. e.g. everything
v0.9.x might change fundamentally, if we find a better approach (e.g. based
on feedback provided by the community).
(+ we agreed on release early and often already. some parts which need
further discussions are known
.
LieGrue,
strub
- Original Message -
From: Gerhard Petracek gerhard.petra...@gmail.com
To: deltaspike-dev@incubator.apache.org
Cc:
Sent: Monday, January 23, 2012 7:56 AM
Subject: Re: [DISCUSS] BeanManagerProvider API
hi christian,
thx for moving this discussion
@IllegalStateException:
+1 (that's what we have already).
@christian:
i agree and therefore we have the jndi lookup in place.
we have never seen a npe caused by #getBeanManager, however, it also
doesn't harm to check it.
regards,
gerhard
2012/1/23 Arne Limburg arne.limb...@openknowledge.de
hi rudy,
i've added some ideas to [1].
regards,
gerhard
[1] https://cwiki.apache.org/confluence/display/DeltaSpike/Forge+Plugin
2012/1/19 Gerhard Petracek gerhard.petra...@gmail.com
hi rudy,
nice - thx for the info!
regards,
gerhard
2012/1/19 Rudy De Busscher rdebussc
code has to check explicitly. If it doesn't, the code will
probably fail we NPEs.
So my suggestion is to change #getBeanManager() to never return null
and instead throw a meaningful runtime exception just like
#getInstance() does it already.
Christian
2012/1/23 Gerhard Petracek
)
+1
On Tue, Jan 24, 2012 at 12:53, Gerhard Petracek
gerhard.petra...@gmail.comwrote:
hi,
in this case we would have to move all util classes and helpers.
maybe we should create an own package for such classes (e.g. util) -
we
would have
- api
- spi
- util
hi jason,
i just checked the original source-code in myfaces codi and there 'null' is
part of the contract of the method.
however, you are right - here it doesn't make sense since we are using it
differently.
regards,
gerhard
2012/1/25 Jason Porter lightguard...@gmail.com
As soon as I
+1!
regards,
gerhard
2012/1/25 Mark Struberg strub...@yahoo.de
-1 to i18n and typesafe logging for version one.
Lincoln, why you hatin' on type-safe logging? Brother, hook me up with a
+1
:)
-Dan
Hehe, that's the nice thing here at Apache.
Since we only discuss those
hi rudy,
it's the opposite - thx a lot for writing such things.
@all: please run the build before you push your commits.
regards,
gerhard
2012/1/25 Rudy De Busscher rdebussc...@gmail.com
fyi,
The CI build failed with this checkstyle error:
file
+1
regards,
gerhard
2012/1/25 Jason Porter lightguard...@gmail.com
+1 to Mark's idea of throwing a runtime exception instead of returning
null.
Sent from my iPhone
On Jan 25, 2012, at 1:18, Gerhard Petracek gerhard.petra...@gmail.com
wrote:
hi jason,
i just checked the original
welcome adam!
a nice starting point is [1] (and all resources linked there).
if you miss an information, you are very welcome to ask. we just started
with the wiki and we will improve it step by step.
as soon as you have your cla on file, we will talk about the next steps
concerning source-code
2011/12/23 Christian Kaltepoth christ...@kaltepoth.de
+1
2011/12/23 Gerhard Petracek gerhard.petra...@gmail.com:
+1 if we keep the impl in impl-bda [1]
regards,
gerhard
[1]
https://cwiki.apache.org/confluence/display/DeltaSpike/Project+Structure
2011/12/23 Jason Porter
welcome thomas!
a nice starting point is [1] (and all resources linked there).
if you miss an information, you are very welcome to ask. we just started
with the wiki and we will improve it step by step.
as soon as you have your cla on file, we will talk about the next steps
concerning source-code
, Gerhard Petracek (Created) (JIRA) wrote:
global alternatives
---
Key: DELTASPIKE-61
URL: https://issues.apache.org/jira/browse/DELTASPIKE-61
Project: DeltaSpike
Issue Type: New Feature
Components: Core
it well as is
different than what's supplied via vanilla CDI. I'm fine going ahead and
trying it out though.
On Wed, Jan 25, 2012 at 14:40, Gerhard Petracek
gerhard.petra...@gmail.comwrote:
in myfaces codi we had different approaches for it. the problem was that
sometimes
it (of course that may be because I'm tired right now), but it looks
good.
On Thu, Jan 26, 2012 at 17:56, Gerhard Petracek
gerhard.petra...@gmail.comwrote:
hi @ all,
i implemented the qualifier logic and pushed the current version to [1].
(i
tested it with different servers.)
(i also did
The DeltaSpike PPMC is proud to announce a new addition to our community.
Please welcome Christian Kaltepoth as the newest DeltaSpike committer!
@Christian: Please add yourself to the Parent-POM [1].
Welcome regards,
Gerhard
[1] http://s.apache.org/deltaspike_parent-pom
the API developed by OWASP[2] team, based on the
lines and concerns gathered by that open security group.
[1] http://code.google.com/p/owasp-esapi-java/
[2] https://www.owasp.org/index.php/Main_Page
On Mon, Jan 30, 2012 at 8:57 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi
security frameworks like shiro (or
at least we shouldn't block the possibility to implement such custom
adapters easily).
regards,
gerhard
2012/1/30 Shane Bryzak sbry...@redhat.com
On 30/01/12 18:57, Gerhard Petracek wrote:
hi @ all,
as discussed at [1] the current suggestion is to start
hi dan,
thx! if you think about a) or b) mentioned by christian we should discuss
it before you spend a lot of time on it. (because there are/were good
reasons for not doing that.)
@all:
the only issues i saw (as well):
- right now moving resources is broken. e.g.
.
regards,
gerhard
2012/1/30 Gerhard Petracek gerhard.petra...@gmail.com
hi dan,
thx! if you think about a) or b) mentioned by christian we should discuss
it before you spend a lot of time on it. (because there are/were good
reasons for not doing that.)
@all:
the only issues i saw
of?
On 30 Jan 2012, at 12:45, Gerhard Petracek wrote:
hi shane,
that's a noble goal. however, i know a lot of users who
will never
use
our security implementation - only the api/spi to
integrate
with
the
other modules of deltaspike (that's independent
hi @ all,
imo this feature of myfaces codi-core is a nice starting point for the
security-api discussion, because the basic idea behind it is a very thin
integration layer (which can be used by other modules).
the basic concept:
a cdi interceptor invokes (inline) voters to secure the target
D. Ament john.d.am...@gmail.com
Is it up to the developer to define the bean that implements an interface?
On Tue, Jan 31, 2012 at 6:59 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
hi @ all,
imo this feature of myfaces codi-core is a nice starting point for the
security-api
,
Arne
-Ursprüngliche Nachricht-
Von: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
Gesendet: Dienstag, 31. Januar 2012 13:14
An: deltaspike-dev@incubator.apache.org
Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
that's one option. a 2nd option is to use
, but discussing security
mechanisms without discussing the stuff which needs to get secured is only
half of the truth ;)
LieGrue,
strub
[1]
https://cwiki.apache.org/EXTCDI/jsf-usage.html#JSFUsage-TypesafeViewConfig
- Original Message -
From: Gerhard Petracek gerhard.petra...@gmail.com
Shane Bryzak sbry...@redhat.com
On 01/02/12 00:21, Gerhard Petracek wrote:
hi mark,
thx for the heads-up. i just talked with shane about all those details.
i don't see an issue with view-configs. codi just extracts the @Secured
annotation during the bootstrapping process in case of view-configs
time for us to kick the tires on @Exclude.
On Tue, Jan 31, 2012 at 07:30, Gerhard Petracek
gerhard.petra...@gmail.comwrote:
hi rudy,
thx! imo it's the right time to restart this discussion.
mark prefers to use @Typed() for custom project-stages (@mark please
correct me if i mix
care which way we
go.
On Tue, Jan 31, 2012 at 07:57, Gerhard Petracek
gerhard.petra...@gmail.comwrote:
hi shane,
that's one of the reasons why i won't block it right now.
if the majority prefers custom annotations, we should just introduce
it
after v0.1 and prototype
. This eliminates a
possible pitfall for users if they forget the @Typed annotation.
Christian
2012/2/1 Peter Muir pm...@redhat.com:
+1 to gerhards approach.
--
Pete Muir
http://in.relation.to/Bloggers/Pete
On 31 Jan 2012, at 14:30, Gerhard Petracek gerhard.petra...@gmail.com
: Gerhard Petracek [mailto:gerhard.petra...@gmail.com]
Gesendet: Mittwoch, 1. Februar 2012 08:54
An: deltaspike-dev@incubator.apache.org
Betreff: Re: [DISCUSS][SECURITY-API] [DELTASPIKE-64] @Secured
@christian: that's correct. but the advantage of using custom annotation
arguments can't be used
as we have the final
implementation (and therefore all the details) and we can remove the other
approach.
if we see that both make sense, we just keep them.
regards,
gerhard
2012/2/1 Gerhard Petracek gerhard.petra...@gmail.com
yes - that's possible as well.
short addition - 3b allows:
@TwoOf
hi rudy,
that's great - thx!
i created an easier url [1] for it.
regards,
gerhard
[1] http://s.apache.org/ds_it_os-servers
2012/2/1 Rudy De Busscher rdebussc...@gmail.com
Hi All,
The setup of the Jenkins server is (at last) completely done.
You can access the status page at (1)
The
hi mehdi,
yesterday we saw that also with our sonar build. jason said that they saw
it also at seam3 (it is a jdk bug and you just have to upgrade to a newer
jdk version).
imo we should also apply your fix.
thx regards,
gerhard
2012/2/1 Mehdi Heidarzadeh heidarzad...@gmail.com
Hi @All
hi @ all,
i added a first draft to [1].
regards,
gerhard
[1] http://wiki.apache.org/incubator/February2012
2012/2/1 Marvin no-re...@apache.org
Dear podling,
This email was sent by an automated system on behalf of the Apache
Incubator PMC.
It is an initial reminder to give you plenty
Hi,
I'd like to call a VOTE on releasing Apache DeltaSpike 0.1-incubating.
Maven staging repository:
https://repository.apache.org/content/repositories/orgapachedeltaspike-187/
Source release:
the source-release looks fine - +1
regards,
gerhard
2012/2/4 Gerhard Petracek gpetra...@apache.org
Hi,
I'd like to call a VOTE on releasing Apache DeltaSpike 0.1-incubating.
Maven staging repository:
https://repository.apache.org/content/repositories/orgapachedeltaspike-187/
Source
didn't yet add my key to our repo. It can be found here:
https://svn.apache.org/repos/asf/openwebbeans/trunk/KEYS
LieGrue,
strub
- Original Message -
From: Gerhard Petracek gpetra...@apache.org
To: deltaspike-dev@incubator.apache.org
Cc:
Sent: Saturday, February 4, 2012 2:22
thank you for voting!
16 binding +1 votes:
- Antoine Sabot-Durand (ppmc)
- Arne Limburg (ppmc)
- Brian Leathem (ppmc)
- Cody Lerum (ppmc)
- Gerhard Petracek (ppmc, ipmc, mentor)
- Jakob Korherr (ppmc)
- Jason Porter (ppmc)
- John Ament (ppmc)
- Ken Finnigan (ppmc)
- Marius Bogoevici
hi @ all,
fyi:
i started the ipmc vote [1]. we have to do this additional step until we
graduate.
(a top level project can finish releases immediately as soon as the
corresponding vote passed.)
regards,
gerhard
[1] http://s.apache.org/B6a
1 - 100 of 834 matches
Mail list logo
