I'll do some more digging but I now suspect it is one of the annotation
processors in the hpi lifecycle... on the versions of java on my machine I
could not reproduce this issue either... I even added some tests using
abstract classes and when the annotations are available again in a
module-c...
S
Stephen;
Since I need this in with the smallest attainable spoon; I made a small
test project:
https://github.com/krosenvold/annotation-test.git
In module-b there is *no* JSR whatsoever on the classpath, even though the
interface in module A is annotated.
This works on java 1.5 and 1.7.
This s
notice we already have com.google.code.findbugs:jsr305 in core dependencies [1]
through transitive dependencies from guava
given classloader isolation, I don't think this has much impact, as soon as it
is not used in Maven public API
Regards,
Hervé
[1]
http://maven.apache.org/ref/3-LATEST/ap
On 8 May 2013 11:49, Kristian Rosenvold wrote:
> Just to be totally clear on this (and still using a tiny spoon); the real
> issue here is really if we want to add the annotations to core
> itself.
If you want to add these annotations onto any class that will be
implemented or extended in a diff
Just to be totally clear on this (and still using a tiny spoon); the real
issue here is really if we want to add the annotations to core
itself. It would appear to me that all other use is basically fine with
provided-scope.
And if we decided to stick with javax.annotation.Nonnull
and javax.annota
Hmmm though using the when parameter may be an issue: e.g.
@Nonnull(when=MAYBE)
On 8 May 2013 11:23, Stephen Connolly wrote:
> Hmmm I may have lost the plot somewhat, as the findbugs annotations are
> @TypeQualifierNickname's for @Nonnull anyway...
>
> I guess my point is that we need to decide
Hmmm I may have lost the plot somewhat, as the findbugs annotations are
@TypeQualifierNickname's for @Nonnull anyway...
I guess my point is that we need to decide *and document* exactly which
annotations are we using. My view is the Nonnull and Nullable are good...
ones with parameters are less go
If you do
com.google.code.findbugs
jsr305
2.0.1
provided
In one of Maven's APIs thinking that RetentionPolicy.RUNTIME or
RetentionPolicy.COMPILE will save you as the JVM spec says missing
annotations are to be ignored... you will be burned when compiling
implemen
Linking to one of your private git repos made this only marginally clearer;
I see the edu.umd in there though !
> So setting the dependency as "provided" is all well and good until you need
> to implement an interface with the annotation applied... at which point you
> need to add back in the "p
https://github.com/stephenc/findbugs-annotations which has the following
annotations:
https://github.com/stephenc/findbugs-annotations/blob/master/src/main/java/edu/umd/cs/findbugs/annotations/NonNull.java
https://github.com/stephenc/findbugs-annotations/blob/master/src/main/java/edu/umd/cs/findbu
You mean there's an older set of findbugs annoations ?
Kristian
2013/5/8 Stephen Connolly
> IntelliJ also supports the findbugs and jcip annotations too... but in any
> case I will hold my piece... given that these annotations do not have
> parameters the risk is almost non-existant for *these
ok, I started with https://issues.apache.org/jira/browse/MPOM-40
Regards,
Hervé
Le mercredi 8 mai 2013 10:06:08 Kristian Rosenvold a écrit :
> I suspect like a lot of the rest of the community, they simply gave up on
> the jcp.
>
> I am no insider on the project but com.google.code.findbugs/jsr
IntelliJ also supports the findbugs and jcip annotations too... but in any
case I will hold my piece... given that these annotations do not have
parameters the risk is almost non-existant for *these* but I do think it is
a more general risk
On 8 May 2013 09:06, Kristian Rosenvold wrote:
> I susp
I suspect like a lot of the rest of the community, they simply gave up on
the jcp.
I am no insider on the project but com.google.code.findbugs/jsr-305 was
last published in a 2.0.1 version in july 2012, and
seems to be alive and kicking. IntelliJ also supports the annotations which
means we finall
+1 for having some set of @NonNull annotation and picking it. I have raised
my concerns about potential signature change causing classloading issues.
Somebody could do an experiment and prove my concerns to be a pile of
rubbish... in any case, let's pick a set of annotations and use them.
On 8 Ma
On 8 May 2013 08:34, Hervé BOUTEMY wrote:
> I like this: could we define it as the standard way to add such
> annotations in
> whole Maven components? Any problem if we do it in Maven core itself?
>
> I'm not a JSR-305 expert, any basic explanation on the
> com.google.code.findbugs:jsr305 choice
+1 for making this standard all over the place. As long as we use
"provided" scope we
don't have to worry about conflicts either (to my understanding annotations
don't need to
be present in the runtime).
The tool support gathered is simply /immense/; at least in IntelliJ idea.
It tends to
get a bi
I believe I removed that about 10 minutes later :) Repeat after me:
Compile, then commit.
Kristian
2013/5/8 Stephen Connolly
> On 7 May 2013 17:49, wrote:
>
> > Updated Branches:
> > refs/heads/master 231773324 -> 7b330f584
> >
> >
> > Added jsr305 annotations
> >
> >
> > Project: http://gi
On 7 May 2013 17:49, wrote:
> Updated Branches:
> refs/heads/master 231773324 -> 7b330f584
>
>
> Added jsr305 annotations
>
>
> Project: http://git-wip-us.apache.org/repos/asf/maven-surefire/repo
> Commit:
> http://git-wip-us.apache.org/repos/asf/maven-surefire/commit/7b330f58
> Tree: http://gi
yeah, nice to hear: we added a lot of ITs to m-site-p to improve quality, and
this one surprised me a lot.
I'm glad I won't have to work once again on the topic :)
Regards,
Hervé
Le mardi 7 mai 2013 21:40:39 Andreas Gudian a écrit :
> Ha, found it. The site plugin is working correctly, but I ha
I like this: could we define it as the standard way to add such annotations in
whole Maven components? Any problem if we do it in Maven core itself?
I'm not a JSR-305 expert, any basic explanation on the
com.google.code.findbugs:jsr305 choice is good to know
then we could add it to maven parent
21 matches
Mail list logo
