Re: RepoInit: Intended behaviour in case of failures and backwards-compatibility

[Eric Norman]

>
> How about we go there when such a use case comes up in reality?
>
> Regards
> Carsten
>

I apologise for trying to be proactive.  It seems my opinions don't matter
here as the Adobe voices have overwhelmed the discussion.

Have a good day.
-Eric

On Mon, Dec 19, 2022 at 4:16 AM Carsten Ziegeler 
wrote:

> How about we go there when such a use case comes up in reality?
>
> Regards
> Carsten
>
>
> Am 19.12.2022 um 13:09 schrieb Konrad Windszus:
> > Please read the full mailing list thread.
> > This were the use cases brought up by Eric
> >
> > "I can envision a highly modular distribution in which two
> > modules (from different owners) may accidentally have paths that collide.
> > So I can see how a repoinit that would fail fast in that scenario could
> be
> > useful.  In other words, if someone else already created a path (with the
> > wrong types) that you are not expecting to be there, then failing right
> > away seems like a reasonable solution.”
> >
> > Konrad
> >
> >
> >
> >> On 19. Dec 2022, at 12:50, Bertrand Delacretaz 
> wrote:
> >>
> >> Hi,
> >>
> >> I agree with deprecating "create path" and implementing new
> instructions.
> >>
> >> But I'm not sure why you would need two new instructions:
> >>
> >> Konrad Windszus  wrote:
> >> ...
> >>> a) ensure node (for creating or updating node(s) with primary and
> mixin type)
> >>> b) update node (for just updating existing node(s) with primary and
> mixin type).
> >> ...
> >>
> >> In both cases, you want the specified nodes to be exactly as described
> >> in the statement, so why two instructions?
> >>
> >> What would "update node" do if not all nodes exist yet, fail? Do
> >> nothing? Both are not good IMO.
> >>
> >> Whoever writes the repoinit script specifies an end state, I don't
> >> think they care about the previous state, so I think just "create
> >> node" is sufficient and simpler to implement.
> >>
> >> But it's actually not a single node that's being created or updated,
> >> it's the whole subtree, when you write something like
> >>
> >> create node (nt:folder) /one(mixin nt:art)/step(mixin
> nt:dance)/two/steps
> >>
> >> You're actually touching up to 4 nodes...I think "create nodes" or
> >> "set nodes" is a better name for this new instruction.
> >>
> >> -Bertrand
> >
> >
>
> --
> Carsten Ziegeler
> Adobe
> cziege...@apache.org
>

[jira] [Commented] (SLING-11718) Migrate to Jakarta JSON API

[Robert Munteanu (Jira)]

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

Robert Munteanu commented on SLING-11718:
-

Thanks [~cziegeler]!

> Migrate to Jakarta JSON API
> ---
>
> Key: SLING-11718
> URL: https://issues.apache.org/jira/browse/SLING-11718
> Project: Sling
>  Issue Type: New Feature
>  Components: Feature Model, Feature Model Analyser, Maven Plugins and 
> Archetypes
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Feature Model Analyser 2.0.0, slingfeature-maven-plugin 
> 1.6.10, Feature Diff 0.1.0, JCR ContentLoader 2.5.4, Content-Package to 
> Feature Model Converter 1.1.26, Feature Model 2.0.0, Feature Model API 
> Regions Extension 2.0.0, Feature Model Launcher 1.2.4
>
>
> Starting with JEE 9 the package names for the enterprise APIs changed from 
> javax.* to jakarta.* which means that we will benefit from updates to those 
> APIs only if we make the move.
> For the feature model and the related tooling, it should be fairly easy to do 
> this move as this code is usually only used at tool time but not at 
> application runtime.
> We can simply replace javax.json with jakarta.json and do new releases of 
> everything involved with a new major version. As we are currently using 
> javax.json in parts of the API, this will be a breaking change, therefore the 
> major version update.



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

[jira] [Created] (SLING-11740) DefaultErrorHandler should not catch Error

[Carsten Ziegeler (Jira)]

Carsten Ziegeler created SLING-11740:


 Summary: DefaultErrorHandler should not catch Error
 Key: SLING-11740
 URL: https://issues.apache.org/jira/browse/SLING-11740
 Project: Sling
  Issue Type: Improvement
  Components: Engine
Affects Versions: Engine 2.13.0
Reporter: Carsten Ziegeler
 Fix For: Engine 2.13.4


The DefaultErrorHandler is catching Error when it forwards to a delegate error 
handler. As Error should not be caught by applications in general, we should 
probably rather remove those two catch statements



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

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

[Daniel Klco]

Thanks Stefan, I'll correct these. It shouldn't affect the built
application, however.

My +1

On Sat, Dec 17, 2022 at 9:50 AM Stefan Seifert
 wrote:

> +1
>
> please note: the repository contains paths that are invalid on windows:
>
> error: invalid path
> 'reference/src/main/resources/jcr_root/oak:index/slingPage/indexRules/sling:Page/properties/hideInSitemap.json'
> fatal: unable to checkout working tree
>
> stefan
>
>
> > -Original Message-
> > From: Daniel Klco 
> > Sent: Friday, December 16, 2022 5:05 AM
> > To: dev@sling.apache.org
> > Subject: [VOTE] Release Apache Sling App CMS version 1.1.4
> >
> > Hi,
> >
> > We solved 2 issues in this release:
> > https://issues.apache.org/jira/projects/SLING/versions/12352558
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachesling-2707/
> >
> > 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 2707 /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.
>

[GitHub] [sling-org-apache-sling-feature-cpconverter] niekraaijmakers commented on pull request #152: SLING-11739 Index definition extraction from content packages is miss…

[GitBox]

niekraaijmakers commented on PR #152:
URL: 
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/152#issuecomment-1357776732

   @niekraaijmakers can't say much about the first patch of code but the second 
one (retrieving /.content.xml ) is surely better. 


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (SLING-11718) Migrate to Jakarta JSON API

[Carsten Ziegeler (Jira)]

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

Carsten Ziegeler commented on SLING-11718:
--

Thanks [~rombert] - this seems to be a "transitive" bug due to  SLING-11725 . 
cpconverter build fine before it. Regardless, I've updated the cpconverter, 
build works fine again.

> Migrate to Jakarta JSON API
> ---
>
> Key: SLING-11718
> URL: https://issues.apache.org/jira/browse/SLING-11718
> Project: Sling
>  Issue Type: New Feature
>  Components: Feature Model, Feature Model Analyser, Maven Plugins and 
> Archetypes
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Feature Model Analyser 2.0.0, slingfeature-maven-plugin 
> 1.6.10, Feature Diff 0.1.0, JCR ContentLoader 2.5.4, Content-Package to 
> Feature Model Converter 1.1.26, Feature Model 2.0.0, Feature Model API 
> Regions Extension 2.0.0, Feature Model Launcher 1.2.4
>
>
> Starting with JEE 9 the package names for the enterprise APIs changed from 
> javax.* to jakarta.* which means that we will benefit from updates to those 
> APIs only if we make the move.
> For the feature model and the related tooling, it should be fairly easy to do 
> this move as this code is usually only used at tool time but not at 
> application runtime.
> We can simply replace javax.json with jakarta.json and do new releases of 
> everything involved with a new major version. As we are currently using 
> javax.json in parts of the API, this will be a breaking change, therefore the 
> major version update.



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

[GitHub] [sling-org-apache-sling-feature-cpconverter] rombert commented on pull request #152: SLING-11739 Index definition extraction from content packages is miss…

[GitBox]

rombert commented on PR #152:
URL: 
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/152#issuecomment-1357708421

   @abhishekgarg18  - the build failure is unrelated, seems the previous commit 
has introduced a regression.
   
   While we clear that our, @DominikSuess / @niekraaijmakers - what are your 
thoughts on this PR?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Commented] (SLING-11718) Migrate to Jakarta JSON API

[Robert Munteanu (Jira)]

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

Robert Munteanu commented on SLING-11718:
-

[~cziegeler] - the cpconverter build started failing after your changes  
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/commit/0723195531a3c5fa09ddc4ca3526ac8f8e12c00f,
 can you please look into it?

{noformat}[WARNING] Dependency 
org.apache.sling:org.apache.sling.jcr.contentparser:jar:1.2.6 (provided) via 
org.apache.sling:org.apache.sling.jcr.contentloader:jar:2.5.3-SNAPSHOT not 
found as runtime dependency!
[ERROR] Rule 0: 
org.apache.sling.maven.enforcer.RequireProvidedDependenciesInRuntimeClasspath 
failed with message:
Found 1 missing runtime dependency. Look at the warnings emitted above for the 
details.
{noformat}

> Migrate to Jakarta JSON API
> ---
>
> Key: SLING-11718
> URL: https://issues.apache.org/jira/browse/SLING-11718
> Project: Sling
>  Issue Type: New Feature
>  Components: Feature Model, Feature Model Analyser, Maven Plugins and 
> Archetypes
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Feature Model Analyser 2.0.0, slingfeature-maven-plugin 
> 1.6.10, Feature Diff 0.1.0, JCR ContentLoader 2.5.4, Content-Package to 
> Feature Model Converter 1.1.26, Feature Model 2.0.0, Feature Model API 
> Regions Extension 2.0.0, Feature Model Launcher 1.2.4
>
>
> Starting with JEE 9 the package names for the enterprise APIs changed from 
> javax.* to jakarta.* which means that we will benefit from updates to those 
> APIs only if we make the move.
> For the feature model and the related tooling, it should be fairly easy to do 
> this move as this code is usually only used at tool time but not at 
> application runtime.
> We can simply replace javax.json with jakarta.json and do new releases of 
> everything involved with a new major version. As we are currently using 
> javax.json in parts of the API, this will be a breaking change, therefore the 
> major version update.



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

Re: RepoInit: Intended behaviour in case of failures and backwards-compatibility

[Konrad Windszus]

> On 19. Dec 2022, at 14:45, Bertrand Delacretaz  wrote:
> 
> So my preference goes to "set nodes ...", but if the majority prefers
> "ensure nodes" that also works.

Sounds better to me as well.
Konrad

Re: RepoInit: Intended behaviour in case of failures and backwards-compatibility

[Bertrand Delacretaz]

Hi,

Konrad Windszus  wrote:

> ...So I will for now only update 
> https://github.com/apache/sling-org-apache-sling-repoinit-parser/pull/27 
>  
> with
>
> Instruction "ensure node" (for creating or updating node(s) with primary and 
> mixin type)

works for me but I think it should be "nodes" and not "node" as a
typical instruction will touch multiple nodes.

Also, I would prefer "set" over "ensure" as we already have "set
properties" with a similar behavior in the language.

So my preference goes to "set nodes ...", but if the majority prefers
"ensure nodes" that also works.

-Bertrand

Re: RepoInit: Intended behaviour in case of failures and backwards-compatibility

[Konrad Windszus]

I think it is fine to leave out "update node" for now (but you have to keep it 
in mind for naming the other new instruction to allow for such semantics later 
on).
So I will for now only update 
https://github.com/apache/sling-org-apache-sling-repoinit-parser/pull/27 
 with 

Instruction "ensure node" (for creating or updating node(s) with primary and 
mixin type).
WDYT?
Konrad

> On 19. Dec 2022, at 13:16, Carsten Ziegeler  wrote:
> 
> How about we go there when such a use case comes up in reality?
> 
> Regards
> Carsten
> 
> 
> Am 19.12.2022 um 13:09 schrieb Konrad Windszus:
>> Please read the full mailing list thread.
>> This were the use cases brought up by Eric
>> "I can envision a highly modular distribution in which two
>> modules (from different owners) may accidentally have paths that collide.
>> So I can see how a repoinit that would fail fast in that scenario could be
>> useful.  In other words, if someone else already created a path (with the
>> wrong types) that you are not expecting to be there, then failing right
>> away seems like a reasonable solution.”
>> Konrad
>>> On 19. Dec 2022, at 12:50, Bertrand Delacretaz  
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> I agree with deprecating "create path" and implementing new instructions.
>>> 
>>> But I'm not sure why you would need two new instructions:
>>> 
>>> Konrad Windszus  wrote:
>>> ...
 a) ensure node (for creating or updating node(s) with primary and mixin 
 type)
 b) update node (for just updating existing node(s) with primary and mixin 
 type).
>>> ...
>>> 
>>> In both cases, you want the specified nodes to be exactly as described
>>> in the statement, so why two instructions?
>>> 
>>> What would "update node" do if not all nodes exist yet, fail? Do
>>> nothing? Both are not good IMO.
>>> 
>>> Whoever writes the repoinit script specifies an end state, I don't
>>> think they care about the previous state, so I think just "create
>>> node" is sufficient and simpler to implement.
>>> 
>>> But it's actually not a single node that's being created or updated,
>>> it's the whole subtree, when you write something like
>>> 
>>>create node (nt:folder) /one(mixin nt:art)/step(mixin nt:dance)/two/steps
>>> 
>>> You're actually touching up to 4 nodes...I think "create nodes" or
>>> "set nodes" is a better name for this new instruction.
>>> 
>>> -Bertrand
> 
> -- 
> Carsten Ziegeler
> Adobe
> cziege...@apache.org

Re: RepoInit: Intended behaviour in case of failures and backwards-compatibility

[Carsten Ziegeler]

How about we go there when such a use case comes up in reality?

Regards
Carsten


Am 19.12.2022 um 13:09 schrieb Konrad Windszus:

Please read the full mailing list thread.
This were the use cases brought up by Eric

"I can envision a highly modular distribution in which two
modules (from different owners) may accidentally have paths that collide.
So I can see how a repoinit that would fail fast in that scenario could be
useful.  In other words, if someone else already created a path (with the
wrong types) that you are not expecting to be there, then failing right
away seems like a reasonable solution.”

Konrad




On 19. Dec 2022, at 12:50, Bertrand Delacretaz  wrote:

Hi,

I agree with deprecating "create path" and implementing new instructions.

But I'm not sure why you would need two new instructions:

Konrad Windszus  wrote:
...

a) ensure node (for creating or updating node(s) with primary and mixin type)
b) update node (for just updating existing node(s) with primary and mixin type).

...

In both cases, you want the specified nodes to be exactly as described
in the statement, so why two instructions?

What would "update node" do if not all nodes exist yet, fail? Do
nothing? Both are not good IMO.

Whoever writes the repoinit script specifies an end state, I don't
think they care about the previous state, so I think just "create
node" is sufficient and simpler to implement.

But it's actually not a single node that's being created or updated,
it's the whole subtree, when you write something like

create node (nt:folder) /one(mixin nt:art)/step(mixin nt:dance)/two/steps

You're actually touching up to 4 nodes...I think "create nodes" or
"set nodes" is a better name for this new instruction.

-Bertrand





--
Carsten Ziegeler
Adobe
cziege...@apache.org

Re: RepoInit: Intended behaviour in case of failures and backwards-compatibility

[Konrad Windszus]

Please read the full mailing list thread.
This were the use cases brought up by Eric

"I can envision a highly modular distribution in which two
modules (from different owners) may accidentally have paths that collide.
So I can see how a repoinit that would fail fast in that scenario could be
useful.  In other words, if someone else already created a path (with the
wrong types) that you are not expecting to be there, then failing right
away seems like a reasonable solution.”

Konrad



> On 19. Dec 2022, at 12:50, Bertrand Delacretaz  wrote:
> 
> Hi,
> 
> I agree with deprecating "create path" and implementing new instructions.
> 
> But I'm not sure why you would need two new instructions:
> 
> Konrad Windszus  wrote:
> ...
>> a) ensure node (for creating or updating node(s) with primary and mixin type)
>> b) update node (for just updating existing node(s) with primary and mixin 
>> type).
> ...
> 
> In both cases, you want the specified nodes to be exactly as described
> in the statement, so why two instructions?
> 
> What would "update node" do if not all nodes exist yet, fail? Do
> nothing? Both are not good IMO.
> 
> Whoever writes the repoinit script specifies an end state, I don't
> think they care about the previous state, so I think just "create
> node" is sufficient and simpler to implement.
> 
> But it's actually not a single node that's being created or updated,
> it's the whole subtree, when you write something like
> 
>create node (nt:folder) /one(mixin nt:art)/step(mixin nt:dance)/two/steps
> 
> You're actually touching up to 4 nodes...I think "create nodes" or
> "set nodes" is a better name for this new instruction.
> 
> -Bertrand

Re: RepoInit: Intended behaviour in case of failures and backwards-compatibility

[Bertrand Delacretaz]

Hi,

I agree with deprecating "create path" and implementing new instructions.

But I'm not sure why you would need two new instructions:

Konrad Windszus  wrote:
...
> a) ensure node (for creating or updating node(s) with primary and mixin type)
> b) update node (for just updating existing node(s) with primary and mixin 
> type).
...

In both cases, you want the specified nodes to be exactly as described
in the statement, so why two instructions?

What would "update node" do if not all nodes exist yet, fail? Do
nothing? Both are not good IMO.

Whoever writes the repoinit script specifies an end state, I don't
think they care about the previous state, so I think just "create
node" is sufficient and simpler to implement.

But it's actually not a single node that's being created or updated,
it's the whole subtree, when you write something like

create node (nt:folder) /one(mixin nt:art)/step(mixin nt:dance)/two/steps

You're actually touching up to 4 nodes...I think "create nodes" or
"set nodes" is a better name for this new instruction.

-Bertrand

[jira] [Updated] (SLING-11739) Index definition extraction from content packages is missing binary files data

[Abhishek Garg (Jira)]

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

Abhishek Garg updated SLING-11739:
--
Description: 
Currently, binaries are stored in indexDefinitions at [1] and these binaries 
should be written in JSONOutput at [2], However each time we are getting it as 
empty at [2].

The reason is that we are storing binaries against its repositoryPath instead 
it should be its parent path.

i.e we are storing tika config.xml binaries at repositoryPath
`oak:index/damAssetLucene-8-custom-2/tika/config.xml`
and while writing at [2],we are trying to fetch it from 
`oak:index/damAssetLucene-8-custom-2/tika/`
because of this we are getting it as empty as nodeName is till 
`oak:index/damAssetLucene-8-custom-2/tika` only.

[1]:[https://github.com/niekraaijmakers/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/handlers/IndexDefinitionsEntryHandler.java]
[2]:[https://github.com/niekraaijmakers/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/index/IndexDefinitionsJsonWriter.java#L137]

 

  was:
Currently, binaries are stored in indexDefinitions at [1] and these binaries 
should be written in JSONOutput at [2], However each time we are it. as empty 
at [2].

The reason is that we are storing binaries against its repositoryPath instead 
it should be its parent path.

i.e we are tika config.xml binaries at repositoryPath
`oak:index/damAssetLucene-8-custom-2/tika/config.xml`
and while writing at [2],we are trying to fetch it from 
`oak:index/damAssetLucene-8-custom-2/tika/`
which is causing it empty as nodeName is till 
`oak:index/damAssetLucene-8-custom-2/tika` only.


[1]:[https://github.com/niekraaijmakers/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/handlers/IndexDefinitionsEntryHandler.java]
[2]:[https://github.com/niekraaijmakers/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/index/IndexDefinitionsJsonWriter.java#L137]

 


> Index definition extraction from content packages is missing binary files data
> --
>
> Key: SLING-11739
> URL: https://issues.apache.org/jira/browse/SLING-11739
> Project: Sling
>  Issue Type: Bug
>  Components: Content-Package to Feature Model Converter
>Affects Versions: Content-Package to Feature Model Converter 1.1.24
>Reporter: Abhishek Garg
>Priority: Major
>
> Currently, binaries are stored in indexDefinitions at [1] and these binaries 
> should be written in JSONOutput at [2], However each time we are getting it 
> as empty at [2].
> The reason is that we are storing binaries against its repositoryPath instead 
> it should be its parent path.
> i.e we are storing tika config.xml binaries at repositoryPath
> `oak:index/damAssetLucene-8-custom-2/tika/config.xml`
> and while writing at [2],we are trying to fetch it from 
> `oak:index/damAssetLucene-8-custom-2/tika/`
> because of this we are getting it as empty as nodeName is till 
> `oak:index/damAssetLucene-8-custom-2/tika` only.
> [1]:[https://github.com/niekraaijmakers/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/handlers/IndexDefinitionsEntryHandler.java]
> [2]:[https://github.com/niekraaijmakers/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/index/IndexDefinitionsJsonWriter.java#L137]
>  



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

[jira] [Commented] (SLING-11739) Index definition extraction from content packages is missing binary files data

[Abhishek Garg (Jira)]

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

Abhishek Garg commented on SLING-11739:
---

PR to fix that
[https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/152]

cc : [~rombert] [~Sc0rpic0m]

> Index definition extraction from content packages is missing binary files data
> --
>
> Key: SLING-11739
> URL: https://issues.apache.org/jira/browse/SLING-11739
> Project: Sling
>  Issue Type: Bug
>  Components: Content-Package to Feature Model Converter
>Affects Versions: Content-Package to Feature Model Converter 1.1.24
>Reporter: Abhishek Garg
>Priority: Major
>
> Currently, binaries are stored in indexDefinitions at [1] and these binaries 
> should be written in JSONOutput at [2], However each time we are it. as empty 
> at [2].
> The reason is that we are storing binaries against its repositoryPath instead 
> it should be its parent path.
> i.e we are tika config.xml binaries at repositoryPath
> `oak:index/damAssetLucene-8-custom-2/tika/config.xml`
> and while writing at [2],we are trying to fetch it from 
> `oak:index/damAssetLucene-8-custom-2/tika/`
> which is causing it empty as nodeName is till 
> `oak:index/damAssetLucene-8-custom-2/tika` only.
> [1]:[https://github.com/niekraaijmakers/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/handlers/IndexDefinitionsEntryHandler.java]
> [2]:[https://github.com/niekraaijmakers/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/index/IndexDefinitionsJsonWriter.java#L137]
>  



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

[GitHub] [sling-org-apache-sling-feature-cpconverter] abhishekgarg18 opened a new pull request, #152: SLING-11739 Index definition extraction from content packages is miss…

[GitBox]

abhishekgarg18 opened a new pull request, #152:
URL: 
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/152

   …ing binary files data


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@sling.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

[jira] [Created] (SLING-11739) Index definition extraction from content packages is missing binary files data

[Abhishek Garg (Jira)]

Abhishek Garg created SLING-11739:
-

 Summary: Index definition extraction from content packages is 
missing binary files data
 Key: SLING-11739
 URL: https://issues.apache.org/jira/browse/SLING-11739
 Project: Sling
  Issue Type: Bug
  Components: Content-Package to Feature Model Converter
Affects Versions: Content-Package to Feature Model Converter 1.1.24
Reporter: Abhishek Garg


Currently, binaries are stored in indexDefinitions at [1] and these binaries 
should be written in JSONOutput at [2], However each time we are it. as empty 
at [2].

The reason is that we are storing binaries against its repositoryPath instead 
it should be its parent path.

i.e we are tika config.xml binaries at repositoryPath
`oak:index/damAssetLucene-8-custom-2/tika/config.xml`
and while writing at [2],we are trying to fetch it from 
`oak:index/damAssetLucene-8-custom-2/tika/`
which is causing it empty as nodeName is till 
`oak:index/damAssetLucene-8-custom-2/tika` only.


[1]:[https://github.com/niekraaijmakers/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/handlers/IndexDefinitionsEntryHandler.java]
[2]:[https://github.com/niekraaijmakers/sling-org-apache-sling-feature-cpconverter/blob/master/src/main/java/org/apache/sling/feature/cpconverter/index/IndexDefinitionsJsonWriter.java#L137]

 



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

Re: RepoInit: Intended behaviour in case of failures and backwards-compatibility

[Konrad Windszus]

Sounds good to me, so that would leave us with two new statements:

a) ensure node (for creating or updating node(s) with primary and mixin type)
b) update node (for just updating existing node(s) with primary and mixin type).

I will update my PR at 
https://github.com/apache/sling-org-apache-sling-repoinit-parser/pull/27 
 
accordingly.
Konrad

> On 19. Dec 2022, at 11:44, Julian Sedding  wrote:
> 
> How about "ensure node"? It's shorter than "updateOrCreate node",
> which to me seems likely the most common case.
> 
> Regards
> Julian
> 
> PS: my preference is also with deprecating "create path" in favour of
> a new clearly defined instruction.
> 
> On Mon, Dec 19, 2022 at 7:21 AM Konrad Windszus  wrote:
>> 
>> Thanks for the use cases. But then „create node“ according to your proposal 
>> would only work exactly once. A restart of the runtime or just the sling jcr 
>> bundle would automatically fail because then the node would already be there 
>> when the statement is executed again….
>> So IMHO only update and updateOrCreate are useful.
>> WDYT,
>> Konrad
>> 
>> 
>>> Am 16.12.2022 um 20:42 schrieb Eric Norman :
>>> 
>>> Also, another use case I was thinking of for the "update node" scenario is
>>> if you want to add a mixin to a node that was expected to be already
>>> created elsewhere,  if the node doesn't exist yet then your mixin won't get
>>> assigned and you could have indeterminate behavior later.  So failing fast
>>> would quickly tell you something is wrong.
>>> 
>>> Regards,
>>> -Eric
>>> 
 On Fri, Dec 16, 2022 at 11:19 AM Eric Norman  wrote:
 
 TBH I don’t yet see use cases for failing when the node does already
> exist  (create node in your proposal) nor for failing when the node does
> not exist (update node)
> 
 
 Yes, that is kind of the point.  You can't possibly conceive every
 possible use case, so just make the language generic enough to satisfy a
 broad set of use cases.  I can envision a highly modular distribution in
 which two modules (from different owners) may accidentally have paths that
 collide.  So I can see how a repoinit that would fail fast in that scenario
 could be useful.  In other words, if someone else already created a path
 (with the wrong types) that you are not expecting to be there, then failing
 right away seems like a reasonable solution.
 
 (We also don’t have anything like that for set properties AFAIK)
> 
 
 I think the "[set|default] propertyName ..." syntax is conceptually
 similar.  In that, the "default" operator would only modify the value if it
 does not already have a non-default value.
 
 Regards,
 -Eric
 
> On Fri, Dec 16, 2022 at 11:04 AM Konrad Windszus  wrote:
> 
> TBH I don’t yet see use cases for failing when the node does already
> exist  (create node in your proposal) nor for failing when the node does
> not exist (update node)
> Can you share some examples you have in mind which would benefit from
> that functionality?
> (We also don’t have anything like that for set properties AFAIK)
> 
> Thanks,
> Konrad
> 
> 
>> On 16. Dec 2022, at 19:59, Eric Norman  wrote:
>> 
>> For me the proposed "strict" modifier doesn't seem obvious what it is
> going
>> to do.
>> 
>> I would prefer a more verbose language with several options and let me
>> choose which one to use.  In other words, deprecate the original
>> (ambiguous) "create path" syntax and replace it with a new
>> "[create|update|createOrUpdate] node" syntax that is more clear what is
>> expected to happen.
>> 
>> For example:
>> 
>> # the original syntax (leave as is for backward compatibility).
>> #   This would be similar to the "createOrUpdate" use case without any
>> #   attempts to change the primaryNodeType and mixinTypes of already
>> existing nodes
>> create path (nt:folder) /one(mixin nt:art)/step(mixin
> nt:dance)/two/steps
>> 
>> #
>> 
> 
>> # - New replacement
>> syntax ---
>> #
>> 
> 
>> 
>> # new syntax that will fail if any of the paths already exist
>> create node (nt:folder) /one(mixin nt:art)/step(mixin
> nt:dance)/two/steps
>> 
>> # new syntax that will fail if any of the affected paths do not already
>> exist
>> #   and would attempt to change the primaryNodeType and mixinTypes where
>> specified
>> update node (nt:folder) /one(mixin nt:art)/step(mixin
> nt:dance)/two/steps
>> 
>> # new syntax that will create nodes that do not yet exist and update

Re: RepoInit: Intended behaviour in case of failures and backwards-compatibility

[Julian Sedding]

How about "ensure node"? It's shorter than "updateOrCreate node",
which to me seems likely the most common case.

Regards
Julian

PS: my preference is also with deprecating "create path" in favour of
a new clearly defined instruction.

On Mon, Dec 19, 2022 at 7:21 AM Konrad Windszus  wrote:
>
> Thanks for the use cases. But then „create node“ according to your proposal 
> would only work exactly once. A restart of the runtime or just the sling jcr 
> bundle would automatically fail because then the node would already be there 
> when the statement is executed again….
> So IMHO only update and updateOrCreate are useful.
> WDYT,
> Konrad
>
>
> > Am 16.12.2022 um 20:42 schrieb Eric Norman :
> >
> > Also, another use case I was thinking of for the "update node" scenario is
> > if you want to add a mixin to a node that was expected to be already
> > created elsewhere,  if the node doesn't exist yet then your mixin won't get
> > assigned and you could have indeterminate behavior later.  So failing fast
> > would quickly tell you something is wrong.
> >
> > Regards,
> > -Eric
> >
> >> On Fri, Dec 16, 2022 at 11:19 AM Eric Norman  wrote:
> >>
> >> TBH I don’t yet see use cases for failing when the node does already
> >>> exist  (create node in your proposal) nor for failing when the node does
> >>> not exist (update node)
> >>>
> >>
> >> Yes, that is kind of the point.  You can't possibly conceive every
> >> possible use case, so just make the language generic enough to satisfy a
> >> broad set of use cases.  I can envision a highly modular distribution in
> >> which two modules (from different owners) may accidentally have paths that
> >> collide.  So I can see how a repoinit that would fail fast in that scenario
> >> could be useful.  In other words, if someone else already created a path
> >> (with the wrong types) that you are not expecting to be there, then failing
> >> right away seems like a reasonable solution.
> >>
> >> (We also don’t have anything like that for set properties AFAIK)
> >>>
> >>
> >> I think the "[set|default] propertyName ..." syntax is conceptually
> >> similar.  In that, the "default" operator would only modify the value if it
> >> does not already have a non-default value.
> >>
> >> Regards,
> >> -Eric
> >>
> >>> On Fri, Dec 16, 2022 at 11:04 AM Konrad Windszus  wrote:
> >>>
> >>> TBH I don’t yet see use cases for failing when the node does already
> >>> exist  (create node in your proposal) nor for failing when the node does
> >>> not exist (update node)
> >>> Can you share some examples you have in mind which would benefit from
> >>> that functionality?
> >>> (We also don’t have anything like that for set properties AFAIK)
> >>>
> >>> Thanks,
> >>> Konrad
> >>>
> >>>
>  On 16. Dec 2022, at 19:59, Eric Norman  wrote:
> 
>  For me the proposed "strict" modifier doesn't seem obvious what it is
> >>> going
>  to do.
> 
>  I would prefer a more verbose language with several options and let me
>  choose which one to use.  In other words, deprecate the original
>  (ambiguous) "create path" syntax and replace it with a new
>  "[create|update|createOrUpdate] node" syntax that is more clear what is
>  expected to happen.
> 
>  For example:
> 
>  # the original syntax (leave as is for backward compatibility).
>  #   This would be similar to the "createOrUpdate" use case without any
>  #   attempts to change the primaryNodeType and mixinTypes of already
>  existing nodes
>  create path (nt:folder) /one(mixin nt:art)/step(mixin
> >>> nt:dance)/two/steps
> 
>  #
> 
> >>> 
>  # - New replacement
>  syntax ---
>  #
> 
> >>> 
> 
>  # new syntax that will fail if any of the paths already exist
>  create node (nt:folder) /one(mixin nt:art)/step(mixin
> >>> nt:dance)/two/steps
> 
>  # new syntax that will fail if any of the affected paths do not already
>  exist
>  #   and would attempt to change the primaryNodeType and mixinTypes where
>  specified
>  update node (nt:folder) /one(mixin nt:art)/step(mixin
> >>> nt:dance)/two/steps
> 
>  # new syntax that will create nodes that do not yet exist and update
> >>> nodes
>  that do already exist
>  #  by attempting to change the primaryNodeType and mixinTypes where
>  specified
>  createOrUpdate node (nt:folder) /one(mixin
>  nt:art)/step(mixin nt:dance)/two/steps
> 
> 
> 
>  Regards,
>  -Eric
> 
>  On Fri, Dec 16, 2022 at 6:53 AM Julian Reschke 
>  wrote:
> 
> > On 16.12.2022 14:38, Konrad Windszus wrote:
> >>
> >>> On 16. Dec 2022, at 14:31, Bertrand Delacretaz <
> >>> bdelacre...@apache.org>
> > wrote:
> >>

[jira] [Resolved] (SLING-11738) Add option to prevent request override

[Carsten Ziegeler (Jira)]

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

Carsten Ziegeler resolved SLING-11738.
--
Resolution: Fixed

https://github.com/apache/sling-org-apache-sling-featureflags/commit/e33ce2150d5905683c096255f7f4089919ad425f

> Add option to prevent request override
> --
>
> Key: SLING-11738
> URL: https://issues.apache.org/jira/browse/SLING-11738
> Project: Sling
>  Issue Type: Improvement
>  Components: Feature Flags
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Feature Flags 1.2.4
>
>
> While it is useful doing development to override a feature flag value, this 
> might not be desirable in production. We should therefore provide an option 
> to disable per request overrides



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

[jira] [Created] (SLING-11738) Add option to prevent request override

[Carsten Ziegeler (Jira)]

Carsten Ziegeler created SLING-11738:


 Summary: Add option to prevent request override
 Key: SLING-11738
 URL: https://issues.apache.org/jira/browse/SLING-11738
 Project: Sling
  Issue Type: Improvement
  Components: Feature Flags
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Feature Flags 1.2.4


While it is useful doing development to override a feature flag value, this 
might not be desirable in production. We should therefore provide an option to 
disable per request overrides



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

Re: New repository for SLING-11729 (RepoInit FileVault Validator)

[Konrad Windszus]

Done now in 
https://gitbox.apache.org/repos/asf/sling-org-apache-sling-repoinit-filevault-validator.git
 
.

> On 15. Dec 2022, at 10:41, Konrad Windszus  wrote:
> 
> Hi,
> I proposed a FileVault validator for RepoInit in 
> https://issues.apache.org/jira/browse/SLING-11729 
> .
> The initial source can be found in 
> https://github.com/apache/sling-whiteboard/tree/master/org.apache.sling.repoinit.filevault.validator
>  
> .
> 
> I would like to create a new repo named 
> “org.apache.sling.repoinit.filevault.validator” for it and move the source 
> there as I plan to cut a first release soon.
> 
> Do you have any objections or comments?
> 
> Thanks,
> Konrad