>Do we really want org.apache.sling.contextaware.config as package name?
>Sling Content Distribution uses org.apache.sling.distribution, so
>org.apache.sling.configuration for Sling's context-ware configuration
>should be fine, no?
only "configuration" is misleading, because it's not about osgi c
as a workaround i switched to external link in rev. 1764795, 1764796
stefan
>-Original Message-
>From: Stefan Seifert [mailto:sseif...@pro-vision.de]
>Sent: Thursday, October 13, 2016 4:01 PM
>To: dev@sling.apache.org
>Subject: [sling-site] problem with linking to s
in [1] oliver mentioned the usage of property names in the current
implementation:
sling:config-ref
sling:config-collection-inherit
sling:config-property-inherit
should we use headless camel case instead? is this more consistent with the
other parts of sling?
sling:configRef
sling:configCollec
in [1] oliver mentioned that the current java package name is not
consistent/not ideal.
currently wie use
o.a.s.contextaware.config => "highlevel configuration API"
o.a.s.contextaware.config.resource => "lowlevel resource API"
bertrand and myself noted that the package name should included "co
n/the-sling-engine/mappings-for-
>resource-resolution.html <https://sling.apache.org/documentation/the-sling-
>engine/mappings-for-resource-resolution.html>.
>
>> On 14 Oct 2016, at 13:04, Carsten Ziegeler wrote:
>>
>> Stefan Seifert wrote
>>> in [1] oliver mentioned
>I see the point to distinguish between "highlevel configuration API" and
>"lowlevel resource API" but even highlevel API is build around resources
>(as
>everything in Sling). Maybe there is another way/name to make the
>difference
>obvious.
>
>The "context-aware config" name still sounds too bulk
+1
+1
>Having an adjective as root package is rather strange and I'm not aware of
>one
>at Sling. If we really want to have context aware[1] in the package name
>I'm
>in favor of o.a.s.contextawareconfig.
than it would be
o.a.s.contextawareconfig => "highlevel configuration API"
o.a.s.contextawarecon
ok, let's take o.a.s.caconfig - it's short and still unique
-> https://issues.apache.org/jira/browse/SLING-6157
stefan
>-Original Message-
>From: Georg Henzler [mailto:ghenz...@apache.org]
>Sent: Friday, October 14, 2016 10:55 PM
>To: dev@sling.apache.org
>Subject: Re: [context-aware con
Hi,
Context-Aware Configuration API 1.0.0 (4 Issues)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338139
Context-Aware Configuration SPI 1.0.0 (7 Issues)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338440
Context-Aware Configuration Impl 1.0.0 (16 Issues)
https:
+1
part of our release process is "Appendix C: Deploy bundles on the Sling OBR"
some of the recent releases were are added to OBR, but a lot of them were never
added, although they are bundles. this seems to be true for some years, not
checked it in detail.
do we still support OBR as deployment ta
+1
we need to document the new features from SLING-5992 and SLING-6183 in [1]
stefan
[1] http://sling.apache.org/documentation/bundles/models.html
>-Original Message-
>From: Justin Edelson [mailto:jus...@justinedelson.com]
>Sent: Monday, October 31, 2016 12:55 AM
>To: dev@sling.apache
+1
+1
sounds basically ok to me.
of course we could check first if the tweaks we want to enable using this SPI
might be as well directly implemented in the
DefaultConfigurationResourceResolvingStrategy, if they are a good addition to
the general default behavior.
if the usecases are too exotic for t
>a) If the value from the sling:confRef property ends with the bucket
>name, then a warning is logged and this value is ignored
>
>b) If the value from the sling:confRef property is relative, the parent
>hierarchy of the context resource is traversed up to find a context
>resource with an absolute
is this a "general SPI", or an SPI provided by
DefaultConfigurationResourceResolvingStrategy, so somewhat like a "2nd level
SPI"? not nice, but yes I think as well there is no nice way to support this
exotic use case without duplicating the
DefaultConfigurationResourceResolvingStrategy which we
+1
>Stefan Seifert wrote
>> is this a "general SPI", or an SPI provided by
>DefaultConfigurationResourceResolvingStrategy, so somewhat like a "2nd
>level SPI"? not nice, but yes I think as well there is no nice way to
>support this e
+1
+1
+1
+1
+1
etaz [mailto:bdelacre...@apache.org]
>Sent: Tuesday, November 1, 2016 8:25 AM
>To: dev
>Subject: Re: sling releases - deploy to OBR?
>
>On Mon, Oct 31, 2016 at 11:09 PM, Stefan Seifert
>wrote:
>> ...do we still support OBR as deployment target? or should we just remove
>> it
gt;Hello,
>
>The vote passes with 4 binding +1s from Carsten Ziegeler, Justin Edelson,
>Stefan Egli and Stefan Seifert.
>
>Thanks,
>Radu
+1
+1
+1
+1
>We solved 8 issues in the JCR Resource 2.8.2 release:
>https://issues.apache.org/jira/browse/SLING/fixforversion/12336744
+1 (only for JCR Resource 2.8.2)
stefan
+1
+1
+1
+1
Hi,
This is the first release:
https://issues.apache.org/jira/browse/SLING/fixforversion/12338737
Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1581/
You can use this UNIX script to download the release and verify the signatures:
http://svn.apache.org/repo
>On Mon, Nov 21, 2016 at 10:12 AM, Robert Munteanu
>wrote:
>> ...So my proposals would be:
>> 1) Remove the "old" explorer from the launchpad
>> 2) Move the "old" explorer to the attic
>> 3) Include composum in the launchpad ...
+1 from my side.
composum console [1] is published with MIT license
>Just one remark about the naming.
>It is "bnd" (all lowercase) instead of "BND" (compare with
>http://bnd.bndtools.org/).
>Can you rename it (both in JIRA as well as the name in the pom.xml)?
done (but the vote can go on anyway - it's fixed for the next release)
stefan
+1
Hi,
The vote has passed with the following result :
+1 (binding): Justin Edelson, Konrad Windszus, Stefan Seifert
I will copy this release to the Sling dist directory and
promote the artifacts to the central Maven repository.
Stefan
ensions/contextaware-config/impl/src/main/java/org/apache/sling/caconfig/resource/impl/def/DefaultConfigurationResourceResolvingStrategy.java#L230
>-Original Message-
>From: Burkhard Pauli [mailto:m...@bpauli.de]
>Sent: Thursday, November 24, 2016 2:06 PM
>To: dev@sling.apache.or
ah, i've looked for a non-deprecated felix API for this but did not find it.
will give it a try.
stefan
>-Original Message-
>From: Chetan Mehrotra [mailto:chetan.mehro...@gmail.com]
>Sent: Thursday, November 24, 2016 3:19 PM
>To: dev
>Subject: Re: svn commit: r1771140 - in
>/sling/trunk/c
for some time the caconfig integration tests are failing because the
org.apache.sling.junit.core is not whitelisted in LoginAdminWhitelist (see [1]).
but it is whitelisted via regexp (using the same merge-fix as robert for the
launchpad tests - see [2]).
the resulting slingstart.txt in the buil
-1
i think there is an issue with this ticket, we should clarify it first:
https://issues.apache.org/jira/browse/SLING-5519?focusedCommentId=15701634#comment-15701634
stefan
>-Original Message-
>From: Robert Munteanu [mailto:romb...@apache.org]
>Sent: Friday, November 25, 2016 12:24 PM
+1
>Your current configuration looks like this:
>whitelist.bundles.regexp="^org\.apache\.sling\.junit(\..*)?$"
>
>Inside target/slingstart.txt this becomes:
>whitelist.bundles.regexp="^org.apache.sling.junit(..*)?$"
>
>Note: all slashes have disappeared.
this is strange, yes.
the same escaping probl
t;semantics-of-a-quoted-string-in-the-http1-1-rfc2616) we should only refer
>to https://tools.ietf.org/html/rfc7230#section-3.2.6 instead (in the
>documentation).
>
>> On 28 Nov 2016, at 12:45, Stefan Seifert wrote:
>>
>>
>>> Your current configuration looks l
>My suggestion would be to:
>
>- move all issues from version N to version N+2
>- delete Jira version N
+1
+1
ime the ResourceResolverFactory
>becomes available went down from 10+ to ~3 seconds.
>
>Regards
>Julian
>
>[0] https://issues.apache.org/jira/browse/SLING-6334
>[1] https://issues.apache.org/jira/browse/SLING-6335
>
>
>On Mon, Nov 28, 2016 at 2:02 PM, Stefan Seifert
>wrot
>As I wrote, I see value in having the possibility to amend the
>whitelist without losing entries managed by another entity.
+1
i see carstens point, but the pain in special environments like integration
tests can quickly get bigger. currently it only works because we had luck that
three diffe
following [4] it looks that the best options are currently either GSON or
Jackson.
i think GSON has smaller footprint and is more compact, but both are good
options.
another criteria for choosing is: do they publish their APIs following semantic
versioning? otherwise we have the same dilemma as
+1
Hi,
OSGi Mock 2.2.0 (4 issues)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338265
OSGi Mock 1.9.0 (3 issues)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338264
Sling Mock 2.2.0 (2 issues)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338379
Sling
+1
+1
sling models 1.3.6 is already releaes (voting still in process).
1.3.6 should be closed in jira and 1.3.8 added.
stefan
>-Original Message-
>From: Konrad Windszus (JIRA) [mailto:j...@apache.org]
>Sent: Thursday, December 8, 2016 12:26 PM
>To: dev@sling.apache.org
>Subject: [jira] [Updat
>Thanks for the hint, unfortunately our release process described that
>creating new versions in JIRA is done after the VOTE was successful
>(http://sling.staging.apache.org/documentation/development/release-
>management.html#update-jira).
>Maybe we should insert an additional step "creating a new
s in jira manually - this would be too much pain, searching by name
>does the job as well.
>
>I agree this is very painful, as the list is almost endless. Maybe we
>could create a bookmarklet to simplify this step? Or archive old
>versions routinely, so the list isn't as long?
&g
Hi,
The vote has passed with the following result :
+1 (binding): Stefan Seifert, Justin Edelson, Robert Munteanu
I will copy this release to the Sling dist directory and
promote the artifacts to the central Maven repository.
stefan
OTE] Release Apache Sling Models Implementation 1.3.6
>and Jackson Exporter 1.0.6
>
>Hi,
>
>The vote has passed with the following result :
>
>+1 (binding): Justin Edelson, Stefan Seifert, Robert Munteanu
>
>I will copy this release to the Sling dist directory and
>prom
+1
+1
Hi,
Context-Aware Configuration API 1.1.0 (2 issues)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338408
Context-Aware Configuration SPI 1.2.0 (9 issues)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338673
Context-Aware Configuration Impl 1.2.0 (15 issues)
https:
+1
Hi,
Testing JCR Mock 1.2.0 (1 issue)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338263
Testing OSGi Mock 2.2.2 (2 issues)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338803
Testing OSGi Mock 1.9.2 (2 issues)
https://issues.apache.org/jira/browse/SLING/fixforve
+1
+1
+1
+1
+1
yes - again. this happened multiple times the last months, and affects not only
the sling svn-github bridge, but a lot of other apache svn projects as well.
we already openend several tickets, they all were resolved after some days (by
restarting a service), but after some weeks it breaks again.
+1
+1
the initial ticket for this release was SLING-5594 - i've added an appropriate
JIRA version
stefan
+1
+1
+1
Hi,
The vote has passed with the following result :
+1 (binding): Stefan Seifert, Carsten Ziegeler, Radu Cotescu
I will copy this release to the Sling dist directory and
promote the artifacts to the central Maven repository.
stefan
Hi,
The vote has passed with the following result :
+1 (binding): Stefan Seifert, Carsten Ziegeler, Radu Cotescu
I will copy this release to the Sling dist directory and
promote the artifacts to the central Maven repository.
stefan
Hi,
Apache Sling Mock 2.2.4 (1 issue)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338856
Apache Sling Mock 1.9.4 (1 issue)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338857
JUnit Core 1.0.22 (1 issue)
https://issues.apache.org/jira/browse/SLING/fixforversion/1
+1
+1
Hi,
Apache Sling Models API 1.3.2 (1 issue)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338658
Apache Sling Models Impl 1.3.8 (3 issues)
https://issues.apache.org/jira/browse/SLING/fixforversion/12338820
Staging repository:
https://repository.apache.org/content/repositories/org
the new context-aware configuration feature is currently in sling-contrib.
my proposal is to move it to bundles/extensions - we had a couple of releases
and 2 PMC members have contributed, and we plan to maintain it in the future as
well.
if no one has objections i will move it end of the week.
SLING-6416 revealed a problem in the type conversion logic of the
ValueMapDecorator [1] of the Sling API not supporting BigDecimal conversions.
as the TODO indicates (present there for nearly 8 years) the current conversion
logic is not very smart (and not very efficient), and supports less conv
+1
Gi
conversion service.
stefan
[1]
https://github.com/osgi/design/raw/master/rfps/rfp-0169-Object-Conversion.pdf
[2] https://github.com/apache/felix/tree/trunk/converter
>-----Original Message-
>From: Stefan Seifert [mailto:sseif...@pro-vision.de]
>Sent: Monday, December 19, 2016
>> ...so, what about defining only an "conversion interface" in the Sling
>API, limit it per
>> javadocs to support only a fixes list of types and conversions, and start
>with providing
>> an own implementation in a new bundle based on what is in jcr.resource
>today...
>
>+1 on having our own API
>Whatever we do, we should rather build utility (static) methods for the
>conversion or have a static way of getting the converter.
>Creating an OSGi service out of this is imho overkill.
then we will effectively put the conversion logic into the Sling API bundle
itself?
this would be an easy so
>* API: I suggest to break this out of the Sling API bundle into a separate
>bundle. One of the problems I see we have with the API bundle is that is
>becoming more and more a collection of API with independent lifecycle.
>Particularly the Resource API has its own life warranting its own bundle.
>
>* Bloat: Please consider to not bloat the conversion functionality and
>carefully consider which conversion really makes sense and which is just
>nice-to-have-because-JCR-has-it.
i've created at ticket about which conversion rules we speak SLING-6420 and
outlinded them in a wiki page https://cw
jcr.resource in the generic
impl as well
- introducing dependencies to the Sling API
- bloating things
if no one objects I would follow this way in SLING-6420, which would also help
solve the initial mock problem SLING-6416.
Stefan
>-Original Message-
>From: Stefan Seifert [mailto:sseif.
>Sounds good, I think we should also improve the decorator to check
>whether it is decorating a ValueMap (as opposed to a map) and then
>potentially use the methods of the wrapped ValueMap for conversion as well
good idea, i've created a separate ticket SLING-6421 for this. in this case i
suppos
Hi,
We solved 1 issues in this release:
https://issues.apache.org/jira/browse/SLING/fixforversion/12336078
Staging repository:
https://repository.apache.org/content/repositories/orgapachesling-1613/
You can use this UNIX script to download the release and verify the signatures:
http://svn.apache
+1
+1
+1
no objections, so we will move it - tracked in [1]
stefan
[1] https://issues.apache.org/jira/browse/SLING-6427
>-Original Message-
>From: Stefan Seifert [mailto:sseif...@pro-vision.de]
>Sent: Monday, December 19, 2016 11:43 AM
>To: 'dev@sling.apache.org'
>Subjec
601 - 700 of 4635 matches
Mail list logo
