Dne 30.7.2012 16:47, Edward Capriolo napsal(a):
I am sure no one would have an issue with an optional findbugs target.
https://issues.apache.org/jira/browse/CASSANDRA-4891
here you have optional findbugs target.
Running Findbugs from ant is simple as well, just google "ant Findbugs",
plenty of doc and examples on how to do it...
--z
On Jul 30, 2012, at 11:18 AM, Radim Kolar wrote:
> i am using maven to build cassandra. i didnt have in mind to contribute build
> system because you are not interested
Dne 30.7.2012 16:52, Jonathan Ellis napsal(a):
Is Jenkins smart enough to be able to say, "I know we had X findbugs
warnings previously, which are known to be false positives, but now
there are X+1" ?
yes. Look at hadoop project pre-commit check builds.
i am using maven to build cassandra. i didnt have in mind to contribute
build system because you are not interested in maven. In maven you just
call findbugs plugin, nothing special to contribute. I had in mind patch
fixing various FB discovered problems. but because its difficult to post
it as
Findbugs can be customized with a exclude filter to exclude from checking
issues that produce a high number of false positives.
For the rest of "false positives" @suppresswarnings annotation can be used.
I suggest Understanding the issue Findbugs highlights before suppressing it, I
did see devs
On Mon, Jul 30, 2012 at 9:52 AM, Jonathan Ellis wrote:
> Is Jenkins smart enough to be able to say, "I know we had X findbugs
> warnings previously, which are known to be false positives, but now
> there are X+1" ?
In my experience, jenkins hasn't even been smart enough to build
cassandra in a co
Is Jenkins smart enough to be able to say, "I know we had X findbugs
warnings previously, which are known to be false positives, but now
there are X+1" ?
On Mon, Jul 30, 2012 at 9:47 AM, Edward Capriolo wrote:
> I am sure no one would have an issue with an optional findbugs target.
>
> On Mon, Ju
I am sure no one would have an issue with an optional findbugs target.
On Mon, Jul 30, 2012 at 10:32 AM, Radim Kolar wrote:
> was any decision about findbugs made? you do not consider code style
> recommended by findbugs as good practice which should be followed?
>
> I can submit few findbugs pat
I don't think there is much value in integrating it into the build
process, since there is a fairly high rate of false positives.
Intermittently running it manually could be valuable, and we have done
this in the past.
On Mon, Jul 30, 2012 at 9:32 AM, Radim Kolar wrote:
> was any decision about f
was any decision about findbugs made? you do not consider code style
recommended by findbugs as good practice which should be followed?
I can submit few findbugs patches, but it will probably turns into
flamewar WE vs FINDBUGS like there:
https://issues.apache.org/jira/browse/HADOOP-8619
find
Dne 23.7.2012 16:34, Zoltan Farkas napsal(a):
In general, I prefer integrating findbugs into the build process and fail the
build if issues are found. I am a strong believer in this approach, increases
the quality of the project significantly.
Thats true, i am currently in process of fixing fin
In general, I prefer integrating findbugs into the build process and fail the
build if issues are found. I am a strong believer in this approach, increases
the quality of the project significantly.
Enforcing coding style and complexity rules is one step further...
Cheers
--z
On Jul 23, 2012,
The line numbers here don't appear to match with trunk.
you are right, it was from old trunk 415 commits old. It was just demo
of findbugs, for serious use developers should install findbugs maven
plugin or eclipse plugin (preferred).
The line numbers here don't appear to match with trunk.
On Sun, Jul 22, 2012 at 9:36 AM, Radim Kolar wrote:
> I used findbugs on cassandra and it returns 69 possible errors.
>
> most problematic part of code is CQL - lot of null pointer problems there
>
> some interesting errors:
>
> C:/apache-nu
14 matches
Mail list logo
