Gradle
  1. Gradle
  2. GRADLE-1696

Gradle 1.0-milestone-4 local cache structure changed cause the Arquillian test broken

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Resolution: Not A Bug
    • Affects Version/s: 1.0-milestone-4
    • Fix Version/s: None

      Description

      I'm using gradle to build the CDI project and use arquillian to run the unit test, in the arqullian test case, I have to include the jar from gradle cache, for example:
      the "org.jboss.seam:jboss-el:2.0.0.GA" is mapping to System.getProperty("user.home")/.gradle/cache/org.jboss.seam/jboss-el/jars/jboss-el-2.0.0.GA.jar,
      Now the file is in:
      System.getProperty("user.home")/.gradle/caches/artifacts/org.jboss.seam/jboss-el/aedb9ed72585ce82a68cb685d36dd090/jars/jboss-el-2.0.0.GA.jar

      How can I get the magic number(aedb9ed72585ce82a68cb685d36dd090) from my testcase?

        Activity

        Hide
        Graeme Rocher added a comment -

        The Grails team are also having problems with this as we have a distribution whereby we ship all dependencies inside the Grails zip so people can use Grails whilst offline:

        https://github.com/grails/grails-core/blob/master/gradle/assemble.gradle#L3

        This currently works by copying the Gradle cache into GRAILS_HOME/lib for all declared dependencies. This is currently broken with 1.0 milestone 4

        Is there a supported way to do what we need to do?

        Show
        Graeme Rocher added a comment - The Grails team are also having problems with this as we have a distribution whereby we ship all dependencies inside the Grails zip so people can use Grails whilst offline: https://github.com/grails/grails-core/blob/master/gradle/assemble.gradle#L3 This currently works by copying the Gradle cache into GRAILS_HOME/lib for all declared dependencies. This is currently broken with 1.0 milestone 4 Is there a supported way to do what we need to do?
        Hide
        Matt Stine added a comment -

        We're running into similar difficulties regarding the need to be able to work in "offline mode." We applied the following fix to get us there:

        repositories {
        if (rootProject.hasProperty('offline')) {
        add(new FileSystemResolver()) {
        name = 'gradleCache'

        addArtifactPattern("$

        {gradle.gradleUserHomeDir}/cache/${ResolverContainer.DEFAULT_CACHE_ARTIFACT_PATTERN}")

        addIvyPattern("${gradle.gradleUserHomeDir}

        /cache/$

        {ResolverContainer.DEFAULT_CACHE_IVY_PATTERN}

        ")
        }
        }
        else {
        repositories

        { mavenCentral() }


        }
        }

        In the meantime we've had to shift development back to milestone 3. Of course we'll need to deal with this at some point. As Graeme said, is there a new way around this in milestone 4?

        Show
        Matt Stine added a comment - We're running into similar difficulties regarding the need to be able to work in "offline mode." We applied the following fix to get us there: repositories { if (rootProject.hasProperty('offline')) { add(new FileSystemResolver()) { name = 'gradleCache' addArtifactPattern("$ {gradle.gradleUserHomeDir}/cache/${ResolverContainer.DEFAULT_CACHE_ARTIFACT_PATTERN}") addIvyPattern("${gradle.gradleUserHomeDir} /cache/$ {ResolverContainer.DEFAULT_CACHE_IVY_PATTERN} ") } } else { repositories { mavenCentral() } } } In the meantime we've had to shift development back to milestone 3. Of course we'll need to deal with this at some point. As Graeme said, is there a new way around this in milestone 4?
        Hide
        Daz DeBoer added a comment -

        Hi guys
        A lot has changed in caching and dependency resolution since Milestone 4. We still consider the cache structure to be 'internal' and not part of the public API of Gradle. That said, we'd like to hear about your genuine use cases that require direct access to the cache. I'd like to create new issues for these use cases, and close this issue.

        Wang: We do have a DSL for accessing the cached artifact (ResolvedConfiguration). It seems like your issue is that this isn't available from inside your tests? What sort of API are you looking for?

        Matt: I assume you're not still stuck on Milestone 3? A lot has changed since then, and Milestone 8 has a '--offline' flag that will hopefully remove the need for you to spin your own.

        Graeme: I know that Luke Daley has been working on the Grails build, and will be updating it to use Milestone 8 soon. I assume this isn't a blocker for you.

        All: One of our plans is to make available a 'project-specific' view of the cache, perhaps under the PROJECT_ROOT/.gradle directory. This would present the dependencies for a project in a standard directory layout, and would be considered part of the public API for Gradle. I feel this would solve the problems eluded to by Wang and Graeme, but not Matt's, which is solved by the new --offline switch.

        Comments?

        Show
        Daz DeBoer added a comment - Hi guys A lot has changed in caching and dependency resolution since Milestone 4. We still consider the cache structure to be 'internal' and not part of the public API of Gradle. That said, we'd like to hear about your genuine use cases that require direct access to the cache. I'd like to create new issues for these use cases, and close this issue. Wang: We do have a DSL for accessing the cached artifact (ResolvedConfiguration). It seems like your issue is that this isn't available from inside your tests? What sort of API are you looking for? Matt: I assume you're not still stuck on Milestone 3? A lot has changed since then, and Milestone 8 has a '--offline' flag that will hopefully remove the need for you to spin your own. Graeme: I know that Luke Daley has been working on the Grails build, and will be updating it to use Milestone 8 soon. I assume this isn't a blocker for you. All: One of our plans is to make available a 'project-specific' view of the cache, perhaps under the PROJECT_ROOT/.gradle directory. This would present the dependencies for a project in a standard directory layout, and would be considered part of the public API for Gradle. I feel this would solve the problems eluded to by Wang and Graeme, but not Matt's, which is solved by the new --offline switch. Comments?
        Hide
        Daz DeBoer added a comment -

        I've now added GRADLE-2094, and I'd like to close this issue if you guys are in agreement.

        Show
        Daz DeBoer added a comment - I've now added GRADLE-2094 , and I'd like to close this issue if you guys are in agreement.
        Hide
        Wang Liyu added a comment -

        I found a way to work around this, put the artifacts ID:filename map into system Properties, and in the test case, read from the system properties:

        configurations.default.resolvedConfiguration.resolvedArtifacts.each

        {ModuleVersionIdentifier module=it.moduleVersion.id; systemProperties[module.group+":"+module.name+":"+module.version]=it.file;}

        I guess that's the only way to do it now. this ticket can be closed.

        Show
        Wang Liyu added a comment - I found a way to work around this, put the artifacts ID:filename map into system Properties, and in the test case, read from the system properties: configurations.default.resolvedConfiguration.resolvedArtifacts.each {ModuleVersionIdentifier module=it.moduleVersion.id; systemProperties[module.group+":"+module.name+":"+module.version]=it.file;} I guess that's the only way to do it now. this ticket can be closed.

          People

          • Assignee:
            Daz DeBoer
            Reporter:
            Wang Liyu
          • Votes:
            2 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development