[jira] [Commented] (SLING-8587) Sling Feature Maven Plugin does not work w/o proper FM setup

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-8587:
-

Maven supports phases and mojos can be bound to a phase. WIth that you can 
control the ordering and don't need the markers which would be a very uncommon 
thing to do in maven.

> Sling Feature Maven Plugin does not work w/o proper FM setup
> 
>
> Key: SLING-8587
> URL: https://issues.apache.org/jira/browse/SLING-8587
> Project: Sling
>  Issue Type: New Feature
>  Components: Feature Model
>Affects Versions: slingfeature-maven-plugin 1.0.4
>Reporter: Andreas Schaefer
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.6
>
>
> Because this Maven Plugin does a check after the project is loaded it will 
> fail if there is no feature files or other issues with the feature files even 
> if that is resolved along the project's build.
> For example if for whatever reason the feature directory is not there or 
> empty a 'mvn clean' will fail.
> Adding the convert content package Mojo to this feature is not working 
> because there is no feature file at the beginning as they are created by the 
> Mojo.
> This tests should be moved to the Mojo that depend on it and it must be 
> executed on each Mojo as the features can have been changed in the meantime.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (SLING-8587) Sling Feature Maven Plugin does not work w/o proper FM setup

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-8587:
-

[~schaefa] Yes, this fixes the mvn clean problem,  but I thought SLING-8541 is 
covering the other part - or is that something different?

> Sling Feature Maven Plugin does not work w/o proper FM setup
> 
>
> Key: SLING-8587
> URL: https://issues.apache.org/jira/browse/SLING-8587
> Project: Sling
>  Issue Type: New Feature
>  Components: Feature Model
>Affects Versions: slingfeature-maven-plugin 1.0.4
>Reporter: Andreas Schaefer
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.6
>
>
> Because this Maven Plugin does a check after the project is loaded it will 
> fail if there is no feature files or other issues with the feature files even 
> if that is resolved along the project's build.
> For example if for whatever reason the feature directory is not there or 
> empty a 'mvn clean' will fail.
> Adding the convert content package Mojo to this feature is not working 
> because there is no feature file at the beginning as they are created by the 
> Mojo.
> This tests should be moved to the Mojo that depend on it and it must be 
> executed on each Mojo as the features can have been changed in the meantime.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Re: [VOTE] Release Apache Sling Content Parser API 2.0.0, Apache Sling Content Parser JSON 2.0.0, Apache Sling Content Parser XML 2.0.0, Apache Sling Content Parser XML JCR 2.0.0, Apache Sling Content

[Andreas Schaefer]

+1 (non-binding)

Cheers - Andy

> On Jul 24, 2019, at 7:55 AM, Radu Cotescu  wrote:
> 
> Hi,
> 
> We solved 1 issue in these releases:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12345735
> https://issues.apache.org/jira/browse/SLING/fixforversion/12345850
> https://issues.apache.org/jira/browse/SLING/fixforversion/12345851
> https://issues.apache.org/jira/browse/SLING/fixforversion/12345852
> https://issues.apache.org/jira/browse/SLING/fixforversion/12345947
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-2107/
> 
> 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 2107 /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,
> Radu Cotescu
> 

[jira] [Reopened] (SLING-8587) Sling Feature Maven Plugin does not work w/o proper FM setup

[Andreas Schaefer (JIRA)]

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

Andreas Schaefer reopened SLING-8587:
-

That fixed the issue of the Maven Clean but will not be sufficient to work with 
the Converters.

I would suggest that we either:
- postpone the parsing of the FM files until it is needed by Mojos
- allow to re-run the parsing of the FM files to account for generated FMs

Either way we should have two flags:
- one that marks when a (re-)parsing should be done due to FM generation
- one that marks when FM is settled (aggregate, attach ..) and generation 
should not be allowed anymore

Rerunning the parsing seems to do just fine as I just did really crude in my 
branch where the parsing is done on each FM handling Mojo.

> Sling Feature Maven Plugin does not work w/o proper FM setup
> 
>
> Key: SLING-8587
> URL: https://issues.apache.org/jira/browse/SLING-8587
> Project: Sling
>  Issue Type: New Feature
>  Components: Feature Model
>Affects Versions: slingfeature-maven-plugin 1.0.4
>Reporter: Andreas Schaefer
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.6
>
>
> Because this Maven Plugin does a check after the project is loaded it will 
> fail if there is no feature files or other issues with the feature files even 
> if that is resolved along the project's build.
> For example if for whatever reason the feature directory is not there or 
> empty a 'mvn clean' will fail.
> Adding the convert content package Mojo to this feature is not working 
> because there is no feature file at the beginning as they are created by the 
> Mojo.
> This tests should be moved to the Mojo that depend on it and it must be 
> executed on each Mojo as the features can have been changed in the meantime.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Re: [VOTE] Release Apache Sling Content Parser API 2.0.0, Apache Sling Content Parser JSON 2.0.0, Apache Sling Content Parser XML 2.0.0, Apache Sling Content Parser XML JCR 2.0.0, Apache Sling Content

[Carsten Ziegeler]

+1


Radu Cotescu wrote

Hi,

We solved 1 issue in these releases:
https://issues.apache.org/jira/browse/SLING/fixforversion/12345735
https://issues.apache.org/jira/browse/SLING/fixforversion/12345850
https://issues.apache.org/jira/browse/SLING/fixforversion/12345851
https://issues.apache.org/jira/browse/SLING/fixforversion/12345852
https://issues.apache.org/jira/browse/SLING/fixforversion/12345947

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

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 2107 /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,
Radu Cotescu


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

Re: [VOTE] Release Apache Sling Content Parser API 2.0.0, Apache Sling Content Parser JSON 2.0.0, Apache Sling Content Parser XML 2.0.0, Apache Sling Content Parser XML JCR 2.0.0, Apache Sling Content

[Konrad Windszus]

IMHO  it is the other way around: If only few/one bundle are supposed to 
implement the interface rather annotate with ProviderType (compare with 
https://osgi.org/javadoc/osgi.annotation/7.0.0/org/osgi/annotation/versioning/ProviderType.html
 

 and 
https://github.com/apache/sling-org-apache-sling-contentparser-api/blob/master/src/main/java/org/apache/sling/contentparser/api/ParserHelper.java
 
).
But I don't think it does matter for final classes as you anyhow cannot 
extend/implement them!
Konrad

> On 24. Jul 2019, at 18:40, Radu Cotescu  wrote:
> 
> Hi Stefan,
> 
>> On 24 Jul 2019, at 18:29, Stefan Seifert  wrote:
>> 
>> p.s. i think the annotation in [1] should be @ProviderType, not 
>> @ConsumerType - but i think this can be changed in future releases without 
>> breaking anything.
>> [1] 
>> https://github.com/apache/sling-org-apache-sling-contentparser-api/blob/master/src/main/java/org/apache/sling/contentparser/api/ParserHelper.java
>>  
>> 
> The class is not supposed to be implemented, so IMO this is a Consumer, 
> right? The ConsumerType is actually the default assumed by most OSGi plugins 
> if I remember correctly, so annotating this final class with ConsumerType was 
> just a pedantic move on my part.
> 
> Cheers,
> Radu

Re: [VOTE] Release Apache Sling Content Parser API 2.0.0, Apache Sling Content Parser JSON 2.0.0, Apache Sling Content Parser XML 2.0.0, Apache Sling Content Parser XML JCR 2.0.0, Apache Sling Content

[Radu Cotescu]

Hi Stefan,

> On 24 Jul 2019, at 18:29, Stefan Seifert  wrote:
> 
> p.s. i think the annotation in [1] should be @ProviderType, not @ConsumerType 
> - but i think this can be changed in future releases without breaking 
> anything.
> [1] 
> https://github.com/apache/sling-org-apache-sling-contentparser-api/blob/master/src/main/java/org/apache/sling/contentparser/api/ParserHelper.java
>  
> 
The class is not supposed to be implemented, so IMO this is a Consumer, right? 
The ConsumerType is actually the default assumed by most OSGi plugins if I 
remember correctly, so annotating this final class with ConsumerType was just a 
pedantic move on my part.

Cheers,
Radu

[jira] [Resolved] (SLING-8599) The CLI tool reports an incorrect number of fixed JIRA issues when the same issue is linked to multiple versions

[Radu Cotescu (JIRA)]

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

Radu Cotescu resolved SLING-8599.
-
Resolution: Fixed

Fixed in [commit 
d7809cf|https://github.com/apache/sling-org-apache-sling-committer-cli/commit/d7809cf].

> The CLI tool reports an incorrect number of fixed JIRA issues when the same 
> issue is linked to multiple versions
> 
>
> Key: SLING-8599
> URL: https://issues.apache.org/jira/browse/SLING-8599
> Project: Sling
>  Issue Type: Bug
>  Components: Tooling
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Committer CLI 1.0.0
>
>
> The CLI tool reports an incorrect number of fixed JIRA issues when the same 
> issue is linked to multiple versions because it adds up the number of fixed 
> issues for each release instead of creating a set with the fixed issues.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

RE: [VOTE] Release Apache Sling Content Parser API 2.0.0, Apache Sling Content Parser JSON 2.0.0, Apache Sling Content Parser XML 2.0.0, Apache Sling Content Parser XML JCR 2.0.0, Apache Sling Content

[Stefan Seifert]

+1

stefan

p.s. i think the annotation in [1] should be @ProviderType, not @ConsumerType - 
but i think this can be changed in future releases without breaking anything.
[1] 
https://github.com/apache/sling-org-apache-sling-contentparser-api/blob/master/src/main/java/org/apache/sling/contentparser/api/ParserHelper.java




>-Original Message-
>From: Radu Cotescu [mailto:r...@apache.org]
>Sent: Wednesday, July 24, 2019 4:56 PM
>To: Sling Dev
>Subject: [VOTE] Release Apache Sling Content Parser API 2.0.0, Apache Sling
>Content Parser JSON 2.0.0, Apache Sling Content Parser XML 2.0.0, Apache
>Sling Content Parser XML JCR 2.0.0, Apache Sling Content Parser Test
>Utilities 2.0.0
>
>Hi,
>
>We solved 1 issue in these releases:
>https://issues.apache.org/jira/browse/SLING/fixforversion/12345735
>https://issues.apache.org/jira/browse/SLING/fixforversion/12345850
>https://issues.apache.org/jira/browse/SLING/fixforversion/12345851
>https://issues.apache.org/jira/browse/SLING/fixforversion/12345852
>https://issues.apache.org/jira/browse/SLING/fixforversion/12345947
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-2107/
>
>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 2107 /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,
>Radu Cotescu
>

[jira] [Created] (SLING-8599) The CLI tool reports an incorrect number of fixed JIRA issues when the same issue is linked to multiple versions

[Radu Cotescu (JIRA)]

Radu Cotescu created SLING-8599:
---

 Summary: The CLI tool reports an incorrect number of fixed JIRA 
issues when the same issue is linked to multiple versions
 Key: SLING-8599
 URL: https://issues.apache.org/jira/browse/SLING-8599
 Project: Sling
  Issue Type: Bug
  Components: Tooling
Reporter: Radu Cotescu
Assignee: Radu Cotescu
 Fix For: Committer CLI 1.0.0


The CLI tool reports an incorrect number of fixed JIRA issues when the same 
issue is linked to multiple versions because it adds up the number of fixed 
issues for each release instead of creating a set with the fixed issues.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (SLING-7927) JSON Content Loading errors out import on malformed json

[Jason E Bailey (JIRA)]

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

Jason E Bailey commented on SLING-7927:
---

I'll review and correct, the line at times between the two are odd.

> JSON Content Loading errors out import on malformed json
> 
>
> Key: SLING-7927
> URL: https://issues.apache.org/jira/browse/SLING-7927
> Project: Sling
>  Issue Type: Bug
>Reporter: Jason E Bailey
>Assignee: Jason E Bailey
>Priority: Major
> Fix For: JCR Content Parser 1.2.8
>
>
> Current Behaviour:
> During the importing of json content from a bundle. If one of the files 
> contains malformed json the load process is discontinued and exits. This 
> stops the loading of any other, correctly formatted, data.
>  
> Expected Behaviour:
> If a single file contains malformed content, that specific file should 
> discontinue, the error logged and then the process continues to import the 
> rest of the provided content.
> As it is right now, it's possible to load the bundle and have the application 
> in an unworkable state. preventing the ability to trouble shoot and 
> investigate the root cause.
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Updated] (SLING-7926) JSON Content Parser should support namespace mangling

[Jason E Bailey (JIRA)]

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

Jason E Bailey updated SLING-7926:
--
Summary: JSON Content Parser should support namespace mangling  (was: JSON 
Content Loading should support namespace mangling)

> JSON Content Parser should support namespace mangling
> -
>
> Key: SLING-7926
> URL: https://issues.apache.org/jira/browse/SLING-7926
> Project: Sling
>  Issue Type: Improvement
>Reporter: Jason E Bailey
>Assignee: Jason E Bailey
>Priority: Major
> Fix For: JCR Content Parser 1.2.8
>
>
> Currently it's possible to define a json file with a name that matches a 
> mangled namespace. Which then makes the file unable to be accessed from the 
> ResourceResolver
> i.e. importing a file `_jcr_content.json` will create the node `_jcr_content` 
> which cannot then be resolved as the resource resolver will attempt to 
> convert `_jcr_content` to `jcr:content` supporting namespace mangling will 
> additionally provide a cleaner `colon` support then the current 
> recommendation of a url mangled colon of `%3A`
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (SLING-7926) JSON Content Loading should support namespace mangling

[Jason E Bailey (JIRA)]

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

Jason E Bailey commented on SLING-7926:
---

You're correct, I was looking at both of them at that time and switched names. 
I'll Update

> JSON Content Loading should support namespace mangling
> --
>
> Key: SLING-7926
> URL: https://issues.apache.org/jira/browse/SLING-7926
> Project: Sling
>  Issue Type: Improvement
>Reporter: Jason E Bailey
>Assignee: Jason E Bailey
>Priority: Major
> Fix For: JCR Content Parser 1.2.8
>
>
> Currently it's possible to define a json file with a name that matches a 
> mangled namespace. Which then makes the file unable to be accessed from the 
> ResourceResolver
> i.e. importing a file `_jcr_content.json` will create the node `_jcr_content` 
> which cannot then be resolved as the resource resolver will attempt to 
> convert `_jcr_content` to `jcr:content` supporting namespace mangling will 
> additionally provide a cleaner `colon` support then the current 
> recommendation of a url mangled colon of `%3A`
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[VOTE] Release Apache Sling Content Parser API 2.0.0, Apache Sling Content Parser JSON 2.0.0, Apache Sling Content Parser XML 2.0.0, Apache Sling Content Parser XML JCR 2.0.0, Apache Sling Content Par

[Radu Cotescu]

Hi,

We solved 1 issue in these releases:
https://issues.apache.org/jira/browse/SLING/fixforversion/12345735
https://issues.apache.org/jira/browse/SLING/fixforversion/12345850
https://issues.apache.org/jira/browse/SLING/fixforversion/12345851
https://issues.apache.org/jira/browse/SLING/fixforversion/12345852
https://issues.apache.org/jira/browse/SLING/fixforversion/12345947

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

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 2107 /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,
Radu Cotescu

[jira] [Updated] (SLING-8592) Onboard content parser modules on SonarCloud

[Radu Cotescu (JIRA)]

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

Radu Cotescu updated SLING-8592:

Component/s: Content Parser

> Onboard content parser modules on SonarCloud
> 
>
> Key: SLING-8592
> URL: https://issues.apache.org/jira/browse/SLING-8592
> Project: Sling
>  Issue Type: Sub-task
>  Components: Content Parser
>Reporter: Radu Cotescu
>Priority: Major
>
> The following modules should be onboarded on SonarCloud:
> # https://github.com/apache/sling-org-apache-sling-contentparser-api
> # https://github.com/apache/sling-org-apache-sling-contentparser-json
> # https://github.com/apache/sling-org-apache-sling-contentparser-xml
> # https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr
> # https://github.com/apache/sling-org-apache-sling-contentparser-testutils



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Updated] (SLING-8592) Onboard content parser modules on SonarCloud

[Radu Cotescu (JIRA)]

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

Radu Cotescu updated SLING-8592:

Fix Version/s: (was: Content Parser Test Utilities 2.0.0)
   (was: Content Parser XML JCR 2.0.0)
   (was: Content Parser XML 2.0.0)
   (was: Content Parser JSON 2.0.0)
   (was: Content Parser API 2.0.0)

> Onboard content parser modules on SonarCloud
> 
>
> Key: SLING-8592
> URL: https://issues.apache.org/jira/browse/SLING-8592
> Project: Sling
>  Issue Type: Sub-task
>Reporter: Radu Cotescu
>Priority: Major
>
> The following modules should be onboarded on SonarCloud:
> # https://github.com/apache/sling-org-apache-sling-contentparser-api
> # https://github.com/apache/sling-org-apache-sling-contentparser-json
> # https://github.com/apache/sling-org-apache-sling-contentparser-xml
> # https://github.com/apache/sling-org-apache-sling-contentparser-xml-jcr
> # https://github.com/apache/sling-org-apache-sling-contentparser-testutils



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Comment Edited] (SLING-7926) JSON Content Loading should support namespace mangling

[Radu Cotescu (JIRA)]

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

Radu Cotescu edited comment on SLING-7926 at 7/24/19 2:02 PM:
--

[~jebailey], isn't this issue about the JCR Content Loader and _not_ the Parser?


was (Author: radu.cotescu):
[~jebailey], isn't this issue about the JCR Content Loader?

> JSON Content Loading should support namespace mangling
> --
>
> Key: SLING-7926
> URL: https://issues.apache.org/jira/browse/SLING-7926
> Project: Sling
>  Issue Type: Improvement
>Reporter: Jason E Bailey
>Assignee: Jason E Bailey
>Priority: Major
> Fix For: JCR Content Parser 1.2.8
>
>
> Currently it's possible to define a json file with a name that matches a 
> mangled namespace. Which then makes the file unable to be accessed from the 
> ResourceResolver
> i.e. importing a file `_jcr_content.json` will create the node `_jcr_content` 
> which cannot then be resolved as the resource resolver will attempt to 
> convert `_jcr_content` to `jcr:content` supporting namespace mangling will 
> additionally provide a cleaner `colon` support then the current 
> recommendation of a url mangled colon of `%3A`
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Comment Edited] (SLING-7927) JSON Content Loading errors out import on malformed json

[Radu Cotescu (JIRA)]

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

Radu Cotescu edited comment on SLING-7927 at 7/24/19 2:02 PM:
--

[~jebailey], isn't this issue about the JCR Content Loader and _not_ the Parser?


was (Author: radu.cotescu):
[~jebailey], isn't this issue about the JCR Content Loader?

> JSON Content Loading errors out import on malformed json
> 
>
> Key: SLING-7927
> URL: https://issues.apache.org/jira/browse/SLING-7927
> Project: Sling
>  Issue Type: Bug
>Reporter: Jason E Bailey
>Assignee: Jason E Bailey
>Priority: Major
> Fix For: JCR Content Parser 1.2.8
>
>
> Current Behaviour:
> During the importing of json content from a bundle. If one of the files 
> contains malformed json the load process is discontinued and exits. This 
> stops the loading of any other, correctly formatted, data.
>  
> Expected Behaviour:
> If a single file contains malformed content, that specific file should 
> discontinue, the error logged and then the process continues to import the 
> rest of the provided content.
> As it is right now, it's possible to load the bundle and have the application 
> in an unworkable state. preventing the ability to trouble shoot and 
> investigate the root cause.
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (SLING-7927) JSON Content Loading errors out import on malformed json

[Radu Cotescu (JIRA)]

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

Radu Cotescu commented on SLING-7927:
-

[~jebailey], isn't this issue about the JCR Content Loader?

> JSON Content Loading errors out import on malformed json
> 
>
> Key: SLING-7927
> URL: https://issues.apache.org/jira/browse/SLING-7927
> Project: Sling
>  Issue Type: Bug
>Reporter: Jason E Bailey
>Assignee: Jason E Bailey
>Priority: Major
> Fix For: JCR Content Parser 1.2.8
>
>
> Current Behaviour:
> During the importing of json content from a bundle. If one of the files 
> contains malformed json the load process is discontinued and exits. This 
> stops the loading of any other, correctly formatted, data.
>  
> Expected Behaviour:
> If a single file contains malformed content, that specific file should 
> discontinue, the error logged and then the process continues to import the 
> rest of the provided content.
> As it is right now, it's possible to load the bundle and have the application 
> in an unworkable state. preventing the ability to trouble shoot and 
> investigate the root cause.
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (SLING-7926) JSON Content Loading should support namespace mangling

[Radu Cotescu (JIRA)]

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

Radu Cotescu commented on SLING-7926:
-

[~jebailey], isn't this issue about the JCR Content Loader?

> JSON Content Loading should support namespace mangling
> --
>
> Key: SLING-7926
> URL: https://issues.apache.org/jira/browse/SLING-7926
> Project: Sling
>  Issue Type: Improvement
>Reporter: Jason E Bailey
>Assignee: Jason E Bailey
>Priority: Major
> Fix For: JCR Content Parser 1.2.8
>
>
> Currently it's possible to define a json file with a name that matches a 
> mangled namespace. Which then makes the file unable to be accessed from the 
> ResourceResolver
> i.e. importing a file `_jcr_content.json` will create the node `_jcr_content` 
> which cannot then be resolved as the resource resolver will attempt to 
> convert `_jcr_content` to `jcr:content` supporting namespace mangling will 
> additionally provide a cleaner `colon` support then the current 
> recommendation of a url mangled colon of `%3A`
>  
>  



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Created] (SLING-8598) Deprecate org.apache.sling.jcr.contentparser

[Radu Cotescu (JIRA)]

Radu Cotescu created SLING-8598:
---

 Summary: Deprecate org.apache.sling.jcr.contentparser
 Key: SLING-8598
 URL: https://issues.apache.org/jira/browse/SLING-8598
 Project: Sling
  Issue Type: Task
  Components: JCR
Reporter: Radu Cotescu
Assignee: Radu Cotescu
 Fix For: JCR Content Parser 1.2.8


Once the modules resulted from SLING-8570 are released we should deprecate 
{{org.apache.sling.jcr.contentparser}}.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Re: Issue with Sling Feature Maven Plugin

[Carsten Ziegeler]

I've added a proposal to SLING-8541 to deal with the use case

Let's continue there

Carsten


Carsten Ziegeler wrote


I started to remove the DependencyLifecycleParticipant just to find out 
that this might create problems in reactor builds where one feature 
project depends on another feature: with the DLP these inter feature 
dependencies are managed as maven dependencies and the build order is 
correctly handled. Without the DLP, maven has no clue about these 
dependencies and might build them in the wrong order.


With that I don't think removing the DLP is a good idea.

As mentioned, we can solve the "mvn clean" problem easily and I'll fix 
that.


Second, we need to look into how the converter comes into play. I don't 
want to have the conversion as part of the featureplugin. At this point 
in time, the use case of the converter and the featureplugin in 
combination is a little bit unclear to me. Maybe you can explain a 
little bit about this?



Regards

Carsten

Carsten Ziegeler wrote

Hi,

I gave this a second thought and maybe we should drop the 
DependencyLifecycleParticipant from this plugin and simply handle it 
in the mojos. Probably the first mojo requiring a feature will 
initiate the work. I have the feeling that this could also simplify 
some of the code.


For my use case of having a feature as a maven dependency, we could 
simply build a different maven plugin. It's a different usage of 
features so splitting it into another plugin makes sense. I don't have 
any sample project for that to share.


Regards
Carsten

Andreas Schaefer wrote

Hi Carsten

Yes, moving the ‘feature exists’ check would fix the issue of no 
features in certain Mojos.
That said I think the Plugin must be able to pick up changes to 
feature models files during the build is it now the converter or 
copying in FMs as resources during the build.


We could have a static flag within Plugin that would indicate when a 
re-evaluation needs to be done so copying resources or generating FMs 
(aka converter) could trigger a re-evaluation.


Do you have a sample project regarding the use case of dependency 
through FM? I would like to add a IT test so that this is covered.


- Andy

On Jul 22, 2019, at 10:16 AM, Carsten Ziegeler 
 wrote:



Hi,


for a normal feature build it is not required to have the 
DependencyLifecycleParticipant, that's why your build works. For 
additional functionality like using the mvn versions plugin etc t is 
required.


And you're correct that any changes to features after the 
DependencyLifecycleParticipant  has run are not picked up.


One main one reason for the current way of doing things was actually 
the mvn versions plugin. However, the feature plugin has now a 
similar functionality.


The other reason is to use feature files to define dependencies for 
a java project. So instead of listing all your dependencies in the 
pom, you can simply reference a feature file and through the 
DependencyLifecycleParticipant these are added as dependencies to 
your project. This is very useful for bundle development as well as 
for developing small applications where you take a base stack 
defined as a feature and just add another bundle. I don't want to 
loose that functionality.


We can solve the "mvn clean" problem by just moving the check to the 
mojos. Each mojo calls already a central method that verifies if the 
DependencyLifecycleParticipant  has run and if we move the "no 
features found" check there, that problem is solved.


I understand that the converter use case is a different one, in that 
case you probably don't need a DependencyLifecycleParticipant  at all.


I think we already have a configuration for whether the 
DependencyLifecycleParticipant  is adding the artifacts from feature 
files to the maven project as dependencies. We could now defer all 
the functionality of the DependencyLifecycleParticipant  to the 
first mojo if that flag is turned off.



WDYT?


Regards

Carsten


Andreas Schaefer wrote

Hi Carsten
There are a few issues with the current way the plugin works:
1. If for whatever reason the features folder does not contain any 
features then a ‘mvn clean’ will fail. That check should be moved 
to a Mojo that requires a feature file and not being done for all 
Mojos
2. The DependencyLifecycleParticipant has a state which means that 
changes to features after the loading of the project is not 
reflected in that state meaning that when I generate feature files 
(CQ / PM converter) then it will not be considered by the feature 
Mojos (I did not do a thorough investigation so I might be wrong)
3. All the tests and a full Sling / Peregrine CMS conversion (9 CP 
packages), built and launch worked just fine for me.
I do not think the converter runs too late but it runs within the 
confines of the plugin meaning the DependencyLifecycleParticipant 
is fire ahead of the converters invocation. This is the firing 
sequence:

- Convert Sling PM to FM
- Convert Peregrine CMS CP 

[jira] [Commented] (SLING-8541) slingfeature-maven-plugin should allow for generated feature model files

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-8541:
-

As discussed in the mailing list I don't want to remove the usage of the 
DependencyLifecycleParticipant as this is the only way to work in a multi 
project setup with inter dependencies between features. The DLP is also useful 
for scenarios where you want to have the artifacts of a feature as project 
dependencies (although this could be moved to a separate plugin)

The use case described here is about generated features - which obviously are 
not available when the DLP runs.

How about we add a new configuration option
...
and this allows to specify a directory in the target folder and this option is 
evaluated (once) when the first mojo needing features is invoked

> slingfeature-maven-plugin should allow for generated feature model files
> 
>
> Key: SLING-8541
> URL: https://issues.apache.org/jira/browse/SLING-8541
> Project: Sling
>  Issue Type: New Feature
>  Components: Feature Model
>Affects Versions: slingfeature-maven-plugin 1.0.4
>Reporter: Andreas Schaefer
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.6
>
>
> The Sling Feature Maven Plugin is checking that the feature model folder is 
> containing feature model files when the plugin is started.
> This fails when the FM are generated prior to the execution of the Sling 
> Feature Maven Plugin. This check should be either made optional or moved 
> prior to the actual execution of the Plugin's goal.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Resolved] (SLING-8587) Sling Feature Maven Plugin does not work w/o proper FM setup

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-8587.
-
Resolution: Fixed

> Sling Feature Maven Plugin does not work w/o proper FM setup
> 
>
> Key: SLING-8587
> URL: https://issues.apache.org/jira/browse/SLING-8587
> Project: Sling
>  Issue Type: New Feature
>  Components: Feature Model
>Affects Versions: slingfeature-maven-plugin 1.0.4
>Reporter: Andreas Schaefer
>Assignee: Andreas Schaefer
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.6
>
>
> Because this Maven Plugin does a check after the project is loaded it will 
> fail if there is no feature files or other issues with the feature files even 
> if that is resolved along the project's build.
> For example if for whatever reason the feature directory is not there or 
> empty a 'mvn clean' will fail.
> Adding the convert content package Mojo to this feature is not working 
> because there is no feature file at the beginning as they are created by the 
> Mojo.
> This tests should be moved to the Mojo that depend on it and it must be 
> executed on each Mojo as the features can have been changed in the meantime.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Assigned] (SLING-8587) Sling Feature Maven Plugin does not work w/o proper FM setup

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reassigned SLING-8587:
---

Assignee: Carsten Ziegeler  (was: Andreas Schaefer)

> Sling Feature Maven Plugin does not work w/o proper FM setup
> 
>
> Key: SLING-8587
> URL: https://issues.apache.org/jira/browse/SLING-8587
> Project: Sling
>  Issue Type: New Feature
>  Components: Feature Model
>Affects Versions: slingfeature-maven-plugin 1.0.4
>Reporter: Andreas Schaefer
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.6
>
>
> Because this Maven Plugin does a check after the project is loaded it will 
> fail if there is no feature files or other issues with the feature files even 
> if that is resolved along the project's build.
> For example if for whatever reason the feature directory is not there or 
> empty a 'mvn clean' will fail.
> Adding the convert content package Mojo to this feature is not working 
> because there is no feature file at the beginning as they are created by the 
> Mojo.
> This tests should be moved to the Mojo that depend on it and it must be 
> executed on each Mojo as the features can have been changed in the meantime.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Resolved] (SLING-8597) Build fails with java 11

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-8597.
-
Resolution: Fixed

Updated to latest parent pom and fix the subpackages directive (23e8484)

> Build fails with java 11
> 
>
> Key: SLING-8597
> URL: https://issues.apache.org/jira/browse/SLING-8597
> Project: Sling
>  Issue Type: Bug
>  Components: Maven Plugins and Archetypes
>Affects Versions: slingfeature-maven-plugin 1.0.4
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.6
>
>
> The build of the plugin currently fails as an old version of the surefire 
> plugin is used. In addition it seems that the javadoc subpackages directive 
> needs to be specified by using a "=" as a value separator (instead of a space)



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Created] (SLING-8597) Build fails with java 11

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-8597:
---

 Summary: Build fails with java 11
 Key: SLING-8597
 URL: https://issues.apache.org/jira/browse/SLING-8597
 Project: Sling
  Issue Type: Bug
  Components: Maven Plugins and Archetypes
Affects Versions: slingfeature-maven-plugin 1.0.4
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: slingfeature-maven-plugin 1.0.6


The build of the plugin currently fails as an old version of the surefire 
plugin is used. In addition it seems that the javadoc subpackages directive 
needs to be specified by using a "=" as a value separator (instead of a space)



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Commented] (SLING-8596) mvn clean fails if feature directory is empty

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-8596:
-

Fixed in 285815b by moving this check to mojo execution time

> mvn clean fails if feature directory is empty
> -
>
> Key: SLING-8596
> URL: https://issues.apache.org/jira/browse/SLING-8596
> Project: Sling
>  Issue Type: Bug
>  Components: Maven Plugins and Archetypes
>Affects Versions: slingfeature-maven-plugin 1.0.4
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.6
>
>
> As the DependencyLifecycleParticipant is currently checking whether the 
> features directory is empty, mvn clean fails in these cases.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Resolved] (SLING-8596) mvn clean fails if feature directory is empty

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-8596.
-
Resolution: Fixed

> mvn clean fails if feature directory is empty
> -
>
> Key: SLING-8596
> URL: https://issues.apache.org/jira/browse/SLING-8596
> Project: Sling
>  Issue Type: Bug
>  Components: Maven Plugins and Archetypes
>Affects Versions: slingfeature-maven-plugin 1.0.4
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.0.6
>
>
> As the DependencyLifecycleParticipant is currently checking whether the 
> features directory is empty, mvn clean fails in these cases.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Created] (SLING-8596) mvn clean fails if feature directory is empty

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-8596:
---

 Summary: mvn clean fails if feature directory is empty
 Key: SLING-8596
 URL: https://issues.apache.org/jira/browse/SLING-8596
 Project: Sling
  Issue Type: Bug
  Components: Maven Plugins and Archetypes
Affects Versions: slingfeature-maven-plugin 1.0.4
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: slingfeature-maven-plugin 1.0.6


As the DependencyLifecycleParticipant is currently checking whether the 
features directory is empty, mvn clean fails in these cases.



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Updated] (SLING-8570) Extract a generic Content Parser API from org.apache.sling.jcr.contentparser with pluggable implementations

[Radu Cotescu (JIRA)]

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

Radu Cotescu updated SLING-8570:

Fix Version/s: Content Parser Test Utilities 1.0.0

> Extract a generic Content Parser API from org.apache.sling.jcr.contentparser 
> with pluggable implementations
> ---
>
> Key: SLING-8570
> URL: https://issues.apache.org/jira/browse/SLING-8570
> Project: Sling
>  Issue Type: New Feature
>  Components: Content Parser
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Content Parser API 1.0.0, Content Parser JSON 1.0.0, 
> Content Parser XML 1.0.0, Content Parser XML JCR 1.0.0, Content Parser Test 
> Utilities 1.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The {{org.apache.sling.jcr.contentparser}} bundle provides the API and three 
> parser implementations supporting JSON, XML and Vault XML structures for 
> generating Sling resource trees. The goal of this issue is to modularise 
> {{org.apache.sling.jcr.contentparser}}, by extracting 4 bundles:
> # org.apache.sling.contentparser.api - API only, no JCR / Jackrabbit 
> dependencies
> # org.apache.sling.contentparser.json - JSON parser implementation
> # org.apache.sling.contentparser.xml - XML parser implementation
> # org.apache.sling.contentparser.xml.jcr - JackRabbit FileVault parser 
> implementation



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[jira] [Updated] (SLING-8570) Extract a generic Content Parser API from org.apache.sling.jcr.contentparser with pluggable implementations

[Radu Cotescu (JIRA)]

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

Radu Cotescu updated SLING-8570:

Component/s: Content Parser

> Extract a generic Content Parser API from org.apache.sling.jcr.contentparser 
> with pluggable implementations
> ---
>
> Key: SLING-8570
> URL: https://issues.apache.org/jira/browse/SLING-8570
> Project: Sling
>  Issue Type: New Feature
>  Components: Content Parser
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Content Parser API 1.0.0, Content Parser JSON 1.0.0, 
> Content Parser XML 1.0.0, Content Parser XML JCR 1.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> The {{org.apache.sling.jcr.contentparser}} bundle provides the API and three 
> parser implementations supporting JSON, XML and Vault XML structures for 
> generating Sling resource trees. The goal of this issue is to modularise 
> {{org.apache.sling.jcr.contentparser}}, by extracting 4 bundles:
> # org.apache.sling.contentparser.api - API only, no JCR / Jackrabbit 
> dependencies
> # org.apache.sling.contentparser.json - JSON parser implementation
> # org.apache.sling.contentparser.xml - XML parser implementation
> # org.apache.sling.contentparser.xml.jcr - JackRabbit FileVault parser 
> implementation



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

Re: Issue with Sling Feature Maven Plugin

[Carsten Ziegeler]

I started to remove the DependencyLifecycleParticipant just to find out 
that this might create problems in reactor builds where one feature 
project depends on another feature: with the DLP these inter feature 
dependencies are managed as maven dependencies and the build order is 
correctly handled. Without the DLP, maven has no clue about these 
dependencies and might build them in the wrong order.


With that I don't think removing the DLP is a good idea.

As mentioned, we can solve the "mvn clean" problem easily and I'll fix that.

Second, we need to look into how the converter comes into play. I don't 
want to have the conversion as part of the featureplugin. At this point 
in time, the use case of the converter and the featureplugin in 
combination is a little bit unclear to me. Maybe you can explain a 
little bit about this?



Regards

Carsten

Carsten Ziegeler wrote

Hi,

I gave this a second thought and maybe we should drop the 
DependencyLifecycleParticipant from this plugin and simply handle it in 
the mojos. Probably the first mojo requiring a feature will initiate the 
work. I have the feeling that this could also simplify some of the code.


For my use case of having a feature as a maven dependency, we could 
simply build a different maven plugin. It's a different usage of 
features so splitting it into another plugin makes sense. I don't have 
any sample project for that to share.


Regards
Carsten

Andreas Schaefer wrote

Hi Carsten

Yes, moving the ‘feature exists’ check would fix the issue of no 
features in certain Mojos.
That said I think the Plugin must be able to pick up changes to 
feature models files during the build is it now the converter or 
copying in FMs as resources during the build.


We could have a static flag within Plugin that would indicate when a 
re-evaluation needs to be done so copying resources or generating FMs 
(aka converter) could trigger a re-evaluation.


Do you have a sample project regarding the use case of dependency 
through FM? I would like to add a IT test so that this is covered.


- Andy

On Jul 22, 2019, at 10:16 AM, Carsten Ziegeler  
wrote:



Hi,


for a normal feature build it is not required to have the 
DependencyLifecycleParticipant, that's why your build works. For 
additional functionality like using the mvn versions plugin etc t is 
required.


And you're correct that any changes to features after the 
DependencyLifecycleParticipant  has run are not picked up.


One main one reason for the current way of doing things was actually 
the mvn versions plugin. However, the feature plugin has now a 
similar functionality.


The other reason is to use feature files to define dependencies for a 
java project. So instead of listing all your dependencies in the pom, 
you can simply reference a feature file and through the 
DependencyLifecycleParticipant these are added as dependencies to 
your project. This is very useful for bundle development as well as 
for developing small applications where you take a base stack defined 
as a feature and just add another bundle. I don't want to loose that 
functionality.


We can solve the "mvn clean" problem by just moving the check to the 
mojos. Each mojo calls already a central method that verifies if the 
DependencyLifecycleParticipant  has run and if we move the "no 
features found" check there, that problem is solved.


I understand that the converter use case is a different one, in that 
case you probably don't need a DependencyLifecycleParticipant  at all.


I think we already have a configuration for whether the 
DependencyLifecycleParticipant  is adding the artifacts from feature 
files to the maven project as dependencies. We could now defer all 
the functionality of the DependencyLifecycleParticipant  to the first 
mojo if that flag is turned off.



WDYT?


Regards

Carsten


Andreas Schaefer wrote

Hi Carsten
There are a few issues with the current way the plugin works:
1. If for whatever reason the features folder does not contain any 
features then a ‘mvn clean’ will fail. That check should be moved to 
a Mojo that requires a feature file and not being done for all Mojos
2. The DependencyLifecycleParticipant has a state which means that 
changes to features after the loading of the project is not 
reflected in that state meaning that when I generate feature files 
(CQ / PM converter) then it will not be considered by the feature 
Mojos (I did not do a thorough investigation so I might be wrong)
3. All the tests and a full Sling / Peregrine CMS conversion (9 CP 
packages), built and launch worked just fine for me.
I do not think the converter runs too late but it runs within the 
confines of the plugin meaning the DependencyLifecycleParticipant is 
fire ahead of the converters invocation. This is the firing sequence:

- Convert Sling PM to FM
- Convert Peregrine CMS CP to FM
- Aggregate FMs
- Attach FMs
- Analyze FMs
BTW there is also the issue that the ‘slingosgifeature’ packaging / 
our 

[GitHub] [sling-org-apache-sling-distribution-core] cschneider commented on issue #11: Adding Proxy Configuration if available

[GitBox]

cschneider commented on issue #11: Adding Proxy Configuration if available
URL: 
https://github.com/apache/sling-org-apache-sling-distribution-core/pull/11#issuecomment-514503970
 
 
   Does this code work if we have no proxy configuration? The PR adds a 
mandatory reference to ProxyConfiguration. Can we be sure this service is 
always present?


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Created] (SLING-8595) Update of sling parent pom

[Christian Schneider (JIRA)]

Christian Schneider created SLING-8595:
--

 Summary: Update of sling parent pom
 Key: SLING-8595
 URL: https://issues.apache.org/jira/browse/SLING-8595
 Project: Sling
  Issue Type: Improvement
  Components: Content Distribution
Reporter: Christian Schneider
Assignee: Christian Schneider
 Fix For: Content Distribution Core 0.4.2


When running upstream modules together with sling distribution core in eclipse 
I got issues as the outdated osgi core jar slipped into the build dependencies 
of the upstream module.

I found that updating the parent pom fixed the issue. 



--
This message was sent by Atlassian JIRA
(v7.6.14#76016)

[GitHub] [sling-org-apache-sling-distribution-core] cschneider merged pull request #20: SLING-8591 - Hook to support custom code when installing or deleting …

[GitBox]

cschneider merged pull request #20: SLING-8591 - Hook to support custom code 
when installing or deleting …
URL: https://github.com/apache/sling-org-apache-sling-distribution-core/pull/20
 
 
   


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.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services