<!--
  ~ Copyright 2009 the original author or authors.
  ~
  ~ Licensed under the Apache License, Version 2.0 (the "License");
  ~ you may not use this file except in compliance with the License.
  ~ You may obtain a copy of the License at
  ~
  ~      http://www.apache.org/licenses/LICENSE-2.0
  ~
  ~ Unless required by applicable law or agreed to in writing, software
  ~ distributed under the License is distributed on an "AS IS" BASIS,
  ~ WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  ~ See the License for the specific language governing permissions and
  ~ limitations under the License.
  -->
<appendix id='ide_support' xmlns:xi="http://www.w3.org/2001/XInclude">
    <title>Existing IDE Support and how to cope without it</title>
    <section id='sec:intellij'>
        <title>IntelliJ</title>
        <para>Gradle has been mainly developed with Idea IntelliJ and its very good Groovy plugin. Gradle's build script
            <footnote>
                <para>Gradle is built with Gradle
                </para>
            </footnote>
            has also been developed with the support of this IDE. IntelliJ allows you to define any filepattern to be
            interpreted as a Groovy script. In the case of Gradle you can define such a pattern for
            <filename>build.gradle</filename>
            and <filename>settings.gradle</filename>. This will already help very much. What is missing is the classpath
            to the Gradle binaries to offer content assistance for the Gradle classes. You might add the Gradle jar
            (which you can find in your distribution) to your project's classpath. It does not really belong there, but
            if you do this you have a fantastic IDE support for developing Gradle scripts. Of course if you use
            additional libraries for your build scripts they would further pollute your project classpath.
        </para>
        <para>We hope that in the future <filename>*.gradle</filename> files
            get special treatment by IntelliJ and you will be able to define a specific classpath for them.
        </para>
    </section>
    <section>
        <title>Eclipse</title>
        <para>There is a Groovy plugin for eclipse. We don't know in what state it is and how it would support Gradle.
            In the next edition of this user guide we can hopefully write more about this.
        </para>
    </section>
    <section id='sec:using_gradle_without_ide_support'>
        <title>Using Gradle without IDE support</title>
        <para>What we can do for you is to spare you typing things like
            <literal>throw new org.gradle.api.tasks.StopExecutionException()</literal>
            and just type
            <literal>throw new StopExecutionException()</literal>
            instead. We do this by automatically adding a set of import statements to the Gradle scripts before Gradle
            executes them. Listed below are the imports added to each script.
        </para>
        <figure>
            <title>gradle-imports</title>
            <programlisting><xi:include href='../../../../../subprojects/core/src/main/resources/org/gradle/configuration/default-imports.txt' parse='text'/></programlisting>
        </figure>
    </section>
</appendix>
