bndtools / bnd

Bnd/Bndtools. Tooling to build OSGi bundles including Eclipse, Maven, and Gradle plugins.
https://bndtools.org
Other
527 stars 305 forks source link

support ability for gradle tasks to infer `-runee` #4142

Closed rotty3000 closed 3 years ago

rotty3000 commented 4 years ago

The bnd-*-maven-plugins have this support and it makes testing simpler by allowing the outer build to switch it's Java version whereby that information trickles down into the plugins.

It would be great if gradle tasks supported the same.

rotty3000 commented 4 years ago

perhaps this is only intersting to the resolve task (unlike in bnd-*-maven-plugins where several of those could resolve.)

rotty3000 commented 4 years ago

actually, any task that accepts a bndrun should be interested.

bjhargrave commented 4 years ago

I am not sure what inferring -runee means. Shouldn't Bnd always just use the current java if no -runee is specified? Why should the drivers (gradle, maven, eclipse) have to take special care?

rotty3000 commented 4 years ago

the fallback would certainly be current java. But since drivers have these source/target configurations one might need to consider those. in maven we consider this, and then use current java as fallback.

rotty3000 commented 4 years ago

See https://github.com/bndtools/bnd/blob/master/biz.aQute.bnd.maven/src/aQute/bnd/maven/lib/resolve/BndrunContainer.java#L275-L299

rotty3000 commented 4 years ago

actually, the fallback for maven isn't quite current java however, maven itself will always provide a value pretty much. The fallback .orElse(EE.JavaSE_1_8)); will essentially never be used. It's just a protection.

rotty3000 commented 4 years ago

actually...

.orElseGet(() -> EE.highestFromTargetVersion(System.getProperty("java.version"))
                        // if that all fails at least we know bnd needs at least
                        // Java 8 at this point
                        .orElse(EE.JavaSE_1_8));

it does fallback on current java!

bjhargrave commented 4 years ago

I guess my point is, why isn't the inference of -runee done in Bndrun? Where every driver benefits?

rotty3000 commented 4 years ago

The point is NOT to set it at all! In maven all I need to do is change JAVA_HOME then run with the new Java and everything resolves and runes against the new Java including the inferred EE. This is great for matrix CI runs.

rotty3000 commented 4 years ago

This is most useful when resolve happens as part of the build, which is the point here. IF you don't then just set the -runee to a preset value.

bjhargrave commented 4 years ago

The point is NOT to set it at all!

Yes, I fully get that. That is why I said "why isn't the inference of -runee done in Bndrun?" That is the type Bndrun, not the bndrun file.

rotty3000 commented 4 years ago

Got it! I think that would be reasonable. Do you think reading details from the build driver is wrong then?

bjhargrave commented 4 years ago

Bndrun (type) can infer -runee from the Java in which it is executing. So if your build is running on Java 11, Bndrun would infer -runee to be Java 11. You don't need to have Bndrun know anything about the driver for that.

rotty3000 commented 4 years ago

I'm asking if the compilation target level should have anything to do with this calculation the way it does in maven?