Re: [PR] Bump org.apache.maven:maven-core from 3.6.3 to 3.8.1 [sling-slingfeature-maven-plugin]
sonarcloud[bot] commented on PR #85: URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/85#issuecomment-2078365308 ## [](https://sonarcloud.io/dashboard?id=apache_sling-slingfeature-maven-plugin=85) **Quality Gate passed** Issues  [0 New issues](https://sonarcloud.io/project/issues?id=apache_sling-slingfeature-maven-plugin=85=false=true)  [0 Accepted issues](https://sonarcloud.io/component_measures?id=apache_sling-slingfeature-maven-plugin=85=new_accepted_issues=list) Measures  [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-slingfeature-maven-plugin=85=false=true)  No data about Coverage  [0.0% Duplication on New Code](https://sonarcloud.io/component_measures?id=apache_sling-slingfeature-maven-plugin=85=new_duplicated_lines_density=list) [See analysis details on SonarCloud](https://sonarcloud.io/dashboard?id=apache_sling-slingfeature-maven-plugin=85) -- 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-11906 Migrate to slf4j 2.x [sling-org-apache-sling-commons-log]
enapps-enorman commented on PR #18: URL: https://github.com/apache/sling-org-apache-sling-commons-log/pull/18#issuecomment-2077746890 > 1. ServiceLoder (+mediator) ... > Would it be possible to short-circuit the ServiceLoader in a similar manner to the work we do for Commons Johnzon? That would keep deployments lean and do less unneeded work. The ServiceLoader mediator availability isn't really a problem for me since I have to have it around anyway for the various jetty-* bundles that I use that require it. Also, the sling starter already includes the mediator bundles for groovy, so... In my opinion, trying to do that kind of ServiceLoader workaround is a losing battle. I think what you are suggesting is to repackage the ServiceLoader consumers and providers into the same bundle so there is no classloading visibility problems. The problem with that is that someone has to be paying attention whenever any of those third-party bundles has a new release and then do a new release of the o.a.sling.commons.log with the new bits. That didn't happen the last time which led to the embedded slf4j / logback classes in the o.a.sling.commons.log bundle drifting years out of date. With that said, I do see that there is one other option described in the slf4j FAQ that might work without the mediator: https://www.slf4j.org/faq.html#changesInVersion200 > SINCE 2.0.9 You can specify the provider class explicitly via the "slf4j.provider" system property. This bypasses the service loader mechanism for finding providers and may shorten SLF4J initialization. I believe the extra work to do that would be to configure the "slf4j.provider" framework property, export the "org.apache.sling.commons.log.logback.spi" package from the o.a.sling.commons.log bundle and then deploy a fragment bundle attached to the slf4j-api host bundle that augments the Import-Package instruction to include the "org.apache.sling.commons.log.logback.spi" package to make it visible to the slf4j-api classloader. If that works then the choice to use the ServiceLoader mediator or the framework-property + fragment bundle could be decided by whoever is constructing the application. Let me know if that would be acceptable to you. > 2. The classloading issues from Logback It has been 2 weeks since I opened the PR proposal to logback and there has been no response at all. Do you know anyone over there would could review it and give a yes or no answer? I'm not really interested in wasting more of my time on alternate ways to do the same thing. If you want to try some other approach then please provide a patch with the changes you think will work better. -- 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] [Commented] (SLING-12197) cpconverter: Sling-Initial-Content directories created as nt:folder instead of sling:Folder
[
https://issues.apache.org/jira/browse/SLING-12197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840859#comment-17840859
]
Niek Raaijmakers commented on SLING-12197:
--
At least for mutable content, if i'm not wrong we use the order of the
generated packages.csv from the cpconverter to deploy later.
> cpconverter: Sling-Initial-Content directories created as nt:folder instead
> of sling:Folder
> ---
>
> Key: SLING-12197
> URL: https://issues.apache.org/jira/browse/SLING-12197
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Affects Versions: Content-Package to Feature Model Converter 1.3.4
>Reporter: Stefan Seifert
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.3.8
>
> Attachments: io.wcm.handler.link-apps-1.10.2-cp2fm-converted.zip
>
>
> the cpconverter extracts Sling-Initial-Content from OSGi bundles and creates
> FileVault packages with the transformed content.
> this works well, but there is one difference when the resulting content
> package is installed compared when uploading the OSGi bundle with the
> Sling-Initial-Content directly:
> * the JCR Content Loader by defaults creates a {{sling:Folder}} node type for
> each directory found in the Sling-Initial-Content (see also
> [docs|https://sling.apache.org/documentation/bundles/content-loading-jcr-contentloader.html#initial-content-loading-1])
> * the cpconverter process creates no {{.content.xml}} file for the folders,
> but only for the actual JSON files found in the process. as a result, the
> folders are created as {{nt:folder}} when uploading the transformed package
> * this difference becomes relevant, when a JSON file in Sling-Initial-Content
> defines a primary type of {{nt:unstructured}} - it is not allowed to created
> such a node directly below a {{nt:folder}} node - but it is allowed to do so
> below a {{sling:Folder}} node
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12197) cpconverter: Sling-Initial-Content directories created as nt:folder instead of sling:Folder
[
https://issues.apache.org/jira/browse/SLING-12197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840857#comment-17840857
]
Niek Raaijmakers commented on SLING-12197:
--
I am totally up to look into this , but it has to be aligned with priorities
(aka management).
Also because I haven't touched this in quite some time and it will take some
context switching.
[~sseifert] your comments are the first make some sense to me why it now
breaks all of sudden, because I didn't touch this for a very long time.
I guess pinpointing this might be time intensive though but I guess we don't
have much choice at this point?
> cpconverter: Sling-Initial-Content directories created as nt:folder instead
> of sling:Folder
> ---
>
> Key: SLING-12197
> URL: https://issues.apache.org/jira/browse/SLING-12197
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Affects Versions: Content-Package to Feature Model Converter 1.3.4
>Reporter: Stefan Seifert
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.3.8
>
> Attachments: io.wcm.handler.link-apps-1.10.2-cp2fm-converted.zip
>
>
> the cpconverter extracts Sling-Initial-Content from OSGi bundles and creates
> FileVault packages with the transformed content.
> this works well, but there is one difference when the resulting content
> package is installed compared when uploading the OSGi bundle with the
> Sling-Initial-Content directly:
> * the JCR Content Loader by defaults creates a {{sling:Folder}} node type for
> each directory found in the Sling-Initial-Content (see also
> [docs|https://sling.apache.org/documentation/bundles/content-loading-jcr-contentloader.html#initial-content-loading-1])
> * the cpconverter process creates no {{.content.xml}} file for the folders,
> but only for the actual JSON files found in the process. as a result, the
> folders are created as {{nt:folder}} when uploading the transformed package
> * this difference becomes relevant, when a JSON file in Sling-Initial-Content
> defines a primary type of {{nt:unstructured}} - it is not allowed to created
> such a node directly below a {{nt:folder}} node - but it is allowed to do so
> below a {{sling:Folder}} node
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] Update context-aware-configuration.md [sling-site]
stefanseifert merged PR #160: URL: https://github.com/apache/sling-site/pull/160 -- 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-12302) CA Config access syntax is inconsistent in HTL
[
https://issues.apache.org/jira/browse/SLING-12302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved SLING-12302.
Assignee: Stefan Seifert
Resolution: Fixed
thanks, i've merged the PR
> CA Config access syntax is inconsistent in HTL
> --
>
> Key: SLING-12302
> URL: https://issues.apache.org/jira/browse/SLING-12302
> Project: Sling
> Issue Type: Bug
>Reporter: Karol Lewandowski
>Assignee: Stefan Seifert
>Priority: Major
>
> I have a problem understanding how nested configs can be accessed in HTL or
> if there is a bug in the implementation.
> The
> [documentation|https://sling.apache.org/documentation/bundles/context-aware-configuration/context-aware-configuration.html#accessing-configuration-from-htlsightly-templates]
> gives an example:
> {{{}$\{caconfig['x.y.z.ConfigSample']['nestedConfig/stringParam']{
> However, it doesn't work when a configuration annotation class is defined.
> Steps to reproduce:
> 1. Create a config node:
> {{/conf/we-retail/sling:configs/us/en/sling:configs/com.mysite.core.config.TestConfig}}
> {code:xml}
>
> http://sling.apache.org/jcr/sling/1.0;
> xmlns:jcr="http://www.jcp.org/jcr/1.0;
> jcr:primaryType="sling:OsgiConfig"
> email="t...@example.com"
> enabled="{Boolean}true"
> number="{Long}123">
> jcr:primaryType="sling:OsgiConfig"
> greeting="hello"/>
>
> {code}
> and reference it from some path.
> 2. Access in HTL without configuration annotation class:
> {code}
> Email: ${caconfig['com.mysite.core.config.TestConfig'].email}
> Number: ${caconfig['com.mysite.core.config.TestConfig'].number}
> Enabled: ${caconfig['com.mysite.core.config.TestConfig'].enabled}
> Greeting (config path):
> ${caconfig['com.mysite.core.config.TestConfig/nested'].greeting}
> Greeting (property path):
> ${caconfig['com.mysite.core.config.TestConfig']['nested/greeting']} {code}
> This gives the output:
> {code}
> Email: t...@example.com
> Number: 123
> Enabled: true
> Greeting (config path): hello
> Greeting (property path): hello {code}
> It works as expected.
> 3. Create annotation classes:
> {code:java}
> package com.mysite.core.config;
> import org.apache.sling.caconfig.annotation.Configuration;
> @Configuration
> public @interface TestConfig {
> String email();
> int number() default 5;
> boolean enabled();
> NestedConfig nested();
> }
> {code}
> and
> {code:java}
> package com.mysite.core.config;
> public @interface NestedConfig {
> String greeting();
> }
> {code}
> The previous HTL will print:
> {code}
> Email: t...@example.com
> Number: 123
> Enabled: true
> Greeting (config path): hello
> Greeting (property path): {code}
> Accessing nested config value with property name path doesn't work. Is it
> expected?
> I'm working on support for CA Configs in AEM IDE, so I don't want to make it
> work in my AEM application but provide the correct syntax support.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12197) cpconverter: Sling-Initial-Content directories created as nt:folder instead of sling:Folder
[
https://issues.apache.org/jira/browse/SLING-12197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840834#comment-17840834
]
Stefan Seifert commented on SLING-12197:
good point - i discovered that most of the test code for Sling-Initial-Content
is in this test class:
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/master/src/test/java/org/apache/sling/feature/cpconverter/handlers/BundleEntryHandleSlingInitialContentTest.java
and the good thing the unit test uses already a jar file
{{io.wcm.handler.media-1.11.6.jar}} which is affected exactly by the problem.
i've found that there is already an implementation that should fix the problem
described in this ticket (but does not actually), this path is exactly verified
here as repoinit statement, but fails to be created with sling:Folder currently
(nt:folder instead):
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/blob/2ed5bdc8ccaf8ab9079268bfbc9d1fdc77bbd485/src/test/java/org/apache/sling/feature/cpconverter/handlers/BundleEntryHandleSlingInitialContentTest.java#L146
so maybe this is a pointer to a strange thing: the whole initial content
processing with the folder primary types worked initially fine (e.g. with
cpconverter around 1.1.25), and broke some time later. maybe the root cause is
not the sling-initial-content processing, but the processing of the repoinit
statements it creates?
e.g. if the order of deploying the content package generated from the jar file,
and execution of the repoinit statements is done in the wrong way (package
first), it will break, if it is done right it will work. because the repoinit
statements in the unit test look correct and should fix the problem.
maybe the problem is not within cpconverter, but in downstream code picking up
the resulting packages and repoinit statements, and the problem lies there
(i.e. AEMaaCS build pipeline)?
> cpconverter: Sling-Initial-Content directories created as nt:folder instead
> of sling:Folder
> ---
>
> Key: SLING-12197
> URL: https://issues.apache.org/jira/browse/SLING-12197
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Affects Versions: Content-Package to Feature Model Converter 1.3.4
>Reporter: Stefan Seifert
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.3.8
>
> Attachments: io.wcm.handler.link-apps-1.10.2-cp2fm-converted.zip
>
>
> the cpconverter extracts Sling-Initial-Content from OSGi bundles and creates
> FileVault packages with the transformed content.
> this works well, but there is one difference when the resulting content
> package is installed compared when uploading the OSGi bundle with the
> Sling-Initial-Content directly:
> * the JCR Content Loader by defaults creates a {{sling:Folder}} node type for
> each directory found in the Sling-Initial-Content (see also
> [docs|https://sling.apache.org/documentation/bundles/content-loading-jcr-contentloader.html#initial-content-loading-1])
> * the cpconverter process creates no {{.content.xml}} file for the folders,
> but only for the actual JSON files found in the process. as a result, the
> folders are created as {{nt:folder}} when uploading the transformed package
> * this difference becomes relevant, when a JSON file in Sling-Initial-Content
> defines a primary type of {{nt:unstructured}} - it is not allowed to created
> such a node directly below a {{nt:folder}} node - but it is allowed to do so
> below a {{sling:Folder}} node
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12197) cpconverter: Sling-Initial-Content directories created as nt:folder instead of sling:Folder
[
https://issues.apache.org/jira/browse/SLING-12197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840821#comment-17840821
]
Robert Munteanu commented on SLING-12197:
-
Sure, if Niek has the time to look at it I'm all for it :-) I looked the
initial PR from SLING-10931 and it's a lot of code, not easy to figure out
where to insert what.
As for the test case, it would be very helpful if you could create a simple
package with Sling initial content that install on the latest Sling Starter but
fails when passed through the CP Converter. The bundle you linked above
requires AEM-specific APIs and I can't use it for testing.
> cpconverter: Sling-Initial-Content directories created as nt:folder instead
> of sling:Folder
> ---
>
> Key: SLING-12197
> URL: https://issues.apache.org/jira/browse/SLING-12197
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Affects Versions: Content-Package to Feature Model Converter 1.3.4
>Reporter: Stefan Seifert
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.3.8
>
> Attachments: io.wcm.handler.link-apps-1.10.2-cp2fm-converted.zip
>
>
> the cpconverter extracts Sling-Initial-Content from OSGi bundles and creates
> FileVault packages with the transformed content.
> this works well, but there is one difference when the resulting content
> package is installed compared when uploading the OSGi bundle with the
> Sling-Initial-Content directly:
> * the JCR Content Loader by defaults creates a {{sling:Folder}} node type for
> each directory found in the Sling-Initial-Content (see also
> [docs|https://sling.apache.org/documentation/bundles/content-loading-jcr-contentloader.html#initial-content-loading-1])
> * the cpconverter process creates no {{.content.xml}} file for the folders,
> but only for the actual JSON files found in the process. as a result, the
> folders are created as {{nt:folder}} when uploading the transformed package
> * this difference becomes relevant, when a JSON file in Sling-Initial-Content
> defines a primary type of {{nt:unstructured}} - it is not allowed to created
> such a node directly below a {{nt:folder}} node - but it is allowed to do so
> below a {{sling:Folder}} node
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [VOTE] Release Apache Sling OSGi Feature Maven Plugin 1.8.2
+1 Carsten On 25.04.2024 10:42, Robert Munteanu wrote: Hi, We solved 4 issues in this release: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710=12353863=Text Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2855/ 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 2855 /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. Regards, Robert Munteanu -- Carsten Ziegeler Adobe cziege...@apache.org
Re: [VOTE] Release Apache Sling Commons JSON 2.0.28
+1 Carsten On 25.04.2024 13:20, Robert Munteanu wrote: Hi, We solved 1 issue in this release: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710=12354549=Text Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2856/ 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 2856 /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. Regards, Robert Munteanu -- Carsten Ziegeler Adobe cziege...@apache.org
RE: [VOTE] Release Apache Sling Commons JSON 2.0.28
+1 stefan
RE: [VOTE] Release Apache Sling OSGi Feature Maven Plugin 1.8.2
+1 stefan
[VOTE] Release Apache Sling Commons JSON 2.0.28
Hi, We solved 1 issue in this release: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710=12354549=Text Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2856/ 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 2856 /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. Regards, Robert Munteanu
[jira] [Assigned] (SLING-12304) Broken backwards compatibility: out of order json object
[ https://issues.apache.org/jira/browse/SLING-12304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu reassigned SLING-12304: --- Assignee: Remo Liechti > Broken backwards compatibility: out of order json object > > > Key: SLING-12304 > URL: https://issues.apache.org/jira/browse/SLING-12304 > Project: Sling > Issue Type: Bug >Affects Versions: Commons JSON 2.0.26 >Reporter: Remo Liechti >Assignee: Remo Liechti >Priority: Critical > Fix For: Commons JSON 2.0.28 > > > The fix of CVE-2022-47937 introduced an invalid backwards compatibility for > the order in jsonobject. > New behaviour: has the keys unordered, as JsonObject uses a HashMap. > Old behaviour: Kept insertion order of keys as JsonObject used LinkedHashMap. > To no break existing users of the library, reestablish the old behaviour. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12304) Broken backwards compatibility: out of order json object
[ https://issues.apache.org/jira/browse/SLING-12304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu resolved SLING-12304. - Resolution: Fixed PR applied, thanks [~rliechti]! > Broken backwards compatibility: out of order json object > > > Key: SLING-12304 > URL: https://issues.apache.org/jira/browse/SLING-12304 > Project: Sling > Issue Type: Bug >Affects Versions: Commons JSON 2.0.26 >Reporter: Remo Liechti >Assignee: Remo Liechti >Priority: Critical > Fix For: Commons JSON 2.0.28 > > > The fix of CVE-2022-47937 introduced an invalid backwards compatibility for > the order in jsonobject. > New behaviour: has the keys unordered, as JsonObject uses a HashMap. > Old behaviour: Kept insertion order of keys as JsonObject used LinkedHashMap. > To no break existing users of the library, reestablish the old behaviour. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12300) Provide a way to retrieve a JCR backed resource by its node identifier
[
https://issues.apache.org/jira/browse/SLING-12300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840756#comment-17840756
]
Radu Cotescu commented on SLING-12300:
--
I've updated the PR to include a configuration flag. Let me know what you
think. I'd like to get this merged by the end of next week.
> Provide a way to retrieve a JCR backed resource by its node identifier
> --
>
> Key: SLING-12300
> URL: https://issues.apache.org/jira/browse/SLING-12300
> Project: Sling
> Issue Type: New Feature
> Components: JCR
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: JCR Resource 3.3.0
>
>
> Since all {{javax.jcr.Nodes}} have an identifier [0], a useful feature would
> be {{Resource}} retrieval by node id, which could be its {{jcr:uuid}}
> property for referenceable nodes or the path. In systems that would like to
> use UUID addressing, this would reduce the need for executing JCR queries for
> resource retrieval and would avoid double-reads via the JCR and then Sling
> API to obtain the resource.
> In order to provide a unified behaviour, paths starting with the {{/jcr:id/}}
> prefix should use the resource retrieval by node identifier.
> [0] -
> https://javadoc.io/static/javax.jcr/jcr/2.0/javax/jcr/Node.html#getIdentifier()
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12197) cpconverter: Sling-Initial-Content directories created as nt:folder instead of sling:Folder
[
https://issues.apache.org/jira/browse/SLING-12197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840751#comment-17840751
]
Stefan Seifert commented on SLING-12197:
can we reach out to [~Sc0rpic0m] who did the initial implementation as part of
SLING-10931?
> cpconverter: Sling-Initial-Content directories created as nt:folder instead
> of sling:Folder
> ---
>
> Key: SLING-12197
> URL: https://issues.apache.org/jira/browse/SLING-12197
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Affects Versions: Content-Package to Feature Model Converter 1.3.4
>Reporter: Stefan Seifert
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.3.8
>
> Attachments: io.wcm.handler.link-apps-1.10.2-cp2fm-converted.zip
>
>
> the cpconverter extracts Sling-Initial-Content from OSGi bundles and creates
> FileVault packages with the transformed content.
> this works well, but there is one difference when the resulting content
> package is installed compared when uploading the OSGi bundle with the
> Sling-Initial-Content directly:
> * the JCR Content Loader by defaults creates a {{sling:Folder}} node type for
> each directory found in the Sling-Initial-Content (see also
> [docs|https://sling.apache.org/documentation/bundles/content-loading-jcr-contentloader.html#initial-content-loading-1])
> * the cpconverter process creates no {{.content.xml}} file for the folders,
> but only for the actual JSON files found in the process. as a result, the
> folders are created as {{nt:folder}} when uploading the transformed package
> * this difference becomes relevant, when a JSON file in Sling-Initial-Content
> defines a primary type of {{nt:unstructured}} - it is not allowed to created
> such a node directly below a {{nt:folder}} node - but it is allowed to do so
> below a {{sling:Folder}} node
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] SLING-12300 - Provide a way to retrieve a JCR backed resource by its node identifier [sling-org-apache-sling-jcr-resource]
sonarcloud[bot] commented on PR #42: URL: https://github.com/apache/sling-org-apache-sling-jcr-resource/pull/42#issuecomment-2076812580 ## [](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-jcr-resource=42) **Quality Gate passed** Issues  [1 New issue](https://sonarcloud.io/project/issues?id=apache_sling-org-apache-sling-jcr-resource=42=false=true)  [0 Accepted issues](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-jcr-resource=42=new_accepted_issues=list) Measures  [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-org-apache-sling-jcr-resource=42=false=true)  [94.4% Coverage on New Code](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-jcr-resource=42=new_coverage=list)  [0.0% Duplication on New Code](https://sonarcloud.io/component_measures?id=apache_sling-org-apache-sling-jcr-resource=42=new_duplicated_lines_density=list) [See analysis details on SonarCloud](https://sonarcloud.io/dashboard?id=apache_sling-org-apache-sling-jcr-resource=42) -- 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] [Closed] (SLING-11633) ClientSideTeleporter throwing illegal argument when target byte code is > 1.8
[ https://issues.apache.org/jira/browse/SLING-11633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu closed SLING-11633. --- > ClientSideTeleporter throwing illegal argument when target byte code is > 1.8 > - > > Key: SLING-11633 > URL: https://issues.apache.org/jira/browse/SLING-11633 > Project: Sling > Issue Type: Improvement > Components: Testing > Environment: Apache Maven 3.8.5 > (3599d3414f046de2324203b78ddcf9b5e4388aa0) > Maven home: C:\aem-tools\utils\apache-maven-3.8.5 > Java version: 11.0.15.1, vendor: Oracle Corporation, runtime: > C:\aem-tools\utils\jdk-11.0.15.1 > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" >Reporter: Scott Yuan >Assignee: Scott Yuan >Priority: Trivial > Fix For: JUnit Tests Teleporter 1.0.26 > > Attachments: mylab.zip > > Original Estimate: 2h > Time Spent: 0.5h > Remaining Estimate: 1.5h > > When attempted to use the latest 1.0.22 to build test cases using > TeleporterRule with Java 11+ code, illegal arguments error occurred. > It can be reproduce with the attached Maven project by change following > properites to 11. > * maven.compiler.source > * maven.compiler.target -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-9327) Teleporter not working with jdk11 due to missing xml bind classes
[
https://issues.apache.org/jira/browse/SLING-9327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu closed SLING-9327.
--
> Teleporter not working with jdk11 due to missing xml bind classes
> -
>
> Key: SLING-9327
> URL: https://issues.apache.org/jira/browse/SLING-9327
> Project: Sling
> Issue Type: Bug
> Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.10
>Reporter: Thierry Ygé
>Assignee: Robert Munteanu
>Priority: Blocker
> Fix For: JUnit Tests Teleporter 1.0.26
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Currently when using teleporter on jdk11 based environment, the teleporter is
> failing due to missing class.
> {quote}java.lang.NoClassDefFoundError: javax/xml/bind/DatatypeConverter at
> org.apache.sling.testing.teleporter.client.TeleporterHttpClient.setConnectionCredentials(TeleporterHttpClient.java:63)
> at
> org.apache.sling.testing.teleporter.client.TeleporterHttpClient.getHttpGetStatus(TeleporterHttpClient.java:136)
> at
> org.apache.sling.testing.teleporter.client.TeleporterHttpClient.waitForStatus(TeleporterHttpClient.java:75)
> at
> org.apache.sling.testing.teleporter.client.TeleporterHttpClient.installBundle(TeleporterHttpClient.java:94)
> at
> org.apache.sling.testing.teleporter.client.ClientSideTeleporter.installTestBundle(ClientSideTeleporter.java:173)
> at
> org.apache.sling.testing.teleporter.client.ClientSideTeleporter.access$000(ClientSideTeleporter.java:45)
> at
> org.apache.sling.testing.teleporter.client.ClientSideTeleporter$2.evaluate(ClientSideTeleporter.java:207)
> at
> com.adobe.granite.testing.serverside.rules.GraniteSSTRule$1.evaluate(GraniteSSTRule.java:104)
> {quote}
> This is due to jdk not containing this package anymore since jdk 9.
> Teleporter used is 1.0.10 and with 1.0.20 I couldn't use it as it fails with
> missing osgi core dependency, unless I would then add it manually in the test
> module pom.
> Note from [~bdelacretaz]
> As per
> [https://stackoverflow.com/questions/52502189/java-11-package-javax-xml-bind-does-not-exist]
> it looks like using {{jakarta.xml.bind}} as an additional dependency might
> fix this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[RESULT] [VOTE] Release Apache Sling JUnit Tests Teleporter 1.0.26
Hi, The vote has passed with the following result: +1 (binding): Robert Munteanu, Stefan Seifert, Joerg Hoh, Radu Cotescu +1 (non-binding): none I will copy this release to the Sling dist directory and promote the artifacts to the central Maven repository. Regards, Robert Munteanu
Re: [VOTE] Release Apache Sling Rewriter 1.4.2
On Wed, 2024-04-24 at 14:35 +0200, Carsten Ziegeler wrote: > Please vote to approve this release: +1 Note: the build fails for me in various forms on anything but Java 8, it would be good to clean this up. Robert signature.asc Description: This is a digitally signed message part
[VOTE] Release Apache Sling OSGi Feature Maven Plugin 1.8.2
Hi, We solved 4 issues in this release: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710=12353863=Text Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2855/ 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 2855 /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. Regards, Robert Munteanu
[jira] [Resolved] (SLING-12173) Configuration errors in Eclipse for projects using the slingfeature-maven-plugin
[
https://issues.apache.org/jira/browse/SLING-12173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu resolved SLING-12173.
-
Fix Version/s: OSGi Feature Maven Plugin 1.8.2
(was: OSGi Feature Maven Plugin 1.8.4)
Resolution: Fixed
> Configuration errors in Eclipse for projects using the
> slingfeature-maven-plugin
>
>
> Key: SLING-12173
> URL: https://issues.apache.org/jira/browse/SLING-12173
> Project: Sling
> Issue Type: Bug
> Components: Maven Plugins and Archetypes
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: OSGi Feature Maven Plugin 1.8.2
>
>
> The slingfeature-maven-plugin currently uses the Jakarta JSON implementation
> of the Apache Johnzon parser.
> I have noticed problems in the Eclipse IDE, where projects fail to update
> with hard to isolate errors (see below).
> {noformat}java.util.ServiceConfigurationError: jakarta.json.spi.JsonProvider:
> org.apache.johnzon.core.JsonProviderImpl not a subtype
> at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:593)
> at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1244)
> at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1273)
> at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309)
> at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1393)
> at jakarta.json.spi.JsonProvider.provider(JsonProvider.java:69)
> at jakarta.json.Json.createReader(Json.java:189)
> at
> org.apache.sling.feature.maven.JSONFeatures.read(JSONFeatures.java:64)
> at
> org.apache.sling.feature.maven.ProjectHelper.readFeatureFile(ProjectHelper.java:622)
> at
> org.apache.sling.feature.maven.Preprocessor.readProjectFeatures(Preprocessor.java:304)
> at
> org.apache.sling.feature.maven.Preprocessor.process(Preprocessor.java:145)
> at
> org.apache.sling.feature.maven.Preprocessor.process(Preprocessor.java:110)
> at
> org.apache.sling.feature.maven.extensions.DependencyLifecycleParticipant.afterProjectsRead(DependencyLifecycleParticipant.java:87)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.executeParticipants(ProjectRegistryManager.java:824)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.lambda$15(ProjectRegistryManager.java:791)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:214)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.lambda$14(ProjectRegistryManager.java:790)
> at java.base/java.util.HashMap$Values.forEach(HashMap.java:1065)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.lambda$11(ProjectRegistryManager.java:788)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:214)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.readMavenProjectFacades(ProjectRegistryManager.java:760)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.refresh(ProjectRegistryManager.java:392)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.refresh(ProjectRegistryManager.java:366)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.refresh(ProjectRegistryManager.java:318)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.getProjectFacade(MavenBuilder.java:146)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$0(MavenBuilder.java:84)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:214)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:83)
> at
>
[jira] [Updated] (SLING-12305) Build fails on Java 21 due to invoker plug-in: Unsupported class file major version 65
[
https://issues.apache.org/jira/browse/SLING-12305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-12305:
Fix Version/s: OSGi Feature Maven Plugin 1.8.4
(was: OSGi Feature Maven Plugin 1.8.2)
> Build fails on Java 21 due to invoker plug-in: Unsupported class file major
> version 65
> --
>
> Key: SLING-12305
> URL: https://issues.apache.org/jira/browse/SLING-12305
> Project: Sling
> Issue Type: Bug
>Affects Versions: OSGi Feature Maven Plugin 1.8.0
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: OSGi Feature Maven Plugin 1.8.4
>
>
> The invoker plugin-ins runs groovy scripts in the {{verify}} goal, and this
> fails on Java 21 with
> {noformat}
> [INFO] --- invoker:3.5.1:integration-test (integration-test) @
> slingfeature-maven-plugin ---
> [INFO] Building: analyzer-apiregions-errors-detected/pom.xml
> [INFO] run post-build script verify.groovy
> [INFO] BUG! exception in phase 'semantic analysis' in source unit
> 'Script1.groovy' Unsupported class file major version 65
> [INFO] analyzer-apiregions-errors-detected/pom.xml .. FAILED
> (3.0 s)
> {noformat}
> The stack trace seems to indicate that Groovy tries to parse Java 21 bytecode
> and fails.
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Unsupported class file major
> version 65
> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:199)
> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:180)
> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:166)
> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:287)
> at
> org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(AsmDecompiler.java:83)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-12305) Build fails on Java 21 due to invoker plug-in: Unsupported class file major version 65
[
https://issues.apache.org/jira/browse/SLING-12305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu resolved SLING-12305.
-
Resolution: Fixed
> Build fails on Java 21 due to invoker plug-in: Unsupported class file major
> version 65
> --
>
> Key: SLING-12305
> URL: https://issues.apache.org/jira/browse/SLING-12305
> Project: Sling
> Issue Type: Bug
>Affects Versions: OSGi Feature Maven Plugin 1.8.0
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: OSGi Feature Maven Plugin 1.8.4
>
>
> The invoker plugin-ins runs groovy scripts in the {{verify}} goal, and this
> fails on Java 21 with
> {noformat}
> [INFO] --- invoker:3.5.1:integration-test (integration-test) @
> slingfeature-maven-plugin ---
> [INFO] Building: analyzer-apiregions-errors-detected/pom.xml
> [INFO] run post-build script verify.groovy
> [INFO] BUG! exception in phase 'semantic analysis' in source unit
> 'Script1.groovy' Unsupported class file major version 65
> [INFO] analyzer-apiregions-errors-detected/pom.xml .. FAILED
> (3.0 s)
> {noformat}
> The stack trace seems to indicate that Groovy tries to parse Java 21 bytecode
> and fails.
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Unsupported class file major
> version 65
> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:199)
> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:180)
> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:166)
> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:287)
> at
> org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(AsmDecompiler.java:83)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12173) Configuration errors in Eclipse for projects using the slingfeature-maven-plugin
[
https://issues.apache.org/jira/browse/SLING-12173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-12173:
Fix Version/s: OSGi Feature Maven Plugin 1.8.4
(was: OSGi Feature Maven Plugin 1.8.2)
> Configuration errors in Eclipse for projects using the
> slingfeature-maven-plugin
>
>
> Key: SLING-12173
> URL: https://issues.apache.org/jira/browse/SLING-12173
> Project: Sling
> Issue Type: Bug
> Components: Maven Plugins and Archetypes
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: OSGi Feature Maven Plugin 1.8.4
>
>
> The slingfeature-maven-plugin currently uses the Jakarta JSON implementation
> of the Apache Johnzon parser.
> I have noticed problems in the Eclipse IDE, where projects fail to update
> with hard to isolate errors (see below).
> {noformat}java.util.ServiceConfigurationError: jakarta.json.spi.JsonProvider:
> org.apache.johnzon.core.JsonProviderImpl not a subtype
> at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:593)
> at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1244)
> at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1273)
> at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309)
> at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1393)
> at jakarta.json.spi.JsonProvider.provider(JsonProvider.java:69)
> at jakarta.json.Json.createReader(Json.java:189)
> at
> org.apache.sling.feature.maven.JSONFeatures.read(JSONFeatures.java:64)
> at
> org.apache.sling.feature.maven.ProjectHelper.readFeatureFile(ProjectHelper.java:622)
> at
> org.apache.sling.feature.maven.Preprocessor.readProjectFeatures(Preprocessor.java:304)
> at
> org.apache.sling.feature.maven.Preprocessor.process(Preprocessor.java:145)
> at
> org.apache.sling.feature.maven.Preprocessor.process(Preprocessor.java:110)
> at
> org.apache.sling.feature.maven.extensions.DependencyLifecycleParticipant.afterProjectsRead(DependencyLifecycleParticipant.java:87)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.executeParticipants(ProjectRegistryManager.java:824)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.lambda$15(ProjectRegistryManager.java:791)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:214)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.lambda$14(ProjectRegistryManager.java:790)
> at java.base/java.util.HashMap$Values.forEach(HashMap.java:1065)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.lambda$11(ProjectRegistryManager.java:788)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:214)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.readMavenProjectFacades(ProjectRegistryManager.java:760)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.refresh(ProjectRegistryManager.java:392)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.refresh(ProjectRegistryManager.java:366)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.refresh(ProjectRegistryManager.java:318)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.getProjectFacade(MavenBuilder.java:146)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$0(MavenBuilder.java:84)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:214)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:83)
> at
>
Re: [PR] SLING-12173 - Configuration errors in Eclipse for projects using the slingfeature-maven-plugin [sling-slingfeature-maven-plugin]
rombert merged PR #83: URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/83 -- 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-12173 - Configuration errors in Eclipse for projects using the slingfeature-maven-plugin [sling-slingfeature-maven-plugin]
sonarcloud[bot] commented on PR #83: URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/83#issuecomment-2076657865 ## [](https://sonarcloud.io/dashboard?id=apache_sling-slingfeature-maven-plugin=83) **Quality Gate passed** Issues  [0 New issues](https://sonarcloud.io/project/issues?id=apache_sling-slingfeature-maven-plugin=83=false=true)  [0 Accepted issues](https://sonarcloud.io/component_measures?id=apache_sling-slingfeature-maven-plugin=83=new_accepted_issues=list) Measures  [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-slingfeature-maven-plugin=83=false=true)  No data about Coverage  [0.0% Duplication on New Code](https://sonarcloud.io/component_measures?id=apache_sling-slingfeature-maven-plugin=83=new_duplicated_lines_density=list) [See analysis details on SonarCloud](https://sonarcloud.io/dashboard?id=apache_sling-slingfeature-maven-plugin=83) -- 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] Bump org.apache.maven:maven-core from 3.6.3 to 3.8.1 [sling-slingfeature-maven-plugin]
sonarcloud[bot] commented on PR #85: URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/85#issuecomment-2076655092 ## [](https://sonarcloud.io/dashboard?id=apache_sling-slingfeature-maven-plugin=85) **Quality Gate passed** Issues  [0 New issues](https://sonarcloud.io/project/issues?id=apache_sling-slingfeature-maven-plugin=85=false=true)  [0 Accepted issues](https://sonarcloud.io/component_measures?id=apache_sling-slingfeature-maven-plugin=85=new_accepted_issues=list) Measures  [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-slingfeature-maven-plugin=85=false=true)  No data about Coverage  [0.0% Duplication on New Code](https://sonarcloud.io/component_measures?id=apache_sling-slingfeature-maven-plugin=85=new_duplicated_lines_density=list) [See analysis details on SonarCloud](https://sonarcloud.io/dashboard?id=apache_sling-slingfeature-maven-plugin=85) -- 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
[PR] Bump org.apache.maven:maven-core from 3.6.3 to 3.8.1 [sling-slingfeature-maven-plugin]
dependabot[bot] opened a new pull request, #85: URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/85 Bumps [org.apache.maven:maven-core](https://github.com/apache/maven) from 3.6.3 to 3.8.1. Commits https://github.com/apache/maven/commit/05c21c65bdfed0f71a2f2ada8b84da59348c4c5d;>05c21c6 [maven-release-plugin] prepare release maven-3.8.1 https://github.com/apache/maven/commit/d295dc362fe7d7b189b4976a5742a17362eb51a1;>d295dc3 [MNG-7128] keep blocked attribute from mirrors in artifact repositories https://github.com/apache/maven/commit/a46906806a31edb462b935e380a657b6efde6231;>a469068 next version in branch 3.8.x is 3.8.1-SNAPSHOT https://github.com/apache/maven/commit/dad8a3e1c55f34b7949945bc622f26447ddbf4f9;>dad8a3e [maven-release-plugin] prepare for next development iteration https://github.com/apache/maven/commit/6aa1f4acf5d6323e9aa08b763cb9933dc96749b9;>6aa1f4a [maven-release-plugin] prepare release maven-3.8.0 https://github.com/apache/maven/commit/907d53ad3264718f66ff15e1363d76b07dd0c05f;>907d53a [MNG-7118] block HTTP repositories by default https://github.com/apache/maven/commit/899465aeec03753ea91e15a79579eab76369c016;>899465a [MNG-7117] add support for blocked mirror https://github.com/apache/maven/commit/fa79cb22e456cc65522b5bab8c4240fe08c5775f;>fa79cb2 [MNG-7116] add support for mirrorOf external:http:* https://github.com/apache/maven/commit/e5f6634e17362387282b3867c9b23d4b54fea871;>e5f6634 use Maven Resolver 1.6.2 https://github.com/apache/maven/commit/09f77da9b0c39848fe763bdd4a392151eec0d8c3;>09f77da [MNG-7119] Upgrade Maven Wagon to 3.4.3 Additional commits viewable in https://github.com/apache/maven/compare/maven-3.6.3...maven-3.8.1;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/apache/sling-slingfeature-maven-plugin/network/alerts). -- 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-12305 - Build fails on Java 21 due to invoker plug-in: Unsupported class file major version 65 [sling-slingfeature-maven-plugin]
rombert merged PR #84: URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/84 -- 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-12305 - Build fails on Java 21 due to invoker plug-in: Unsupported class file major version 65 [sling-slingfeature-maven-plugin]
rombert commented on PR #84: URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/84#issuecomment-2076638281 Merging as Java 11/17/21 builds passed, but still pending on Windows nodes. -- 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-12305 - Build fails on Java 21 due to invoker plug-in: Unsupported class file major version 65 [sling-slingfeature-maven-plugin]
sonarcloud[bot] commented on PR #84: URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/84#issuecomment-2076635365 ## [](https://sonarcloud.io/dashboard?id=apache_sling-slingfeature-maven-plugin=84) **Quality Gate passed** Issues  [0 New issues](https://sonarcloud.io/project/issues?id=apache_sling-slingfeature-maven-plugin=84=false=true)  [0 Accepted issues](https://sonarcloud.io/component_measures?id=apache_sling-slingfeature-maven-plugin=84=new_accepted_issues=list) Measures  [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=apache_sling-slingfeature-maven-plugin=84=false=true)  No data about Coverage  [0.0% Duplication on New Code](https://sonarcloud.io/component_measures?id=apache_sling-slingfeature-maven-plugin=84=new_duplicated_lines_density=list) [See analysis details on SonarCloud](https://sonarcloud.io/dashboard?id=apache_sling-slingfeature-maven-plugin=84) -- 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] [Updated] (SLING-12305) Build fails on Java 21 due to invoker plug-in: Unsupported class file major version 65
[
https://issues.apache.org/jira/browse/SLING-12305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-12305:
Issue Type: Bug (was: Task)
> Build fails on Java 21 due to invoker plug-in: Unsupported class file major
> version 65
> --
>
> Key: SLING-12305
> URL: https://issues.apache.org/jira/browse/SLING-12305
> Project: Sling
> Issue Type: Bug
>Affects Versions: OSGi Feature Maven Plugin 1.8.0
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: OSGi Feature Maven Plugin 1.8.2
>
>
> The invoker plugin-ins runs groovy scripts in the {{verify}} goal, and this
> fails on Java 21 with
> {noformat}
> [INFO] --- invoker:3.5.1:integration-test (integration-test) @
> slingfeature-maven-plugin ---
> [INFO] Building: analyzer-apiregions-errors-detected/pom.xml
> [INFO] run post-build script verify.groovy
> [INFO] BUG! exception in phase 'semantic analysis' in source unit
> 'Script1.groovy' Unsupported class file major version 65
> [INFO] analyzer-apiregions-errors-detected/pom.xml .. FAILED
> (3.0 s)
> {noformat}
> The stack trace seems to indicate that Groovy tries to parse Java 21 bytecode
> and fails.
> {noformat}
> Caused by: java.lang.IllegalArgumentException: Unsupported class file major
> version 65
> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:199)
> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:180)
> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:166)
> at groovyjarjarasm.asm.ClassReader.(ClassReader.java:287)
> at
> org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(AsmDecompiler.java:83)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (SLING-12305) Build fails on Java 21 due to invoker plug-in: Unsupported class file major version 65
Robert Munteanu created SLING-12305:
---
Summary: Build fails on Java 21 due to invoker plug-in:
Unsupported class file major version 65
Key: SLING-12305
URL: https://issues.apache.org/jira/browse/SLING-12305
Project: Sling
Issue Type: Task
Affects Versions: OSGi Feature Maven Plugin 1.8.0
Reporter: Robert Munteanu
Assignee: Robert Munteanu
Fix For: OSGi Feature Maven Plugin 1.8.2
The invoker plugin-ins runs groovy scripts in the {{verify}} goal, and this
fails on Java 21 with
{noformat}
[INFO] --- invoker:3.5.1:integration-test (integration-test) @
slingfeature-maven-plugin ---
[INFO] Building: analyzer-apiregions-errors-detected/pom.xml
[INFO] run post-build script verify.groovy
[INFO] BUG! exception in phase 'semantic analysis' in source unit
'Script1.groovy' Unsupported class file major version 65
[INFO] analyzer-apiregions-errors-detected/pom.xml .. FAILED (3.0
s)
{noformat}
The stack trace seems to indicate that Groovy tries to parse Java 21 bytecode
and fails.
{noformat}
Caused by: java.lang.IllegalArgumentException: Unsupported class file major
version 65
at groovyjarjarasm.asm.ClassReader.(ClassReader.java:199)
at groovyjarjarasm.asm.ClassReader.(ClassReader.java:180)
at groovyjarjarasm.asm.ClassReader.(ClassReader.java:166)
at groovyjarjarasm.asm.ClassReader.(ClassReader.java:287)
at
org.codehaus.groovy.ast.decompiled.AsmDecompiler.parseClass(AsmDecompiler.java:83)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] SLING-12173 - Configuration errors in Eclipse for projects using the slingfeature-maven-plugin [sling-slingfeature-maven-plugin]
rombert commented on PR #82: URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/82#issuecomment-2076567925 Closed in favour of #83 -- 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-12173 - Configuration errors in Eclipse for projects using the slingfeature-maven-plugin [sling-slingfeature-maven-plugin]
rombert closed pull request #82: SLING-12173 - Configuration errors in Eclipse for projects using the slingfeature-maven-plugin URL: https://github.com/apache/sling-slingfeature-maven-plugin/pull/82 -- 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] [Commented] (SLING-12173) Configuration errors in Eclipse for projects using the slingfeature-maven-plugin
[
https://issues.apache.org/jira/browse/SLING-12173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840686#comment-17840686
]
Carsten Ziegeler commented on SLING-12173:
--
[~rombert] To be honest I prefer our wrapper over the other solutions; its much
simpler to use - it also is faster due to the hard coded factory.
> Configuration errors in Eclipse for projects using the
> slingfeature-maven-plugin
>
>
> Key: SLING-12173
> URL: https://issues.apache.org/jira/browse/SLING-12173
> Project: Sling
> Issue Type: Bug
> Components: Maven Plugins and Archetypes
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: OSGi Feature Maven Plugin 1.8.2
>
>
> The slingfeature-maven-plugin currently uses the Jakarta JSON implementation
> of the Apache Johnzon parser.
> I have noticed problems in the Eclipse IDE, where projects fail to update
> with hard to isolate errors (see below).
> {noformat}java.util.ServiceConfigurationError: jakarta.json.spi.JsonProvider:
> org.apache.johnzon.core.JsonProviderImpl not a subtype
> at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:593)
> at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1244)
> at
> java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1273)
> at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1309)
> at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1393)
> at jakarta.json.spi.JsonProvider.provider(JsonProvider.java:69)
> at jakarta.json.Json.createReader(Json.java:189)
> at
> org.apache.sling.feature.maven.JSONFeatures.read(JSONFeatures.java:64)
> at
> org.apache.sling.feature.maven.ProjectHelper.readFeatureFile(ProjectHelper.java:622)
> at
> org.apache.sling.feature.maven.Preprocessor.readProjectFeatures(Preprocessor.java:304)
> at
> org.apache.sling.feature.maven.Preprocessor.process(Preprocessor.java:145)
> at
> org.apache.sling.feature.maven.Preprocessor.process(Preprocessor.java:110)
> at
> org.apache.sling.feature.maven.extensions.DependencyLifecycleParticipant.afterProjectsRead(DependencyLifecycleParticipant.java:87)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.executeParticipants(ProjectRegistryManager.java:824)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.lambda$15(ProjectRegistryManager.java:791)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:214)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.lambda$14(ProjectRegistryManager.java:790)
> at java.base/java.util.HashMap$Values.forEach(HashMap.java:1065)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.lambda$11(ProjectRegistryManager.java:788)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:214)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.readMavenProjectFacades(ProjectRegistryManager.java:760)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.refresh(ProjectRegistryManager.java:392)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.refresh(ProjectRegistryManager.java:366)
> at
> org.eclipse.m2e.core.internal.project.registry.ProjectRegistryManager.refresh(ProjectRegistryManager.java:318)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.getProjectFacade(MavenBuilder.java:146)
> at
> org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.lambda$0(MavenBuilder.java:84)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:394)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:275)
> at
> org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:214)
> at
>
[jira] [Commented] (SLING-12197) cpconverter: Sling-Initial-Content directories created as nt:folder instead of sling:Folder
[
https://issues.apache.org/jira/browse/SLING-12197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840675#comment-17840675
]
Robert Munteanu commented on SLING-12197:
-
[~sseifert] - I did not have time to look into it in depth, but reading through
the description it seems like a clear incompatibility between the CP Converter
and Initial Content behaviour that we need to address. I don't know the
codebase that well either, so a fix is not immediate for me either,
unfortunately.
> cpconverter: Sling-Initial-Content directories created as nt:folder instead
> of sling:Folder
> ---
>
> Key: SLING-12197
> URL: https://issues.apache.org/jira/browse/SLING-12197
> Project: Sling
> Issue Type: Bug
> Components: Content-Package to Feature Model Converter
>Affects Versions: Content-Package to Feature Model Converter 1.3.4
>Reporter: Stefan Seifert
>Priority: Major
> Fix For: Content-Package to Feature Model Converter 1.3.8
>
> Attachments: io.wcm.handler.link-apps-1.10.2-cp2fm-converted.zip
>
>
> the cpconverter extracts Sling-Initial-Content from OSGi bundles and creates
> FileVault packages with the transformed content.
> this works well, but there is one difference when the resulting content
> package is installed compared when uploading the OSGi bundle with the
> Sling-Initial-Content directly:
> * the JCR Content Loader by defaults creates a {{sling:Folder}} node type for
> each directory found in the Sling-Initial-Content (see also
> [docs|https://sling.apache.org/documentation/bundles/content-loading-jcr-contentloader.html#initial-content-loading-1])
> * the cpconverter process creates no {{.content.xml}} file for the folders,
> but only for the actual JSON files found in the process. as a result, the
> folders are created as {{nt:folder}} when uploading the transformed package
> * this difference becomes relevant, when a JSON file in Sling-Initial-Content
> defines a primary type of {{nt:unstructured}} - it is not allowed to created
> such a node directly below a {{nt:folder}} node - but it is allowed to do so
> below a {{sling:Folder}} node
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] SLING-11906 Migrate to slf4j 2.x [sling-org-apache-sling-commons-log]
rombert commented on PR #18: URL: https://github.com/apache/sling-org-apache-sling-commons-log/pull/18#issuecomment-2076491663 > For your reference, I stashed my workaround fragment bundle project at: https://github.com/enapps-enorman/sling-org-apache-sling-slf4j1x-compatibility On that topic, I think the bundle may be useful in case we are ready with the switch before Oak is, thank you for preparing that. -- 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] [Updated] (SLING-12304) Broken backwards compatibility: out of order json object
[ https://issues.apache.org/jira/browse/SLING-12304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated SLING-12304: Fix Version/s: Commons JSON 2.0.28 > Broken backwards compatibility: out of order json object > > > Key: SLING-12304 > URL: https://issues.apache.org/jira/browse/SLING-12304 > Project: Sling > Issue Type: Bug >Affects Versions: Commons JSON 2.0.26 >Reporter: Remo Liechti >Priority: Critical > Fix For: Commons JSON 2.0.28 > > > The fix of CVE-2022-47937 introduced an invalid backwards compatibility for > the order in jsonobject. > New behaviour: has the keys unordered, as JsonObject uses a HashMap. > Old behaviour: Kept insertion order of keys as JsonObject used LinkedHashMap. > To no break existing users of the library, reestablish the old behaviour. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12304) Broken backwards compatibility: out of order json object
Remo Liechti created SLING-12304: Summary: Broken backwards compatibility: out of order json object Key: SLING-12304 URL: https://issues.apache.org/jira/browse/SLING-12304 Project: Sling Issue Type: Bug Affects Versions: Commons JSON 2.0.26 Reporter: Remo Liechti The fix of CVE-2022-47937 introduced an invalid backwards compatibility for the order in jsonobject. New behaviour: has the keys unordered, as JsonObject uses a HashMap. Old behaviour: Kept insertion order of keys as JsonObject used LinkedHashMap. To no break existing users of the library, reestablish the old behaviour. -- This message was sent by Atlassian Jira (v8.20.10#820010)
