Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Generating packages from dynamic content fails with NO-SOURCE

See original GitHub issue

I’m trying to feed the outputs from a gradle task into packageCompose but I can’t seem to get it working.

The first time I execute packageCompose, it exits with NO-SOURCE even though I have added the task that generates the jcr_root folder as a dependency. It seems gradle decides during the configuration phase (when the folder given as contentDir is still empty or doesn’t exist) not to execute packageCompose. The second execution works (because contentDir will have been filled by that point).

To me it seems like the plugin isn’t honoring best practices as described in https://docs.gradle.org/current/userguide/custom_plugins.html#sec:working_with_files_in_custom_tasks_and_plugins to evaluate file paths lazily instead accepting only File instances (like contentDir in its current form).

Relevant build.gradle.kts:

tasks {
    register("generateContent") {
        doLast {
            // In actuality a more elaborate way of generating content
            mkdir("$buildDir/generatedContent/jcr_root")
            file("$buildDir/generatedContent/jcr_root/some-file.txt").createNewFile()
        }
    }
}

aem {
    tasks {
        packageCompose {
            dependsOn(named("generateContent"))
            contentDir = file("$buildDir/generatedContent")
        }
    }
}

Additionally I have noticed that I need to execute the task twice (after the initial NO-SOURCE run) for it to be up-to-date because the added files in META-INF that were generated by packageCompose count as changed inputs. This seems optimizable.

Issue Analytics

State:
Created 4 years ago
Comments:7 (5 by maintainers)

Top GitHub Comments

1reaction

sabberwormcommented, Nov 5, 2019

The from worked just fine, thanks. Not sure why I didn’t think of it.

The problem with the second invocation not being up-to-date remains, though:

> Task :packageCompose
Caching disabled for task ':packageCompose' because:
  Build cache is disabled
Task ':packageCompose' is not up-to-date because:
  Input property 'rootSpec$1$1' file /PROJECT/build/aem/packageCompose/metadata/META-INF/MANIFEST.MF has been added.
  Input property 'rootSpec$1$1' file /PROJECT/build/aem/packageCompose/metadata/META-INF/vault has been added.
  Input property 'rootSpec$1$1' file /PROJECT/build/aem/packageCompose/metadata/META-INF/vault/config.xml has been added.
Copying package metadata files from path: '/PROJECT/src/main/content/META-INF'
Providing package metadata files in directory: '/PROJECT/build/aem/packageCompose/metadata/META-INF
Reflections took 13 ms to scan 1 urls, producing 8 keys and 8 values 
Considering original package Vault filters specified in file: '/PROJECT/build/aem/packageCompose/metadata/META-INF/vault/roots.xml'
ZIP file created: /PROJECT/build/aem/packageCompose/aem.portal.ui.frontend-2019.12.0-SNAPSHOT.zip

Only the third invocation reports the task as UP-TO-DATE.

0reactions

pun-kycommented, Nov 12, 2019

thx @sabberworm

Additionally I have noticed that I need to execute the task twice (after the initial NO-SOURCE run) for it to be up-to-date because the added files in META-INF that were generated by packageCompose count as changed inputs. This seems optimizable.

https://github.com/Cognifide/gradle-aem-plugin/issues/500 to be fixed