On 06/09/2011, at 2:21 PM, Steve Ebersole wrote:
> This is going to be a preference thing, meaning there is obviously no
> right/wrong answer here. Y'all are just going to have to make a decision
> here in my experience.
>
> But since you asked... :)
>
> I dislike this as well. As a library developer I perhaps have a different
> requirement compared to application developers. But Hibernate, for example,
> uses deprecation quite a bit which is pretty normal IMO with libraries that
> have been around for longish amounts of time. Under this proposal though I
> would have to do "extra" stuff just to be able to build which obviously I
> would like to avoid ;)
We are in the same boat with library vs. application. WRT to deprecation, the
solution would be to use @SuppressWarnings("deprecation") where for some reason
we are intentionally using a deprecated part of an API.
I'm not aware of any situation where a warning can't be suppressed with
@SuppressWarnings, but I don't have a lot of experience with it.
The problem I am trying to address is that the build currently emits quite a
few warnings and has done for a while. I'd prefer that it didn't.
One option would be to have a separate CI build that just did a clean compile
and failed for warnings, giving us incentive to fix without blocking.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
