sling ci builds per module

discussed at the Sling Committer Round Table @ adaptTo() 2016 we all agreed that we need CI build individually per module/bundle, not a big build for all bundles at once. benefits: - much faster feedback in case of a broken build, and much more specific - if one module is broken only it's own

Re: Resource packaging/content packaging in Sling

I currently solve it by using the package manager from composum[2] but having support for content packages in Sling itself would in my opinion create extra opportunities. There are for example occasions where developers make something for AEM which could just as well work in standard Sling.

sling attic / cleanup

discussed at the Sling Committer Round Table @ adaptTo() 2016 before taking steps like migration sling svn to git we should check if we have modules that are no longer relevant and maintained, and moving them to the "attic" (perhaps creating a new one for this). esp. in contrib there is a good

moving sling to git

discussed at the Sling Committer Round Table @ adaptTo() 2016 we discussed again the long-debate topic moving from svn to git. no commiter hat and objection that moving to git creates a real problem. all agreed it would be nice to move to git. aspects that where discussed: - every module

[jira] [Commented] (SLING-6061) Create per-module Jenkins jobs

[ https://issues.apache.org/jira/browse/SLING-6061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15531031#comment-15531031 ] Robert Munteanu commented on SLING-6061: Right now all of the bundles and utility modules built by

Launchpad stable and launchpad unstable

discussed at the Sling Committer Round Table @ adaptTo() 2016 currently we have only one launchpad in trunk, which contains a mixture of release dependencies and snapshot dependencies. this makes it difficult to release new versions because one has to release all snapshot projects first, and

quarterly releases of sling

discussed at the Sling Committer Round Table @ adaptTo() 2016 we have the goal to do sling releses more frequently, perhaps 4 per year. it should be made easier to release sling. this would be the case if the launchpad is split into a stable and unstable part (see separate thread), and the

Integration tests near to modules

discussed at the Sling Committer Round Table @ adaptTo() 2016 in sling there is a big integration test project that tests the core sling functionality and the different sling bundles playing together. a problem with this apporach ist hat different aspects are mixed in one project, and if a new

Resource packaging/content packaging in Sling

discussed at the Sling Committer Round Table @ adaptTo() 2016 currently there is no support for content packages in sling to easily package content/resources from the repository or resource hierarchy and transfer it between instances. concerning File Vault packages several parts are already

Replace sling launchpad with karaf?

discussed at the Sling Committer Round Table @ adaptTo() 2016 one idea arised: why do we still maintain our own launchpad, when the "rest of the world" is using karaf? karaf is quite mature now, and no longer bloated or too complex as it may be some years ago. we did not go deeper into the

Sling Launchpad and Sling Karaf features

discussed at the Sling Committer Round Table @ adaptTo() 2016 currently we have Slind launchpad with a quite monolithic configuration [1] one big list of all sling bundles), and we have a karaf feature repository [2] with nicely cut features for different aspects of sling, allowing the deployer

maven site documentation for sling maven plugins

discussed at the Sling Committer Round Table @ adaptTo() 2016 sling provides a couple of maven plugins, but does not provide a detailed documentation about their goals and properties at [1]. such a documentation can be generated easily by using the maven site for the plugin project. the only

Sling Committer Round Table @ adaptTo() 2016

yesterday we the "Sling Committer Round Table" took place at the adaptTo() 2016 conference, and it was a very nice meeting [1]. i took notes about the topics we discussed and will open a separate mail thread for each topic. one of the topics was: more frequent face-to-face meetings (more than

adaptTo() 2016 - slides online

the slides of the adaptTo() 2016 conference in berlin are now online - 25 talks plus lightning talks, 200 participants. you find the slides and code samples here: https://adapt.to/2016/schedule and some images... (more to follow) https://adapt.to/2016/en/conference/gallery.html Stefan

[jira] [Created] (SLING-6073) pipe writer and additionalbindings configurations added through POST break the pipe

Nicolas Peltier created SLING-6073: -- Summary: pipe writer and additionalbindings configurations added through POST break the pipe Key: SLING-6073 URL: https://issues.apache.org/jira/browse/SLING-6073

Re: [VOTE] Release Apache Sling Discovery Commons 1.0.16 and Discovery Oak 1.2.14

On 28/09/16 13:10, "Stefan Seifert" wrote: >technically the semantic versioning is not violated because the package >version was raised, but usually it is a good habit to reflect this in the >bundle version as well, theoretically the bundle major version should be

[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener

[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15529517#comment-15529517 ] Carsten Ziegeler commented on SLING-6056: - :) I understand that you think that method is required

[jira] [Comment Edited] (SLING-6056) achieve 1:1 mapping between observation and resource change listener

[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15529403#comment-15529403 ] Stefan Egli edited comment on SLING-6056 at 9/28/16 12:17 PM: -- if we have the

[jira] [Comment Edited] (SLING-6056) achieve 1:1 mapping between observation and resource change listener

[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15529403#comment-15529403 ] Stefan Egli edited comment on SLING-6056 at 9/28/16 12:17 PM: -- if we have the

[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener

[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15529403#comment-15529403 ] Stefan Egli commented on SLING-6056: if we have the new method you suggested in ObservationReporter:

[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener

[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15529391#comment-15529391 ] Carsten Ziegeler commented on SLING-6056: - Alright but having the registration of the two

[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener

[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15529346#comment-15529346 ] Stefan Egli commented on SLING-6056: bq. The jcr resource module will register two observers I don't

RE: [VOTE] Release Apache Sling Discovery Commons 1.0.16 and Discovery Oak 1.2.14

technically the semantic versioning is not violated because the package version was raised, but usually it is a good habit to reflect this in the bundle version as well, theoretically the bundle major version should be updated as well. the problem in this case would be avoided in the first

[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener

[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15529285#comment-15529285 ] Carsten Ziegeler commented on SLING-6056: - Ok, so we can add a new reportChanges method to

Re: Build failed in Jenkins: sling-installer-factories-1.7 #1

Misconfigured project, sorry for the noise. Will be disabled in the next run. Robert On Wed, 2016-09-28 at 09:26 +, Apache Jenkins Server wrote: > See > > -- > Started by an SCM change

[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener

[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15529055#comment-15529055 ] Stefan Egli commented on SLING-6056: bq. So I assume you mean we should avoid this additional

[jira] [Commented] (SLING-6056) achieve 1:1 mapping between observation and resource change listener

[ https://issues.apache.org/jira/browse/SLING-6056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15528972#comment-15528972 ] Carsten Ziegeler commented on SLING-6056: - I start to understand the problem, now a

Re: Failing distribution ITs (Was: Build failed in Jenkins: sling-contrib-extensions-distribution-1.8 #2)

I'll have a look at them, thanks Robert. Regards, Tommaso Il giorno mar 27 set 2016 alle ore 20:39 Robert Munteanu ha scritto: > Hi, > > Seems that the distribution ITs are failing, can someone please look > into it? > > Thanks, > > Robert > > On Tue, 2016-09-27 at 17:37

Re: [VOTE] Release Apache Sling Discovery Commons 1.0.16 and Discovery Oak 1.2.14

Hi Stefan, Good point, it should probably be 1.1.0. So it is considered a violation of semantic versioning the way I've done it now? (Two points: discovery.commons is only used by discovery.oak and discovery.impl afaik, and this change won't require recompiling, but mainly adapting sling.api

Re: [VOTE] Release Apache Sling Oak Restrictions version 1.0.0

> > It needs to be the key fingerprint I think - not the key id (just in > > case > > that isn't what you have set there). > > > > Otherwise, the release looks good to me. > > Good point, I updated it to be the full key fingerprint. > > I'll wait a bit for the .asc file to be updated, it's a batch

RE: [VOTE] Release Apache Sling Discovery Commons 1.0.16 and Discovery Oak 1.2.14

signatures and build are fine, but i've one question: rev. 1761756 for SLING-5995 breaks the API compatibility and increases the package version of package org.apache.sling.discovery.commons.providers.spi.base to 2.0.0, forcing all existing implementations to recompile or adapt their version