[jira] [Commented] (SLING-5984) Queries with findResources

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-5984:
---

this would be a nice addition to the resource provider.
if you could come up with a patch (and integration test) it would speed up 
things...

please note there were also thoughts about a generic query support in the sling 
resource API independently of the underlying data store - but this is currently 
only in draft status and not yet part of the sling resource or resource 
provider APIs: SLING-4752

> Queries with findResources
> --
>
> Key: SLING-5984
> URL: https://issues.apache.org/jira/browse/SLING-5984
> Project: Sling
>  Issue Type: Improvement
>  Components: NoSQL
>Affects Versions: NoSQL MongoDB Resource Provider 1.1.0
>Reporter: Christoph Thodte
>
> Query-method in in ResourceProvider for MongoDB is not implemented:
> https://github.com/apache/sling/blob/trunk/contrib/nosql/generic/src/main/java/org/apache/sling/nosql/generic/adapter/AbstractNoSqlAdapter.java
> and 
> https://github.com/apache/sling/blob/trunk/contrib/nosql/mongodb-resourceprovider/src/main/java/org/apache/sling/nosql/mongodb/resourceprovider/impl/MongoDBNoSqlAdapter.java
> I think that's an additional task to implement this method. The MongoDB Query 
> syntax should be supported. 
> What do you think about?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6113) JcrProviderStateFactory needs a reference to the bundle that's using it

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-6113:


bq. That's already available in the map as ResourceProvider.AUTH_SERVICE_BUNDLE

Thanks for the info - that AUTH_SERVICE_BUNDLE is currently only provided for 
calls to {{ResourceResolverFactory.getServiceResourceResolver}}, but I see that 
{{ResourceResolverFactoryImpl}} does have the using bundle info, so I'll be 
able to use that for admin resource resolvers as well.

> JcrProviderStateFactory needs a reference to the bundle that's using it
> ---
>
> Key: SLING-6113
> URL: https://issues.apache.org/jira/browse/SLING-6113
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR Resource 2.8.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> This is needed to implement the SLING-5135 login admin whitelist: the 
> JcrProviderStateFactory needs a reference to the bundle that wants to open an 
> admin session or create an admin resource resolver, to be able to pass it 
> through the whitelist once that's implemented



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6114) Support nested configurations in configurated locations

[ASF GitHub Bot (JIRA)]

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

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

Github user stefanseifert closed the pull request at:

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


> Support nested configurations in configurated locations
> ---
>
> Key: SLING-6114
> URL: https://issues.apache.org/jira/browse/SLING-6114
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> Let's assume you have a content like this:
> /content/level1/level2[@sling-config-ref='/conf/project/sub']
> and configurations
> /conf/project/something
> /conf/project/sub/something-else
> the default path strategy should directly go up the hierarchy in the 
> configured location (/conf in this case), so /conf/project/sub is tried 
> first, then /conf/project and then the other configured paths.
> The only question is if you have
> /libs/conf/project/sub
> is this handled before /conf/project or after?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-6114) Support nested configurations in configurated locations

[Stefan Seifert (JIRA)]

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

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

Completed: At revision: 1763789  


> Support nested configurations in configurated locations
> ---
>
> Key: SLING-6114
> URL: https://issues.apache.org/jira/browse/SLING-6114
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> Let's assume you have a content like this:
> /content/level1/level2[@sling-config-ref='/conf/project/sub']
> and configurations
> /conf/project/something
> /conf/project/sub/something-else
> the default path strategy should directly go up the hierarchy in the 
> configured location (/conf in this case), so /conf/project/sub is tried 
> first, then /conf/project and then the other configured paths.
> The only question is if you have
> /libs/conf/project/sub
> is this handled before /conf/project or after?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] sling pull request #179: SLING-6114 Support nested configurations in configu...

[stefanseifert]

Github user stefanseifert closed the pull request at:

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


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

[jira] [Commented] (SLING-6114) Support nested configurations in configurated locations

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6114:
-

[~sseif...@pro-vision.de] Yed I think that makes sense, just having /conf and 
the other paths are ordered fallbacks

> Support nested configurations in configurated locations
> ---
>
> Key: SLING-6114
> URL: https://issues.apache.org/jira/browse/SLING-6114
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> Let's assume you have a content like this:
> /content/level1/level2[@sling-config-ref='/conf/project/sub']
> and configurations
> /conf/project/something
> /conf/project/sub/something-else
> the default path strategy should directly go up the hierarchy in the 
> configured location (/conf in this case), so /conf/project/sub is tried 
> first, then /conf/project and then the other configured paths.
> The only question is if you have
> /libs/conf/project/sub
> is this handled before /conf/project or after?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6114) Support nested configurations in configurated locations

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6114:
---

proposal: https://github.com/apache/sling/pull/179

some remarks:
* implementation works as described above including the special usecase
* i saw that the your assumption from the ticket description which i answered 
in [this 
comment|https://issues.apache.org/jira/browse/SLING-6114?focusedCommentId=1129#comment-1129]
 was somewhat implemented already at least how the osgi config was defined 
previously:
** it defined allowed path /conf, /apps/conf, /libs/conf - with any path 
hierarchy
** so it would be possible to store deep hierarchy of config below /apps/conf 
and /libs/conf for this whitelist, although the remaining implementation did 
not support this
** and it would be possible for a content resource to reference a config 
resource below or equals /apps/conf and /libs/conf and /conf/global directly, 
which should not be the case in my opinion - these are only fallback path, and 
referencing a global config directly makes no sense when using context-aware 
config without any context
* so i changed the implementation to allow only one single (configurable) path 
where configuration are stored in (default: /conf), and allowing only 
references to resources below this path (i will update the PR to disallow 
references to /conf/global) as well.

[~cziegeler] what is your opinion on this whitelist/reference aspect?

> Support nested configurations in configurated locations
> ---
>
> Key: SLING-6114
> URL: https://issues.apache.org/jira/browse/SLING-6114
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> Let's assume you have a content like this:
> /content/level1/level2[@sling-config-ref='/conf/project/sub']
> and configurations
> /conf/project/something
> /conf/project/sub/something-else
> the default path strategy should directly go up the hierarchy in the 
> configured location (/conf in this case), so /conf/project/sub is tried 
> first, then /conf/project and then the other configured paths.
> The only question is if you have
> /libs/conf/project/sub
> is this handled before /conf/project or after?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] sling pull request #179: SLING-6114 Support nested configurations in configu...

[stefanseifert]

GitHub user stefanseifert opened a pull request:

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

SLING-6114 Support nested configurations in configurated locations



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/stefanseifert/sling 
feature/SLING-6114-nested-conf-configs

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/179.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #179


commit ecb73376117af30bf99c1c2aff51e00737d8f56b
Author: sseifert 
Date:   2016-10-07T15:00:40Z

SLING-6114 Support nested configurations in configured locations

commit b43fd8daebf5a801007a1df0eec69ceacb4019a9
Author: sseifert 
Date:   2016-10-07T15:12:21Z

SLING-6114 Allow only one single (configurable) path to store 
configurations in, and to reference to




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

[jira] [Commented] (SLING-6114) Support nested configurations in configurated locations

[ASF GitHub Bot (JIRA)]

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

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

GitHub user stefanseifert opened a pull request:

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

SLING-6114 Support nested configurations in configurated locations



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/stefanseifert/sling 
feature/SLING-6114-nested-conf-configs

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/179.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #179


commit ecb73376117af30bf99c1c2aff51e00737d8f56b
Author: sseifert 
Date:   2016-10-07T15:00:40Z

SLING-6114 Support nested configurations in configured locations

commit b43fd8daebf5a801007a1df0eec69ceacb4019a9
Author: sseifert 
Date:   2016-10-07T15:12:21Z

SLING-6114 Allow only one single (configurable) path to store 
configurations in, and to reference to




> Support nested configurations in configurated locations
> ---
>
> Key: SLING-6114
> URL: https://issues.apache.org/jira/browse/SLING-6114
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> Let's assume you have a content like this:
> /content/level1/level2[@sling-config-ref='/conf/project/sub']
> and configurations
> /conf/project/something
> /conf/project/sub/something-else
> the default path strategy should directly go up the hierarchy in the 
> configured location (/conf in this case), so /conf/project/sub is tried 
> first, then /conf/project and then the other configured paths.
> The only question is if you have
> /libs/conf/project/sub
> is this handled before /conf/project or after?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6114) Support nested configurations in configurated locations

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6114:
-

Yes I think case #1 is what you would expect

> Support nested configurations in configurated locations
> ---
>
> Key: SLING-6114
> URL: https://issues.apache.org/jira/browse/SLING-6114
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> Let's assume you have a content like this:
> /content/level1/level2[@sling-config-ref='/conf/project/sub']
> and configurations
> /conf/project/something
> /conf/project/sub/something-else
> the default path strategy should directly go up the hierarchy in the 
> configured location (/conf in this case), so /conf/project/sub is tried 
> first, then /conf/project and then the other configured paths.
> The only question is if you have
> /libs/conf/project/sub
> is this handled before /conf/project or after?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6114) Support nested configurations in configurated locations

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6114:
---

there is one special case - consider this scenario

{noformat}
/content/level1[@config-ref='/conf/a1/a2']
/content/level1/level2[@config-ref='/conf/b1/b2']
{noformat}

what is the expected lookup order for {{/content/level1/level2}}?

# {noformat}
/conf/b1/b2
/conf/b1
/conf/a1/a2
/conf/a1
/conf/global
/apps/conf
/libs/conf
{noformat}
# {noformat}
/conf/b1/b2
/conf/a1/a2
/conf/b1
/conf/a1
/conf/global
/apps/conf
/libs/conf
{noformat}

or asking other way around: which inheritance hierarchy has higher priority? 
parent resources of the conf resources, or conf resources referenced by parent 
resources of the content resource?
for me case #1 feels more sensible.

> Support nested configurations in configurated locations
> ---
>
> Key: SLING-6114
> URL: https://issues.apache.org/jira/browse/SLING-6114
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> Let's assume you have a content like this:
> /content/level1/level2[@sling-config-ref='/conf/project/sub']
> and configurations
> /conf/project/something
> /conf/project/sub/something-else
> the default path strategy should directly go up the hierarchy in the 
> configured location (/conf in this case), so /conf/project/sub is tried 
> first, then /conf/project and then the other configured paths.
> The only question is if you have
> /libs/conf/project/sub
> is this handled before /conf/project or after?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6114) Support nested configurations in configurated locations

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6114:
-

Ups, you're of course right - just forget my question :)

> Support nested configurations in configurated locations
> ---
>
> Key: SLING-6114
> URL: https://issues.apache.org/jira/browse/SLING-6114
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> Let's assume you have a content like this:
> /content/level1/level2[@sling-config-ref='/conf/project/sub']
> and configurations
> /conf/project/something
> /conf/project/sub/something-else
> the default path strategy should directly go up the hierarchy in the 
> configured location (/conf in this case), so /conf/project/sub is tried 
> first, then /conf/project and then the other configured paths.
> The only question is if you have
> /libs/conf/project/sub
> is this handled before /conf/project or after?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6114) Support nested configurations in configurated locations

[Stefan Seifert (JIRA)]

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

Stefan Seifert updated SLING-6114:
--
Labels: contextaware-config  (was: )

> Support nested configurations in configurated locations
> ---
>
> Key: SLING-6114
> URL: https://issues.apache.org/jira/browse/SLING-6114
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> Let's assume you have a content like this:
> /content/level1/level2[@sling-config-ref='/conf/project/sub']
> and configurations
> /conf/project/something
> /conf/project/sub/something-else
> the default path strategy should directly go up the hierarchy in the 
> configured location (/conf in this case), so /conf/project/sub is tried 
> first, then /conf/project and then the other configured paths.
> The only question is if you have
> /libs/conf/project/sub
> is this handled before /conf/project or after?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6114) Support nested configurations in configurated locations

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6114:
---

{quote}
The only question is if you have
/libs/conf/project/sub
is this handled before /conf/project or after?
{quote}

we currently do not have any support for deep structuring levels in /apps/conf 
or /libs/conf, both are just a "single level" with default resources for the 
given configuration names. thus neither {{/libs/conf/project/sub}} nor 
{{/libs/conf/project}} should be looked up, only {{/libs/conf}}.

or do you see a need for supporting all this hierarchy in /apps and /libs as 
well?

> Support nested configurations in configurated locations
> ---
>
> Key: SLING-6114
> URL: https://issues.apache.org/jira/browse/SLING-6114
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> Let's assume you have a content like this:
> /content/level1/level2[@sling-config-ref='/conf/project/sub']
> and configurations
> /conf/project/something
> /conf/project/sub/something-else
> the default path strategy should directly go up the hierarchy in the 
> configured location (/conf in this case), so /conf/project/sub is tried 
> first, then /conf/project and then the other configured paths.
> The only question is if you have
> /libs/conf/project/sub
> is this handled before /conf/project or after?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-6101) Create JMX MBeans for SCD agents

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili resolved SLING-6101.

   Resolution: Fixed
Fix Version/s: Content Distribution 0.2.0

fixed in r1763764, thanks [~simone.tripodi] for your patch.

> Create JMX MBeans for SCD agents
> 
>
> Key: SLING-6101
> URL: https://issues.apache.org/jira/browse/SLING-6101
> Project: Sling
>  Issue Type: Sub-task
>  Components: Distribution
>Reporter: Simone Tripodi
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-6101.patch, SLING-6101.patch.1, SLING-6101.patch.2
>
>
> JMX support is an important tool for checking and monitoring status of SCD 
> agents, that should be added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6101) Create JMX MBeans for SCD agents

[Tommaso Teofili (JIRA)]

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

Tommaso Teofili commented on SLING-6101:


+1 to your patch, very nice and I'm not a big fun of magic stuff either :)

> Create JMX MBeans for SCD agents
> 
>
> Key: SLING-6101
> URL: https://issues.apache.org/jira/browse/SLING-6101
> Project: Sling
>  Issue Type: Sub-task
>  Components: Distribution
>Reporter: Simone Tripodi
>Assignee: Tommaso Teofili
> Attachments: SLING-6101.patch, SLING-6101.patch.1, SLING-6101.patch.2
>
>
> JMX support is an important tool for checking and monitoring status of SCD 
> agents, that should be added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (SLING-6112) Make Sling IDE independent of m2e-tycho

[Konrad Windszus (JIRA)]

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

Konrad Windszus reassigned SLING-6112:
--

Assignee: Robert Munteanu  (was: Konrad Windszus)

> Make Sling IDE independent of m2e-tycho
> ---
>
> Key: SLING-6112
> URL: https://issues.apache.org/jira/browse/SLING-6112
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>Assignee: Robert Munteanu
> Fix For: Sling Eclipse IDE 1.1.2
>
> Attachments: SLING-6112-v01.patch, SLING-6112-v02.patch
>
>
> Currently Sling IDE requires the installation of m2e-tycho. This was being 
> added in https://issues.apache.org/jira/browse/SLING-3608. Now that the 
> maven-bundle-plugin ships with m2e support OOTB (FELIX-4009) we should get 
> rid of that dependency.
> This is also important since newer versions of the maven-bundle-plugin 
> conflict with that extension 
> (https://issues.apache.org/jira/browse/FELIX-4009?focusedCommentId=15192263=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15192263).
> See also the discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg60112.html.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6112) Make Sling IDE independent of m2e-tycho

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6112:


No problem, just test with the new patch. It turns out it was me, who 
introduced the dependency to m2e-tycho back in 2014 
(https://issues.apache.org/jira/browse/SLING-3612)

> Make Sling IDE independent of m2e-tycho
> ---
>
> Key: SLING-6112
> URL: https://issues.apache.org/jira/browse/SLING-6112
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Sling Eclipse IDE 1.1.2
>
> Attachments: SLING-6112-v01.patch, SLING-6112-v02.patch
>
>
> Currently Sling IDE requires the installation of m2e-tycho. This was being 
> added in https://issues.apache.org/jira/browse/SLING-3608. Now that the 
> maven-bundle-plugin ships with m2e support OOTB (FELIX-4009) we should get 
> rid of that dependency.
> This is also important since newer versions of the maven-bundle-plugin 
> conflict with that extension 
> (https://issues.apache.org/jira/browse/FELIX-4009?focusedCommentId=15192263=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15192263).
> See also the discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg60112.html.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6112) Make Sling IDE independent of m2e-tycho

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6112:
---
Attachment: SLING-6112-v02.patch

The new version of the patch relies on the default java configurator to be 
executed before the sling bundle project configurator is being executed. 
Hopefully this was really the last reference to the m2e-tycho extension which 
was now removed.

> Make Sling IDE independent of m2e-tycho
> ---
>
> Key: SLING-6112
> URL: https://issues.apache.org/jira/browse/SLING-6112
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Sling Eclipse IDE 1.1.2
>
> Attachments: SLING-6112-v01.patch, SLING-6112-v02.patch
>
>
> Currently Sling IDE requires the installation of m2e-tycho. This was being 
> added in https://issues.apache.org/jira/browse/SLING-3608. Now that the 
> maven-bundle-plugin ships with m2e support OOTB (FELIX-4009) we should get 
> rid of that dependency.
> This is also important since newer versions of the maven-bundle-plugin 
> conflict with that extension 
> (https://issues.apache.org/jira/browse/FELIX-4009?focusedCommentId=15192263=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15192263).
> See also the discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg60112.html.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SLING-6112) Make Sling IDE independent of m2e-tycho

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-6112 at 10/7/16 1:29 PM:
-

The plugin.xml in 
https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/plugin.xml#L54
 still references the m2e-tycho confiigurator in the {{secondaryTo}} attribute. 
This refers to 
https://github.com/tesla/m2eclipse-tycho/blob/master/org.sonatype.tycho.m2e/lifecycle-mapping-metadata.xml#L113.
We should change to 
http://git.eclipse.org/c/m2e/m2e-core.git/tree/org.eclipse.m2e.jdt/src/org/eclipse/m2e/jdt/internal/JavaProjectConfigurator.java
 (with id="org.eclipse.m2e.jdt.javaConfigurator", 
http://git.eclipse.org/c/m2e/m2e-core.git/tree/org.eclipse.m2e.jdt/plugin.xml#n42).

The only question is whether we should stick to the deprecated {{secondaryTo}} 
logic or rely on the new {{runsAfter}} being introduced with m2e 1.6 
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=449495)?


was (Author: kwin):
There seems to be a bug in 
https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/plugin.xml#L54
 in the {{secondaryTo}} attribute. This is supposed to refer to another 
configurator id. But the configurator with id {{maven-bundle-plugin}} does just 
not exist (neither in m2e nor in m2e-tycho).
What was meant is probably 
http://git.eclipse.org/c/m2e/m2e-core.git/tree/org.eclipse.m2e.jdt/src/org/eclipse/m2e/jdt/internal/JavaProjectConfigurator.java
 (with id="org.eclipse.m2e.jdt.javaConfigurator", 
http://git.eclipse.org/c/m2e/m2e-core.git/tree/org.eclipse.m2e.jdt/plugin.xml#n42).

The only question is whether we should stick to the deprecated {{secondaryTo}} 
logic or rely on the new {{runsAfter}} being introduced with m2e 1.6 
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=449495)?

> Make Sling IDE independent of m2e-tycho
> ---
>
> Key: SLING-6112
> URL: https://issues.apache.org/jira/browse/SLING-6112
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Sling Eclipse IDE 1.1.2
>
> Attachments: SLING-6112-v01.patch
>
>
> Currently Sling IDE requires the installation of m2e-tycho. This was being 
> added in https://issues.apache.org/jira/browse/SLING-3608. Now that the 
> maven-bundle-plugin ships with m2e support OOTB (FELIX-4009) we should get 
> rid of that dependency.
> This is also important since newer versions of the maven-bundle-plugin 
> conflict with that extension 
> (https://issues.apache.org/jira/browse/FELIX-4009?focusedCommentId=15192263=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15192263).
> See also the discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg60112.html.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SLING-6112) Make Sling IDE independent of m2e-tycho

[Robert Munteanu (JIRA)]

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

Robert Munteanu edited comment on SLING-6112 at 10/7/16 1:24 PM:
-

I'll be able to test this early next week, so if you're not in a rush it should 
wait until them.

_Edit_: typo


was (Author: rombert):
I'll be test this early next week, so if you're not in a rush it should wait 
until them.

> Make Sling IDE independent of m2e-tycho
> ---
>
> Key: SLING-6112
> URL: https://issues.apache.org/jira/browse/SLING-6112
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Sling Eclipse IDE 1.1.2
>
> Attachments: SLING-6112-v01.patch
>
>
> Currently Sling IDE requires the installation of m2e-tycho. This was being 
> added in https://issues.apache.org/jira/browse/SLING-3608. Now that the 
> maven-bundle-plugin ships with m2e support OOTB (FELIX-4009) we should get 
> rid of that dependency.
> This is also important since newer versions of the maven-bundle-plugin 
> conflict with that extension 
> (https://issues.apache.org/jira/browse/FELIX-4009?focusedCommentId=15192263=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15192263).
> See also the discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg60112.html.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6112) Make Sling IDE independent of m2e-tycho

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-6112:


I'll be test this early next week, so if you're not in a rush it should wait 
until them.

> Make Sling IDE independent of m2e-tycho
> ---
>
> Key: SLING-6112
> URL: https://issues.apache.org/jira/browse/SLING-6112
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Sling Eclipse IDE 1.1.2
>
> Attachments: SLING-6112-v01.patch
>
>
> Currently Sling IDE requires the installation of m2e-tycho. This was being 
> added in https://issues.apache.org/jira/browse/SLING-3608. Now that the 
> maven-bundle-plugin ships with m2e support OOTB (FELIX-4009) we should get 
> rid of that dependency.
> This is also important since newer versions of the maven-bundle-plugin 
> conflict with that extension 
> (https://issues.apache.org/jira/browse/FELIX-4009?focusedCommentId=15192263=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15192263).
> See also the discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg60112.html.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6112) Make Sling IDE independent of m2e-tycho

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-6112:
---
Fix Version/s: Sling Eclipse IDE 1.1.2

> Make Sling IDE independent of m2e-tycho
> ---
>
> Key: SLING-6112
> URL: https://issues.apache.org/jira/browse/SLING-6112
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Sling Eclipse IDE 1.1.2
>
> Attachments: SLING-6112-v01.patch
>
>
> Currently Sling IDE requires the installation of m2e-tycho. This was being 
> added in https://issues.apache.org/jira/browse/SLING-3608. Now that the 
> maven-bundle-plugin ships with m2e support OOTB (FELIX-4009) we should get 
> rid of that dependency.
> This is also important since newer versions of the maven-bundle-plugin 
> conflict with that extension 
> (https://issues.apache.org/jira/browse/FELIX-4009?focusedCommentId=15192263=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15192263).
> See also the discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg60112.html.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6112) Make Sling IDE independent of m2e-tycho

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6112:


There seems to be a bug in 
https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/plugin.xml#L54
 in the {{secondaryTo}} attribute. This is supposed to refer to another 
configurator id. But the configurator with id {{maven-bundle-plugin}} does just 
not exist (neither in m2e nor in m2e-tycho).
What was meant is probably 
http://git.eclipse.org/c/m2e/m2e-core.git/tree/org.eclipse.m2e.jdt/src/org/eclipse/m2e/jdt/internal/JavaProjectConfigurator.java
 (with id="org.eclipse.m2e.jdt.javaConfigurator", 
http://git.eclipse.org/c/m2e/m2e-core.git/tree/org.eclipse.m2e.jdt/plugin.xml#n42).

The only question is whether we should stick to the deprecated {{secondaryTo}} 
logic or rely on the new {{runsAfter}} being introduced with m2e 1.6 
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=449495)?

> Make Sling IDE independent of m2e-tycho
> ---
>
> Key: SLING-6112
> URL: https://issues.apache.org/jira/browse/SLING-6112
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Attachments: SLING-6112-v01.patch
>
>
> Currently Sling IDE requires the installation of m2e-tycho. This was being 
> added in https://issues.apache.org/jira/browse/SLING-3608. Now that the 
> maven-bundle-plugin ships with m2e support OOTB (FELIX-4009) we should get 
> rid of that dependency.
> This is also important since newer versions of the maven-bundle-plugin 
> conflict with that extension 
> (https://issues.apache.org/jira/browse/FELIX-4009?focusedCommentId=15192263=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15192263).
> See also the discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg60112.html.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6113) JcrProviderStateFactory needs a reference to the bundle that's using it

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6113:
-

That's already available in the map as ResourceProvider.AUTH_SERVICE_BUNDLE, 
the JcrProviderStateFactory already uses this for service users or more precise 
to pass this info on to the sling repository

> JcrProviderStateFactory needs a reference to the bundle that's using it
> ---
>
> Key: SLING-6113
> URL: https://issues.apache.org/jira/browse/SLING-6113
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR Resource 2.8.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> This is needed to implement the SLING-5135 login admin whitelist: the 
> JcrProviderStateFactory needs a reference to the bundle that wants to open an 
> admin session or create an admin resource resolver, to be able to pass it 
> through the whitelist once that's implemented



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-6113) JcrProviderStateFactory needs a reference to the bundle that's using it

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-6113.
-
   Resolution: Not A Problem
Fix Version/s: (was: JCR Resource 2.8.2)

> JcrProviderStateFactory needs a reference to the bundle that's using it
> ---
>
> Key: SLING-6113
> URL: https://issues.apache.org/jira/browse/SLING-6113
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR Resource 2.8.0
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> This is needed to implement the SLING-5135 login admin whitelist: the 
> JcrProviderStateFactory needs a reference to the bundle that wants to open an 
> admin session or create an admin resource resolver, to be able to pass it 
> through the whitelist once that's implemented



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-6114) Support nested configurations in configurated locations

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-6114:
---

 Summary: Support nested configurations in configurated locations
 Key: SLING-6114
 URL: https://issues.apache.org/jira/browse/SLING-6114
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Carsten Ziegeler
Assignee: Stefan Seifert
 Fix For: Context-Aware Configuration 1.0.0


Let's assume you have a content like this:
/content/level1/level2[@sling-config-ref='/conf/project/sub']

and configurations
/conf/project/something
/conf/project/sub/something-else

the default path strategy should directly go up the hierarchy in the configured 
location (/conf in this case), so /conf/project/sub is tried first, then 
/conf/project and then the other configured paths.
The only question is if you have
/libs/conf/project/sub
is this handled before /conf/project or after?





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-6113) JcrProviderStateFactory needs a reference to the bundle that's using it

[Bertrand Delacretaz (JIRA)]

Bertrand Delacretaz created SLING-6113:
--

 Summary: JcrProviderStateFactory needs a reference to the bundle 
that's using it
 Key: SLING-6113
 URL: https://issues.apache.org/jira/browse/SLING-6113
 Project: Sling
  Issue Type: Improvement
  Components: JCR
Affects Versions: JCR Resource 2.8.0
Reporter: Bertrand Delacretaz
Assignee: Bertrand Delacretaz
Priority: Minor
 Fix For: JCR Resource 2.8.2


This is needed to implement the SLING-5135 login admin whitelist: the 
JcrProviderStateFactory needs a reference to the bundle that wants to open an 
admin session or create an admin resource resolver, to be able to pass it 
through the whitelist once that's implemented



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6112) Make Sling IDE independent of m2e-tycho

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6112:
---
Attachment: SLING-6112-v01.patch

Attached is a patch which removes the dependency of m2e-tycho, removes that 
plugin from the target definition and makes sure that "bundle" projects are 
setup with the default JDT lifecycle.
The only thing missing is the potentially useful 
https://github.com/tesla/m2eclipse-tycho/blob/master/org.sonatype.tycho.m2e/src/org/sonatype/tycho/m2e/felix/internal/MavenBundlePluginConfigurator.java
 which regenerates the Manifest whenever something changes (does not work 
reliably though). This has anyhow been incorporated to 
https://issues.apache.org/jira/browse/FELIX-4009 (for goal {{manifest}} and 
needs to be explicitly enabled). Therefore I would say, we don't loose much, so 
I wouldn't display a warning either here but just rely on full builds for the 
Manifest to be generated correctly.
[~rombert] Could you have a look?

> Make Sling IDE independent of m2e-tycho
> ---
>
> Key: SLING-6112
> URL: https://issues.apache.org/jira/browse/SLING-6112
> Project: Sling
>  Issue Type: Improvement
>  Components: Tooling
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Attachments: SLING-6112-v01.patch
>
>
> Currently Sling IDE requires the installation of m2e-tycho. This was being 
> added in https://issues.apache.org/jira/browse/SLING-3608. Now that the 
> maven-bundle-plugin ships with m2e support OOTB (FELIX-4009) we should get 
> rid of that dependency.
> This is also important since newer versions of the maven-bundle-plugin 
> conflict with that extension 
> (https://issues.apache.org/jira/browse/FELIX-4009?focusedCommentId=15192263=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15192263).
> See also the discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg60112.html.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Sling IDE: Dependency from m2e-feature to org.sonatype.tycho.m2e.feature

[Konrad Windszus]

Created https://issues.apache.org/jira/browse/SLING-6112 to track that.

> On 7 Oct 2016, at 14:16, Robert Munteanu  wrote:
> 
> I would be happy to remove the link to tycho-m2e, given that newer
> plugin versions work without it and that we give users a fair warning
> when an unsupported plugin version is encountered.
> 
> Robert
> 
> On Fri, 2016-10-07 at 14:12 +0200, Konrad Windszus wrote:
>> Could it be that the part we are relying on is just this one: https:/
>> /github.com/tesla/m2eclipse-
>> tycho/blob/master/org.sonatype.tycho.m2e/lifecycle-mapping-
>> metadata.xml#L54? > tycho/blob/master/org.sonatype.tycho.m2e/lifecycle-mapping-
>> metadata.xml#L54?>
>> What about adding that to the Sling IDE?
>> 
>>> On 7 Oct 2016, at 14:03, Konrad Windszus  wrote:
>>> 
>>> Hi Robert,
>>> To be honest, I still don't quite get that. 
>>> The project configurators part should be part of m2e-ui (https://gi
>>> thub.com/apache/sling/tree/trunk/tooling/ide/eclipse-m2e-
>>> ui/src/org/apache/sling/ide/eclipse/m2e/internal).
>>> The (incremental) manifest generation is now being done through the
>>> maven-bundle-plugin since 3.2.0 natively (https://issues.apache.org
>>> /jira/browse/FELIX-4009). The same for the maven-scr-plugin
>>> (https://issues.apache.org/jira/browse/FELIX-3358).
>>> So which code part of m2e-tycho is really necessary here?
>>> 
>>> When looking through the code at https://github.com/tesla/m2eclipse
>>> -tycho/ it seems that really only
>>> https://github.com/tesla/m2eclipse-
>>> tycho/blob/master/org.sonatype.tycho.m2e/src/org/sonatype/tycho/m2e
>>> /felix/internal/MavenBundlePluginConfigurator.java  might be
>>> relevant and there our own project configurator should be enough (h
>>> ttps://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-
>>> ui/src/org/apache/sling/ide/eclipse/m2e/internal/BundleProjectConfi
>>> gurator.java).
>>> 
>>> If really both configurators are necessary to get things running we
>>> should try to figure out which part  of https://github.com/tesla/m2
>>> eclipse-
>>> tycho/blob/master/org.sonatype.tycho.m2e/src/org/sonatype/tycho/m2e
>>> /felix/internal/MavenBundlePluginConfigurator.java  needs to be
>>> taken over to https://github.com/apache/sling/blob/trunk/tooling/id
>>> e/eclipse-m2e-
>>> ui/src/org/apache/sling/ide/eclipse/m2e/internal/BundleProjectConfi
>>> gurator.java to make things work.
>>> 
>>> Do you by chance remember what exactly was not working when you
>>> didn't have the m2e-tycho plugin installed?
>>> Thanks,
>>> Konrad
>>> 
 On 7 Oct 2016, at 13:43, Robert Munteanu 
 wrote:
 
 Hi Konrad,
 
 On Fri, 2016-10-07 at 12:20 +0200, Konrad Windszus wrote:
> Currently the m2e-feature of the Sling IDE still requires the
> feature
> org.sonatype.tycho.m2e.feature (https://github.com/apache/sling
> /blob/
> 4df9ab2d6592422889c71fa13afd453a10a5a626/tooling/ide/m2e-
> feature/feature.xml#L229
>  afd453
> a10a5a626/tooling/ide/m2e-feature/feature.xml#L229>)
> Since the latter seems rather unmaintained I would like to get
> rid of
> that dependency which was added in the context of https://issue
> s.apac
> he.org/jira/browse/SLING-3608
> .
> 
> This is also important since newer versions of the maven-
> bundle-
> plugin conflict with that extension (https://issues.apache.org/
> jira/b
> rowse/FELIX-
> 4009?focusedCommentId=15192263=com.atlassian.jira.plugin.s
> ystem.
> issuetabpanels:comment-tabpanel#comment-15192263
>  4009?focusedCommentId=15192263=com.atlassian.jira.plugin.s
> ystem.
> issuetabpanels:comment-tabpanel#comment-15192263>)
> 
> @Robert: Do you have any idea why this was initially added?
> SLING-
> 3608 does not give much hints here. There should be no explicit
> runtime dependency to any tycho code IMHO.
 
 
 The dependency is there to make sure that the OSGi metadata (
 manifest,
 SCR descriptors, etc ) is generated and put in the right
 location.
 
 Without the tycho-m2e feature things will be broken out of the
 box.
 
 So while there is no hard dependency, it is in my opinion
 required, at
 least for now.
 
 How to gracefully accommodate the transition is another issue,
 and I
 don't have a good answer for that.
 
 Robert
>>> 
>>> 
>> 
>> 
>> 
> 

[jira] [Created] (SLING-6112) Make Sling IDE independent of m2e-tycho

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-6112:
--

 Summary: Make Sling IDE independent of m2e-tycho
 Key: SLING-6112
 URL: https://issues.apache.org/jira/browse/SLING-6112
 Project: Sling
  Issue Type: Improvement
  Components: Tooling
Affects Versions: Sling Eclipse IDE 1.1.0
Reporter: Konrad Windszus
Assignee: Konrad Windszus


Currently Sling IDE requires the installation of m2e-tycho. This was being 
added in https://issues.apache.org/jira/browse/SLING-3608. Now that the 
maven-bundle-plugin ships with m2e support OOTB (FELIX-4009) we should get rid 
of that dependency.

This is also important since newer versions of the maven-bundle-plugin conflict 
with that extension 
(https://issues.apache.org/jira/browse/FELIX-4009?focusedCommentId=15192263=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15192263).

See also the discussion at 
http://www.mail-archive.com/dev@sling.apache.org/msg60112.html.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Sling IDE: Dependency from m2e-feature to org.sonatype.tycho.m2e.feature

[Robert Munteanu]

I would be happy to remove the link to tycho-m2e, given that newer
plugin versions work without it and that we give users a fair warning
when an unsupported plugin version is encountered.

Robert

On Fri, 2016-10-07 at 14:12 +0200, Konrad Windszus wrote:
> Could it be that the part we are relying on is just this one: https:/
> /github.com/tesla/m2eclipse-
> tycho/blob/master/org.sonatype.tycho.m2e/lifecycle-mapping-
> metadata.xml#L54?  tycho/blob/master/org.sonatype.tycho.m2e/lifecycle-mapping-
> metadata.xml#L54?>
> What about adding that to the Sling IDE?
> 
> > On 7 Oct 2016, at 14:03, Konrad Windszus  wrote:
> > 
> > Hi Robert,
> > To be honest, I still don't quite get that. 
> > The project configurators part should be part of m2e-ui (https://gi
> > thub.com/apache/sling/tree/trunk/tooling/ide/eclipse-m2e-
> > ui/src/org/apache/sling/ide/eclipse/m2e/internal).
> > The (incremental) manifest generation is now being done through the
> > maven-bundle-plugin since 3.2.0 natively (https://issues.apache.org
> > /jira/browse/FELIX-4009). The same for the maven-scr-plugin
> > (https://issues.apache.org/jira/browse/FELIX-3358).
> > So which code part of m2e-tycho is really necessary here?
> > 
> > When looking through the code at https://github.com/tesla/m2eclipse
> > -tycho/ it seems that really only
> > https://github.com/tesla/m2eclipse-
> > tycho/blob/master/org.sonatype.tycho.m2e/src/org/sonatype/tycho/m2e
> > /felix/internal/MavenBundlePluginConfigurator.java  might be
> > relevant and there our own project configurator should be enough (h
> > ttps://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-
> > ui/src/org/apache/sling/ide/eclipse/m2e/internal/BundleProjectConfi
> > gurator.java).
> > 
> > If really both configurators are necessary to get things running we
> > should try to figure out which part  of https://github.com/tesla/m2
> > eclipse-
> > tycho/blob/master/org.sonatype.tycho.m2e/src/org/sonatype/tycho/m2e
> > /felix/internal/MavenBundlePluginConfigurator.java  needs to be
> > taken over to https://github.com/apache/sling/blob/trunk/tooling/id
> > e/eclipse-m2e-
> > ui/src/org/apache/sling/ide/eclipse/m2e/internal/BundleProjectConfi
> > gurator.java to make things work.
> > 
> > Do you by chance remember what exactly was not working when you
> > didn't have the m2e-tycho plugin installed?
> > Thanks,
> > Konrad
> > 
> > > On 7 Oct 2016, at 13:43, Robert Munteanu 
> > > wrote:
> > > 
> > > Hi Konrad,
> > > 
> > > On Fri, 2016-10-07 at 12:20 +0200, Konrad Windszus wrote:
> > > > Currently the m2e-feature of the Sling IDE still requires the
> > > > feature
> > > > org.sonatype.tycho.m2e.feature (https://github.com/apache/sling
> > > > /blob/
> > > > 4df9ab2d6592422889c71fa13afd453a10a5a626/tooling/ide/m2e-
> > > > feature/feature.xml#L229
> > > >  > > > afd453
> > > > a10a5a626/tooling/ide/m2e-feature/feature.xml#L229>)
> > > > Since the latter seems rather unmaintained I would like to get
> > > > rid of
> > > > that dependency which was added in the context of https://issue
> > > > s.apac
> > > > he.org/jira/browse/SLING-3608
> > > > .
> > > > 
> > > > This is also important since newer versions of the maven-
> > > > bundle-
> > > > plugin conflict with that extension (https://issues.apache.org/
> > > > jira/b
> > > > rowse/FELIX-
> > > > 4009?focusedCommentId=15192263=com.atlassian.jira.plugin.s
> > > > ystem.
> > > > issuetabpanels:comment-tabpanel#comment-15192263
> > > >  > > > 4009?focusedCommentId=15192263=com.atlassian.jira.plugin.s
> > > > ystem.
> > > > issuetabpanels:comment-tabpanel#comment-15192263>)
> > > > 
> > > > @Robert: Do you have any idea why this was initially added?
> > > > SLING-
> > > > 3608 does not give much hints here. There should be no explicit
> > > > runtime dependency to any tycho code IMHO.
> > > 
> > > 
> > > The dependency is there to make sure that the OSGi metadata (
> > > manifest,
> > > SCR descriptors, etc ) is generated and put in the right
> > > location.
> > > 
> > > Without the tycho-m2e feature things will be broken out of the
> > > box.
> > > 
> > > So while there is no hard dependency, it is in my opinion
> > > required, at
> > > least for now.
> > > 
> > > How to gracefully accommodate the transition is another issue,
> > > and I
> > > don't have a good answer for that.
> > > 
> > > Robert
> > 
> > 
> 
> 
> 

Re: Sling IDE: Dependency from m2e-feature to org.sonatype.tycho.m2e.feature

[Robert Munteanu]

On Fri, 2016-10-07 at 14:03 +0200, Konrad Windszus wrote:
> Hi Robert,
> To be honest, I still don't quite get that. 
> The project configurators part should be part of m2e-ui (https://gith
> ub.com/apache/sling/tree/trunk/tooling/ide/eclipse-m2e-
> ui/src/org/apache/sling/ide/eclipse/m2e/internal).
> The (incremental) manifest generation is now being done through the
> maven-bundle-plugin since 3.2.0 natively (https://issues.apache.org/j
> ira/browse/FELIX-4009). The same for the maven-scr-plugin
> (https://issues.apache.org/jira/browse/FELIX-3358).
> So which code part of m2e-tycho is really necessary here?

m2e-tycho is IIRC only necessary for old versions of the maven plugins
that need a m2e configurator.

Robert

> 
> When looking through the code at https://github.com/tesla/m2eclipse-t
> ycho/ it seems that really only https://github.com/tesla/m2eclipse-
> tycho/blob/master/org.sonatype.tycho.m2e/src/org/sonatype/tycho/m2e/f
> elix/internal/MavenBundlePluginConfigurator.java  might be relevant
> and there our own project configurator should be enough (https://gith
> ub.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-
> ui/src/org/apache/sling/ide/eclipse/m2e/internal/BundleProjectConfigu
> rator.java).
> 
> If really both configurators are necessary to get things running we
> should try to figure out which part  of https://github.com/tesla/m2ec
> lipse-
> tycho/blob/master/org.sonatype.tycho.m2e/src/org/sonatype/tycho/m2e/f
> elix/internal/MavenBundlePluginConfigurator.java  needs to be taken
> over to https://github.com/apache/sling/blob/trunk/tooling/ide/eclips
> e-m2e-
> ui/src/org/apache/sling/ide/eclipse/m2e/internal/BundleProjectConfigu
> rator.java to make things work.
> 
> Do you by chance remember what exactly was not working when you
> didn't have the m2e-tycho plugin installed?
> Thanks,
> Konrad
> 
> > On 7 Oct 2016, at 13:43, Robert Munteanu 
> > wrote:
> > 
> > Hi Konrad,
> > 
> > On Fri, 2016-10-07 at 12:20 +0200, Konrad Windszus wrote:
> > > Currently the m2e-feature of the Sling IDE still requires the
> > > feature
> > > org.sonatype.tycho.m2e.feature (https://github.com/apache/sling/b
> > > lob/
> > > 4df9ab2d6592422889c71fa13afd453a10a5a626/tooling/ide/m2e-
> > > feature/feature.xml#L229
> > >  > > d453
> > > a10a5a626/tooling/ide/m2e-feature/feature.xml#L229>)
> > > Since the latter seems rather unmaintained I would like to get
> > > rid of
> > > that dependency which was added in the context of https://issues.
> > > apac
> > > he.org/jira/browse/SLING-3608
> > > .
> > > 
> > > This is also important since newer versions of the maven-bundle-
> > > plugin conflict with that extension (https://issues.apache.org/ji
> > > ra/b
> > > rowse/FELIX-
> > > 4009?focusedCommentId=15192263=com.atlassian.jira.plugin.sys
> > > tem.
> > > issuetabpanels:comment-tabpanel#comment-15192263
> > >  > > 4009?focusedCommentId=15192263=com.atlassian.jira.plugin.sys
> > > tem.
> > > issuetabpanels:comment-tabpanel#comment-15192263>)
> > > 
> > > @Robert: Do you have any idea why this was initially added?
> > > SLING-
> > > 3608 does not give much hints here. There should be no explicit
> > > runtime dependency to any tycho code IMHO.
> > 
> > 
> > The dependency is there to make sure that the OSGi metadata (
> > manifest,
> > SCR descriptors, etc ) is generated and put in the right location.
> > 
> > Without the tycho-m2e feature things will be broken out of the box.
> > 
> > So while there is no hard dependency, it is in my opinion required,
> > at
> > least for now.
> > 
> > How to gracefully accommodate the transition is another issue, and
> > I
> > don't have a good answer for that.
> > 
> > Robert
> 
> 
> 

Re: Sling IDE: Dependency from m2e-feature to org.sonatype.tycho.m2e.feature

[Konrad Windszus]

Could it be that the part we are relying on is just this one: 
https://github.com/tesla/m2eclipse-tycho/blob/master/org.sonatype.tycho.m2e/lifecycle-mapping-metadata.xml#L54?
 

What about adding that to the Sling IDE?

> On 7 Oct 2016, at 14:03, Konrad Windszus  wrote:
> 
> Hi Robert,
> To be honest, I still don't quite get that. 
> The project configurators part should be part of m2e-ui 
> (https://github.com/apache/sling/tree/trunk/tooling/ide/eclipse-m2e-ui/src/org/apache/sling/ide/eclipse/m2e/internal).
> The (incremental) manifest generation is now being done through the 
> maven-bundle-plugin since 3.2.0 natively 
> (https://issues.apache.org/jira/browse/FELIX-4009). The same for the 
> maven-scr-plugin (https://issues.apache.org/jira/browse/FELIX-3358).
> So which code part of m2e-tycho is really necessary here?
> 
> When looking through the code at https://github.com/tesla/m2eclipse-tycho/ it 
> seems that really only 
> https://github.com/tesla/m2eclipse-tycho/blob/master/org.sonatype.tycho.m2e/src/org/sonatype/tycho/m2e/felix/internal/MavenBundlePluginConfigurator.java
>   might be relevant and there our own project configurator should be enough 
> (https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/src/org/apache/sling/ide/eclipse/m2e/internal/BundleProjectConfigurator.java).
> 
> If really both configurators are necessary to get things running we should 
> try to figure out which part  of 
> https://github.com/tesla/m2eclipse-tycho/blob/master/org.sonatype.tycho.m2e/src/org/sonatype/tycho/m2e/felix/internal/MavenBundlePluginConfigurator.java
>   needs to be taken over to 
> https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/src/org/apache/sling/ide/eclipse/m2e/internal/BundleProjectConfigurator.java
>  to make things work.
> 
> Do you by chance remember what exactly was not working when you didn't have 
> the m2e-tycho plugin installed?
> Thanks,
> Konrad
> 
>> On 7 Oct 2016, at 13:43, Robert Munteanu  wrote:
>> 
>> Hi Konrad,
>> 
>> On Fri, 2016-10-07 at 12:20 +0200, Konrad Windszus wrote:
>>> Currently the m2e-feature of the Sling IDE still requires the feature
>>> org.sonatype.tycho.m2e.feature (https://github.com/apache/sling/blob/
>>> 4df9ab2d6592422889c71fa13afd453a10a5a626/tooling/ide/m2e-
>>> feature/feature.xml#L229
>>> >> a10a5a626/tooling/ide/m2e-feature/feature.xml#L229>)
>>> Since the latter seems rather unmaintained I would like to get rid of
>>> that dependency which was added in the context of https://issues.apac
>>> he.org/jira/browse/SLING-3608
>>> .
>>> 
>>> This is also important since newer versions of the maven-bundle-
>>> plugin conflict with that extension (https://issues.apache.org/jira/b
>>> rowse/FELIX-
>>> 4009?focusedCommentId=15192263=com.atlassian.jira.plugin.system.
>>> issuetabpanels:comment-tabpanel#comment-15192263
>>> >> 4009?focusedCommentId=15192263=com.atlassian.jira.plugin.system.
>>> issuetabpanels:comment-tabpanel#comment-15192263>)
>>> 
>>> @Robert: Do you have any idea why this was initially added? SLING-
>>> 3608 does not give much hints here. There should be no explicit
>>> runtime dependency to any tycho code IMHO.
>> 
>> The dependency is there to make sure that the OSGi metadata ( manifest,
>> SCR descriptors, etc ) is generated and put in the right location.
>> 
>> Without the tycho-m2e feature things will be broken out of the box.
>> 
>> So while there is no hard dependency, it is in my opinion required, at
>> least for now.
>> 
>> How to gracefully accommodate the transition is another issue, and I
>> don't have a good answer for that.
>> 
>> Robert
> 

Re: Sling IDE: Dependency from m2e-feature to org.sonatype.tycho.m2e.feature

[Konrad Windszus]

Hi Robert,
To be honest, I still don't quite get that. 
The project configurators part should be part of m2e-ui 
(https://github.com/apache/sling/tree/trunk/tooling/ide/eclipse-m2e-ui/src/org/apache/sling/ide/eclipse/m2e/internal).
The (incremental) manifest generation is now being done through the 
maven-bundle-plugin since 3.2.0 natively 
(https://issues.apache.org/jira/browse/FELIX-4009). The same for the 
maven-scr-plugin (https://issues.apache.org/jira/browse/FELIX-3358).
So which code part of m2e-tycho is really necessary here?

When looking through the code at https://github.com/tesla/m2eclipse-tycho/ it 
seems that really only 
https://github.com/tesla/m2eclipse-tycho/blob/master/org.sonatype.tycho.m2e/src/org/sonatype/tycho/m2e/felix/internal/MavenBundlePluginConfigurator.java
  might be relevant and there our own project configurator should be enough 
(https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/src/org/apache/sling/ide/eclipse/m2e/internal/BundleProjectConfigurator.java).

If really both configurators are necessary to get things running we should try 
to figure out which part  of 
https://github.com/tesla/m2eclipse-tycho/blob/master/org.sonatype.tycho.m2e/src/org/sonatype/tycho/m2e/felix/internal/MavenBundlePluginConfigurator.java
  needs to be taken over to 
https://github.com/apache/sling/blob/trunk/tooling/ide/eclipse-m2e-ui/src/org/apache/sling/ide/eclipse/m2e/internal/BundleProjectConfigurator.java
 to make things work.

Do you by chance remember what exactly was not working when you didn't have the 
m2e-tycho plugin installed?
Thanks,
Konrad

> On 7 Oct 2016, at 13:43, Robert Munteanu  wrote:
> 
> Hi Konrad,
> 
> On Fri, 2016-10-07 at 12:20 +0200, Konrad Windszus wrote:
>> Currently the m2e-feature of the Sling IDE still requires the feature
>> org.sonatype.tycho.m2e.feature (https://github.com/apache/sling/blob/
>> 4df9ab2d6592422889c71fa13afd453a10a5a626/tooling/ide/m2e-
>> feature/feature.xml#L229
>> > a10a5a626/tooling/ide/m2e-feature/feature.xml#L229>)
>> Since the latter seems rather unmaintained I would like to get rid of
>> that dependency which was added in the context of https://issues.apac
>> he.org/jira/browse/SLING-3608
>> .
>> 
>> This is also important since newer versions of the maven-bundle-
>> plugin conflict with that extension (https://issues.apache.org/jira/b
>> rowse/FELIX-
>> 4009?focusedCommentId=15192263=com.atlassian.jira.plugin.system.
>> issuetabpanels:comment-tabpanel#comment-15192263
>> > 4009?focusedCommentId=15192263=com.atlassian.jira.plugin.system.
>> issuetabpanels:comment-tabpanel#comment-15192263>)
>> 
>> @Robert: Do you have any idea why this was initially added? SLING-
>> 3608 does not give much hints here. There should be no explicit
>> runtime dependency to any tycho code IMHO.
> 
> The dependency is there to make sure that the OSGi metadata ( manifest,
> SCR descriptors, etc ) is generated and put in the right location.
> 
> Without the tycho-m2e feature things will be broken out of the box.
> 
> So while there is no hard dependency, it is in my opinion required, at
> least for now.
> 
> How to gracefully accommodate the transition is another issue, and I
> don't have a good answer for that.
> 
> Robert

[jira] [Commented] (SLING-6110) ServerSideTeleporter can't read the bundle header Sling-Test-WaitForService-Timeout

[Marcel Jolk (JIRA)]

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

Marcel Jolk commented on SLING-6110:


Still works. Thanks!

> ServerSideTeleporter can't read the bundle header 
> Sling-Test-WaitForService-Timeout
> ---
>
> Key: SLING-6110
> URL: https://issues.apache.org/jira/browse/SLING-6110
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.8, JUnit Core 1.0.18
>Reporter: Marcel Jolk
>Assignee: Stefan Seifert
> Fix For: JUnit Core 1.0.20
>
>
> The _Sling-Test-WaitForService-Timeout_ bundle header is not properly read by 
> the {{ServerSideTeleporter}}. The method {{getService()}} reads the bundle 
> header using the {{BundleContext}} 
> ({{bundleContext.getBundle().getHeaders()}}). This {{BundleContext}} is set 
> in the {{Activator}} class on start of the bundle 
> {{org.apache.sling.junit.core}}. Therefore {{bundleContext.getBundle()}} 
> resolves to the bundle {{org.apache.sling.junit.core}}. This bundle does not 
> have the proper headers. Instead the bundle headers of the bundle, which is 
> created in the {{ClientSideTeleporter}}, including the class under test, 
> should be used. Thus its {{BundleContext}} is needed.
> I already made the required code changes using {{FrameWorkUtil}} to retrieve 
> the {{BundleContext}} for the class under test. I'll create a pull request, 
> which resolves this issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Sling IDE: Dependency from m2e-feature to org.sonatype.tycho.m2e.feature

[Robert Munteanu]

Hi Konrad,

On Fri, 2016-10-07 at 12:20 +0200, Konrad Windszus wrote:
> Currently the m2e-feature of the Sling IDE still requires the feature
> org.sonatype.tycho.m2e.feature (https://github.com/apache/sling/blob/
> 4df9ab2d6592422889c71fa13afd453a10a5a626/tooling/ide/m2e-
> feature/feature.xml#L229
>  a10a5a626/tooling/ide/m2e-feature/feature.xml#L229>)
> Since the latter seems rather unmaintained I would like to get rid of
> that dependency which was added in the context of https://issues.apac
> he.org/jira/browse/SLING-3608
> .
> 
> This is also important since newer versions of the maven-bundle-
> plugin conflict with that extension (https://issues.apache.org/jira/b
> rowse/FELIX-
> 4009?focusedCommentId=15192263=com.atlassian.jira.plugin.system.
> issuetabpanels:comment-tabpanel#comment-15192263
>  4009?focusedCommentId=15192263=com.atlassian.jira.plugin.system.
> issuetabpanels:comment-tabpanel#comment-15192263>)
> 
> @Robert: Do you have any idea why this was initially added? SLING-
> 3608 does not give much hints here. There should be no explicit
> runtime dependency to any tycho code IMHO.

The dependency is there to make sure that the OSGi metadata ( manifest,
SCR descriptors, etc ) is generated and put in the right location.

Without the tycho-m2e feature things will be broken out of the box.

So while there is no hard dependency, it is in my opinion required, at
least for now.

How to gracefully accommodate the transition is another issue, and I
don't have a good answer for that.

Robert

[jira] [Updated] (SLING-6101) Create JMX MBeans for SCD agents

[Simone Tripodi (JIRA)]

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

Simone Tripodi updated SLING-6101:
--
Attachment: SLING-6101.patch.2

Hi again [~teofili],
after a review at the current code status, I am proposing a new patch where:
 * useless properties have been cut off;
 * {{MBean}} creation in the _AgentFactories_ are less magical - I am not a big 
fan of introspection.
WDYT?

> Create JMX MBeans for SCD agents
> 
>
> Key: SLING-6101
> URL: https://issues.apache.org/jira/browse/SLING-6101
> Project: Sling
>  Issue Type: Sub-task
>  Components: Distribution
>Reporter: Simone Tripodi
>Assignee: Tommaso Teofili
> Attachments: SLING-6101.patch, SLING-6101.patch.1, SLING-6101.patch.2
>
>
> JMX support is an important tool for checking and monitoring status of SCD 
> agents, that should be added.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-6110) ServerSideTeleporter can't read the bundle header Sling-Test-WaitForService-Timeout

[Stefan Seifert (JIRA)]

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

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

Completed: At revision: 1763743  

thanks - i applied your patch in a slightly modified version.
please check if it still fixes the problem on your side.

> ServerSideTeleporter can't read the bundle header 
> Sling-Test-WaitForService-Timeout
> ---
>
> Key: SLING-6110
> URL: https://issues.apache.org/jira/browse/SLING-6110
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.8, JUnit Core 1.0.18
>Reporter: Marcel Jolk
>Assignee: Stefan Seifert
> Fix For: JUnit Core 1.0.20
>
>
> The _Sling-Test-WaitForService-Timeout_ bundle header is not properly read by 
> the {{ServerSideTeleporter}}. The method {{getService()}} reads the bundle 
> header using the {{BundleContext}} 
> ({{bundleContext.getBundle().getHeaders()}}). This {{BundleContext}} is set 
> in the {{Activator}} class on start of the bundle 
> {{org.apache.sling.junit.core}}. Therefore {{bundleContext.getBundle()}} 
> resolves to the bundle {{org.apache.sling.junit.core}}. This bundle does not 
> have the proper headers. Instead the bundle headers of the bundle, which is 
> created in the {{ClientSideTeleporter}}, including the class under test, 
> should be used. Thus its {{BundleContext}} is needed.
> I already made the required code changes using {{FrameWorkUtil}} to retrieve 
> the {{BundleContext}} for the class under test. I'll create a pull request, 
> which resolves this issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (SLING-6110) ServerSideTeleporter can't read the bundle header Sling-Test-WaitForService-Timeout

[Stefan Seifert (JIRA)]

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

Stefan Seifert reassigned SLING-6110:
-

Assignee: Stefan Seifert

> ServerSideTeleporter can't read the bundle header 
> Sling-Test-WaitForService-Timeout
> ---
>
> Key: SLING-6110
> URL: https://issues.apache.org/jira/browse/SLING-6110
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.8, JUnit Core 1.0.18
>Reporter: Marcel Jolk
>Assignee: Stefan Seifert
> Fix For: JUnit Core 1.0.20
>
>
> The _Sling-Test-WaitForService-Timeout_ bundle header is not properly read by 
> the {{ServerSideTeleporter}}. The method {{getService()}} reads the bundle 
> header using the {{BundleContext}} 
> ({{bundleContext.getBundle().getHeaders()}}). This {{BundleContext}} is set 
> in the {{Activator}} class on start of the bundle 
> {{org.apache.sling.junit.core}}. Therefore {{bundleContext.getBundle()}} 
> resolves to the bundle {{org.apache.sling.junit.core}}. This bundle does not 
> have the proper headers. Instead the bundle headers of the bundle, which is 
> created in the {{ClientSideTeleporter}}, including the class under test, 
> should be used. Thus its {{BundleContext}} is needed.
> I already made the required code changes using {{FrameWorkUtil}} to retrieve 
> the {{BundleContext}} for the class under test. I'll create a pull request, 
> which resolves this issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [sightly] How to add extra option to an expression

[Radu Cotescu]

Hi Feike,

A RuntimeExtension is just a runtime function. In order to have it invoked
you would also have to write a Filter [1] that, whenever your “dateFormat”
option is detected in an expression, it would transform that expression in
a RuntimeCall that would call your runtime function. At [2] you have a
simpler filter that you could use as a source of inspiration.

Let me know if you need more help.

Cheers,
Radu

[1] -
https://github.com/apache/sling/blob/trunk/bundles/scripting/sightly/compiler/src/main/java/org/apache/sling/scripting/sightly/impl/filter/Filter.java

[2] -
https://github.com/apache/sling/blob/trunk/bundles/scripting/sightly/compiler/src/main/java/org/apache/sling/scripting/sightly/impl/filter/I18nFilter.java


On Fri, 7 Oct 2016 at 09:24 Feike Visser  wrote:

> Hi there,
>
>
>
> I am working to implement [0], to add basically dateFormat option to a
> Sightly expression.
>
>
>
> Like ${ value @ dateFormat=’dd/mm/’ }
>
>
>
> Attached I have this implemented, but it is being invoked.
>
>
>
> Am I forgetting something?
>
>
>
> Thanks!
>
> Feike
>
>
>
> [0]: https://issues.apache.org/jira/browse/SLING-6102
>
>
>

[jira] [Resolved] (SLING-6094) HTL can generate invalid Java code by using user-supplied input

[Radu Cotescu (JIRA)]

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

Radu Cotescu resolved SLING-6094.
-
Resolution: Fixed

Fixed in [r1763629|https://svn.apache.org/r1763629], added tests in 
[r1763732|https://svn.apache.org/r1763732].

> HTL can generate invalid Java code by using user-supplied input
> ---
>
> Key: SLING-6094
> URL: https://issues.apache.org/jira/browse/SLING-6094
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Sightly Engine 1.0.18
>Reporter: Mark J. Becker
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Java Compiler 1.0.2, Scripting HTL Engine 
> 1.0.22
>
>
> HTL can generate invalid Java code by using user-supplied input or markup 
> elements as fragments for variable names, leading to failed script executions.
> This could happen with the {{data-sly-attribute}} plug-in, when the value is 
> a map and the plug-in has to analyse previously defined attributes (see 
> {{v-bind:src}}):
> {code:html}
> 
> {code}
> or with user-defined script variable names:
> {code:html}
> correctly escaped variable
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Sling IDE: Dependency from m2e-feature to org.sonatype.tycho.m2e.feature

[Konrad Windszus]

Currently the m2e-feature of the Sling IDE still requires the feature 
org.sonatype.tycho.m2e.feature 
(https://github.com/apache/sling/blob/4df9ab2d6592422889c71fa13afd453a10a5a626/tooling/ide/m2e-feature/feature.xml#L229
 
)
Since the latter seems rather unmaintained I would like to get rid of that 
dependency which was added in the context of 
https://issues.apache.org/jira/browse/SLING-3608 
.

This is also important since newer versions of the maven-bundle-plugin conflict 
with that extension 
(https://issues.apache.org/jira/browse/FELIX-4009?focusedCommentId=15192263=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15192263
 
)

@Robert: Do you have any idea why this was initially added? SLING-3608 does not 
give much hints here. There should be no explicit runtime dependency to any 
tycho code IMHO.

Re: Possibility of making nt:resource unreferenceable

[Julian Reschke]

On 2016-10-07 10:56, Carsten Ziegeler wrote:

Julian Reschke wrote

On 2016-10-07 08:04, Carsten Ziegeler wrote:

...
The easiest solution that comes to my mind is:

Whenever a nt:resource child node of a nt:file node is created, it is
silently changed to oak:resource.

Carsten
...


Observation: that might break code that actually wants a referenceable
node: it would create the node, check for the presence of
mix:referenceable, and then decide not to add it because it's already
there.



Well, there might be code that assumes that a file uploaded through
webdav is using a resource child node that is referenceable.
Or a file posted through the Sling POST servlet has this. Now, you could
argue if that code did not create the file, it should check node types,
but how likely is that if the code has history?

So whatever solution we pick, there is a risk that existing code fails.
...


That is true..

However, my preference would be to only break code which is 
non-conforming right now. Code should not rely on nt:resource being 
referenceable (see 
).


So my preference would be to make that change and see what breaks (and 
get that fixed).


> ...


Best regards, Julian

[jira] [Resolved] (SLING-6111) Allow to configure whether to create a snapshot during content package installation

[Konrad Windszus (JIRA)]

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

Konrad Windszus resolved SLING-6111.

   Resolution: Fixed
Fix Version/s: Installer Packages Factory 1.0.0

Fixed with [r1763710|https://svn.apache.org/r1763710].

> Allow to configure whether to create a snapshot during content package 
> installation
> ---
>
> Key: SLING-6111
> URL: https://issues.apache.org/jira/browse/SLING-6111
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Affects Versions: Installer Packages Factory 1.0.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Installer Packages Factory 1.0.0
>
>
> It would be nice to be able to somehow influence whether a snapshot should be 
> created prior to installing the content package (using 
> JcrPackage.extract(...), 
> http://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/packaging/JcrPackage.html#extract(org.apache.jackrabbit.vault.fs.io.ImportOptions))
>  vs. JcrPackage.import(...)).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (SLING-6110) ServerSideTeleporter can't read the bundle header Sling-Test-WaitForService-Timeout

[Robert Munteanu (JIRA)]

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

Robert Munteanu reopened SLING-6110:


We don't resolve issues until the code changes are integrated in the Sling SVN 
repository, so reopening for now.

But thanks for the report and the pull request :-)

> ServerSideTeleporter can't read the bundle header 
> Sling-Test-WaitForService-Timeout
> ---
>
> Key: SLING-6110
> URL: https://issues.apache.org/jira/browse/SLING-6110
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.8, JUnit Core 1.0.18
>Reporter: Marcel Jolk
> Fix For: JUnit Core 1.0.20
>
>
> The _Sling-Test-WaitForService-Timeout_ bundle header is not properly read by 
> the {{ServerSideTeleporter}}. The method {{getService()}} reads the bundle 
> header using the {{BundleContext}} 
> ({{bundleContext.getBundle().getHeaders()}}). This {{BundleContext}} is set 
> in the {{Activator}} class on start of the bundle 
> {{org.apache.sling.junit.core}}. Therefore {{bundleContext.getBundle()}} 
> resolves to the bundle {{org.apache.sling.junit.core}}. This bundle does not 
> have the proper headers. Instead the bundle headers of the bundle, which is 
> created in the {{ClientSideTeleporter}}, including the class under test, 
> should be used. Thus its {{BundleContext}} is needed.
> I already made the required code changes using {{FrameWorkUtil}} to retrieve 
> the {{BundleContext}} for the class under test. I'll create a pull request, 
> which resolves this issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6082) Add installer factory for content packages

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6082:


Created SLING-6111 to track that.

> Add installer factory for content packages
> --
>
> Key: SLING-6082
> URL: https://issues.apache.org/jira/browse/SLING-6082
> Project: Sling
>  Issue Type: New Feature
>  Components: Installer
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Installer Packages Factory 1.0.0
>
>
> in this mail thread better support for resource/content packaging was 
> discussed: http://sling.markmail.org/message/m2xfrnljzhqnfbpc
> We should add support for installing content packages to our OSGi installer



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-6111) Allow to configure whether to create a snapshot during content package installation

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-6111:
--

 Summary: Allow to configure whether to create a snapshot during 
content package installation
 Key: SLING-6111
 URL: https://issues.apache.org/jira/browse/SLING-6111
 Project: Sling
  Issue Type: Improvement
  Components: Installer
Affects Versions: Installer Packages Factory 1.0.0
Reporter: Konrad Windszus
Assignee: Konrad Windszus


It would be nice to be able to somehow influence whether a snapshot should be 
created prior to installing the content package (using JcrPackage.extract(...), 
http://jackrabbit.apache.org/filevault/apidocs/org/apache/jackrabbit/vault/packaging/JcrPackage.html#extract(org.apache.jackrabbit.vault.fs.io.ImportOptions))
 vs. JcrPackage.import(...)).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: svn commit: r1763633 - /sling/trunk/tooling/jenkins/create_jobs.groovy

[Robert Munteanu]

On Fri, 2016-10-07 at 08:22 +, Radu Cotescu wrote:
> Hi Robert,
> 
> The HTL integration tests were not run after changes in the HTL
> modules, so
> that's why I added those explicit downstream configurations. Do you
> have a
> better solution?

Downstream configurations are automatically detected for dependencies
declared in the pom.xml file.

They must be set manually for dependencies defined in the provisioning
model ( but you did more than that ).

With your recent change all should be fine.

I've also documented this a bit at

  https://cwiki.apache.org/confluence/display/SLING/Sling+Jenkins+Setup
#SlingJenkinsSetup-Managinginter-jobdependencies

Thanks,

Robert

> 
> Thanks,
> Radu
> 
> On Fri, 7 Oct 2016 at 10:11 Robert Munteanu 
> wrote:
> 
> > Hi Radu,
> > 
> > On Thu, 2016-10-06 at 17:08 +, r...@apache.org wrote:
> > > Author: radu
> > > Date: Thu Oct  6 17:08:14 2016
> > > New Revision: 1763633
> > > 
> > > URL: http://svn.apache.org/viewvc?rev=1763633=rev
> > > Log:
> > > SLING-6061 - Create per-module Jenkins jobs
> > > 
> > > * added downstream builds for HTL
> > 
> > 
> > The Jenkins jobs already infer dependencies based on the
> > information
> > defined in the pom.xml files.
> > 
> > I added the 'downstream' parameter to work around for not detecting
> > those dependencies for the provisioning model, but that does not
> > seem
> > to be what you are looking for.
> > 
> > If you look for instance at the distribution-core job [1] you will
> > see
> > that it has 3 downstream projects, but there are none defined in
> > the
> > create_jobs.groovy script.
> > 
> > What issue did you try to solve with this change?
> > 
> > Robert
> > 
> > 
> > 
> > > 
> > > Modified:
> > > sling/trunk/tooling/jenkins/create_jobs.groovy
> > > 
> > > Modified: sling/trunk/tooling/jenkins/create_jobs.groovy
> > > URL: http://svn.apache.org/viewvc/sling/trunk/tooling/jenkins/cre
> > > ate_
> > > jobs.groovy?rev=1763633=1763632=1763633=diff
> > > =
> > > 
> > > =
> > > --- sling/trunk/tooling/jenkins/create_jobs.groovy (original)
> > > +++ sling/trunk/tooling/jenkins/create_jobs.groovy Thu Oct  6
> > > 17:08:14 2016
> > > @@ -292,7 +292,23 @@ def modules = [
> > >  location: 'bundles/scripting/jsp'
> > >  ],
> > >  [
> > > -location: 'bundles/scripting/sightly/engine'
> > > +location: 'bundles/scripting/sightly/compiler',
> > > +downstream: ['bundles/scripting/sightly/java-compiler']
> > > +],
> > > +[
> > > +location: 'bundles/scripting/sightly/java-compiler',
> > > +downstream: [
> > > +'bundles/scripting/sightly/engine',
> > > +'bundles/scripting/sightly/js-use-provider',
> > > +'bundles/scripting/sightly/models-use-provider'
> > > +]
> > > +],
> > > +[
> > > +location: 'bundles/scripting/sightly/engine',
> > > +downstream: [
> > > +'bundles/scripting/sightly/testing-content',
> > > +'bundles/scripting/sightly/testing'
> > > +]
> > >  ],
> > >  [
> > >  location: 'bundles/scripting/sightly/js-use-provider'
> > > @@ -304,19 +320,14 @@ def modules = [
> > >  location: 'bundles/scripting/sightly/repl'
> > >  ],
> > >  [
> > > -location: 'bundles/scripting/sightly/testing-content'
> > > +location: 'bundles/scripting/sightly/testing-content',
> > > +downstream: ['bundles/scripting/sightly/testing']
> > >  ],
> > >  [
> > >  location: 'bundles/scripting/sightly/testing',
> > >  jdks: ['1.8']
> > >  ],
> > >  [
> > > -location: 'bundles/scripting/sightly/compiler'
> > > -],
> > > -[
> > > -location: 'bundles/scripting/sightly/java-compiler'
> > > -],
> > > -[
> > >  location: 'bundles/servlets/compat'
> > >  ],
> > >  [
> > > @@ -606,7 +617,7 @@ def jdkMapping = [
> > >  ]
> > > 
> > >  modules.each { module ->
> > > -
> > > +
> > >  def svnDir = svnBase +"/" + module.location
> > >  def jdks = module.jdks ?: defaultJdks
> > >  def deploy = true
> > > 
> > > 
> > > 
> > 
> > 
> > 

[jira] [Resolved] (SLING-6110) ServerSideTeleporter can't read the bundle header Sling-Test-WaitForService-Timeout

[Marcel Jolk (JIRA)]

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

Marcel Jolk resolved SLING-6110.

Resolution: Fixed

> ServerSideTeleporter can't read the bundle header 
> Sling-Test-WaitForService-Timeout
> ---
>
> Key: SLING-6110
> URL: https://issues.apache.org/jira/browse/SLING-6110
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.8, JUnit Core 1.0.18
>Reporter: Marcel Jolk
> Fix For: JUnit Core 1.0.20
>
>
> The _Sling-Test-WaitForService-Timeout_ bundle header is not properly read by 
> the {{ServerSideTeleporter}}. The method {{getService()}} reads the bundle 
> header using the {{BundleContext}} 
> ({{bundleContext.getBundle().getHeaders()}}). This {{BundleContext}} is set 
> in the {{Activator}} class on start of the bundle 
> {{org.apache.sling.junit.core}}. Therefore {{bundleContext.getBundle()}} 
> resolves to the bundle {{org.apache.sling.junit.core}}. This bundle does not 
> have the proper headers. Instead the bundle headers of the bundle, which is 
> created in the {{ClientSideTeleporter}}, including the class under test, 
> should be used. Thus its {{BundleContext}} is needed.
> I already made the required code changes using {{FrameWorkUtil}} to retrieve 
> the {{BundleContext}} for the class under test. I'll create a pull request, 
> which resolves this issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6110) ServerSideTeleporter can't read the bundle header Sling-Test-WaitForService-Timeout

[ASF GitHub Bot (JIRA)]

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

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

GitHub user marcel-j opened a pull request:

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

SLING-6110: use the proper bundleContext in the ServerSideTeleporter …

…to retrieve the correct bundle headers

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/marcel-j/sling trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/178.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #178


commit c400ed4291090da2fb522692a1837265d991db2a
Author: Marcel Jolk 
Date:   2016-10-07T09:00:10Z

SLING-6110: use the proper bundleContext in the ServerSideTeleporter to 
retrieve the correct bundle headers




> ServerSideTeleporter can't read the bundle header 
> Sling-Test-WaitForService-Timeout
> ---
>
> Key: SLING-6110
> URL: https://issues.apache.org/jira/browse/SLING-6110
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.8, JUnit Core 1.0.18
>Reporter: Marcel Jolk
> Fix For: JUnit Core 1.0.20
>
>
> The _Sling-Test-WaitForService-Timeout_ bundle header is not properly read by 
> the {{ServerSideTeleporter}}. The method {{getService()}} reads the bundle 
> header using the {{BundleContext}} 
> ({{bundleContext.getBundle().getHeaders()}}). This {{BundleContext}} is set 
> in the {{Activator}} class on start of the bundle 
> {{org.apache.sling.junit.core}}. Therefore {{bundleContext.getBundle()}} 
> resolves to the bundle {{org.apache.sling.junit.core}}. This bundle does not 
> have the proper headers. Instead the bundle headers of the bundle, which is 
> created in the {{ClientSideTeleporter}}, including the class under test, 
> should be used. Thus its {{BundleContext}} is needed.
> I already made the required code changes using {{FrameWorkUtil}} to retrieve 
> the {{BundleContext}} for the class under test. I'll create a pull request, 
> which resolves this issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] sling pull request #178: SLING-6110: use the proper bundleContext in the Ser...

[marcel-j]

GitHub user marcel-j opened a pull request:

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

SLING-6110: use the proper bundleContext in the ServerSideTeleporter …

…to retrieve the correct bundle headers

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/marcel-j/sling trunk

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/178.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #178


commit c400ed4291090da2fb522692a1837265d991db2a
Author: Marcel Jolk 
Date:   2016-10-07T09:00:10Z

SLING-6110: use the proper bundleContext in the ServerSideTeleporter to 
retrieve the correct bundle headers




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

[jira] [Created] (SLING-6110) ServerSideTeleporter can't read the bundle header Sling-Test-WaitForService-Timeout

[Marcel Jolk (JIRA)]

Marcel Jolk created SLING-6110:
--

 Summary: ServerSideTeleporter can't read the bundle header 
Sling-Test-WaitForService-Timeout
 Key: SLING-6110
 URL: https://issues.apache.org/jira/browse/SLING-6110
 Project: Sling
  Issue Type: Bug
  Components: Testing
Affects Versions: JUnit Core 1.0.18, JUnit Tests Teleporter 1.0.8
Reporter: Marcel Jolk
 Fix For: JUnit Core 1.0.20


The _Sling-Test-WaitForService-Timeout_ bundle header is not properly read by 
the {{ServerSideTeleporter}}. The method {{getService()}} reads the bundle 
header using the {{BundleContext}} 
({{bundleContext.getBundle().getHeaders()}}). This {{BundleContext}} is set in 
the {{Activator}} class on start of the bundle {{org.apache.sling.junit.core}}. 
Therefore {{bundleContext.getBundle()}} resolves to the bundle 
{{org.apache.sling.junit.core}}. This bundle does not have the proper headers. 
Instead the bundle headers of the bundle, which is created in the 
{{ClientSideTeleporter}}, including the class under test, should be used. Thus 
its {{BundleContext}} is needed.

I already made the required code changes using {{FrameWorkUtil}} to retrieve 
the {{BundleContext}} for the class under test. I'll create a pull request, 
which resolves this issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Possibility of making nt:resource unreferenceable

[Carsten Ziegeler]

Julian Reschke wrote
> On 2016-10-07 08:04, Carsten Ziegeler wrote:
>> ...
>> The easiest solution that comes to my mind is:
>>
>> Whenever a nt:resource child node of a nt:file node is created, it is
>> silently changed to oak:resource.
>>
>> Carsten
>> ...
> 
> Observation: that might break code that actually wants a referenceable
> node: it would create the node, check for the presence of
> mix:referenceable, and then decide not to add it because it's already
> there.
> 

Well, there might be code that assumes that a file uploaded through
webdav is using a resource child node that is referenceable.
Or a file posted through the Sling POST servlet has this. Now, you could
argue if that code did not create the file, it should check node types,
but how likely is that if the code has history?

So whatever solution we pick, there is a risk that existing code fails.

Having a single place / configuration where the magic is done, helps in
disabling the magic if required. Spreading it across modules is calling
for more trouble.

And I'm still wondering how likely it is that some code out there
assumes that the resource child node of a file is referenceable and is
actually using this.

Carsten

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

[jira] [Resolved] (SLING-6082) Add installer factory for content packages

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-6082.
-
Resolution: Fixed

I've added a first simple solution for installing/uninstalling content packages
Let's track every other feature in new issues

> Add installer factory for content packages
> --
>
> Key: SLING-6082
> URL: https://issues.apache.org/jira/browse/SLING-6082
> Project: Sling
>  Issue Type: New Feature
>  Components: Installer
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Installer Packages Factory 1.0.0
>
>
> in this mail thread better support for resource/content packaging was 
> discussed: http://sling.markmail.org/message/m2xfrnljzhqnfbpc
> We should add support for installing content packages to our OSGi installer



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6082) Add installer factory for content packages

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-6082:

Fix Version/s: Installer Packages Factory 1.0.0

> Add installer factory for content packages
> --
>
> Key: SLING-6082
> URL: https://issues.apache.org/jira/browse/SLING-6082
> Project: Sling
>  Issue Type: New Feature
>  Components: Installer
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Installer Packages Factory 1.0.0
>
>
> in this mail thread better support for resource/content packaging was 
> discussed: http://sling.markmail.org/message/m2xfrnljzhqnfbpc
> We should add support for installing content packages to our OSGi installer



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: svn commit: r1763633 - /sling/trunk/tooling/jenkins/create_jobs.groovy

[Radu Cotescu]

Hi Robert,

The HTL integration tests were not run after changes in the HTL modules, so
that's why I added those explicit downstream configurations. Do you have a
better solution?

Thanks,
Radu

On Fri, 7 Oct 2016 at 10:11 Robert Munteanu  wrote:

> Hi Radu,
>
> On Thu, 2016-10-06 at 17:08 +, r...@apache.org wrote:
> > Author: radu
> > Date: Thu Oct  6 17:08:14 2016
> > New Revision: 1763633
> >
> > URL: http://svn.apache.org/viewvc?rev=1763633=rev
> > Log:
> > SLING-6061 - Create per-module Jenkins jobs
> >
> > * added downstream builds for HTL
>
> The Jenkins jobs already infer dependencies based on the information
> defined in the pom.xml files.
>
> I added the 'downstream' parameter to work around for not detecting
> those dependencies for the provisioning model, but that does not seem
> to be what you are looking for.
>
> If you look for instance at the distribution-core job [1] you will see
> that it has 3 downstream projects, but there are none defined in the
> create_jobs.groovy script.
>
> What issue did you try to solve with this change?
>
> Robert
>
>
>
> >
> > Modified:
> > sling/trunk/tooling/jenkins/create_jobs.groovy
> >
> > Modified: sling/trunk/tooling/jenkins/create_jobs.groovy
> > URL: http://svn.apache.org/viewvc/sling/trunk/tooling/jenkins/create_
> > jobs.groovy?rev=1763633=1763632=1763633=diff
> > =
> > =
> > --- sling/trunk/tooling/jenkins/create_jobs.groovy (original)
> > +++ sling/trunk/tooling/jenkins/create_jobs.groovy Thu Oct  6
> > 17:08:14 2016
> > @@ -292,7 +292,23 @@ def modules = [
> >  location: 'bundles/scripting/jsp'
> >  ],
> >  [
> > -location: 'bundles/scripting/sightly/engine'
> > +location: 'bundles/scripting/sightly/compiler',
> > +downstream: ['bundles/scripting/sightly/java-compiler']
> > +],
> > +[
> > +location: 'bundles/scripting/sightly/java-compiler',
> > +downstream: [
> > +'bundles/scripting/sightly/engine',
> > +'bundles/scripting/sightly/js-use-provider',
> > +'bundles/scripting/sightly/models-use-provider'
> > +]
> > +],
> > +[
> > +location: 'bundles/scripting/sightly/engine',
> > +downstream: [
> > +'bundles/scripting/sightly/testing-content',
> > +'bundles/scripting/sightly/testing'
> > +]
> >  ],
> >  [
> >  location: 'bundles/scripting/sightly/js-use-provider'
> > @@ -304,19 +320,14 @@ def modules = [
> >  location: 'bundles/scripting/sightly/repl'
> >  ],
> >  [
> > -location: 'bundles/scripting/sightly/testing-content'
> > +location: 'bundles/scripting/sightly/testing-content',
> > +downstream: ['bundles/scripting/sightly/testing']
> >  ],
> >  [
> >  location: 'bundles/scripting/sightly/testing',
> >  jdks: ['1.8']
> >  ],
> >  [
> > -location: 'bundles/scripting/sightly/compiler'
> > -],
> > -[
> > -location: 'bundles/scripting/sightly/java-compiler'
> > -],
> > -[
> >  location: 'bundles/servlets/compat'
> >  ],
> >  [
> > @@ -606,7 +617,7 @@ def jdkMapping = [
> >  ]
> >
> >  modules.each { module ->
> > -
> > +
> >  def svnDir = svnBase +"/" + module.location
> >  def jdks = module.jdks ?: defaultJdks
> >  def deploy = true
> >
> >
> >
>
>

Re: svn commit: r1763633 - /sling/trunk/tooling/jenkins/create_jobs.groovy

[Robert Munteanu]

Hi Radu,

On Thu, 2016-10-06 at 17:08 +, r...@apache.org wrote:
> Author: radu
> Date: Thu Oct  6 17:08:14 2016
> New Revision: 1763633
> 
> URL: http://svn.apache.org/viewvc?rev=1763633=rev
> Log:
> SLING-6061 - Create per-module Jenkins jobs
> 
> * added downstream builds for HTL

The Jenkins jobs already infer dependencies based on the information
defined in the pom.xml files.

I added the 'downstream' parameter to work around for not detecting
those dependencies for the provisioning model, but that does not seem
to be what you are looking for.

If you look for instance at the distribution-core job [1] you will see
that it has 3 downstream projects, but there are none defined in the
create_jobs.groovy script.

What issue did you try to solve with this change?

Robert



> 
> Modified:
> sling/trunk/tooling/jenkins/create_jobs.groovy
> 
> Modified: sling/trunk/tooling/jenkins/create_jobs.groovy
> URL: http://svn.apache.org/viewvc/sling/trunk/tooling/jenkins/create_
> jobs.groovy?rev=1763633=1763632=1763633=diff
> =
> =
> --- sling/trunk/tooling/jenkins/create_jobs.groovy (original)
> +++ sling/trunk/tooling/jenkins/create_jobs.groovy Thu Oct  6
> 17:08:14 2016
> @@ -292,7 +292,23 @@ def modules = [
>  location: 'bundles/scripting/jsp'
>  ],
>  [
> -location: 'bundles/scripting/sightly/engine'
> +location: 'bundles/scripting/sightly/compiler',
> +downstream: ['bundles/scripting/sightly/java-compiler']
> +],
> +[
> +location: 'bundles/scripting/sightly/java-compiler',
> +downstream: [
> +'bundles/scripting/sightly/engine',
> +'bundles/scripting/sightly/js-use-provider',
> +'bundles/scripting/sightly/models-use-provider'
> +]
> +],
> +[
> +location: 'bundles/scripting/sightly/engine',
> +downstream: [
> +'bundles/scripting/sightly/testing-content',
> +'bundles/scripting/sightly/testing'
> +]
>  ],
>  [
>  location: 'bundles/scripting/sightly/js-use-provider'
> @@ -304,19 +320,14 @@ def modules = [
>  location: 'bundles/scripting/sightly/repl'
>  ],
>  [
> -location: 'bundles/scripting/sightly/testing-content'
> +location: 'bundles/scripting/sightly/testing-content',
> +downstream: ['bundles/scripting/sightly/testing']
>  ],
>  [
>  location: 'bundles/scripting/sightly/testing',
>  jdks: ['1.8']
>  ],
>  [
> -location: 'bundles/scripting/sightly/compiler'
> -],
> -[
> -location: 'bundles/scripting/sightly/java-compiler'
> -],
> -[
>  location: 'bundles/servlets/compat'
>  ],
>  [
> @@ -606,7 +617,7 @@ def jdkMapping = [
>  ]
>  
>  modules.each { module ->
> -  
> +
>  def svnDir = svnBase +"/" + module.location
>  def jdks = module.jdks ?: defaultJdks
>  def deploy = true
> 
> 
> 

[jira] [Commented] (SLING-2477) Configuration via sling:OsgiConfig nodes does not support all types

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-2477:


Note that for website changes to go live you need to publish them via 
https://cms.apache.org (search for "Sling" there) - I have done that now.

> Configuration via sling:OsgiConfig nodes does not support all types
> ---
>
> Key: SLING-2477
> URL: https://issues.apache.org/jira/browse/SLING-2477
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: JCR Installer 3.1.2
>Reporter: Alexander Klimetschek
> Attachments: SLING-2477.patch
>
>
> Most notably, the common "service.ranking" needs to be an Integer, while the 
> jcr property mapping only allows for "Long" types at the moment. The problem 
> is that JCR has a smaller set of property types than the OSGi config admin 
> (JCR: String, Boolean, Long, Double, Decimal; OSGi: String, Boolean, Long, 
> Integer, Float, Double, and probably more differences...).
> Similarly to properties files (which do it in the value like 
> 'service.ranking=I"-1"' with I=Integer), there must be a way to 
> explicitly specify the type regardless of the JCR type. For example, encoding 
> it in the property name like "service.ranking{int}".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-2756) Document sling:OsgiConfig format and properties format

[Carsten Ziegeler (JIRA)]

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

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

As SLING-2477 has been set to won't fix, we can do the same here

> Document sling:OsgiConfig format and properties format 
> ---
>
> Key: SLING-2756
> URL: https://issues.apache.org/jira/browse/SLING-2756
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: JCR Installer 3.1.6
>Reporter: Ian Boston
>
> Depending on the implementation approach chosen for SLING-2477:
> If the name{type} configuration format is chosen for the properties of an 
> sling:OsgiConfig node, then document both the name{type} format and the 
> I"1000" format.
> If the I"1000" format is chosen document it including details of JCR mappings.
> (The reason we need to document both for name{type} is that there are 
> downstream properties files in the I"1000" format already which we need to 
> support. Requiring migration of those properties and unifying on the 
> name{type} format for both file and sling:OsgiConfig would be a major effort, 
> and probably not worth it.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-4183) Jcr Installer Provider only supports storing array values for OSGi Component Properties (for sling:OsgiConfig resources) but not java.util.Vector

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-4183:


Documented the flaws of sling:OsgiConfig in 
http://sling.apache.org/documentation/bundles/jcr-installer-provider.html with 
r1763692.

> Jcr Installer Provider only supports storing array values for OSGi Component 
> Properties (for sling:OsgiConfig resources) but not java.util.Vector
> -
>
> Key: SLING-4183
> URL: https://issues.apache.org/jira/browse/SLING-4183
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Affects Versions: JCR Installer 3.1.8
>Reporter: Konrad Windszus
>
> The OSGi Compendium 4.3.0, $105.14.3.13 defines two storage formats for 
> multivalue entries: one is vector and the other one is array.
> As long as a configuration is maintained via the Felix Webconsole, it will 
> stick to the data format being given in the metatype manifest (through the 
> cardinality attribute).
> If the JCR Installer is used to deploy the OSGi configuration it will always 
> use array, in case the property is a multivalue property in the JCR 
> (https://github.com/apache/sling/blob/trunk/installer/providers/jcr/src/main/java/org/apache/sling/installer/provider/jcr/impl/ConfigNodeConverter.java#L99)
> In the best case the JCR Installer should evaluate the metatype manifest as 
> well. Or it should support {{Vector}}s through some special prefix on a 
> multivalue property name.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-2477) Configuration via sling:OsgiConfig nodes does not support all types

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-2477:


Documented the flaws of sling:OsgiConfig in 
http://sling.apache.org/documentation/bundles/jcr-installer-provider.html with 
r1763692.

> Configuration via sling:OsgiConfig nodes does not support all types
> ---
>
> Key: SLING-2477
> URL: https://issues.apache.org/jira/browse/SLING-2477
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: JCR Installer 3.1.2
>Reporter: Alexander Klimetschek
> Attachments: SLING-2477.patch
>
>
> Most notably, the common "service.ranking" needs to be an Integer, while the 
> jcr property mapping only allows for "Long" types at the moment. The problem 
> is that JCR has a smaller set of property types than the OSGi config admin 
> (JCR: String, Boolean, Long, Double, Decimal; OSGi: String, Boolean, Long, 
> Integer, Float, Double, and probably more differences...).
> Similarly to properties files (which do it in the value like 
> 'service.ranking=I"-1"' with I=Integer), there must be a way to 
> explicitly specify the type regardless of the JCR type. For example, encoding 
> it in the property name like "service.ranking{int}".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-4894) Allow failed package install to retry later on

[Timothee Maret (JIRA)]

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

Timothee Maret resolved SLING-4894.
---
   Resolution: Won't Fix
Fix Version/s: Installer Core 3.6.10

> Allow failed package install to retry later on
> --
>
> Key: SLING-4894
> URL: https://issues.apache.org/jira/browse/SLING-4894
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Affects Versions: Installer Core 3.6.8
>Reporter: Timothee Maret
> Fix For: Installer Core 3.6.10
>
>
> Currently, when an artifact can't be installed for any reason, the 
> OsgiInstaller will set the IGNORED state. The installer does not retry to 
> install artifacts with the IGNORED state.
> This issue tracks allowing packages installations to be tried later (for 
> instance on restart) when they fail.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6059) Context-Aware Config: Make resource inheritance for configuration collections configurable

[ASF GitHub Bot (JIRA)]

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

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

Github user stefanseifert closed the pull request at:

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


> Context-Aware Config: Make resource inheritance for configuration collections 
> configurable
> --
>
> Key: SLING-6059
> URL: https://issues.apache.org/jira/browse/SLING-6059
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> currently and automatic merging/combining of configuration resource items 
> takes place. example:
> {noformat}
> /conf/site1/feature/a
> /conf/site1/feature/c
> /conf/global/feature/b
> /libs/conf/feature/c
> {noformat}
> this returns a,b,c when config resource collection for "feature" is 
> requested. c is from /conf/site1/feature/c and not from /libs/conf/feature/c.
> this is inconsistent to the support for properties (where currently no such 
> "merging" is supported), and can have undesired effects.
> furthermore it is problematic when saving configuration collections via the 
> ConfigurationManager interface (SLING-6026). when storing a set of config 
> resources for /conf/site1 they are stored as children of /conf/site1/feature. 
> but when reading them again they are automatically merged with the others 
> from the fallback paths, and the user has no possibility to prevent this.
> so we should either disable this merging on paths, or implement it correctly 
> with giving the user control when merging should take place or not (confmgr 
> has a special property for this).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-6059) Context-Aware Config: Make resource inheritance for configuration collections configurable

[Stefan Seifert (JIRA)]

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

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

Completed: At revision: 1763689  

i've added an explicit check for "jcr:content" - to avoid filtering out nodes 
containing ":" users might create themselves. we can change it later or make it 
configurable if needed.

committed the PR.

> Context-Aware Config: Make resource inheritance for configuration collections 
> configurable
> --
>
> Key: SLING-6059
> URL: https://issues.apache.org/jira/browse/SLING-6059
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> currently and automatic merging/combining of configuration resource items 
> takes place. example:
> {noformat}
> /conf/site1/feature/a
> /conf/site1/feature/c
> /conf/global/feature/b
> /libs/conf/feature/c
> {noformat}
> this returns a,b,c when config resource collection for "feature" is 
> requested. c is from /conf/site1/feature/c and not from /libs/conf/feature/c.
> this is inconsistent to the support for properties (where currently no such 
> "merging" is supported), and can have undesired effects.
> furthermore it is problematic when saving configuration collections via the 
> ConfigurationManager interface (SLING-6026). when storing a set of config 
> resources for /conf/site1 they are stored as children of /conf/site1/feature. 
> but when reading them again they are automatically merged with the others 
> from the fallback paths, and the user has no possibility to prevent this.
> so we should either disable this merging on paths, or implement it correctly 
> with giving the user control when merging should take place or not (confmgr 
> has a special property for this).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] sling pull request #177: SLING-6059 Context-Aware Config: Make resource inhe...

[stefanseifert]

Github user stefanseifert closed the pull request at:

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


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

[jira] [Commented] (SLING-4894) Allow failed package install to retry later on

[Timothee Maret (JIRA)]

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

Timothee Maret commented on SLING-4894:
---

Thanks [~cziegeler] for looking at this. IIUC, this proposal and SLING-5745 
share the same goal of offering a mean to move artifacts from ignored to an 
installed state. I am fine if we chose the explicit approach (SLING-5745) 
rather than the implicit one proposed here.

> Allow failed package install to retry later on
> --
>
> Key: SLING-4894
> URL: https://issues.apache.org/jira/browse/SLING-4894
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Affects Versions: Installer Core 3.6.8
>Reporter: Timothee Maret
>
> Currently, when an artifact can't be installed for any reason, the 
> OsgiInstaller will set the IGNORED state. The installer does not retry to 
> install artifacts with the IGNORED state.
> This issue tracks allowing packages installations to be tried later (for 
> instance on restart) when they fail.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-741) Integrate OBR with JCR Install

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-741.

Resolution: Won't Fix

Closing this old issue as won't fix. I think at least for the Sling world the 
OBR idea never took off. If this happens, we can reconsider these things

> Integrate OBR with JCR Install
> --
>
> Key: SLING-741
> URL: https://issues.apache.org/jira/browse/SLING-741
> Project: Sling
>  Issue Type: New Feature
>  Components: Installer
>Affects Versions: JCR Installer 3.0.0
>Reporter: Julian Sedding
>Priority: Minor
>
> During a discussion I had with Felix Meschberger today, the following idea 
> was born.
> The aim of this proposal is to bridge the gap between bundles installed via 
> OBR and bundles installed via JCR Install, thus making the benefits (e.g. 
> backup, clustering) of JCR-installed bundles available to OBR.
> Instead of installing the bundle directly into the OSGi framework, OBR could 
> copy them into an install folder of the JCR. The bundle would then be 
> installed into the OSGi framework via JCR Install.
> Comments welcome.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-4815) Add OsgiInstallerImpl configuration to deactivate automatic uninstallation

[Carsten Ziegeler (JIRA)]

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

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

This should be solved as a configuration of the transformer factory dealing 
with the install/uninstall of packages. The OSGi installer has no knowledge 
about the artifacts

> Add OsgiInstallerImpl configuration to deactivate automatic uninstallation
> --
>
> Key: SLING-4815
> URL: https://issues.apache.org/jira/browse/SLING-4815
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Reporter: Geoffroy Schneck
>Priority: Minor
>
> Currently, deleting a contentpackage in the defined crx auto installer 
> directory after a previous drop, the package and the content will be 
> uninstalled from cq.
> This forces the content package to exist on the filesystem, and within the 
> CRX Package Manager, which increases used space .
> Ideally, the uninstall behavior could be configurable, so you can choose to 
> free space from the folder after initial installation .



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5779) Packaged OSGi config intermittently do not get installed before bundle start

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra updated SLING-5779:
---
Summary: Packaged OSGi config intermittently do not get installed before 
bundle start  (was: LuceneIndexProviderService is sometimes not configured)

> Packaged OSGi config intermittently do not get installed before bundle start
> 
>
> Key: SLING-5779
> URL: https://issues.apache.org/jira/browse/SLING-5779
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Reporter: Robert Munteanu
> Fix For: Installer Core 3.6.10
>
> Attachments: error.log.gz, stdout.log.gz
>
>
> (Setting version to Launchpad for now until we find out the root cause).
> From time to time I see the launchpad failing to start properly. The first 
> error that is visible is {noformat}10.06.2016 18:18:48.826 *ERROR* 
> [OsgiInstallerImpl] org.apache.jackrabbit.oak-lucene 
> [org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService(31)]
>  The activate method has thrown an exception (java.lang.NullPointerException: 
> Index directory cannot be determined as neither index directory path 
> [localIndexDir] nor repository home [repository.home] defined)
> java.lang.NullPointerException: Index directory cannot be determined as 
> neither index directory path [localIndexDir] nor repository home 
> [repository.home] defined
> at 
> com.google.common.base.Preconditions.checkNotNull(Preconditions.java:236){noformat}
> That's weird since the provisioning model holds all the configurations and 
> the relevant bundles are present in the {{:boot}} feature → Start Level 1.
> My launchpad jar was built from r1747733 ( but of course SNAPSHOT 
> dependencies mean that someone else building the launchpad will not get the 
> same exact output ).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5779) Packaged OSGi config intermittently do not get installed before bundle start

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra updated SLING-5779:
---
Component/s: (was: Launchpad)

> Packaged OSGi config intermittently do not get installed before bundle start
> 
>
> Key: SLING-5779
> URL: https://issues.apache.org/jira/browse/SLING-5779
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Reporter: Robert Munteanu
> Fix For: Installer Core 3.6.10
>
> Attachments: error.log.gz, stdout.log.gz
>
>
> (Setting version to Launchpad for now until we find out the root cause).
> From time to time I see the launchpad failing to start properly. The first 
> error that is visible is {noformat}10.06.2016 18:18:48.826 *ERROR* 
> [OsgiInstallerImpl] org.apache.jackrabbit.oak-lucene 
> [org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService(31)]
>  The activate method has thrown an exception (java.lang.NullPointerException: 
> Index directory cannot be determined as neither index directory path 
> [localIndexDir] nor repository home [repository.home] defined)
> java.lang.NullPointerException: Index directory cannot be determined as 
> neither index directory path [localIndexDir] nor repository home 
> [repository.home] defined
> at 
> com.google.common.base.Preconditions.checkNotNull(Preconditions.java:236){noformat}
> That's weird since the provisioning model holds all the configurations and 
> the relevant bundles are present in the {{:boot}} feature → Start Level 1.
> My launchpad jar was built from r1747733 ( but of course SNAPSHOT 
> dependencies mean that someone else building the launchpad will not get the 
> same exact output ).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5779) LuceneIndexProviderService is sometimes not configured

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra updated SLING-5779:
---
Fix Version/s: (was: Launchpad Builder 9)
   Installer Core 3.6.10

> LuceneIndexProviderService is sometimes not configured
> --
>
> Key: SLING-5779
> URL: https://issues.apache.org/jira/browse/SLING-5779
> Project: Sling
>  Issue Type: Bug
>  Components: Installer, Launchpad
>Reporter: Robert Munteanu
> Fix For: Installer Core 3.6.10
>
> Attachments: error.log.gz, stdout.log.gz
>
>
> (Setting version to Launchpad for now until we find out the root cause).
> From time to time I see the launchpad failing to start properly. The first 
> error that is visible is {noformat}10.06.2016 18:18:48.826 *ERROR* 
> [OsgiInstallerImpl] org.apache.jackrabbit.oak-lucene 
> [org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService(31)]
>  The activate method has thrown an exception (java.lang.NullPointerException: 
> Index directory cannot be determined as neither index directory path 
> [localIndexDir] nor repository home [repository.home] defined)
> java.lang.NullPointerException: Index directory cannot be determined as 
> neither index directory path [localIndexDir] nor repository home 
> [repository.home] defined
> at 
> com.google.common.base.Preconditions.checkNotNull(Preconditions.java:236){noformat}
> That's weird since the provisioning model holds all the configurations and 
> the relevant bundles are present in the {{:boot}} feature → Start Level 1.
> My launchpad jar was built from r1747733 ( but of course SNAPSHOT 
> dependencies mean that someone else building the launchpad will not get the 
> same exact output ).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-4815) Add OsgiInstallerImpl configuration to deactivate automatic uninstallation

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-4815:

Affects Version/s: (was: Sling Query 3.0.0)

> Add OsgiInstallerImpl configuration to deactivate automatic uninstallation
> --
>
> Key: SLING-4815
> URL: https://issues.apache.org/jira/browse/SLING-4815
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Reporter: Geoffroy Schneck
>Priority: Minor
>
> Currently, deleting a contentpackage in the defined crx auto installer 
> directory after a previous drop, the package and the content will be 
> uninstalled from cq.
> This forces the content package to exist on the filesystem, and within the 
> CRX Package Manager, which increases used space .
> Ideally, the uninstall behavior could be configurable, so you can choose to 
> free space from the folder after initial installation .



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5631) File Installer generating new pid's for factory in each start of the framework

[Carsten Ziegeler (JIRA)]

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

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

Thanks for the feedback, [~ivoleitao]

> File Installer generating new pid's for factory in each start of the framework
> --
>
> Key: SLING-5631
> URL: https://issues.apache.org/jira/browse/SLING-5631
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.6.8, File Installer 1.1.0, Installer 
> Configuration Factory 1.1.2
> Environment: Linux; bndtools;
>Reporter: Ivo Leitão
>Priority: Minor
> Attachments: cpeng.error.05-31-2016.log, log.zip, 
> org.apache.sling.commons.log.LogManager.factory.config-debug.log.config, 
> org.apache.sling.commons.log.LogManager.factory.writer-debug.log.config
>
>
> Hi,
> I'm changing from felix file installer to Sling file installer and I stumbled 
> upon a problem that I was not seeing on felix file installer. I'm using 
> bndtools to develop and I make multiple restarts. The first time I booted the 
> felix framework I dint't have any problems. The second time my factory 
> configurations became repeated. To give an example:
> First Boot:
> 05e9adef-c7a9-49b5-a243-39f029e4389c.config
> factory.config with:
> factory.pidList=[ \
>   "platform.directory.datasource.05e9adef-c7a9-49b5-a243-39f029e4389c", \
>   ]
> Second Boot:
> 05e9adef-c7a9-49b5-a243-39f029e4389c.config  
> 5b18e3a2-6bc3-497e-9b3c-e09107552df8.config  
> factory.config with:
> factory.pid="platform.directory.datasource"
> factory.pidList=[ \
>   "platform.directory.datasource.5b18e3a2-6bc3-497e-9b3c-e09107552df8", \
>   "platform.directory.datasource.05e9adef-c7a9-49b5-a243-39f029e4389c", \
>   ]
> This was not happening with file install. Is this by design and I need to 
> clean config admin dir's every time I boot or a bug in file install ?
> This is causing multiple problems inclusive with sling log component wich 
> immediately complains with and exception
> 30.03.2016 19:14:37.697 *ERROR* [CM Configuration Updater (Update: 
> pid=org.apache.sling.commons.log.LogManager.factory.config.30a7d154-cf89-47da-a1af-62afd3c6f96d)]
>  org.apache.felix.configadmin.1.8.8 
> [[org.osgi.service.cm.ConfigurationAdmin]][org.osgi.service.cm.ManagedServiceFactory,
>  id=7
> Updating property org.apache.sling.commons.log.names of configuration 
> org.apache.sling.commons.log.LogManager.factory.config.30a7d154-cf89-47da-a1af-62afd3c6f96d
>  caused a problem: Category platform already defined by configuration 
> org.apache.sling.commons.log.LogManager.factory.config.30a7d154-cf89-47da-a1af-62afd3c6f96d
> org.osgi.service.cm.ConfigurationException: 
> org.apache.sling.commons.log.names : Category platform already defined by 
> configuration 
> org.apache.sling.commons.log.LogManager.factory.config.30a7d154-cf89-47da-a1af-62afd3c6f96d
>   at 
> org.apache.sling.commons.log.logback.internal.config.LoggerManagedServiceFactory.updated(LoggerManagedServiceFactory.java:36)
>   at 
> org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.updated(ManagedServiceFactoryTracker.java:159)
>   at 
> org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.provideConfiguration(ManagedServiceFactoryTracker.java:93)
>   at 
> org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1753)
>   at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143)
>   at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: 
> org.apache.sling.commons.log.logback.internal.config.ConfigurationException: 
>   at 
> org.apache.sling.commons.log.logback.internal.LogConfigManager.updateLoggerConfiguration(LogConfigManager.java:533)
>   at 
> org.apache.sling.commons.log.logback.internal.config.LoggerManagedServiceFactory.updated(LoggerManagedServiceFactory.java:34)
>   ... 6 common frames omitted



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5779) LuceneIndexProviderService is sometimes not configured

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra updated SLING-5779:
---
Component/s: Installer

> LuceneIndexProviderService is sometimes not configured
> --
>
> Key: SLING-5779
> URL: https://issues.apache.org/jira/browse/SLING-5779
> Project: Sling
>  Issue Type: Bug
>  Components: Installer, Launchpad
>Reporter: Robert Munteanu
> Fix For: Launchpad Builder 9
>
> Attachments: error.log.gz, stdout.log.gz
>
>
> (Setting version to Launchpad for now until we find out the root cause).
> From time to time I see the launchpad failing to start properly. The first 
> error that is visible is {noformat}10.06.2016 18:18:48.826 *ERROR* 
> [OsgiInstallerImpl] org.apache.jackrabbit.oak-lucene 
> [org.apache.jackrabbit.oak.plugins.index.lucene.LuceneIndexProviderService(31)]
>  The activate method has thrown an exception (java.lang.NullPointerException: 
> Index directory cannot be determined as neither index directory path 
> [localIndexDir] nor repository home [repository.home] defined)
> java.lang.NullPointerException: Index directory cannot be determined as 
> neither index directory path [localIndexDir] nor repository home 
> [repository.home] defined
> at 
> com.google.common.base.Preconditions.checkNotNull(Preconditions.java:236){noformat}
> That's weird since the provisioning model holds all the configurations and 
> the relevant bundles are present in the {{:boot}} feature → Start Level 1.
> My launchpad jar was built from r1747733 ( but of course SNAPSHOT 
> dependencies mean that someone else building the launchpad will not get the 
> same exact output ).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-2060) Refresh bundles with optional dependencies if such dependency is installed

[Carsten Ziegeler (JIRA)]

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

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

Set to won't fix as there does not seem to be a real need for this

> Refresh bundles with optional dependencies if such dependency is installed
> --
>
> Key: SLING-2060
> URL: https://issues.apache.org/jira/browse/SLING-2060
> Project: Sling
>  Issue Type: New Feature
>  Components: Installer
>Affects Versions: Installer Core 3.1.2
>Reporter: Carsten Ziegeler
>
> When a bundle has an optional dependency and a new bundle is installed 
> afterwards having this dependency, the first bundle should be refreshed
> See [1] for some discussions on the topic
> [1] 
> http://markmail.org/thread/qiqfb3uvrb6apimt#query:+page:1+mid:yarhksmfadr6hu3r+state:results



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-2523) Improve the JCR Installer

[Carsten Ziegeler (JIRA)]

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

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

The jcr installer implementation has changed a little bit
In addition we discourage from using the repo to install bundles/configs
The provisioning model should be used
Therefore setting this to won't fix

> Improve the JCR Installer
> -
>
> Key: SLING-2523
> URL: https://issues.apache.org/jira/browse/SLING-2523
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Affects Versions: JCR Installer 3.1.4
>Reporter: Carsten Ziegeler
> Attachments: SLING-2523_1.patch, SLING-2523_2.patch
>
>
> The current implementation has some drawbacks: 
> - it registers several observation listeners
> - to handle deletes it has to register even more listeners
> - observation events are just used as markers and there is a polling thread 
> running continously to check for changed markers and then rescan a sub tree 
> in the repository
> - changes are not reported to the OSGi installer in one method call
> I think we can simplify and improve the implementation by
> - just registering a single observation listener for root and then do simple 
> path matching operations
> - use the observation events to detect what has changed
> - report the changes in a single method call
> In addition it would be nice if the jcr installer waits befire reporting 
> changes from an observation event and looks if there is not another 
> observation event coming in "right after". This could improve situations 
> where changes are not done by a single save but by a serious of saves



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-2752) Revisit re-saving of config settings in light of support for wider range of types.

[Carsten Ziegeler (JIRA)]

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

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

As SLING-2477 is set to won't fix, we can resolve this one as well

> Revisit re-saving of config settings in light of support for wider range of 
> types.
> --
>
> Key: SLING-2752
> URL: https://issues.apache.org/jira/browse/SLING-2752
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: JCR Installer 3.1.6
>Reporter: Ian Boston
>
> Post SLING-2477 we need to revisit SLING-1971 to ensure that anything done 
> there to enable write back of configuration settings still works. Exactly 
> what needs to be worked out.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-2477) Configuration via sling:OsgiConfig nodes does not support all types

[Carsten Ziegeler (JIRA)]

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

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

Setting to won't fix as we have the file based approach solving the problem.
In addition, we discourage using the repo for defining configurations. The 
provisioning model is the better option

> Configuration via sling:OsgiConfig nodes does not support all types
> ---
>
> Key: SLING-2477
> URL: https://issues.apache.org/jira/browse/SLING-2477
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: JCR Installer 3.1.2
>Reporter: Alexander Klimetschek
> Attachments: SLING-2477.patch
>
>
> Most notably, the common "service.ranking" needs to be an Integer, while the 
> jcr property mapping only allows for "Long" types at the moment. The problem 
> is that JCR has a smaller set of property types than the OSGi config admin 
> (JCR: String, Boolean, Long, Double, Decimal; OSGi: String, Boolean, Long, 
> Integer, Float, Double, and probably more differences...).
> Similarly to properties files (which do it in the value like 
> 'service.ranking=I"-1"' with I=Integer), there must be a way to 
> explicitly specify the type regardless of the JCR type. For example, encoding 
> it in the property name like "service.ranking{int}".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-4183) Jcr Installer Provider only supports storing array values for OSGi Component Properties (for sling:OsgiConfig resources) but not java.util.Vector

[Carsten Ziegeler (JIRA)]

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

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

There is a solution to this: use a configuration file
Therefore setting this to won't fix

> Jcr Installer Provider only supports storing array values for OSGi Component 
> Properties (for sling:OsgiConfig resources) but not java.util.Vector
> -
>
> Key: SLING-4183
> URL: https://issues.apache.org/jira/browse/SLING-4183
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Affects Versions: JCR Installer 3.1.8
>Reporter: Konrad Windszus
>
> The OSGi Compendium 4.3.0, $105.14.3.13 defines two storage formats for 
> multivalue entries: one is vector and the other one is array.
> As long as a configuration is maintained via the Felix Webconsole, it will 
> stick to the data format being given in the metatype manifest (through the 
> cardinality attribute).
> If the JCR Installer is used to deploy the OSGi configuration it will always 
> use array, in case the property is a multivalue property in the JCR 
> (https://github.com/apache/sling/blob/trunk/installer/providers/jcr/src/main/java/org/apache/sling/installer/provider/jcr/impl/ConfigNodeConverter.java#L99)
> In the best case the JCR Installer should evaluate the metatype manifest as 
> well. Or it should support {{Vector}}s through some special prefix on a 
> multivalue property name.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-4558) Simpler serviceuser config for service user mappings

[Carsten Ziegeler (JIRA)]

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

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

As mentioned handling this as a special case its imho not the way to solve it. 
In general, we discourage having configurations in the repository anyway. The 
provisioning model should be used to define all configurations.
Therefore setting this to won't fix

> Simpler serviceuser config for service user mappings
> 
>
> Key: SLING-4558
> URL: https://issues.apache.org/jira/browse/SLING-4558
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Reporter: Alexander Klimetschek
> Attachments: SLING-4558.patch
>
>
> For a service user configuration (amendment), one has to currently remember a 
> weird long PID:
> {{org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended}}
> plus making sure it has a unique ID by appending {{-something}}, which 
> confuses people as to whether that "something" must correspond to a bundle or 
> service name (not necessary) or they come up with these long names:
> {{org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended-org.apache.sling.serviceusermapping.impl.ServiceUserMapperImpl.amended.something.xml}}
> which then create too long paths for some cases (git checkouts under windows 
> or jcr repository limitations).
> A simple {{serviceuser}} config node name would be better.
> For reference, the target service is 
> [MappingConfigAmendment|https://github.com/apache/sling/blob/trunk/bundles/extensions/serviceusermapper/src/main/java/org/apache/sling/serviceusermapping/impl/MappingConfigAmendment.java]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-4746) Installer does not consistently update bundle location in Webconsole

[Carsten Ziegeler (JIRA)]

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

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

Bundle location is not updated when a bundle is updated (this is according to 
the spec).
It really depends if the remove/add of a bundle is reported to the installer in 
one command. In this case an update is performed, but if its remove first, and 
then add, the bundle is uninstalled and then installed. Creating a new bundle 
with a new location.
This can happen with the jcr installer and package installs for example.

Therefore I set this to won't fix. If you think there is still an issue to be 
fixed in the installer please reopen but also provide a reproducible test 
scenario

> Installer does not consistently update bundle location in Webconsole
> 
>
> Key: SLING-4746
> URL: https://issues.apache.org/jira/browse/SLING-4746
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: File Installer 1.0.4
>Reporter: Jörg Hoh
>
> I have a sling-based application using Apache Oak as content repository. I 
> started with Oak being part of the Launchpad, so I had for example a bundle 
> "org.apache.jackrabbit.oak-solr-osgi" in version 1.0. The OSGI Webconsole 
> displayed as bundle location 
> "launchpad:resources/install.crx3/15/oak-solr-osgi-1.0.0.jar", which is 
> perfect.
> Now I upgraded Oak to version 1.0.13 by putting the bundles inside 
> /libs/system/install. The OSGI Webconsole displays for my bundle 
> oak-solr-osgi the version 1.0.13, but still shows as Bundle location the 
> string "launchpad:resources/install.crx3/15/oak-solr-osgi-1.0.0.jar".
> But this isn't true for all bundles. For example I deployed the bundle oak-mk 
> in version 1.0.13 in the very same way as the oak-solr-osgi bundle, but there 
> the bundle location is updated and displays 
> "jcrinstall:/libs/system/install.crx3/oak-mk-1.0.13.jar", which is correct.
> So the update process seems to work to reliably. I've seen this behaviour not 
> only for mixed installers, but also with jcrinstaller only.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-4867) EntityResourceList should be thread-safe

[Carsten Ziegeler (JIRA)]

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

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

I'll close this as won't fix as this is either fixed already, or not 
reproducible. If the issue appears again, please reopen

> EntityResourceList should be thread-safe
> 
>
> Key: SLING-4867
> URL: https://issues.apache.org/jira/browse/SLING-4867
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.6.6
>Reporter: Julian Sedding
>
> There was a Jenkins test failure\[0\] due to the following exception. This 
> looks like {{EntityResourceList}} should be thread-safe.
> [~cziegeler], I took the liberty to assign the issue to you. Hope that's ok.
> {noformat}
> Exception in thread "OsgiInstallerImpl" 
> java.util.ConcurrentModificationException
>   at java.util.ArrayList.sort(ArrayList.java:1456)
>   at java.util.Collections.sort(Collections.java:141)
>   at 
> org.apache.sling.installer.core.impl.EntityResourceList.getActiveResource(EntityResourceList.java:125)
>   at 
> org.apache.sling.installer.factories.configuration.impl.ConfigTaskCreator.createTask(ConfigTaskCreator.java:71)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.getTask(OsgiInstallerImpl.java:632)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.computeTasks(OsgiInstallerImpl.java:612)
>   at 
> org.apache.sling.installer.core.impl.OsgiInstallerImpl.run(OsgiInstallerImpl.java:262)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> \[0\] https://builds.apache.org/job/sling-trunk-1.8/1292/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-4894) Allow failed package install to retry later on

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-4894:
-

I think the current handling is fine, and I think we should rather add some 
management functions like suggested in SLING-5745

> Allow failed package install to retry later on
> --
>
> Key: SLING-4894
> URL: https://issues.apache.org/jira/browse/SLING-4894
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Affects Versions: Installer Core 3.6.8
>Reporter: Timothee Maret
>
> Currently, when an artifact can't be installed for any reason, the 
> OsgiInstaller will set the IGNORED state. The installer does not retry to 
> install artifacts with the IGNORED state.
> This issue tracks allowing packages installations to be tried later (for 
> instance on restart) when they fail.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5014) Installer blacklist, to avoid reinstalling older bundles

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-5014:
-

[~dsuess] Thanks for the patch, unfortunately , the patch also contains a lot 
of reformatting. In addition I think this should go directory into the core, 
avoiding the unstable dependency to the existence of another service. The 
installer might start before the blacklistener service etc. So I think making 
this a feature of the OSGi installer itself, is the better option.
Could you please provide an updated patch?

> Installer blacklist, to avoid reinstalling older bundles
> 
>
> Key: SLING-5014
> URL: https://issues.apache.org/jira/browse/SLING-5014
> Project: Sling
>  Issue Type: Bug
>  Components: Installer
>Affects Versions: Installer Core 3.6.6
>Reporter: Dominik Süß
> Attachments: SLING-5014-1.diff
>
>
> In case a bundle has mutliple install candiates only the highest version 
> (with the highest priorty for the same versions) wins. An uninstall directive 
> in the Sling bootstrap.txt file or provisioning model uninstalls this 
> version. The way the OSGi install behavior is defined this lets the next 
> artifact in the priority queue to get active and consequently only leads to 
> downgrade to the next in the queue.
> As the uninstall directive declares a range that should be uninstalled the 
> expectation is that after a startup with such an uninstall directive none of 
> the declared versions are in an installed state. In consequence the OSGi 
> installer must save this metainformation in the state that prevents a 
> downgrade to a version that is part of an active uninstall directive.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (SLING-5542) BundleUpdateTask should log problems on loglevel WARN

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reassigned SLING-5542:
---

Assignee: Carsten Ziegeler

> BundleUpdateTask should log problems on loglevel WARN
> -
>
> Key: SLING-5542
> URL: https://issues.apache.org/jira/browse/SLING-5542
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Affects Versions: Installer Core 3.6.4
>Reporter: Jörg Hoh
>Assignee: Carsten Ziegeler
> Fix For: Installer Core 3.6.10
>
> Attachments: SLING-5542.patch
>
>
> A failing UpdateTask should log the exception on loglevel WARN instead of 
> just INFO.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5542) BundleUpdateTask should log problems on loglevel WARN

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-5542.
-
Resolution: Fixed

Thanks for the patch, Jörg. It's applied

> BundleUpdateTask should log problems on loglevel WARN
> -
>
> Key: SLING-5542
> URL: https://issues.apache.org/jira/browse/SLING-5542
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Affects Versions: Installer Core 3.6.4
>Reporter: Jörg Hoh
>Assignee: Carsten Ziegeler
> Fix For: Installer Core 3.6.10
>
> Attachments: SLING-5542.patch
>
>
> A failing UpdateTask should log the exception on loglevel WARN instead of 
> just INFO.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5542) BundleUpdateTask should log problems on loglevel WARN

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-5542:

Fix Version/s: Installer Core 3.6.10

> BundleUpdateTask should log problems on loglevel WARN
> -
>
> Key: SLING-5542
> URL: https://issues.apache.org/jira/browse/SLING-5542
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer
>Affects Versions: Installer Core 3.6.4
>Reporter: Jörg Hoh
> Fix For: Installer Core 3.6.10
>
> Attachments: SLING-5542.patch
>
>
> A failing UpdateTask should log the exception on loglevel WARN instead of 
> just INFO.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (SLING-6104) Improve handling to avoid Oak warning

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler reassigned SLING-6104:
---

Assignee: Carsten Ziegeler

> Improve handling to avoid Oak warning
> -
>
> Key: SLING-6104
> URL: https://issues.apache.org/jira/browse/SLING-6104
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer, JCR
>Affects Versions: JCR Resource 2.8.0, JCR Installer 3.1.16, Pipes 0.0.10
>Reporter: Jörg Hoh
>Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.8.2, JCR Installer 3.1.18, Pipes 0.0.10
>
>
> I often see messages like this in our logs (AEM 6.0):
> {noformat}
> WARN org.apache.jackrabbit.oak.jcr.session.ItemImpl Item#refresh invokes 
> Session#refresh!
> {noformat}
> I found that in 
> bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/JcrResourceUtil.java
>  there is one occurrences of this pattern:
> {code}
> 444 } catch (RepositoryException re) {
> 445 // we ignore this as this folder might be 
> created from a different task
> 446 node.refresh(false);
> 447 }
> {code}
> This should be changed to {code}node.getSession().refresh(false);{code} to 
> avoid this warning. From my point of view the semantic does not change.
> I found the same pattern here as well:
> * 
> installer/providers/jcr/src/main/java/org/apache/sling/installer/provider/jcr/impl/JcrUtil.java
> * 
> contrib/extensions/sling-pipes/src/main/java/org/apache/sling/pipes/PathPipe.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-6104) Improve handling to avoid Oak warning

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-6104.
-
Resolution: Fixed

Thanks for reporting.

I've fixed the three places

> Improve handling to avoid Oak warning
> -
>
> Key: SLING-6104
> URL: https://issues.apache.org/jira/browse/SLING-6104
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer, JCR
>Affects Versions: JCR Resource 2.8.0, JCR Installer 3.1.16, Pipes 0.0.10
>Reporter: Jörg Hoh
>Assignee: Carsten Ziegeler
> Fix For: JCR Resource 2.8.2, JCR Installer 3.1.18, Pipes 0.0.10
>
>
> I often see messages like this in our logs (AEM 6.0):
> {noformat}
> WARN org.apache.jackrabbit.oak.jcr.session.ItemImpl Item#refresh invokes 
> Session#refresh!
> {noformat}
> I found that in 
> bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/JcrResourceUtil.java
>  there is one occurrences of this pattern:
> {code}
> 444 } catch (RepositoryException re) {
> 445 // we ignore this as this folder might be 
> created from a different task
> 446 node.refresh(false);
> 447 }
> {code}
> This should be changed to {code}node.getSession().refresh(false);{code} to 
> avoid this warning. From my point of view the semantic does not change.
> I found the same pattern here as well:
> * 
> installer/providers/jcr/src/main/java/org/apache/sling/installer/provider/jcr/impl/JcrUtil.java
> * 
> contrib/extensions/sling-pipes/src/main/java/org/apache/sling/pipes/PathPipe.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6104) Improve handling to avoid Oak warning

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6104:
-

Fixed jcr installer in rev 1763687

> Improve handling to avoid Oak warning
> -
>
> Key: SLING-6104
> URL: https://issues.apache.org/jira/browse/SLING-6104
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer, JCR
>Affects Versions: JCR Resource 2.8.0, JCR Installer 3.1.16, Pipes 0.0.10
>Reporter: Jörg Hoh
> Fix For: JCR Resource 2.8.2, JCR Installer 3.1.18, Pipes 0.0.10
>
>
> I often see messages like this in our logs (AEM 6.0):
> {noformat}
> WARN org.apache.jackrabbit.oak.jcr.session.ItemImpl Item#refresh invokes 
> Session#refresh!
> {noformat}
> I found that in 
> bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/JcrResourceUtil.java
>  there is one occurrences of this pattern:
> {code}
> 444 } catch (RepositoryException re) {
> 445 // we ignore this as this folder might be 
> created from a different task
> 446 node.refresh(false);
> 447 }
> {code}
> This should be changed to {code}node.getSession().refresh(false);{code} to 
> avoid this warning. From my point of view the semantic does not change.
> I found the same pattern here as well:
> * 
> installer/providers/jcr/src/main/java/org/apache/sling/installer/provider/jcr/impl/JcrUtil.java
> * 
> contrib/extensions/sling-pipes/src/main/java/org/apache/sling/pipes/PathPipe.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6104) Improve handling to avoid Oak warning

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6104:
-

Fixed jcr.resource in rev 1763684

> Improve handling to avoid Oak warning
> -
>
> Key: SLING-6104
> URL: https://issues.apache.org/jira/browse/SLING-6104
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer, JCR
>Affects Versions: JCR Resource 2.8.0, JCR Installer 3.1.16, Pipes 0.0.10
>Reporter: Jörg Hoh
> Fix For: JCR Resource 2.8.2, JCR Installer 3.1.18, Pipes 0.0.10
>
>
> I often see messages like this in our logs (AEM 6.0):
> {noformat}
> WARN org.apache.jackrabbit.oak.jcr.session.ItemImpl Item#refresh invokes 
> Session#refresh!
> {noformat}
> I found that in 
> bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/JcrResourceUtil.java
>  there is one occurrences of this pattern:
> {code}
> 444 } catch (RepositoryException re) {
> 445 // we ignore this as this folder might be 
> created from a different task
> 446 node.refresh(false);
> 447 }
> {code}
> This should be changed to {code}node.getSession().refresh(false);{code} to 
> avoid this warning. From my point of view the semantic does not change.
> I found the same pattern here as well:
> * 
> installer/providers/jcr/src/main/java/org/apache/sling/installer/provider/jcr/impl/JcrUtil.java
> * 
> contrib/extensions/sling-pipes/src/main/java/org/apache/sling/pipes/PathPipe.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-6104) Improve handling to avoid Oak warning

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6104:
-

Fixed pipes in rev 1763685

> Improve handling to avoid Oak warning
> -
>
> Key: SLING-6104
> URL: https://issues.apache.org/jira/browse/SLING-6104
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer, JCR
>Affects Versions: JCR Resource 2.8.0, JCR Installer 3.1.16, Pipes 0.0.10
>Reporter: Jörg Hoh
> Fix For: JCR Resource 2.8.2, JCR Installer 3.1.18, Pipes 0.0.10
>
>
> I often see messages like this in our logs (AEM 6.0):
> {noformat}
> WARN org.apache.jackrabbit.oak.jcr.session.ItemImpl Item#refresh invokes 
> Session#refresh!
> {noformat}
> I found that in 
> bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/JcrResourceUtil.java
>  there is one occurrences of this pattern:
> {code}
> 444 } catch (RepositoryException re) {
> 445 // we ignore this as this folder might be 
> created from a different task
> 446 node.refresh(false);
> 447 }
> {code}
> This should be changed to {code}node.getSession().refresh(false);{code} to 
> avoid this warning. From my point of view the semantic does not change.
> I found the same pattern here as well:
> * 
> installer/providers/jcr/src/main/java/org/apache/sling/installer/provider/jcr/impl/JcrUtil.java
> * 
> contrib/extensions/sling-pipes/src/main/java/org/apache/sling/pipes/PathPipe.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-6104) Improve handling to avoid Oak warning

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler updated SLING-6104:

Fix Version/s: Pipes 0.0.10
   JCR Installer 3.1.18
   JCR Resource 2.8.2

> Improve handling to avoid Oak warning
> -
>
> Key: SLING-6104
> URL: https://issues.apache.org/jira/browse/SLING-6104
> Project: Sling
>  Issue Type: Improvement
>  Components: Installer, JCR
>Affects Versions: JCR Resource 2.8.0, JCR Installer 3.1.16, Pipes 0.0.10
>Reporter: Jörg Hoh
> Fix For: JCR Resource 2.8.2, JCR Installer 3.1.18, Pipes 0.0.10
>
>
> I often see messages like this in our logs (AEM 6.0):
> {noformat}
> WARN org.apache.jackrabbit.oak.jcr.session.ItemImpl Item#refresh invokes 
> Session#refresh!
> {noformat}
> I found that in 
> bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/JcrResourceUtil.java
>  there is one occurrences of this pattern:
> {code}
> 444 } catch (RepositoryException re) {
> 445 // we ignore this as this folder might be 
> created from a different task
> 446 node.refresh(false);
> 447 }
> {code}
> This should be changed to {code}node.getSession().refresh(false);{code} to 
> avoid this warning. From my point of view the semantic does not change.
> I found the same pattern here as well:
> * 
> installer/providers/jcr/src/main/java/org/apache/sling/installer/provider/jcr/impl/JcrUtil.java
> * 
> contrib/extensions/sling-pipes/src/main/java/org/apache/sling/pipes/PathPipe.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[sightly] How to add extra option to an expression

[Feike Visser]

Hi there,

I am working to implement [0], to add basically dateFormat option to a Sightly 
expression.

Like ${ value @ dateFormat=’dd/mm/’ }

Attached I have this implemented, but it is being invoked.

Am I forgetting something?

Thanks!
Feike

[0]: https://issues.apache.org/jira/browse/SLING-6102

[jira] [Commented] (SLING-6059) Context-Aware Config: Make resource inheritance for configuration collections configurable

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6059:
-

Thanks [~sseif...@pro-vision.de], proposal looks good to me

Nodes with ":" were skipped to not include jcr:content in the result, but I 
didn't want to explicitely code this in and thought that we simply skip 
everything with a prefix - maybe really to magical.
Should we hard-code jcr:content? Or make it configurable with jcr:content being 
the default? Not sure what the best option is. Adding a filter service sounds 
like too much overhead, but is another option

> Context-Aware Config: Make resource inheritance for configuration collections 
> configurable
> --
>
> Key: SLING-6059
> URL: https://issues.apache.org/jira/browse/SLING-6059
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: contextaware-config
> Fix For: Context-Aware Configuration 1.0.0
>
>
> currently and automatic merging/combining of configuration resource items 
> takes place. example:
> {noformat}
> /conf/site1/feature/a
> /conf/site1/feature/c
> /conf/global/feature/b
> /libs/conf/feature/c
> {noformat}
> this returns a,b,c when config resource collection for "feature" is 
> requested. c is from /conf/site1/feature/c and not from /libs/conf/feature/c.
> this is inconsistent to the support for properties (where currently no such 
> "merging" is supported), and can have undesired effects.
> furthermore it is problematic when saving configuration collections via the 
> ConfigurationManager interface (SLING-6026). when storing a set of config 
> resources for /conf/site1 they are stored as children of /conf/site1/feature. 
> but when reading them again they are automatically merged with the others 
> from the fallback paths, and the user has no possibility to prevent this.
> so we should either disable this merging on paths, or implement it correctly 
> with giving the user control when merging should take place or not (confmgr 
> has a special property for this).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Possibility of making nt:resource unreferenceable

[Julian Reschke]

On 2016-10-07 08:04, Carsten Ziegeler wrote:

...
The easiest solution that comes to my mind is:

Whenever a nt:resource child node of a nt:file node is created, it is
silently changed to oak:resource.

Carsten
...


Observation: that might break code that actually wants a referenceable 
node: it would create the node, check for the presence of 
mix:referenceable, and then decide not to add it because it's already there.


Best regards, Julian

Re: Possibility of making nt:resource unreferenceable

[Chetan Mehrotra]

On Fri, Oct 7, 2016 at 11:34 AM, Carsten Ziegeler  wrote:
> Whenever a nt:resource child node of a nt:file node is created, it is
> silently changed to oak:resource.

I like this!

This can be done via an Editor which does this transformation upon
addition of new node. Something which can be easily enabled/disabled
if need arises. With this we would not have make change in many places
like JcrUtil.putFile, WebDav, Vault, Sling Post Servlet, any custom
code creating nt:file say using JcrUtil.putFile.

Chetan Mehrotra

Re: Possibility of making nt:resource unreferenceable

[Carsten Ziegeler]

What about a totally different approach. My main problems with some of
the suggestions are:

a) we have to fix a lot of places (post servlet, webdav, other modules
creating files), creating duplicate code. If this is made configurable,
then its even more of a nightmare.
b) oak:resource is not a node type defined in the spec

I understand that changing nt:resource might be a problem - although
this might be more a theoretical one.

Obviously the preferred solution is to do it in a single place, which
leads to changing it in Oak or having some way to do it via Oak -
instead of changing several places above Oak in the application layer.

The easiest solution that comes to my mind is:

Whenever a nt:resource child node of a nt:file node is created, it is
silently changed to oak:resource.

Carsten

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