Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Feature Request - exportPath dynamic for each build variant. #814

Open
4 of 10 tasks
apkelly opened this issue Nov 23, 2022 · 3 comments
Open
4 of 10 tasks

Feature Request - exportPath dynamic for each build variant. #814

apkelly opened this issue Nov 23, 2022 · 3 comments
Labels

Comments

@apkelly
Copy link

apkelly commented Nov 23, 2022

About this issue

  • Briefly describe the issue
    I currently use a command like this to generate my aboutlicense.json file

./gradlew app:exportLibraryDefinitions -PaboutLibraries.exportPath=src/main/assets/ -PaboutLibraries.exportVariant=dimensionRelease

Where dimension is different components of my build variant. Different variants will possibly have different included libraries e.g. a "pro" version of my app might include an extra library.

When building the different versions of my app, free/pro etc, I'd like the output json file placed in the correct src/free/assets or src/pro/assets folders.

It'd be great if exportPath could use the configuration of exportVariant to know where to place the file, perhaps making the path relative to dimension. e.g. -PaboutLibraries.exportPath=/assets/ PaboutLibraries.exportVariant=proRelease would place the file in src/pro/assets

Details

  •  Used library version - 10.5.1
  •  Used support library version
  •  Used gradle build tools version - 7.3.3
  •  Used tooling / Android Studio version - Android Studio Flamingo, Canary 8
  •  Other used libraries, potential conflicting libraries - Jetpack Compose 1.3

Checklist

@mikepenz
Copy link
Owner

@apkelly thank you for describing your usecase.

I may need some more information to better understand the benefit.

As you describe, you are passing the exportPath and exportVariant already. E.g. you will probably have multiple such export steps for the different variants.

What would the major benefit of the exportPath internally identifying the variant specific folder? As I assume this is only gonna be defined ones and then most likely stay for the most part like that?


Theoretically the android integration would do something like this: https://github.com/mikepenz/AboutLibraries/blob/develop/plugin-build/plugin/src/main/kotlin/com/mikepenz/aboutlibraries/plugin/AboutLibrariesPluginAndroidExtension.kt#L43

But personally I also prefer the "manual" approach, with the file being checked in as it allows for much more control of what's getting changed.

@apkelly
Copy link
Author

apkelly commented Nov 24, 2022

The app I work on is branded for different clients, and also runs on different vendor hardware (each with their own SDKs)....its not an app for mobile phones, so we have lots of different "release" build variants.

I like the idea of manually running the export command, but I wanted to see if there was a way to cut down on the configuration, so that exportPath could be defined in my aboutlibraries section of my gradle file, and then depending on the exportVariant being created, the json file would be deposited in the correct /src/xxx/assets folder.

@mikepenz
Copy link
Owner

Oh I see. So it's not an Android project, as such the automatic registration for android build tasks won't work.

Not sure how much can be reproduced of that as part of the sample app. But it may be worth exploring to add some of these variants to the app-desktop sample we have, and then see if something similar like we do for Android (https://github.com/mikepenz/AboutLibraries/blob/develop/plugin-build/plugin/src/main/kotlin/com/mikepenz/aboutlibraries/plugin/AboutLibrariesPluginAndroidExtension.kt) would be possible for those desktop builds. 🤔

One thing I am not sure on is, if Gradle will have the appropriate folder per variant. I'd prefer not to base the folder path definition on assumptions which may break for other people.

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

No branches or pull requests

3 participants
@mikepenz @apkelly and others