[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=17841445#comment-17841445
]
Stefan Seifert commented on SLING-12197:
thanks for the analysis!
> 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=17841068#comment-17841068
]
Stefan Seifert commented on SLING-12197:
bq. 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.
yes, but in this case its about the ordering of (sticking to the unit test
example):
1. repoinit statements generated from {{io.wcm.handler.media-1.11.6.jar}}
2. content package {{io.wcm.handler.media-apps-1.11.6-cp2fm-converted.zip}}
with *immutable* content generated from {{io.wcm.handler.media-1.11.6.jar}},
containing nodes and scripts below {{/apps}}
they have to be executed in exactly this order - if the folders already exists
after installing the package the repoinit statements have no effect.
> 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] [Comment Edited] (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=17841068#comment-17841068
]
Stefan Seifert edited comment on SLING-12197 at 4/26/24 7:02 AM:
-
bq. 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.
yes, but in this case its about the ordering of (sticking to the unit test
example):
# repoinit statements generated from {{io.wcm.handler.media-1.11.6.jar}}
# content package {{io.wcm.handler.media-apps-1.11.6-cp2fm-converted.zip}} with
*immutable* content generated from {{io.wcm.handler.media-1.11.6.jar}},
containing nodes and scripts below {{/apps}}
they have to be executed in exactly this order - if the folders already exists
after installing the package the repoinit statements have no effect.
was (Author: sseif...@pro-vision.de):
bq. 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.
yes, but in this case its about the ordering of (sticking to the unit test
example):
1. repoinit statements generated from {{io.wcm.handler.media-1.11.6.jar}}
2. content package {{io.wcm.handler.media-apps-1.11.6-cp2fm-converted.zip}}
with *immutable* content generated from {{io.wcm.handler.media-1.11.6.jar}},
containing nodes and scripts below {{/apps}}
they have to be executed in exactly this order - if the folders already exists
after installing the package the repoinit statements have no effect.
> 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] [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)
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
[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: [VOTE] Release Apache Sling Rewriter 1.4.2
+1 stefan
[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=17840385#comment-17840385
]
Stefan Seifert commented on SLING-12197:
[~rombert] any news on this one?
we need to make sure cpconverter creates a {{.content.xml}} with
{{jcr:primaryType=sling:Folder}} for each folder found in Sling-Initial-Content
which do not have a node type defined explicitly, so it behaves the same as the
Sling Content Loader.
i looked again a bit deeper at the cpconverter implementation, but the handling
of Sling-Initial-Content and handing it over to the other processing is rather
complex, so i currently do not feel confident to come up with a quick patch.
> 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-12302) CA Config access syntax is inconsistent in HTL
[
https://issues.apache.org/jira/browse/SLING-12302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17840363#comment-17840363
]
Stefan Seifert commented on SLING-12302:
the first syntax
{noformat}
${caconfig['com.mysite.core.config.TestConfig/nested'].greeting} {noformat}
should be used.
that the second syntax with {{['nested/greeting']}} is working is probably only
by chance, as a normal value map is used if not annotation class is used, and
that supports by default accessing deeper resource hierarchy levels via
property access. this is not the case if annotation class is used, because
there the value map is constructed by other means, e.g. to support the default
values that may be defined in the annotation class.
sidenote: you should not use {{jcr:primaryType="sling:OsgiConfig"}} in context
of caconfig - it's only use is for defining osgi configurations in the JCR
repository, so using it here could have unwanted side-effect. just use
nt:unstructured (unless you are using a different persistence strategy e.g.
https://wcm.io/caconfig/extensions/ for storing in cq:Page objects).
> 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
>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] [Closed] (SLING-12278) Improve handling of late instantiated context in SlingContextExtension/OsgiContextExtension
[
https://issues.apache.org/jira/browse/SLING-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert closed SLING-12278.
--
> Improve handling of late instantiated context in
> SlingContextExtension/OsgiContextExtension
> ---
>
> Key: SLING-12278
> URL: https://issues.apache.org/jira/browse/SLING-12278
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.4.2, Testing Sling Mock 3.5.0
>Reporter: Konrad Windszus
>Assignee: Stefan Seifert
>Priority: Major
>
> Currently neither in
> https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
> nor in
> https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
> it is mentioned that the context must not be instantiated in {{@BeforeAll}}
> or {{@BeforeEach}} as at that point in time the extension has already
> instantiated another context. Those two contexts may lead to subtle issues
> (for example if resources are only added in the second context). For a
> concrete example look at
> https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
> In the best case the JUnit5 extension never creates a context (but only uses
> the existing instance) or at least creation should be deferred until the
> Before methods have been executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (SLING-12278) Improve handling of late instantiated context in SlingContextExtension/OsgiContextExtension
[
https://issues.apache.org/jira/browse/SLING-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert resolved SLING-12278.
Resolution: Fixed
https://github.com/apache/sling-site/commit/5c122e825c6cf212e74fadeb2e6cc2afce0666a8
> Improve handling of late instantiated context in
> SlingContextExtension/OsgiContextExtension
> ---
>
> Key: SLING-12278
> URL: https://issues.apache.org/jira/browse/SLING-12278
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.4.2, Testing Sling Mock 3.5.0
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently neither in
> https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
> nor in
> https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
> it is mentioned that the context must not be instantiated in {{@BeforeAll}}
> or {{@BeforeEach}} as at that point in time the extension has already
> instantiated another context. Those two contexts may lead to subtle issues
> (for example if resources are only added in the second context). For a
> concrete example look at
> https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
> In the best case the JUnit5 extension never creates a context (but only uses
> the existing instance) or at least creation should be deferred until the
> Before methods have been executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (SLING-12278) Improve handling of late instantiated context in SlingContextExtension/OsgiContextExtension
[
https://issues.apache.org/jira/browse/SLING-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert reassigned SLING-12278:
--
Assignee: Stefan Seifert
> Improve handling of late instantiated context in
> SlingContextExtension/OsgiContextExtension
> ---
>
> Key: SLING-12278
> URL: https://issues.apache.org/jira/browse/SLING-12278
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.4.2, Testing Sling Mock 3.5.0
>Reporter: Konrad Windszus
>Assignee: Stefan Seifert
>Priority: Major
>
> Currently neither in
> https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
> nor in
> https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
> it is mentioned that the context must not be instantiated in {{@BeforeAll}}
> or {{@BeforeEach}} as at that point in time the extension has already
> instantiated another context. Those two contexts may lead to subtle issues
> (for example if resources are only added in the second context). For a
> concrete example look at
> https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
> In the best case the JUnit5 extension never creates a context (but only uses
> the existing instance) or at least creation should be deferred until the
> Before methods have been executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (SLING-12278) Improve handling of late instantiated context in SlingContextExtension/OsgiContextExtension
[
https://issues.apache.org/jira/browse/SLING-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839637#comment-17839637
]
Stefan Seifert commented on SLING-12278:
documentation PR: https://github.com/apache/sling-site/pull/159
> Improve handling of late instantiated context in
> SlingContextExtension/OsgiContextExtension
> ---
>
> Key: SLING-12278
> URL: https://issues.apache.org/jira/browse/SLING-12278
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.4.2, Testing Sling Mock 3.5.0
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently neither in
> https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
> nor in
> https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
> it is mentioned that the context must not be instantiated in {{@BeforeAll}}
> or {{@BeforeEach}} as at that point in time the extension has already
> instantiated another context. Those two contexts may lead to subtle issues
> (for example if resources are only added in the second context). For a
> concrete example look at
> https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
> In the best case the JUnit5 extension never creates a context (but only uses
> the existing instance) or at least creation should be deferred until the
> Before methods have been executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (SLING-12278) Improve handling of late instantiated context in SlingContextExtension/OsgiContextExtension
[
https://issues.apache.org/jira/browse/SLING-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Seifert updated SLING-12278:
---
Component/s: Testing
Affects Version/s: Testing Sling Mock 3.5.0
Testing OSGi Mock 3.4.2
the way the current junit 5 implemention is done in sling-mock, osgi-mock and
aem-mock dates back to the time of JUnit 5.0 ([PR
#5|[https://github.com/wcm-io/wcm-io-testing/pull/5]),] and i've never
investigated much further if this is nowadays still the best way to do an junit
5 extension. it seems the programmatic extension registration was introduced in
junit 5.1.
i currently cannot oversee how much benefit a switch or additional support of
programmatic extension registration would bring - in any case it would be a lot
of work to make sure it all works as expected, and we cannot remove the current
way to register it for backwards compatibility.
so for now, i will only extend the documentation to make sure context objects
are not created e.g. in BeforeEach/BeforeAll methods.
> Improve handling of late instantiated context in
> SlingContextExtension/OsgiContextExtension
> ---
>
> Key: SLING-12278
> URL: https://issues.apache.org/jira/browse/SLING-12278
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.4.2, Testing Sling Mock 3.5.0
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently neither in
> https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
> nor in
> https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
> it is mentioned that the context must not be instantiated in {{@BeforeAll}}
> or {{@BeforeEach}} as at that point in time the extension has already
> instantiated another context. Those two contexts may lead to subtle issues
> (for example if resources are only added in the second context). For a
> concrete example look at
> https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
> In the best case the JUnit5 extension never creates a context (but only uses
> the existing instance) or at least creation should be deferred until the
> Before methods have been executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (SLING-12278) Improve handling of late instantiated context in SlingContextExtension/OsgiContextExtension
[
https://issues.apache.org/jira/browse/SLING-12278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839626#comment-17839626
]
Stefan Seifert edited comment on SLING-12278 at 4/22/24 11:51 AM:
--
the way the current junit 5 implemention is done in sling-mock, osgi-mock and
aem-mock dates back to the time of JUnit 5.0 ([PR
#5|https://github.com/wcm-io/wcm-io-testing/pull/5]), and i've never
investigated much further if this is nowadays still the best way to do an junit
5 extension. it seems the programmatic extension registration was introduced in
junit 5.1.
i currently cannot oversee how much benefit a switch or additional support of
programmatic extension registration would bring - in any case it would be a lot
of work to make sure it all works as expected, and we cannot remove the current
way to register it for backwards compatibility.
so for now, i will only extend the documentation to make sure context objects
are not created e.g. in BeforeEach/BeforeAll methods.
was (Author: sseif...@pro-vision.de):
the way the current junit 5 implemention is done in sling-mock, osgi-mock and
aem-mock dates back to the time of JUnit 5.0 ([PR
#5|[https://github.com/wcm-io/wcm-io-testing/pull/5]),] and i've never
investigated much further if this is nowadays still the best way to do an junit
5 extension. it seems the programmatic extension registration was introduced in
junit 5.1.
i currently cannot oversee how much benefit a switch or additional support of
programmatic extension registration would bring - in any case it would be a lot
of work to make sure it all works as expected, and we cannot remove the current
way to register it for backwards compatibility.
so for now, i will only extend the documentation to make sure context objects
are not created e.g. in BeforeEach/BeforeAll methods.
> Improve handling of late instantiated context in
> SlingContextExtension/OsgiContextExtension
> ---
>
> Key: SLING-12278
> URL: https://issues.apache.org/jira/browse/SLING-12278
> Project: Sling
> Issue Type: Improvement
> Components: Testing
>Affects Versions: Testing OSGi Mock 3.4.2, Testing Sling Mock 3.5.0
>Reporter: Konrad Windszus
>Priority: Major
>
> Currently neither in
> https://sling.apache.org/documentation/development/osgi-mock.html#junit-5-osgi-context-junit-extension
> nor in
> https://sling.apache.org/documentation/development/sling-mock.html#junit-5-sling-context-junit-extension
> it is mentioned that the context must not be instantiated in {{@BeforeAll}}
> or {{@BeforeEach}} as at that point in time the extension has already
> instantiated another context. Those two contexts may lead to subtle issues
> (for example if resources are only added in the second context). For a
> concrete example look at
> https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/37.
> In the best case the JUnit5 extension never creates a context (but only uses
> the existing instance) or at least creation should be deferred until the
> Before methods have been executed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
RE: [VOTE] Sling Engine 2.15.14
+1 stefan
[jira] [Closed] (SLING-12287) sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release
[ https://issues.apache.org/jira/browse/SLING-12287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12287. -- > sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release > > > Key: SLING-12287 > URL: https://issues.apache.org/jira/browse/SLING-12287 > Project: Sling > Issue Type: Improvement > Components: Testing > Reporter: Stefan Seifert > Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Sling Mock Oak 3.2.0-1.22.15, Testing Sling Mock > Oak 4.0.0-1.62.0 > > > following the discussion with [~reschke] in SLING-12266 we should move away > from oak 1.44 which is quite outdated. however, we need to ensure to keep > compatibility with the old 1.22.x version range to support all sorts of > projects using the mocks. > a solution might be to switch to a recent version of oak in the POM, and > create dedicated ITs to test against this and older 1.22.x versions to ensure > compatibility. > the benefit is, that all projects that are "just using" sling-mock-oak > without thinking about the dependency management (e.g. not using something > like [https://wcm.io/tooling/maven/aem-dependencies.html)] will get the > latest version which is better supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12266) Cache initial repository state to improve JCR_OAK performance
[ https://issues.apache.org/jira/browse/SLING-12266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12266. -- > Cache initial repository state to improve JCR_OAK performance > - > > Key: SLING-12266 > URL: https://issues.apache.org/jira/browse/SLING-12266 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga > Assignee: Stefan Seifert >Priority: Minor > Fix For: Testing Sling Mock Oak 3.2.0-1.22.15, Testing Sling Mock > 3.5.0, Testing Sling Mock Oak 4.0.0-1.62.0 > > > A lot of effort goes into preparing an Oak Mock repository from scratch: node > types need to be registered, indexes need to be created, and all this happens > over several commits. None of this work depends on the test case itself, so > it will always result in the exact same repository state. We could take the > root NodeState from the first repository we build, then build subsequent > repositories on top of it, avoiding most of the redundant work. Commits can > be relatively expensive even in memory, so each one we avoid can save a lot > of time in the long term. > > This would require extending the contract between Testing Sling Mock and the > ResourceResolverTypeAdapters, to add optional "make snapshot" and "build repo > from snapshot" operations. For adapters that don't support them, we would > keep rebuilding things from scratch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12265) Node type registration is inefficient during unit tests when using the JCR_OAK resolver type
[ https://issues.apache.org/jira/browse/SLING-12265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12265. -- > Node type registration is inefficient during unit tests when using the > JCR_OAK resolver type > > > Key: SLING-12265 > URL: https://issues.apache.org/jira/browse/SLING-12265 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga >Assignee: Stefan Seifert >Priority: Minor > Labels: performance > Fix For: Testing Sling Mock 3.5.0 > > > I did some profiling on my company's slow-running unit tests today, and found > that 70+% of the CPU time is spent inside NodeTypeDefinitionScanner, more > specifically in the commit() call triggered by it. Our test classpath > includes AEM Mocks and the Cloud SDK, resulting in 30+ CND files being > detected, and as many commits done preparing the repository before each test. > (Slightly more, because some commits fail and get retried later.) > It should be possible to parse each CND into memory structures in a separate > pass, then create the node types all at once in a single commit. This > wouldn't just eliminate the extra commits, but would also remove the need to > retry, since all dependencies would also be provided in the same call. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12296) sling-mock-oak: Update to Oak 1.62.0
[ https://issues.apache.org/jira/browse/SLING-12296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12296. -- > sling-mock-oak: Update to Oak 1.62.0 > > > Key: SLING-12296 > URL: https://issues.apache.org/jira/browse/SLING-12296 > Project: Sling > Issue Type: Improvement > Components: Testing > Reporter: Stefan Seifert > Assignee: Stefan Seifert >Priority: Minor > Fix For: Testing Sling Mock Oak 4.0.0-1.62.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12284) sling/jcr/osgi/resourceresolver-mock: Update to Parent 60, Java 11 Minimum Version
[ https://issues.apache.org/jira/browse/SLING-12284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12284. -- > sling/jcr/osgi/resourceresolver-mock: Update to Parent 60, Java 11 Minimum > Version > -- > > Key: SLING-12284 > URL: https://issues.apache.org/jira/browse/SLING-12284 > Project: Sling > Issue Type: Improvement > Components: Testing > Reporter: Stefan Seifert > Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Logging Mock 2.1.0, Testing Sling Mock Oak > 3.2.0-1.22.15, Context-Aware Configuration Mock Plugin 1.6.0, Testing JCR > Mock 1.7.0, Testing OSGi Mock 3.5.0, Testing ResourceResolver Mock 1.5.0, > Testing Sling Mock 3.5.0, Testing Sling Mock Oak 4.0.0-1.62.0 > > > update to parent 60, see also [https://cwiki.apache.org/confluence/x/SI75E] > this drops java 8 support, and instead supports java 11, 17, 21 - build is > done with java 17 > minimum java requirement for runtime is java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[RESULT] [VOTE] Release Apache Sling Testing Sling Mock Oak 3.2.0-1.22.15
Hi, The vote has passed with the following result : +1 (binding): Stefan Seifert, Jörg Hoh, Radu Cotescu, Robert Munteanu I will copy this release to the Sling dist directory and promote the artifacts to the central Maven repository. stefan
[RESULT] [VOTE] Release Apache Sling Testing Sling Mock 3.5.0, Sling Mock Oak 4.0.0-1.62.0
Hi, The vote has passed with the following result : +1 (binding): Stefan Seifert, Jörg Hoh, Radu Cotescu, Robert Munteanu I will copy this release to the Sling dist directory and promote the artifacts to the central Maven repository. stefan
RE: [VOTE] Release Apache Sling Rewriter 1.4.0
+1 stefan
RE: [Vote] Release Apache Sling Engine 2.15.12
+1 stefan
RE: [VOTE] Release Apache Sling Testing Sling Mock 3.5.0, Sling Mock Oak 4.0.0-1.62.0
+1 stefan
RE: [VOTE] Release Apache Sling Testing Sling Mock Oak 3.2.0-1.22.15
+1 stefan
[VOTE] Release Apache Sling Testing Sling Mock 3.5.0, Sling Mock Oak 4.0.0-1.62.0
Hi, Testing Sling Mock 3.5.0 (3 issues) https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12354169=Text=12310710 Testing Sling Mock Oak 4.0.0-1.62.0 (7 issues) https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12354581=Text=12310710 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2848/ 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 2848 /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. stefan
[VOTE] Release Apache Sling Testing Sling Mock Oak 3.2.0-1.22.15
Hi, We solved 6 issues in this release: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12353253=Text=12310710 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2849/ 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 2849 /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. stefan
[jira] [Resolved] (SLING-12296) sling-mock-oak: Update to Oak 1.62.0
[ https://issues.apache.org/jira/browse/SLING-12296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12296. Resolution: Fixed https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/commit/68e22b7f3087f1caafbc457ddb2b20df7e8c1beb > sling-mock-oak: Update to Oak 1.62.0 > > > Key: SLING-12296 > URL: https://issues.apache.org/jira/browse/SLING-12296 > Project: Sling > Issue Type: Improvement > Components: Testing > Reporter: Stefan Seifert > Assignee: Stefan Seifert >Priority: Minor > Fix For: Testing Sling Mock Oak 4.0.0-1.62.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12296) sling-mock-oak: Update to Oak 1.62.0
Stefan Seifert created SLING-12296: -- Summary: sling-mock-oak: Update to Oak 1.62.0 Key: SLING-12296 URL: https://issues.apache.org/jira/browse/SLING-12296 Project: Sling Issue Type: Improvement Components: Testing Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Testing Sling Mock Oak 4.0.0-1.62.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12287) sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release
[ https://issues.apache.org/jira/browse/SLING-12287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12287. Resolution: Fixed * 4.x: (master): [https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/commit/d4f0388ac9cf592a218230ee01cf14a6c3a93463] * 3.2.x: https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/commit/edf70e21c3e06b9e4960d99332669050727c7251 > sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release > > > Key: SLING-12287 > URL: https://issues.apache.org/jira/browse/SLING-12287 > Project: Sling > Issue Type: Improvement > Components: Testing > Reporter: Stefan Seifert > Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Sling Mock Oak 3.2.0-1.22.15, Testing Sling Mock > Oak 4.0.0-1.60.0 > > > following the discussion with [~reschke] in SLING-12266 we should move away > from oak 1.44 which is quite outdated. however, we need to ensure to keep > compatibility with the old 1.22.x version range to support all sorts of > projects using the mocks. > a solution might be to switch to a recent version of oak in the POM, and > create dedicated ITs to test against this and older 1.22.x versions to ensure > compatibility. > the benefit is, that all projects that are "just using" sling-mock-oak > without thinking about the dependency management (e.g. not using something > like [https://wcm.io/tooling/maven/aem-dependencies.html)] will get the > latest version which is better supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SLING-12287) sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release
[ https://issues.apache.org/jira/browse/SLING-12287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836439#comment-17836439 ] Stefan Seifert edited comment on SLING-12287 at 4/17/24 2:00 PM: - looking deeper into this, i think it's not easy possible to have a single JAR/POM supporting both oak 1.22 and latest oak version at the same time. there is too much change between them, regarding supported jdks and the change guava is embedded. i currently plan to do a branching of sling-mock-oak - one maintenance branch for 1.22.x and one for latest versions - this is in-line how oak itself it is doing. i started two draft PRs and will continue test the produced JARs in different project environments if this is working. maybe we can eliminate more of the shading/embedding in the latest sling-mock-oak version which would be a good thing. * sling-mock-oak 4.x with Oak 1.60: [https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/pull/14] * sling-mock-oak 3.2.x with Oak 1.22: [https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/pull/13] was (Author: sseif...@pro-vision.de): looking deeper into this, i think it's not easy possible to have a single JAR/POM supporting both oak 1.22 and latest oak version at the same time. there is too much change between them, regarding supported jdks and the change guava is embedded. i currently plan to do a branching of sling-mock-oak - one maintenance branch for 1.22.x and one for latest versions - this is in-line how oak itself it is doing. i started two draft PRs and will continue test the produced JARs in different project environments if this is working. maybe we can eliminate more of the shading/embedding in the latest sling-mock-oak version which would be a good thing. * sling-mock-oak 4.x with Oak 1.60: https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/pull/13 * sling-mock-oak 3.2.x with Oak 1.22: https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/pull/14 > sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release > > > Key: SLING-12287 > URL: https://issues.apache.org/jira/browse/SLING-12287 > Project: Sling > Issue Type: Improvement > Components: Testing > Reporter: Stefan Seifert > Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Sling Mock Oak 3.2.0-1.22.15, Testing Sling Mock > Oak 4.0.0-1.60.0 > > > following the discussion with [~reschke] in SLING-12266 we should move away > from oak 1.44 which is quite outdated. however, we need to ensure to keep > compatibility with the old 1.22.x version range to support all sorts of > projects using the mocks. > a solution might be to switch to a recent version of oak in the POM, and > create dedicated ITs to test against this and older 1.22.x versions to ensure > compatibility. > the benefit is, that all projects that are "just using" sling-mock-oak > without thinking about the dependency management (e.g. not using something > like [https://wcm.io/tooling/maven/aem-dependencies.html)] will get the > latest version which is better supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12287) sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release
[ https://issues.apache.org/jira/browse/SLING-12287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated SLING-12287: --- Fix Version/s: Testing Sling Mock Oak 4.0.0-1.60.0 > sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release > > > Key: SLING-12287 > URL: https://issues.apache.org/jira/browse/SLING-12287 > Project: Sling > Issue Type: Improvement > Components: Testing > Reporter: Stefan Seifert > Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Sling Mock Oak 3.2.0-1.22.15, Testing Sling Mock > Oak 4.0.0-1.60.0 > > > following the discussion with [~reschke] in SLING-12266 we should move away > from oak 1.44 which is quite outdated. however, we need to ensure to keep > compatibility with the old 1.22.x version range to support all sorts of > projects using the mocks. > a solution might be to switch to a recent version of oak in the POM, and > create dedicated ITs to test against this and older 1.22.x versions to ensure > compatibility. > the benefit is, that all projects that are "just using" sling-mock-oak > without thinking about the dependency management (e.g. not using something > like [https://wcm.io/tooling/maven/aem-dependencies.html)] will get the > latest version which is better supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12287) sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release
[ https://issues.apache.org/jira/browse/SLING-12287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated SLING-12287: --- Summary: sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release (was: sling-mock-oak: Use latest Oak Version and add ITs to ensure compatiblity with 1.22.x) > sling-mock-oak: Update to Oak 1.60 and provide separate 1.22 release > > > Key: SLING-12287 > URL: https://issues.apache.org/jira/browse/SLING-12287 > Project: Sling > Issue Type: Improvement > Components: Testing > Reporter: Stefan Seifert > Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Sling Mock Oak 3.2.0-1.44.0 > > > following the discussion with [~reschke] in SLING-12266 we should move away > from oak 1.44 which is quite outdated. however, we need to ensure to keep > compatibility with the old 1.22.x version range to support all sorts of > projects using the mocks. > a solution might be to switch to a recent version of oak in the POM, and > create dedicated ITs to test against this and older 1.22.x versions to ensure > compatibility. > the benefit is, that all projects that are "just using" sling-mock-oak > without thinking about the dependency management (e.g. not using something > like [https://wcm.io/tooling/maven/aem-dependencies.html)] will get the > latest version which is better supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
RE: [VOTE] Release Apache Sling JUnit Tests Teleporter 1.0.26
+1 stefan
[jira] [Closed] (SLING-12281) Content Parser: Update to Parent 60, Java 11 Minimum Version
[ https://issues.apache.org/jira/browse/SLING-12281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12281. -- > Content Parser: Update to Parent 60, Java 11 Minimum Version > > > Key: SLING-12281 > URL: https://issues.apache.org/jira/browse/SLING-12281 > Project: Sling > Issue Type: Improvement > Components: Content Parser > Reporter: Stefan Seifert > Assignee: Stefan Seifert >Priority: Major > Fix For: Content Parser API 2.1.0, Content Parser Test Utilities > 2.1.0, Content Parser JSON 2.1.0, Content Parser XML 2.1.0, Content Parser > XML JCR 2.1.0 > > > update to parent 60, regarding [https://cwiki.apache.org/confluence/x/SI75E] > this drops java 8 support, and instead supports java 11, 17, 21 - build is > done with java 17 > minimum java requirement for runtime is java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12102) Content Parser: Update to Parent 52
[ https://issues.apache.org/jira/browse/SLING-12102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12102. -- > Content Parser: Update to Parent 52 > --- > > Key: SLING-12102 > URL: https://issues.apache.org/jira/browse/SLING-12102 > Project: Sling > Issue Type: Improvement > Components: Content Parser >Affects Versions: Content Parser API 2.0.0, Content Parser JSON 2.0.0, > Content Parser XML 2.0.0, Content Parser XML JCR 2.0.0, Content Parser Test > Utilities 2.0.0 >Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Content Parser API 2.1.0, Content Parser Test Utilities > 2.1.0, Content Parser JSON 2.1.0, Content Parser XML 2.1.0, Content Parser > XML JCR 2.1.0 > > > update to latest parent, fix build with java 17 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12282) Content Parser: Update Dependencies to 2023
[ https://issues.apache.org/jira/browse/SLING-12282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12282. -- > Content Parser: Update Dependencies to 2023 > --- > > Key: SLING-12282 > URL: https://issues.apache.org/jira/browse/SLING-12282 > Project: Sling > Issue Type: Improvement > Components: Content Parser > Reporter: Stefan Seifert > Assignee: Stefan Seifert >Priority: Major > Fix For: Content Parser Test Utilities 2.1.0, Content Parser JSON > 2.1.0, Content Parser XML 2.1.0, Content Parser XML JCR 2.1.0 > > > in line with and using the same concept of SLING-12208 update 3rdparty > dependencies to a newer version for content parser modules -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12280) Migrate org.apache.sling.contentparser.json to jakarta.json
[ https://issues.apache.org/jira/browse/SLING-12280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12280. -- > Migrate org.apache.sling.contentparser.json to jakarta.json > --- > > Key: SLING-12280 > URL: https://issues.apache.org/jira/browse/SLING-12280 > Project: Sling > Issue Type: Sub-task > Components: Content Parser > Reporter: Stefan Seifert > Assignee: Stefan Seifert >Priority: Major > Fix For: Content Parser JSON 2.1.0 > > > to support johnzon 2.0 in unit tests with sling-mocks, we need to switch to > jakarta.json for the JSON content parser as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[RESULT] [VOTE] Release Apache Sling Content Parser JSON 2.1.0
Hi, The vote has passed with the following result : +1 (binding): Stefan Seifert, Robert Munteanu, Konrad Windszus I will copy this release to the Sling dist directory and promote the artifacts to the central Maven repository. stefan
RE: [VOTE] Release Apache Sling Commons JSON 2.0.26
+1 stefan
RE: [VOTE] Release Apache Sling Content Parser JSON 2.1.0
we need one more binding vote! steafn > -Original Message- > From: Stefan Seifert > Sent: Tuesday, April 9, 2024 12:15 PM > To: dev@sling.apache.org > Subject: [VOTE] Release Apache Sling Content Parser JSON 2.1.0 > > Hi, > > We solved 4 issues in this release: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12353724 > yleName=Text=12310710 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2844/ > > 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 2844 /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. > > stefan
[jira] [Commented] (SLING-12287) sling-mock-oak: Use latest Oak Version and add ITs to ensure compatiblity with 1.22.x
[ https://issues.apache.org/jira/browse/SLING-12287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836439#comment-17836439 ] Stefan Seifert commented on SLING-12287: looking deeper into this, i think it's not easy possible to have a single JAR/POM supporting both oak 1.22 and latest oak version at the same time. there is too much change between them, regarding supported jdks and the change guava is embedded. i currently plan to do a branching of sling-mock-oak - one maintenance branch for 1.22.x and one for latest versions - this is in-line how oak itself it is doing. i started two draft PRs and will continue test the produced JARs in different project environments if this is working. maybe we can eliminate more of the shading/embedding in the latest sling-mock-oak version which would be a good thing. * sling-mock-oak 4.x with Oak 1.60: https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/pull/13 * sling-mock-oak 3.2.x with Oak 1.22: https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/pull/14 > sling-mock-oak: Use latest Oak Version and add ITs to ensure compatiblity > with 1.22.x > - > > Key: SLING-12287 > URL: https://issues.apache.org/jira/browse/SLING-12287 > Project: Sling > Issue Type: Improvement > Components: Testing > Reporter: Stefan Seifert > Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Sling Mock Oak 3.2.0-1.44.0 > > > following the discussion with [~reschke] in SLING-12266 we should move away > from oak 1.44 which is quite outdated. however, we need to ensure to keep > compatibility with the old 1.22.x version range to support all sorts of > projects using the mocks. > a solution might be to switch to a recent version of oak in the POM, and > create dedicated ITs to test against this and older 1.22.x versions to ensure > compatibility. > the benefit is, that all projects that are "just using" sling-mock-oak > without thinking about the dependency management (e.g. not using something > like [https://wcm.io/tooling/maven/aem-dependencies.html)] will get the > latest version which is better supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
RE: [VOTE] Release Apache Sling Tenant 1.1.8
+1 stefan
[jira] [Resolved] (SLING-12266) Cache initial repository state to improve JCR_OAK performance
[ https://issues.apache.org/jira/browse/SLING-12266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12266. Fix Version/s: Testing Sling Mock Oak 3.2.0-1.44.0 Testing Sling Mock 3.5.0 Resolution: Fixed * [https://github.com/apache/sling-org-apache-sling-testing-sling-mock/commit/0fb97232b98a91bdca3b5accaa3d499175e4685b] * [https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/commit/7a8c92c3f6995c54d38aebecd8225d2fa3a2f5ee] * > Cache initial repository state to improve JCR_OAK performance > - > > Key: SLING-12266 > URL: https://issues.apache.org/jira/browse/SLING-12266 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga > Assignee: Stefan Seifert >Priority: Minor > Fix For: Testing Sling Mock Oak 3.2.0-1.44.0, Testing Sling Mock > 3.5.0 > > > A lot of effort goes into preparing an Oak Mock repository from scratch: node > types need to be registered, indexes need to be created, and all this happens > over several commits. None of this work depends on the test case itself, so > it will always result in the exact same repository state. We could take the > root NodeState from the first repository we build, then build subsequent > repositories on top of it, avoiding most of the redundant work. Commits can > be relatively expensive even in memory, so each one we avoid can save a lot > of time in the long term. > > This would require extending the contract between Testing Sling Mock and the > ResourceResolverTypeAdapters, to add optional "make snapshot" and "build repo > from snapshot" operations. For adapters that don't support them, we would > keep rebuilding things from scratch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12287) sling-mock-oak: Use latest Oak Version and add ITs to ensure compatiblity with 1.22.x
Stefan Seifert created SLING-12287: -- Summary: sling-mock-oak: Use latest Oak Version and add ITs to ensure compatiblity with 1.22.x Key: SLING-12287 URL: https://issues.apache.org/jira/browse/SLING-12287 Project: Sling Issue Type: Improvement Components: Testing Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Testing Sling Mock Oak 3.2.0-1.44.0 following the discussion with [~reschke] in SLING-12266 we should move away from oak 1.44 which is quite outdated. however, we need to ensure to keep compatibility with the old 1.22.x version range to support all sorts of projects using the mocks. a solution might be to switch to a recent version of oak in the POM, and create dedicated ITs to test against this and older 1.22.x versions to ensure compatibility. the benefit is, that all projects that are "just using" sling-mock-oak without thinking about the dependency management (e.g. not using something like [https://wcm.io/tooling/maven/aem-dependencies.html)] will get the latest version which is better supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12266) Cache initial repository state to improve JCR_OAK performance
[ https://issues.apache.org/jira/browse/SLING-12266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836068#comment-17836068 ] Stefan Seifert commented on SLING-12266: ah, ok. there was some need form other sling modules to have a slightly newer version from oak in sling-mock-oak than 1.22, so we are currently between chairs of supporting the "old and the new world". usually, the actual version that is used in the unit tests should be controlled by the project environment e.g. when using [https://wcm.io/tooling/maven/aem-dependencies.html] for either AEMaaCS or AEM 6.5, so this is a bit of an academic discussion. of course, there may be projects that to not care about that dependency management and end up with 1.44. we might think about a way to ensure compatibility with different old and new versions in CI and use a newer version in the POM. however, this is off-topic for this ticket. [~Csaba Varga] it would be great if you can remove the makeJcr optimization then we can merge the PRs. > Cache initial repository state to improve JCR_OAK performance > - > > Key: SLING-12266 > URL: https://issues.apache.org/jira/browse/SLING-12266 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga >Assignee: Stefan Seifert >Priority: Minor > > A lot of effort goes into preparing an Oak Mock repository from scratch: node > types need to be registered, indexes need to be created, and all this happens > over several commits. None of this work depends on the test case itself, so > it will always result in the exact same repository state. We could take the > root NodeState from the first repository we build, then build subsequent > repositories on top of it, avoiding most of the redundant work. Commits can > be relatively expensive even in memory, so each one we avoid can save a lot > of time in the long term. > > This would require extending the contract between Testing Sling Mock and the > ResourceResolverTypeAdapters, to add optional "make snapshot" and "build repo > from snapshot" operations. For adapters that don't support them, we would > keep rebuilding things from scratch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12266) Cache initial repository state to improve JCR_OAK performance
[ https://issues.apache.org/jira/browse/SLING-12266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836059#comment-17836059 ] Stefan Seifert commented on SLING-12266: yes - and we should be using that oak 1.22.x version in all sling mocks, sling-mock-oak is using 1.44 > Cache initial repository state to improve JCR_OAK performance > - > > Key: SLING-12266 > URL: https://issues.apache.org/jira/browse/SLING-12266 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga > Assignee: Stefan Seifert >Priority: Minor > > A lot of effort goes into preparing an Oak Mock repository from scratch: node > types need to be registered, indexes need to be created, and all this happens > over several commits. None of this work depends on the test case itself, so > it will always result in the exact same repository state. We could take the > root NodeState from the first repository we build, then build subsequent > repositories on top of it, avoiding most of the redundant work. Commits can > be relatively expensive even in memory, so each one we avoid can save a lot > of time in the long term. > > This would require extending the contract between Testing Sling Mock and the > ResourceResolverTypeAdapters, to add optional "make snapshot" and "build repo > from snapshot" operations. For adapters that don't support them, we would > keep rebuilding things from scratch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12266) Cache initial repository state to improve JCR_OAK performance
[ https://issues.apache.org/jira/browse/SLING-12266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836054#comment-17836054 ] Stefan Seifert commented on SLING-12266: i tested both PRs locally with the unit tests from aem-mock (which runs all tests on all resource resolver types), and it again was a considerable improvement in run time (from 45s to 32s on my machine). i did not see any difference with and without [https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/pull/12/commits/11de72022bf969e7253c6f6725b528963d3638db,] so i recommend to remove this optimization again - it seems oak is smart enough to not re-register the CND files again or it does not make a difference. concerning the latest jackrabbit/oak versions: we have an eye on this, but as described in SLING-12208 we have to maintain a wide range of compatibility for project contexts these mocks are used. esp. if used in AEM 6.x context, a very old oak version is still in use, and we have to support this. that's why we cannot always update to latest and greatest in the mocks here. > Cache initial repository state to improve JCR_OAK performance > - > > Key: SLING-12266 > URL: https://issues.apache.org/jira/browse/SLING-12266 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga > Assignee: Stefan Seifert >Priority: Minor > > A lot of effort goes into preparing an Oak Mock repository from scratch: node > types need to be registered, indexes need to be created, and all this happens > over several commits. None of this work depends on the test case itself, so > it will always result in the exact same repository state. We could take the > root NodeState from the first repository we build, then build subsequent > repositories on top of it, avoiding most of the redundant work. Commits can > be relatively expensive even in memory, so each one we avoid can save a lot > of time in the long term. > > This would require extending the contract between Testing Sling Mock and the > ResourceResolverTypeAdapters, to add optional "make snapshot" and "build repo > from snapshot" operations. For adapters that don't support them, we would > keep rebuilding things from scratch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12266) Cache initial repository state to improve JCR_OAK performance
[ https://issues.apache.org/jira/browse/SLING-12266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835756#comment-17835756 ] Stefan Seifert commented on SLING-12266: the approach looks good to me in general. it would be nice if there is a way to avoid code like [https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/pull/12/commits/11de72022bf969e7253c6f6725b528963d3638db] which seems to duplicate some logic from the Jcr class implementation. but i have too less insight there from an oak impl perspective. [~reschke] can you have a look at PR [https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/pull/12] as well from an oak perspective? > Cache initial repository state to improve JCR_OAK performance > - > > Key: SLING-12266 > URL: https://issues.apache.org/jira/browse/SLING-12266 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga >Priority: Minor > > A lot of effort goes into preparing an Oak Mock repository from scratch: node > types need to be registered, indexes need to be created, and all this happens > over several commits. None of this work depends on the test case itself, so > it will always result in the exact same repository state. We could take the > root NodeState from the first repository we build, then build subsequent > repositories on top of it, avoiding most of the redundant work. Commits can > be relatively expensive even in memory, so each one we avoid can save a lot > of time in the long term. > > This would require extending the contract between Testing Sling Mock and the > ResourceResolverTypeAdapters, to add optional "make snapshot" and "build repo > from snapshot" operations. For adapters that don't support them, we would > keep rebuilding things from scratch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SLING-12266) Cache initial repository state to improve JCR_OAK performance
[ https://issues.apache.org/jira/browse/SLING-12266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert reassigned SLING-12266: -- Assignee: Stefan Seifert > Cache initial repository state to improve JCR_OAK performance > - > > Key: SLING-12266 > URL: https://issues.apache.org/jira/browse/SLING-12266 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga > Assignee: Stefan Seifert >Priority: Minor > > A lot of effort goes into preparing an Oak Mock repository from scratch: node > types need to be registered, indexes need to be created, and all this happens > over several commits. None of this work depends on the test case itself, so > it will always result in the exact same repository state. We could take the > root NodeState from the first repository we build, then build subsequent > repositories on top of it, avoiding most of the redundant work. Commits can > be relatively expensive even in memory, so each one we avoid can save a lot > of time in the long term. > > This would require extending the contract between Testing Sling Mock and the > ResourceResolverTypeAdapters, to add optional "make snapshot" and "build repo > from snapshot" operations. For adapters that don't support them, we would > keep rebuilding things from scratch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12284) sling/jcr/osgi/resourceresolver-mock: Update to Parent 60, Java 11 Minimum Version
[ https://issues.apache.org/jira/browse/SLING-12284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12284. Resolution: Fixed logging-mock * [https://github.com/apache/sling-org-apache-sling-testing-logging-mock/commit/cb4e079f89240290e32ec0d2ba103be89707a33a] * [https://github.com/apache/sling-org-apache-sling-testing-logging-mock/commit/3ed3f3eb7fd4f9ea0910a7619d4c3a6f8dcf4cde] * [https://github.com/apache/sling-org-apache-sling-testing-logging-mock/commit/77933617b033b98ba983fa9e00bea5fea548ef3d] jcr-mock * [https://github.com/apache/sling-org-apache-sling-testing-jcr-mock/commit/74f6c497295699a66db3d6fd2f9147f8faa24404] * [https://github.com/apache/sling-org-apache-sling-testing-jcr-mock/commit/423f2856db8d03d5accb12dd3b55c5fc6311c020] * [https://github.com/apache/sling-org-apache-sling-testing-jcr-mock/commit/2b964f2b6e7db301aa51258deffa7af7f53a98e2] osgi-mock * [https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/commit/771ed600ac3347f8f0c563e10a06fd0ed73d2d1a] * [https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/commit/5cb642928aab2001b8fbfb326ea92b58f713b4de] * [https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/commit/dbc9d3051a741de52c64ea6c32bd00b883c8fdbb] resourceresolver-mock * [https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/commit/b86313a0fb75f067ddcddd5b184e032c17e27434] * [https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/commit/d4090be2060ec63d87f1a505b9ca5c0a1fc3] * [https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/commit/0f2acd051d0bf40139e19ea58787931c8b9bf02b] sling-mock * [https://github.com/apache/sling-org-apache-sling-testing-sling-mock/commit/bf72c05b952fc688442e0d0a3bc3c7ea2df3f478] * [https://github.com/apache/sling-org-apache-sling-testing-sling-mock/commit/74c1f1ec587abb9dcf8a115aa8fe4b5eee6b9f72] * [https://github.com/apache/sling-org-apache-sling-testing-sling-mock/commit/211ce26e26de49822fad6bad3ce6dd4941b80dd0] sling-mock-oak * [https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/commit/16c34e2aa6f8cbfb384ddb324d6b3a6bc51f48a4] * [https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/commit/61ee823f52beeca205edd2aafbf5b0f2779c6619] * [https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/commit/7998acc66ba183b371839f27f1a9cfaa46b4ea07] caconfig-mock-plugin * [https://github.com/apache/sling-org-apache-sling-testing-caconfig-mock-plugin/commit/fd5f9e100d7de2125a3a2731367d04d4d926b94e] * [https://github.com/apache/sling-org-apache-sling-testing-caconfig-mock-plugin/commit/1468f9ec381a74a2c4e59cda67e3e296210ede34] * [https://github.com/apache/sling-org-apache-sling-testing-caconfig-mock-plugin/commit/c3b5889cc26b0900baadb2cd4c350707d215ffa2] > sling/jcr/osgi/resourceresolver-mock: Update to Parent 60, Java 11 Minimum > Version > -- > > Key: SLING-12284 > URL: https://issues.apache.org/jira/browse/SLING-12284 > Project: Sling > Issue Type: Improvement > Components: Testing > Reporter: Stefan Seifert > Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Logging Mock 2.1.0, Testing Sling Mock Oak > 3.2.0-1.44.0, Context-Aware Configuration Mock Plugin 1.6.0, Testing JCR Mock > 1.7.0, Testing OSGi Mock 3.5.0, Testing ResourceResolver Mock 1.5.0, Testing > Sling Mock 3.5.0 > > > update to parent 60, see also [https://cwiki.apache.org/confluence/x/SI75E] > this drops java 8 support, and instead supports java 11, 17, 21 - build is > done with java 17 > minimum java requirement for runtime is java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12265) Node type registration is inefficient during unit tests when using the JCR_OAK resolver type
[ https://issues.apache.org/jira/browse/SLING-12265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12265. Fix Version/s: Testing Sling Mock 3.5.0 Resolution: Fixed https://github.com/apache/sling-org-apache-sling-testing-sling-mock/commit/4ff35ad95143d85bc1f91888cd53a3f624f86e06 > Node type registration is inefficient during unit tests when using the > JCR_OAK resolver type > > > Key: SLING-12265 > URL: https://issues.apache.org/jira/browse/SLING-12265 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga >Assignee: Stefan Seifert >Priority: Minor > Labels: performance > Fix For: Testing Sling Mock 3.5.0 > > > I did some profiling on my company's slow-running unit tests today, and found > that 70+% of the CPU time is spent inside NodeTypeDefinitionScanner, more > specifically in the commit() call triggered by it. Our test classpath > includes AEM Mocks and the Cloud SDK, resulting in 30+ CND files being > detected, and as many commits done preparing the repository before each test. > (Slightly more, because some commits fail and get retried later.) > It should be possible to parse each CND into memory structures in a separate > pass, then create the node types all at once in a single commit. This > wouldn't just eliminate the extra commits, but would also remove the need to > retry, since all dependencies would also be provided in the same call. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (SLING-12284) sling/jcr/osgi/resourceresolver-mock: Update to Parent 60, Java 11 Minimum Version
[ https://issues.apache.org/jira/browse/SLING-12284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert updated SLING-12284: --- Fix Version/s: Testing Logging Mock 2.1.0 Testing Sling Mock Oak 3.2.0-1.44.0 Context-Aware Configuration Mock Plugin 1.6.0 Testing JCR Mock 1.7.0 Testing OSGi Mock 3.5.0 Testing ResourceResolver Mock 1.5.0 Testing Sling Mock 3.5.0 > sling/jcr/osgi/resourceresolver-mock: Update to Parent 60, Java 11 Minimum > Version > -- > > Key: SLING-12284 > URL: https://issues.apache.org/jira/browse/SLING-12284 > Project: Sling > Issue Type: Improvement > Components: Testing > Reporter: Stefan Seifert > Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Logging Mock 2.1.0, Testing Sling Mock Oak > 3.2.0-1.44.0, Context-Aware Configuration Mock Plugin 1.6.0, Testing JCR Mock > 1.7.0, Testing OSGi Mock 3.5.0, Testing ResourceResolver Mock 1.5.0, Testing > Sling Mock 3.5.0 > > > update to parent 60, see also [https://cwiki.apache.org/confluence/x/SI75E] > this drops java 8 support, and instead supports java 11, 17, 21 - build is > done with java 17 > minimum java requirement for runtime is java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12284) sling/jcr/osgi/resourceresolver-mock: Update to Parent 60, Java 11 Minimum Version
Stefan Seifert created SLING-12284: -- Summary: sling/jcr/osgi/resourceresolver-mock: Update to Parent 60, Java 11 Minimum Version Key: SLING-12284 URL: https://issues.apache.org/jira/browse/SLING-12284 Project: Sling Issue Type: Improvement Components: Testing Reporter: Stefan Seifert Assignee: Stefan Seifert update to parent 60, see also [https://cwiki.apache.org/confluence/x/SI75E] this drops java 8 support, and instead supports java 11, 17, 21 - build is done with java 17 minimum java requirement for runtime is java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12265) Node type registration is inefficient during unit tests when using the JCR_OAK resolver type
[ https://issues.apache.org/jira/browse/SLING-12265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835436#comment-17835436 ] Stefan Seifert commented on SLING-12265: thanks for the contribution! i've added comments in the PR. > Node type registration is inefficient during unit tests when using the > JCR_OAK resolver type > > > Key: SLING-12265 > URL: https://issues.apache.org/jira/browse/SLING-12265 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga >Assignee: Stefan Seifert >Priority: Minor > Labels: performance > > I did some profiling on my company's slow-running unit tests today, and found > that 70+% of the CPU time is spent inside NodeTypeDefinitionScanner, more > specifically in the commit() call triggered by it. Our test classpath > includes AEM Mocks and the Cloud SDK, resulting in 30+ CND files being > detected, and as many commits done preparing the repository before each test. > (Slightly more, because some commits fail and get retried later.) > It should be possible to parse each CND into memory structures in a separate > pass, then create the node types all at once in a single commit. This > wouldn't just eliminate the extra commits, but would also remove the need to > retry, since all dependencies would also be provided in the same call. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (SLING-12266) Cache initial repository state to improve JCR_OAK performance
[ https://issues.apache.org/jira/browse/SLING-12266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835343#comment-17835343 ] Stefan Seifert commented on SLING-12266: sounds like an idea worth to experiment with - we have to make sure that still for each test run a completely clean repository is prepared. i have not much experience with the related details of the in-memory oak we are using. if you can come up with a PR with your idea i would be happy to check it further. > Cache initial repository state to improve JCR_OAK performance > - > > Key: SLING-12266 > URL: https://issues.apache.org/jira/browse/SLING-12266 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga >Priority: Minor > > A lot of effort goes into preparing an Oak Mock repository from scratch: node > types need to be registered, indexes need to be created, and all this happens > over several commits. None of this work depends on the test case itself, so > it will always result in the exact same repository state. We could take the > root NodeState from the first repository we build, then build subsequent > repositories on top of it, avoiding most of the redundant work. Commits can > be relatively expensive even in memory, so each one we avoid can save a lot > of time in the long term. > > This would require extending the contract between Testing Sling Mock and the > ResourceResolverTypeAdapters, to add optional "make snapshot" and "build repo > from snapshot" operations. For adapters that don't support them, we would > keep rebuilding things from scratch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (SLING-12265) Node type registration is inefficient during unit tests when using the JCR_OAK resolver type
[ https://issues.apache.org/jira/browse/SLING-12265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert reassigned SLING-12265: -- Assignee: Stefan Seifert > Node type registration is inefficient during unit tests when using the > JCR_OAK resolver type > > > Key: SLING-12265 > URL: https://issues.apache.org/jira/browse/SLING-12265 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Csaba Varga >Assignee: Stefan Seifert >Priority: Minor > Labels: performance > > I did some profiling on my company's slow-running unit tests today, and found > that 70+% of the CPU time is spent inside NodeTypeDefinitionScanner, more > specifically in the commit() call triggered by it. Our test classpath > includes AEM Mocks and the Cloud SDK, resulting in 30+ CND files being > detected, and as many commits done preparing the repository before each test. > (Slightly more, because some commits fail and get retried later.) > It should be possible to parse each CND into memory structures in a separate > pass, then create the node types all at once in a single commit. This > wouldn't just eliminate the extra commits, but would also remove the need to > retry, since all dependencies would also be provided in the same call. -- This message was sent by Atlassian Jira (v8.20.10#820010)
RE: [VOTE] Release Apache Sling Content Parser JSON 2.1.0
+1 stefan
[VOTE] Release Apache Sling Content Parser JSON 2.1.0
Hi, We solved 4 issues in this release: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12353724=Text=12310710 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2844/ 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 2844 /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. stefan
[jira] [Resolved] (SLING-12282) Content Parser: Update Dependencies to 2023
[ https://issues.apache.org/jira/browse/SLING-12282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12282. Fix Version/s: Content Parser Test Utilities 2.0.2 Content Parser JSON 2.1.0 Content Parser XML 2.0.2 Content Parser XML JCR 2.0.2 Resolution: Fixed * [https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/4603719426ed0835622f8763f5e988e0f3204066] * [https://github.com/apache/sling-org-apache-sling-contentparser-testutils/commit/9f2285f0814829d7e46d7ae1e387a855a01e989d] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml/commit/7481cad4a4ab0908e37698cacfb3cbe2603a0536] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr/commit/7785f84968e7558fe12529d4afccb78d60e50932] > Content Parser: Update Dependencies to 2023 > --- > > Key: SLING-12282 > URL: https://issues.apache.org/jira/browse/SLING-12282 > Project: Sling > Issue Type: Improvement > Components: Content Parser > Reporter: Stefan Seifert > Assignee: Stefan Seifert >Priority: Major > Fix For: Content Parser Test Utilities 2.0.2, Content Parser JSON > 2.1.0, Content Parser XML 2.0.2, Content Parser XML JCR 2.0.2 > > > in line with and using the same concept of SLING-12208 update 3rdparty > dependencies to a newer version for content parser modules -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12282) Content Parser: Update Dependencies to 2023
Stefan Seifert created SLING-12282: -- Summary: Content Parser: Update Dependencies to 2023 Key: SLING-12282 URL: https://issues.apache.org/jira/browse/SLING-12282 Project: Sling Issue Type: Improvement Components: Content Parser Reporter: Stefan Seifert Assignee: Stefan Seifert in line with and using the same concept of SLING-12208 update 3rdparty dependencies to a newer version for content parser modules -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (SLING-12281) Content Parser: Update to Parent 60, Java 11 Minimum Version
[ https://issues.apache.org/jira/browse/SLING-12281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17835317#comment-17835317 ] Stefan Seifert edited comment on SLING-12281 at 4/9/24 9:18 AM: api * [https://github.com/apache/sling-org-apache-sling-contentparser-api/commit/5da0a66e4bd1fb665372a4fb032a559d2ad8a395] * [https://github.com/apache/sling-org-apache-sling-contentparser-api/commit/93ca1c43db8fd67d6f6f7feccdabc73cb8bb40a9] * [https://github.com/apache/sling-org-apache-sling-contentparser-api/commit/bfa02530164493302ff3725d8c39178b8965a908] * [https://github.com/apache/sling-org-apache-sling-contentparser-api/commit/d94752766a39a89c1338ecf9fa94b86c71bf4772] testutils * [https://github.com/apache/sling-org-apache-sling-contentparser-testutils/commit/eab27e12d2859c6abe0081bbaf222120df6b398b] * [https://github.com/apache/sling-org-apache-sling-contentparser-testutils/commit/044f9aac4e8f29490137a88a94dff2b6bae8182c] * [https://github.com/apache/sling-org-apache-sling-contentparser-testutils/commit/619c56e5256ea6c8901ea25d2f6cd47c80289ab6] json * [https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/003f277c5cbff1a9b1757b423a27e496b6313b6a] * [https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/c44e65544895cb2c2076e7a0aeebbb0585382733] * [https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/d1aa7a6b1908902bfe94f8f619a8a12cfa4b023d] * [https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/f298b41a7aadf3eba985afec5adff413bb5843bc] xml * [https://github.com/apache/sling-org-apache-sling-contentparser-xml/commit/edc6f841e62a011d37f90f64a61650f9d51a0f42] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml/commit/5af3f77f9eb497135a9cf641ef99f98e9c199986] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml/commit/4ca3c865cdafa504b1f6de6759cfa90500a07a91] xml-jcr * [https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr/commit/692df61a55137e855406e2713bedf3e820599f66] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr/commit/3b87b0e718eacdce1197bdb4f07e8160d0ec68b1] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr/commit/60b907ee5a4956573bcda1508329c9b381d0fe72] was (Author: sseif...@pro-vision.de): api * [https://github.com/apache/sling-org-apache-sling-contentparser-api/commit/5da0a66e4bd1fb665372a4fb032a559d2ad8a395] * [https://github.com/apache/sling-org-apache-sling-contentparser-api/commit/93ca1c43db8fd67d6f6f7feccdabc73cb8bb40a9] * [https://github.com/apache/sling-org-apache-sling-contentparser-api/commit/bfa02530164493302ff3725d8c39178b8965a908] testutils * [https://github.com/apache/sling-org-apache-sling-contentparser-testutils/commit/eab27e12d2859c6abe0081bbaf222120df6b398b] * [https://github.com/apache/sling-org-apache-sling-contentparser-testutils/commit/044f9aac4e8f29490137a88a94dff2b6bae8182c] * [https://github.com/apache/sling-org-apache-sling-contentparser-testutils/commit/619c56e5256ea6c8901ea25d2f6cd47c80289ab6] json * [https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/003f277c5cbff1a9b1757b423a27e496b6313b6a] * [https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/c44e65544895cb2c2076e7a0aeebbb0585382733] * [https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/d1aa7a6b1908902bfe94f8f619a8a12cfa4b023d] xml * [https://github.com/apache/sling-org-apache-sling-contentparser-xml/commit/edc6f841e62a011d37f90f64a61650f9d51a0f42] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml/commit/5af3f77f9eb497135a9cf641ef99f98e9c199986] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml/commit/4ca3c865cdafa504b1f6de6759cfa90500a07a91] xml-jcr * [https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr/commit/692df61a55137e855406e2713bedf3e820599f66] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr/commit/3b87b0e718eacdce1197bdb4f07e8160d0ec68b1] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr/commit/60b907ee5a4956573bcda1508329c9b381d0fe72] > Content Parser: Update to Parent 60, Java 11 Minimum Version > > > Key: SLING-12281 > URL: https://issues.apache.org/jira/browse/SLING-12281 > Project: Sling > Issue Type: Improvement > Components: Content Parser > Reporter: Stefan Seifert > Assignee: Stefan Seifert >Priority: Major > Fix For: Content Parser API 2.0.2, Content Parser Test Utilities > 2.0.2, Content Parser JSON 2.1.0, Content Parser XML 2.0.2, Content Parser &g
[jira] [Resolved] (SLING-12281) Content Parser: Update to Parent 60, Java 11 Minimum Version
[ https://issues.apache.org/jira/browse/SLING-12281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12281. Resolution: Fixed api * [https://github.com/apache/sling-org-apache-sling-contentparser-api/commit/5da0a66e4bd1fb665372a4fb032a559d2ad8a395] * [https://github.com/apache/sling-org-apache-sling-contentparser-api/commit/93ca1c43db8fd67d6f6f7feccdabc73cb8bb40a9] * [https://github.com/apache/sling-org-apache-sling-contentparser-api/commit/bfa02530164493302ff3725d8c39178b8965a908] testutils * [https://github.com/apache/sling-org-apache-sling-contentparser-testutils/commit/eab27e12d2859c6abe0081bbaf222120df6b398b] * [https://github.com/apache/sling-org-apache-sling-contentparser-testutils/commit/044f9aac4e8f29490137a88a94dff2b6bae8182c] * [https://github.com/apache/sling-org-apache-sling-contentparser-testutils/commit/619c56e5256ea6c8901ea25d2f6cd47c80289ab6] json * [https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/003f277c5cbff1a9b1757b423a27e496b6313b6a] * [https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/c44e65544895cb2c2076e7a0aeebbb0585382733] * [https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/d1aa7a6b1908902bfe94f8f619a8a12cfa4b023d] xml * [https://github.com/apache/sling-org-apache-sling-contentparser-xml/commit/edc6f841e62a011d37f90f64a61650f9d51a0f42] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml/commit/5af3f77f9eb497135a9cf641ef99f98e9c199986] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml/commit/4ca3c865cdafa504b1f6de6759cfa90500a07a91] xml-jcr * [https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr/commit/692df61a55137e855406e2713bedf3e820599f66] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr/commit/3b87b0e718eacdce1197bdb4f07e8160d0ec68b1] * [https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr/commit/60b907ee5a4956573bcda1508329c9b381d0fe72] > Content Parser: Update to Parent 60, Java 11 Minimum Version > > > Key: SLING-12281 > URL: https://issues.apache.org/jira/browse/SLING-12281 > Project: Sling > Issue Type: Improvement > Components: Content Parser > Reporter: Stefan Seifert > Assignee: Stefan Seifert >Priority: Major > Fix For: Content Parser API 2.0.2, Content Parser Test Utilities > 2.0.2, Content Parser JSON 2.1.0, Content Parser XML 2.0.2, Content Parser > XML JCR 2.0.2 > > > update to parent 60, regarding [https://cwiki.apache.org/confluence/x/SI75E] > this drops java 8 support, and instead supports java 11, 17, 21 - build is > done with java 17 > minimum java requirement for runtime is java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12281) Content Parser: Update to Parent 60, Java 11 Minimum Version
Stefan Seifert created SLING-12281: -- Summary: Content Parser: Update to Parent 60, Java 11 Minimum Version Key: SLING-12281 URL: https://issues.apache.org/jira/browse/SLING-12281 Project: Sling Issue Type: Improvement Components: Content Parser Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Content Parser API 2.0.2, Content Parser Test Utilities 2.0.2, Content Parser JSON 2.1.0, Content Parser XML 2.0.2, Content Parser XML JCR 2.0.2 update to parent 60, regarding [https://cwiki.apache.org/confluence/x/SI75E] this drops java 8 support, and instead supports java 11, 17, 21 - build is done with java 17 minimum java requirement for runtime is java 11 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (SLING-12280) Migrate org.apache.sling.contentparser.json to jakarta.json
[ https://issues.apache.org/jira/browse/SLING-12280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12280. Resolution: Fixed https://github.com/apache/sling-org-apache-sling-contentparser-json/commit/b9589121fd01e644c55ac9aae69dfe32f6fa5969 > Migrate org.apache.sling.contentparser.json to jakarta.json > --- > > Key: SLING-12280 > URL: https://issues.apache.org/jira/browse/SLING-12280 > Project: Sling > Issue Type: Sub-task > Components: Content Parser > Reporter: Stefan Seifert > Assignee: Stefan Seifert >Priority: Major > Fix For: Content Parser JSON 2.1.0 > > > to support johnzon 2.0 in unit tests with sling-mocks, we need to switch to > jakarta.json for the JSON content parser as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12280) Migrate org.apache.sling.contentparser.json to jakarta.json
Stefan Seifert created SLING-12280: -- Summary: Migrate org.apache.sling.contentparser.json to jakarta.json Key: SLING-12280 URL: https://issues.apache.org/jira/browse/SLING-12280 Project: Sling Issue Type: Sub-task Components: Content Parser Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Content Parser JSON 2.1.0 to support johnzon 2.0 in unit tests with sling-mocks, we need to switch to jakarta.json for the JSON content parser as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
adaptTo() 2024 - Important: Rescheduled to October 2024
Dear adaptTo() Community, Due to a trade fair taking place in Berlin at the same time as our event, hotel prices had risen sharply by the time of the original date. To offer you a high-quality event at a fair price, we have decided to move the date. We hope you will agree to this and look forward to seeing you in Berlin in October. New date for adaptTo() conference: 21st - 23rd October 2024 Tickets: We have extended the availability of Early Bird tickets until June 30th, and for Loyalty tickets until August 31st. https://adapt.to/tickets Call for Papers: Submit your talk now! Submission deadline is April 15th. https://adapt.to/cfp Your adaptTo() Conference Team
[jira] [Commented] (SLING-12234) Commons Log builds fail on Windows
[
https://issues.apache.org/jira/browse/SLING-12234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17827913#comment-17827913
]
Stefan Seifert commented on SLING-12234:
{quote}[~sseifert], Can you run the build successful on your local Windows?
{quote}
i can reproduce the problem on my windows machine. i started a bit debugging,
but did not found the root case with the temp file creation fails in
ITPackaingData:
{noformat}
java.io.IOException: Zugriff verweigert
at java.base/java.io.WinNTFileSystem.createFileExclusively(Native Method)
at java.base/java.io.File.createTempFile(File.java:2129)
at java.base/java.io.File.createTempFile(File.java:2175)
at
org.ops4j.pax.tinybundles.core.intern.BndBuilder.sink(BndBuilder.java:127)
at
org.ops4j.pax.tinybundles.core.intern.BndBuilder.createBundle(BndBuilder.java:100)
at
org.ops4j.pax.tinybundles.core.intern.BndBuilder.wrapWithBnd(BndBuilder.java:76)
at
org.ops4j.pax.tinybundles.core.intern.BndBuilder.build(BndBuilder.java:68)
at
org.ops4j.pax.tinybundles.core.intern.TinyBundleImpl.build(TinyBundleImpl.java:206)
at
org.apache.sling.commons.log.logback.integration.PackagingDataTestUtil.createTestBundle(PackagingDataTestUtil.java:59)
at
org.apache.sling.commons.log.logback.integration.ITPackagingData.packageDataWorking(ITPackagingData.java:148)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runLeafWithRetry(ContainerTestRunner.java:97)
at
org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChildWithRetry(ContainerTestRunner.java:84)
at
org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:75)
at
org.ops4j.pax.exam.invoker.junit.internal.ContainerTestRunner.runChild(ContainerTestRunner.java:43)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at
org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.invokeViaJUnit(JUnitProbeInvoker.java:124)
at
org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.findAndInvoke(JUnitProbeInvoker.java:97)
at
org.ops4j.pax.exam.invoker.junit.internal.JUnitProbeInvoker.call(JUnitProbeInvoker.java:73)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.invokeMethodOnService(RemoteFrameworkImpl.java:435)
at
org.ops4j.pax.swissbox.framework.RemoteFrameworkImpl.invokeMethodOnService(RemoteFrameworkImpl.java:408)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at
java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:359)
at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:200)
at java.rmi/sun.rmi.transport.Transport$1.run(Transport.java:197)
at java.base/java.security.AccessController.doPrivileged(Native Method)
at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:562)
at
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:796
adaptTo() 2024: Call for Papers, Early Bird Tickets
Dear adaptTo() Community, adaptTo() is returning to the vibrant Kulturbrauerei in Berlin from September 23rd to 25th 2024, for another edition of Europe's leading AEM Developer Conference. https://adapt.to/ The adaptTo() is a community event. Therefore we encourage everyone to participate. By covering various facets of the overall topics Adobe Experience Manager, Adobe Experience Cloud, and the underlying OSS projects Apache Sling, Apache Felix, and Apache Jackrabbit Oak, we set starting points for the community to discuss and interact. The Call for Papers has officially opened and you have now the chance to shape adaptTo(). Submissions are being accepted until 15th of April 2024. https://adapt.to/cfp Early Bird Tickets for the on-site adaptTo() 2024 are available now! We also offer a special Loyalty Discount for previous attendees. https://adapt.to/tickets Your adaptTo() Conference Team
[jira] [Commented] (SLING-12250) Adding Resource with sling:vanityPath set causes mismatch when resolving vanity URL (timing issue)
[ https://issues.apache.org/jira/browse/SLING-12250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17817033#comment-17817033 ] Stefan Seifert commented on SLING-12250: the initializing that part of sling resource resolver which also interprets the vanity paths changed a couple of times of the last years for performance and stability improvements, and is done mostly async in the latest release. as using vanity paths in unit test is more an edge case, it makes no sense to automatically wait for it's completion for all tests. if you have a test that really needs vanity paths, probably use libraries like [https://github.com/awaitility/awaitility] to wait until it's available and then proceed with the tests. > Adding Resource with sling:vanityPath set causes mismatch when resolving > vanity URL (timing issue) > -- > > Key: SLING-12250 > URL: https://issues.apache.org/jira/browse/SLING-12250 > Project: Sling > Issue Type: Bug > Components: Testing >Affects Versions: Testing Sling Mock 3.4.18 >Reporter: Henry Kuijpers >Priority: Major > > It could happen that a Resource containing sling:vanityPath is added and then > resolved, but the Resource did not end up yet in the vanity logic. > Observed with JCR_OAK mock context. > Adding Thread.sleep(1000) fixes the issue, but it's of course not a very good > solution. -- This message was sent by Atlassian Jira (v8.20.10#820010)
RE: [VOTE] Release Apache Sling Parent and Bundle Parent version 60
+1 after the release we should send a separate heads-up mail to the mailing list pointing to https://cwiki.apache.org/confluence/x/SI75E and the required steps to make sure everyone notices. stefan
RE: Sling Model Caching & GC problems
> @Joerg: Pauls mail never hit the mailing list. Can you forward it? must be a problem on you side - it's in the archives: https://lists.apache.org/thread/xj6qosnjtgxvdf1lh58zs1bv5lh0y0q6 stefan
RE: [VOTE] Release Apache Sling Commons Log 5.5.0
+1 stefan
[jira] [Closed] (SLING-12208) sling/jcr/osgi/resourceresolver-mock: Update Dependencies to 2023
[ https://issues.apache.org/jira/browse/SLING-12208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12208. -- > sling/jcr/osgi/resourceresolver-mock: Update Dependencies to 2023 > - > > Key: SLING-12208 > URL: https://issues.apache.org/jira/browse/SLING-12208 > Project: Sling > Issue Type: Improvement > Components: Testing > Reporter: Stefan Seifert > Assignee: Stefan Seifert >Priority: Major > Fix For: Testing JCR Mock 1.6.14, Testing Sling Mock Oak > 3.1.12-1.44.0, Testing ResourceResolver Mock 1.4.6, Testing OSGi Mock 3.4.2, > Testing Sling Mock 3.4.18 > > > every 1-2 years we update the dependencies of sling-mock and related mock > modules to a new "baseline" of dependencies. as sling-mock is used in a lot > of user projects with very different context (applications, deployment > target) we try to be as backwards-compatible as possible but dropping out > older versions from time to time. > the baseline we target for this ticket is: > [https://repo1.maven.org/maven2/io/wcm/maven/io.wcm.maven.aem-dependencies/6.5.17.0001/io.wcm.maven.aem-dependencies-6.5.17.0001.pom] > several dependencies from this POM esp. from Sling and Oak are not the latest > version from mid 2023, but it's a consistent baseline that is still used in a > lot of projects. > the goal is to stick to this baseline for the next 1-2 years and only deviate > from it with a good reason. such a reason might be security warnings in > artifact scanners - but only if it deviates not too much or in a potential > risky way from this baseline. > the goal is that all mock code that is written sticks to this baseline. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[RESULT] [VOTE] Release Apache Sling Testing JCR Mock 1.6.14, OSGi Mock 3.4.2, ResourceResolver Mock 1.4.6, Sling Mock 3.4.18
Hi, The vote has passed with the following result : +1 (binding): Stefan Seifert, Robert Munteanu, Jörg Hoh, Eric Norman I will copy this release to the Sling dist directory and promote the artifacts to the central Maven repository. stefan
RE: [VOTE] Release Apache Sling Servlets Resolver 2.11.0
+1 stefan
RE: [VOTE] Release Apache Sling Rewriter 1.3.10
+1 stefan
RE: [VOTE] Release Apache Sling Testing JCR Mock 1.6.14, OSGi Mock 3.4.2, ResourceResolver Mock 1.4.6, Sling Mock 3.4.18
+1 stefan
[VOTE] Release Apache Sling Testing JCR Mock 1.6.14, OSGi Mock 3.4.2, ResourceResolver Mock 1.4.6, Sling Mock 3.4.18
Hi, Testing JCR Mock 1.6.14 (1 issue) https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12354068=Text=12310710 Testing OSGi Mock 3.4.2 (1 issue) https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12353872=Text=12310710 Testing ResourceResolver Mock 1.4.6 (1 issue) https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12353544=Text=12310710 Testing Sling Mock 3.4.18 (1 issue) https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12354009=Text=12310710 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2832/ 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 2832 /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. stefan
RE: [VOTE] Release Apache Sling Testing Clients 3.0.22
+1 stefan
RE: [VOTE] Release Apache Sling Rewriter 1.3.8
+1 stefan
RE: [VOTE] Release Apache Sling JCR Jackrabbit Access Manager version 4.0.2
+1 stefan
[jira] [Resolved] (SLING-12208) sling/jcr/osgi/resourceresolver-mock: Update Dependencies to 2023
[ https://issues.apache.org/jira/browse/SLING-12208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert resolved SLING-12208. Resolution: Fixed * [https://github.com/apache/sling-org-apache-sling-testing-jcr-mock/commit/c9cf4bc35580394dcd2327cc25a3baf479647de3] * [https://github.com/apache/sling-org-apache-sling-testing-osgi-mock/commit/2ff8736b466ef13c449adb0bb3df125cd9430e63] * [https://github.com/apache/sling-org-apache-sling-testing-resourceresolver-mock/commit/34db5a5a8ad48adb7e041a135af6cc239cd65fe6] * [https://github.com/apache/sling-org-apache-sling-testing-sling-mock/commit/39a864df8893025de7db92cc55528d0fd0fda160] * [https://github.com/apache/sling-org-apache-sling-testing-sling-mock-oak/commit/83747eff96ad0804e5b772257edeb010317a8841] > sling/jcr/osgi/resourceresolver-mock: Update Dependencies to 2023 > - > > Key: SLING-12208 > URL: https://issues.apache.org/jira/browse/SLING-12208 > Project: Sling > Issue Type: Improvement > Components: Testing > Reporter: Stefan Seifert > Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Sling Mock Oak 3.1.12-1.44.0, Testing > ResourceResolver Mock 1.4.6, Testing OSGi Mock 3.4.2, Testing Sling Mock > 3.4.18, Testing JCR Mock 1.6.14 > > > every 1-2 years we update the dependencies of sling-mock and related mock > modules to a new "baseline" of dependencies. as sling-mock is used in a lot > of user projects with very different context (applications, deployment > target) we try to be as backwards-compatible as possible but dropping out > older versions from time to time. > the baseline we target for this ticket is: > [https://repo1.maven.org/maven2/io/wcm/maven/io.wcm.maven.aem-dependencies/6.5.17.0001/io.wcm.maven.aem-dependencies-6.5.17.0001.pom] > several dependencies from this POM esp. from Sling and Oak are not the latest > version from mid 2023, but it's a consistent baseline that is still used in a > lot of projects. > the goal is to stick to this baseline for the next 1-2 years and only deviate > from it with a good reason. such a reason might be security warnings in > artifact scanners - but only if it deviates not too much or in a potential > risky way from this baseline. > the goal is that all mock code that is written sticks to this baseline. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (SLING-12208) sling/jcr/osgi/resourceresolver-mock: Update Dependencies to 2023
Stefan Seifert created SLING-12208: -- Summary: sling/jcr/osgi/resourceresolver-mock: Update Dependencies to 2023 Key: SLING-12208 URL: https://issues.apache.org/jira/browse/SLING-12208 Project: Sling Issue Type: Improvement Components: Testing Reporter: Stefan Seifert Assignee: Stefan Seifert Fix For: Testing Sling Mock Oak 3.1.12-1.44.0, Testing ResourceResolver Mock 1.4.6, Testing OSGi Mock 3.4.2, Testing Sling Mock 3.4.18, Testing JCR Mock 1.6.14 every 1-2 years we update the dependencies of sling-mock and related mock modules to a new "baseline" of dependencies. as sling-mock is used in a lot of user projects with very different context (applications, deployment target) we try to be as backwards-compatible as possible but dropping out older versions from time to time. the baseline we target for this ticket is: [https://repo1.maven.org/maven2/io/wcm/maven/io.wcm.maven.aem-dependencies/6.5.17.0001/io.wcm.maven.aem-dependencies-6.5.17.0001.pom] several dependencies from this POM esp. from Sling and Oak are not the latest version from mid 2023, but it's a consistent baseline that is still used in a lot of projects. the goal is to stick to this baseline for the next 1-2 years and only deviate from it with a good reason. such a reason might be security warnings in artifact scanners - but only if it deviates not too much or in a potential risky way from this baseline. the goal is that all mock code that is written sticks to this baseline. -- This message was sent by Atlassian Jira (v8.20.10#820010)
RE: [VOTE] Release Apache Sling JCR Jackrabbit User Manager version 2.2.30
+1 stefan
RE: [VOTE] Release Apache Sling Testing JCR Mock version 1.6.12
+1 stefan
RE: [VOTE] Release Apache Sling Engine 2.15.10
+1 stefan
[jira] [Closed] (SLING-12192) caconfig-mock-plugin: Fix nested config path building when writing config with custom persistence strategies
[ https://issues.apache.org/jira/browse/SLING-12192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12192. -- > caconfig-mock-plugin: Fix nested config path building when writing config > with custom persistence strategies > > > Key: SLING-12192 > URL: https://issues.apache.org/jira/browse/SLING-12192 > Project: Sling > Issue Type: Bug > Components: Testing >Affects Versions: Context-Aware Configuration Mock Plugin 1.5.2 > Reporter: Stefan Seifert >Assignee: Stefan Seifert >Priority: Major > Fix For: Context-Aware Configuration Mock Plugin 1.5.4 > > > as reported in https://github.com/wcm-io/io.wcm.testing.aem-mock/issues/25 > there is currently an issue when custom persistence strategies are in place: > nested configurations may be written in invalid paths, resulting in not found > when reading the configuration again. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (SLING-12191) caconfig-mock-plugin: Update to Parent 52
[ https://issues.apache.org/jira/browse/SLING-12191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12191. -- > caconfig-mock-plugin: Update to Parent 52 > - > > Key: SLING-12191 > URL: https://issues.apache.org/jira/browse/SLING-12191 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Context-Aware Configuration Mock Plugin 1.5.2 > Reporter: Stefan Seifert > Assignee: Stefan Seifert >Priority: Minor > Fix For: Context-Aware Configuration Mock Plugin 1.5.4 > > > update to latest parent -- This message was sent by Atlassian Jira (v8.20.10#820010)
[RESULT] [VOTE] Release Apache Sling Context-Aware Configuration Mock Plugin 1.5.4
Hi, The vote has passed with the following result : +1 (binding): Stefan Seifert, Radu Cotescu, Robert Munteanu I will copy this release to the Sling dist directory and promote the artifacts to the central Maven repository. stefan
RE: [VOTE] Release Apache Sling Context-Aware Configuration Mock Plugin 1.5.4
i need one more binding vote ... stefan > -Original Message- > From: Stefan Seifert > Sent: Monday, December 11, 2023 4:16 PM > To: dev@sling.apache.org > Subject: [VOTE] Release Apache Sling Context-Aware Configuration Mock > Plugin 1.5.4 > > Hi, > > We solved 2 issues in this release: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12353380 > yleName=Text=12310710 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachesling-2821/ > > 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 2821 /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. > > stefan
RE: [VOTE] Release Apache Sling GraphQL 0.0.26
+1 stefan
[jira] [Closed] (SLING-12187) sling-mock: Make compatbile with Sling XSS 2.4.0
[ https://issues.apache.org/jira/browse/SLING-12187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Seifert closed SLING-12187. -- > sling-mock: Make compatbile with Sling XSS 2.4.0 > > > Key: SLING-12187 > URL: https://issues.apache.org/jira/browse/SLING-12187 > Project: Sling > Issue Type: Improvement > Components: Testing >Affects Versions: Testing Sling Mock 3.4.14 > Reporter: Stefan Seifert > Assignee: Stefan Seifert >Priority: Major > Fix For: Testing Sling Mock 3.4.16 > > > we need to update the managed dependencies to be compatible with the changes > from Sling XSS 2.4.0. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[RESULT] [VOTE] Release Apache Sling Testing Sling Mock 3.4.16
Hi, The vote has passed with the following result : +1 (binding): Stefan Seifert, Carsten Ziegeler, Eric Norman I will copy this release to the Sling dist directory and promote the artifacts to the central Maven repository. stefan
RE: [VOTE] Release Apache Sling Context-Aware Configuration Mock Plugin 1.5.4
+1 stefan
[VOTE] Release Apache Sling Context-Aware Configuration Mock Plugin 1.5.4
Hi, We solved 2 issues in this release: https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12353380=Text=12310710 Staging repository: https://repository.apache.org/content/repositories/orgapachesling-2821/ 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 2821 /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. stefan
