Re: OSGi Installer Configuration - Primitive Arrays

[Konrad Windszus]

To me it felt, like you argued against fixing the documentation and rather 
restrict the types you want to accept. But obviously this is not the case...

Ok, then I am going to fix the documentation and close 
https://issues.apache.org/jira/browse/SLING-8314 
<https://issues.apache.org/jira/browse/SLING-8314> as "Works as Designed" 
without merging the attached PR.
Also I am gonna document the limitations of the write back (which are the same 
as the limitations of the .config file format).

> On 14. Mar 2019, at 13:27, Karl Pauls  wrote:
> 
> On Thu, Mar 14, 2019 at 1:04 PM Konrad Windszus  wrote:
>> 
>> 
>> 
>>> On 14. Mar 2019, at 11:23, Konrad Windszus  wrote:
>>> 
>>> 
>>> 
>>>> On 14. Mar 2019, at 10:19, Karl Pauls >>> <mailto:karlpa...@gmail.com>> wrote:
>>>> 
>>>>> So I don't agree with
>>>>>> The point that we for the writeback don't
>>>>>> convert is hence, technically, a bug.
>>>> 
>>>> It is - assuming we hold our documentation to be the source of what we
>>>> support :-).
>>> Since the implementation was there first before Carsten added the 
>>> documentation I would rather say it is a documentation issue.
>> 
>> Also it says in 
>> https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#configuration-files-config-
>>  
>> <https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#configuration-files-config->
>> "Configuration files ending in .config use the format of the Apache Felix 
>> ConfigAdmin implementation 
>> <https://github.com/apache/felix/blob/trunk/configadmin/src/main/java/org/apache/felix/cm/file/ConfigurationHandler.java>."
> 
> Yes, thats what it is using to handle the format specified directly below it.
> 
> I'm not sure what you are trying to argue for at this point. As I
> said, I'm not against changing the definition - all I'm saying is that
> in case we do, we should define how we handle the writeback because we
> then run into changing config files depending on who touched them
> last. Furthermore, as there is no specification for the Felix class we
> should still define what we expect in the format and obviously, as far
> as we specify something that isn't working yet, implement that (and
> probably stop hot linking to some class in Felix trunk).
> 
> regards,
> 
> Karl
> 
> 
> -- 
> Karl Pauls
> karlpa...@gmail.com

Re: OSGi Installer Configuration - Primitive Arrays

[Konrad Windszus]

I prepared an updated documentation in 
https://github.com/apache/sling-site/pull/34 
<https://github.com/apache/sling-site/pull/34>.
Please review and comment directly on the PR.

AFAIK we don't have any conversion issues WRT primitives vs. objects except for 
the already fixed https://issues.apache.org/jira/browse/SLING-6247 
<https://issues.apache.org/jira/browse/SLING-6247>.

We should just upgrade the JCR Installer to Felix CM 1.8.6 as well to allow to 
give out diff friendly multivalue entries 
(https://issues.apache.org/jira/browse/SLING-8316 
<https://issues.apache.org/jira/browse/SLING-8316>).

Konrad

> On 14. Mar 2019, at 14:06, Karl Pauls  wrote:
> 
> On Thu, Mar 14, 2019 at 1:53 PM Konrad Windszus  <mailto:konra...@gmx.de>> wrote:
>> 
>> To me it felt, like you argued against fixing the documentation and rather 
>> restrict the types you want to accept. But obviously this is not the case...
> 
> I just argued that with the current documentation it was a bug in the
> writeback (which AFAICS, would be fixed by the PR we got). If you want
> to for the future support something else and everybody is fine with
> the broader support that is ok with me (as I said from the beginning)
> as long as we have that documented and the conversion issues are
> addressed/described (and are tested to work of course :-).
> 
> regards,
> 
> Karl
> 
>> Ok, then I am going to fix the documentation and close 
>> https://issues.apache.org/jira/browse/SLING-8314 
>> <https://issues.apache.org/jira/browse/SLING-8314> as "Works as Designed" 
>> without merging the attached PR.
>> Also I am gonna document the limitations of the write back (which are the 
>> same as the limitations of the .config file format).
>> 
>>> On 14. Mar 2019, at 13:27, Karl Pauls  wrote:
>>> 
>>> On Thu, Mar 14, 2019 at 1:04 PM Konrad Windszus  wrote:
>>>> 
>>>> 
>>>> 
>>>>> On 14. Mar 2019, at 11:23, Konrad Windszus  wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 14. Mar 2019, at 10:19, Karl Pauls >>>>> <mailto:karlpa...@gmail.com>> wrote:
>>>>>> 
>>>>>>> So I don't agree with
>>>>>>>> The point that we for the writeback don't
>>>>>>>> convert is hence, technically, a bug.
>>>>>> 
>>>>>> It is - assuming we hold our documentation to be the source of what we
>>>>>> support :-).
>>>>> Since the implementation was there first before Carsten added the 
>>>>> documentation I would rather say it is a documentation issue.
>>>> 
>>>> Also it says in 
>>>> https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#configuration-files-config-
>>>>  
>>>> <https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#configuration-files-config->
>>>> "Configuration files ending in .config use the format of the Apache Felix 
>>>> ConfigAdmin implementation 
>>>> <https://github.com/apache/felix/blob/trunk/configadmin/src/main/java/org/apache/felix/cm/file/ConfigurationHandler.java>."
>>> 
>>> Yes, thats what it is using to handle the format specified directly below 
>>> it.
>>> 
>>> I'm not sure what you are trying to argue for at this point. As I
>>> said, I'm not against changing the definition - all I'm saying is that
>>> in case we do, we should define how we handle the writeback because we
>>> then run into changing config files depending on who touched them
>>> last. Furthermore, as there is no specification for the Felix class we
>>> should still define what we expect in the format and obviously, as far
>>> as we specify something that isn't working yet, implement that (and
>>> probably stop hot linking to some class in Felix trunk).
>>> 
>>> regards,
>>> 
>>> Karl
>>> 
>>> 
>>> --
>>> Karl Pauls
>>> karlpa...@gmail.com
>> 
> 
> 
> -- 
> Karl Pauls
> karlpa...@gmail.com <mailto:karlpa...@gmail.com>

Re: [VOTE][PROPOSAL] Promote the ContentPackage2FeatureModel whiteboard component as a regular Sling sub-project

[Konrad Windszus]

Great and useful tool.
Some questions around that:

1. From the readme at 
https://github.com/apache/sling-whiteboard/tree/master/content-package-2-feature-model#supported-configurations
 

 it is not 100% clear if really all configs are converted to JSON format. Maybe 
we can make an explicit statement about that.
2. Also what I am lacking is how to deploy a FeatureModel to an already started 
Sling instance. AFAIK this is currently not yet there which is not a problem, 
but it is also worth mentioning it in the readme. This is especially crucial 
for content-packages as they are often deployed to an already existing 
instance. So an explicit "Deployment" section would be highly appreciated.

Thanks,
Konrad

> On 21. Mar 2019, at 11:57, Simone Tripodi  wrote:
> 
> Hi all,
> this email to propose to continue a tool development I started from
> the whiteboard[1] as a regular sub-project.
> 
> The tool I started developing is about converting existing plain old
> JCR content-packages[2] to the new Sling Feature Model[3] files +
> bundles.
> 
> Benefits of adopting this tool will make easier the transition for JCR
> users transitioning to the newer Sling technology.
> 
> Status of the whiteboard:
> The tool is able to convert pilot content-packages and contains a test
> coverage of +60%, all supported features are described on the README,
> it already support being packaged as a standalone-CLI tool.
> 
> Proposal for the new Git repository:
> https://github.com/apache/sling-org-apache-sling-cp2fm
> 
> Vote will be open for 72 hours and will close ~ on March the 24th 11:40am
> 
> [ ] +1!!!
> [ ] +/-0, fine, but consider to clarify before...
> [ ] -1, nope, because... (and please explain why)
> 
> Many thanks in advance!
> -Simo
> 
> [1] 
> https://github.com/apache/sling-whiteboard/tree/master/content-package-2-feature-model
> [2] http://jackrabbit.apache.org/filevault/
> [3] https://github.com/apache/sling-org-apache-sling-feature
> 
> http://people.apache.org/~simonetripodi/
> http://twitter.com/simonetripodi

Re: [RTC] Rename error.log to success.log

[Konrad Windszus]

+1 to sling.log
-1 to success.log (because errors are still contained in there)

Konrad

> On 1. Apr 2019, at 10:18, Roy Teeuwen  wrote:
> 
> Hey Robert,
> 
> Why not call it sling.log? or status.log? Because it will still log errors / 
> exceptions in the success.log this way
> 
> Greets,
> Roy
> 
>> On 1 Apr 2019, at 09:19, Robert Munteanu  wrote:
>> 
>> Hi,
>> 
>> I think for some time we have overlooked the operational aspects of
>> Apache Sling and that it's high time to address this huge gap we have
>> between developing with Sling and operating with Sling.
>> 
>> One of the things that bothers me the most is that everything is
>> written in the _error_ log file. That is absolutely setting us up for
>> failure! Everytime I need to see what Sling is doing I have to go to
>> the _error_ log, and this already brings about the idea of _errors_ in
>> Sling.
>> 
>> As we all know, there are no errors in Sling, there is only great
>> success. I would therefore like to submit this simple patch to change
>> the default log file name to success.log .
>> 
>> Given the obviousness of the benefit, this discussion is open only for
>> today.
>> 
>> Thanks,
>> 
>> Robert
>> 
>> diff --git a/src/main/provisioning/sling.txt
>> b/src/main/provisioning/sling.txt
>> index 55f2d9b..5a4984c 100644
>> --- a/src/main/provisioning/sling.txt
>> +++ b/src/main/provisioning/sling.txt
>> @@ -134,7 +134,7 @@
>> 
>>  org.apache.sling.commons.log.LogManager
>>org.apache.sling.commons.log.pattern="%d{dd.MM. HH:mm:ss.SSS}\
>> *%level*\ [%thread]\ %logger\ %msg%n"
>> -org.apache.sling.commons.log.file="logs/error.log"
>> +org.apache.sling.commons.log.file="logs/success.log"
>>org.apache.sling.commons.log.level="info"
>>org.apache.sling.commons.log.file.size="'.'-MM-dd"
>>org.apache.sling.commons.log.file.number=I"7"
>> 
> 

Re: Travis builds for sling?

[Konrad Windszus]

Hi Christian,
this is explained in 
https://cwiki.apache.org/confluence/display/SLING/Sling+Jenkins+Setup 
.
Konrad

> On 24. Apr 2019, at 17:31, Christian Schneider  
> wrote:
> 
> I also saw these single line Jenkinsfiles. They are super convenient as
> long as your build has no specialities .. but I would have no clue what to
> do if my build is different.
> 
> Btw. How do they work? The Jenkinsfile does not refer to any library or
> similar .. so the build does not seem to be fully described by the source
> repo. Is this defined in the jenkins build on the server?
> 
> Christian
> 
> 
> Am Mi., 24. Apr. 2019 um 16:44 Uhr schrieb Robert Munteanu <
> romb...@apache.org>:
> 
>> On Wed, 2019-04-24 at 14:47 +0200, Christian Schneider wrote:
>>> s/jenkiona/jenkins/ :-)
>> 
>> I like Jenkiona :-)
>> 
>> Other that that - you're right, with the pipeline-based builds we
>> already have the 'build as a code' set up that Travis promises.
>> 
>> Additionally, we are able to have a 'marker' Jenkinsfile of one line (
>> well, +18 of license :-) ) for each repo, which makes the management of
>> builds much much simpler. I would not like to see 300 .travis.yml files
>> duplicated across the Sling repos.
>> 
>> Of course, I for one am always open to the option to moving to some
>> other CI platform, granted that it provides tangible benefits over the
>> current setup.
>> 
>> Thanks,
>> 
>> Robert
>> 
>>> 
>>> Am Mi., 24. Apr. 2019 um 14:47 Uhr schrieb Christian Schneider <
>>> ch...@die-schneider.net>:
>>> 
 At Aries we are also still investigating if it makes sense to
 actually use
 travis. I just wanted to announce that it is possible now if you
 also want
 to experiment.
 
 What I like in travis and even more in circle ci is that you can
 define
 the whole build in your source repo. There is nothing to set up on
 the
 build server.
 Circle ci even allows to define a docker image where your code is
 built.
 So you can install whatever build tools you need.
 
 I noticed that the sling modules already use jenkins pipeline jobs.
 So I
 guess most these advantages (compare to old style jenkiona) are
 already
 present in the current builds.
 
 Christian
 
 Am Mi., 24. Apr. 2019 um 11:20 Uhr schrieb Radu Cotescu <
 r...@apache.org>:
 
> Hi Christian,
> 
>> On 24 Apr 2019, at 10:32, Christian Schneider <
>> ch...@die-schneider.net>
> wrote:
>> I just found that apache infra can enable travis integration on
>> request.
>> 
>> I just enabled this for Aries:
>> https://issues.apache.org/jira/browse/INFRA-18131
>> 
>> See here for an example:
>> https://travis-ci.org/apache/aries-journaled-events
>> 
>> Would this be interesting for sling?
>> 
>> Cheers,
>> Christian
> 
> Sling’s modules are already built on ASF’s Jenkins server [0] and
> there’s
> as well a SonarCloud integration [1][2]. I’m not sure what other
> features a
> TravisCI integration would bring.
> 
> Cheers,
> Radu
> 
> [0] - https://builds.apache.org/view/All/job/Sling/ <
> https://builds.apache.org/view/All/job/Sling/>
> [1] - https://sonarcloud.io/organizations/apache/projects <
> https://sonarcloud.io/organizations/apache/projects>
> [2] -
> 
>> https://cwiki.apache.org/confluence/display/SLING/SonarCloud+analysis
> <
> 
>> https://cwiki.apache.org/confluence/display/SLING/SonarCloud+analysis>
> 
> 
 
 --
 --
 Christian Schneider
 http://www.liquid-reality.de
 
 Computer Scientist
 http://www.adobe.com
 
 
>>> 
>>> --
>> 
>> 
> 
> -- 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Computer Scientist
> http://www.adobe.com

Re: Request for a Sling Repository for the Sling Project Archetype

[Konrad Windszus]

The check_stage_release.sh is always the same, i.e. you should not modify its 
URL. Only the parameters need to be modified to check the according staging 
area in Nexus.
Please first run the check script according to your Vote Mail yourself before 
you send out the mail.
Konrad


> On 24. Apr 2019, at 19:14, Andreas Schaefer  wrote:
> 
> Hi Robert
> 
> I am nearly there. The project was released, staged and staging was closed. 
> When I tried to write the VOTE email I ran into an issue where I cannot 
> provide the UNIX script to check the signature:
> 
> I found this from a VOTE from you:
> 
> https://gitbox.apache.org/repos/asf?p=sling-tooling-release.git;a=blob;f=check_staged_release.sh;hb=HEAD
>  
> 
> 
> But when I updated this to mine:
> 
> https://gitbox.apache.org/repos/asf?p=sling-project-archtype.git;a=blob;f=check_staged_release.sh;hb=HEAD
>  
> 
> 
> Then it says it cannot find the file. Is there anything I need to do to 
> create that file?
> 
> Cheers - Andy
> 
>> On Apr 24, 2019, at 7:46 AM, Robert Munteanu  wrote:
>> 
>> 
>> 
>> On Tue, 2019-04-23 at 11:28 -0700, Andreas Schaefer wrote:
>>> I followed this [1] for to setup the release management but I ran
>>> into an issue with GPG where the fingerprint is not adhering to the
>>> listed format in the page: fingerprint = part but it looks like this:
>>> 
>>> gpg --fingerprint
>>> /Volumes/UserHD/Users/achaefa/.gnupg/pubring.kbx
>>> 
>>> ...
>>> pub   rsa4096 2019-04-22 [SC] [expires: 2023-04-22]
>>> 49EC C3FC FD4C DF49 F308  DEC2 7493 91D1 63EF CDEF
>>> …
>>> 
>>> Is the fingerprint added to my Apache Id with the spaces or without?
>> 
>> If I look at https://people.apache.org/keys/group/sling.asc , my key is
>> listed with spaces, just like yours, matching what I see locally for
>> `gpg --fingerprint`.
>> 
>> I suspect that this is fine and you should be able to proceed with the
>> release.
>> 
>> Hope this helps,
>> 
>> Robert
>> 
> 

Re: [RESULT] [VOTE] Release Apache Sling Project Archetype 1.0.0

[Konrad Windszus]

Hi Andy,
look at 
https://sling.apache.org/documentation/development/release-management.html#promoting-the-release
 
,
 paragraph 2 on how you push to Maven Central.

Konorad

> On 1. May 2019, at 23:24, Andreas Schaefer  wrote:
> 
> Hi Stefan
> 
> Thanks for that.
> 
> Is there anything I or a PMC needs to do to get this onto Maven central or 
> does this just take some time?
> 
> As of now I cannot build this w/o a local build:
> 
> mvn archetype:generate \
>-DarchetypeGroupId=org.apache.sling \
>-DarchetypeArtifactId=sling-project-archetype \
>-DarchetypeVersion=1.0.0
> 
> Cheers - Andy Schaefer
> 
>> On Apr 30, 2019, at 1:42 PM, Stefan Seifert  wrote:
>> 
>> 
>>> Can a PMC  copy this release to the Sling dist directory and promote the
>>> artifacts to the central Maven repository?
>> 
>> done
>> 
>> Completed: At revision: 33845  
>> 
>> stefan
>> 
> 

Re: Being prepared for "javax"

[Konrad Windszus]

IMHO there is one other use case which is javax.activation.PostConstruct 
(https://jira.apache.org/jira/browse/SLING-7312 
) used from Sling Models.
But I agree with Carsten that we should not think about this yet, as long as 
there is no definite plan what happens to that annotation in the future...

Konrad

> On 8. May 2019, at 21:58, Carsten Ziegeler  wrote:
> 
> I guess the only hard dependency Sling has is on the servlet API, we might 
> use some other javax specs here and there.
> 
> But, there are no concrete plans yet and I don't think its worth speculating. 
> On the other hand, this might only get problematic for Sling (or any other 
> project) if a) a an update of a specification is produced using the new 
> namespace and b) someone wants to use it in combination with Sling (or any 
> other project using the old namespace). Creating new specifications and 
> adaption usually takes some time, and we can look at it when/if it happens - 
> and maybe it turns out that by that time the answer is easy and poses no 
> problems.
> 
> 
> Regards
> 
> Carsten
> 
> 
> Suren Konathala wrote
>> Most of you may have been following the news/updates on the usage "javax".
>> There's lot of discussions and nothing concrete yet. But wanted to know how
>> much of Sling core will be affected and maybe start planning proactively?
>>- Eclipse foundation announcement
>>https://eclipse-foundation.blog/2019/05/03/jakarta-ee-java-trademarks/
>>- Proposals from Eclipse Foundation
>>https://www.eclipse.org/lists/jakartaee-platform-dev/msg00029.html
>> Thanks
>> Suren
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Sling Default POST Servlets 2.3.30, Sling Form Based Authentication Handler 1.0.14, Sling Starter Content 1.0.4

[Konrad Windszus]

+1 (checked signatures)

Konrad

> On 15. May 2019, at 22:58, Georg Henzler  wrote:
> 
> Hi,
> 
> We solved 2 issues in this release:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SLING%20AND%20fixVersion%20in%20(%22Starter%20Content%201.0.4%22%2C%20%22Form%20Based%20Authentication%201.0.14%22%2C%20%22Servlets%20Post%202.3.30%22)
> 
> There are still some outstanding issues:
> https://issues.apache.org/jira/browse/SLING-8418 (I need the release of 
> "Sling Starter Content 1.0.4" to continue with that)
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-2081/
> 
> 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 2081 /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.
> 
> -Georg

Re: [VOTE] Release Apache Sling Installer Health Checks 2.0.2

[Konrad Windszus]

+1
Konrad

> On 20. May 2019, at 18:25, Robert Munteanu  wrote:
> 
> Hi,
> 
> We solved 3 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12343031
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-2082/
> 
> 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 2082 /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 Hackathon in Berlin - September 2019?

[Konrad Windszus]

I would like to participate as well.
Topics to be discussed: 
- Current state of the Sling Feature Model
- Other Deprecation Candidates

Konrad

> On 13. May 2019, at 12:46, Stefan Seifert  wrote:
> 
> this year's adaptTo() conference in berlin is from september 2nd-4th. we have 
> again the possibility to host a "Sling Hackathon" on the day after (thursday 
> sept. 5th) for up to 20 people. the hackathon is focused mainly on Sling 
> Committers, but other community members are also welcome.
> 
> before doing final planning for this date we want to ask in the mailing list:
> - do you see topics or tickets which would be a good candidate to be 
> discussed (or better: solved) at this date?
> - are you interested to participate even if we do not come up with a 
> predefined list of topics?
> 
> it's some months until september - on the other hand travel plans have to be 
> made soon. thus it would be good to have answers/proposals until *end of 
> may*, so we can decide early in june.
> 
> stefan
> 

Re: June board report draft

[Konrad Windszus]

I kind of missed those steps as well in the past. I thought that this would be 
automatically done as soon as you push something to dist.
Can we aim for a better automation here?
Also from the script 
https://github.com/apache/sling-tooling-release/blob/master/update_reporter.sh 

 it is not clear to me in which format the release file has to be given. Can 
you provide an example?
Is it supposed to contain the full Maven G:A:V or rather the filename?
Thanks,
Konrad

> On 12. Jun 2019, at 15:38, Robert Munteanu  wrote:
> 
> Hi Timothee,
> 
> On Wed, 2019-06-12 at 15:30 +0200, Timothee Maret wrote:
>> Hi Robert,
>> 
>> I am not sure if this is expected or even relevant but the list of
>> releases
>> does not seem to include all the items from
>> https://sling.apache.org/releases.html
> 
> We should include all releases in the report. Which exactly are you
> missing? The release list is automatically generated 
> https://reporter.apache.org/ . The reporter relies on the PMC member
> that commits a new release to dist to also add it to
> reporter.apache.org . Maybe not all releases are added there, hence the
> discrepancy.
> 
> Thanks,
> 
> Robert
> 

Re: Release automation (was: June board report draft)

[Konrad Windszus]

Perfect thanks. Is this considered mature enough to be the default release 
process?
I think at least a hint to that tool would be nice within 
https://sling.apache.org/documentation/development/release-management.html 
<https://sling.apache.org/documentation/development/release-management.html>.
I will definitely try that the next time I do a release.
Konrad

> On 13. Jun 2019, at 16:40, Robert Munteanu  wrote:
> 
> Hi Konrad,
> 
> On Wed, 2019-06-12 at 16:33 +0200, Konrad Windszus wrote:
>> I kind of missed those steps as well in the past. I thought that this
>> would be automatically done as soon as you push something to dist.
>> Can we aim for a better automation here?
>> Also from the script 
>> https://github.com/apache/sling-tooling-release/blob/master/update_reporter.sh
>> <
>> https://github.com/apache/sling-tooling-release/blob/master/update_reporter.sh
>>> it is not clear to me in which format the release file has to be
>> given. Can you provide an example?
>> Is it supposed to contain the full Maven G:A:V or rather the
>> filename?
> 
> I think that for release automation the committer CLI is the solution
> 
>  https://github.com/apache/sling-org-apache-sling-committer-cli
> 
> It allows a release manager to execute various steps in an automated
> manner. It's still WIP, but you can:
> 
> - generate vote emails
> - generate vote result emails
> - create next jira version
> - record release data in reporter.apache.org
> - generate a diff to apply on the website
> 
> Thanks,
> 
> Robert
> 
>> Thanks,
>> Konrad
>> 
>>> On 12. Jun 2019, at 15:38, Robert Munteanu 
>>> wrote:
>>> 
>>> Hi Timothee,
>>> 
>>> On Wed, 2019-06-12 at 15:30 +0200, Timothee Maret wrote:
>>>> Hi Robert,
>>>> 
>>>> I am not sure if this is expected or even relevant but the list
>>>> of
>>>> releases
>>>> does not seem to include all the items from
>>>> https://sling.apache.org/releases.html
>>> 
>>> We should include all releases in the report. Which exactly are you
>>> missing? The release list is automatically generated 
>>> https://reporter.apache.org/ . The reporter relies on the PMC
>>> member
>>> that commits a new release to dist to also add it to
>>> reporter.apache.org . Maybe not all releases are added there, hence
>>> the
>>> discrepancy.
>>> 
>>> Thanks,
>>> 
>>> Robert
>>> 
> 

OSGi DS 1.4 run time dependency with latest bundle parent

[Konrad Windszus]

The latest sling bundle parent defines version 1.4.0 of the dependency 
"org.osgi:org.osgi.service.component.annotations" 
(https://github.com/apache/sling-parent/blob/e9b6c950b577172cd613fbcbe06a9120bcd789c2/sling-bundle-parent/pom.xml#L287).
Once you use that you get a requirement like following in the created bundle 
headers: "osgi.extender;filter:="(&( 
osgi.extender=osgi.component)(&(version>=1.4.0)(!(version>=2.0.0". 
Due to that requirement the bundle will no longer start in OSGi DS 1.3 or older 
implementations, although the XML might be fully compliant with DS 1.3. Further 
details about this in 
https://github.com/bndtools/bnd/issues/2163#issuecomment-388542309.

Are we fine in general to only support OSGi DS 1.4 and no longer OSGi DS 1.3 in 
Sling for all new releases?
Do you know of any other workaround how to prevent that header from being 
emitted apart from overwriting the version 1.4 with the version 1.3?

In my particular use case I am talking about Sling Models 
(https://issues.apache.org/jira/browse/SLING-8452).

Thanks for your input,
Konrad
 

Re: Travis builds for sling?

[Konrad Windszus]

If you consider doing this, please take the tiny URL of the Confluence page as 
this it the only stable one.
Konrad

> Am 02.07.2019 um 14:06 schrieb Robert Munteanu :
> 
>> On Thu, 2019-04-25 at 10:10 +0200, Christian Schneider wrote:
>> Many thanks. That helps a lot. Maybe that wiki should be linked from
>> the
>> JenkinsFiles so people have an easier time to understand that concept
>> and
>> how to tweak it.
>> 
> 
> Yes, we could. Note however that we have hundreds of Jenkinsfiles to
> patch like this :-)
> 
> If you feel lucky you can try and apply the changes yourself, something
> like:
> 
> - generate patch file
> - apply patch file to all repos
> - commit all repos
> - push all repos
> 
> should work. For running commands on top of all repositories you can
> use
> 
> $ repo forall -c "$COMMAND"
> 
> Robert
> 
>> Christian
>> 
>> Am Mi., 24. Apr. 2019 um 17:39 Uhr schrieb Konrad Windszus <
>> konra...@gmx.de
>>> :
>>> Hi Christian,
>>> this is explained in
>>> https://cwiki.apache.org/confluence/display/SLING/Sling+Jenkins+Setup
>>> <
>>> https://cwiki.apache.org/confluence/display/SLING/Sling+Jenkins+Setup>;.
>>> Konrad
>>> 
>>>> On 24. Apr 2019, at 17:31, Christian Schneider <
>>>> ch...@die-schneider.net>
>>> wrote:
>>>> I also saw these single line Jenkinsfiles. They are super
>>>> convenient as
>>>> long as your build has no specialities .. but I would have no
>>>> clue what
>>> to
>>>> do if my build is different.
>>>> 
>>>> Btw. How do they work? The Jenkinsfile does not refer to any
>>>> library or
>>>> similar .. so the build does not seem to be fully described by
>>>> the source
>>>> repo. Is this defined in the jenkins build on the server?
>>>> 
>>>> Christian
>>>> 
>>>> 
>>>> Am Mi., 24. Apr. 2019 um 16:44 Uhr schrieb Robert Munteanu <
>>>> romb...@apache.org>:
>>>> 
>>>>>> On Wed, 2019-04-24 at 14:47 +0200, Christian Schneider wrote:
>>>>>> s/jenkiona/jenkins/ :-)
>>>>> 
>>>>> I like Jenkiona :-)
>>>>> 
>>>>> Other that that - you're right, with the pipeline-based builds
>>>>> we
>>>>> already have the 'build as a code' set up that Travis promises.
>>>>> 
>>>>> Additionally, we are able to have a 'marker' Jenkinsfile of one
>>>>> line (
>>>>> well, +18 of license :-) ) for each repo, which makes the
>>>>> management of
>>>>> builds much much simpler. I would not like to see 300
>>>>> .travis.yml files
>>>>> duplicated across the Sling repos.
>>>>> 
>>>>> Of course, I for one am always open to the option to moving to
>>>>> some
>>>>> other CI platform, granted that it provides tangible benefits
>>>>> over the
>>>>> current setup.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Robert
>>>>> 
>>>>>> Am Mi., 24. Apr. 2019 um 14:47 Uhr schrieb Christian
>>>>>> Schneider <
>>>>>> ch...@die-schneider.net>:
>>>>>> 
>>>>>>> At Aries we are also still investigating if it makes sense
>>>>>>> to
>>>>>>> actually use
>>>>>>> travis. I just wanted to announce that it is possible now
>>>>>>> if you
>>>>>>> also want
>>>>>>> to experiment.
>>>>>>> 
>>>>>>> What I like in travis and even more in circle ci is that
>>>>>>> you can
>>>>>>> define
>>>>>>> the whole build in your source repo. There is nothing to
>>>>>>> set up on
>>>>>>> the
>>>>>>> build server.
>>>>>>> Circle ci even allows to define a docker image where your
>>>>>>> code is
>>>>>>> built.
>>>>>>> So you can install whatever build tools you need.
>>>>>>> 
>>>>>>> I noticed that the sling modules already use jenkins
>>>>>>> pipeline jobs.
>>>>>>> So I
>>>>>>

Re: Updating javax.json APIs version

[Konrad Windszus]

Also according to https://johnzon.apache.org/#Get_started 
 you should reference the 
geronimo-json_1.1_spec
for the API dependency (don't know though for which reason).
But I would follow the advice from Apache Johnzon...

Konrad

> On 3. Jul 2019, at 13:38, dav...@apache.org wrote:
> 
> Hi Simo,
> 
> On the change to javax.json:javax.json-api:1.1.4 - that is the license of
> that jar? Just making sure that it's licensed in a compatible way for the
> ASF.
> 
> Best regards,
> 
> David
> 
> On Tue, 2 Jul 2019 at 23:38, Simone Tripodi 
> wrote:
> 
>> Hi all,
>> I just did a simple experiment in the o.a.s.feature.io bundle by
>> replacing the following dependencies:
>> 
>> org.apache.geronimo.specs:geronimo-json_1.0_spec:1.0-alpha-1 ->
>> javax.json:javax.json-api:1.1.4
>> org.apache.johnzon:johnzon-core:1.0.0 ->
>> org.apache.johnzon:johnzon-core:1.1.12
>> 
>> Despite the fact that new APIs are the official version, they also are
>> compatible with the existing Sling bundle and contain few new methods
>> that would allow me implementing the Feature streaming APIs in an
>> easier way.
>> 
>> WDYT? Is there any blocker on upgrading the dependencies?
>> TIA,
>> ~Simo
>> 
>> http://people.apache.org/~simonetripodi/
>> http://twitter.com/simonetripodi
>> 

Adding Resource Filter to Sling Starter

[Konrad Windszus]

Hi,
in the context of https://issues.apache.org/jira/browse/SLING-8271 
 I became aware of 
https://github.com/apache/sling-org-apache-sling-resource-filter 
.
I really like those helper classes and I think they should be part of the next 
Sling Starter?

WDYT?
Thanks,
Konrad

Re: nodejs based sling packager

[Konrad Windszus]

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 
) 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: [VOTE] Release Apache Sling Content Parser API 2.0.0, Apache Sling Content Parser JSON 2.0.0, Apache Sling Content Parser XML 2.0.0, Apache Sling Content Parser XML JCR 2.0.0, Apache Sling Content

[Konrad Windszus]

IMHO  it is the other way around: If only few/one bundle are supposed to 
implement the interface rather annotate with ProviderType (compare with 
https://osgi.org/javadoc/osgi.annotation/7.0.0/org/osgi/annotation/versioning/ProviderType.html
 

 and 
https://github.com/apache/sling-org-apache-sling-contentparser-api/blob/master/src/main/java/org/apache/sling/contentparser/api/ParserHelper.java
 
).
But I don't think it does matter for final classes as you anyhow cannot 
extend/implement them!
Konrad

> On 24. Jul 2019, at 18:40, Radu Cotescu  wrote:
> 
> Hi Stefan,
> 
>> On 24 Jul 2019, at 18:29, Stefan Seifert  wrote:
>> 
>> p.s. i think the annotation in [1] should be @ProviderType, not 
>> @ConsumerType - but i think this can be changed in future releases without 
>> breaking anything.
>> [1] 
>> https://github.com/apache/sling-org-apache-sling-contentparser-api/blob/master/src/main/java/org/apache/sling/contentparser/api/ParserHelper.java
>>  
>> 
> The class is not supposed to be implemented, so IMO this is a Consumer, 
> right? The ConsumerType is actually the default assumed by most OSGi plugins 
> if I remember correctly, so annotating this final class with ConsumerType was 
> just a pedantic move on my part.
> 
> Cheers,
> Radu

Re: Sling Authenticator issue on Sling 11

[Konrad Windszus]

Hi Andy, the sling.auth.requirements don’t mingle with the access rights. This 
configuration only influences whether the user should be redirected to the 
login page (in case he is not yet logged in) or not. Hope this helps 
Konrad 

> Am 31.07.2019 um 17:47 schrieb Andreas Schaefer :
> 
> Hi
> We at Peregrine CMS ran into an issue with Sling 11 and the Sling 
> Authenticator. I adjusted the scenario to plain Sling to explain.
> 
> OOTB there is not access to /etc/clientlibs/repl/ace.js meaning when I try to 
> access that page in a browser and are not logged in I will get a 404.
> 
> Now I add ‘-/etc/clientlibs/repl’ to the Sling Authenticator’s 
> sling.auth.requirements and try again and I will still get a 404. This was 
> working in Sling 9. Adding read permission to everyone on 
> /etc/clientlibs/repl makes the file accessible.
> 
> Giving read permission for our case is fine but it seems to me that the Sling 
> Authenticator’s sling.auth.requirements with ‘-‘ prefix is superfluous as it 
> does not give access to a node w/o logging in. The only thing it does is to 
> force a login with ‘+/etc/clientlibs/repl’ even if everyone has access.
> 
> Cheers - Andy

Re: [Features] Merging Configurations

[Konrad Windszus]

Hi,
I would actually refuse to merge if the same PID occurs. It might be unexpected 
(and incompatible) if you do transparent merging on the property level.
It is just important that it is easy to resolve those conflict without touching 
the feature, i.e. some force option which enforces merging (where the 2nd 
configuration overwrites properties from the 1st).

Konrad

> On 14. Aug 2019, at 08:23, Carsten Ziegeler  wrote:
> 
> Hi,
> 
> when two features are merged (aggregated), configurations are automatically 
> merged. Meaning if both features have a configuration for the same PID, the 
> properties from the second feature are put into the configuration of the 
> first feature, adding and potentially overwriting values.
> 
> However, for everything else (bundles, framework properties, artifacts) it is 
> up to the caller of the merge functionality to provide guidance for clashes. 
> Meaning if both features have the same bundle/artifact in different versions, 
> then there is no auto merge. Same for framework properties.
> 
> It seems a little bit inconsistent that we're using a different approach for 
> configurations - and it can lead to unexpected results as well. These might 
> be rare but I would argue they occur as often as the case of merging features 
> containing the same bundle in different versions.
> 
> So I think we should not auto merge clashing configurations. The question is 
> on which level we handle the clash: we can already refuse to merge if the 
> same PID occurs - or we refuse if the same property within a PID occurs?
> 
> WDYT?
> 
> Regards
> Carsten
> 
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Apache Sling Health Check Core 2.0.0, Sling Health Check Web Console 2.0.0

[Konrad Windszus]

Hi Georg,
wouldn't it make sense to add a relocation section to this last release 
(https://maven.apache.org/guides/mini/guide-relocation.html 
)?
That way it would be even more obvious on how to migrate...
Konrad


> On 22. Aug 2019, at 19:34, Georg Henzler  wrote:
> 
> Hi,
> 
> We solved 1 issues in this release:
> https://issues.apache.org/jira/browse/SLING-8653
> 
> There are no outstanding issues.
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-2117/
> 
> 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 2117 /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.
> 
> -Georg

Re: [VOTE] Release Apache Sling Health Check Core 2.0.0, Sling Health Check Web Console 2.0.0

[Konrad Windszus]

Yes, Felix HC. This is a drop in replacement at least for these two bundles 
IMHO (although the API package has changed).
Konrad

> On 26. Aug 2019, at 10:01, Stefan Seifert  wrote:
> 
> relocate to what - felix HC?
> relocate makes only sense if the new target is a drop-in replacement - which 
> is not the case with sling HC -> felix HC?
> 
> stefan
> 
>> -----Original Message-
>> From: Konrad Windszus [mailto:konra...@gmx.de]
>> Sent: Monday, August 26, 2019 9:51 AM
>> To: dev@sling.apache.org
>> Subject: Re: [VOTE] Release Apache Sling Health Check Core 2.0.0, Sling
>> Health Check Web Console 2.0.0
>> 
>> Hi Georg,
>> wouldn't it make sense to add a relocation section to this last release
>> (https://maven.apache.org/guides/mini/guide-relocation.html
>> <https://maven.apache.org/guides/mini/guide-relocation.html>)?
>> That way it would be even more obvious on how to migrate...
>> Konrad
>> 
>> 
>>> On 22. Aug 2019, at 19:34, Georg Henzler  wrote:
>>> 
>>> Hi,
>>> 
>>> We solved 1 issues in this release:
>>> https://issues.apache.org/jira/browse/SLING-8653
>>> 
>>> There are no outstanding issues.
>>> 
>>> Staging repository:
>>> https://repository.apache.org/content/repositories/orgapachesling-2117/
>>> 
>>> 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 2117 /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.
>>> 
>>> -Georg
> 
> 

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

[Konrad Windszus]

I fully agree with that statement.
Actually there is already a task at FileVault to have an installation endpoint 
(accompanied by a branch): https://issues.apache.org/jira/browse/JCRVLT-151 


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] https://github.com/ist-dresden/composum
> 
> 
> On 2019-08-27 11:04, Robert Munteanu wrote:
>> Hi Stefan,
>> On Tue, 2019-08-27 at 08:49 +, Stefan Seifert wrote:
>>> i'm not against adding it to sling, but maybe the jackrabbit project
>>> would also be a good place for it? alongside with [1]?
>> This was (summarily) discussed at [2]. Don't have a strong opinion
>> either way, just relaying the answer :-)
>> Thanks,
>> Robert
>>> stefan
>>> [1] http://jackrabbit.apache.org/filevault-package-maven-plugin/
>> [2]:
>> https://lists.apache.org/thread.html/8e417968d0b4ecaa3eb3bd321b13629b86f59c5e2b20284f138119b0@%3Cdev.sling.apache.org%3E
>>> > -Original Message-
>>> > From: Robert Munteanu 
>>> > Sent: Monday, August 26, 2019 4:43 PM
>>> > To: dev@sling.apache.org
>>> > Subject: [VOTE] Accept the donation of the Sling Packager tool,
>>> > SLING-8584
>>> >
>>> > Hi,
>>> >
>>> > Please vote to accept the donation of the Sling Packager module
>>> > described in SLING-8584 [1].
>>> >
>>> > This majority vote is open for at least 72 hours.
>>> >
>>> > Thanks,
>>> >
>>> > Robert
>>> >
>>> > [1]: https://issues.apache.org/jira/browse/SLING-8584
>>> >

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

[Konrad Windszus]

For me the situation looks a bit slightly different: I raised a concern in 
https://lists.apache.org/thread.html/7699b02a090d0397d661721f47a6d70b72fb83ff372fafb7d45e6f5e@%3Cdev.sling.apache.org%3E
 

 and Ruben answered and I unfortunately never really followed-up on that one. 
Still for me we haven't really reached consensus back then. I was rather a bit 
surprised that Robert started the VOTE without commenting on the mailing list 
thread first.

But I want to stress one point first:
This is a great tool and I really appreciate the contribution and won't vote 
-1. But I would still appreciate if the tool would instead be donated to 
Jackrabbit as I feel this project makes more sense as home for the plugin. But 
since Ruben does not seem to consider this as a valid option I am also fine 
with having that inside Sling for the moment.
Once Jackrabbit provides an HTTP endpoint we can think again about moving the 
project to Apache Jackrabbit.

Konrad

> On 27. Aug 2019, at 14:33, Carsten Ziegeler  wrote:
> 
> TBH I find this conversation a little bit strange. We have a contribution, 
> this contribution has been made to us, the Apache Sling project. The 
> suggestion with contributing to Jackrabbit has been discussed over a month 
> ago and it seemed no one had an issue with accepting this contribution in 
> Sling after that.
> 
> Now, when it comes to a vote there is the suggestion to go with Jackrabbit 
> again.
> 
> I think this is not how we should handle contribution
> 
> Regards
> Carsten
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Apache Sling Health Check Core 2.0.0, Sling Health Check Web Console 2.0.0

[Konrad Windszus]

Makes sense. Thanks for the answer.
Here is  my +1.

> On 26. Aug 2019, at 18:12, Georg Henzler  wrote:
> 
> Interesting thought - I didn't think about using [1].
> 
> I think it is fine though, since those two bundles should
> never be referenced via maven directly - rather they are
> part of a runtime (as e.g. compiled by the provisioning
> model [2] or the feature model). For those non-pom
> references, I don't think the metadata from [1] would
> be picked up.
> 
> I included a different mechanism though: By explicitly
> referencing the new Felix HC API [3] the new bundles only
> start if the Felix API bundle is installed - so anybody
> blindly upgrading to apache-sling-hc-core|webconsole
> 2.0.0 will get unstarted bundles showing the missing
> Felix HC API package - that should be pointer enough to
> find the migration guide [4].
> 
> -Georg
> 
> 
> [1] https://maven.apache.org/guides/mini/guide-relocation.html
> 
> [2] 
> https://github.com/apache/sling-org-apache-sling-starter/blob/master/src/main/provisioning/healthcheck.txt
> 
> [3] 
> https://github.com/apache/sling-org-apache-sling-hc-core/blob/b0cfe3c8f7fdc1790f8c16bc075967f12ce33686/src/main/java/org/apache/sling/hc/core/impl/NoopHcCore.java#L33
> 
> [4] 
> https://sling.apache.org/documentation/bundles/sling-health-check-tool.html
> 
> On 2019-08-26 10:04, Konrad Windszus wrote:
>> Yes, Felix HC. This is a drop in replacement at least for these two
>> bundles IMHO (although the API package has changed).
>> Konrad
>>> On 26. Aug 2019, at 10:01, Stefan Seifert  wrote:
>>> relocate to what - felix HC?
>>> relocate makes only sense if the new target is a drop-in replacement - 
>>> which is not the case with sling HC -> felix HC?
>>> stefan
>>>> -Original Message-
>>>> From: Konrad Windszus [mailto:konra...@gmx.de]
>>>> Sent: Monday, August 26, 2019 9:51 AM
>>>> To: dev@sling.apache.org
>>>> Subject: Re: [VOTE] Release Apache Sling Health Check Core 2.0.0, Sling
>>>> Health Check Web Console 2.0.0
>>>> Hi Georg,
>>>> wouldn't it make sense to add a relocation section to this last release
>>>> (https://maven.apache.org/guides/mini/guide-relocation.html
>>>> <https://maven.apache.org/guides/mini/guide-relocation.html>)?
>>>> That way it would be even more obvious on how to migrate...
>>>> Konrad
>>>>> On 22. Aug 2019, at 19:34, Georg Henzler  wrote:
>>>>> Hi,
>>>>> We solved 1 issues in this release:
>>>>> https://issues.apache.org/jira/browse/SLING-8653
>>>>> There are no outstanding issues.
>>>>> Staging repository:
>>>>> https://repository.apache.org/content/repositories/orgapachesling-2117/
>>>>> 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 2117 /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.
>>>>> -Georg

Re: htl-maven-plugin - default value for sourceDirectory

[Konrad Windszus]

Hi,
The logic in the filevault-package-maven-plugin is as follows:
It looks for the first found directory below any of the following: 
${project.basedir}/jcr_root,${project.basedir}/src/main/jcr_root,${project.basedir}/src/main/content/jcr_root,${project.basedir}/src/content/jcr_root,${project.build.outputDirectory}
(http://jackrabbit.apache.org/filevault-package-maven-plugin/package-mojo.html#jcrRootSourceDirectory)

This works pretty well and rarely forces anyone to reconfigure the plugin.

The list could be even extended to cater for other use cases like script in a 
bundle...

Thanks,
Konrad


> On 9. Sep 2019, at 10:46, Radu Cotescu  wrote:
> 
> Hi Robert,
> 
> On Fri, 6 Sep 2019 at 17:49, Robert Munteanu  wrote:
> 
>> Hi,
>> 
>> I have added the htl-maven-plugin for validation to a content package
>> project. I noticed initially that the validation did process anything,
>> because of looking by default in ${project.build.sourceDirectory},
>> which is src/main/java.
>> 
>> Would it make sense to change this default, so that it picks up expect
>> locations of htl scripts, e.g. jcr_root or src/main/content/jcr_root?
>> 
>> Thanks,
>> Robert
> 
> 
> I guess such a change shouldn’t affect users, since we’ve always advised
> them to either change the source directory in the pom or configure the
> plugin. However, I’d stay away from JCR specific tooling and conventions as
> defaults.
> 
> Cheers,
> Radu
> 
>> 

Re: [VOTE] Release Apache Sling Tooling Support Install 1.0.6

[Konrad Windszus]

+1 (checked signatures and build)
Konrad

> On 9. Sep 2019, at 11:04, Robert Munteanu  wrote:
>
> On Thu, 2019-09-05 at 10:50 +, Robert Munteanu wrote:
>> This majority vote is open for at least 72 hours.
>
> We are missing two binding votes, can anyone else please check+vote?
>
> Thanks,
> Robert
>

Re: Why get rid of the rewriter?

[Konrad Windszus]

The new url rewriter SPI will be perfectly supporting AOP.
Konrad

> Am 10.09.2019 um 16:09 schrieb Justin Edelson :
> 
> I see that the same assumptions are being made here that were made a year
> ago when this was discussed. I would strongly caution against assuming that
> the "aspect developer" and the "script developer" are the same person or
> even work for the same organization. The value of AOP programming styles,
> such as that used by the rewriter, is that these roles do not need to be
> aware of each other.
> 
> Agree 100% that AEM should change how link rewriting is done. But that's
> not really Sling's concern per se with respect to the rewriter. Sling's
> concern should be (1) whether or not AOP has value in a component-based
> system (I think the answer here is a clear "yes") and (2) what the right
> programming model is to support AOP. To Reuben's point, it is certainly
> possible that SAX is the wrong programming model (I personally don't agree,
> but I have a very soft spot for SAX). But the answer to that IMO is to
> define a better programming model, not jump to the conclusion that AOP
> doesn't have value.
> 
> Cheers,
> Justin
> 
> On Tue, Sep 10, 2019 at 9:54 AM Carsten Ziegeler 
> wrote:
> 
>> The rewriter is a generic solution (for xhtml) which works independent
>> of the scripting engine used. However, with engines like HTL which knows
>> about HTML and has all the contextual information about the html
>> elements, it is way more efficient to do any transformation whether its
>> link transformations or anything else already during that step.
>> Reparsing with a rather expensive XML processing pipeline is flexible
>> but also slows down the rendering unnecessary.
>> 
>> Carsten
>> 
>>> Am 10.09.2019 um 14:56 schrieb 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 <
>> bdelacre...@apache.org>
>>> 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
 
>>> 
>>> 
>> 
>> --
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
>> 

Re: Why get rid of the rewriter?

[Konrad Windszus]

Why can footnotes not be added as request attributes (either just as a numeric 
counter or a complex object depending on the use case)?

> On 10. Sep 2019, at 16:55, Julian Sedding  wrote:
> 
> Another real-world use-case that was nicely solved using the rewriter
> is footnotes. Footnotes are collected by a rewriter and consecutive
> numbers injected into the markup. At the end of a page all collected
> footnote's texts were then rendered.
> 
> Off the top of my head I cannot name another elegant solution for this 
> problem.
> 
> Granted there is extra processing due to serialising -> parsing ->
> serialising. However, I have yet to encounter a real world scenario
> where this performance cost becomes a performance problem.
> 
> HTL question: could HTL be (easily) modified to generate SAX events
> instead of rendering the markup directly? That should (for HTL) allow
> getting rid of the processing overhead. Just a thought on how to solve
> the underlying issue while keeping the rewriter (maybe by allowing it
> to be hooked in differently).
> 
> Regards
> Julian
> 
> 
> 
> 
> 
> 
> 
> On Tue, Sep 10, 2019 at 4:35 PM Konrad Windszus  wrote:
>> 
>> The new url rewriter SPI will be perfectly supporting AOP.
>> Konrad
>> 
>>> Am 10.09.2019 um 16:09 schrieb Justin Edelson :
>>> 
>>> I see that the same assumptions are being made here that were made a year
>>> ago when this was discussed. I would strongly caution against assuming that
>>> the "aspect developer" and the "script developer" are the same person or
>>> even work for the same organization. The value of AOP programming styles,
>>> such as that used by the rewriter, is that these roles do not need to be
>>> aware of each other.
>>> 
>>> Agree 100% that AEM should change how link rewriting is done. But that's
>>> not really Sling's concern per se with respect to the rewriter. Sling's
>>> concern should be (1) whether or not AOP has value in a component-based
>>> system (I think the answer here is a clear "yes") and (2) what the right
>>> programming model is to support AOP. To Reuben's point, it is certainly
>>> possible that SAX is the wrong programming model (I personally don't agree,
>>> but I have a very soft spot for SAX). But the answer to that IMO is to
>>> define a better programming model, not jump to the conclusion that AOP
>>> doesn't have value.
>>> 
>>> Cheers,
>>> Justin
>>> 
>>> On Tue, Sep 10, 2019 at 9:54 AM Carsten Ziegeler 
>>> wrote:
>>> 
>>>> The rewriter is a generic solution (for xhtml) which works independent
>>>> of the scripting engine used. However, with engines like HTL which knows
>>>> about HTML and has all the contextual information about the html
>>>> elements, it is way more efficient to do any transformation whether its
>>>> link transformations or anything else already during that step.
>>>> Reparsing with a rather expensive XML processing pipeline is flexible
>>>> but also slows down the rendering unnecessary.
>>>> 
>>>> Carsten
>>>> 
>>>>> Am 10.09.2019 um 14:56 schrieb 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 <
>>>> bdelacre...@apache.org>
>>>>> 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
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> --
>>>> --
>>>> Carsten Ziegeler
>>>> Adobe Research Switzerland
>>>> cziege...@apache.org
>>>> 
>> 

Re: [hackathon] maven archetypes

[Konrad Windszus]

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: [hackathon] CI experience

[Konrad Windszus]

> On 5. Sep 2019, at 16:28, Stefan Seifert  wrote:
> 
> - Challenge: Building non-committer PRs with Jenkins is no longer allowed 
>  - problem described in SLING-7245 - Validate pull requests using Jenkins 
> Resolved
>- reason are security issues, see also INFRA-18973
>- we assume it will not be fixed by INFRA due to this, we need another 
> solution
>  - possible solutions in ASF Jenkins:
>- run builds in container?
>- use our own build slaves somewhere external?
>  - or use external CI providers like travis, cloudbees, circleci
>- requirements for such an external CI:
>  - possibility to reuse our shared jenkins libraries to avoid duplication 
> in all build descriptor files
>  - sonarcloud trigger
>- konrad will do a PoC with cloudbees
This is now tracked in https://issues.apache.org/jira/browse/SLING-8704 
.


> 
> - sonarcube rules
>  - how can we define custom rules? (disabling default ones, add new ones)
>  - can we maintain those in a separate rule file (e.g. to be also reused 
> outside sling)?
>  - let's start with a minimal set of custom rules
>  - auto-checking in PRs is only done for new code introduced in the PR
>  - all already onboarded projects need to be mapped with the new rule settings
>  - new projects need to be assigned manually to it (no API for it currently)
> 
> - sonar check onbaording for new sling modules currently depends on 
> contacting someone in sonarcloud to do it manually
>  - there is a user group "sling-admins" at sonarcube which can do a lot of 
> things - but not onboarding new projects
>  - manual process usually takes ~2 days, sometimes longer if the person is 
> not in office
>  - is there an API for this in sonarcloud that sonarcloud itself could use to 
> automate the process?
>  - maybe the newly introduced "sling" topic on git repo may help?
>  - on the long run it would be nice to control something like this via the 
> asf.yaml
> 
> - git PR policies
>  - we should document our preferred way of applying PRs
>  - preferred is rebasing to get a linear history
>  - original author info should be kept in commit
>  - if squashing is required it should be done before rebasing
>  - is it possible to prevent force-push on master branch? currently only 
> possible by contacting INFRA
> 
> - sling starter
>  - already documented in release management rules: sling starter needs to be 
> update with latest versions once a module contained there gets a new release 
> (should be tested with sling starter before starting the release)
>  - all modules that are part of the sling starter: automatically run starter 
> ITs for github PRs on this module
> 
> - website source code list
>  - add link to sling-aggregator/docs/modules page
> 
> - Docker Engine on build hosts for integration tests (possible?)
>  - should be possible with adding additional "docker" label in the sling 
> modules list -> then it gets configured in the jenkins jobs
> 
> - matrix build (e.g. multiple JDKs)
>  - can be configured already
>  - a good target list would be the java LTS versions since java 8 + the 
> current unstable, e.g. 8,11,13 currently
> 
> Stefan
> 
> 

Missing horizontal scroll bars on Sling Website

[Konrad Windszus]

I just noticed that the horizontal scroll bars are missing (at least in Chrome 
77 on Mac OS X) e.g. in 
https://sling.apache.org/documentation/bundles/scripting/scripting-htl.html#javascript-use-provider
 
.
 Is that related to the recent CSS update? Can we please restore the horizontal 
scroll bars?

Thanks,
Konrad

Re: Missing horizontal scroll bars on Sling Website

[Konrad Windszus]

For me the same issue happens with Firefox 69.0 on Mac OS.
It only appears for width above 768px (so Mobile is not affected).
Konrad

> On 16. Sep 2019, at 18:53, Eric Norman  wrote:
> 
> FYI: I also see missing horizontal bars with Chromium 76 on linux.
> 
> -Eric
> 
> On Mon, Sep 16, 2019 at 9:47 AM Jason E Bailey 
> wrote:
> 
>> I may have spoke to soon. I'm seeing horizontal scoll bars when they are
>> needed. Are you on mobile?
>> 
>> --
>> Jason
>> 
>> On Mon, Sep 16, 2019, at 12:42 PM, Jason E Bailey wrote:
>>> Didn't notice that before, and whether it's the css I added or not.
>>> I'll go ahead and see what I can do to fix it since I was the last one
>>> playing with it.
>>> 
>>> --
>>> Jason
>>> 
>>> On Mon, Sep 16, 2019, at 12:14 PM, Konrad Windszus wrote:
>>>> I just noticed that the horizontal scroll bars are missing (at least
>> in
>>>> Chrome 77 on Mac OS X) e.g. in
>>>> 
>> https://sling.apache.org/documentation/bundles/scripting/scripting-htl.html#javascript-use-provider
>> <
>> https://sling.apache.org/documentation/bundles/scripting/scripting-htl.html#javascript-use-provider>.
>> Is that related to the recent CSS update? Can we please restore the
>> horizontal scroll bars?
>>>> 
>>>> Thanks,
>>>> Konrad
>>>> 
>>>> 
>>> 
>> 

Re: Missing horizontal scroll bars on Sling Website

[Konrad Windszus]

Looks good now. Thanks a lot for the quick fix.

Konrad

> On 16. Sep 2019, at 19:27, Jason E Bailey  wrote:
> 
> implemented a fix and committed it. tested it locally and got good results.  
> Should take a few minutes and you'll be able to see it.
> 
> --
> Jason
> 
> On Mon, Sep 16, 2019, at 12:56 PM, Konrad Windszus wrote:
>> For me the same issue happens with Firefox 69.0 on Mac OS.
>> It only appears for width above 768px (so Mobile is not affected).
>> Konrad
>> 
>>> On 16. Sep 2019, at 18:53, Eric Norman  wrote:
>>> 
>>> FYI: I also see missing horizontal bars with Chromium 76 on linux.
>>> 
>>> -Eric
>>> 
>>> On Mon, Sep 16, 2019 at 9:47 AM Jason E Bailey 
>>> wrote:
>>> 
>>>> I may have spoke to soon. I'm seeing horizontal scoll bars when they are
>>>> needed. Are you on mobile?
>>>> 
>>>> --
>>>> Jason
>>>> 
>>>> On Mon, Sep 16, 2019, at 12:42 PM, Jason E Bailey wrote:
>>>>> Didn't notice that before, and whether it's the css I added or not.
>>>>> I'll go ahead and see what I can do to fix it since I was the last one
>>>>> playing with it.
>>>>> 
>>>>> --
>>>>> Jason
>>>>> 
>>>>> On Mon, Sep 16, 2019, at 12:14 PM, Konrad Windszus wrote:
>>>>>> I just noticed that the horizontal scroll bars are missing (at least
>>>> in
>>>>>> Chrome 77 on Mac OS X) e.g. in
>>>>>> 
>>>> https://sling.apache.org/documentation/bundles/scripting/scripting-htl.html#javascript-use-provider
>>>> <
>>>> https://sling.apache.org/documentation/bundles/scripting/scripting-htl.html#javascript-use-provider>.
>>>> Is that related to the recent CSS update? Can we please restore the
>>>> horizontal scroll bars?
>>>>>> 
>>>>>> Thanks,
>>>>>> Konrad
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> 
>> 

Re: bnd baselining and development versions

[Konrad Windszus]

That would officially violate 
https://www.osgi.org/developer/white-papers/semantic-versioning/bundles-and-fragments/
 

 and the warning come from bnd itself.
https://github.com/bndtools/bnd/blob/abdf289ce7599d1595a29ec546774d56eb824f99/biz.aQute.bndlib/src/aQute/bnd/differ/Baseline.java#L297
 


I think the only permanent solution is either
a) adjust the bundle version accordingly (and rather get rid of odd/even 
release version numbers)
b) adjust bnd to support an instruction which allows to skip the bundle version 
check

Thanks
Konrad


> On 20. Sep 2019, at 11:23, Robert Munteanu  wrote:
> 
> Hi,
> 
> After locally updating a module to use the latest parent pom, with the
> bnd Maven tooling, I get a complaint with bnd that the version is too
> low.
> 
> The bundle version change (1.2.6 to 1.2.7) is too low, the new version
> must be at least 1.3.0
> 
> That is fine, and I agree with it. However, it goes against our
> practice of using odd/even versioning numbers and changing the version
> on release.
> 
> I've disabled the baseline check for that module for now, but it would
> be good to have a more permanent solution.
> 
> Thanks,
> Robert
> 

Re: bnd baselining and development versions

[Konrad Windszus]

I am not aware of any more places (e.g. OSGi Installer or Felix Web Console) 
where changes from SNAPSHOT to non SNAPSHOT versions would not be applied (even 
if the version number does not change).
But maybe Carsten Ziegeler could confirm.
The relevant code is IMHO 
https://github.com/apache/sling-org-apache-sling-installer-core/blob/33eeae619c5aae2a7a52903edbdd6a85b08e0891/src/main/java/org/apache/sling/installer/core/impl/tasks/BundleTaskCreator.java#L235
 
<https://github.com/apache/sling-org-apache-sling-installer-core/blob/33eeae619c5aae2a7a52903edbdd6a85b08e0891/src/main/java/org/apache/sling/installer/core/impl/tasks/BundleTaskCreator.java#L235>

Konrad

> On 20. Sep 2019, at 12:32, Radu Cotescu  wrote:
> 
> Hi Konrad,
> 
>> On 20 Sep 2019, at 11:34, Konrad Windszus  wrote:
>> 
>> a) adjust the bundle version accordingly (and rather get rid of odd/even 
>> release version numbers)
> 
> Can we safely get rid of the odd/even release version numbers? IIRC we’re 
> using this so that a development version gets upgraded with the newest 
> released version in the OSGi container.
> 
> To take Robert’s example, 1.2.7-SNAPSHOT would be a greater version than 
> 1.2.7. So would 1.2.7.timestamp.
> 
> Thanks,
> Radu
> 

Re: bnd baselining and development versions

[Konrad Windszus]

I don't think it is hard to fix the OSGi Installer to make it aware of 
-SNAPSHOT < .
But unfortunately it is impossible to force people to update the OSGi installer 
for updating newer Sling bundles,
therefore I fear we should come up with a patch for bnd to optionally skip 
bundle version baselining.

Konrad

> On 20. Sep 2019, at 15:53, Radu Cotescu  wrote:
> 
> 
>> On 20 Sep 2019, at 12:36, Konrad Windszus  wrote:
>> 
>> I am not aware of any more places (e.g. OSGi Installer or Felix Web Console) 
>> where changes from SNAPSHOT to non SNAPSHOT versions would not be applied 
>> (even if the version number does not change).
>> But maybe Carsten Ziegeler could confirm.
>> The relevant code is IMHO 
>> https://github.com/apache/sling-org-apache-sling-installer-core/blob/33eeae619c5aae2a7a52903edbdd6a85b08e0891/src/main/java/org/apache/sling/installer/core/impl/tasks/BundleTaskCreator.java#L235
>>  
>> <https://github.com/apache/sling-org-apache-sling-installer-core/blob/33eeae619c5aae2a7a52903edbdd6a85b08e0891/src/main/java/org/apache/sling/installer/core/impl/tasks/BundleTaskCreator.java#L235>
>> 
>> Konrad
>> 
> 
> The OSGi installer does care about versions and it seems that a version with 
> a qualifier is greater than one without. So 1.2.7-SNAPSHOT or 
> 1.2.7.1568987500 are greater than 1.2.7.
> 
> The Felix Web Console doesn’t seem to care at all about bundle versions. I 
> was able to replace a 1.2.7 with a 1.2.6 by POSTing to 
> /system/console/bundles.
> 
> I guess that as long as we support the OSGi installer we cannot get rid of 
> the odd/even release policy.
> 
> Thanks,
> Radu

Re: bnd baselining and development versions

[Konrad Windszus]

Well, after having a second thought I don't think that -SNAPSHOT ever appears 
in the bundle version. The bnd-maven-plugin will instead always rely on a 
timestamp as qualifier. As long as we keep the same timestamp as qualifier also 
during the release we have a nice order of bundle versions (irrespective of 
SNAPSHOT or release).

> On 20. Sep 2019, at 16:02, Radu Cotescu  wrote:
> 
> +2 (as it seems that Konrad also agrees with this). Robert, will you be the 
> volunteer for proposing the change to bnd?
> 
>> On 20 Sep 2019, at 13:36, Robert Munteanu  wrote:
>> 
>> - baselining for exported package versions on every build
>> - baselining for the bundle version when releasing, - mvn
>> release:prepare
>> 
>> This would allow us to keep our strategy _and_ pick the right version
>> number for the bundle. (This is probably not available in bnd, but
>> maybe we could enhance it)
> 

Re: bnd baselining and development versions

[Konrad Windszus]

Not at all, but AFAIK OSGi version qualifiers don't have special support for 
SNAPSHOTS. Therefore -SNAPSHOT should never appear in bundle versions.
Compare with 
https://osgi.org/javadoc/r4v43/core/org/osgi/framework/Version.html#compareTo(org.osgi.framework.Version)
 
.

> On 20. Sep 2019, at 16:20, Radu Cotescu  wrote:
> 
> How would you know if the bundle you have on your instance is a snapshot or a 
> released one if we append timestamps as qualifiers to all versions?

Re: bnd baselining and development versions

[Konrad Windszus]

https://github.com/bndtools/bnd/blob/abdf289ce7599d1595a29ec546774d56eb824f99/maven/bnd-maven-plugin/src/main/java/aQute/bnd/maven/plugin/BndMavenPlugin.java#L306

> On 20. Sep 2019, at 16:20, Radu Cotescu  wrote:
> 
> How would you know if the bundle you have on your instance is a snapshot or a 
> released one if we append timestamps as qualifiers to all versions?
> 
>> On 20 Sep 2019, at 16:08, Konrad Windszus  wrote:
>> 
>> As long as we keep the same timestamp as qualifier also during the release 
>> we have a nice order of bundle versions (irrespective of SNAPSHOT or 
>> release).
> 

Re: bnd baselining and development versions

[Konrad Windszus]

Well I think the baselining issue only appears with the latest bnd-maven-plugin 
and not the maven-bundle-plugin.
So the bundles we have migrated to the latest parent do no longer need to 
follow odd/even release versions, right?

Konrad

> On 20. Sep 2019, at 17:09, Radu Cotescu  wrote:
> 
> Right! But we already knew that bnd converts a snapshot version to a 
> timestamp one. And the older maven-bundle-plugin makes the SNAPSHOT part of 
> the bundle version a qualifier.
> 
> To summarise:
> For bundle version 1.2.7-SNAPSHOT we’d have:
> Bundle-Version: 1.2.7. generated by bnd
> Bundle-Version: 1.2.7.SNAPSHOT generated by maven-bundle-plugin
> 
> Given that not all modules are migrated to the bnd plugin I think we have to 
> continue to maintain our odd / even release policy and enhance bnd to allow 
> us to perform the bundle version check on-demand, which in our case would be 
> at release time.
> 
> Thanks,
> Radu

Re: bnd baselining and development versions

[Konrad Windszus]

A workaround has been suggested by the bnd people and I have opened 
https://issues.apache.org/jira/browse/SLING-8735 
 to track implementation of 
this workaround in the next bundle parent.

Konrad

> On 23. Sep 2019, at 11:41, Robert Munteanu  wrote:
> 
> On Fri, 2019-09-20 at 16:02 +0200, Radu Cotescu wrote:
>> +2 (as it seems that Konrad also agrees with this). Robert, will you
>> be the volunteer for proposing the change to bnd?
> 
> I proposed the change
> 
>  https://github.com/bndtools/bnd/issues/3446
> 
> I know there is a lot more discussion, but this improvement will
> unblock us on the short term. On the longer run we could revisit
> odd/even versioning policy, but I guess that's quite a big change I
> would prefer to do it on our own terms, not forced by a tooling
> problem.
> 
> Thanks,
> Robert
> 

Re: Changing the resource to render and the handling servlet in a request

[Konrad Windszus]

Nice, can you add this to 
https://sling.apache.org/documentation/bundles/rendering-content-default-get-servlets.html?
 

Thanks,
Konrad

> On 15. Oct 2019, at 11:19, Robert Munteanu  wrote:
> 
> Hi Julian,
> 
> On Mon, 2019-09-30 at 21:40 +0200, Julian Sedding wrote:
>> Hi Robert (again)
>> 
>> I tried what I suggested and found exactly what you described: the
>> extension of the forwarded request is not changed.
>> 
>> However, there is a workaround. You can change the extension if you
>> append one to the path passed into the RequestDispatcher, i.e. the
>> path to your binary. The default GET servlet supports stream
>> rendering
>> (spooling binaries) for both the "null" extension and for ".res"[0].
>> Therefore the following should work.
>> 
>>String suffix = request.getRequestPathInfo().getSuffix();
>>request
>>.getRequestDispatcher("/content/maven" + suffix + ".res")
>>.forward(request, response);
>> 
>> Not particularly obvious or nice, so an API enhancement would still
>> be
>> a good thing.
> 
> That works, and without an API change, so that's extra nice :-) Thanks
> for digging into this.
> 
> Robert
> 
>> 
>> Regards
>> Julian
>> 
>> [0] 
>> https://github.com/apache/sling-org-apache-sling-servlets-get/blob/master/src/main/java/org/apache/sling/servlets/get/impl/DefaultGetServlet.java#L223-L227
>> 
>> On Fri, Sep 27, 2019 at 11:21 AM Julian Sedding 
>> wrote:
>>> Hi Robert
>>> 
>>> Have you tried "forwarding" instead of "including"? AFAIK that
>>> should
>>> clear any previous reuest path info etc.
>>> 
>>> Regards
>>> Julian
>>> 
>>> On Thu, Sep 26, 2019 at 4:54 PM Robert Munteanu >>> wrote:
 On Thu, 2019-09-26 at 13:32 +0200, Radu Cotescu wrote:
> Hi Robert,
> 
>> On 26 Sep 2019, at 13:08, Robert Munteanu >> 
>> wrote:
>> 
>> 
>> My solution has two steps:
>> 
>> 1. wrap the original request using a
>> SlingHttpServletRequestWrapper
>> and
>> overriding getResource() to return the new resource. Also
>> overriding
>> getRequestPathInfo to return an object that points to the new
>> resource
>> 
>> 2. obtain a reference to the DefaultGetServlet via
>> 
>> @Reference(target =
>> "(component.name=org.apache.sling.servlets.get.DefaultGetServ
>> let)")
>> private Servlet getServlet;
>> 
>> (I guess I could use the component pid as a slight
>> improvement).
>> 
>> and invoke its service() method with the altered request and
>> the
>> same response.
>> 
> 
> Why can’t you use the RequestDispatcher in the second step
> instead of
> directly referencing the DefaultGetServlet?
 
 Good question :-) There are two answers to this:
 
 1. I did not think of that
 2. It does not allow me to override the extension. But that
 should be a
 simple change. So I filed
 
  https://issues.apache.org/jira/browse/SLING-8742
 
 to allow overriding the extension when including a resource.
 
 Thanks,
 Robert
 
> 

Re: Dynamic Class Loader Manager causes lots of service restarts

[Konrad Windszus]

Hi Julian,
thanks a lot for bringing up this topic. Indeed the restart cascade causes some 
issues for me as well. Just invalidating the cache of the DCLM without 
restarting it fully sounds reasonable to me, but I am not that familiar with 
class loader insights. I vaguely remember that the restart might be necessary 
due to static cache fields but I don't remember the details...
Maybe Carsten remembers...
Konrad

> On 22. Oct 2019, at 10:00, Julian Sedding  wrote:
> 
> Hi all
> 
> I have observed repeatedly that reinstalling bundles of a custom Sling
> (actually AEM) application causes a lot of activity in the OSGi
> framework and thus can take quite a long time (10s of seconds to
> minutes), which feels quite disruptive during development where
> frequent deployments are common.
> 
> As far as I can see the Dynamic Class Loader Manager (DCLM) does "the
> right thing" and restarts itself when a bundle whose classes have been
> loaded via the dynamic class loader is reinstalled. The restart of the
> DCLM then causes all services referencing it to restart as well,
> causing, amongst others, scripting engines to restart and generally
> triggering a cascade of service restarts.
> 
> This seems to be especially common with bundles providing model
> classes that are used in rendering scripts (a prime use-case for
> customizations), but is not limited to such cases. Note: it is
> necessary to run a rendering script using the model before
> reinstalling the bundle in order to cause the restarts
> 
> I was wondering if it wouldn't be possible to change the DCLM in a way
> that it doesn't need to restart, but that it just swaps out the class
> loader(s) behind the facade.I don't have much experience with
> implementing custom class loaders, but I have a hunch that this may be
> difficult to get right due to class loader internal caching of loaded
> classes.
> 
> Is there anyone more knowledgable in this area who could provide an
> assessment regarding the feasibility of such an approach?
> 
> Regards
> Julian

Re: Dynamic Class Loader Manager causes lots of service restarts

[Konrad Windszus]

One of the main issues with the DCLM restart is the availability of the AEM 
package manager itself. As the AEM package manager ReST endpoint depends as 
well on the DCLM (written in JSP) it is usually restarted after a bundle 
deployment triggered by package installation (and therefore for quite a time no 
longer available for a subsequent package installation). Although some of the 
pain has been taken with https://issues.apache.org/jira/browse/SLING-3747 
<https://issues.apache.org/jira/browse/SLING-3747>, it is still an issue for 
subsequent package installations.
I guess much of the pain would already be resolved in case something like 
https://issues.apache.org/jira/browse/JCRVLT-151 
<https://issues.apache.org/jira/browse/JCRVLT-151> would be implemented in a 
way which doesn't rely on scripts (but rather on precompiled servlets).
Konrad


> On 22. Oct 2019, at 10:21, Konrad Windszus  wrote:
> 
> Hi Julian,
> thanks a lot for bringing up this topic. Indeed the restart cascade causes 
> some issues for me as well. Just invalidating the cache of the DCLM without 
> restarting it fully sounds reasonable to me, but I am not that familiar with 
> class loader insights. I vaguely remember that the restart might be necessary 
> due to static cache fields but I don't remember the details...
> Maybe Carsten remembers...
> Konrad
> 
>> On 22. Oct 2019, at 10:00, Julian Sedding  wrote:
>> 
>> Hi all
>> 
>> I have observed repeatedly that reinstalling bundles of a custom Sling
>> (actually AEM) application causes a lot of activity in the OSGi
>> framework and thus can take quite a long time (10s of seconds to
>> minutes), which feels quite disruptive during development where
>> frequent deployments are common.
>> 
>> As far as I can see the Dynamic Class Loader Manager (DCLM) does "the
>> right thing" and restarts itself when a bundle whose classes have been
>> loaded via the dynamic class loader is reinstalled. The restart of the
>> DCLM then causes all services referencing it to restart as well,
>> causing, amongst others, scripting engines to restart and generally
>> triggering a cascade of service restarts.
>> 
>> This seems to be especially common with bundles providing model
>> classes that are used in rendering scripts (a prime use-case for
>> customizations), but is not limited to such cases. Note: it is
>> necessary to run a rendering script using the model before
>> reinstalling the bundle in order to cause the restarts
>> 
>> I was wondering if it wouldn't be possible to change the DCLM in a way
>> that it doesn't need to restart, but that it just swaps out the class
>> loader(s) behind the facade.I don't have much experience with
>> implementing custom class loaders, but I have a hunch that this may be
>> difficult to get right due to class loader internal caching of loaded
>> classes.
>> 
>> Is there anyone more knowledgable in this area who could provide an
>> assessment regarding the feasibility of such an approach?
>> 
>> Regards
>> Julian
> 

Re: [VOTE] Release Apache Sling Thread Support 3.2.14

[Konrad Windszus]

+1

Konrad

> On 25. Jan 2018, at 14:42, Robert Munteanu  wrote:
> 
> 
> Hi,
> 
> We solved 3 issues in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12342655
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1861
> 
> 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 1861 /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: New i18n release and basename handling (was: [VOTE] Release Apache Sling Starter 10 + associated testing projects and archetypes (take 2))

[Konrad Windszus]

Agreed, now with  https://issues.apache.org/jira/browse/SLING-7421 
<https://issues.apache.org/jira/browse/SLING-7421> resolved and the IT added 
for this as well you could go ahead with spinning a new release to unblock 
Sling 10. We defer the baseline discussion to 
https://issues.apache.org/jira/browse/SLING-7429 
<https://issues.apache.org/jira/browse/SLING-7429>.

> On 23. Jan 2018, at 13:28, Robert Munteanu  wrote:
> 
> Hi Konrad,
> 
> On Tue, 2018-01-23 at 13:13 +0100, Konrad Windszus wrote:
>> But before spinning a new release I would like to get some more
>> opinions on the basename handling of the i18n bundle in general
>> (compare with https://issues.apache.org/jira/browse/SLING-7421?focuse
>> dCommentId=16335677&page=com.atlassian.jira.plugin.system.issuetabpan
>> els:comment-tabpanel#comment-16335677677 <https://issues.apache.org/j
>> ira/browse/SLING-
>> 7421?focusedCommentId=16335677&page=com.atlassian.jira.plugin.system.
>> issuetabpanels:comment-tabpanel#comment-16335677>). I think most of
>> the users might assume something else when it comes to requesting a
>> dictionary without a basename. Right now it is not possible to
>> explicitly request a value from a dictionary which is not having the
>> basename property set.
> 
> Without knowing too much about the i18n bundle, I woudl separate fixing
> the regression from properly defining the future behaviour. 
> 
> I would like to get Sling 10 out the door with the same behaviour as
> Sling 9, rather than wait even more to get better basename handling.
> After all, no one complained so far :-)
> 
> Thanks,
> 
> Robert

Re: [VOTE] Release Apache Sling I18N Support 2.5.12

[Konrad Windszus]

> On 25. Jan 2018, at 15:16, Robert Munteanu  wrote:
> 
> Please vote to approve this release:
+1

Konrad

Re: [VOTE] Release Apache Sling I18N Support 2.5.12

[Konrad Windszus]

That is the general issue which is used for tracking the upgrade to parent 33 
for multiple modules. For i18n this is finished but other modules will follow...

> On 25. Jan 2018, at 15:27, Jason E Bailey  wrote:
> 
> One of the issues shows in progress?
> 
> 
> - Jason
> 
> On Thu, Jan 25, 2018, at 9:16 AM, Robert Munteanu wrote:
>> Hi,
>> 
>> We solved 3 issues in this release:
>> https://issues.apache.org/jira/projects/SLING/versions/12342247
>> 
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachesling-1862
>> 
>> 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 1862 /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: apache/sling as github landing repository

[Konrad Windszus]

Thanks, maybe we can use the branch from 
https://github.com/apache/sling-site/tree/scm-project-url-list 
 (mentioned in 
https://issues.apache.org/jira/browse/SLING-7161 
) as a basis instead. That 
provides already much more information and leveraging the already existing xml 
file from sling-aggregator is a good idea as long as 
https://issues.apache.org/jira/browse/SLING-7262 
 is not resolved.
Konrad

> On 26. Jan 2018, at 18:05, Bertrand Delacretaz  wrote:
> 
> Hi,
> 
> On Fri, Jan 26, 2018 at 12:54 AM, Alexander Klimetschek
>  wrote:
>> ...
>> 1. restore the apache/sling named repo...
>> 2. have a readme in there as the github landing page, just like any github 
>> project nowadays,
>> which should include an about project and most information how to use 
>> sling/download it...
> 
> I like the idea in general, thanks!
> 
> We already have download/build information on our website, I think we
> shouldn't duplicate - so either remove the webiste info or point to it
> from that README, but create something consistent and that does not
> easily get stale.
> 
> For now, I have created a list of all our repositories at
> http://sling.apache.org/repolist.html based on the XML list of
> projects generated at https://github.com/apache/sling-aggregator. It
> would be nice to expand it with a few words about each repository but
> I haven't checked how to generate that so far - and whether that would
> interfere with the repo tool.
> 
> -Bertrand

Re: [VOTE] Release Apache Sling Thread Support 3.2.16

[Konrad Windszus]

+1
Konrad

> On 29. Jan 2018, at 10:03, Robert Munteanu  wrote:
> 
> Hi,
> 
> We solved 5 issues in this release:
> https://issues.apache.org/jira/projects/SLING/versions/12342668
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1863
> 
> 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 1863 /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.
> 
> Thanks,
> 
> Robert

Re: [DISCUSSION] Rename Launchpad Starter

[Konrad Windszus]

+1
Konrad

Von meinem iPhone gesendet

> Am 09.02.2018 um 05:43 schrieb Daniel Klco :
> 
> All,
> 
> In https://issues.apache.org/jira/browse/SLING-7484 we're going to be
> moving the existing Launchpad Content into a sub-directory of /content to
> enable restricting access to / by default. As part of this, change we are
> suggesting:
> 
>   - Moving all root content to /content/starter
>   - Renaming the module to Starter Content
>   - Updating references in other bundles such as Starter and Auth Forms to
>   the new directory
> 
> Are there any objects to this approach?
> 
> My +1 for the change.

Re: wiki access

[Konrad Windszus]

Yes, I can confirm that in the past the individual users have been given access 
(not based on group memberships). If this is no longer accurate we need to fix 
https://sling.apache.org/documentation.html#the-public-wiki 
 as well.
Konrad

> On 16. Feb 2018, at 15:07, Jason Bailey  wrote:
> 
> Refencing this chain
> 
> http://sling.markmail.org/thread/bhbs2hgquwljnsj5
> 
> The last time this was brought up on the mailing list it was stated that 
> access was controlled the admins who are listed here
> https://cwiki.apache.org/confluence/spaces/viewspacesummary.action?key=SLING&showAllAdmins=true
> 
> -Jason
> 
> -Original Message-
> From: Robert Munteanu [mailto:romb...@apache.org] 
> Sent: Friday, February 16, 2018 2:36 AM
> To: dev@sling.apache.org
> Subject: Re: wiki access
> 
> EXTERNAL
> 
> Hi Jason,
> 
> On Thu, 2018-02-15 at 22:02 -0500, Jason E Bailey wrote:
>> Can someone with admin rights provide me with access to the wiki 
>> please?
>> user name:jeb
>> 
>> Thanks
>> - Jason
> 
> I see that the 'index' wiki page is accessible to the 'sling- committers' 
> group, but I don't see its membership listed anywhere. This might be synced 
> from LDAP, but uf you can't edit the page I suggest you contact infra about 
> it.
> 
> Thanks,
> 
> Robert

Minimum JCR access rights for a path-based Sling servlet

[Konrad Windszus]

Although it is currently stated at 
https://sling.apache.org/documentation/the-sling-engine/servlets.html#caveats-when-binding-servlets-by-path
 

 that no JCR repository acls are evaluated when accessing a servlet registered 
by path I always get back a 401 when trying to access such a servlet with an 
unprivileged user. Is there some minimum repository right being evaluated 
beforehand (i.e. by a servlet filter or the Sling Main Servlet somehow?).
Thanks for your input,
Konrad

Re: Minimum JCR access rights for a path-based Sling servlet

[Konrad Windszus]

Sorry for the noise, actually no right is necessary as correctly stated in the 
wiki. I had an issue with the user provisioning process.
Konrad

> On 19. Feb 2018, at 18:01, Konrad Windszus  wrote:
> 
> Although it is currently stated at 
> https://sling.apache.org/documentation/the-sling-engine/servlets.html#caveats-when-binding-servlets-by-path
>  
> <https://sling.apache.org/documentation/the-sling-engine/servlets.html#caveats-when-binding-servlets-by-path>
>  that no JCR repository acls are evaluated when accessing a servlet 
> registered by path I always get back a 401 when trying to access such a 
> servlet with an unprivileged user. Is there some minimum repository right 
> being evaluated beforehand (i.e. by a servlet filter or the Sling Main 
> Servlet somehow?).
> Thanks for your input,
> Konrad
> 

Re: [Maven] Updating to parent pom 33 breaks all projects

[Konrad Windszus]

Actually Oli switched to individual spec chapter artifacts and there was also 
some discussion triggered by me in the comments (e.g. 
https://issues.apache.org/jira/browse/SLING-7384?focusedCommentId=16327408&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16327408).

It was you Carsten, who answered and said
"But again, in general its better to use the above mentioned single purpose 
artifacts". 

Therefore you have to include the individual annotation artifacts (which are 
all managed in parent) in your project!
Please clarify if there was some misunderstanding there.
Konrad

> On 26. Feb 2018, at 12:15, Carsten Ziegeler  wrote:
> 
> Hi
> 
> it seems that updating to parent pom 33 is way harder than it should be.
> For an unknown reason the OSGi annotations are no longer declared as
> dependencies, requiring now each and every project to define
> them...which I think is really annoying.
> 
> The change in question is referencing SLING-7384, but I can't find a
> discussion nor reason in there. So why has this been done?
> 
> Regards
> Carsten
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [Maven] Updating to parent pom 33 breaks all projects

[Konrad Windszus]

@Carsten:
Which dependency exactly to you want to declare now? The aggregate one for 
annotations or the individual ones per annotation definition?

But I rather tend to agree with Oli here. We should really force every project 
to declare all(!) its dependencies. Having a dirty classpath for non-OSGi 
modules just because you derive from parent does not seem right to me.
This should be a one time effort (given that OSGi does not rename the artifacts 
again in the future).

Konrad

> On 26. Feb 2018, at 12:44, Carsten Ziegeler  wrote:
> 
> Well, how many non OSGi modules do we have? I totally agree that it's
> better to not declare dependencies in the parent pom. But every rule has
> an exception, and I think the annotations (not the api) are an exception.
> 
> Upgrading to the new parent pom is now really a pain.
> 
> Regards
> Carsten
> 
> Oliver Lietz wrote
>> On Monday 26 February 2018 12:15:16 Carsten Ziegeler wrote:
>>> Hi
>> 
>> Hi Carsten,
>> 
>>> it seems that updating to parent pom 33 is way harder than it should be.
>>> For an unknown reason the OSGi annotations are no longer declared as
>>> dependencies, requiring now each and every project to define
>>> them...which I think is really annoying.
>>> 
>>> The change in question is referencing SLING-7384, but I can't find a
>>> discussion nor reason in there. So why has this been done?
>> 
>> in my opinion dependencies should only be managed in parent and not 
>> declared. 
>> We have several modules which are "not OSGi" and they inherit those 
>> dependencies although not used at all.
>> 
>> Regards,
>> O.
>> 
>>> Regards
>>> Carsten
>> 
>> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [Maven] Updating to parent pom 33 breaks all projects

[Konrad Windszus]

This is true for every other managed dependency in parent as well.
We do maintain a certain baseline with parent and I think this is good.

Projects deliberately supporting older versions of the baseline cannot upgrade 
to the most recent parent then!

> On 26. Feb 2018, at 14:01, Carsten Ziegeler  wrote:
> 
> Sure works, but I guess it's better (yes arguing against myself now...)
> if each project references it's own version of those annotations :)
> Using a new version of the annotations and rebuilding your project will
> most likely bind your project to the latest DS version although you
> might not be using any feature of it. bnd uses the annotations package
> version to create the namespace for the XML (as far as I know).
> 
> Updating a parent pom should not bring such surprises, so therefore not
> having these things in the pom at all is probably the best option.
> 
> Carsten
> 
> 
> Oliver Lietz wrote
>> On Monday 26 February 2018 13:28:27 Carsten Ziegeler wrote:
>>> Yepp and following your argumentation then every project which starts to
>>> use R7 annotations can do so in its own pom.
>> 
>> I guess we release a new parent with new version for annotations and 
>> upgrading 
>> to that parent should be enough – or do you expect new Maven coordinates 
>> (again)?
>> 
>> Regards,
>> O.
>> 
>>> Let's leave it the way it is. It would just have been nice to hear about
>>> these breaking changes in some way. But I guess I could have seen this
>>> coming by watching the commits. So all fine
>>> 
>>> Carsten
>>> 
>>> 
>>> Oliver Lietz wrote
>>> 
 On Monday 26 February 2018 13:05:46 Carsten Ziegeler wrote:
> Well, it seems I'm the only one complaining anyway...
> 
> TBH, I don't see a real advantage in having these things in the
> dependency management at all then. But I guess, it will just be me
> again...
 
 I expect to see an update at least for versioning annotations with R7, no?
 
 O.
 
> Carsten
> 
> 
> Oliver Lietz wrote
> 
>> On Monday 26 February 2018 12:44:53 Carsten Ziegeler wrote:
>>> Well, how many non OSGi modules do we have? I totally agree that it's
>>> better to not declare dependencies in the parent pom. But every rule
>>> has
>>> an exception, and I think the annotations (not the api) are an
>>> exception.
>> 
>> The Maven and bnd plugins, Maven archetypes, the IDE modules and several
>> testing modules are non-OSGi – but I don't have any numbers.
>> 
>>> Upgrading to the new parent pom is now really a pain.
>> 
>> I don't think adding one or two dependencies is a big deal (correctness
>> vs
>> convenience) and we have already updated several modules to Parent 33.
>> If others disagree we can add back those annotations with Parent 34.
>> 
>> Regards,
>> O.
>> 
>>> Regards
>>> Carsten
>>> 
>>> Oliver Lietz wrote
>>> 
 On Monday 26 February 2018 12:15:16 Carsten Ziegeler wrote:
> Hi
 
 Hi Carsten,
 
> it seems that updating to parent pom 33 is way harder than it should
> be.
> For an unknown reason the OSGi annotations are no longer declared as
> dependencies, requiring now each and every project to define
> them...which I think is really annoying.
> 
> The change in question is referencing SLING-7384, but I can't find a
> discussion nor reason in there. So why has this been done?
 
 in my opinion dependencies should only be managed in parent and not
 declared. We have several modules which are "not OSGi" and they
 inherit
 those dependencies although not used at all.
 
 Regards,
 O.
 
> Regards
> Carsten
>> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [Maven] Updating to parent pom 33 breaks all projects

[Konrad Windszus]

> 
> Maybe we can have a compromise and require a property in the pom, e.g. 
> 
>  
>true
>  
> 
> That property will activate the OSGi-related profile from the parent
> pom.
> 
> Not ideal but still better than copy/pasting considerably more
> dependency versions.
> 

This is not supported by Maven. Only properties given via command line can be 
used for profile activation (see https://issues.apache.org/jira/browse/MNG-5127 
and a lot of related tickets). Therefore we would rather need to rely on 
existence of a dedicated marker file.

Re: [CANCELLED][VOTE] Release Apache Sling Scripting HTL Engine 1.0.50-1.3.1

[Konrad Windszus]

Would you consider including https://issues.apache.org/jira/browse/SLING-7516 
 in the upcoming release? The 
attached PR is IMHO pretty straight-forward.
Thanks,
Konrad

> On 7. Mar 2018, at 17:15, Radu Cotescu  wrote:
> 
> Sorry for the blunder - it seems I've run the wrong tests when validating
> the fix and I've introduced a regression. I'm therefore cancelling the
> release and reopening the issue.
> 
> Thanks,
> Radu
> 
> On Wed, 7 Mar 2018 at 15:44 Daniel Klco  wrote:
> 
>> +1
>> 
>> On Wed, Mar 7, 2018 at 9:01 AM, Radu Cotescu  wrote:
>> 
>>> Hi,
>>> 
>>> We solved 1 issue in this release:
>>> https://issues.apache.org/jira/projects/SLING/versions/12342848
>>> 
>>> Staging repository:
>>> https://repository.apache.org/content/repositories/orgapachesling-1881
>>> 
>>> You can use this UNIX script to download the release and verify the
>>> signatures:
>>> https://raw.githubusercontent.com/apache/sling-tooling-
>>> release/master/check_staged_release.sh
>>> 
>>> Usage:
>>> curl
>>> https://raw.githubusercontent.com/apache/sling-tooling-
>>> release/master/check_staged_release.sh
>>> | bash -s 1881
>>> 
>>> 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.
>>> 
>>> Cheers,
>>> Radu
>>> 
>> 

Re: Google Summer of Code 2018 Mentor Registration

[Konrad Windszus]

Very much +1 on SLING-7231.

> On 8. Mar 2018, at 14:03, Radu Cotescu  wrote:
> 
> Hi,
> 
> Is this something we could try this year? I've recently stumbled (again)
> upon an issue that could be an interesting summer project:
> https://issues.apache.org/jira/browse/SLING-7231
> The issue in question is fairly isolated from the rest of the stack, so the
> ramping-up period should be rather short, and IMO it would be a win-win
> situation.
> 
> Do we have other proposals that make sense?
> 
> Any ideas that we'd like to promote for GSoC should be on JIRA, labeled
> with 'gsoc2018' [4].
> 
> Cheers,
> Radu
> 
> [4] - https://issues.apache.org/jira/issues/?filter=12343065
> 
> -- Forwarded message -
> From: Ulrich Stärk 
> Date: Sat, 24 Feb 2018 at 22:20
> Subject: Google Summer of Code 2018 Mentor Registration
> To: 
> Cc: d...@community.apache.org 
> 
> 
> Dear PMCs,
> 
> I'm happy to announce that the ASF has made it onto the list of accepted
> organizations for
> Google Summer of Code 2018! [1,2]
> 
> It is now time for mentors to sign up, so please pass this email on to your
> community and
> podlings. If you aren’t already subscribed to ment...@community.apache.org
> you should do so now else
> you might miss important information.
> 
> Mentor signup requires two steps: mentor signup in Google's system [3] and
> PMC acknowledgement.
> 
> If you want to mentor a project in this year's SoC you will have to
> 
> 1. Be an Apache committer.
> 2. Request an acknowledgement from the PMC for which you want to mentor
> projects. Use the below
> template and *do not forget to copy ment...@community.apache.org*. We will
> use the email adress you
> indicate to send the invite to be a mentor for Apache.
> 
> PMCs, read carefully please.
> 
> We request that each mentor is acknowledged by a PMC member. This is to
> ensure the mentor is in good
> standing with the community. When you receive a request for
> acknowledgement, please ACK it and cc
> ment...@community.apache.org
> 
> Lastly, it is not yet too late to record your ideas in Jira (see my
> previous emails for details).
> Students will now begin to explore ideas so if you haven’t already done so,
> record your ideas
> immediately!
> 
> Cheers,
> 
> Uli
> 
> mentor request email template:
> 
> to: private@.apache.org
> cc: ment...@community.apache.org
> subject: GSoC 2018 mentor request for 
> 
>  PMC,
> 
> please acknowledge my request to become a mentor for Google Summer of Code
> 2018 projects for Apache
> .
> 
> I would like to receive the mentor invite to 
> 
> 
> 
> 
> 
> [1] https://summerofcode.withgoogle.com/organizations/
> [2] https://summerofcode.withgoogle.com/organizations/5718432427802624/
> [3] https://summerofcode.withgoogle.com/

Re: [VOTE] Release Apache Sling Testing Clients version 1.2.0 and Apache Sling Testing Rules 1.0.8

[Konrad Windszus]

+1
Konrad

> On 2. Apr 2018, at 12:30, Andrei Dulvac  wrote:
> 
> Bump.
> 
> On Fri, Mar 30, 2018, 09:41 Andrei Dulvac  wrote:
> 
>> Hi Robert.
>> 
>> There were no issues specifically fixed in the rules, just a commit to
>> update to this version of the clients.
>> 
>> 
>> On Thu, Mar 29, 2018, 14:23 Robert Munteanu  wrote:
>> 
>>> Hi Andrei,
>>> 
>>> On Thu, 2018-03-29 at 11:55 +, Andrei Dulvac wrote:
 We solved 4 issues in this release:
 
 https://issues.apache.org/jira/projects/SLING/versions/12342572
>>> 
>>> What is the changelog for the testing rules release?
>>> 
>>> Robert
>>> 
>> 

Bundle version for SNAPSHOTs generated by bnd-maven-plugin

[Konrad Windszus]

I am just migrating the OSGi Installer HC 
(https://github.com/apache/sling-org-apache-sling-installer-hc/) to the 
bnd-maven-plugin and I observed one difference to the maven-bundle-plugin:

The bundle version for SNAPSHOTs by default looks like "1.0.1." 
instead of "1.0.1.SNAPSHOT" (as it was with the maven-bundle-plugin).
The reason for that is this line: 
https://github.com/bndtools/bnd/blob/d7511968b0ec96f1bec5bd3de59f8010cb3cb9f1/maven/bnd-maven-plugin/src/main/java/aQute/bnd/maven/plugin/BndMavenPlugin.java#L262
 wich
sets the snapshot instruction to the timestamp 
(http://bnd.bndtools.org/instructions/snapshot.html). This leads to the 
SNAPSHOT qualifier in the version being replaced by the timestamp in the 
generated bundle version.

This is IMHO problematic in combination with the OSGi Installer, as that 
behaves differently when it detects a SNAPSHOT 
(https://github.com/apache/sling-org-apache-sling-installer-core/blob/1561f5e626bab4859b4c060ef1bec06026018f18/src/main/java/org/apache/sling/installer/core/impl/tasks/BundleInfo.java#L109).
 

Should we configure all our bundles in a way that SNAPSHOT in the version is 
not being replaced, or can we come up with a more intelligent solution in the 
OSGi Installer?
I noticed that in the manifest we have in addition still 
"Implementation-Version: 1.0.1-SNAPSHOT" on which we could maybe base the 
SNAPSHOT detection of the OSGi Installer.

WDYT?
Konrad

[VOTE] Release Apache Sling Installer Health Checks version 2.0.0

[Konrad Windszus]

Hi,

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

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

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 1893 /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.

Konrad

Re: Bundle version for SNAPSHOTs generated by bnd-maven-plugin

[Konrad Windszus]

By default the timestamp is having the format "MMddHHmm" 
(http://bnd.bndtools.org/macros/tstamp.html 
<http://bnd.bndtools.org/macros/tstamp.html>), this could be a problem in 
certain cases where you redeploy two builds within the same minute.


> On 9. Apr 2018, at 15:55, Justin Edelson  wrote:
> 
> I'm not sure this is problematic from the perspective of the installer. The
> point of the different SNAPSHOT handling is to support the use case of
> updating a bundle with the *same* bundle version. However, if the bundle
> versions are including a timestamp, it isn't needed since the bundle
> versions would be constantly increasing.
> 
> Now there could be a problem if the timestamp somehow not taking timezones
> into account, but assuming it is UNIX epoch based, then this won't be an
> issue.
> 
> Regards,
> Justin
> 
> On Fri, Apr 6, 2018 at 2:32 AM Konrad Windszus  wrote:
> 
>> I am just migrating the OSGi Installer HC (
>> https://github.com/apache/sling-org-apache-sling-installer-hc/) to the
>> bnd-maven-plugin and I observed one difference to the maven-bundle-plugin:
>> 
>> The bundle version for SNAPSHOTs by default looks like "1.0.1."
>> instead of "1.0.1.SNAPSHOT" (as it was with the maven-bundle-plugin).
>> The reason for that is this line:
>> https://github.com/bndtools/bnd/blob/d7511968b0ec96f1bec5bd3de59f8010cb3cb9f1/maven/bnd-maven-plugin/src/main/java/aQute/bnd/maven/plugin/BndMavenPlugin.java#L262
>> wich
>> sets the snapshot instruction to the timestamp (
>> http://bnd.bndtools.org/instructions/snapshot.html). This leads to the
>> SNAPSHOT qualifier in the version being replaced by the timestamp in the
>> generated bundle version.
>> 
>> This is IMHO problematic in combination with the OSGi Installer, as that
>> behaves differently when it detects a SNAPSHOT (
>> https://github.com/apache/sling-org-apache-sling-installer-core/blob/1561f5e626bab4859b4c060ef1bec06026018f18/src/main/java/org/apache/sling/installer/core/impl/tasks/BundleInfo.java#L109
>> ).
>> 
>> Should we configure all our bundles in a way that SNAPSHOT in the version
>> is not being replaced, or can we come up with a more intelligent solution
>> in the OSGi Installer?
>> I noticed that in the manifest we have in addition still
>> "Implementation-Version: 1.0.1-SNAPSHOT" on which we could maybe base the
>> SNAPSHOT detection of the OSGi Installer.
>> 
>> WDYT?
>> Konrad
>> 
>> 
>> 

Re: Bundle version for SNAPSHOTs generated by bnd-maven-plugin

[Konrad Windszus]

I added this requirement now to the newly created 
https://issues.apache.org/jira/browse/SLING-7575 
<https://issues.apache.org/jira/browse/SLING-7575>. We are blocked though by 
https://github.com/bndtools/bnd/issues/2265 
<https://github.com/bndtools/bnd/issues/2265> (until the release of 
bnd-maven-plugin 4.0).
Feel free to extend the list of common bnd instructions which should in the 
future be defined in our parent pom.
Thanks,
Konrad

> On 9. Apr 2018, at 16:30, Justin Edelson  wrote:
> 
> Oh yeah, then that's a problem. It really should be epoch-based IMO.
> 
> On Mon, Apr 9, 2018 at 10:28 AM Konrad Windszus  wrote:
> 
>> By default the timestamp is having the format "MMddHHmm" (
>> http://bnd.bndtools.org/macros/tstamp.html <
>> http://bnd.bndtools.org/macros/tstamp.html>), this could be a problem in
>> certain cases where you redeploy two builds within the same minute.
>> 
>> 
>>> On 9. Apr 2018, at 15:55, Justin Edelson 
>> wrote:
>>> 
>>> I'm not sure this is problematic from the perspective of the installer.
>> The
>>> point of the different SNAPSHOT handling is to support the use case of
>>> updating a bundle with the *same* bundle version. However, if the bundle
>>> versions are including a timestamp, it isn't needed since the bundle
>>> versions would be constantly increasing.
>>> 
>>> Now there could be a problem if the timestamp somehow not taking
>> timezones
>>> into account, but assuming it is UNIX epoch based, then this won't be an
>>> issue.
>>> 
>>> Regards,
>>> Justin
>>> 
>>> On Fri, Apr 6, 2018 at 2:32 AM Konrad Windszus  wrote:
>>> 
>>>> I am just migrating the OSGi Installer HC (
>>>> https://github.com/apache/sling-org-apache-sling-installer-hc/) to the
>>>> bnd-maven-plugin and I observed one difference to the
>> maven-bundle-plugin:
>>>> 
>>>> The bundle version for SNAPSHOTs by default looks like
>> "1.0.1."
>>>> instead of "1.0.1.SNAPSHOT" (as it was with the maven-bundle-plugin).
>>>> The reason for that is this line:
>>>> 
>> https://github.com/bndtools/bnd/blob/d7511968b0ec96f1bec5bd3de59f8010cb3cb9f1/maven/bnd-maven-plugin/src/main/java/aQute/bnd/maven/plugin/BndMavenPlugin.java#L262
>>>> wich
>>>> sets the snapshot instruction to the timestamp (
>>>> http://bnd.bndtools.org/instructions/snapshot.html). This leads to the
>>>> SNAPSHOT qualifier in the version being replaced by the timestamp in the
>>>> generated bundle version.
>>>> 
>>>> This is IMHO problematic in combination with the OSGi Installer, as that
>>>> behaves differently when it detects a SNAPSHOT (
>>>> 
>> https://github.com/apache/sling-org-apache-sling-installer-core/blob/1561f5e626bab4859b4c060ef1bec06026018f18/src/main/java/org/apache/sling/installer/core/impl/tasks/BundleInfo.java#L109
>>>> ).
>>>> 
>>>> Should we configure all our bundles in a way that SNAPSHOT in the
>> version
>>>> is not being replaced, or can we come up with a more intelligent
>> solution
>>>> in the OSGi Installer?
>>>> I noticed that in the manifest we have in addition still
>>>> "Implementation-Version: 1.0.1-SNAPSHOT" on which we could maybe base
>> the
>>>> SNAPSHOT detection of the OSGi Installer.
>>>> 
>>>> WDYT?
>>>> Konrad
>>>> 
>>>> 
>>>> 
>> 
>> 

Re: [PROPOSAL] replace sling committer list with link to apache phonebook

[Konrad Windszus]

+1

maybe we can use the homepage url in LDAP to maintain the organization (compare 
with https://people.apache.org/phonebook-about.html 
). Unfortunately that is not 
yet exposed in the Apache Phonebook.

> On 10. Apr 2018, at 15:01, Stefan Seifert  wrote:
> 
> currently we maintain a list of all committers and PMC members in a CMS page 
> on [1].
> this page is currently outdated, some committers are missing (e.g. david 
> bosschaert).
> 
> my proposal is to remove this manually maintained list and replace it with a 
> link to the apache phonebook [2]
> 
> pro:
> - no redundant data, no manual maintenance: phonebook is always based on the 
> "true source"
> - distinction between PMC members, chair and committers is clearly visible 
> (for vote counting)
> 
> con:
> - we lose some probably important information currently present on this page:
>  - organization (not maintained for all members)
>  - role
> 
> the page [1] contains also additional sections with emeritus members, thanks 
> etc. - these sections would remain untouched.
> 
> WDYT?
> 
> stefan
> 
> [1] https://sling.apache.org/project-information/project-team.html
> [2] https://people.apache.org/phonebook.html?pmc=sling
> 
> 

[RESULT] [VOTE] Release Apache Sling Installer Health Checks version 2.0.0

[Konrad Windszus]

Hi,

The vote has passed with the following result :

+1 (binding): Radu, Dan, Oli

I will copy this release to the Sling dist directory and
promote the artifacts to the central Maven repository.

Thanks for voting,
Konrad

Re: [LAZY] Removing .md5 digest files in our releases folder

[Konrad Windszus]

In general I agree with that. We should just defer the actual deletion until we 
figured out how to prevent MD5 generation for new releases in the first place.
Konrad

> Am 12.04.2018 um 17:34 schrieb Bertrand Delacretaz :
> 
> Hi,
> 
> Now that http://sling.apache.org/downloads.cgi points to sha1 digests,
> is anyone opposed to removing all .md5 files from
> https://dist.apache.org/repos/dist/release/sling/ ?
> 
> I have checked and each .md5 file has a .sha1 equivalent.
> 
> I'll go ahead and to that tomorrow or Monday unless someone objects
> (svn is our friend anyway).
> 
> (see https://issues.apache.org/jira/browse/SLING-7534 for context)
> 
> -Bertrand

Re: [VOTE] Release Apache Sling Commons Log 5.1.16

[Konrad Windszus]

You must be logged in for that.
I already reported that in https://issues.apache.org/jira/browse/INFRA-15862 
 but it seems this is a JIRA 
issue Atlassian doesn't want to fix to sell more licenses :-(

> On 24. Apr 2018, at 17:08, David Bosschaert  
> wrote:
> 
> Hi Julian,
> 
> When I open https://issues.apache.org/jira/projects/SLING/versions/12343096
> I'm getting an error. Is that link correct?
> 
> Best regards,
> 
> David
> 
> On 24 April 2018 at 15:55, Daniel Klco  wrote:
> 
>> +1
>> 
>> On Tue, Apr 24, 2018 at 8:18 AM, Julian Sedding 
>> wrote:
>> 
>>> Hi,
>>> 
>>> We solved 1 issues in the Apache Sling Commons Log 5.1.16 release:
>>> https://issues.apache.org/jira/projects/SLING/versions/12343096
>>> 
>>> Staging repository:
>>> https://repository.apache.org/content/repositories/orgapachesling-1895/
>>> 
>>> 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 1895 /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
>>> Julian
>>> 
>> 

Teleporter: deploy a test bundle, then use it from the client(!) side, afterwards undeploy it

[Konrad Windszus]

Hi,
since in general I very much like to keep related things together in most of 
the cases want to execute the IT in the same Maven module where the actual 
implementation is.

Therefore, teleporter rules are very handy, because they transparently create 
bundles only for the IT purpose and execute them remotely.
But sometimes I want to cover in the IT also the request starting on the client 
side, e.g. to check if a certain servlet/script is correctly deployed.

How can I combine these two approaches to have a special servlet only necessary 
for the IT (not part of the actual code) transparently deployed as dedicated 
test bundle and call that then from my test with an http client?
These are the steps which would be necessary:
1. create and deploy the test bundle containing my servlet with the teleporter
2. execute the IT leveraging an HTTP client to send a request to the previously 
deployed servlet
3. uninstall the test bundle

Any ideas how to accomplish that with either the existing teleporter rules or a 
small extension of them? 

Thanks,
Konrad

Re: [Dev][GSoC2018][OpenIDConnect] Using Apache Oltu OpenID Connect as a maven dependency

[Konrad Windszus]

Maybe it is worth to consider using 
https://bitbucket.org/connect2id/oauth-2.0-sdk-with-openid-connect-extensions/overview
 
.
It is having an Apache 2.0 license and seems to be quite actively maintained.
All releases are available from Maven Central.
Konrad

> On 6. May 2018, at 20:46, Hasini Witharana  wrote:
> 
> Hi all,
> 
> I want to use org.apache.oltu.openidconnect as a maven dependency. But this
> is not included in https://mvnrepository.com/artifact/org.apache.oltu .
> 
> I tried the instructions, given in https://stackoverflow.com/ques
> tions/23513141/resolve-oltu-openid-connect-dependency-in-maven . Still I
> get an error with the version. Their mailing list is not responding because
> Oltu is a retired project now.
> 
> Does anyone know how to achieve $subject?
> 
> Thank you.
> 
> -- 
> *Hasini Witharana*
> Undergraduate | Department of Computer Science and Engineering
> University of Moratuwa
> Linkedin 

XSS API: Don't modify certain unicode escape characters in the input string, e.g. for emojis

[Konrad Windszus]

If I understand the XSS API correctly, the only supported methods for HTML 
contexts are encodeForHtml 
(https://github.com/apache/sling-org-apache-sling-xss/blob/257e7096dad689a46d474d1f251d504ca5508db7/src/main/java/org/apache/sling/xss/impl/XSSAPIImpl.java#L419)
and encodeForHtmlAttr 
(https://github.com/apache/sling-org-apache-sling-xss/blob/257e7096dad689a46d474d1f251d504ca5508db7/src/main/java/org/apache/sling/xss/impl/XSSAPIImpl.java#L427).
Both always escape & with &!

What should I use if I still want to pertain certain Unicode escape characters 
(https://www.w3.org/International/questions/qa-escapes) like certain Emojis 
(e.g. ✅ should not be modified).
Is there already some support for this in the XSS API or if not, does it make 
sense to add support there?

Thanks,
Konrad

Re: XSS API: Don't modify certain unicode escape characters in the input string, e.g. for emojis

[Konrad Windszus]

Thanks for your input.
I created https://issues.apache.org/jira/browse/SLING-7658 
<https://issues.apache.org/jira/browse/SLING-7658>.
Konrad

> On 8. May 2018, at 17:45, Carsten Ziegeler  wrote:
> 
> Sounds like a bug to me
> 
> Carsten
> 
> 
> Konrad Windszus wrote
>> 
>> If I understand the XSS API correctly, the only supported methods for HTML 
>> contexts are encodeForHtml 
>> (https://github.com/apache/sling-org-apache-sling-xss/blob/257e7096dad689a46d474d1f251d504ca5508db7/src/main/java/org/apache/sling/xss/impl/XSSAPIImpl.java#L419)
>> and encodeForHtmlAttr 
>> (https://github.com/apache/sling-org-apache-sling-xss/blob/257e7096dad689a46d474d1f251d504ca5508db7/src/main/java/org/apache/sling/xss/impl/XSSAPIImpl.java#L427).
>> Both always escape & with &!
>> 
>> What should I use if I still want to pertain certain Unicode escape 
>> characters (https://www.w3.org/International/questions/qa-escapes) like 
>> certain Emojis (e.g. ✅ should not be modified).
>> Is there already some support for this in the XSS API or if not, does it 
>> make sense to add support there?
>> 
>> Thanks,
>> Konrad
>> 
> -- 
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org

Re: [VOTE] Release Apache Slingstart Maven Plugin version 1.8.0

[Konrad Windszus]

-1 from my side.

I think I found a regression. Compare with 
https://issues.apache.org/jira/browse/SLING-7662?focusedCommentId=16471979&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16471979
 
.
Konrad

> On 9. May 2018, at 11:06, dav...@apache.org wrote:
> 
> Hi all,
> 
> We solved 1 issue in this release:
> https://issues.apache.org/jira/projects/SLING/versions/12342542
> 
> As this release adds new functionality the minor version of this component
> is increased.
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1902
> 
> 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 1902 /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.
> 
> Best regards,
> 
> David

Re: JSR 305 annotations (nullability)

[Konrad Windszus]

There are some ideas in https://issues.apache.org/jira/browse/SLING-7312 
 but not yet a solution, as 
even the proposed alternative spotbugs-annotations is not yet JSR-305 free 
(which might be problematic from a licensing point of view). But IMHO the 
spotbugs annotations are the best alternative: 
https://github.com/spotbugs/spotbugs/tree/release-3.1/spotbugs-annotations/src/main/java/edu/umd/cs/findbugs/annotations
 
,
 because they are not bound to a specific IDE and are still supported by 
spotbugs/findbugs. The only thing I am not sure about is whether SonarQube 
natively supports spotbugs-annotations.
Konrad

> On 15. May 2018, at 15:26, Julian Reschke  wrote:
> 
> Hi there,
> 
> does the Sling team have a plan how to move away from the JSR 305 annotations?
> 
> See
> 
> 
> 
> and
> 
> 
> 
> 
> It would probably good to coordinate with Jackrabbit Oak; see 
> ...
> 
> Best regards, Julian

Re: JSR 305 annotations (nullability)

[Konrad Windszus]

IMHO migration from JSR-305 to 
https://github.com/spotbugs/spotbugs/tree/release-3.1/spotbugs-annotations/src/main/java/edu/umd/cs/findbugs/annotations
 
<https://github.com/spotbugs/spotbugs/tree/release-3.1/spotbugs-annotations/src/main/java/edu/umd/cs/findbugs/annotations>
 is very painless, because the former evolved from the latter. You only need to 
adjust the package name but the semantics of the annotations are the same. Also 
it has most probably the best tooling/IDE support because those are by far the 
oldest nullability annotations (invented by FindBugs before JSR-305 has even 
been started). Now they are actively maintained by the spotbugs community. I 
currently fail to see a better alternative, but I am open to other suggestions.
Konrad

> On 15. May 2018, at 17:12, Julian Reschke  wrote:
> 
> On 2018-05-15 16:39, Konrad Windszus wrote:
>> There are some ideas in https://issues.apache.org/jira/browse/SLING-7312 
>> <https://issues.apache.org/jira/browse/SLING-7312> but not yet a solution, 
>> as even the proposed alternative spotbugs-annotations is not yet JSR-305 
>> free (which might be problematic from a licensing point of view). But IMHO 
>> the spotbugs annotations are the best alternative: 
>> https://github.com/spotbugs/spotbugs/tree/release-3.1/spotbugs-annotations/src/main/java/edu/umd/cs/findbugs/annotations
>>  
>> <https://github.com/spotbugs/spotbugs/tree/release-3.1/spotbugs-annotations/src/main/java/edu/umd/cs/findbugs/annotations>,
>>  because they are not bound to a specific IDE and are still supported by 
>> spotbugs/findbugs. The only thing I am not sure about is whether SonarQube 
>> natively supports spotbugs-annotations.
>> Konrad
> 
> It seems everybody agrees on the goal to move away, however it's not clear 
> what to move to (see for instance, 
> <https://github.com/google/guava/issues/2960>).
> 
> Best regards, Julian
> 

Depending on SNAPSHOT parent pom

[Konrad Windszus]

Hi, does anyone have any idea, why the Jenkins cannot resolve the latest parent 
SNAPSHOT 
(https://builds.apache.org/view/S-Z/view/Sling/job/sling-org-apache-sling-servlets-annotations-it-1.8/3/
 
)?
Is the snapshot repo being added in the Jenkins' settings.xml?
I remember vaguely an issue (that was also raised with INFRA) with that but I 
could not find any references.
Does anyone have a hint?

If we really have a limitation here, I would like to document that at 
https://cwiki.apache.org/confluence/display/SLING/Sling+Jenkins+Setup 


Thanks,
Konrad

Re: Depending on SNAPSHOT parent pom

[Konrad Windszus]

Found it, it was tracked in https://issues.apache.org/jira/browse/INFRA-15815 
<https://issues.apache.org/jira/browse/INFRA-15815>.

> On 29. May 2018, at 19:24, Konrad Windszus  wrote:
> 
> Hi, does anyone have any idea, why the Jenkins cannot resolve the latest 
> parent SNAPSHOT 
> (https://builds.apache.org/view/S-Z/view/Sling/job/sling-org-apache-sling-servlets-annotations-it-1.8/3/
>  
> <https://builds.apache.org/view/S-Z/view/Sling/job/sling-org-apache-sling-servlets-annotations-it-1.8/3/>)?
> Is the snapshot repo being added in the Jenkins' settings.xml?
> I remember vaguely an issue (that was also raised with INFRA) with that but I 
> could not find any references.
> Does anyone have a hint?
> 
> If we really have a limitation here, I would like to document that at 
> https://cwiki.apache.org/confluence/display/SLING/Sling+Jenkins+Setup 
> <https://cwiki.apache.org/confluence/display/SLING/Sling+Jenkins+Setup>
> 
> Thanks,
> Konrad
> 
> 

Re: Depending on SNAPSHOT parent pom

[Konrad Windszus]

I documented this limitation now in 
https://cwiki.apache.org/confluence/display/SLING/Sling+Jenkins+Setup#SlingJenkinsSetup-SNAPSHOTparentversions
 
<https://cwiki.apache.org/confluence/display/SLING/Sling+Jenkins+Setup#SlingJenkinsSetup-SNAPSHOTparentversions>.

> On 29. May 2018, at 19:30, Konrad Windszus  wrote:
> 
> Found it, it was tracked in https://issues.apache.org/jira/browse/INFRA-15815 
> <https://issues.apache.org/jira/browse/INFRA-15815>.
> 
>> On 29. May 2018, at 19:24, Konrad Windszus  wrote:
>> 
>> Hi, does anyone have any idea, why the Jenkins cannot resolve the latest 
>> parent SNAPSHOT 
>> (https://builds.apache.org/view/S-Z/view/Sling/job/sling-org-apache-sling-servlets-annotations-it-1.8/3/
>>  
>> <https://builds.apache.org/view/S-Z/view/Sling/job/sling-org-apache-sling-servlets-annotations-it-1.8/3/>)?
>> Is the snapshot repo being added in the Jenkins' settings.xml?
>> I remember vaguely an issue (that was also raised with INFRA) with that but 
>> I could not find any references.
>> Does anyone have a hint?
>> 
>> If we really have a limitation here, I would like to document that at 
>> https://cwiki.apache.org/confluence/display/SLING/Sling+Jenkins+Setup 
>> <https://cwiki.apache.org/confluence/display/SLING/Sling+Jenkins+Setup>
>> 
>> Thanks,
>> Konrad
>> 
>> 
> 

Plan to release servlet annotations (https://issues.apache.org/jira/browse/SLING-7624)

[Konrad Windszus]

Since the discussion around the servlet annotations in 
https://issues.apache.org/jira/browse/SLING-7624 
 settled a bit I would like 
to do a first release soon. Please raise your voice now if you have any 
concerns with the annotations how they are currently structured 
(https://github.com/apache/sling-org-apache-sling-servlets-annotations 
).
I plan on starting the release vote next week, in parallel I will also extend 
the documentation at 
https://sling.apache.org/documentation/the-sling-engine/servlets.html 
 to 
document the new annotations and also give some hints on how to migrate from 
SCR annotations.

Thanks,
Konrad

Re: Committer access to sling-dist (Was: Re: [RESULT][VOTE] Release Apache Sling Feature, Feature-IO, Feature-Analyser and Feature-ModelConverter 0.1.2)

[Konrad Windszus]

+1 on letting committers copy to dist as well. We have release votes so any PMC 
member can express concerns previously!
Also since most of the artifacts are anyhow consumed via Maven Central it would 
not be a very wise decision to not publish a released artifact to dist (for 
whatever reason!)

> On 8. Jun 2018, at 16:48, dav...@apache.org wrote:
> 
> Hi all,
> 
> On 8 June 2018 at 15:29,  wrote:
> 
>> I will copy this release to the Sling dist directory and promote the
>> artifacts to the central Maven repository.
>> 
>> 
> Actually, copying to the Sling dist directory can apparently only be done
> by PMC members (see
> http://sling.apache.org/documentation/development/release-management.html#promoting-the-release
> ).
> It's a bit strange because as a committer I can publish the artifact into
> Maven Central.
> 
> According to http://www.apache.org/legal/release-policy.html#upload-ci
> "The PMC can also vote to let non-PMC-members update the dist/release area.
> To get this set up, please open a JIRA ticket at the INFRA JIRA referencing
> the PMC vote."
> 
> Would it be an idea to change the rules around the Sling dist directory so
> that committers can also commit to it in addition to PMC members? Then I
> can finish the tasks relating to this release without having to bother
> anyone else :)
> 
> Best regards,
> 
> David

Re: Using declarative services in sling-commons-mime?

[Konrad Windszus]

I am in favor of applying your PR. It simplifies the code and I fail to see any 
regressions/drawbacks.
Konrad

> Am 11.06.2018 um 18:13 schrieb Christian Schneider :
> 
> Some time ago I proposed a change in sling-commons-mime to use declarative
> services instead of BundleActivator for registering the mime types.
> 
> See:
> https://issues.apache.org/jira/browse/SLING-7612
> 
> The code simplifies the setup quite a bit as the service creation and
> destruction is done by DS and the properties are derived from the
> annotations.
> 
> Bertrand was a bit worried about changed timings as this is a low level
> bundle and so with DS involved services might come up a bit later as before.
> 
> What do you think?
> 
> Christian
> 
> -- 
> -- 
> Christian Schneider
> http://www.liquid-reality.de
> 
> Computer Scientist
> http://www.adobe.com

[VOTE] Release Apache Sling Servlet Annotations 1.0.0

[Konrad Windszus]

Hi,

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

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

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 1915 /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.

Konrad

Re: [VOTE] Release Apache Sling Thread Support 3.2.18

[Konrad Windszus]

+1

Konrad

> On 13. Jun 2018, at 17:04, Robert Munteanu  wrote:
> 
> Hi,
> 
> We solved 2 issues in this release:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SLING%20AND%20fixVersion%20%3D%20%22Commons%20Threads%203.2.18%22
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-1914
> 
> 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 1914 /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.
> 
> Thanks,
> 
> Robert

Sling IDE Tooling: Debugging does no longer work with the provided launcher configuration

[Konrad Windszus]

I tried to work on some Sling IDE Tooling issues and for that need to start 
Eclipse with the tooling included in debug mode. There is even a laucher for 
that included in 
https://github.com/apache/sling-ide-tooling/blob/42a964b8961c4951f68053b9ac455abadd8595d6/eclipse/target-definition/Sling%20IDE%20Tooling.launch#L33
 which lists all necessary plugins.
Unfortunately when I use this launcher config to debug Eclipse it emits the 
following error message:

ENTRY org.apache.sling.ide.eclipse-core 4 0 2018-06-15 14:32:25.095
!MESSAGE FrameworkEvent ERROR
!STACK 0
org.osgi.framework.BundleException: Could not resolve module: 
org.apache.sling.ide.eclipse-core [48]
  Unresolved requirement: Import-Package: org.apache.sling.ide.artifacts

at org.eclipse.osgi.container.Module.start(Module.java:444)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1634)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1613)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1585)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1528)
at 
org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
at 
org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
at 
org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)

When I try open the provided launcher configuration in Eclipse it always shows 
"Launch with all workspace and enabled target plugins" which does not work, 
because shared/modules/artifacts is no longer detected as Eclipse plugin (and 
still necessary to run Sling IDE Tooling).

I tried to set both target definitions (both dev and non-dev) but did not 
succeed. Every time Eclipse is not launched with the module "artifacts".
I am using Eclipse 4.7.2 to launch.

Does anyone have any idea?
Also I am wondering, if it is the right approach to maintain both the required 
plugins both in the target definition file (2 times, for dev and non-dev) and 
also within the Eclipse launcher now. This seems to be a very error-prone 
process...

Thanks,
Konrad

Re: Sling IDE Tooling: Debugging does no longer work with the provided launcher configuration

[Konrad Windszus]

Ok, I figured out I explicitly had to configure "artifact" and "api" as Eclipse 
Plugins to make Eclipse treat them correctly. Isn't there an automated way to 
do that (e.g. by commiting the .project file and build.properties)? Those files 
shouldn't do any harm to IntelliJ as they are only considered in Eclipse and 
should make setting up the project much easier for all developers in Eclipse.


> On 15. Jun 2018, at 14:40, Konrad Windszus  wrote:
> 
> I tried to work on some Sling IDE Tooling issues and for that need to start 
> Eclipse with the tooling included in debug mode. There is even a laucher for 
> that included in 
> https://github.com/apache/sling-ide-tooling/blob/42a964b8961c4951f68053b9ac455abadd8595d6/eclipse/target-definition/Sling%20IDE%20Tooling.launch#L33
>  which lists all necessary plugins.
> Unfortunately when I use this launcher config to debug Eclipse it emits the 
> following error message:
> 
> ENTRY org.apache.sling.ide.eclipse-core 4 0 2018-06-15 14:32:25.095
> !MESSAGE FrameworkEvent ERROR
> !STACK 0
> org.osgi.framework.BundleException: Could not resolve module: 
> org.apache.sling.ide.eclipse-core [48]
>  Unresolved requirement: Import-Package: org.apache.sling.ide.artifacts
> 
>   at org.eclipse.osgi.container.Module.start(Module.java:444)
>   at 
> org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1634)
>   at 
> org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1613)
>   at 
> org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1585)
>   at 
> org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1528)
>   at 
> org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)
>   at 
> org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
>   at 
> org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
> 
> When I try open the provided launcher configuration in Eclipse it always 
> shows "Launch with all workspace and enabled target plugins" which does not 
> work, because shared/modules/artifacts is no longer detected as Eclipse 
> plugin (and still necessary to run Sling IDE Tooling).
> 
> I tried to set both target definitions (both dev and non-dev) but did not 
> succeed. Every time Eclipse is not launched with the module "artifacts".
> I am using Eclipse 4.7.2 to launch.
> 
> Does anyone have any idea?
> Also I am wondering, if it is the right approach to maintain both the 
> required plugins both in the target definition file (2 times, for dev and 
> non-dev) and also within the Eclipse launcher now. This seems to be a very 
> error-prone process...
> 
> Thanks,
> Konrad

[RESULT] [VOTE] Release Apache Sling Servlet Annotations 1.0.0

[Konrad Windszus]

Hi, 
The vote has passed with the following result : 

+1 (binding): Dan, Radu, Robert

I will copy this release to the Sling dist directory and promote the artifacts 
to the central Maven repository.

Thanks for voting,
Konrad

JBake Build has error java.lang.ArrayIndexOutOfBoundsException: 3 for downloads.html

[Konrad Windszus]

When building locally the Sling Site I get the following error:

...
[ERROR] Rendering 
[/Users/konradwindszus/git/sling-site/target/sling-site-0.1-SNAPSHOT/downloads.html]...
 failed!
org.jbake.template.RenderingException: 
java.lang.ArrayIndexOutOfBoundsException: 3
at org.jbake.template.GroovyMarkupTemplateEngine.renderDocument 
(GroovyMarkupTemplateEngine.java:53)
at org.jbake.template.DelegatingTemplateEngine.renderDocument 
(DelegatingTemplateEngine.java:65)
at org.jbake.app.Renderer.render (Renderer.java:209)
at org.jbake.render.DocumentsRenderer.render (DocumentsRenderer.java:25)
at org.jbake.app.Oven.bake (Oven.java:151)
at org.jbake.maven.GenerateMojo.reRender (GenerateMojo.java:95)
at org.jbake.maven.WatchMojo.executeInternal (WatchMojo.java:87)
at org.jbake.maven.GenerateMojo.execute (GenerateMojo.java:67)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo 
(DefaultBuildPluginManager.java:134)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:154)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute 
(MojoExecutor.java:146)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject 
(LifecycleModuleBuilder.java:81)
at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
 (SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute 
(LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke 
(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke 
(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced 
(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch 
(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode 
(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main 
(Launcher.java:356)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 3
at org.codehaus.groovy.runtime.BytecodeInterface8.objectArrayGet 
(BytecodeInterface8.java:363)
at 
downloads$_run_closure3$_closure5$_closure6$_closure7$_closure12$_closure31$_closure32$_closure33.doCall
 (downloads.tpl:389)
at 
downloads$_run_closure3$_closure5$_closure6$_closure7$_closure12$_closure31$_closure32$_closure33.call
 (downloads.tpl)
at groovy.text.markup.BaseTemplate.writeBody (BaseTemplate.java:277)
at groovy.text.markup.BaseTemplate.methodMissing (BaseTemplate.java:253)
at 
downloads$_run_closure3$_closure5$_closure6$_closure7$_closure12$_closure31$_closure32.doCall
 (downloads.tpl)
at 
downloads$_run_closure3$_closure5$_closure6$_closure7$_closure12$_closure31$_closure32.call
 (downloads.tpl)
at org.codehaus.groovy.runtime.DefaultGroovyMethods.each 
(DefaultGroovyMethods.java:2040)
at org.codehaus.groovy.runtime.DefaultGroovyMethods.each 
(DefaultGroovyMethods.java:2025)
at org.codehaus.groovy.runtime.DefaultGroovyMethods.each 
(DefaultGroovyMethods.java:2066)
at 
downloads$_run_closure3$_closure5$_closure6$_closure7$_closure12$_closure31.doCall
 (downloads.tpl:384)
at 
downloads$_run_closure3$_closure5$_closure6$_closure7$_closure12$_closure31.call
 (downloads.tpl)
at groovy.text.markup.BaseTemplate.writeBody (BaseTemplate.java:277)
at groovy.text.markup.BaseTemplate.methodMissing (BaseTemplate.java:253)
at downloads$_run_closure3$_closure5$_closure6$_closure7$_closure12.doCall 
(downloads.tpl:382)
at downloads$_run_closure3$_closure5$_closure6$_closure7$_closure12.call 
(downloads.tpl)
at groovy.text.markup.BaseTemplate.writeBody (BaseTemplate.java:277)
at groovy.text.markup.BaseTemplate.methodMissing (BaseTemplate.java:253)
at downloads$_run_closure3$_closure5$_closure6$_closure7.doCall 
(downloads.tpl:380)
at downloads$_run_closure3$_closure5$_closure6$_closure7.call 
(downloads.tpl)
at groovy.text.markup.BaseTemplate.writeBody (BaseTemplate.java:277)
at groovy.text.markup.BaseTemplate.methodMissing (BaseTemplate.java:253)
at downloads$_run_closure3$_closure5$_closure6.doCall (downloads.tpl)
at downloads$_run_closure3$_closure5$_closure6

Configuration File Format for OSGi Installer: https://issues.apache.org/jira/browse/SLING-7757

[Konrad Windszus]

Currently the OSGi Installer is relying on the ConfigurationHandler from the 
ConfigAdmin to parse *.config files 
(https://github.com/apache/sling-org-apache-sling-installer-core/blob/0a34e33dd26092437be5180e34979abbf9a88300/src/main/java/org/apache/sling/installer/core/impl/InternalResource.java#L257).
 

According to 
https://issues.apache.org/jira/browse/FELIX-5306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16526093#comment-16526093
 it seems that now the Felix Utils ConfigurationHandler 
(https://github.com/apache/felix/blob/trunk/utils/src/main/java/org/apache/felix/utils/properties/ConfigurationHandler.java)
 is the more stable parser, as it is used by the FileInstaller (so even in the 
future, we can rely on it being backwards compatible) while the 
ConfigurationHandler of the ConfigAdmin should only be used by Felix 
internally. Also the latter supports user-friendly float/double notation.

Does anything speak against switching from the CA one to the Felix Utils one 
(https://issues.apache.org/jira/browse/SLING-7757)?
IIUC both should be compatible (as the latter is a fork from the former).

The initial driver really is user-friendly float/double value support but I 
think in general it is preferable to rely on a stable parser/serializer.

The write-back would need to be modified at the same time in the File Installer 
(https://github.com/apache/sling-org-apache-sling-installer-provider-file/blob/ba2153071d71251c1c31402b6f39cc2061bf63cf/src/main/java/org/apache/sling/installer/provider/file/impl/FileInstaller.java#L204)
 and the JCR installer 
(https://github.com/apache/sling-org-apache-sling-installer-provider-jcr/blob/7fbd3963466ccd5ef8cf7eae6498f2f565e04931/src/main/java/org/apache/sling/installer/provider/jcr/impl/JcrInstaller.java#L780).

What do you think?
Thanks in advance for the input,
Konrad

Re: Configuration File Format for OSGi Installer: https://issues.apache.org/jira/browse/SLING-7757

[Konrad Windszus]

There are quite some tests in 
https://github.com/apache/felix/blob/trunk/utils/src/test/java/org/apache/felix/utils/properties/ConfigurationHandlerTest.java
 
<https://github.com/apache/felix/blob/trunk/utils/src/test/java/org/apache/felix/utils/properties/ConfigurationHandlerTest.java>.

> On 2. Jul 2018, at 11:40, Bertrand Delacretaz  wrote:
> 
> Hi,
> 
> On Thu, Jun 28, 2018 at 4:57 PM Konrad Windszus  wrote:
>> ...Does anything speak against switching from the CA one to the Felix Utils 
>> one (https://issues.apache.org/jira/browse/SLING-7757)?
>> IIUC both should be compatible (as the latter is a fork from the former). ...
> 
> Do we (or Felix) have tests that demonstrate that?
> 
> -Bertrand

Re: [Proposal] Default compiler should be changed to JRE8 in parent pom

[Konrad Windszus]

I would  recommend to not provide a default compiler class version at all but 
rather force each inheriting module to set that explicitly via a property. 
There is even a Maven enforcer rule which makes Maven builds fail in case that 
property is not set. 
That way each module must define the compatibility on its own!
Konrad

Von meinem iPhone gesendet

> Am 05.07.2018 um 17:11 schrieb Nicolas Peltier :
> 
> isn't this also a removal of sling support for java 7 ?
> leaving the option to compile with it does not help as soon as you get java
> 8 specificities
> 
> i'm not saying i'm against it, just that it's not just a default language
> level change, and we should be clearer if we do it
> 
>> Le jeu. 5 juil. 2018 à 17:09, Jason E Bailey  a écrit :
>> 
>> I'm proposing we update the parent pom so that JRE8 is the default
>> compilation level.
>> 
>> This should not break code except for extreme corner cases
>> http://www.oracle.com/technetwork/java/javase/8-compatibility-guide-2156366.html
>> 
>> This will provide access to language improvements that are in Java8 for
>> all development.
>> 
>> 
>> - Jason
>> 

Re: Where is OSGi Configuration read Sling JCR?

[Konrad Windszus]

This is more a question for the Sling Users mailing list, but 
http://sling.apache.org/documentation/bundles/osgi-installer.html 
 should 
contain some information about that.

> On 9. Jul 2018, at 16:32, Andreas Schaefer  wrote:
> 
> Hi
> 
> I was wondering if anyone know where any OSGi configuration is read from the 
> JCR tree (*.config, *.xml files)?
> 
> Is there a Sling class involved or is that done inside Felix and Jackrabbit 
> Oak?
> 
> Thanks - Andreas Schaefer Sr.

Re: Sling Hackathon Sept. 13th, 2018 in Berlin

[Konrad Windszus]

I would like to join as well.
Konrad

> On 18. May 2018, at 15:07, Stefan Seifert  wrote:
> 
> same as last year, we have the possibility to host a "Sling Hackathon" in 
> berlin in september.
> 
> the date is thursday 13.09.18 which is directly after the adaptTo() which 
> takes place 10-12.9.18 in potsdam (20min with train to our office).
> 
> the hackathon will take place in the office of pro!vision GmbH, 
> Berlin-Charlottenburg.
> 
> we should be at least 4 or 5 participants and have room for up to 20 people.
> 
> if you are interested and want to participate: please send me a private mail 
> or a reply on this list!
> 
> stefan
> 
> p.s. we will again reserve a time slot for a "sling committer round table" on 
> the tuesday 11.9. evening during the adaptTo().
> 
> 

Re: [PROPOSAL] Donating a tool able to generate markdown documentation from annotations

[Konrad Windszus]

Hi Simone,
this looks great. Just some comments:
> 
> How it works: it is a plain Java8 annotations processor, able to generate
> documentations for:
> 
> * SlingServlet annotated components;
> * (Deprecated) Felix SCR annotations (we still have lot of components in
> the repo which use such annotations, i.e. Apache Sling Distribution Core)
> * OSGi Component/Metatype annotations

What about instead acting on top of the generated component definitions or 
metatype resources? That way you would be independent of how they have been 
generated?
Konrad

Re: [VOTE] Switch from JSR-305 annotations to Jetbrains Annotations for all Sling Models

[Konrad Windszus]

+1

> On 2. Aug 2018, at 10:55, Stefan Seifert  wrote:
> 
> as recently discussed in SLING-7312 and the mailing list the JSR-305 
> annotations for null-analysis (javax.annotations) we are currently using 
> break our compatibility with Java 9. the problem is that JSR-305 was never 
> accepted and thus it's hard and troublesome to use them in Java 9 (see [1]). 
> there are several alternatives for nullable annotations with good tool 
> support, but some of them (e.g. findbugs/spotbugs annotations) use a license 
> not fully compatible with the apache license (discussed in [2]).
> 
> the jackrabbit/oak team has decided to switch to jetbrains annotations 
> [3][4][5] and developed some tooling to ease the migration. although coming 
> from the manufacturer of IntelliJ there is wide tool support for them e.g. in 
> FindBugs/SpotBugs, Sonar and can be configured in Eclipse as well.
> 
> i've created a ticket [6] to describe the steps we need to go and which sling 
> modules are affected. this ticket is about to get a consensus that the 
> jetbrains annotations are the way we want to go.
> 
> benefits:
> - removes a blocker from achieving Java 9 compatibility
> - same annotations as used by jackrabbit/oak
> - tooling for migration available
> - jetbrains annotations use apache 2.0 license
> - wide-spread tooling support for jetbrains annotations (which would not be 
> the case if we develop our own annotations)
> 
> drawbacks:
> - the jetbrains annotations include some more (mostly IntelliJ-specific) 
> annotations than only the nullable annotations
> - the jetbrains annotations are no "standard annotations"
> 
> 
> Please vote to approve switching to Jetbrains Annotations:
> 
>  [ ] +1 Switch to Jetbrains Annotations
>  [ ]  0 Don't care
>  [ ] -1 Don't switch to Jetbrains Annotations
> 
> 
> stefan
> 
> 
> [1] https://blog.codefx.org/java/jsr-305-java-9/
> [2] https://issues.apache.org/jira/browse/JCR-4301
> [3] https://www.jetbrains.com/help/idea/nullable-and-notnull-annotations.html
> [4] http://repo1.maven.org/maven2/org/jetbrains/annotations/16.0.2/
> [5] https://github.com/JetBrains/java-annotations
> [6] https://issues.apache.org/jira/browse/SLING-7798
> 
> 

Re: [VOTE] Switch from JSR-305 annotations to Jetbrains Annotations for all Sling Models

[Konrad Windszus]

> However, I wanted to point out option b). IIRC, there is nothing
> preventing us to just provide the package ourselves and then it would be
> problem solved, no?

Unfortunately not, due to potential split-packages: 
https://blog.codefx.org/java/jsr-305-java-9/ 

> 
> 
> regards,
> 
> Karl
> 
> On Thursday, August 2, 2018, Julian Reschke  wrote:
> 
>> On 2018-08-02 10:55, Stefan Seifert wrote:
>> 
>>> ...
>>> benefits:
>>> - removes a blocker from achieving Java 9 compatibility
>>> 
>> 
>> AFAICT, it's only Java 11 where there's an actual compat problem (but yes,
>> that'll be the version we need to support soonish).
>> 
>> ... > drawbacks:
>>> - the jetbrains annotations include some more (mostly IntelliJ-specific)
>>> annotations than only the nullable annotations
>>> - the jetbrains annotations are no "standard annotations"
>>> ...
>>> 
>> 
>> Well, if there were "standard annotations" for this, we'd use them :-)
>> 
>>> ...
>> 
>> Best regards, Julian
>> 
> 
> 
> -- 
> Karl Pauls
> karlpa...@gmail.com

Re: [VOTE] Switch from JSR-305 annotations to Jetbrains Annotations for all Sling Models

[Konrad Windszus]

At Sling we use other classes from javax.annotation as well (compare with 
https://issues.apache.org/jira/browse/SLING-7135 
<https://issues.apache.org/jira/browse/SLING-7135>). So most probably we have 
to rely on the official Oracle replacement and the question for me is how that 
behaves in the context of Java 8 which exports javax.annotation from the system 
bundle.

> On 2. Aug 2018, at 12:11, Karl Pauls  wrote:
> 
> Would would be the problem with that? I wasn’t talking about a jpms module
> - IMO, we can just create a bundle that contains and exports
> javax.annotation and be done with it think.
> 
> regards,
> 
> Karl
> 
> On Thursday, August 2, 2018, Konrad Windszus  wrote:
> 
>> 
>>> However, I wanted to point out option b). IIRC, there is nothing
>>> preventing us to just provide the package ourselves and then it would be
>>> problem solved, no?
>> 
>> Unfortunately not, due to potential split-packages:
>> https://blog.codefx.org/java/jsr-305-java-9/ <
>> https://blog.codefx.org/java/jsr-305-java-9/>
>>> 
>>> 
>>> regards,
>>> 
>>> Karl
>>> 
>>> On Thursday, August 2, 2018, Julian Reschke 
>> wrote:
>>> 
>>>> On 2018-08-02 10:55, Stefan Seifert wrote:
>>>> 
>>>>> ...
>>>>> benefits:
>>>>> - removes a blocker from achieving Java 9 compatibility
>>>>> 
>>>> 
>>>> AFAICT, it's only Java 11 where there's an actual compat problem (but
>> yes,
>>>> that'll be the version we need to support soonish).
>>>> 
>>>> ... > drawbacks:
>>>>> - the jetbrains annotations include some more (mostly
>> IntelliJ-specific)
>>>>> annotations than only the nullable annotations
>>>>> - the jetbrains annotations are no "standard annotations"
>>>>> ...
>>>>> 
>>>> 
>>>> Well, if there were "standard annotations" for this, we'd use them :-)
>>>> 
>>>>> ...
>>>> 
>>>> Best regards, Julian
>>>> 
>>> 
>>> 
>>> --
>>> Karl Pauls
>>> karlpa...@gmail.com
>> 
>> 
> 
> -- 
> Karl Pauls
> karlpa...@gmail.com

Re: [VOTE] Switch from JSR-305 annotations to Jetbrains Annotations for all Sling Models

[Konrad Windszus]

Then I would be in favour of just trying to deploy 
http://search.maven.org/#artifactdetails%7Cjavax.annotation%7Cjavax.annotation-api%7C1.3%7Cjar
 
<http://search.maven.org/#artifactdetails|javax.annotation|javax.annotation-api|1.3|jar>
 with Sling and see how that behaves with Java 8, 9 and 11. That will gives us 
some time for the migration of the JSR-305 annotations (as that bundle is 
exporting the correct package to also workaround the missing import for JSR 
305).

> On 2. Aug 2018, at 12:28, Karl Pauls  wrote:
> 
> On Thursday, August 2, 2018, Karl Pauls  <mailto:karlpa...@gmail.com>> wrote:
> 
>> 
>> 
>> On Thursday, August 2, 2018, Konrad Windszus  wrote:
>> 
>>> At Sling we use other classes from javax.annotation as well (compare with
>>> https://issues.apache.org/jira/browse/SLING-7135 <
>>> https://issues.apache.org/jira/browse/SLING-7135>). So most probably we
>>> have to rely on the official Oracle replacement and the question for me is
>>> how that behaves in the context of Java 8 which exports javax.annotation
>>> from the system bundle.
>> 
>> 
>>> That would work like normal, assuming no versioning or uses constraints
>> to the contrary it would just resolve from the system bundle if it is there
>> in the jdk or from the bundle if not.
>> 
> 
> Luckily, there are no split packages in osgi :-)
> 
> 
> 
>> regards,
>> 
>> Karl
>> 
>>> 
>>>> On 2. Aug 2018, at 12:11, Karl Pauls  wrote:
>>>> 
>>>> Would would be the problem with that? I wasn’t talking about a jpms
>>> module
>>>> - IMO, we can just create a bundle that contains and exports
>>>> javax.annotation and be done with it think.
>>>> 
>>>> regards,
>>>> 
>>>> Karl
>>>> 
>>>> On Thursday, August 2, 2018, Konrad Windszus  wrote:
>>>> 
>>>>> 
>>>>>> However, I wanted to point out option b). IIRC, there is nothing
>>>>>> preventing us to just provide the package ourselves and then it would
>>> be
>>>>>> problem solved, no?
>>>>> 
>>>>> Unfortunately not, due to potential split-packages:
>>>>> https://blog.codefx.org/java/jsr-305-java-9/ <
>>>>> https://blog.codefx.org/java/jsr-305-java-9/>
>>>>>> 
>>>>>> 
>>>>>> regards,
>>>>>> 
>>>>>> Karl
>>>>>> 
>>>>>> On Thursday, August 2, 2018, Julian Reschke 
>>>>> wrote:
>>>>>> 
>>>>>>> On 2018-08-02 10:55, Stefan Seifert wrote:
>>>>>>> 
>>>>>>>> ...
>>>>>>>> benefits:
>>>>>>>> - removes a blocker from achieving Java 9 compatibility
>>>>>>>> 
>>>>>>> 
>>>>>>> AFAICT, it's only Java 11 where there's an actual compat problem (but
>>>>> yes,
>>>>>>> that'll be the version we need to support soonish).
>>>>>>> 
>>>>>>> ... > drawbacks:
>>>>>>>> - the jetbrains annotations include some more (mostly
>>>>> IntelliJ-specific)
>>>>>>>> annotations than only the nullable annotations
>>>>>>>> - the jetbrains annotations are no "standard annotations"
>>>>>>>> ...
>>>>>>>> 
>>>>>>> 
>>>>>>> Well, if there were "standard annotations" for this, we'd use them
>>> :-)
>>>>>>> 
>>>>>>>> ...
>>>>>>> 
>>>>>>> Best regards, Julian
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Karl Pauls
>>>>>> karlpa...@gmail.com
>>>>> 
>>>>> 
>>>> 
>>>> --
>>>> Karl Pauls
>>>> karlpa...@gmail.com
>>> 
>>> 
>> 
>> --
>> Karl Pauls
>> karlpa...@gmail.com
>> 
>> 
> 
> -- 
> Karl Pauls
> karlpa...@gmail.com <mailto:karlpa...@gmail.com>