Re: Jenkins build is still unstable: sling-launchpad-testing-1.8 #1439

[Carsten Ziegeler]

It seems to be a problem with Sling's junit integration:
see https://issues.apache.org/jira/browse/SLING-6750

Apache Jenkins Server wrote
> See 
> 
> 
> 


 

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

[jira] [Created] (SLING-6750) NPE with TestContextRunListenerWrapper in WriteableResourcesTest

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-6750:
---

 Summary: NPE with TestContextRunListenerWrapper in 
WriteableResourcesTest
 Key: SLING-6750
 URL: https://issues.apache.org/jira/browse/SLING-6750
 Project: Sling
  Issue Type: Bug
  Components: Launchpad, Testing
Reporter: Carsten Ziegeler
Priority: Blocker


There is an NPE in the WriteableResourcesTest. It seems the field 
ResourceResolverFactory is not initialized when the test starts.

0.03.2017 07:06:38.015 *WARN* [qtp1706723350-50] 
org.apache.sling.junit.impl.TestContextRunListenerWrapper JUnit test execution 
failed: 
testSimpleCRUD(org.apache.sling.launchpad.testservices.serversidetests.WriteableResourcesTest):
 null
java.lang.NullPointerException: null
at 
org.apache.sling.launchpad.testservices.serversidetests.WriteableResourcesTest.setup(WriteableResourcesTest.java:57)




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

[jira] [Resolved] (SLING-6748) Move ValuePreparer to the models API package

[Justin Edelson (JIRA)]

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

Justin Edelson resolved SLING-6748.
---
Resolution: Fixed

moved in r1789419

> Move ValuePreparer to the models API package
> 
>
> Key: SLING-6748
> URL: https://issues.apache.org/jira/browse/SLING-6748
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models API 1.3.2
>Reporter: Burkhard Pauli
>Assignee: Justin Edelson
> Fix For: Sling Models API 1.3.4, Sling Models Impl 1.3.10
>
>
> In SLING-6318 the internal ValuePreparer interface was added to improve the 
> injection performance. 
> To also allow external injectors to benefit from this improvement, the 
> internal interface should be moved to the public API package.



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

[jira] [Updated] (SLING-6748) Move ValuePreparer to the models API package

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-6748:
--
Fix Version/s: Sling Models Impl 1.3.10
   Sling Models API 1.3.4

> Move ValuePreparer to the models API package
> 
>
> Key: SLING-6748
> URL: https://issues.apache.org/jira/browse/SLING-6748
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models API 1.3.2
>Reporter: Burkhard Pauli
>Assignee: Justin Edelson
> Fix For: Sling Models API 1.3.4, Sling Models Impl 1.3.10
>
>
> In SLING-6318 the internal ValuePreparer interface was added to improve the 
> injection performance. 
> To also allow external injectors to benefit from this improvement, the 
> internal interface should be moved to the public API package.



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

[jira] [Assigned] (SLING-6748) Move ValuePreparer to the models API package

[Justin Edelson (JIRA)]

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

Justin Edelson reassigned SLING-6748:
-

Assignee: Justin Edelson

> Move ValuePreparer to the models API package
> 
>
> Key: SLING-6748
> URL: https://issues.apache.org/jira/browse/SLING-6748
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models API 1.3.2
>Reporter: Burkhard Pauli
>Assignee: Justin Edelson
> Fix For: Sling Models API 1.3.4, Sling Models Impl 1.3.10
>
>
> In SLING-6318 the internal ValuePreparer interface was added to improve the 
> injection performance. 
> To also allow external injectors to benefit from this improvement, the 
> internal interface should be moved to the public API package.



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

[jira] [Created] (SLING-6749) Expose Sightly Filter Class

[Michael Hodgdon (JIRA)]

Michael Hodgdon created SLING-6749:
--

 Summary: Expose Sightly Filter Class
 Key: SLING-6749
 URL: https://issues.apache.org/jira/browse/SLING-6749
 Project: Sling
  Issue Type: Improvement
Affects Versions: Scripting Sightly Engine 1.0.18
Reporter: Michael Hodgdon


Move org.apache.sling.scripting.sightly.impl.filter.Filter out of the impl 
package and export it in the osgi bundle, so that filters can be registered in 
other bundles.



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

[jira] [Created] (SLING-6748) Move ValuePreparer to the models API package

[Burkhard Pauli (JIRA)]

Burkhard Pauli created SLING-6748:
-

 Summary: Move ValuePreparer to the models API package
 Key: SLING-6748
 URL: https://issues.apache.org/jira/browse/SLING-6748
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Sling Models API 1.3.2
Reporter: Burkhard Pauli


In SLING-6318 the internal ValuePreparer interface was added to improve the 
injection performance. 

To also allow external injectors to benefit from this improvement, the internal 
interface should be moved to the public API package.



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

[jira] [Comment Edited] (SLING-6747) User Manager: Support setting nested user properties

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-6747 at 3/29/17 4:25 PM:
-

The reason for that limitation is that {{RequestProperty.getName()}} is used 
everywhere in 
https://github.com/apache/sling/blob/trunk/bundles/jcr/jackrabbit-usermanager/src/main/java/org/apache/sling/jackrabbit/usermanager/impl/post/AbstractAuthorizablePostServlet.java#L318
 instead of {{RequestProperty.getPath()}}. In addition there is an explicit 
check for nested property names in 
https://github.com/apache/sling/blob/trunk/bundles/jcr/jackrabbit-usermanager/src/main/java/org/apache/sling/jackrabbit/usermanager/impl/post/AbstractAuthorizablePostServlet.java#L115
 which skips all those parameters.


was (Author: kwin):
The reason for that limitation is that {{RequestProperty.getName()}} is used 
everywhere in 
https://github.com/apache/sling/blob/trunk/bundles/jcr/jackrabbit-usermanager/src/main/java/org/apache/sling/jackrabbit/usermanager/impl/post/AbstractAuthorizablePostServlet.java#L318
 instead of {{RequestProperty.getPath()}}.

> User Manager: Support setting nested user properties
> 
>
> Key: SLING-6747
> URL: https://issues.apache.org/jira/browse/SLING-6747
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR Jackrabbit User Manager 2.2.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> Currently if a property like {{preferences/myproperty}} is set to any value 
> through the POST request to e.g. /system/userManager/user/admin.update.html 
> the according property is not correctly set, but the response does also not 
> indicate any error.



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

[jira] [Commented] (SLING-6747) User Manager: Support setting nested user properties

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6747:


The reason for that limitation is that {{RequestProperty.getName()}} is used 
everywhere in 
https://github.com/apache/sling/blob/trunk/bundles/jcr/jackrabbit-usermanager/src/main/java/org/apache/sling/jackrabbit/usermanager/impl/post/AbstractAuthorizablePostServlet.java#L318
 instead of {{RequestProperty.getPath()}}.

> User Manager: Support setting nested user properties
> 
>
> Key: SLING-6747
> URL: https://issues.apache.org/jira/browse/SLING-6747
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR Jackrabbit User Manager 2.2.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>
> Currently if a property like {{preferences/myproperty}} is set to any value 
> through the POST request to e.g. /system/userManager/user/admin.update.html 
> the according property is not correctly set, but the response does also not 
> indicate any error.



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

[jira] [Created] (SLING-6747) User Manager: Support setting nested user properties

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-6747:
--

 Summary: User Manager: Support setting nested user properties
 Key: SLING-6747
 URL: https://issues.apache.org/jira/browse/SLING-6747
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Affects Versions: JCR Jackrabbit User Manager 2.2.4
Reporter: Konrad Windszus
Assignee: Konrad Windszus


Currently if a property like {{preferences/myproperty}} is set to any value 
through the POST request to e.g. /system/userManager/user/admin.update.html the 
according property is not correctly set, but the response does also not 
indicate any error.



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

[jira] [Resolved] (SLING-4547) JcrResourceBundle does not support multiple base names

[Konrad Windszus (JIRA)]

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

Konrad Windszus resolved SLING-4547.

Resolution: Fixed

> JcrResourceBundle does not support multiple base names
> --
>
> Key: SLING-4547
> URL: https://issues.apache.org/jira/browse/SLING-4547
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Affects Versions: i18n 2.5.8
>Reporter: Andrei Pilets
>Assignee: Konrad Windszus
> Fix For: i18n 2.5.10
>
>
> The sling:basename property may be multi-valued, that is the messages of a 
> mix:language nodes may belong to multiple base names and thus ResourceBundle 
> instances, as stated at 
> https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html.
>  
> The latest codebase does not work in that way.
> JcrResourceBundle#loadPotentialLanguageRoots():
> if (baseName == null || baseName.equals(properties.get(PROP_BASENAME, ""))) {
>  paths.add(bundle.getPath());
> }
> In case if property sling:basename have multiple values, only the first base 
> name is considered, others are skipped.
> The correct implementation would be to use properties.get(PROP_BASENAME) - 
> method version without default value parameter, which would return array. You 
> would need to iterate over its items and check equality.



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

[jira] [Updated] (SLING-517) Improve i18n node types

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-517:
--
Component/s: i18n

> Improve i18n node types
> ---
>
> Key: SLING-517
> URL: https://issues.apache.org/jira/browse/SLING-517
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, i18n
>Affects Versions: I18n 2.0.2
>Reporter: Alexander Klimetschek
>Assignee: Carsten Ziegeler
> Fix For: I18n 2.0.2
>
>
> As discussed on the mailing list 
> http://markmail.org/message/dobbllzzimgtwssg, the current node types in the 
> i18n bundle should be improved regarding naming and a more efficient and 
> human-readable content structure.
> 1) Rename node type "sling:Language" to "sling:MessageBundle", because it is 
> a container for messages, not a language.
> 2) "sling:MessageBundle" only contains "sling:Message"s - we don't want to 
> mix it with other content if this structure is typically auto-generated (eg. 
> XLIFF importer)
> 3) "sling:MessageBundle" extends nt:hierarchyNode to be able to place it 
> inside a nt:folder.
> 4) "sling:Message" can be a node type, I don't see the case where one wants 
> to mix it with an existing node type structure and needs a mixin. 
> "sling:MessageEntry" can be removed then.
> 5) "sling:Message" does not need to inherit from nt:hierarchyNode anymore (it 
> will only be use inside sling:MessageBundle, which can be put into an 
> nt:folder)
> 6) The sling:key should be optional and only be used if the actual key (which 
> would typically be the original, eg. english, source string) is not a valid 
> JCR name. Otherwise the node name should be the key (no need for generating 
> message1, message2, etc.)
> 7) If the key is not valid for the jcr name, we generate a valid name based 
> on the key, to make the node structure more browsable.
> Here is a pseudo algorithm for generating the key:
>   input: node name
>   esc = cut off 50 char from key
>   esc = escape esc (using 
> org.apache.jackrabbit.util.Text.escapeIllegalJcrChars())
>   if escaped == original key => put in node name
>   else => put in sling:key property, use
>   ensure unique name! append number
> 8) JcrResourceBundle must be changed that it always loads all entries from 
> the sling:MessageBundle into a hashmap (as it does now already if one calls 
> ResourceBundle.getKeys()). This way it knows the correct keys which are 
> either in the node name or in the sling:key property because it loads them 
> properly upon intial loading. The single key query that is done in 
> ResourceBundle.handleGetObject() will be changed to access the hashmap only.
> The latter change should improve performance due to in-memory caching, albeit 
> the first call to getObject() or getString() will be a bit slower.
> New node types
> =
> [sling:MessageBundle] > nt:hierarchyNode, mix:language
>   - basename (string)
>   + * (sling:Message)
> [sling:Message] > nt:base
>  - sling:key (string)
>  - sling:message (undefined)
> Example (new) node tree
> 
> /libs/languages
>+ Deutsch (sling:MessageBundle)
> - jcr:language = de-ch
> + Ok (sling:Message)
>  - sling:message = "'sch Ok"
> + Lorem_Ipsum_001 (sling:Message)
>  - sling:key = "Lorem Ipsum is simply [...]"
>  - sling:message = "Mir doch egal."



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

[jira] [Updated] (SLING-5741) discarding complete ResourceBundleCache in case of JSON dictionary

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5741:
---
Component/s: i18n

> discarding complete ResourceBundleCache in case of JSON dictionary
> --
>
> Key: SLING-5741
> URL: https://issues.apache.org/jira/browse/SLING-5741
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions, i18n
>Affects Versions: i18n 2.4.6
>Reporter: Ankit Agarwal
>
> In case user is using JSON dictionary then condition mentioned here 
> https://github.com/apache/sling/blob/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java#L198
> will becomes true for any change in languagerootpaths which are cached. And 
> this will discard complete resource bundle cache. which is different if user 
> is using sling:Message dictionary.
> for example user has json dictionary at path  
> "/libs/test/i18n/de.json"
> and also resource bundle for language "de" is cached so , 
> "libs/test/i18n/de.json" will be in languageRootPaths.
> So any change at "/libs/test/i18n/de.json" will discard complete 
> resourcebundleCache.
> Where as in case of  sling:dictionary 
> languageRootPath will be like "/libs/test/i18n/de" 
> and any change in this dictionary will have path like this 
> "/libs/test/i18n/de/testMessage" so condition becomes false and complete 
> resourcebundleCache. will not be discarded.
> Can we improve this, like if condition becomes true, than check among the 
> cached resourceBundle to which resourceBundle this path belongs to and than 
> discarding that resourceBundle. and if this resourceBundle is parent of any 
> ResourceBundle then discard that too. 



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

[jira] [Updated] (SLING-5708) discarding ResourceBundle of all locale

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5708:
---
Component/s: i18n

> discarding ResourceBundle of all locale
> ---
>
> Key: SLING-5708
> URL: https://issues.apache.org/jira/browse/SLING-5708
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, i18n
>Affects Versions: i18n 2.4.6
>Reporter: Ankit Agarwal
>
> After fix for SLING-4795 was included. 
> Only ResourceBundle of locale which has been changed will be discarded. 
> But this works this way only if, ResourceBundle of locale which has been 
> changed is already available in ResourceBundle cache.
> If ResourceBundle cache does not have ResourceBundle of locale which has been 
> has been , Complete Cache is discarded. Is this a correct behaviour ? 



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

[jira] [Updated] (SLING-2536) JcrResourceBundle breaks the contract of getLocale

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-2536:
---
Component/s: i18n

> JcrResourceBundle breaks the contract of getLocale
> --
>
> Key: SLING-2536
> URL: https://issues.apache.org/jira/browse/SLING-2536
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions, i18n
>Affects Versions: i18n 2.2.2
>Reporter: Endolf
>
> The javadoc for getLocale state that it should return the locale of this 
> bundle or the locale of the fallback. Currently JcrResourceBundle always 
> returns the requested locale even if there is no mix:language for that locale.
> e.g. Only a mix:language with a jcr:language en is in the jcr, a request for 
> a resource bundle of sv will return a ResourceBundle object where getLocale 
> returns sv. This should return en according to the javadoc.



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

[jira] [Updated] (SLING-6382) JcrResourceBundle.getBaseBundleName() always returns null

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6382:
---
Component/s: i18n

> JcrResourceBundle.getBaseBundleName() always returns null
> -
>
> Key: SLING-6382
> URL: https://issues.apache.org/jira/browse/SLING-6382
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions, i18n
>Affects Versions: i18n 2.5.4
>Reporter: Konrad Windszus
>Priority: Minor
>
> The method {{getBaseBundleName}} being added with Java8 to {{ResourceBundle}} 
> (https://docs.oracle.com/javase/8/docs/api/java/util/ResourceBundle.html#getBaseBundleName--)
>  always returns {{null}} for {{JcrResourceBundles}}. The reason for that is 
> that the private field {{name}} inside {{ResourceBundle}} only gets set if 
> {{loadBundle(CacheKey cacheKey, List formats,Control control,boolean 
> reload)}} gets called.



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

[jira] [Updated] (SLING-4944) JcrResourceBundleProvider: Potential race condition between setting the resourceResolver and using it

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-4944:
---
Component/s: i18n

> JcrResourceBundleProvider: Potential race condition between setting the 
> resourceResolver and using it
> -
>
> Key: SLING-4944
> URL: https://issues.apache.org/jira/browse/SLING-4944
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions, i18n
>Affects Versions: i18n 2.4.4
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: i18n 2.4.6
>
>
> After fixing SLING-4910 there is still a very slim chance that the resource 
> resolver is being null while being used within the scheduleReloadBundles, 
> because that is called, before the resolver is initialized. The chance to see 
> that in reality is close to zero though, because scheduleReloadBundles is 
> using the resource resolver only in a scheduled thread.



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

[jira] [Updated] (SLING-5816) Support both lower and upper case language and country code

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-5816:
---
Component/s: i18n

> Support both lower and upper case language and country code
> ---
>
> Key: SLING-5816
> URL: https://issues.apache.org/jira/browse/SLING-5816
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Affects Versions: i18n 2.4.6
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: i18n 2.4.8
>
>
> As specified in 
> http://sling.apache.org/documentation/bundles/internationalization-support-i18n.html
>  both lower and uppercase language and country codes should be supported.



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

[jira] [Commented] (SLING-4547) JcrResourceBundle does not support multiple base names

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-4547:


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

> JcrResourceBundle does not support multiple base names
> --
>
> Key: SLING-4547
> URL: https://issues.apache.org/jira/browse/SLING-4547
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Affects Versions: i18n 2.5.8
>Reporter: Andrei Pilets
>Assignee: Konrad Windszus
> Fix For: i18n 2.5.10
>
>
> The sling:basename property may be multi-valued, that is the messages of a 
> mix:language nodes may belong to multiple base names and thus ResourceBundle 
> instances, as stated at 
> https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html.
>  
> The latest codebase does not work in that way.
> JcrResourceBundle#loadPotentialLanguageRoots():
> if (baseName == null || baseName.equals(properties.get(PROP_BASENAME, ""))) {
>  paths.add(bundle.getPath());
> }
> In case if property sling:basename have multiple values, only the first base 
> name is considered, others are skipped.
> The correct implementation would be to use properties.get(PROP_BASENAME) - 
> method version without default value parameter, which would return array. You 
> would need to iterate over its items and check equality.



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

RE: [VOTE] Release Apache Sling File System Resource Provider 2.0.0, File System Resource Provider 1.3.0

[Stefan Seifert]

>On Wednesday 29 March 2017 12:51:59 Stefan Seifert wrote:
>> >> +1 (depends now on Jackrabbit, would prefer embedding
>> >> org.apache.jackrabbit.util.ISO8601 like we do in other bundles, e.g.
>> >
>> >event)
>> >
>> >After having a closer look, I don't think it's worth the effort as there
>> >are
>> >more new dependencies (JCR, Vault, Guava).
>>
>> there is no dependency on guava (only test dependency via sling-mock).
>
>Guava is a transitive dependency of Jackrabbit.

ah, ok - thanks for clarification. than we have to live with it for now.
we might try to optimize this in further release to embed what is easy possible.

stefan

[jira] [Updated] (SLING-4547) JcrResourceBundle does not support multiple base names

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-4547:
---
Fix Version/s: i18n 2.5.10

> JcrResourceBundle does not support multiple base names
> --
>
> Key: SLING-4547
> URL: https://issues.apache.org/jira/browse/SLING-4547
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Affects Versions: i18n 2.5.8
>Reporter: Andrei Pilets
>Assignee: Konrad Windszus
> Fix For: i18n 2.5.10
>
>
> The sling:basename property may be multi-valued, that is the messages of a 
> mix:language nodes may belong to multiple base names and thus ResourceBundle 
> instances, as stated at 
> https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html.
>  
> The latest codebase does not work in that way.
> JcrResourceBundle#loadPotentialLanguageRoots():
> if (baseName == null || baseName.equals(properties.get(PROP_BASENAME, ""))) {
>  paths.add(bundle.getPath());
> }
> In case if property sling:basename have multiple values, only the first base 
> name is considered, others are skipped.
> The correct implementation would be to use properties.get(PROP_BASENAME) - 
> method version without default value parameter, which would return array. You 
> would need to iterate over its items and check equality.



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

[jira] [Updated] (SLING-4547) JcrResourceBundle does not support multiple base names

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-4547:
---
Affects Version/s: i18n 2.5.8

> JcrResourceBundle does not support multiple base names
> --
>
> Key: SLING-4547
> URL: https://issues.apache.org/jira/browse/SLING-4547
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Affects Versions: i18n 2.5.8
>Reporter: Andrei Pilets
>Assignee: Konrad Windszus
> Fix For: i18n 2.5.10
>
>
> The sling:basename property may be multi-valued, that is the messages of a 
> mix:language nodes may belong to multiple base names and thus ResourceBundle 
> instances, as stated at 
> https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html.
>  
> The latest codebase does not work in that way.
> JcrResourceBundle#loadPotentialLanguageRoots():
> if (baseName == null || baseName.equals(properties.get(PROP_BASENAME, ""))) {
>  paths.add(bundle.getPath());
> }
> In case if property sling:basename have multiple values, only the first base 
> name is considered, others are skipped.
> The correct implementation would be to use properties.get(PROP_BASENAME) - 
> method version without default value parameter, which would return array. You 
> would need to iterate over its items and check equality.



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

RE: [VOTE] Release Apache Sling File System Resource Provider 2.0.0, File System Resource Provider 1.3.0

[Oliver Lietz]

On Wednesday 29 March 2017 12:51:59 Stefan Seifert wrote:
> >> +1 (depends now on Jackrabbit, would prefer embedding
> >> org.apache.jackrabbit.util.ISO8601 like we do in other bundles, e.g.
> >
> >event)
> >
> >After having a closer look, I don't think it's worth the effort as there
> >are
> >more new dependencies (JCR, Vault, Guava).
> 
> there is no dependency on guava (only test dependency via sling-mock).

Guava is a transitive dependency of Jackrabbit.

> but yes, there are more dependencies for the filevault support now
> (jackrabbit filevault, jcr api, and some jackrabbit utils), and the used
> classes have more dependencies itself, so it's not so easy to embed them
> all - and the dependencies are available in sling launchpad anyway.

As Carsten removed javax.jcr from minimal Sling and commons.json is no longer 
required, I did adjust some (Karaf) features.
The sling-extension-fsresource with fsresource 2.0.0 depends now on javax.jcr, 
jackrabbit-api, jackrabbit-jcr-commons, vault and guava. Otherwise it would 
not resolve.

Regards,
O.

> stefan

Re: PaxExam based ITs create folders outside target

[Konrad Windszus]

> On 29 Mar 2017, at 15:12, Oliver Lietz  wrote:
> 
> On Wednesday 29 March 2017 14:48:06 Oliver Lietz wrote:
>> On Wednesday 29 March 2017 14:37:58 Konrad Windszus wrote:
>>> This is still not 100% fixed.
>>> The Jenkins Workspace still contains the folder
>>> https://builds.apache.org/job/sling-bundles-extensions-validation-core-1.8
>>> /
>>> ws/sling/repository/index/indexWriterDir/ outside of target. That folder
>>> must have been created by PaxExam after I wiped out the workspace in the
>>> Jenkins Job on the 16th of March. @Oli: Do you have any idea?
>> 
>> Will have a look...
> 
> I cannot reproduce locally and Rat didn't complain on Jenkins. The ZIP from 
> that workspace doesn't contain the _empty_ directory – either omitted when 
> archived or possible display issue on Jenkins?
> 
> Grepping for sling/repository/index in testing.log didn't reveal any 
> configuration issues either.
> 
> Jenkins page refreshed, sling/repository/index is gone. Did you wipe out 
> workspace again, Konrad?
No, but I assume the last build was executed on another Jenkins node where the 
workspace has been wiped out. It ss probably an issue with Jenkins Slaves 
(wiping of the workspace probably has not been properly propagated to all 
Slaves). Thanks for having a look and let's see whether that occurs in the 
future again.
> 
> Regards,
> O.
> 
>> O.
>> 
>>> Thanks,
>>> Konrad
>>> 
 On 16 Mar 2017, at 13:55, Oliver Lietz  wrote:
 
 On Thursday 16 March 2017 13:31:15 Konrad Windszus wrote:
> Hi,
 
 Hi Konrad,
 
> it seems that PaxExam based ITs may create folders outside the target
> folder (see
> https://builds.apache.org/job/sling-bundles-extensions-validation-core-> 
> > >> 1.
> 8/
> ws/) For Validation the folder
> sling/repository/index/lucene-1488547426482/data was obviously created
> by
> PaxExam.
> 
> Usually the repository lives below
> https://builds.apache.org/job/sling-bundles-extensions-validation-core-> 
> > >> 1.
> 8/
> ws/target/paxexam/ValidationServiceIT/sling/repository/
> 
> I also sometimes have seen this locally but I fail to reproduce it
> reliably. Does anyone have an idea, why the lucene index is there?
 
 that happend when configuration changed for LuceneIndexProviderService
 during container start and should be fixed in r1786426.
 
> Seems that PaxExam relies on relative paths somehow, which are
> sometimes
> relative to target and sometimes to the project root.
 
 No, in the above case configuration from Option slingLaunchpadOak was
 present first and configuration with workingDirectory kicked in later.
 
 Regards,
 O.
 
> Thanks for any help
> Konrad
> 
>> On 16 Mar 2017, at 12:11, Apache Jenkins Server
>>  wrote:
>> 
>> See
>> > e-> >>> 1 .8/55/display/redirect?page=changes>
>> 
>> Changes:
>> 
>> [kwin] fix some more warnings
>> 
>> --
>> Started by an SCM change
>> Started by upstream project
>> "sling-bundles-extensions-validation-test-services-1.8" build number
>> 28
>> originally caused by:
>> Started by upstream project
>> "sling-bundles-extensions-validation-api-1.8"
>> build number 25>
>> originally caused by:
>> Started by an SCM change
>> 
>> [EnvInject] - Loading node environment variables.
>> Building remotely on H23 (ubuntu) in workspace
>> > e-> >>> 1 .8/ws/> Updating
>> https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/valida
>> ti
>> o
>> n/core at revision '2017-03-16T11:10:09.674 +' U
>> src/test/java/org/apache/sling/validation/impl/model/MergedValidationM
>> od
>> e
>> lTest.java U
>> src/test/java/org/apache/sling/validation/impl/resourcemodel/ResourceV
>> al
>> i
>> dationModelProviderImplTest.java U
>> src/test/java/org/apache/sling/validation/impl/ValidationServiceImplTe
>> st
>> .
>> java U
>> src/main/java/org/apache/sling/validation/impl/ValidationServiceImpl.j
>> av
>> a
>> At revision 1787158
>> 
>> Parsing POMs
>> Established TCP socket on 34822
>> maven33-agent.jar already up to date
>> maven33-interceptor.jar already up to date
>> maven3-interceptor-commons.jar already up to date
>> [sling-bundles-extensions-validation-core-1.8] $
>> /home/jenkins/tools/java/latest1.8/bin/java -Xmx2g -Xms256m -cp
>> /home/jenkins/jenkins-slave/maven33-agent.jar:/home/jenkins/tools/mave
>> n/
>> a
>> pache-maven-3.3.9/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tool
>> s/
>> ma
>> 

[jira] [Commented] (SLING-6723) Make dependency to javax.jcr, jcr.contentloader and jcr.api optional

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6723:
-

The AbstractPostOperation is now free from those APIs (rev 1789360)

> Make dependency to javax.jcr, jcr.contentloader and jcr.api optional
> 
>
> Key: SLING-6723
> URL: https://issues.apache.org/jira/browse/SLING-6723
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Servlets Post 2.3.16
>
>
> In order to be able to run Sling in a very minimal version, the dependencies 
> to javax.jcr, jcr.api and jcr.contentloader should be optional. Otherwise a 
> whole set of modules needs to be dragged in just to make the servlets post 
> module provide the basic functionality (which is usually sufficient for most 
> applications)



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

Re: PaxExam based ITs create folders outside target

[Oliver Lietz]

On Wednesday 29 March 2017 14:48:06 Oliver Lietz wrote:
> On Wednesday 29 March 2017 14:37:58 Konrad Windszus wrote:
> > This is still not 100% fixed.
> > The Jenkins Workspace still contains the folder
> > https://builds.apache.org/job/sling-bundles-extensions-validation-core-1.8
> > /
> > ws/sling/repository/index/indexWriterDir/ outside of target. That folder
> > must have been created by PaxExam after I wiped out the workspace in the
> > Jenkins Job on the 16th of March. @Oli: Do you have any idea?
> 
> Will have a look...

I cannot reproduce locally and Rat didn't complain on Jenkins. The ZIP from 
that workspace doesn't contain the _empty_ directory – either omitted when 
archived or possible display issue on Jenkins?

Grepping for sling/repository/index in testing.log didn't reveal any 
configuration issues either.

Jenkins page refreshed, sling/repository/index is gone. Did you wipe out 
workspace again, Konrad?

Regards,
O.

> O.
> 
> > Thanks,
> > Konrad
> > 
> > > On 16 Mar 2017, at 13:55, Oliver Lietz  wrote:
> > > 
> > > On Thursday 16 March 2017 13:31:15 Konrad Windszus wrote:
> > >> Hi,
> > > 
> > > Hi Konrad,
> > > 
> > >> it seems that PaxExam based ITs may create folders outside the target
> > >> folder (see
> > >> https://builds.apache.org/job/sling-bundles-extensions-validation-core-> 
> > >> > >> 1.
> > >> 8/
> > >> ws/) For Validation the folder
> > >> sling/repository/index/lucene-1488547426482/data was obviously created
> > >> by
> > >> PaxExam.
> > >> 
> > >> Usually the repository lives below
> > >> https://builds.apache.org/job/sling-bundles-extensions-validation-core-> 
> > >> > >> 1.
> > >> 8/
> > >> ws/target/paxexam/ValidationServiceIT/sling/repository/
> > >> 
> > >> I also sometimes have seen this locally but I fail to reproduce it
> > >> reliably. Does anyone have an idea, why the lucene index is there?
> > > 
> > > that happend when configuration changed for LuceneIndexProviderService
> > > during container start and should be fixed in r1786426.
> > > 
> > >> Seems that PaxExam relies on relative paths somehow, which are
> > >> sometimes
> > >> relative to target and sometimes to the project root.
> > > 
> > > No, in the above case configuration from Option slingLaunchpadOak was
> > > present first and configuration with workingDirectory kicked in later.
> > > 
> > > Regards,
> > > O.
> > > 
> > >> Thanks for any help
> > >> Konrad
> > >> 
> > >>> On 16 Mar 2017, at 12:11, Apache Jenkins Server
> > >>>  wrote:
> > >>> 
> > >>> See
> > >>>  > >>> e-> >>> 1 .8/55/display/redirect?page=changes>
> > >>> 
> > >>> Changes:
> > >>> 
> > >>> [kwin] fix some more warnings
> > >>> 
> > >>> --
> > >>> Started by an SCM change
> > >>> Started by upstream project
> > >>> "sling-bundles-extensions-validation-test-services-1.8" build number
> > >>> 28
> > >>> originally caused by:
> > >>> Started by upstream project
> > >>> "sling-bundles-extensions-validation-api-1.8"
> > >>> build number 25>
> > >>> originally caused by:
> > >>> Started by an SCM change
> > >>> 
> > >>> [EnvInject] - Loading node environment variables.
> > >>> Building remotely on H23 (ubuntu) in workspace
> > >>>  > >>> e-> >>> 1 .8/ws/> Updating
> > >>> https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/valida
> > >>> ti
> > >>> o
> > >>> n/core at revision '2017-03-16T11:10:09.674 +' U
> > >>> src/test/java/org/apache/sling/validation/impl/model/MergedValidationM
> > >>> od
> > >>> e
> > >>> lTest.java U
> > >>> src/test/java/org/apache/sling/validation/impl/resourcemodel/ResourceV
> > >>> al
> > >>> i
> > >>> dationModelProviderImplTest.java U
> > >>> src/test/java/org/apache/sling/validation/impl/ValidationServiceImplTe
> > >>> st
> > >>> .
> > >>> java U
> > >>> src/main/java/org/apache/sling/validation/impl/ValidationServiceImpl.j
> > >>> av
> > >>> a
> > >>> At revision 1787158
> > >>> 
> > >>> Parsing POMs
> > >>> Established TCP socket on 34822
> > >>> maven33-agent.jar already up to date
> > >>> maven33-interceptor.jar already up to date
> > >>> maven3-interceptor-commons.jar already up to date
> > >>> [sling-bundles-extensions-validation-core-1.8] $
> > >>> /home/jenkins/tools/java/latest1.8/bin/java -Xmx2g -Xms256m -cp
> > >>> /home/jenkins/jenkins-slave/maven33-agent.jar:/home/jenkins/tools/mave
> > >>> n/
> > >>> a
> > >>> pache-maven-3.3.9/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tool
> > >>> s/
> > >>> ma
> > >>> ven/apache-maven-3.3.9/conf/logging jenkins.maven3.agent.Maven33Main
> > >>> /home/jenkins/tools/maven/apache-maven-3.3.9
> > >>> /home/jenkins/jenkins-slave/slave.jar
> > >>> /home/jenkins/jenkins-slave/maven33-interceptor.jar
> > >>> /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 34822
> > >>> <===[JENKINS REMOTING 

[jira] [Assigned] (SLING-4547) JcrResourceBundle does not support multiple base names

[Konrad Windszus (JIRA)]

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

Konrad Windszus reassigned SLING-4547:
--

Assignee: Konrad Windszus

> JcrResourceBundle does not support multiple base names
> --
>
> Key: SLING-4547
> URL: https://issues.apache.org/jira/browse/SLING-4547
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Reporter: Andrei Pilets
>Assignee: Konrad Windszus
>
> The sling:basename property may be multi-valued, that is the messages of a 
> mix:language nodes may belong to multiple base names and thus ResourceBundle 
> instances, as stated at 
> https://sling.apache.org/documentation/bundles/internationalization-support-i18n.html.
>  
> The latest codebase does not work in that way.
> JcrResourceBundle#loadPotentialLanguageRoots():
> if (baseName == null || baseName.equals(properties.get(PROP_BASENAME, ""))) {
>  paths.add(bundle.getPath());
> }
> In case if property sling:basename have multiple values, only the first base 
> name is considered, others are skipped.
> The correct implementation would be to use properties.get(PROP_BASENAME) - 
> method version without default value parameter, which would return array. You 
> would need to iterate over its items and check equality.



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

[jira] [Resolved] (SLING-6746) Remove and ban maven-scr-plugin

[Stefan Seifert (JIRA)]

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

Stefan Seifert resolved SLING-6746.
---
Resolution: Fixed

Completed: At revision: 1789357  

i added this message to the ban: "Felix SCR annotations and the 
maven-scr-plugin are no longer supported - please migrate to OSGi annotations 
or stick with Sling Parent 29."

> Remove and ban maven-scr-plugin
> ---
>
> Key: SLING-6746
> URL: https://issues.apache.org/jira/browse/SLING-6746
> Project: Sling
>  Issue Type: Bug
>  Components: General
>Affects Versions: Parent 30
>Reporter: Konrad Windszus
>Assignee: Stefan Seifert
>Priority: Critical
> Fix For: Parent 31
>
>
> The additional execution of maven-bundle-plugin:manifest being added with 
> SLING-6572 is basically overwriting the service descriptors and metatype 
> resources which are written with maven-scr-plugin with empty files. Those 
> empty files finally end up in the bundle. This affects all modules still 
> leveraging the maven-scr-plugin for generating the service 
> descriptors/metatype resources.



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

[jira] [Assigned] (SLING-6746) Remove and ban maven-scr-plugin

[Stefan Seifert (JIRA)]

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

Stefan Seifert reassigned SLING-6746:
-

Assignee: Stefan Seifert
 Summary: Remove and ban maven-scr-plugin  (was: Additional execution of 
maven-bundle-plugin:manifest is blanking out resources generated by 
maven-scr-plugin)

i've changed the ticket title from "Additional execution of 
maven-bundle-plugin:manifest is blanking out resources generated by 
maven-scr-plugin" to "Remove and ban maven-scr-plugin"

> Remove and ban maven-scr-plugin
> ---
>
> Key: SLING-6746
> URL: https://issues.apache.org/jira/browse/SLING-6746
> Project: Sling
>  Issue Type: Bug
>  Components: General
>Affects Versions: Parent 30
>Reporter: Konrad Windszus
>Assignee: Stefan Seifert
>Priority: Critical
> Fix For: Parent 31
>
>
> The additional execution of maven-bundle-plugin:manifest being added with 
> SLING-6572 is basically overwriting the service descriptors and metatype 
> resources which are written with maven-scr-plugin with empty files. Those 
> empty files finally end up in the bundle. This affects all modules still 
> leveraging the maven-scr-plugin for generating the service 
> descriptors/metatype resources.



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

RE: [VOTE] Release Apache Sling File System Resource Provider 2.0.0, File System Resource Provider 1.3.0

[Stefan Seifert]

>> +1 (depends now on Jackrabbit, would prefer embedding
>> org.apache.jackrabbit.util.ISO8601 like we do in other bundles, e.g.
>event)
>
>After having a closer look, I don't think it's worth the effort as there
>are
>more new dependencies (JCR, Vault, Guava).

there is no dependency on guava (only test dependency via sling-mock).

but yes, there are more dependencies for the filevault support now (jackrabbit 
filevault, jcr api, and some jackrabbit utils), and the used classes have more 
dependencies itself, so it's not so easy to embed them all - and the 
dependencies are available in sling launchpad anyway.

stefan

[jira] [Updated] (SLING-6746) Additional execution of maven-bundle-plugin:manifest is blanking out resources generated by maven-scr-plugin

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6746:
---
Fix Version/s: Parent 31

> Additional execution of maven-bundle-plugin:manifest is blanking out 
> resources generated by maven-scr-plugin
> 
>
> Key: SLING-6746
> URL: https://issues.apache.org/jira/browse/SLING-6746
> Project: Sling
>  Issue Type: Bug
>  Components: General
>Affects Versions: Parent 30
>Reporter: Konrad Windszus
>Priority: Critical
> Fix For: Parent 31
>
>
> The additional execution of maven-bundle-plugin:manifest being added with 
> SLING-6572 is basically overwriting the service descriptors and metatype 
> resources which are written with maven-scr-plugin with empty files. Those 
> empty files finally end up in the bundle. This affects all modules still 
> leveraging the maven-scr-plugin for generating the service 
> descriptors/metatype resources.



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

Re: PaxExam based ITs create folders outside target

[Oliver Lietz]

On Wednesday 29 March 2017 14:37:58 Konrad Windszus wrote:
> This is still not 100% fixed.
> The Jenkins Workspace still contains the folder
> https://builds.apache.org/job/sling-bundles-extensions-validation-core-1.8/
> ws/sling/repository/index/indexWriterDir/ outside of target. That folder
> must have been created by PaxExam after I wiped out the workspace in the
> Jenkins Job on the 16th of March. @Oli: Do you have any idea?

Will have a look...

O.

> Thanks,
> Konrad
> 
> > On 16 Mar 2017, at 13:55, Oliver Lietz  wrote:
> > 
> > On Thursday 16 March 2017 13:31:15 Konrad Windszus wrote:
> >> Hi,
> > 
> > Hi Konrad,
> > 
> >> it seems that PaxExam based ITs may create folders outside the target
> >> folder (see
> >> https://builds.apache.org/job/sling-bundles-extensions-validation-core-1.
> >> 8/
> >> ws/) For Validation the folder
> >> sling/repository/index/lucene-1488547426482/data was obviously created by
> >> PaxExam.
> >> 
> >> Usually the repository lives below
> >> https://builds.apache.org/job/sling-bundles-extensions-validation-core-1.
> >> 8/
> >> ws/target/paxexam/ValidationServiceIT/sling/repository/
> >> 
> >> I also sometimes have seen this locally but I fail to reproduce it
> >> reliably. Does anyone have an idea, why the lucene index is there?
> > 
> > that happend when configuration changed for LuceneIndexProviderService
> > during container start and should be fixed in r1786426.
> > 
> >> Seems that PaxExam relies on relative paths somehow, which are sometimes
> >> relative to target and sometimes to the project root.
> > 
> > No, in the above case configuration from Option slingLaunchpadOak was
> > present first and configuration with workingDirectory kicked in later.
> > 
> > Regards,
> > O.
> > 
> >> Thanks for any help
> >> Konrad
> >> 
> >>> On 16 Mar 2017, at 12:11, Apache Jenkins Server
> >>>  wrote:
> >>> 
> >>> See
> >>>  
> >>> >>> 1
> >>> .8/55/display/redirect?page=changes>
> >>> 
> >>> Changes:
> >>> 
> >>> [kwin] fix some more warnings
> >>> 
> >>> --
> >>> Started by an SCM change
> >>> Started by upstream project
> >>> "sling-bundles-extensions-validation-test-services-1.8" build number 28
> >>> originally caused by:
> >>> Started by upstream project
> >>> "sling-bundles-extensions-validation-api-1.8"
> >>> build number 25>
> >>> originally caused by:
> >>> Started by an SCM change
> >>> 
> >>> [EnvInject] - Loading node environment variables.
> >>> Building remotely on H23 (ubuntu) in workspace
> >>>  
> >>> >>> 1
> >>> .8/ws/> Updating
> >>> https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/validati
> >>> o
> >>> n/core at revision '2017-03-16T11:10:09.674 +' U
> >>> src/test/java/org/apache/sling/validation/impl/model/MergedValidationMod
> >>> e
> >>> lTest.java U
> >>> src/test/java/org/apache/sling/validation/impl/resourcemodel/ResourceVal
> >>> i
> >>> dationModelProviderImplTest.java U
> >>> src/test/java/org/apache/sling/validation/impl/ValidationServiceImplTest
> >>> .
> >>> java U
> >>> src/main/java/org/apache/sling/validation/impl/ValidationServiceImpl.jav
> >>> a
> >>> At revision 1787158
> >>> 
> >>> Parsing POMs
> >>> Established TCP socket on 34822
> >>> maven33-agent.jar already up to date
> >>> maven33-interceptor.jar already up to date
> >>> maven3-interceptor-commons.jar already up to date
> >>> [sling-bundles-extensions-validation-core-1.8] $
> >>> /home/jenkins/tools/java/latest1.8/bin/java -Xmx2g -Xms256m -cp
> >>> /home/jenkins/jenkins-slave/maven33-agent.jar:/home/jenkins/tools/maven/
> >>> a
> >>> pache-maven-3.3.9/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/
> >>> ma
> >>> ven/apache-maven-3.3.9/conf/logging jenkins.maven3.agent.Maven33Main
> >>> /home/jenkins/tools/maven/apache-maven-3.3.9
> >>> /home/jenkins/jenkins-slave/slave.jar
> >>> /home/jenkins/jenkins-slave/maven33-interceptor.jar
> >>> /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 34822
> >>> <===[JENKINS REMOTING CAPACITY]===>   channel started
> >>> Executing Maven:  -B -f
> >>>  
> >>> >>> 1
> >>> .8/ws/pom.xml>
> >>> -Dmaven.repo.local=/home/jenkins/jenkins-slave/maven-repositories/0 -U
> >>> clean deploy [INFO] Scanning for projects...
> >>> [INFO]
> >>> [INFO]
> >>> 
> >>> [INFO] Building Apache Sling Validation Framework Core Implementation
> >>> 1.0.0-SNAPSHOT [INFO]
> >>> 
> >>> [INFO] Downloading:
> >>> http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling
> >>> .
> >>> validation.api/1.0.0-SNAPSHOT/maven-metadata.xml [INFO] Downloaded:
> >>> 

[jira] [Commented] (SLING-6746) Additional execution of maven-bundle-plugin:manifest is blanking out resources generated by maven-scr-plugin

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6746:
-

We should not use the Felix SCR bnd plugin - we should really move away from 
the Felix SCR annotations. If a project is using these, it can stay with the 
existing older versions of the parent pom. We should migrate all projects, it 
really takes not a lot to migrate a project.
+1 for banning the scr plugin

> Additional execution of maven-bundle-plugin:manifest is blanking out 
> resources generated by maven-scr-plugin
> 
>
> Key: SLING-6746
> URL: https://issues.apache.org/jira/browse/SLING-6746
> Project: Sling
>  Issue Type: Bug
>  Components: General
>Affects Versions: Parent 30
>Reporter: Konrad Windszus
>Priority: Critical
>
> The additional execution of maven-bundle-plugin:manifest being added with 
> SLING-6572 is basically overwriting the service descriptors and metatype 
> resources which are written with maven-scr-plugin with empty files. Those 
> empty files finally end up in the bundle. This affects all modules still 
> leveraging the maven-scr-plugin for generating the service 
> descriptors/metatype resources.



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

Re: [VOTE] Release Apache Sling File System Resource Provider 2.0.0, File System Resource Provider 1.3.0

[Oliver Lietz]

On Wednesday 29 March 2017 11:04:04 Oliver Lietz wrote:
> On Monday 27 March 2017 16:21:49 Stefan Seifert wrote:
> > Hi,
> > 
> > Apache Sling File System Resource Provider 2.0.0  (3 issues)
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12339777
> 
> +1 (depends now on Jackrabbit, would prefer embedding
> org.apache.jackrabbit.util.ISO8601 like we do in other bundles, e.g. event)

After having a closer look, I don't think it's worth the effort as there are 
more new dependencies (JCR, Vault, Guava).

O.

> > Apache Sling File System Resource Provider 1.3.0  (2 issues)
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12338947
> 
> +1
> 
> O.

Re: PaxExam based ITs create folders outside target

[Konrad Windszus]

This is still not 100% fixed.
The Jenkins Workspace still contains the folder 
https://builds.apache.org/job/sling-bundles-extensions-validation-core-1.8/ws/sling/repository/index/indexWriterDir/
 outside of target.
That folder must have been created by PaxExam after I wiped out the workspace 
in the Jenkins Job on the 16th of March.
@Oli: Do you have any idea?
Thanks,
Konrad

> On 16 Mar 2017, at 13:55, Oliver Lietz  wrote:
> 
> On Thursday 16 March 2017 13:31:15 Konrad Windszus wrote:
>> Hi,
> 
> Hi Konrad,
> 
>> it seems that PaxExam based ITs may create folders outside the target folder
>> (see
>> https://builds.apache.org/job/sling-bundles-extensions-validation-core-1.8/
>> ws/) For Validation the folder
>> sling/repository/index/lucene-1488547426482/data was obviously created by
>> PaxExam.
>> 
>> Usually the repository lives below
>> https://builds.apache.org/job/sling-bundles-extensions-validation-core-1.8/
>> ws/target/paxexam/ValidationServiceIT/sling/repository/
>> 
>> I also sometimes have seen this locally but I fail to reproduce it reliably.
>> Does anyone have an idea, why the lucene index is there?
> 
> that happend when configuration changed for LuceneIndexProviderService during 
> container start and should be fixed in r1786426.
> 
>> Seems that PaxExam relies on relative paths somehow, which are sometimes
>> relative to target and sometimes to the project root.
> 
> No, in the above case configuration from Option slingLaunchpadOak was present 
> first and configuration with workingDirectory kicked in later.
> 
> Regards,
> O.
> 
>> Thanks for any help
>> Konrad
>> 
>>> On 16 Mar 2017, at 12:11, Apache Jenkins Server
>>>  wrote:
>>> 
>>> See
>>> >> .8/55/display/redirect?page=changes>
>>> 
>>> Changes:
>>> 
>>> [kwin] fix some more warnings
>>> 
>>> --
>>> Started by an SCM change
>>> Started by upstream project
>>> "sling-bundles-extensions-validation-test-services-1.8" build number 28
>>> originally caused by:
>>> Started by upstream project "sling-bundles-extensions-validation-api-1.8"
>>> build number 25> 
>>> originally caused by:
>>> Started by an SCM change
>>> 
>>> [EnvInject] - Loading node environment variables.
>>> Building remotely on H23 (ubuntu) in workspace
>>> >> .8/ws/> Updating
>>> https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/validatio
>>> n/core at revision '2017-03-16T11:10:09.674 +' U
>>> src/test/java/org/apache/sling/validation/impl/model/MergedValidationMode
>>> lTest.java U
>>> src/test/java/org/apache/sling/validation/impl/resourcemodel/ResourceVali
>>> dationModelProviderImplTest.java U
>>> src/test/java/org/apache/sling/validation/impl/ValidationServiceImplTest.
>>> java U
>>> src/main/java/org/apache/sling/validation/impl/ValidationServiceImpl.java
>>> At revision 1787158
>>> 
>>> Parsing POMs
>>> Established TCP socket on 34822
>>> maven33-agent.jar already up to date
>>> maven33-interceptor.jar already up to date
>>> maven3-interceptor-commons.jar already up to date
>>> [sling-bundles-extensions-validation-core-1.8] $
>>> /home/jenkins/tools/java/latest1.8/bin/java -Xmx2g -Xms256m -cp
>>> /home/jenkins/jenkins-slave/maven33-agent.jar:/home/jenkins/tools/maven/a
>>> pache-maven-3.3.9/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/ma
>>> ven/apache-maven-3.3.9/conf/logging jenkins.maven3.agent.Maven33Main
>>> /home/jenkins/tools/maven/apache-maven-3.3.9
>>> /home/jenkins/jenkins-slave/slave.jar
>>> /home/jenkins/jenkins-slave/maven33-interceptor.jar
>>> /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 34822
>>> <===[JENKINS REMOTING CAPACITY]===>   channel started
>>> Executing Maven:  -B -f
>>> >> .8/ws/pom.xml>
>>> -Dmaven.repo.local=/home/jenkins/jenkins-slave/maven-repositories/0 -U
>>> clean deploy [INFO] Scanning for projects...
>>> [INFO]
>>> [INFO]
>>> 
>>> [INFO] Building Apache Sling Validation Framework Core Implementation
>>> 1.0.0-SNAPSHOT [INFO]
>>> 
>>> [INFO] Downloading:
>>> http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.
>>> validation.api/1.0.0-SNAPSHOT/maven-metadata.xml [INFO] Downloaded:
>>> http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.
>>> validation.api/1.0.0-SNAPSHOT/maven-metadata.xml (1023 B at 2.2 KB/sec)
>>> [INFO] Downloading:
>>> http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.
>>> validation.api/1.0.0-SNAPSHOT/org.apache.sling.validation.api-1.0.0-201703
>>> 16.110912-1580.pom [INFO] Downloaded:
>>> 

[jira] [Commented] (SLING-6746) Additional execution of maven-bundle-plugin:manifest is blanking out resources generated by maven-scr-plugin

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6746:


Agreed, can you make the according changes in parent?  The enforcer rule sounds 
useful in addition, I would just adjust the message so that it says something 
like:
"maven-scr-plugin is incompatible with the manifest goal of the 
maven-bundle-plugin. Please either remove Felix SCR annotations completely (and 
migrate to OSGi annotations which are processed by the maven-bundle-plugin 
itself) or use the SCR bnd plugin from 
http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/apache-felix-scr-bndtools-use.html;

> Additional execution of maven-bundle-plugin:manifest is blanking out 
> resources generated by maven-scr-plugin
> 
>
> Key: SLING-6746
> URL: https://issues.apache.org/jira/browse/SLING-6746
> Project: Sling
>  Issue Type: Bug
>  Components: General
>Affects Versions: Parent 30
>Reporter: Konrad Windszus
>Priority: Critical
>
> The additional execution of maven-bundle-plugin:manifest being added with 
> SLING-6572 is basically overwriting the service descriptors and metatype 
> resources which are written with maven-scr-plugin with empty files. Those 
> empty files finally end up in the bundle. This affects all modules still 
> leveraging the maven-scr-plugin for generating the service 
> descriptors/metatype resources.



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

[jira] [Comment Edited] (SLING-6746) Additional execution of maven-bundle-plugin:manifest is blanking out resources generated by maven-scr-plugin

[Stefan Seifert (JIRA)]

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

Stefan Seifert edited comment on SLING-6746 at 3/29/17 12:21 PM:
-

yes, we should remove maven-scr-plugin from parent - and it is not worth 
investing any effort in making it play together because the 
{{SCRDescriptorBndPlugin}} is doing all that maven-scr-plugin was doing before.
we may even use maven enforcer to ban the maven-scr-plugin from projects 
updating to this parent pom - example:
https://github.com/wcm-io/wcm-io-tooling/blob/develop/maven/aem-global-parent/pom.xml#L158


was (Author: sseif...@pro-vision.de):
yes, we should remove maven-scr-plugin from parent - and it is not worth 
investing any effort in making it play together because the is doing all that 
maven-scr-plugin was doing before.
we may even use maven enforcer to ban the maven-scr-plugin from projects 
updating to this parent pom - example:
https://github.com/wcm-io/wcm-io-tooling/blob/develop/maven/aem-global-parent/pom.xml#L158

> Additional execution of maven-bundle-plugin:manifest is blanking out 
> resources generated by maven-scr-plugin
> 
>
> Key: SLING-6746
> URL: https://issues.apache.org/jira/browse/SLING-6746
> Project: Sling
>  Issue Type: Bug
>  Components: General
>Affects Versions: Parent 30
>Reporter: Konrad Windszus
>Priority: Critical
>
> The additional execution of maven-bundle-plugin:manifest being added with 
> SLING-6572 is basically overwriting the service descriptors and metatype 
> resources which are written with maven-scr-plugin with empty files. Those 
> empty files finally end up in the bundle. This affects all modules still 
> leveraging the maven-scr-plugin for generating the service 
> descriptors/metatype resources.



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

[jira] [Commented] (SLING-6746) Additional execution of maven-bundle-plugin:manifest is blanking out resources generated by maven-scr-plugin

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6746:
---

yes, we should remove maven-scr-plugin from parent - and it is not worth 
investing any effort in making it play together because the is doing all that 
maven-scr-plugin was doing before.
we may even use maven enforcer to ban the maven-scr-plugin from projects 
updating to this parent pom - example:
https://github.com/wcm-io/wcm-io-tooling/blob/develop/maven/aem-global-parent/pom.xml#L158

> Additional execution of maven-bundle-plugin:manifest is blanking out 
> resources generated by maven-scr-plugin
> 
>
> Key: SLING-6746
> URL: https://issues.apache.org/jira/browse/SLING-6746
> Project: Sling
>  Issue Type: Bug
>  Components: General
>Affects Versions: Parent 30
>Reporter: Konrad Windszus
>Priority: Critical
>
> The additional execution of maven-bundle-plugin:manifest being added with 
> SLING-6572 is basically overwriting the service descriptors and metatype 
> resources which are written with maven-scr-plugin with empty files. Those 
> empty files finally end up in the bundle. This affects all modules still 
> leveraging the maven-scr-plugin for generating the service 
> descriptors/metatype resources.



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

[jira] [Commented] (SLING-6746) Additional execution of maven-bundle-plugin:manifest is blanking out resources generated by maven-scr-plugin

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6746:


This was kind of unexpected. Then we should IMHO completely remove the 
maven-scr-plugin from the parent if it is now incompatible with other plugin 
executions. That does not sound like a smooth migration path, therefore I would 
rather propose to make the maven-bundle-plugin behave more reluctant before it 
overwrites/blanks out those resources. Do you think this could be done in the 
maven-bundle-plugin, or does it require a fix from bnd?

> Additional execution of maven-bundle-plugin:manifest is blanking out 
> resources generated by maven-scr-plugin
> 
>
> Key: SLING-6746
> URL: https://issues.apache.org/jira/browse/SLING-6746
> Project: Sling
>  Issue Type: Bug
>  Components: General
>Affects Versions: Parent 30
>Reporter: Konrad Windszus
>Priority: Critical
>
> The additional execution of maven-bundle-plugin:manifest being added with 
> SLING-6572 is basically overwriting the service descriptors and metatype 
> resources which are written with maven-scr-plugin with empty files. Those 
> empty files finally end up in the bundle. This affects all modules still 
> leveraging the maven-scr-plugin for generating the service 
> descriptors/metatype resources.



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

[event] kafka-based sling.event.api implementation

[Stefan Egli]

Hi,

The split of Sling event into an API and a Resource-based bundle will now
ease other implementations than the current Resource-based one.

I'll be starting to work on one such implementation that is going to be
kafka based (perhaps split into a generic messaging and a specific kafka
part):

https://issues.apache.org/jira/browse/SLING-6745

I'm planning to do it in my whiteboard area

http://svn.apache.org/viewvc/sling/whiteboard/egli/event/kafka

and would suggest to eventually move it to something like

contrib/extensions/event-kafka



Cheers,

Stefan

[jira] [Commented] (SLING-6746) Additional execution of maven-bundle-plugin:manifest is blanking out resources generated by maven-scr-plugin

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6746:
---

the solution should be to completely remove the maven-scr-plugin and instead 
add this bnd plugin to maven bundle plugin:
{noformat}
<_plugin>org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin;destdir=${project.build.outputDirectory}
{noformat}
and
{code:xml}

  org.apache.felix
  org.apache.felix.scr.bnd
  1.7.2

{code}

as discussed in SLING-6649 this should not go into sling parent, but has to be 
defined for those project poms still using scr annotations until they migrate 
to osgi annotations (or stick with an older version of sling parent).

> Additional execution of maven-bundle-plugin:manifest is blanking out 
> resources generated by maven-scr-plugin
> 
>
> Key: SLING-6746
> URL: https://issues.apache.org/jira/browse/SLING-6746
> Project: Sling
>  Issue Type: Bug
>  Components: General
>Affects Versions: Parent 30
>Reporter: Konrad Windszus
>Priority: Critical
>
> The additional execution of maven-bundle-plugin:manifest being added with 
> SLING-6572 is basically overwriting the service descriptors and metatype 
> resources which are written with maven-scr-plugin with empty files. Those 
> empty files finally end up in the bundle. This affects all modules still 
> leveraging the maven-scr-plugin for generating the service 
> descriptors/metatype resources.



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

[jira] [Commented] (SLING-6746) Additional execution of maven-bundle-plugin:manifest is blanking out resources generated by maven-scr-plugin

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6746:


[~sseif...@pro-vision.de] Can you have a look, since you introduced this 
regression in SLING-6572?

> Additional execution of maven-bundle-plugin:manifest is blanking out 
> resources generated by maven-scr-plugin
> 
>
> Key: SLING-6746
> URL: https://issues.apache.org/jira/browse/SLING-6746
> Project: Sling
>  Issue Type: Bug
>  Components: General
>Affects Versions: Parent 30
>Reporter: Konrad Windszus
>Priority: Critical
>
> The additional execution of maven-bundle-plugin:manifest being added with 
> SLING-6572 is basically overwriting the service descriptors and metatype 
> resources which are written with maven-scr-plugin with empty files. Those 
> empty files finally end up in the bundle. This affects all modules still 
> leveraging the maven-scr-plugin for generating the service 
> descriptors/metatype resources.



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

Re: Parent 30 breaks maven-scr-plugin

[Konrad Windszus]

I found the culprit: It is 
https://github.com/apache/sling/commit/9b0c5e785554029de2cdf5ddc2549efe5b13e9a5
So the extra execution of maven-bundle-plugin:manifest is basically overwriting 
the service descriptors which are written with maven-scr-plugin with empty 
files. Those empty files end up in the bundle and lead to these issue. I 
created https://issues.apache.org/jira/browse/SLING-6746 for that.
Konrad 

> On 29 Mar 2017, at 10:55, Konrad Windszus  wrote:
> 
>> 
>> On 29 Mar 2017, at 10:45, Carsten Ziegeler  wrote:
>> 
>> Konrad Windszus wrote
>>> 
 On 29 Mar 2017, at 10:29, Oliver Lietz  wrote:
 
 On Wednesday 29 March 2017 08:44:59 Konrad Windszus wrote:
> It seems that parent 30 breaks the usage of the maven-scr-plugin. With 29 
> it
> works. When looking at the history of the parent pom.xml
> (https://github.com/apache/sling/commits/trunk/parent/pom.xml) I don't
> really see the reason for that. If I understand correctly reverting to
> parent 29 makes everything work as before. Although I do agree that we
> should migrate all modules in the future towards OSGi annotations and get
> rid of the maven-scr-plugin, having a broken maven-scr-plugin integration
> in parent 30 feels like a regression to me. Does anyone have a clue what
> the issue is with parent 30 here?
 
 I guess it's one of SLING-6246, SLING-6532 or SLING-6533.
>>> 
>>> The latter two should lead to failures at compile time already (if e.g. the 
>>> SCR annotations can no longer be resolved).
>>> If it is SLING-6246 that sounds like a major regression in the 
>>> maven-scr-plugin itself then, which is probably worth investigating.
>> 
>> The problem is that many poms have the scr annotations as an explicit
>> dependency. So when updating to parent 30 you still have that dependency
>> and don't get compilation problems
>> 
> Right, but that shouldn't cause the regression either. So most probably the 
> updated version of the maven-scr-plugin is just not working correctly.
>> 
>> Carsten
>> 
>> -- 
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org

[jira] [Commented] (SLING-6723) Make dependency to javax.jcr, jcr.contentloader and jcr.api optional

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6723:
-

Absolutely, I'll make sure that these things are logged and handled in a 
meaningful way.

As a first step, I've moved ordering to a separate class in rev 1789343

> Make dependency to javax.jcr, jcr.contentloader and jcr.api optional
> 
>
> Key: SLING-6723
> URL: https://issues.apache.org/jira/browse/SLING-6723
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Servlets Post 2.3.16
>
>
> In order to be able to run Sling in a very minimal version, the dependencies 
> to javax.jcr, jcr.api and jcr.contentloader should be optional. Otherwise a 
> whole set of modules needs to be dragged in just to make the servlets post 
> module provide the basic functionality (which is usually sufficient for most 
> applications)



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

[jira] [Created] (SLING-6746) Additional execution of maven-bundle-plugin:manifest is blanking out resources generated by maven-scr-plugin

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-6746:
--

 Summary: Additional execution of maven-bundle-plugin:manifest is 
blanking out resources generated by maven-scr-plugin
 Key: SLING-6746
 URL: https://issues.apache.org/jira/browse/SLING-6746
 Project: Sling
  Issue Type: Bug
  Components: General
Affects Versions: Parent 30
Reporter: Konrad Windszus
Priority: Critical


The additional execution of maven-bundle-plugin:manifest being added with 
SLING-6572 is basically overwriting the service descriptors and metatype 
resources which are written with maven-scr-plugin with empty files. Those empty 
files finally end up in the bundle. This affects all modules still leveraging 
the maven-scr-plugin for generating the service descriptors/metatype resources.



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

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

[Stefan Egli (JIRA)]

Stefan Egli created SLING-6745:
--

 Summary: 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)

Re: Dependencies in Jenkins Jobs

[Robert Munteanu]

On Wed, 2017-03-29 at 13:44 +0200, Konrad Windszus wrote:
> I think the solution is the configuration option "Block build when
> upstream project is building"[0], which should be IMHO enabled on all
> Jenkins Jobs for Sling. 
> WDYT?
> @Robert: Can you change the seed job accordingly?
> Konrad

Sure, done in https://svn.apache.org/r1789342

Robert

> 
> [0] - http://blogs.wandisco.com/2012/07/26/bringing-order-your-jenkin
> s-jobs/
> 
> > On 29 Mar 2017, at 13:34, Konrad Windszus  > ic.biz> wrote:
> > 
> > I just ran into a Jenkins Build Failure in https://builds.apache.or
> > g/job/sling-bundles-extensions-validation-core-1.8/80/.
> > Although this does have a dependency on Validation API in 1.0.0-
> > SNAPSHOT the according API build job (https://builds.apache.org/job
> > /sling-bundles-extensions-validation-api-1.8/) has not been
> > triggered prior to build 80 of validation core. Therefore an older
> > version of the API bundle has been used, which is incompatible. Is
> > there anything we can tweak here on the Jenkins side to make sure
> > that the upstream jobs are triggered first (if they are affected by
> > the same commit)?
> > Thanks,
> > Konrad
> 
> 

Re: Dependencies in Jenkins Jobs

[Konrad Windszus]

I think the solution is the configuration option "Block build when upstream 
project is building"[0], which should be IMHO enabled on all Jenkins Jobs for 
Sling. 
WDYT?
@Robert: Can you change the seed job accordingly?
Konrad

[0] - http://blogs.wandisco.com/2012/07/26/bringing-order-your-jenkins-jobs/

> On 29 Mar 2017, at 13:34, Konrad Windszus  
> wrote:
> 
> I just ran into a Jenkins Build Failure in 
> https://builds.apache.org/job/sling-bundles-extensions-validation-core-1.8/80/.
> Although this does have a dependency on Validation API in 1.0.0-SNAPSHOT the 
> according API build job 
> (https://builds.apache.org/job/sling-bundles-extensions-validation-api-1.8/) 
> has not been triggered prior to build 80 of validation core. Therefore an 
> older version of the API bundle has been used, which is incompatible. Is 
> there anything we can tweak here on the Jenkins side to make sure that the 
> upstream jobs are triggered first (if they are affected by the same commit)?
> Thanks,
> Konrad

Dependencies in Jenkins Jobs

[Konrad Windszus]

I just ran into a Jenkins Build Failure in 
https://builds.apache.org/job/sling-bundles-extensions-validation-core-1.8/80/.
Although this does have a dependency on Validation API in 1.0.0-SNAPSHOT the 
according API build job 
(https://builds.apache.org/job/sling-bundles-extensions-validation-api-1.8/) 
has not been triggered prior to build 80 of validation core. Therefore an older 
version of the API bundle has been used, which is incompatible. Is there 
anything we can tweak here on the Jenkins side to make sure that the upstream 
jobs are triggered first (if they are affected by the same commit)?
Thanks,
Konrad

[jira] [Commented] (SLING-6637) [htl] data-sly-use should not raise an exception when resource doesn't exist

[Feike Visser (JIRA)]

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

Feike Visser commented on SLING-6637:
-

I raised the following improvement JIRA on this subject: 
https://issues.apache.org/jira/browse/SLING-6744

> [htl] data-sly-use should not raise an exception when resource doesn't exist
> 
>
> Key: SLING-6637
> URL: https://issues.apache.org/jira/browse/SLING-6637
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Reporter: Feike Visser
>Assignee: Radu Cotescu
>
> Following code: 
> {code}
> 
> {code}
> You get now the following exception:
> {code}
> org.apache.sling.scripting.sightly.SightlyException: No use provider could 
> resolve identifier x/y/z
> {code}
> In practice you want to have a null-value assigned to x, now developers will 
> make a lot of checks to make sure the resource does exist.
> In addition we can log warning message when this happens.



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

[jira] [Commented] (SLING-6727) Align accessors in API

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6727:


Makes sense, fixed in [r1789339|https://svn.apache.org/r1789339].

> Align accessors in API
> --
>
> Key: SLING-6727
> URL: https://issues.apache.org/jira/browse/SLING-6727
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> We currently have {{getValidationModel(...)}} and 
> {{getModel(...)}}/{{getModels(...)}}, but should use one or the other.
> Also we should remove _Validated_ from 
> {{ValidationModel#getValidatedResourceType()}}.



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

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

[Feike Visser (JIRA)]

Feike Visser created SLING-6744:
---

 Summary: [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)

Re: Sling Eclipse Tooling and OSGi Bundle Content

[Stefan Egli]

Hi Andreas,

On 28/03/17 19:38, "Andreas Schaefer Sr."  wrote:

>BTW as an Eclipse newbie how do I deploy an OSGi Bundle to Sling?

If the project is properly setup (see [0]) the bundle gets deployed
automatically on every change. You can also adjust if you want it
automatically or manually.

Cheers,
Stefan
--
[0] - 
https://sling.apache.org/documentation/development/ide-tooling.html#bundle-
sync

[jira] [Resolved] (SLING-6743) Drop workspace support

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-6743.
-
Resolution: Fixed

Removed in rev 1789321

> Drop workspace support
> --
>
> Key: SLING-6743
> URL: https://issues.apache.org/jira/browse/SLING-6743
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Servlets Post 2.3.16
>
>
> We dropped workspace support from most other modules long time ago, it seems 
> we missed the servlets post module. We should remove it here as well as it is 
> not needed anymore.



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

[jira] [Created] (SLING-6743) Drop workspace support

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-6743:
---

 Summary: Drop workspace support
 Key: SLING-6743
 URL: https://issues.apache.org/jira/browse/SLING-6743
 Project: Sling
  Issue Type: Improvement
  Components: Servlets
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Servlets Post 2.3.16


We dropped workspace support from most other modules long time ago, it seems we 
missed the servlets post module. We should remove it here as well as it is not 
needed anymore.



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

Re: [event] splitting sling.event into API and Implementation bundle

[Stefan Egli]

On 29/03/17 09:33, "Stefan Egli"  wrote:

>I'll go ahead with the split and will come back when finished.

I've done the main split of event into event/api and event/resource.

As a next step I would suggest to release event/api so that event/resource
can refer to it via a released version and not SNAPSHOT (at the moment
event/resource is still self-contained, its basically unchanged from
event, just renamed).

Would appreciate if someone could have a look if event/api is clean for an
initial 1.0.0 release.

>You'll have to refresh the project structure in your IDEs afterwards.

now.

Cheers,
Stefan

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

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-6679:
-

Are there any plans for modules in contrib, e.g. distribution?

> 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-6739) split sling.event into event.api and event.impl

[Stefan Egli (JIRA)]

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

Stefan Egli commented on SLING-6739:


h6. step 6: event/api/README adjusted 
(http://svn.apache.org/viewvc?rev=1789319=rev)

> split sling.event into event.api and event.impl
> ---
>
> Key: SLING-6739
> URL: https://issues.apache.org/jira/browse/SLING-6739
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Event 4.2.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> Currently sling.event contains both API and implementation. In order to 
> support different implementation variants it would be good to have two 
> separate bundles, one containing just the API and one with the (current) 
> implementation. I would suggest to create
> bundles/extensions/event-api
> bundles/extensions/event-impl
> and to remove the current
> bundles/extensions/event



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

[jira] [Commented] (SLING-6739) split sling.event into event.api and event.impl

[Stefan Egli (JIRA)]

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

Stefan Egli commented on SLING-6739:


h6. step 5: further cleanup of the event/api/pom.xml 
(http://svn.apache.org/viewvc?rev=1789318=rev)

> split sling.event into event.api and event.impl
> ---
>
> Key: SLING-6739
> URL: https://issues.apache.org/jira/browse/SLING-6739
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Event 4.2.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> Currently sling.event contains both API and implementation. In order to 
> support different implementation variants it would be good to have two 
> separate bundles, one containing just the API and one with the (current) 
> implementation. I would suggest to create
> bundles/extensions/event-api
> bundles/extensions/event-impl
> and to remove the current
> bundles/extensions/event



--
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

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-6679:


Saw the commit just now, thanks!

> 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

[Karl Pauls (JIRA)]

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

Karl Pauls commented on SLING-6679:
---

[~rombert], yeah - I removed one snaphot too many. Carsten just committed an 
update of the serviceusermapping bundle to the latest snapshot. Should work now.

> 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

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-6679:


[~karlpauls] - the launchpad does not start anymore after these changes, see 
https://builds.apache.org/job/sling-launchpad-builder-1.8/

The relevant snippet I have found in the logs is

{noformat}29.03.2017 09:25:22.244 *INFO* [OsgiInstallerImpl] 
org.apache.sling.installer.core.impl.tasks.BundleStartTask Could not start 
bundle org.apache.sling.xss [145]. Reason: {}. Will retry.
org.osgi.framework.BundleException: Unable to resolve org.apache.sling.xss 
[145](R 145.0): missing requirement [org.apache.sling.xss [145](R 145.0)] 
osgi.wiring.package; 
(&(osgi.wiring.package=org.apache.sling.serviceusermapping)(version>=1.2.0)(!(version>=2.0.0)))
 [caused by: Unable to resolve org.apache.sling.serviceusermapper [139](R 
139.0): missing requirement [org.apache.sling.serviceusermapper [139](R 139.0)] 
osgi.wiring.package; 
(&(osgi.wiring.package=org.apache.sling.commons.json)(version>=2.0.0)(!(version>=3.0.0)))]
 Unresolved requirements: [[org.apache.sling.xss [145](R 145.0)] 
osgi.wiring.package; 
(&(osgi.wiring.package=org.apache.sling.serviceusermapping)(version>=1.2.0)(!(version>=2.0.0)))]
at 
org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:4111)
at org.apache.felix.framework.Felix.startBundle(Felix.java:2117)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:998)
at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:984)
at 
org.apache.sling.installer.core.impl.tasks.BundleStartTask.execute(BundleStartTask.java:97)
at 
org.apache.sling.installer.core.impl.OsgiInstallerImpl.doExecuteTasks(OsgiInstallerImpl.java:894)
at 
org.apache.sling.installer.core.impl.OsgiInstallerImpl.executeTasks(OsgiInstallerImpl.java:729)
at 
org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:286)
at java.lang.Thread.run(Thread.java:745){noformat}

> 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-6727) Align accessors in API

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-6727:
-

[~kwin], it's the tense which irritates. How about 
{{getValidatingResourceType()}}?

> Align accessors in API
> --
>
> Key: SLING-6727
> URL: https://issues.apache.org/jira/browse/SLING-6727
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> We currently have {{getValidationModel(...)}} and 
> {{getModel(...)}}/{{getModels(...)}}, but should use one or the other.
> Also we should remove _Validated_ from 
> {{ValidationModel#getValidatedResourceType()}}.



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

[jira] [Commented] (SLING-6739) split sling.event into event.api and event.impl

[Stefan Egli (JIRA)]

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

Stefan Egli commented on SLING-6739:


h6. step 4: initial adjustment of event/resource/pom.xml, just renaming the 
bundle symbolic name and version 
(http://svn.apache.org/viewvc?rev=1789306=rev)

> split sling.event into event.api and event.impl
> ---
>
> Key: SLING-6739
> URL: https://issues.apache.org/jira/browse/SLING-6739
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Event 4.2.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> Currently sling.event contains both API and implementation. In order to 
> support different implementation variants it would be good to have two 
> separate bundles, one containing just the API and one with the (current) 
> implementation. I would suggest to create
> bundles/extensions/event-api
> bundles/extensions/event-impl
> and to remove the current
> bundles/extensions/event



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

[jira] [Commented] (SLING-6727) Align accessors in API

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6727:


I consistently use now the term validationModel (always with prefix 
{{validation}}) to prevent any mixing up with Sling Models in 
[r1789304|https://svn.apache.org/r1789304].

Regarding {{ValidationModel#getValidatedResourceType()}} I am in favour of 
leaving it like that. IMHO it is clearer that way that this is referring to the 
resource type of the resource to be validated rather than to the resource type 
of the underlying (resource-based) validation model. Also this is in line with 
the property name described for resource-based validation models in 
http://sling.apache.org/documentation/bundles/validation.html#validation-model-resources.

> Align accessors in API
> --
>
> Key: SLING-6727
> URL: https://issues.apache.org/jira/browse/SLING-6727
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> We currently have {{getValidationModel(...)}} and 
> {{getModel(...)}}/{{getModels(...)}}, but should use one or the other.
> Also we should remove _Validated_ from 
> {{ValidationModel#getValidatedResourceType()}}.



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

[jira] [Resolved] (SLING-6727) Align accessors in API

[Konrad Windszus (JIRA)]

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

Konrad Windszus resolved SLING-6727.

Resolution: Fixed

> Align accessors in API
> --
>
> Key: SLING-6727
> URL: https://issues.apache.org/jira/browse/SLING-6727
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> We currently have {{getValidationModel(...)}} and 
> {{getModel(...)}}/{{getModels(...)}}, but should use one or the other.
> Also we should remove _Validated_ from 
> {{ValidationModel#getValidatedResourceType()}}.



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

[jira] [Assigned] (SLING-6727) Align accessors in API

[Konrad Windszus (JIRA)]

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

Konrad Windszus reassigned SLING-6727:
--

Assignee: Konrad Windszus

> Align accessors in API
> --
>
> Key: SLING-6727
> URL: https://issues.apache.org/jira/browse/SLING-6727
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions, Validation
>Reporter: Oliver Lietz
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
>
> We currently have {{getValidationModel(...)}} and 
> {{getModel(...)}}/{{getModels(...)}}, but should use one or the other.
> Also we should remove _Validated_ from 
> {{ValidationModel#getValidatedResourceType()}}.



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

[jira] [Updated] (SLING-6515) Sling Post Processor considering validation model as well

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6515:
---
Fix Version/s: (was: Sling Models Validation Impl 1.0.0)
   Validation 1.0.0

> Sling Post Processor considering validation model as well
> -
>
> Key: SLING-6515
> URL: https://issues.apache.org/jira/browse/SLING-6515
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Validation 1.0.0
>
> Attachments: SLING-6515-v01.patch
>
>
> It should be possible to optionally enable a Sling Post Processor which 
> validates the incoming parameters against a validation model. In case the 
> incoming parameters are not valid, there must be an error response. 



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

[jira] [Resolved] (SLING-6515) Sling Post Processor considering validation model as well

[Konrad Windszus (JIRA)]

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

Konrad Windszus resolved SLING-6515.

   Resolution: Fixed
Fix Version/s: Sling Models Validation Impl 1.0.0

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

> Sling Post Processor considering validation model as well
> -
>
> Key: SLING-6515
> URL: https://issues.apache.org/jira/browse/SLING-6515
> Project: Sling
>  Issue Type: Improvement
>  Components: Validation
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Sling Models Validation Impl 1.0.0
>
> Attachments: SLING-6515-v01.patch
>
>
> It should be possible to optionally enable a Sling Post Processor which 
> validates the incoming parameters against a validation model. In case the 
> incoming parameters are not valid, there must be an error response. 



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

Re: [RT] Configurationless Sling?

[Carsten Ziegeler]

Oliver Lietz wrote
> On Wednesday 29 March 2017 08:00:27 Carsten Ziegeler wrote:
>> Oliver Lietz wrote
>>
 It would be good if we have this description only once in our code base
 and not several times and can then generate different artifacts (if
 needed) out of it.
>>>
>>> Right, but I'm pretty sure I raised my concerns generating Karaf Features
>>> and Configurations (and repoinit statements) from provisioning model
>>> already.
>>>
>>> * Launchpad is _unstable_ most of the time (using snapshots mostly) while
>>> Karaf Features are _stable_ (only a few snapshots left). Launchpad is in
>>> fact the test bed for AEM, but Sling Karaf aims at good user experience
>>> and production readiness.
>>
>> Well, we decided to not use snapshot dependencies in launchpad anymore.
>> It just has not happened yet. But I think we should start directly after
>> the release of Sling 9. I didn't say we should use Launchpad as the
>> base, I said we should use the same source which probably is a
>> provisioning model. Launchpad's only purpose is to get people easily
>> started with Sling, nothing less but also nothing more.
>>
>>> * There are much more and finer grained features in Karaf than in
>>> Launchpad.
>> I don't want to be pedantic, but these things are not *in* Karaf. The
>> features are defined in Sling and can be consumed by Karaf.
> 
> Sorry, I don't get your point here.
> * in Karaf: /trunk/karaf/org.apache.sling.karaf-features/src/main/feature
>  (around 70)
> * in Launchpad:  /trunk/launchpad/builder/src/main/provisioning
> [feature name=...] (around 10)
> 
> Well, (re)usable features *for* Karaf or Launchpad instead of *in*?

I was just trying to emphasize that the source for this is not in the
Karaf project, it is in *our* svn. But I think I slightly missunderstood
you and as mentioned was too pedantic. :(

> 
>> And I don't
>> see any reason why we can't describe these things with a provisioning
>> model and a) reference it in Launchpad and b) generate a Karaf feature
>> out of it.
>>
>> The only potentially missing feature are dependencies (as you note
>> below). I'll think we should rethink the format of the provisioning
>> model anyway and with that we could add dependency handling. The Karaf
>> feature XML is unfortunately not suited for our needs as it's not
>> possible to add other artifact types and especially not possible to add
>> things like repo init.
> 
> Not sure which artifacts you have in mind, but e.g. Pax Web pulls in its 
> jetty.xml with configfile. That should be possible with repoinit files also.
> And I guess we can evolve the Karaf Feature format as we can evolve the 
> provisioning model when we say what's missing.
> 

I can provide a list of things missing:
- inheritance of features in contrast to dependencies - but maybe that
is possible in Karaf
- framework properties
- other artifacts than bundles, e.g. content packages, sub systems etc.
- additional free form sections for things like repo init or sub system
definitions etc.
- usage of the new JSON format for configurations as defined by R7

>From the top of my head, that's all

Carsten


 

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

Re: [VOTE] Release Apache Sling File System Resource Provider 2.0.0, File System Resource Provider 1.3.0

[Oliver Lietz]

On Monday 27 March 2017 16:21:49 Stefan Seifert wrote:
> Hi,
> 
> Apache Sling File System Resource Provider 2.0.0  (3 issues)
> https://issues.apache.org/jira/browse/SLING/fixforversion/12339777

+1 (depends now on Jackrabbit, would prefer embedding 
org.apache.jackrabbit.util.ISO8601 like we do in other bundles, e.g. event)

> Apache Sling File System Resource Provider 1.3.0  (2 issues)
> https://issues.apache.org/jira/browse/SLING/fixforversion/12338947

+1

O.

Re: Parent 30 breaks maven-scr-plugin

[Konrad Windszus]

> On 29 Mar 2017, at 10:45, Carsten Ziegeler  wrote:
> 
> Konrad Windszus wrote
>> 
>>> On 29 Mar 2017, at 10:29, Oliver Lietz  wrote:
>>> 
>>> On Wednesday 29 March 2017 08:44:59 Konrad Windszus wrote:
 It seems that parent 30 breaks the usage of the maven-scr-plugin. With 29 
 it
 works. When looking at the history of the parent pom.xml
 (https://github.com/apache/sling/commits/trunk/parent/pom.xml) I don't
 really see the reason for that. If I understand correctly reverting to
 parent 29 makes everything work as before. Although I do agree that we
 should migrate all modules in the future towards OSGi annotations and get
 rid of the maven-scr-plugin, having a broken maven-scr-plugin integration
 in parent 30 feels like a regression to me. Does anyone have a clue what
 the issue is with parent 30 here?
>>> 
>>> I guess it's one of SLING-6246, SLING-6532 or SLING-6533.
>> 
>> The latter two should lead to failures at compile time already (if e.g. the 
>> SCR annotations can no longer be resolved).
>> If it is SLING-6246 that sounds like a major regression in the 
>> maven-scr-plugin itself then, which is probably worth investigating.
> 
> The problem is that many poms have the scr annotations as an explicit
> dependency. So when updating to parent 30 you still have that dependency
> and don't get compilation problems
> 
Right, but that shouldn't cause the regression either. So most probably the 
updated version of the maven-scr-plugin is just not working correctly.
> 
> Carsten
> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Apache Sling Service User Mapper 1.2.6

[Oliver Lietz]

On Monday 27 March 2017 10:41:23 Carsten Ziegeler wrote:
> Hi,
> 
> We solved 1 issues in this release:
> 
> https://issues.apache.org/jira/browse/SLING-6555

+1

O.

Re: [VOTE] Release Apache Sling ResourceResolver 1.5.22

[Oliver Lietz]

On Monday 27 March 2017 07:18:26 Carsten Ziegeler wrote:
> Hi,
> 
> We solved 1 issues in this release:
> 
> https://issues.apache.org/jira/browse/SLING-6710

+1

O.

[jira] [Comment Edited] (SLING-6739) split sling.event into event.api and event.impl

[Stefan Egli (JIRA)]

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

Stefan Egli edited comment on SLING-6739 at 3/29/17 8:49 AM:
-

h6. step 3: initial adjustment of event/api/pom.xml, removing of non applicable 
files (http://svn.apache.org/viewvc?rev=1789298=rev)
Also switched back to parent 29


was (Author: egli):
h6. step 3: initial adjustment of event/api/pom.xml, removing of non applicable 
files (http://svn.apache.org/viewvc?rev=1789298=rev)

> split sling.event into event.api and event.impl
> ---
>
> Key: SLING-6739
> URL: https://issues.apache.org/jira/browse/SLING-6739
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Event 4.2.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> Currently sling.event contains both API and implementation. In order to 
> support different implementation variants it would be good to have two 
> separate bundles, one containing just the API and one with the (current) 
> implementation. I would suggest to create
> bundles/extensions/event-api
> bundles/extensions/event-impl
> and to remove the current
> bundles/extensions/event



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

[jira] [Commented] (SLING-6739) split sling.event into event.api and event.impl

[Stefan Egli (JIRA)]

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

Stefan Egli commented on SLING-6739:


h6. step 3: initial adjustment of event/api/pom.xml, removing of non applicable 
files (http://svn.apache.org/viewvc?rev=1789298=rev)

> split sling.event into event.api and event.impl
> ---
>
> Key: SLING-6739
> URL: https://issues.apache.org/jira/browse/SLING-6739
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Event 4.2.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> Currently sling.event contains both API and implementation. In order to 
> support different implementation variants it would be good to have two 
> separate bundles, one containing just the API and one with the (current) 
> implementation. I would suggest to create
> bundles/extensions/event-api
> bundles/extensions/event-impl
> and to remove the current
> bundles/extensions/event



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

Re: Parent 30 breaks maven-scr-plugin

[Carsten Ziegeler]

Konrad Windszus wrote
> 
>> On 29 Mar 2017, at 10:29, Oliver Lietz  wrote:
>>
>> On Wednesday 29 March 2017 08:44:59 Konrad Windszus wrote:
>>> It seems that parent 30 breaks the usage of the maven-scr-plugin. With 29 it
>>> works. When looking at the history of the parent pom.xml
>>> (https://github.com/apache/sling/commits/trunk/parent/pom.xml) I don't
>>> really see the reason for that. If I understand correctly reverting to
>>> parent 29 makes everything work as before. Although I do agree that we
>>> should migrate all modules in the future towards OSGi annotations and get
>>> rid of the maven-scr-plugin, having a broken maven-scr-plugin integration
>>> in parent 30 feels like a regression to me. Does anyone have a clue what
>>> the issue is with parent 30 here?
>>
>> I guess it's one of SLING-6246, SLING-6532 or SLING-6533.
> 
> The latter two should lead to failures at compile time already (if e.g. the 
> SCR annotations can no longer be resolved).
> If it is SLING-6246 that sounds like a major regression in the 
> maven-scr-plugin itself then, which is probably worth investigating.

The problem is that many poms have the scr annotations as an explicit
dependency. So when updating to parent 30 you still have that dependency
and don't get compilation problems


 Carsten

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

Re: [RT] Configurationless Sling?

[Carsten Ziegeler]

Oliver Lietz wrote
> On Tuesday 28 March 2017 15:01:47 Carsten Ziegeler wrote:
>> Julian Sedding wrote
>>
>>> Hi Carsten
>>>
>>> I fully agree with the intention of your email.
>>>
>>> As a convention for service users, would it make sense to use the
>>> bundle-symbolic-name as the user-ID (or principal-name)? If we can
>>> detect the class name of the service that's creating the
>>> Session/ResourceResolver, we could even use the fully qualified
>>> classname. Not sure that there is a way other than inspecting the call
>>> stack, however.
>>
>> Yes, I guess that is maybe somehow doable. We could use the bundle
>> symbolic name and the sub service information. That should be enough. We
>> don't need the class name. It's very unlikely that users with that name
>> exist out of the box. That would free us from most of the mapping
>> configurations.
>>
>> What do others think?
>>
>>> IIUC the service user mapping is only one part of the story. The other
>>> part are the permissions required by a service user. I suppose
>>> permissions are also a kind of configuration? So how would we go about
>>> having a working default permission setup? Without that, a convention
>>> for service users becomes kind of pointless. Or am I missing
>>> something?
>>
>> Yes, we need the repoinit stuff for this, actually we need repoinit for
>> two things: setting up a user (we shouldn't do this automatically) and
>> setting up the ACLs.
> 
> Having a service user per bundle shifts away the amount of configuration from 
> service user mapping to repoinit only, right?

That would only be the default configuration, you can still deploy the
current configurations mapping several bundles to the same service user.
And - and that's my use case - think about running Sling without JCR, in
that case repoinit is not needed anyway.

Carsten


 

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

Re: Parent 30 breaks maven-scr-plugin

[Konrad Windszus]

> On 29 Mar 2017, at 10:29, Oliver Lietz  wrote:
> 
> On Wednesday 29 March 2017 08:44:59 Konrad Windszus wrote:
>> It seems that parent 30 breaks the usage of the maven-scr-plugin. With 29 it
>> works. When looking at the history of the parent pom.xml
>> (https://github.com/apache/sling/commits/trunk/parent/pom.xml) I don't
>> really see the reason for that. If I understand correctly reverting to
>> parent 29 makes everything work as before. Although I do agree that we
>> should migrate all modules in the future towards OSGi annotations and get
>> rid of the maven-scr-plugin, having a broken maven-scr-plugin integration
>> in parent 30 feels like a regression to me. Does anyone have a clue what
>> the issue is with parent 30 here?
> 
> I guess it's one of SLING-6246, SLING-6532 or SLING-6533.

The latter two should lead to failures at compile time already (if e.g. the SCR 
annotations can no longer be resolved).
If it is SLING-6246 that sounds like a major regression in the maven-scr-plugin 
itself then, which is probably worth investigating.
> 
> 
> O.
> 
>> Thanks,
>> Konrad
> 

Re: Parent 30 breaks maven-scr-plugin

[Oliver Lietz]

On Wednesday 29 March 2017 08:44:59 Konrad Windszus wrote:
> It seems that parent 30 breaks the usage of the maven-scr-plugin. With 29 it
> works. When looking at the history of the parent pom.xml
> (https://github.com/apache/sling/commits/trunk/parent/pom.xml) I don't
> really see the reason for that. If I understand correctly reverting to
> parent 29 makes everything work as before. Although I do agree that we
> should migrate all modules in the future towards OSGi annotations and get
> rid of the maven-scr-plugin, having a broken maven-scr-plugin integration
> in parent 30 feels like a regression to me. Does anyone have a clue what
> the issue is with parent 30 here?

I guess it's one of SLING-6246, SLING-6532 or SLING-6533.

O.

> Thanks,
> Konrad

Re: [RT] Configurationless Sling?

[Oliver Lietz]

On Tuesday 28 March 2017 15:01:47 Carsten Ziegeler wrote:
> Julian Sedding wrote
> 
> > Hi Carsten
> > 
> > I fully agree with the intention of your email.
> > 
> > As a convention for service users, would it make sense to use the
> > bundle-symbolic-name as the user-ID (or principal-name)? If we can
> > detect the class name of the service that's creating the
> > Session/ResourceResolver, we could even use the fully qualified
> > classname. Not sure that there is a way other than inspecting the call
> > stack, however.
> 
> Yes, I guess that is maybe somehow doable. We could use the bundle
> symbolic name and the sub service information. That should be enough. We
> don't need the class name. It's very unlikely that users with that name
> exist out of the box. That would free us from most of the mapping
> configurations.
> 
> What do others think?
> 
> > IIUC the service user mapping is only one part of the story. The other
> > part are the permissions required by a service user. I suppose
> > permissions are also a kind of configuration? So how would we go about
> > having a working default permission setup? Without that, a convention
> > for service users becomes kind of pointless. Or am I missing
> > something?
> 
> Yes, we need the repoinit stuff for this, actually we need repoinit for
> two things: setting up a user (we shouldn't do this automatically) and
> setting up the ACLs.

Having a service user per bundle shifts away the amount of configuration from 
service user mapping to repoinit only, right?
Currently we have several bundles using one service user only, e.g. sling-
scripting oder sling-readall.

Regards,
O.

> Carsten
> 
> > Regards
> > Julian
> > 
> > On Mon, Mar 27, 2017 at 4:02 PM, Carsten Ziegeler  
wrote:
> >> Hi,
> >> 
> >> for a long time we have tried to use sensible defaults for all of our
> >> configurations. This allows our users to run a default Sling without any
> >> additional configuration (it should even be possible to run it without a
> >> Configuration Admin service available - but that's another story).
> >> 
> >> While we were pretty successful with this, we simply blew it with the
> >> move from login administrative to service users. A lot of the (core)
> >> modules now use service users and these require a configured mapping in
> >> order to work properly. While for example the servlets resolver
> >> previously did not require any configuration, it requires at least the
> >> mapping. Which in turn means you can't simply use that module as-is.
> >> 
> >> Switching to service users is of course a good idea but I'm wondering if
> >> we can find a way to get back to a configurationless Sling again?
> >> 
> >> Clearly we don't want to the mapping to be part of the bundles using the
> >> service users.
> >> 
> >> One possible solution would be an out of the box bundle with the
> >> necessary repo init and configurations. This would cover the core
> >> bundles like servlets resolver and resource resolver.
> >> 
> >> But maybe there is a better option?
> >> 
> >> Regards
> >> Carsten
> >> --
> >> Carsten Ziegeler
> >> Adobe Research Switzerland
> >> cziege...@apache.org

Re: [RT] Configurationless Sling?

[Oliver Lietz]

On Wednesday 29 March 2017 08:00:27 Carsten Ziegeler wrote:
> Oliver Lietz wrote
> 
> >> It would be good if we have this description only once in our code base
> >> and not several times and can then generate different artifacts (if
> >> needed) out of it.
> > 
> > Right, but I'm pretty sure I raised my concerns generating Karaf Features
> > and Configurations (and repoinit statements) from provisioning model
> > already.
> > 
> > * Launchpad is _unstable_ most of the time (using snapshots mostly) while
> > Karaf Features are _stable_ (only a few snapshots left). Launchpad is in
> > fact the test bed for AEM, but Sling Karaf aims at good user experience
> > and production readiness.
> 
> Well, we decided to not use snapshot dependencies in launchpad anymore.
> It just has not happened yet. But I think we should start directly after
> the release of Sling 9. I didn't say we should use Launchpad as the
> base, I said we should use the same source which probably is a
> provisioning model. Launchpad's only purpose is to get people easily
> started with Sling, nothing less but also nothing more.
> 
> > * There are much more and finer grained features in Karaf than in
> > Launchpad.
> I don't want to be pedantic, but these things are not *in* Karaf. The
> features are defined in Sling and can be consumed by Karaf.

Sorry, I don't get your point here.
* in Karaf: /trunk/karaf/org.apache.sling.karaf-features/src/main/feature
 (around 70)
* in Launchpad:  /trunk/launchpad/builder/src/main/provisioning
[feature name=...] (around 10)

Well, (re)usable features *for* Karaf or Launchpad instead of *in*?

> And I don't
> see any reason why we can't describe these things with a provisioning
> model and a) reference it in Launchpad and b) generate a Karaf feature
> out of it.
> 
> The only potentially missing feature are dependencies (as you note
> below). I'll think we should rethink the format of the provisioning
> model anyway and with that we could add dependency handling. The Karaf
> feature XML is unfortunately not suited for our needs as it's not
> possible to add other artifact types and especially not possible to add
> things like repo init.

Not sure which artifacts you have in mind, but e.g. Pax Web pulls in its 
jetty.xml with configfile. That should be possible with repoinit files also.
And I guess we can evolve the Karaf Feature format as we can evolve the 
provisioning model when we say what's missing.

Regards,
O.

> Regards
> Carsten
> 
> > * Every (Karaf) feature is backed by an integration test.
> > 
> > * Testing PaxExam's options and versions are already generated from
> > (Karaf)
> > features.
> > 
> > * The provisioning model does not support dependencies (yet).
> > 
> > I guess it takes only a few hours to create templates for generating
> > provisioning models from (Karaf) features and a few more to split into
> > separate files, but I'm more interested in filling the missing piece
> > regarding repoinit (and creating immutable/static instances from features
> > with Karaf Profiles).
> > 
> > Currently all repoinit statements from karaf-repoinit are executed when
> > installing feature sling-oak-tar:
> > 
> > https://github.com/apache/sling/blob/trunk/karaf/org.apache.sling.karaf-fe
> > atures/src/main/feature/feature.xml#L387
> > 
> > https://github.com/apache/sling/blob/trunk/karaf/org.apache.sling.karaf-co
> > nfigs/src/main/resources/org.apache.sling.jcr.repoinit.impl.RepositoryInit
> > ializer.config
> > 
> > references=[\
> > 
> >   "raw:classpath://org.apache.sling.karaf-repoinit/sling.txt",\
> >   "raw:classpath://org.apache.sling.karaf-repoinit/sling-discovery.txt",\
> >   "raw:classpath://org.apache.sling.karaf-repoinit/sling-event.txt",\
> >   "raw:classpath://org.apache.sling.karaf-repoinit/sling-i18n.txt",\
> >   "raw:classpath://org.apache.sling.karaf-repoinit/sling-installer-jcr.txt
> >   ",\
> >   "raw:classpath://org.apache.sling.karaf-repoinit/sling-scripting.txt",\
> >   "raw:classpath://org.apache.sling.karaf-repoinit/sling-validation.txt",\
> >   "raw:classpath://org.apache.sling.karaf-repoinit/sling-xss.txt"\
> > 
> > ]
> > 
> > It's obvious that having a (factory) component or other mechanism which is
> > able to execute statements in more than one batch makes sense.
> > 
> >> I think we should also split this up into a minimal set. For example I'm
> >> currently trying to get Sling running without JCR - in order to trim the
> >> dependencies down. And in that case I only need the service user mapping
> >> for some core bundles, no repo init etc.
> > 
> > The minimal set in Karaf is the feature sling:
> > 
> > https://github.com/apache/sling/blob/trunk/karaf/org.apache.sling.karaf-fe
> > atures/src/main/feature/feature.xml#L22
> > 
> > How do you want to create service users without repoinit?
> > 
> > Regards,
> > O.
> > 
> >> Regards
> >> Carsten

Re: [RT] Configurationless Sling?

[Carsten Ziegeler]

Karl Pauls wrote
> On Wed, Mar 29, 2017 at 8:54 AM, Bertrand Delacretaz
>  wrote:
>> On Tue, Mar 28, 2017 at 8:08 PM, Oliver Lietz  wrote:
>>> ...Launchpad is in fact the test bed for AEM...
>>
>> you mean Sling right?
>>
>> Launchpad with snapshots is required currently IMO, to catch
>> integration failures early by building launchpad/testing on snapshots.
> 
> Given my recent struggle with the org.json replacement I'd like to add
> that it would be good if we either try to do a better job in keeping
> the SNAPSHOTS current or have a way to generate a "most recent
> snapshots" launchpad on demand.
> 
That is exactly the idea: stable has no snapshot dependencies at all and
unstable uses SNAPSHOT for all Sling dependencies. And that's automatec

Carsten

> Right now, the launchpad is a mix of stable bundles (that either have
> newer releases or snapshots with changes) and current snapshots. That
> makes it hard to know what configuration passes the integration tests
> and its somewhat painful if you want to see if you broke something
> because if you happen to update a bundle from an old version (possibly
> several) to its latest SNAPSHOT it might cause failing tests
> completely unrelated to your changes (I lost almost half a day due to
> e.g. the servlets post bundle not providing its services due to the
> update to parent 30 which had nothing to do with my commons.json
> changes).
> 
> regards,
> 
> Karl
> 
>> -Bertrand
> 
> 
> 


 

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

Re: [RT] Configurationless Sling?

[Karl Pauls]

On Wed, Mar 29, 2017 at 8:54 AM, Bertrand Delacretaz
 wrote:
> On Tue, Mar 28, 2017 at 8:08 PM, Oliver Lietz  wrote:
>> ...Launchpad is in fact the test bed for AEM...
>
> you mean Sling right?
>
> Launchpad with snapshots is required currently IMO, to catch
> integration failures early by building launchpad/testing on snapshots.

Given my recent struggle with the org.json replacement I'd like to add
that it would be good if we either try to do a better job in keeping
the SNAPSHOTS current or have a way to generate a "most recent
snapshots" launchpad on demand.

Right now, the launchpad is a mix of stable bundles (that either have
newer releases or snapshots with changes) and current snapshots. That
makes it hard to know what configuration passes the integration tests
and its somewhat painful if you want to see if you broke something
because if you happen to update a bundle from an old version (possibly
several) to its latest SNAPSHOT it might cause failing tests
completely unrelated to your changes (I lost almost half a day due to
e.g. the servlets post bundle not providing its services due to the
update to parent 30 which had nothing to do with my commons.json
changes).

regards,

Karl

> -Bertrand



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

[jira] [Commented] (SLING-6739) split sling.event into event.api and event.impl

[Stefan Egli (JIRA)]

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

Stefan Egli commented on SLING-6739:


h6. step 1: svn renamed event to event-renamed-for-split and svn copied it to 
event/api and event/resource 
(http://svn.apache.org/viewvc?rev=1789290=rev):
{noformat}
svn mv event event-renamed-for-split
mkdir event
svn add event
cd event
svn cp ../event-renamed-for-split api
svn cp ../event-renamed-for-split resource
svn commit -m "SLING-6739 : copied bundles/extensions/event into event/api and 
event/resources - done via svn cp to preserve history of both new parts"
{noformat}
h6. step 2: removed event-renamed-for-split 
(http://svn.apache.org/viewvc?rev=1789291=rev)
{noformat}
svn rm event-renamed-for-split
svn commit -m "SLING-6739 : removed temp directory event-renamed-for-split"
{noformat}

> split sling.event into event.api and event.impl
> ---
>
> Key: SLING-6739
> URL: https://issues.apache.org/jira/browse/SLING-6739
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Event 4.2.2
>Reporter: Stefan Egli
>Assignee: Stefan Egli
>
> Currently sling.event contains both API and implementation. In order to 
> support different implementation variants it would be good to have two 
> separate bundles, one containing just the API and one with the (current) 
> implementation. I would suggest to create
> bundles/extensions/event-api
> bundles/extensions/event-impl
> and to remove the current
> bundles/extensions/event



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

Re: [event] splitting sling.event into API and Implementation bundle

[Stefan Egli]

On 28/03/17 18:28, "Carsten Ziegeler"  wrote:

>What about event.resource ? Its an implementation based on the resource
>api
>
>Or event.resource.impl :)

event/resource sounds good to me.


I'll go ahead with the split and will come back when finished.

You'll have to refresh the project structure in your IDEs afterwards.

Cheers,
Stefan

Re: [RT] Configurationless Sling?

[Carsten Ziegeler]

Bertrand Delacretaz wrote
> On Wed, Mar 29, 2017 at 8:00 AM, Carsten Ziegeler  
> wrote:
>> ...we decided to not use snapshot dependencies in launchpad anymore...
> 
> Really? I know my memory is weak for those kinds of things but I don't
> remember that, do you have a link to that decision?
> 
> What I remember is aiming to have two Launchpads, stable (no
> snapshots) and unstable.
> 
Right, that's exactly what I meant :) We have a stable launchpad (no
snapshots) and in addition the unstable one.
The "default" (if you build launchpad) will be the stable one.

Carsten

 

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

Re: Parent 30 breaks maven-scr-plugin

[Carsten Ziegeler]

Konrad Windszus wrote
> It seems that parent 30 breaks the usage of the maven-scr-plugin. With 29 it 
> works. When looking at the history of the parent pom.xml 
> (https://github.com/apache/sling/commits/trunk/parent/pom.xml) I don't really 
> see the reason for that.
> If I understand correctly reverting to parent 29 makes everything work as 
> before. Although I do agree that we should migrate all modules in the future 
> towards OSGi annotations and get rid of the maven-scr-plugin, having a broken 
> maven-scr-plugin integration in parent 30 feels like a regression to me. Does 
> anyone have a clue what the issue is with parent 30 here?


I don't know the exact reason, but while this could be considered a
regression, I don't think we should regard it as one.
The solution is simple: don't blindly update to parent pom 30. There is
no need atm to do so. It's good to have a parent pom which shows latest
best practice and doesn't use the obsolete stuff anymore.

If you move to the R6 annotations, move to version 30. In the last weeks
I've already converted several projects, others have done similar. So
it's only a matter of time until we have migrated all projects.

Regards

 Carsten

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

Re: [RT] Configurationless Sling?

[Bertrand Delacretaz]

On Tue, Mar 28, 2017 at 8:08 PM, Oliver Lietz  wrote:
> ...Launchpad is in fact the test bed for AEM...

you mean Sling right?

Launchpad with snapshots is required currently IMO, to catch
integration failures early by building launchpad/testing on snapshots.

-Bertrand

Re: [RT] Configurationless Sling?

[Bertrand Delacretaz]

On Wed, Mar 29, 2017 at 8:00 AM, Carsten Ziegeler  wrote:
> ...we decided to not use snapshot dependencies in launchpad anymore...

Really? I know my memory is weak for those kinds of things but I don't
remember that, do you have a link to that decision?

What I remember is aiming to have two Launchpads, stable (no
snapshots) and unstable.

Karaf features can be derived from the former, and testing from the latter.

-Bertrand

Parent 30 breaks maven-scr-plugin

[Konrad Windszus]

It seems that parent 30 breaks the usage of the maven-scr-plugin. With 29 it 
works. When looking at the history of the parent pom.xml 
(https://github.com/apache/sling/commits/trunk/parent/pom.xml) I don't really 
see the reason for that.
If I understand correctly reverting to parent 29 makes everything work as 
before. Although I do agree that we should migrate all modules in the future 
towards OSGi annotations and get rid of the maven-scr-plugin, having a broken 
maven-scr-plugin integration in parent 30 feels like a regression to me. Does 
anyone have a clue what the issue is with parent 30 here?
Thanks,
Konrad

Re: repository.apache.org slow?

[Robert Munteanu]

On Tue, 2017-03-07 at 18:36 +0200, Robert Munteanu wrote:
> Hi,
> 
> Is repository.apache.org slow for anyone else? I am waiting 5+
> minutes
> for the staging script to download the starged artifacts. Also the
> web
> UI feels slow.
> 
> Robert

Seems to be an intermittent issue when connect()-ing to the host,
either via HTTP or HTTPS. Filed

  https://issues.apache.org/jira/browse/INFRA-13776

Robert

[jira] [Updated] (SLING-6741) Migrate to R6 annotations, clean up dependencies

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-6741:

Summary: Migrate to R6 annotations, clean up dependencies  (was: i18n build 
fails with "ServiceLookup gave up" during tests)

> Migrate to R6 annotations, clean up dependencies
> 
>
> Key: SLING-6741
> URL: https://issues.apache.org/jira/browse/SLING-6741
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Reporter: Karl Pauls
> Fix For: i18n 2.5.10
>
>
> The build works fine when switching to sling parent 29.



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

[jira] [Resolved] (SLING-6741) Migrate to R6 annotations, clean up dependencies

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-6741.
-
Resolution: Fixed

Fixed by switching to R6 annotations, back to parent pom 30

> Migrate to R6 annotations, clean up dependencies
> 
>
> Key: SLING-6741
> URL: https://issues.apache.org/jira/browse/SLING-6741
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Reporter: Karl Pauls
>Assignee: Carsten Ziegeler
> Fix For: i18n 2.5.10
>
>
> The build works fine when switching to sling parent 29.



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

[jira] [Assigned] (SLING-6741) Migrate to R6 annotations, clean up dependencies

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reassigned SLING-6741:
---

Assignee: Carsten Ziegeler

> Migrate to R6 annotations, clean up dependencies
> 
>
> Key: SLING-6741
> URL: https://issues.apache.org/jira/browse/SLING-6741
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Reporter: Karl Pauls
>Assignee: Carsten Ziegeler
> Fix For: i18n 2.5.10
>
>
> The build works fine when switching to sling parent 29.



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

[jira] [Updated] (SLING-6741) i18n build fails with "ServiceLookup gave up" during tests

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-6741:

Fix Version/s: i18n 2.5.10

> i18n build fails with "ServiceLookup gave up" during tests
> --
>
> Key: SLING-6741
> URL: https://issues.apache.org/jira/browse/SLING-6741
> Project: Sling
>  Issue Type: Bug
>  Components: i18n
>Reporter: Karl Pauls
> Fix For: i18n 2.5.10
>
>
> The build works fine when switching to sling parent 29.



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

[jira] [Resolved] (SLING-6742) Servlets post is broken with parent 30

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-6742.
-
Resolution: Won't Fix

I switched to R6 annotations as part of SLING-6721

> Servlets post is broken with parent 30
> --
>
> Key: SLING-6742
> URL: https://issues.apache.org/jira/browse/SLING-6742
> Project: Sling
>  Issue Type: Bug
>  Components: Servlets
>Reporter: Karl Pauls
>
> The issue is that the maven-scr-plugin doesn't get configured with sling 30. 
> That makes it so that the service component xml files don't get generated 
> properly. 
> I switched to sling 29 for now. 



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

Re: [RT] Configurationless Sling?

[Carsten Ziegeler]

Oliver Lietz wrote
>> It would be good if we have this description only once in our code base
>> and not several times and can then generate different artifacts (if
>> needed) out of it.
> 
> Right, but I'm pretty sure I raised my concerns generating Karaf Features and 
> Configurations (and repoinit statements) from provisioning model already.
> 
> * Launchpad is _unstable_ most of the time (using snapshots mostly) while 
> Karaf Features are _stable_ (only a few snapshots left). Launchpad is in fact 
> the test bed for AEM, but Sling Karaf aims at good user experience and 
> production readiness.

Well, we decided to not use snapshot dependencies in launchpad anymore.
It just has not happened yet. But I think we should start directly after
the release of Sling 9. I didn't say we should use Launchpad as the
base, I said we should use the same source which probably is a
provisioning model. Launchpad's only purpose is to get people easily
started with Sling, nothing less but also nothing more.

> 
> * There are much more and finer grained features in Karaf than in Launchpad.

I don't want to be pedantic, but these things are not *in* Karaf. The
features are defined in Sling and can be consumed by Karaf. And I don't
see any reason why we can't describe these things with a provisioning
model and a) reference it in Launchpad and b) generate a Karaf feature
out of it.

The only potentially missing feature are dependencies (as you note
below). I'll think we should rethink the format of the provisioning
model anyway and with that we could add dependency handling. The Karaf
feature XML is unfortunately not suited for our needs as it's not
possible to add other artifact types and especially not possible to add
things like repo init.

Regards
Carsten

> 
> * Every (Karaf) feature is backed by an integration test.
> 
> * Testing PaxExam's options and versions are already generated from (Karaf) 
> features.
> 
> * The provisioning model does not support dependencies (yet).
> 
> I guess it takes only a few hours to create templates for generating 
> provisioning models from (Karaf) features and a few more to split into 
> separate files, but I'm more interested in filling the missing piece 
> regarding 
> repoinit (and creating immutable/static instances from features with Karaf 
> Profiles).
> 
> Currently all repoinit statements from karaf-repoinit are executed when 
> installing feature sling-oak-tar:
> 
> https://github.com/apache/sling/blob/trunk/karaf/org.apache.sling.karaf-features/src/main/feature/feature.xml#L387
> 
> https://github.com/apache/sling/blob/trunk/karaf/org.apache.sling.karaf-configs/src/main/resources/org.apache.sling.jcr.repoinit.impl.RepositoryInitializer.config
> 
> references=[\
>   "raw:classpath://org.apache.sling.karaf-repoinit/sling.txt",\
>   "raw:classpath://org.apache.sling.karaf-repoinit/sling-discovery.txt",\
>   "raw:classpath://org.apache.sling.karaf-repoinit/sling-event.txt",\
>   "raw:classpath://org.apache.sling.karaf-repoinit/sling-i18n.txt",\
>   "raw:classpath://org.apache.sling.karaf-repoinit/sling-installer-jcr.txt",\
>   "raw:classpath://org.apache.sling.karaf-repoinit/sling-scripting.txt",\
>   "raw:classpath://org.apache.sling.karaf-repoinit/sling-validation.txt",\
>   "raw:classpath://org.apache.sling.karaf-repoinit/sling-xss.txt"\
> ]
> 
> It's obvious that having a (factory) component or other mechanism which is 
> able to execute statements in more than one batch makes sense.
> 
>> I think we should also split this up into a minimal set. For example I'm
>> currently trying to get Sling running without JCR - in order to trim the
>> dependencies down. And in that case I only need the service user mapping
>> for some core bundles, no repo init etc.
> 
> The minimal set in Karaf is the feature sling:
> 
> https://github.com/apache/sling/blob/trunk/karaf/org.apache.sling.karaf-features/src/main/feature/feature.xml#L22
> 
> How do you want to create service users without repoinit?
> 
> Regards,
> O.
> 
>> Regards
>> Carsten
> 
> 


 

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