Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
GRADLE-2079 use jar url in javadoc attribute - add fromJarURL() to FileReferenceFactory. - add getJarURL() to FileReference. - replaced FileReference.getPath references on javadoc attribute by FileReference.getJarURL. - removed jar urls with "in-jar" paths in test .classpath files as gradle doesn't the then generation of them.

    • -1
    • +1
    ./m3/ToolingApiHonorsProjectCustomizationsIntegrationTest.groovy
  1. … 12 more files in changeset.
- Added ClasspathSource, to allow a ClassLoader to make its classpath available via ClasspathUtil.getClasspath() without making it parent(s) visible. - Fixed broken int tests. - Removed the 'observable' bit from ObservableUrlClassLoader and renamed it to MutableURLClassLoader.

    • -1
    • +1
    ./fixture/ToolingApiCompatibilitySuiteRunner.groovy
  1. … 18 more files in changeset.
GRADLE-2080 Introduced ModelConfigurationListener, which is used to fire an event after all configuration is done. Changed the tooling API to use this event to trigger when to build its model.

    • -0
    • +45
    ./m8/ToolingApiEclipseModelIntegrationTest.groovy
  1. … 5 more files in changeset.
Fixed the problem with one of the tests that sneaked in when improving the java home validation.

    • -2
    • +4
    ./m8/JavaConfigurabilityIntegrationTest.groovy
Fixed the problem with slf4j static configuration in the tooling api provider...

Now we configure the static slf4j logging for tooling api provider only once per provider implementation (every provider implementation lives in safe environment - e.g. separate classloader). This has limitations, e.g. once the logging level has been set, you cannot change it for the same provider implementation (DefaultConnection). However, I don't think this is a big deal because provider api is pretty thin (not much logging). The internal verboseLogging property is still used by our tests and might be used by clients for troubleshooting. We still can change log levels for the build execution - however at the moment we don't offer log level configurable in the tooling api.

-rationalized some code around embeddable logging

-improved the related coverage

    • -0
    • +4
    ./m8/ConcurrentToolingApiIntegrationTest.groovy
    • -111
    • +0
    ./m8/LoggingIntegrationTest.groovy
    • -0
    • +133
    ./m8/ToolingApiLoggingIntegrationTest.groovy
  1. … 12 more files in changeset.
Added more integ coverage related to logging in the tooling api. Necessary before refactorings related to logging / slf4j global configuration.

    • -4
    • +14
    ./m8/ConcurrentToolingApiIntegrationTest.groovy
    • -0
    • +111
    ./m8/LoggingIntegrationTest.groovy
  1. … 1 more file in changeset.
Minor fix to the integ test (made sure the assertion runs)

    • -1
    • +4
    ./m8/GradlePropertiesIntegrationTest.groovy
More validation and accurracy to the javaHome setting for the daemon...

Basically, when the client configures the daemon's java home to bad location we will fail quickly and eagerly with a proper exception message. Previous behavior was "daemon timeout error" because the ant-based java executable locator fell back to PATH if java home was invalid *plus* daemon compatibility checks prevented connecting the daemon stared from PATH java (java home mismatch).

    • -14
    • +13
    ./m8/JavaConfigurabilityIntegrationTest.groovy
    • -4
    • +8
    ./m8/StrictLongRunningOperationIntegrationTest.groovy
  1. … 11 more files in changeset.
Added simple validation for javaHome tooling api configurability

    • -3
    • +16
    ./m8/JavaConfigurabilityIntegrationTest.groovy
    • -2
    • +4
    ./m8/StrictLongRunningOperationIntegrationTest.groovy
  1. … 2 more files in changeset.
Enabled first integ test for invalid jvm args passed via the tooling api

    • -6
    • +14
    ./m8/JavaConfigurabilityIntegrationTest.groovy
Daemon honors java home configuration (also for tooling api)...

On the server side I simply stop replacing the java.home property. It feels awkward anyway as we have daemon per java home. Now we can honor the java home configuration that gets applied when daemon starts (by looking for the correct java executable). This change needs a peer review. Added some fixes to the integration tests / unignored them.

    • -0
    • +2
    ./m8/BuildEnvironmentModelIntegrationTest.groovy
    • -2
    • +5
    ./m8/GradlePropertiesIntegrationTest.groovy
    • -21
    • +5
    ./m8/JavaConfigurabilityIntegrationTest.groovy
  1. … 2 more files in changeset.
Final fix to the integ test

    • -1
    • +3
    ./m8/JavaConfigurabilityIntegrationTest.groovy
Some tooling api fixes/investigation related to the java home configurability

    • -1
    • +1
    ./m8/GradlePropertiesIntegrationTest.groovy
    • -1
    • +17
    ./m8/JavaConfigurabilityIntegrationTest.groovy
  1. … 1 more file in changeset.
Added support for java home supplied via gradle.properties...

Added relevant coverage using the AvailableJavaHomes. Moved/added related tooling api coverate to a separate test case.

    • -0
    • +64
    ./m8/GradlePropertiesIntegrationTest.groovy
    • -1
    • +19
    ./m8/JavaConfigurabilityIntegrationTest.groovy
  1. … 3 more files in changeset.
Added proper tooling api coverage for custom java home using sweet AvailableJavaHomes

    • -0
    • +21
    ./m8/JavaConfigurabilityIntegrationTest.groovy
Adding some examples/docs for the new tooling api configurability. I'll also reference them from the release notes.

    • -1
    • +8
    ./AutoTestedSamplesToolingApiTest.groovy
  1. … 2 more files in changeset.
Added more coverage to the tooling api related to jvm arguments. Tweaked the docs a bit.

    • -4
    • +5
    ./m8/BuildEnvironmentModelIntegrationTest.groovy
    • -0
    • +19
    ./m8/JavaConfigurabilityIntegrationTest.groovy
  1. … 1 more file in changeset.
Minor refactoring before tackling GRADLE-1799 (no decent feedback when daemon fails to start)...

I'm not starting to work on it just now but I wanted to document some of the code investigation I did. Reworked the loop a little bit because it didn't make sense to ask for the connection immediately after starting the daemon (it surely hasn't started yet). Fixed the @Ignore import.

    • -4
    • +4
    ./m8/JavaConfigurabilityIntegrationTest.groovy
  1. … 1 more file in changeset.
Fixed compilation issue related to misue of spock labels.

    • -4
    • +2
    ./m8/JavaConfigurabilityIntegrationTest.groovy
Added yet ignored tests that need to be implemented soonish.

    • -0
    • +30
    ./m8/JavaConfigurabilityIntegrationTest.groovy
Added explicit coverage for tooling api config taking precedence over gradle.properties

    • -0
    • +20
    ./m8/JavaConfigurabilityIntegrationTest.groovy
Fixed a minor problem in the test.

    • -2
    • +2
    ./m8/JavaConfigurabilityIntegrationTest.groovy
Improving the tooling api coverage for concurrency.

The test that was exercising the concurrent scenario with different target gradle versions now truly uses the 'previous' version, instead of hardcoded M7. Introduced ReleasedVersions type that holds that information (this can be improved further). Unignored the concurrent test because the reason for failure we a red herring (I think).

    • -7
    • +11
    ./m8/ConcurrentToolingApiIntegrationTest.groovy
  1. … 2 more files in changeset.
Enabled the smoke test of Tooling API samples from the javadoc...

It tries to compile the java snippets using the java 6 compiler api. I'm using this api reflectively to avoid compilation issues on java5. The test is configured to run only when the environment is compatible with java6. It's a first iteration, hopefully this test improves down the road.

    • -3
    • +40
    ./AutoTestedSamplesToolingApiTest.groovy
Ignored one test until we get a solution. It's a new concurrency issue exposed by running multiple different target versions of gradle concurrently with the tooling api. We couldn't run this test before releasing M7.

    • -0
    • +3
    ./m8/ConcurrentToolingApiIntegrationTest.groovy
Removed a TODO, there's little point in separating those tests.

    • -2
    • +0
    ./m8/ConcurrentToolingApiIntegrationTest.groovy
Made sure current consumer can read gradle version from M7. Tweaked the error messages a bit.

    • -1
    • +1
    ./m8/VersionOnlyBuildEnvironmentIntegrationTest.groovy
  1. … 2 more files in changeset.
Unignored a test that can now be ran after releasing M7

    • -3
    • +0
    ./m8/ConcurrentToolingApiIntegrationTest.groovy
Removed small thingy used for debugging

    • -2
    • +4
    ./m8/StrictLongRunningOperationIntegrationTest.groovy
Added strict validation for remaining LongRunningOperation configuration options.

    • -7
    • +28
    ./m8/StrictLongRunningOperationIntegrationTest.groovy
  1. … 3 more files in changeset.