I'm sold ;)
On Wed, Jul 23, 2014 at 12:35 AM, Adam Murdoch
<adam.murd...@gradleware.com> wrote:
>
> On 22 Jul 2014, at 4:24 pm, Szczepan Faber <szcze...@gmail.com> 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 <szcze...@gmail.com> 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
