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.

Sign up for GitHub

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

Jump to bottom

Regression with Gradle 8.2-rc-2 #5695

Closed
marcphilipp opened this issue Jun 12, 2023 · 6 comments · Fixed by #5702
Closed

Regression with Gradle 8.2-rc-2 #5695

marcphilipp opened this issue Jun 12, 2023 · 6 comments · Fixed by #5702

Comments

@marcphilipp
Copy link
Contributor

After updating the JUnit build from Gradle 8.1 to 8.2-rc-2 (see draft PR), the produced manifests no longer include version numbers for imported packages which causes our verifyOSGi Resolve tasks to fail (Build Scan).

Full diff:

--- MANIFEST-8.1	2023-06-12 09:41:32
+++ MANIFEST-8.2	2023-06-12 09:41:32
@@ -1,7 +1,7 @@
 Manifest-Version: 1.0
 Build-Date: 2023-06-12
-Build-Revision: e41a174f53d543ecfee683cf854e61067d7bf900 
-Build-Time: 09:39:13.752+0200
+Build-Revision: 34d235eadd8ab0f318541bce13b6b2ab71d40a28 
+Build-Time: 09:33:40.345+0200
 Built-By: JUnit Team
 Bundle-ManifestVersion: 2
 Bundle-Name: JUnit Platform Suite Commons
@@ -15,12 +15,10 @@
 Implementation-Vendor: junit.org
 Implementation-Version: 1.10.0-SNAPSHOT
 Import-Package: org.apiguardian.api;resolution:=optional;version="[1.1
- ,2)",org.junit.platform.commons.util;version="[1.10,2)",org.junit.pla
- tform.engine;version="[1.10,2)",org.junit.platform.engine.discovery;v
- ersion="[1.10,2)",org.junit.platform.launcher;version="[1.10,2)",org.
- junit.platform.launcher.core;version="[1.10,2)",org.junit.platform.su
- ite.api;version="[1.10,2)",org.junit.platform.commons.logging;status=
- INTERNAL;version="[1.10,2)"
+ ,2)",org.junit.platform.commons.util,org.junit.platform.engine,org.ju
+ nit.platform.engine.discovery,org.junit.platform.launcher,org.junit.p
+ latform.launcher.core,org.junit.platform.suite.api,org.junit.platform
+ .commons.logging;status=INTERNAL
 Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.8))"
 Specification-Title: junit-platform-suite-commons
 Specification-Vendor: junit.org

Do you have any ideas why that would be?
@marcphilipp marcphilipp mentioned this issue Jun 12, 2023
Merged
@big-guy big-guy mentioned this issue Jun 12, 2023
Closed
@marcphilipp marcphilipp mentioned this issue Jun 15, 2023
Merged
@marcphilipp
Copy link
Contributor Author

marcphilipp commented Jun 15, 2023 •
edited
Loading

@tresat has written an analysis of the issue in junit-team/junit5#3351 (comment) and will submit a PR

marcphilipp pushed a commit to junit-team/junit5 that referenced this issue Jun 15, 2023
@tresat
Work around bndtools/bnd#5695 by configuring jar tasks eagerly (#3354)
287607c 
Eagerly configure Jar tasks to create the BundleTaskExtension prior to
the Gradle compileClasspath configuration becoming locked and
triggering it's beforeLocking callback to run. This allows the BND
extension to modify the LibraryElements attribute on that configuration
and request a variant with the "jar" value prior to Gradle
automatically modifying the attribute to request the "classes" value.
This ensures jars are present on the classpath for BND to use when
checked for exported classes to use when building the manifest. If it
only uses the classes directory for this task, it will not have access
to version information and will not write version info to the manifest
it is assembling for the current project, causing the verifyOSGi task
to fail.

Addresses issue bndtools/bnd#5695 and allows merging of #3351.
@pkriens
Copy link
Member

pkriens commented Jun 15, 2023

Thanks a lot for doing this. I would really appreciate the PR.

@bjhargrave time to add your thoughts?

@bjhargrave
Copy link
Member

Bnd does need to use the jar library elements since Bnd needs the built jars in the class path to (1) access the OSGi metadata in the jar, and (2) the complete contents of the jar since Bnd can assemble a jar quite differently than the contents of the compilation output directories.

@tresat
Copy link
Contributor

tresat commented Jun 15, 2023

Yes. We think the fix to BND will actually be pretty straightforward. I started work on an integration test in the BND project to demo this situation but haven't finished yet. Back to that tomorrow.

@tresat tresat mentioned this issue Jun 16, 2023
Closed
@bjhargrave bjhargrave linked a pull request Jun 30, 2023 that will close this issue
gradle: Use an ArtifactView for jar library elements selection #5702
Merged
@bjhargrave
Copy link
Member

I tested the fix in #5702 against the junit5 build (after reverting 287607c) and confirmed it fixes the issue.

@marcphilipp
Copy link
Contributor Author

Awesome, thank you!

TWiStErRob added a commit to TWiStErRob/mockito that referenced this issue Jul 4, 2023
@TWiStErRob
Downgrade to Gradle 8.1 to prevent triggering bndtools/bnd#5695
de0e384 
See https://docs.gradle.org/8.2/userguide/upgrading_version_8.html#deferred_or_avoided_configuration_of_some_tasks for more details.
TWiStErRob added a commit to TWiStErRob/mockito that referenced this issue Jul 4, 2023
@TWiStErRob
Revert "Downgrade to Gradle 8.1 to prevent triggering bndtools/bnd#5695"
0a56409 
This reverts commit de0e384.
@TWiStErRob TWiStErRob mentioned this issue Jul 4, 2023
Merged
8 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
4 participants
@tresat @pkriens @marcphilipp @bjhargrave