-
Notifications
You must be signed in to change notification settings - Fork 33
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
Gradle catalog + platform #268
Conversation
Just pushed a working sketch of plugins to enforce a pure declarative Gradle build script plugins under It's based on the current wip of Gradle |
so, together with @jjohannes, we clean up the project the best possible
the only build directory isn't possible to move is I tested |
.gitignore
Outdated
@@ -1,3 +1,4 @@ | |||
/.project | |||
/.settings/ | |||
/target/ | |||
/gradle-scijava/.gradle |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@elect86 I would add /.idea/
here and remove all the .idea
files this PR adds right now.
pom.xml
Outdated
<execution> | ||
<id>attach-gradle-catalog</id> | ||
<!-- Check if correct--> | ||
<phase>package</phase> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it works without adding the <phase>
here at all. The default should be fine. See similar setup here:
https://github.com/google/guava/blob/master/guava/pom.xml#L205
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, I can confirm it works
@elect86 Thank you for continuing to work on this! And @jjohannes thank you for reviewing! Here is the current error happening on CI:
With 5a514ac I tried to be very explicit about the intended working directory, but even then the same error persists. So more investigation is needed. |
I have no idea why the CI is so problematic... |
with an |
SO post |
@elect86 and I spoke earlier today about the issue maybe being the While it does seem like quite a coincidence that the Gradle-specific logic is triggered multiple times, and there are three "extra" invocations of
which gets printed after all three of the No, the issue is that the Gradle platform/catalog logic happens again as part of the integration testing, a.k.a. the "mega melt": a subsequent step to ensure that all component versions work together as advertised. To reproduce the problem locally, you can invoke Specifically, the script performs the following (slightly simplified) commands to set up a temporary doctored pom-scijava parent for use with local testing:
It seems Maven sets the CWD and To fix, I changed the Once I fixed that initial issue, there still remained another problem, however. The pom-scijava POM is intended as the parent POM for downstream components. As currently written, any project extending this updated version of pom-scijava inherits the exec-maven-plugin execution that tries to launch gradle. We do not want this; the gradle execution is supposed to occur only for the pom-scijava build itself, not builds of downstream components that extend it. I implemented a workaround with 9cd9000, which wraps the gradle catalog+platform generation into a profile that gets activated only when a |
Awesome, thanks for taking care of this So now, can it be merged? Can we test it with a snapshot publication? |
…ts get added alongside the main publication
added conditional catalog import in platform, when starting the catalog hasnt been generated yet and the configuration crashes
…radle declarative style
For some reason, the CI attempts to run ./gradlew from the directory target/gradle-scijava, rather than gradle-scijava. Let's prepend the ${basedir} to be more explicit about what we want.
Signed-off-by: Curtis Rueden <[email protected]>
We do not need to perform the entire Maven lifecycle just to install the doctored 999-mega-melt version of the pom-scijava parent into the local repository cache. We can just invoke the install:install goal directly. Not only does this speed up the mega-melt slightly (e.g. no enforcer checks), it also avoids an issue whereby the Gradle platform+catalog build would fail due to being in the wrong working/base directory.
Let's leave it to consumers to decide which metadata model is "richer" and which one they "should prefer". They know their own use cases.
We don't want it being triggered in downstream projects that extend pom-scijava -- only in the pom-scijava build itself.
thanks dear |
Gradle Catalog and Platform properly generated and the corresponding artifacts get added alongside the main publication
We'd still need to verify whether this version does matter or less, we'll see with a snapshot publications maybe?
Another cool thing Gradle Platform can do is aligning to boms as well, like here
But we need to coordinate this, there are other boms which may be interesting, such as
jakarta.jakartaee-bom
and tons of google ones, which is a mess for someone like me which is not familiar..