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

[Question]: I think it's better to move the samples to root project? #573

Open
1 task done
MohamedRejeb opened this issue Apr 27, 2024 · 7 comments
Open
1 task done
Assignees
Labels
question Further information is requested

Comments

@MohamedRejeb
Copy link
Contributor

General info

What is your question?

HI,
I think it's better to move samples to the root project, it's easier for testing and debugging. You can directly run the sample with the latest changes without the need to publish the library. Also, when you clone the project, the IDE will only recognize the root project and you need to open the samples as separate projects.

Relevant log output (optional)

No response

@MohamedRejeb MohamedRejeb added the question Further information is requested label Apr 27, 2024
@jan-tennert
Copy link
Collaborator

Yea, I think that should be fine. Originally there were some problems with Compose in the same class path, but that has been fixed a while ago.

@jan-tennert jan-tennert self-assigned this Apr 29, 2024
@jan-tennert
Copy link
Collaborator

Handling this currently, unsure if this as easy as it sounds. Each sample has their own modules & settings, which makes it hard to include them all without a lot of boilerplate. Looking at the KotlinX dependencies, most of them have samples with their own gradle project.

@jan-tennert
Copy link
Collaborator

@MohamedRejeb any idea on this?

@MohamedRejeb
Copy link
Contributor Author

I think that the library needs convention plugins, it will make this much easier.
The build.gradle files will look like this
https://github.com/MohamedRejeb/Calf/blob/main/calf-file-picker/build.gradle.kts

I can work on this if it makes sense to you.
For modules with different targets we can have different function to setup targets depending on the case.

@jan-tennert
Copy link
Collaborator

jan-tennert commented Jun 24, 2024

If we mean the same thing, we already have some methods to make the configuration easier:
https://github.com/supabase-community/supabase-kt/blob/master/Storage/build.gradle.kts
But yea, we can probably continue improving on these, if we include all samples. I'm wondering, how should we handle the project build (when changes get merged into master)? We could try to build & compile all samples in the GH actions, but that is probably going to take ages since building the root project already takes 40 min. Same with the PR actions, but they currently only include tests not full project builds.

@jan-tennert
Copy link
Collaborator

jan-tennert commented Jun 24, 2024

root project already takes 40 min.

Probably a bit less if the Gradle files are cached, but its still ~25-30min.

@MohamedRejeb
Copy link
Contributor Author

We can conditionally exclude samples from build when needed. Something like this should work:

if (System.getProperty("LibrariesOnly") != "true") {
    include(":sample:kmp")
}
./gradlew -PLibrariesOnly=true build

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

No branches or pull requests

2 participants