Re: Maven Archetypes

[Ruben Reusser]

it would be great if it gets the same bells and whistles as the 
archetype AEM has at the moment and maybe starts aligning with the split 
code and content structure a bit more as well.


Ruben

On 10/8/2021 12:34 PM, Andreas Schaefer wrote:

Hi

I did not work on the Project Archetype for a while but I am going to have a 
look into it with respect to FMs.
There were some suggestions on how to improve it a while back and I will try to 
find them again.

Cheers - Andy


On Oct 8, 2021, at 8:01 AM, Robert Munteanu  wrote:

On Fri, 2021-10-08 at 08:44 -0400, Cris Rockwell wrote:

Hi


Shall we mark those archetypes as deprecated for now?

Yes. I can make that update to the site (if no one objects). It makes
sense to deprecate broken archetypes, at least temporarily. These
provide an initial starting point for developers looking to try the
framework, so I think they should not only work properly but also
have good documentation if possible. I also understand resource
constraints.

+1 from me.



I would be in favour of just maintaing the sling-project-archetype
and
making sure that a) it works and b) is a reasonable starting point
for
Sling-based apps.

FYI. I used sling-project-archetype two days ago. It worked well for
me. It provided a reasonable starting basis for my new project.

Good to know, thanks.
Robert

Re: Should the sling-project-archetype generate a launcher module?

[Ruben Reusser]

Robert,

I think its a good idea - I wonder however if in that case the sling 
sample in the sling starter should be removed and the initial content a 
bit rearranged to allow for a cleaner start of a new application on top 
of sling?


Ruben

On 7/9/2021 5:25 AM, Robert Munteanu wrote:

Hi,

I was browsing the sling-project-archetype and was wondering whether we
should have a 'launcher' module, generated by default, and based on the
Sling Starter 12 feature model.

I think it would make it simpler to demonstrate 'this is how you start
a Sling project', with the (hopefully) small added cost of maintenance
and the caveat

Thoughts?

Thanks,
Robert

[jira] [Updated] (SLING-10369) org.apache.sling.starter dependencies out of date

[Ruben Reusser (Jira)]

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

Ruben Reusser updated SLING-10369:
--
Description: 
please accept PR [1] to update the dependencies of the sling starter

the following dependencies were outdated:
{code:java}
[INFO]   org.apache.sling:org.apache.sling.api ... 2.23.0 -> 2.23.4
[INFO]   org.apache.sling:org.apache.sling.serviceusermapper ... 1.5.2 -> 1.5.4
[INFO]   org.apache.felix:org.apache.felix.configadmin ... 1.9.20 -> 1.9.22
[INFO]   org.apache.felix:org.apache.felix.http.jetty .. 4.1.6 -> 
4.1.8{code}
 [1] [https://github.com/apache/sling-org-apache-sling-starter/pull/21] 

  was:
please accept PR [1] to update the dependencies of the sling starter

the following dependencies were outdated:
{code:java}
[INFO] org.apache.sling:org.apache.sling.auth.core ... 1.5.0 -> 1.5.2
[INFO] org.apache.sling:org.apache.sling.engine .. 2.7.2 -> 2.7.4
[INFO] org.apache.sling:org.apache.sling.repoinit.parser . 1.6.6 -> 1.6.8
[INFO] org.apache.sling:org.apache.sling.resourceresolver  1.7.2 -> 1.7.4
[INFO] org.apache.sling:org.apache.sling.xss  2.2.8 -> 2.2.12
[INFO] com.composum.nodes:composum-nodes-commons . 2.3.0 -> 2.6.1
[INFO] com.composum.nodes:composum-nodes-console . 2.3.0 -> 2.6.1
[INFO] com.composum.nodes:composum-nodes-jslibs .. 2.3.0 -> 2.6.1
[INFO] com.composum.nodes:composum-nodes-pckgmgr . 2.3.0 -> 2.6.1
[INFO] com.composum.nodes:composum-nodes-usermgr . 2.3.0 -> 2.6.1
[INFO] org.apache.felix:org.apache.felix.http.jetty .. 4.1.4 -> 4.1.6
[INFO] org.apache.felix:org.apache.felix.scr ... 2.1.24 -> 2.1.26
[INFO] org.apache.felix:org.apache.felix.utils . 1.11.6 -> 
1.11.8{code}
also had to move org.apache.sling.commons.metrics and 
io.dropwizard.metrics:metrics-core from start-level 15 to start-level 5 to be 
able to build the project due to
{code:java}
[ERROR] org.apache.sling:org.apache.sling.auth.core:1.5.2: is importing 
package(s) org.apache.sling.commons.metrics in start level 5 but no bundle is 
exporting these for that start level.
[ERROR] Analyser detected errors on feature 
'org.apache.sling:org.apache.sling.starter:slingosgifeature:nosample_base:12-SNAPSHOT'.
 See log output for error messages.{code}
 [1] https://github.com/apache/sling-org-apache-sling-starter/pull/19


> org.apache.sling.starter dependencies out of date
> -
>
> Key: SLING-10369
> URL: https://issues.apache.org/jira/browse/SLING-10369
> Project: Sling
>  Issue Type: Improvement
>  Components: Starter
>Reporter: Ruben Reusser
>Assignee: Bertrand Delacretaz
>Priority: Critical
>
> please accept PR [1] to update the dependencies of the sling starter
> the following dependencies were outdated:
> {code:java}
> [INFO]   org.apache.sling:org.apache.sling.api ... 2.23.0 -> 
> 2.23.4
> [INFO]   org.apache.sling:org.apache.sling.serviceusermapper ... 1.5.2 -> 
> 1.5.4
> [INFO]   org.apache.felix:org.apache.felix.configadmin ... 1.9.20 -> 
> 1.9.22
> [INFO]   org.apache.felix:org.apache.felix.http.jetty .. 4.1.6 -> 
> 4.1.8{code}
>  [1] [https://github.com/apache/sling-org-apache-sling-starter/pull/21] 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SLING-10369) org.apache.sling.starter dependencies out of date

[Ruben Reusser (Jira)]

Ruben Reusser created SLING-10369:
-

 Summary: org.apache.sling.starter dependencies out of date
 Key: SLING-10369
 URL: https://issues.apache.org/jira/browse/SLING-10369
 Project: Sling
  Issue Type: Improvement
  Components: Starter
Reporter: Ruben Reusser
Assignee: Bertrand Delacretaz


please accept PR [1] to update the dependencies of the sling starter

the following dependencies were outdated:
{code:java}
[INFO] org.apache.sling:org.apache.sling.auth.core ... 1.5.0 -> 1.5.2
[INFO] org.apache.sling:org.apache.sling.engine .. 2.7.2 -> 2.7.4
[INFO] org.apache.sling:org.apache.sling.repoinit.parser . 1.6.6 -> 1.6.8
[INFO] org.apache.sling:org.apache.sling.resourceresolver  1.7.2 -> 1.7.4
[INFO] org.apache.sling:org.apache.sling.xss  2.2.8 -> 2.2.12
[INFO] com.composum.nodes:composum-nodes-commons . 2.3.0 -> 2.6.1
[INFO] com.composum.nodes:composum-nodes-console . 2.3.0 -> 2.6.1
[INFO] com.composum.nodes:composum-nodes-jslibs .. 2.3.0 -> 2.6.1
[INFO] com.composum.nodes:composum-nodes-pckgmgr . 2.3.0 -> 2.6.1
[INFO] com.composum.nodes:composum-nodes-usermgr . 2.3.0 -> 2.6.1
[INFO] org.apache.felix:org.apache.felix.http.jetty .. 4.1.4 -> 4.1.6
[INFO] org.apache.felix:org.apache.felix.scr ... 2.1.24 -> 2.1.26
[INFO] org.apache.felix:org.apache.felix.utils . 1.11.6 -> 
1.11.8{code}
also had to move org.apache.sling.commons.metrics and 
io.dropwizard.metrics:metrics-core from start-level 15 to start-level 5 to be 
able to build the project due to
{code:java}
[ERROR] org.apache.sling:org.apache.sling.auth.core:1.5.2: is importing 
package(s) org.apache.sling.commons.metrics in start level 5 but no bundle is 
exporting these for that start level.
[ERROR] Analyser detected errors on feature 
'org.apache.sling:org.apache.sling.starter:slingosgifeature:nosample_base:12-SNAPSHOT'.
 See log output for error messages.{code}
 [1] https://github.com/apache/sling-org-apache-sling-starter/pull/19



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (SLING-10347) org.apache.sling.starter dependencies out of date

[Ruben Reusser (Jira)]

Ruben Reusser created SLING-10347:
-

 Summary: org.apache.sling.starter dependencies out of date
 Key: SLING-10347
 URL: https://issues.apache.org/jira/browse/SLING-10347
 Project: Sling
  Issue Type: Improvement
  Components: Starter
Reporter: Ruben Reusser


please accept PR [1] to update the dependencies of the sling starter

the following dependencies were outdated:
{code:java}
[INFO] org.apache.sling:org.apache.sling.auth.core ... 1.5.0 -> 1.5.2
[INFO] org.apache.sling:org.apache.sling.engine .. 2.7.2 -> 2.7.4
[INFO] org.apache.sling:org.apache.sling.repoinit.parser . 1.6.6 -> 1.6.8
[INFO] org.apache.sling:org.apache.sling.resourceresolver  1.7.2 -> 1.7.4
[INFO] org.apache.sling:org.apache.sling.xss  2.2.8 -> 2.2.12
[INFO] com.composum.nodes:composum-nodes-commons . 2.3.0 -> 2.6.1
[INFO] com.composum.nodes:composum-nodes-console . 2.3.0 -> 2.6.1
[INFO] com.composum.nodes:composum-nodes-jslibs .. 2.3.0 -> 2.6.1
[INFO] com.composum.nodes:composum-nodes-pckgmgr . 2.3.0 -> 2.6.1
[INFO] com.composum.nodes:composum-nodes-usermgr . 2.3.0 -> 2.6.1
[INFO] org.apache.felix:org.apache.felix.http.jetty .. 4.1.4 -> 4.1.6
[INFO] org.apache.felix:org.apache.felix.scr ... 2.1.24 -> 2.1.26
[INFO] org.apache.felix:org.apache.felix.utils . 1.11.6 -> 
1.11.8{code}
also had to move org.apache.sling.commons.metrics and 
io.dropwizard.metrics:metrics-core from start-level 15 to start-level 5 to be 
able to build the project due to
{code:java}
[ERROR] org.apache.sling:org.apache.sling.auth.core:1.5.2: is importing 
package(s) org.apache.sling.commons.metrics in start level 5 but no bundle is 
exporting these for that start level.
[ERROR] Analyser detected errors on feature 
'org.apache.sling:org.apache.sling.starter:slingosgifeature:nosample_base:12-SNAPSHOT'.
 See log output for error messages.{code}
 [1]https://github.com/apache/sling-org-apache-sling-starter/pull/19



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Sling Declarative Dynamic Resources

[Ruben Reusser]

Carsten,

I think I understand your security concern - do you see another way to 
solve this in that case?


Ruben

On 4/22/2021 10:31 PM, Carsten Ziegeler wrote:

Thanks Ruben,

in my opinion /apps belongs to developers. In our case its immutable 
for good reasons. Drilling a hole into this and allowing non 
developers contribute to /apps, especially in a dynamic fashion 
circumventing the immutability sounds very risky and can result in 
security problems.


I understand that extra configuration options are added to partially 
address this, but then it comes down to how effective these are and 
what holes they might have.


Now, in general I'm not against a feature like dynamic resources - but 
making something immutable mutable especially for a different audience 
is too dangerous.


Regards
Carsten

Re: Sling Declarative Dynamic Resources

[Ruben Reusser]

Carsten,  see inline

On 4/22/2021 6:55 AM, Carsten Ziegeler wrote:


Am 21.04.2021 um 15:30 schrieb Ruben Reusser:
- for each website that is created we have to create a corresponding 
/apps folder for rendering purposes


I assume the ddr solution is temporary and eventually the information 
is added to /apps directly? In this case I would do that immediately.


we try to live in a composite nodestore world where /apps is not 
writable - so no, we can't write to apps when creating a website


- we also want to give editors a certain control over group names, 
labels and the component variations an editor can pick from when 
creating a page



That sounds as if that is part of content not stored in /apps?

the default node structure we want to create if a user adds a component 
to a page is currently under apps but we would like to keep it somewhere 
in /content in the future


our big motivation for DDR is to make authoring and maintaining a 
website less dependent on developers and allow for better customization 
options after the initial effort to build a site has been completed.



Carsten


Ruben

Re: Sling Declarative Dynamic Resources

[Ruben Reusser]

Dan,

I am in favor of adding the features from ddr to sling-superimposing - 
is that ok for others too?


Ruben

On 4/20/2021 4:14 PM, Daniel Klco wrote:

IMO the biggest difference is how this defines the root of the dynamic
resources, e.g. via creating a resource at that path or providing a
configuration with the source and target. This alone is a major advantage
as it means that ddr configurations can be defined at runtime with a
composite store.

The problem I see here is that we are trying to solve the same problem
multiple ways.

My take on the problem is:

As a developer or superuser, I want to be able to present a virtual tree of
resources generated from a tree of resources and a configuration tree.

Resource merger solves this problem by anchoring a root and then defining
source paths which can be overlayed and configured in order. This works
well in the case where you have only two trees and you want to present a
merged copy of these two trees, but does not work for arbitrary anchor
points.

Superimposing supports creating arbitrary roots but these roots can only be
tied to one source. It also only allows overriding the overlayed resouces
by using a lower level api (such as JCR) because the sling post servlet
will update the source resources.

Generally, I think it's better to have fewer ways of doing the same thing,
do it makes sense to consolidate if possible. Given that resouces merger is
widely used, I can't see how it would be worth the effort to regression
check potential breaking issues. However, given that SuperImposing has not
been significantly updated in years, I would recommend that we:

1. Update SuperImposing to work on Java 11 / OSGi 6 / Sling 12
2. Update SuperImposing to support defining virtual trees by source and
source+target and other DDR features
3. Define a feature model to install the bundle and create an oak index for
the mixin
4. Release this as the 1.0 version of SuperImposing

I've already taken a run at updating SuperImposing and am ~75% there.

What do others think?

-Dan

On Tue, Apr 20, 2021, 5:34 PM Andreas Schaefer 
wrote:


Here is a short recap after trying to compare Superimposing Resource (SIR)
and the Declarative Dynamice Resource (DDR). They are similar in some
respect and different in others:

Feature SIR DDR

Resource Resolver type  Admin RRService RR
Linking fromTarget  Source
Mixin   Supported   Not
Supported
Resource ChangesSupported   Supported
Property ChangesNot Supported   Supported
Configure Parent by
1st Level Child Supported   Not Supported
OverlaysSupported
  Not Supported
2nd Level Redirection   Not Supported   Supported
Filtering (Security)Not Supported   Supported
Java 11 Not Supported   Supported
Sling 12Not Supported
  Supported

Cheers - Andy


On Apr 20, 2021, at 6:13 AM, Stefan Seifert 

wrote:

hello ruben.

use case sounds a bit similar to

https://github.com/apache/sling-org-apache-sling-superimposing (a bit

outdated)

and
https://github.com/apache/sling-org-apache-sling-resourcemerger

can you differentiate what DDR does differently?

stefan


-Original Message-
From: Ruben Reusser 
Sent: Tuesday, April 20, 2021 1:54 PM
To: dev@sling.apache.org
Subject: Re: Sling Declarative Dynamic Resources

totally forgot to add the link to the code base - sorry



https://github.com/apache/sling-whiteboard/tree/master/org.apache.sling.ddr

On 4/19/2021 10:29 AM, Ruben Reusser wrote:

dear sling community

Andreas has been working to create a way to dynamically create
component proxies in Sling based on a configuration. In peregrine-cms
we are planning to use this approach when a new tenant (a new website)
is created by a user. It allows us to proxy the base components into a
new /apps folder for the website. A super user for the site can then
potentially change the title/group of a component and the default
structure that is used when adding a component to a page.

We hope this component may be useful to other sling based content
management systems as well. We'd like to ask to move this module out
of the whiteboard - but of course we welcome any
comments/concerns/things we should consider to make sure everybody can
benefit from this module.

looking forward to your comments!

Ruben

Re: Sling Declarative Dynamic Resources

[Ruben Reusser]

Bertrand, Carsten,

On 4/20/2021 10:57 PM, Carsten Ziegeler wrote:
I totally agree that we should try to avoid overlapping solutions and 
as mentioned superimposing and ddr sound pretty similar.


I understand the use cases on a higher level. However - similar to 
Bertrand - I'm a little bit worried. The readme for ddr talks about 
circumventing an immutable repository. If its possible to basically 
make immutable parts mutable, then this is entering dangerous territory.


I understand your concern - that is one of the reasons why we made sure 
we allow blocking of resource types in ddr.


we tried to outline our usecase we need to solve:

- for each website that is created we have to create a corresponding 
/apps folder for rendering purposes
- we also want to give editors a certain control over group names, 
labels and the component variations an editor can pick from when 
creating a page


would love to hear if there is a better alternative for this


Regards
Carsten

Re: Sling Declarative Dynamic Resources

[Ruben Reusser]

Stefan, thanks for the pointers

dynamic declarative resources is I think something between the 2 
solutions you pointed out - its meant to be a simple overlay of nodes in 
/apps using a configuration in /conf ro support immutable /apps trees


sling-org-apache-sling-superimposing may in fact provide almost the same 
functionality we are looking for and is definitely worth a try from our 
side!


thanks

Ruben

On 4/20/2021 6:13 AM, Stefan Seifert wrote:

hello ruben.

use case sounds a bit similar to

https://github.com/apache/sling-org-apache-sling-superimposing (a bit outdated)
and
https://github.com/apache/sling-org-apache-sling-resourcemerger

can you differentiate what DDR does differently?

stefan


-Original Message-
From: Ruben Reusser 
Sent: Tuesday, April 20, 2021 1:54 PM
To: dev@sling.apache.org
Subject: Re: Sling Declarative Dynamic Resources

totally forgot to add the link to the code base - sorry

https://github.com/apache/sling-whiteboard/tree/master/org.apache.sling.ddr

On 4/19/2021 10:29 AM, Ruben Reusser wrote:

dear sling community

Andreas has been working to create a way to dynamically create
component proxies in Sling based on a configuration. In peregrine-cms
we are planning to use this approach when a new tenant (a new website)
is created by a user. It allows us to proxy the base components into a
new /apps folder for the website. A super user for the site can then
potentially change the title/group of a component and the default
structure that is used when adding a component to a page.

We hope this component may be useful to other sling based content
management systems as well. We'd like to ask to move this module out
of the whiteboard - but of course we welcome any
comments/concerns/things we should consider to make sure everybody can
benefit from this module.

looking forward to your comments!

Ruben

Re: Sling Declarative Dynamic Resources

[Ruben Reusser]

totally forgot to add the link to the code base - sorry

https://github.com/apache/sling-whiteboard/tree/master/org.apache.sling.ddr

On 4/19/2021 10:29 AM, Ruben Reusser wrote:

dear sling community

Andreas has been working to create a way to dynamically create 
component proxies in Sling based on a configuration. In peregrine-cms 
we are planning to use this approach when a new tenant (a new website) 
is created by a user. It allows us to proxy the base components into a 
new /apps folder for the website. A super user for the site can then 
potentially change the title/group of a component and the default 
structure that is used when adding a component to a page.


We hope this component may be useful to other sling based content 
management systems as well. We'd like to ask to move this module out 
of the whiteboard - but of course we welcome any 
comments/concerns/things we should consider to make sure everybody can 
benefit from this module.


looking forward to your comments!

Ruben

Sling Declarative Dynamic Resources

[Ruben Reusser]

dear sling community

Andreas has been working to create a way to dynamically create component 
proxies in Sling based on a configuration. In peregrine-cms we are 
planning to use this approach when a new tenant (a new website) is 
created by a user. It allows us to proxy the base components into a new 
/apps folder for the website. A super user for the site can then 
potentially change the title/group of a component and the default 
structure that is used when adding a component to a page.


We hope this component may be useful to other sling based content 
management systems as well. We'd like to ask to move this module out of 
the whiteboard - but of course we welcome any comments/concerns/things 
we should consider to make sure everybody can benefit from this module.


looking forward to your comments!

Ruben

[jira] [Commented] (SLING-10143) bundles referenced in sling starter are out of date

[Ruben Reusser (Jira)]

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

Ruben Reusser commented on SLING-10143:
---

PR created at [https://github.com/apache/sling-org-apache-sling-starter/pull/18]

I did however notice a shutdown issue with the new starter in the 
org.apache.sling.discovery.oak module - not sure if that is an issue or not 
(start sling, hit ctrl-c to stop sling, get the error) - the issue is not 
present in master: 
{code:java}
ERROR : bundle org.apache.sling.discovery.oak:1.2.30 
(148)[org.apache.sling.discovery.oak.OakDiscoveryService(232)] : The 
updatedPropertyProvider method has thrown an exceptionERROR : bundle 
org.apache.sling.discovery.oak:1.2.30 
(148)[org.apache.sling.discovery.oak.OakDiscoveryService(232)] : The 
updatedPropertyProvider method has thrown an 
exceptionjava.lang.IllegalArgumentException: Can't create child on a synthetic 
root at 
org.apache.sling.resourceresolver.impl.ResourceResolverImpl.create(ResourceResolverImpl.java:979)
 at 
org.apache.sling.api.resource.ResourceUtil.getOrCreateResourceInternal(ResourceUtil.java:666)
 at 
org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:603)
 at 
org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:571)
 at 
org.apache.sling.api.resource.ResourceUtil.getOrCreateResourceInternal(ResourceUtil.java:654)
 at 
org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:603)
 at 
org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:571)
 at 
org.apache.sling.api.resource.ResourceUtil.getOrCreateResourceInternal(ResourceUtil.java:654)
 at 
org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:603)
 at 
org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:571)
 at 
org.apache.sling.api.resource.ResourceUtil.getOrCreateResourceInternal(ResourceUtil.java:654)
 at 
org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:603)
 at 
org.apache.sling.api.resource.ResourceUtil.getOrCreateResource(ResourceUtil.java:571){code}

> bundles referenced in sling starter are out of date
> ---
>
> Key: SLING-10143
> URL: https://issues.apache.org/jira/browse/SLING-10143
> Project: Sling
>  Issue Type: Improvement
>  Components: Starter
>    Reporter: Ruben Reusser
>Priority: Major
> Fix For: Starter 12
>
> Attachments: 
> 0001-updated-3rd-party-dependencies-of-sling-starter.patch, 
> 0002-javax.activation-dependency-needed-to-be-increased.patch, 
> 0003-updated-to-latest-sling-bundles-added-missing-felix-.patch
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Would be nice to make sure the sling starter uses the latest bundles - 
> according to 
> {code:java}
> mvn versions:display-dependency-updates{code}
> the sling starter is a bit out of date with the dependencies
> {code:java}
> [INFO] The following dependencies in Dependencies have newer versions:
> [INFO]   com.composum.nodes:composum-nodes-commons . 2.1.1 -> 
> 2.3.0
> [INFO]   com.composum.nodes:composum-nodes-console . 2.1.1 -> 
> 2.3.0
> [INFO]   com.composum.nodes:composum-nodes-jslibs .. 2.1.1 -> 
> 2.3.0
> [INFO]   com.composum.nodes:composum-nodes-pckgmgr . 2.1.1 -> 
> 2.3.0
> [INFO]   com.composum.nodes:composum-nodes-usermgr . 2.1.1 -> 
> 2.3.0
> [INFO]   com.fasterxml.jackson.core:jackson-annotations .. 2.11.1 -> 
> 2.12.1
> [INFO]   com.fasterxml.jackson.core:jackson-core . 2.11.1 -> 
> 2.12.1
> [INFO]   com.fasterxml.jackson.core:jackson-databind . 2.11.1 -> 
> 2.12.1
> [INFO]   com.google.guava:guava .. 15.0 -> 
> 30.1-jre
> [INFO]   com.h2database:h2-mvstore . 1.4.194 -> 
> 1.4.200
> [INFO]   commons-codec:commons-codec . 1.14 -> 
> 1.15
> [INFO]   commons-collections:commons-collections  3.2.2 -> 
> 20040616
> [INFO]   commons-io:commons-io ... 2.6 -> 
> 2.8.0
> [INFO]   io.dropwizard.metrics:metrics-core . 3.2.6 -> 
> 4.2.0-beta.1
> [INFO]   org.antlr:antlr4-runtime .. 4.7.2 -> 
> 4.9.1
> [INFO]   org.apache.commons:commons-lang3 . 3.9 -> 
> 3.11
> [INFO]   org.apache.felix:org.apache.felix.configadmin ... 1.9.16 -> 
> 1.9.20
> [INFO]   org.apache.felix:org.apache.felix.eventadmin ..

[jira] [Commented] (SLING-10143) bundles referenced in sling starter are out of date

[Ruben Reusser (Jira)]

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

Ruben Reusser commented on SLING-10143:
---

patch files to bring dependencies up to latest versions attached to this issue

out of date dependencies are now greatly reduced, however, hard to say if this 
introduces new issues. 
{code:java}
[INFO] artifact org.apache.felix:org.apache.felix.cm.json: checking for updates 
from central
[INFO] The following dependencies in Dependencies have newer versions:
[INFO]   com.google.guava:guava .. 15.0 -> 30.1-jre
[INFO]   commons-collections:commons-collections  3.2.2 -> 20040616
[INFO]   io.dropwizard.metrics:metrics-core . 3.2.6 -> 4.2.0-beta.1
[INFO]   org.apache.tika:tika-core  1.24 -> 2.0.0-ALPHA
[INFO]   org.apache.tika:tika-parsers . 1.24 -> 2.0.0-ALPHA
[INFO]   org.jvnet.staxex:stax-ex .. 1.7.6 -> 2.0.0
[INFO]   org.slf4j:jcl-over-slf4j .. 1.7.30 -> 2.0.0-alpha1
[INFO]   org.slf4j:log4j-over-slf4j  1.7.30 -> 2.0.0-alpha1
[INFO]   org.slf4j:slf4j-api ... 1.7.30 -> 2.0.0-alpha1

{code}

> bundles referenced in sling starter are out of date
> ---
>
> Key: SLING-10143
> URL: https://issues.apache.org/jira/browse/SLING-10143
> Project: Sling
>  Issue Type: Improvement
>      Components: Starter
>Reporter: Ruben Reusser
>Priority: Major
> Fix For: Starter 12
>
> Attachments: 
> 0001-updated-3rd-party-dependencies-of-sling-starter.patch, 
> 0002-javax.activation-dependency-needed-to-be-increased.patch, 
> 0003-updated-to-latest-sling-bundles-added-missing-felix-.patch
>
>
> Would be nice to make sure the sling starter uses the latest bundles - 
> according to 
> {code:java}
> mvn versions:display-dependency-updates{code}
> the sling starter is a bit out of date with the dependencies
> {code:java}
> [INFO] The following dependencies in Dependencies have newer versions:
> [INFO]   com.composum.nodes:composum-nodes-commons . 2.1.1 -> 
> 2.3.0
> [INFO]   com.composum.nodes:composum-nodes-console . 2.1.1 -> 
> 2.3.0
> [INFO]   com.composum.nodes:composum-nodes-jslibs .. 2.1.1 -> 
> 2.3.0
> [INFO]   com.composum.nodes:composum-nodes-pckgmgr . 2.1.1 -> 
> 2.3.0
> [INFO]   com.composum.nodes:composum-nodes-usermgr . 2.1.1 -> 
> 2.3.0
> [INFO]   com.fasterxml.jackson.core:jackson-annotations .. 2.11.1 -> 
> 2.12.1
> [INFO]   com.fasterxml.jackson.core:jackson-core . 2.11.1 -> 
> 2.12.1
> [INFO]   com.fasterxml.jackson.core:jackson-databind . 2.11.1 -> 
> 2.12.1
> [INFO]   com.google.guava:guava .. 15.0 -> 
> 30.1-jre
> [INFO]   com.h2database:h2-mvstore . 1.4.194 -> 
> 1.4.200
> [INFO]   commons-codec:commons-codec . 1.14 -> 
> 1.15
> [INFO]   commons-collections:commons-collections  3.2.2 -> 
> 20040616
> [INFO]   commons-io:commons-io ... 2.6 -> 
> 2.8.0
> [INFO]   io.dropwizard.metrics:metrics-core . 3.2.6 -> 
> 4.2.0-beta.1
> [INFO]   org.antlr:antlr4-runtime .. 4.7.2 -> 
> 4.9.1
> [INFO]   org.apache.commons:commons-lang3 . 3.9 -> 
> 3.11
> [INFO]   org.apache.felix:org.apache.felix.configadmin ... 1.9.16 -> 
> 1.9.20
> [INFO]   org.apache.felix:org.apache.felix.eventadmin .. 1.5.0 -> 
> 1.6.2
> [INFO]   org.apache.felix:org.apache.felix.http.jetty . 4.0.18 -> 
> 4.1.4
> [INFO]   org.apache.felix:org.apache.felix.metatype  1.2.2 -> 
> 1.2.4
> [INFO]   org.apache.felix:org.apache.felix.scr ... 2.1.20 -> 
> 2.1.24
> [INFO]   org.apache.felix:org.apache.felix.utils . 1.11.2 -> 
> 1.11.6
> [INFO]   org.apache.felix:org.apache.felix.webconsole .. 4.5.0 -> 
> 4.6.0
> [INFO]   org.apache.geronimo.specs:geronimo-annotation_1.3_spec  1.1 -> 
> 1.3
> [INFO]   org.apache.geronimo.specs:geronimo-atinject_1.0_spec .. 1.1 -> 
> 1.2
> [INFO]   org.apache.httpcomponents:httpclient  4.5.10 -> 
> 4.5.13
> [INFO]   org.apache.httpcomponents:httpclient-osgi ... 4.5.10 -> 
> 4.5.13
> [INFO]   org.apache.httpcomponents:httpcore-osgi . 4.4.12 -> 
> 

[jira] [Updated] (SLING-10143) bundles referenced in sling starter are out of date

[Ruben Reusser (Jira)]

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

Ruben Reusser updated SLING-10143:
--
Attachment: 0001-updated-3rd-party-dependencies-of-sling-starter.patch
0002-javax.activation-dependency-needed-to-be-increased.patch
0003-updated-to-latest-sling-bundles-added-missing-felix-.patch

> bundles referenced in sling starter are out of date
> ---
>
> Key: SLING-10143
> URL: https://issues.apache.org/jira/browse/SLING-10143
> Project: Sling
>  Issue Type: Improvement
>  Components: Starter
>    Reporter: Ruben Reusser
>Priority: Major
> Fix For: Starter 12
>
> Attachments: 
> 0001-updated-3rd-party-dependencies-of-sling-starter.patch, 
> 0002-javax.activation-dependency-needed-to-be-increased.patch, 
> 0003-updated-to-latest-sling-bundles-added-missing-felix-.patch
>
>
> Would be nice to make sure the sling starter uses the latest bundles - 
> according to 
> {code:java}
> mvn versions:display-dependency-updates{code}
> the sling starter is a bit out of date with the dependencies
> {code:java}
> [INFO] The following dependencies in Dependencies have newer versions:
> [INFO]   com.composum.nodes:composum-nodes-commons . 2.1.1 -> 
> 2.3.0
> [INFO]   com.composum.nodes:composum-nodes-console . 2.1.1 -> 
> 2.3.0
> [INFO]   com.composum.nodes:composum-nodes-jslibs .. 2.1.1 -> 
> 2.3.0
> [INFO]   com.composum.nodes:composum-nodes-pckgmgr . 2.1.1 -> 
> 2.3.0
> [INFO]   com.composum.nodes:composum-nodes-usermgr . 2.1.1 -> 
> 2.3.0
> [INFO]   com.fasterxml.jackson.core:jackson-annotations .. 2.11.1 -> 
> 2.12.1
> [INFO]   com.fasterxml.jackson.core:jackson-core . 2.11.1 -> 
> 2.12.1
> [INFO]   com.fasterxml.jackson.core:jackson-databind . 2.11.1 -> 
> 2.12.1
> [INFO]   com.google.guava:guava .. 15.0 -> 
> 30.1-jre
> [INFO]   com.h2database:h2-mvstore . 1.4.194 -> 
> 1.4.200
> [INFO]   commons-codec:commons-codec . 1.14 -> 
> 1.15
> [INFO]   commons-collections:commons-collections  3.2.2 -> 
> 20040616
> [INFO]   commons-io:commons-io ... 2.6 -> 
> 2.8.0
> [INFO]   io.dropwizard.metrics:metrics-core . 3.2.6 -> 
> 4.2.0-beta.1
> [INFO]   org.antlr:antlr4-runtime .. 4.7.2 -> 
> 4.9.1
> [INFO]   org.apache.commons:commons-lang3 . 3.9 -> 
> 3.11
> [INFO]   org.apache.felix:org.apache.felix.configadmin ... 1.9.16 -> 
> 1.9.20
> [INFO]   org.apache.felix:org.apache.felix.eventadmin .. 1.5.0 -> 
> 1.6.2
> [INFO]   org.apache.felix:org.apache.felix.http.jetty . 4.0.18 -> 
> 4.1.4
> [INFO]   org.apache.felix:org.apache.felix.metatype  1.2.2 -> 
> 1.2.4
> [INFO]   org.apache.felix:org.apache.felix.scr ... 2.1.20 -> 
> 2.1.24
> [INFO]   org.apache.felix:org.apache.felix.utils . 1.11.2 -> 
> 1.11.6
> [INFO]   org.apache.felix:org.apache.felix.webconsole .. 4.5.0 -> 
> 4.6.0
> [INFO]   org.apache.geronimo.specs:geronimo-annotation_1.3_spec  1.1 -> 
> 1.3
> [INFO]   org.apache.geronimo.specs:geronimo-atinject_1.0_spec .. 1.1 -> 
> 1.2
> [INFO]   org.apache.httpcomponents:httpclient  4.5.10 -> 
> 4.5.13
> [INFO]   org.apache.httpcomponents:httpclient-osgi ... 4.5.10 -> 
> 4.5.13
> [INFO]   org.apache.httpcomponents:httpcore-osgi . 4.4.12 -> 
> 4.4.14
> [INFO]   org.apache.jackrabbit:jackrabbit-data ... 2.20.0 -> 
> 2.21.5
> [INFO]   org.apache.jackrabbit:jackrabbit-jcr-commons  2.20.0 -> 
> 2.21.5
> [INFO]   org.apache.jackrabbit:jackrabbit-jcr-rmi  2.20.0 -> 
> 2.21.5
> [INFO]   org.apache.jackrabbit:jackrabbit-spi  2.20.0 -> 
> 2.21.5
> [INFO]   org.apache.jackrabbit:jackrabbit-spi-commons  2.20.0 -> 
> 2.21.5
> [INFO]   org.apache.jackrabbit:jackrabbit-webdav . 2.20.0 -> 
> 2.21.5
> [INFO]   org.apache.jackrabbit:oak-api ... 1.32.0 -> 
> 1.38.0
> [INFO]   org.apache.jackrabbit:oak-authorization-principalbased ...
> [INFO] 1.32.0 -> 
> 1.38.0
> [INFO]   org.apache.jackrabbit:oak-blob .. 1.32.0

[jira] [Created] (SLING-10143) bundles referenced in sling starter are out of date

[Ruben Reusser (Jira)]

Ruben Reusser created SLING-10143:
-

 Summary: bundles referenced in sling starter are out of date
 Key: SLING-10143
 URL: https://issues.apache.org/jira/browse/SLING-10143
 Project: Sling
  Issue Type: Improvement
  Components: Starter
Reporter: Ruben Reusser
 Fix For: Starter 12


Would be nice to make sure the sling starter uses the latest bundles - 
according to 
{code:java}
mvn versions:display-dependency-updates{code}
the sling starter is a bit out of date with the dependencies
{code:java}
[INFO] The following dependencies in Dependencies have newer versions:
[INFO]   com.composum.nodes:composum-nodes-commons . 2.1.1 -> 2.3.0
[INFO]   com.composum.nodes:composum-nodes-console . 2.1.1 -> 2.3.0
[INFO]   com.composum.nodes:composum-nodes-jslibs .. 2.1.1 -> 2.3.0
[INFO]   com.composum.nodes:composum-nodes-pckgmgr . 2.1.1 -> 2.3.0
[INFO]   com.composum.nodes:composum-nodes-usermgr . 2.1.1 -> 2.3.0
[INFO]   com.fasterxml.jackson.core:jackson-annotations .. 2.11.1 -> 2.12.1
[INFO]   com.fasterxml.jackson.core:jackson-core . 2.11.1 -> 2.12.1
[INFO]   com.fasterxml.jackson.core:jackson-databind . 2.11.1 -> 2.12.1
[INFO]   com.google.guava:guava .. 15.0 -> 30.1-jre
[INFO]   com.h2database:h2-mvstore . 1.4.194 -> 1.4.200
[INFO]   commons-codec:commons-codec . 1.14 -> 1.15
[INFO]   commons-collections:commons-collections  3.2.2 -> 20040616
[INFO]   commons-io:commons-io ... 2.6 -> 2.8.0
[INFO]   io.dropwizard.metrics:metrics-core . 3.2.6 -> 4.2.0-beta.1
[INFO]   org.antlr:antlr4-runtime .. 4.7.2 -> 4.9.1
[INFO]   org.apache.commons:commons-lang3 . 3.9 -> 3.11
[INFO]   org.apache.felix:org.apache.felix.configadmin ... 1.9.16 -> 1.9.20
[INFO]   org.apache.felix:org.apache.felix.eventadmin .. 1.5.0 -> 1.6.2
[INFO]   org.apache.felix:org.apache.felix.http.jetty . 4.0.18 -> 4.1.4
[INFO]   org.apache.felix:org.apache.felix.metatype  1.2.2 -> 1.2.4
[INFO]   org.apache.felix:org.apache.felix.scr ... 2.1.20 -> 2.1.24
[INFO]   org.apache.felix:org.apache.felix.utils . 1.11.2 -> 1.11.6
[INFO]   org.apache.felix:org.apache.felix.webconsole .. 4.5.0 -> 4.6.0
[INFO]   org.apache.geronimo.specs:geronimo-annotation_1.3_spec  1.1 -> 1.3
[INFO]   org.apache.geronimo.specs:geronimo-atinject_1.0_spec .. 1.1 -> 1.2
[INFO]   org.apache.httpcomponents:httpclient  4.5.10 -> 4.5.13
[INFO]   org.apache.httpcomponents:httpclient-osgi ... 4.5.10 -> 4.5.13
[INFO]   org.apache.httpcomponents:httpcore-osgi . 4.4.12 -> 4.4.14
[INFO]   org.apache.jackrabbit:jackrabbit-data ... 2.20.0 -> 2.21.5
[INFO]   org.apache.jackrabbit:jackrabbit-jcr-commons  2.20.0 -> 2.21.5
[INFO]   org.apache.jackrabbit:jackrabbit-jcr-rmi  2.20.0 -> 2.21.5
[INFO]   org.apache.jackrabbit:jackrabbit-spi  2.20.0 -> 2.21.5
[INFO]   org.apache.jackrabbit:jackrabbit-spi-commons  2.20.0 -> 2.21.5
[INFO]   org.apache.jackrabbit:jackrabbit-webdav . 2.20.0 -> 2.21.5
[INFO]   org.apache.jackrabbit:oak-api ... 1.32.0 -> 1.38.0
[INFO]   org.apache.jackrabbit:oak-authorization-principalbased ...
[INFO] 1.32.0 -> 1.38.0
[INFO]   org.apache.jackrabbit:oak-blob .. 1.32.0 -> 1.38.0
[INFO]   org.apache.jackrabbit:oak-blob-plugins .. 1.32.0 -> 1.38.0
[INFO]   org.apache.jackrabbit:oak-commons ... 1.32.0 -> 1.38.0
[INFO]   org.apache.jackrabbit:oak-core .. 1.32.0 -> 1.38.0
[INFO]   org.apache.jackrabbit:oak-core-spi .. 1.32.0 -> 1.38.0
[INFO]   org.apache.jackrabbit:oak-jackrabbit-api  1.32.0 -> 1.38.0
[INFO]   org.apache.jackrabbit:oak-jcr ... 1.32.0 -> 1.38.0
[INFO]   org.apache.jackrabbit:oak-lucene  1.32.0 -> 1.38.0
[INFO]   org.apache.jackrabbit:oak-query-spi . 1.32.0 -> 1.38.0
[INFO]   org.apache.jackrabbit:oak-security-spi .. 1.32.0 -> 1.38.0
[INFO]   org.apache.jackrabbit:oak-segment-tar ... 1.32.0 -> 1.38.0
[INFO]   org.apache.jackrabbit:oak-store-composite ... 1.32.0 -> 1.38.0
[INFO]   org.apache.jackrabbit:oak-store-document  1.32.0 -> 1.38.0
[INFO]   org.apache.jackrabbit:oak-store-spi . 1.32.0 -> 1.38.0
[INFO]   org.apache.jackrabbit.vault:org.apache.jackrabbit.vault ...

Re: state of sling-org-apache-sling-starter

[Ruben Reusser]

Eric,

thank you - there seems to be quite a list of outdated bundles int the 
starter even outside of sling itself. I am trying to wrap my head around 
how to make bring everything safely up to date.


it looks like some of the versions in use have known security 
vulnerabilities.


Ruben

On 11/27/2020 1:28 PM, Eric Norman wrote:

Hi Ruben,

I've just fixed the org.apache.sling.jcr.contentloader item from your
list.  It might be worth opening a new issue in jira for tracking the
others.

FYI: I usually use the following command to produce a report on
dependencies that are not the latest version:

*mvn versions:display-dependency-updates*


Regards,
-Eric

On Tue, Nov 24, 2020 at 9:06 PM Ruben Reusser  wrote:


here's the current list of mismatches:

org.apache.sling.commons.fsclassloader starter: 1.0.14 downloads: 1.0.8
org.apache.sling.commons.scheduler starter: 2.7.6 downloads: 2.7.2
org.apache.sling.models.impl starter: 1.4.12 downloads: 1.4.16
org.apache.sling.serviceusermapper starter: 1.4.4 downloads: 1.4.2
org.apache.sling.servlets.resolver starter: 2.7.10 downloads: 2.7.8
org.apache.sling.commons.johnzon starter: 1.2.4 downloads: 1.2.6
org.apache.sling.commons.osgi starter: 2.4.0 downloads: 2.4.2
org.apache.sling.installer.core starter: 3.11.2 downloads: 3.11.4
org.apache.sling.settings starter: 1.4.0 downloads: 1.4.2
org.apache.sling.discovery.oak starter: 1.2.28 downloads: 1.2.30
org.apache.sling.discovery.support starter: 1.0.4 downloads: 1.0.6
org.apache.sling.jcr.contentloader starter: 2.3.0 downloads: 2.4.0
org.apache.sling.extensions.webconsolesecurityprovider starter: 1.2.4
downloads: 1.2.2


On Tue, Nov 24, 2020 at 5:13 pm, Bertrand Delacretaz
 wrote:

Hi Ruben,

On Tue, Nov 24, 2020 at 4:29 PM Ruben Reusser mailto:r...@headwire.com>> wrote:

  ...is there a process to update the starter and the downloads page
when a
  new version of a bundle is released?...

Updating it is part of our release instructions at
<

https://sling.apache.org/documentation/development/release-management.html#update-the-sling-starter-module-1


But I suspect we miss that sometimes - patches welcome of course!

-Bertrand

Re: state of sling-org-apache-sling-starter

[Ruben Reusser]

here's the current list of mismatches:

org.apache.sling.commons.fsclassloader starter: 1.0.14 downloads: 1.0.8
org.apache.sling.commons.scheduler starter: 2.7.6 downloads: 2.7.2
org.apache.sling.models.impl starter: 1.4.12 downloads: 1.4.16
org.apache.sling.serviceusermapper starter: 1.4.4 downloads: 1.4.2
org.apache.sling.servlets.resolver starter: 2.7.10 downloads: 2.7.8
org.apache.sling.commons.johnzon starter: 1.2.4 downloads: 1.2.6
org.apache.sling.commons.osgi starter: 2.4.0 downloads: 2.4.2
org.apache.sling.installer.core starter: 3.11.2 downloads: 3.11.4
org.apache.sling.settings starter: 1.4.0 downloads: 1.4.2
org.apache.sling.discovery.oak starter: 1.2.28 downloads: 1.2.30
org.apache.sling.discovery.support starter: 1.0.4 downloads: 1.0.6
org.apache.sling.jcr.contentloader starter: 2.3.0 downloads: 2.4.0
org.apache.sling.extensions.webconsolesecurityprovider starter: 1.2.4 
downloads: 1.2.2



On Tue, Nov 24, 2020 at 5:13 pm, Bertrand Delacretaz 
 wrote:

Hi Ruben,

On Tue, Nov 24, 2020 at 4:29 PM Ruben Reusser <mailto:r...@headwire.com>> wrote:
 ...is there a process to update the starter and the downloads page 
when a

 new version of a bundle is released?...


Updating it is part of our release instructions at
<https://sling.apache.org/documentation/development/release-management.html#update-the-sling-starter-module-1>

But I suspect we miss that sometimes - patches welcome of course!

-Bertrand

state of sling-org-apache-sling-starter

[Ruben Reusser]

dear sling devs

I was looking at the feature files in sling starter as bit today and 
noticed some discrepancies between the sling starter and the latest 
released modules list on the sling website


just some examples:

org.apache.sling:org.apache.sling.commons.osgi starter: 2.4.0, downloads 
page : 2.4.2
org.apache.sling:org.apache.sling.commons.fsclassloader, starter: 
1.0.14, downloads page: 1.0.8


is there a process to update the starter and the downloads page when a 
new version of a bundle is released?


Ruben

[1] https://github.com/apache/sling-org-apache-sling-starter/
[2] https://sling.apache.org/downloads.cgi

Re: [VOTE] Release Apache Sling Content Package Archetype 1.0.0

[Ruben Reusser]

Robert,

On 11/6/2020 6:07 AM, Robert Munteanu wrote:

Hi Ruben and thanks for looking into this.

On Fri, 2020-11-06 at 05:36 -0800, Ruben Reusser wrote:

Robert,

had a quick look at this archetype - for a 1.0.0 release I am
missing
documentation around this archetype.

What kind of documentation are you looking for? The archetype is
referenced at [2], but nowhere else I guess. I find it simple and self-
explanatory, but would be happy to add more information.


I was hoping for something along the lines of the readme in the project 
archetype [3]



I am also curious if the Java Use Object it creates in apps is really
a
good idea? After all, this is just a content archetype.

The idea behind the archetype was to allow users to quickly generate a
content package. They are free to adjust it how they see fit
afterwards, e.g. by removing rendering scripts.

Generally, I think it's more useful to bake more stuff in the archetype
and allow users to remove it, rather than give them too many options or
very 'slim' archetypes. And it makes maintenance for us much easier.
I totally understand the idea behind why to put a simple html component 
into the content package. I however struggle with the fact that Java Use 
Objects are probably not a best practice for sling projects or other 
upstream projects. Maybe I am wrong here.

looking at the sling-package-archetype at [1] you also decided to
not
use a profile for the package installation - not sure if it would be
better to follow  similar pattern in both archetypes

Right, that should be adjusted. I started with my personal perference
and forgot to to switch to the profile. Can you please file a Sling
issue so it is fixed for the next version?


will do. Looks like the documentation is a bit out of sync as well on 
this topic (project archetype readme vs docs)



Thanks,
Robert

[2]: 
https://sling.apache.org/documentation/development/content-packages.html#maven-projects-1


Ruben

[1]
https://github.com/apache/sling-project-archetype/blob/master/src/main/resources/archetype-resources/README.NotAll.md


[3] https://github.com/apache/sling-project-archetype/blob/master/README.md

Re: [VOTE] Release Apache Sling Content Package Archetype 1.0.0

[Ruben Reusser]

Robert,

had a quick look at this archetype - for a 1.0.0 release I am missing 
documentation around this archetype.


I am also curious if the Java Use Object it creates in apps is really a 
good idea? After all, this is just a content archetype.


looking at the sling-package-archetype at [1] you also decided to not 
use a profile for the package installation - not sure if it would be 
better to follow  similar pattern in both archetypes


Ruben

[1] 
https://github.com/apache/sling-project-archetype/blob/master/src/main/resources/archetype-resources/README.NotAll.md


On 11/6/2020 4:18 AM, Robert Munteanu wrote:

Hi,

This is a first release of the tooling, so no issues fixed (but a
version was created):
https://issues.apache.org/jira/browse/SLING/fixforversion/12349357

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

You can use this UNIX script to download the release and verify the
signatures:
https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD

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

Please vote to approve this release:

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

This majority vote is open for at least 72 hours.

Regards,
Robert Munteanu

Re: sling level package format

[Ruben Reusser]

Carsten,

great to hear I am not the only one that is interested in such a format

Would be nice to collect a couple of use cases for such a format to make 
sure we end up with something useful for everybody


my current need would be the ability to:

- create users if they do not exist
- create groups if they do not exist
- set up a tenant if the tenant does not exist yet
- turn off incremental processing of pages/assets
- import pages and assets honoring their stored replication state and 
applying the correct permissions

- run post processing on all loaded content

Ruben

On 10/24/2020 12:44 AM, Carsten Ziegeler wrote:

Hi,

sounds like an interesting idea. I think it makes sense to explore this

Regards
Carsten

Am 21.10.2020 um 14:59 schrieb Ruben Reusser:

Dear Sling Devs,

currently we rely heavily on jcr filevalut packages to ingest content 
into our sling instances. While the filevault format is great to 
operate on the JCR level it unfortunately does not seem to be the 
best way to ingest some content. I have been wondering for a while if 
it would be a good idea to create a sling supported import format 
that operates at a higher level instead.


Such an import format could for example solve issues like

- ingest a page with all its versions
- add/update a page and correctly manage the replication state of the 
page

- turn off asset processing when ingesting processed assets

It may be a good idea for sling to provide a basic infrastructure for 
such an import format where the actions one can take through the 
format is left to an implementation.

Such a format could also be streamable.

Unfortunately however such a format would not be able to support the 
bidirectional nature of the jcr filevault packages we currently enjoy.


Would love to hear your thoughts on this and if it would make sense 
to start working on such a format.


Ruben

sling level package format

[Ruben Reusser]

Dear Sling Devs,

currently we rely heavily on jcr filevalut packages to ingest content 
into our sling instances. While the filevault format is great to operate 
on the JCR level it unfortunately does not seem to be the best way to 
ingest some content. I have been wondering for a while if it would be a 
good idea to create a sling supported import format that operates at a 
higher level instead.


Such an import format could for example solve issues like

- ingest a page with all its versions
- add/update a page and correctly manage the replication state of the page
- turn off asset processing when ingesting processed assets

It may be a good idea for sling to provide a basic infrastructure for 
such an import format where the actions one can take through the format 
is left to an implementation.

Such a format could also be streamable.

Unfortunately however such a format would not be able to support the 
bidirectional nature of the jcr filevault packages we currently enjoy.


Would love to hear your thoughts on this and if it would make sense to 
start working on such a format.


Ruben

Re: [DISCUSS] Resource Mapping SPI

[Ruben Reusser]

Georg, thanks for the reply - agree my use cases should be covered with that

On 8/24/2020 7:42 AM, Georg Henzler wrote:

Hi Ruben,


One use case that probably also should be considered here is the case
where static pages are generated with sling. In that case the
rendering of the page is not tied to a request.


While [1] has a request in the signature, the idea is not that this
needs to be "a currently active" request. It can be

Re: [DISCUSS] Resource Mapping SPI

[Ruben Reusser]

looking forward to the new resource mapping strategy!

One use case that probably also should be considered here is the case 
where static pages are generated with sling. In that case the rendering 
of the page is not tied to a request.


Ruben

On 8/23/2020 2:24 AM, Carsten Ziegeler wrote:

Thanks for taking this up.

As noted in the issue, I think we should investigate whether this is a 
good opportunity to rethink mapping / resolving in general. In 
hindsight, we probably shouldn't have added the mapping part to the 
resource resolver. The resolve() method does two things: it applies 
mappings (which is independent of the current user) and it resolves to 
a resource (finding the resource and figuring out the selectors, 
extensions etc.) based on the user.


So how about moving the mapping part out of the resource resolver? As 
we've seen recently other parts of Sling like auth core could benefit 
from this as well.


I haven't fully thought this through, but this is the rough idea:

We create a new OSGi service, PathMapperFactory (its probably not a 
good name but I don't want to invest time into naming at this stage). 
It has one method:


   PathMapper newPathMapper(HttpServletRequest request)

where the request parameter is optional. PathMapper has the 
resolve/map methods doing the mapping (based on the newly suggested 
SPI). If a request has been provided to the factory method, that 
object is used for resolving/mapping.
I'm unsure about the exact methods of PathMapper, but it needs a 
resolve method taking in a path (the request path) and returning the 
resolved path (vanity path, aliases etc are applied) and a flag 
whether a redirect should happen.


Sling's main servlet (or more precise the processor) is changed: for 
an incoming request it calls the PathMapperFactory with the request 
and then the resolve method on PathMapper. If the result is absolut or 
the redirect flag is set, the redirect happens.


Otherwise, authentication is invoked with the resolved path - this 
frees auth core (and all auth handlers etc) from dealing with mappings.


If authentication is successful, a new resource resolver is created 
and the PathMapper is passed to the resource resolver via the 
attributes of the resource resolver factory. ResourceResolver gets a 
new method "getPathMapper()" - if no PathMapper is passed to the 
resource resolver factory, the factory creates a new one by invoking 
newPathMapper(null) on the PathMapperFactory. In all cases, a resource 
resolver has a PathMapper.


We add a new method to Resource Resolver, similar to the resolve() 
method but just doing the resolution part - no mapping. This method is 
used by the main servlet instead of the existing resolve() method. We 
deprecate resolve() and map() and change the implementation to 
internally use the passed in PathMapper instance.


This way we have a clear separation between mapping and resolving and 
in which contexts the operations happen. With adding the PathMapper to 
the resource resolver we make it available to all parts in the system 
which need to call todays map() method - and as the PathMapper 
instance knows the request, there is no need to pass it around anymore.


Now, again, just a rough write down of the idea, don't get hung up on 
the naming that can and needs to improve. Its also not directly about 
the new SPI, but rather how we make the SPI available to the rest of 
the system.


Regards
Carsten

Am 14.08.2020 um 07:57 schrieb Georg Henzler:

Hi all,

so I eventually got around to continue on this. I created JIRA
issue [1] and the branches [2] in API and [3] in resourceresolver
with a first working version.



I definitely prefer immutable classes with a dedicated builder


@Konrad I was critical first because the verbosity of the code,
but it made implementing ResourceUriMappingChain actually easier.
My concern about the verbosity was not that much a problem with
Java 8 anymore.


...And I do believe that mapping is
about the relationship between requests and resources ...

and

- RequestMapper: it maps a "request" to a Resource OR it maps a
Resource to a form that can be requested.


@Julian: So these are very good points, I think RequestMapper is
not ideal because in async code (e.g. Sling jobs), you might
have the case that you have a resource and you map it to a URI
(e.g. for sending an email). in rr.map() you use no
request and usually some manual work is needed to add the host.
My idea for the future would be to provide a simple
ExampleRequest that can be used to provide a hostname or headers
which will then tell the active mappers to do the right thing for
the async, non-request use case. I ended up calling the
SPI interface itself ResourceToUriMapper (which I think is
best spot on for what it does).

So overall I have it all working now in the branches [2] and [3],
currently ResourceUriMappingChain is called from
ResourceResolverImpl.resolveInternal() and
ResourceMapperImpl.getAllMappings(). Other 

Re: Prevent Default Sling Post servlet from ever processing certain requests

[Ruben Reusser]

on the same line: is it possible to restrict what jcr:primaryType and 
what sling:resourceType is allowed to be created by the post servlet or 
even more in general?


On 6/18/2020 6:38 AM, Konrad Windszus wrote:

That already comes close, but I was more thinking about a dedicated operation 
which indicates, that a required specialized servlet is missing. That could by 
default return a status 500 with a reasonable error message (so only one 
parameter necessary).
I created https://issues.apache.org/jira/browse/SLING-9531 
 to track that.
Thanks for your input,
Konrad


On 18. Jun 2020, at 15:30, Karl Pauls  wrote:

https://sling.apache.org/documentation/bundles/manipulating-content-the-slingpostservlet-servlets-post.html#slingpostservlet-operations-1

obviously, that only helps if you have the client under your control.

regards,

Karl

On Thursday, June 18, 2020, Karl Pauls  wrote:


I guess you could add a nop operation.

regards,

Karl

On Thursday, June 18, 2020, Bertrand Delacretaz 
wrote:


On Thu, Jun 18, 2020 at 2:46 PM Konrad Windszus
 wrote:

...Is there a simple way (like a certain parameter or request path

format) which prevents the

Sling POST servlet from responding?...

Not that I know, but my memory is bad for such things.


If not, do you think that this would be a useful addition?

I think so - maybe something like the PathBasedAcceptor [1] created
for SLING-8110 could help set stricter requirements for that default
servlet to execute.

-Bertrand

[1] https://github.com/apache/sling-org-apache-sling-servlets-
resolver/blob/master/src/main/java/org/apache/sling/
servlets/resolver/internal/PathBasedServletAcceptor.java



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



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

[Discuss] (SLING-8350) Switch the Sling starter to the feature model

[Ruben Reusser]

Robert,

you mentioned bringing this discussion to the dev mailing list (hope I 
did this the right way)



- kickstart launcher (fat JAR)


I am not sure why you think the kickstarter is a fat jar. It relies on a 
feature file for sling and the feature launcher. It's main purpose is to 
provide the same command line argument interface as the 
apache.sling.starter on top of the feature launcher as the feature 
launcher is rather limited in that regard. Also note that once the 
feature launcher with FAR support is released the kickstarter will also 
support FARs.


as a reference: below the -h output for the feature launcher, 
kickstarter and classic sling starter


Ruben

feature launcher command line interface:

usage: launcher -C  Set artifact clash override -c  Set cache 
dir -CC  Set config clash override -D  Set framework 
properties -ec  Provide extension configuration, format: 
extensionName:key1=val1,key2=val2 -f  Set feature files -fa  
Set framework artifact (overrides felix framework version) -fv  Set 
felix framework version -p  Set home dir -u  Set repository 
url -V  Set variable value -v Verbose


kickstarter command line interface

Usage: java -jar  [-hnv] [-a=] 
[-c=] [-f=] [-i=] 
[-j=] [-l=] [-p=] [-r=] 
[-s=] [-af=]... 
[-D=]... [COMMAND] Apache Sling Kickstart [COMMAND] 
Optional Command for Server Instance Interaction, can be one of: 
'start', 'stop', 'status' or 'threads' -a, --address= the 
interface to bind to (use 0.0.0.0 for any) -af, 
--additionalFeature= additional feature files -c, 
--slingHome= the sling context directory (default sling) -D, 
--define= sets property n to value v. Make sure to use 
this option *after* the jar filename. The JVM also has a -D option which 
has a different meaning -f, --logFile= the log file, "-" for 
stdout (default logs/error.log) -h, --help Display the usage message. 
-i, --launcherHome= the launcher home directory (default 
launcher) -j, --control= host and port to use for 
control connection in the format '[host:]port' (default 127.0.0.1:0) -l, 
--logLevel= the initial loglevel (0..4, FATAL, ERROR, WARN, 
INFO, DEBUG) -n, --noShutdownHook don't install the shutdown hook -p, 
--port= the port to listen to (default 8080) -r, 
--context= the root servlet context path for the http 
service (default is /) -s, --mainFeature= main feature 
file (file path or URL) replacing the provided Sling Feature File -v, 
--verbose the feature launcher is verbose on launch Copyright(c) 2020 
The Apache Software Foundation.


classic

usage: org.apache.sling.launchpad.app.Main [ start | stop | status ] [ 
-j adr ] [ -l loglevel ] [ -f logfile ] [ -c slinghome ] [ -i 
launchpadhome ] [ -a address ] [ -p port ] { -Dn=v } [ -h ]

    start listen for control connection (uses -j)
    stop  terminate running Apache Sling (uses -j)
    status    check whether Apache Sling is running (uses -j)
    threads   request a thread dump from Apache Sling (uses -j)
    -j adr    host and port to use for control connection in the 
format '[host:]port' (default 127.0.0.1:0)
    -l loglevel   the initial loglevel (0..4, FATAL, ERROR, WARN, INFO, 
DEBUG)

    -f logfile    the log file, "-" for stdout (default logs/error.log)
    -c slinghome  the sling context directory (default sling)
    -i launchpadhome  the launchpad directory (default slinghome)
    -a address    the interfact to bind to (use 0.0.0.0 for any)
    -p port   the port to listen to (default 8080)
    -r path   the root servlet context path for the http service 
(default is /)

    -n    don't install the shutdown hook
    -Dn=v sets property n to value v. Make sure to use this 
option *after* the jar filename. The JVM also has a -D option which has 
a different meaning

    -h    prints this usage message

On 5/8/2020 12:27 AM, Robert Munteanu (Jira) wrote:

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

Robert Munteanu commented on SLING-8350:


I think it's worthwhile discussing the way forward ( or the way out :-) ) with 
the Feature Model on dev@sling . I don't claim to have a good understanding of 
the solution space yet, but what I understand is that we have three possible 
levels of support:

- feature launcher + feature file ( JSON )
- feature launcher + feature archive ( FAR )
- kickstart launcher (fat JAR)

I am not sure which option is "the best", and IIRC at some point we were 
discussing FAR vs KickStart.

As I've said, it would be worthwhile to discuss on the dev list.

Re: Documentation for content-package based development

[Ruben Reusser]

Hi Robert,

this is awesome! I think it would be nice to also mention at [1] the 
ability to upload and deploy a content package through the composum UI. 
Also, should we move [2] from the peregrine repos to the sling samples 
instead?


Ruben

]1] 
https://sling.apache.org/documentation/development/content-packages.html#deploying-a-content-package-at-runtime-1

[2] https://github.com/peregrine-cms/simple-sling-vue-example

On 5/8/2020 7:00 AM, Robert Munteanu wrote:

Hi,

As part of the sling 12 theme of content-package based development I
kicked off a page to help users wrap their head around the concept.

   https://sling.apache.org/documentation/development/content-packages.html

I'm talking about things that are not fully familiar to me, like the
Sling Project Archetype and the Sling Packager tool, so any input is
welcome.

Note that it's not supposed to be a comprehensive guide, but rather a
starting point.

Comments welcome.

Thanks,
Robert

Re: slingpackager in it's own git repo

[Ruben Reusser]

I think the problem with the naming of the packager has to be looked at 
from the npmjs registry [1]
Ideally we use a similar name for the repo as we would use for 
publishing to npm and how we would like people to use it from the 
command line.


sling-packager is unfortunately already taken and seems to be part of a 
sling in node implementation [2].


Installation would happen through the command

> npm install *@apache-sling/slingpackager* --global

and one would use the command with

> *slingpackager* --help

while github.com/*apache/sling-slingpackager* has a repetition of sling 
in the name it would map nicely to npm and the command line execution of 
the tool. If we use github.com/apache/sling-packager we run the risk 
that people will try to use the sling-packager module that already 
exists at [3]


[1] https://www.npmjs.com/
[2] https://www.npmjs.com/package/sling-server
[3] https://www.npmjs.com/package/sling-packager

On 4/27/2020 9:37 AM, Henry Saginor wrote:

I like js in the name because it lets me know it's not a Java project. Most
Sling projects are java and maven. So, repo naming is derived from maven
artifact id and "java" does not need to be advertised. I am not sure about
cli. I imagine exposing slingpackage operations as API so it can be used by
other tools as a library as well.

On Mon, Apr 27, 2020 at 1:35 AM Robert Munteanu  wrote:


On Fri, 2020-04-24 at 11:39 -0700, Henry Saginor wrote:

I am happy to put up the repository name to a vote. Here are the
choices
and reasoning as I see it..
1) github.com/apache/sling-slingpackager - short and filterable by
sling-
as project
2) github.com/apache/sling-js-slingpackager - the same as 1) but
includes
js to id it as a js project
3) github.com/apache/apache-sling-js-slingpackager - maps to npm org.
I
think this is better for compliance. But I am not sure.
4) github.com/apache/sling-apache-sling-js-slingpackager - also maps
to npm
org but starts with sling- to follow sling project conventions.

Well, first - ASF Infra requires that we start the repo name with
'sling-'.

Personally, I think any repetition of 'sling' and 'apache' is
confusing, so I would go with either 'sling-packager' or 'sling-js-
packager'.

I am not sure whether we need the 'js' part, since we don't advertise
'java' for our packages ... Maybe include 'cli' somewhere, since it's a
CLI tool and would make it clear what the scope is? Just throwing out
ideas...


Also, can we move it to a new repo 1st and then figure out npm
release?

+1

Thanks,
Robert

Re: [VOTE] Promote sling-org-apache-sling-quickstart / sling-quickstart-maven-plugin to their own Sling Modules

[Ruben Reusser]

how about crankstart, cloudstart or jumpstart?

On 2/5/2020 1:42 AM, Bertrand Delacretaz wrote:

On Wed, Feb 5, 2020 at 10:12 AM Robert Munteanu  wrote:

...First all all - thanks Andy for your persistence

Indeed, I think we owe Andy multiple beverages-of-his-choice!


...I see some confusion potential where people would be applying AEM
quickstart knowledge to the Sling quickstart and vice-versa...

Yes that's what I meant, I'm not worried about trademarks but avoiding
possible confusing is helpful.

-Bertrand

Re: Sling FM Starter Module

[Ruben Reusser]

Robert,

I think the first focus is on 1, fast followed by 2 and 3

Ruben

On 11/19/2019 6:53 AM, Robert Munteanu wrote:

On Tue, 2019-11-19 at 06:47 -0800, Ruben Reusser wrote:

Robert,

would we not want each module to produce it's own feature file and
then
have an aggregation somewhere?

Depends on what you define as a module. I see multiple options here:

1. A bundle produces its own feature file.

For instance, slingshot - single bundle, single feature file.

2. A set of bundles define their own feature file in a shared project

This would be for example composum, defining all bundles + configs they
need to start up in the Composum project. Then we import it in the
application we are running.

3. A set of bundles are included in a feature file of the application
project.

This would be the Sling starter defining its own feature files and
including e.g. composum Sling scripting bundles + configs in its own
repository.

Which is the one under discussion?

Robert


Ruben

On 11/19/2019 6:41 AM, Robert Munteanu wrote:

On Fri, 2019-11-15 at 11:47 -0800, Andreas Schaefer wrote:

Hi

I started to get the pieces into place for a build up of
Peregrine
CMS based on Sling 11 using FMs.

First I updated the Sling Feature Converter Maven Plugin to
install
the generated slingosgifeature into my local Maven repo and then
use
these dependencies to assemble and launch Peregrine. This works
fine
for most parts (content does not deploy but that is another
story).

Next step is to install FMs from Bundles into the local Maven
repo
which will be used for bundles or content bundles like Sling.

My question is: is it expected for the developer to write its own
slingosgiffeature file or is there a way to generate that from a
POM
?

Do you want to generate feature files for individual bundles? I
would
expect that you have a feature file that groups related bundles
together, similar to what we do with the provisioning model.

Robert


As far as I can see the Sling Feature Maven Plugin does not
provide
that.

Cheers - Andy


On Nov 11, 2019, at 2:11 AM, Robert Munteanu <
romb...@apache.org>
wrote:

Hi Andreas,

On Fri, 2019-11-08 at 09:51 -0800, Andreas Schaefer wrote:

Hi

I am wondering how a Sling FM Starter Module would look like
and
how
it is used by clients like Peregrine.

It is my assumption that any FM slingosgifeature project will
install
that file on release on a public Maven repository like all of
our
Sling Module.

Then the Sling FM Starter Module will select the appropriate
slingosgifeature files and assemble it into a Sling release
slingosgifeature which is then also installed on a public
Maven
repo.
This enables anyone to build the latest Sling instance w/o
having
any
other Sling Module checked out / built like right now it is
done
in
PM based Sling Starter.

A customer will then do the same by taking the Sling
slingosgifeature
file and assembly it with their own project and external
projects
slingosgifeature files to build the final Sling / Customer
instance.

Overall that sounds reasonable to me. The only note that I want
to
make
is that since we are doing releases at best once per year,
downstream
projects would either need to depend on SNAPSHOT versions of
the
Sling
Starter, or depend on older versions.

Thanks,
Robert

Re: Sling FM Starter Module

[Ruben Reusser]

Robert,

would we not want each module to produce it's own feature file and then 
have an aggregation somewhere?


Ruben

On 11/19/2019 6:41 AM, Robert Munteanu wrote:

On Fri, 2019-11-15 at 11:47 -0800, Andreas Schaefer wrote:

Hi

I started to get the pieces into place for a build up of Peregrine
CMS based on Sling 11 using FMs.

First I updated the Sling Feature Converter Maven Plugin to install
the generated slingosgifeature into my local Maven repo and then use
these dependencies to assemble and launch Peregrine. This works fine
for most parts (content does not deploy but that is another story).

Next step is to install FMs from Bundles into the local Maven repo
which will be used for bundles or content bundles like Sling.

My question is: is it expected for the developer to write its own
slingosgiffeature file or is there a way to generate that from a POM
?

Do you want to generate feature files for individual bundles? I would
expect that you have a feature file that groups related bundles
together, similar to what we do with the provisioning model.

Robert


As far as I can see the Sling Feature Maven Plugin does not provide
that.

Cheers - Andy


On Nov 11, 2019, at 2:11 AM, Robert Munteanu 
wrote:

Hi Andreas,

On Fri, 2019-11-08 at 09:51 -0800, Andreas Schaefer wrote:

Hi

I am wondering how a Sling FM Starter Module would look like and
how
it is used by clients like Peregrine.

It is my assumption that any FM slingosgifeature project will
install
that file on release on a public Maven repository like all of our
Sling Module.

Then the Sling FM Starter Module will select the appropriate
slingosgifeature files and assemble it into a Sling release
slingosgifeature which is then also installed on a public Maven
repo.
This enables anyone to build the latest Sling instance w/o having
any
other Sling Module checked out / built like right now it is done
in
PM based Sling Starter.

A customer will then do the same by taking the Sling
slingosgifeature
file and assembly it with their own project and external projects
slingosgifeature files to build the final Sling / Customer
instance.

Overall that sounds reasonable to me. The only note that I want to
make
is that since we are doing releases at best once per year,
downstream
projects would either need to depend on SNAPSHOT versions of the
Sling
Starter, or depend on older versions.

Thanks,
Robert

sling12 timeline/feature models

[Ruben Reusser]

hi,

I was wondering if there is a release timeline for Sling12. It seems 
Sling12 would be a great candidate to move over to feature models.


Would love to hear what the community thinks about that and if there is 
a way to contribute/get together and work on the sling 12 release.


Ruben

Re: Publishing packages on npmjs.com

[Ruben Reusser]

Robert, I do not have an opinion on 1 or 2. Do what's best for the sling 
PMC team


Ruben

On 11/6/2019 9:11 AM, Robert Munteanu wrote:

Thanks, Ruben.

I will then create the @apache-sling org on NPM. There is only one
question left - how to manage credentials. I see two options:

1. Create a shared account that is registered using the
'priv...@sling.apache.org' email. This makes sure credentials are not
tied to a single account, but then again makes it harder to revoke and
there is less tracing.

2. Create it using my account and then grant access to other PMC
members on-demand, using the '@apache.org' accounts.

I slightly prefer 2, I think the credentials are better handled without
reset links being accessible in (privately) archived mailing lists.

I plan to create the org on Monday, so if you have other ideas, please
let me know.

Thanks,
Robert


On Thu, 2019-10-24 at 05:37 -0700, Ruben Reusser wrote:

Robert, thank you for looking into this

there is also a sling-packager user package preventing us from using
sling-packager or slingpackager.

I honestly would prefer the org and as an org only 1 is an option.

thank you

Ruben

On 10/24/2019 3:04 AM, Robert Munteanu wrote:

Hi,

In https://issues.apache.org/jira/browse/SLING-8747 we are
discussing
how to publish Sling packages on npmjs.com .

First thing to settle would be the naming convention. I guess we
have
four options here:

1. @apache-sling/$PACKAGE-NAME
2. @sling/$PACKAGE-NAME
3. apache-sling-$PACKAGE-NAME
4. sling-$PACKAGE-NAME

I think an org is preferrable since we would be able to add
multiple
accounts to it.

There already is a user package https://www.npmjs.com/package/sling
  ,
so I'm not sure if we can create a @sling organisation.

Which option to you prefer? New ones are welcome, of course.

Thanks,
Robert

Re: Publishing packages on npmjs.com

[Ruben Reusser]

Robert, thank you for looking into this

there is also a sling-packager user package preventing us from using 
sling-packager or slingpackager.


I honestly would prefer the org and as an org only 1 is an option.

thank you

Ruben

On 10/24/2019 3:04 AM, Robert Munteanu wrote:

Hi,

In https://issues.apache.org/jira/browse/SLING-8747 we are discussing
how to publish Sling packages on npmjs.com .

First thing to settle would be the naming convention. I guess we have
four options here:

1. @apache-sling/$PACKAGE-NAME
2. @sling/$PACKAGE-NAME
3. apache-sling-$PACKAGE-NAME
4. sling-$PACKAGE-NAME

I think an org is preferrable since we would be able to add multiple
accounts to it.

There already is a user package https://www.npmjs.com/package/sling ,
so I'm not sure if we can create a @sling organisation.

Which option to you prefer? New ones are welcome, of course.

Thanks,
Robert

[jira] [Created] (SLING-8747) establish @apachesling npmjs organization

[Ruben Reusser (Jira)]

Ruben Reusser created SLING-8747:


 Summary: establish @apachesling npmjs organization
 Key: SLING-8747
 URL: https://issues.apache.org/jira/browse/SLING-8747
 Project: Sling
  Issue Type: Improvement
  Components: CI
Reporter: Ruben Reusser


now that the donation for the slingpackager has been accepted we need to create 
a common apachesling organization on npmjs and start setting up a ci/cd flow to 
release the slingpackager

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



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [hackathon] maven archetypes

[Ruben Reusser]

for B) - the module names the archetype currently uses have been chosen 
to be aligned with the names the AEM Project Archetype uses. While I 
understand the ui.* may look odd it was meant to make it easier for a 
developer familiar with AEM to work on a sling project.


The archetype also supports the common profiles to deploy packages such 
as autoInstallBundle and autoInstallPackage


I am not opposed to changing the module names or the profile names, I 
just like consistency and the ease of moving from one product to another.


Ruben

On 9/12/2019 9:32 AM, Stefan Seifert wrote:

+1

i also think we can omit D) for the first step.
i'm also fine with C) that it always include sample data - we can always add a 
switch later to remove it.

for B) we might consider putting all bundle projects below a bundles/ folder
and all content package projects below a /content-packages folder
it's not unusual you create more of them for bigger projects, and then they are 
nicely grouped.

stefan


-Original Message-
From: Konrad Windszus [mailto:konra...@gmx.de]
Sent: Thursday, September 12, 2019 5:53 PM
To: dev@sling.apache.org
Subject: Re: [hackathon] maven archetypes

Definitely +1 on having only one archetype. In case D is too much effort,
we could even leave it out.
A maintained archetype is better than what we currently have.
And it should be pretty easy for every developer to just copy over from a
blueprint project created from the archetype only the desired modules...

Konrad


On 12. Sep 2019, at 16:50, Robert Munteanu  wrote:

On Thu, 2019-09-05 at 14:43 +, Stefan Seifert wrote:

- currently there are lots of sling maven archetypes, and most of
them not well maintained
- we would favor to have only one single "project" archetypes,
probably the new "project" archetype contributed by andy
- add parameters to switch features on and off, e.g. for generating
only with bundle but not with the content packages
  - this can be done using the groovy prost process
  - there is already a groovy script with a lot of logic in it, to be
reviewed if it already covers all use cases
- the plan is to no longer have the need to maintain multiple
archetypes
- review the generated structure of the current project archetypes.
the structure is derived from the adobe AEM project archetype, but we
like not all of it. e.g. the "ui." prefix for the contant packages,
probably introduce "bundles" and "content-packages" folders to but
bundles and content packages in.

I would like to propose the following:

A. deprecate all project archetype ( + parent ) except the sling-
project-archetype

1. sling-slingstart-archetype
2. sling-archetype-parent
3. sling-taglib-archetype
4. sling-servlet-archetype
5. sling-bundle-archetype
6. sling-initial-content-archetype
7. sling-launchpad-standalone-archetype
8. sling-launchpad-webapp-archetype
9. sling-jcrinstall-bundle-archetype

B. include the following artifacts in the project

1. core ( Java bundle )
2. content ( content package, sample data )
3. apps ( content package, Sling scripts )
4. launcher ( feature model project )

C. I like the fact that the project includes sample data. Would it
simplify maintenance if we always generated the sample data? I would
expect the user to tweak it anyway.

D. We _could_ heavily tweak the project and make it generate a single
module, by e.g. deleting anything but the one of the modules and then
making them top-level after generation has run (groovy script).

That would effectively replace the other 8 existing projects, but I'm
not sure if the complexity is worth it.

Thoughts?

Thanks,
Robert

Re: Why get rid of the rewriter?

[Ruben Reusser]

As was pointed out before the rewriter is used in a lot of projects for
other things than rewriting links (in our case we use it a lot to inject
legal disclaimers or content fragment models)

The bigger problem however is that it assumes hml == xml and hence can not
deal with attributes with no value

Ruben

On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz 
wrote:

> Hi,
>
> On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey  wrote:
> > ...Can anyone summarize why we are getting rid of it?...
>
> I'm not sure if we need to "get rid" of that module, even if some
> portion of Sling users stops using it.
>
> The proposal at [1] says the rewriter should be "deprecated and no
> longer used", which is apparently what was discussed at the adaptTo
> round table or hackathon.
>
> If people still find the module useful I think it''s fine to move it
> to "contrib" status instead of deprecating. As long as there's a
> reasonable expectation that the module will be maintained I think
> that's a realistic status, but our guarantees are weak for contrib
> modules so there's no pressure.
>
> And if other modules provide better ways of doing similar things, link
> to them from the rewriter's docs.
>
> -Bertrand
>
> [1]
> https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E
>


-- 
thank you

Ruben Reusser
CTO, headwire.com, Inc

Re: [VOTE] Accept the donation of the Sling Packager tool, SLING-8584

[Ruben Reusser]

the slingpackager is meant to work against content management systems 
built on sling. It currently supports package managers by


- Composum
- AEM

If there are other package managers in the future I'd love to add 
support for them as well.


We interact with sling to install packages, not with jackrabbit. My 
preference would still be to include this in sling :-) (who knows, 
maybe some day sling decides not to run on jackrabbit anymore - the 
sling packager could then be transformed to support the new 
format/other endpoints)


Ruben

On Tue, Aug 27, 2019 at 2:32 AM, Konrad Windszus  
wrote:

I fully agree with that statement.
Actually there is already a task at FileVault to have an installation 
endpoint (accompanied by a branch): 
 
<>


For all those reasons I would also rather like to see this addition 
to Apache Jackrabbit.

Konrad



 On 27. Aug 2019, at 11:25, Georg Henzler > wrote:


 Hi,

 I also have my doubts... reasoning to have it in Sling from [2]:

 since the tool packages and deploys it is dependent 
Jackrabbit-Vault for

 the package format and on Apache Sling and Composum for the
 upload/install/list/uninstall/delete endpoint. I'd honestly much 
prefer

 for it to be an Apache Sling module.


 Composum [3] is included in the sling starter but not actually 
maintained
 as part of Sling. I'm not aware of any dependency the packager 
would have
 to Sling, so I think the Jackrabbit project would make a lot more 
sense to
 host the Packager tool. For instance, people not using Sling but 
only
 Jackrabbit could use it, also maybe at some point somebody will 
eventually
 create an Open Source Package Manager there (to provide the simple 
endpoints
 for upload/install/list/uninstall/delete without UI would be 
actually really

 easy, maybe it's a good time to do this now :)

 -Georg

 [3] 

[jira] [Commented] (SLING-8655) Add an Annotation to Sling Model to mark a property to be Externalized

[Ruben Reusser (Jira)]

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

Ruben Reusser commented on SLING-8655:
--

[~vladb] [~sseifert] [~radu.cotescu] we are mostly looking to externalize for 
an SPA use case - it looks like [~vladb]'s suggestion would work well for that 
- Does it still make sense to add the suggested ExternalizedSerializer to Sling 
as this is probably a use case most client side rendered web apps/sites will 
face at one point?

> Add an Annotation to Sling Model to mark a property to be Externalized
> --
>
> Key: SLING-8655
> URL: https://issues.apache.org/jira/browse/SLING-8655
> Project: Sling
>  Issue Type: New Feature
>  Components: Sling Models
>Affects Versions: Sling Models API 1.3.8
>Reporter: Andreas Schaefer
>Assignee: Andreas Schaefer
>Priority: Major
> Fix For: Sling Models API 1.3.10
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> For Peregrine CMS we use Sling Models to obtain data in JSon format to be 
> rendered on the client side. This means that the returned content is not 
> externalized aka paths are not mapped to the external view.
> Sling Model should have an Annotation (@ExternalizedPath) that marks a 
> property to be externalized when loaded.
> In order to be flexible the Externalized Path Injector should be pluggable so 
> that customers can add their custom Externalized Path Providers if they 
> choose to do so. By default there is a provider that uses the Resource 
> Resolver's map() function.



--
This message was sent by Atlassian Jira
(v8.3.2#803003)

[jira] [Issue Comment Deleted] (SLING-7768) Add String Interpolation support to /etc/map

[Ruben Reusser (JIRA)]

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

Ruben Reusser updated SLING-7768:
-
Comment: was deleted

(was: so when this was done there was a bigger discussion about making this 
more generic and hence this never made it into sling itself as it's only 
supporting etc/map. 

A more generic solution to this problem could be achieved with sling pipes (a 
config structure somewhere in the repository that is copied over to the final 
location with sling pipes and while doing so it should be able to pickup and 
inject the environment variables))

> Add String Interpolation support to /etc/map
> 
>
> Key: SLING-7768
> URL: https://issues.apache.org/jira/browse/SLING-7768
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
> Environment: Sling 11-SNAPSHOT, JDK 1.8
>Reporter: Andreas Schaefer
>Priority: Major
> Attachments: Screenshot 2018-07-06 11.41.58.png, Screenshot 
> 2018-07-06 11.42.41.png, Screenshot 2018-07-06 11.43.34.png
>
>
> Having worked on migrations of a Sling derivate Ruben & I ran into issues 
> where the /etc/map would map to production instead of testing environment.
>  Many big customer have extensive /etc/maps and also many different 
> environments like dev, qa, staging, prod etc.
>  It would be great to have a tool where for example items like the host name 
> or external links in /etc/map could be configured outside so that just one 
> entry has to adjusted rather than creating a full copy of the /etc/map tree.
>   
>  Example:
>   
>  /etc/map/http/phv.fq.host.name.8080
>   
>  Placeholder provides:
>  DEV: phv.fq.host.name=localhost
>  QA: phv.fq.host.name=qa.author.acme.com
>  STAGING: 
> phv.fq.host.name=[staging.author.acme.com|http://staging.author.acme.com/]
>  PROD: phv.fq.host.name=[acme.com|http://acme.com/]
>   
>  At runtime these are the resolved values:
>  DEV: http/localhost.8080
>  QA: http/qa.author.acme.com.8080
>  STAGING: http/[staging.author.acme.com|http://staging.author.acme.com/].8080
>  PROD: http/[acme.com|http://acme.com/].8080
>   
>  Not only does that make it easier and faster to create new test environments 
> but it also cuts down on the chance of copy-n-paste errors.
>   
>  I have a working POC with an PlaceholderProvider OSGi service and an 
> enhanced MapEntries that resolved any placeholders if found.
>   
>  Attached are 3 screenshots:
>  1. OSGi Placeholder Provider Configuration
>  2. /etc/map (Composum)
>  3. Result of [http://andreass.local:8080/] call



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

[jira] [Commented] (SLING-7768) Add String Interpolation support to /etc/map

[Ruben Reusser (JIRA)]

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

Ruben Reusser commented on SLING-7768:
--

so when this was done there was a bigger discussion about making this more 
generic and hence this never made it into sling itself as it's only supporting 
etc/map. 

A more generic solution to this problem could be achieved with sling pipes (a 
config structure somewhere in the repository that is copied over to the final 
location with sling pipes and while doing so it should be able to pickup and 
inject the environment variables)

> Add String Interpolation support to /etc/map
> 
>
> Key: SLING-7768
> URL: https://issues.apache.org/jira/browse/SLING-7768
> Project: Sling
>  Issue Type: Improvement
>  Components: ResourceResolver
> Environment: Sling 11-SNAPSHOT, JDK 1.8
>Reporter: Andreas Schaefer
>Priority: Major
> Attachments: Screenshot 2018-07-06 11.41.58.png, Screenshot 
> 2018-07-06 11.42.41.png, Screenshot 2018-07-06 11.43.34.png
>
>
> Having worked on migrations of a Sling derivate Ruben & I ran into issues 
> where the /etc/map would map to production instead of testing environment.
>  Many big customer have extensive /etc/maps and also many different 
> environments like dev, qa, staging, prod etc.
>  It would be great to have a tool where for example items like the host name 
> or external links in /etc/map could be configured outside so that just one 
> entry has to adjusted rather than creating a full copy of the /etc/map tree.
>   
>  Example:
>   
>  /etc/map/http/phv.fq.host.name.8080
>   
>  Placeholder provides:
>  DEV: phv.fq.host.name=localhost
>  QA: phv.fq.host.name=qa.author.acme.com
>  STAGING: 
> phv.fq.host.name=[staging.author.acme.com|http://staging.author.acme.com/]
>  PROD: phv.fq.host.name=[acme.com|http://acme.com/]
>   
>  At runtime these are the resolved values:
>  DEV: http/localhost.8080
>  QA: http/qa.author.acme.com.8080
>  STAGING: http/[staging.author.acme.com|http://staging.author.acme.com/].8080
>  PROD: http/[acme.com|http://acme.com/].8080
>   
>  Not only does that make it easier and faster to create new test environments 
> but it also cuts down on the chance of copy-n-paste errors.
>   
>  I have a working POC with an PlaceholderProvider OSGi service and an 
> enhanced MapEntries that resolved any placeholders if found.
>   
>  Attached are 3 screenshots:
>  1. OSGi Placeholder Provider Configuration
>  2. /etc/map (Composum)
>  3. Result of [http://andreass.local:8080/] call



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

Re: nodejs based sling packager

[Ruben Reusser]

Konrad,

since the tool packages and deploys it is dependent Jackrabbit-Vault for 
the package format and on Apache Sling and Composum for the 
upload/install/list/uninstall/delete endpoint. I'd honestly much prefer 
for it to be an Apache Sling module.


Ruben

On 7/17/2019 12:39 AM, Konrad Windszus wrote:

Hi Ruben,
very nice, but wouldn't it make more sense to contribute that to Apache Jackrabbit 
(next to the https://github.com/apache/jackrabbit-filevault-package-maven-plugin 
<https://github.com/apache/jackrabbit-filevault-package-maven-plugin>) rather 
than to Sling?
AFAICS there is no dependency to Sling bundles but only to JCR...

WDYT?
Thanks,
Konrad


On 14. Jul 2019, at 17:44, Ruben Reusser  wrote:

Dear Sling Developers,

in an effort to help 'front end developers' embrace Apache Sling and in order 
to make simple front-end Sling projects maven independent we created a node 
only slingpackager [1] and a sample VueJs based Slnig Content Browser [2] as a 
showcase project.

We'd like to see the slingpackager (and potentially the showcase example) be 
part of Apache Sling and maybe live on npmjs in an Apache Sling organization 
(@apachesling for example).

We'd love to hear what you think about this!

Ruben Reusser

[1] https://github.com/peregrine-cms/slingpackager
[2] https://github.com/peregrine-cms/simple-sling-vue-example

Re: nodejs based sling packager

[Ruben Reusser]

Dan, thanks for reporting the issue - what version of sling, java, node 
are you using?


On 7/15/2019 6:26 AM, Daniel Klco wrote:

Ruben,

Nice idea! The package CLI tool is a nice tool beyond just being a Node
example.

I did have some trouble installing the simple-sling-vue-example into a
local Sling instance. It's possible that my node definitions are somehow
messed up, but I got the following error message:

Collecting import information... Installing node types... Installing
privileges... Importing content... - / - /content E
/content/vuecontentbrowser ! javax.jcr.nodetype.NoSuchNodeTypeException:
Node type sling0:OrderedFolder does not exist E
/content/vuecontentbrowser/css ! java.lang.IllegalStateException: Parent
node not found. E /content/vuecontentbrowser/css/app.d4b2f170.css !
java.lang.IllegalStateException: Parent node not found. E
/content/vuecontentbrowser/js ! java.lang.IllegalStateException: Parent
node not found. E /content/vuecontentbrowser/js/app.ea81798f.js !
java.lang.IllegalStateException: Parent node not found. E
/content/vuecontentbrowser/js/app.ea81798f.js.map !
java.lang.IllegalStateException: Parent node not found. E
/content/vuecontentbrowser/js/chunk-vendors.c9e50ecf.js !
java.lang.IllegalStateException: Parent node not found. E
/content/vuecontentbrowser/js/chunk-vendors.c9e50ecf.js.map !
java.lang.IllegalStateException: Parent node not found. E
/content/vuecontentbrowser/favicon.ico ! java.lang.IllegalStateException:
Parent node not found. E /content/vuecontentbrowser/index.html !
java.lang.IllegalStateException: Parent node not found. saving approx 10
nodes... Package imported (with errors, check logs!)

On Sun, Jul 14, 2019 at 11:44 AM Ruben Reusser  wrote:


Dear Sling Developers,

in an effort to help 'front end developers' embrace Apache Sling and in
order to make simple front-end Sling projects maven independent we
created a node only slingpackager [1] and a sample VueJs based Slnig
Content Browser [2] as a showcase project.

We'd like to see the slingpackager (and potentially the showcase
example) be part of Apache Sling and maybe live on npmjs in an Apache
Sling organization (@apachesling for example).

We'd love to hear what you think about this!

Ruben Reusser

[1] https://github.com/peregrine-cms/slingpackager
[2] https://github.com/peregrine-cms/simple-sling-vue-example

nodejs based sling packager

[Ruben Reusser]

Dear Sling Developers,

in an effort to help 'front end developers' embrace Apache Sling and in 
order to make simple front-end Sling projects maven independent we 
created a node only slingpackager [1] and a sample VueJs based Slnig 
Content Browser [2] as a showcase project.


We'd like to see the slingpackager (and potentially the showcase 
example) be part of Apache Sling and maybe live on npmjs in an Apache 
Sling organization (@apachesling for example).


We'd love to hear what you think about this!

Ruben Reusser

[1] https://github.com/peregrine-cms/slingpackager
[2] https://github.com/peregrine-cms/simple-sling-vue-example

Re: [DISCUSS] Create new sling repo for org.apache.sling.cli

[Ruben Reusser]

Robert,

On 3/29/2019 8:59 AM, Robert Munteanu wrote:

Hi Ruben,

On Fri, 2019-03-29 at 08:13 -0700, Ruben Reusser wrote:

Robert,

I think as long as the 'maybe help with other stuff' part of your
email
is true I'd suggest not to use sling.cli

Suggestions welcome, I'm not terribly good at naming :-)


maybe sling.dc (sling developer companion) for things that are relevant 
to the work a sling developer does?




On a separate note, for the sling based peregrine-cms we chose to
use
nodejs for the cli [1] to lower the entry barrier a bit

That's interesting. I briefly considered using something like go which
seems better suited for CLI tools ... but ended up deciding for
something familiar. How did you find node for writing CLI tools?


writing cli tools with node is in fact very simple and straight forward 
as most nodejs based frameworks provide a cli tool. There is also a cli 
tool for front end developers working on AEM (aemfed) at [1] it relies 
on aemsync [2]


[1] https://www.npmjs.com/package/aemfed

[2] https://www.npmjs.com/package/aemsync


Robert


Ruben


[1] https://github.com/headwirecom/percli

On 3/29/2019 2:13 AM, Robert Munteanu wrote:

Hi,

Radu and I have been working on a little tool to automate some of
the
release work [1] (and maybe help with other stuff). See [2] for
background information.

As it's starting to take shape and become usable we'd like to move
it
out of the whiteboard.

I suggest we use 'org.apache.sling.cli' as the artifactId and
'sling-
org-apache-sling-cli' as the repository.

Thoughts?

Thanks,

Robert

[1]: https://github.com/apache/sling-whiteboard/tree/master/cli
[2]:
https://lists.apache.org/thread.html/b3001deea28c800f81830701c9293e66634f5512d70bed0043fb2302@%3Cdev.sling.apache.org%3E

[jira] [Commented] (SLING-8278) improve chrome audit score

[Ruben Reusser (JIRA)]

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

Ruben Reusser commented on SLING-8278:
--

https://issues.apache.org/jira/browse/SLING-8283 is needed to get the best 
practices score up 

> improve chrome audit score
> --
>
> Key: SLING-8278
> URL: https://issues.apache.org/jira/browse/SLING-8278
> Project: Sling
>  Issue Type: Improvement
>  Components: Starter
>    Reporter: Ruben Reusser
>Priority: Trivial
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> google chrome audit currently lists a set of accessibility and seo problems 
> with the sling starter content. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (SLING-8283) httpGet in system/sling.js uses depricated main thread blocking code

[Ruben Reusser (JIRA)]

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

Ruben Reusser commented on SLING-8283:
--

https://github.com/apache/sling-org-apache-sling-servlets-post/pull/4

> httpGet in system/sling.js uses depricated main thread blocking code
> 
>
> Key: SLING-8283
> URL: https://issues.apache.org/jira/browse/SLING-8283
> Project: Sling
>  Issue Type: Improvement
>  Components: Best practices
>    Reporter: Ruben Reusser
>Priority: Major
>
> the sling starter homepage throws the following error in the browser console.
> sling.js:75 [Deprecation] Synchronous XMLHttpRequest on the main thread is 
> deprecated because of its detrimental effects to the end user's experience. 
> For more help, check 
> [https://xhr.spec.whatwg.org/.|https://xhr.spec.whatwg.org/]
> As the error mentions this is due to the fact that sling is using main thread 
> blocking calls in /system/sling.js - this is generally not recommended 
> anymore as it blocks the ability for a user to interact with the browser
> The problem can easily be solved by using callbacks instead of main thread 
> blocking code. 
> by altering Sling.httpGet to support callbacks this change can be made 
> gradually over time without a break in backwards compatibility
>  
> {code:java}
> /**
>  * HTTP GET XHR Helper
>  * @param {String} url The URL
>  * @param {Function} optional second parameter for async version of the 
> method.
>  *The callback will get the XHR object, method returns immediately
>  * @return the XHR object, use .responseText for the data
>  * @type String
>  */
> Sling.httpGet = function(url, callback) {
> var httpcon = Sling.getXHR();
> if (httpcon) {
> if(callback) {
> httpcon.onload = function() { callback(this); };
> httpcon.open('GET', url);
> httpcon.send(null);
> } else {
> httpcon.open('GET', url, false);
> httpcon.send(null);
> return httpcon;
> }
> } else {
> return null;
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SLING-8283) httpGet in system/sling.js uses depricated main thread blocking code

[Ruben Reusser (JIRA)]

Ruben Reusser created SLING-8283:


 Summary: httpGet in system/sling.js uses depricated main thread 
blocking code
 Key: SLING-8283
 URL: https://issues.apache.org/jira/browse/SLING-8283
 Project: Sling
  Issue Type: Improvement
  Components: Best practices
Reporter: Ruben Reusser


the sling starter homepage throws the following error in the browser console.

sling.js:75 [Deprecation] Synchronous XMLHttpRequest on the main thread is 
deprecated because of its detrimental effects to the end user's experience. For 
more help, check [https://xhr.spec.whatwg.org/.|https://xhr.spec.whatwg.org/]

As the error mentions this is due to the fact that sling is using main thread 
blocking calls in /system/sling.js - this is generally not recommended anymore 
as it blocks the ability for a user to interact with the browser

The problem can easily be solved by using callbacks instead of main thread 
blocking code. 

by altering Sling.httpGet to support callbacks this change can be made 
gradually over time without a break in backwards compatibility

 
{code:java}
/**
 * HTTP GET XHR Helper
 * @param {String} url The URL
 * @param {Function} optional second parameter for async version of the method.
 *The callback will get the XHR object, method returns immediately
 * @return the XHR object, use .responseText for the data
 * @type String
 */
Sling.httpGet = function(url, callback) {
var httpcon = Sling.getXHR();
if (httpcon) {
if(callback) {
httpcon.onload = function() { callback(this); };
httpcon.open('GET', url);
httpcon.send(null);
} else {
httpcon.open('GET', url, false);
httpcon.send(null);
return httpcon;
}
} else {
return null;
}
}
{code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (SLING-8278) improve chrome audit score

[Ruben Reusser (JIRA)]

Ruben Reusser created SLING-8278:


 Summary: improve chrome audit score
 Key: SLING-8278
 URL: https://issues.apache.org/jira/browse/SLING-8278
 Project: Sling
  Issue Type: Improvement
  Components: Starter
Reporter: Ruben Reusser


google chrome audit currently lists a set of accessibility and seo problems 
with the sling starter content. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Sling 12 themes

[Ruben Reusser]

since we now have sling models and sling model exporters I would also 
kind of like a rewrite chain on json to shorten URLs for example.


Ruben


On 10/23/2018 9:59 AM, Jason E Bailey wrote:

It depends on what I'm writing and where, whether it's server side or front 
end. But in general I use a combination of html/jsp and models for the majority 
of my code. The delta between what the html looks like between these 
implementations is usually minor.

I do like the contextual awareness that HTL brings, I was doing something 
similar in the rewriter before HTL became a thing. But I like it as a tool in 
the chest. Not as something that is required.

- Jason

On Tue, Oct 23, 2018, at 12:50 PM, Carsten Ziegeler wrote:

So what do you like for creating html?

Carsten

Am 23.10.2018 um 18:42 schrieb Jason E Bailey:

1. I don't use HTL

2. When I last mucked with HTL, and this could have changed, it had problems 
itself with HTML5

3. When I've used the rewriter it's because I need something centralized that 
is modifying HTML with out regard to where the  HTML is coming from.

4. I dislike HTL

5. I really dislike HTL

- Jason

On Tue, Oct 23, 2018, at 12:33 PM, Carsten Ziegeler wrote:

Why do we need a rewriter if we're using HTL? I think a plugin model to
influence or inspect the html using HTL is way more efficient as HTL
already knowns the context of an element.

Regards
Carsten

Am 23.10.2018 um 18:02 schrieb Jason E Bailey:


On Tue, Oct 23, 2018, at 11:08 AM, Daniel Klco wrote:

A couple thoughts from my end:
 - Cleanup of the Rewriter, providing a HTML 5 pipeline

I was going to start working on the HTML 5  rewriter next week.

- Jason


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

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

Re: /etc/map with Placeholders for farms / dev stack

[Ruben Reusser]

Georg,

I think this is a good discussion - looks like the sling team has to 
make some decisions here and I am glad the etc/map work Andreas did is 
at least sparking a bigger discussion.


From my point of view using packages and install hooks may work but may 
not be the best solution as it would imply a package install every time 
a change to the configs are necessary.


Not sure if maybe this would need a bigger spec to continue the work and 
alignment on what everybody would like to see


Ruben

On 7/30/2018 4:29 PM, Georg Henzler wrote:

Hi Andreas,


Install Hooks have their own issues like that they do not work for
replication


Install Hooks work flawlessly with replication since around two years
(AEM 6.3)


and they requires to changes whatever the customer has /
provides in order to add the place holders.


not sure what you mean with this?


... allowing external URLs is dangerous...

I do agree with that and I will remove that from my POC.


A property file should still be possible... so if we do this
in Sling, I think the following is needed:

Property Sources to be supported at minimum:

* An OSGi configuration
* A local properties file
* OS Env variables
* Java System Properties

There should be an Felix console plugin to show what is active
from what source and where the value is used. It should live in
a bundle named like e.g. org.apache.sling.systemenv and provide
a simple interface to perform string interpolation on any
string. This service can then be used by

* Resource resolver
* Sling distribution
* Context-Aware Configuration

a product like AEM can also use this interface in

* AEM replication config
* externaliser config

To have this mechanism properly rolled out it will take some
time (until all listed modules properly use the to-defined
interface)

IMHO it is not an option to do it locally in resourceresolver
because

a) it would result in quite a bit of duplicated code across the
modules listed above (once we actually start implement it)
b) if additional sources need to be added in the future (think
ZooKeeper as one interesting option to receive those env-specific
values), all consumers would have to be updated (unlikely to
happen, more likely is to have inconsistent behaviour over time)

Since the described above is quite a bit of effort, I opt for
pushing a lower-level approach forward (something like [1] or
maybe even something on oak level). Then there is only one
implementation needed and it's available immediately, everywhere.

-Georg

[1] https://issues.apache.org/jira/browse/JCRVLT-254

Re: Markdown resource provider

[Ruben Reusser]

on a more serious note, this would be possibly great for dita as well 
(for example better process for the xmladdon for AEM)


Ruben


On 7/29/2018 6:30 AM, Jason E Bailey wrote:

Eugen - I didn't realize that it was a thing. So I'm good with it.  However I 
now have a strong desire to make an HTML resource provider that will define 
resources trees with HTML, which you can then use to generate HTML. A meta-HTML 
:)

- Jason


On Sun, Jul 29, 2018, at 1:52 AM, Ioan Eugen Stan wrote:

Hi,

Nice work Robert.

@Jason: I do believe there is value in yaml frontmatter. A lot of
existing tools support markdown + frontmatter and people using them are
familiar with that. Adding something Sling specific is going to make
interoerability harder. It is going to be non portable as well.

I'm in favor of using front matter. It will help port markdown apps to
sling and promote interoperability between such apps.

Regards,

Eugen Stan
Netdava International

   Mesaj original
De la: jason.bai...@24601.org
Trimis: 28 iulie 2018 20:28
Către: dev@sling.apache.org
Răsp. la: dev@sling.apache.org
Subiect: Re: Markdown resource provider

I believe there's a difference between what the two end goals are. There
is a the rendering of a Markdown resource into HTML and then there is
using a Markdown file to generate a resource.

A couple of thoughts on this.
# For a Markdown Resource providing attributes, I don't see a reason to
use YAML for this. Markdown support integrated HTML and HTML supports
custom tags.  You could  create some thing along the lines of  this wouldn't be displayed when
viewing a rendered version of the file but be accessible when parsing.

#  We have a module for taking different file types and creating a
Resource Object out of them, that's the ContentParser. If the goal was
to import the md file into an existing resource we'd use the
ContentLoader. If we wanted the ability to read and write the file then
I see a ResourceProvider and since we have a FSResourceProvider I still
think it makes sense to allow that to be expandable.



--
Jason

On Fri, Jul 27, 2018, at 10:31 AM, Carsten Ziegeler wrote:
  




Daniel Klco wrote

My first thought after reading the last paragraph was - Wouldn't it be
cool if the FsResourceProvider was extensible so that specific files could
be rendered in a specific manner, then you could add a MarkDown Handler and
it would make it easier for other people to add custom handlers or to
extend existing one for specific requirements.


Agreed! This mechanism could be useful for XML or JSON files as well.
Imagine if one could register an XSLT handler and just have Sling serve the
rendered HTML for a dump of XML files.


That's why I mentioned the resource decorator approach - it allows you
to do this, and then you're even independent of the resource provider
serving the resource.
The decorator approach might not be the most obvious one, but I think it
does the trick and doesn't require us to add another overlapping concept.

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

[jira] [Commented] (SLING-7058) the stop command line option does not seem to work

[Ruben Reusser (JIRA)]

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

Ruben Reusser commented on SLING-7058:
--

it seems this issue is due to the logic in 
https://github.com/apache/sling/blob/trunk/launchpad/base/src/main/java/org/apache/sling/launchpad/app/Main.java
 as it only initializes the ControlListener if the command start is passed to 
sling. This may of course be intentional

> the stop command line option does not seem to work
> --
>
> Key: SLING-7058
> URL: https://issues.apache.org/jira/browse/SLING-7058
> Project: Sling
>  Issue Type: Bug
>  Components: Launchpad
>    Reporter: Ruben Reusser
>Priority: Minor
>
> as per 
> https://sling.apache.org/documentation/the-sling-engine/the-sling-launchpad.html#command-line-options
>  a user should be able to stop a running sling instance by calling
> {code:java}
> java -jar sling-9.jar stop
> {code}
> Sling is supposed to write a file at startup with the chosen control port and 
> the secret key at 
> `$\{sling.home}/conf/controlport`
> I do not see that file created nor does the above command work to stop a 
> running sling instance. 



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

[jira] [Created] (SLING-7058) the stop command line option does not seem to work

[Ruben Reusser (JIRA)]

Ruben Reusser created SLING-7058:


 Summary: the stop command line option does not seem to work
 Key: SLING-7058
 URL: https://issues.apache.org/jira/browse/SLING-7058
 Project: Sling
  Issue Type: Bug
  Components: Launchpad
Reporter: Ruben Reusser
Priority: Minor


as per 
https://sling.apache.org/documentation/the-sling-engine/the-sling-launchpad.html#command-line-options
 a user should be able to stop a running sling instance by calling

{code:java}
java -jar sling-9.jar stop
{code}

Sling is supposed to write a file at startup with the chosen control port and 
the secret key at 
`$\{sling.home}/conf/controlport`

I do not see that file created nor does the above command work to stop a 
running sling instance. 




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

Sling post servlet import

[Ruben Reusser]

Hi there,

A couple of days ago I posted on the users list about the sling post servlet 
and import command. There seem to be some odd issues

1) order at reimport is not preserved
2) replace import merges sub nodes instead of replacing them

https://lists.apache.org/thread.html/58295987e9b13fd93424c183674316c0eb986b30d85cfb63e9bd1004@%3Cusers.sling.apache.org%3E

Not sure if thats just me not understanding the intent of the import command or 
if there is really something wrong there.

Ruben

Re: struggling with sling-9 build and sling model exporter

[Ruben Reusser]

actually, adding the latest version would be better

[artifacts]
org.apache.sling/org.apache.sling.models.jacksonexporter/1.0.7-SNAPSHOT
com.fasterxml.jackson.core/jackson-databind/2.8.6
com.fasterxml.jackson.core/jackson-core/2.8.6
com.fasterxml.jackson.core/jackson-annotations/2.8.6


On 4/3/2017 11:26 AM, Ruben Reusser wrote:

while you are at fixing the launchpad, would be good to add

[feature name=model-exporter]

# Add the dependencies on the Model exporter
[artifacts]
org.apache.sling/org.apache.sling.models.jacksonexporter/1.0.7-SNAPSHOT
com.fasterxml.jackson.core/jackson-databind/2.3.2
com.fasterxml.jackson.core/jackson-core/2.3.2
com.fasterxml.jackson.core/jackson-annotations/2.3.2

at the same time

Ruben

On 4/3/2017 11:24 AM, Oliver Lietz wrote:

On Monday 03 April 2017 20:16:49 Carsten Ziegeler wrote:

Just fixed the bug in the servlets post servlet, still remaining:

   ServerSideInstallerTest.noActiveResources:61 Active resources found:
[group[[resource[entityId=bundle:org.apache.sling.scripting.sightly.js.provi 


der, scheme=launchpad,
url=launchpad:resources/install/0/org.apache.sling.scripting.sightly.js.prov 

ider-1.0.20.jar, type=bundle, error=null, state=INSTALL, 
version=1.0.20,

lastChange=-1, priority=50, digest=149124324
Some packages changed in Sightly recently. Using latest Sightly 
snapshots in

Launchpad fixed it for me.

Regards,
O.


Carsten
Carsten Ziegeler wrote


Ruben Reusser wrote


seems to me it's because Apache Sling Scripting HTL JavaScript Use
Provider does not activate anymore.

Yes, that seems to be one error.

But the file upload is currently not fully working either and 
that's due
to my "improvements" in that area. I just fixed one of the failing 
test

cases, looking into the other now.

Carsten

Re: struggling with sling-9 build and sling model exporter

[Ruben Reusser]

while you are at fixing the launchpad, would be good to add

[feature name=model-exporter]

# Add the dependencies on the Model exporter
[artifacts]
org.apache.sling/org.apache.sling.models.jacksonexporter/1.0.7-SNAPSHOT
com.fasterxml.jackson.core/jackson-databind/2.3.2
com.fasterxml.jackson.core/jackson-core/2.3.2
com.fasterxml.jackson.core/jackson-annotations/2.3.2

at the same time

Ruben

On 4/3/2017 11:24 AM, Oliver Lietz wrote:

On Monday 03 April 2017 20:16:49 Carsten Ziegeler wrote:

Just fixed the bug in the servlets post servlet, still remaining:

   ServerSideInstallerTest.noActiveResources:61 Active resources found:
[group[[resource[entityId=bundle:org.apache.sling.scripting.sightly.js.provi
der, scheme=launchpad,
url=launchpad:resources/install/0/org.apache.sling.scripting.sightly.js.prov
ider-1.0.20.jar, type=bundle, error=null, state=INSTALL, version=1.0.20,
lastChange=-1, priority=50, digest=149124324

Some packages changed in Sightly recently. Using latest Sightly snapshots in
Launchpad fixed it for me.

Regards,
O.


Carsten
Carsten Ziegeler wrote


Ruben Reusser wrote


seems to me it's because Apache Sling Scripting HTL JavaScript Use
Provider does not activate anymore.

Yes, that seems to be one error.

But the file upload is currently not fully working either and that's due
to my "improvements" in that area. I just fixed one of the failing test
cases, looking into the other now.

Carsten

Re: struggling with sling-9 build and sling model exporter

[Ruben Reusser]

seems to me it's because Apache Sling Scripting HTL JavaScript Use 
Provider does not activate anymore.


Ruben

On 4/3/2017 10:40 AM, Carsten Ziegeler wrote:

Daniel Klco wrote

Hm, I'm seeing that as well. I'm seeing failures
in org.apache.sling.launchpad.webapp.integrationtest.UploadFileTest.
Checking into it now.


Hmm, this might be related to my recent changes to the post servlet. If
you need help, let me know

Regards
Carsten


In the meantime, you can skip the tests if you need to run a build (of
course this isn't a permanent solution)

Thanks,
Dan

On Mon, Apr 3, 2017 at 9:11 AM, Ruben Reusser <r...@headwire.com> wrote:


Hi

I have been trying to successfully build trunk for the past couple of days
- it seems building launchpad/builder fails due to the tests. Is that just
me or a common problem?

I also noticed that the sling model exporter is missing from launchpad -
is that intentional?

thank you

Ruben




  

struggling with sling-9 build and sling model exporter

[Ruben Reusser]

Hi

I have been trying to successfully build trunk for the past couple of 
days - it seems building launchpad/builder fails due to the tests. Is 
that just me or a common problem?


I also noticed that the sling model exporter is missing from launchpad - 
is that intentional?


thank you

Ruben

Re: Configuration of the ResourceResolver Mapping

[Ruben Reusser]

I think approach b) has a couple of short comings for larger sites as well

a good example are bucket pages (say you have to bucket content because 
otherwise you have to many subnodes). I've seen sites where these bucket 
pages are removed from the urls.


a secondary issue is that the upstream caching mechanism does not know 
about the mapping and therefore has trouble caching pages in a good 
manner (suffix and selector based pages)


I would honestly prefer an option c)

where
1) sling can be asked to resolve a short url to a long url (in 
conjunction with an apache module that can use this resolution for caching)
2) use a rewrite pipeline for outgoing url changes (there are also use 
cases for serving assets from a static domain)


Ruben

On 4/19/2016 6:18 AM, Bertrand Delacretaz wrote:

On Tue, Apr 19, 2016 at 3:12 PM, Julian Sedding  wrote:

...The whole mapping business is overly complicated IMHO and any reduction
of the complexity is welcome

Indeed. I would suggest that people who are actively managing large
Sling instances in the field (hint, hint ;-) come up with proposals
about how to simplify the whole thing.

-Bertrand

Re: Worthwhile to create a Sling CMS?

[Ruben Reusser]

for what it's worth, it would be really nice to have an inline editing 
experience, maybe like


https://slate.adobe.com/welcome/

Ruben

On 1/19/2016 5:25 AM, Sandro Boehme wrote:

Hello,

I personally think there is a market and demand for a small Sling CMS 
that is a website builder which assembles frontend components from an 
open marketplace.


It would help me a big deal if some of you could tell me if they would 
use this kind of CMS or if the know people who would use it as that 
validates (or invalidates) my effort!


It should be as simple and straightforward as a typical website 
builder for composing a page from the frontend components. At the same 
time the barrier to develop these components should be as low as 
possible and developers should be able to sell components to allow a 
thriving marketplace for users to choose components from.


When researching to see if there is something comparable I didn't 
found anything. The closest were Wix, LightCMS, Hippo (marketplace 
planned), Liferay and Nuxeo. But they all have an enterprise edition 
which raises the barrier for many users and developers to use the CMS 
and makes the distribution of the CMS harder. If you know something 
else that matches my goals better I would really like to know it!


For me it seems obvious to go that route but I'm certainly biased :-). 
This is why your opinion is very important to me!


If you would like to know more about this initiative you will find 
more (technical) information at the introduction page of the survey 
here: https://de.surveymonkey.com/r/WL7S2PJ
Of course if you don't have the time you don't need to fill the 
questionnaire and you can just read the first page.


Any feedback is much appreciated!

Thanks,

Sandro

version number changes in sling

[Ruben Reusser]

Hi,

I noticed that the version numbers of the poms in sling seem to be all 
over the place. If you look at [1]


org.apache.felix | org.apache.sling.scripting.velocity
current version is: 2.0.0-SNAPSHOT
version before: 2.0.1-SNAPSHOT

is that correct or am I looking at the commits the wrong way?

thanks

[1] http://www.headwire.com/sling/?path=contrib--scripting--velocity

Re: [RT] Move to Oak

[Ruben Reusser]

just my 2c - will somebody go through all the samples/documentation when 
moving to oak and make sure everything still works/update the 
documentation?


Ruben

On 5/11/2015 12:29 PM, Antonio Sanso wrote:

+1

regards

antonio

On May 11, 2015, at 8:40 PM, Carsten Ziegeler cziege...@apache.org wrote:


Hi,

what about moving our launchpad completely to Oak and forget about the
old jackrabbit in there? I don't think we should provide both in our
launchpad in the long run.

The bundles for jackrabbit are still around if someone wants to use them

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

Re: [RT] The various roles of (multitenant) content

[Ruben Reusser]

looking at this it seems the same functionality would be handy for 
feature flags, no?


Ruben

On 8/18/2014 6:19 AM, Bertrand Delacretaz wrote:

Hi,

On Mon, Aug 18, 2014 at 2:56 PM, Ian Boston i...@tfd.co.uk wrote:
...

Is configuration part of application content or system content or both?

...

We probably need a more fine-grained definition for configs - for now
I see the following types of configuration:

a) Global system-level config, like the URL of a remote logging
server. This can be either pure OSGi configs or based on shared
repository content with suitable access control.

b) Version-specific system config, where Sling instances that run the
same version of system and application code share the same config.
Also manageable in the content repository with access control.

c) Application or tenant-specific config. Using non-OSGi configs which
are just content in the repository, picked up on the fly by services
that process a tenant-specific request, works. But I don't think we
currently have a solution for tenant-specific configuration of OSGi
services, unless the services are specifically designed for that.

So I'd say with our current installer there is configuration both in
system and application content. and tenant-specific configurations
require specific code for now.

-Bertrand

Re: [RT] Multi Tenancy

[Ruben Reusser]

for us the goal would be to run multiple customers in one sling instance 
without the ability to touch the code/content of any other tenant. It 
would be nice if


a) restricting users from one tennat to another would be simple
b) allow a good search path override for each tenant
c) split out the admin account into tenants (an admin session should not 
have access to all tenants)

d) osgi properties per tenant (probably needs to be handled in felix?)

Ruben

On 8/11/2014 6:29 AM, Bertrand Delacretaz wrote:

Hi,

On Mon, Aug 11, 2014 at 3:13 PM, Stefan Seifert sseif...@pro-vision.de wrote:

...btw. we should perhaps first start to define what we mean with the term 
tenant. this much-used and
overloaded term might be a source of confusion as well...

Definitely - I suggest creating a page under
https://cwiki.apache.org/confluence/display/SLING for multi-tenant use
cases and definitions.

-Bertrand

Re: Idea: Caching in Sling

[Ruben Reusser]

Ben,

we chose a bit of a different approach and added html caching for CQ a 
while back


http://www.headwire.com/svn/projects/cqbpcache/trunk/cqbpcache/

basically,we use a tag that allows you to monitor changes in a path and 
cache the html accordingly until a node in the path (or one if its 
subnodes) changes.


Feel free to try it out, feedback welcome

Ruben

On 7/28/2014 11:15 PM, Ben Zahler wrote:

Hi all,

We are considering to implement a resource-based caching in Sling.

I have found some efforts to do something similar in the past, but they all 
seem to have been either abandoned or do something different from what we have 
in mind.

So it would be great to get some feedback if it this has been tried before and 
was given up or if our idea is just not what the Sling-world is waiting for.

This is what our Sling-Cache would do:

-   deliver sling resources from cache based on an exact path

-   deliver sling resources from cache for a subtree of the repository

The following scenarios would benefit from such a cache:

-   navigation components that are expensive to calculate and are identical 
for whole subtrees of a site

-   cacheable components on non-caheable pages

-   CQ use cases with dispatcher caching invalidate the large sections or 
the whole cache. After an invalidation, for a short time all traffic hits 
CQ/Sling. With resource based caching, this could be improved, allowing Sling 
to scale better.

Of course we would create an open-source implementation of our idea, caching 
either in memory or in the repository itself and leave room for other 
implementations with external caches.

So is this an idea you would love to see implemented or is it rather something 
that you deem unnecessarily complex?

Thanks for any feedback!

Cheers,
Ben Zahler

Inside Solutions AG | Bahnhofplatz 11 | 4410 Liestal | Schweiz
Telefon: +41 61 551 00 40 | Direkt: +41 61 551 00 43
http://www.inside-solutions.chhttp://www.inside-solutions.ch/

Re: Launchpad 7 Release?

[Ruben Reusser]

just my 2c, but before releasing 7 it would be a good idea to make sure 
all tutorials and samples are correctly working as well. I took a quick 
look at espblog and was not able to get it to run with launchpad 7


Ruben

On 7/22/2014 11:04 PM, Carsten Ziegeler wrote:

2014-07-22 23:12 GMT+02:00 Oliver Lietz apa...@oliverlietz.de:


+1, I think it's important to have a Sling 7 release soon.

Yes, but not a half-baked one. We would have even more users complainig
about
7 as we now have with 6.



Well, which part do you think would be half-baked if we simply release
everything as is. I think most of the bundles (if not all) are in a pretty
good shape right now.

Carsten



I haven't checked the SNAPSHOT bundles, but I think there are some

bundles

where nothing changed after their latest release so we may use some
already released bundles and not release *all* now.

there are probaly less than 20 bundles.


In theory, the list.xml should only reference snapshots which have actually
changes. But I'll check this today to see where we are.

Carsten

problems launching the current sling release

[Ruben Reusser]

hi,

I downloaded the standalone bundle from [1] and trying to run it with

java -jar org.apache.sling.launchpad-6-standalone.jar

getting the following exception (java 7 on windows):

22.07.2014 09:30:18.229 *INFO* [main] Setting sling.home=sling (default)
22.07.2014 09:30:18.230 *INFO* [main] Starting Sling in sling 
(C:\projects\sling\sling)
22.07.2014 09:30:18.243 *INFO* [main] Renaming current launcher jar 
org.apache.sling.launchpad.base.jar.1406046590632 to 
org.apache.sling.launchpad.base.jar

22.07.2014 09:30:18.245 *INFO* [main] Checking launcher JAR in folder sling
22.07.2014 09:30:18.255 *INFO* [main] Existing launcher is up to date, 
using it: 2.3.0 (org.apache.sling.launchpad.base.jar)
22.07.2014 09:30:18.256 *INFO* [main] Loading launcher class 
org.apache.sling.launchpad.base.app.MainDelegate from 
org.apache.sling.launchpad.base.jar

22.07.2014 09:30:18.276 *INFO* [main] Starting launcher ...
22.07.2014 09:30:18.277 *INFO* [main] HTTP server port: 8080
22.07.2014 09:30:18.349 *ERROR* [main] Failed to Start OSGi framework
org.osgi.framework.BundleException: Uncaught Instantiation Issue: 
java.lang.ArrayIndexOutOfBoundsException: -1
at 
org.apache.sling.launchpad.base.impl.Sling.init(Sling.java:245)
at 
org.apache.sling.launchpad.base.app.MainDelegate$1.init(MainDelegate.java:159)
at 
org.apache.sling.launchpad.base.app.MainDelegate.start(MainDelegate.java:159)

at org.apache.sling.launchpad.app.Main.startSling(Main.java:244)
at org.apache.sling.launchpad.app.Main.init(Main.java:107)
at org.apache.sling.launchpad.app.Main.main(Main.java:56)
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.elementData(ArrayList.java:403)
at java.util.ArrayList.get(ArrayList.java:416)
at 
org.apache.felix.framework.BundleImpl.getCurrentModule(BundleImpl.java:1046)
at 
org.apache.felix.framework.BundleImpl.getSymbolicName(BundleImpl.java:863)
at 
org.apache.sling.launchpad.base.impl.SlingFelix.getSymbolicName(SlingFelix.java:32)

at org.apache.felix.framework.Felix.toString(Felix.java:1012)
at org.apache.felix.framework.Logger.doLog(Logger.java:128)
at org.apache.felix.framework.Logger._log(Logger.java:181)
at org.apache.felix.framework.Logger.log(Logger.java:114)
at 
org.apache.felix.framework.ExtensionManager.init(ExtensionManager.java:201)

at org.apache.felix.framework.Felix.init(Felix.java:374)
at 
org.apache.sling.launchpad.base.impl.SlingFelix.init(SlingFelix.java:39)
at 
org.apache.sling.launchpad.base.impl.Sling.init(Sling.java:235)

... 5 more
22.07.2014 09:30:18.351 *ERROR* [main] There was a problem launching Sling
22.07.2014 09:30:18.352 *INFO* [Sling Terminator] Java VM is shutting down

[1] http://sling.apache.org/downloads.cgi

Re: Sling demos (Was Re: Ways of launching Sling for the demos)

[Ruben Reusser]

Carsten

It would be a good idea to make the demos available from the root page in sling 
once a demo is deployed. Some short description of the demo and how it's 
supposed to be used would be good too.

Ruben

 On May 16, 2014, at 4:49 AM, Carsten Ziegeler cziege...@apache.org wrote:
 
 Thanks for bringing this up, David!
 
 So what do people think, should we remove some of the demos David
 mentioned? It doesn't make sense to have them around when they are of no
 real value.
 
 Carsten
 
 
 2014-04-07 15:36 GMT+02:00 David Bosschaert david.bosscha...@gmail.com:
 
 Hi all,
 
 On 3 April 2014 17:14, David Bosschaert david.bosscha...@gmail.com
 wrote:
 On 3 April 2014 16:15, Bertrand Delacretaz bdelacre...@apache.org
 wrote:
 Note that you might find some quite old stuff under /samples, if you
 have suggestions for things that should be archived or at least marked
 obsolete let's hear them!
 
 I'm planning to take a closer look at their semantics soon - will
 share my thoughts :)
 
 I had a closer look at the demos. Many of the demos weren't really
 broken, but the steps to use them were often wrong (which made you
 feel it was broken) or missing. I updated the documentation for the
 following demos:
 * accessmanager-ui
 * espblog
 * javashell
 * path-based-rtp
 * slingbucks
 * slingshot
 * usermanager-ui
 * webloader (service and ui)
 the patch is in SLING-3489. I think they above demos are definitely useful
 :)
 
 The JavaShell demo had two deps that were broken, a fix is attached
 here: SLING-3493.
 
 I wasn't too sure about the following demos
 * simple-demo, I personally find this demo confusing and not 'simple' at
 all.
 * framework-fragment - this demo is broken, but it seems to show how
 to expand the OSGi Framework system packages. Seems to me that the
 Sling project is the wrong place for a demo like this (and in
 addition, you generally don't want to advocate this feature anyway).
 * installing-dependencies, a maven-based demo, is this still relevant?
 When would you use this setup?
 Maybe remove these three?
 
 I wasn't sure whether the following demos worked, at least I didn't
 figure out how to make them change the login form...
 * custom-login-form
 * custom-selector-login-form
 if someone can tell me how to make them do something, let me know and
 I can update their docs...
 
 The post-servlet-ext demo does seem to work, but requires development
 on the user side before you can actually see what it does. (The user
 needs to create a page that does a post with :operation=link to see
 something)
 I would suggest to add some more content to this demo so that you can
 actually see what it does.
 
 There are also a number of demos that aren't listed as submodules of
 the 'samples' pom, so they have less visibility. I would suggest to
 either remove them or make them submodules:
 * inplace-integration-tests: this one is broken, but seems useful. I
 think we should fix it and include as submodule in parent pom.
 * mail-archive: this is the beginning of a more comprehensive example.
 It seems nice but is unfortunately unfinished and doesn't seem to
 currently work. Should we keep it?
 * urlfilter: an example of using Servlet Filters with Sling. There is
 no documentation, but it might be useful to keep (and add some docs :)
 * workspacepicker: another Servlet Filter demo, this time using OSGi
 Services (whereas the urlfilter uses @SlingFilter). Again: without
 docs. Should we keep this?
 
 Thoughts, anyone?
 Cheers,
 
 David
 
 
 
 -- 
 Carsten Ziegeler
 cziege...@apache.org

Re: [OT] Feature flag influence on Resource access (Was: FYI: feature flags prototype)

[Ruben Reusser]

it may be worth it revisiting the tenant api in regards to feature flags 
as well and have some sort of way to have feature flag dependent osgi 
properties.


Ruben

On 12/6/2013 12:51 PM, Justin Edelson wrote:

On Fri, Dec 6, 2013 at 12:10 PM, Alexander Klimetschek
aklim...@adobe.com wrote:

On 06.12.2013, at 08:08, Felix Meschberger fmesc...@adobe.com wrote:


Think back and forth I really think  that we should put feature flag support 
into the ResourceResolver proper.

I agree.

+1

Henry wrote it well: So, fundamentally all that the framework can do
is provide a way to define flags, provide a switch panel and a way to
extend it, and API to check flags in condition statements. How and
where each flag is used is up to the developer of a specific
application feature.

The ResourceResolver is such an application feature which needs to be
enhanced to support feature flags. We probably have some others in
Sling as well.

Regards,
Justin


Another completely open question is: the resource resolver is not tied to a 
request, backend services use it as well. So if the feature flag is driven by 
the request, how do you handle that for those service resolvers?

AFAIU, the two major cases for feature flags are a) user dependent and b) global on/off. 
But in both cases it can depend on the application whether those services have to fall 
under the flags or not. For example, you might have an observation going on that does 
something advanced (*). Should it run even if it's feature is off (as nobody 
will use the results as long as the feature is off)? Or should it be totally disabled? 
This is a question often only the application can decide.

Say the service resolvers are using admin sessions or some service users, then 
you could turn it on/off based on them - to be in line with user-based request 
resolvers in case a). But it could also be that you have flag a where you must 
handle it in application code and don't want it handled in the resolver 
already. Thus you either make it configurable on the flag itself what impact it 
has or you actually ask for a resource resolver with special feature flags in 
the first place (or not, getting a standard one).

Also, I mentioned observation: it's a JCR level thing that wouldn't be affected 
by Sling resource resolver feature flags.

Just thinking out loud here, not sure what the cleanest approach would be...

Cheers,
Alex

Re: FYI: feature flags prototype

[Ruben Reusser]

Roy Fielding's presentation on the subject may also be interesting

http://www.slideshare.net/royfielding/evolve13-keynote-scrambled-eggs
page 36 to 45

Ruben

On 11/14/2013 1:55 PM, Dominik Süß wrote:

Hi Alex,
this is one way but just solves this partially since you completely rely on
inclusions to happen, but sometimes you just walk the tree and collect the
information of resources e.g. to draw the navigation - and for such
situations it would then be required to add such logic to the rendering
Code where you could just filter the ResourceTree beforehand.

Best regards,
Dominik


On Thu, Nov 14, 2013 at 10:48 PM, Alexander Klimetschek
aklim...@adobe.comwrote:


On 14.11.2013, at 05:11, Dominik Süß dominik.su...@gmail.com wrote:


As mentioned earlier the majority of features I have implemented yet do
have a frontendpart that would get rendered and it would add additional
complexity if I have to use custom resourceTypes (inherited ones through
superType) just to disable them based on such rules.

Wouldn't you just filter those requests out on a high level, e.g. using a
servlet filter? Which can already be provided in a modular fashion by an
optional featureflags module.


Cheers,
Alex

Re: FYI: feature flags prototype

[Ruben Reusser]

Bertrand, Dominik,

the feature flag may also have an impact on the nodes/properties that 
you need to render the feature. Being able to handle this in the 
resource tree directly without having to handle it in component code 
would be great. However, I am not sure if the intention of the feature 
flag was more to enable/change little features (code fragment) and not 
really change big things (leave that to testtarget or other products?)


Ruben

On 11/13/2013 6:32 AM, Dominik Süß wrote:

Hi Bertrand,

the UI of an application based on Sling are often composed of existing
resourceTypes so you cannot just decide in the code to display or not to
display so you have to annotate/flag the resources and then have some
code deciding if this resource should be rendered or not. For sure you
could add code to each resource to check if it is to be rendered but this
is a lot of repetive code. Another option would be a Servlet filter to skip
inclusion at that Point. But this all fails in some situations like whenyou
consume an aggregated json dump and use this on client side. Therefore the
only shared location that all code should act on when looking at the
persistance is the resourcetree, and as already existing API the Access
Gate API seems to be capable of doing exactly what is required - masking
the resourcetree based on custom logic.

Best regards
Dominik


On Wed, Nov 13, 2013 at 12:01 PM, Bertrand Delacretaz 
bdelacre...@apache.org wrote:


Hi Dominik,

On Tue, Nov 12, 2013 at 5:07 PM, Dominik Süß dominik.su...@gmail.com
wrote:

...as far as I can see the API is just covering the java aspect of

this...

Nothing prevents you from using the FeatureFlags service in scripted code.


you could have a gate looking for a marker at a resource
which indicates it to be part of a specific feature and therefore

disables

access to it

Do we need any changes to Sling or to this new API to enable that?

The problem IMO is that this makes the whole thing less transparent
than using feature flags in the rendering code. OTOH if people can
implement it themselves (and add the corresponding info to
RequestProgressTracker) for transparency, I don't mind.

-Bertrand

Re: [tooling] Moving forward with IDE tooling

[Ruben Reusser]

I was trying to dumb down the example with 'content', however, in the CQ 
world there are a couple of areas where the tool comes with an editor 
for certain functionalities, for example workflows. While I can manage 
them in XML, it would be much nicer to manage them in CQ (or in the IDE, 
maybe through a hook that allows me to manage them in the repository and 
then at save bring the generated structure back to the IDE).


Also, editing the XML's in an IDE has a couple of shortcomings due to 
the fact that the XML structure currently used is very finicky and does 
not allow for a DTD for example. This makes it IMHO pretty hard to 
manage the structures in an IDE. (for example, list of child nodes has 
to be at the end of the .content.xml file, can't be in the beginning and 
the xml tag names are used to drive the node names in the repository, 
not allowing a clear validation of the options).


Ruben

On 6/2/2013 9:33 AM, Dominik Süß wrote:

I'm trying to summarize my thoughts including the several opinions
scenarios stated:
a) The main usecase seems to be development from IDE (persisted to FS and
therefore to be integreated with any FS based versioning tool of choice)
b) a  (on save) sync the application from FS to Sling via IDE seems what
everybody needs and agrees on
c) Not directly mentioned but what I think should be defined as well how
and when bundlebased (JAVA) code gets synced to the repository
d) where I didn't hear consensus is about syncing from Sling to FS. The
reason why I have my problem with that,  is that autosync needs an explicit
definition how structures get mapped. In direction repository this is easy
since this unwraps the filebased (xml or json) wrappers and creates a lot
of finegrained strucures, but the other way around there would be the need
of an implicit way how those structures get serialized to the FS or some
(potentially) complex definition that a dev would have to make (possible
with vault afaik, but IMHO errorprone).
e) one of the main reasons for d is to see changes from the repository
within the IDE. I here fully second Carsten that this shouldn't be
automagically resolved but be controlled from the dev.  The IDE here can
create some tooling to identify and display changes and support the job to
reestablish synchronity (this might be the hardest part for the tooling
since I  havent seen a proper ui doing such a job).
f) regarding sample content mentioned by Ruben I think some
packagingmechanism and a maven task to upload/download this package should
besufficient (lock package, upload, change content in repo, download
package, check in vcs)

Cheers
Dominik


On Sun, Jun 2, 2013 at 4:33 PM, Ruben Reusser r...@headwire.com wrote:


we frequently have a content project during development with a sample site
that can be deployed over maven to a local dev instance. Maintaining the
sample content in the project requires to author in the cms and then sync
back to file system. Making bulk changes to the structure (for example,
globally rename a sling:resourceSuperType) is easier done in the IDE.
Content is then pushed back into the repository. I am not saying a constant
sync is needed, but a way for the IDE to 'update from repository' would
really help.

The vlt sync command has another issue. Since it stores its state in the
local file system but relies on the server to manage the files your server
instance and file system can get out of sync (say your server crashes and
you have to reinstall it). Switching instances (say current version vs new
version) for testing purposes (is everything still working fine) is not
well supported either.

Ruben


On 6/2/2013 6:35 AM, Antonio Sanso wrote:


On Jun 2, 2013, at 10:41 AM, Carsten Ziegeler wrote:

  I think a sync in both directions is problematic and I wouldn't go there

-
but I know that there only a few having this opinion.
In my opinion, when I'm talking about a developer that's someone who
develops code including scripts and usually Java - this might also
include
coding in client side stuff like js and css. There is the central tool
you
use for developing and that's the IDE with a strong integration into the
SCM (svn, git etc). The dev never has to leave this IDE for anything. In
this scenario, there is only a sync from IDE to Sling required - but not
the other way round.


+1

  Whenever that's needed (syncing data from Sling into the file system)

this
should imho be an explicit decision by the dev - simply by invoking an
action from the IDE.


+1

Regards

Antonio


  An automatic sync in both directions is dangerous and

imho in most cases not wanted/desired/required.

As soon as we're talking about automatic sync from Sling to the project
checkout, this has a different style of development in mind - which I
think
we should not support when talking about IDE support. Either we support
IDE
development and then we do it right and have a style of working that does
not require to leave the IDE - or we do something different

Re: [tooling] Moving forward with IDE tooling

[Ruben Reusser]

I think the use case of doing maven/jenkins builds and continuous 
integrations should also be considered here. Most CQ projects at this 
time seem to be using maven builds that create packages that can be 
deployed to CQ. Since VLT is open sourced and since the packaging part 
is also in VLT I'd expect that to be open sourced as well. vlt sync 
would actually work if it did manage the .content.xml files as well 
(didn't it do that in the beginning - seems that feature was removed?) 
allowing developers to change their code either in the ide or crxde|lite 
and having the code sync'd to the file system for checkin and separate 
builds for CI. Breaking this experience may be a big problem.


Ruben

On 5/31/2013 7:27 AM, Dominik Süß wrote:

One problematic part about serialisation is structuredepth. In development
you might not want to handle complex structures by shifting folders around,
so it would be nice to have a format that allows to define a substructure,
so in the Sling Initialcontent you might even define one big JSON that
defines the complete structure. The consequence of that if you also need to
be able to export changes to the filesystem it isn't clear when things
should be handled within a file, and when to break up in folderstructures.

In vault this is implicitly solved for specific nodetypes. E.g. in cq a
dialog always gets exportet to a specific xml file covering this explicit
substrutcture in one aggregated file. But still even in vault you can have
situations where you define substructures in the .content.xml which leads
to an instant asynchronity with the repository since vault tries to synch
that as folder/file structure.

I currently have no idea for good solution, but in any case these problems
should be solved.

Dominik


On Fri, May 31, 2013 at 3:19 PM, Robert Munteanu romb...@apache.org wrote:


On Fri, 2013-05-31 at 21:14 +0900, Carsten Ziegeler wrote:

Some time ago I thought about this and had the following idea:
- we define a packaging for resources - this can be used to represent the
resources in the file system or in a zip file
- if a resource is a file, it is represented as a file with the same name
- if a resource is not a file, it is represented as a directory
- properties if a non-file resource, and all additional metadata of a

file

is stored in a [content].xml (or json)

Good point, added
https://cwiki.apache.org/confluence/display/SLING/Sling+IDE
+tooling#SlingIDEtooling-Resourceserializationformat to capture the
proposal / points to discuss.

Robert


This would allow browsing through the file system to the resource you

want

to edit and just edit the properties of this resource in a file. It makes
syncing very easy and fast.

Maybe we can distinguish between a resource which might have child nodes
and one that doesn't and make the mapping differently.

In any case the whole mechanism needs some research, a disadvantage might
be if you map a huge resource tree which has no files at all to the file
system, this will result in a huge directory tree instead of one large
content.xml - however as we're talking about developer tooling, we can
neglect this.

Just a rough idea

Carsten


2013/5/31 Robert Munteanu romb...@apache.org


On Thu, 2013-05-30 at 20:48 -0700, Ruben Reusser wrote:

is the vlt sync now actually updating .content.xml files? I thought

it

can only sync regular files.

I'm frankly more of an IDE guy than a VLT guy from a development
experience point of view.

However, I think that the IDE is the right place for the change
detection/sync capabilities, while VLT will be a mechanism from
transporting changes from/to the repository.

Robert

Re: [tooling] Moving forward with IDE tooling

[Ruben Reusser]

is the vlt sync now actually updating .content.xml files? I thought it 
can only sync regular files.


Ruben

On 5/30/2013 7:24 PM, Justin Edelson wrote:

Ian - please do add the autosync use case to the wiki page I created.


On Thu, May 30, 2013 at 9:47 PM, Ian Boston i...@tfd.co.uk wrote:


Hi,
+1 to that. After working on sling for many years doing a mixture of bundle
and UI work, mainly using the FileSystemResolver bundle, I realise now if
VLT had been available with sync mode (ie auto syncing the repo and the
file system), we (the team I was working with at the time) would have made
much more rapid progress. UI dev work needs file-save-refresh. The in
browser editing UIs deliver this, as does VLT in sync mode, but
unfortunately native eclipse based tooling is just too slow (on my machine,
might be my machine). Using VLT since I joined Adobe, has been a joy, and I
am very glad to know its being donated to the ASF.

Had we had VLT then, we would have developed in a very different way, and
might not have had half the problems we had with tooling and team
structure.
Ian


On 31 May 2013 10:16, Justin Edelson jus...@justinedelson.com wrote:


Hi,
I would strongly suggest that this effort be based on VLT. As mentioned

on

the wiki page, we're in the process of moving that to ASF and I think

once

the code is available, it will be clear that it provides a good low-level
interface for this type of UI.

While it is true that VLT currently only works with DavEX servers, I
suspect it would not be hard to isolate the Ex bits and have a WebDAV
only driver which could be used on non-JCR applications for basic file
operations.

My concern is that we end up building one more abstraction which is going
to sit on top of all the other abstractions (VLT, Dav(Ex), JCR, MK,

etc.).

I know VLT has some baggage, but I'd just ask that people keep an open
mind.

Separately, I'm going to start a child page of this wiki page to gather

use

cases. There are some functional areas listed on the main page, but I

think

we should try to capture individual use cases.

Regards,
Justin


On Thu, May 30, 2013 at 10:48 AM, Robert Munteanu romb...@apache.org

wrote:
Hi,

Following Antonio's kick-start of the Sling developer tooling [1] I've
gathered some thoughts about the initial goals and implementation of

our

Sling IDE tooling.

The document is at [2] so please have a look and let me know what your
thoughts are. I intend to take a pass at the code next week and align

it

to the proposed structure, as a foundation for feature work.

Robert

[1]: https://cwiki.apache.org/SLING/slingclipse.html
[2]:

https://cwiki.apache.org/confluence/display/SLING/Sling+IDE+tooling

not able to run standalone jar file (6) from download site

[Ruben Reusser]

hi,

I downloaded the sling standalone jar file from the website and tried to 
run it with java 7. I also dropped down to Java 6, that makes everything 
work fine - not sure if this is a known issue or if I should file a defect.


Ruben

( http://sling.apache.org/downloads.cgi )
java -jar org.apache.sling.launchpad-6-standalone.jar start
26.03.2013 15:09:01.453 *INFO* [main] Setting sling.home=sling (default)
26.03.2013 15:09:01.454 *INFO* [Sling Control 
Listener@hw8win/192.168.56.1:63000] Sling Control Server started
26.03.2013 15:09:01.454 *INFO* [main] Starting Sling in sling 
(C:\projects\sling\sling)

26.03.2013 15:09:01.462 *INFO* [main] Checking launcher JAR in folder sling
26.03.2013 15:09:01.470 *INFO* [main] Installing new launcher: 
jar:file:/C:/projects/sling/org.apache.sling.launchpad-6-standalone.jar!/resources/org.apache.sli
ng.launchpad.base.jar, 2.3.0 
(org.apache.sling.launchpad.base.jar.1364335741470)
26.03.2013 15:09:01.472 *INFO* [main] Loading launcher class 
org.apache.sling.launchpad.base.app.MainDelegate from 
org.apache.sling.launchpad.base.jar.136433574

1470
26.03.2013 15:09:01.486 *INFO* [main] Starting launcher ...
26.03.2013 15:09:01.488 *INFO* [main] HTTP server port: 8080
26.03.2013 15:09:01.541 *ERROR* [main] Failed to Start OSGi framework
org.osgi.framework.BundleException: Uncaught Instantiation Issue: 
java.lang.ArrayIndexOutOfBoundsException: -1
at 
org.apache.sling.launchpad.base.impl.Sling.init(Sling.java:245)
at 
org.apache.sling.launchpad.base.app.MainDelegate$1.init(MainDelegate.java:159)
at 
org.apache.sling.launchpad.base.app.MainDelegate.start(MainDelegate.java:159)

at org.apache.sling.launchpad.app.Main.startSling(Main.java:244)
at org.apache.sling.launchpad.app.Main.init(Main.java:107)
at org.apache.sling.launchpad.app.Main.main(Main.java:56)
Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.elementData(Unknown Source)
at java.util.ArrayList.get(Unknown Source)
at 
org.apache.felix.framework.BundleImpl.getCurrentModule(BundleImpl.java:1046)
at 
org.apache.felix.framework.BundleImpl.getSymbolicName(BundleImpl.java:863)
at 
org.apache.sling.launchpad.base.impl.SlingFelix.getSymbolicName(SlingFelix.java:32)

at org.apache.felix.framework.Felix.toString(Felix.java:1012)
at org.apache.felix.framework.Logger.doLog(Logger.java:128)
at org.apache.felix.framework.Logger._log(Logger.java:181)
at org.apache.felix.framework.Logger.log(Logger.java:114)
at 
org.apache.felix.framework.ExtensionManager.init(ExtensionManager.java:201)

at org.apache.felix.framework.Felix.init(Felix.java:374)
at 
org.apache.sling.launchpad.base.impl.SlingFelix.init(SlingFelix.java:39)
at 
org.apache.sling.launchpad.base.impl.Sling.init(Sling.java:235)

... 5 more
26.03.2013 15:09:01.591 *ERROR* [main] There was a problem launching Sling
26.03.2013 15:09:01.596 *INFO* [Sling Terminator] Java VM is shutting down

Re: TenantManager API

[Ruben Reusser]

i was wondering if tenants should work differently and be more transparent to 
the user by allowing to swotch the osgi properties per tenant. this would allow 
for a more transparent implementation without forcing the developer to think 
about tenants that much.

Ruben

On Feb 21, 2013, at 2:14 AM, Felix Meschberger fmesc...@adobe.com wrote:

 Hi
 
 SLING-2710 [1] proposes the addition of a TenantManager service interface. 
 Thanks for the comments so far.
 
 One question that came up in the issue is whether the TenantManager should 
 extend the TenantProvider or not.
 
 I am a bit undecided: On the one hand I think that the TenantManager is not a 
 TenantProvider. Also by not extending the TenantProvider the implementation 
 has more freedom and it forces proper access to the service.
 
 On the other hand, for administrative tools really using the TenantManager 
 having it extend the TenantProvider might make the code simpler (only one 
 service to get instead of two).
 
 WDYT ?
 
 Regards
 Felix
 
 [1] https://issues.apache.org/jira/browse/SLING-2710

Re: current standalone sling jar file

[Ruben Reusser]

used the link from here: http://sling.apache.org/site/downloads.cgi
running on windows vista with jdk6

Ruben

On 8/31/2012 3:19 AM, Bertrand Delacretaz wrote:

On Fri, Aug 31, 2012 at 1:13 AM, Ruben Reusser r...@headwire.com wrote:

...is the current downloadable standalone sling
version still working?...

Not sure what you mean by downloadeable, URL?

The build at https://builds.apache.org/job/sling-trunk-1.6/ uses the
standalone launchpad jar and the tests currently pass, a few recent
builds failed but it looks more like jenkins issues.

-Bertrand

Re: current standalone sling jar file

[Ruben Reusser]

ok, was finally able to start the one from an svn build - just had to 
give it way more memory


Ruben

On 8/31/2012 12:47 AM, Carsten Ziegeler wrote:

Hi,

I just build latest from trunk and works for me

Carsten

2012/8/31 Ruben Reusser r...@headwire.com:

hi,

not sure if it's me - but if the current downloadable standalone sling
version still working? Tried to run it and sling did not come up - also,
when I do a build from the trunk and try to start the standalone jar file, I
get a whole bunch of exceptions about missing dependencies.

Ruben

current standalone sling jar file

[Ruben Reusser]

hi,

not sure if it's me - but if the current downloadable standalone sling 
version still working? Tried to run it and sling did not come up - also, 
when I do a build from the trunk and try to start the standalone jar 
file, I get a whole bunch of exceptions about missing dependencies.


Ruben

Re: Sling Site and CMS

[Ruben Reusser]

also, it seems like the tutorials section is not working due to the URL

http://sling.staging.apache.org/tutorials--how-tos.html

Ruben

On 5/21/2012 5:05 AM, Bertrand Delacretaz wrote:

Hi Felix,

On Sun, May 20, 2012 at 1:09 AM, Felix Meschbergerfmesc...@adobe.com  wrote:

...Granted we have a few open issues like the confluence to markdown conversion 
mangling with the {{}} constructs...
...The rest we can fix over time...

There's still a number of pages where tables and lists are broken and
make the content in unusable in large part:

http://sling.staging.apache.org/dispatching-requests.html
http://sling.staging.apache.org/mappings-for-resource-resolution.html
http://sling.staging.apache.org/bundles.html (no links)
http://sling.staging.apache.org/news.html

I think we should fix those before switching...unfortunately I'm
unable to help right now.
-Bertrand

Re: [JSON] Stable Child Resource Order

[Ruben Reusser]

you can just add a feed.json.jsp file and use {resourcename}.feed.json 
to render your custom output


HTH

Ruben

On 4/7/2011 12:47 PM, Eric Norman wrote:

Is there any reason why you can't just make a custom script to output
whatever JSON format you want?  I'm not convinced this has usefulness
outside your use case that would warrant changing the generic format.


On Thu, Apr 7, 2011 at 10:26 AM, Tobias Bocanegratri...@adobe.com  wrote:


thanks felix,
i think we go the same way here - maybe it was not so clear from my wording
:-)
all i'm saying is: sling uses a JSON like format to present a resource
tree which can cause problems for JSON/ECMA compliant clients that
don't implement stable child object ordering. as mentioned by [3] this
is very unfortunate that ECMA script engines don't do that.
such clients currently can't re-use the existing JSON-Object decoder
and need to implement it themselves.


Maybe we could just use a regular illegal property name like
:child-node-order or :sling:child-node-order instead of a single

character
sling is all about resources - not nodes, right :-) so i'd rather go for:

:child-resource-names or a shorter :child-names

regards, toby

[3] http://old.nabble.com/iteration-order-for-Object-td31120998.html

On Thu, Apr 7, 2011 at 4:31 AM, Felix Meschbergerfmesc...@adobe.com
wrote:

Hi,

Am Donnerstag, den 07.04.2011, 12:22 +0100 schrieb Alexander
Klimetschek:

On 07.04.11 09:17, Felix Meschbergerfmesc...@adobe.com  wrote:

the special array * would contain the names of the child resources
in the order provided by the resource resolver.

Maybe we could just use a regular illegal property name like
:child-node-order or :sling:child-node-order instead of a single
character.

What about using :order?

The problem is that :order already is used by the Sling POST Servlet
to define the order of newly inserted nodes...

While I don't think we are walking into a collision here in the near
future, I would like to either not use that name or correlate an
potential update of Sling POST Servlet's use of the parameter, e.g. to
define/update the order of nodes 


And the selector would be order as well (e.g.

foo.order.infinity.json).

sounds reasonable to me.

Regards
Felix