Re: Sling API exporting @ConsumerType class
Are we sure that this is the right solution? With the proposed solution, scripting core needs to be changed regardless. But more important, now every bundle that uses LazyBindings will get a narrow package range not just scripting.core. Or in other words, scripting.core will continue to have a narrow package range and you will run into the same problem with the next addition to LazyBindings. Regards Carsten Are we sure that no one out there is using LazyBindings in the same way as On 13.06.2024 21:43, Jörg Hoh wrote: Hi Julian, regarding the "LazyBindings.putOnly" method, the motivation was a mostly about performance, as I found a number of occurrences, where the put method actually resolved the supplier, but the return value of put() was not used at all. Also I want to avoid any change on the semantics of put, because for that I would need a major version bump; besides that the API contract of java.script.Bindings says that null is only returned if there was no value previously associated with that name. For that reason I believe that it's best if * the ProtectedBindings moves into the SLING API bundle (package org.apache.sling.api.scripting, next to the LazyBindings) * and the both LazyBindings and ProtectedBindings are marked as ProviderType to make that take effect I need to release a new version of scirpting.core as well, but then the narrow import range for the package org.apache.sling.api.scripting is more relaxed, and allows an easier evolution of the API. Jörg Am Mi., 12. Juni 2024 um 14:22 Uhr schrieb Julian Sedding < jsedd...@gmail.com>: Hi Jörg In general, I agree that we could, and maybe should, evaluate which types in the Sling API should be @ProviderType instead of @ConsumerType. My assumption would be that most types should be @ProviderType. I don't know what sort of versioning change adding the @ProviderType annotation causes, however. Regarding your specific case, I wonder if it would be acceptable to remove the "putOnly" method, and instead modify the "put" method to return "null" for in the case where a key was inserted, but the supplier never evaluated. Of course that would change the behaviour, so might cause issues in some edge cases. Regards Julian On Mon, Jun 10, 2024 at 12:38 PM Jörg Hoh wrote: Eric pointed out correctly, that there was tight connection between SLING API and Scripting core, as the package import range on scripting core (bundle version 2.4.8) is quite narrow for the package org.apache.sling.api.scripting: org.apache.sling.api.scripting; version="[2.5, 2.6)" This is caused by the class LazyBindings being a ConsumerType ( https://github.com/apache/sling-org-apache-sling-api/blob/bdbd1768969917d0e2436d5b008fff80aaa729dc/src/main/java/org/apache/sling/api/scripting/LazyBindings.java#L56 ) and the scripting core inheriting from it (in ProtectedBindings). My latest extension to it (SLING-12062) then caused a bump of the exported version, thus breaking the existing imports. Of course I could do a release of the Scripting Core as well and make sure that it works with the package version as well, but I wonder if this is the right thing to do. Should the Sling API export ConsumerType interfaces and classes at all, which can cause this type of problems, or should we try to avoid them? This is a more general question; and in case that we want to avoid those, the question is still how we want to move forward with this specific instance of it. My personal opinion is * to avoid @ConsumerType exports in the Sling API in general and * move the ProtectedBindings class, which inherits from the LazyBindings over to the API that would allow us to have a wider import range on the scripting.core side. WDYT? Jörg -- https://cqdump.joerghoh.de -- Carsten Ziegeler Adobe cziege...@apache.org
[jira] [Updated] (SLING-11965) Make API build with Java 17
[ https://issues.apache.org/jira/browse/SLING-11965?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Hoh updated SLING-11965: -- Fix Version/s: API 2.27.6 (was: API 2.27.4) > Make API build with Java 17 > --- > > Key: SLING-11965 > URL: https://issues.apache.org/jira/browse/SLING-11965 > Project: Sling > Issue Type: Task > Components: API >Affects Versions: API 2.27.2 >Reporter: Joerg Hoh >Assignee: Robert Munteanu >Priority: Major > Fix For: API 2.27.6 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-11878) Clarify Javadoc on which methods allow a ModifiableValueMap to be changed
[
https://issues.apache.org/jira/browse/SLING-11878?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Hoh updated SLING-11878:
--
Fix Version/s: API 2.27.6
(was: API 2.27.4)
> Clarify Javadoc on which methods allow a ModifiableValueMap to be changed
> -
>
> Key: SLING-11878
> URL: https://issues.apache.org/jira/browse/SLING-11878
> Project: Sling
> Issue Type: Improvement
> Components: API
>Affects Versions: API 2.27.2
>Reporter: Tomasz Niedźwiedź
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: API 2.27.6
>
>
> Hi, one of the users of AEM Rules for SonarQube has asked a question about
> the {{ModifiableValueMap}} interface and the methods through which the map is
> changeable. Here's the original [GitHub
> issue|https://github.com/wttech/AEM-Rules-for-SonarQube/issues/237#issuecomment-1536213675].
> Whether the Sonar rule is valid or should be changed depends on the intended
> way the MVM API should be used. I believe the current implementation of the
> Sonar rule is based on a piece of Sling API Javadoc that I think could use
> some clarification.
> Looking at [the latest available version of the
> Javadoc|https://sling.apache.org/apidocs/sling12/org/apache/sling/api/resource/ModifiableValueMap.html],
> here's what it says about changing resources through {{ModifiableValueMap}}
> instances:
> {quote}The {{ModifiableValueMap}} is an extension of the
> [{{ValueMap}}|https://sling.apache.org/apidocs/sling12/org/apache/sling/api/resource/ValueMap.html]
> which allows to modify and persist properties. All changes to this map are
> stored in the transient layer of the resource resolver or more precisely in
> the transient layer of the resource provider managing this resource.
> Once
> [{{ResourceResolver.commit()}}|https://sling.apache.org/apidocs/sling12/org/apache/sling/api/resource/ResourceResolver.html#commit--]
> is called, the changes are finally persisted.
> *The modifiable value map is only changeable through one of these methods*
> * *{{Map.put(Object, Object)}}*
> * *{{Map.putAll(java.util.Map)}}*
> * *{{Map.remove(Object)}}*
> *The map is not modifiable through the collections provided by*
> * *{{Map.entrySet()}}*
> * *{{Map.keySet()}}*
> * *{{Map.values()}}*
> *And it can't be modified by these methods:*
> * *{{Map.clear()}}*{quote}
> Since the {{ModifiableValueMap}} interface implements {{{}java.util.Map{}}},
> it also comes with the following methods:
> * {{replace}}
> * {{replaceAll}}
> I've done a quick test in AEM 6.5, by means of the Groovy console, and these
> methods have the effect of modifying the map's underlying resource once the
> session is saved/RR is committed.
> Should these methods also be documented as valid? Or is there a reason they
> shouldn't be called?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12219) ResourceUtil.normalize does not handle segments with multiple dots correctly
[ https://issues.apache.org/jira/browse/SLING-12219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Hoh updated SLING-12219: -- Fix Version/s: API 2.27.6 (was: API 2.27.4) > ResourceUtil.normalize does not handle segments with multiple dots correctly > > > Key: SLING-12219 > URL: https://issues.apache.org/jira/browse/SLING-12219 > Project: Sling > Issue Type: Bug > Components: API >Affects Versions: API 2.27.2 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Major > Fix For: API 2.27.6 > > > If a path segment contains more than two dots but anything else, then > ResourceUtil.normalize does not handle these correctly. It should just return > null. Instead in some cases it is leaving the segment untouched or shortens > it for example from four dots to two dots. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-11845) ResourceResolver.getSearchPaths() javadoc does not match implementation
[
https://issues.apache.org/jira/browse/SLING-11845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Hoh updated SLING-11845:
--
Fix Version/s: API 2.27.6
(was: API 2.27.4)
> ResourceResolver.getSearchPaths() javadoc does not match implementation
> ---
>
> Key: SLING-11845
> URL: https://issues.apache.org/jira/browse/SLING-11845
> Project: Sling
> Issue Type: Improvement
> Components: API
>Affects Versions: API 2.27.2
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: API 2.27.6
>
>
> The [javadoc for
> ResourceResolver.getSearchPaths()|https://sling.apache.org/apidocs/sling12/org/apache/sling/api/resource/ResourceResolver.html#getSearchPath--]
> states:
> {quote}If no search path is set an empty array is returned.
> {quote}
> But the current implementation returns an array with a single value "/" in it
> if no search path is specified
> ([Link|https://github.com/apache/sling-org-apache-sling-resourceresolver/blob/46f67c7cff13071d96cf58dde86730b6ffbb2639/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverFactoryActivator.java#L307]).
> I recommend to adjust the javadoc to match the implementation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12215) javadoc of ResourceUtil.normalize does not match implementation
[ https://issues.apache.org/jira/browse/SLING-12215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Hoh updated SLING-12215: -- Fix Version/s: API 2.27.6 (was: API 2.27.4) > javadoc of ResourceUtil.normalize does not match implementation > --- > > Key: SLING-12215 > URL: https://issues.apache.org/jira/browse/SLING-12215 > Project: Sling > Issue Type: Improvement > Components: API >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler >Priority: Minor > Fix For: API 2.27.6 > > > The javadoc mentions that it returns null on relative paths, but the method > actually handles them -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: Sling API exporting @ConsumerType class
Hi Julian, regarding the "LazyBindings.putOnly" method, the motivation was a mostly about performance, as I found a number of occurrences, where the put method actually resolved the supplier, but the return value of put() was not used at all. Also I want to avoid any change on the semantics of put, because for that I would need a major version bump; besides that the API contract of java.script.Bindings says that null is only returned if there was no value previously associated with that name. For that reason I believe that it's best if * the ProtectedBindings moves into the SLING API bundle (package org.apache.sling.api.scripting, next to the LazyBindings) * and the both LazyBindings and ProtectedBindings are marked as ProviderType to make that take effect I need to release a new version of scirpting.core as well, but then the narrow import range for the package org.apache.sling.api.scripting is more relaxed, and allows an easier evolution of the API. Jörg Am Mi., 12. Juni 2024 um 14:22 Uhr schrieb Julian Sedding < jsedd...@gmail.com>: > Hi Jörg > > In general, I agree that we could, and maybe should, evaluate which > types in the Sling API should be @ProviderType instead of > @ConsumerType. My assumption would be that most types should be > @ProviderType. I don't know what sort of versioning change adding the > @ProviderType annotation causes, however. > > Regarding your specific case, I wonder if it would be acceptable to > remove the "putOnly" method, and instead modify the "put" method to > return "null" for in the case where a key was inserted, but the > supplier never evaluated. Of course that would change the behaviour, > so might cause issues in some edge cases. > > Regards > Julian > > On Mon, Jun 10, 2024 at 12:38 PM Jörg Hoh > wrote: > > > > Eric pointed out correctly, that there was tight connection between SLING > > API and Scripting core, as the package import range on scripting core > > (bundle version 2.4.8) is quite narrow for the package > > org.apache.sling.api.scripting: > > > > org.apache.sling.api.scripting; version="[2.5, 2.6)" > > > > This is caused by the class LazyBindings being a ConsumerType ( > > > https://github.com/apache/sling-org-apache-sling-api/blob/bdbd1768969917d0e2436d5b008fff80aaa729dc/src/main/java/org/apache/sling/api/scripting/LazyBindings.java#L56 > ) > > and the scripting core inheriting from it (in ProtectedBindings). > > > > My latest extension to it (SLING-12062) then caused a bump of the > exported > > version, thus breaking the existing imports. > > > > Of course I could do a release of the Scripting Core as well and make > sure > > that it works with the package version as well, but I wonder if this is > the > > right thing to do. > > > > Should the Sling API export ConsumerType interfaces and classes at all, > > which can cause this type of problems, or should we try to avoid them? > This > > is a more general question; and in case that we want to avoid those, the > > question is still how we want to move forward with this specific instance > > of it. > > > > My personal opinion is > > * to avoid @ConsumerType exports in the Sling API in general and > > * move the ProtectedBindings class, which inherits from the LazyBindings > > over to the API > > > > that would allow us to have a wider import range on the scripting.core > side. > > > > WDYT? > > > > Jörg > > > > > > -- > > https://cqdump.joerghoh.de > -- https://cqdump.joerghoh.de
[CANCELLED] [VOTE] Release Apache Sling API 2.27.4
Hi, I cancelled the release, as Eric pointed out correctly that this new version did not play with the latest version of scripting core. Will fix it and then restart the release process. Jörg Am Di., 4. Juni 2024 um 15:24 Uhr schrieb Jörg Hoh : > We solved 9 issues in this > release:https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12353245=Text=12310710 > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2865/ > > You can use this UNIX script to download the release and verify the > signatures:https://raw.githubusercontent.com/apache/sling-tooling-release/master/check_staged_release.sh > Usage: > sh check_staged_release.sh 2865 /tmp/sling-staging > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] 0 Don't care > [ ] -1 Don't release, because ... > > This majority vote is open for at least 72 hours. > > > > -- > https://cqdump.joerghoh.de > > -- https://cqdump.joerghoh.de
[jira] [Updated] (SLING-12062) add LazyBindings.putOnly
[
https://issues.apache.org/jira/browse/SLING-12062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Hoh updated SLING-12062:
--
Fix Version/s: API 2.27.6
(was: API 2.27.4)
> add LazyBindings.putOnly
>
>
> Key: SLING-12062
> URL: https://issues.apache.org/jira/browse/SLING-12062
> Project: Sling
> Issue Type: Task
> Components: API
>Affects Versions: API 2.27.2
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: API 2.27.6
>
>
> The LazyBindings support the lazy evaluation of values to avoid the potential
> costly resolution of values at provisioning time (the values are only
> resolved when requested via {{get}}).
> But if for some reasons the same key is put twice into a LazyBinding, the
> second call to {{put(key, value)}} resolves the already provided value and
> returns it, but this return value of {{put}} is often ignored.
> So the LazyBindings should have a {{putOnly(key,value)}} method, which
> behaves the same way as the existing {{put}}, but does not return the
> (resolved) previous value. This can be used by all providers which just push
> data into the LazyBindings, but are not interested in any value returned by
> the normal {{put}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12249) Clarify "ADDED" resource changes for ancestor nodes of path
[ https://issues.apache.org/jira/browse/SLING-12249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Hoh updated SLING-12249: -- Fix Version/s: API 2.27.6 (was: API 2.27.4) > Clarify "ADDED" resource changes for ancestor nodes of path > --- > > Key: SLING-12249 > URL: https://issues.apache.org/jira/browse/SLING-12249 > Project: Sling > Issue Type: Improvement > Components: API >Affects Versions: API 2.15.0 >Reporter: Konrad Windszus >Assignee: Konrad Windszus >Priority: Major > Fix For: API 2.27.6 > > > Similar to what was clarified in SLING-6066, events for ancestors of the > registered path may not only be received for "REMOVED" resource changes but > also for "ADDED" resource changes. > This happens e.g. for moving resources with the JCR Resource Provider which > uses internally the semantics from > https://issues.apache.org/jira/browse/OAK-1459?focusedCommentId=13911484=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13911484 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-11546) ValueMap.get("calendar", String.class) conversion loses timezone information
[
https://issues.apache.org/jira/browse/SLING-11546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joerg Hoh updated SLING-11546:
--
Fix Version/s: API 2.27.6
(was: API 2.27.4)
> ValueMap.get("calendar", String.class) conversion loses timezone information
>
>
> Key: SLING-11546
> URL: https://issues.apache.org/jira/browse/SLING-11546
> Project: Sling
> Issue Type: Bug
> Components: API
>Affects Versions: API 2.21.0
>Reporter: Jelle Bouwmans
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: API 2.27.6
>
> Attachments: image-2022-08-19-10-41-27-129.png,
> image-2022-08-19-10-45-25-409.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When doing a ValueMap.get("calendar", String.class) conversion, before
> SLING-8116,
> ISO8601.format() was used. Now, Calendar.toInstant().toString() is used. This
> gives a different result, because the ISO8601 gives the correct timezone, but
> toInstant() gives the Zulu time.
> toInstant() does the following:
> {quote}public final Instant toInstant() \{ return
> Instant.ofEpochMilli(getTimeInMillis()); }
> {quote}
> Timezones and offsets are completely ignored.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] SLING-10288 - FelixFrameworkScanner sets framework properties always for current Java version [sling-org-apache-sling-feature-analyser]
rombert commented on PR #47: URL: https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/47#issuecomment-2165813375 For now we can't merge as-is. Existing analysers will because they will be unable to parse the "system.bundle" entry, which is not a valid artifact id. I need to find a solution that allows working with older versions. Options (untested): - use "org.apache.felix:org.apache.felix.framework:0" key, because that one is never listed as a bundle - use a "reserved:system.bundle:0.0.0" value (or similar), to make it clear that this is not an actual artifact id, but an "extension" -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (SLING-12262) Repoinit: report failures via metrics
[ https://issues.apache.org/jira/browse/SLING-12262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joerg Hoh resolved SLING-12262. --- Resolution: Fixed > Repoinit: report failures via metrics > - > > Key: SLING-12262 > URL: https://issues.apache.org/jira/browse/SLING-12262 > Project: Sling > Issue Type: Task > Components: Repoinit >Affects Versions: Repoinit JCR 1.1.46 >Reporter: Joerg Hoh >Assignee: Joerg Hoh >Priority: Major > Fix For: Repoinit JCR 1.1.52 > > > When a repoinit statement fails (and for that reason the SlingRepository > service cannot be started, repoinit should expose this as a metric. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] SLING-10288 - FelixFrameworkScanner sets framework properties always for current Java version [sling-org-apache-sling-feature-analyser]
sonarcloud[bot] commented on PR #47: URL: https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/47#issuecomment-2165167175 ## [](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-feature-analyser=47) **Quality Gate failed** Failed conditions  [41.5% Coverage on New Code](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-analyser=47=new_coverage=list) (required ≥ 80%) [See analysis details on SonarCloud](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-feature-analyser=47) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] SLING-10288 - FelixFrameworkScanner sets framework properties always for current Java version [sling-org-apache-sling-feature-analyser]
sonarcloud[bot] commented on PR #47: URL: https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/47#issuecomment-2165535521 ## [](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-feature-analyser=47) **Quality Gate failed** Failed conditions  [63.6% Coverage on New Code](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-analyser=47=new_coverage=list) (required ≥ 80%) [See analysis details on SonarCloud](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-feature-analyser=47) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
Re: [PR] SLING-10288 - FelixFrameworkScanner sets framework properties always for current Java version [sling-org-apache-sling-feature-analyser]
rombert commented on PR #47:
URL:
https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/47#issuecomment-2165453415
I think this is ready for review. I performed some manual tests in the
following way:
**Patched Sling Starter**
```patchdiff --git a/pom.xml b/pom.xml
index da6dfa7..9350d1c 100644
--- a/pom.xml
+++ b/pom.xml
@@ -93,6 +93,13 @@
slingfeature-maven-plugin
1.8.2
true
+
+
+org.apache.sling
+
org.apache.sling.feature.analyser
+2.0.5-SNAPSHOT
+
+
asm.version,jackrabbit.version,groovy.version,oak.version,slf4j.version,composum.nodes.version,jackson.version
@@ -102,6 +109,7 @@
oak/*.json
oak/persistence/oak_persistence_sns.json
app/*.json
+
metadata/metadata.json
Sling With Oak Segment NS
Persistence
@@ -110,12 +118,14 @@
oak/*.json
oak/persistence/oak_persistence_mongods.json
app/*.json
+
metadata/metadata.json
Sling With Oak Document NS Mongo
Persistence
nosample_base
*.json
oak/*.json
+
metadata/metadata.json
Sling With No Samples and No
Persistence
diff --git a/src/main/features/base.json b/src/main/features/base.json
index 3ed7dfd..c2360c7 100644
--- a/src/main/features/base.json
+++ b/src/main/features/base.json
@@ -3,8 +3,9 @@
"execution-environment:JSON|false":{
"framework":{
"id":"org.apache.felix:org.apache.felix.framework:7.0.5"
-}
-},
+},
+"javaVersion": "21"
+},
"bundles":[
{
"id":"org.owasp.encoder:encoder:1.2.3",
diff --git a/src/main/features/metadata/metadata.json
b/src/main/features/metadata/metadata.json
new file mode 100644
index 000..ba2927f
--- /dev/null
+++ b/src/main/features/metadata/metadata.json
@@ -0,0 +1,13 @@
+{
+"analyser-metadata:JSON|true":
+{
+ ".*" : {
+"manifest": null,
+"report": {
+ "error": false,
+ "warning": false
+}
+ },
+ "system.bundle": { }
+}
+}
\ No newline at end of file
```
This way we record the execution metadata
**Sample Sling bundle**
Configured a Sling bundle to output Java 17 bytecode
```xml
org.apache.maven.plugins
maven-compiler-plugin
17
17
```
**Sample Sling Launcher**
Configured a Sling launcher to include the above bundle and to extend from
the Sling Starter, so that the system bundle metadata is read. The launcher
includes the above bundle, to make sure the checks work as expected.
1. When the Starter is built with Java 11 and the launcher is built with
Java 11, the build fails ( Artifact com.example:core:1.0-SNAPSHOT requires
[com.example.core/1.0.0.SNAPSHOT] osgi.ee;
filter:="(&(osgi.ee=JavaSE)(version=17))" in start level 20 but no artifact is
providing a matching capability in this start level. )
2. When the Starter is built with Java 17 or 21 and the launcher is built
with Java 11, the build passes
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Re: [PR] SLING-10288 - FelixFrameworkScanner sets framework properties always for current Java version [sling-org-apache-sling-feature-analyser]
sonarcloud[bot] commented on PR #47: URL: https://github.com/apache/sling-org-apache-sling-feature-analyser/pull/47#issuecomment-2165172323 ## [](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-feature-analyser=47) **Quality Gate failed** Failed conditions  [46.3% Coverage on New Code](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-feature-analyser=47=new_coverage=list) (required ≥ 80%) [See analysis details on SonarCloud](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-feature-analyser=47) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
