findbugs version

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

findbugs version

Szczepan Faber
Hey guys,

Currently configured default findbugs version (2.0.3) is not happy
with java 8. Newest findbugs (3.0.0) enjoys java 8 but requires java 7
(http://findbugs.sourceforge.net/). I suggest we encapsulate this in
the plugin so that findbugs has higher chance to work out of the box
for Gradle users. So, if current java is < 1.7, we use findbugs 2.0.3,
else 3.0.0.

Thoughts?
--
Szczepan Faber
Core dev@gradle; Founder@mockito

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: findbugs version

Luke Daley-2


On 18 July 2014 at 12:33:54 am, Szczepan Faber ([hidden email]) wrote:

Hey guys, 

Currently configured default findbugs version (2.0.3) is not happy 
with java 8. Newest findbugs (3.0.0) enjoys java 8 but requires java 7 
(http://findbugs.sourceforge.net/). I suggest we encapsulate this in 
the plugin so that findbugs has higher chance to work out of the box 
for Gradle users. So, if current java is < 1.7, we use findbugs 2.0.3, 
else 3.0.0. 

Thoughts? 

+1.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: findbugs version

Adam Murdoch
In reply to this post by Szczepan Faber

This means two different people would use different versions of findbugs for the same project, if one happens run the build using java 6 and the other java 7. I don’t think this is a good idea.

I can see the following options:

1. Change the default version to 3.0.0. Fail with a decent error if running on Java 6.
2. Leave the default where it is. Fail with a decent error if running on Java 8.
3. Select 3.0.0 if the project’s target java version is >= 1.7. Fail with a decent error if running on Java 6 (we should be doing this any way). If the project’s target java version is <= 1.7 or not declared default to 2.x.
4. One of the above, plus deprecate default versions, and require that the version be explicitly declared.

I reckon we just go with #1.

On 18 Jul 2014, at 12:33 am, Szczepan Faber <[hidden email]> wrote:

Hey guys,

Currently configured default findbugs version (2.0.3) is not happy
with java 8. Newest findbugs (3.0.0) enjoys java 8 but requires java 7
(http://findbugs.sourceforge.net/). I suggest we encapsulate this in
the plugin so that findbugs has higher chance to work out of the box
for Gradle users. So, if current java is < 1.7, we use findbugs 2.0.3,
else 3.0.0.

Thoughts?
--
Szczepan Faber
Core dev@gradle; Founder@mockito

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: findbugs version

Szczepan Faber
> This means two different people would use different versions of findbugs for
> the same project, if one happens run the build using java 6 and the other
> java 7. I don't think this is a good idea.

It does sound somewhat dangerous but I'm wondering what's the
practical issue with this. It would be cool if our findbugs plugin
worked out of the box for java6 people, too. Perhaps a lifecycle
message saying that we're using downgraded version of Findbugs is
enough. OTOH, java6 is no longer supported, so your #1 idea is clean
and reasonable.

Cheers!

> On 18 Jul 2014, at 12:33 am, Szczepan Faber <[hidden email]> wrote:
>
> Hey guys,
>
> Currently configured default findbugs version (2.0.3) is not happy
> with java 8. Newest findbugs (3.0.0) enjoys java 8 but requires java 7
> (http://findbugs.sourceforge.net/). I suggest we encapsulate this in
> the plugin so that findbugs has higher chance to work out of the box
> for Gradle users. So, if current java is < 1.7, we use findbugs 2.0.3,
> else 3.0.0.
>
> Thoughts?
> --
> Szczepan Faber
> Core dev@gradle; Founder@mockito
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>
>
> --
> Adam Murdoch
> Gradle Co-founder
> http://www.gradle.org
> CTO Gradleware Inc. - Gradle Training, Support, Consulting
> http://www.gradleware.com
>
>
>



--
Szczepan Faber
Core dev@gradle; Founder@mockito

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: findbugs version

Adam Murdoch

On 22 Jul 2014, at 4:24 pm, Szczepan Faber <[hidden email]> wrote:

This means two different people would use different versions of findbugs for
the same project, if one happens run the build using java 6 and the other
java 7. I don't think this is a good idea.

It does sound somewhat dangerous but I'm wondering what's the
practical issue with this.

Some scenarios:

1. I’m using java 7 on a project that doesn’t declare a findbugs version.
2. I change the rule sets to include a new rule introduced in findbugs 3 and run the build.
3. It passes and I commit. CI is happy.
4. My teammate is using java 6. They update from vcs and run the build. It fails because the rule isn’t available.

or

1. In my organisation, all tools have to be vetted and are added to a corporate repo. I can’t use maven central. Findbugs 2 is available in this repo, Findbugs 3 is not.
2. I’m using java 6, I run the build and all is good. CI is happy.
3. My teammate switches to Java 7. The build fails because the new version of findbugs is not available.

You can also come up with similar situations where Ci is happy/not happy and the dev builds are/are not. Or reproducibility where I build now and in the future attempt to diagnose or reproduce that build.

In all these cases, it would be much better if the user received something like: “you are using the default version of findbugs (3.0.2) and this is not supported on the version of Java you are using (1.6.0_25). You should either upgrade your version of Java or use a different version of findbugs."


It would be cool if our findbugs plugin
worked out of the box for java6 people, too.

In general, we can’t really guarantee this for an external tool. We can give nice error messages, though.

Perhaps a lifecycle
message saying that we're using downgraded version of Findbugs is
enough. OTOH, java6 is no longer supported, so your #1 idea is clean
and reasonable.

Cheers!

On 18 Jul 2014, at 12:33 am, Szczepan Faber <[hidden email]> wrote:

Hey guys,

Currently configured default findbugs version (2.0.3) is not happy
with java 8. Newest findbugs (3.0.0) enjoys java 8 but requires java 7
(http://findbugs.sourceforge.net/). I suggest we encapsulate this in
the plugin so that findbugs has higher chance to work out of the box
for Gradle users. So, if current java is < 1.7, we use findbugs 2.0.3,
else 3.0.0.

Thoughts?
--
Szczepan Faber
Core dev@gradle; Founder@mockito

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email




--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com






-- 
Szczepan Faber
Core dev@gradle; Founder@mockito

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email


--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
CTO Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: findbugs version

Szczepan Faber
I'm sold ;)

On Wed, Jul 23, 2014 at 12:35 AM, Adam Murdoch
<[hidden email]> wrote:

>
> On 22 Jul 2014, at 4:24 pm, Szczepan Faber <[hidden email]> wrote:
>
> This means two different people would use different versions of findbugs for
> the same project, if one happens run the build using java 6 and the other
> java 7. I don't think this is a good idea.
>
>
> It does sound somewhat dangerous but I'm wondering what's the
> practical issue with this.
>
>
> Some scenarios:
>
> 1. I'm using java 7 on a project that doesn't declare a findbugs version.
> 2. I change the rule sets to include a new rule introduced in findbugs 3 and
> run the build.
> 3. It passes and I commit. CI is happy.
> 4. My teammate is using java 6. They update from vcs and run the build. It
> fails because the rule isn't available.
>
> or
>
> 1. In my organisation, all tools have to be vetted and are added to a
> corporate repo. I can't use maven central. Findbugs 2 is available in this
> repo, Findbugs 3 is not.
> 2. I'm using java 6, I run the build and all is good. CI is happy.
> 3. My teammate switches to Java 7. The build fails because the new version
> of findbugs is not available.
>
> You can also come up with similar situations where Ci is happy/not happy and
> the dev builds are/are not. Or reproducibility where I build now and in the
> future attempt to diagnose or reproduce that build.
>
> In all these cases, it would be much better if the user received something
> like: "you are using the default version of findbugs (3.0.2) and this is not
> supported on the version of Java you are using (1.6.0_25). You should either
> upgrade your version of Java or use a different version of findbugs."
>
>
> It would be cool if our findbugs plugin
> worked out of the box for java6 people, too.
>
>
> In general, we can't really guarantee this for an external tool. We can give
> nice error messages, though.
>
> Perhaps a lifecycle
> message saying that we're using downgraded version of Findbugs is
> enough. OTOH, java6 is no longer supported, so your #1 idea is clean
> and reasonable.
>
> Cheers!
>
> On 18 Jul 2014, at 12:33 am, Szczepan Faber <[hidden email]> wrote:
>
> Hey guys,
>
> Currently configured default findbugs version (2.0.3) is not happy
> with java 8. Newest findbugs (3.0.0) enjoys java 8 but requires java 7
> (http://findbugs.sourceforge.net/). I suggest we encapsulate this in
> the plugin so that findbugs has higher chance to work out of the box
> for Gradle users. So, if current java is < 1.7, we use findbugs 2.0.3,
> else 3.0.0.
>
> Thoughts?
> --
> Szczepan Faber
> Core dev@gradle; Founder@mockito
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>
>
> --
> Adam Murdoch
> Gradle Co-founder
> http://www.gradle.org
> CTO Gradleware Inc. - Gradle Training, Support, Consulting
> http://www.gradleware.com
>
>
>
>
>
>
> --
> Szczepan Faber
> Core dev@gradle; Founder@mockito
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>
> --
> Adam Murdoch
> Gradle Co-founder
> http://www.gradle.org
> CTO Gradleware Inc. - Gradle Training, Support, Consulting
> http://www.gradleware.com
>
>
>



--
Szczepan Faber
Core dev@gradle; Founder@mockito

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Loading...