[jira] [Created] (SLING-7190) i18n translations not updated unless bundle is restarted

[Shivendra Vikram Srinet (JIRA)]

Shivendra Vikram Srinet created SLING-7190:
--

 Summary: i18n translations not updated unless bundle is restarted
 Key: SLING-7190
 URL: https://issues.apache.org/jira/browse/SLING-7190
 Project: Sling
  Issue Type: Bug
  Components: Extensions
Affects Versions: i18n 2.5.6
Reporter: Shivendra Vikram Srinet
 Fix For: i18n 2.5.10


Required System Setup - AEM 6.2SP1-CFP6 
Navigate to - http://localhost:4502/libs/cq/i18n/translator.html
Select dictionary /libs/granite/i18n 
Dictionary would get loaded in the UI
Update fr Translation for 'Create' to any random string
Click on save
Change System Language to fr
Navigate to - http://localhost:4502/sites.html/content
Check Create button label on the top right. It's not updated

Restarting the bundle (sling i18n) and refreshing the page loads the new 
translation. 

Prior to CFP6 (sling i18n 2.4.4) no restart was required. The bundle 
automatically got refreshed after any change in the resource. 




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Sling build broken for me.

[Karl Pauls]

On Wed, Oct 11, 2017 at 6:07 PM, Robert Munteanu  wrote:
> On Wed, 2017-10-11 at 16:04 +0200, Karl Pauls wrote:
>> On Wed, Oct 11, 2017 at 3:46 PM, Ian Boston  wrote:
>> > Hi,
>> >
>> > On 11 October 2017 at 11:21, Robert Munteanu 
>> > wrote:
>> >
>> > > Hi Ian,
>> > >
>> > > On Wed, 2017-10-11 at 10:47 +0100, Ian Boston wrote:
>> > > > Hi,
>> > > > Could be me.
>> > > > I do mvn clean install on a clean Sling checkout with a clean
>> > > > maven
>> > > > repo
>> > > > and I get failiures to download slingfeature:9-SNAPSHOT
>> > > > required by
>> > > > an IT
>> > > > test sample. This happens before the reactor starts.
>> > >
>> > > Fixed in http://svn.apache.org/viewvc?rev=1811803=revev .
>> > >
>> > > >
>> > > > If I fix that by using slingfeature:9 I then get 11 test
>> > > > failures in
>> > > > commons.log related to the format of the logging output.
>> > > >
>> > > > Is this just me ?
>> > > >
>> > > > If it is just me, I can disable tests there to move on.
>> > >
>> > > I am not sure anyone is building the full reactor anymore
>> >
>> >
>> >
>> > Isnt that a bit dangerous ?
>> > Not being able to reliably build Sling could allow a failure to go
>> > for
>> > months without being noticed using old snapshot builds from other
>> > modules.
>> >
>> > I assume no one is building all of Sling because it takes too long
>> > now ?
>>
>>
>> Carsten and I did sit down semi-regularly and got it back building.
>> Not sure when we did that last but it can't be more than a month or
>> two.
>>
>> I agree that this is not a good state to be in.
>>
>> regards,
>>
>> Karl
>
> Would it help if we added weekly builds for all modules, irrespective
> if any changes are present?

Yes, I think that would be a good start. Ultimately, I still think we
should get this "run integration tests with all bundles set to
SNAPSHOT build" working but until we have that we might as well make
sure we run the reactor every once in a while. Would that be hard to
do?

regards,

Karl

> Robert



-- 
Karl Pauls
karlpa...@gmail.com

RE: [VOTE] Release Apache Sling Discovery Oak 1.2.22

[Stefan Seifert]

+1

RE: [VOTE] Release Apache Sling Maven Sling Plugin 2.3.4

[Stefan Seifert]

+1

[VOTE] Release Apache Sling Maven Sling Plugin 2.3.4

[Stefan Seifert]

Hi,

We solved 1 issues in this release:
https://issues.apache.org/jira/projects/SLING/versions/12341647

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

You can use this UNIX script to download the release and verify the signatures:
http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh

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

Please vote to approve this release:

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

This majority vote is open for at least 72 hours.

stefan

Re: Sling build broken for me.

[Robert Munteanu]

On Wed, 2017-10-11 at 16:04 +0200, Karl Pauls wrote:
> On Wed, Oct 11, 2017 at 3:46 PM, Ian Boston  wrote:
> > Hi,
> > 
> > On 11 October 2017 at 11:21, Robert Munteanu 
> > wrote:
> > 
> > > Hi Ian,
> > > 
> > > On Wed, 2017-10-11 at 10:47 +0100, Ian Boston wrote:
> > > > Hi,
> > > > Could be me.
> > > > I do mvn clean install on a clean Sling checkout with a clean
> > > > maven
> > > > repo
> > > > and I get failiures to download slingfeature:9-SNAPSHOT
> > > > required by
> > > > an IT
> > > > test sample. This happens before the reactor starts.
> > > 
> > > Fixed in http://svn.apache.org/viewvc?rev=1811803=revev .
> > > 
> > > > 
> > > > If I fix that by using slingfeature:9 I then get 11 test
> > > > failures in
> > > > commons.log related to the format of the logging output.
> > > > 
> > > > Is this just me ?
> > > > 
> > > > If it is just me, I can disable tests there to move on.
> > > 
> > > I am not sure anyone is building the full reactor anymore
> > 
> > 
> > 
> > Isnt that a bit dangerous ?
> > Not being able to reliably build Sling could allow a failure to go
> > for
> > months without being noticed using old snapshot builds from other
> > modules.
> > 
> > I assume no one is building all of Sling because it takes too long
> > now ?
> 
> 
> Carsten and I did sit down semi-regularly and got it back building.
> Not sure when we did that last but it can't be more than a month or
> two.
> 
> I agree that this is not a good state to be in.
> 
> regards,
> 
> Karl

Would it help if we added weekly builds for all modules, irrespective
if any changes are present?

Robert

[jira] [Updated] (SLING-7189) Misleading Artifact Coordinates message for ResourceResolverType.JCR_OAK

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-7189:
--
Component/s: (was: Apache Sling Testing Rules)
 Testing

> Misleading Artifact Coordinates message for ResourceResolverType.JCR_OAK
> 
>
> Key: SLING-7189
> URL: https://issues.apache.org/jira/browse/SLING-7189
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing Sling Mock 2.2.12
>Reporter: Jens Lauterbach
>Assignee: Stefan Seifert
>Priority: Trivial
> Fix For: Testing Sling Mock 1.9.10, Testing Sling Mock 2.2.14
>
> Attachments: sling-7189-code.zip, sling-7189.patch
>
>
> When you create a {{SlingContext}} using {{ResourceResolverType.JCR_OAK}} you 
> get the following error if you do not have the required dependency:
> {quote}
> java.lang.RuntimeException: Unable to initialize JCR_OAK resource resolver 
> factory: Unable to instantiate resourcer resolver: 
> org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter. Make 
> sure this maven dependency is included: 
> org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak
> {quote}
> The message contains the {{groupId}} and {{artifactId}} of the dependency you 
> are supposed to add to your project:
> {quote}org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak{quote}
> The problem is that this dependency does not seem to exist. I was able to 
> solve this issue by adding the following dependency:
> {code}
> 
> org.apache.sling
> org.apache.sling.testing.sling-mock-oak
> 2.0.2
>  
> {code}
> This dependency does include the class 
> {{org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter}} 
> which is apparently the class that is supposed to be loaded by all of this.
> *Therefore, I would propose to update the artifact coordinates in the error 
> message.*
> I added a demo project that can be used to re-produce this issue:
> # Extract the attached archive
> # Run {{mvn clean test}}
> # Error occurs
> # Uncomment dependency in {{pom.xml}}
> # Run {{mvn clean test}}
> # Error is gone



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (SLING-7189) Misleading Artifact Coordinates message for ResourceResolverType.JCR_OAK

[Stefan Seifert (JIRA)]

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

Stefan Seifert resolved SLING-7189.
---
   Resolution: Fixed
 Assignee: Stefan Seifert
Fix Version/s: Testing Sling Mock 2.2.14
   Testing Sling Mock 1.9.10

you're right - this is a typo - thanks for reporting.
fixed in the next release.

Completed: At revision: 1811834  (2.x)
Completed: At revision: 1811833  (1.x)

> Misleading Artifact Coordinates message for ResourceResolverType.JCR_OAK
> 
>
> Key: SLING-7189
> URL: https://issues.apache.org/jira/browse/SLING-7189
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing Sling Mock 2.2.12
>Reporter: Jens Lauterbach
>Assignee: Stefan Seifert
>Priority: Trivial
> Fix For: Testing Sling Mock 1.9.10, Testing Sling Mock 2.2.14
>
> Attachments: sling-7189-code.zip, sling-7189.patch
>
>
> When you create a {{SlingContext}} using {{ResourceResolverType.JCR_OAK}} you 
> get the following error if you do not have the required dependency:
> {quote}
> java.lang.RuntimeException: Unable to initialize JCR_OAK resource resolver 
> factory: Unable to instantiate resourcer resolver: 
> org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter. Make 
> sure this maven dependency is included: 
> org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak
> {quote}
> The message contains the {{groupId}} and {{artifactId}} of the dependency you 
> are supposed to add to your project:
> {quote}org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak{quote}
> The problem is that this dependency does not seem to exist. I was able to 
> solve this issue by adding the following dependency:
> {code}
> 
> org.apache.sling
> org.apache.sling.testing.sling-mock-oak
> 2.0.2
>  
> {code}
> This dependency does include the class 
> {{org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter}} 
> which is apparently the class that is supposed to be loaded by all of this.
> *Therefore, I would propose to update the artifact coordinates in the error 
> message.*
> I added a demo project that can be used to re-produce this issue:
> # Extract the attached archive
> # Run {{mvn clean test}}
> # Error occurs
> # Uncomment dependency in {{pom.xml}}
> # Run {{mvn clean test}}
> # Error is gone



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-7189) Misleading Artifact Coordinates message for ResourceResolverType.JCR_OAK

[Jens Lauterbach (JIRA)]

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

Jens Lauterbach updated SLING-7189:
---
Attachment: sling-7189.patch

Added patch to fix the issue.

> Misleading Artifact Coordinates message for ResourceResolverType.JCR_OAK
> 
>
> Key: SLING-7189
> URL: https://issues.apache.org/jira/browse/SLING-7189
> Project: Sling
>  Issue Type: Bug
>  Components: Apache Sling Testing Rules
>Affects Versions: Testing Sling Mock 2.2.12
>Reporter: Jens Lauterbach
>Priority: Trivial
> Attachments: sling-7189-code.zip, sling-7189.patch
>
>
> When you create a {{SlingContext}} using {{ResourceResolverType.JCR_OAK}} you 
> get the following error if you do not have the required dependency:
> {quote}
> java.lang.RuntimeException: Unable to initialize JCR_OAK resource resolver 
> factory: Unable to instantiate resourcer resolver: 
> org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter. Make 
> sure this maven dependency is included: 
> org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak
> {quote}
> The message contains the {{groupId}} and {{artifactId}} of the dependency you 
> are supposed to add to your project:
> {quote}org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak{quote}
> The problem is that this dependency does not seem to exist. I was able to 
> solve this issue by adding the following dependency:
> {code}
> 
> org.apache.sling
> org.apache.sling.testing.sling-mock-oak
> 2.0.2
>  
> {code}
> This dependency does include the class 
> {{org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter}} 
> which is apparently the class that is supposed to be loaded by all of this.
> *Therefore, I would propose to update the artifact coordinates in the error 
> message.*
> I added a demo project that can be used to re-produce this issue:
> # Extract the attached archive
> # Run {{mvn clean test}}
> # Error occurs
> # Uncomment dependency in {{pom.xml}}
> # Run {{mvn clean test}}
> # Error is gone



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Sling build broken for me.

[Karl Pauls]

On Wed, Oct 11, 2017 at 3:46 PM, Ian Boston  wrote:
> Hi,
>
> On 11 October 2017 at 11:21, Robert Munteanu  wrote:
>
>> Hi Ian,
>>
>> On Wed, 2017-10-11 at 10:47 +0100, Ian Boston wrote:
>> > Hi,
>> > Could be me.
>> > I do mvn clean install on a clean Sling checkout with a clean maven
>> > repo
>> > and I get failiures to download slingfeature:9-SNAPSHOT required by
>> > an IT
>> > test sample. This happens before the reactor starts.
>>
>> Fixed in http://svn.apache.org/viewvc?rev=1811803=rev .
>>
>> >
>> > If I fix that by using slingfeature:9 I then get 11 test failures in
>> > commons.log related to the format of the logging output.
>> >
>> > Is this just me ?
>> >
>> > If it is just me, I can disable tests there to move on.
>>
>> I am not sure anyone is building the full reactor anymore
>
>
>
> Isnt that a bit dangerous ?
> Not being able to reliably build Sling could allow a failure to go for
> months without being noticed using old snapshot builds from other modules.
>
> I assume no one is building all of Sling because it takes too long now ?


Carsten and I did sit down semi-regularly and got it back building.
Not sure when we did that last but it can't be more than a month or
two.

I agree that this is not a good state to be in.

regards,

Karl

>
>> - we are
>> building individual modules on Jenkins [1].
>>
>> commons.log builds fine for me as an individual module and I don't see
>> it failing on Jenkins either.
>>
>> If there's a consistent failure at your end, please file a bug.
>
>
>
> Both commons log and commons log webconsole fail performing PaxExam ITs,
> reliably. Normal Unit tests are Ok.
> JDK 1.8.0
> Maven 3.5.0
>
> I have disabled tests in those bundles to move on, assuming its something
> strange about my box.
>
> Best Regards
> Ian
>
>
>
>> But for
>> getting the launchpad up and running only need to build
>> launchpad/builder/ - all depenendencies are releases therefore the
>> reactor build is not used.
>>
>> Thanks,
>>
>> Robert
>>
>>
>> [1]: https://builds.apache.org/view/S-Z/view/Sling/
>>



-- 
Karl Pauls
karlpa...@gmail.com

[jira] [Updated] (SLING-7189) Misleading Artifact Coordinates message for ResourceResolverType.JCR_OAK

[Jens Lauterbach (JIRA)]

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

Jens Lauterbach updated SLING-7189:
---
Priority: Trivial  (was: Minor)

> Misleading Artifact Coordinates message for ResourceResolverType.JCR_OAK
> 
>
> Key: SLING-7189
> URL: https://issues.apache.org/jira/browse/SLING-7189
> Project: Sling
>  Issue Type: Bug
>  Components: Apache Sling Testing Rules
>Affects Versions: Testing Sling Mock 2.2.12
>Reporter: Jens Lauterbach
>Priority: Trivial
> Attachments: sling-7189-code.zip
>
>
> When you create a {{SlingContext}} using {{ResourceResolverType.JCR_OAK}} you 
> get the following error if you do not have the required dependency:
> {quote}
> java.lang.RuntimeException: Unable to initialize JCR_OAK resource resolver 
> factory: Unable to instantiate resourcer resolver: 
> org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter. Make 
> sure this maven dependency is included: 
> org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak
> {quote}
> The message contains the {{groupId}} and {{artifactId}} of the dependency you 
> are supposed to add to your project:
> {quote}org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak{quote}
> The problem is that this dependency does not seem to exist. I was able to 
> solve this issue by adding the following dependency:
> {code}
> 
> org.apache.sling
> org.apache.sling.testing.sling-mock-oak
> 2.0.2
>  
> {code}
> This dependency does include the class 
> {{org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter}} 
> which is apparently the class that is supposed to be loaded by all of this.
> *Therefore, I would propose to update the artifact coordinates in the error 
> message.*
> I added a demo project that can be used to re-produce this issue:
> # Extract the attached archive
> # Run {{mvn clean test}}
> # Error occurs
> # Uncomment dependency in {{pom.xml}}
> # Run {{mvn clean test}}
> # Error is gone



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: Sling build broken for me.

[Ian Boston]

Hi,

On 11 October 2017 at 11:21, Robert Munteanu  wrote:

> Hi Ian,
>
> On Wed, 2017-10-11 at 10:47 +0100, Ian Boston wrote:
> > Hi,
> > Could be me.
> > I do mvn clean install on a clean Sling checkout with a clean maven
> > repo
> > and I get failiures to download slingfeature:9-SNAPSHOT required by
> > an IT
> > test sample. This happens before the reactor starts.
>
> Fixed in http://svn.apache.org/viewvc?rev=1811803=rev .
>
> >
> > If I fix that by using slingfeature:9 I then get 11 test failures in
> > commons.log related to the format of the logging output.
> >
> > Is this just me ?
> >
> > If it is just me, I can disable tests there to move on.
>
> I am not sure anyone is building the full reactor anymore



Isnt that a bit dangerous ?
Not being able to reliably build Sling could allow a failure to go for
months without being noticed using old snapshot builds from other modules.

I assume no one is building all of Sling because it takes too long now ?



> - we are
> building individual modules on Jenkins [1].
>
> commons.log builds fine for me as an individual module and I don't see
> it failing on Jenkins either.
>
> If there's a consistent failure at your end, please file a bug.



Both commons log and commons log webconsole fail performing PaxExam ITs,
reliably. Normal Unit tests are Ok.
JDK 1.8.0
Maven 3.5.0

I have disabled tests in those bundles to move on, assuming its something
strange about my box.

Best Regards
Ian



> But for
> getting the launchpad up and running only need to build
> launchpad/builder/ - all depenendencies are releases therefore the
> reactor build is not used.
>
> Thanks,
>
> Robert
>
>
> [1]: https://builds.apache.org/view/S-Z/view/Sling/
>

[jira] [Updated] (SLING-7189) Misleading Artifact Coordinates message for ResourceResolverType.JCR_OAK

[Jens Lauterbach (JIRA)]

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

Jens Lauterbach updated SLING-7189:
---
Description: 
When you create a {{SlingContext}} using {{ResourceResolverType.JCR_OAK}} you 
get the following error if you do not have the required dependency:

{quote}
java.lang.RuntimeException: Unable to initialize JCR_OAK resource resolver 
factory: Unable to instantiate resourcer resolver: 
org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter. Make 
sure this maven dependency is included: 
org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak
{quote}

The message contains the {{groupId}} and {{artifactId}} of the dependency you 
are supposed to add to your project:

{quote}org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak{quote}

The problem is that this dependency does not seem to exist. I was able to solve 
this issue by adding the following dependency:

{code}

org.apache.sling
org.apache.sling.testing.sling-mock-oak
2.0.2
 
{code}

This dependency does include the class 
{{org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter}} 
which is apparently the class that is supposed to be loaded by all of this.

*Therefore, I would propose to update the artifact coordinates in the error 
message.*

I added a demo project that can be used to re-produce this issue:

# Extract the archive
# Run {{mvn clean test}}
# Error occurs
# Uncomment dependency in {{pom.xml}}
# Run {{mvn clean test}}
# Error is gone

  was:
When you create a {{SlingContext}} using {{ResourceResolverType.JCR_OAK}} you 
get the following error if you do not have the required dependency:

{quote}
java.lang.RuntimeException: Unable to initialize JCR_OAK resource resolver 
factory: Unable to instantiate resourcer resolver: 
org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter. Make 
sure this maven dependency is included: 
org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak
{quote}

The message contains the {{groupId}} and {{artifactId}} of the dependency you 
are supposed to add to your project:

{quote}org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak{quote}

The problem is that this dependency does not seem to exist. I was able to solve 
this issue by adding the following dependency:

{code}

org.apache.sling
org.apache.sling.testing.sling-mock-oak
2.0.2
 
{code}

This dependency does include the class 
{{org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter}} 
which is apparently the class that is supposed to be loaded by all of this.

*Therefore, I would propose to update the artifact coordinates in the error 
message.*


> Misleading Artifact Coordinates message for ResourceResolverType.JCR_OAK
> 
>
> Key: SLING-7189
> URL: https://issues.apache.org/jira/browse/SLING-7189
> Project: Sling
>  Issue Type: Bug
>  Components: Apache Sling Testing Rules
>Affects Versions: Testing Sling Mock 2.2.12
>Reporter: Jens Lauterbach
>Priority: Minor
> Attachments: sling-7189-code.zip
>
>
> When you create a {{SlingContext}} using {{ResourceResolverType.JCR_OAK}} you 
> get the following error if you do not have the required dependency:
> {quote}
> java.lang.RuntimeException: Unable to initialize JCR_OAK resource resolver 
> factory: Unable to instantiate resourcer resolver: 
> org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter. Make 
> sure this maven dependency is included: 
> org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak
> {quote}
> The message contains the {{groupId}} and {{artifactId}} of the dependency you 
> are supposed to add to your project:
> {quote}org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak{quote}
> The problem is that this dependency does not seem to exist. I was able to 
> solve this issue by adding the following dependency:
> {code}
> 
> org.apache.sling
> org.apache.sling.testing.sling-mock-oak
> 2.0.2
>  
> {code}
> This dependency does include the class 
> {{org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter}} 
> which is apparently the class that is supposed to be loaded by all of this.
> *Therefore, I would propose to update the artifact coordinates in the error 
> message.*
> I added a demo project that can be used to re-produce this issue:
> # Extract the archive
> # Run {{mvn clean test}}
> # Error occurs
> # Uncomment dependency in {{pom.xml}}
> # Run {{mvn clean test}}
> # Error is gone



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-7189) Misleading Artifact Coordinates message for ResourceResolverType.JCR_OAK

[Jens Lauterbach (JIRA)]

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

Jens Lauterbach updated SLING-7189:
---
Description: 
When you create a {{SlingContext}} using {{ResourceResolverType.JCR_OAK}} you 
get the following error if you do not have the required dependency:

{quote}
java.lang.RuntimeException: Unable to initialize JCR_OAK resource resolver 
factory: Unable to instantiate resourcer resolver: 
org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter. Make 
sure this maven dependency is included: 
org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak
{quote}

The message contains the {{groupId}} and {{artifactId}} of the dependency you 
are supposed to add to your project:

{quote}org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak{quote}

The problem is that this dependency does not seem to exist. I was able to solve 
this issue by adding the following dependency:

{code}

org.apache.sling
org.apache.sling.testing.sling-mock-oak
2.0.2
 
{code}

This dependency does include the class 
{{org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter}} 
which is apparently the class that is supposed to be loaded by all of this.

*Therefore, I would propose to update the artifact coordinates in the error 
message.*

I added a demo project that can be used to re-produce this issue:

# Extract the attached archive
# Run {{mvn clean test}}
# Error occurs
# Uncomment dependency in {{pom.xml}}
# Run {{mvn clean test}}
# Error is gone

  was:
When you create a {{SlingContext}} using {{ResourceResolverType.JCR_OAK}} you 
get the following error if you do not have the required dependency:

{quote}
java.lang.RuntimeException: Unable to initialize JCR_OAK resource resolver 
factory: Unable to instantiate resourcer resolver: 
org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter. Make 
sure this maven dependency is included: 
org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak
{quote}

The message contains the {{groupId}} and {{artifactId}} of the dependency you 
are supposed to add to your project:

{quote}org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak{quote}

The problem is that this dependency does not seem to exist. I was able to solve 
this issue by adding the following dependency:

{code}

org.apache.sling
org.apache.sling.testing.sling-mock-oak
2.0.2
 
{code}

This dependency does include the class 
{{org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter}} 
which is apparently the class that is supposed to be loaded by all of this.

*Therefore, I would propose to update the artifact coordinates in the error 
message.*

I added a demo project that can be used to re-produce this issue:

# Extract the archive
# Run {{mvn clean test}}
# Error occurs
# Uncomment dependency in {{pom.xml}}
# Run {{mvn clean test}}
# Error is gone


> Misleading Artifact Coordinates message for ResourceResolverType.JCR_OAK
> 
>
> Key: SLING-7189
> URL: https://issues.apache.org/jira/browse/SLING-7189
> Project: Sling
>  Issue Type: Bug
>  Components: Apache Sling Testing Rules
>Affects Versions: Testing Sling Mock 2.2.12
>Reporter: Jens Lauterbach
>Priority: Minor
> Attachments: sling-7189-code.zip
>
>
> When you create a {{SlingContext}} using {{ResourceResolverType.JCR_OAK}} you 
> get the following error if you do not have the required dependency:
> {quote}
> java.lang.RuntimeException: Unable to initialize JCR_OAK resource resolver 
> factory: Unable to instantiate resourcer resolver: 
> org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter. Make 
> sure this maven dependency is included: 
> org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak
> {quote}
> The message contains the {{groupId}} and {{artifactId}} of the dependency you 
> are supposed to add to your project:
> {quote}org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak{quote}
> The problem is that this dependency does not seem to exist. I was able to 
> solve this issue by adding the following dependency:
> {code}
> 
> org.apache.sling
> org.apache.sling.testing.sling-mock-oak
> 2.0.2
>  
> {code}
> This dependency does include the class 
> {{org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter}} 
> which is apparently the class that is supposed to be loaded by all of this.
> *Therefore, I would propose to update the artifact coordinates in the error 
> message.*
> I added a demo project that can be used to re-produce this issue:
> # Extract the attached archive
> # Run {{mvn clean test}}
> # Error occurs
> # Uncomment dependency in {{pom.xml}}
> # Run {{mvn clean test}}
> # Error is 

[jira] [Updated] (SLING-7189) Misleading Artifact Coordinates message for ResourceResolverType.JCR_OAK

[Jens Lauterbach (JIRA)]

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

Jens Lauterbach updated SLING-7189:
---
Attachment: sling-7189-code.zip

Added demo code.

> Misleading Artifact Coordinates message for ResourceResolverType.JCR_OAK
> 
>
> Key: SLING-7189
> URL: https://issues.apache.org/jira/browse/SLING-7189
> Project: Sling
>  Issue Type: Bug
>  Components: Apache Sling Testing Rules
>Affects Versions: Testing Sling Mock 2.2.12
>Reporter: Jens Lauterbach
>Priority: Minor
> Attachments: sling-7189-code.zip
>
>
> When you create a {{SlingContext}} using {{ResourceResolverType.JCR_OAK}} you 
> get the following error if you do not have the required dependency:
> {quote}
> java.lang.RuntimeException: Unable to initialize JCR_OAK resource resolver 
> factory: Unable to instantiate resourcer resolver: 
> org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter. Make 
> sure this maven dependency is included: 
> org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak
> {quote}
> The message contains the {{groupId}} and {{artifactId}} of the dependency you 
> are supposed to add to your project:
> {quote}org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak{quote}
> The problem is that this dependency does not seem to exist. I was able to 
> solve this issue by adding the following dependency:
> {code}
> 
> org.apache.sling
> org.apache.sling.testing.sling-mock-oak
> 2.0.2
>  
> {code}
> This dependency does include the class 
> {{org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter}} 
> which is apparently the class that is supposed to be loaded by all of this.
> *Therefore, I would propose to update the artifact coordinates in the error 
> message.*



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-7189) Misleading Artifact Coordinates message for ResourceResolverType.JCR_OAK

[Jens Lauterbach (JIRA)]

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

Jens Lauterbach updated SLING-7189:
---
Description: 
When you create a {{SlingContext}} using {{ResourceResolverType.JCR_OAK}} you 
get the following error if you do not have the required dependency:

{quote}
java.lang.RuntimeException: Unable to initialize JCR_OAK resource resolver 
factory: Unable to instantiate resourcer resolver: 
org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter. Make 
sure this maven dependency is included: 
org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak
{quote}

The message contains the {{groupId}} and {{artifactId}} of the dependency you 
are supposed to add to your project:

{quote}org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak{quote}

The problem is that this dependency does not seem to exist. I was able to solve 
this issue by adding the following dependency:

{code}

org.apache.sling
org.apache.sling.testing.sling-mock-oak
2.0.2
 
{code}

This dependency does include the class 
{{org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter}} 
which is apparently the class that is supposed to be loaded by all of this.

*Therefore, I would propose to update the artifact coordinates in the error 
message.*

  was:
When you create a {{SlingContext}} using {{ResourceResolverType.JCR_OAK}} you 
get the following error if you do not have the required dependency:

{quote}
java.lang.RuntimeException: Unable to initialize JCR_OAK resource resolver 
factory: Unable to instantiate resourcer resolver: 
org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter. Make 
sure this maven dependency is included: 
org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak
{quote}

The message contains the {{groupId}} and {{artifactId}} of the dependency you 
are supposed to add to your project:

{quote}org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak{quote}

The problem is that this dependency does not seem to exist. I was able to solve 
this issue by adding the following dependency:

{code}

org.apache.sling
org.apache.sling.testing.sling-mock-oak
2.0.2
 
{code}

This dependency does include the class 
{{org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter}} 
which is apparently the class that is supposed to be loaded by all of this.


> Misleading Artifact Coordinates message for ResourceResolverType.JCR_OAK
> 
>
> Key: SLING-7189
> URL: https://issues.apache.org/jira/browse/SLING-7189
> Project: Sling
>  Issue Type: Bug
>  Components: Apache Sling Testing Rules
>Affects Versions: Testing Sling Mock 2.2.12
>Reporter: Jens Lauterbach
>Priority: Minor
>
> When you create a {{SlingContext}} using {{ResourceResolverType.JCR_OAK}} you 
> get the following error if you do not have the required dependency:
> {quote}
> java.lang.RuntimeException: Unable to initialize JCR_OAK resource resolver 
> factory: Unable to instantiate resourcer resolver: 
> org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter. Make 
> sure this maven dependency is included: 
> org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak
> {quote}
> The message contains the {{groupId}} and {{artifactId}} of the dependency you 
> are supposed to add to your project:
> {quote}org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak{quote}
> The problem is that this dependency does not seem to exist. I was able to 
> solve this issue by adding the following dependency:
> {code}
> 
> org.apache.sling
> org.apache.sling.testing.sling-mock-oak
> 2.0.2
>  
> {code}
> This dependency does include the class 
> {{org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter}} 
> which is apparently the class that is supposed to be loaded by all of this.
> *Therefore, I would propose to update the artifact coordinates in the error 
> message.*



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (SLING-7189) Misleading Artifact Coordinates message for ResourceResolverType.JCR_OAK

[Jens Lauterbach (JIRA)]

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

Jens Lauterbach updated SLING-7189:
---
Description: 
When you create a {{SlingContext}} using {{ResourceResolverType.JCR_OAK}} you 
get the following error if you do not have the required dependency:

{quote}
java.lang.RuntimeException: Unable to initialize JCR_OAK resource resolver 
factory: Unable to instantiate resourcer resolver: 
org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter. Make 
sure this maven dependency is included: 
org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak
{quote}

The message contains the {{groupId}} and {{artifactId}} of the dependency you 
are supposed to add to your project:

{quote}org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak{quote}

The problem is that this dependency does not seem to exist. I was able to solve 
this issue by adding the following dependency:

{code}

org.apache.sling
org.apache.sling.testing.sling-mock-oak
2.0.2
 
{code}

This dependency does include the class 
{{org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter}} 
which is apparently the class that is supposed to be loaded by all of this.

> Misleading Artifact Coordinates message for ResourceResolverType.JCR_OAK
> 
>
> Key: SLING-7189
> URL: https://issues.apache.org/jira/browse/SLING-7189
> Project: Sling
>  Issue Type: Bug
>  Components: Apache Sling Testing Rules
>Affects Versions: Testing Sling Mock 2.2.12
>Reporter: Jens Lauterbach
>Priority: Minor
>
> When you create a {{SlingContext}} using {{ResourceResolverType.JCR_OAK}} you 
> get the following error if you do not have the required dependency:
> {quote}
> java.lang.RuntimeException: Unable to initialize JCR_OAK resource resolver 
> factory: Unable to instantiate resourcer resolver: 
> org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter. Make 
> sure this maven dependency is included: 
> org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak
> {quote}
> The message contains the {{groupId}} and {{artifactId}} of the dependency you 
> are supposed to add to your project:
> {quote}org.apache.sling:org.apache.sling.testing.sling-mock-jackrabbit-oak{quote}
> The problem is that this dependency does not seem to exist. I was able to 
> solve this issue by adding the following dependency:
> {code}
> 
> org.apache.sling
> org.apache.sling.testing.sling-mock-oak
> 2.0.2
>  
> {code}
> This dependency does include the class 
> {{org.apache.sling.testing.mock.sling.oak.OakMockResourceResolverAdapter}} 
> which is apparently the class that is supposed to be loaded by all of this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-7189) Misleading Artifact Coordinates message for ResourceResolverType.JCR_OAK

[Jens Lauterbach (JIRA)]

Jens Lauterbach created SLING-7189:
--

 Summary: Misleading Artifact Coordinates message for 
ResourceResolverType.JCR_OAK
 Key: SLING-7189
 URL: https://issues.apache.org/jira/browse/SLING-7189
 Project: Sling
  Issue Type: Bug
  Components: Apache Sling Testing Rules
Affects Versions: Testing Sling Mock 2.2.12
Reporter: Jens Lauterbach
Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (SLING-7188) Sling post servlet should be logging more in debug / trace

[Nicolas Peltier (JIRA)]

Nicolas Peltier created SLING-7188:
--

 Summary: Sling post servlet should be logging more in debug / 
trace 
 Key: SLING-7188
 URL: https://issues.apache.org/jira/browse/SLING-7188
 Project: Sling
  Issue Type: Improvement
  Components: Servlets
Affects Versions: Servlets Post 2.3.22
Reporter: Nicolas Peltier


While filters are pretty well logged, all that happen after "Request 
Processing" is unknown. Would be nice to have, at debug or trace level may be, 
pointers of where we are in the post handling to avoid situation like
{Code}
org.apache.sling.engine.impl.debug.RequestProgressTrackerLogFilter REQUEST_18 - 
  52611 TIMER_END{52611,Request Processing} Request Processing
org.apache.sling.servlets.post.impl.operations.ModifyOperation Exception during
 response processing.
java.lang.NullPointerException: null
{Code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Re: [sling-site] branch master updated: Avoid encoding issues

[Bertrand Delacretaz]

Hi Julian,

On Wed, Oct 11, 2017 at 1:26 PM, Julian Sedding  wrote:
> ...I'll try reverting this fix and set AddDefaultCharset utf-8 in
> .htaccess instead

IMO it's better to avoid unicode chars in code, and those templates
are code so my preference is to keep \u00a9 for the copyright sign.
Encoding issues can also show up when editing files so better safe
than sorry.

That being said, if you can add encoding settings in the right places
like .htaccess that's fantastic! I just prefer keeping the code as is
- belt and suspenders maybe ;-)

-Bertrand

Re: [sling-site] branch master updated: Avoid encoding issues

[Julian Sedding]

Hi Bertrand

I'll try reverting this fix and set AddDefaultCharset utf-8 in
.htaccess instead. I believe that will be more convenient down the
road (if it works).

Regards
Julian


On Tue, Oct 10, 2017 at 11:51 AM,   wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> bdelacretaz pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/sling-site.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new 7fb315a  Avoid encoding issues
> 7fb315a is described below
>
> commit 7fb315ad7ac1edffc6e983fb5dcd9840097f3aef
> Author: Bertrand Delacretaz 
> AuthorDate: Tue Oct 10 11:51:13 2017 +0200
>
> Avoid encoding issues
> ---
>  src/main/jbake/templates/footer.tpl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/main/jbake/templates/footer.tpl 
> b/src/main/jbake/templates/footer.tpl
> index 555c601..d6cf40f 100644
> --- a/src/main/jbake/templates/footer.tpl
> +++ b/src/main/jbake/templates/footer.tpl
> @@ -4,5 +4,5 @@ p() {
>  yield "may be trademarks or registered trademarks of their respective 
> owners."
>  }
>  p() {
> -yield "Copyright © 2011-2017 The Apache Software Foundation."
> +yield "Copyright \u00a9 2011-2017 The Apache Software Foundation."
>  }
>
> --
> To stop receiving notification emails like this one, please contact
> ['"comm...@sling.apache.org" '].

Re: Depending on Oak 1.7.x

[Ian Boston]

On 11 October 2017 at 11:25, Robert Munteanu  wrote:

> On Wed, 2017-10-11 at 11:16 +0100, Ian Boston wrote:
> > Hi,
> > Switching to depend on Oak 1.7 requires upgrading oak-server to use
> > 1.7 or
> > later.
> > There has been some incompatible changes at a bundle level and
> > package
> > level between 1.6 and 1.7 so its not as simple has changing the
> > versions.
> > For instance oak-api bundle didnt existi in 1.6 and NodeAggregator
> > class
> > doesn't appear to exist in 1.7. oak-server wont build without a
> > patch.
> >
> > Obviously, if you have an oak-server or equivalent that already
> > depends on
> > 1.7 or later, then its trivial, but Sling doesn't.
>
> So we need need to make oak-server and jcr.resource dependent on Oak
> 1.7, right?
>

Yes, working on a patch now.
Compiles but all ITs fail.


>
> I would guess that oak-server is not such a big issue. Is it possible
> to make the dependency from jcr.resource to the newer oak api optional?
> If the bundle would also run on Oak 1.6 I guess there would be no
> issue.
>


In the original patch with AdapterFactories that would have been simple as
it was very loosly coupled for exactly this reason, however that patch was
rejected by this list, and a much more tightly bound patch[1] was
required.  Making HelperData, core to Sling GET Servlets, load safely with
one of its imports optional will be messy and will make its method calls
nasty.

Best Regards
Ian

1 https://github.com/apache/sling/compare/trunk...ieb:OAK-6575-3-2



>
> Thanks,
>
> Robert
>
> > Best Regards
> > Ian
> >
> > On 11 October 2017 at 11:07, Stefan Egli 
> > wrote:
> >
> > > Having said that, the only bullet to bite when switching to Oak
> > > 1.7.x is
> > > increased maintenance effort: the affected bundles will become
> > > backwards
> > > incompatible wrt Oak 1.6.x and if they need to be patched it would
> > > not be
> > > possible to do so in trunk anymore.
> > >
> > > Cheers,
> > > Stefan
> > >
> > > On 11/10/17 12:03, "Stefan Egli"  wrote:
> > >
> > > > Hi Ian,
> > > >
> > > > I don't see a problem with having a dependency on an unstable Oak
> > > > 1.7.x in
> > > > Sling.
> > > >
> > > > Actual deployments can still, independent of this, make a call
> > > > whether or
> > > > not they want to actually run on Oak 1.7.x or wait for Oak 1.8
> > > > (which is
> > > > advisable). IMO having this dependency doesn't imply on which
> > > > version it
> > > > will ultimately run.
> > > >
> > > > Cheers,
> > > > Stefan
> > > >
> > > > On 11/10/17 11:54, "Ian Boston"  > > > i...@tfd.co.uk> wrote:
> > > >
> > > > > Hi,
> > > > > Oak 1.7.x is Oak unstable release branch working towards 1.8.
> > > > > I have a feature in SLING-7140 that is blocked by an API change
> > > > > in Oak
> > > > > present in 1.8-SNAPSHOT and available as an unmerged but tested
> > > > > patch to
> > > > > Oak 1.6.x.
> > > > >
> > > > > The Oak team are unwilling merge the patch to 1.6 and have
> > > > > asked that
> > > > > Sling
> > > > > depend on the latest release of Oak 1.7.
> > > > >
> > > > > How does the Sling team feel about this ?
> > > > >
> > > > > The patch for SLING-7140 cant be merged until the API is
> > > > > available in Oak
> > > > > in some form and I don't want to depend on Oak 1.8-SNAPSHOT as
> > > > > this will
> > > > > block Sling releases of the bundles involved.
> > > > > Best Regards
> > > > > Ian
> > > >
> > > >
> > >
> > >
> > >
>
>

Re: Depending on Oak 1.7.x

[Oliver Lietz]

On Wednesday 11 October 2017 12:15:25 Konrad Windszus wrote:
> Adjusting the dependency implicitly has an effect on the import-version
> range being calculated by bnd for Sling bundles depending on Oak. Therefore
> depending on 1.7 most probably prevents the same Sling bundle from running
> with Oak 1.6. We had this discussion before and basically we were advised
> to only depend on the stable versions of Oak back then.

We should use releases from stable branches only, whether Oak or Jackrabbit or 
any other dependency.

Regards,
O.

> So I would much rather prefer to still rely on the last stable release.
> Konrad
> 
> > On 11. Oct 2017, at 12:03, Stefan Egli  wrote:
> > 
> > Hi Ian,
> > 
> > I don't see a problem with having a dependency on an unstable Oak 1.7.x in
> > Sling.
> > 
> > Actual deployments can still, independent of this, make a call whether or
> > not they want to actually run on Oak 1.7.x or wait for Oak 1.8 (which is
> > advisable). IMO having this dependency doesn't imply on which version it
> > will ultimately run.
> > 
> > Cheers,
> > Stefan
> > 
> > On 11/10/17 11:54, "Ian Boston"  > 
> > i...@tfd.co.uk> wrote:
> >> Hi,
> >> Oak 1.7.x is Oak unstable release branch working towards 1.8.
> >> I have a feature in SLING-7140 that is blocked by an API change in Oak
> >> present in 1.8-SNAPSHOT and available as an unmerged but tested patch to
> >> Oak 1.6.x.
> >> 
> >> The Oak team are unwilling merge the patch to 1.6 and have asked that
> >> Sling
> >> depend on the latest release of Oak 1.7.
> >> 
> >> How does the Sling team feel about this ?
> >> 
> >> The patch for SLING-7140 cant be merged until the API is available in Oak
> >> in some form and I don't want to depend on Oak 1.8-SNAPSHOT as this will
> >> block Sling releases of the bundles involved.
> >> Best Regards
> >> Ian

Re: Depending on Oak 1.7.x

[Robert Munteanu]

On Wed, 2017-10-11 at 11:16 +0100, Ian Boston wrote:
> Hi,
> Switching to depend on Oak 1.7 requires upgrading oak-server to use
> 1.7 or
> later.
> There has been some incompatible changes at a bundle level and
> package
> level between 1.6 and 1.7 so its not as simple has changing the
> versions.
> For instance oak-api bundle didnt existi in 1.6 and NodeAggregator
> class
> doesn't appear to exist in 1.7. oak-server wont build without a
> patch.
> 
> Obviously, if you have an oak-server or equivalent that already
> depends on
> 1.7 or later, then its trivial, but Sling doesn't.

So we need need to make oak-server and jcr.resource dependent on Oak
1.7, right?

I would guess that oak-server is not such a big issue. Is it possible
to make the dependency from jcr.resource to the newer oak api optional?
If the bundle would also run on Oak 1.6 I guess there would be no
issue.

Thanks,

Robert

> Best Regards
> Ian
> 
> On 11 October 2017 at 11:07, Stefan Egli 
> wrote:
> 
> > Having said that, the only bullet to bite when switching to Oak
> > 1.7.x is
> > increased maintenance effort: the affected bundles will become
> > backwards
> > incompatible wrt Oak 1.6.x and if they need to be patched it would
> > not be
> > possible to do so in trunk anymore.
> > 
> > Cheers,
> > Stefan
> > 
> > On 11/10/17 12:03, "Stefan Egli"  wrote:
> > 
> > > Hi Ian,
> > > 
> > > I don't see a problem with having a dependency on an unstable Oak
> > > 1.7.x in
> > > Sling.
> > > 
> > > Actual deployments can still, independent of this, make a call
> > > whether or
> > > not they want to actually run on Oak 1.7.x or wait for Oak 1.8
> > > (which is
> > > advisable). IMO having this dependency doesn't imply on which
> > > version it
> > > will ultimately run.
> > > 
> > > Cheers,
> > > Stefan
> > > 
> > > On 11/10/17 11:54, "Ian Boston"  > > i...@tfd.co.uk> wrote:
> > > 
> > > > Hi,
> > > > Oak 1.7.x is Oak unstable release branch working towards 1.8.
> > > > I have a feature in SLING-7140 that is blocked by an API change
> > > > in Oak
> > > > present in 1.8-SNAPSHOT and available as an unmerged but tested
> > > > patch to
> > > > Oak 1.6.x.
> > > > 
> > > > The Oak team are unwilling merge the patch to 1.6 and have
> > > > asked that
> > > > Sling
> > > > depend on the latest release of Oak 1.7.
> > > > 
> > > > How does the Sling team feel about this ?
> > > > 
> > > > The patch for SLING-7140 cant be merged until the API is
> > > > available in Oak
> > > > in some form and I don't want to depend on Oak 1.8-SNAPSHOT as
> > > > this will
> > > > block Sling releases of the bundles involved.
> > > > Best Regards
> > > > Ian
> > > 
> > > 
> > 
> > 
> > 

Re: Sling build broken for me.

[Robert Munteanu]

Hi Ian,

On Wed, 2017-10-11 at 10:47 +0100, Ian Boston wrote:
> Hi,
> Could be me.
> I do mvn clean install on a clean Sling checkout with a clean maven
> repo
> and I get failiures to download slingfeature:9-SNAPSHOT required by
> an IT
> test sample. This happens before the reactor starts.

Fixed in http://svn.apache.org/viewvc?rev=1811803=rev .

> 
> If I fix that by using slingfeature:9 I then get 11 test failures in
> commons.log related to the format of the logging output.
> 
> Is this just me ?
> 
> If it is just me, I can disable tests there to move on.

I am not sure anyone is building the full reactor anymore - we are
building individual modules on Jenkins [1].

commons.log builds fine for me as an individual module and I don't see
it failing on Jenkins either.

If there's a consistent failure at your end, please file a bug. But for
getting the launchpad up and running only need to build
launchpad/builder/ - all depenendencies are releases therefore the
reactor build is not used.

Thanks,

Robert


[1]: https://builds.apache.org/view/S-Z/view/Sling/

Re: [RT] Updates to the provisioning model

[Dominik Süß]

Hi Carsten,

can you provide some insights on timing wrt Felix Snapshot dependencies.
When we plugged together the demo we still had a few dependencies on
unreleased artifacts for the OSGi R7 work.

I would rather see this change happening yesterday than tomorrow to start
working on how the model can be maintained and operated over time and add
the corresponding missing pieces for this as touched in the presentation
(e.g. Deployment Admin & optimizations of installer and packagetransformer
for Sling). As some of that specifically should work properly hand-in-hand
with the builder and analyzer part I would want to avoid working against a
heavily moving target (assuming that SNAPSHOT is not settled at all).

Cheers
Dominik

On Thu, Oct 5, 2017 at 4:10 PM, Julian Sedding  wrote:

> Hi Bertrand
>
> I suppose it would be
>
> cat provisioning-model | jsmin | jq .
>
> I have not tested this, however.
>
> Regards
> Julian
>
>
> On Thu, Oct 5, 2017 at 3:39 PM, Bertrand Delacretaz
>  wrote:
> > On Thu, Oct 5, 2017 at 11:39 AM, Julian Sedding 
> wrote:
> >> ...lets stick with JSON + comments...
> >
> > Is that format accepted by JSON tools? Can I for example do
> >
> >   cat provisioning-model | jq .
> >
> > ?
> >
> > Otherwise I fear the format combines the worst of both worlds: hard
> > for humans to read and write (JSON) and not directly suitable for
> > machine processing. In which case I suggest rediscussing the comments
> > format/schema to make sure the result is pure JSON - maybe with
> > _comment_ elements that tools can easily ignore.
> >
> > -Bertrand
>

Re: Depending on Oak 1.7.x

[Ian Boston]

Hi,
Switching to depend on Oak 1.7 requires upgrading oak-server to use 1.7 or
later.
There has been some incompatible changes at a bundle level and package
level between 1.6 and 1.7 so its not as simple has changing the versions.
For instance oak-api bundle didnt existi in 1.6 and NodeAggregator class
doesn't appear to exist in 1.7. oak-server wont build without a patch.

Obviously, if you have an oak-server or equivalent that already depends on
1.7 or later, then its trivial, but Sling doesn't.
Best Regards
Ian

On 11 October 2017 at 11:07, Stefan Egli  wrote:

> Having said that, the only bullet to bite when switching to Oak 1.7.x is
> increased maintenance effort: the affected bundles will become backwards
> incompatible wrt Oak 1.6.x and if they need to be patched it would not be
> possible to do so in trunk anymore.
>
> Cheers,
> Stefan
>
> On 11/10/17 12:03, "Stefan Egli"  wrote:
>
> >Hi Ian,
> >
> >I don't see a problem with having a dependency on an unstable Oak 1.7.x in
> >Sling.
> >
> >Actual deployments can still, independent of this, make a call whether or
> >not they want to actually run on Oak 1.7.x or wait for Oak 1.8 (which is
> >advisable). IMO having this dependency doesn't imply on which version it
> >will ultimately run.
> >
> >Cheers,
> >Stefan
> >
> >On 11/10/17 11:54, "Ian Boston"  >i...@tfd.co.uk> wrote:
> >
> >>Hi,
> >>Oak 1.7.x is Oak unstable release branch working towards 1.8.
> >>I have a feature in SLING-7140 that is blocked by an API change in Oak
> >>present in 1.8-SNAPSHOT and available as an unmerged but tested patch to
> >>Oak 1.6.x.
> >>
> >>The Oak team are unwilling merge the patch to 1.6 and have asked that
> >>Sling
> >>depend on the latest release of Oak 1.7.
> >>
> >>How does the Sling team feel about this ?
> >>
> >>The patch for SLING-7140 cant be merged until the API is available in Oak
> >>in some form and I don't want to depend on Oak 1.8-SNAPSHOT as this will
> >>block Sling releases of the bundles involved.
> >>Best Regards
> >>Ian
> >
> >
>
>
>

Re: Depending on Oak 1.7.x

[Konrad Windszus]

Adjusting the dependency implicitly has an effect on the import-version range 
being calculated by bnd for Sling bundles depending on Oak.
Therefore depending on 1.7 most probably prevents the same Sling bundle from 
running with Oak 1.6.
We had this discussion before and basically we were advised to only depend on 
the stable versions of Oak back then.

So I would much rather prefer to still rely on the last stable release.
Konrad


> On 11. Oct 2017, at 12:03, Stefan Egli  wrote:
> 
> Hi Ian,
> 
> I don't see a problem with having a dependency on an unstable Oak 1.7.x in
> Sling.
> 
> Actual deployments can still, independent of this, make a call whether or
> not they want to actually run on Oak 1.7.x or wait for Oak 1.8 (which is
> advisable). IMO having this dependency doesn't imply on which version it
> will ultimately run.
> 
> Cheers,
> Stefan
> 
> On 11/10/17 11:54, "Ian Boston"  i...@tfd.co.uk> wrote:
> 
>> Hi,
>> Oak 1.7.x is Oak unstable release branch working towards 1.8.
>> I have a feature in SLING-7140 that is blocked by an API change in Oak
>> present in 1.8-SNAPSHOT and available as an unmerged but tested patch to
>> Oak 1.6.x.
>> 
>> The Oak team are unwilling merge the patch to 1.6 and have asked that
>> Sling
>> depend on the latest release of Oak 1.7.
>> 
>> How does the Sling team feel about this ?
>> 
>> The patch for SLING-7140 cant be merged until the API is available in Oak
>> in some form and I don't want to depend on Oak 1.8-SNAPSHOT as this will
>> block Sling releases of the bundles involved.
>> Best Regards
>> Ian
> 
> 

Re: Depending on Oak 1.7.x

[Stefan Egli]

Having said that, the only bullet to bite when switching to Oak 1.7.x is
increased maintenance effort: the affected bundles will become backwards
incompatible wrt Oak 1.6.x and if they need to be patched it would not be
possible to do so in trunk anymore.

Cheers,
Stefan

On 11/10/17 12:03, "Stefan Egli"  wrote:

>Hi Ian,
>
>I don't see a problem with having a dependency on an unstable Oak 1.7.x in
>Sling.
>
>Actual deployments can still, independent of this, make a call whether or
>not they want to actually run on Oak 1.7.x or wait for Oak 1.8 (which is
>advisable). IMO having this dependency doesn't imply on which version it
>will ultimately run.
>
>Cheers,
>Stefan
>
>On 11/10/17 11:54, "Ian Boston" i...@tfd.co.uk> wrote:
>
>>Hi,
>>Oak 1.7.x is Oak unstable release branch working towards 1.8.
>>I have a feature in SLING-7140 that is blocked by an API change in Oak
>>present in 1.8-SNAPSHOT and available as an unmerged but tested patch to
>>Oak 1.6.x.
>>
>>The Oak team are unwilling merge the patch to 1.6 and have asked that
>>Sling
>>depend on the latest release of Oak 1.7.
>>
>>How does the Sling team feel about this ?
>>
>>The patch for SLING-7140 cant be merged until the API is available in Oak
>>in some form and I don't want to depend on Oak 1.8-SNAPSHOT as this will
>>block Sling releases of the bundles involved.
>>Best Regards
>>Ian
>
>

Re: Depending on Oak 1.7.x

[Stefan Egli]

Hi Ian,

I don't see a problem with having a dependency on an unstable Oak 1.7.x in
Sling.

Actual deployments can still, independent of this, make a call whether or
not they want to actually run on Oak 1.7.x or wait for Oak 1.8 (which is
advisable). IMO having this dependency doesn't imply on which version it
will ultimately run.

Cheers,
Stefan

On 11/10/17 11:54, "Ian Boston"  wrote:

>Hi,
>Oak 1.7.x is Oak unstable release branch working towards 1.8.
>I have a feature in SLING-7140 that is blocked by an API change in Oak
>present in 1.8-SNAPSHOT and available as an unmerged but tested patch to
>Oak 1.6.x.
>
>The Oak team are unwilling merge the patch to 1.6 and have asked that
>Sling
>depend on the latest release of Oak 1.7.
>
>How does the Sling team feel about this ?
>
>The patch for SLING-7140 cant be merged until the API is available in Oak
>in some form and I don't want to depend on Oak 1.8-SNAPSHOT as this will
>block Sling releases of the bundles involved.
>Best Regards
>Ian

Depending on Oak 1.7.x

[Ian Boston]

Hi,
Oak 1.7.x is Oak unstable release branch working towards 1.8.
I have a feature in SLING-7140 that is blocked by an API change in Oak
present in 1.8-SNAPSHOT and available as an unmerged but tested patch to
Oak 1.6.x.

The Oak team are unwilling merge the patch to 1.6 and have asked that Sling
depend on the latest release of Oak 1.7.

How does the Sling team feel about this ?

The patch for SLING-7140 cant be merged until the API is available in Oak
in some form and I don't want to depend on Oak 1.8-SNAPSHOT as this will
block Sling releases of the bundles involved.
Best Regards
Ian

Sling build broken for me.

[Ian Boston]

Hi,
Could be me.
I do mvn clean install on a clean Sling checkout with a clean maven repo
and I get failiures to download slingfeature:9-SNAPSHOT required by an IT
test sample. This happens before the reactor starts.

If I fix that by using slingfeature:9 I then get 11 test failures in
commons.log related to the format of the logging output.

Is this just me ?

If it is just me, I can disable tests there to move on.

Best Regards
Ian