Re: SLING-5462 - MockServiceReference sorting is wrong w.r.t. service ranking

Hi Bertand, your test looks invalid to me. The Javadoc for BundleContext.getServiceReferences(…) doesn’t specify any order in which the services are returned (https://osgi.org/javadoc/r6/core/org/osgi/framework/BundleContext.html#getServiceReferences%28java.lang.Class,%20java.lang.String%29). In

Re: SLING-5462 - MockServiceReference sorting is wrong w.r.t. service ranking

mit/898f5850c82c6a621ab8fc265fdda2ad8d18349d#diff-cb38b920345df2a5f3763908befbd29dR63>. This definitely should be fixed on the MockServiceReference IMHO. All the tests which rely on the wrong sorting must be fixed. > On 28 Jan 2016, at 13:38, Konrad Windszus wrote: > > Hi Bertand, > your test looks invalid to me.

Re: SLING-5462 - MockServiceReference sorting is wrong w.r.t. service ranking

Yes I agree. I commented in https://issues.apache.org/jira/browse/SLING-5462 <https://issues.apache.org/jira/browse/SLING-5462> on how this should be fixed. Konrad > On 28 Jan 2016, at 13:51, Bertrand Delacretaz wrote: > > Hi Konrad, > > On Thu, Jan 28, 2016 at 1:47 PM, K

Superimposing resource resolver

Hi, IMHO the superimposing resource resolver can be deprecated now (https://issues.apache.org/jira/browse/SLING-1778) as now the overriding resource merger is available (https://issues.apache.org/jira/browse/SLING-3657). Although the latter uses sling:resourceSuperType instead of sling:superimpo

Re: Superimposing resource resolver

t that section only considers the MergingResourcePicker (/mnt/overlay) not the newer OverridingResourcePicker (/mnt/override). > On 29 Jan 2016, at 11:46, Konrad Windszus > wrote: > > Hi, > IMHO the superimposing resource resolver can be deprecated now > (https://issues.apac

Sling Resource Merger and intended behaviour of sling:hideProperties and sling:hideChildren

As being suggested by Julian Sedding in https://issues.apache.org/jira/browse/SLING-5468 I want to get your input on how the properties "sling:hideProperties=*” and "sling:hideChildren=*” are supposed to work in the Sling Resource Merger. At least for the OverridingResourcePicker using the wi

Re: Sling Resource Merger and intended behaviour of sling:hideProperties and sling:hideChildren

;t had time to read it yet. > > Regards > Julian > > On Fri, Jan 29, 2016 at 6:02 PM, Konrad Windszus > wrote: >> As being suggested by Julian Sedding in >> https://issues.apache.org/jira/browse/SLING-5468 I want to get your input on >> how the properties >>

Re: Sling Resource Merger and intended behaviour of sling:hideProperties and sling:hideChildren

h in SLING-5468. Konrad > On 03 Feb 2016, at 08:43, Julian Sedding wrote: > > Hi Konrad > > I read through the page. Good job! It looks fine and I didn't spot any > error. (Not that I am an authority on the Resource Merger...). > > Regards > Julian > &g

Re: [VOTE] Release Apache Sling Resource Merger 1.3.0

> On 10 Feb 2016, at 16:27, Stefan Egli wrote: > > +1 > > (Minor detail: I see only 3 issues in 12333082 though ;) That was me, because I removed the fix version from https://issues.apache.org/jira/browse/SLING-5460 (which is a duplicate of the not yet fixed https://issues.apache.org/jira/bro

Re: Sling Resource Merger and intended behaviour of sling:hideProperties and sling:hideChildren

" you must escape that within sling:hideChildren with another "!". sling:hideChilden = "!!child1" -> hide children with name "!child1". I will add that information to http://sling.apache.org/documentation/bundles/resource-merger.html. > On 03 Feb 2016

Re: [RT] Deprecating the jcr resource API

+1 on deprecating this class. > On 12 Feb 2016, at 07:50, Carsten Ziegeler wrote: > > Hi, > > I think we should deprecate the jcr resource API completely, most of it > is already deprecated. Deprecating will allow us to get rid of it in the > future and reduce the parts we have to maintain. >

Clarification on Sling Parameter Handlling

Hi, I would like to clarify few things on https://sling.apache.org/documentation/the-sling-engine/request-parameters.html but quickly wanted to check here first if no one opposes. 1. Since Servlet Spec 3.0 there was support for multipart requests being added (through HttpServletRequest.getParts

Re: Clarification on Sling Parameter Handlling

-engine/request-parameters.html#effects-of-sling-on-servlet-api-parameter-methods. > On 12 Feb 2016, at 17:22, Carsten Ziegeler wrote: > > Konrad Windszus wrote >> Hi, >> I would like to clarify few things on >> https://sling.apache.org/documentation/the-sling-engine/requ

Re: Naming a new support bundle

Hi Robert, as far as I know for retrieving the GAVs there is only the web console plugin at https://github.com/apache/felix/blob/trunk/webconsole-plugins/packageadmin/src/main/java/org/apache/felix/webconsole/plugins/packageadmin/internal/WebConsolePlugin.java#L280, which is looking up the GAV f

maven-sling-plugin and usePut with intermediate folders

Hi, in the context of [0] the handling of usePut=true was extended to also create intermediate nodes through the Sling POST servlet. Currently the maven-sling-plugin behaves like this: If you use usePut=true then you must point the targetUrl towards a WebDAV implementation (which handles the P

Re: maven-sling-plugin and usePut with intermediate folders

Hi Robert, thanks for your comments. > Am 24.02.2016 um 21:17 schrieb Robert Munteanu : > > Hi Konrad, > > On Wed, 2016-02-24 at 15:33 +0100, Konrad Windszus wrote: >> Hi, >> in the context of [0] the handling of usePut=true was extended to >> also create int

Re: maven-sling-plugin and usePut with intermediate folders

Hi Steven, I will take care of the PR soon, looks good at first glance. For improving the WebDAV support I have created https://issues.apache.org/jira/browse/SLING-5559 Thanks for your comments, Konrad > On 25 Feb 2016, at 02:14, Steven Walters wrote: > > On Wed, Feb 24, 2016 at 4:27 PM, Carst

Re: Health Check Tickets

Hi Georg, I applied both outstanding patches in SLING-5415 and SLING-4417. Maybe someone else can take over the release part? Konrad > On 25 Feb 2016, at 00:24, Georg Henzler wrote: > > Hi > > apart from some sporadic patches from my side, there has not been much > activity regarding health c

Re: Health Check Tickets

x27;t have any plans on adding unit tests for those issues. Konrad > On 25 Feb 2016, at 14:22, Bertrand Delacretaz wrote: > > Hi, > > On Thu, Feb 25, 2016 at 9:50 AM, Konrad Windszus wrote: >> ...I applied both outstanding patches in SLING-5415 and SLING-4417... > >

Blocked release of maven-sling-plugin

Hi, I intend to release maven-sling-plugin 2.1.8 (https://issues.apache.org/jira/browse/SLING/fixforversion/12334142). Unfortunately currently the POM contains a dependency towards a SNAPSHOT version of org.apache.sling.commons.json. The according commit, which changed that version is http://svn

[VOTE] Release Apache Sling Maven Sling Plugin 2.1.8

Hi, We solved 2 issues in this release: https://issues.apache.org/jira/browse/SLING/fixforversion/12334142 The documentation at http://sling.apache.org/documentation/development/sling.html has already been updated accordingly. Staging repository: https://repository.apache.org/content/repositorie

Re: Blocked release of maven-sling-plugin

snapshot until the release is available. this is our standard procedure in in > this case. > > i forget to set it back after the release was published - did it now in rev. > 1734762 > > stefan > >> -Original Message- >> From: Konrad Windszus [mail

Re: Blocked release of maven-sling-plugin

Actually that will not reveal what needs to be fixed in the pom.xml until another release was done. > On 14 Mar 2016, at 08:48, Carsten Ziegeler wrote: > > Bertrand Delacretaz wrote >> On Sun, Mar 13, 2016 at 10:41 AM, Carsten Ziegeler >> wrote: >>> ...The really annoying part is that we don'

Re: [VOTE] Accept the donation of the Sling Dynamic Include module, SLING-5594

+1 Konrad > On 14 Mar 2016, at 11:50, Bertrand Delacretaz wrote: > > Hi Sling community, > > Please vote to accept the donation of the Sling Dynamic Include module > described in SLING-5594, for inclusion in the Sling contrib subtree. > > This majority vote is open for at least 72 hours and her

Changing behaviour of ServletResolver.resolveServlet (SLING-5607)

Hi, according to the javadoc any of the three resolveServlet methods in ServletResolver are not supposed to return null [1]. Unfortunately the implementation returns null instead of throwing an exception. Either the javadoc/null annotation or the implementation needs to be fixed. I initially cre

Re: Changing behaviour of ServletResolver.resolveServlet (SLING-5607)

servlet could be found (for whatever reason). Would you mind taking over the ticket SLING-5605 and close SLING-5607 as invalid? > > Regards > Carsten > > Konrad Windszus wrote >> Hi, >> according to the javadoc any of the three resolveServlet methods in >

Re: [RT] Improve resource type handling

For me it would help a lot to quickly reconsider the current situation. As far as I know resource super types are used for two different things in Sling right now: 1. Script resolution: Influences which script is being picked up (initially or via includes from other scripts), documented in http

[RESULT[VOTE] Release Apache Sling Maven Sling Plugin 2.1.8

Hi, The vote has passed with the following result : +1 (binding): Robert Munteanu, Carsten Ziegeler, Stefan Seifert I will promote the artifacts to the central Maven repository. Could some PMC member please move the artifacts to dist? Thanks for voting, Konrad

Re: Enable Dual Git for Sling ?

AFAIK this does only allow bridging between Github and Apache Git (http://mail-archives.apache.org/mod_mbox/whimsical-dev/201602.mbox/%3c56cb0973.3000...@apache.org%3E). Not between SVN and Github. So to leverage that, Sling first has to migrate from SVN to Git. Konrad > On 22 Mar 2016, at 21:59

Re: SLING-5537 (deprecated jcr.base stuff) breaks oak.server bundle, how to fix?

The javadoc still mentions the method setup though: http://svn.apache.org/viewvc/sling/trunk/bundles/jcr/base/src/main/java/org/apache/sling/jcr/base/AbstractSlingRepositoryManager.java?revision=1731720&view=markup&pathrev=1731720#l58. Can you fix this then as well? Konrad > Am 31.03.2016 um 16:

Sling Scheduled Jobs and Sling Scheduler Service

In the past there was only one service for scheduling jobs [1] (completely independent of Sling Jobs). Since Sling 7 it is even possible to schedule Sling Jobs itself (which are persisted in the repository and may be distributed in a cluster) [2]. It would be really nice to have some documentati

Re: Sling Scheduled Jobs and Sling Scheduler Service

bs are only executed in a dedicated single thread and have no relationship with Sling Job Queues at all. Can someone confirm this? Thanks, Konrad > On 06 Apr 2016, at 16:16, Konrad Windszus wrote: > > In the past there was only one service for scheduling jobs [1] (completely > in

Re: Sling Scheduled Jobs and Sling Scheduler Service

Hi Carsten, thanks a lot for that information. I try to update the documentation around scheduling soon. Could you please confirm that I got the f flow for scheduling correct from the code: Once you schedule a Sling Scheduled Job, it will be persisted in the JCR (so in case of a Sling server cra

Re: Sling Scheduled Jobs and Sling Scheduler Service

at 08:34, Carsten Ziegeler wrote: > > Konrad Windszus wrote >> Hi Carsten, thanks a lot for that information. I try to update the >> documentation around scheduling soon. > > Great thanks > >> Could you please confirm that I got the f flow for scheduling correct

Re: Sling Scheduled Jobs and Sling Scheduler Service

me this can only happen if there is no according JobConsumer being registered. @Carsten: Can you clarify that paragraph a bit? Thanks, Konrad > On 10 Apr 2016, at 20:55, Konrad Windszus wrote: > > I updated the documentation at > http://sling.apache.org/documentation/bund

Meaning of :ignore: parameter of SlingPostServlet

Obviously when the parameter :ignore: is send as parameter for the SlingPostServlet all properties with empty values are just removed instead of adding those with empty values. Unfortunately that behaviour is neither documented at https://sling.apache.org/documentation/bundles/manipulating-con

Re: Meaning of :ignore: parameter of SlingPostServlet

between null or the empty array. Thanks, Konrad > On 13 Apr 2016, at 19:13, Konrad Windszus wrote: > > Obviously when the parameter :ignore: is send as parameter for the > SlingPostServlet all properties with empty values are just removed instead of > adding those with emp

Re: [Models] Injecting from two sources

This may be related to https://issues.apache.org/jira/browse/SLING-4155 . Please have a look. Konrad > On 14 Apr 2016, at 10:27, Oliver Lietz wrote: > > On Thursday 14 April 2016 07:47:33 Stefan Seifert wrote: >> please try to use use @Inject or

Order of services returned by SlingScriptHelper.getServices(...)

Currently the order of Services being returned by SlingScriptHelper.getServices(...) is undefined similar to BundleContext.getServiceReferences(). The difference is, the latter could be easily sorted, because the ServiceReferences implement a Comparable interface, the former cannot be that easi

Re: Order of services returned by SlingScriptHelper.getServices(...)

> On 18 Apr 2016, at 09:47, Bertrand Delacretaz wrote: > > Hi, > > On Fri, Apr 15, 2016 at 3:07 PM, Konrad Windszus wrote: >> ...I would propose to stick to a predefined order in the returned array: >> https://issues.apache.org/jira/browse/SLING-5665 > > That

Re: svn commit: r1739128 - /sling/trunk/bundles/extensions/validation/core/src/main/java/org/apache/sling/validation/impl/CompositeValidationResult.java

No typo, I really meant "if and only if" (https://en.wikipedia.org/wiki/If_and_only_if ) > On 18 Apr 2016, at 15:45, Oliver Lietz wrote: > > On Monday 18 April 2016 16:13:56 Robert Munteanu wrote: >> On Thu, 2016-04-14 at 15:50 +, o...@apache.or

Re: Integration tests broken due to SLING-5665 org.apache.sling.api.scripting package version change, is that needed?

Can you elaborate why the ITs in org.apache.sling.launchpad.test-services bundle break because of this? > On 18 Apr 2016, at 15:22, Bertrand Delacretaz wrote: > > Hi, > > In https://svn.apache.org/r1739719 Konrad incremented the > org.apache.sling.api.scripting from 2.2.0 to 2.3.0 for SLING-56

Re: Integration tests broken due to SLING-5665 org.apache.sling.api.scripting package version change, is that needed?

I think according to semantic versioning (https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf) it requires an update of the minor version (as I have done). There it says: . minor — API consumers are compatible with exporters that have the same major number and an equal or higher m

Re: Integration tests broken due to SLING-5665 org.apache.sling.api.scripting package version change, is that needed?

-Packages statement only covers the same major and minor version as lower bound (it does consider neither macro nor qualifier) and therefore would be the same for the old and the new API (i.e. [2.2,3.0)) > Am 18.04.2016 um 18:29 schrieb Konrad Windszus : > > I think according to

Configuration of the ResourceResolver Mapping

Currently there are two possibilities to configure the resource resolver mapping: a) Through the OSGi property "resource.resolver.mapping" of the PID org.apache.sling.jcr.resource.internal.JcrResourceResolverFactoryImpl b) Through the resources below the path being specified by the OSGI property

Re: Configuration of the ResourceResolver Mapping

whole mapping business is overly complicated IMHO and any reduction of > the complexity is welcome. > > Regards > Julian > > On Tue, Apr 19, 2016 at 2:35 PM, Konrad Windszus wrote: >> Currently there are two possibilities to configure the resource resolver >> mapp

Re: Configuration of the ResourceResolver Mapping

IMHO and any reduction of > the complexity is welcome. > > Regards > Julian > > On Tue, Apr 19, 2016 at 2:35 PM, Konrad Windszus wrote: >> Currently there are two possibilities to configure the resource resolver >> mapping:

Re: Configuration of the ResourceResolver Mapping

Again my answers are inline. > On 19 Apr 2016, at 16:42, Julian Sedding wrote: > > Hi Konrad > > See my reply inline. > > Regards > Julian > > On Tue, Apr 19, 2016 at 3:32 PM, Konrad Windszus wrote: >> Hi Julian, >> thanks for that hint. I will try

Re: Integration tests broken due to SLING-5665 org.apache.sling.api.scripting package version change, is that needed?

ices bundle is rebuilt with a >> version range of [2.3,3) and does not find that in the launchpad) I already elaborated why I think that increasing the version makes sense here. I would love to fix the IT, but currently just don't know how. Konrad > On 18 Apr 2016, at 16:00, Konrad Win

Re: Integration tests broken due to SLING-5665 org.apache.sling.api.scripting package version change, is that needed?

at 11:21, Konrad Windszus wrote: > > Can someone give me a pointer? To be honest I don't really know how to fix > this here and what is the real problem because I couldn't find where this > happens in the code: >>> (Currently this breaks a

Re: FYI, TeleporterRule + reorganized server-side tests docs

) 2) Is of packaging "bundle" for whatever reason. How do you feel about reworking the Teleporter, that this simple setup is supported without any Customizer at all? Thanks, Konrad > On 30 Sep 2015, at 13:38, Konrad Windszus wrote: > > Hi Bertrand, > to me it is not cl

Re: FYI, TeleporterRule + reorganized server-side tests docs

-side execution at all. So I would recommend to just move it. > On 21 Apr 2016, at 15:23, Konrad Windszus wrote: > > I would like to revive this old thread, because I now want to leverage the > TeleporterRule. It would be great if someone could verify the following > observations

Re: FYI, TeleporterRule + reorganized server-side tests docs

Thanks for you fast input. > On 21 Apr 2016, at 16:00, Bertrand Delacretaz wrote: > > Hi Konrad, > > On Thu, Apr 21, 2016 at 3:23 PM, Konrad Windszus wrote: >> I would like to revive this old thread, because I now want to leverage the >> TeleporterRule... > &

Re: Reloading of Locale Specific ResourceBundle

This is done because of inheritance. Just imagine you have a resource bundle for de_DE (already existing) Now you provide an additional resource bundle for de (which was not there before). This requires de_DE to also be invalidated, because it get's a new parent. In case you have a good idea on h

Re: Splitting up sling-testing-tools

Thanks for that, looks great. Can we have an updated documentation at https://sling.apache.org/documentation/tutorials-how-tos/testing-sling-based-applications.html, https://sling.apache.org/documentation/bundles/org-apache-sling-junit-bundles.html and https://sling.apache.org/documentation/de

Re: Splitting up sling-testing-tools

Just providing a patch on the markdown pages in the SVN referenced in [0] should work fine. Then any committer can apply that. > On 03 May 2016, at 10:36, Bertrand Delacretaz wrote: > > Hi, > > On Mon, May 2, 2016 at 8:52 PM, Radu Cotescu wrote: >> ...If you want to submit a patch for the Sli

Documentation on starting servers with slingstart-maven-plugin

Hi, I added some basic information on how to start/stop Sling servers with the slingstart-maven-plugin in http://sling.staging.apache.org/documentation/development/slingstart.html#starting-a-server . It

Re: Splitting up sling-testing-tools

ndrei >> >> On Tue, May 3, 2016 at 10:53 AM Bertrand Delacretaz < >> bdelacre...@apache.org> wrote: >> >>> On Tue, May 3, 2016 at 10:46 AM, Konrad Windszus wrote: >>>> Just providing a patch on the markdown pages in the SVN reference

Re: Splitting up sling-testing-tools

I also just observed that the WebconsoleClient still has a dependency towards testing.tools. I created a bug report in https://issues.apache.org/jira/browse/SLING-5725 <https://issues.apache.org/jira/browse/SLING-5725>. > On 12 May 2016, at 14:14, Konrad Windszus wrote: > > Ju

Re: Splitting up sling-testing-tools

Now the junit/rules module has the artifact id "org.apache.sling.testing.rules" while all other artifacts in that location have something like "org.apache.sling.junit.*". I think we should consolidate that. Also the packages in the new junit/rules are named "org.apache.sling.testing.junit.rules.

Re: svn commit: r1743648 - in /sling: site/trunk/content/documentation/bundles/ trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/injectors/ trunk/bundles/extensions/mode

I know that you can use Via for that purpose, but it is very often forgotten. And due to the way how injectors are asked this oversight is very hard to debug and trace down. Just allowing to directly adapt from a request for both injectors, makes using those injectors a lot more comfortable. T

Re: svn commit: r1743648 - in /sling: site/trunk/content/documentation/bundles/ trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/injectors/ trunk/bundles/extensions/mode

it > unnecessary in some (but not all) cases just adds confusion. > > Please go ahead and revert while you solicit other feedback. I'm doubtful > that other feedback will cause me to revoke my veto, but I'm open to the > idea. > > Regards, > Justin > On Fri, May

Test errors in TeleporterHttpClientTest

I get the following errors after the fixes from https://issues.apache.org/jira/browse/SLING-5715: waitForStatusWithLongTimeout(org.apache.sling.testing.teleporter.client.TeleporterHttpClientTest) Time elapsed: 0.026 sec <<< ERROR! java.lang.NoClassDefFoundError: Could not initialize class jav

Re: Test errors in TeleporterHttpClientTest

The same errors occur in the Jenkins Build: https://builds.apache.org/job/sling-trunk-1.8/org.apache.sling$org.apache.sling.junit.teleporter/3190/testReport/. > Am 15.05.2016 um 16:42 schrieb Konrad Windszus : > > I get the following errors after the fixes from > https://issues.apa

Re: Test errors in TeleporterHttpClientTest

st.waitForStatusWithShortTimeout(TeleporterHttpClientTest.java:72) To be honest I don't know what causes these errors. Konrad > On 17 May 2016, at 11:57, Bertrand Delacretaz wrote: > > Hi, > > On Sun, May 15, 2016 at 4:42 PM, Konrad Windszus wrote: >> NoClassDefFoundError

Re: Test errors in TeleporterHttpClientTest

properties are removed in DefaultPropertyBasedCustomizerTest.setup(). I fixed this in r1744390 (https://svn.apache.org/r1744390) Konrad > On 18 May 2016, at 08:30, Konrad Windszus wrote: > > Hi Bertrand, it still does not work for me. Now I get:

OSGi Installer: Removing entities with the highest priority should automatically install the entity with the 2nd highest priority

Hi, Currently in case the entity (e.g. bundle or configuration) with the highest priority is removed through the OSGi Installer (no matter which provider contributed it), the one with the 2nd highest priority will not automatically get activated (see https://issues.apache.org/jira/browse/SLING-5

Re: OSGi Installer: Removing entities with the highest priority should automatically install the entity with the 2nd highest priority

r. But there seems definitely something to be fishy when the Installer can reach such a state. Konrad > On 24 May 2016, at 13:30, Carsten Ziegeler wrote: > > Carsten Ziegeler wrote >> Konrad Windszus wrote >>> Hi, >>> Currently in case the entity (e.g. bundle

Dependency Management

Hi together, there was quite a discussion going on in https://issues.apache.org/jira/browse/SLING-5603 on how to deal with 3rd party dependencies in Sling. There are basically two different opinions there: a) let each bundle decide on its own in which version it depends on a certain 3rd party

Re: Dependency Management

Hi, > Am 26.05.2016 um 14:36 schrieb Bertrand Delacretaz : > > Hi, > > On Thu, May 26, 2016 at 10:21 AM, Konrad Windszus wrote: >> ...there was quite a discussion going on in >> https://issues.apache.org/jira/browse/SLING-5603 on how >> to deal with 3rd party

Re: Dependency Management

; bundle's build, none of the Import-Package version ranges will be > affected. > > This is a relatively simple way to create bundles with strongly > compatible Import-Package version ranges. > > Regards > Julian > > On Thu, May 26, 2016 at 2:46 PM, Konrad Windszus wrote: &

Re: Dependency Management

that is outside of a >> bundle's build, none of the Import-Package version ranges will be >> affected. >> >> This is a relatively simple way to create bundles with strongly >> compatible Import-Package version ranges. >> >> Regards >> Juli

Re: Dependency Management

> On 27 May 2016, at 11:14, Oliver Lietz wrote: > > Upgrading a library bundle to a newer version does NOT break compatibility > with Sling's downstream systems. It is not like upgrading from Java 7 to 8 or > from Declarative Services 1.2 to 1.3. > > If you can deploy a newer version of a com

Resource.getParent() on NonExistingResource

Hi, I have a question around the getParent() method on a NonExistingResource. Currently it returns null in case the parent is also a non existing resource. According to the javadoc of Resource.getParent() this is kind of unexpected, because it states (https://github.com/apache/sling/blob/trunk/b

Re: Resource.getParent() on NonExistingResource

Hi Robert, thanks for your input. > > I am not sure whether this would confuse existing clients though... I am also a bit worried about that but the only example I could think of is a code trying to create the parent nodes or collecting the non-existing ones by checking getParent() for null.

Re: Resource.getParent() on NonExistingResource

; >> Hi Konrad, >> >> +1 for making the behaviour of NonExistingResource more consistent - I >> personally can't think of any places this would break existing code. >> >> Regards >> Georg >> >> >> >> On 2016-06-01 15:

Re: Dependency Management

I would like to wrap things up here: So it seems the common agreement is: 1) Depend on the lowest possible version of a dependency (to let bnd generate import package ranges which are as broad as possible to support as many different systems as possible (even old ones)). A module should only b

Re: Dependency Management

Hi, > On 07 Jun 2016, at 10:12, Oliver Lietz wrote: > > On Monday 06 June 2016 14:57:16 Konrad Windszus wrote: >> I would like to wrap things up here: >> >> So it seems the common agreement is: > > Really? > >> 1) Depend on the lowest possible versi

Re: Dependency Management

> On 07 Jun 2016, at 10:32, Konrad Windszus wrote: > > Hi, >> On 07 Jun 2016, at 10:12, Oliver Lietz wrote: >> >> On Monday 06 June 2016 14:57:16 Konrad Windszus wrote: >>> I would like to wrap things up here: >>> >>> So it seems the co

Re: Please welcome Andrei Dulvac, Sling committer

Welcome, Konrad > On 09 Jun 2016, at 05:51, Chetan Mehrotra wrote: > > Welcome Andrei > > Chetan Mehrotra > > On Wed, Jun 8, 2016 at 8:07 PM, Stefan Seifert > wrote: > >> welcome! >> >> stefan >> >>> -Original Message- >>> From: Robert Munteanu [mailto:romb...@apache.org] >>> Sent

Release of Testing ResourceResolverMock

I would like to have a release of Testing ResourceResolver Mock 1.1.14 for fix https://issues.apache.org/jira/browse/SLING-5673. I am working on some issue related to NonExistingResource's and for that it would be very handy to have proper testing support. Should we wait for any more fixes? Othe

Re: Resource.getParent() on NonExistingResource

my opinion. So the NonExistingResource should not rely on AbstractResource.getParent() at all, but rather use its own implementation relying on ResourceResolver.resolve(...). WDYT? Thanks, Konrad > On 02 Jun 2016, at 14:48, Konrad Windszus wrote: > > Thanks for the input. > I cre

Re: Resource.getParent() on NonExistingResource

g at this, I'm really wondering if it was a good idea to implement > getParent on NonExistingResource. Let the client deal with it instead of > adding complex special cases. > > Carsten > > Konrad Windszus wrote >> There is one related problem with mapping: >> >&g

Re: Resource.getParent() on NonExistingResource

(even acting on a SyntheticResource). Konrad > On 10 Jun 2016, at 09:48, Carsten Ziegeler wrote: > > Konrad Windszus wrote >> This is complex to solve for the client (and kind of unexpected that this is >> not working). >> So what speaks against supporting this

Re: Release of Testing ResourceResolverMock

Perfect, thanks. Konrad > On 10 Jun 2016, at 13:48, Stefan Seifert wrote: > > i will do the release as i want to release some of the other mock libs as > well today. > > stefan > > >> -Original Message- >> From: Konrad Windszus [mailto:konra..

Re: Resource.getParent() on NonExistingResource

ave > _foo_bar as a component. > > /* : star resource handling > > > getParent() would likely be broken if it involved resolve() in such cases. > > > -Rob > > On 6/10/16, 12:12 AM, "Konrad Windszus" wrote: > >> There is one related problem w

Re: Resource.getParent() on NonExistingResource

until we find a matching one, or if we don't find a matching one return a NonExistingResource(), again being feeded with the same list of possible resolved repository paths. WDYT? Konrad > On 10 Jun 2016, at 10:13, Carsten Ziegeler wrote: > > Konrad Windszus wrote >> My use

Re: Resource.getParent() on NonExistingResource

ed when just acting on Strings instead of Resources. > > Regards > Julian > > On Fri, Jun 10, 2016 at 5:12 PM, Konrad Windszus wrote: >> I am talking about >> https://github.com/apache/sling/blob/c9e59667d8f9cd698bc33a51f3e6a22e85d4a952/bundles/scripting/sightly/engine/s

Re: Scripting Core (and Sling API)

I changed the package version of org.apache.sling.api.scripting from 2.2.0 to 2.3.0 in r1739719 for the semantic change in SLING-5665. Which package was previously at 2.1.1? Konrad > On 04 Jul 2016, at 08:21, Carsten Ziegeler wrote: > > I think SLING-5665 is a clarification of the javadocs in t

Re: Scripting Core (and Sling API)

It was changed from 2.1.1 to 2.2.0 in r1714786 (for SLING-5301), but there was a release in between. Therefore the change from 2.2.0 to 2.3.0 for SLING-5665 seems right to me. Konrad > On 04 Jul 2016, at 09:13, Konrad Windszus wrote: > > I changed the package v

Re: Scripting Core (and Sling API)

On 04 Jul 2016, at 14:03, Oliver Lietz wrote: > > On Monday 04 July 2016 10:04:10 Carsten Ziegeler wrote: >> Konrad Windszus wrote >> >>> It was changed from 2.1.1 to 2.2.0 in r1714786 (for SLING-5301), but there >>> was a release in between. Therefor

Re: Scripting Core (and Sling API)

> On 04 Jul 2016, at 14:34, Oliver Lietz wrote: > > On Monday 04 July 2016 14:17:13 Konrad Windszus wrote: >> On 04 Jul 2016, at 14:03, Oliver Lietz wrote: >>> On Monday 04 July 2016 10:04:10 Carsten Ziegeler wrote: >>>> Konrad Windszus wrote >>>&

Re: Updating our parent pom

> On 14 Jul 2016, at 21:43, Carsten Ziegeler wrote: > > Hi, > > looking at our parent pom, we have there some really really old > dependencies. The reasoning behind this is that we usually try to use > the minimal possible version for a dependency. However, for some things > newer versions are

Re: Reconsider usage of service PID

What about usage of PIDs when providing configurations through the repository (as sling:OsgiConfig resources or configuration files as described in https://sling.apache.org/documentation/bundles/configuration-installer-factory.html

Re: Reconsider usage of service PID

Hi Carsten, I am just wondering because you said the service PID is an implementation detail and being generated automatically by DS (in case the service has been started by DS), if we can always rely on the PID being the component's class name for all Felix version's in the future. I just don't

Re: Reconsider usage of service PID

Thanks a lot for the clarification. I was wrongly assuming that the connection is made by leveraging the SERVICE_PID property of the component, which is now no longer set by default by the maven-scr-plugin (https://issues.apache.org/jira/browse/FELIX-5304

OSGi Installer: Restore manually overwritten OSGi configuration instance (for a component factory)

Hi, sometimes it happens that OSGi configurations being installed through the OSGi Installer are manually overwritten in the Felix Web Console. From that point on the overwritten configuration takes precedence over the configuration provided through the OSGi Installer (e.g. through the JCR Inst

Re: OSGi Installer: Restore manually overwritten OSGi configuration instance (for a component factory)

It is the same: If I click "Delete" the component configuration is removed completely and not recreated until I deliberately change something about the configuration in the repository (which leads to the EventListener being triggered). Konrad > On 21 Jul 2016, at 08:51, Carsten Ziegeler wrote:

Re: Build failed in Jenkins: sling-trunk-1.8 #3614

The issue seems to be https://issues.apache.org/jira/browse/MSOURCES-94 . It is probably worth upgrading maven-source-plugin to 3.0.1. Not sure from where we are inheriting version 3.0.0 though... Konrad > On 25 Jul 2016, at 14:38, Apache Jenkin

Re: [Context Aware Configs] Merging?

Can't we just use the resource merger approach for merging configs (http://sling.staging.apache.org/documentation/bundles/resource-merger.html )? There probably needs to be a dedicated resource picker for configurations,

<    6   7   8   9   10   11   12   13   14   15   >