RE: [hackathon] maven archetypes

[Stefan Seifert]

+1

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

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

stefan

>-Original Message-
>From: Konrad Windszus [mailto:konra...@gmx.de]
>Sent: Thursday, September 12, 2019 5:53 PM
>To: dev@sling.apache.org
>Subject: Re: [hackathon] maven archetypes
>
>Definitely +1 on having only one archetype. In case D is too much effort,
>we could even leave it out.
>A maintained archetype is better than what we currently have.
>And it should be pretty easy for every developer to just copy over from a
>blueprint project created from the archetype only the desired modules...
>
>Konrad
>
>> On 12. Sep 2019, at 16:50, Robert Munteanu  wrote:
>>
>> On Thu, 2019-09-05 at 14:43 +, Stefan Seifert wrote:
>>> - currently there are lots of sling maven archetypes, and most of
>>> them not well maintained
>>> - we would favor to have only one single "project" archetypes,
>>> probably the new "project" archetype contributed by andy
>>> - add parameters to switch features on and off, e.g. for generating
>>> only with bundle but not with the content packages
>>>  - this can be done using the groovy prost process
>>>  - there is already a groovy script with a lot of logic in it, to be
>>> reviewed if it already covers all use cases
>>> - the plan is to no longer have the need to maintain multiple
>>> archetypes
>>> - review the generated structure of the current project archetypes.
>>> the structure is derived from the adobe AEM project archetype, but we
>>> like not all of it. e.g. the "ui." prefix for the contant packages,
>>> probably introduce "bundles" and "content-packages" folders to but
>>> bundles and content packages in.
>>
>> I would like to propose the following:
>>
>> A. deprecate all project archetype ( + parent ) except the sling-
>> project-archetype
>>
>> 1. sling-slingstart-archetype
>> 2. sling-archetype-parent
>> 3. sling-taglib-archetype
>> 4. sling-servlet-archetype
>> 5. sling-bundle-archetype
>> 6. sling-initial-content-archetype
>> 7. sling-launchpad-standalone-archetype
>> 8. sling-launchpad-webapp-archetype
>> 9. sling-jcrinstall-bundle-archetype
>>
>> B. include the following artifacts in the project
>>
>> 1. core ( Java bundle )
>> 2. content ( content package, sample data )
>> 3. apps ( content package, Sling scripts )
>> 4. launcher ( feature model project )
>>
>> C. I like the fact that the project includes sample data. Would it
>> simplify maintenance if we always generated the sample data? I would
>> expect the user to tweak it anyway.
>>
>> D. We _could_ heavily tweak the project and make it generate a single
>> module, by e.g. deleting anything but the one of the modules and then
>> making them top-level after generation has run (groovy script).
>>
>> That would effectively replace the other 8 existing projects, but I'm
>> not sure if the complexity is worth it.
>>
>> Thoughts?
>>
>> Thanks,
>> Robert

Re: [hackathon] maven archetypes

[Andreas Schaefer]

With respect to C:

The Sling Project Archetype has two versions of each module in it:
- plain (no code)
- sample code

The archetype can do the following:
- merge samples into module aka having only one module
- delete samples
- keep them separate. Only the plain code module is active in the build but the 
user can copy them over pretty easily

D:

I did not yet start working on it but technically there should be no reason why 
this can’t be done.

The only problem is the number of parameters that have to be handled as all 
parameters must be specified when the archetype is launched.

- Andy

> On Sep 12, 2019, at 7:50 AM, 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: [Jenkins] Sling » sling-org-apache-sling-launchpad-testing » master #310 is BROKEN

[Robert Munteanu]

On Thu, 2019-09-12 at 16:03 +, Apache Jenkins Server wrote:
> Scripts not permitted to use new java.lang.RuntimeException
> java.lang.String. Administrators can decide whether to approve or
> reject this signature.

This cryptic failure should be fixed with 

https://github.com/apache/sling-tooling-jenkins/commit/7d2b31d

Thanks,
Robert

[jira] [Comment Edited] (SLING-8704) Build PRs from non-committers

[Konrad Windszus (Jira)]

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

Konrad Windszus edited comment on SLING-8704 at 9/12/19 4:07 PM:
-

I opened https://app.codeship.com/apache-sling for PoC purposes and I am now 
waiting for INFRA to approve the codeship app for Github 
(https://github.com/apps/codeship/installations/new). Asked in 
https://issues.apache.org/jira/browse/INFRA-18973.


was (Author: kwin):
I opened https://app.codeship.com/apache-sling for PoC purposes and I am now 
waiting for INFRA to approve the codeship app for Github 
(https://github.com/apps/codeship/installations/new).

> Build PRs from non-committers
> -
>
> Key: SLING-8704
> URL: https://issues.apache.org/jira/browse/SLING-8704
> Project: Sling
>  Issue Type: Improvement
>  Components: Build and Source Control
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> As outlined in 
> https://issues.apache.org/jira/browse/INFRA-18748?focusedCommentId=16885091=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16885091
>  and discussed in 
> https://lists.apache.org/thread.html/7ba9424ae1cadd61363a5c6e7d12dec9f5b424b1f68e27915032fbab@%3Cprivate.infra.apache.org%3E
>  it is no longer allowed to automatically build PRs from non-committers on 
> ASF infra.
> Therefore another solution needs to be found to be able to validate PRs from 
> contributors. This validation should include at least a Maven build and the 
> validation of SonarQube rules.
> Several options come to my mind
> # Use CloudBees Code Ship https://app.codeship.com/home. Currently it is 
> unclear whether there is a dedicated ASF account. I asked about it in 
> https://issues.apache.org/jira/browse/INFRA-18973. Preferred option as 
> probably the Jenkinsfile can be reused.
> # Use Travis CI. There is a dedicated ASF account but it a) needs to be 
> enabled by INFRA per project and b) requires to maintain another build script 
> next to the Jenkinsfile we already have
> # Use another 3rd party build provider
> This was also discussed during the Sling Hackathon 2019 
> (https://lists.apache.org/thread.html/fb675eda239779450943623490e5a232786464df1dfb1feac5ec4ee0@%3Cdev.sling.apache.org%3E).



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

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

[jira] [Assigned] (SLING-8694) Allow selectively downloading artifacts from a staged Nexus repository

[Radu Cotescu (Jira)]

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

Radu Cotescu reassigned SLING-8694:
---

Assignee: Radu Cotescu

> Allow selectively downloading artifacts from a staged Nexus repository
> --
>
> Key: SLING-8694
> URL: https://issues.apache.org/jira/browse/SLING-8694
> Project: Sling
>  Issue Type: New Feature
>  Components: Tooling
>Reporter: Radu Cotescu
>Assignee: Radu Cotescu
>Priority: Major
> Fix For: Committer CLI 1.0.0
>
>
> The Committer CLI tool should allow selectively downloading certain artifacts 
> from a staged Nexus repository (e.g. pom files) in order to allow mapping the 
> artifacts to a JIRA release, without having to force any conventions on the 
> staged repository's description.



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

[jira] [Commented] (SLING-8704) Build PRs from non-committers

[Konrad Windszus (Jira)]

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

Konrad Windszus commented on SLING-8704:


I opened https://app.codeship.com/apache-sling for PoC purposes and I am now 
waiting for INFRA to approve the codeship app for Github 
(https://github.com/apps/codeship/installations/new).

> Build PRs from non-committers
> -
>
> Key: SLING-8704
> URL: https://issues.apache.org/jira/browse/SLING-8704
> Project: Sling
>  Issue Type: Improvement
>  Components: Build and Source Control
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> As outlined in 
> https://issues.apache.org/jira/browse/INFRA-18748?focusedCommentId=16885091=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16885091
>  and discussed in 
> https://lists.apache.org/thread.html/7ba9424ae1cadd61363a5c6e7d12dec9f5b424b1f68e27915032fbab@%3Cprivate.infra.apache.org%3E
>  it is no longer allowed to automatically build PRs from non-committers on 
> ASF infra.
> Therefore another solution needs to be found to be able to validate PRs from 
> contributors. This validation should include at least a Maven build and the 
> validation of SonarQube rules.
> Several options come to my mind
> # Use CloudBees Code Ship https://app.codeship.com/home. Currently it is 
> unclear whether there is a dedicated ASF account. I asked about it in 
> https://issues.apache.org/jira/browse/INFRA-18973. Preferred option as 
> probably the Jenkinsfile can be reused.
> # Use Travis CI. There is a dedicated ASF account but it a) needs to be 
> enabled by INFRA per project and b) requires to maintain another build script 
> next to the Jenkinsfile we already have
> # Use another 3rd party build provider
> This was also discussed during the Sling Hackathon 2019 
> (https://lists.apache.org/thread.html/fb675eda239779450943623490e5a232786464df1dfb1feac5ec4ee0@%3Cdev.sling.apache.org%3E).



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

[jira] [Updated] (SLING-8704) Build PRs from non-committers

[Konrad Windszus (Jira)]

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

Konrad Windszus updated SLING-8704:
---
Description: 
As outlined in 
https://issues.apache.org/jira/browse/INFRA-18748?focusedCommentId=16885091=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16885091
 and discussed in 
https://lists.apache.org/thread.html/7ba9424ae1cadd61363a5c6e7d12dec9f5b424b1f68e27915032fbab@%3Cprivate.infra.apache.org%3E
 it is no longer allowed to automatically build PRs from non-committers on ASF 
infra.

Therefore another solution needs to be found to be able to validate PRs from 
contributors. This validation should include at least a Maven build and the 
validation of SonarQube rules.

Several options come to my mind
# Use CloudBees Code Ship https://app.codeship.com/home. Currently it is 
unclear whether there is a dedicated ASF account. I asked about it in 
https://issues.apache.org/jira/browse/INFRA-18973. Preferred option as probably 
the Jenkinsfile can be reused.
# Use Travis CI. There is a dedicated ASF account but it a) needs to be enabled 
by INFRA per project and b) requires to maintain another build script next to 
the Jenkinsfile we already have
# Use another 3rd party build provider


This was also discussed during the Sling Hackathon 2019 
(https://lists.apache.org/thread.html/fb675eda239779450943623490e5a232786464df1dfb1feac5ec4ee0@%3Cdev.sling.apache.org%3E).

  was:
As outlined in 
https://issues.apache.org/jira/browse/INFRA-18748?focusedCommentId=16885091=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16885091
 and discussed in 
https://lists.apache.org/thread.html/7ba9424ae1cadd61363a5c6e7d12dec9f5b424b1f68e27915032fbab@%3Cprivate.infra.apache.org%3E
 it is no longer allowed to automatically build PRs from non-committers on ASF 
infra.

Therefore another solution needs to be found to be able to validate PRs from 
contributors. This validation should include at least a Maven build and the 
validation of SonarQube rules.

Several options come to my mind
# Use CloudBees Code Ship https://app.codeship.com/home. Currently it is 
unclear whether there is a dedicated ASF account. I asked about it in 
https://issues.apache.org/jira/browse/INFRA-18973. Preferred option as probably 
the Jenkinsfile can be reused.
# Use Travis CI. There is a dedicated ASF account but it a) needs to be enabled 
by INFRA per project and b) requires to maintain another build script next to 
the Jenkinsfile we already have
# Use another 3rd party build provider



> Build PRs from non-committers
> -
>
> Key: SLING-8704
> URL: https://issues.apache.org/jira/browse/SLING-8704
> Project: Sling
>  Issue Type: Improvement
>  Components: Build and Source Control
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
>Priority: Major
>
> As outlined in 
> https://issues.apache.org/jira/browse/INFRA-18748?focusedCommentId=16885091=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16885091
>  and discussed in 
> https://lists.apache.org/thread.html/7ba9424ae1cadd61363a5c6e7d12dec9f5b424b1f68e27915032fbab@%3Cprivate.infra.apache.org%3E
>  it is no longer allowed to automatically build PRs from non-committers on 
> ASF infra.
> Therefore another solution needs to be found to be able to validate PRs from 
> contributors. This validation should include at least a Maven build and the 
> validation of SonarQube rules.
> Several options come to my mind
> # Use CloudBees Code Ship https://app.codeship.com/home. Currently it is 
> unclear whether there is a dedicated ASF account. I asked about it in 
> https://issues.apache.org/jira/browse/INFRA-18973. Preferred option as 
> probably the Jenkinsfile can be reused.
> # Use Travis CI. There is a dedicated ASF account but it a) needs to be 
> enabled by INFRA per project and b) requires to maintain another build script 
> next to the Jenkinsfile we already have
> # Use another 3rd party build provider
> This was also discussed during the Sling Hackathon 2019 
> (https://lists.apache.org/thread.html/fb675eda239779450943623490e5a232786464df1dfb1feac5ec4ee0@%3Cdev.sling.apache.org%3E).



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

[Jenkins] Sling » sling-org-apache-sling-launchpad-testing » master #310 is BROKEN

[Apache Jenkins Server]

[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.002 s 
- in org.apache.sling.launchpad.webapp.integrationtest.issues.SLING2522Test
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.issues.SLING2617Test
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.135 s 
- in org.apache.sling.launchpad.webapp.integrationtest.issues.SLING2617Test
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.issues.SLING457Test
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.383 s 
- in org.apache.sling.launchpad.webapp.integrationtest.issues.SLING457Test
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.issues.SLING2082Test
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 s 
- in org.apache.sling.launchpad.webapp.integrationtest.issues.SLING2082Test
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.issues.SLING2094Test
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.353 s 
- in org.apache.sling.launchpad.webapp.integrationtest.issues.SLING2094Test
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.issues.SLING760Test
[INFO] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.129 s 
- in org.apache.sling.launchpad.webapp.integrationtest.issues.SLING760Test
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.runmodes.InactiveRunModeTest
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 s 
- in 
org.apache.sling.launchpad.webapp.integrationtest.runmodes.InactiveRunModeTest
[INFO] Running 
org.apache.sling.launchpad.webapp.integrationtest.resourceprovider.PlanetsResourceProviderTest
[INFO] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.03 s - 
in 
org.apache.sling.launchpad.webapp.integrationtest.resourceprovider.PlanetsResourceProviderTest
[INFO] Running org.apache.sling.launchpad.webapp.integrationtest.RedirectTest
[INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.171 s 
- in org.apache.sling.launchpad.webapp.integrationtest.RedirectTest
[INFO] 
[INFO] Results:
[INFO] 
[WARNING] Tests run: 660, Failures: 0, Errors: 0, Skipped: 1
[INFO] 
[INFO] 
[INFO] --- slingstart-maven-plugin:1.7.16:stop (stop-container) @ 
org.apache.sling.launchpad.testing ---
[INFO] Stopping 1 Launchpad instances
[INFO] Stopping Launchpad '_-41000'
12.09.2019 16:03:33.356 *INFO * [Apache Sling Terminator] Java VM is shutting 
down
12.09.2019 16:03:33.356 *INFO * [Apache Sling Terminator] Stopping Apache Sling
Warning: Nashorn engine is planned to be removed from a future JDK release
12.09.2019 16:03:35.803 *INFO * [Sling Notifier] Apache Sling has been stopped
[INFO] 
[INFO] --- ianal-maven-plugin:1.0-alpha-1:verify-legal-files (default) @ 
org.apache.sling.launchpad.testing ---
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by 
org.codehaus.groovy.reflection.CachedConstructor 
(file:/home/jenkins/.m2/repository/org/codehaus/groovy/groovy-all-minimal/1.5.6/groovy-all-minimal-1.5.6.jar)
 to constructor java.io.File(java.lang.String,java.io.File)
WARNING: Please consider reporting this to the maintainers of 
org.codehaus.groovy.reflection.CachedConstructor
WARNING: Use --illegal-access=warn to enable warnings of further illegal 
reflective access operations
WARNING: All illegal access operations will be denied in a future release
[INFO] Checking legal files in: 
org.apache.sling.launchpad.testing-12-SNAPSHOT.jar
[INFO] Checking legal files in: 
org.apache.sling.launchpad.testing-12-SNAPSHOT-sources.jar
[INFO] 
[INFO] --- apache-rat-plugin:0.11:check (default) @ 
org.apache.sling.launchpad.testing ---
[INFO] 51 implicit excludes (use -debug for more details).
[INFO] Exclude: DEPENDENCIES
[INFO] Exclude: src/main/appended-resources/META-INF/*
[INFO] Exclude: velocity.log
[INFO] Exclude: target/*
[INFO] Exclude: README.md
[INFO] Exclude: maven-eclipse.xml
[INFO] Exclude: .*
[INFO] Exclude: .*/**
[INFO] Exclude: **/*.json
[INFO] Exclude: DEPENDENCIES
[INFO] Exclude: **/*.rej
[INFO] Exclude: hs_err_*.log
[INFO] Exclude: **/repository/index/*/index-details.txt
[INFO] Exclude: bnd.bnd
[INFO] 7 resources included (use -debug for more details)
[INFO] Rat check: Summary of files. Unapproved: 0 unknown: 0 generated: 0 
approved: 6 licence.
[INFO] 
[INFO] --- maven-failsafe-plugin:2.21.0:verify (default) @ 
org.apache.sling.launchpad.testing ---
[INFO] 
[INFO] BUILD SUCCESS
[INFO] 
[INFO] Total time:  05:21 min
[INFO] Finished at: 2019-09-12T16:03:37Z
[INFO] 
[INFO] [jenkins-event-spy] Generated 
/home/jenkins/jenkins-slave/workspace/e-sling-launchpad-testing_master@tmp/withMaven7b421c6f/maven-spy-20190912-155816

[jira] [Commented] (SLING-7245) Validate pull requests using Jenkins

[Konrad Windszus (Jira)]

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

Konrad Windszus commented on SLING-7245:


The broken PR build is now tracked in SLING-8704.

> Validate pull requests using Jenkins
> 
>
> Key: SLING-7245
> URL: https://issues.apache.org/jira/browse/SLING-7245
> Project: Sling
>  Issue Type: Improvement
>  Components: Build and Source Control
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Attachments: image-2019-01-30-12-52-54-106.png, 
> image-2019-01-30-12-52-56-248.png
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> We should refine the work done in SLING-7163 and validate PRs using Jenkins.



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

[jira] [Created] (SLING-8704) Build PRs from non-committers

[Konrad Windszus (Jira)]

Konrad Windszus created SLING-8704:
--

 Summary: Build PRs from non-committers
 Key: SLING-8704
 URL: https://issues.apache.org/jira/browse/SLING-8704
 Project: Sling
  Issue Type: Improvement
  Components: Build and Source Control
Reporter: Konrad Windszus
Assignee: Konrad Windszus


As outlined in 
https://issues.apache.org/jira/browse/INFRA-18748?focusedCommentId=16885091=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16885091
 and discussed in 
https://lists.apache.org/thread.html/7ba9424ae1cadd61363a5c6e7d12dec9f5b424b1f68e27915032fbab@%3Cprivate.infra.apache.org%3E
 it is no longer allowed to automatically build PRs from non-committers on ASF 
infra.

Therefore another solution needs to be found to be able to validate PRs from 
contributors. This validation should include at least a Maven build and the 
validation of SonarQube rules.

Several options come to my mind
# Use CloudBees Code Ship https://app.codeship.com/home. Currently it is 
unclear whether there is a dedicated ASF account. I asked about it in 
https://issues.apache.org/jira/browse/INFRA-18973. Preferred option as probably 
the Jenkinsfile can be reused.
# Use Travis CI. There is a dedicated ASF account but it a) needs to be enabled 
by INFRA per project and b) requires to maintain another build script next to 
the Jenkinsfile we already have
# Use another 3rd party build provider




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

[jira] [Resolved] (SLING-6756) Remove setting/advising to set permsize and max heap size

[Robert Munteanu (Jira)]

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

Robert Munteanu resolved SLING-6756.

Resolution: Not A Problem

Verified that there are no more jvm.config files in Sling repos, therefore not 
a problem anymore.

> Remove setting/advising to set permsize and max heap size
> -
>
> Key: SLING-6756
> URL: https://issues.apache.org/jira/browse/SLING-6756
> Project: Sling
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> PermSize is no longer an issue with java 8 as Java 8 no longer knows a 
> dedicated permgen space 
> (https://dzone.com/articles/java-8-permgen-metaspace). Still we set 
> {{-XX:MaxPermSize=256m}} in 
> https://github.com/apache/sling/blob/trunk/.mvn/jvm.config (SLING-4530) which 
> leads to a warning when building with Java 8.
> The related ant check in parent has been removed though in 
> https://issues.apache.org/jira/browse/SLING-5862. Althought the reason why 
> the check has been removed is a bit unclear to me from the comments, I would 
> propose to remove the jvm.config completely and do no longer advise to set 
> permsize or heapsize explicitly.
> The heapsize is currently bound to at most 512MB, which is in 90% of the 
> cases just limiting the maximum heapsize of a modern JVM (because it should 
> be 1/4 of the physical memory in most of the JVM, see 
> http://stackoverflow.com/questions/4667483/how-is-the-default-java-heap-size-determined).



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

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

[Robert Munteanu]

On Thu, 2019-09-05 at 14: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
> 
> - 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)

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

(volunteers welcome)

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

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

(assigned to me)

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

https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=75957583=19=20

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

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

(unassigned, probably should wait until we migrate to the feature
model)

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

Someone (I forget who, sorry), mentioned that all 'ubuntu' slaves have
docker installed, so this is done.

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

https://github.com/apache/sling-org-apache-sling-launchpad-testing/commit/05c32b6
https://cwiki.apache.org/confluence/display/SLING/Java+version+support

Note that currently many of our modules do not build on Java 11, due to
using older versions of the sling parent pom. Migration is difficult
since we need to migrate away from the Felix SCR plugin.

Robert

[jira] [Commented] (SLING-6756) Remove setting/advising to set permsize and max heap size

[Konrad Windszus (Jira)]

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

Konrad Windszus commented on SLING-6756:


I think we no longer have any .mvn folder in any of our git repositories, 
therefore I think we can close it as invalid.

> Remove setting/advising to set permsize and max heap size
> -
>
> Key: SLING-6756
> URL: https://issues.apache.org/jira/browse/SLING-6756
> Project: Sling
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> PermSize is no longer an issue with java 8 as Java 8 no longer knows a 
> dedicated permgen space 
> (https://dzone.com/articles/java-8-permgen-metaspace). Still we set 
> {{-XX:MaxPermSize=256m}} in 
> https://github.com/apache/sling/blob/trunk/.mvn/jvm.config (SLING-4530) which 
> leads to a warning when building with Java 8.
> The related ant check in parent has been removed though in 
> https://issues.apache.org/jira/browse/SLING-5862. Althought the reason why 
> the check has been removed is a bit unclear to me from the comments, I would 
> propose to remove the jvm.config completely and do no longer advise to set 
> permsize or heapsize explicitly.
> The heapsize is currently bound to at most 512MB, which is in 90% of the 
> cases just limiting the maximum heapsize of a modern JVM (because it should 
> be 1/4 of the physical memory in most of the JVM, see 
> http://stackoverflow.com/questions/4667483/how-is-the-default-java-heap-size-determined).



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

[jira] [Created] (SLING-8703) Run Sling Starter ITs for modules part of the Sling Starter

[Robert Munteanu (Jira)]

Robert Munteanu created SLING-8703:
--

 Summary: Run Sling Starter ITs for modules part of the Sling 
Starter
 Key: SLING-8703
 URL: https://issues.apache.org/jira/browse/SLING-8703
 Project: Sling
  Issue Type: Improvement
  Components: Build and Source Control, Starter
Reporter: Robert Munteanu


When building a module that is part of the Sling Starter, we should be able to 
quickly validate the current SNAPSHOT Starter with the current SNAPSHOT module:

- opt-in when building locally
- by default when building on Jenkins

It might be worth delaying this until the Starter moves to the Feature model.



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

[jira] [Resolved] (SLING-2760) org.apache.sling.auth.openid bundle has dependencies not available on Maven central

[Robert Munteanu (Jira)]

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

Robert Munteanu resolved SLING-2760.

Resolution: Won't Fix

Project is in the attic, resolving WONTFIX

> org.apache.sling.auth.openid bundle has dependencies not available on Maven 
> central
> ---
>
> Key: SLING-2760
> URL: https://issues.apache.org/jira/browse/SLING-2760
> Project: Sling
>  Issue Type: Bug
>  Components: Authentication
>Affects Versions: OpenID Authentication 1.0.2
>Reporter: Robert Munteanu
>Priority: Minor
>
> The org.apache.sling.auth.openid bundle includes the following repository 
> definition in its pom.xml file
> {code}
> 
>   
> true
>   
>   dyuproject-repo
>   dyuproject-repo
>   http://dyuproject.googlecode.com/svn/repos/maven2
> 
> 
> {code}
> and the following dependencies
> {code}
> 
> com.dyuproject
> dyuproject-openid
> 1.1.7
> 
> 
> com.dyuproject
> dyuproject-util
> 1.1.7
> 
> 
> com.dyuproject
> dyuproject-json
> 1.1.7
> 
> {code}
> Since we sync/upload these artifacts to maven central [1] we should consider 
> following the recommendation of not adding repositories to POMs [2] . There 
> is an open request in the dyuproject tracker [3] to upload the openid 
> artifacts to Maven Central, but it's been there for almost two years, and the 
> project hasn't seen much activity ( no commits since June 2011 ).
> I see two ways around this issue:
> - Use the sonatype service for uploading 3rd party bundles to Maven Central 
> [4]
> - Replace the com.dyuproject dependency with something different
> Thoughts?
> [1]: http://search.maven.org/#search|ga|1|org.apache.sling.auth.openid
> [2]: 
> https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-6.CentralSyncRequirement
> [3]: http://code.google.com/p/dyuproject/issues/detail?id=32
> [4]: 
> https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository



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

[jira] [Closed] (SLING-2760) org.apache.sling.auth.openid bundle has dependencies not available on Maven central

[Robert Munteanu (Jira)]

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

Robert Munteanu closed SLING-2760.
--

> org.apache.sling.auth.openid bundle has dependencies not available on Maven 
> central
> ---
>
> Key: SLING-2760
> URL: https://issues.apache.org/jira/browse/SLING-2760
> Project: Sling
>  Issue Type: Bug
>  Components: Authentication
>Affects Versions: OpenID Authentication 1.0.2
>Reporter: Robert Munteanu
>Priority: Minor
>
> The org.apache.sling.auth.openid bundle includes the following repository 
> definition in its pom.xml file
> {code}
> 
>   
> true
>   
>   dyuproject-repo
>   dyuproject-repo
>   http://dyuproject.googlecode.com/svn/repos/maven2
> 
> 
> {code}
> and the following dependencies
> {code}
> 
> com.dyuproject
> dyuproject-openid
> 1.1.7
> 
> 
> com.dyuproject
> dyuproject-util
> 1.1.7
> 
> 
> com.dyuproject
> dyuproject-json
> 1.1.7
> 
> {code}
> Since we sync/upload these artifacts to maven central [1] we should consider 
> following the recommendation of not adding repositories to POMs [2] . There 
> is an open request in the dyuproject tracker [3] to upload the openid 
> artifacts to Maven Central, but it's been there for almost two years, and the 
> project hasn't seen much activity ( no commits since June 2011 ).
> I see two ways around this issue:
> - Use the sonatype service for uploading 3rd party bundles to Maven Central 
> [4]
> - Replace the com.dyuproject dependency with something different
> Thoughts?
> [1]: http://search.maven.org/#search|ga|1|org.apache.sling.auth.openid
> [2]: 
> https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-6.CentralSyncRequirement
> [3]: http://code.google.com/p/dyuproject/issues/detail?id=32
> [4]: 
> https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository



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

[jira] [Commented] (SLING-6756) Remove setting/advising to set permsize and max heap size

[Robert Munteanu (Jira)]

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

Robert Munteanu commented on SLING-6756:


[~kwin] - I think this is no longer applicable, right?

> Remove setting/advising to set permsize and max heap size
> -
>
> Key: SLING-6756
> URL: https://issues.apache.org/jira/browse/SLING-6756
> Project: Sling
>  Issue Type: Improvement
>Reporter: Konrad Windszus
>Priority: Major
>
> PermSize is no longer an issue with java 8 as Java 8 no longer knows a 
> dedicated permgen space 
> (https://dzone.com/articles/java-8-permgen-metaspace). Still we set 
> {{-XX:MaxPermSize=256m}} in 
> https://github.com/apache/sling/blob/trunk/.mvn/jvm.config (SLING-4530) which 
> leads to a warning when building with Java 8.
> The related ant check in parent has been removed though in 
> https://issues.apache.org/jira/browse/SLING-5862. Althought the reason why 
> the check has been removed is a bit unclear to me from the comments, I would 
> propose to remove the jvm.config completely and do no longer advise to set 
> permsize or heapsize explicitly.
> The heapsize is currently bound to at most 512MB, which is in 90% of the 
> cases just limiting the maximum heapsize of a modern JVM (because it should 
> be 1/4 of the physical memory in most of the JVM, see 
> http://stackoverflow.com/questions/4667483/how-is-the-default-java-heap-size-determined).



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

[jira] [Updated] (SLING-8702) Investigate automatically onboarding Sling projects to SonarCloud

[Robert Munteanu (Jira)]

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

Robert Munteanu updated SLING-8702:
---
Summary: Investigate automatically onboarding Sling projects to SonarCloud  
(was: Investigate automatically onoboarding Sling projects to SonarCloud)

> Investigate automatically onboarding Sling projects to SonarCloud
> -
>
> Key: SLING-8702
> URL: https://issues.apache.org/jira/browse/SLING-8702
> Project: Sling
>  Issue Type: Task
>  Components: Build and Source Control
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
>
> [~bellingard] - at our last Hackathon we discussed the option of 
> automatically onboarding projects to SonarCloud as they are created.  Is 
> there an API that we could use for this? Alternatively, can we somehow mark 
> the repositories in the ASF GitHub org for inclusion? We now have control of 
> the repository tags, for instance.
> Thanks!



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

[jira] [Created] (SLING-8702) Investigate automatically onoboarding Sling projects to SonarCloud

[Robert Munteanu (Jira)]

Robert Munteanu created SLING-8702:
--

 Summary: Investigate automatically onoboarding Sling projects to 
SonarCloud
 Key: SLING-8702
 URL: https://issues.apache.org/jira/browse/SLING-8702
 Project: Sling
  Issue Type: Task
  Components: Build and Source Control
Reporter: Robert Munteanu
Assignee: Robert Munteanu


[~bellingard] - at our last Hackathon we discussed the option of automatically 
onboarding projects to SonarCloud as they are created.  Is there an API that we 
could use for this? Alternatively, can we somehow mark the repositories in the 
ASF GitHub org for inclusion? We now have control of the repository tags, for 
instance.

Thanks!



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

[jira] [Created] (SLING-8701) Investigate custom set of SonarCloud rules

[Robert Munteanu (Jira)]

Robert Munteanu created SLING-8701:
--

 Summary: Investigate custom set of SonarCloud rules
 Key: SLING-8701
 URL: https://issues.apache.org/jira/browse/SLING-8701
 Project: Sling
  Issue Type: Task
  Components: Best practices
Reporter: Robert Munteanu


>From [dev@sling.apache.org: [hackathon] CI 
>experience|https://lists.apache.org/thread.html/fb675eda239779450943623490e5a232786464df1dfb1feac5ec4ee0@%3Cdev.sling.apache.org%3E]

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)



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

[Jenkins] Sling » sling-org-apache-sling-launchpad-testing » master #309 is FIXED

[Apache Jenkins Server]

Please see 
https://builds.apache.org/job/Sling/job/sling-org-apache-sling-launchpad-testing/job/master/309/
 for details.

No further emails will be sent until the status of the build is changed.

Updating the News

[Jason E Bailey]

Reminder, if there's something that you feel is significant to Sling. Add it to 
the website news. 
Currently the last news item on our front page is from last year. 

- Jason

Re: [hackathon] maven archetypes

[Robert Munteanu]

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] switch to feature model

[Robert Munteanu]

On Mon, 2019-09-09 at 09:04 -0700, Andreas Schaefer wrote:
> Hi
> 
> I am not sure about this but my question was the other way around.
> 
> Do we want in the future that Content Package are writing in a
> Feature Model way (Content ZIP file separate from Bundles connected
> though a FM configuration)?
> 
> As far as I am concerned I do not see any issues where a traditional
> CP cannot be writing in an FM way but I might be wrong.

So

current way = bundles embedded in content packages
feature model way = bundles declared in the feature model

?

I would go with the second option, but I don't think it's something to
invest too much effort into right now.

Thanks,
Robert

[jira] [Comment Edited] (SLING-8700) Unexpected compiler errors in Eclipse during development

[Robert Munteanu (Jira)]

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

Robert Munteanu edited comment on SLING-8700 at 9/12/19 1:52 PM:
-

This I've tried and did not work:

- disabling the Maven Builder for the affected project
- deleting .settings/.classpath/.project and reimporting all projects
- upgrading to Eclipse 2019-09

It's interesting that at some point during import output directories named 
{{bin}} are created, but they don't seem to be updated. Maybe a side effect of 
the configurators?

{noformat}
$ find -name ServerUtil.class | xargs stat
  File: ./target/classes/org/apache/sling/ide/eclipse/core/ServerUtil.class
  Size: 6375Blocks: 16 IO Block: 4096   regular file
Device: 10303h/66307d   Inode: 542140737   Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  robert)   Gid: (  100/   users)
Access: 2019-09-12 15:30:22.765170216 +0200
Modify: 2019-09-12 15:30:22.757170234 +0200
Change: 2019-09-12 15:30:22.757170234 +0200
 Birth: 2019-09-12 15:27:42.041547537 +0200
  File: ./bin/src/org/apache/sling/ide/eclipse/core/ServerUtil.class
  Size: 6667Blocks: 16 IO Block: 4096   regular file
Device: 10303h/66307d   Inode: 1074448344  Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  robert)   Gid: (  100/   users)
Access: 2019-09-12 15:31:21.841031527 +0200
Modify: 2019-09-12 15:26:43.545684863 +0200
Change: 2019-09-12 15:26:43.545684863 +0200
 Birth: 2019-09-12 15:26:43.545684863 +0200
{noformat}

In this example the {{ServerUtil}} class in target/classes is newer than the 
one in bin.

The simplest way to reproduce:

* Open {{ServerUtil}}
* add a dummy change, save
* add another dummy change, save

At this point I get some compiltation errors in ServerUtil but also in 
SlingLaunchpadBehaviour

 !compiler-errors-screenshot.png|width=500! 

In the screenshot it's clearly visible that the error is present on the method 
invocation, but not on the type name and not on the import.

[~kwin] - does this problem happen to you as well?


was (Author: rombert):
This I've tried and did not work:

- disabling the Maven Builder for the affected project
- deleting .settings/.classpath/.project and reimporting all projects
- upgrading to Eclipse 2019-09

It's interesting that at some point during import output directories named 
{{bin}} are created, but they don't seem to be updated. Maybe a side effect of 
the configurators?

{noformat}
$ find -name ServerUtil.class | xargs stat
  File: ./target/classes/org/apache/sling/ide/eclipse/core/ServerUtil.class
  Size: 6375Blocks: 16 IO Block: 4096   regular file
Device: 10303h/66307d   Inode: 542140737   Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  robert)   Gid: (  100/   users)
Access: 2019-09-12 15:30:22.765170216 +0200
Modify: 2019-09-12 15:30:22.757170234 +0200
Change: 2019-09-12 15:30:22.757170234 +0200
 Birth: 2019-09-12 15:27:42.041547537 +0200
  File: ./bin/src/org/apache/sling/ide/eclipse/core/ServerUtil.class
  Size: 6667Blocks: 16 IO Block: 4096   regular file
Device: 10303h/66307d   Inode: 1074448344  Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  robert)   Gid: (  100/   users)
Access: 2019-09-12 15:31:21.841031527 +0200
Modify: 2019-09-12 15:26:43.545684863 +0200
Change: 2019-09-12 15:26:43.545684863 +0200
 Birth: 2019-09-12 15:26:43.545684863 +0200
{noformat}

In this example the {{ServerUtil}} class in target/classes is newer than the 
one in bin.

The simplest way to reproduce:

* Open {{ServerUtil}}
* add a dummy change, save
* add another dummy change, save

At this point I get some compiltation errors in ServerUtil but also in 
SlingLaunchpadBehaviour

 !compiler-errors-screenshot.png|thumbnail! 

In the screenshot it's clearly visible that the error is present on the method 
invocation, but not on the type name and not on the import.

[~kwin] - does this problem happen to you as well?

> Unexpected compiler errors in Eclipse during development
> 
>
> Key: SLING-8700
> URL: https://issues.apache.org/jira/browse/SLING-8700
> Project: Sling
>  Issue Type: Task
>  Components: IDE
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Sling Eclipse IDE 1.2.4
>
> Attachments: compiler-errors-screenshot.png
>
>
> 1. Change any code in eclipse-ui module in Eclipse
> 2. Run the plug-ins as an Eclipse Application (Sling IDE Tooling shared 
> launch config)
> Result: eclipse-ui fails to start, logged event _An error occurred while 
> automatically activating bundle org.apache.sling.ide.eclipse-ui (536)._ Error 
> is attached, but root cause are compilation errors in 
> org.apache.sling.ide.eclipse.ui.internal.Activator., e.g.
>  

[jira] [Comment Edited] (SLING-8700) Unexpected compiler errors in Eclipse during development

[Robert Munteanu (Jira)]

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

Robert Munteanu edited comment on SLING-8700 at 9/12/19 1:52 PM:
-

This I've tried and did not work:

- disabling the Maven Builder for the affected project
- deleting .settings/.classpath/.project and reimporting all projects
- upgrading to Eclipse 2019-09

It's interesting that at some point during import output directories named 
{{bin}} are created, but they don't seem to be updated. Maybe a side effect of 
the configurators?

{noformat}
$ find -name ServerUtil.class | xargs stat
  File: ./target/classes/org/apache/sling/ide/eclipse/core/ServerUtil.class
  Size: 6375Blocks: 16 IO Block: 4096   regular file
Device: 10303h/66307d   Inode: 542140737   Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  robert)   Gid: (  100/   users)
Access: 2019-09-12 15:30:22.765170216 +0200
Modify: 2019-09-12 15:30:22.757170234 +0200
Change: 2019-09-12 15:30:22.757170234 +0200
 Birth: 2019-09-12 15:27:42.041547537 +0200
  File: ./bin/src/org/apache/sling/ide/eclipse/core/ServerUtil.class
  Size: 6667Blocks: 16 IO Block: 4096   regular file
Device: 10303h/66307d   Inode: 1074448344  Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  robert)   Gid: (  100/   users)
Access: 2019-09-12 15:31:21.841031527 +0200
Modify: 2019-09-12 15:26:43.545684863 +0200
Change: 2019-09-12 15:26:43.545684863 +0200
 Birth: 2019-09-12 15:26:43.545684863 +0200
{noformat}

In this example the {{ServerUtil}} class in target/classes is newer than the 
one in bin.

The simplest way to reproduce:

* Open {{ServerUtil}}
* add a dummy change, save
* add another dummy change, save

At this point I get some compiltation errors in ServerUtil but also in 
SlingLaunchpadBehaviour

 !compiler-errors-screenshot.png|width=700! 

In the screenshot it's clearly visible that the error is present on the method 
invocation, but not on the type name and not on the import.

[~kwin] - does this problem happen to you as well?


was (Author: rombert):
This I've tried and did not work:

- disabling the Maven Builder for the affected project
- deleting .settings/.classpath/.project and reimporting all projects
- upgrading to Eclipse 2019-09

It's interesting that at some point during import output directories named 
{{bin}} are created, but they don't seem to be updated. Maybe a side effect of 
the configurators?

{noformat}
$ find -name ServerUtil.class | xargs stat
  File: ./target/classes/org/apache/sling/ide/eclipse/core/ServerUtil.class
  Size: 6375Blocks: 16 IO Block: 4096   regular file
Device: 10303h/66307d   Inode: 542140737   Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  robert)   Gid: (  100/   users)
Access: 2019-09-12 15:30:22.765170216 +0200
Modify: 2019-09-12 15:30:22.757170234 +0200
Change: 2019-09-12 15:30:22.757170234 +0200
 Birth: 2019-09-12 15:27:42.041547537 +0200
  File: ./bin/src/org/apache/sling/ide/eclipse/core/ServerUtil.class
  Size: 6667Blocks: 16 IO Block: 4096   regular file
Device: 10303h/66307d   Inode: 1074448344  Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  robert)   Gid: (  100/   users)
Access: 2019-09-12 15:31:21.841031527 +0200
Modify: 2019-09-12 15:26:43.545684863 +0200
Change: 2019-09-12 15:26:43.545684863 +0200
 Birth: 2019-09-12 15:26:43.545684863 +0200
{noformat}

In this example the {{ServerUtil}} class in target/classes is newer than the 
one in bin.

The simplest way to reproduce:

* Open {{ServerUtil}}
* add a dummy change, save
* add another dummy change, save

At this point I get some compiltation errors in ServerUtil but also in 
SlingLaunchpadBehaviour

 !compiler-errors-screenshot.png|width=500! 

In the screenshot it's clearly visible that the error is present on the method 
invocation, but not on the type name and not on the import.

[~kwin] - does this problem happen to you as well?

> Unexpected compiler errors in Eclipse during development
> 
>
> Key: SLING-8700
> URL: https://issues.apache.org/jira/browse/SLING-8700
> Project: Sling
>  Issue Type: Task
>  Components: IDE
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Sling Eclipse IDE 1.2.4
>
> Attachments: compiler-errors-screenshot.png
>
>
> 1. Change any code in eclipse-ui module in Eclipse
> 2. Run the plug-ins as an Eclipse Application (Sling IDE Tooling shared 
> launch config)
> Result: eclipse-ui fails to start, logged event _An error occurred while 
> automatically activating bundle org.apache.sling.ide.eclipse-ui (536)._ Error 
> is attached, but root cause are compilation errors in 
> org.apache.sling.ide.eclipse.ui.internal.Activator., e.g.
>  

[jira] [Commented] (SLING-8700) Unexpected compiler errors in Eclipse during development

[Robert Munteanu (Jira)]

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

Robert Munteanu commented on SLING-8700:


This I've tried and did not work:

- disabling the Maven Builder for the affected project
- deleting .settings/.classpath/.project and reimporting all projects
- upgrading to Eclipse 2019-09

It's interesting that at some point during import output directories named 
{{bin}} are created, but they don't seem to be updated. Maybe a side effect of 
the configurators?

{noformat}
$ find -name ServerUtil.class | xargs stat
  File: ./target/classes/org/apache/sling/ide/eclipse/core/ServerUtil.class
  Size: 6375Blocks: 16 IO Block: 4096   regular file
Device: 10303h/66307d   Inode: 542140737   Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  robert)   Gid: (  100/   users)
Access: 2019-09-12 15:30:22.765170216 +0200
Modify: 2019-09-12 15:30:22.757170234 +0200
Change: 2019-09-12 15:30:22.757170234 +0200
 Birth: 2019-09-12 15:27:42.041547537 +0200
  File: ./bin/src/org/apache/sling/ide/eclipse/core/ServerUtil.class
  Size: 6667Blocks: 16 IO Block: 4096   regular file
Device: 10303h/66307d   Inode: 1074448344  Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/  robert)   Gid: (  100/   users)
Access: 2019-09-12 15:31:21.841031527 +0200
Modify: 2019-09-12 15:26:43.545684863 +0200
Change: 2019-09-12 15:26:43.545684863 +0200
 Birth: 2019-09-12 15:26:43.545684863 +0200
{noformat}

In this example the {{ServerUtil}} class in target/classes is newer than the 
one in bin.

The simplest way to reproduce:

* Open {{ServerUtil}}
* add a dummy change, save
* add another dummy change, save

At this point I get some compiltation errors in ServerUtil but also in 
SlingLaunchpadBehaviour

 !compiler-errors-screenshot.png|thumbnail! 

In the screenshot it's clearly visible that the error is present on the method 
invocation, but not on the type name and not on the import.

[~kwin] - does this problem happen to you as well?

> Unexpected compiler errors in Eclipse during development
> 
>
> Key: SLING-8700
> URL: https://issues.apache.org/jira/browse/SLING-8700
> Project: Sling
>  Issue Type: Task
>  Components: IDE
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Sling Eclipse IDE 1.2.4
>
> Attachments: compiler-errors-screenshot.png
>
>
> 1. Change any code in eclipse-ui module in Eclipse
> 2. Run the plug-ins as an Eclipse Application (Sling IDE Tooling shared 
> launch config)
> Result: eclipse-ui fails to start, logged event _An error occurred while 
> automatically activating bundle org.apache.sling.ide.eclipse-ui (536)._ Error 
> is attached, but root cause are compilation errors in 
> org.apache.sling.ide.eclipse.ui.internal.Activator., e.g.
>   AbstractUIPlugin cannot be resolved to a type
>   ServiceTracker cannot be resolved to a type
>   SerializationManager cannot be resolved to a type
>   SerializationManager cannot be resolved to a type
>   ServiceTracker cannot be resolved to a type
>   FilterLocator cannot be resolved to a type
>   FilterLocator cannot be resolved to a type
> Note that these errors are not reflected in the editor.
> Solution is usually to clean the affected project.
> The same applies to the eclipse-core plug-in, so I assume this is not 
> isolated to a single Eclipse project. Iit does not apply to 
> org.apache.sling.ide.api or org.apache.sling.ide.artifacts, so I assume this 
> is related to the projects under '/eclipse' only, not to those under 
> '/shared'.
> It also happens that when editing a class ( e.g. JcrNode ), random compiler 
> errors pop up in the same project.



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

[jira] [Updated] (SLING-8700) Unexpected compiler errors in Eclipse during development

[Robert Munteanu (Jira)]

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

Robert Munteanu updated SLING-8700:
---
Attachment: compiler-errors-screenshot.png

> Unexpected compiler errors in Eclipse during development
> 
>
> Key: SLING-8700
> URL: https://issues.apache.org/jira/browse/SLING-8700
> Project: Sling
>  Issue Type: Task
>  Components: IDE
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
> Fix For: Sling Eclipse IDE 1.2.4
>
> Attachments: compiler-errors-screenshot.png
>
>
> 1. Change any code in eclipse-ui module in Eclipse
> 2. Run the plug-ins as an Eclipse Application (Sling IDE Tooling shared 
> launch config)
> Result: eclipse-ui fails to start, logged event _An error occurred while 
> automatically activating bundle org.apache.sling.ide.eclipse-ui (536)._ Error 
> is attached, but root cause are compilation errors in 
> org.apache.sling.ide.eclipse.ui.internal.Activator., e.g.
>   AbstractUIPlugin cannot be resolved to a type
>   ServiceTracker cannot be resolved to a type
>   SerializationManager cannot be resolved to a type
>   SerializationManager cannot be resolved to a type
>   ServiceTracker cannot be resolved to a type
>   FilterLocator cannot be resolved to a type
>   FilterLocator cannot be resolved to a type
> Note that these errors are not reflected in the editor.
> Solution is usually to clean the affected project.
> The same applies to the eclipse-core plug-in, so I assume this is not 
> isolated to a single Eclipse project. Iit does not apply to 
> org.apache.sling.ide.api or org.apache.sling.ide.artifacts, so I assume this 
> is related to the projects under '/eclipse' only, not to those under 
> '/shared'.
> It also happens that when editing a class ( e.g. JcrNode ), random compiler 
> errors pop up in the same project.



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

Re: [VOTE] Release Apache Sling bnd Remove Parameters from OSGi Headers Plugin 1.0.0

[David Bosschaert]

+1

David

On Wed, 11 Sep 2019 at 12:52, Oliver Lietz  wrote:

> Hi,
>
> We solved 1 issue in this release:
> https://issues.apache.org/jira/browse/SLING/fixforversion/12344864
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachesling-2128
>
> 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 2128 /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,
> O.
>
>
>
>

[GitHub] [sling-ide-tooling] rombert commented on issue #9: SLING-3629 - Provide an XML formatter for content.xml files

[GitBox]

rombert commented on issue #9: SLING-3629 - Provide an XML formatter for 
content.xml files
URL: https://github.com/apache/sling-ide-tooling/pull/9#issuecomment-530806403
 
 
   One of the builds failed because someone/something interrupted the build
   ```
   [INFO] Running org.apache.sling.ide.jcr.RepositoryUtilsTest
   [INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.073 
s - in org.apache.sling.ide.jcr.RepositoryUtilsTest
   [INFO] Running org.apache.sling.ide.impl.vlt.AddOrUpdateNodeCommandTest
   Sending interrupt signal to process
   ```
   Merging


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] [sling-ide-tooling] rombert merged pull request #9: SLING-3629 - Provide an XML formatter for content.xml files

[GitBox]

rombert merged pull request #9: SLING-3629 - Provide an XML formatter for 
content.xml files
URL: https://github.com/apache/sling-ide-tooling/pull/9
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: Why get rid of the rewriter?

[Justin Edelson]

+1 great summary.

On Tue, Sep 10, 2019 at 12:37 PM Stefan Seifert 
wrote:

> i try to write a first summary:
>
> - we have good use cases for a rewriter in general, but are unhappy with
> the current implementation and it's way of configuration. the whole thing
> is a bit "alien" to the other parts of sling.
>
> - a new rewriter implementation should be performant and with up-to-date
> support for modern HTML. ideally something like SAX for HTML (not
> XML/XHTML). this would not cover other use cases producing something other
> than HTML, though. perhaps there are libraries out there that can be built
> upon. should also provide modular support, e.g. rewriting only the output
> of a single component or text fragment. maybe someone can come up with a
> proposal.
>
> - we have to keep the old rewriter for backward compatibility because it
> was used a lot in the past, but do not plan to maintain it further and
> probably will remove it from the sling starter as well. mark it as
> deprecated or contrib.
>
> - we do no longer want to use the rewriter for link validation and
> externalization, but support this as aspect in another, more appropriate
> way (with some basic support or hooks/SPIs from Sling itself, the rest is
> more up to upstream layers). we have currently only very rough ideas here,
> a proposal needs to be draftet as well.
>
> stefan
>
> >-Original Message-
> >From: Jason E Bailey [mailto:jason.bai...@24601.org]
> >Sent: Tuesday, September 10, 2019 6:09 PM
> >To: dev@sling.apache.org
> >Subject: Re: Why get rid of the rewriter?
> >
> >I'm positive towards the concept of the rewriter, a utility that provides
> >centralized features that addresses cross-cutting concerns with user
> >generated content.
> >
> >I'm not a fan of the current implementation of the rewriter.
> >
> >1.  As Ruben pointed out, as of HTML5  html doesn't have anything to do
> >with XML. There is no concept of namespace in HTML now. There is no self
> >closing tag. There may not be an end tag. There is a concept of implied
> >parent tags.
> >
> >2. TagSoup, which is currently used to parse the HTML, requires  fully
> >cached content and will attempt to validate the content and add to it,
> >where appropriate. Which isn't necessary.
> >
> >3. The Rewriter requires the pipeline configuration to be in a specific
> >place with a specific name which is inflexible and contrary to other tools
> >we use.
> >
> >
> >The point being that I would prefer to have the rewriter implementation
> >deprecated in favor of a more up to date solution then having the concept
> >of the rewriter deprecated.
> >
> >
> >
> >--
> >Jason
> >
> >On Tue, Sep 10, 2019, at 8:56 AM, Ruben Reusser wrote:
> >> As was pointed out before the rewriter is used in a lot of projects for
> >> other things than rewriting links (in our case we use it a lot to inject
> >> legal disclaimers or content fragment models)
> >>
> >> The bigger problem however is that it assumes hml == xml and hence can
> >not
> >> deal with attributes with no value
> >>
> >> Ruben
> >>
> >> On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz
> >
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey  wrote:
> >> > > ...Can anyone summarize why we are getting rid of it?...
> >> >
> >> > I'm not sure if we need to "get rid" of that module, even if some
> >> > portion of Sling users stops using it.
> >> >
> >> > The proposal at [1] says the rewriter should be "deprecated and no
> >> > longer used", which is apparently what was discussed at the adaptTo
> >> > round table or hackathon.
> >> >
> >> > If people still find the module useful I think it''s fine to move it
> >> > to "contrib" status instead of deprecating. As long as there's a
> >> > reasonable expectation that the module will be maintained I think
> >> > that's a realistic status, but our guarantees are weak for contrib
> >> > modules so there's no pressure.
> >> >
> >> > And if other modules provide better ways of doing similar things, link
> >> > to them from the rewriter's docs.
> >> >
> >> > -Bertrand
> >> >
> >> > [1]
> >> >
> >
> https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3
> >f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E
> >> >
> >>
> >>
> >> --
> >> thank you
> >>
> >> Ruben Reusser
> >> CTO, headwire.com, Inc
> >>
>
>
>

Re: Why get rid of the rewriter?

[Julian Sedding]

@Stefan: thanks for the summary. +1 IMHO that captures the main points
of the discussion well.

Regards
Julian

On Tue, Sep 10, 2019 at 6:37 PM Stefan Seifert  wrote:
>
> i try to write a first summary:
>
> - we have good use cases for a rewriter in general, but are unhappy with the 
> current implementation and it's way of configuration. the whole thing is a 
> bit "alien" to the other parts of sling.
>
> - a new rewriter implementation should be performant and with up-to-date 
> support for modern HTML. ideally something like SAX for HTML (not XML/XHTML). 
> this would not cover other use cases producing something other than HTML, 
> though. perhaps there are libraries out there that can be built upon. should 
> also provide modular support, e.g. rewriting only the output of a single 
> component or text fragment. maybe someone can come up with a proposal.
>
> - we have to keep the old rewriter for backward compatibility because it was 
> used a lot in the past, but do not plan to maintain it further and probably 
> will remove it from the sling starter as well. mark it as deprecated or 
> contrib.
>
> - we do no longer want to use the rewriter for link validation and 
> externalization, but support this as aspect in another, more appropriate way 
> (with some basic support or hooks/SPIs from Sling itself, the rest is more up 
> to upstream layers). we have currently only very rough ideas here, a proposal 
> needs to be draftet as well.
>
> stefan
>
> >-Original Message-
> >From: Jason E Bailey [mailto:jason.bai...@24601.org]
> >Sent: Tuesday, September 10, 2019 6:09 PM
> >To: dev@sling.apache.org
> >Subject: Re: Why get rid of the rewriter?
> >
> >I'm positive towards the concept of the rewriter, a utility that provides
> >centralized features that addresses cross-cutting concerns with user
> >generated content.
> >
> >I'm not a fan of the current implementation of the rewriter.
> >
> >1.  As Ruben pointed out, as of HTML5  html doesn't have anything to do
> >with XML. There is no concept of namespace in HTML now. There is no self
> >closing tag. There may not be an end tag. There is a concept of implied
> >parent tags.
> >
> >2. TagSoup, which is currently used to parse the HTML, requires  fully
> >cached content and will attempt to validate the content and add to it,
> >where appropriate. Which isn't necessary.
> >
> >3. The Rewriter requires the pipeline configuration to be in a specific
> >place with a specific name which is inflexible and contrary to other tools
> >we use.
> >
> >
> >The point being that I would prefer to have the rewriter implementation
> >deprecated in favor of a more up to date solution then having the concept
> >of the rewriter deprecated.
> >
> >
> >
> >--
> >Jason
> >
> >On Tue, Sep 10, 2019, at 8:56 AM, Ruben Reusser wrote:
> >> As was pointed out before the rewriter is used in a lot of projects for
> >> other things than rewriting links (in our case we use it a lot to inject
> >> legal disclaimers or content fragment models)
> >>
> >> The bigger problem however is that it assumes hml == xml and hence can
> >not
> >> deal with attributes with no value
> >>
> >> Ruben
> >>
> >> On Tue, Sep 10, 2019 at 5:12 AM Bertrand Delacretaz
> >
> >> wrote:
> >>
> >> > Hi,
> >> >
> >> > On Mon, Sep 9, 2019 at 3:07 PM Jason E Bailey  wrote:
> >> > > ...Can anyone summarize why we are getting rid of it?...
> >> >
> >> > I'm not sure if we need to "get rid" of that module, even if some
> >> > portion of Sling users stops using it.
> >> >
> >> > The proposal at [1] says the rewriter should be "deprecated and no
> >> > longer used", which is apparently what was discussed at the adaptTo
> >> > round table or hackathon.
> >> >
> >> > If people still find the module useful I think it''s fine to move it
> >> > to "contrib" status instead of deprecating. As long as there's a
> >> > reasonable expectation that the module will be maintained I think
> >> > that's a realistic status, but our guarantees are weak for contrib
> >> > modules so there's no pressure.
> >> >
> >> > And if other modules provide better ways of doing similar things, link
> >> > to them from the rewriter's docs.
> >> >
> >> > -Bertrand
> >> >
> >> > [1]
> >> >
> >https://lists.apache.org/thread.html/c80093524461d7203fa9799b79ebbf6bfd1bb3
> >f9795865f4aaf3cd4a@%3Cdev.sling.apache.org%3E
> >> >
> >>
> >>
> >> --
> >> thank you
> >>
> >> Ruben Reusser
> >> CTO, headwire.com, Inc
> >>
>
>

Re: Why get rid of the rewriter?

[Julian Sedding]

@Konrad: I guess it boils down to rich-text processing again. So you
could argue that each component should explicitly process all its
rich-text properties explicitly and dump into a data-structure held in
a request attribute. It would be possible, but it would be much more
invasive than post-processing the markup, especially if the capability
is to be retrofitted in an application with 100+ existing components,
many of which would have rich-text properties.

Regards
Julian

On Tue, Sep 10, 2019 at 5:09 PM Konrad Windszus  wrote:
>
> 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 

Re: Why get rid of the rewriter?

[Justin Edelson]

... for urls, not for markup in general.

On Tue, Sep 10, 2019 at 10:35 AM 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
> >>
>
>

[jira] [Created] (SLING-8700) Unexpected compiler errors in Eclipse during development

[Robert Munteanu (Jira)]

Robert Munteanu created SLING-8700:
--

 Summary: Unexpected compiler errors in Eclipse during development
 Key: SLING-8700
 URL: https://issues.apache.org/jira/browse/SLING-8700
 Project: Sling
  Issue Type: Task
  Components: IDE
Reporter: Robert Munteanu
Assignee: Robert Munteanu
 Fix For: Sling Eclipse IDE 1.2.4


1. Change any code in eclipse-ui module in Eclipse
2. Run the plug-ins as an Eclipse Application (Sling IDE Tooling shared launch 
config)

Result: eclipse-ui fails to start, logged event _An error occurred while 
automatically activating bundle org.apache.sling.ide.eclipse-ui (536)._ Error 
is attached, but root cause are compilation errors in 
org.apache.sling.ide.eclipse.ui.internal.Activator., e.g.

AbstractUIPlugin cannot be resolved to a type
ServiceTracker cannot be resolved to a type
SerializationManager cannot be resolved to a type
SerializationManager cannot be resolved to a type
ServiceTracker cannot be resolved to a type
FilterLocator cannot be resolved to a type
FilterLocator cannot be resolved to a type

Note that these errors are not reflected in the editor.

Solution is usually to clean the affected project.

The same applies to the eclipse-core plug-in, so I assume this is not isolated 
to a single Eclipse project. Iit does not apply to org.apache.sling.ide.api or 
org.apache.sling.ide.artifacts, so I assume this is related to the projects 
under '/eclipse' only, not to those under '/shared'.

It also happens that when editing a class ( e.g. JcrNode ), random compiler 
errors pop up in the same project.



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

[GitHub] [sling-ide-tooling] rombert opened a new pull request #9: SLING-3629 - Provide an XML formatter for content.xml files

[GitBox]

rombert opened a new pull request #9: SLING-3629 - Provide an XML formatter for 
content.xml files
URL: https://github.com/apache/sling-ide-tooling/pull/9
 
 
   Update following review comments from @kwin


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Updated] (SLING-8699) Create sub-command to moving artifacts to dist.apache.org

[Robert Munteanu (Jira)]

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

Robert Munteanu updated SLING-8699:
---
Issue Type: New Feature  (was: Task)

> Create sub-command to moving artifacts to dist.apache.org
> -
>
> Key: SLING-8699
> URL: https://issues.apache.org/jira/browse/SLING-8699
> Project: Sling
>  Issue Type: New Feature
>  Components: Tooling
>Reporter: Robert Munteanu
>Priority: Major
> Fix For: Committer CLI 1.0.0
>
>
> With SLING-8684 we now have the pieces in place to automate promoting 
> artifacts to dist.apache.org.
> This sub-command will perform the following actions:
> - compute SHA-256 checksums and adds them to the files to be deployed
> - not include MD5 checksums
> - use the Java API equivalent of {{svn remove https://dist.apache.org/ ...}} 
> to remove all old artifacts of a release
> - use the Java API equivalent of {{svn import . https://dist.apache.org/ 
> ...}} to import local set of artifacts to SVN



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

Re: Release Validator Docker Image

[Robert Munteanu]

Filed https://issues.apache.org/jira/browse/SLING-8699 for tracking.

Thanks,
Robert

On Wed, 2019-09-11 at 04:19 +0200, Carsten Ziegeler wrote:
> Sounds good to me, with the addition that it does not upload the md5 
> files to SVN and only creates the sha256 (or sha512?) if the check
> of 
> the files is successful
> 
> Carsten
> 
> Am 10.09.2019 um 23:33 schrieb Robert Munteanu:
> > On Tue, 2019-09-10 at 22:57 +0200, Carsten Ziegeler wrote:
> > > I think the value is already there today, we push manually to
> > > dist
> > > and
> > > having the sha512 there and not the md5 is already a win.
> > > It would be great to have this mirrored in the maven repository,
> > > but
> > > that probably needs those bugs to be fixed.
> > 
> > So my proposal, echoing discussions at the hackathon would be to
> > implement a command that publishes a release to dist and that:
> > 
> > - downloads the release artifacts from Nexus (already covered by
> > existing command)
> > - computes SHA-256 checksums and adds them to the files to be
> > deployed
> > - uses the Java API equivalent of `svn remove 
> > https://dist.apache.org/
> > ...` to remove all old artifacts of a release
> > - uses the Java API equivalent of `svn import .
> > https://dist.apache.org/ ...` to import local set of artifacts to
> > SVN
> > 
> > Would that cover everyone's needs for pushing to dist?
> > 
> > Robert
> > 
> > > Carsten
> > > 
> > > Am 10.09.2019 um 13:16 schrieb Radu Cotescu:
> > > > Hi Carsten,
> > > > 
> > > > > On 9 Sep 2019, at 19:29, Carsten Ziegeler <
> > > > > cziege...@apache.org>
> > > > > wrote:
> > > > > 
> > > > > Can we maybe also remove the md5 files and create sha512
> > > > > files,
> > > > > when the checksum is correct?
> > > > > 
> > > > 
> > > > The sha1 and md5 files seem to be generated by Nexus and not by
> > > > our
> > > > Maven release process. I quickly checked how the sha512 files
> > > > are
> > > > generated and this seems to be a config in the Apache parent
> > > > pom
> > > > [4]. However, those are not attached [5] to the build, most
> > > > probably due to [6].
> > > > 
> > > > I guess we can create the sha512 files with this CLI tool, but
> > > > the
> > > > value would come only when we’d be able to push the staged
> > > > artifacts to dist.
> > > > 
> > > > Cheers,
> > > > Radu
> > > > 
> > > > [4] -
> > > > https://github.com/apache/maven-apache-parent/blob/apache-21/pom.xml#L440
> > > > <
> > > > https://github.com/apache/maven-apache-parent/blob/apache-21/pom.xml#L440
> > > > [5] -
> > > > https://checksum-maven-plugin.nicoulaj.net/files-mojo.html#attachChecksums
> > > > <
> > > > https://checksum-maven-plugin.nicoulaj.net/files-mojo.html#attachChecksums>[6
> > > > ] - https://issues.apache.org/jira/browse/INFRA-14923 <
> > > > https://issues.apache.org/jira/browse/INFRA-14923>
> > > > 

[jira] [Resolved] (SLING-8572) sling-ide-tooling is reported as broken but is actually successful

[Robert Munteanu (Jira)]

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

Robert Munteanu resolved SLING-8572.

Resolution: Fixed

Fixed with [sling-tooling-jenkins commit 
ac8c908|https://github.com/apache/sling-tooling-jenkins/commit/ac8c908].

> sling-ide-tooling is reported as broken but is actually successful
> --
>
> Key: SLING-8572
> URL: https://issues.apache.org/jira/browse/SLING-8572
> Project: Sling
>  Issue Type: Bug
>  Components: Build and Source Control, IDE
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
>
> https://builds.apache.org/job/Sling/job/sling-ide-tooling/job/master/46/ was 
> successful, but the notification said that it was broken
> {noformat}
> [Pipeline] { (Notifications)
> [Pipeline] echo
> Status change is BROKEN, notifications will be sent.
> [Pipeline] emailext
> {noformat}



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

[jira] [Commented] (SLING-8572) sling-ide-tooling is reported as broken but is actually successful

[Robert Munteanu (Jira)]

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

Robert Munteanu commented on SLING-8572:


I've expanded the status check to use {{currentBuild.currentResult}}  (variant 
2 in debug output ). For the sling whiteboard the output is

* successful build: {{[DEBUG] current result (variant 1) is SUCCESS, current 
result (variant 2) is SUCCESS, previous result is SUCCESS}}
* failed build: {{[DEBUG] current result (variant 1) is FAILURE, current result 
(variant 2) is FAILURE, previous result is SUCCESS}}

For the IDE tooling:

* successful build: {{[DEBUG] current result (variant 1) is null, current 
result (variant 2) is SUCCESS, previous result is SUCCESS}}
* failed build: {{[DEBUG] current result (variant 1) is FAILURE, current result 
(variant 2) is FAILURE, previous result is SUCCESS}}

The fix seems to be to use {{curentBuild.currentResult}} instead of 
{{currentBuild.result}}.

> sling-ide-tooling is reported as broken but is actually successful
> --
>
> Key: SLING-8572
> URL: https://issues.apache.org/jira/browse/SLING-8572
> Project: Sling
>  Issue Type: Bug
>  Components: Build and Source Control, IDE
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
>
> https://builds.apache.org/job/Sling/job/sling-ide-tooling/job/master/46/ was 
> successful, but the notification said that it was broken
> {noformat}
> [Pipeline] { (Notifications)
> [Pipeline] echo
> Status change is BROKEN, notifications will be sent.
> [Pipeline] emailext
> {noformat}



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

[jira] [Commented] (SLING-8572) sling-ide-tooling is reported as broken but is actually successful

[Robert Munteanu (Jira)]

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

Robert Munteanu commented on SLING-8572:


It seems that the current result is not recognised for the ide tooling: 
{{[DEBUG] current result is null, previous result is SUCCESS}}

> sling-ide-tooling is reported as broken but is actually successful
> --
>
> Key: SLING-8572
> URL: https://issues.apache.org/jira/browse/SLING-8572
> Project: Sling
>  Issue Type: Bug
>  Components: Build and Source Control, IDE
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
>
> https://builds.apache.org/job/Sling/job/sling-ide-tooling/job/master/46/ was 
> successful, but the notification said that it was broken
> {noformat}
> [Pipeline] { (Notifications)
> [Pipeline] echo
> Status change is BROKEN, notifications will be sent.
> [Pipeline] emailext
> {noformat}



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

[jira] [Assigned] (SLING-8572) sling-ide-tooling is reported as broken but is actually successful

[Robert Munteanu (Jira)]

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

Robert Munteanu reassigned SLING-8572:
--

Assignee: Robert Munteanu

> sling-ide-tooling is reported as broken but is actually successful
> --
>
> Key: SLING-8572
> URL: https://issues.apache.org/jira/browse/SLING-8572
> Project: Sling
>  Issue Type: Bug
>  Components: Build and Source Control, IDE
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Major
>
> https://builds.apache.org/job/Sling/job/sling-ide-tooling/job/master/46/ was 
> successful, but the notification said that it was broken
> {noformat}
> [Pipeline] { (Notifications)
> [Pipeline] echo
> Status change is BROKEN, notifications will be sent.
> [Pipeline] emailext
> {noformat}



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

[jira] [Resolved] (SLING-8594) Create an API Jar analyser that checks that it's transitively closed

[Simone Tripodi (Jira)]

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

Simone Tripodi resolved SLING-8594.
---
Resolution: Won't Fix

Existing Analyzer Tasks provide the same check already

> Create an API Jar analyser that checks that it's transitively closed
> 
>
> Key: SLING-8594
> URL: https://issues.apache.org/jira/browse/SLING-8594
> Project: Sling
>  Issue Type: Improvement
>  Components: Feature Model Analyser
>Affects Versions: Feature Model Analyser 1.0.4
>Reporter: Simone Tripodi
>Assignee: Simone Tripodi
>Priority: Major
> Fix For: Feature Model Analyser 1.1.2
>
>
> The APIs exposed by an APIs Jar should be transitively closed. This means 
> that they should not refer to APIs that are not provided by the APIs jar 
> itself or the Java platform.



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

[jira] [Created] (SLING-8699) Create sub-command to moving artifacts to dist.apache.org

[Robert Munteanu (Jira)]

Robert Munteanu created SLING-8699:
--

 Summary: Create sub-command to moving artifacts to dist.apache.org
 Key: SLING-8699
 URL: https://issues.apache.org/jira/browse/SLING-8699
 Project: Sling
  Issue Type: Task
  Components: Tooling
Reporter: Robert Munteanu
 Fix For: Committer CLI 1.0.0


With SLING-8684 we now have the pieces in place to automate promoting artifacts 
to dist.apache.org.

This sub-command will perform the following actions:

- compute SHA-256 checksums and adds them to the files to be deployed
- not include MD5 checksums
- use the Java API equivalent of {{svn remove https://dist.apache.org/ ...}} to 
remove all old artifacts of a release
- use the Java API equivalent of {{svn import . https://dist.apache.org/ ...}} 
to import local set of artifacts to SVN



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

[jira] [Comment Edited] (SLING-8698) Activate Apache Sling bnd Remove Parameters from OSGi Headers Plugin on SonarCloud

[Robert Munteanu (Jira)]

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

Robert Munteanu edited comment on SLING-8698 at 9/12/19 7:29 AM:
-

It's still [~bellingard] that needs to add you to the Sling admin group. 
Fabrice, can you also do that when onboarding the new project? Thanks!


was (Author: rombert):
It's still [~bellingard] that needs to add you to the Sling admin. Fabrice, can 
you also do that when onboarding the new project? Thanks!

> Activate Apache Sling bnd Remove Parameters from OSGi Headers Plugin on 
> SonarCloud
> --
>
> Key: SLING-8698
> URL: https://issues.apache.org/jira/browse/SLING-8698
> Project: Sling
>  Issue Type: Task
>Affects Versions: bnd Remove Parameters from OSGi Headers Plugin 1.0.0
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
>
> Project: 
> [sling-org-apache-sling-bnd-plugin-headers-parameters-remove|https://github.com/apache/sling-org-apache-sling-bnd-plugin-headers-parameters-remove]



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

[jira] [Commented] (SLING-8698) Activate Apache Sling bnd Remove Parameters from OSGi Headers Plugin on SonarCloud

[Robert Munteanu (Jira)]

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

Robert Munteanu commented on SLING-8698:


It's still [~bellingard] that needs to add you to the Sling admin. Fabrice, can 
you also do that when onboarding the new project? Thanks!

> Activate Apache Sling bnd Remove Parameters from OSGi Headers Plugin on 
> SonarCloud
> --
>
> Key: SLING-8698
> URL: https://issues.apache.org/jira/browse/SLING-8698
> Project: Sling
>  Issue Type: Task
>Affects Versions: bnd Remove Parameters from OSGi Headers Plugin 1.0.0
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Major
>
> Project: 
> [sling-org-apache-sling-bnd-plugin-headers-parameters-remove|https://github.com/apache/sling-org-apache-sling-bnd-plugin-headers-parameters-remove]



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

[jira] [Comment Edited] (SLING-8683) Slingfeature maven plugin should be usable to wrap project artifacts in feature.

[Carsten Ziegeler (Jira)]

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

Carsten Ziegeler edited comment on SLING-8683 at 9/12/19 7:00 AM:
--

Renamed the mojo to include artifact and adjusted the configuration; it's now 
possible to specify the name of an extension to put the artifact into as well 
(using includeArtifactExtension):
{noformat}

  org.apache.sling 
  slingfeature-maven-plugin
  1.1.3-SNAPSHOT
  true
  

  
include-artifact
   attach-features
 
  
  
  
bundle
  

{noformat}


was (Author: cziegeler):
Renamed the mojo to include artifact and adjusted the configuration; it's now 
possible to specify the name of an extension to put the artifact into as well 
(using includeArtifactExtension):
{noformat}

  org.apache.sling 
  slingfeature-maven-plugin
  1.1.3-SNAPSHOT
  true
  

  
include-artifact
   attach-features
 



bundle


{noformat}

> Slingfeature maven plugin should be usable to wrap project artifacts in 
> feature.
> 
>
> Key: SLING-8683
> URL: https://issues.apache.org/jira/browse/SLING-8683
> Project: Sling
>  Issue Type: Improvement
>  Components: Feature Model
>Affects Versions: slingfeature-maven-plugin 1.1.0
>Reporter: Karl Pauls
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.1.4
>
>
> It would be nice if there was an easy way to create a feature for the 
> artifact(s) of a maven project without manually creating the feature. The 
> idea was to maybe make it so that if the slingfeature-maven-plugin is added 
> to a project, it will generate and a attach a feature wrapping the 
> artifact(s) from the build automatically. 



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

[jira] [Commented] (SLING-8683) Slingfeature maven plugin should be usable to wrap project artifacts in feature.

[Carsten Ziegeler (Jira)]

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

Carsten Ziegeler commented on SLING-8683:
-

Renamed the mojo to include artifact and adjusted the configuration; it's now 
possible to specify the name of an extension to put the artifact into as well 
(using includeArtifactExtension):
{noformat}

  org.apache.sling 
  slingfeature-maven-plugin
  1.1.3-SNAPSHOT
  true
  

  
include-artifact
   attach-features
 



bundle


{noformat}

> Slingfeature maven plugin should be usable to wrap project artifacts in 
> feature.
> 
>
> Key: SLING-8683
> URL: https://issues.apache.org/jira/browse/SLING-8683
> Project: Sling
>  Issue Type: Improvement
>  Components: Feature Model
>Affects Versions: slingfeature-maven-plugin 1.1.0
>Reporter: Karl Pauls
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: slingfeature-maven-plugin 1.1.4
>
>
> It would be nice if there was an easy way to create a feature for the 
> artifact(s) of a maven project without manually creating the feature. The 
> idea was to maybe make it so that if the slingfeature-maven-plugin is added 
> to a project, it will generate and a attach a feature wrapping the 
> artifact(s) from the build automatically. 



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