Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Add support + test for dynamic extensions amps #4

Merged
merged 5 commits into from
Oct 25, 2018
Merged

Add support + test for dynamic extensions amps #4

merged 5 commits into from
Oct 25, 2018

Conversation

rschev
Copy link
Member

@rschev rschev commented Oct 25, 2018

Basic support for making a dynamic extensions amp by leveraging the existing dynamic extensions gradle plugin and just embedding the resulting jar in the amp. The syntax for this in the build.gradle is:

amp {
    de {
        from project.jar
    }
}

rschev and others added 4 commits October 25, 2018 11:40
- Private accessor to CopySpec, users should not be able to mess with it
directly
- Don't recreate the CopySpec each time in the getter, when calling de()
multiple times we want to reconfigure the existing CopySpec
- Remove returns from public de() closure
- Rename getDeCopySpec() to getDe() for better grooby propertyaccess
Also involves changing the configuration in build.gradle to indicate
that your project builds a DE amp. This is now done via
ampConfig { dynamicExtensionAmp = true }.
Copy link
Member Author

@rschev rschev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed your mind about adding a new CopySpec in the getter?

@vierbergenlars vierbergenlars merged commit 589969a into xenit-eu:master Oct 25, 2018
@vierbergenlars
Copy link
Member

@rschev Yes, because when you change more settings of the copyspec, you don't want to change previous copyspecs.

Example:

amp {
  de {
    from configurations.runtime
  }
  de {
    from project.jar
    rename { "project-module.jar" }
  }
}

If it was the same copyspec, this would rename all jars from configurations.runtime to project-module.jar, which is quite unexpected behavior.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants