[jira] [Commented] (SLING-6543) slingstart-maven-plugin: Optionally make the start mojo blocking until the server is fully up and running

2017-04-13 Thread Andreas Schaefer (JIRA)

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

Andreas Schaefer commented on SLING-6543:
-

For now I use this a little bit obscure Maven Plugin to make sure Sling is 
ready to deploy a package through Composum:



org.sonatype.plugins
wait-maven-plugin
1.0

${http.host}
${http.port}
/bin/browser.html
1
10



pre-integration-test
pre-integration-test

wait





That said this is no ideal as I am not sure how stable that plugin is and it 
might not work in all scenarios.

> slingstart-maven-plugin: Optionally make the start mojo blocking until the 
> server is fully up and running
> -
>
> Key: SLING-6543
> URL: https://issues.apache.org/jira/browse/SLING-6543
> Project: Sling
>  Issue Type: Bug
>  Components: Tooling
>Affects Versions: Slingstart Maven Plugin 1.7.0
>Reporter: Konrad Windszus
>
> Right now the {{start}} goal will only start the server (in a dedicated 
> process) and then return when the control port returns that the server is 
> started. 
> That does not necessarily mean that all services from all bundles are already 
> fully started.
> It should be possible to block until the server is fully started and some 
> services are up and running. Otherwise follow-up processes (like 
> {{maven-failsafe-plugin}}) will need to implement some wait approach.
> One possibility is to issue repeated GET requests against the instance at a 
> dedicated URL until it reports a 200 (similar to what is done in 
> {{SlingTestBase.waitForServerReady(...)}} 
> (https://github.com/apache/sling/blob/trunk/testing/tools/src/main/java/org/apache/sling/testing/tools/sling/SlingTestBase.java#L263).
>  The list of URLs must be configurable.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SLING-6620) HTL integration tests do not honor locale format

2017-04-13 Thread Radu Cotescu (JIRA)

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

Radu Cotescu commented on SLING-6620:
-

Fixed in 
[r1791270|https://svn.apache.org/viewvc?view=revision=1791270].

> HTL integration tests do not honor locale format
> 
>
> Key: SLING-6620
> URL: https://issues.apache.org/jira/browse/SLING-6620
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
> Environment: user.country = US
> user.country.format = DE
> user.language = en
> user.language.format = de
>Reporter: Oliver Lietz
>Assignee: Radu Cotescu
>
> {noformat}
> Failed tests: 
>   TestBuilder$1.runTest:146 Expected value '01 December '18 12:00 AM; day in 
> year: 335; week in year: 49' for selector '#format-date-11'. Instead we got 
> '01 Dezember '18 12:00 AM; day in year: 335; week in year: 48'. Please check 
> the expected markup from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value 'December' for selector 
> '#format-date-3'. Instead we got 'Dezember'. Please check the expected markup 
> from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '1,000.00' for selector 
> '#format-number-6'. Instead we got '1.000,00'. Please check the expected 
> markup from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '-3.14' for selector 
> '#format-number-7'. Instead we got '-3,14'. Please check the expected markup 
> from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '(3.14)' for selector 
> '#format-number-8'. Instead we got '(3,14)'. Please check the expected markup 
> from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '-.314E01' for selector 
> '#format-number-9'. Instead we got '-,314E01'. Please check the expected 
> markup from /testfiles/output/exprlang/filters.html.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (SLING-6620) HTL integration tests do not honor locale format

2017-04-13 Thread Radu Cotescu (JIRA)

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

Radu Cotescu resolved SLING-6620.
-
Resolution: Fixed

> HTL integration tests do not honor locale format
> 
>
> Key: SLING-6620
> URL: https://issues.apache.org/jira/browse/SLING-6620
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
> Environment: user.country = US
> user.country.format = DE
> user.language = en
> user.language.format = de
>Reporter: Oliver Lietz
>Assignee: Radu Cotescu
>
> {noformat}
> Failed tests: 
>   TestBuilder$1.runTest:146 Expected value '01 December '18 12:00 AM; day in 
> year: 335; week in year: 49' for selector '#format-date-11'. Instead we got 
> '01 Dezember '18 12:00 AM; day in year: 335; week in year: 48'. Please check 
> the expected markup from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value 'December' for selector 
> '#format-date-3'. Instead we got 'Dezember'. Please check the expected markup 
> from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '1,000.00' for selector 
> '#format-number-6'. Instead we got '1.000,00'. Please check the expected 
> markup from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '-3.14' for selector 
> '#format-number-7'. Instead we got '-3,14'. Please check the expected markup 
> from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '(3.14)' for selector 
> '#format-number-8'. Instead we got '(3,14)'. Please check the expected markup 
> from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '-.314E01' for selector 
> '#format-number-9'. Instead we got '-,314E01'. Please check the expected 
> markup from /testfiles/output/exprlang/filters.html.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (SLING-6620) HTL integration tests do not honor locale format

2017-04-13 Thread Radu Cotescu (JIRA)

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

Radu Cotescu updated SLING-6620:

Fix Version/s: (was: Scripting HTL Engine 1.0.34)

> HTL integration tests do not honor locale format
> 
>
> Key: SLING-6620
> URL: https://issues.apache.org/jira/browse/SLING-6620
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
> Environment: user.country = US
> user.country.format = DE
> user.language = en
> user.language.format = de
>Reporter: Oliver Lietz
>Assignee: Radu Cotescu
>
> {noformat}
> Failed tests: 
>   TestBuilder$1.runTest:146 Expected value '01 December '18 12:00 AM; day in 
> year: 335; week in year: 49' for selector '#format-date-11'. Instead we got 
> '01 Dezember '18 12:00 AM; day in year: 335; week in year: 48'. Please check 
> the expected markup from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value 'December' for selector 
> '#format-date-3'. Instead we got 'Dezember'. Please check the expected markup 
> from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '1,000.00' for selector 
> '#format-number-6'. Instead we got '1.000,00'. Please check the expected 
> markup from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '-3.14' for selector 
> '#format-number-7'. Instead we got '-3,14'. Please check the expected markup 
> from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '(3.14)' for selector 
> '#format-number-8'. Instead we got '(3,14)'. Please check the expected markup 
> from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '-.314E01' for selector 
> '#format-number-9'. Instead we got '-,314E01'. Please check the expected 
> markup from /testfiles/output/exprlang/filters.html.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Closed] (SLING-6620) HTL integration tests do not honor locale format

2017-04-13 Thread Radu Cotescu (JIRA)

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

Radu Cotescu closed SLING-6620.
---

> HTL integration tests do not honor locale format
> 
>
> Key: SLING-6620
> URL: https://issues.apache.org/jira/browse/SLING-6620
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
> Environment: user.country = US
> user.country.format = DE
> user.language = en
> user.language.format = de
>Reporter: Oliver Lietz
>Assignee: Radu Cotescu
>
> {noformat}
> Failed tests: 
>   TestBuilder$1.runTest:146 Expected value '01 December '18 12:00 AM; day in 
> year: 335; week in year: 49' for selector '#format-date-11'. Instead we got 
> '01 Dezember '18 12:00 AM; day in year: 335; week in year: 48'. Please check 
> the expected markup from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value 'December' for selector 
> '#format-date-3'. Instead we got 'Dezember'. Please check the expected markup 
> from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '1,000.00' for selector 
> '#format-number-6'. Instead we got '1.000,00'. Please check the expected 
> markup from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '-3.14' for selector 
> '#format-number-7'. Instead we got '-3,14'. Please check the expected markup 
> from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '(3.14)' for selector 
> '#format-number-8'. Instead we got '(3,14)'. Please check the expected markup 
> from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '-.314E01' for selector 
> '#format-number-9'. Instead we got '-,314E01'. Please check the expected 
> markup from /testfiles/output/exprlang/filters.html.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (SLING-6620) HTL integration tests do not honor locale format

2017-04-13 Thread Radu Cotescu (JIRA)

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

Radu Cotescu updated SLING-6620:

Affects Version/s: (was: Scripting HTL Engine 1.0.32)

> HTL integration tests do not honor locale format
> 
>
> Key: SLING-6620
> URL: https://issues.apache.org/jira/browse/SLING-6620
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
> Environment: user.country = US
> user.country.format = DE
> user.language = en
> user.language.format = de
>Reporter: Oliver Lietz
>Assignee: Radu Cotescu
>
> {noformat}
> Failed tests: 
>   TestBuilder$1.runTest:146 Expected value '01 December '18 12:00 AM; day in 
> year: 335; week in year: 49' for selector '#format-date-11'. Instead we got 
> '01 Dezember '18 12:00 AM; day in year: 335; week in year: 48'. Please check 
> the expected markup from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value 'December' for selector 
> '#format-date-3'. Instead we got 'Dezember'. Please check the expected markup 
> from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '1,000.00' for selector 
> '#format-number-6'. Instead we got '1.000,00'. Please check the expected 
> markup from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '-3.14' for selector 
> '#format-number-7'. Instead we got '-3,14'. Please check the expected markup 
> from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '(3.14)' for selector 
> '#format-number-8'. Instead we got '(3,14)'. Please check the expected markup 
> from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '-.314E01' for selector 
> '#format-number-9'. Instead we got '-,314E01'. Please check the expected 
> markup from /testfiles/output/exprlang/filters.html.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Created] (SLING-6781) VltUtils only keep the last filter for a given path

2017-04-13 Thread Timothee Maret (JIRA)
Timothee Maret created SLING-6781:
-

 Summary: VltUtils only keep the last filter for a given path
 Key: SLING-6781
 URL: https://issues.apache.org/jira/browse/SLING-6781
 Project: Sling
  Issue Type: Bug
  Components: Content Distribution
Affects Versions: Content Distribution Core 0.2.6
Reporter: Timothee Maret
Assignee: Timothee Maret
 Fix For: Content Distribution Core 0.2.8


The utility method VltUtils#parseFilters [0] does not merge the definitions for 
the same path. As an example providing the filters

{code}
new String[]{"/home/users|-.*/.tokens","/home/users|-.*/.rep:cache"}
{code}
will return a tree map with only one entry ({{.*/.rep:cache}}) for the path 
{{/home/users}}).

[0] 
https://github.com/apache/sling/blob/trunk/contrib/extensions/distribution/core/src/main/java/org/apache/sling/distribution/serialization/impl/vlt/VltUtils.java#L305-L338
 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SLING-6744) [HTL] Introduction of data-sly-resolve

2017-04-13 Thread Radu Cotescu (JIRA)

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

Radu Cotescu commented on SLING-6744:
-

{{data-sly-resolve}}, the way you define it, is something Sling specific. 
However, the HTL's specification is designed in a way that's more or less Sling 
agnostic. Block elements are defined by the specification, and not by Apache 
sling.

> [HTL] Introduction of data-sly-resolve
> --
>
> Key: SLING-6744
> URL: https://issues.apache.org/jira/browse/SLING-6744
> Project: Sling
>  Issue Type: New Feature
>  Components: Scripting
>Reporter: Feike Visser
>
> We have functionality to resolve a resource via data-sly-use.
> The functionality is implemented to throw an exception when the resource does 
> not exist.
> With data-sly-resolve, you can resolve a resource. If the resource does not 
> exist a null gets assigned to the variable.
> This is the same as you would do with resolver.getResource()



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (SLING-6744) [HTL] Introduction of data-sly-resolve

2017-04-13 Thread Radu Cotescu (JIRA)

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

Radu Cotescu resolved SLING-6744.
-
Resolution: Invalid

> [HTL] Introduction of data-sly-resolve
> --
>
> Key: SLING-6744
> URL: https://issues.apache.org/jira/browse/SLING-6744
> Project: Sling
>  Issue Type: New Feature
>  Components: Scripting
>Reporter: Feike Visser
>
> We have functionality to resolve a resource via data-sly-use.
> The functionality is implemented to throw an exception when the resource does 
> not exist.
> With data-sly-resolve, you can resolve a resource. If the resource does not 
> exist a null gets assigned to the variable.
> This is the same as you would do with resolver.getResource()



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (SLING-6745) kafka-based sling.event.api implementation

2017-04-13 Thread Stefan Egli (JIRA)

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

Stefan Egli resolved SLING-6745.

Resolution: Won't Do

This will not be followed up further here, at the moment. Therefore marking as 
'wont do' for now. If this decision changes, we can always come back to this 
topic at a later point.

> kafka-based sling.event.api implementation
> --
>
> Key: SLING-6745
> URL: https://issues.apache.org/jira/browse/SLING-6745
> Project: Sling
>  Issue Type: New Feature
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> In job handling to scale for larger deployment it is essential to be able to 
> execute a job outside of the local instance. This can be in another instance 
> in the same cluster (ie when ontop of documentMk) or outside of the cluster 
> (in AEM eg via 
> [offloading|https://docs.adobe.com/docs/en/aem/6-2/deploy/configuring/offloading.html]).
>  In both cases Sling Event (Resource) stores the job in the repository 
> (/var/eventing/jobs).
> It could be useful to have another variant of job execution that is managed 
> entirely outside of the repository. With SLING-5645 a new API was created to 
> support messaging-based implementations that would fit in this category as 
> they map a job to a (one or a few) message(s). 
> This new SLING-5645 Job-API is not entirely compatible with sling.event.api 
> though.
> This ticket is to track an effort to provide a messaging-based implementation 
> for sling.event.api - namely for Kafka. The goal is to become a drop-in 
> replacement of sling event without much need for change on the user side of 
> the sling.event.api.
> This might not right away become part of sling, but might start off in the 
> contrib section - to underscore that it's not something supported, at least 
> as of yet.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SLING-6679) Replace usage of org.apache.sling.commons.json.* and org.json

2017-04-13 Thread Karl Pauls (JIRA)

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

Karl Pauls commented on SLING-6679:
---

IC, well, I agree with Carsten that it is in general better to make bundles as 
self-contained as possible and the Felix utils JSONWriter is much smaller so if 
we are talking embedding it is probably better to go with that one for the 
use-case he mentions (i.e., bundles that just produce json in a 
straight-forward way). 

> Replace usage of org.apache.sling.commons.json.* and org.json
> -
>
> Key: SLING-6679
> URL: https://issues.apache.org/jira/browse/SLING-6679
> Project: Sling
>  Issue Type: Improvement
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>
> Following the deprecation of org.apache.sling.commons.json (SLING-6536) we 
> need to replace its usage everywhere else (at least if we want to be able to 
> release other modules that depend on it). 
> This is the umbrella issue for getting this done. The idea is to create 
> sub-issues with patches for individual components, review the patches, and 
> when all are done: close this issue. 
> General discussions and problems should go to this issue and specific ones on 
> the sub-issue in question.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SLING-6679) Replace usage of org.apache.sling.commons.json.* and org.json

2017-04-13 Thread Radu Cotescu (JIRA)

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

Radu Cotescu commented on SLING-6679:
-

Well, I have no preference, but seeing the last few contradicting comments 
between Carsten and you I thought I should maybe suggest that code as a 
candidate for switching.

> Replace usage of org.apache.sling.commons.json.* and org.json
> -
>
> Key: SLING-6679
> URL: https://issues.apache.org/jira/browse/SLING-6679
> Project: Sling
>  Issue Type: Improvement
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>
> Following the deprecation of org.apache.sling.commons.json (SLING-6536) we 
> need to replace its usage everywhere else (at least if we want to be able to 
> release other modules that depend on it). 
> This is the umbrella issue for getting this done. The idea is to create 
> sub-issues with patches for individual components, review the patches, and 
> when all are done: close this issue. 
> General discussions and problems should go to this issue and specific ones on 
> the sub-issue in question.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SLING-6780) org.apache.sling.scripting.sightly.js.provider does not declare a version range for the org.mozilla.javascript import

2017-04-13 Thread Radu Cotescu (JIRA)

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

Radu Cotescu commented on SLING-6780:
-

Switched to depending on the {{org.apache.servicemix.bundles.rhino}} bundle, so 
that {{bnd}} defines the correct imports in 
[r1791227|https://svn.apache.org/r1791227].

> org.apache.sling.scripting.sightly.js.provider does not declare a version 
> range for the org.mozilla.javascript import
> -
>
> Key: SLING-6780
> URL: https://issues.apache.org/jira/browse/SLING-6780
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly JS Use Provider 1.0.10
>Reporter: Vlad Bailescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL JS Use Provider 1.0.22
>
>
> The {{org.apache.sling.scripting.sightly.js.provider}} bundle is not 
> declaring a version range for the {{org.mozilla.javascript}} import in its 
> manifest. This can become a problem when someone installs an incompatible 
> version. The solution is simple: make sure we declare a correct version range 
> for {{org.mozilla.javascript}} import.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SLING-6679) Replace usage of org.apache.sling.commons.json.* and org.json

2017-04-13 Thread Karl Pauls (JIRA)

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

Karl Pauls commented on SLING-6679:
---

[~radu.cotescu], you can if you think it is better but personally, I don't 
think that is needed. Its already using the Felix JSONWriter and that is fine 
for simple usecases like this. 

> Replace usage of org.apache.sling.commons.json.* and org.json
> -
>
> Key: SLING-6679
> URL: https://issues.apache.org/jira/browse/SLING-6679
> Project: Sling
>  Issue Type: Improvement
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>
> Following the deprecation of org.apache.sling.commons.json (SLING-6536) we 
> need to replace its usage everywhere else (at least if we want to be able to 
> release other modules that depend on it). 
> This is the umbrella issue for getting this done. The idea is to create 
> sub-issues with patches for individual components, review the patches, and 
> when all are done: close this issue. 
> General discussions and problems should go to this issue and specific ones on 
> the sub-issue in question.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SLING-6780) org.apache.sling.scripting.sightly.js.provider does not declare a version range for the org.mozilla.javascript import

2017-04-13 Thread Konrad Windszus (JIRA)

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

Konrad Windszus commented on SLING-6780:


As written in https://github.com/apache/sling/pull/213#discussion_r111349248 I 
don't agree with the import range. This should IMHO be [1.7,2) and I would 
prefer to automatically generate through bnd, by exchanging the dependency 
Rhino in 
https://github.com/vladbailescu/sling/blob/0ec63ac17191b8b2ad839924d39c11e32435192e/bundles/scripting/sightly/js-use-provider/pom.xml#L174
 with the service mix bundle (added in SLING-6668). 

> org.apache.sling.scripting.sightly.js.provider does not declare a version 
> range for the org.mozilla.javascript import
> -
>
> Key: SLING-6780
> URL: https://issues.apache.org/jira/browse/SLING-6780
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly JS Use Provider 1.0.10
>Reporter: Vlad Bailescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL JS Use Provider 1.0.22
>
>
> The {{org.apache.sling.scripting.sightly.js.provider}} bundle is not 
> declaring a version range for the {{org.mozilla.javascript}} import in its 
> manifest. This can become a problem when someone installs an incompatible 
> version. The solution is simple: make sure we declare a correct version range 
> for {{org.mozilla.javascript}} import.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SLING-6780) org.apache.sling.scripting.sightly.js.provider does not declare a version range for the org.mozilla.javascript import

2017-04-13 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on SLING-6780:
---

Github user vladbailescu closed the pull request at:

https://github.com/apache/sling/pull/213


> org.apache.sling.scripting.sightly.js.provider does not declare a version 
> range for the org.mozilla.javascript import
> -
>
> Key: SLING-6780
> URL: https://issues.apache.org/jira/browse/SLING-6780
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly JS Use Provider 1.0.10
>Reporter: Vlad Bailescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL JS Use Provider 1.0.22
>
>
> The {{org.apache.sling.scripting.sightly.js.provider}} bundle is not 
> declaring a version range for the {{org.mozilla.javascript}} import in its 
> manifest. This can become a problem when someone installs an incompatible 
> version. The solution is simple: make sure we declare a correct version range 
> for {{org.mozilla.javascript}} import.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[GitHub] sling pull request #213: SLING-6780 - org.apache.sling.scripting.sightly.js....

2017-04-13 Thread vladbailescu
Github user vladbailescu closed the pull request at:

https://github.com/apache/sling/pull/213


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---


[jira] [Resolved] (SLING-6780) org.apache.sling.scripting.sightly.js.provider does not declare a version range for the org.mozilla.javascript import

2017-04-13 Thread Radu Cotescu (JIRA)

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

Radu Cotescu resolved SLING-6780.
-
Resolution: Fixed

Fixed in [r1791224|https://svn.apache.org/r1791224].

> org.apache.sling.scripting.sightly.js.provider does not declare a version 
> range for the org.mozilla.javascript import
> -
>
> Key: SLING-6780
> URL: https://issues.apache.org/jira/browse/SLING-6780
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly JS Use Provider 1.0.10
>Reporter: Vlad Bailescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL JS Use Provider 1.0.22
>
>
> The {{org.apache.sling.scripting.sightly.js.provider}} bundle is not 
> declaring a version range for the {{org.mozilla.javascript}} import in its 
> manifest. This can become a problem when someone installs an incompatible 
> version. The solution is simple: make sure we declare a correct version range 
> for {{org.mozilla.javascript}} import.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SLING-6679) Replace usage of org.apache.sling.commons.json.* and org.json

2017-04-13 Thread Radu Cotescu (JIRA)

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

Radu Cotescu commented on SLING-6679:
-

[~karlpauls], should we also change this code to use {{javax.json}}? - 
https://github.com/apache/sling/blob/trunk/bundles/scripting/core/src/main/java/org/apache/sling/scripting/core/impl/SlingBindingsVariablesListJsonServlet.java#L94

> Replace usage of org.apache.sling.commons.json.* and org.json
> -
>
> Key: SLING-6679
> URL: https://issues.apache.org/jira/browse/SLING-6679
> Project: Sling
>  Issue Type: Improvement
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>
> Following the deprecation of org.apache.sling.commons.json (SLING-6536) we 
> need to replace its usage everywhere else (at least if we want to be able to 
> release other modules that depend on it). 
> This is the umbrella issue for getting this done. The idea is to create 
> sub-issues with patches for individual components, review the patches, and 
> when all are done: close this issue. 
> General discussions and problems should go to this issue and specific ones on 
> the sub-issue in question.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (SLING-6620) HTL integration tests do not honor locale format

2017-04-13 Thread Radu Cotescu (JIRA)

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

Radu Cotescu updated SLING-6620:

Affects Version/s: Scripting HTL Engine 1.0.32

> HTL integration tests do not honor locale format
> 
>
> Key: SLING-6620
> URL: https://issues.apache.org/jira/browse/SLING-6620
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting HTL Engine 1.0.32
> Environment: user.country = US
> user.country.format = DE
> user.language = en
> user.language.format = de
>Reporter: Oliver Lietz
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Engine 1.0.34
>
>
> {noformat}
> Failed tests: 
>   TestBuilder$1.runTest:146 Expected value '01 December '18 12:00 AM; day in 
> year: 335; week in year: 49' for selector '#format-date-11'. Instead we got 
> '01 Dezember '18 12:00 AM; day in year: 335; week in year: 48'. Please check 
> the expected markup from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value 'December' for selector 
> '#format-date-3'. Instead we got 'Dezember'. Please check the expected markup 
> from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '1,000.00' for selector 
> '#format-number-6'. Instead we got '1.000,00'. Please check the expected 
> markup from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '-3.14' for selector 
> '#format-number-7'. Instead we got '-3,14'. Please check the expected markup 
> from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '(3.14)' for selector 
> '#format-number-8'. Instead we got '(3,14)'. Please check the expected markup 
> from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '-.314E01' for selector 
> '#format-number-9'. Instead we got '-,314E01'. Please check the expected 
> markup from /testfiles/output/exprlang/filters.html.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (SLING-6620) HTL integration tests do not honor locale format

2017-04-13 Thread Radu Cotescu (JIRA)

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

Radu Cotescu updated SLING-6620:

Fix Version/s: Scripting HTL Engine 1.0.34

> HTL integration tests do not honor locale format
> 
>
> Key: SLING-6620
> URL: https://issues.apache.org/jira/browse/SLING-6620
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting HTL Engine 1.0.32
> Environment: user.country = US
> user.country.format = DE
> user.language = en
> user.language.format = de
>Reporter: Oliver Lietz
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Engine 1.0.34
>
>
> {noformat}
> Failed tests: 
>   TestBuilder$1.runTest:146 Expected value '01 December '18 12:00 AM; day in 
> year: 335; week in year: 49' for selector '#format-date-11'. Instead we got 
> '01 Dezember '18 12:00 AM; day in year: 335; week in year: 48'. Please check 
> the expected markup from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value 'December' for selector 
> '#format-date-3'. Instead we got 'Dezember'. Please check the expected markup 
> from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '1,000.00' for selector 
> '#format-number-6'. Instead we got '1.000,00'. Please check the expected 
> markup from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '-3.14' for selector 
> '#format-number-7'. Instead we got '-3,14'. Please check the expected markup 
> from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '(3.14)' for selector 
> '#format-number-8'. Instead we got '(3,14)'. Please check the expected markup 
> from /testfiles/output/exprlang/filters.html.
>   TestBuilder$1.runTest:146 Expected value '-.314E01' for selector 
> '#format-number-9'. Instead we got '-,314E01'. Please check the expected 
> markup from /testfiles/output/exprlang/filters.html.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Reopened] (SLING-6658) Register models with their implType implicitly

2017-04-13 Thread Konrad Windszus (JIRA)

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

Konrad Windszus reopened SLING-6658:


Also adjusted the javadoc of the {{Model}} annotation in 
[r1791221|http://svn.apache.org/r1791221].

> Register models with their implType implicitly
> --
>
> Key: SLING-6658
> URL: https://issues.apache.org/jira/browse/SLING-6658
> Project: Sling
>  Issue Type: Improvement
>Reporter: Dirk Rudolph
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: Sling Models API 1.3.4, Sling Models Impl 1.3.10
>
> Attachments: models.mdtext.patch
>
>
> As discussed in SLING-6652, the implementation of the {{@Exporter}} feature 
> introduced a undocumented assumption of the order of the adapterTypes. 
> This ticket is about always registering any {{@Model}} implicitly with its 
> {{implType}}, if not specified explicitly. This will allow the ExportServlet 
> to always use the {{implType}} while creating the {{@Model}} its going to 
> export.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (SLING-6658) Register models with their implType implicitly

2017-04-13 Thread Konrad Windszus (JIRA)

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

Konrad Windszus resolved SLING-6658.

Resolution: Fixed

> Register models with their implType implicitly
> --
>
> Key: SLING-6658
> URL: https://issues.apache.org/jira/browse/SLING-6658
> Project: Sling
>  Issue Type: Improvement
>Reporter: Dirk Rudolph
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: Sling Models API 1.3.4, Sling Models Impl 1.3.10
>
> Attachments: models.mdtext.patch
>
>
> As discussed in SLING-6652, the implementation of the {{@Exporter}} feature 
> introduced a undocumented assumption of the order of the adapterTypes. 
> This ticket is about always registering any {{@Model}} implicitly with its 
> {{implType}}, if not specified explicitly. This will allow the ExportServlet 
> to always use the {{implType}} while creating the {{@Model}} its going to 
> export.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (SLING-6658) Register models with their implType implicitly

2017-04-13 Thread Konrad Windszus (JIRA)

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

Konrad Windszus updated SLING-6658:
---
Fix Version/s: Sling Models API 1.3.4

> Register models with their implType implicitly
> --
>
> Key: SLING-6658
> URL: https://issues.apache.org/jira/browse/SLING-6658
> Project: Sling
>  Issue Type: Improvement
>Reporter: Dirk Rudolph
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: Sling Models API 1.3.4, Sling Models Impl 1.3.10
>
> Attachments: models.mdtext.patch
>
>
> As discussed in SLING-6652, the implementation of the {{@Exporter}} feature 
> introduced a undocumented assumption of the order of the adapterTypes. 
> This ticket is about always registering any {{@Model}} implicitly with its 
> {{implType}}, if not specified explicitly. This will allow the ExportServlet 
> to always use the {{implType}} while creating the {{@Model}} its going to 
> export.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Assigned] (SLING-6658) Register models with their implType implicitly

2017-04-13 Thread Konrad Windszus (JIRA)

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

Konrad Windszus reassigned SLING-6658:
--

Assignee: Konrad Windszus  (was: Justin Edelson)

> Register models with their implType implicitly
> --
>
> Key: SLING-6658
> URL: https://issues.apache.org/jira/browse/SLING-6658
> Project: Sling
>  Issue Type: Improvement
>Reporter: Dirk Rudolph
>Assignee: Konrad Windszus
>Priority: Minor
> Fix For: Sling Models Impl 1.3.10
>
> Attachments: models.mdtext.patch
>
>
> As discussed in SLING-6652, the implementation of the {{@Exporter}} feature 
> introduced a undocumented assumption of the order of the adapterTypes. 
> This ticket is about always registering any {{@Model}} implicitly with its 
> {{implType}}, if not specified explicitly. This will allow the ExportServlet 
> to always use the {{implType}} while creating the {{@Model}} its going to 
> export.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Commented] (SLING-6780) org.apache.sling.scripting.sightly.js.provider does not declare a version range for the org.mozilla.javascript import

2017-04-13 Thread Vlad Bailescu (JIRA)

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

Vlad Bailescu commented on SLING-6780:
--

[~olli], thanks for your input. Already discussed with [~radu.cotescu] and 
agreed we should add the version range manually and not rely on the dependency, 
please see the updated PR: https://github.com/apache/sling/pull/213

> org.apache.sling.scripting.sightly.js.provider does not declare a version 
> range for the org.mozilla.javascript import
> -
>
> Key: SLING-6780
> URL: https://issues.apache.org/jira/browse/SLING-6780
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly JS Use Provider 1.0.10
>Reporter: Vlad Bailescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL JS Use Provider 1.0.22
>
>
> The {{org.apache.sling.scripting.sightly.js.provider}} bundle is not 
> declaring a version range for the {{org.mozilla.javascript}} import in its 
> manifest. This can become a problem when someone installs an incompatible 
> version. The solution is simple: make sure we declare a correct version range 
> for {{org.mozilla.javascript}} import.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Updated] (SLING-6780) org.apache.sling.scripting.sightly.js.provider does not declare a version range for the org.mozilla.javascript import

2017-04-13 Thread Vlad Bailescu (JIRA)

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

Vlad Bailescu updated SLING-6780:
-
Description: The {{org.apache.sling.scripting.sightly.js.provider}} bundle 
is not declaring a version range for the {{org.mozilla.javascript}} import in 
its manifest. This can become a problem when someone installs an incompatible 
version. The solution is simple: make sure we declare a correct version range 
for {{org.mozilla.javascript}} import.  (was: The 
{{org.apache.sling.scripting.sightly.js.provider}} bundle is not declaring a 
version range for the {{org.mozilla.javascript}} import in its manifest. This 
can become a problem when someone installs an incompatible version. The 
solution is simple: declare an explicit dependency on 
{{org.apache.sling.scripting.javascript}} so that the bundle plugin can pick up 
the correct version range.)

> org.apache.sling.scripting.sightly.js.provider does not declare a version 
> range for the org.mozilla.javascript import
> -
>
> Key: SLING-6780
> URL: https://issues.apache.org/jira/browse/SLING-6780
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly JS Use Provider 1.0.10
>Reporter: Vlad Bailescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL JS Use Provider 1.0.22
>
>
> The {{org.apache.sling.scripting.sightly.js.provider}} bundle is not 
> declaring a version range for the {{org.mozilla.javascript}} import in its 
> manifest. This can become a problem when someone installs an incompatible 
> version. The solution is simple: make sure we declare a correct version range 
> for {{org.mozilla.javascript}} import.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)


[jira] [Resolved] (SLING-4637) Provide Validation feature

2017-04-13 Thread Oliver Lietz (JIRA)

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

Oliver Lietz resolved SLING-4637.
-
   Resolution: Done
Fix Version/s: Karaf repoinit 0.2.2
   Karaf Configs 0.2.0
   Karaf Distribution 0.2.0

[r1791216|https://svn.apache.org/r1791216]

> Provide Validation feature
> --
>
> Key: SLING-4637
> URL: https://issues.apache.org/jira/browse/SLING-4637
> Project: Sling
>  Issue Type: New Feature
>  Components: Karaf
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Karaf Features 0.2.0, Karaf Integration Tests 0.2.0, 
> Karaf Distribution 0.2.0, Karaf Configs 0.2.0, Karaf repoinit 0.2.2
>
>
> {{sling-extension-validation}}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)