Local publication requires "remote" JAR signing #1173
Comments
|
Workaround in: #1171 (comment) |
|
This is strange. When I run that task, it skips the signing tasks I think: Are you on the latest master branch? If so, can you run |
No, I checked out 3c2db2d. I checked out master (abbfdea), and now I am getting a different error: Note I executed this beforehand:
I get: |
|
What is your JDK version? The master branch requires JDK 11. |
|
Ah, 18.0.2. I switched to 11.0.17. But, still getting the same error. |
|
WALA master is currently at 4171cd8. Maybe try that? What is your operating system? |
|
Sorry for the delay. 4171cd8 doesn't seem to be building. On 1fa41ad, it works. |
|
|
Since it's working in later versions, I'll close as "cannot be reproduced." Please feel free to open if necessary or desired. |
|
Just got this error again when I checked out the |
|
Ah that must be it! I think signing will be required if the version does not end in |
|
Interesting. I was under the impression that you would only want snapshot dependencies if there is some feature that you need that is currently under development. This is not the case here; it would seem that all the needed features have been released. See this article. |
|
And, I can't get the test JARs from Maven Central as they are not published there. |
|
I forgot about the test fixtures jars, which do not get released; that is an issue. @liblit do you know how hard it would be to disable signing whenever artifacts are being published to the local repo (as opposed to a remote one)? |
|
My impression from the code is that local repository artifacts are already left unsigned: WALA/buildSrc/src/main/kotlin/com/ibm/wala/gradle/publishing.gradle.kts Lines 174 to 185 in 2dde18a There's also this, immediately after: WALA/buildSrc/src/main/kotlin/com/ibm/wala/gradle/publishing.gradle.kts Lines 187 to 188 in 2dde18a But that should only affect signing tasks for installations into the remote repository, if the earlier comment about not signing local installations is accurate. Indeed, if I show the names of all So I'm not seeing any tasks that should be trying to sign local jars. |
|
@liblit did you try it when checking out a released version tag, e.g., |
|
OK, I checked out WALA/buildSrc/src/main/groovy/gradle-mvn-push.gradle Lines 148 to 166 in 8d53585 And here's me not seeing any signing tasks for a local repository: That being said, I admit that I have not been paying close attention to this issue so far, preferring to let @khatchad work through whatever problems he was seeing in his own stream-of-consciousness way. Going back to the original report, yes, I can at least confirm that
So that at least demonstrates that my interpretation of the signing configuration as offered here is incorrect, and likewise that the following comment is incorrect: Now that I have a clear understanding of the problem, and a clear demonstration that my own prior understanding was wrong, I'll dive deeper. It is surprising to me that |
|
Thanks a lot, @liblit! In the meantime @khatchad a workaround is to just set things up so you can sign the artifacts. For local publication it won't matter who signs them I assume. Instructions for setup are here: https://github.com/wala/WALA/wiki/Creating-Releases-and-Snapshots#initial-setup you'll have to set up a GPG key and also do the Gradle configuration. |
|
After further investigation, I recommend that we do not change the WALA build infrastructure to correct this issue. Instead, when installing locally, @khatchad (or anyone else) should use the More details follow. Basic Concepts: Publications and RepositoriesThink of a Gradle "publication" as a set of build artifacts that could potentially be installed or uploaded somewhere. WALA defines two publications:
By contrast, a Gradle "repository" is a local or remote place where a publication can be sent. WALA defines three repositories:
Orthogonality of Publications and RepositoriesPublications and repositories are orthogonal. Any publication can potentially be uploaded or installed into any repository. Our intent is to only install the Thus, for every publication and repository pair, Gradle creates a task that publishes that publication to that repository. For WALA, this gives us:
Gradle also creates several tasks that perform multiple publishing operations by depending on various subsets of the above tasks:
Filtering Down to the Desired SubsetGradle's automatic creation of all six permutations is over-eager, since we really would never want to publish the
Unfortunately, we cannot tell Gradle to avoid creating all six tasks, even through half of them make no sense for us. Instead, what we do is to selectively disable tasks that would put the wrong publications into the wrong repositories: WALA/buildSrc/src/main/kotlin/com/ibm/wala/gradle/publishing.gradle.kts Lines 195 to 203 in 2dde18a The good news is that these The bad news is that disabling a task using Thus, when you direct Gradle to What Can We Do About It?Generally speaking, Gradle is better at adding items to a build rather than removing items from a build. We cannot delete the undesired publication tasks, such as Thus, my conclusion is that we should simply accept the existing tasks as doing exactly what they say on the tin. In particular, Instead, use a different task that does what you want. Specifically, |
|
Amazing explanation @liblit thanks! I've added some notes to the wiki here: This brings up another question in my mind: @liblit was there a reason we don't publish test fixture artifacts to Maven Central? It seems a bit weird in that it is "internal" test code, but it seems there is now at least one case where it would be useful. Given all the WALA code is pretty stable, I'm not sure I can think of a good reason not to publish test fixture artifacts to Maven Central, unless it is technically difficult. |
|
@khatchad please confirm that the discussion above resolves these issues for you. |
|
@msridhar wrote:
Nice! Thank you for distilling my long-winded explanation down to the critical pieces that our users may need to know.
Nothing I can think of, especially given that some of those artifacts are actually required externally. I'll revise our publication sets to include test fixtures everywhere. |
Confirmed. |
Correct. |
Per wala/WALA#1173 (comment), using the `publishLocalPublicationToMavenLocal` task instead of the more obvious `publishToMavenLocal` task.
Per wala/WALA#1173 (comment), usinmg the `publishLocalPublicationToMavenLocal` task instead of the more obvious `publishToMavenLocal` task.
* Some work on Maven infrastructure. Based on https://github.com/Anemone95/wala-python/blob/709a3047eab5ed0c3a7889f7478566ae0dd9ea7a/python-frontend/pom.xml * Add gitignore. * Upgrade to WALA 1.5.8. Based on maldil@705e59f * Remove version. We're getting it from the parent pom. * Fix version. * Ignore Vim intermediate/temporary files. From https://github.com/github/gitignore/blob/4488915eec0b3a45b5c63ead28f286819c0917de/Global/Vim.gitignore * Start contribution document. * Metadat updates. * Ignore gradle output. * Remove the test scope. It would seem that the test files are in the normal source directories. * Update JUnit. * Add Eclipse Gradle metadata. Not sure if it's completely necessary. * Modify building instructions. * More Eclipse Gradle metadata. * Ignore maven intermediate output. * Add workaround for wala/WALA#1173. * Modernize the Travis CI build. * Need more history. * Remove deploy section. The token isn't working. * Add slack notification. * Add gradle caches. * Make it more readable. * Revert "Make it more readable." This reverts commit 5953caf. * Remove the WALA build step. I think it is included in the deployment. * Remove sudo key. * Remove space. * Remove unnecessary verison. * Decentralize build. Different projects have different build and resource directories. * Update Eclipse metadata. * Add missing intraproject module dependency. * Remove obselete Gradle metadata? Buildship seemed to do this automatically. * For com.ibm.wala.cast.python.test, "source" is both a source and test directory? * Exclude the server test for now. It's timing out. * Increase antlr version. * Ignore test in the source code instead. This seems to be the project standard. * Add test reporting. * Revert "Add slack notification." This reverts commit 9355100. It doesn't seem to work. * Remove tab character. * Make it compile in Eclipse. Added an m2e property not to set the source folder as a test source. The problem is that Eclipse will not export test source packages, but this package is *both* a test source and normal source. * Switch to mainline IDE. * Update README.md. * Fix relative link. * Add anchor. * Enhance anchor. * Upgrade to WALA v1.5.9. * Using publishLocalPublicationToMavenLocal in CI. Per wala/WALA#1173 (comment), using the `publishLocalPublicationToMavenLocal` task instead of the more obvious `publishToMavenLocal` task. * Use publishLocalPublicationToMavenLocal in docs. Per wala/WALA#1173 (comment), usinmg the `publishLocalPublicationToMavenLocal` task instead of the more obvious `publishToMavenLocal` task.
Installing WALA to the local maven repo fails on at least on 3c2db2d:
Originally posted by @khatchad in #1171 (comment)
The text was updated successfully, but these errors were encountered: