+1 to drop, I hate them.
On 1 Apr 2013, at 10:06, Christian Kaltepoth christ...@kaltepoth.de wrote:
+1 for dropping
2013/3/31 Cody Lerum cody.le...@gmail.com
drop em.
On Sun, Mar 31, 2013 at 10:35 AM, Mark Struberg strub...@yahoo.de wrote:
yes, let's drop them. annotations are
Hi Adrian,
Please add comments to CDI-129, so that when we address the issue we take note
of your comments, all of which are relevant.
On 27 Mar 2013, at 22:08, Adrian Gonzalez adr_gonza...@yahoo.fr wrote:
Hello,
Sorry to add more comments on this issue.
I have quite a few questions /
of
responsibility of the Apache DeltaSpike Project; and be it further
RESOLVED, that the persons listed immediately below be and
hereby are appointed to serve as the initial members of the
Apache DeltaSpike Project:
Gerhard Petracek gpetracek at apache.org
Mark Struberg struberg at apache.org
Pete Muir
Hi all,
At the moment it's really hard for Red Hat to fund more people to work on
DeltaSpike. Without a clear roadmap, and a regular release schedule (e.g. time
boxed) it's really hard for us to justify more people for DeltaSpike as we
can't see how many people we should offer to get to the
://github.com/rmannibucau
2012/12/20 Pete Muir pm...@redhat.com:
:-) Yes for sure. I suspect we dont' need @InvocationHandler at all.
On 20 Dec 2012, at 16:30, John D. Ament wrote:
The problem I have is that now InvocationHandler is both an
interface
and
an @interface which will make
Hi
I'm struggling to use BeanProvider to get a reference to a bean with a
parameterized type.
I tried:
Type type = new TypeLiteralEventExceptionToCatchEvent() {
private static final long serialVersionUID = -1563354351612225196L;
}.getType();
EventExceptionToCatch evt =
!
+1 to #1. I also agree that the term Service Handler
might
not
be
so
appropriate, so it should be discussed as well.
Here is the latest pull request with some comments from
Pete
yet
to
be
reviewed: https://github.com/jboss/cdi/pull/28
2012/3/7 Pete Muir pm...@redhat.com
Agreed
is the latest pull request with
some comments from Pete
yet
to
be
reviewed:
https://github.com/jboss/cdi/pull/28
2012/3/7 Pete Muir
pm...@redhat.com
Agreed :-)
George is working on it for CDI
1.1. George, can you share
your
proposal
so far?
On 7 Mar 2012, at 17:05, Gerhard
On 17 Dec 2012, at 08:55, Gerhard Petracek wrote:
hi karl,
#1 apache myfaces (extval) doesn't implement jsr 303 (e.g. apache
bval implements it)
#2 there is no agreement that ds is only backend oriented
regards,
gerhard
2012/12/17 Karl Kildén karl.kil...@gmail.com
Hi Thomas,
On 20 Nov 2012, at 00:50, Radu Creanga wrote:
Hello everyone,
Pete,
We aren't firing servlet events in CDI 1.1 due to backwards incompatibility
issues with extensions.
Hmm, I was going off of [1]. There it stills says that it will be done, but
ok.
This was proposed but in the end the
+0 from me, I would be happy with either + don't really use JSF anymore ;-)
On 17 Oct 2012, at 10:27, Mark Struberg wrote:
+1
looks really good!
LieGrue,
strub
- Original Message -
From: Gerhard Petracek gerhard.petra...@gmail.com
To: deltaspike
Original inspiration for xml came from Gavin's design for CDI 1.0. I don't know
more details about why they went this direction.
On 25 Sep 2012, at 00:19, Jason Porter wrote:
It did (maybe it still does), but at some point we decided that wasn't
recommended, I don't recall why though, perhaps
IMO this is a very useful feature. There was a feature request for CDI 1.1 to
add this, but I'm not sure it will make it.
On 13 Sep 2012, at 21:49, Romain Manni-Bucau wrote:
Hi,
wonder if we want the already bridged proxy feature (i'll explain don't
worry ;)).
There are cases where the
As I mentioned, Jason is on vacation atm, so I'll just insert a placeholder
that he was planning on migrating the XML config from Seam into DeltaSpike.
If we can refrain from an extensive discussion until he is back from vacation,
that will make the discussion flow a lot better :-) I just
All, the CDI EG requires feedback on an item in the spec which is not clear,
and has been implemented differently between implementations, and is not TCK
tested. As Deltaspike contains lots of extensions authors, requesting feedback.
Please either send direct to me, or post to
On 15 Aug 2012, at 15:30, Stuart Douglas wrote:
On 15/08/2012, at 11:20 PM, Pete Muir pm...@redhat.com wrote:
All, the CDI EG requires feedback on an item in the spec which is not clear,
and has been implemented differently between implementations, and is not TCK
tested. As Deltaspike
On 15 Aug 2012, at 16:23, Stuart Douglas wrote:
On 16/08/2012, at 12:41 AM, Pete Muir pm...@redhat.com wrote:
On 15 Aug 2012, at 15:30, Stuart Douglas wrote:
On 15/08/2012, at 11:20 PM, Pete Muir pm...@redhat.com wrote:
All, the CDI EG requires feedback on an item in the spec
Apologies, I meant have it in eventually e.g. 0.4 not have it in this
release :-).
On 30 Jul 2012, at 11:25, Pete Muir wrote:
I would like us to have this bit in, whether it's in a separate module, or
core, that is fine by me.
On 27 Jul 2012, at 23:29, Mark Struberg wrote:
I'd rather
And by it I mean the mini-authentication API + credentials + events we had in
0.2 :-)
On 30 Jul 2012, at 11:29, Pete Muir wrote:
Apologies, I meant have it in eventually e.g. 0.4 not have it in this
release :-).
On 30 Jul 2012, at 11:25, Pete Muir wrote:
I would like us to have
/5 Pete Muir
pm...@redhat.comIn
Seam
2
we:
* checked if UT was
available in
JNDI, and used it if
it
were
* checked if there
was a CMT
transaction, and used it
(IIRC
this
wwas to work around
Having looked at what we had in 0.2
(https://github.com/apache/incubator-deltaspike/tree/5e4a7eb4de01004206f24ae22b9850e643bffe54/deltaspike/modules/security/api/src/main/java/org/apache/deltaspike/security/api
is the link into the tag :-), I think this would be a good point to stay with.
The
think it is
better to had them in the cms instead of by project
wdyt?
- Romain
2012/7/25 Pete Muir pm...@redhat.com
On 25 Jul 2012, at 16:36, Matt Benson wrote:
On Wed, Jul 25, 2012 at 10:22 AM, Pete Muir pm...@redhat.com wrote:
On 25 Jul 2012, at 16:16, Matt Benson wrote
On 25 Jul 2012, at 08:05, Romain Manni-Bucau wrote:
Hi,
CMS should be fine for this requirements then it needs some work but offers
all the needed hooks.
At least for consistency with other apache projects (a lot migrated to the
cms) i think it is good to use it.
I agree, it seems like
I think a high level roadmap, showing how we get from here to 1.0, will help a
lot:
* it will give users confidence that their favourite feature will be added
* it will give people planning new projects based on CDI an understanding of
when they can start adding DeltaSpike to their project, and
+1 to adding it from me.
XML config is probably the feature (as opposed to enhancement to existing
feature or bug fix) most requested for CDI. I think we need something like
this in DeltaSpike, in order to fulfil our goals.
A non compiled format such as XML (or YAML or ...) makes a lot of
-
From: Pete Muir pm...@redhat.com
To: deltaspike-dev@incubator.apache.org
Cc:
Sent: Saturday, July 7, 2012 12:33 PM
Subject: Re: v0.4-incubating adding Seam Config (xml config)
+1 to adding it from me.
XML config is probably the feature (as opposed to enhancement to existing
feature
In Seam 2 we:
* checked if UT was available in JNDI, and used it if it were
* checked if there was a CMT transaction, and used it (IIRC this wwas to work
around abug)
* otherwise tried to use a resource local transaction (e.g. from Hibernate)
* allowed the user to override and specify one
I agree, it would be good to get a bit further away from the default bootstrap
theme, make it look more individual...
On 5 Jul 2012, at 15:45, Romain Manni-Bucau wrote:
i think it needs a nicer theme (colors) but it is a really nice startup!
- Romain
2012/7/5 Mark Struberg
Liking it more already!
What about aligning the button colours with the overall colour scheme?
On 5 Jul 2012, at 17:34, Charles Moulliard wrote:
Here is a new proposition where color has been changed in the nav bar, nav
bar is bigger too, size is bigger for text, change color box in green
On 4 Jul 2012, at 08:09, Charles Moulliard wrote:
Hi,
Yesterday night, a interesting and vibrant discussion took place on IRC
channel about new look'n'feel of DeltaSpike. As we are human, with different
colors perceptions and different tastes, I have find the time this morning
to compile
.:
deltaspike-jpa-transaction
deltaspike-jpa-query
...
regards,
gerhard
2012/6/25 Pete Muir pm...@redhat.com
Well, we were looking for some good use cases for the ServiceHandler.
I would be in support of adding it to DS core, now we have a
strong
use
case.
Property util should
...@gmail.com
@ pete:
+1
@ java-se vs java-ee features:
we can think about a more fine-grained structure (similar to seam3).
e.g.:
deltaspike-jpa-transaction
deltaspike-jpa-query
...
regards,
gerhard
2012/6/25 Pete Muir pm...@redhat.com
Well, we were looking for some good
. Just a maven
trick. this way everuone is happy and honestly today any nice IDE supports
it without any issue.
- Romain
2012/6/27 Pete Muir pm...@redhat.com
It's insanely complex for a new user. Java is already confusing, with it's
hundreds of libs. Adding more complexity to packaging
IMO this would be a great thing to add!
On 24 Jun 2012, at 16:56, Romain Manni-Bucau wrote:
Hi,
just browsed http://ctpconsulting.github.com/query/1.0.0.Alpha4/index.html and
it is really amazing (a spring-data CDI oriented).
it is currently based on solder but since DS integrates a lot
,
strub
- Original Message -
From: Pete Muir pm...@redhat.com
To: deltaspike-dev@incubator.apache.org
Cc:
Sent: Monday, June 25, 2012 1:53 PM
Subject: Re: cdi-query
IMO this would be a great thing to add!
On 24 Jun 2012, at 16:56, Romain Manni-Bucau wrote:
Hi,
just
Agree with Mark, much better to CDI enable a converter framework in DS, than
make a whole converter framework :-)
On 14 Jun 2012, at 07:21, Mark Struberg wrote:
Hi Antoine!
DS is imo clearly not only targeting JSF!
And I wasn't saying that a Converter framework wont be fine.
BUT:
Following up on all emails sent so far on this thread:
* I like Mark's priorities - @Transactional is definitely the item most
requested
* I like the design of plugging in different persistence strategies
* Agreed that the standardised stuff for configuring datasources is a mess, we
don't
Hi all
The Java EE spec leads would like feedback on how often stereotypes are
dynamic vs static.
A static stereotype is one that is defined in Java code, compiled, and then
deployed without modification from a container extension.
A dynamic stereotype is one that defined in Java code,
A late +1 :-)
On 23 Apr 2012, at 06:30, Nicklas Karlsson wrote:
+1 for all three
On Sun, Apr 22, 2012 at 9:14 PM, Mehdi Heidarzadeh
heidarzad...@gmail.comwrote:
+1 for JPA support.
--
---
Nik
Just thinking about the process here. Bruno has certain deliverables with dates
that relate to security + CDI, and can help out with API design and
implementation. Some of the stuff he needs to deliver is later in the the
original plan. So I would suggest that we reorder the plan so that
We also split this out originally in Seam 3 (catch from Solder, i8ln from
Solder), and we found it was too much split. We merged catch back into core.
I would say we should put both in core, assuming there is no JSF dependency
introduced.
OT: Is the message name final? I prefer i8ln as the
stones of such a
decision are.
LieGrue,
strub
- Original Message -
From: Pete Muir pm...@redhat.com
To: deltaspike-dev@incubator.apache.org; Mark Struberg strub...@yahoo.de
Cc:
Sent: Thursday, April 5, 2012 2:30 PM
Subject: Re: [DISCUSS] Modularity for reusable parts
+1 to @BeforeHandles.
On 4 Apr 2012, at 08:44, Gerhard Petracek wrote:
hi @ all,
jason and i updated the current draft [1] - please review it.
before jason will commit it (by the end of the week), we would like to
discuss TraversalMode.
currently there are 2 modes DEPTH_FIRST
).
- it doesn't make sense for scopes which are too different (and the spi
should be enough to customize the default behaviour of existing scopes).
it would be nice if you share your requirements, maybe there is an existing
(custom) scope you can use.
regards,
gerhard
2012/4/2 Pete
, Pete Muir wrote:
If you are happy to be tied to a specific CDI implementation, you could use
the Weld bound conversations -
http://docs.jboss.org/weld/reference/1.1.5.Final/en-US/html/contexts.html#d0e5506
- which can be backed by two maps, one representing the session and one
the request
since instance
has
another meaning in CDI...
Regards,
Arne
-Ursprüngliche Nachricht-
Von: Pete Muir [mailto:pm...@redhat.com]
Gesendet: Dienstag, 3. April 2012 15:20
An: deltaspike-dev@incubator.apache.org; Mark Struberg
Betreff: Re: Custom Context utilities
Given that it's
I'm not quite sure what this would constitute, beyond a trivial base class or a
consistent start/stop API. Every context has quite different requirements in my
experience, and the hard part is linking the context to the start/stop points,
and to whatever backs the context, not the actual
Exposing OSGi services to CDI should be portable, but the rest of what is in
OSGi Weld isn't so easy IMO, as it actually involves how the CDI container is
booted, which doesn't have an SPI in CDI. Mathieu can tell you more.
Note that we are also pursuing this as an OSGI spec (David and Martin
/infinispan/infinispan/blob/master/cdi/extension/src/main/java/org/infinispan/cdi/AdvancedCacheProducer.java
[2]
https://github.com/seam/social/blob/develop/impl/src/main/java/org/jboss/seam/social/oauth/OAuthGenericManager.java
Antoine SABOT-DURAND
Le 9 mars 2012 à 17:32, Pete Muir a écrit
,
gerhard
2012/3/27 Pete Muir pm...@redhat.com
This was one of the main purposes of Solder, which is where these
classes
come from. Perhaps we need a deltaspike toolbox module.
On 26 Mar 2012, at 22:01, Matt Benson wrote:
Could it be that certain classes belong in some DS artifact
, then?
Matt
On Sun, Mar 25, 2012 at 1:40 PM, Jason Porter lightguard...@gmail.com wrote:
For now, the wiki is as good as anywhere else.
Sent from my iPhone
On Mar 25, 2012, at 12:03, Pete Muir pm...@redhat.com wrote:
Ok, I see that they are not used. So, what is the objection
the implementation to core?
I can't see how you can reduce the visibility without changing the API?
regards,
gerhard
2012/3/25 Pete Muir pm...@redhat.com
I assume you mean the visibility of the constructors of AnnotationBuilder,
ImmutableInjectioPoint, InjectableMethod, and ParameterValue
are even quite special for extensions authors.
regards,
gerhard
2012/3/25 Pete Muir pm...@redhat.com
Yes, this is definitely all squarely aimed at extension authors and not
end user apps IMO.
On 25 Mar 2012, at 18:03, Mark Struberg wrote:
Is this useful for Extension implementers
PM
Subject: Re: [DISCUSS] start()/boot() vs stop()/shutdown()
hi mark,
3 lines would mean that we agree on the merged shutdown and that isn't
what
we have right now.
regards,
gerhard
2012/3/19 Pete Muir pm...@redhat.com
I'm strongly in favour of the slightly more verbose API
/openwebbeans.properties
- Original Message -
From: Pete Muir pm...@redhat.com
To: deltaspike-dev@incubator.apache.org
Cc: Mark Struberg strub...@yahoo.de
Sent: Monday, March 19, 2012 2:29 PM
Subject: Re: [DISCUSS] start()/boot() vs stop()/shutdown()
What about if I wanted to stop
Petracek wrote:
hi pete,
in my test it worked
with org.jboss.weld.context.ApplicationContext#invalidate
regards,
gerhard
2012/3/19 Pete Muir pm...@redhat.com
You can't restart the application context in Weld.
I'll have to think on what this means for the API you propose, but my
/asf/openwebbeans/trunk/webbeans-test/cditest/src/main/java/org/apache/webbeans/cditest/CdiTestContainer.java
- Original Message -
From: Pete Muir pm...@redhat.com
To: deltaspike-dev@incubator.apache.org
Cc:
Sent: Monday, March 19, 2012 3:24 PM
Subject: Re: [DISCUSS] start
- Original Message -
From: Pete Muir pm...@redhat.com
To: deltaspike-dev@incubator.apache.org; Mark Struberg strub...@yahoo.de
Cc:
Sent: Monday, March 19, 2012 3:41 PM
Subject: Re: [DISCUSS] start()/boot() vs stop()/shutdown()
Personally, I think this is a safe API to go
as well.
regards,
gerhard
2012/3/19 Pete Muir pm...@redhat.com
Sorry ;-)
(A).
On 19 Mar 2012, at 14:52, Mark Struberg wrote:
Personally, I think this is a safe API to go with for no
And which of the 2 options did 'this' stand for? :)
A.) startRequestContext
I quite like Bean Family Producer actually.
On 9 Mar 2012, at 08:54, Antoine Sabot-Durand wrote:
What about Bean Family or Bean Family Producer ?
Antoine SABOT-DURAND
Le 7 mars 2012 à 16:55, Pete Muir a écrit :
Yes, we need a new name for the feature, generic beans isn't good
.
at least i haven't seen an use-case which really needed it. that was
the
reason for a +0 (which still means that i'm ok with adding it).
regards,
gerhard
2012/3/6 Pete Muir pm...@redhat.com
So, you mean just write a bean with all the boilerplate code in it?
On 6 Mar 2012, at 15:58
agree on the idea, it should be re-visited for
deltaspike (if we really need it)
4) we agree on it independent of the result in cdi 1.1
1-3 is ok for me but -1 for #4
regards,
gerhard
2012/3/7 Pete Muir pm...@redhat.com
I'm not sure what you mean by a super interceptor
What CDI mechanism would you use instead?
On 5 Mar 2012, at 08:47, Gerhard Petracek wrote:
+0
no -1 because there are use-cases for it.
no +1 because i would use std. cdi mechanisms instead.
regards,
gerhard
2012/3/4 Gerhard Petracek gerhard.petra...@gmail.com
hi john,
the
.
regards,
gerhard
2012/2/29 Mark Struberg strub...@yahoo.de
sounds really good!
we could introduce a subset of this stuff in DS and provide a backward
compatway for CDI-1.0 containers (beside using a different package)
LieGrue,
strub
- Original Message -
From: Pete
Pete Muir pm...@redhat.com
This just reinforces my feeling that CDIControl and context lifecycle
management should be two separate APIs. Context control is relevant in Java
EE and SE. Container start/stop is only relevant in JavaSE.
I would suggest that context lifecycle management should
behaviour IRL :-)
On 29 Feb 2012, at 15:13, Pete Muir wrote:
I've added the proposed APIs to the doc.
On 29 Feb 2012, at 14:18, Gerhard Petracek wrote:
i agree with pete.
we can create a draft at [1].
regards,
gerhard
[1]
https://cwiki.apache.org/confluence/display/DeltaSpike/CDI+1.1
+1
On 16 Feb 2012, at 09:02, Gerhard Petracek wrote:
hi @ all,
you might have seen that i committed the initial version of [1] and [2].
right now we can't commit the corresponding tests, because we have to wait
for a new version of arquillian.
therefore i pushed them to [3]. the
On 20 Feb 2012, at 15:10, Dan Allen wrote:
The location of beans.xml in a war that Rudy suggests is correct, according
to the spec.
We've discussed this issue frequently on various mailinglists and forums
because the general consensus is that a web archive should support honor
either
I think how this works is interpreted differently by everyone. So for now we
assume that it doesn't work there. And for CDI 1.1 we explicitly list it as a
location to be supported and force people to support it (Stuart).
On 20 Feb 2012, at 15:37, Mark Struberg wrote:
The CDI spec might be
a multi-page dialogue gets opened and ends
when it will finally be stored.
etc.
Of course for custom scopes this needs to be refined or the Extension
providing this scope must allow us to control this.
LieGrue,
strub
- Original Message -
From: Pete Muir pm...@redhat.com
+1 to the idea but I would want to discuss the API in quite a lot of detail.
On 9 Feb 2012, at 10:13, Mark Struberg wrote:
Hi!
I developed an API to bootstrap and control CDI containers from within a SE
application [1].
This was originally developed to make OpenWebBeans SE applications
+1
On 4 Feb 2012, at 01:22, Gerhard Petracek wrote:
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:
On 30 Jan 2012, at 01:01, Shane Bryzak wrote:
On 27/01/12 16:55, Gerhard Petracek wrote:
hi @ all,
(i planned to send this mail after starting the release procedure for v0.1.
however, the review phase for v0.1 is going to end soon and we have seen
several other discussions already.)
Sorry, yes, I was to specific calling out Gerhard ;-)
On 30 Jan 2012, at 12:57, Pete Muir wrote:
I think we're suffering from a communication problem here, rather than a
different philosophy ;-)
What we are proposing is an API/SPI abstraction which delegates the actual
work to other
of the security module we might have multiple impl.
modules) or users aren't interested in using one of our impl. module at
all, but the other deltaspike modules need an api/spi to use it - if the
user adds an impl module to the application)
regards,
gerhard
2012/1/30 Pete Muir pm...@redhat.com
Yep. It will be great to see Deltaspike running well on all Java EE servers and
beyond!
On 26 Jan 2012, at 18:17, Mark Struberg wrote:
Hi Joseph!
That's great news!
You might already know Rudy De Busscher who is also very active on Apache
MyFaces.
He is already helping out by
Also,
On 25 Jan 2012, at 09:25, Gerhard Petracek wrote:
1) -1 for i18n logging (i think we agree on it already)
I know our product managers are after i8ln for log messages - at least INFO
(IIRC) and above should be l10n'd. I'll try to share the why when I've chatted
to them.
So, I'm +0
Message -
From: Pete Muir pm...@redhat.com
To: deltaspike-dev@incubator.apache.org
Cc:
Sent: Wednesday, January 25, 2012 12:23 PM
Subject: Re: [DISCUSS] Logging
Also,
On 25 Jan 2012, at 09:25, Gerhard Petracek wrote:
1) -1 for i18n logging (i think we agree on it already)
I
+0.5 from me as well.
I would want to see AnnotationInstanceProvider enhanced to have the ability to
create a memberless annotation instance without having to provide an empty map
as an argument.
I would like to spend some time considering a type safe approach such as Matt's
*in addition to*
The idea behind the redefiner was to allow the use of a limited form of a
closure to work over the class. Every annotation on the class will receive a
callback to the function, in which you can decide how to use the annotation
(replace, keep etc). This gives you access to the context in which
, it's possible imperatively, but messy imo, as you need to
iterate over a lot of stuff to get there.
On 18 Jan 2012, at 15:51, Pete Muir wrote:
The idea behind the redefiner was to allow the use of a limited form of a
closure to work over the class. Every annotation on the class will receive
+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 they make a lot of
+1. Solder offers the same -
https://github.com/seam/solder/blob/master/api/src/main/java/org/jboss/solder/reflection/AnnotationInstanceProvider.java
Solder also allows you to pass in a map of values. Does CODI have a
ComplexLiteral that does this?
On 18 Jan 2012, at 17:08, Gerhard Petracek
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 the same -
https://github.com
in the
DeltaSpike repo) says Copyright 2011, Red Hat, Inc. and/or its
affiliates, and individual contributors by the @authors tag. The
@authors tag cites Stuart Douglas and Pete Muir, so I read the notice
as saying that copyright is shared between these individuals and Red
Hat
On 15 Jan 2012, at 16:22, Mark Struberg wrote:
Copyright 2011, Red Hat, Inc. and/or its
affiliates, and individual contributors by the @authors tag.
To clarify this as well. This doesn't mean a 'shared' ownership! Usually this
wording in an OSS license is used to express that both the
I like this :-)
On 3 Jan 2012, at 19:33, Arne Limburg wrote:
@Exclude could be used in a sentence:
@Exclude(inProjectStage=Production.class)
@Exclude(notInProjectStage=UnitTest.class)
@Exclude(onExpression=...)
-Ursprüngliche Nachricht-
Von: Pete Muir [mailto:pm...@redhat.com
This is no longer true, Eclipse (m2e) supports both approaches nowadays.
On 23 Dec 2011, at 23:02, Dan Allen wrote:
I agree that it potentially puts some bumps in the road, but the benefit is
that you can import that parent into the IDE when it's adjacent to the
other modules. When it's above
We chose @Veto originally, as it didn't deviate from the spec's veto() method,
so should be less of a learning curve. I don't like @Deactivate as it makes it
sound like you have to activate other beans. @Ignore is too overloaded a term
for me to be comfortable with it (@IgnoreWarnings). I like
89 matches
Mail list logo
