On 6/03/10 5:56 AM, Mike wrote:
I agree there needs to be some tests for these. I'll start addressing that.
Excellent. If it comes down to choosing, I'd much prefer to have an
integration test that provides some kind of smoke test for this stuff,
over a bunch of unit tests (of course, I'd rather have both kinds of
tests, but that's not always possible). Right now, it's very difficult
to determine if changes to the core break the open api or the gui. In
general, I let the tests guide me. If intellij tells me a piece of code
which needs to change is not used, then I delete it and see what the
tests say about the change. This is why the files went away, nothing
failed when I deleted them. An integration test would help me to keep
things working as intended, and I really, really don't want to be
manually testing stuff every time I make a change.
Mike
Automated Logic Research Team
--- On Fri, 3/5/10, Hans Dockter<[email protected]> wrote:
From: Hans Dockter<[email protected]>
Subject: Re: [gradle-dev] removal of 'unused code' in open-api
To: [email protected]
Date: Friday, March 5, 2010, 3:46 PM
Hi Mike,
On Thu, Mar 4, 2010 at 3:29 PM,
Mike<[email protected]>
wrote:
Adam,
on January 5th you removed several classes from the Open
API project of gradle. The comment states that these were
unused. These classes are being used by my Idea plugin
(which I'm finally back working on trying to see if I
can get it into the open source community). I can add them
back or you could revert the change, but specifically, I
wanted you to be aware they are used by an external project.
If you're wondering why, its because the Open API
project is trying to shield external users from changes in
gradle. My hope was that once gradle hits 1.0, only
additions would be made to the Open API thereby gaining
backward compatibility for things like IDE plugins and CI
servers. I wanted to decouple versions of gradle and IDEs so
people can be free to upgrade either at any time (nothing
more frustrating than when your latest IDE isn't
compatible with your tools). Its also been made generic so
many IDE can take advantage of several features in both
gradle
and the gradle UI.
It is hard for us to have classes in the codebase, where we
don't get any feedback if we break things. So either
those classes should be part of the plugin or we need tests
for them.
Cheers
- Hans
--
Hans Dockter
Founder, Gradle
http://www.gradle.org, http://twitter.com/gradleorg
CEO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
Mike
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
