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

Should assemble depend on package? #7

Open
sergej-koscejev opened this issue Jan 25, 2022 · 3 comments
Open

Should assemble depend on package? #7

sergej-koscejev opened this issue Jan 25, 2022 · 3 comments

Comments

@sergej-koscejev
Copy link
Member

In Gradle Java plugin assemble task includes jar, see https://docs.gradle.org/current/userguide/java_plugin.html

Should this plugin do the same, so that ./gradlew assemble means "build and package the output but skip tests"?

@coolya
Copy link
Contributor

coolya commented Jan 25, 2022

I think this is a good idea. For people coming from gradle with a java/kotlin background it would be the least surprising behaviour.

I like this type of behaviour when writing kotlin code for cases where I want to skip the tests but still produce a usable artefact. If I want to include tests I would run build instead of assemble.

@sergej-koscejev
Copy link
Member Author

To clarify, currently assemble depends on assembleMps which calls the assemble target in MPS-generated build scripts. So ./gradlew assemble builds the project and produces jars in build/artifacts. It just doesn't produce the final zip for uploading to Maven. So the question is whether assemble should mean what it means in MPS or what it means in Gradle Java.

@coolya
Copy link
Contributor

coolya commented Feb 21, 2022

I think in MPS terms assemble with the plugin isn't the same as with the vanilla MPS world. Here assemble also includes generate with isn't a dependency in the ant scripts from MPS. In the MPS world assemble would only assemble what is already generated without further input from the user. I think it's safe to deviate from the MPS terminology here and be consistent with how the Java with gradle does.

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

No branches or pull requests

2 participants