[jira] [Resolved] (SLING-12442) Regression due to SLING-11299

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding resolved SLING-12442.

Resolution: Fixed

> Regression due to SLING-11299
> -
>
> Key: SLING-12442
> URL: https://issues.apache.org/jira/browse/SLING-12442
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting JSP 2.6.0, Scripting JSP 2.6.2
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Major
> Fix For: Scripting JSP 2.6.4
>
>
> The fix for SLING-11299 introduced a regression. With that change, a JSP 
> script is re-compiled whenever an exception occurs during the execution of 
> the script.
> To fix the immediate issue, in this ticket, the "improved" error logging will 
> be reverted to what it was before SLING-11299. Restoring this improvement 
> will be covered in a separate ticket.
> Re-compilation performs the following (non-atomic/non-synchronized) steps
>  * delete old java file
>  * delete old class file
>  * generate new java file
>  * compile new java file to class file
>  * add smap data (java source maps for languages that are converted to java 
> source)
>  ** write tmp class file with added smap data (non-randomized file name)
>  ** delete class file
>  ** move tmp class file to class file path
> Any request threads that want to render the same JSP script, and that observe 
> that the class file is missing, will also start recompilation with all steps 
> from above.
> This can lead to multiple threads throwing exceptions due to an unexpected 
> state on the file system. Especially under load, it can be difficult for the 
> system to recover from such a situation.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (SLING-12442) Regression due to SLING-11299

[Julian Sedding (Jira)]

Julian Sedding created SLING-12442:
--

 Summary: Regression due to SLING-11299
 Key: SLING-12442
 URL: https://issues.apache.org/jira/browse/SLING-12442
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: Scripting JSP 2.6.2, Scripting JSP 2.6.0
Reporter: Julian Sedding
Assignee: Julian Sedding
 Fix For: Scripting JSP 2.6.4


The fix for SLING-11299 introduced a regression. With that change, a JSP script 
is re-compiled whenever an exception occurs during the execution of the script.

To fix the immediate issue, in this ticket, the "improved" error logging will 
be reverted to what it was before SLING-11299. Restoring this improvement will 
be covered in a separate ticket.

Re-compilation performs the following (non-atomic/non-synchronized) steps
 * delete old java file
 * delete old class file
 * generate new java file
 * compile new java file to class file
 * add smap data (java source maps for languages that are converted to java 
source)
 ** write tmp class file with added smap data (non-randomized file name)
 ** delete class file
 ** move tmp class file to class file path

Any request threads that want to render the same JSP script, and that observe 
that the class file is missing, will also start recompilation with all steps 
from above.

This can lead to multiple threads throwing exceptions due to an unexpected 
state on the file system. Especially under load, it can be difficult for the 
system to recover from such a situation.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (SLING-12438) Update Sling Scripting JSP to parent version 60

[Julian Sedding (Jira)]

Julian Sedding created SLING-12438:
--

 Summary: Update Sling Scripting JSP to parent version 60
 Key: SLING-12438
 URL: https://issues.apache.org/jira/browse/SLING-12438
 Project: Sling
  Issue Type: Task
  Components: Scripting
Affects Versions: Scripting JSP 2.6.2
Reporter: Julian Sedding
Assignee: Julian Sedding
 Fix For: Scripting JSP 2.6.4


Update Sling Scripting JSP's parent to version 60.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: Sling Scripting JSP - Java17+

[Julian Sedding]

Hi Robert

Thank you for the reply.

You are right, that's probably the most sensible course of action.
I'll look into overwriting the fixupmessages instruction.

Regarding parent 52, that runs into the same problem. In fact I
couldn't find any parent version higher than the current one, which
didn't run into this issue. I think parent 60 is fine, and we build
for Java 11.

That does help, thanks!

Regards
Julian

On Wed, 18 Sept 2024 at 17:16, Robert Munteanu  wrote:
>
> Hi Julian,
>
> On Wed, 2024-09-18 at 15:16 +0200, Julian Sedding wrote:
> > To complicate matters, there is a bnd warning "Export
> > org.apache.sling.scripting.jsp.jasper.runtime,  has 2,  private
> > references [org.apache.sling.scripting.jsp.jasper,
> > org.apache.sling.scripting.jsp.jasper.el]". This warning is turned
> > into an error when I update the parent and fails the build.
>
> This is indeed explicitly configured in more recent parent poms, but
> you should be able to turn it back into a warning by overwriting the
> fixupmessages instruction, I think this is what the commons-log bundle
> does at [1].
>
> I think that the export has been like this for a long time with no ill
> effects so we don't need to touch it now.
>
> > Does anyone have opinions on how to proceed? Is it acceptable to bump
> > the export version of "org.apache.sling.scripting.jsp.jasper.runtime"
> > from 2.5.0 to 3.0.0 in order to get Java 17+ support in the build? Or
> > should we leave the bundle alone and only ever build it with Java 11?
>
> To clarify, if you target the parent pom version 60 you need to buid
> with Java 17 or newer, but the target version can still be 11. You
> could also go with "just" parent pom version 52 which still builds on
> 11.
>
> Hope this helps,
> Robert
>
> [1]:
> https://github.com/apache/sling-org-apache-sling-commons-log/blob/454190a289a568da93024bff496af773e598c97c/bnd.bnd#L33

Sling Scripting JSP - Java17+

[Julian Sedding]

Hi

TL;DR - updating the build of "org.apache.sling.scripting.jsp" to work
with Java 17 and beyond requires bumping exported the version of the
exported package "org.apache.sling.scripting.jsp.jasper.runtime" from
2.5.0 to 3.0.0. Is this acceptable?

Whenever I build the module org.apache.sling.scripting.jsp with Java
17, I get a ConcurrentModificationException from within the (ancient
version of) the bnd-maven-plugin. Therefore, I have been looking at
increasing the sling-bundle-parent version of
org.apache.sling.scripting.jsp from 35 to 60, in order to implicitly
bump the version of bnd used under the hood, and because that's where
we want our modules to get to.

To complicate matters, there is a bnd warning "Export
org.apache.sling.scripting.jsp.jasper.runtime,  has 2,  private
references [org.apache.sling.scripting.jsp.jasper,
org.apache.sling.scripting.jsp.jasper.el]". This warning is turned
into an error when I update the parent and fails the build.

In order to resolve the warning/error, I looked at moving some classes
from the "runtime" package to other (not exported) packages. This
worked well and allowed me to leave the classes required by generated
JSPs to remain in the exported package without any changes to their
API. However, because I remove several classes from the package, I
need to bump its major version. I explored exporting the referenced
packages as well, but soon dismissed that option, because it leads to
nearly all classes in the bundle being exported.

The bundle currently exports version 2.5.0 of the package
"org.apache.sling.scripting.jsp.jasper.runtime", which AFAIU is used
by compiled JSP scripts, as can be seen in the class Generator[1],
which converts JSPs to java source files. I am wondering if we can
assume that "only" compiled JSPs use this package?

Does anyone have opinions on how to proceed? Is it acceptable to bump
the export version of "org.apache.sling.scripting.jsp.jasper.runtime"
from 2.5.0 to 3.0.0 in order to get Java 17+ support in the build? Or
should we leave the bundle alone and only ever build it with Java 11?

Thanks
Julian

[1] 
https://github.com/apache/sling-org-apache-sling-scripting-jsp/blob/6fe463b0b538fb177ad93acee7590b3ff702bac8/src/main/java/org/apache/sling/scripting/jsp/jasper/compiler/Generator.java

[jira] [Resolved] (SLING-12420) JSP scripts are falsely re-compiled on events from HTL engine

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding resolved SLING-12420.

Resolution: Fixed

> JSP scripts are falsely re-compiled on events from HTL engine
> -
>
> Key: SLING-12420
> URL: https://issues.apache.org/jira/browse/SLING-12420
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting JSP 2.6.2
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Minor
> Fix For: Scripting JSP 2.6.4
>
>
> The JSP scripting engine renews its {{JspRuntimeContext}} on every change, 
> even from other scripting engines. This can lead to JSP scripts being 
> unnecessarily re-compiled.
> The events should be filtered and only relevant events should lead to the 
> renewal of the {{JspRuntimeContext}}.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (SLING-12421) Race between serving request and destroying JspServletWrapper

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding resolved SLING-12421.

Resolution: Fixed

> Race between serving request and destroying JspServletWrapper
> -
>
> Key: SLING-12421
> URL: https://issues.apache.org/jira/browse/SLING-12421
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting JSP 2.6.2
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Minor
> Fix For: Scripting JSP 2.6.4
>
>
> When a {{JspServletWrapper}} is destroyed, it is possible that a request is 
> still being served concurrently. This can lead to a {{NullPointerException}} 
> if the internal field {{theServlet}} is already set to {{null}} by the time 
> it's {{service()}} method is called.
> To fix this, {{theServlet}} should be copied to a local field at the 
> beginning of the {{JspServletWrapper#service()}} method.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (SLING-12421) Race between serving request and destroying JspServletWrapper

[Julian Sedding (Jira)]

[ 
https://issues.apache.org/jira/browse/SLING-12421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17882024#comment-17882024
 ] 

Julian Sedding commented on SLING-12421:


After looking into how this could be improved, I concluded that the lowest risk 
change is to not set {{theServlet}} to {{null}} when it is being destroyed.

> Race between serving request and destroying JspServletWrapper
> -
>
> Key: SLING-12421
> URL: https://issues.apache.org/jira/browse/SLING-12421
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting JSP 2.6.2
>    Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Minor
> Fix For: Scripting JSP 2.6.4
>
>
> When a {{JspServletWrapper}} is destroyed, it is possible that a request is 
> still being served concurrently. This can lead to a {{NullPointerException}} 
> if the internal field {{theServlet}} is already set to {{null}} by the time 
> it's {{service()}} method is called.
> To fix this, {{theServlet}} should be copied to a local field at the 
> beginning of the {{JspServletWrapper#service()}} method.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (SLING-12425) Enable/disable discovery.impl via configuration

[Julian Sedding (Jira)]

[ 
https://issues.apache.org/jira/browse/SLING-12425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17880611#comment-17880611
 ] 

Julian Sedding commented on SLING-12425:


[~mreutegg] it should also be possible to solve this concern using the 
["Condition 
Specification"|https://docs.osgi.org/specification/osgi.core/8.0.0/service.condition.html]
 and it's [hook in the "Declarative 
Services"|https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.component.html#service.component-satisfying.condition].

> Enable/disable discovery.impl via configuration
> ---
>
> Key: SLING-12425
> URL: https://issues.apache.org/jira/browse/SLING-12425
> Project: Sling
>  Issue Type: Improvement
>  Components: Discovery
>Reporter: Marcel Reutegger
>Priority: Minor
>
> Add a configuration property that allows to enable/disable discovery.impl. 
> This allows installing multiple alternative discovery implementations (e.g. 
> discovery.oak and discovery.impl) and use one at runtime by setting 
> configuration properties accordingly.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (SLING-12420) JSP scripts are falsely re-compiled on events from HTL engine

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated SLING-12420:
---
Description: 
The JSP scripting engine renews its {{JspRuntimeContext}} on every change, even 
from other scripting engines. This can lead to JSP scripts being unnecessarily 
re-compiled.

The events should be filtered and only relevant events should lead to the 
renewal of the {{JspRuntimeContext}}.

  was:
The JSP scripting engine renews its {{{color:#00}JspRuntimeContext{color}}} 
on every change, even from other scripting engines. This can lead to JSP 
scripts being unnecessarily re-compiled.

The events should be filtered and only relevant events should lead to the 
renewal of the {{
{color:#00}JspRuntimeContext{color}}}.


> JSP scripts are falsely re-compiled on events from HTL engine
> -
>
> Key: SLING-12420
> URL: https://issues.apache.org/jira/browse/SLING-12420
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting JSP 2.6.2
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Minor
> Fix For: Scripting JSP 2.6.4
>
>
> The JSP scripting engine renews its {{JspRuntimeContext}} on every change, 
> even from other scripting engines. This can lead to JSP scripts being 
> unnecessarily re-compiled.
> The events should be filtered and only relevant events should lead to the 
> renewal of the {{JspRuntimeContext}}.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (SLING-12420) JSP scripts are falsely re-compiled on events from HTL engine

[Julian Sedding (Jira)]

Julian Sedding created SLING-12420:
--

 Summary: JSP scripts are falsely re-compiled on events from HTL 
engine
 Key: SLING-12420
 URL: https://issues.apache.org/jira/browse/SLING-12420
 Project: Sling
  Issue Type: Improvement
  Components: Scripting
Affects Versions: Scripting JSP 2.6.2
Reporter: Julian Sedding
Assignee: Julian Sedding
 Fix For: Scripting JSP 2.6.4


The JSP scripting engine renews its {{{color:#00}JspRuntimeContext{color}}} 
on every change, even from other scripting engines. This can lead to JSP 
scripts being unnecessarily re-compiled.

The events should be filtered and only relevant events should lead to the 
renewal of the {{
{color:#00}JspRuntimeContext{color}}}.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (SLING-12310) Fix test compatibility with java 17

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed SLING-12310.
--

> Fix test compatibility with java 17
> ---
>
> Key: SLING-12310
> URL: https://issues.apache.org/jira/browse/SLING-12310
> Project: Sling
>  Issue Type: Improvement
>  Components: i18n
>Affects Versions: i18n 2.6.2
>Reporter: Eric Norman
>Assignee: Eric Norman
>Priority: Major
> Fix For: I18N Support 2.6.4
>
>
> Some of the tests are failing when building with java 17.  
>  * bump oak/jackrabbit dependencies to the oldest still supported and 
> compatible version
>  * replace powermock usage with mockito
>  * replace dependency on org.apache.sling.commons.testing with sling mocks 
> equivalent
>  * update various dependency versions to compatible versions
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (SLING-12315) A race condition leads to failing resource-bundle registration during deactivation

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed SLING-12315.
--

> A race condition leads to failing resource-bundle registration during 
> deactivation
> --
>
> Key: SLING-12315
> URL: https://issues.apache.org/jira/browse/SLING-12315
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Affects Versions: i18n 2.6.2
>Reporter: Elia Colombo
>Assignee: Elia Colombo
>Priority: Major
> Fix For: I18N Support 2.6.4
>
>
> The following exception was observed:
> {code:java}
> [sling-default-5-ResourceBundleProvider: reload all resource bundles] 
> org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception during job 
> execution of job 
> 'org.apache.sling.i18n.impl.JcrResourceBundleProvider$1@688bc8e' with name 
> 'ResourceBundleProvider: reload all resource bundles' : Cannot invoke 
> "org.osgi.framework.BundleContext.registerService(java.lang.Class, Object, 
> java.util.Dictionary)" because "this.bundleContext" is 
> nulljava.lang.NullPointerException: Cannot invoke 
> "org.osgi.framework.BundleContext.registerService(java.lang.Class, Object, 
> java.util.Dictionary)" because "this.bundleContext" is null at  
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.registerResourceBundle(JcrResourceBundleProvider.java:532)
>  [org.apache.sling.i18n:2.6.2]{code}
> During the deactivation of JcrResourceBundleProvider, ReloadBundle jobs that 
> are still running can try to register new resourceBundles. This fails, if 
> deactivate already set bundleContext to null. 
> Proposed solution:
>  * Simplify and improve the thread-safety model by encapsulating bundle 
> service registration/deregistration and bookkeeping in the new class 
> ResourceBundleRegistry.
>  * The thread-safety concerns related to registration, deregistration, 
> bookkeeping of the resource bundles and of their associated service 
> registrations are encapsulated in the new class. 
>  * The object is created in the activate method and closed in the deactivated 
> method.
>  * The new class receives bundleContext in the constructor, removing the need 
> for a field in JcrResourceBundleProvider.
>  * The isClosed state of the new class is used as a cancel flag during 
> deactivation to prevent new registrations, processing of new onChange events 
> and scheduling new bundle reloading jobs during deactivation.
>  * Add unit tests for interleaved registration, clearing, deactivation.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[RESULT] [VOTE] Release Apache Sling I18N Support 2.6.4

[Julian Sedding]

Hi,

The vote has passed with the following result:

+1 (binding): Stefan Seifert, Joerg Hoh, Robert Munteanu, Julian Sedding
+1 (non-binding): none

I will copy this release to the Sling dist directory and promote the
artifacts to the central Maven repository.

Regards
Julian

Re: [VOTE] Release Apache Sling I18N Support 2.6.4

[Julian Sedding]

+1 - all checks ok

Regards
Julian

On Fri, 23 Aug 2024 at 10:23, Robert Munteanu  wrote:
>
> On Thu, 2024-08-22 at 10:54 +0200, Julian Sedding wrote:
> > Please vote to approve this release:
>
> +1
> Robert

Re: [Vote] Apache Sling Repoinit JCR 1.1.52

[Julian Sedding]

+1 - all checks ok

Regards
Julian

On Tue, 27 Aug 2024 at 09:24, Stefan Seifert
 wrote:
>
> +1 for the release itself
>
> however the changelog is not correct:
> - SLING-12348 is not part of the release, no commit (ticket is open)
> - SLING-12347 is part of the release, but still marked as open (although the 
> .git-blame-ignore-revs has no effect any longer due to squashing, but that’s 
> cosmetic)
>
> stefan
>
>
> > -Original Message-
> > From: Jörg Hoh 
> > Sent: Monday, August 26, 2024 12:11 PM
> > To: Sling Developers List 
> > Subject: [Vote] Apache Sling Repoinit JCR 1.1.52
> >
> > Hi,
> >
> > We solved 4 issues in this
> > release:https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=123
> > 54791&styleName=Text&projectId=12310710
> >
> > Staging
> > repository:https://repository.apache.org/content/repositories/orgapachesli
> > ng-2885/
> >
> > 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 2885 /tmp/sling-staging
> >
> > Please vote to approve this release:
> >
> >   [ ] +1 Approve the release
> >   [ ]  0 Don't care
> >   [ ] -1 Don't release, because ...
> >
> > This majority vote is open for at least 72 hours.
> >
> >
> >
> > --
> > https://cqdump.joerghoh.de

Re: [VOTE] Apache Sling Commons Threads 3.3.0

[Julian Sedding]

+1 - all checks ok

Regards
Julian

On Mon, 26 Aug 2024 at 11:04, Robert Munteanu  wrote:
>
> On Mon, 2024-08-26 at 09:57 +0200, Jörg Hoh wrote:
> > Please vote to approve this release:
>
> +1
> Robert

[VOTE] Release Apache Sling I18N Support 2.6.4

[Julian Sedding]

Hi,

We solved 2 issues in the Apache Sling I18N Support 2.6.4 release:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12354636&styleName=Text&projectId=12310710

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-2882/

You can use this UNIX script to download the release and verify the signatures:
https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD

Usage: sh check_staged_release.sh 2882 /tmp/sling-staging

Please vote to approve this release:

[  ]  +1 Approve the release
[  ]0 Don't care
[  ]   -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Regards
Julian

[jira] [Updated] (SLING-12312) add jakarta.servlet support in RequestLocaleResolver

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated SLING-12312:
---
Fix Version/s: (was: i18n 2.6.4)

> add jakarta.servlet support in RequestLocaleResolver
> 
>
> Key: SLING-12312
> URL: https://issues.apache.org/jira/browse/SLING-12312
> Project: Sling
>  Issue Type: Improvement
>Reporter: Eric Norman
>Assignee: Eric Norman
>Priority: Major
>
> provide a variant of the RequestLocaleResolver#resolveLocale call that 
> accepts a jakarta.servlet.http.HttpServletRequest for use cases that have 
> migrated to EE9 or later.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (SLING-12315) A race condition leads to failing resource-bundle registration during deactivation

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated SLING-12315:
---
Affects Version/s: i18n 2.6.2

> A race condition leads to failing resource-bundle registration during 
> deactivation
> --
>
> Key: SLING-12315
> URL: https://issues.apache.org/jira/browse/SLING-12315
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Affects Versions: i18n 2.6.2
>Reporter: Elia Colombo
>Assignee: Elia Colombo
>Priority: Major
> Fix For: i18n 2.6.4
>
>
> The following exception was observed:
> {code:java}
> [sling-default-5-ResourceBundleProvider: reload all resource bundles] 
> org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception during job 
> execution of job 
> 'org.apache.sling.i18n.impl.JcrResourceBundleProvider$1@688bc8e' with name 
> 'ResourceBundleProvider: reload all resource bundles' : Cannot invoke 
> "org.osgi.framework.BundleContext.registerService(java.lang.Class, Object, 
> java.util.Dictionary)" because "this.bundleContext" is 
> nulljava.lang.NullPointerException: Cannot invoke 
> "org.osgi.framework.BundleContext.registerService(java.lang.Class, Object, 
> java.util.Dictionary)" because "this.bundleContext" is null at  
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.registerResourceBundle(JcrResourceBundleProvider.java:532)
>  [org.apache.sling.i18n:2.6.2]{code}
> During the deactivation of JcrResourceBundleProvider, ReloadBundle jobs that 
> are still running can try to register new resourceBundles. This fails, if 
> deactivate already set bundleContext to null. 
> Proposed solution:
>  * Simplify and improve the thread-safety model by encapsulating bundle 
> service registration/deregistration and bookkeeping in the new class 
> ResourceBundleRegistry.
>  * The thread-safety concerns related to registration, deregistration, 
> bookkeeping of the resource bundles and of their associated service 
> registrations are encapsulated in the new class. 
>  * The object is created in the activate method and closed in the deactivated 
> method.
>  * The new class receives bundleContext in the constructor, removing the need 
> for a field in JcrResourceBundleProvider.
>  * The isClosed state of the new class is used as a cancel flag during 
> deactivation to prevent new registrations, processing of new onChange events 
> and scheduling new bundle reloading jobs during deactivation.
>  * Add unit tests for interleaved registration, clearing, deactivation.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (SLING-12315) A race condition leads to failing resource-bundle registration during deactivation

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding resolved SLING-12315.

Resolution: Fixed

> A race condition leads to failing resource-bundle registration during 
> deactivation
> --
>
> Key: SLING-12315
> URL: https://issues.apache.org/jira/browse/SLING-12315
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Affects Versions: i18n 2.6.2
>Reporter: Elia Colombo
>Assignee: Elia Colombo
>Priority: Major
> Fix For: i18n 2.6.4
>
>
> The following exception was observed:
> {code:java}
> [sling-default-5-ResourceBundleProvider: reload all resource bundles] 
> org.apache.sling.commons.scheduler.impl.QuartzScheduler Exception during job 
> execution of job 
> 'org.apache.sling.i18n.impl.JcrResourceBundleProvider$1@688bc8e' with name 
> 'ResourceBundleProvider: reload all resource bundles' : Cannot invoke 
> "org.osgi.framework.BundleContext.registerService(java.lang.Class, Object, 
> java.util.Dictionary)" because "this.bundleContext" is 
> nulljava.lang.NullPointerException: Cannot invoke 
> "org.osgi.framework.BundleContext.registerService(java.lang.Class, Object, 
> java.util.Dictionary)" because "this.bundleContext" is null at  
> org.apache.sling.i18n.impl.JcrResourceBundleProvider.registerResourceBundle(JcrResourceBundleProvider.java:532)
>  [org.apache.sling.i18n:2.6.2]{code}
> During the deactivation of JcrResourceBundleProvider, ReloadBundle jobs that 
> are still running can try to register new resourceBundles. This fails, if 
> deactivate already set bundleContext to null. 
> Proposed solution:
>  * Simplify and improve the thread-safety model by encapsulating bundle 
> service registration/deregistration and bookkeeping in the new class 
> ResourceBundleRegistry.
>  * The thread-safety concerns related to registration, deregistration, 
> bookkeeping of the resource bundles and of their associated service 
> registrations are encapsulated in the new class. 
>  * The object is created in the activate method and closed in the deactivated 
> method.
>  * The new class receives bundleContext in the constructor, removing the need 
> for a field in JcrResourceBundleProvider.
>  * The isClosed state of the new class is used as a cancel flag during 
> deactivation to prevent new registrations, processing of new onChange events 
> and scheduling new bundle reloading jobs during deactivation.
>  * Add unit tests for interleaved registration, clearing, deactivation.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (SLING-12310) Fix test compatibility with java 17

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated SLING-12310:
---
Component/s: i18n

> Fix test compatibility with java 17
> ---
>
> Key: SLING-12310
> URL: https://issues.apache.org/jira/browse/SLING-12310
> Project: Sling
>  Issue Type: Improvement
>  Components: i18n
>Reporter: Eric Norman
>Assignee: Eric Norman
>Priority: Major
> Fix For: i18n 2.6.4
>
>
> Some of the tests are failing when building with java 17.  
>  * bump oak/jackrabbit dependencies to the oldest still supported and 
> compatible version
>  * replace powermock usage with mockito
>  * replace dependency on org.apache.sling.commons.testing with sling mocks 
> equivalent
>  * update various dependency versions to compatible versions
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (SLING-12310) Fix test compatibility with java 17

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated SLING-12310:
---
Affects Version/s: i18n 2.6.2

> Fix test compatibility with java 17
> ---
>
> Key: SLING-12310
> URL: https://issues.apache.org/jira/browse/SLING-12310
> Project: Sling
>  Issue Type: Improvement
>  Components: i18n
>Affects Versions: i18n 2.6.2
>Reporter: Eric Norman
>Assignee: Eric Norman
>Priority: Major
> Fix For: i18n 2.6.4
>
>
> Some of the tests are failing when building with java 17.  
>  * bump oak/jackrabbit dependencies to the oldest still supported and 
> compatible version
>  * replace powermock usage with mockito
>  * replace dependency on org.apache.sling.commons.testing with sling mocks 
> equivalent
>  * update various dependency versions to compatible versions
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (SLING-12385) OSGi mock context seems to not take service ranking into account

[Julian Sedding (Jira)]

[ 
https://issues.apache.org/jira/browse/SLING-12385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17874200#comment-17874200
 ] 

Julian Sedding commented on SLING-12385:


[~bartthierens] further to Henry's comments, your assumption that a lower 
service ranking is ordered before a higher one is wrong.

{quote}
The _ranking order_ is defined as follows:
 * Sorted on descending ranking number (highest first)
 * If the ranking numbers are equal, sorted on ascending {{service.id}} 
property (oldest first).
{quote}

Source: 
https://docs.osgi.org/specification/osgi.core/8.0.0/framework.service.html#framework.service.servicerankingorder

> OSGi mock context seems to not take service ranking into account
> 
>
> Key: SLING-12385
> URL: https://issues.apache.org/jira/browse/SLING-12385
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing OSGi Mock 3.4.2
>Reporter: Bart Thierens
>Priority: Major
>
> Logging this issue here as I can't log it in github.  I assume this is the 
> correct approach.
> I am unable to make my registered services in a test case mimick the same 
> ordering behaviour than in an actual OSGi environment.  The 
> AemContext/AemContextImpl/SlingContextImpl/OsgiContextImpl does not respect 
> the `@ServiceRanking` annotation, nor the component property 
> "service.ranking".
> It seems vital to be able to test that a certain part of application logic 
> executes certain services in order, and that seems impossible now - unless 
> the developer registers the services exactly in the order he expects them, 
> which beats the purpose of the test.
> If this is documented behaviour, I can't find it anywhere... (And it's still 
> not correct imho)
> Personal use case: A certain component that has "processors" (which are 
> components implementing a single service) that are ordered by service ranking 
> (low = first, high = later). When a service is disabled/unregistered, 
> registered or even re-registered, the order must stay consistent (low => 
> high).  This actually works perfectly, but not in test-cases.
> I created a demo (AEM) project that showcases this problem: 
> [https://github.com/senn/aemcontext-no-serviceranking-ordering]
> It contains tests for the various context implementations and also a separate 
> branch that has the same issue without `@ServiceRanking` and with the 
> "service.ranking" properties.
> I don't have a fix ready, but might look into it in a few weeks when I have 
> time.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Apache Sling Installer Configuration Factory 1.4.6

[Julian Sedding]

+1 - all checks ok

Thank you Stefan!

Regards
Julian

On Thu, 15 Aug 2024 at 10:52, Robert Munteanu  wrote:
>
> On Thu, 2024-08-15 at 10:33 +0200, Stefan Egli wrote:
> > Please vote to approve this release:
>
> +1
> Robert

Re: [VOTE] Release Apache Sling Commons Prometheus Metrics Exporter 0.1.2

[Julian Sedding]

+1 - all checks ok

Regards
Julian

On Wed, 14 Aug 2024 at 15:50, Jörg Hoh  wrote:
>
> +1
>
> Am Mi., 14. Aug. 2024 um 11:25 Uhr schrieb Robert Munteanu <
> romb...@apache.org>:
>
> > Hi,
> >
> > We solved 1 issue in this release:
> >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710&version=12353665&styleName=Text
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-2879/
> >
> > 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 2879 /tmp/sling-staging
> >
> > Please vote to approve this release:
> >
> >   [ ] +1 Approve the release
> >   [ ]  0 Don't care
> >   [ ] -1 Don't release, because ...
> >
> > This majority vote is open for at least 72 hours.
> >
> > Regards,
> > Robert Munteanu
> >
>
>
> --
> https://cqdump.joerghoh.de

Re: [VOTE] Release Apache Sling XSS Protection 2.4.2

[Julian Sedding]

+1 - all checks ok

Regards
Julian

On Wed, 14 Aug 2024 at 16:55, Robert Munteanu  wrote:
>
> On Wed, 2024-08-14 at 15:47 +0200, Jörg Hoh wrote:
> > Please vote to approve this release:
>
> +1
> Robert

[jira] [Commented] (SLING-12388) Handle duplicate literals

[Julian Sedding (Jira)]

[ 
https://issues.apache.org/jira/browse/SLING-12388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17873519#comment-17873519
 ] 

Julian Sedding commented on SLING-12388:


I added a test in https://github.com/apache/sling-org-apache-sling-xss/pull/44

> Handle duplicate literals
> -
>
> Key: SLING-12388
> URL: https://issues.apache.org/jira/browse/SLING-12388
> Project: Sling
>  Issue Type: Improvement
>  Components: XSS Protection API
>Reporter: Joerg Hoh
>Assignee: Joerg Hoh
>Priority: Major
> Fix For: XSS Protection API 2.4.2
>
>
> When testing the most recent SNAPSHOT version of the bundle against a recent 
> AEM as Cloud Service instance, I got this exception:
> {noformat}
> 13.06.2024 10:04:54.106 *ERROR* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Unable to load policy from 
> /libs/cq/xssprotection/config.xml
> java.lang.IllegalArgumentException: duplicate element: a
> at 
> java.base/java.util.ImmutableCollections$SetN.(ImmutableCollections.java:604)
> at java.base/java.util.Set.of(Set.java:701)
> at org.owasp.shim.ForJava9AndLater.setOf(ForJava9AndLater.java:61) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.owasp.html.HtmlPolicyBuilder$AttributeBuilder.matching(HtmlPolicyBuilder.java:933)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.AntiSamyPolicyAdapter.(AntiSamyPolicyAdapter.java:145)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.HtmlSanitizer.(HtmlSanitizer.java:40) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.PolicyHandler.(PolicyHandler.java:47) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.setActivePolicy(XSSFilterImpl.java:331)
>  [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.updatePolicy(XSSFilterImpl.java:293) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> org.apache.sling.xss.impl.XSSFilterImpl.activate(XSSFilterImpl.java:269) 
> [org.apache.sling.xss:2.4.1.SNAPSHOT]
> at 
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [...]
> 13.06.2024 10:04:54.109 *INFO* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Could not find a policy file at the 
> configured location cq/xssprotection/config.xml. Attempting to use the 
> default resource embedded in the bundle.
> 13.06.2024 10:04:54.282 *INFO* [FelixStartLevel] 
> org.apache.sling.xss.impl.XSSFilterImpl Installed policy from the embedded 
> SLING-INF/content/config.xml file from the bundle.
> {noformat}
> Analyzing this I found this snippet of the configuration is responsible for 
> it:
> {noformat}
> 
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> {noformat}
> This configuration works with the previous version 2.4.0 of the XSS bundle. 
> When I remove the uppercase variants of the literals from the configuration, 
> I don't get the exception anymore with the latest SNAPSHOT.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (SLING-12366) Failure to read from InputStream backed by closed session

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated SLING-12366:
---
Fix Version/s: XSS Protection API 2.4.2

> Failure to read from InputStream backed by closed session
> -
>
> Key: SLING-12366
> URL: https://issues.apache.org/jira/browse/SLING-12366
> Project: Sling
>  Issue Type: Improvement
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 2.4.0
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Major
> Fix For: XSS Protection API 2.4.2
>
>
> The method {{org.apache.sling.xss.impl.XSSFilterImpl.AntiSamyPolicy#read()}} 
> opens a {{ResourceResolver}}, finds a {{Resource}}, adapts it to an 
> {{InputStream}}, returns the {{InputStream}} and closes the 
> {{ResourceResolver}} via try-with-resource.
> This works fine, as long as the {{InputStream}} is not a 
> {{JcrExternalizableInputStream}}, which is only available when the blob 
> resides in an external blob store, e.g. azure.
> The reason is that the {{JcrExternalizableInputStream}} takes a reference to 
> the JCR {{Property}} and only reads it lazily. In this scenario, when it 
> reads the property, the session is already closed.
> A typical stack-trace looks like the one below:
> {noformat}
> [main] ERROR org.apache.sling.xss.impl.XSSFilterImpl - Unable to load policy 
> from /libs/sling/xss/config.xml
> java.io.IOException: This session has been closed.
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrExternalizableInputStream.getInputStream(JcrExternalizableInputStream.java:70)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrExternalizableInputStream.read(JcrExternalizableInputStream.java:57)
>   at java.base/java.io.InputStream.read(InputStream.java:271)
>   at java.base/java.io.InputStream.read(InputStream.java:205)
>   at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1485)
>   at org.apache.commons.io.IOUtils.copy(IOUtils.java:1105)
>   at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1458)
>   at org.apache.commons.io.IOUtils.copy(IOUtils.java:1083)
>   at org.apache.sling.xss.impl.PolicyHandler.(PolicyHandler.java:43)
>   at 
> org.apache.sling.xss.impl.XSSFilterImpl.setActivePolicy(XSSFilterImpl.java:331)
>   at 
> org.apache.sling.xss.impl.XSSFilterImpl.updatePolicy(XSSFilterImpl.java:293)
>   at 
> org.apache.sling.xss.impl.XSSFilterImpl.activate(XSSFilterImpl.java:269)
>   [... snipped the caller ...]
> Caused by: javax.jcr.RepositoryException: This session has been closed.
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.checkAlive(SessionDelegate.java:323)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.ItemDelegate.checkAlive(ItemDelegate.java:83)
>   at 
> org.apache.jackrabbit.oak.jcr.session.operation.ItemOperation.checkPreconditions(ItemOperation.java:34)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:614)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:204)
>   at 
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
>   at 
> org.apache.jackrabbit.oak.jcr.session.PropertyImpl.getValue(PropertyImpl.java:248)
>   at 
> org.apache.jackrabbit.oak.jcr.session.PropertyImpl.getBinary(PropertyImpl.java:287)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrExternalizableInputStream.getInputStream(JcrExternalizableInputStream.java:68)
>   ... 93 more
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (SLING-12366) Failure to read from InputStream backed by closed session

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding resolved SLING-12366.

Resolution: Fixed

> Failure to read from InputStream backed by closed session
> -
>
> Key: SLING-12366
> URL: https://issues.apache.org/jira/browse/SLING-12366
> Project: Sling
>  Issue Type: Improvement
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 2.4.0
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Major
>
> The method {{org.apache.sling.xss.impl.XSSFilterImpl.AntiSamyPolicy#read()}} 
> opens a {{ResourceResolver}}, finds a {{Resource}}, adapts it to an 
> {{InputStream}}, returns the {{InputStream}} and closes the 
> {{ResourceResolver}} via try-with-resource.
> This works fine, as long as the {{InputStream}} is not a 
> {{JcrExternalizableInputStream}}, which is only available when the blob 
> resides in an external blob store, e.g. azure.
> The reason is that the {{JcrExternalizableInputStream}} takes a reference to 
> the JCR {{Property}} and only reads it lazily. In this scenario, when it 
> reads the property, the session is already closed.
> A typical stack-trace looks like the one below:
> {noformat}
> [main] ERROR org.apache.sling.xss.impl.XSSFilterImpl - Unable to load policy 
> from /libs/sling/xss/config.xml
> java.io.IOException: This session has been closed.
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrExternalizableInputStream.getInputStream(JcrExternalizableInputStream.java:70)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrExternalizableInputStream.read(JcrExternalizableInputStream.java:57)
>   at java.base/java.io.InputStream.read(InputStream.java:271)
>   at java.base/java.io.InputStream.read(InputStream.java:205)
>   at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1485)
>   at org.apache.commons.io.IOUtils.copy(IOUtils.java:1105)
>   at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1458)
>   at org.apache.commons.io.IOUtils.copy(IOUtils.java:1083)
>   at org.apache.sling.xss.impl.PolicyHandler.(PolicyHandler.java:43)
>   at 
> org.apache.sling.xss.impl.XSSFilterImpl.setActivePolicy(XSSFilterImpl.java:331)
>   at 
> org.apache.sling.xss.impl.XSSFilterImpl.updatePolicy(XSSFilterImpl.java:293)
>   at 
> org.apache.sling.xss.impl.XSSFilterImpl.activate(XSSFilterImpl.java:269)
>   [... snipped the caller ...]
> Caused by: javax.jcr.RepositoryException: This session has been closed.
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.checkAlive(SessionDelegate.java:323)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.ItemDelegate.checkAlive(ItemDelegate.java:83)
>   at 
> org.apache.jackrabbit.oak.jcr.session.operation.ItemOperation.checkPreconditions(ItemOperation.java:34)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:614)
>   at 
> org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:204)
>   at 
> org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
>   at 
> org.apache.jackrabbit.oak.jcr.session.PropertyImpl.getValue(PropertyImpl.java:248)
>   at 
> org.apache.jackrabbit.oak.jcr.session.PropertyImpl.getBinary(PropertyImpl.java:287)
>   at 
> org.apache.sling.jcr.resource.internal.helper.jcr.JcrExternalizableInputStream.getInputStream(JcrExternalizableInputStream.java:68)
>   ... 93 more
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (SLING-12408) simplify logic in AntiSamyPolicyAdapter

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding resolved SLING-12408.

Resolution: Fixed

> simplify logic in AntiSamyPolicyAdapter
> ---
>
> Key: SLING-12408
> URL: https://issues.apache.org/jira/browse/SLING-12408
> Project: Sling
>  Issue Type: Improvement
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 2.4.0
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Minor
> Fix For: XSS Protection API 2.4.2
>
>
> The logic in {{AntiSamyPolicyAdapter}} has quite a lot of unnecessary case 
> distinctions and can be simplified by removing code.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (SLING-12408) simplify logic in AntiSamyPolicyAdapter

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated SLING-12408:
---
Description: 
The logic in {{AntiSamyPolicyAdapter}} has quite a lot of unnecessary case 
distinctions and can be simplified by removing code.

 

  was:The logic in {{AntiSamyPolicyAdapter}} has quite a lot of unnecessary 
case distinctions and can be simplified by removing code.


> simplify logic in AntiSamyPolicyAdapter
> ---
>
> Key: SLING-12408
> URL: https://issues.apache.org/jira/browse/SLING-12408
> Project: Sling
>  Issue Type: Improvement
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 2.4.0
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Minor
> Fix For: XSS Protection API 2.4.2
>
>
> The logic in {{AntiSamyPolicyAdapter}} has quite a lot of unnecessary case 
> distinctions and can be simplified by removing code.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (SLING-12368) regression: rule for "ol" tag fails on java 9+ after SLING-12276

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated SLING-12368:
---
Fix Version/s: (was: XSS Protection API 2.4.2)

> regression: rule for "ol" tag fails on java 9+ after SLING-12276
> 
>
> Key: SLING-12368
> URL: https://issues.apache.org/jira/browse/SLING-12368
> Project: Sling
>  Issue Type: Improvement
>  Components: XSS Protection API
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
>
> The dependency update in SLING-12276 brings a change, where 
> {{java.lang.Set.of()}} methods are used _if_ the runtime is java 9+. 
> {{Set.of()}} throws an exception if any two arguments are equal.
> The configuration for the "ol" tag is as follows:
> {code:xml}
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> {code}
> The literals "a", "A", "i", "I", "1" are all converted to lower case and 
> result in the following call {{{}Set.of("a", "a", "i", "i", "1"){}}}. On Java 
> 9+, this results in the following exception:
> {noformat}
> java.lang.IllegalArgumentException: duplicate element: a
>   at 
> java.base/java.util.ImmutableCollections$SetN.(ImmutableCollections.java:587)
>   at java.base/java.util.Set.of(Set.java:701)
>   at org.owasp.shim.ForJava9AndLater.setOf(ForJava9AndLater.java:61)
>   at 
> org.owasp.html.HtmlPolicyBuilder$AttributeBuilder.matching(HtmlPolicyBuilder.java:933)
>   at 
> org.apache.sling.xss.impl.AntiSamyPolicyAdapter.(AntiSamyPolicyAdapter.java:146)
>   at org.apache.sling.xss.impl.HtmlSanitizer.(HtmlSanitizer.java:40)
> ...
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (SLING-12368) regression: rule for "ol" tag fails on java 9+ after SLING-12276

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding resolved SLING-12368.

Resolution: Duplicate

Yes [~joerghoh], this is a duplicate of SLING-12388.

> regression: rule for "ol" tag fails on java 9+ after SLING-12276
> 
>
> Key: SLING-12368
> URL: https://issues.apache.org/jira/browse/SLING-12368
> Project: Sling
>  Issue Type: Improvement
>  Components: XSS Protection API
>Reporter: Julian Sedding
>Assignee: Julian Sedding
>Priority: Major
> Fix For: XSS Protection API 2.4.2
>
>
> The dependency update in SLING-12276 brings a change, where 
> {{java.lang.Set.of()}} methods are used _if_ the runtime is java 9+. 
> {{Set.of()}} throws an exception if any two arguments are equal.
> The configuration for the "ol" tag is as follows:
> {code:xml}
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> {code}
> The literals "a", "A", "i", "I", "1" are all converted to lower case and 
> result in the following call {{{}Set.of("a", "a", "i", "i", "1"){}}}. On Java 
> 9+, this results in the following exception:
> {noformat}
> java.lang.IllegalArgumentException: duplicate element: a
>   at 
> java.base/java.util.ImmutableCollections$SetN.(ImmutableCollections.java:587)
>   at java.base/java.util.Set.of(Set.java:701)
>   at org.owasp.shim.ForJava9AndLater.setOf(ForJava9AndLater.java:61)
>   at 
> org.owasp.html.HtmlPolicyBuilder$AttributeBuilder.matching(HtmlPolicyBuilder.java:933)
>   at 
> org.apache.sling.xss.impl.AntiSamyPolicyAdapter.(AntiSamyPolicyAdapter.java:146)
>   at org.apache.sling.xss.impl.HtmlSanitizer.(HtmlSanitizer.java:40)
> ...
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (SLING-12408) simplify logic in AntiSamyPolicyAdapter

[Julian Sedding (Jira)]

Julian Sedding created SLING-12408:
--

 Summary: simplify logic in AntiSamyPolicyAdapter
 Key: SLING-12408
 URL: https://issues.apache.org/jira/browse/SLING-12408
 Project: Sling
  Issue Type: Improvement
  Components: XSS Protection API
Affects Versions: XSS Protection API 2.4.0
Reporter: Julian Sedding
Assignee: Julian Sedding
 Fix For: XSS Protection API 2.4.2


The logic in {{AntiSamyPolicyAdapter}} has quite a lot of unnecessary case 
distinctions and can be simplified by removing code.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (SLING-12368) regression: rule for "ol" tag fails on java 9+ after SLING-12276

[Julian Sedding (Jira)]

Julian Sedding created SLING-12368:
--

 Summary: regression: rule for "ol" tag fails on java 9+ after 
SLING-12276
 Key: SLING-12368
 URL: https://issues.apache.org/jira/browse/SLING-12368
 Project: Sling
  Issue Type: Improvement
  Components: XSS Protection API
Reporter: Julian Sedding
Assignee: Julian Sedding
 Fix For: XSS Protection API 2.4.2


The dependency update in SLING-12276 brings a change, where 
{{java.lang.Set.of()}} methods are used _if_ the runtime is java 9+. 
{{Set.of()}} throws an exception if any two arguments are equal.

The configuration for the "ol" tag is as follows:
{code:xml}
















{code}
The literals "a", "A", "i", "I", "1" are all converted to lower case and result 
in the following call {{{}Set.of("a", "a", "i", "i", "1"){}}}. On Java 9+, this 
results in the following exception:
{noformat}
java.lang.IllegalArgumentException: duplicate element: a
at 
java.base/java.util.ImmutableCollections$SetN.(ImmutableCollections.java:587)
at java.base/java.util.Set.of(Set.java:701)
at org.owasp.shim.ForJava9AndLater.setOf(ForJava9AndLater.java:61)
at 
org.owasp.html.HtmlPolicyBuilder$AttributeBuilder.matching(HtmlPolicyBuilder.java:933)
at 
org.apache.sling.xss.impl.AntiSamyPolicyAdapter.(AntiSamyPolicyAdapter.java:146)
at org.apache.sling.xss.impl.HtmlSanitizer.(HtmlSanitizer.java:40)
...
{noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (SLING-12366) Failure to read from InputStream backed by closed session

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated SLING-12366:
---
Description: 
The method {{org.apache.sling.xss.impl.XSSFilterImpl.AntiSamyPolicy#read()}} 
opens a {{ResourceResolver}}, finds a {{Resource}}, adapts it to an 
{{InputStream}}, returns the {{InputStream}} and closes the 
{{ResourceResolver}} via try-with-resource.

This works fine, as long as the {{InputStream}} is not a 
{{JcrExternalizableInputStream}}, which is only available when the blob resides 
in an external blob store, e.g. azure.

The reason is that the {{JcrExternalizableInputStream}} takes a reference to 
the JCR {{Property}} and only reads it lazily. In this scenario, when it reads 
the property, the session is already closed.

A typical stack-trace looks like the one below:
{noformat}
[main] ERROR org.apache.sling.xss.impl.XSSFilterImpl - Unable to load policy 
from /libs/sling/xss/config.xml
java.io.IOException: This session has been closed.
at 
org.apache.sling.jcr.resource.internal.helper.jcr.JcrExternalizableInputStream.getInputStream(JcrExternalizableInputStream.java:70)
at 
org.apache.sling.jcr.resource.internal.helper.jcr.JcrExternalizableInputStream.read(JcrExternalizableInputStream.java:57)
at java.base/java.io.InputStream.read(InputStream.java:271)
at java.base/java.io.InputStream.read(InputStream.java:205)
at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1485)
at org.apache.commons.io.IOUtils.copy(IOUtils.java:1105)
at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1458)
at org.apache.commons.io.IOUtils.copy(IOUtils.java:1083)
at org.apache.sling.xss.impl.PolicyHandler.(PolicyHandler.java:43)
at 
org.apache.sling.xss.impl.XSSFilterImpl.setActivePolicy(XSSFilterImpl.java:331)
at 
org.apache.sling.xss.impl.XSSFilterImpl.updatePolicy(XSSFilterImpl.java:293)
at 
org.apache.sling.xss.impl.XSSFilterImpl.activate(XSSFilterImpl.java:269)
[... snipped the caller ...]
Caused by: javax.jcr.RepositoryException: This session has been closed.
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.checkAlive(SessionDelegate.java:323)
at 
org.apache.jackrabbit.oak.jcr.delegate.ItemDelegate.checkAlive(ItemDelegate.java:83)
at 
org.apache.jackrabbit.oak.jcr.session.operation.ItemOperation.checkPreconditions(ItemOperation.java:34)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.prePerform(SessionDelegate.java:614)
at 
org.apache.jackrabbit.oak.jcr.delegate.SessionDelegate.perform(SessionDelegate.java:204)
at 
org.apache.jackrabbit.oak.jcr.session.ItemImpl.perform(ItemImpl.java:112)
at 
org.apache.jackrabbit.oak.jcr.session.PropertyImpl.getValue(PropertyImpl.java:248)
at 
org.apache.jackrabbit.oak.jcr.session.PropertyImpl.getBinary(PropertyImpl.java:287)
at 
org.apache.sling.jcr.resource.internal.helper.jcr.JcrExternalizableInputStream.getInputStream(JcrExternalizableInputStream.java:68)
... 93 more
{noformat}


  was:
The method {{org.apache.sling.xss.impl.XSSFilterImpl.AntiSamyPolicy#read()}} 
opens a {{ResourceResolver}}, finds a {{Resource}}, adapts it to an 
{{InputStream}}, returns the {{InputStream}} and closes the 
{{ResourceResolver}} via try-with-resource.

This works fine, as long as the {{InputStream}} is not a 
{{JcrExternalizableInputStream}}, which is only available when the blob resides 
in an external blob store, e.g. azure.

The reason is that the {{JcrExternalizableInputStream}} takes a reference to 
the JCR {{Property}} and only reads it lazily. In this scenario, when it reads 
the property, the session is already closed.


> Failure to read from InputStream backed by closed session
> -
>
> Key: SLING-12366
> URL: https://issues.apache.org/jira/browse/SLING-12366
> Project: Sling
>  Issue Type: Improvement
>  Components: XSS Protection API
>Affects Versions: XSS Protection API 2.4.0
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Major
>
> The method {{org.apache.sling.xss.impl.XSSFilterImpl.AntiSamyPolicy#read()}} 
> opens a {{ResourceResolver}}, finds a {{Resource}}, adapts it to an 
> {{InputStream}}, returns the {{InputStream}} and closes the 
> {{ResourceResolver}} via try-with-resource.
> This works fine, as long as the {{InputStream}} is not a 
> {{JcrExternalizableInputStream}}, which is only available when the blob 
> resides in an external blob store, e.g. azure.
> The reason is that the {{JcrExternalizableInputStream}} takes a reference to 
> the JCR {{Property}} and only reads it lazily. In this scenario, when it 
> reads

[jira] [Created] (SLING-12366) Failure to read from InputStream backed by closed session

[Julian Sedding (Jira)]

Julian Sedding created SLING-12366:
--

 Summary: Failure to read from InputStream backed by closed session
 Key: SLING-12366
 URL: https://issues.apache.org/jira/browse/SLING-12366
 Project: Sling
  Issue Type: Improvement
  Components: XSS Protection API
Affects Versions: XSS Protection API 2.4.0
Reporter: Julian Sedding
Assignee: Julian Sedding


The method {{org.apache.sling.xss.impl.XSSFilterImpl.AntiSamyPolicy#read()}} 
opens a {{ResourceResolver}}, finds a {{Resource}}, adapts it to an 
{{InputStream}}, returns the {{InputStream}} and closes the 
{{ResourceResolver}} via try-with-resource.

This works fine, as long as the {{InputStream}} is not a 
{{JcrExternalizableInputStream}}, which is only available when the blob resides 
in an external blob store, e.g. azure.

The reason is that the {{JcrExternalizableInputStream}} takes a reference to 
the JCR {{Property}} and only reads it lazily. In this scenario, when it reads 
the property, the session is already closed.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (SLING-12283) Configuration in Cluster mode are not in sync

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated SLING-12283:
---
Fix Version/s: Installer Configuration Factory 1.4.6

> Configuration in Cluster mode are not in sync
> -
>
> Key: SLING-12283
> URL: https://issues.apache.org/jira/browse/SLING-12283
> Project: Sling
>  Issue Type: Bug
>Reporter: Rishabh Daim
>        Assignee: Julian Sedding
>Priority: Major
> Fix For: Installer Configuration Factory 1.4.6
>
>
> {color:#172b4d}Configuration in Cluster mode is not in sync. When instances 
> are in shared mode, and a new configuration is created under 1st instance, it 
> is not reflected correctly in 2nd instance. {color}
> {color:#172b4d}The factory PID and hence properties are altered in the 2nd 
> instance.{color}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (SLING-12283) Configuration in Cluster mode are not in sync

[Julian Sedding (Jira)]

[ 
https://issues.apache.org/jira/browse/SLING-12283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17861063#comment-17861063
 ] 

Julian Sedding commented on SLING-12283:


Further analysis showed that this issue occurs when a factory configuration is 
manually created using the Felix webconsole. The webconsole uses the API 
{{ConfigurationAdmin#createFactoryConfiguration(...)}} to create such a 
configuration. In contrast to the 
{{ConfigurationAdmin#getFactoryConfiguration(...)}} methods, which create a 
{{service.pid}} by concatenating the {{factoryPid}}, a tilde character ('~') 
and the "name" part (an arbitrary string passed by the caller), the 
{{ConfigurationAdmin#createFactoryConfiguration(...)}} methods, as implemented 
by Felix' implementation of the Configuration Admin specification, create a 
{{service.pid}} by concatenating the {{factoryPid}}, a dot character ('.') and 
a randomly generated UUID. The UUID part cannot be controlled by the caller of 
the message, and thus it is impossible to re-create a factory configuration 
with the exact same {{service.pid}} on a second cluster node.

The strategy implemented in PR #15 works as follows:
(1) The {{ConfigTaskCreator}} class, which implements the 
{{ResourceTransformer}} interface, already extracts the {{service.pid}}, and in 
the case of a factory configuration the {{factoryPid}}, from the filename of a 
{{RegisteredResource}} representing a configuration. In this extraction logic, 
the {{service.pid}} extracted from the filename is first matched against the 
format of configurations created using Felix' 
{{ConfigurationAdmin#createFactoryConfiguration(...)}} implementation, and the 
{{factoryPid}} and {{name}} are extracted. If it doesn't match, the previous 
logic, looking for a '~' separator etc is used.
(2) In the {{ConfigUtil#getConfiguration(...)}} method, which is used to check 
if a given configuration already exists, a check for a configuration using a 
"legacy naming convention" is used if no configuration was found with a name 
following the expected '~' separated format.

With these two changes the behaviour is as follows:
# a factory configuration is created on cluster node A using the webconsole
# via {{org.apache.sling.installer.provider.jcr}}, the configuration is 
persisted in the JCR repository using the format {{.}}
# cluster node A sees the new RegisteredResource for the configuration, but 
finds a "live" configuration via the legacy support from point (2) above
# cluster node B sees the new RegisteredResource for the configuration, doesn't 
find a matching "live" configuration, and adds the configuration in the format 
{{~}}, where {{}} is the same uuid used on cluster node 
A

> Configuration in Cluster mode are not in sync
> -
>
> Key: SLING-12283
> URL: https://issues.apache.org/jira/browse/SLING-12283
> Project: Sling
>  Issue Type: Bug
>Reporter: Rishabh Daim
>Priority: Major
>
> {color:#172b4d}Configuration in Cluster mode is not in sync. When instances 
> are in shared mode, and a new configuration is created under 1st instance, it 
> is not reflected correctly in 2nd instance. {color}
> {color:#172b4d}The factory PID and hence properties are altered in the 2nd 
> instance.{color}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (SLING-12283) Configuration in Cluster mode are not in sync

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding resolved SLING-12283.

  Assignee: Julian Sedding
Resolution: Fixed

> Configuration in Cluster mode are not in sync
> -
>
> Key: SLING-12283
> URL: https://issues.apache.org/jira/browse/SLING-12283
> Project: Sling
>  Issue Type: Bug
>Reporter: Rishabh Daim
>        Assignee: Julian Sedding
>Priority: Major
>
> {color:#172b4d}Configuration in Cluster mode is not in sync. When instances 
> are in shared mode, and a new configuration is created under 1st instance, it 
> is not reflected correctly in 2nd instance. {color}
> {color:#172b4d}The factory PID and hence properties are altered in the 2nd 
> instance.{color}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (SLING-12329) Backwards compatibility for legacy repoinit statement reordering

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed SLING-12329.
--

> Backwards compatibility for legacy repoinit statement reordering
> 
>
> Key: SLING-12329
> URL: https://issues.apache.org/jira/browse/SLING-12329
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.46
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Minor
> Fix For: Repoinit JCR 1.1.50
>
>
> The fix for repoinit statement reordering can cause issues for users relying 
> on the legacy ordering.
> We should support a fallback to the legacy ordering and log a deprecation 
> message, warning users that their repoinit script relies on the legacy 
> ordering, support for which may be removed in the future.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[RESULT] [VOTE] Release Apache Sling Repoinit JCR 1.1.50

[Julian Sedding]

Hi,

The vote has passed with the following result:

+1 (binding): Joerg Hoh, Eric Norman, Andrei Dulvac, Julian Sedding
+1 (non-binding): none

I will copy this release to the Sling dist directory and
promote the artifacts to the central Maven repository.

Regards
Julian

Re: Sling API exporting @ConsumerType class

[Julian Sedding]

Hi Jörg

In general, I agree that we could, and maybe should, evaluate which
types in the Sling API should be @ProviderType instead of
@ConsumerType. My assumption would be that most types should be
@ProviderType. I don't know what sort of versioning change adding the
@ProviderType annotation causes, however.

Regarding your specific case, I wonder if it would be acceptable to
remove the "putOnly" method, and instead modify the "put" method to
return "null" for in the case where a key was inserted, but the
supplier never evaluated. Of course that would change the behaviour,
so might cause issues in some edge cases.

Regards
Julian

On Mon, Jun 10, 2024 at 12:38 PM Jörg Hoh
 wrote:
>
> Eric pointed out correctly, that there was tight connection between SLING
> API and Scripting core, as the package import range on scripting core
> (bundle version 2.4.8) is quite narrow for the package
> org.apache.sling.api.scripting:
>
> org.apache.sling.api.scripting; version="[2.5, 2.6)"
>
> This is caused by the class LazyBindings being a ConsumerType (
> https://github.com/apache/sling-org-apache-sling-api/blob/bdbd1768969917d0e2436d5b008fff80aaa729dc/src/main/java/org/apache/sling/api/scripting/LazyBindings.java#L56)
> and the scripting core inheriting from it (in ProtectedBindings).
>
> My latest extension to it (SLING-12062) then caused a bump of the exported
> version, thus breaking the existing imports.
>
> Of course I could do a release of the Scripting Core as well and make sure
> that it works with the package version as well, but I wonder if this is the
> right thing to do.
>
> Should the Sling API export ConsumerType interfaces and classes at all,
> which can cause this type of problems, or should we try to avoid them? This
> is a more general question; and in case that we want to avoid those, the
> question is still how we want to move forward with this specific instance
> of it.
>
> My personal opinion is
> * to avoid @ConsumerType exports in the Sling API in general and
> * move the ProtectedBindings class, which inherits from the LazyBindings
> over to the API
>
> that would allow us to have a wider import range on the scripting.core side.
>
> WDYT?
>
> Jörg
>
>
> --
> https://cqdump.joerghoh.de

Re: VOTE] Release Apache Sling Feature Model Analyser 2.0.4

[Julian Sedding]

+1

Regards
Julian

On Fri, Jun 7, 2024 at 5:40 PM Jörg Hoh  wrote:
>
> +1
>
> (You might need to update your gpg keys before)
>
> Am Fr., 7. Juni 2024 um 14:00 Uhr schrieb ang...@apache.org <
> ang...@apache.org>:
>
> > Hi everyone,
> >
> > We solved 4 issues in this release:
> >
> >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710&version=12353831&styleName=Text
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-2866/
> >
> > 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 2866 /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.
> >
> > Thanks for voting and kind regards
> > Angela
> >
>
>
> --
> https://cqdump.joerghoh.de

Re: [VOTE] Release Apache Sling API 2.27.4

[Julian Sedding]

+1

Regards
Julian

On Tue, Jun 4, 2024 at 3:25 PM Jörg Hoh  wrote:
>
> +1
>
> Am Di., 4. Juni 2024 um 15:24 Uhr schrieb Jörg Hoh :
>
> > We solved 9 issues in this 
> > release:https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12353245&styleName=Text&projectId=12310710
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-2865/
> >
> > You can use this UNIX script to download the release and verify the 
> > signatures:https://raw.githubusercontent.com/apache/sling-tooling-release/master/check_staged_release.sh
> > Usage:
> > sh check_staged_release.sh 2865 /tmp/sling-staging
> >
> > Please vote to approve this release:
> >
> >   [ ] +1 Approve the release
> >   [ ]  0 Don't care
> >   [ ] -1 Don't release, because ...
> >
> > This majority vote is open for at least 72 hours.
> >
> >
> >
> > --
> > https://cqdump.joerghoh.de
> >
> >
>
> --
> https://cqdump.joerghoh.de

Re: [VOTE] Release Apache Sling Repoinit JCR 1.1.50

[Julian Sedding]

+1

Regards
Julian

On Tue, Jun 4, 2024 at 3:25 PM Julian Sedding  wrote:
>
> Hi,
>
> We solved 1 issue in this release:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710&version=12354758&styleName=Text
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-2864/
>
> 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 2864 /tmp/sling-staging
>
> Please vote to approve this release:
>
>   [ ] +1 Approve the release
>   [ ]  0 Don't care
>   [ ] -1 Don't release, because ...
>
> This majority vote is open for at least 72 hours.
>
> Regards
> Julian

[VOTE] Release Apache Sling Repoinit JCR 1.1.50

[Julian Sedding]

Hi,

We solved 1 issue in this release:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710&version=12354758&styleName=Text

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-2864/

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 2864 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Regards
Julian

[jira] [Updated] (SLING-11621) Outdated JCR dependencies

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-11621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated SLING-11621:
---
Fix Version/s: (was: Repoinit JCR 1.1.50)

> Outdated JCR dependencies
> -
>
> Key: SLING-11621
> URL: https://issues.apache.org/jira/browse/SLING-11621
> Project: Sling
>  Issue Type: Task
>  Components: Repoinit
>Reporter: Julian Reschke
>Priority: Major
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> https://github.com/apache/sling-org-apache-sling-jcr-repoinit/blob/9913b787574186a7a31d184480cec3862816438f/pom.xml#L39:
> {noformat}
> 2.18.2
> 1.22.1
> {noformat}
> Jackrabbit 2.18 has been EOLd quite some time ago...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (SLING-12122) Add unit-test creating group with rep:externalId property

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated SLING-12122:
---
Fix Version/s: (was: Repoinit JCR 1.1.50)

> Add unit-test creating group with rep:externalId property
> -
>
> Key: SLING-12122
> URL: https://issues.apache.org/jira/browse/SLING-12122
> Project: Sling
>  Issue Type: Test
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.44
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Minor
>
> Add a unit-test validating that repoinit can successfully create a new group 
> with the {{rep:externalId}} property, that can only be set on creation.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (SLING-12329) Backwards compatibility for legacy repoinit statement reordering

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding resolved SLING-12329.

Resolution: Fixed

> Backwards compatibility for legacy repoinit statement reordering
> 
>
> Key: SLING-12329
> URL: https://issues.apache.org/jira/browse/SLING-12329
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.46
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Minor
> Fix For: Repoinit JCR 1.1.50
>
>
> The fix for repoinit statement reordering can cause issues for users relying 
> on the legacy ordering.
> We should support a fallback to the legacy ordering and log a deprecation 
> message, warning users that their repoinit script relies on the legacy 
> ordering, support for which may be removed in the future.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (SLING-12237) Extend exception message for RepositoryInitializerFactory with config PID and affected script/reference

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed SLING-12237.
--

> Extend exception message for RepositoryInitializerFactory with config PID and 
> affected script/reference
> ---
>
> Key: SLING-12237
> URL: https://issues.apache.org/jira/browse/SLING-12237
> Project: Sling
>  Issue Type: Improvement
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.46
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: Repoinit JCR 1.1.48
>
>
> Currently an error in any of the repoinit scripts or reference just lead to 
> an exception which does not expose the configuration PID triggering the 
> exception, e.g.
> {code}
> javax.jcr.RepositoryException: Applying repoinit operation failed despite 
> retry; set loglevel to DEBUG to see all exceptions. Last exception message 
> was: Session.save failed: javax.jcr.nodetype.ConstraintViolationException: 
> OakConstraint0001: /var/groovyconsole[[nt:folder]]: No matching definition 
> found for child node audit with effective type [nt:unstructured]
>   at 
> org.apache.sling.jcr.repoinit.impl.RepositoryInitializerFactory.applyOperations(RepositoryInitializerFactory.java:176)
>  [org.apache.sling.jcr.repoinit:1.1.38]
> {code}
> As repo init scripts are contributed from many different source locations the 
> underlying configuration PID should be contained in the exception message as 
> well. In addition the index of the according script or the according 
> reference URL should be included.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (SLING-12323) [RepoInit] Avoid java.nio.file.Path for parsing repository paths

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed SLING-12323.
--

> [RepoInit] Avoid java.nio.file.Path for parsing repository paths
> 
>
> Key: SLING-12323
> URL: https://issues.apache.org/jira/browse/SLING-12323
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.46
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Major
> Fix For: Repoinit JCR 1.1.48
>
>
> RepoInit uses {{java.nio.file.Path}} to determine the "parent path" and 
> "name" of a relative repository path. This fails on Windows when the relative 
> repository path contains a colon ":".
> The implementation should not be platform dependent.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (SLING-12243) Standalone execution of Repoinit statements is not clearly documented

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed SLING-12243.
--

> Standalone execution of Repoinit statements is not clearly documented
> -
>
> Key: SLING-12243
> URL: https://issues.apache.org/jira/browse/SLING-12243
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.46
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: Repoinit JCR 1.1.48
>
>
> The repoinit documentation at 
> [https://sling.apache.org/documentation/bundles/repository-initialization.html]
>  does not clearly indicate how to execute repoinit statements outside of the 
> repository initialization cycle. The information is present but not obvious.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[RESULT] [VOTE] Release Apache Sling Repoinit JCR 1.1.48

[Julian Sedding]

Hi,

The vote has passed with the following result:

+1 (binding): Robert Munteanu, Radu Cotescu, Joerg Hoh, Julian Sedding
+1 (non-binding): none

I will copy this release to the Sling dist directory and promote the
artifacts to the central Maven repository.

Regards
Julian

Re: [VOTE] Release Apache Sling Repoinit JCR 1.1.48

[Julian Sedding]

+1

Regards
Julian

On Mon, May 27, 2024 at 3:27 PM Jörg Hoh  wrote:
>
> +1
>
> Am Sa., 25. Mai 2024 um 11:55 Uhr schrieb Julian Sedding  >:
>
> > Hi,
> >
> > We solved 3 issues in the Apache Sling Repoinit JCR 1.1.48 release:
> >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710&version=12353873&styleName=Text
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-2862/
> >
> > You can use this UNIX script to download the release and verify the
> > signatures:
> >
> > https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD
> >
> > Usage: sh check_staged_release.sh 2862 /tmp/sling-staging
> >
> > Please vote to approve this release:
> >
> > [  ]  +1 Approve the release
> > [  ]0 Don't care
> > [  ]   -1 Don't release, because ...
> >
> > This majority vote is open for at least 72 hours.
> >
> > Regards
> > Julian
> >
>
>
> --
> https://cqdump.joerghoh.de

Re: [VOTE] Release Apache Sling Engine 2.15.16

[Julian Sedding]

+1

Regards
Julian

On Fri, May 31, 2024 at 7:27 AM Eric Norman  wrote:
>
> +1
>
> Regards,
> Eric
>
> On Tue, May 28, 2024 at 8:00 AM Jörg Hoh 
> wrote:
>
> > Hi,
> >
> > We solved 5 issues in this
> > release:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710&version=12354681&styleName=Text
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-2863/
> >
> > 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 2863 /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 hours5
> >
> > Jörg
> >
> > --
> > https://cqdump.joerghoh.de
> >

[jira] [Created] (SLING-12329) Backwards compatibility for legacy repoinit statement reordering

[Julian Sedding (Jira)]

Julian Sedding created SLING-12329:
--

 Summary: Backwards compatibility for legacy repoinit statement 
reordering
 Key: SLING-12329
 URL: https://issues.apache.org/jira/browse/SLING-12329
 Project: Sling
  Issue Type: Improvement
  Components: Repoinit
Affects Versions: Repoinit JCR 1.1.46
Reporter: Julian Sedding
Assignee: Julian Sedding
 Fix For: Repoinit JCR 1.1.50


The fix for repoinit statement reordering can cause issues for users relying on 
the legacy ordering.

We should support a fallback to the legacy ordering and log a deprecation 
message, warning users that their repoinit script relies on the legacy 
ordering, support for which may be removed in the future.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[VOTE] Release Apache Sling Repoinit JCR 1.1.48

[Julian Sedding]

Hi,

We solved 3 issues in the Apache Sling Repoinit JCR 1.1.48 release:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710&version=12353873&styleName=Text

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-2862/

You can use this UNIX script to download the release and verify the signatures:
https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD

Usage: sh check_staged_release.sh 2862 /tmp/sling-staging

Please vote to approve this release:

[  ]  +1 Approve the release
[  ]0 Don't care
[  ]   -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Regards
Julian

[jira] [Resolved] (SLING-12323) [RepoInit] Avoid java.nio.file.Path for parsing repository paths

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding resolved SLING-12323.

Fix Version/s: Repoinit JCR 1.1.48
   Resolution: Fixed

> [RepoInit] Avoid java.nio.file.Path for parsing repository paths
> 
>
> Key: SLING-12323
> URL: https://issues.apache.org/jira/browse/SLING-12323
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.46
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Major
> Fix For: Repoinit JCR 1.1.48
>
>
> RepoInit uses {{java.nio.file.Path}} to determine the "parent path" and 
> "name" of a relative repository path. This fails on Windows when the relative 
> repository path contains a colon ":".
> The implementation should not be platform dependent.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (SLING-12323) [RepoInit] Avoid java.nio.file.Path for parsing repository paths

[Julian Sedding (Jira)]

Julian Sedding created SLING-12323:
--

 Summary: [RepoInit] Avoid java.nio.file.Path for parsing 
repository paths
 Key: SLING-12323
 URL: https://issues.apache.org/jira/browse/SLING-12323
 Project: Sling
  Issue Type: Bug
  Components: Repoinit
Affects Versions: Repoinit JCR 1.1.46
Reporter: Julian Sedding
Assignee: Julian Sedding


RepoInit uses {{java.nio.file.Path}} to determine the "parent path" and "name" 
of a relative repository path. This fails on Windows when the relative 
repository path contains a colon ":".

The implementation should not be platform dependent.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Release Apache Sling Servlets Resolver version 2.11.2

[Julian Sedding]

+1

Regards
Julian

On Wed, Feb 21, 2024 at 4:37 PM Radu Cotescu  wrote:
>
> +1
>
> On Wed, 21 Feb 2024 at 14:28, Jörg Hoh  wrote:
> > Please vote to approve this release:
> >
> >   [ ] +1 Approve the release
> >   [ ]  0 Don't care
> >   [ ] -1 Don't release, because ...
> >

Re: Introduce spotless-maven-plugin

[Julian Sedding]

Thanks Konrad!

Regards
Julian

On Fri, Dec 8, 2023 at 4:43 PM Konrad Windszus  wrote:
>
> I created https://issues.apache.org/jira/browse/SLING-12186 to track this and 
> linked two feature branches where this has been tried out.
> Please have a look there.
>
> @Julian: checking happens in phase “process-sources” 
> (https://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html#Lifecycle_Reference)
>  which is pretty early.
>
> Konrad
>
> > On 7. Dec 2023, at 12:40, Stefan Seifert 
> >  wrote:
> >
> >
> >> Sure, any candidate(s) you have in mind? Then I can prepare a PR with the
> >> proposed changes.
> >> Konrad
> >
> > e.g. models-api and models-impl
> >
> > we have to keep in mind that once we apply one-time reformatting of the 
> > code base, all open PRs might be in conflict and will only be mergeable 
> > with manual work.
> >
> > stefan
> >
>

Re: Introduce spotless-maven-plugin

[Julian Sedding]

+1 - for automatic code checking and optional formatting

If it's fast enough, I like having these kind of checks in an early
build-phase. If it only fails late, i.e. on verify or install, that
somehow feels more disruptive to me.

Regards
Julian

On Wed, Dec 6, 2023 at 1:44 PM Konrad Windszus  wrote:
>
> Sure, any candidate(s) you have in mind? Then I can prepare a PR with the 
> proposed changes.
> Konrad
>
> > On 6. Dec 2023, at 11:00, Stefan Seifert 
> >  wrote:
> >
> > ok, sounds good.
> >
> > maybe we can give it a try on one or two modules before forcing it down to 
> > everyone via the parent pom?
> >
> > stefan
> >
> >> -Original Message-
> >> From: Konrad Windszus 
> >> Sent: Wednesday, December 6, 2023 10:56 AM
> >> To: dev@sling.apache.org
> >> Subject: Re: Introduce spotless-maven-plugin
> >>
> >> The basic idea is to introduce that with a new parent pom. Once a module
> >> adopts this new parent version, it needs to manually reformat everything
> >> once to not fail the build. This is a one time effort together with
> >> updating to the new pom.
> >> Therefore it requires some opt-in per module anyways.
> >> Konrad
> >>
> >>> On 6. Dec 2023, at 10:53, Stefan Seifert  >> e.com.INVALID> wrote:
> >>>
> >>> i like it to have tooling like this around (but if have no experience
> >> with this tool).
> >>>
> >>> one important point is that e.g. for PRs it only validates newly added
> >> lines. if all PRs fail due to inconsistent formatting in the existing
> >> codebase this would be quite disruptive.
> >>>
> >>> stefan
> >>>
>  -Original Message-
>  From: Konrad Windszus 
>  Sent: Tuesday, December 5, 2023 9:18 PM
>  To: dev@sling.apache.org
>  Subject: Introduce spotless-maven-plugin
> 
>  Hi,
>  We never had any formalised code formatting rules nor ever provided any
>  formatters for different IDEs (at least not that I am aware of).
>  That often leads to undesired formatting changes in PRs.
>  I propose to introduce
>  https://github.com/diffplug/spotless/tree/main/plugin-maven to
>  automatically enforce certain formatting rules during build (as well as
> >> to
>  optionally apply those).
> 
>  There are quite some built-in rule sets.
>  Apache Maven uses
> >> https://github.com/diffplug/spotless/tree/main/plugin-
>  maven#palantir-java-format and
>  https://github.com/diffplug/spotless/tree/main/plugin-maven#maven-pom
>  quite successfully for a while now.
> 
>  I am open to using another rule set, but the important bit is that we
> >> can
>  enforce that across different IDEs easily during the build and fixing
> >> is
>  easy for contributors/committers as well.
> 
>  WDYT?
> 
>  Konrad
> >
>

[jira] [Resolved] (SLING-12162) Update o.a.s.junit.core to jupiter 5.10.1

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding resolved SLING-12162.

Resolution: Fixed

> Update o.a.s.junit.core to jupiter 5.10.1
> -
>
> Key: SLING-12162
> URL: https://issues.apache.org/jira/browse/SLING-12162
> Project: Sling
>  Issue Type: Task
>  Components: JUnit Core
>Affects Versions: JUnit Core 1.1.6
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Major
> Fix For: JUnit Core 1.1.8
>
>
> In the context of [PR 
> #20|https://github.com/apache/sling-org-apache-sling-junit-core/pull/20], it 
> turned out that a change between jupiter 5.10.0 and 5.10.1 brakes a test case.
> I have identified the [relevant 
> change|https://github.com/junit-team/junit5/pull/3500/files#diff-eec44cb3c2bd65dc0944562c5b919097b7995cbbd874f3ff6f9cd1dd170a2814R1506-L1510]
>  to be stricter enforcement of a test method predicate. It turns out that we 
> have a meta-test (we're running tests within tests for o.a.s.junit.core) that 
> overrides and inherited test method, but does not itself add the `@Test` 
> annotation on it. That way the test method in question is not found, which 
> fails an assertion that checks if any meta-tests were run.
> cc [~apelluru]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (SLING-12162) Update o.a.s.junit.core to jupiter 5.10.1

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated SLING-12162:
---
Fix Version/s: JUnit Core 1.1.8

> Update o.a.s.junit.core to jupiter 5.10.1
> -
>
> Key: SLING-12162
> URL: https://issues.apache.org/jira/browse/SLING-12162
> Project: Sling
>  Issue Type: Task
>  Components: JUnit Core
>Affects Versions: JUnit Core 1.1.6
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Major
> Fix For: JUnit Core 1.1.8
>
>
> In the context of [PR 
> #20|https://github.com/apache/sling-org-apache-sling-junit-core/pull/20], it 
> turned out that a change between jupiter 5.10.0 and 5.10.1 brakes a test case.
> I have identified the [relevant 
> change|https://github.com/junit-team/junit5/pull/3500/files#diff-eec44cb3c2bd65dc0944562c5b919097b7995cbbd874f3ff6f9cd1dd170a2814R1506-L1510]
>  to be stricter enforcement of a test method predicate. It turns out that we 
> have a meta-test (we're running tests within tests for o.a.s.junit.core) that 
> overrides and inherited test method, but does not itself add the `@Test` 
> annotation on it. That way the test method in question is not found, which 
> fails an assertion that checks if any meta-tests were run.
> cc [~apelluru]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (SLING-12162) Update o.a.s.junit.core to jupiter 5.10.1

[Julian Sedding (Jira)]

Julian Sedding created SLING-12162:
--

 Summary: Update o.a.s.junit.core to jupiter 5.10.1
 Key: SLING-12162
 URL: https://issues.apache.org/jira/browse/SLING-12162
 Project: Sling
  Issue Type: Task
  Components: JUnit Core
Affects Versions: JUnit Core 1.1.6
Reporter: Julian Sedding
Assignee: Julian Sedding


In the context of [PR 
#20|https://github.com/apache/sling-org-apache-sling-junit-core/pull/20], it 
turned out that a change between jupiter 5.10.0 and 5.10.1 brakes a test case.

I have identified the [relevant 
change|https://github.com/junit-team/junit5/pull/3500/files#diff-eec44cb3c2bd65dc0944562c5b919097b7995cbbd874f3ff6f9cd1dd170a2814R1506-L1510]
 to be stricter enforcement of a test method predicate. It turns out that we 
have a meta-test (we're running tests within tests for o.a.s.junit.core) that 
overrides and inherited test method, but does not itself add the `@Test` 
annotation on it. That way the test method in question is not found, which 
fails an assertion that checks if any meta-tests were run.

cc [~apelluru]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (SLING-12115) Repoinit should leave importBehaviour for ACL creation to JCR

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed SLING-12115.
--

> Repoinit should leave importBehaviour for ACL creation to JCR
> -
>
> Key: SLING-12115
> URL: https://issues.apache.org/jira/browse/SLING-12115
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.44
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Major
> Fix For: Repoinit JCR 1.1.46
>
>
> JCR Repoinit checks the existence of the principal, for which ACLs should be 
> created. In an Oak repository, this check depends on the {{ImportBehaviour}} 
> configured for the {{SecurityProvider}}. JCR Repoinit should not check, but 
> instead rely on the repository's behaviour.
> cc [~angela]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (SLING-12107) JCR Repoinit executes operations out of order

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed SLING-12107.
--

> JCR Repoinit executes operations out of order
> -
>
> Key: SLING-12107
> URL: https://issues.apache.org/jira/browse/SLING-12107
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.44
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Major
> Fix For: Repoinit JCR 1.1.46
>
>
> When applying ACLs, repoinit checks if the referenced authorizable exists, 
> and it fails if it doesn't.
> However, my goal was to set up ACLs with my deployment for a group that was 
> to be sync'ed from an {{ExternalIdentityProvider}} once the first member of 
> that group logs in.
> To work around this limitation, I tried running the following repoinit script:
> {noformat}
> create group testGroup
> set ACL for testGroup
>   allow jcr:read on /content/foo
>   deny jcr:write on /content/foo
> end
> delete group testGroup
> {noformat}
> It turned out that the statements were executed in the following order:
> {noformat}
> create group testGroup
> delete group testGroup
> set ACL for testGroup
>   allow jcr:read on /content/foo
>   deny jcr:write on /content/foo
> end
> {noformat}
> Of course that caused the script to fail just as if no group was created.
> The incorrect ordering may also cause other scenarios to fail.
> The {{ExecutionOrderTest}} suggests that some re-ordering is done on purpose. 
> E.g. namespaces and nodetypes should be created before e.g. paths are created.
> I would expect that registration of custom privileges should also be executed 
> before other operations. I don't see how that could be harmful.
> But for all other statements, I would expect the execution order to match the 
> order of the statements within the repoinit script.
> cc [~bdelacretaz], [~cziegeler], [~angela]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (SLING-12114) Update org.apache.sling.jcr.repoinit to parent pom 52

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed SLING-12114.
--

> Update org.apache.sling.jcr.repoinit to parent pom 52
> -
>
> Key: SLING-12114
> URL: https://issues.apache.org/jira/browse/SLING-12114
> Project: Sling
>  Issue Type: Task
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.44
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Minor
> Fix For: Repoinit JCR 1.1.46
>
>
> Update to parent pom version 52, update used and remove unnecessary 
> dependencies.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (SLING-12122) Add unit-test creating group with rep:externalId property

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated SLING-12122:
---
Fix Version/s: Repoinit JCR 1.1.48
   (was: Repoinit JCR 1.1.46)

> Add unit-test creating group with rep:externalId property
> -
>
> Key: SLING-12122
> URL: https://issues.apache.org/jira/browse/SLING-12122
> Project: Sling
>  Issue Type: Test
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.44
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Minor
> Fix For: Repoinit JCR 1.1.48
>
>
> Add a unit-test validating that repoinit can successfully create a new group 
> with the {{rep:externalId}} property, that can only be set on creation.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (SLING-11621) Outdated JCR dependencies

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-11621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding updated SLING-11621:
---
Fix Version/s: Repoinit JCR 1.1.48
   (was: Repoinit JCR 1.1.46)

> Outdated JCR dependencies
> -
>
> Key: SLING-11621
> URL: https://issues.apache.org/jira/browse/SLING-11621
> Project: Sling
>  Issue Type: Task
>  Components: Repoinit
>Reporter: Julian Reschke
>Priority: Major
> Fix For: Repoinit JCR 1.1.48
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> https://github.com/apache/sling-org-apache-sling-jcr-repoinit/blob/9913b787574186a7a31d184480cec3862816438f/pom.xml#L39:
> {noformat}
> 2.18.2
> 1.22.1
> {noformat}
> Jackrabbit 2.18 has been EOLd quite some time ago...



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[RESULT] [VOTE] Release Apache Sling Repoinit JCR 1.1.46

[Julian Sedding]

Hi,

The vote has passed with the following result:

+1 (binding): Stefan Seifert, Carsten Ziegeler, Dan Klco, Joerg Hoh,
Julian Sedding
+1 (non-binding): none

I will copy this release to the Sling dist directory and
promote the artifacts to the central Maven repository.

Regards
Julian


On Fri, Nov 17, 2023 at 11:44 AM Julian Sedding  wrote:
>
> +1
>
> Regards
> Julian
>
> On Tue, Nov 14, 2023 at 8:22 AM Jörg Hoh  
> wrote:
> >
> > +1
> >
> > Am Mo., 13. Nov. 2023 um 13:25 Uhr schrieb Julian Sedding <
> > jsedd...@gmail.com>:
> >
> > > Hi,
> > >
> > > We solved 3 issues in this release:
> > >
> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710&version=12352870&styleName=Text
> > >
> > > Staging repository:
> > > https://repository.apache.org/content/repositories/orgapachesling-2807/
> > >
> > > 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 2807 /tmp/sling-staging
> > >
> > > Please vote to approve this release:
> > >
> > >   [ ] +1 Approve the release
> > >   [ ]  0 Don't care
> > >   [ ] -1 Don't release, because ...
> > >
> > > This majority vote is open for at least 72 hours.
> > >
> > > Regards
> > > Julian
> > >
> >
> >
> > --
> > Cheers,
> > Jörg Hoh,
> >
> > https://cqdump.joerghoh.de
> > Twitter: @joerghoh

Re: [VOTE] Release Apache Sling Repoinit JCR 1.1.46

[Julian Sedding]

+1

Regards
Julian

On Tue, Nov 14, 2023 at 8:22 AM Jörg Hoh  wrote:
>
> +1
>
> Am Mo., 13. Nov. 2023 um 13:25 Uhr schrieb Julian Sedding <
> jsedd...@gmail.com>:
>
> > Hi,
> >
> > We solved 3 issues in this release:
> >
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710&version=12352870&styleName=Text
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-2807/
> >
> > 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 2807 /tmp/sling-staging
> >
> > Please vote to approve this release:
> >
> >   [ ] +1 Approve the release
> >   [ ]  0 Don't care
> >   [ ] -1 Don't release, because ...
> >
> > This majority vote is open for at least 72 hours.
> >
> > Regards
> > Julian
> >
>
>
> --
> Cheers,
> Jörg Hoh,
>
> https://cqdump.joerghoh.de
> Twitter: @joerghoh

Re: [VOTE] Release Apache Sling Testing OSGi Mock 3.4.0

[Julian Sedding]

+1

Thank you Stefan!

Regards
Julian

On Fri, Nov 17, 2023 at 10:10 AM Stefan Seifert
 wrote:
>
> +1
>
> stefan

Re: [VOTE] Release Apache Sling Engine 2.15.8

[Julian Sedding]

+1

Regards
Julian

On Wed, Nov 15, 2023 at 4:02 PM Daniel Klco  wrote:
>
> +1
>
> On Wed, Nov 15, 2023 at 3:17 AM Stefan Seifert
>  wrote:
>
> > +1
> >
> > stefan
> >

[jira] [Created] (SLING-12157) [osgi-mock] late binding does not work for non-service DS components

[Julian Sedding (Jira)]

Julian Sedding created SLING-12157:
--

 Summary: [osgi-mock] late binding does not work for non-service DS 
components 
 Key: SLING-12157
 URL: https://issues.apache.org/jira/browse/SLING-12157
 Project: Sling
  Issue Type: Task
  Components: Testing
Affects Versions: Testing OSGi Mock 3.3.10
Reporter: Julian Sedding
Assignee: Julian Sedding


A DS component that is not a service can be "injected" and "activated", but if 
a service becomes available, that satisfies a dynamic reference, the "bind" 
method is not called. The same should be true for the "unbind" scenario.

I observed this when I was registering a {{ResourceDecorator}} service in a 
test case, and it did not get bound by the {{ResourceResolverFactoryActivator}} 
that was already registered by the {{SlingContext}}.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Release Apache Sling Resource Resolver 1.11.4

[Julian Sedding]

+1

Regards
Julian

On Tue, Nov 14, 2023 at 11:37 AM Stefan Seifert
 wrote:
>
> +1
>
> stefan

Re: [VOTE] Release Apache Sling slingfeature maven plugin 1.8.0

[Julian Sedding]

+1

Regards
Julian

On Tue, Nov 14, 2023 at 8:21 AM Jörg Hoh  wrote:
>
> +1
>
> Am Mo., 13. Nov. 2023 um 10:41 Uhr schrieb Carsten Ziegeler <
> cziege...@apache.org>:
>
> > Hi,
> >
> > We solved 6 issues in the feature model
> > https://issues.apache.org/jira/projects/SLING/versions/12353832
> >
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-2806/
> >
> > You can use this UNIX script to download the release and verify the
> > signatures:
> >
> > https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD
> >
> > Usage:
> > sh check_staged_release.sh 2806 /tmp/sling-staging
> >
> > Please vote to approve this release:
> >
> >[ ] +1 Approve the release
> >[ ]  0 Don't care
> >[ ] -1 Don't release, because ...
> >
> > This majority vote is open for at least 72 hours.
> >
> > Regards
> > Carsten
> > --
> > Carsten Ziegeler
> > Adobe
> > cziege...@apache.org
> >
>
>
> --
> Cheers,
> Jörg Hoh,
>
> https://cqdump.joerghoh.de
> Twitter: @joerghoh

[jira] [Commented] (SLING-12153) Update maven-archiver and maven-filtering

[Julian Sedding (Jira)]

[ 
https://issues.apache.org/jira/browse/SLING-12153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17785985#comment-17785985
 ] 

Julian Sedding commented on SLING-12153:


The dependency in question is 
{{org.eclipse.sisu:org.eclipse.sisu.plexus:0.0.0.M2a}}, which pulls in 
{{com.google.guava:guava:10.0.1}}. After updating both the {{maven-archiver}} 
and {{maven-filtering}} dependencies, the dependency to 
{{org.eclipse.sisu:org.eclipse.sisu.plexus}} becomes a test dependency and thus 
no longer appears in the transitive dependency graph.

The exception stack trace was:
{noformat}
java.lang.NoSuchMethodError: 'com.google.common.cache.CacheBuilder 
com.google.common.cache.CacheBuilder.maximumSize(long)'
at 
com.github.fge.jsonschema.core.load.SchemaLoader.(SchemaLoader.java:105)
at 
com.github.fge.jsonschema.main.JsonSchemaFactory.(JsonSchemaFactory.java:138)
at 
com.github.fge.jsonschema.main.JsonSchemaFactoryBuilder.freeze(JsonSchemaFactoryBuilder.java:139)
at 
com.github.fge.jsonschema.main.JsonSchemaFactory.byDefault(JsonSchemaFactory.java:113)
at 
org.apache.sling.feature.maven.Preprocessor.(Preprocessor.java:66)
at 
org.apache.sling.feature.maven.mojos.DependencyLifecycleParticipant.afterProjectsRead(DependencyLifecycleParticipant.java:79)
at 
org.jetbrains.idea.maven.server.utils.Maven3XProjectResolver.loadExtensions(Maven3XProjectResolver.java:391)
at 
org.jetbrains.idea.maven.server.utils.Maven3XProjectResolver.lambda$doResolveProject$2(Maven3XProjectResolver.java:153)
at 
org.jetbrains.idea.maven.server.Maven3ServerEmbedder.executeWithSessionScope(Maven3ServerEmbedder.java:289)
at 
org.jetbrains.idea.maven.server.Maven3ServerEmbedder.executeWithMavenSession(Maven3ServerEmbedder.java:232)
at 
org.jetbrains.idea.maven.server.utils.Maven3XProjectResolver.doResolveProject(Maven3XProjectResolver.java:117)
at 
org.jetbrains.idea.maven.server.utils.Maven3XProjectResolver.resolveProjects(Maven3XProjectResolver.java:88)
at 
org.jetbrains.idea.maven.server.Maven3XServerEmbedder.resolveProjects(Maven3XServerEmbedder.java:528)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at 
java.rmi/sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:360)
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(AccessController.java:712)
at java.rmi/sun.rmi.transport.Transport.serviceCall(Transport.java:196)
at 
java.rmi/sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:587)
at 
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:828)
at 
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:705)
at 
java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at 
java.rmi/sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:704)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
{noformat}

The problem is a signature change from {{CacheBuilder#maximumSize(int)}} to 
{{CacheBuilder#maximumSize(long)}} somewhere between guava 10.0.1 and more 
modern versions.

> Update maven-archiver and maven-filtering
> -
>
> Key: SLING-12153
> URL: https://issues.apache.org/jira/browse/SLING-12153
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Minor
> Fix For: OSGi Feature Maven Plugin 1.8.2
>
>
> [~jsedding] noticed that the plug-in brings in older versions of the 
> maven-archiver and maven-filtering. Those dependencies 
> {quote}drag an ancient guava version into the classpath via a transitive 
> dependency that was moved into "test" scope in newer versions of these two 
> libraries{quote}
> This causes various problems with IntelliJ and Eclipse integration. And 
> upgrading dependencies is always a good idea :-)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[VOTE] Release Apache Sling Repoinit JCR 1.1.46

[Julian Sedding]

Hi,

We solved 3 issues in this release:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710&version=12352870&styleName=Text

Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-2807/

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 2807 /tmp/sling-staging

Please vote to approve this release:

  [ ] +1 Approve the release
  [ ]  0 Don't care
  [ ] -1 Don't release, because ...

This majority vote is open for at least 72 hours.

Regards
Julian

[jira] [Resolved] (SLING-12114) Update org.apache.sling.jcr.repoinit to parent pom 52

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding resolved SLING-12114.

Resolution: Fixed

> Update org.apache.sling.jcr.repoinit to parent pom 52
> -
>
> Key: SLING-12114
> URL: https://issues.apache.org/jira/browse/SLING-12114
> Project: Sling
>  Issue Type: Task
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.44
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Minor
> Fix For: Repoinit JCR 1.1.46
>
>
> Update to parent pom version 52, update used and remove unnecessary 
> dependencies.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (SLING-12115) Repoinit should leave importBehaviour for ACL creation to JCR

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding resolved SLING-12115.

Resolution: Fixed

> Repoinit should leave importBehaviour for ACL creation to JCR
> -
>
> Key: SLING-12115
> URL: https://issues.apache.org/jira/browse/SLING-12115
> Project: Sling
>  Issue Type: Bug
>  Components: Repoinit
>Affects Versions: Repoinit JCR 1.1.44
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Major
> Fix For: Repoinit JCR 1.1.46
>
>
> JCR Repoinit checks the existence of the principal, for which ACLs should be 
> created. In an Oak repository, this check depends on the {{ImportBehaviour}} 
> configured for the {{SecurityProvider}}. JCR Repoinit should not check, but 
> instead rely on the repository's behaviour.
> cc [~angela]



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies

[Julian Sedding (Jira)]

[ 
https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784238#comment-17784238
 ] 

Julian Sedding commented on SLING-12131:


We have {{org.apache.sling.testing.osgi-mock}} and 
{{org.apache.sling.testing.osgi-mock}} testing libraries, which each provide a 
rule. You can find projects importing them with a [github 
search|https://github.com/search?q=org%3Aapache+org.apache.sling.testing.osgi-mock+language%3A%22Maven+POM%22+-repo%3Aapache%2Fsling-whiteboard&type=code]
 (adjust for sling-mock). Note, when JUnit5 came along, their respective junit4 
(and thus rule-based) variants were renamed to 
{{org.apache.sling.testing.osgi-mock.junit4}} and 
{{{}org.apache.sling.testing.sling-mock.junit4{}}}.

There's also 
[{{org.apache.sling.junit.teleporter}}|https://github.com/apache/sling-org-apache-sling-junit-teleporter],
 not sure that's widely used, but it would be very difficult to rewrite for 
JUnit5. You could search for usages of that one as well.

> Update sling-parent pom.xml to include JUnit5 dependencies
> --
>
> Key: SLING-12131
> URL: https://issues.apache.org/jira/browse/SLING-12131
> Project: Sling
>  Issue Type: Task
>Reporter: Rob McDougall
>Priority: Major
>
> JUnit4 is in maintenance mode (no updates in the last 2 years and then only 
> security fixes).  I think updating projects to JUnit5 should be encouraged.
> I am thinking this should be a relatively easy change of adding the 
> junit-jupiter and junit-vintage-engine into the Dependency Management section 
> of the sling-parent.
> Once this is done, individual projects could switch to the vintage-engine (at 
> the very least) or move to jupiter by switching the dependency in their 
> project pom.
> Some day down the road, the JUnit 4 dependencies could be removed.  Projects 
> that have not updated to JUnit5 (vintage or jupiter) by that time are likely 
> no longer maintained.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies

[Julian Sedding (Jira)]

[ 
https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784213#comment-17784213
 ] 

Julian Sedding edited comment on SLING-12131 at 11/8/23 9:49 PM:
-

{quote}Given that, unless anyone objects, I am going to create a PR for this.
{quote}
Go ahead! I think we have a clear consensus on that one.
{quote}I've used this before and it works well, [...]
{quote}
Glad to hear that!
{quote}Well, complete conversion to JUnit5 Jupiter should not be required 
before the JUnit4 can be removed. Conversion to JUnit5 Vintage Engine should 
handle custom @Rules and whatever other JUnit4 constructs are being used. 
That's all I am talking about. Once that is done, the dependency on the 
unmaintained JUnit4 is removed. Conversion from Vintage to Jupiter can take as 
long as it takes.
{quote}
JUnit4 is not removed as long as you have the JUnit5 Vintage Engine. JUnit4 is 
then just a transitive dependency and not explicitly in your pom. As long as 
you are using @Rules, which are a JUnit4 API, you cannot remove the JUnit4 
dependency. There is also {{{}junit-jupiter-migrationsupport{}}}, which can 
emulate some JUnit4 rules. But again, that one does not remove the dependency 
on the @Rule API provided by the JUnit4 dependency.

So I think we're finding common ground :) I'm conceding that migrating is 
desirable, and you seem to be conceding that it's a best-effort exercise and 
some parts of such a migration can be non-trivial.


was (Author: jsedding):
bq. Given that, unless anyone objects, I am going to create a PR for this.

Go ahead! I think we have a clear consencus on that one.

bq. I've used this before and it works well, [...]

Glad to hear that!

bq. Well, complete conversion to JUnit5 Jupiter should not be required before 
the JUnit4 can be removed. Conversion to JUnit5 Vintage Engine should handle 
custom @Rules and whatever other JUnit4 constructs are being used. That's all I 
am talking about. Once that is done, the dependency on the unmaintained JUnit4 
is removed. Conversion from Vintage to Jupiter can take as long as it takes.

JUnit4 is not removed as long as you have the JUnit5 Vintage Engine. JUnit4 is 
then just a transitive dependency and not explicitly in your pom. As long as 
you are using @Rules, which are a JUnit4 API, you cannot remove the JUnit4 
dependency. There is also {{{}junit-jupiter-migrationsupport{}}}, which can 
emulate some JUnit4 rules. But again, that one does not remove the dependency 
on the @Rule API provided by the JUnit4 dependency.

So I think we're finding common ground :) I'm conceding that migrating is 
desirable, and you seem to be conceding that it's a best-effort exercise and 
some parts of such a migration can be non-trivial.

> Update sling-parent pom.xml to include JUnit5 dependencies
> --
>
> Key: SLING-12131
> URL: https://issues.apache.org/jira/browse/SLING-12131
> Project: Sling
>  Issue Type: Task
>Reporter: Rob McDougall
>Priority: Major
>
> JUnit4 is in maintenance mode (no updates in the last 2 years and then only 
> security fixes).  I think updating projects to JUnit5 should be encouraged.
> I am thinking this should be a relatively easy change of adding the 
> junit-jupiter and junit-vintage-engine into the Dependency Management section 
> of the sling-parent.
> Once this is done, individual projects could switch to the vintage-engine (at 
> the very least) or move to jupiter by switching the dependency in their 
> project pom.
> Some day down the road, the JUnit 4 dependencies could be removed.  Projects 
> that have not updated to JUnit5 (vintage or jupiter) by that time are likely 
> no longer maintained.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies

[Julian Sedding (Jira)]

[ 
https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784213#comment-17784213
 ] 

Julian Sedding edited comment on SLING-12131 at 11/8/23 9:49 PM:
-

bq. Given that, unless anyone objects, I am going to create a PR for this.

Go ahead! I think we have a clear consencus on that one.

bq. I've used this before and it works well, [...]

Glad to hear that!

bq. Well, complete conversion to JUnit5 Jupiter should not be required before 
the JUnit4 can be removed. Conversion to JUnit5 Vintage Engine should handle 
custom @Rules and whatever other JUnit4 constructs are being used. That's all I 
am talking about. Once that is done, the dependency on the unmaintained JUnit4 
is removed. Conversion from Vintage to Jupiter can take as long as it takes.

JUnit4 is not removed as long as you have the JUnit5 Vintage Engine. JUnit4 is 
then just a transitive dependency and not explicitly in your pom. As long as 
you are using @Rules, which are a JUnit4 API, you cannot remove the JUnit4 
dependency. There is also {{{}junit-jupiter-migrationsupport{}}}, which can 
emulate some JUnit4 rules. But again, that one does not remove the dependency 
on the @Rule API provided by the JUnit4 dependency.

So I think we're finding common ground :) I'm conceding that migrating is 
desirable, and you seem to be conceding that it's a best-effort exercise and 
some parts of such a migration can be non-trivial.


was (Author: jsedding):
bq. I've used this before and it works well, [...]

Glad to hear that!

bq. Well, complete conversion to JUnit5 Jupiter should not be required before 
the JUnit4 can be removed. Conversion to JUnit5 Vintage Engine should handle 
custom @Rules and whatever other JUnit4 constructs are being used. That's all I 
am talking about. Once that is done, the dependency on the unmaintained JUnit4 
is removed. Conversion from Vintage to Jupiter can take as long as it takes.

JUnit4 is not removed as long as you have the JUnit5 Vintage Engine. JUnit4 is 
then just a transitive dependency and not explicitly in your pom. As long as 
you are using @Rules, which are a JUnit4 API, you cannot remove the JUnit4 
dependency. There is also {{junit-jupiter-migrationsupport}}, which can emulate 
some JUnit4 rules. But again, that one does not remove the dependency on the 
@Rule API provided by the JUnit4 dependency.

So I think we're finding common ground :) I'm conceding that migrating is 
desirable, and you seem to be conceding that it's a best-effort exercise and 
some parts of such a migration can be non-trivial.

> Update sling-parent pom.xml to include JUnit5 dependencies
> --
>
> Key: SLING-12131
> URL: https://issues.apache.org/jira/browse/SLING-12131
> Project: Sling
>  Issue Type: Task
>Reporter: Rob McDougall
>Priority: Major
>
> JUnit4 is in maintenance mode (no updates in the last 2 years and then only 
> security fixes).  I think updating projects to JUnit5 should be encouraged.
> I am thinking this should be a relatively easy change of adding the 
> junit-jupiter and junit-vintage-engine into the Dependency Management section 
> of the sling-parent.
> Once this is done, individual projects could switch to the vintage-engine (at 
> the very least) or move to jupiter by switching the dependency in their 
> project pom.
> Some day down the road, the JUnit 4 dependencies could be removed.  Projects 
> that have not updated to JUnit5 (vintage or jupiter) by that time are likely 
> no longer maintained.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies

[Julian Sedding (Jira)]

[ 
https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784213#comment-17784213
 ] 

Julian Sedding commented on SLING-12131:


bq. I've used this before and it works well, [...]

Glad to hear that!

bq. Well, complete conversion to JUnit5 Jupiter should not be required before 
the JUnit4 can be removed. Conversion to JUnit5 Vintage Engine should handle 
custom @Rules and whatever other JUnit4 constructs are being used. That's all I 
am talking about. Once that is done, the dependency on the unmaintained JUnit4 
is removed. Conversion from Vintage to Jupiter can take as long as it takes.

JUnit4 is not removed as long as you have the JUnit5 Vintage Engine. JUnit4 is 
then just a transitive dependency and not explicitly in your pom. As long as 
you are using @Rules, which are a JUnit4 API, you cannot remove the JUnit4 
dependency. There is also {{junit-jupiter-migrationsupport}}, which can emulate 
some JUnit4 rules. But again, that one does not remove the dependency on the 
@Rule API provided by the JUnit4 dependency.

So I think we're finding common ground :) I'm conceding that migrating is 
desirable, and you seem to be conceding that it's a best-effort exercise and 
some parts of such a migration can be non-trivial.

> Update sling-parent pom.xml to include JUnit5 dependencies
> --
>
> Key: SLING-12131
> URL: https://issues.apache.org/jira/browse/SLING-12131
> Project: Sling
>  Issue Type: Task
>Reporter: Rob McDougall
>Priority: Major
>
> JUnit4 is in maintenance mode (no updates in the last 2 years and then only 
> security fixes).  I think updating projects to JUnit5 should be encouraged.
> I am thinking this should be a relatively easy change of adding the 
> junit-jupiter and junit-vintage-engine into the Dependency Management section 
> of the sling-parent.
> Once this is done, individual projects could switch to the vintage-engine (at 
> the very least) or move to jupiter by switching the dependency in their 
> project pom.
> Some day down the road, the JUnit 4 dependencies could be removed.  Projects 
> that have not updated to JUnit5 (vintage or jupiter) by that time are likely 
> no longer maintained.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (SLING-12126) Update o.a.s.repoinit.parser to 1.9.0 in feature model analyzer

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed SLING-12126.
--

> Update o.a.s.repoinit.parser to 1.9.0 in feature model analyzer
> ---
>
> Key: SLING-12126
> URL: https://issues.apache.org/jira/browse/SLING-12126
> Project: Sling
>  Issue Type: Task
>  Components: Feature Model Analyser
>Affects Versions: Feature Model Analyser 2.0.0
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Minor
> Fix For: Feature Model Analyser 2.0.2
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (SLING-11935) JarDecompressorTest.testWithEmbeddedJar fails on Jenkins/Windows

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-11935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed SLING-11935.
--

> JarDecompressorTest.testWithEmbeddedJar fails on Jenkins/Windows
> 
>
> Key: SLING-11935
> URL: https://issues.apache.org/jira/browse/SLING-11935
> Project: Sling
>  Issue Type: Bug
>  Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Robert Munteanu
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: OSGi Feature Maven Plugin 1.7.4
>
>
> This is the only CI failure, but I don't understand enough about the 
> JarDecompressor to make an informed fix. I will ignore the test on Windows 
> for now, but it would be great to understand the root cause and fix it.
> {noformat}[ERROR] 
> org.apache.sling.feature.maven.mojos.JarDecompressorTest.testJarWithEmbeddedJar
>   Time elapsed: 0.071 s  <<< FAILURE!
> java.lang.AssertionError: expected:<2108> but was:<1984>
>   at org.junit.Assert.fail(Assert.java:89)
>   at org.junit.Assert.failNotEquals(Assert.java:835)
>   at org.junit.Assert.assertEquals(Assert.java:647)
>   at org.junit.Assert.assertEquals(Assert.java:633)
>   at 
> org.apache.sling.feature.maven.mojos.JarDecompressorTest.testJarWithEmbeddedJar(JarDecompressorTest.java:81)
>   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:59)
>   at 
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
>   at 
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
>   at 
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
>   at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
>   at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
>   at 
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
>   at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
>   at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
>   at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
>   at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
>   at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
>   at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
>   at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:364)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:237)
>   at 
> org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:158)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:428)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:162)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.run(ForkedBooter.java:562)
>   at 
> org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:548){noformat}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (SLING-11947) Convert Plexus to JSR330 components

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-11947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed SLING-11947.
--

> Convert Plexus to JSR330 components
> ---
>
> Key: SLING-11947
> URL: https://issues.apache.org/jira/browse/SLING-11947
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Affects Versions: OSGi Feature Maven Plugin 1.7.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: OSGi Feature Maven Plugin 1.7.4
>
>
> As Plexus component descriptors are deprecated 
> (https://codehaus-plexus.github.io/plexus-containers/#deprecated) one should 
> migrate instead to the standard JSR330 annotations which are evaluated at run 
> time (https://github.com/eclipse/sisu.plexus/wiki/Plexus-to-JSR330)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (SLING-11948) Get rid of legacy maven-compat dependency

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-11948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed SLING-11948.
--

> Get rid of legacy maven-compat dependency
> -
>
> Key: SLING-11948
> URL: https://issues.apache.org/jira/browse/SLING-11948
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Affects Versions: OSGi Feature Maven Plugin 1.7.2
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: OSGi Feature Maven Plugin 1.7.4
>
>
> This involves leveraging Maven Resolver API directly. Using legacy 
> maven-compat leads to a WARN with Maven 3.9.x.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (SLING-11987) Allow report into a single file

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-11987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed SLING-11987.
--

> Allow report into a single file
> ---
>
> Key: SLING-11987
> URL: https://issues.apache.org/jira/browse/SLING-11987
> Project: Sling
>  Issue Type: New Feature
>  Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: OSGi Feature Maven Plugin 1.7.4
>
>
> The feature report can either be outputted into the normal log output or into 
> separate report files per feature.
> Sometimes it is useful to get a single report across all features



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (SLING-9883) ApisJarMojo: Provide-Capability should be collected from all contained bundles and exposed

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-9883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed SLING-9883.
-

> ApisJarMojo: Provide-Capability should be collected from all contained 
> bundles and exposed
> --
>
> Key: SLING-9883
> URL: https://issues.apache.org/jira/browse/SLING-9883
> Project: Sling
>  Issue Type: Improvement
>  Components: Feature Model
>Affects Versions: slingfeature-maven-plugin 1.4.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
> Fix For: OSGi Feature Maven Plugin 1.7.4
>
>
> In order to leverage 
> https://github.com/bndtools/bnd/tree/master/maven/bnd-resolver-maven-plugin 
> at build time it would be nice if the API jar would include the 
> {{Provide-Capability}} headers from all contained bundles (similar to 
> {{Export-Package}} and {{Sling-Nodetypes}}).
> See also 
> https://lists.apache.org/thread.html/r7bb5c4493fa241ac5cd8d8ea313ff970866e2f2efc6254ee6a0fd41a%40%3Cdev.sling.apache.org%3E



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (SLING-12009) Report errors and warnings at the end of the scan

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed SLING-12009.
--

> Report errors and warnings at the end of the scan
> -
>
> Key: SLING-12009
> URL: https://issues.apache.org/jira/browse/SLING-12009
> Project: Sling
>  Issue Type: Improvement
>  Components: Maven Plugins and Archetypes
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: OSGi Feature Maven Plugin 1.7.4
>
>
> Especially when a lot of features get analysed, the errors and warnings are 
> "hidden" in between all the analysis runs. This makes it sometimes hard to 
> find them.
> The report could be deferred to the end of the scan 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (SLING-11985) Add report about imported packages

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-11985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed SLING-11985.
--

> Add report about imported packages
> --
>
> Key: SLING-11985
> URL: https://issues.apache.org/jira/browse/SLING-11985
> Project: Sling
>  Issue Type: New Feature
>  Components: Feature Model, Maven Plugins and Archetypes
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: OSGi Feature Maven Plugin 1.7.4
>
>
> We only have a report for exported packages; sometimes it is also useful to 
> get info about all imported packages



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Closed] (SLING-12127) Update o.a.s.repoinit.parser to 1.9.0 in slingfeature-maven-plugin

[Julian Sedding (Jira)]

 [ 
https://issues.apache.org/jira/browse/SLING-12127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Julian Sedding closed SLING-12127.
--

> Update o.a.s.repoinit.parser to 1.9.0 in slingfeature-maven-plugin
> --
>
> Key: SLING-12127
> URL: https://issues.apache.org/jira/browse/SLING-12127
> Project: Sling
>  Issue Type: Task
>  Components: Feature Model, Maven Plugins and Archetypes
>Affects Versions: OSGi Feature Maven Plugin 1.7.2
>    Reporter: Julian Sedding
>    Assignee: Julian Sedding
>Priority: Minor
> Fix For: OSGi Feature Maven Plugin 1.7.4
>
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (SLING-12131) Update sling-parent pom.xml to include JUnit5 dependencies

[Julian Sedding (Jira)]

[ 
https://issues.apache.org/jira/browse/SLING-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784146#comment-17784146
 ] 

Julian Sedding commented on SLING-12131:


If migration is the goal, then it may make sense to facilitate semi-automated 
migration. A quick google turned up that the OpenRewrite projct has several 
[rules for migrating various 
scenarios|https://docs.openrewrite.org/recipes/java/testing/junit5]. There is a 
maven plugin, so we could add a configuration to the parent pom. IIUC it is 
[invoked using {{mvn 
rewrite:run}}|https://docs.openrewrite.org/running-recipes/getting-started#step-4-run-a-simple-refactoring-recipe].
 We could also put the plugin into a profile, if we want to guard against any 
surprises.

I agree that it would be desirable to migrate all actively maintained modules 
to junit5. That said, I don't believe it is realistic in the foreseeable 
future, most certainly not without automation. There are custom {{@Rule}} 
implementations that are non-trivial to migrate. There are runners, that may 
not be trivial to migrate, either. The difference between assertions and some 
ootb {{@Rule}}s can likely be covered with automation. Remains to be seen how 
well the automation works.

> Update sling-parent pom.xml to include JUnit5 dependencies
> --
>
> Key: SLING-12131
> URL: https://issues.apache.org/jira/browse/SLING-12131
> Project: Sling
>  Issue Type: Task
>Reporter: Rob McDougall
>Priority: Major
>
> JUnit4 is in maintenance mode (no updates in the last 2 years and then only 
> security fixes).  I think updating projects to JUnit5 should be encouraged.
> I am thinking this should be a relatively easy change of adding the 
> junit-jupiter and junit-vintage-engine into the Dependency Management section 
> of the sling-parent.
> Once this is done, individual projects could switch to the vintage-engine (at 
> the very least) or move to jupiter by switching the dependency in their 
> project pom.
> Some day down the road, the JUnit 4 dependencies could be removed.  Projects 
> that have not updated to JUnit5 (vintage or jupiter) by that time are likely 
> no longer maintained.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [VOTE] Release Apache Sling App CMS version 1.1.8

[Julian Sedding]

+1 - all checks ok

Regards

Julian

On Wed, Nov 8, 2023 at 3:40 PM Daniel Klco  wrote:
>
> My +1
>
> On Wed, Nov 8, 2023 at 8:20 AM Robert Munteanu  wrote:
>
> > On Sun, 2023-11-05 at 23:22 -0500, Daniel Klco wrote:
> > > Please vote to approve this release:
> >
> > +1
> > Robert
> >

Re: [VOTE] Release Apache Sling Content Distribution Journal Messages 0.5.6

[Julian Sedding]

+1 - all checks ok

Regards
Julian

On Wed, Nov 8, 2023 at 2:01 PM Robert Munteanu  wrote:
>
> On Tue, 2023-11-07 at 10:24 +0100, Timothee Maret wrote:
> > Please vote to approve this release:
>
> +1
> Robert

[RESULT] [VOTE] Release Apache Sling OSGi Feature Maven Plugin 1.7.4, Apache Sling Feature Model Analyser 2.0.2

[Julian Sedding]

Hi,

The vote has passed with the following result:

+1 (binding): Carsten Ziegeler, Joerg Hoh, Julian Sedding
+1 (non-binding): none

I will copy this release to the Sling dist directory and
promote the artifacts to the central Maven repository.

Regards
Julian


On Wed, Nov 8, 2023 at 3:11 PM Julian Sedding  wrote:
>
> +1
>
> Regards
> Julian
>
> On Sun, Nov 5, 2023 at 12:39 PM Jörg Hoh  
> wrote:
> >
> > +1
> >
> > Am Sa., 4. Nov. 2023 um 16:07 Uhr schrieb Julian Sedding  > >:
> >
> > > Hi,
> > >
> > > We solved 9 issues in these releases:
> > >
> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710&version=12352907&styleName=Text
> > >
> > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310710&version=12353405&styleName=Text
> > >
> > > Staging repository:
> > > https://repository.apache.org/content/repositories/orgapachesling-2800/
> > >
> > > 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 2800 /tmp/sling-staging
> > >
> > > Please vote to approve this release:
> > >
> > >   [ ] +1 Approve the release
> > >   [ ]  0 Don't care
> > >   [ ] -1 Don't release, because ...
> > >
> > > This majority vote is open for at least 72 hours.
> > >
> > > Regards
> > > Julian
> > >
> >
> >
> > --
> > Cheers,
> > Jörg Hoh,
> >
> > https://cqdump.joerghoh.de
> > Twitter: @joerghoh