Comments (2)
It seems to me that we currently rely entirely on the runtime (i.e. circle config) to determine what version of JDK we should require, and so local runs are bound to diverge in behaviour.
Perhaps instead we should enforce setting a targetCompatibility (though most likely sourceCompatibility as well) of the jdk we want, then this preflight logic could use that to infer what JVM must be available on the stacks.
from sls-packaging.
Looking into this some more, it turns out that we're not deriving the JDK from the current runtime's version (directly), but via the targetCompatibility
. Which indeed, if you don't set a source/target compatibility, will default to the version of the JVM you ran gradle with.
So, the solution in this case is to make sure you have a sourceCompatibility = 14
in your product's build.gradle.
from sls-packaging.
Related Issues (20)
- Differing classloaders can cause distribution plugins to miss dependency recommendations from within the repository HOT 2
- Locking asset configuration with GCV does not work if subprojects define their own repos
- Distribution tarballs contain bogus empty go-init and go-java-launcher directories
- Allow a library to mark a dep as optional HOT 1
- Increase default JFR stack depth beyond the default (conservative) 64 frames
- Use Async JVM Unified Logging on JDK 17+ HOT 1
- Enable UseStringDeduplication where feasible HOT 1
- Add validation to add a service dependency for new conjure projects
- Generate a product-dependencies.lock file for Recommended Product Dependencies Plugin
- productDependencies configuration might be broken with $project versions HOT 1
- Use 'hybrid' as default with java 11 and shenandoah with java 12
- var/log and var/run not created in distributions HOT 1
- sls-packaging Default JVM arguments are not applied in launcher scripts
- Implicit dependency on latest Gradle HOT 1
- Remove product dependency warning if higher version
- Support disabling inferred product dependencies HOT 3
- Overriding init.sh results in two init.sh headers in the sls.tgz HOT 5
- Remove gradle workaround HOT 1
- Cannot easily override GC settings via configuration HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sls-packaging.