[GitHub] [sling-org-apache-sling-starter] rombert commented on issue #6: embed Composum configuration bundle in the provisioning script

2019-08-14 Thread GitBox
rombert commented on issue #6: embed Composum configuration bundle in the 
provisioning script
URL: 
https://github.com/apache/sling-org-apache-sling-starter/pull/6#issuecomment-521138897
 
 
   Merged, thanks @ist-rw !


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: [Features] Merging Configurations

2019-08-14 Thread Radu Cotescu
+1

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



[Features] Merging Configurations

2019-08-14 Thread Carsten Ziegeler

Hi,

when two features are merged (aggregated), configurations are 
automatically merged. Meaning if both features have a configuration for 
the same PID, the properties from the second feature are put into the 
configuration of the first feature, adding and potentially overwriting 
values.


However, for everything else (bundles, framework properties, artifacts) 
it is up to the caller of the merge functionality to provide guidance 
for clashes. Meaning if both features have the same bundle/artifact in 
different versions, then there is no auto merge. Same for framework 
properties.


It seems a little bit inconsistent that we're using a different approach 
for configurations - and it can lead to unexpected results as well. 
These might be rare but I would argue they occur as often as the case of 
merging features containing the same bundle in different versions.


So I think we should not auto merge clashing configurations. The 
question is on which level we handle the clash: we can already refuse to 
merge if the same PID occurs - or we refuse if the same property within 
a PID occurs?


WDYT?

Regards
Carsten

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


Re: [Features] Merging Configurations

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

Konrad

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



Re: [Features] Merging Configurations

2019-08-14 Thread Karl Pauls
On Wednesday, August 14, 2019, Konrad Windszus  wrote:

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


+1

regards,

Karl


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

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


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

2019-08-14 Thread Apache Jenkins Server
[INFO] 
[INFO] Results:
[INFO] 
[ERROR] Errors: 
[ERROR]   MappingEventsProxyTest.runWriteableResourcesTest:26 » JsonGeneration 
write(par...
[INFO] 
[ERROR] Tests run: 660, Failures: 0, Errors: 1, 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'
14.08.2019 08:08:38.184 *INFO * [Apache Sling Terminator] Java VM is shutting 
down
14.08.2019 08:08:38.185 *INFO * [Apache Sling Terminator] Stopping Apache Sling
Warning: Nashorn engine is planned to be removed from a future JDK release
Warning: Nashorn engine is planned to be removed from a future JDK release
Warning: Nashorn engine is planned to be removed from a future JDK release
Warning: Nashorn engine is planned to be removed from a future JDK release
14.08.2019 08:08:44.728 *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 FAILURE
[INFO] 
[INFO] Total time:  03:16 min
[INFO] Finished at: 2019-08-14T08:08:45Z
[INFO] 
[INFO] [jenkins-event-spy] Generated 
/home/jenkins/jenkins-slave/workspace/e-sling-launchpad-testing_master@tmp/withMavene868a416/maven-spy-20190814-080529-22612286762230037466162.log
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-failsafe-plugin:2.21.0:verify (default) on 
project org.apache.sling.launchpad.testing: There are test failures.
[ERROR] 
[ERROR] Please refer to 
/home/jenkins/jenkins-slave/workspace/e-sling-launchpad-testing_master/target/failsafe-reports
 for the individual test results.
[ERROR] Please refer to dump files (if any exist) [date]-jvmRun[N].dump, 
[date].dumpstream and [date]-jvmRun[N].dumpstream.
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[Pipeline] }
[withMaven] Publishers: Pipeline Graph Publisher: 27 ms, JGiven Publisher: 2 ms
[Pipeline] // withMaven
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // timeout
[Pipeline] stage
[Pipeline] { (Notifications)
[Pipeline] echo
Status change is BROKEN, notifications will be sent.
[Pipeline] emailext

[jira] [Created] (SLING-8629) ConfigurationAdmin does not get registered without configurations

2019-08-14 Thread Carsten Ziegeler (JIRA)
Carsten Ziegeler created SLING-8629:
---

 Summary: ConfigurationAdmin does not get registered without 
configurations
 Key: SLING-8629
 URL: https://issues.apache.org/jira/browse/SLING-8629
 Project: Sling
  Issue Type: Bug
  Components: Feature Model
Affects Versions: Feature Model Launcher 1.0.6
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Feature Model Launcher 1.0.8


If the "featurelauncher" persistence manager for configuration admin is used, 
the persistence manager is only registered if OSGi configurations are contained 
in the launched feature model.
This means, if there are no configurations, than no peristence manager is 
registered which in turn prevents configuration admin from being registered
The persistence manager should be registered independent from whether 
configurations are available or not.



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


[GitHub] [sling-org-apache-sling-starter] rombert merged pull request #6: embed Composum configuration bundle in the provisioning script

2019-08-14 Thread GitBox
rombert merged pull request #6: embed Composum configuration bundle in the 
provisioning script
URL: https://github.com/apache/sling-org-apache-sling-starter/pull/6
 
 
   


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


[RT] Support OSGi R7 Logging

2019-08-14 Thread Carsten Ziegeler

Hi,

the OSGi R7 specification has an update to the Log Service which we 
should support in some way in Sling.


Today, we have our own LogService implementation 
(org.apache.sling.commons.logservice). One way to implement R7 could be 
to simply update our implementation. However logging is not our core 
business, so I think it makes more sense to use an existing implementation.


Fortunately, the Apache Felix project has an R7 LogService 
implementation. So we could replace our own implementation with that.


Unfortunately, that's not a simple replacement as our commons.logservice 
is also implementing slf4j support by logging every received log event 
to slf4j. On the other hand we have slf4j support in our 
org.apache.sling.commons.log bundle (it's easy to confuse these two 
bundles we have). So we could move the slf4j support to that bundle as 
well and have everything in a single place.


Or we could remove our own logservice implementation from the logservice 
bundle and just keep the slf4j support there. That would be a little bit 
more compatible.


Just for completeness, the R7 log service specification also introduces 
streaming support for logging. The Apache Felix implementation does not 
support this. But as the streaming support is additional we can use the 
Eclipse log stream implementation on top of Felix implementation if we 
want to support that, too.


WDYT?

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


Re: [DISCUSS] Switching o.a.s.starter-content to use scripts and resources?

2019-08-14 Thread Georg Henzler




Replying to myself here - the /content/startup/index.html file is
different from the /content/starter/index.html one, so no change is
required here.


Sorry for the late reply - so fixed perfectly via SLING-8615. The file
/content/startup/index.html used to be loaded from starter-startup [1],
I only recently moved it to starter-content. It's a good thing to have
it closer together with the regular content, unfortunately for
/content/starter/index.html we can still not use scripts and resources
as the Sling engine is not ready yet during early startup.

-Georg

[1] 
https://github.com/apache/sling-org-apache-sling-starter-startup/blob/maintenance/src/main/resources/index.html


Request for the Sling Feature Converter Maven Plugin to become a Sling Module

2019-08-14 Thread Andreas Schaefer
Hi

I am aware that this is a long shot but this Maven Plugin can make life easier 
for User that want to convert Sling into a Feature as well as launching Sling 
FM with their Content Packages.

The ticket for this request is: 
https://issues.apache.org/jira/browse/SLING-8490 


The project right now is in the Sling Whitespace under branch 
‘sling-feature-converter-maven-plugin’ but I will merge this into the ‘master’ 
branch today or tomorrow.

I use this Plugin to evaluate issues with Content Packages (see 
https://github.com/schaefa/cpconverter-ssue-fm-starter/tree/issue/package-group 
)
 which allows me to easily take a Content Package and spin up a Sling FM 
instance.

This is also used for the Peregrine CMS where we create a Peregrine CMS 
instance that is started with all content packages installed when the Sling FM 
instances starts.

There is one sticky point:
- In order to get an End-2-End scenario working the FM instance needs to be 
launched. I am not sure where to place it. From my point of view it is better 
off in the Sling Feature Maven Plugin as this is the final stage and it not 
really related to converting anything but I am not sure where you want to place 
it.

Cheers - Andy Schaefer

[GitHub] [sling-org-apache-sling-feature-cpconverter] schaefa opened a new pull request #16: SLING-8630 - Prevent the Converter from overwritting an existing POM …

2019-08-14 Thread GitBox
schaefa opened a new pull request #16: SLING-8630 - Prevent the Converter from 
overwritting an existing POM …
URL: 
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/16
 
 
   …file


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] [Created] (SLING-8631) Introduce state for extensions

2019-08-14 Thread Carsten Ziegeler (JIRA)
Carsten Ziegeler created SLING-8631:
---

 Summary: Introduce state for extensions
 Key: SLING-8631
 URL: https://issues.apache.org/jira/browse/SLING-8631
 Project: Sling
  Issue Type: New Feature
  Components: Feature Model
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Feature Model 1.0.8


Currently an extension is either required or optional. However, the extensions 
of the feature model also allow to keep transient state like a cache of 
calculations. For example, the result of scanning a feature could be attached 
to a feature model to avoid rescanning of downstream users.
Therefore we should probably add a method to get the state of an extension with 
the values TRANSIENT,OPTIONAL,REQUIRED



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


[jira] [Created] (SLING-8632) Add a method to get a JSON object from an extension

2019-08-14 Thread Carsten Ziegeler (JIRA)
Carsten Ziegeler created SLING-8632:
---

 Summary: Add a method to get a JSON object from an extension
 Key: SLING-8632
 URL: https://issues.apache.org/jira/browse/SLING-8632
 Project: Sling
  Issue Type: New Feature
  Components: Feature Flags
Reporter: Carsten Ziegeler
Assignee: Carsten Ziegeler
 Fix For: Feature Model 1.0.8


Extensions allow to store JSON objects, however, the method to retrieve that 
object just returns a string - which in turn requires every consumer to parse 
the string.
Initially we wanted to avoid a dependency on JSON api/impl, however as we need 
it for the merging of features anyway, we can safely add such a method to the 
API



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


[jira] [Resolved] (SLING-8629) ConfigurationAdmin does not get registered without configurations

2019-08-14 Thread Carsten Ziegeler (JIRA)


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

Carsten Ziegeler resolved SLING-8629.
-
Resolution: Fixed

Fixed in rev e9e01ee

> ConfigurationAdmin does not get registered without configurations
> -
>
> Key: SLING-8629
> URL: https://issues.apache.org/jira/browse/SLING-8629
> Project: Sling
>  Issue Type: Bug
>  Components: Feature Model
>Affects Versions: Feature Model Launcher 1.0.6
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
>Priority: Major
> Fix For: Feature Model Launcher 1.0.8
>
>
> If the "featurelauncher" persistence manager for configuration admin is used, 
> the persistence manager is only registered if OSGi configurations are 
> contained in the launched feature model.
> This means, if there are no configurations, than no peristence manager is 
> registered which in turn prevents configuration admin from being registered
> The persistence manager should be registered independent from whether 
> configurations are available or not.



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


[GitHub] [sling-org-apache-sling-feature-cpconverter] schaefa merged pull request #15: SLING-8626 - Added Maven Model Version to generated POM, replace any …

2019-08-14 Thread GitBox
schaefa merged pull request #15: SLING-8626 - Added Maven Model Version to 
generated POM, replace any …
URL: 
https://github.com/apache/sling-org-apache-sling-feature-cpconverter/pull/15
 
 
   


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] [Resolved] (SLING-8626) Content Package Converter is taking Group from Package Group instead of from Maven Group

2019-08-14 Thread Andreas Schaefer (JIRA)


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

Andreas Schaefer resolved SLING-8626.
-
Resolution: Fixed

At the end it turned out that the issue was that group and artifact ids taken 
from the package properties (META-INF/vault/properties.xml) or Bundle Header 
can contain spaces and this is fixed now.

> Content Package Converter is taking Group from Package Group instead of from 
> Maven Group
> 
>
> Key: SLING-8626
> URL: https://issues.apache.org/jira/browse/SLING-8626
> Project: Sling
>  Issue Type: Bug
>  Components: Content-Package to Feature Model Converter
> Environment: Sling 11, Java 8
>Reporter: Andreas Schaefer
>Assignee: Andreas Schaefer
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There are two issues with the Content Package to Feature Model Converter with 
> respect to groups:
>  # If a group is set in the Content Package then this group will be used in 
> the Feature Id as well as for the folder where it is created
>  # If anything changes in the Content Package Vault properties then this will 
> not be reflected in the conversion on a Mac (10.14, Mojave). This is because 
> the deflated file remains the same and in my testing the file did not change 
> even though the package did.
> The issue with the group is severe as the original POM file and the 
> 'cp2fm-converted' file are not in the same location causing issues with the 
> launcher at least.



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


SonarCloud review for Sling Whiteboard project / branch

2019-08-14 Thread Andreas Schaefer
Hi

I wanted to check out the review of SonarCloud for my Sling Whiteboard module 
‘sling-feature-converter-maven-plugin’ which is for now in its own branch but I 
created a PR for it. Even though I can find the PR in SonarCloud 
(https://sonarcloud.io/dashboard?id=apache_sling-whiteboard=48 
) it 
does not have any review in it.

How can I run a review? Do I need to merge the changes into master?

Cheers - Andy Schaefer

[jira] [Commented] (SLING-8490) Create Maven Plugin for FM Content Package Converter

2019-08-14 Thread Andreas Schaefer (JIRA)


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

Andreas Schaefer commented on SLING-8490:
-

Plugin is created as part of the Sling Whiteboard module and is under its own 
branch:

[https://github.com/apache/sling-whiteboard/tree/feature/sling-feature-converter-maven-plugin/sling-feature-converter-maven-plugin]

There is a pending PR to merge it into the master branch:

[https://github.com/apache/sling-whiteboard/pull/48]

> Create Maven Plugin for FM Content Package Converter
> 
>
> Key: SLING-8490
> URL: https://issues.apache.org/jira/browse/SLING-8490
> Project: Sling
>  Issue Type: New Feature
>  Components: Feature Model
>Reporter: Andreas Schaefer
>Assignee: Andreas Schaefer
>Priority: Major
>
> Converting Content Packages will have to be converter for a while until 
> everything is migrated to Feature Model. Many Sling customers will have to 
> work with both worlds and so a Content Package Conversion done from within a 
> Maven POM file would make it easier to automate this.
> The plugin would expose the CP Converter's CLI api as configuration 
> parameters and also copy the converted packages into the local Maven repo if 
> requested.



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


[jira] [Created] (SLING-8630) Converter must not replace existing POM files

2019-08-14 Thread Andreas Schaefer (JIRA)
Andreas Schaefer created SLING-8630:
---

 Summary: Converter must not replace existing POM files
 Key: SLING-8630
 URL: https://issues.apache.org/jira/browse/SLING-8630
 Project: Sling
  Issue Type: Bug
  Components: Feature Model
Reporter: Andreas Schaefer
Assignee: Andreas Schaefer


When the output folder for the converted feature is set to the local Maven repo 
(~/.m2/repository) then an existing POM is overwritten by the converter with 
the generated one. This can and will change the behavior of Maven for other 
projects. So, if a POM file exists then it should not be replaced and even if 
the existing POM is the generated it is not necessary as this file should not 
change otherwise the POM will be placed somewhere else.



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