[jira] [Resolved] (SLING-6220) [log] Perform initial configuration from framework properties synchronously

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra resolved SLING-6220.

Resolution: Fixed

Applied slightly modified patch with r1767821

> [log] Perform initial configuration from framework properties synchronously
> ---
>
> Key: SLING-6220
> URL: https://issues.apache.org/jira/browse/SLING-6220
> Project: Sling
>  Issue Type: Improvement
>  Components: Commons
>Reporter: Felix Meschberger
>Assignee: Chetan Mehrotra
> Fix For: Commons Log 5.0.2
>
>
> {{LogbackManager}} uses {{LogConfigManager}} to support traditional logging 
> configuration including initial (global) configuration from framework 
> properties. Once everything is setup the {{LogbackManager.configChanged()}} 
> method is called to initiate logging for the first time.
> Unfortunately {{configChanged}} is processed asynchronously leading to 
> initial configuration to be applied only later - in some special use cases 
> even *after* the complete application has already started.
> I proposed to replace the call to {{configChanged()}} by a call to 
> {{configure()}} which actually implements the configuration change *before* 
> the {{started}} flag is set to {{true}}.
> Proposed patch:
> {code}
> Index: 
> src/main/java/org/apache/sling/commons/log/logback/internal/LogbackManager.java
> ===
> --- 
> src/main/java/org/apache/sling/commons/log/logback/internal/LogbackManager.java
>(Revision 1767024)
> +++ 
> src/main/java/org/apache/sling/commons/log/logback/internal/LogbackManager.java
>(Arbeitskopie)
> @@ -167,8 +167,13 @@
>  registerWebConsoleSupport();
>  registerEventHandler();
>  
> +// initial configuration must be done synchronously (aka immediately)
> +addInfo("LogbackManager: BEGIN initial configuration");
> +configure();
> +addInfo("LogbackManager: END initialconfiguration");
> +
> +// now open the gate for regular configuration
>  started = true;
> -configChanged();
>  }
>  
>  public void shutdown() {
> {code}



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

Re: [VOTE] Release Apache Sling Web Console Security Provider 1.2.0

[Justin Edelson]

+1

On Wed, Nov 2, 2016 at 12:43 PM Carsten Ziegeler 
wrote:

> +1
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>
>

[RESULT] [VOTE] Release Apache Sling Model API 1.3.0, Implementation 1.3.0, and Jackson Exporter 1.0.0

[Justin Edelson]

This vote has passed with the following result:

+1 (binding): Justin Edelson, Carsten Ziegeler, Stefan Egli, Daniel Klco,
Stefan Seifert

I will copy this release to the Sling dist directory and promote the
artifacts to the central Maven repository and, to Stefan S.'s point below,
work on updating the documentation.

On Mon, Oct 31, 2016 at 7:47 PM Stefan Seifert 
wrote:

> +1
>
> we need to document the new features from SLING-5992 and SLING-6183 in [1]
>
> stefan
>
> [1] http://sling.apache.org/documentation/bundles/models.html
>
>
>
> >-Original Message-
> >From: Justin Edelson [mailto:jus...@justinedelson.com]
> >Sent: Monday, October 31, 2016 12:55 AM
> >To: dev@sling.apache.org
> >Subject: [VOTE] Release Apache Sling Model API 1.3.0, Implementation
> 1.3.0,
> >and Jackson Exporter 1.0.0
> >
> >Hi,
> >
> >We solved 4 issue in this release:
> >
> >https://issues.apache.org/jira/browse/SLING/fixforversion/12338158
> >https://issues.apache.org/jira/browse/SLING/fixforversion/12338159
> >https://issues.apache.org/jira/browse/SLING/fixforversion/12338620
> >
> >Staging repository:
> >https://repository.apache.org/content/repositories/orgapachesling-1556/
> >
> >You can use this UNIX script to download the release and verify the
> >signatures:
> >http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
> >
> >Usage:
> >sh check_staged_release.sh 1556 /tmp/sling-staging
> >
> >Please vote to approve this release:
> >[ ] +1 Approve the release
> >[ ]  0 Don't care
> >[ ] -1 Don't release, because ...
> >
> >This vote will be open for 72 hours.
>

Re: Sling Eclipse IDE Release?

[Konrad Windszus]

Hi Robert

> Am 02.11.2016 um 14:34 schrieb Robert Munteanu :
> 
> Hi Konrad,
> 
>> On Wed, 2016-11-02 at 11:25 +0100, Konrad Windszus wrote:
>> Unfortunately the current version of Sling Eclipse IDE is not
>> compatible with the newest maven-bundle-plugin 3.2.0 with the new m2e
>> lifecycle mapping for the manifest goal (set up like described in
>> http://felix.apache.org/documentation/faqs/apache-felix-bundle-
>> plugin-faq.html#use-scr-metadata-generated-by-bnd-in-unit-tests). I
>> fixed that with https://issues.apache.org/jira/browse/SLING-6112 by
>> making m2e-tycho no longer a requirement. 
> 
> I would suggest making this 1.2.0 . With the contributions that you
> made it's definitely not a bugfix release :-)
> 
Ok, let's call it 1.2.0. I will adjust in JIRA tomorrow.
>> 
>> Apart from that 11 other issues have been resolved (https://issues.ap
>> ache.org/jira/browse/SLING-
>> 5634?jql=project%20%3D%20SLING%20AND%20status%20%3D%20Resolved%20AND%
>> 20fixVersion%20%3D%20%22Sling%20Eclipse%20IDE%201.1.2%22%20ORDER%20BY
>> %20priority%20DESC).
>> 
>> I would therefore like to have a new release from Sling IDE within
>> the next weeks.
>> Is there anything important missing from the unresolved issues
>> supposably fixed with Sling Eclipse IDE 1.1.2 (https://issues.apache.
>> org/jira/browse/SLING-
>> 4455?jql=fixVersion%20%3D%20%22Sling%20Eclipse%20IDE%201.1.2%22%20AND
>> %20project%20%3D%20SLING%20AND%20resolution%20%3D%20Unresolved%20ORDE
>> R%20BY%20priority%20DESC)?
> 
> I just filed
> 
> https://issues.apache.org/jira/browse/SLING-6231
> 
> regarding the unstable Sightly editor tests. Not sure if I will manage
> to fix them, but it would be good to.
> 
> I am also writing some tests for 
> 
>  https://issues.apache.org/jira/browse/SLING-6112
> 
> to make sure the proper markers are attached.
> 
Great, thanks a lot.
> Other than that, I have an upstream bug report from the AEM Developer
> Tools
> 
>  https://github.com/Adobe-Marketing-Cloud/aem-eclipse-developer-tools/
> issues/72
> 
> which is probably related to code in the Sling IDE Tooling, but I have
> not yet managed to reproduce it :-( If you have seen this or have more
> information about how this could be reproduced I'd really like this
> fixed for the next release.

I have seen this issue only once, but did not yet find a reliable way to 
reproduce it. Also I have seen one other issue were hiding the servlet 
descriptor entry point in the package explorer was not hidden. Have not yet 
found a way to reproduce either. Will look into both issues tomorrow. 

One last thing is around xml validation. Seems that this is fully disabled for 
sling-content facet. what was the reason to disable that and where in the code 
does that happen. I would like to have that validator rather enabled and just 
disable the warning related to the missing schema. Can you give a hint on that 
one?
> 
> Thanks,
> 
> Robert

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

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-6112 at 11/2/16 5:40 PM:
-

1. Agreed and committed with [r1767717|https://svn.apache.org/r1767717].
2. Makes sense. We should probably only provide two quickfixes then: a) install 
m2e-tycho, b) configure plugins accordingly. For b) we should only link to that 
wiki page. I will create an according paragraph in the troubleshooting section 
(https://sling.apache.org/documentation/development/ide-tooling.html#troubleshooting)
 which explains usage with {{maven-bundle-plugin}} (prior 3.2.0 and since 
3.2.0) and {{maven-bnd-plugin}}.


was (Author: kwin):
1. Agreed and committed with [r1767717|https://svn.apache.org/r1767717].
2. Makes sense. We should probably only provide two quickfixes then: a) install 
m2e-tycho, b) configure plugins accordingly. For b) we should only link to that 
wiki page. I will create an according paragraph in the troubleshooting section 
(https://sling.apache.org/documentation/development/ide-tooling.html#troubleshooting)
 which explains usage with `maven-bundle-plugin` (prior 3.2.0 and since 3.2.0) 
and `maven-bnd-plugin`.

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



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

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

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-6112 at 11/2/16 5:39 PM:
-

1. Agreed and committed with [r1767717|https://svn.apache.org/r1767717].
2. Makes sense. We should probably only provide two quickfixes then: a) install 
m2e-tycho, b) configure plugins accordingly. For b) we should only link to that 
wiki page. I will create an according paragraph in the troubleshooting section 
(https://sling.apache.org/documentation/development/ide-tooling.html#troubleshooting)
 which explains usage with `maven-bundle-plugin` (prior 3.2.0 and since 3.2.0) 
and `maven-bnd-plugin`.


was (Author: kwin):
1. Agreed and committed with [r1767717|htps://svn.apache.org/r1767717].
2. Makes sense. We should probably only provide two quickfixes then: a) install 
m2e-tycho, b) configure plugins accordingly. For b) we should only link to that 
dedicated subpage explaining how that works for maven-bundle-plugin and 
bnd-maven-plugin (with according links). I will create an according paragraph 
in the troubleshooting section 
(https://sling.apache.org/documentation/development/ide-tooling.html#troubleshooting).

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



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

[jira] [Created] (SLING-6235) Integrate slingshot sample

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-6235:
---

 Summary: Integrate slingshot sample
 Key: SLING-6235
 URL: https://issues.apache.org/jira/browse/SLING-6235
 Project: Sling
  Issue Type: Sub-task
  Components: Launchpad
Reporter: Carsten Ziegeler
 Fix For: Launchpad Builder 9






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

Re: [VOTE] Release Apache Sling Web Console Security Provider 1.2.0

[Carsten Ziegeler]

+1

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

[VOTE] Release Apache Sling Web Console Security Provider 1.2.0

[Carsten Ziegeler]

Hi,

We solved 1 issue in this release:
https://issues.apache.org/jira/browse/SLING-6234

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

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

Usage:
sh check_staged_release.sh 1560 /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
Carsten
-- 
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org

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

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6112:


1. Agreed and committed with [r1767717|htps://svn.apache.org/r1767717].
2. Makes sense. We should probably only provide two quickfixes then: a) install 
m2e-tycho, b) configure plugins accordingly. For b) we should only link to that 
dedicated subpage explaining how that works for maven-bundle-plugin and 
bnd-maven-plugin (with according links). I will create an according paragraph 
in the troubleshooting section 
(https://sling.apache.org/documentation/development/ide-tooling.html#troubleshooting).

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



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

[jira] [Resolved] (SLING-6234) Web Console Security Provider should supprt logout

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-6234.
-
Resolution: Fixed

Implemented in rev 1767718, also updated to latest parent pom

> Web Console Security Provider should supprt logout
> --
>
> Key: SLING-6234
> URL: https://issues.apache.org/jira/browse/SLING-6234
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Web Console Security Provider 1.1.8
>
>
> The web console security provider is using Sling's authenticator for 
> authentication, it should also support using it for logging out.
> Otherwise the web console tries to do a generic logout which doesn't really 
> work.



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

[jira] [Created] (SLING-6234) Web Console Security Provider should supprt logout

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-6234:
---

 Summary: Web Console Security Provider should supprt logout
 Key: SLING-6234
 URL: https://issues.apache.org/jira/browse/SLING-6234
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Web Console Security Provider 1.1.8


The web console security provider is using Sling's authenticator for 
authentication, it should also support using it for logging out.
Otherwise the web console tries to do a generic logout which doesn't really 
work.



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

[jira] [Resolved] (SLING-4003) Investigate compatibility with m2eclipse-tycho 0.7.0 or newer

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-4003.

   Resolution: Won't Fix
Fix Version/s: (was: Sling Eclipse IDE 1.1.2)

Agreed, making this a WONTFIX

> Investigate compatibility with m2eclipse-tycho 0.7.0 or newer
> -
>
> Key: SLING-4003
> URL: https://issues.apache.org/jira/browse/SLING-4003
> Project: Sling
>  Issue Type: Task
>  Components: IDE
>Reporter: Robert Munteanu
>Priority: Minor
>
> With commit 
> [85cd048f|https://github.com/tesla/m2eclipse-tycho/commit/85cd048ffcd47020992bdec2cd44f1a4945173bf]
>  m2eclipse-tycho will no longer regenerate the bundle's manifest on each 
> change. This will result in improved performance. 
> However, it might also mean that when a new SCR component is added the 
> manifest's Service-Component will not get updated with the location of the 
> newly generated descriptor files.



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

Re: Build failed in Jenkins: sling-ide #71

[Robert Munteanu]

On Wed, 2016-11-02 at 15:21 +, Apache Jenkins Server wrote:
> Caused by: java.lang.UnsupportedClassVersionError:
> org/eclipse/tycho/core/maven/TychoMavenLifecycleParticipant :
> Unsupported major.minor version 52.0
>   at java.lang.ClassLoader.defineClass1(Native Method)
>   at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
>   at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:14
> 2)
>   at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
>   at java.net.URLClassLoader.access$100(URLClassLoader.java:71)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
>   at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
>   at java.security.AccessController.doPrivileged(Native Method)
>   at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
>   at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClassFromSelf(Cl
> assRealm.java:401)
>   at
> org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(
> SelfFirstStrategy.java:42)
>   at
> org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadCl
> ass(ClassRealm.java:271)
>   at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm
> .java:247)
>   at
> org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm
> .java:239)
>   at
> org.eclipse.sisu.space.URLClassSpace.loadClass(URLClassSpace.java:139
> )
>   ... 49 more
> 

Hmmm, I was a bit eager in upgrading the Tycho version. Still running
on Java 7, so reverted the changes in r1767706 .

Robert

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

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-6112:


I've added an integration test for the error marker ( 
[https://svn.apache.org/r1767696|r1767696], 
[https://svn.apache.org/r1767697|1767697], 
[https://svn.apache.org/r1767698|1767698], 
[https://svn.apache.org/r1767700|1767700] ).

I like the way the quick fixes present the option and the documentation links. 
The only thing I'd tweak a bit is how we present the information to the user.

# when the error is presented, it's not immediately discoverable ( at least to 
me ) that quick fixes are present. Could we maybe add an instruction to launch 
the quick fix?
# I think we may want to add more information in the future to the 'quick 
fixes' that actually instruct the user to make a manual change. I think we 
should like to a documentation page where the issues are explained in more 
detail, together with the references you put up. Not sure if these should be 
the main IDE tooling page or a sub-page created especially for troubleshooting

[~kwin] - WDYT?

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



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

[jira] [Commented] (SLING-6233) Allow configuration of fallback properties for inheritance

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6233:
-

Implemented in rev 1767703, [~sseif...@pro-vision.de] WDYT?

> Allow configuration of fallback properties for inheritance
> --
>
> Key: SLING-6233
> URL: https://issues.apache.org/jira/browse/SLING-6233
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Context-Aware Configuration Impl 1.0.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Context-Aware Configuration Impl 1.0.2
>
>
> The DefaultConfigurationResourceResolvingStrategy is currently using the 
> properties sling:configCollectionInherit and sling:configPropertyInherit for 
> inheritance handling.
> We could make this a little bit more flexible to allow additional property 
> names (similar to SLING-6229). The first property providing a value is used, 
> starting with the above names



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

[jira] [Resolved] (SLING-6231) Sightly SWTBot tests are unstable

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-6231.

Resolution: Fixed

> Sightly SWTBot tests are unstable
> -
>
> Key: SLING-6231
> URL: https://issues.apache.org/jira/browse/SLING-6231
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Sling Eclipse IDE 1.1.2
>
> Attachments: sightly-tests-unstable.jpg
>
>
> The Sightly UI tests fail often on Jenkins but also locally. There seems to 
> be some kind of timing issue involved.
> The failure is the following:
> {noformat}org.eclipse.swtbot.swt.finder.exceptions.WidgetNotFoundException: 
> Could not find widget matching: (of type 'Tree')
>   at 
> org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntil(SWTBotFactory.java:437)
>   at 
> org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntil(SWTBotFactory.java:411)
>   at 
> org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntil(SWTBotFactory.java:399)
>   at 
> org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntilWidgetAppears(SWTBotFactory.java:381)
>   at 
> org.eclipse.swtbot.swt.finder.SWTBotFactory.widget(SWTBotFactory.java:334)
>   at org.eclipse.swtbot.swt.finder.SWTBot.tree(SWTBot.java:1283)
>   at org.eclipse.swtbot.swt.finder.SWTBot.tree(SWTBot.java:1272)
>   at 
> org.apache.sling.ide.test.impl.ui.sightly.SightlyAutocompletionTest$AutocompletionCallable.call(SightlyAutocompletionTest.java:110)
>   at 
> org.apache.sling.ide.test.impl.ui.sightly.SightlyAutocompletionTest.attributeAutocompletion(SightlyAutocompletionTest.java:81){noformat}



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

[jira] [Created] (SLING-6233) Allow configuration of fallback properties for inheritance

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-6233:
---

 Summary: Allow configuration of fallback properties for inheritance
 Key: SLING-6233
 URL: https://issues.apache.org/jira/browse/SLING-6233
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Context-Aware Configuration Impl 1.0.0
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Context-Aware Configuration Impl 1.0.2


The DefaultConfigurationResourceResolvingStrategy is currently using the 
properties sling:configCollectionInherit and sling:configPropertyInherit for 
inheritance handling.
We could make this a little bit more flexible to allow additional property 
names (similar to SLING-6229). The first property providing a value is used, 
starting with the above names



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

[jira] [Updated] (SLING-6231) Sightly SWTBot tests are unstable

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-6231:
---
Assignee: Robert Munteanu

> Sightly SWTBot tests are unstable
> -
>
> Key: SLING-6231
> URL: https://issues.apache.org/jira/browse/SLING-6231
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Sling Eclipse IDE 1.1.2
>
> Attachments: sightly-tests-unstable.jpg
>
>
> The Sightly UI tests fail often on Jenkins but also locally. There seems to 
> be some kind of timing issue involved.
> The failure is the following:
> {noformat}org.eclipse.swtbot.swt.finder.exceptions.WidgetNotFoundException: 
> Could not find widget matching: (of type 'Tree')
>   at 
> org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntil(SWTBotFactory.java:437)
>   at 
> org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntil(SWTBotFactory.java:411)
>   at 
> org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntil(SWTBotFactory.java:399)
>   at 
> org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntilWidgetAppears(SWTBotFactory.java:381)
>   at 
> org.eclipse.swtbot.swt.finder.SWTBotFactory.widget(SWTBotFactory.java:334)
>   at org.eclipse.swtbot.swt.finder.SWTBot.tree(SWTBot.java:1283)
>   at org.eclipse.swtbot.swt.finder.SWTBot.tree(SWTBot.java:1272)
>   at 
> org.apache.sling.ide.test.impl.ui.sightly.SightlyAutocompletionTest$AutocompletionCallable.call(SightlyAutocompletionTest.java:110)
>   at 
> org.apache.sling.ide.test.impl.ui.sightly.SightlyAutocompletionTest.attributeAutocompletion(SightlyAutocompletionTest.java:81){noformat}



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

[jira] [Commented] (SLING-6231) Sightly SWTBot tests are unstable

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-6231:


Fixed:

* [r1767701 |https://svn.apache.org/r1767701] - Use a specific bot instance 
instead of the global one
* [r1767702|https://svn.apache.org/r1767702] - replace hardcoded 1000 ms sleep 
with a polling condition

> Sightly SWTBot tests are unstable
> -
>
> Key: SLING-6231
> URL: https://issues.apache.org/jira/browse/SLING-6231
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
> Fix For: Sling Eclipse IDE 1.1.2
>
> Attachments: sightly-tests-unstable.jpg
>
>
> The Sightly UI tests fail often on Jenkins but also locally. There seems to 
> be some kind of timing issue involved.
> The failure is the following:
> {noformat}org.eclipse.swtbot.swt.finder.exceptions.WidgetNotFoundException: 
> Could not find widget matching: (of type 'Tree')
>   at 
> org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntil(SWTBotFactory.java:437)
>   at 
> org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntil(SWTBotFactory.java:411)
>   at 
> org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntil(SWTBotFactory.java:399)
>   at 
> org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntilWidgetAppears(SWTBotFactory.java:381)
>   at 
> org.eclipse.swtbot.swt.finder.SWTBotFactory.widget(SWTBotFactory.java:334)
>   at org.eclipse.swtbot.swt.finder.SWTBot.tree(SWTBot.java:1283)
>   at org.eclipse.swtbot.swt.finder.SWTBot.tree(SWTBot.java:1272)
>   at 
> org.apache.sling.ide.test.impl.ui.sightly.SightlyAutocompletionTest$AutocompletionCallable.call(SightlyAutocompletionTest.java:110)
>   at 
> org.apache.sling.ide.test.impl.ui.sightly.SightlyAutocompletionTest.attributeAutocompletion(SightlyAutocompletionTest.java:81){noformat}



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

RE: [VOTE] Release Apache Sling MIME type mapping support 2.1.10

[Stefan Seifert]

+1

[jira] [Resolved] (SLING-6229) Allow configuration of fallback properties in DefaultContextPathStrategy

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-6229.
-
Resolution: Fixed

> Allow configuration of fallback properties in DefaultContextPathStrategy
> 
>
> Key: SLING-6229
> URL: https://issues.apache.org/jira/browse/SLING-6229
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Context-Aware Configuration Impl 1.0.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Context-Aware Configuration Impl 1.0.2
>
>
> Currently the DefaultContextPathStrategy only looks for the property 
> sling:configRef.
> If other properties should be looked for, e.g. for migration from Adobe's 
> confmgr, this can be done with an additional ContextPathStrategy - but this 
> has a performance drawback.
> We should allow to define additional property names which are used in the 
> order of appearance. Once a value for such a property is found, its value is 
> used and the others are not queried anymore. The  sling:configRef property is 
> always the first one used and does not need to be configured - which also 
> means it is not possible to deviate from this rule.



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

[jira] [Resolved] (SLING-6230) The SightlyCompiler reports errors and warnings with an offset by one for the line count

[Radu Cotescu (JIRA)]

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

Radu Cotescu resolved SLING-6230.
-
Resolution: Fixed

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

> The SightlyCompiler reports errors and warnings with an offset by one for the 
> line count
> 
>
> Key: SLING-6230
> URL: https://issues.apache.org/jira/browse/SLING-6230
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting HTL Compiler 1.0.2, HTL Maven Plugin 1.0.0
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
> Fix For: Scripting HTL Compiler 1.0.4, HTL Maven Plugin 1.0.4
>
>
> The {{SightlyCompiler}} reports errors and warnings with an offset by one for 
> the line count. Since the HTL Maven Plugin directly uses the compiler, this 
> means that the plugin is also affected.



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

[jira] [Commented] (SLING-6229) Allow configuration of fallback properties in DefaultContextPathStrategy

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6229:
---

ok

> Allow configuration of fallback properties in DefaultContextPathStrategy
> 
>
> Key: SLING-6229
> URL: https://issues.apache.org/jira/browse/SLING-6229
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Context-Aware Configuration Impl 1.0.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Context-Aware Configuration Impl 1.0.2
>
>
> Currently the DefaultContextPathStrategy only looks for the property 
> sling:configRef.
> If other properties should be looked for, e.g. for migration from Adobe's 
> confmgr, this can be done with an additional ContextPathStrategy - but this 
> has a performance drawback.
> We should allow to define additional property names which are used in the 
> order of appearance. Once a value for such a property is found, its value is 
> used and the others are not queried anymore. The  sling:configRef property is 
> always the first one used and does not need to be configured - which also 
> means it is not possible to deviate from this rule.



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

[jira] [Updated] (SLING-6232) Create JMX MBeans for SCD package builders

[Simone Tripodi (JIRA)]

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

Simone Tripodi updated SLING-6232:
--
Attachment: SLING-6232.patch

Hi there [~teofili],
please find in the attachments my first proposal to resolve that issue: it 
registers MBeans that keep data useful to be analysed for monitoring, taking 
care of not populate the JMX console with too many MBeans - there is a queue 
with a configurable capacity that remove top elements when are full, then 
un-register JMX beans.
A possible improvement I have in mind is enabling/disabling MBeans registration.
Just please let me know and I will modify the issue according to your feedbacks!

> Create JMX MBeans for SCD package builders
> --
>
> Key: SLING-6232
> URL: https://issues.apache.org/jira/browse/SLING-6232
> Project: Sling
>  Issue Type: Sub-task
>  Components: Distribution
>Reporter: Simone Tripodi
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
> Attachments: SLING-6232.patch
>
>
> Having statistics about size and creation, installation time (average, 90 
> percentile, max and min to start) would be very helpful in order to monitor 
> performance metrics.
> Also having an API to clear out the package space may be helpful.



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

[jira] [Updated] (SLING-6232) Create JMX MBeans for SCD package builders

[Simone Tripodi (JIRA)]

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

Simone Tripodi updated SLING-6232:
--
Description: 
Having statistics about size and creation, installation time (average, 90 
percentile, max and min to start) would be very helpful in order to monitor 
performance metrics.
Also having an API to clear out the package space may be helpful.

  was:JMX support is an important tool for checking and monitoring status of 
SCD agents, that should be added.


> Create JMX MBeans for SCD package builders
> --
>
> Key: SLING-6232
> URL: https://issues.apache.org/jira/browse/SLING-6232
> Project: Sling
>  Issue Type: Sub-task
>  Components: Distribution
>Reporter: Simone Tripodi
>Assignee: Tommaso Teofili
> Fix For: Content Distribution 0.2.0
>
>
> Having statistics about size and creation, installation time (average, 90 
> percentile, max and min to start) would be very helpful in order to monitor 
> performance metrics.
> Also having an API to clear out the package space may be helpful.



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

[jira] [Created] (SLING-6232) Create JMX MBeans for SCD package builders

[Simone Tripodi (JIRA)]

Simone Tripodi created SLING-6232:
-

 Summary: Create JMX MBeans for SCD package builders
 Key: SLING-6232
 URL: https://issues.apache.org/jira/browse/SLING-6232
 Project: Sling
  Issue Type: Sub-task
  Components: Distribution
Reporter: Simone Tripodi
Assignee: Tommaso Teofili
 Fix For: Content Distribution 0.2.0


JMX support is an important tool for checking and monitoring status of SCD 
agents, that should be added.



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

[jira] [Commented] (SLING-6229) Allow configuration of fallback properties in DefaultContextPathStrategy

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6229:
-

[~sseif...@pro-vision.de] Yes I thought about this, but then decided against it 
- I think that we said that all SPI stuff can only add logic, but not replace 
logic. Now, if we allow to remove sling:configRef from that configuration we're 
breaking that promise (ok, not really SPI here but similar)

> Allow configuration of fallback properties in DefaultContextPathStrategy
> 
>
> Key: SLING-6229
> URL: https://issues.apache.org/jira/browse/SLING-6229
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Context-Aware Configuration Impl 1.0.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Context-Aware Configuration Impl 1.0.2
>
>
> Currently the DefaultContextPathStrategy only looks for the property 
> sling:configRef.
> If other properties should be looked for, e.g. for migration from Adobe's 
> confmgr, this can be done with an additional ContextPathStrategy - but this 
> has a performance drawback.
> We should allow to define additional property names which are used in the 
> order of appearance. Once a value for such a property is found, its value is 
> used and the others are not queried anymore. The  sling:configRef property is 
> always the first one used and does not need to be configured - which also 
> means it is not possible to deviate from this rule.



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

Re: Sling Eclipse IDE Release?

[Robert Munteanu]

Hi Konrad,

On Wed, 2016-11-02 at 11:25 +0100, Konrad Windszus wrote:
> Unfortunately the current version of Sling Eclipse IDE is not
> compatible with the newest maven-bundle-plugin 3.2.0 with the new m2e
> lifecycle mapping for the manifest goal (set up like described in
> http://felix.apache.org/documentation/faqs/apache-felix-bundle-
> plugin-faq.html#use-scr-metadata-generated-by-bnd-in-unit-tests). I
> fixed that with https://issues.apache.org/jira/browse/SLING-6112 by
> making m2e-tycho no longer a requirement. 

I would suggest making this 1.2.0 . With the contributions that you
made it's definitely not a bugfix release :-)

> 
> Apart from that 11 other issues have been resolved (https://issues.ap
> ache.org/jira/browse/SLING-
> 5634?jql=project%20%3D%20SLING%20AND%20status%20%3D%20Resolved%20AND%
> 20fixVersion%20%3D%20%22Sling%20Eclipse%20IDE%201.1.2%22%20ORDER%20BY
> %20priority%20DESC).
> 
> I would therefore like to have a new release from Sling IDE within
> the next weeks.
> Is there anything important missing from the unresolved issues
> supposably fixed with Sling Eclipse IDE 1.1.2 (https://issues.apache.
> org/jira/browse/SLING-
> 4455?jql=fixVersion%20%3D%20%22Sling%20Eclipse%20IDE%201.1.2%22%20AND
> %20project%20%3D%20SLING%20AND%20resolution%20%3D%20Unresolved%20ORDE
> R%20BY%20priority%20DESC)?

I just filed

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

regarding the unstable Sightly editor tests. Not sure if I will manage
to fix them, but it would be good to.

I am also writing some tests for 

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

to make sure the proper markers are attached.

Other than that, I have an upstream bug report from the AEM Developer
Tools

  https://github.com/Adobe-Marketing-Cloud/aem-eclipse-developer-tools/
issues/72

which is probably related to code in the Sling IDE Tooling, but I have
not yet managed to reproduce it :-( If you have seen this or have more
information about how this could be reproduced I'd really like this
fixed for the next release.

Thanks,

Robert

Re: [VOTE] Release Apache Sling MIME type mapping support 2.1.10

[Justin Edelson]

+1

On Wed, Nov 2, 2016 at 8:23 AM Daniel Klco  wrote:

> +1
>
> On Wed, Nov 2, 2016 at 7:07 AM, Carsten Ziegeler 
> wrote:
>
> > +1
> >
> >
> >
> > --
> > Carsten Ziegeler
> > Adobe Research Switzerland
> > cziege...@apache.org
> >
> >
>

[jira] [Updated] (SLING-6231) Sightly SWTBot tests are unstable

[Robert Munteanu (JIRA)]

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

Robert Munteanu updated SLING-6231:
---
Attachment: sightly-tests-unstable.jpg

> Sightly SWTBot tests are unstable
> -
>
> Key: SLING-6231
> URL: https://issues.apache.org/jira/browse/SLING-6231
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Reporter: Robert Munteanu
> Fix For: Sling Eclipse IDE 1.1.2
>
> Attachments: sightly-tests-unstable.jpg
>
>
> The Sightly UI tests fail often on Jenkins but also locally. There seems to 
> be some kind of timing issue involved.
> The failure is the following:
> {noformat}org.eclipse.swtbot.swt.finder.exceptions.WidgetNotFoundException: 
> Could not find widget matching: (of type 'Tree')
>   at 
> org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntil(SWTBotFactory.java:437)
>   at 
> org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntil(SWTBotFactory.java:411)
>   at 
> org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntil(SWTBotFactory.java:399)
>   at 
> org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntilWidgetAppears(SWTBotFactory.java:381)
>   at 
> org.eclipse.swtbot.swt.finder.SWTBotFactory.widget(SWTBotFactory.java:334)
>   at org.eclipse.swtbot.swt.finder.SWTBot.tree(SWTBot.java:1283)
>   at org.eclipse.swtbot.swt.finder.SWTBot.tree(SWTBot.java:1272)
>   at 
> org.apache.sling.ide.test.impl.ui.sightly.SightlyAutocompletionTest$AutocompletionCallable.call(SightlyAutocompletionTest.java:110)
>   at 
> org.apache.sling.ide.test.impl.ui.sightly.SightlyAutocompletionTest.attributeAutocompletion(SightlyAutocompletionTest.java:81){noformat}



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

[jira] [Created] (SLING-6231) Sightly SWTBot tests are unstable

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-6231:
--

 Summary: Sightly SWTBot tests are unstable
 Key: SLING-6231
 URL: https://issues.apache.org/jira/browse/SLING-6231
 Project: Sling
  Issue Type: Bug
  Components: IDE
Reporter: Robert Munteanu
 Fix For: Sling Eclipse IDE 1.1.2


The Sightly UI tests fail often on Jenkins but also locally. There seems to be 
some kind of timing issue involved.

The failure is the following:

{noformat}org.eclipse.swtbot.swt.finder.exceptions.WidgetNotFoundException: 
Could not find widget matching: (of type 'Tree')
at 
org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntil(SWTBotFactory.java:437)
at 
org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntil(SWTBotFactory.java:411)
at 
org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntil(SWTBotFactory.java:399)
at 
org.eclipse.swtbot.swt.finder.SWTBotFactory.waitUntilWidgetAppears(SWTBotFactory.java:381)
at 
org.eclipse.swtbot.swt.finder.SWTBotFactory.widget(SWTBotFactory.java:334)
at org.eclipse.swtbot.swt.finder.SWTBot.tree(SWTBot.java:1283)
at org.eclipse.swtbot.swt.finder.SWTBot.tree(SWTBot.java:1272)
at 
org.apache.sling.ide.test.impl.ui.sightly.SightlyAutocompletionTest$AutocompletionCallable.call(SightlyAutocompletionTest.java:110)
at 
org.apache.sling.ide.test.impl.ui.sightly.SightlyAutocompletionTest.attributeAutocompletion(SightlyAutocompletionTest.java:81){noformat}



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

[jira] [Commented] (SLING-6229) Allow configuration of fallback properties in DefaultContextPathStrategy

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6229:
---

looks good to me

one cosmetic idea: perhaps we should not define "additional" but "all" property 
names, with sling:configRef as default. than it is more consistent and gives 
full control.

> Allow configuration of fallback properties in DefaultContextPathStrategy
> 
>
> Key: SLING-6229
> URL: https://issues.apache.org/jira/browse/SLING-6229
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Context-Aware Configuration Impl 1.0.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Context-Aware Configuration Impl 1.0.2
>
>
> Currently the DefaultContextPathStrategy only looks for the property 
> sling:configRef.
> If other properties should be looked for, e.g. for migration from Adobe's 
> confmgr, this can be done with an additional ContextPathStrategy - but this 
> has a performance drawback.
> We should allow to define additional property names which are used in the 
> order of appearance. Once a value for such a property is found, its value is 
> used and the others are not queried anymore. The  sling:configRef property is 
> always the first one used and does not need to be configured - which also 
> means it is not possible to deviate from this rule.



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

[jira] [Created] (SLING-6230) The SightlyCompiler reports errors and warnings with an offset by one for the line count

[Radu Cotescu (JIRA)]

Radu Cotescu created SLING-6230:
---

 Summary: The SightlyCompiler reports errors and warnings with an 
offset by one for the line count
 Key: SLING-6230
 URL: https://issues.apache.org/jira/browse/SLING-6230
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: HTL Maven Plugin 1.0.0, Scripting HTL Compiler 1.0.2
Reporter: Radu Cotescu
Assignee: Radu Cotescu
 Fix For: HTL Maven Plugin 1.0.4, Scripting HTL Compiler 1.0.4


The {{SightlyCompiler}} reports errors and warnings with an offset by one for 
the line count. Since the HTL Maven Plugin directly uses the compiler, this 
means that the plugin is also affected.



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

Re: [VOTE] Release Apache Sling MIME type mapping support 2.1.10

[Daniel Klco]

+1

On Wed, Nov 2, 2016 at 7:07 AM, Carsten Ziegeler 
wrote:

> +1
>
>
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org
>
>

Re: [VOTE] Release Apache Sling MIME type mapping support 2.1.10

[Carsten Ziegeler]

+1

 

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

[VOTE] Release Apache Sling MIME type mapping support 2.1.10

[Antonio Sanso]

Hi,

We solved 3 issues in this release:
https://issues.apache.org/jira/browse/SLING/fixforversion/12327841

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

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

Usage:
sh check_staged_release.sh 1558 /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.

Re: Launchpad stable and launchpad unstable

[Carsten Ziegeler]

Bertrand Delacretaz wrote
> On Wed, Nov 2, 2016 at 9:39 AM, Carsten Ziegeler  wrote:
>> Bertrand Delacretaz wrote
>>> On Wed, Nov 2, 2016 at 6:56 AM, Carsten Ziegeler  
>>> wrote:
 ...what problem are we exactly trying to solve?
>>> ...As described in the original post here - having a stable launchpad
>>> that's always ready to release, while also continuously testing the
>>> integration of the latest snapshots.
>>>
>> So if the integration tests always test the latest snapshots then there
>> is nothing we have do to, right?...
> 
> We need to test the launchpad that we release, don't we?

Yeah, sorry that I'm a little bit picky here. All I'm trying that we get
a description of the full picture.

We want to test the *same* integration tests against the current
launchpad (which has no snapshot deps) and against the same launchpad
but replacing all sling deps to the latest snapshot versions.
And that might lead us into the situation you describe below.

> 
> Depending on the combination of bundles that release might have
> different behavior than combining the latest snapshots, although maybe
> it's not that likely.

Right, I would argue that it is not very likely.

> 
> As a first step we might manually run the integration tests against
> the launchpad that's about to be released, that's better than nothing
> but some tests will fail and we need a manual analysis of that - which
> is not impossible if the goal is to release say every 3 months.

Instead of coming up with a gigantic approach that will not be used or
only once every two years, I think lets deal with it once we're there.
Something simple like an exclusion list activated by the same mechanism
that switches to snapshot dependencies.

 Carsten

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

[jira] [Resolved] (SLING-6222) [Startup ERROR] org.apache.sling.commons.mime FrameworkEvent ERROR (The bundle is uninstalled.)

[Antonio Sanso (JIRA)]

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

Antonio Sanso resolved SLING-6222.
--
   Resolution: Fixed
Fix Version/s: Commons Mime 2.1.10

> [Startup ERROR] org.apache.sling.commons.mime FrameworkEvent ERROR (The 
> bundle is uninstalled.)
> ---
>
> Key: SLING-6222
> URL: https://issues.apache.org/jira/browse/SLING-6222
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
>Priority: Minor
> Fix For: Commons Mime 2.1.10
>
>
> During startup, the following ERROR randomly appears in the logs:
> {code}
> 25.10.2016 07:57:53.712 *ERROR* [FelixDispatchQueue] 
> org.apache.sling.commons.mime FrameworkEvent ERROR 
> (java.lang.IllegalStateException: The bundle is uninstalled.)
> java.lang.IllegalStateException: The bundle is uninstalled.
>   at org.apache.felix.framework.Felix.getBundleEntry(Felix.java:1741)
>   at org.apache.felix.framework.BundleImpl.getEntry(BundleImpl.java:291)
>   at 
> org.apache.sling.commons.mime.internal.MimeTypeServiceImpl.bundleChanged(MimeTypeServiceImpl.java:249)
>   at 
> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:835)
>   at 
> org.apache.felix.framework.util.EventDispatcher.run(EventDispatcher.java:1148)
>   at 
> org.apache.felix.framework.util.EventDispatcher.access$000(EventDispatcher.java:55)
>   at 
> org.apache.felix.framework.util.EventDispatcher$1.run(EventDispatcher.java:103)
>   at java.lang.Thread.run(Thread.java:745)
> {code}



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

[jira] [Commented] (SLING-6222) [Startup ERROR] org.apache.sling.commons.mime FrameworkEvent ERROR (The bundle is uninstalled.)

[Antonio Sanso (JIRA)]

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

Antonio Sanso commented on SLING-6222:
--

applied modified patch (as per suggestions)

> [Startup ERROR] org.apache.sling.commons.mime FrameworkEvent ERROR (The 
> bundle is uninstalled.)
> ---
>
> Key: SLING-6222
> URL: https://issues.apache.org/jira/browse/SLING-6222
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
>Priority: Minor
>
> During startup, the following ERROR randomly appears in the logs:
> {code}
> 25.10.2016 07:57:53.712 *ERROR* [FelixDispatchQueue] 
> org.apache.sling.commons.mime FrameworkEvent ERROR 
> (java.lang.IllegalStateException: The bundle is uninstalled.)
> java.lang.IllegalStateException: The bundle is uninstalled.
>   at org.apache.felix.framework.Felix.getBundleEntry(Felix.java:1741)
>   at org.apache.felix.framework.BundleImpl.getEntry(BundleImpl.java:291)
>   at 
> org.apache.sling.commons.mime.internal.MimeTypeServiceImpl.bundleChanged(MimeTypeServiceImpl.java:249)
>   at 
> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:835)
>   at 
> org.apache.felix.framework.util.EventDispatcher.run(EventDispatcher.java:1148)
>   at 
> org.apache.felix.framework.util.EventDispatcher.access$000(EventDispatcher.java:55)
>   at 
> org.apache.felix.framework.util.EventDispatcher$1.run(EventDispatcher.java:103)
>   at java.lang.Thread.run(Thread.java:745)
> {code}



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

[jira] [Comment Edited] (SLING-6222) [Startup ERROR] org.apache.sling.commons.mime FrameworkEvent ERROR (The bundle is uninstalled.)

[Antonio Sanso (JIRA)]

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

Antonio Sanso edited comment on SLING-6222 at 11/2/16 10:55 AM:


applied modified patch (as per suggestions) in r1767631


was (Author: asanso):
applied modified patch (as per suggestions)

> [Startup ERROR] org.apache.sling.commons.mime FrameworkEvent ERROR (The 
> bundle is uninstalled.)
> ---
>
> Key: SLING-6222
> URL: https://issues.apache.org/jira/browse/SLING-6222
> Project: Sling
>  Issue Type: Bug
>  Components: Commons
>Reporter: Antonio Sanso
>Assignee: Antonio Sanso
>Priority: Minor
>
> During startup, the following ERROR randomly appears in the logs:
> {code}
> 25.10.2016 07:57:53.712 *ERROR* [FelixDispatchQueue] 
> org.apache.sling.commons.mime FrameworkEvent ERROR 
> (java.lang.IllegalStateException: The bundle is uninstalled.)
> java.lang.IllegalStateException: The bundle is uninstalled.
>   at org.apache.felix.framework.Felix.getBundleEntry(Felix.java:1741)
>   at org.apache.felix.framework.BundleImpl.getEntry(BundleImpl.java:291)
>   at 
> org.apache.sling.commons.mime.internal.MimeTypeServiceImpl.bundleChanged(MimeTypeServiceImpl.java:249)
>   at 
> org.apache.felix.framework.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916)
>   at 
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:835)
>   at 
> org.apache.felix.framework.util.EventDispatcher.run(EventDispatcher.java:1148)
>   at 
> org.apache.felix.framework.util.EventDispatcher.access$000(EventDispatcher.java:55)
>   at 
> org.apache.felix.framework.util.EventDispatcher$1.run(EventDispatcher.java:103)
>   at java.lang.Thread.run(Thread.java:745)
> {code}



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

Re: Launchpad stable and launchpad unstable

[Bertrand Delacretaz]

On Wed, Nov 2, 2016 at 9:39 AM, Carsten Ziegeler  wrote:
> Bertrand Delacretaz wrote
>> On Wed, Nov 2, 2016 at 6:56 AM, Carsten Ziegeler  
>> wrote:
>>> ...what problem are we exactly trying to solve?
>> ...As described in the original post here - having a stable launchpad
>> that's always ready to release, while also continuously testing the
>> integration of the latest snapshots.
>>
> So if the integration tests always test the latest snapshots then there
> is nothing we have do to, right?...

We need to test the launchpad that we release, don't we?

Depending on the combination of bundles that release might have
different behavior than combining the latest snapshots, although maybe
it's not that likely.

As a first step we might manually run the integration tests against
the launchpad that's about to be released, that's better than nothing
but some tests will fail and we need a manual analysis of that - which
is not impossible if the goal is to release say every 3 months.

-Bertrand

Sling Eclipse IDE Release?

[Konrad Windszus]

Unfortunately the current version of Sling Eclipse IDE is not compatible with 
the newest maven-bundle-plugin 3.2.0 with the new m2e lifecycle mapping for the 
manifest goal (set up like described in 
http://felix.apache.org/documentation/faqs/apache-felix-bundle-plugin-faq.html#use-scr-metadata-generated-by-bnd-in-unit-tests).
 I fixed that with https://issues.apache.org/jira/browse/SLING-6112 by making 
m2e-tycho no longer a requirement. 

Apart from that 11 other issues have been resolved 
(https://issues.apache.org/jira/browse/SLING-5634?jql=project%20%3D%20SLING%20AND%20status%20%3D%20Resolved%20AND%20fixVersion%20%3D%20%22Sling%20Eclipse%20IDE%201.1.2%22%20ORDER%20BY%20priority%20DESC).

I would therefore like to have a new release from Sling IDE within the next 
weeks.
Is there anything important missing from the unresolved issues supposably fixed 
with Sling Eclipse IDE 1.1.2 
(https://issues.apache.org/jira/browse/SLING-4455?jql=fixVersion%20%3D%20%22Sling%20Eclipse%20IDE%201.1.2%22%20AND%20project%20%3D%20SLING%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC)?

Konrad

[jira] [Commented] (SLING-6229) Allow configuration of fallback properties in DefaultContextPathStrategy

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6229:
-

Implemented in rev 1767627

[~sseif...@pro-vision.de] WDYT?

> Allow configuration of fallback properties in DefaultContextPathStrategy
> 
>
> Key: SLING-6229
> URL: https://issues.apache.org/jira/browse/SLING-6229
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Context-Aware Configuration Impl 1.0.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Context-Aware Configuration Impl 1.0.2
>
>
> Currently the DefaultContextPathStrategy only looks for the property 
> sling:configRef.
> If other properties should be looked for, e.g. for migration from Adobe's 
> confmgr, this can be done with an additional ContextPathStrategy - but this 
> has a performance drawback.
> We should allow to define additional property names which are used in the 
> order of appearance. Once a value for such a property is found, its value is 
> used and the others are not queried anymore. The  sling:configRef property is 
> always the first one used and does not need to be configured - which also 
> means it is not possible to deviate from this rule.



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

[jira] [Resolved] (SLING-6228) Clarifiy description of DefaultContextPathStrategy configRefResourceNames property

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-6228.
-
Resolution: Fixed

Updated in rev 1767626

> Clarifiy description of DefaultContextPathStrategy configRefResourceNames 
> property
> --
>
> Key: SLING-6228
> URL: https://issues.apache.org/jira/browse/SLING-6228
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Context-Aware Configuration Impl 1.0.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: Context-Aware Configuration Impl 1.0.2
>
>
> The description could be a little bit clearer, as if child names are 
> configured the resource itself is not used, unless it is included in the list 
> of names



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

[jira] [Created] (SLING-6229) Allow configuration of fallback properties in DefaultContextPathStrategy

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-6229:
---

 Summary: Allow configuration of fallback properties in 
DefaultContextPathStrategy
 Key: SLING-6229
 URL: https://issues.apache.org/jira/browse/SLING-6229
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Context-Aware Configuration Impl 1.0.0
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Context-Aware Configuration Impl 1.0.2


Currently the DefaultContextPathStrategy only looks for the property 
sling:configRef.
If other properties should be looked for, e.g. for migration from Adobe's 
confmgr, this can be done with an additional ContextPathStrategy - but this has 
a performance drawback.
We should allow to define additional property names which are used in the order 
of appearance. Once a value for such a property is found, its value is used and 
the others are not queried anymore. The  sling:configRef property is always the 
first one used and does not need to be configured - which also means it is not 
possible to deviate from this rule.



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

[jira] [Created] (SLING-6228) Clarifiy description of DefaultContextPathStrategy configRefResourceNames property

[Carsten Ziegeler (JIRA)]

Carsten Ziegeler created SLING-6228:
---

 Summary: Clarifiy description of DefaultContextPathStrategy 
configRefResourceNames property
 Key: SLING-6228
 URL: https://issues.apache.org/jira/browse/SLING-6228
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Affects Versions: Context-Aware Configuration Impl 1.0.0
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Context-Aware Configuration Impl 1.0.2


The description could be a little bit clearer, as if child names are configured 
the resource itself is not used, unless it is included in the list of names



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

[jira] [Resolved] (SLING-5994) Move from EventHandler to new ResourceChangeListener API

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler resolved SLING-5994.
-
Resolution: Fixed

> Move from EventHandler to new ResourceChangeListener API
> 
>
> Key: SLING-5994
> URL: https://issues.apache.org/jira/browse/SLING-5994
> Project: Sling
>  Issue Type: Task
>  Components: API
>Reporter: Hanish Bansal
>Assignee: Carsten Ziegeler
>
> This issue serves as the container for the issues for migrating all 
> implementations of EventHandler to new Resource Observation API in Sling Code.
> The new API that listens to the resource events is : 
> https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/observation/ResourceChangeListener.java
> API for the Resource Change Events : 
> https://github.com/apache/sling/blob/trunk/bundles/api/src/main/java/org/apache/sling/api/resource/observation/ResourceChange.java



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

[jira] [Resolved] (SLING-6226) substVars not properly handling unknown properties

[Felix Meschberger (JIRA)]

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

Felix Meschberger resolved SLING-6226.
--
Resolution: Fixed

Thanks [~cziegeler].

Committed the patch in Rev. 1767618

> substVars not properly handling unknown properties
> --
>
> Key: SLING-6226
> URL: https://issues.apache.org/jira/browse/SLING-6226
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Launchpad Base 2.6.14
>Reporter: Felix Meschberger
> Fix For: Launchpad Base 2.6.16
>
> Attachments: SLING-6226.diff
>
>
> Assuming a property in {{sling.properties}} of the form
> {code}
> org.apache.sling.commons.log.pattern=%d{-MM-dd HH:mm:ss.SSSXXX} *%level* 
> [%thread] %logger %msg%n
> {code}
> This will break during Sling startup as the date format of this 
> {{log.pattern}} ends with a curly brace but is not matched with a {{ $\{ }}. 
> This is a but in the {{substVars}} method.
> Another problem is that this method is duplicate in the {{Sling}} and 
> {{SlingServlet}} classes where the latter is in the web app class loader 
> while the former already is in the launcher class loader.
> Proposing a patch taking the latest Felix Framework's Util class creating a 
> new {{Util}} class in the shared package.



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

[jira] [Assigned] (SLING-6226) substVars not properly handling unknown properties

[Felix Meschberger (JIRA)]

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

Felix Meschberger reassigned SLING-6226:


Assignee: Felix Meschberger

> substVars not properly handling unknown properties
> --
>
> Key: SLING-6226
> URL: https://issues.apache.org/jira/browse/SLING-6226
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Launchpad Base 2.6.14
>Reporter: Felix Meschberger
>Assignee: Felix Meschberger
> Fix For: Launchpad Base 2.6.16
>
> Attachments: SLING-6226.diff
>
>
> Assuming a property in {{sling.properties}} of the form
> {code}
> org.apache.sling.commons.log.pattern=%d{-MM-dd HH:mm:ss.SSSXXX} *%level* 
> [%thread] %logger %msg%n
> {code}
> This will break during Sling startup as the date format of this 
> {{log.pattern}} ends with a curly brace but is not matched with a {{ $\{ }}. 
> This is a but in the {{substVars}} method.
> Another problem is that this method is duplicate in the {{Sling}} and 
> {{SlingServlet}} classes where the latter is in the web app class loader 
> while the former already is in the launcher class loader.
> Proposing a patch taking the latest Felix Framework's Util class creating a 
> new {{Util}} class in the shared package.



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

Re: Launchpad stable and launchpad unstable

[Carsten Ziegeler]

Bertrand Delacretaz wrote
> On Wed, Nov 2, 2016 at 6:56 AM, Carsten Ziegeler  wrote:
>> ...what problem are we exactly trying to solve?
> 
> As described in the original post here - having a stable launchpad
> that's always ready to release, while also continuously testing the
> integration of the latest snapshots.
> 
So if the integration tests always test the latest snapshots then there
is nothing we have do to, right?

 Carsten

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

[jira] [Commented] (SLING-6227) Disable versioning for chunk nodes

[Marcel Reutegger (JIRA)]

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

Marcel Reutegger commented on SLING-6227:
-

I think it would be best to define the on-parent-version action on the 
sling:chunks node type. This is the node type used for the parent node of the 
sling:chunk nodes. The current definition looks like this:

{noformat}
[sling:chunks]
  mixin
  - sling:fileLength (long)
  - sling:length (long)
  + * (sling:chunk) multiple
{noformat}

If we don't want to version the chunks we can set the on-parent-version action 
to ignore:

{noformat}
[sling:chunks]
  mixin
  - sling:fileLength (long) ignore
  - sling:length (long) ignore
  + * (sling:chunk) multiple ignore
{noformat}

With your sample data you provided, the frozen node would still have a 
jcr:content child node with a jcr:frozenMixinTypes that includes sling:chunks, 
but none of the properties and child nodes defined in sling:chunks. Similarly, 
on restore of this version the versionable node would have the mixin but none 
of the ignored items. I think that's fine, because they are not mandatory.

The change should also be backward compatible, because it does not require 
changes to existing data. 

> Disable versioning for chunk nodes
> --
>
> Key: SLING-6227
> URL: https://issues.apache.org/jira/browse/SLING-6227
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Servlets Post 2.3.16
>
>
> While analyzing some customer setup it was found that {{sling:chunk}} nodes 
> are getting stored in version store and thus preventing the temporary files 
> created from getting garbage collection.
> {noformat}
> /jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_7500_7999
> /jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_6000_6499
> /jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_4500_4999
> /jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_2000_2499
> /jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_10500_10999
> /jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_11000_11499>
>  pn
> { jcr:primaryType = nt:frozenNode, jcr:createdBy = admin, 
> jcr:frozenPrimaryType = sling:chunk, sling:offset = 11000, jcr:created = 
> 2015-12-10T22:23:13.409-05:00, jcr:frozenUuid = 
> 136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/jcr:content/chunk_11000_11499, 
> jcr:data = {-1 bytes}, jcr:uuid = a98d131c-4892-42d4-aa15-4bb0402b176d }
> {noformat}
> This can be fixed by tweaking the nodetype definition for sling:chunks to 
> disable versioning for sling:chunk nodes



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

[jira] [Comment Edited] (SLING-6188) Improve validators

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-6188 at 11/2/16 8:17 AM:
-

Maybe a module validator is the right choice here. That one should be called 
only prior to publishing (still to be verified). There would be the right place 
to do that kind of validation.


was (Author: kwin):
Maybe a module validator 
(https://eclipse.org/webtools/wst/components/validation/scenarios/validation_framework_testplan.html)
 is the right choice here, because it is only being executed once during the 
build.

> Improve validators
> --
>
> Key: SLING-6188
> URL: https://issues.apache.org/jira/browse/SLING-6188
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
> Fix For: Sling Eclipse IDE 1.1.2
>
>
> Both validators being provided by Sling IDE (checking manifest.mf consistency 
> as well as checking for a valid jcr_root) are not classical WST validators 
> bound to a specific file.
> E.g. manifest.mf can become invalid if one of the referenced service.xmls 
> vanishes during the build. So it is hard to tell which modifications require 
> a revalidation. For the content package validation it is currently triggered 
> only once per validation run (still too often) but not filtered on any 
> specific files.
> I would rather propose to not use WST validators for those cases but rather 
> do that check only once after each build.



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

Re: Launchpad stable and launchpad unstable

[Bertrand Delacretaz]

On Wed, Nov 2, 2016 at 6:56 AM, Carsten Ziegeler  wrote:
> ...what problem are we exactly trying to solve?

As described in the original post here - having a stable launchpad
that's always ready to release, while also continuously testing the
integration of the latest snapshots.

-Bertrand

[jira] [Updated] (SLING-6188) Improve validators

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6188:
---
Fix Version/s: Sling Eclipse IDE 1.1.2

> Improve validators
> --
>
> Key: SLING-6188
> URL: https://issues.apache.org/jira/browse/SLING-6188
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
> Fix For: Sling Eclipse IDE 1.1.2
>
>
> Both validators being provided by Sling IDE (checking manifest.mf consistency 
> as well as checking for a valid jcr_root) are not classical WST validators 
> bound to a specific file.
> E.g. manifest.mf can become invalid if one of the referenced service.xmls 
> vanishes during the build. So it is hard to tell which modifications require 
> a revalidation. For the content package validation it is currently triggered 
> only once per validation run (still too often) but not filtered on any 
> specific files.
> I would rather propose to not use WST validators for those cases but rather 
> do that check only once after each build.



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

[jira] [Commented] (SLING-6188) Improve validators

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6188:


Maybe a module validator 
(https://eclipse.org/webtools/wst/components/validation/scenarios/validation_framework_testplan.html)
 is the right choice here, because it is only being executed once during the 
build.

> Improve validators
> --
>
> Key: SLING-6188
> URL: https://issues.apache.org/jira/browse/SLING-6188
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>
> Both validators being provided by Sling IDE (checking manifest.mf consistency 
> as well as checking for a valid jcr_root) are not classical WST validators 
> bound to a specific file.
> E.g. manifest.mf can become invalid if one of the referenced service.xmls 
> vanishes during the build. So it is hard to tell which modifications require 
> a revalidation. For the content package validation it is currently triggered 
> only once per validation run (still too often) but not filtered on any 
> specific files.
> I would rather propose to not use WST validators for those cases but rather 
> do that check only once after each build.



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

[jira] [Commented] (SLING-4031) Missing MANIFEST.MF should be a validation error

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-4031:


Probably that kind of validation should be done through the module validation 
(in SlingBundleModuleDelegate.java, 
https://eclipse.org/webtools/wst/components/validation/scenarios/validation_framework_testplan.html),
 that way the validation is only executed once during the build.

> Missing MANIFEST.MF should be a validation error
> 
>
> Key: SLING-4031
> URL: https://issues.apache.org/jira/browse/SLING-4031
> Project: Sling
>  Issue Type: Test
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.2
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: Sling Eclipse IDE 1.1.2
>
>
> I just noticed a warning on the Sling console when a bundle was rebuilt
> {quote}[October 11, 2014 2:09:53 AM EEST] InstallBundle -> 
> /home/ADOBENET/rmuntean/Downloads/import/myproject/components/target/classes 
> : Project P/myproject.components does not have a META-INF/MANIFEST.MF (yet) - 
> not publishing this time (0 ms)
> {quote}
> This should be a validation error and block publishing.



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

[jira] [Updated] (SLING-6227) Disable versioning for chunk nodes

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra updated SLING-6227:
---
Priority: Major  (was: Minor)

> Disable versioning for chunk nodes
> --
>
> Key: SLING-6227
> URL: https://issues.apache.org/jira/browse/SLING-6227
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
> Fix For: Servlets Post 2.3.16
>
>
> While analyzing some customer setup it was found that {{sling:chunk}} nodes 
> are getting stored in version store and thus preventing the temporary files 
> created from getting garbage collection.
> {noformat}
> /jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_7500_7999
> /jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_6000_6499
> /jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_4500_4999
> /jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_2000_2499
> /jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_10500_10999
> /jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_11000_11499>
>  pn
> { jcr:primaryType = nt:frozenNode, jcr:createdBy = admin, 
> jcr:frozenPrimaryType = sling:chunk, sling:offset = 11000, jcr:created = 
> 2015-12-10T22:23:13.409-05:00, jcr:frozenUuid = 
> 136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/jcr:content/chunk_11000_11499, 
> jcr:data = {-1 bytes}, jcr:uuid = a98d131c-4892-42d4-aa15-4bb0402b176d }
> {noformat}
> This can be fixed by tweaking the nodetype definition for sling:chunks to 
> disable versioning for sling:chunk nodes



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

[jira] [Updated] (SLING-6227) Disable versioning for chunk nodes

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra updated SLING-6227:
---
Description: 
While analyzing some customer setup it was found that {{sling:chunk}} nodes are 
getting stored in version store and thus preventing the temporary files created 
from getting garbage collection.

{noformat}
/jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_7500_7999
/jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_6000_6499
/jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_4500_4999
/jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_2000_2499
/jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_10500_10999

/jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_11000_11499>
 pn
{ jcr:primaryType = nt:frozenNode, jcr:createdBy = admin, jcr:frozenPrimaryType 
= sling:chunk, sling:offset = 11000, jcr:created = 
2015-12-10T22:23:13.409-05:00, jcr:frozenUuid = 
136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/jcr:content/chunk_11000_11499, 
jcr:data = {-1 bytes}, jcr:uuid = a98d131c-4892-42d4-aa15-4bb0402b176d }
{noformat}

This can be fixed by tweaking the nodetype definition for sling:chunks to 
disable versioning for sling:chunk nodes

  was:
While analyzing some customer setup it was found that {{sling:chunk}} nodes are 
getting stored in version store and thus preventing the temporary files created 
from getting garbage collection.

This can be fixed by tweaking the nodetype definition for sling:chunks to 
disable versioning for sling:chunk nodes


> Disable versioning for chunk nodes
> --
>
> Key: SLING-6227
> URL: https://issues.apache.org/jira/browse/SLING-6227
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: Servlets Post 2.3.16
>
>
> While analyzing some customer setup it was found that {{sling:chunk}} nodes 
> are getting stored in version store and thus preventing the temporary files 
> created from getting garbage collection.
> {noformat}
> /jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_7500_7999
> /jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_6000_6499
> /jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_4500_4999
> /jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_2000_2499
> /jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_10500_10999
> /jcr:system/jcr:versionStorage/13/6a/9c/136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/1.3/jcr:frozenNode/jcr:content/chunk_11000_11499>
>  pn
> { jcr:primaryType = nt:frozenNode, jcr:createdBy = admin, 
> jcr:frozenPrimaryType = sling:chunk, sling:offset = 11000, jcr:created = 
> 2015-12-10T22:23:13.409-05:00, jcr:frozenUuid = 
> 136a9c8d-4dd8-42e5-bced-67eec6ad8a3e/jcr:content/chunk_11000_11499, 
> jcr:data = {-1 bytes}, jcr:uuid = a98d131c-4892-42d4-aa15-4bb0402b176d }
> {noformat}
> This can be fixed by tweaking the nodetype definition for sling:chunks to 
> disable versioning for sling:chunk nodes



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

[jira] [Commented] (SLING-6227) Disable versioning for chunk nodes

[Chetan Mehrotra (JIRA)]

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

Chetan Mehrotra commented on SLING-6227:


The nodetype definition is defined 
[here|https://github.com/apache/sling/blob/trunk/bundles/servlets/post/src/main/resources/SLING-INF/nodetypes/chunk.cnd]

[~mreutegg] Can you suggest the required changes here which would prevent such 
nodes from getting added to version store? Also would there be any 
compatibility issue with such a change

> Disable versioning for chunk nodes
> --
>
> Key: SLING-6227
> URL: https://issues.apache.org/jira/browse/SLING-6227
> Project: Sling
>  Issue Type: Improvement
>  Components: Servlets
>Reporter: Chetan Mehrotra
>Assignee: Chetan Mehrotra
>Priority: Minor
> Fix For: Servlets Post 2.3.16
>
>
> While analyzing some customer setup it was found that {{sling:chunk}} nodes 
> are getting stored in version store and thus preventing the temporary files 
> created from getting garbage collection.
> This can be fixed by tweaking the nodetype definition for sling:chunks to 
> disable versioning for sling:chunk nodes



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

[jira] [Created] (SLING-6227) Disable versioning for chunk nodes

[Chetan Mehrotra (JIRA)]

Chetan Mehrotra created SLING-6227:
--

 Summary: Disable versioning for chunk nodes
 Key: SLING-6227
 URL: https://issues.apache.org/jira/browse/SLING-6227
 Project: Sling
  Issue Type: Improvement
  Components: Servlets
Reporter: Chetan Mehrotra
Assignee: Chetan Mehrotra
Priority: Minor
 Fix For: Servlets Post 2.3.16


While analyzing some customer setup it was found that {{sling:chunk}} nodes are 
getting stored in version store and thus preventing the temporary files created 
from getting garbage collection.

This can be fixed by tweaking the nodetype definition for sling:chunks to 
disable versioning for sling:chunk nodes



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

[jira] [Commented] (SLING-6219) Allow to create users with repoinit

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6219:
-

I think at some point we'll have some way to handle credentials in a more 
secure way in general in the provisioning model, but I wouldn't wait for this 
with adding this feature.
Having a user pw in the model is no different from having lets say the 
credentials for a mail server in the model

So I think we're fine adding it as is with plain text.

We can look at a more secure way nevertheless, but again that shouldn't block us

> Allow to create users with repoinit
> ---
>
> Key: SLING-6219
> URL: https://issues.apache.org/jira/browse/SLING-6219
> Project: Sling
>  Issue Type: New Feature
>  Components: JCR, Repoinit
>Reporter: Carsten Ziegeler
> Fix For: Repoinit Parser 1.0.4, Repoinit JCR 1.0.4
>
>
> it seems it's not possible to create a user through the repoinit. 
> This would be very useful for sample apps and testing. For example, the
> slingshot sample app currently needs an admin user to create the sample
> user accounts. And therefore slingshot needs to be in the whitelist for
> admin usage - which is not a good thing
> I suggest we add:
> create user {name}
> create user {name} {password}
> delete user {name}
> If no pw is provided for create user, we create a random pw



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

[jira] [Commented] (SLING-6226) substVars not properly handling unknown properties

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6226:
-

[~fmeschbe] Lgtm

> substVars not properly handling unknown properties
> --
>
> Key: SLING-6226
> URL: https://issues.apache.org/jira/browse/SLING-6226
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Launchpad Base 2.6.14
>Reporter: Felix Meschberger
> Fix For: Launchpad Base 2.6.16
>
> Attachments: SLING-6226.diff
>
>
> Assuming a property in {{sling.properties}} of the form
> {code}
> org.apache.sling.commons.log.pattern=%d{-MM-dd HH:mm:ss.SSSXXX} *%level* 
> [%thread] %logger %msg%n
> {code}
> This will break during Sling startup as the date format of this 
> {{log.pattern}} ends with a curly brace but is not matched with a {{ $\{ }}. 
> This is a but in the {{substVars}} method.
> Another problem is that this method is duplicate in the {{Sling}} and 
> {{SlingServlet}} classes where the latter is in the web app class loader 
> while the former already is in the launcher class loader.
> Proposing a patch taking the latest Felix Framework's Util class creating a 
> new {{Util}} class in the shared package.



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