[jira] [Updated] (SLING-6652) Allow multiple adapters for Models with resourceType binding

[Justin Edelson (JIRA)]

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

Justin Edelson updated SLING-6652:
--
Attachment: SLING-6652.diff

The only problem with this patch is that there is still a warning output:

{code}
Skipped registering class 
org.apache.sling.models.it.exporter.DoubledSecondComponent for resourceType 
sling/exp/doubled under adaptable interface 
org.apache.sling.api.resource.Resource because of existing mapping to class 
org.apache.sling.models.it.exporter.DoubledFirstComponent
{code}

To me, this is not a problem, but if is troublesome, we can add an attribute to 
the {{@Model}} annotation which causes the binding to be skipped.

> Allow multiple adapters for Models with resourceType binding
> 
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
> Attachments: SLING-6652.diff
>
>
> According to 
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
>  the AdapterImplementations support only mapping resourceType to Adapter 1:1. 
> I would like to propose extending that to support 1:n binding between 
> resourceType and adapter classes.
> My use case: 
> Lets assume I want to combine my models with the exporter framework to export 
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but 
> annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6652) Allow multiple adapters for Models with resourceType binding

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6652:
---

This appears to be an XY problem. The actual thing you want is to register 
multiple model classes with {{@Exporter}} annotations against the same resource 
type. This has very little to do with *binding* a resourceType to a Model 
class. That binding is only needed for the {{ModelFactory}} methods introduced 
in SLING-5992 (which as discussed in SLING-6655 is only really relevant for 
loosly typed scripting languages). The fact that the these methods are also 
used by the {{ExporterServlet}} is an implementation detail and one easily 
changed.

I'm attaching a patch which solves your problem without impacting the API 
semantics.



> Allow multiple adapters for Models with resourceType binding
> 
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> According to 
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
>  the AdapterImplementations support only mapping resourceType to Adapter 1:1. 
> I would like to propose extending that to support 1:n binding between 
> resourceType and adapter classes.
> My use case: 
> Lets assume I want to combine my models with the exporter framework to export 
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but 
> annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [jira] [Commented] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

[Justin Edelson]

Hi Dan,
I don't think I'm understanding how that API would work.

You have a single Resource there and a single Class (which I assume is
actually an interface for your use case). Are you saying that for one
Resource, there would be multiple Model classes implementing that same
interface mapped to the same resourceType?

I have seen code which does something like this (which I think is closer to
what your first paragraph is describing):

Resource -> collect children to make a list -> adapt each item in the list
to some interface -> remove the null values -> return the list

This is pretty easy to do with Lambdas. Maybe we should have a separate
module (which can require Java 8) to provide some Functions/Predicates...

Justin

On Thu, Mar 16, 2017 at 4:57 PM Daniel Klco  wrote:

> I do think though that there's a ton of value in the concept of being able
> to tie SlingModels to a resource type. I agree that this API is clunky, but
> the idea of limiting based on resourceType in Sling Models was really
> missing. I am using this concept for a library I have in progress right now
> so that developers can "register" sling Models with a particular interface
> against particular resourceTypes. My library then traverses down a resource
> tree, adapting the objects and generating a representation of the tree for
> a DataLayer representation. This works with the current functionality but
> could be cleaner.
>
> What I would really like to be able to do is something like this:
>
> Collection models = modelFactory.getModelsByResourceType(Resource
> resource, Class T);
>
> I would expect the method to use both the Class and the Resource type to
> generate the collection of models which match the requested class and are
> applicable for the resourceType. Does that make more sense?
>
> Thanks,
> Dan
>
> On Thu, Mar 16, 2017 at 3:34 PM, Dirk Rudolph (JIRA) 
> wrote:
>
> >
> > [ https://issues.apache.org/jira/browse/SLING-6655?page=
> > com.atlassian.jira.plugin.system.issuetabpanels:comment-
> > tabpanel=15928701#comment-15928701 ]
> >
> > Dirk Rudolph commented on SLING-6655:
> > -
> >
> > The difference is that its not obvious to understand what the purpose of
> a
> > certain piece of the implementation is. Anyway, would you be so kind and
> > point us to the right place where those methods are used for Handlebars?
> I
> > guess there is a JSR-223 compliant implementation somehow exposing
> > adaptTo() or the ModelFactory to the scripts themself. IMHO that one is
> > responsible for finding the right adapterType instead of enforcing 1:1
> > resourceType to adapterType.
> >
> > > Remove untyped getModelFrom* methods from ModelFactory
> > > --
> > >
> > > Key: SLING-6655
> > > URL: https://issues.apache.org/jira/browse/SLING-6655
> > > Project: Sling
> > >  Issue Type: Wish
> > >Affects Versions: Sling Models Impl 1.3.0
> > >Reporter: Dirk Rudolph
> > >
> > > As far as I understood the the whole story behind Sling Models API
> > is/was that it can be used to adapt ordinary objects to typed objects.
> With
> > adding {{Object getModelFromResource(...)}} and
> > {{getModelFromRequest(...)}} this paradigm has been broken. Just looking
> at
> > the API, what is the purpose of that methods? I agree that it makes much
> > sense to have a binding between the resourceType of {{Resource}} and
> maybe
> > even {{SlingHttpServletRequest}} and a model, but this resulting into an
> > ordinary object from API perspective makes it kind of pointless.
> > > I propose:
> > > * mark them as deprecated as already done in SLING-6652
> > > * let them throw {{UnsupportedOperationException}} to prevent them
> > being used
> > > * remove them in the next major API release
> > > * move the logic of "finding the nearest implementation by
> resourceType*
> > to {{ResourceTypeBasedResourcePicker}}
> > > and for the exporter:
> > > * if a {{@Model}} has an {{@Exporter}} implicitly registered it with
> the
> > {{implType}} as {{adapterType}}, if not already done
> > > * use the {{implType}} in the {{ExporterServlet}} to adapt from request
> > or {{Resource}} to the model object
> >
> >
> >
> > --
> > This message was sent by Atlassian JIRA
> > (v6.3.15#6346)
> >
>

[jira] [Commented] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6655:
---

bq. The difference is that its not obvious to understand what the purpose of a 
certain piece of the implementation is. 

The fact that these methods were designed for scripting was in the original 
JIRA. It can certainly be added to the JavaDoc if you think it would be helpful.

bq. Anyway, would you be so kind and point us to the right place where those 
methods are used for Handlebars?

Unfortunately no, the implementation isn't open source.

bq.  I guess there is a JSR-223 compliant implementation somehow exposing 
adaptTo() or the ModelFactory to the scripts themself. IMHO that one is 
responsible for finding the right adapterType instead of enforcing 1:1 
resourceType to adapterType.

Not exactly. The ScriptEngine invokes modelFactory.getModelFromResource() and 
then modelFactory.getModelFromRequest() (it might be the other way around; I 
don't have the code in front of me) and then makes the result available as a 
context object in the Handlebars script. It is important to not have any 
reference to ModelFactory or adaptTo() (or any other Java-ism) in the 
Handlebars script itself since otherwise isomorphic rendering wouldn't work. I 
imagine the same thing would be true if you were doing isomorphic rendering 
with a React-based ScriptEngine.

> Remove untyped getModelFrom* methods from ModelFactory
> --
>
> Key: SLING-6655
> URL: https://issues.apache.org/jira/browse/SLING-6655
> Project: Sling
>  Issue Type: Wish
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> As far as I understood the the whole story behind Sling Models API is/was 
> that it can be used to adapt ordinary objects to typed objects. With adding 
> {{Object getModelFromResource(...)}} and {{getModelFromRequest(...)}} this 
> paradigm has been broken. Just looking at the API, what is the purpose of 
> that methods? I agree that it makes much sense to have a binding between the 
> resourceType of {{Resource}} and maybe even {{SlingHttpServletRequest}} and a 
> model, but this resulting into an ordinary object from API perspective makes 
> it kind of pointless. 
> I propose:
> * mark them as deprecated as already done in SLING-6652
> * let them throw {{UnsupportedOperationException}} to prevent them being used
> * remove them in the next major API release
> * move the logic of "finding the nearest implementation by resourceType* to 
> {{ResourceTypeBasedResourcePicker}}
> and for the exporter:
> * if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
> {{implType}} as {{adapterType}}, if not already done
> * use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
> {{Resource}} to the model object



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

RE: Failing Build of current Trunk

[Stefan Seifert]

uh, my fault - should be fixed in rev. 1787254  

stefan

>-Original Message-
>From: Andreas Schaefer [mailto:andreas.schae...@madplanet.com]
>Sent: Thursday, March 16, 2017 10:09 PM
>To: dev
>Cc: Andreas Schaefer
>Subject: Failing Build of current Trunk
>
>Hi
>
>I tried to make sure that my Git repo is clean but today I am not able to
>build the current Git Repo.
>
>The root pom has this line:
>
>bundles/commons/fscontentparser
>
>but that module was renamed to bundles/jcr/contentparser on commit 103d84f9
>
>Cheers - Andy Schaefer
>

Failing Build of current Trunk

[Andreas Schaefer]

Hi

I tried to make sure that my Git repo is clean but today I am not able to build 
the current Git Repo.

The root pom has this line:

bundles/commons/fscontentparser

but that module was renamed to bundles/jcr/contentparser on commit 103d84f9

Cheers - Andy Schaefer

[jira] [Assigned] (SLING-4524) Provide the properties of the current Resource as a ValueMap via the sling:defineObjects tag

[Dan Klco (JIRA)]

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

Dan Klco reassigned SLING-4524:
---

Assignee: Dan Klco

> Provide the properties of the current Resource as a ValueMap via the 
> sling:defineObjects tag
> 
>
> Key: SLING-4524
> URL: https://issues.apache.org/jira/browse/SLING-4524
> Project: Sling
>  Issue Type: Wish
>  Components: Scripting
>Affects Versions: Scripting JSP-Taglib 2.2.6
>Reporter: Olaf Otto
>Assignee: Dan Klco
>
> One of the most common use cases in JSP views is accessing the properties of 
> the current resource. However, this currently requires explicit adaptation of 
> the current resource to ValueMap, which is boilerplate. I'd thus love to see 
> "properties" as one of the defaults provided by the before mentioned tag 
> library.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-4524) Provide the properties of the current Resource as a ValueMap via the sling:defineObjects tag

[Dan Klco (JIRA)]

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

Dan Klco commented on SLING-4524:
-

I agree with [~radu.cotescu]'s comment, this should probably in the 
BindingValuesProvider so it can be shared across the various scripting engines. 
http://markmail.org/message/c4yhj3hck5y4m3dg

> Provide the properties of the current Resource as a ValueMap via the 
> sling:defineObjects tag
> 
>
> Key: SLING-4524
> URL: https://issues.apache.org/jira/browse/SLING-4524
> Project: Sling
>  Issue Type: Wish
>  Components: Scripting
>Affects Versions: Scripting JSP-Taglib 2.2.6
>Reporter: Olaf Otto
>
> One of the most common use cases in JSP views is accessing the properties of 
> the current resource. However, this currently requires explicit adaptation of 
> the current resource to ValueMap, which is boilerplate. I'd thus love to see 
> "properties" as one of the defaults provided by the before mentioned tag 
> library.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: [jira] [Commented] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

[Daniel Klco]

I do think though that there's a ton of value in the concept of being able
to tie SlingModels to a resource type. I agree that this API is clunky, but
the idea of limiting based on resourceType in Sling Models was really
missing. I am using this concept for a library I have in progress right now
so that developers can "register" sling Models with a particular interface
against particular resourceTypes. My library then traverses down a resource
tree, adapting the objects and generating a representation of the tree for
a DataLayer representation. This works with the current functionality but
could be cleaner.

What I would really like to be able to do is something like this:

Collection models = modelFactory.getModelsByResourceType(Resource
resource, Class T);

I would expect the method to use both the Class and the Resource type to
generate the collection of models which match the requested class and are
applicable for the resourceType. Does that make more sense?

Thanks,
Dan

On Thu, Mar 16, 2017 at 3:34 PM, Dirk Rudolph (JIRA) 
wrote:

>
> [ https://issues.apache.org/jira/browse/SLING-6655?page=
> com.atlassian.jira.plugin.system.issuetabpanels:comment-
> tabpanel=15928701#comment-15928701 ]
>
> Dirk Rudolph commented on SLING-6655:
> -
>
> The difference is that its not obvious to understand what the purpose of a
> certain piece of the implementation is. Anyway, would you be so kind and
> point us to the right place where those methods are used for Handlebars? I
> guess there is a JSR-223 compliant implementation somehow exposing
> adaptTo() or the ModelFactory to the scripts themself. IMHO that one is
> responsible for finding the right adapterType instead of enforcing 1:1
> resourceType to adapterType.
>
> > Remove untyped getModelFrom* methods from ModelFactory
> > --
> >
> > Key: SLING-6655
> > URL: https://issues.apache.org/jira/browse/SLING-6655
> > Project: Sling
> >  Issue Type: Wish
> >Affects Versions: Sling Models Impl 1.3.0
> >Reporter: Dirk Rudolph
> >
> > As far as I understood the the whole story behind Sling Models API
> is/was that it can be used to adapt ordinary objects to typed objects. With
> adding {{Object getModelFromResource(...)}} and
> {{getModelFromRequest(...)}} this paradigm has been broken. Just looking at
> the API, what is the purpose of that methods? I agree that it makes much
> sense to have a binding between the resourceType of {{Resource}} and maybe
> even {{SlingHttpServletRequest}} and a model, but this resulting into an
> ordinary object from API perspective makes it kind of pointless.
> > I propose:
> > * mark them as deprecated as already done in SLING-6652
> > * let them throw {{UnsupportedOperationException}} to prevent them
> being used
> > * remove them in the next major API release
> > * move the logic of "finding the nearest implementation by resourceType*
> to {{ResourceTypeBasedResourcePicker}}
> > and for the exporter:
> > * if a {{@Model}} has an {{@Exporter}} implicitly registered it with the
> {{implType}} as {{adapterType}}, if not already done
> > * use the {{implType}} in the {{ExporterServlet}} to adapt from request
> or {{Resource}} to the model object
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.15#6346)
>

Package Manager should be whitelisted for Composum

[Andreas Schaefer]

Hi

Shouldn’t the package ‘com.composum.core.pckgmgr’ being added to the Apache 
Sling Login Admin Whitelist Configuration Fragment for ‘composum’?

As of now packages cannot be fully handled in composum without whitelisting it 
manually.

Cheers - Andy Schaefer Sr.

[jira] [Resolved] (SLING-6656) Wrong language name in GSPScriptEngineFactory

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-6656.
-
Resolution: Fixed

[r1787233|https://svn.apache.org/r1787233]

> Wrong language name in GSPScriptEngineFactory
> -
>
> Key: SLING-6656
> URL: https://issues.apache.org/jira/browse/SLING-6656
> Project: Sling
>  Issue Type: Bug
>  Components: Scripting
>Affects Versions: Scripting Groovy 1.0.2
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Scripting Groovy 1.0.4
>
>
> Should be _Groovy Server Pages_ instead of _Groovy Scripting Pages_.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6656) Wrong language name in GSPScriptEngineFactory

[Oliver Lietz (JIRA)]

Oliver Lietz created SLING-6656:
---

 Summary: Wrong language name in GSPScriptEngineFactory
 Key: SLING-6656
 URL: https://issues.apache.org/jira/browse/SLING-6656
 Project: Sling
  Issue Type: Bug
  Components: Scripting
Affects Versions: Scripting Groovy 1.0.2
Reporter: Oliver Lietz
Assignee: Oliver Lietz
 Fix For: Scripting Groovy 1.0.4


Should be _Groovy Server Pages_ instead of _Groovy Scripting Pages_.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-6655:
-

The difference is that its not obvious to understand what the purpose of a 
certain piece of the implementation is. Anyway, would you be so kind and point 
us to the right place where those methods are used for Handlebars? I guess 
there is a JSR-223 compliant implementation somehow exposing adaptTo() or the 
ModelFactory to the scripts themself. IMHO that one is responsible for finding 
the right adapterType instead of enforcing 1:1 resourceType to adapterType. 

> Remove untyped getModelFrom* methods from ModelFactory
> --
>
> Key: SLING-6655
> URL: https://issues.apache.org/jira/browse/SLING-6655
> Project: Sling
>  Issue Type: Wish
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> As far as I understood the the whole story behind Sling Models API is/was 
> that it can be used to adapt ordinary objects to typed objects. With adding 
> {{Object getModelFromResource(...)}} and {{getModelFromRequest(...)}} this 
> paradigm has been broken. Just looking at the API, what is the purpose of 
> that methods? I agree that it makes much sense to have a binding between the 
> resourceType of {{Resource}} and maybe even {{SlingHttpServletRequest}} and a 
> model, but this resulting into an ordinary object from API perspective makes 
> it kind of pointless. 
> I propose:
> * mark them as deprecated as already done in SLING-6652
> * let them throw {{UnsupportedOperationException}} to prevent them being used
> * remove them in the next major API release
> * move the logic of "finding the nearest implementation by resourceType* to 
> {{ResourceTypeBasedResourcePicker}}
> and for the exporter:
> * if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
> {{implType}} as {{adapterType}}, if not already done
> * use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
> {{Resource}} to the model object



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (SLING-6652) Allow multiple adapters for Models with resourceType binding

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-6652 at 3/16/17 7:21 PM:
--

The API change was considered like that because having n adapterTypes per 
resourceType requires a mechanism to elect which one to use (similar to 
ImplementationPicker). As this would be difficult to achieve which globally 
registered services in the exporter use case, making the untyped API deprecated 
but still keeping its functionality (aligned to the way the lookup() elects 
backed by alphabetical order). 

But you are right, the exporter doesn't really need them at all, not the 
deprecated ones nor the newly added ones (as long as the 
{{ResourceTypeBasedResourcePicker}} is in place)

And this issue is about: multiple adapter per resourceType in general and for 
the exporter in particular. 


was (Author: diru):
The API change was considered like that because having n adapterTypes per 
resourceType requires a mechanism to elect which one to use (similar to 
ImplementationPicker). As this would be difficult to achieve which globally 
registered services in the exporter use case, making the untyped API deprecated 
but still keeping its functionality (aligned to the way the lookup() elects 
backed by alphabetical order). 

But you are right, the exporter doesn't really need them at all, not the 
deprecated ones nor the newly added ones (as long as the 
{{ResourceTypeBasedResourcePicker}} is in place)

> Allow multiple adapters for Models with resourceType binding
> 
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> According to 
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
>  the AdapterImplementations support only mapping resourceType to Adapter 1:1. 
> I would like to propose extending that to support 1:n binding between 
> resourceType and adapter classes.
> My use case: 
> Lets assume I want to combine my models with the exporter framework to export 
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but 
> annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6652) Allow multiple adapters for Models with resourceType binding

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-6652:
-

The API change was considered like that because having n adapterTypes per 
resourceType requires a mechanism to elect which one to use (similar to 
ImplementationPicker). As this would be difficult to achieve which globally 
registered services in the exporter use case, making the untyped API deprecated 
but still keeping its functionality (aligned to the way the lookup() elects 
backed by alphabetical order). 

But you are right, the exporter doesn't really need them at all, not the 
deprecated ones nor the newly added ones (as long as the 
{{ResourceTypeBasedResourcePicker}} is in place)

> Allow multiple adapters for Models with resourceType binding
> 
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> According to 
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
>  the AdapterImplementations support only mapping resourceType to Adapter 1:1. 
> I would like to propose extending that to support 1:n binding between 
> resourceType and adapter classes.
> My use case: 
> Lets assume I want to combine my models with the exporter framework to export 
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but 
> annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6655:
---

bq. Ok I see but as far as I can see handlebars is not yet officially supported 
by sling

I fail to see what difference this makes. Sling has an open architecture and 
can support any language which has a JSR-223 adapter. Whether or not all of 
those languages are supported by Apache-branded bundles shouldn't really matter.

bq. Anyway from my perspective its in the responsibility of the scripting 
implementation then to decide which adaption they want to make if they don't 
know the type.

If the language doesn't provide any affordance to the script developer to make 
that election, I don't see how this is realistic.

> Remove untyped getModelFrom* methods from ModelFactory
> --
>
> Key: SLING-6655
> URL: https://issues.apache.org/jira/browse/SLING-6655
> Project: Sling
>  Issue Type: Wish
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> As far as I understood the the whole story behind Sling Models API is/was 
> that it can be used to adapt ordinary objects to typed objects. With adding 
> {{Object getModelFromResource(...)}} and {{getModelFromRequest(...)}} this 
> paradigm has been broken. Just looking at the API, what is the purpose of 
> that methods? I agree that it makes much sense to have a binding between the 
> resourceType of {{Resource}} and maybe even {{SlingHttpServletRequest}} and a 
> model, but this resulting into an ordinary object from API perspective makes 
> it kind of pointless. 
> I propose:
> * mark them as deprecated as already done in SLING-6652
> * let them throw {{UnsupportedOperationException}} to prevent them being used
> * remove them in the next major API release
> * move the logic of "finding the nearest implementation by resourceType* to 
> {{ResourceTypeBasedResourcePicker}}
> and for the exporter:
> * if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
> {{implType}} as {{adapterType}}, if not already done
> * use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
> {{Resource}} to the model object



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6652) Allow multiple adapters for Models with resourceType binding

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6652:
---

Looking at the Pull Request and reading the original description, I'm a little 
confused about the problem you are trying to solve. If this is really about 
having different model classes respond to different selector/extension 
combinations, then no API changes should be required (except maybe a new 
annotation attribute but even that is debatable). If instead you actually want 
to define new APIs, the use case for those APIs should be described. Right now, 
the description of this issue *only* talks about Exporters.

> Allow multiple adapters for Models with resourceType binding
> 
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> According to 
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
>  the AdapterImplementations support only mapping resourceType to Adapter 1:1. 
> I would like to propose extending that to support 1:n binding between 
> resourceType and adapter classes.
> My use case: 
> Lets assume I want to combine my models with the exporter framework to export 
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but 
> annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-6655:
-

Ok I see but as far as I can see handlebars is not yet officially supported by 
sling (not even in contrib and scripting itself). 

Anyway from my perspective its in the responsibility of the scripting 
implementation then to decide which adaption they want to make if they don't 
know the type. Wdyt?

> Remove untyped getModelFrom* methods from ModelFactory
> --
>
> Key: SLING-6655
> URL: https://issues.apache.org/jira/browse/SLING-6655
> Project: Sling
>  Issue Type: Wish
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> As far as I understood the the whole story behind Sling Models API is/was 
> that it can be used to adapt ordinary objects to typed objects. With adding 
> {{Object getModelFromResource(...)}} and {{getModelFromRequest(...)}} this 
> paradigm has been broken. Just looking at the API, what is the purpose of 
> that methods? I agree that it makes much sense to have a binding between the 
> resourceType of {{Resource}} and maybe even {{SlingHttpServletRequest}} and a 
> model, but this resulting into an ordinary object from API perspective makes 
> it kind of pointless. 
> I propose:
> * mark them as deprecated as already done in SLING-6652
> * let them throw {{UnsupportedOperationException}} to prevent them being used
> * remove them in the next major API release
> * move the logic of "finding the nearest implementation by resourceType* to 
> {{ResourceTypeBasedResourcePicker}}
> and for the exporter:
> * if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
> {{implType}} as {{adapterType}}, if not already done
> * use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
> {{Resource}} to the model object



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-6655 at 3/16/17 7:06 PM:
--

Ok I see but as far as I can see handlebars is not yet officially supported by 
sling (not even in contrib and SLING-2919 has been closed with Won't fix). 

Anyway from my perspective its in the responsibility of the scripting 
implementation then to decide which adaption they want to make if they don't 
know the type. Wdyt?


was (Author: diru):
Ok I see but as far as I can see handlebars is not yet officially supported by 
sling (not even in contrib and scripting itself). 

Anyway from my perspective its in the responsibility of the scripting 
implementation then to decide which adaption they want to make if they don't 
know the type. Wdyt?

> Remove untyped getModelFrom* methods from ModelFactory
> --
>
> Key: SLING-6655
> URL: https://issues.apache.org/jira/browse/SLING-6655
> Project: Sling
>  Issue Type: Wish
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> As far as I understood the the whole story behind Sling Models API is/was 
> that it can be used to adapt ordinary objects to typed objects. With adding 
> {{Object getModelFromResource(...)}} and {{getModelFromRequest(...)}} this 
> paradigm has been broken. Just looking at the API, what is the purpose of 
> that methods? I agree that it makes much sense to have a binding between the 
> resourceType of {{Resource}} and maybe even {{SlingHttpServletRequest}} and a 
> model, but this resulting into an ordinary object from API perspective makes 
> it kind of pointless. 
> I propose:
> * mark them as deprecated as already done in SLING-6652
> * let them throw {{UnsupportedOperationException}} to prevent them being used
> * remove them in the next major API release
> * move the logic of "finding the nearest implementation by resourceType* to 
> {{ResourceTypeBasedResourcePicker}}
> and for the exporter:
> * if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
> {{implType}} as {{adapterType}}, if not already done
> * use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
> {{Resource}} to the model object



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: PaxExam based ITs create folders outside target

[Oliver Lietz]

On Thursday 16 March 2017 15:21:32 Konrad Windszus wrote:
> Some javadocs in
> https://github.com/apache/sling/blob/trunk/testing/org.apache.sling.testing
> .paxexam/src/main/java/org/apache/sling/testing/paxexam/SlingOptions.java#L8
> 62 would be really helpful, which explain under which circumstances you have
> to use the methods with the workingDirectory and when you are allowed to
> use the methods without.

As explained in SLING-6653 you can use slingLaunchpadOakTar and 
slingLaunchpadOakMongo options without a working directory pointing below 
target, but you have to clean up yourself then. I've added a note to README.

> IIUC paxexam is purely for testing, therefore you
> should always use absolute paths (because you cannot rely on
> repository.home being set correctly).

Again, you can do whatever you like and Testing PaxExam provides a method 
workingDirectory() to construct an absolute path below project's 
basedir/target which can be used for options slingLaunchpadOakTar and 
slingLaunchpadOakMongo with parameter workingDirectory (and httpPort and 
mongouri). That way is shown in the README. When not using those launchpad 
options but configuring a custom one you can even set repository.home and use 
that instead of course. Why do you think it's not reliable?

Regards,
O.

> Konrad
> 
> > On 16 Mar 2017, at 14:11, Oliver Lietz  wrote:
> > 
> > On Thursday 16 March 2017 13:54:23 Konrad Windszus wrote:
> >> Probably this commit
> >> https://github.com/apache/sling/blame/trunk/testing/org.apache.sling.test
> >> in
> >> g.paxexam/src/main/java/org/apache/sling/testing/paxexam/SlingOptions.jav
> >> a#L 645 is not correct. The localIndexDir should be IMHO set as absolute
> >> path (not relative!) This is done correctly in
> >> https://github.com/apache/sling/blame/trunk/testing/org.apache.sling.test
> >> in
> >> g.paxexam/src/main/java/org/apache/sling/testing/paxexam/SlingOptions.jav
> >> a#L 879. I am also not getting why the configuration is set two times.
> >> IMHO this should be set only once in the slingLaunchpadOak() with an
> >> absolute path!
> > 
> > No, relative paths are fine for Sling home in normal deployments but not
> > in
> > testing (because directories are not created under target). Therefore
> > configuration moved to sling-launchpad-oak-tar (slingLaunchpadOakTar) and
> > sling-launchpad-oak-mongo (slingLaunchpadOakMongo). You usually don't use
> > those options but slingLaunchpadOakTar(String, int) with configured
> > working
> > directory and HTTP port.
> > 
> > Regards,
> > O.
> > 
> >>> On 16 Mar 2017, at 13:45, Konrad Windszus  wrote:
> >>> 
> >>> Maybe this is related to
> >>> https://issues.apache.org/jira/browse/SLING-4649?focusedCommentId=145088
> >>> 5
> >>> 7=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#
> >>> co
> >>> mment-14508857. It seems that the Lucene index relies on a framework
> >>> property (named repository.home) if this is not explicitly configured.
> >>> Seems that Karaf does not support setting that, therefore the Lucene
> >>> index is created in the wrong directory (and sometime not correctly
> >>> removed). I am still failing to reproduce locally though
> >>> Konrad
> >>> 
>  On 16 Mar 2017, at 13:31, Konrad Windszus  wrote:
>  
>  Hi,
>  it seems that PaxExam based ITs may create folders outside the target
>  folder (see
>  https://builds.apache.org/job/sling-bundles-extensions-validation-core-> 
>   1
>  .8/ws/) For Validation the folder
>  sling/repository/index/lucene-1488547426482/data was obviously created
>  by PaxExam.
>  
>  Usually the repository lives below
>  https://builds.apache.org/job/sling-bundles-extensions-validation-core-> 
>   1
>  .8/ws/target/paxexam/ValidationServiceIT/sling/repository/
>  
>  I also sometimes have seen this locally but I fail to reproduce it
>  reliably. Does anyone have an idea, why the lucene index is there?
>  Seems that PaxExam relies on relative paths somehow, which are
>  sometimes
>  relative to target and sometimes to the project root.
>  
>  Thanks for any help
>  Konrad
>  
> > On 16 Mar 2017, at 12:11, Apache Jenkins Server
> >  wrote:
> > 
> > See
> >  > e
> > -1.8/55/display/redirect?page=changes>
> > 
> > Changes:
> > 
> > [kwin] fix some more warnings
> > 
> > --
> > Started by an SCM change
> > Started by upstream project
> > "sling-bundles-extensions-validation-test-services-1.8" build number
> > 28
> > originally caused by:
> > Started by upstream project
> > "sling-bundles-extensions-validation-api-1.8" build number 25
> > originally caused by:
> > Started by an SCM change
> > 

[jira] [Commented] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6655:
---

Handlebars is the most obvious case where typing is not available.

> Remove untyped getModelFrom* methods from ModelFactory
> --
>
> Key: SLING-6655
> URL: https://issues.apache.org/jira/browse/SLING-6655
> Project: Sling
>  Issue Type: Wish
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> As far as I understood the the whole story behind Sling Models API is/was 
> that it can be used to adapt ordinary objects to typed objects. With adding 
> {{Object getModelFromResource(...)}} and {{getModelFromRequest(...)}} this 
> paradigm has been broken. Just looking at the API, what is the purpose of 
> that methods? I agree that it makes much sense to have a binding between the 
> resourceType of {{Resource}} and maybe even {{SlingHttpServletRequest}} and a 
> model, but this resulting into an ordinary object from API perspective makes 
> it kind of pointless. 
> I propose:
> * mark them as deprecated as already done in SLING-6652
> * let them throw {{UnsupportedOperationException}} to prevent them being used
> * remove them in the next major API release
> * move the logic of "finding the nearest implementation by resourceType* to 
> {{ResourceTypeBasedResourcePicker}}
> and for the exporter:
> * if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
> {{implType}} as {{adapterType}}, if not already done
> * use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
> {{Resource}} to the model object



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph edited comment on SLING-6655 at 3/16/17 6:58 PM:
--

By example? The only one (from sling/bundles/scripting) that would come to my 
mind is javascript. Sightly's use and JSPs are both typed. 

Wouldn't it make sense to handle that corner case in javascript then?


was (Author: diru):
By example? The only one that would come to my mind is javascript. Sightly's 
use and JSPs are both typed. 

Wouldn't it make sense to handle that corner case in javascript then?

> Remove untyped getModelFrom* methods from ModelFactory
> --
>
> Key: SLING-6655
> URL: https://issues.apache.org/jira/browse/SLING-6655
> Project: Sling
>  Issue Type: Wish
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> As far as I understood the the whole story behind Sling Models API is/was 
> that it can be used to adapt ordinary objects to typed objects. With adding 
> {{Object getModelFromResource(...)}} and {{getModelFromRequest(...)}} this 
> paradigm has been broken. Just looking at the API, what is the purpose of 
> that methods? I agree that it makes much sense to have a binding between the 
> resourceType of {{Resource}} and maybe even {{SlingHttpServletRequest}} and a 
> model, but this resulting into an ordinary object from API perspective makes 
> it kind of pointless. 
> I propose:
> * mark them as deprecated as already done in SLING-6652
> * let them throw {{UnsupportedOperationException}} to prevent them being used
> * remove them in the next major API release
> * move the logic of "finding the nearest implementation by resourceType* to 
> {{ResourceTypeBasedResourcePicker}}
> and for the exporter:
> * if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
> {{implType}} as {{adapterType}}, if not already done
> * use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
> {{Resource}} to the model object



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6655:
---

Also, I don't see where SLING-6652 talks about deprecating these methods nor do 
I see why that would be necessary to solve the problem you reported there.

> Remove untyped getModelFrom* methods from ModelFactory
> --
>
> Key: SLING-6655
> URL: https://issues.apache.org/jira/browse/SLING-6655
> Project: Sling
>  Issue Type: Wish
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> As far as I understood the the whole story behind Sling Models API is/was 
> that it can be used to adapt ordinary objects to typed objects. With adding 
> {{Object getModelFromResource(...)}} and {{getModelFromRequest(...)}} this 
> paradigm has been broken. Just looking at the API, what is the purpose of 
> that methods? I agree that it makes much sense to have a binding between the 
> resourceType of {{Resource}} and maybe even {{SlingHttpServletRequest}} and a 
> model, but this resulting into an ordinary object from API perspective makes 
> it kind of pointless. 
> I propose:
> * mark them as deprecated as already done in SLING-6652
> * let them throw {{UnsupportedOperationException}} to prevent them being used
> * remove them in the next major API release
> * move the logic of "finding the nearest implementation by resourceType* to 
> {{ResourceTypeBasedResourcePicker}}
> and for the exporter:
> * if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
> {{implType}} as {{adapterType}}, if not already done
> * use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
> {{Resource}} to the model object



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-6655:
-

By example? The only one that would come to my mind is javascript. Sightly's 
use and JSPs are both typed. 

Wouldn't it make sense to handle that corner case in javascript then?

> Remove untyped getModelFrom* methods from ModelFactory
> --
>
> Key: SLING-6655
> URL: https://issues.apache.org/jira/browse/SLING-6655
> Project: Sling
>  Issue Type: Wish
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> As far as I understood the the whole story behind Sling Models API is/was 
> that it can be used to adapt ordinary objects to typed objects. With adding 
> {{Object getModelFromResource(...)}} and {{getModelFromRequest(...)}} this 
> paradigm has been broken. Just looking at the API, what is the purpose of 
> that methods? I agree that it makes much sense to have a binding between the 
> resourceType of {{Resource}} and maybe even {{SlingHttpServletRequest}} and a 
> model, but this resulting into an ordinary object from API perspective makes 
> it kind of pointless. 
> I propose:
> * mark them as deprecated as already done in SLING-6652
> * let them throw {{UnsupportedOperationException}} to prevent them being used
> * remove them in the next major API release
> * move the logic of "finding the nearest implementation by resourceType* to 
> {{ResourceTypeBasedResourcePicker}}
> and for the exporter:
> * if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
> {{implType}} as {{adapterType}}, if not already done
> * use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
> {{Resource}} to the model object



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6655:
---

These methods exist for loosely typed scripting languages where you don't know 
the target class or interface, but just want the related model.

> Remove untyped getModelFrom* methods from ModelFactory
> --
>
> Key: SLING-6655
> URL: https://issues.apache.org/jira/browse/SLING-6655
> Project: Sling
>  Issue Type: Wish
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> As far as I understood the the whole story behind Sling Models API is/was 
> that it can be used to adapt ordinary objects to typed objects. With adding 
> {{Object getModelFromResource(...)}} and {{getModelFromRequest(...)}} this 
> paradigm has been broken. Just looking at the API, what is the purpose of 
> that methods? I agree that it makes much sense to have a binding between the 
> resourceType of {{Resource}} and maybe even {{SlingHttpServletRequest}} and a 
> model, but this resulting into an ordinary object from API perspective makes 
> it kind of pointless. 
> I propose:
> * mark them as deprecated as already done in SLING-6652
> * let them throw {{UnsupportedOperationException}} to prevent them being used
> * remove them in the next major API release
> * move the logic of "finding the nearest implementation by resourceType* to 
> {{ResourceTypeBasedResourcePicker}}
> and for the exporter:
> * if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
> {{implType}} as {{adapterType}}, if not already done
> * use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
> {{Resource}} to the model object



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-6655:

Description: 
As far as I understood the the whole story behind Sling Models API is/was that 
it can be used to adapt ordinary objects to typed objects. With adding {{Object 
getModelFromResource(...)}} and {{getModelFromRequest(...)}} this paradigm has 
been broken. Just looking at the API, what is the purpose of that methods? I 
agree that it makes much sense to have a binding between the resourceType of 
{{Resource}} and maybe even {{SlingHttpServletRequest}} and a model, but this 
resulting into an ordinary object from API perspective makes it kind of 
pointless. 

I propose:
* mark them as deprecated as already done in SLING-6652
* let them throw {{UnsupportedOperationException}} to prevent them being used
* remove them in the next major API release
* move the logic of "finding the nearest implementation by resourceType* to 
{{ResourceTypeBasedResourcePicker}}

and for the exporter:
* if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
{{implType}} as {{adapterType}}, if not already done
* use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
{{Resource}} to the model object

  was:
As far as I understood the the whole story behind Sling Models API is/was that 
I can be used to adapt {{Adaptable}}s to typed objects. With adding {{Object 
getModelFromResource(...)}} and {{getModelFromRequest(...)}} this paradigm has 
been broken. Just looking at the API what is the purpose of that methods? How 
and why to use them? I agree that it makes much sense to have a binding between 
the resourceType of {{Resource}} and maybe even {{SlingHttpServletRequest}} and 
a Model, but this resulting into an ordinary object from API perspective makes 
it kind of pointless. 

I propose:
* mark them as deprecated as already done in SLING-6652
* let them throw {{UnsupportedOperationException}} to prevent them being used
* remove them in the next major API release
* move the logic of "finding the nearest implementation by resourceType* to 
{{ResourceTypeBasedResourcePicker}}

and for the exporter:
* if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
{{implType}} as {{adapterType}}, if not already done
* use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
{{Resource}} to the model object


> Remove untyped getModelFrom* methods from ModelFactory
> --
>
> Key: SLING-6655
> URL: https://issues.apache.org/jira/browse/SLING-6655
> Project: Sling
>  Issue Type: Wish
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> As far as I understood the the whole story behind Sling Models API is/was 
> that it can be used to adapt ordinary objects to typed objects. With adding 
> {{Object getModelFromResource(...)}} and {{getModelFromRequest(...)}} this 
> paradigm has been broken. Just looking at the API, what is the purpose of 
> that methods? I agree that it makes much sense to have a binding between the 
> resourceType of {{Resource}} and maybe even {{SlingHttpServletRequest}} and a 
> model, but this resulting into an ordinary object from API perspective makes 
> it kind of pointless. 
> I propose:
> * mark them as deprecated as already done in SLING-6652
> * let them throw {{UnsupportedOperationException}} to prevent them being used
> * remove them in the next major API release
> * move the logic of "finding the nearest implementation by resourceType* to 
> {{ResourceTypeBasedResourcePicker}}
> and for the exporter:
> * if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
> {{implType}} as {{adapterType}}, if not already done
> * use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
> {{Resource}} to the model object



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6655) Remove untyped getModelFrom* methods from ModelFactory

[Dirk Rudolph (JIRA)]

Dirk Rudolph created SLING-6655:
---

 Summary: Remove untyped getModelFrom* methods from ModelFactory
 Key: SLING-6655
 URL: https://issues.apache.org/jira/browse/SLING-6655
 Project: Sling
  Issue Type: Wish
Affects Versions: Sling Models Impl 1.3.0
Reporter: Dirk Rudolph


As far as I understood the the whole story behind Sling Models API is/was that 
I can be used to adapt {{Adaptable}}s to typed objects. With adding {{Object 
getModelFromResource(...)}} and {{getModelFromRequest(...)}} this paradigm has 
been broken. Just looking at the API what is the purpose of that methods? How 
and why to use them? I agree that it makes much sense to have a binding between 
the resourceType of {{Resource}} and maybe even {{SlingHttpServletRequest}} and 
a Model, but this resulting into an ordinary object from API perspective makes 
it kind of pointless. 

I propose:
* mark them as deprecated as already done in SLING-6652
* let them throw {{UnsupportedOperationException}} to prevent them being used
* remove them in the next major API release
* move the logic of "finding the nearest implementation by resourceType* to 
{{ResourceTypeBasedResourcePicker}}

and for the exporter:
* if a {{@Model}} has an {{@Exporter}} implicitly registered it with the 
{{implType}} as {{adapterType}}, if not already done
* use the {{implType}} in the {{ExporterServlet}} to adapt from request or 
{{Resource}} to the model object



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] sling pull request #204: Feature/sling 6652

[Buuhuu]

GitHub user Buuhuu opened a pull request:

https://github.com/apache/sling/pull/204

Feature/sling 6652

This pull requests enables 1 to many binding from resourceType to model.

IMHO the implementation is quite ugly because of the way resourceType 
binding is defined. In the current interface the untyped methods 
getModelFromResource(Resource) and getModelFromRequest(SlingHttpServletRequest) 
have been added to ModelFactory. Those are not conform to the way the 
ModelFactory implementation work: creating a typed object from something. I 
understood that the usecase for the jackson exporter doesn't require a typed 
object as exporting an ordinary one works quite well but it makes hard to 
decide which adapterType should be used in case multiple are registered for a 
single resourceType. Having said that I deprecated those methods along with 
related ones but still supporting their expected functionality only with a 
slightly different as adapterTypes are now sorted alphabetically the same way 
its done for the original adapter implementations. Anyway removing those, or 
throwing USOE would make much sense to make the API clean again. Most of the 
code added to Adapter
 Implementations can and should be moved to the ImplementationPicker using it 
which is supposed to decide which implementation to use based on the 
adaptable's resourceType. For the exporter a slightly adjusting would be 
required which is now also implemented. Keeping in mind that class level 
annotations are not inherited there is a 1:1 relation between @Exporter and its 
implementation class and with that we can implicitly add the implType to the 
adapterTypes if not already present. As the implType is known to the 
ExporterServlet anyway it can use it to get the typed object for exporting.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Buuhuu/sling feature/SLING-6652

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/204.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #204


commit f8f0b144bab782e3039eefb9317b20e2147ef508
Author: Dirk Rudolph 
Date:   2017-03-16T18:00:41Z

SLING-6652: extended ModelFactory by deprecating untyped methods using the 
resourceType binding and adding typed equivalent ones

commit 87de04c0f8519cfc47910e9bdb51dc2a21a3013a
Author: Dirk Rudolph 
Date:   2017-03-16T18:03:29Z

SLING-6652:
 - updatd dependecy to latest snapshot of the models api
 - intorduced new data strcture to store multiple adapterTypes/adapter 
implementations per resource type
 - adapted AdapterImplementations to new data structure
 - implemented new typed methods defined at ModelFactory using 
AdapterImplementations
 - adapted UnitTest to new, alphabetical order of registered adapter types 
per resource type

commit a910cae0ecc6a8471a9eb302938bf21872f1569a
Author: Dirk Rudolph 
Date:   2017-03-16T18:07:07Z

SLING-6652:
- reverted formatting changes

commit 2dbc3b4d395672834793dc989f0f4af7221f
Author: Dirk Rudolph 
Date:   2017-03-16T18:10:09Z

SLING-6652:
- reverted formatting changes




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [contentparser] API for simple content representation

[Carsten Ziegeler]

Lgtm, thanks Stefan!

Carsten

Stefan Seifert wrote
> i've prepare a new PR with *only* a streaming API [1].
> please have a new review on the API part.
> 
> it has a very simple ContentHandler interface which reports every resource 
> found with its map of properties - ordered as found in the source.
> 
> to keep the existing unit tests i added the handler that converts the stream 
> API to a map representation to the *unit test* code - this is the code which 
> will then be duplicated across the modules that need a map representation. [2]
> 
> when this is the way we want to go i will commit it.
> 
> stefan
> 
> [1] https://github.com/apache/sling/pull/203
> [2] 
> https://github.com/stefanseifert/sling/tree/feature/SLING-6592-contentparser-stream-api/bundles/jcr/contentparser/src/test/java/org/apache/sling/jcr/contentparser/impl/mapsupport
> 
> 
> 
>> -Original Message-
>> From: Carsten Ziegeler [mailto:cziege...@apache.org]
>> Sent: Wednesday, March 15, 2017 3:35 PM
>> To: dev@sling.apache.org
>> Subject: Re: [contentparser] API for simple content representation
>>
>> Stefan Seifert wrote
>>>
 A streaming API which defines a handler with a method that gets the name
 (or path?) and the map of properties would avoid having this additional
 tree api. I don't see a huge need to be able to have an api to traverse
 the parsed content. If any user of the contentparser really needs it, it
 can use whatever it wants.
>>>
>>> a Stream API would be a good solution for one half of the use cases.
>>> the other half benefits from a Traversing API - we may leave it to the
>> other bundles and live with some code duplication.
>>>
>>> before dropping traversing API completely - what about this: we rename
>> the traversing API to something that makes it obvious that this is not yet-
>> another-content-representation-api but only a tool to hand over data - e.g.
>> "ParsingResult" instead of "Content"?
>>>
>>> the solution could be:
>>> - offer a Streaming API
>>> - offer an optional handler based on this streaming API that produces a
>> "ParsingResult" that has the minimal traversing capabilities as outlined in
>> the PR.
>>>
>>> we could even put this in two separate modules, but this feels a bit
>> over-engineered.
>>>
>>
>> I guess whatever we name it, it's another traversing API :)
>> I would prefer to go with just the streaming api and only if really
>> really really needed by many others start about thinking how to solve that.
>>
>> Carsten
>> --
>> Carsten Ziegeler
>> Adobe Research Switzerland
>> cziege...@apache.org
> 


 

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

[jira] [Created] (SLING-6654) Test distribution has a wrong header

[Tommaso Teofili (JIRA)]

Tommaso Teofili created SLING-6654:
--

 Summary: Test distribution has a wrong header
 Key: SLING-6654
 URL: https://issues.apache.org/jira/browse/SLING-6654
 Project: Sling
  Issue Type: Bug
  Components: Content Distribution
Affects Versions: Content Distribution Core 0.2.6
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
 Fix For: Content Distribution Core 0.2.8


{{SimpleDistributionPackage}} doesn't set the paths if they are empty and, most 
importantly, its delimiter, therefore {{ResourcePackageBuilder}} may fail at 
persisting it because of the resulting wrong header in the package.




--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6652) Allow multiple adapters for Models with resourceType binding

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6652:
---

Understood. I was just expressing how this was designed to be implemented based 
on the fact that a call to

{code}
modelAdapterFactory.getModelFromResource(resource)
{code}

had to be deterministic.

> Allow multiple adapters for Models with resourceType binding
> 
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> According to 
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
>  the AdapterImplementations support only mapping resourceType to Adapter 1:1. 
> I would like to propose extending that to support 1:n binding between 
> resourceType and adapter classes.
> My use case: 
> Lets assume I want to combine my models with the exporter framework to export 
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but 
> annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6652) Allow multiple adapters for Models with resourceType binding

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-6652:
-

This is not what this is about. See I have a resource

{code}
/content/www/my/pages/apage
 + sling:resourceType='my/test/page'
 + ...
{code}

and want to export this resource once as metadata requested with 
"model.metadata" and with "model.data" where each of the selectors represent 
different models of the same resource. So I created 

{code}
@Model(adaptables = Resource.class, resourceType='my/test/page')
@Exporter(..., selector="model.metadata")
class ModelA {
 public String getProp1() { ... } 
 public String getProp2() { ... } 
}
{code} 

and

{code}
@Model(adaptables = Resource.class, resourceType='my/test/page')
@Exporter(..., selector="model.data")
class ModelB {
 public String[] getAllProps() { ... }
}
{code} 

This is a really simplified example where the actual code applies a lot of 
*different* business logic within the different models.

> Allow multiple adapters for Models with resourceType binding
> 
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> According to 
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
>  the AdapterImplementations support only mapping resourceType to Adapter 1:1. 
> I would like to propose extending that to support 1:n binding between 
> resourceType and adapter classes.
> My use case: 
> Lets assume I want to combine my models with the exporter framework to export 
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but 
> annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (SLING-6651) Improve documentation for htl-maven-plugin

[Radu Cotescu (JIRA)]

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

Radu Cotescu reassigned SLING-6651:
---

Assignee: Radu Cotescu

> Improve documentation for htl-maven-plugin
> --
>
> Key: SLING-6651
> URL: https://issues.apache.org/jira/browse/SLING-6651
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: HTL Maven Plugin 1.0.6
>Reporter: Jörg Hoh
>Assignee: Radu Cotescu
>
> Currently the official documentation site for the htl-maven-plugin [1] gives 
> very little information about what the plugin does. It should be improved to 
> make clear, what kind of checks against the HTL scripts are executed.
> An example for a typical usecase would be good as well.
> [1] http://sling.apache.org/components/htl-maven-plugin/



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6652) Allow multiple adapters for Models with resourceType binding

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6652:
---

Sorry, I'm not making myself clear. What I mean is something like:

{code}
@Exporters{
   @Exporter(name = "jackson", extensions = "json", selector = "metadata", 
options = {
  // whatever options are needed for the metadata output
   }),
  @Exporter(name = "jackson", extensions = "json", selector = "data", options = 
{
  // whatever options are needed for the data output
   })
}
@Model(...)
public class AImpl {}
{code}

Now obviously the wildcard is here is whether or not you can actually do what 
you need with the options available. If not, can new options be supported which 
do what you need? For example, one thing I was toying with was the idea of 
making the inclusion of Jackson Modules conditional (right now, if you create a 
{{ModuleProvider}} it gets applied all the time). 

> Allow multiple adapters for Models with resourceType binding
> 
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> According to 
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
>  the AdapterImplementations support only mapping resourceType to Adapter 1:1. 
> I would like to propose extending that to support 1:n binding between 
> resourceType and adapter classes.
> My use case: 
> Lets assume I want to combine my models with the exporter framework to export 
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but 
> annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6652) Allow multiple adapters for Models with resourceType binding

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-6652:
-

That indeed was my initial idea. Having 2 models AImpl and BImpl both 
registered to the resourceType 'my/resource/type' but having different 
selectors set for @Exporter. This unfortunately doesn't work.

> Allow multiple adapters for Models with resourceType binding
> 
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> According to 
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
>  the AdapterImplementations support only mapping resourceType to Adapter 1:1. 
> I would like to propose extending that to support 1:n binding between 
> resourceType and adapter classes.
> My use case: 
> Lets assume I want to combine my models with the exporter framework to export 
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but 
> annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6652) Allow multiple adapters for Models with resourceType binding

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6652:
---

Not necessarily a different implementation of the {{Exporter}} interface 
(although that's definitely possible), but somehow using the {{@Exporter}} 
annotation's options. Updated my comment above to try to make this clearer.

> Allow multiple adapters for Models with resourceType binding
> 
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> According to 
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
>  the AdapterImplementations support only mapping resourceType to Adapter 1:1. 
> I would like to propose extending that to support 1:n binding between 
> resourceType and adapter classes.
> My use case: 
> Lets assume I want to combine my models with the exporter framework to export 
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but 
> annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (SLING-6652) Allow multiple adapters for Models with resourceType binding

[Justin Edelson (JIRA)]

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

Justin Edelson edited comment on SLING-6652 at 3/16/17 4:03 PM:


The way I had anticipated this being handled was by two different {{@Exporter}} 
annotations. Is that not possible in your case?


was (Author: justinedelson):
The way I had anticipated this being handled was by two different exporters. Is 
that not possible in your case?

> Allow multiple adapters for Models with resourceType binding
> 
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> According to 
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
>  the AdapterImplementations support only mapping resourceType to Adapter 1:1. 
> I would like to propose extending that to support 1:n binding between 
> resourceType and adapter classes.
> My use case: 
> Lets assume I want to combine my models with the exporter framework to export 
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but 
> annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Time for a Sling Validation 1.0.0 release

[Oliver Lietz]

On Thursday 16 March 2017 16:04:12 Konrad Windszus wrote:
> I am blocked for the release by the 0.0.3-SNAPSHOT testing dependency to
> org.apache.sling.testing.paxexam in validation.core. Is this gonna be
> released soon?

Yes, I will do some more releases which should be part of 0.0.4 and Sling 9 
tonight.

> Otherwise would it be possible to revert to 0.0.2?

Maybe.

O.

> Konrad
> 
> > On 1 Mar 2017, at 09:03, Konrad Windszus  wrote:
> > 
> > Hi everyone,
> > I think it is time now for a first release of Sling Validation. I used it
> > in several projects already productively and fixed a lot of bugs and
> > refactored the interfaces from the initial proposal from Radu quite a bit
> > (44 issues have been resolved since then,
> > https://issues.apache.org/jira/browse/SLING/fixforversion/12328980). It
> > would be good if everyone who could afford some time could quickly
> > cross-check the API at
> > https://github.com/apache/sling/tree/trunk/bundles/extensions/validation/
> > api. All concerns being raised in a previous review
> > (https://issues.apache.org/jira/browse/SLING-4027) have been addressed
> > meanwhile.
> > 
> > Thanks,
> > Konrad

RE: [contentparser] API for simple content representation

[Stefan Seifert]

i've prepare a new PR with *only* a streaming API [1].
please have a new review on the API part.

it has a very simple ContentHandler interface which reports every resource 
found with its map of properties - ordered as found in the source.

to keep the existing unit tests i added the handler that converts the stream 
API to a map representation to the *unit test* code - this is the code which 
will then be duplicated across the modules that need a map representation. [2]

when this is the way we want to go i will commit it.

stefan

[1] https://github.com/apache/sling/pull/203
[2] 
https://github.com/stefanseifert/sling/tree/feature/SLING-6592-contentparser-stream-api/bundles/jcr/contentparser/src/test/java/org/apache/sling/jcr/contentparser/impl/mapsupport



>-Original Message-
>From: Carsten Ziegeler [mailto:cziege...@apache.org]
>Sent: Wednesday, March 15, 2017 3:35 PM
>To: dev@sling.apache.org
>Subject: Re: [contentparser] API for simple content representation
>
>Stefan Seifert wrote
>>
>>> A streaming API which defines a handler with a method that gets the name
>>> (or path?) and the map of properties would avoid having this additional
>>> tree api. I don't see a huge need to be able to have an api to traverse
>>> the parsed content. If any user of the contentparser really needs it, it
>>> can use whatever it wants.
>>
>> a Stream API would be a good solution for one half of the use cases.
>> the other half benefits from a Traversing API - we may leave it to the
>other bundles and live with some code duplication.
>>
>> before dropping traversing API completely - what about this: we rename
>the traversing API to something that makes it obvious that this is not yet-
>another-content-representation-api but only a tool to hand over data - e.g.
>"ParsingResult" instead of "Content"?
>>
>> the solution could be:
>> - offer a Streaming API
>> - offer an optional handler based on this streaming API that produces a
>"ParsingResult" that has the minimal traversing capabilities as outlined in
>the PR.
>>
>> we could even put this in two separate modules, but this feels a bit
>over-engineered.
>>
>
>I guess whatever we name it, it's another traversing API :)
>I would prefer to go with just the streaming api and only if really
>really really needed by many others start about thinking how to solve that.
>
>Carsten
>--
>Carsten Ziegeler
>Adobe Research Switzerland
>cziege...@apache.org

[jira] [Commented] (SLING-6592) JCR Content Parser

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on SLING-6592:
---

GitHub user stefanseifert opened a pull request:

https://github.com/apache/sling/pull/203

SLING-6592 switch to stream-based API for ContentParser



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/stefanseifert/sling 
feature/SLING-6592-contentparser-stream-api

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/203.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #203


commit 54159e8cba118cfa9df109e4e7fea6ce6ce1a55e
Author: sseifert 
Date:   2017-03-16T15:28:18Z

SLING-6592 switch to stream-based API for ContentParser




> JCR Content Parser
> --
>
> Key: SLING-6592
> URL: https://issues.apache.org/jira/browse/SLING-6592
> Project: Sling
>  Issue Type: New Feature
>  Components: JCR
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: JCR Content Parser 1.0.0
>
>
> for different usecases around file system resource provider and sling mocks 
> (see related tickets) we need to parse content structures from files in the 
> file system, e.g. in JSON format or JCR XML format.
> we should put this code in a new commons library so it can be reused from the 
> different projects.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[GitHub] sling pull request #203: SLING-6592 switch to stream-based API for ContentPa...

[stefanseifert]

GitHub user stefanseifert opened a pull request:

https://github.com/apache/sling/pull/203

SLING-6592 switch to stream-based API for ContentParser



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/stefanseifert/sling 
feature/SLING-6592-contentparser-stream-api

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/sling/pull/203.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #203


commit 54159e8cba118cfa9df109e4e7fea6ce6ce1a55e
Author: sseifert 
Date:   2017-03-16T15:28:18Z

SLING-6592 switch to stream-based API for ContentParser




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (SLING-6652) Allow multiple adapters for Models with resourceType binding

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-6652:
-

You mean registering jackson exporter again with a different name? Well from my 
expectation the exporter name somehow defines the output format: jackson => 
json, fancyxml => xml, but not the data it actually exports. I discussed this 
offline with [~kwindszus] and will propose a way we think it makes sense.

> Allow multiple adapters for Models with resourceType binding
> 
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> According to 
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
>  the AdapterImplementations support only mapping resourceType to Adapter 1:1. 
> I would like to propose extending that to support 1:n binding between 
> resourceType and adapter classes.
> My use case: 
> Lets assume I want to combine my models with the exporter framework to export 
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but 
> annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6652) Allow multiple adapters for Models with resourceType binding

[Justin Edelson (JIRA)]

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

Justin Edelson commented on SLING-6652:
---

The way I had anticipated this being handled was by two different exporters. Is 
that not possible in your case?

> Allow multiple adapters for Models with resourceType binding
> 
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> According to 
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
>  the AdapterImplementations support only mapping resourceType to Adapter 1:1. 
> I would like to propose extending that to support 1:n binding between 
> resourceType and adapter classes.
> My use case: 
> Lets assume I want to combine my models with the exporter framework to export 
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but 
> annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6652) Allow multiple adapters for Models with resourceType binding

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6652:
---
Affects Version/s: Sling Models Impl 1.3.0

> Allow multiple adapters for Models with resourceType binding
> 
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Sling Models Impl 1.3.0
>Reporter: Dirk Rudolph
>
> According to 
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
>  the AdapterImplementations support only mapping resourceType to Adapter 1:1. 
> I would like to propose extending that to support 1:n binding between 
> resourceType and adapter classes.
> My use case: 
> Lets assume I want to combine my models with the exporter framework to export 
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but 
> annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Time for a Sling Validation 1.0.0 release

[Konrad Windszus]

I am blocked for the release by the 0.0.3-SNAPSHOT testing dependency to 
org.apache.sling.testing.paxexam in validation.core.
Is this gonna be released soon? Otherwise would it be possible to revert to 
0.0.2?
Konrad

> On 1 Mar 2017, at 09:03, Konrad Windszus  wrote:
> 
> Hi everyone,
> I think it is time now for a first release of Sling Validation. I used it in 
> several projects already productively and fixed a lot of bugs and refactored 
> the interfaces from the initial proposal from Radu quite a bit (44 issues 
> have been resolved since then, 
> https://issues.apache.org/jira/browse/SLING/fixforversion/12328980).
> It would be good if everyone who could afford some time could quickly 
> cross-check the API at 
> https://github.com/apache/sling/tree/trunk/bundles/extensions/validation/api.
> All concerns being raised in a previous review 
> (https://issues.apache.org/jira/browse/SLING-4027) have been addressed 
> meanwhile.
> 
> Thanks,
> Konrad
> 

[jira] [Commented] (SLING-6653) Make slingLaunchpadOak() private

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-6653:
-

_when convenience is wanted_: it's "ok" to let Lucene write to project's base 
dir, but you have to remove {{sling}} yourself (e.g. with Maven Clean Plugin) 
or configure an exclude for Rat.

> Make slingLaunchpadOak() private
> 
>
> Key: SLING-6653
> URL: https://issues.apache.org/jira/browse/SLING-6653
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing PaxExam 0.0.2
>Reporter: Konrad Windszus
>
> The method {{slingLaunchpadOak()}} should never be used directly instead 
> there should always be a concrete backend being set up (i.e. 
> {{slingLaunchpadOakTar(...)}} or {{slingLaunchpadOakMongo(...)}} should be 
> used). I would propose to make this method private and to always require the 
> path to the working directory as argument. Then the 
> {{LuceneIndexProviderService}} could be configured correctly i.e. as absolute 
> path in slingLaunchpadOak(...) instead of doing it twice (once incorrect with 
> a relative path in {{slingLaunchpadOak(...)}} and once correct with the 
> absolute path in either {{slingLaunchpadOakMongo(...)}} and 
> {{slingLaunchpadOakTar()}}).
> See also the related discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg65593.html.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: Replace and deprecate commons.json

[Karl Pauls]

Ok, it sounds like 1) we are fine with deprecating all classes in the
commons.json bundle and do one more release (I'll increase the minor
number of the package version as well) and 2) replace exiting usage
inside sling with Johnzon. I'll start with the deprecation release
asap and then start to provide patches for the replacement.

regards,

Karl

On Tue, Mar 14, 2017 at 5:20 PM, Carsten Ziegeler  wrote:
> Stefan Seifert wrote
>>
>>> 1) Is the above the way to go (and assuming it is)
>>
>> on the long run this would be the best solution. there was some idea about 
>> keeping the sling commons.json code and solve the license problem by 
>> replacing the implementation. there were some hints about a 
>> "cleanroom-implementation" from android with the same API, but following my 
>> research documented in SLING-6536 there is no 1:1 replacement available (at 
>> least i did not found it). another solution could be to replace the 
>> implementation of the commons.json code internally with a thirdparty json 
>> library. but this might get very hard when the philosophy of json API usage 
>> differs (this is the case e.g. between commons.json and johnzon) and is 
>> perhaps more effort than replacing the usage with another thirdparty library.
>
> I guess replacing the current implementation with something else is a
> lot of work as we might have some subtle deviations from the original
> code. In addition it would be good to get rid of our own json library
> and use something everyone else is using.
>
> So +1 for just deprecating the whole api, releasing it then and
> basically ending the life of that module.
>
>>
>>
>>> 2) What should I try to replace it with (there is a lot of json
>>> libraries out there: somebody suggested johnzon.apache.org but I'm
>>> certainly willing to look into others).
>>
>> from the proposed libraries i like apache johnzon most. it's very compact 
>> and not so "bloated" as gson and Jackson, although of course much younger 
>> and perhaps less mature. there is an outstanding issue using it in OSGi 
>> container documented in GERONIMO-6560, JOHNZON-108 (i've provide PRs). and a 
>> barebone implementation like in felix util [1] is just not enough because 
>> JSON comments and object ordering are not supported (which is correct 
>> following the JSON spec, but sling relies on it on several places). another 
>> plus of johnzon is usage of the standardized javax.json API.
>>
>> to get a feeling how a migration from commons.json to johnzon "feels like" 
>> i've migrated the maven-sling-plugin to it (SLING-6619). this was an 
>> unproblematic use case because the plugin does not run in OSGi and has not 
>> effect on the Launchpad etc. converting JSON reading code is not really 
>> hard, although there are of course subtle differences. converting writing 
>> code is more complex because johnzon follows a builder pattern with 
>> immutable JSON objects, whereas commons.json JSON objects are always 
>> mutable. thus bigger refactorings might be required which is difficult if 
>> the module has insufficient unit test coverage.
>>
>> i also used johnzon in the new (not yet released) fsresource 1.x and 2.x 
>> modules. because this bundles is often manually deployed in a running 
>> instance i embedded johnzon here directly, at least until a commons.json 
>> replacement has settled.
>>
>
> Yeah I think johnzon is a good alternative
>
>
>  Regards
>
> Carsten
>
> --
> Carsten Ziegeler
> Adobe Research Switzerland
> cziege...@apache.org



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

[jira] [Commented] (SLING-6653) Make slingLaunchpadOak() private

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-6653:
-

The working directory is not mandatory for any {{Option}} but 
{{slingLaunchpadOakTar(String, int)}} which should be used when convenience is 
wanted. Have a look at other modules which do not use Testing PaxExam – they do 
create directories ({{jackrabbit}}, {{sling}}?) outside of target (which I 
don't like) but clean up after or have an exclude configured for Rat. With 
moving {{oak-lucene}} and it's configuration away from {{sling-launchpad-oak}} 
the old behavior from {{0.0.2}} creating directories under {{target}} only is 
restored.

> Make slingLaunchpadOak() private
> 
>
> Key: SLING-6653
> URL: https://issues.apache.org/jira/browse/SLING-6653
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing PaxExam 0.0.2
>Reporter: Konrad Windszus
>
> The method {{slingLaunchpadOak()}} should never be used directly instead 
> there should always be a concrete backend being set up (i.e. 
> {{slingLaunchpadOakTar(...)}} or {{slingLaunchpadOakMongo(...)}} should be 
> used). I would propose to make this method private and to always require the 
> path to the working directory as argument. Then the 
> {{LuceneIndexProviderService}} could be configured correctly i.e. as absolute 
> path in slingLaunchpadOak(...) instead of doing it twice (once incorrect with 
> a relative path in {{slingLaunchpadOak(...)}} and once correct with the 
> absolute path in either {{slingLaunchpadOakMongo(...)}} and 
> {{slingLaunchpadOakTar()}}).
> See also the related discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg65593.html.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: PaxExam based ITs create folders outside target

[Konrad Windszus]

Some javadocs in 
https://github.com/apache/sling/blob/trunk/testing/org.apache.sling.testing.paxexam/src/main/java/org/apache/sling/testing/paxexam/SlingOptions.java#L862
 would be really helpful, which explain under which circumstances you have to 
use the methods with the workingDirectory and when you are allowed to use the 
methods without.
IIUC paxexam is purely for testing, therefore you should always use absolute 
paths (because you cannot rely on repository.home being set correctly).
Konrad

> On 16 Mar 2017, at 14:11, Oliver Lietz  wrote:
> 
> On Thursday 16 March 2017 13:54:23 Konrad Windszus wrote:
>> Probably this commit
>> https://github.com/apache/sling/blame/trunk/testing/org.apache.sling.testin
>> g.paxexam/src/main/java/org/apache/sling/testing/paxexam/SlingOptions.java#L
>> 645 is not correct. The localIndexDir should be IMHO set as absolute path
>> (not relative!) This is done correctly in
>> https://github.com/apache/sling/blame/trunk/testing/org.apache.sling.testin
>> g.paxexam/src/main/java/org/apache/sling/testing/paxexam/SlingOptions.java#L
>> 879. I am also not getting why the configuration is set two times.
>> IMHO this should be set only once in the slingLaunchpadOak() with an
>> absolute path!
> 
> No, relative paths are fine for Sling home in normal deployments but not in 
> testing (because directories are not created under target). Therefore 
> configuration moved to sling-launchpad-oak-tar (slingLaunchpadOakTar) and 
> sling-launchpad-oak-mongo (slingLaunchpadOakMongo). You usually don't use 
> those options but slingLaunchpadOakTar(String, int) with configured working 
> directory and HTTP port.
> 
> Regards,
> O.
> 
>>> On 16 Mar 2017, at 13:45, Konrad Windszus  wrote:
>>> 
>>> Maybe this is related to
>>> https://issues.apache.org/jira/browse/SLING-4649?focusedCommentId=1450885
>>> 7=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#co
>>> mment-14508857. It seems that the Lucene index relies on a framework
>>> property (named repository.home) if this is not explicitly configured.
>>> Seems that Karaf does not support setting that, therefore the Lucene
>>> index is created in the wrong directory (and sometime not correctly
>>> removed). I am still failing to reproduce locally though
>>> Konrad
>>> 
 On 16 Mar 2017, at 13:31, Konrad Windszus  wrote:
 
 Hi,
 it seems that PaxExam based ITs may create folders outside the target
 folder (see
 https://builds.apache.org/job/sling-bundles-extensions-validation-core-1
 .8/ws/) For Validation the folder
 sling/repository/index/lucene-1488547426482/data was obviously created
 by PaxExam.
 
 Usually the repository lives below
 https://builds.apache.org/job/sling-bundles-extensions-validation-core-1
 .8/ws/target/paxexam/ValidationServiceIT/sling/repository/
 
 I also sometimes have seen this locally but I fail to reproduce it
 reliably. Does anyone have an idea, why the lucene index is there?
 Seems that PaxExam relies on relative paths somehow, which are sometimes
 relative to target and sometimes to the project root.
 
 Thanks for any help
 Konrad
 
> On 16 Mar 2017, at 12:11, Apache Jenkins Server
>  wrote:
> 
> See
>  -1.8/55/display/redirect?page=changes>
> 
> Changes:
> 
> [kwin] fix some more warnings
> 
> --
> Started by an SCM change
> Started by upstream project
> "sling-bundles-extensions-validation-test-services-1.8" build number 28
> originally caused by:
> Started by upstream project
> "sling-bundles-extensions-validation-api-1.8" build number 25
> originally caused by:
> Started by an SCM change
> [EnvInject] - Loading node environment variables.
> Building remotely on H23 (ubuntu) in workspace
>  -1.8/ws/> Updating
> https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/validat
> ion/core at revision '2017-03-16T11:10:09.674 +' U
> src/test/java/org/apache/sling/validation/impl/model/MergedValidationMo
> delTest.java U
> src/test/java/org/apache/sling/validation/impl/resourcemodel/ResourceVa
> lidationModelProviderImplTest.java U
> src/test/java/org/apache/sling/validation/impl/ValidationServiceImplTes
> t.java U
> src/main/java/org/apache/sling/validation/impl/ValidationServiceImpl.ja
> va At revision 1787158
> 
> Parsing POMs
> Established TCP socket on 34822
> maven33-agent.jar already up to date
> maven33-interceptor.jar already up to date
> maven3-interceptor-commons.jar already up to date
> [sling-bundles-extensions-validation-core-1.8] $

[jira] [Commented] (SLING-6653) Make slingLaunchpadOak() private

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6653:


Ok, but then we should at least make the parameter working directory mandatory 
for that method.

> Make slingLaunchpadOak() private
> 
>
> Key: SLING-6653
> URL: https://issues.apache.org/jira/browse/SLING-6653
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing PaxExam 0.0.2
>Reporter: Konrad Windszus
>
> The method {{slingLaunchpadOak()}} should never be used directly instead 
> there should always be a concrete backend being set up (i.e. 
> {{slingLaunchpadOakTar(...)}} or {{slingLaunchpadOakMongo(...)}} should be 
> used). I would propose to make this method private and to always require the 
> path to the working directory as argument. Then the 
> {{LuceneIndexProviderService}} could be configured correctly i.e. as absolute 
> path in slingLaunchpadOak(...) instead of doing it twice (once incorrect with 
> a relative path in {{slingLaunchpadOak(...)}} and once correct with the 
> absolute path in either {{slingLaunchpadOakMongo(...)}} and 
> {{slingLaunchpadOakTar()}}).
> See also the related discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg65593.html.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: PaxExam based ITs create folders outside target

[Oliver Lietz]

On Thursday 16 March 2017 13:45:44 Konrad Windszus wrote:
> Maybe this is related to
> https://issues.apache.org/jira/browse/SLING-4649?focusedCommentId=14508857;
> page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#commen
> t-14508857. It seems that the Lucene index relies on a framework property
> (named repository.home) if this is not explicitly configured. Seems that
> Karaf does not support setting that, therefore the Lucene index is created
> in the wrong directory (and sometime not correctly removed).

Karaf supports framework settings, but framework settings are just not 
convenient for users getting started with Sling's features.

> I am still
> failing to reproduce locally though

It's fixed.

Regards,
O.

> Konrad
> 
> > On 16 Mar 2017, at 13:31, Konrad Windszus  wrote:
> > 
> > Hi,
> > it seems that PaxExam based ITs may create folders outside the target
> > folder (see
> > https://builds.apache.org/job/sling-bundles-extensions-validation-core-1.
> > 8/ws/) For Validation the folder
> > sling/repository/index/lucene-1488547426482/data was obviously created by
> > PaxExam.
> > 
> > Usually the repository lives below
> > https://builds.apache.org/job/sling-bundles-extensions-validation-core-1.
> > 8/ws/target/paxexam/ValidationServiceIT/sling/repository/
> > 
> > I also sometimes have seen this locally but I fail to reproduce it
> > reliably. Does anyone have an idea, why the lucene index is there?
> > Seems that PaxExam relies on relative paths somehow, which are sometimes
> > relative to target and sometimes to the project root.
> > 
> > Thanks for any help
> > Konrad
> > 
> >> On 16 Mar 2017, at 12:11, Apache Jenkins Server
> >>  wrote:
> >> 
> >> See
> >>  
> >> >> 1.8/55/display/redirect?page=changes>
> >> 
> >> Changes:
> >> 
> >> [kwin] fix some more warnings
> >> 
> >> --
> >> Started by an SCM change
> >> Started by upstream project
> >> "sling-bundles-extensions-validation-test-services-1.8" build number 28
> >> originally caused by:
> >> Started by upstream project "sling-bundles-extensions-validation-api-1.8"
> >> build number 25 originally caused by:
> >> Started by an SCM change
> >> [EnvInject] - Loading node environment variables.
> >> Building remotely on H23 (ubuntu) in workspace
> >>  
> >> >> 1.8/ws/> Updating
> >> https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/validati
> >> on/core at revision '2017-03-16T11:10:09.674 +' U
> >> src/test/java/org/apache/sling/validation/impl/model/MergedValidationMod
> >> elTest.java U
> >> src/test/java/org/apache/sling/validation/impl/resourcemodel/ResourceVal
> >> idationModelProviderImplTest.java U
> >> src/test/java/org/apache/sling/validation/impl/ValidationServiceImplTest
> >> .java U
> >> src/main/java/org/apache/sling/validation/impl/ValidationServiceImpl.jav
> >> a At revision 1787158
> >> 
> >> Parsing POMs
> >> Established TCP socket on 34822
> >> maven33-agent.jar already up to date
> >> maven33-interceptor.jar already up to date
> >> maven3-interceptor-commons.jar already up to date
> >> [sling-bundles-extensions-validation-core-1.8] $
> >> /home/jenkins/tools/java/latest1.8/bin/java -Xmx2g -Xms256m -cp
> >> /home/jenkins/jenkins-slave/maven33-agent.jar:/home/jenkins/tools/maven/
> >> apache-maven-3.3.9/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/
> >> maven/apache-maven-3.3.9/conf/logging jenkins.maven3.agent.Maven33Main
> >> /home/jenkins/tools/maven/apache-maven-3.3.9
> >> /home/jenkins/jenkins-slave/slave.jar
> >> /home/jenkins/jenkins-slave/maven33-interceptor.jar
> >> /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 34822
> >> <===[JENKINS REMOTING CAPACITY]===>   channel started
> >> Executing Maven:  -B -f
> >>  
> >> >> 1.8/ws/pom.xml>
> >> -Dmaven.repo.local=/home/jenkins/jenkins-slave/maven-repositories/0 -U
> >> clean deploy [INFO] Scanning for projects...
> >> [INFO]
> >> [INFO]
> >> 
> >> [INFO] Building Apache Sling Validation Framework Core Implementation
> >> 1.0.0-SNAPSHOT [INFO]
> >> 
> >> [INFO] Downloading:
> >> http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling
> >> .validation.api/1.0.0-SNAPSHOT/maven-metadata.xml [INFO] Downloaded:
> >> http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling
> >> .validation.api/1.0.0-SNAPSHOT/maven-metadata.xml (1023 B at 2.2 KB/sec)
> >> [INFO] Downloading:
> >> http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling
> >> 

[jira] [Commented] (SLING-6653) Make slingLaunchpadOak() private

[Oliver Lietz (JIRA)]

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

Oliver Lietz commented on SLING-6653:
-

{{slingLaunchpadOak()}} needs to be public in case you want to use a different 
Tar, Mongo or new RDBMS storage and don't want to start from scratch 
configuring Sling.

> Make slingLaunchpadOak() private
> 
>
> Key: SLING-6653
> URL: https://issues.apache.org/jira/browse/SLING-6653
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing PaxExam 0.0.2
>Reporter: Konrad Windszus
>
> The method {{slingLaunchpadOak()}} should never be used directly instead 
> there should always be a concrete backend being set up (i.e. 
> {{slingLaunchpadOakTar(...)}} or {{slingLaunchpadOakMongo(...)}} should be 
> used). I would propose to make this method private and to always require the 
> path to the working directory as argument. Then the 
> {{LuceneIndexProviderService}} could be configured correctly i.e. as absolute 
> path in slingLaunchpadOak(...) instead of doing it twice (once incorrect with 
> a relative path in {{slingLaunchpadOak(...)}} and once correct with the 
> absolute path in either {{slingLaunchpadOakMongo(...)}} and 
> {{slingLaunchpadOakTar()}}).
> See also the related discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg65593.html.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: PaxExam based ITs create folders outside target

[Oliver Lietz]

On Thursday 16 March 2017 13:54:23 Konrad Windszus wrote:
> Probably this commit
> https://github.com/apache/sling/blame/trunk/testing/org.apache.sling.testin
> g.paxexam/src/main/java/org/apache/sling/testing/paxexam/SlingOptions.java#L
> 645 is not correct. The localIndexDir should be IMHO set as absolute path
> (not relative!) This is done correctly in
> https://github.com/apache/sling/blame/trunk/testing/org.apache.sling.testin
> g.paxexam/src/main/java/org/apache/sling/testing/paxexam/SlingOptions.java#L
> 879. I am also not getting why the configuration is set two times.
> IMHO this should be set only once in the slingLaunchpadOak() with an
> absolute path!

No, relative paths are fine for Sling home in normal deployments but not in 
testing (because directories are not created under target). Therefore 
configuration moved to sling-launchpad-oak-tar (slingLaunchpadOakTar) and 
sling-launchpad-oak-mongo (slingLaunchpadOakMongo). You usually don't use 
those options but slingLaunchpadOakTar(String, int) with configured working 
directory and HTTP port.

Regards,
O.

> > On 16 Mar 2017, at 13:45, Konrad Windszus  wrote:
> > 
> > Maybe this is related to
> > https://issues.apache.org/jira/browse/SLING-4649?focusedCommentId=1450885
> > 7=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#co
> > mment-14508857. It seems that the Lucene index relies on a framework
> > property (named repository.home) if this is not explicitly configured.
> > Seems that Karaf does not support setting that, therefore the Lucene
> > index is created in the wrong directory (and sometime not correctly
> > removed). I am still failing to reproduce locally though
> > Konrad
> > 
> >> On 16 Mar 2017, at 13:31, Konrad Windszus  wrote:
> >> 
> >> Hi,
> >> it seems that PaxExam based ITs may create folders outside the target
> >> folder (see
> >> https://builds.apache.org/job/sling-bundles-extensions-validation-core-1
> >> .8/ws/) For Validation the folder
> >> sling/repository/index/lucene-1488547426482/data was obviously created
> >> by PaxExam.
> >> 
> >> Usually the repository lives below
> >> https://builds.apache.org/job/sling-bundles-extensions-validation-core-1
> >> .8/ws/target/paxexam/ValidationServiceIT/sling/repository/
> >> 
> >> I also sometimes have seen this locally but I fail to reproduce it
> >> reliably. Does anyone have an idea, why the lucene index is there?
> >> Seems that PaxExam relies on relative paths somehow, which are sometimes
> >> relative to target and sometimes to the project root.
> >> 
> >> Thanks for any help
> >> Konrad
> >> 
> >>> On 16 Mar 2017, at 12:11, Apache Jenkins Server
> >>>  wrote:
> >>> 
> >>> See
> >>>  >>> -1.8/55/display/redirect?page=changes>
> >>> 
> >>> Changes:
> >>> 
> >>> [kwin] fix some more warnings
> >>> 
> >>> --
> >>> Started by an SCM change
> >>> Started by upstream project
> >>> "sling-bundles-extensions-validation-test-services-1.8" build number 28
> >>> originally caused by:
> >>> Started by upstream project
> >>> "sling-bundles-extensions-validation-api-1.8" build number 25
> >>> originally caused by:
> >>> Started by an SCM change
> >>> [EnvInject] - Loading node environment variables.
> >>> Building remotely on H23 (ubuntu) in workspace
> >>>  >>> -1.8/ws/> Updating
> >>> https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/validat
> >>> ion/core at revision '2017-03-16T11:10:09.674 +' U
> >>> src/test/java/org/apache/sling/validation/impl/model/MergedValidationMo
> >>> delTest.java U
> >>> src/test/java/org/apache/sling/validation/impl/resourcemodel/ResourceVa
> >>> lidationModelProviderImplTest.java U
> >>> src/test/java/org/apache/sling/validation/impl/ValidationServiceImplTes
> >>> t.java U
> >>> src/main/java/org/apache/sling/validation/impl/ValidationServiceImpl.ja
> >>> va At revision 1787158
> >>> 
> >>> Parsing POMs
> >>> Established TCP socket on 34822
> >>> maven33-agent.jar already up to date
> >>> maven33-interceptor.jar already up to date
> >>> maven3-interceptor-commons.jar already up to date
> >>> [sling-bundles-extensions-validation-core-1.8] $
> >>> /home/jenkins/tools/java/latest1.8/bin/java -Xmx2g -Xms256m -cp
> >>> /home/jenkins/jenkins-slave/maven33-agent.jar:/home/jenkins/tools/maven
> >>> /apache-maven-3.3.9/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tool
> >>> s/maven/apache-maven-3.3.9/conf/logging jenkins.maven3.agent.Maven33Main
> >>> /home/jenkins/tools/maven/apache-maven-3.3.9
> >>> /home/jenkins/jenkins-slave/slave.jar
> >>> /home/jenkins/jenkins-slave/maven33-interceptor.jar
> >>> /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 34822
> >>> <===[JENKINS REMOTING CAPACITY]===>   channel started
> >>> Executing Maven:  

[jira] [Updated] (SLING-6653) Make slingLaunchpadOak() private

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6653:
---
Description: 
The method {{slingLaunchpadOak()}} should never be used directly instead there 
should always be a concrete backend being set up (i.e. 
{{slingLaunchpadOakTar(...)}} or {{slingLaunchpadOakMongo(...)}} should be 
used). I would propose to make this method private and to always require the 
path to the working directory as argument. Then the 
{{LuceneIndexProviderService}} could be configured correctly i.e. as absolute 
path in slingLaunchpadOak(...) instead of doing it twice (once incorrect with a 
relative path in {{slingLaunchpadOak(...)}} and once correct with the absolute 
path in either {{slingLaunchpadOakMongo(...)}} and {{slingLaunchpadOakTar()}}).

See also the related discussion at 
http://www.mail-archive.com/dev@sling.apache.org/msg65593.html.

  was:The method {{slingLaunchpadOak()}} should never be used directly instead 
there should always be a concrete backend being set up (i.e. 
{{slingLaunchpadOakTar(...)}} or {{slingLaunchpadOakMongo(...)}} should be 
used). I would propose to make this method private and to always require the 
path to the working directory as argument. Then the 
{{LuceneIndexProviderService}} could be configured correctly i.e. as absolute 
path in slingLaunchpadOak(...) instead of doing it twice (once incorrect with a 
relative path in {{slingLaunchpadOak(...)}} and once correct with the absolute 
path in either {{slingLaunchpadOakMongo(...)}} and {{slingLaunchpadOakTar()}})


> Make slingLaunchpadOak() private
> 
>
> Key: SLING-6653
> URL: https://issues.apache.org/jira/browse/SLING-6653
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing PaxExam 0.0.2
>Reporter: Konrad Windszus
>
> The method {{slingLaunchpadOak()}} should never be used directly instead 
> there should always be a concrete backend being set up (i.e. 
> {{slingLaunchpadOakTar(...)}} or {{slingLaunchpadOakMongo(...)}} should be 
> used). I would propose to make this method private and to always require the 
> path to the working directory as argument. Then the 
> {{LuceneIndexProviderService}} could be configured correctly i.e. as absolute 
> path in slingLaunchpadOak(...) instead of doing it twice (once incorrect with 
> a relative path in {{slingLaunchpadOak(...)}} and once correct with the 
> absolute path in either {{slingLaunchpadOakMongo(...)}} and 
> {{slingLaunchpadOakTar()}}).
> See also the related discussion at 
> http://www.mail-archive.com/dev@sling.apache.org/msg65593.html.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6653) Make slingLaunchpadOak() private

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6653:


[~olli] WDYT?

> Make slingLaunchpadOak() private
> 
>
> Key: SLING-6653
> URL: https://issues.apache.org/jira/browse/SLING-6653
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing PaxExam 0.0.2
>Reporter: Konrad Windszus
>
> The method {{slingLaunchpadOak()}} should never be used directly instead 
> there should always be a concrete backend being set up (i.e. 
> {{slingLaunchpadOakTar(...)}} or {{slingLaunchpadOakMongo(...)}} should be 
> used). I would propose to make this method private and to always require the 
> path to the working directory as argument. Then the 
> {{LuceneIndexProviderService}} could be configured correctly i.e. as absolute 
> path in slingLaunchpadOak(...) instead of doing it twice (once incorrect with 
> a relative path in {{slingLaunchpadOak(...)}} and once correct with the 
> absolute path in either {{slingLaunchpadOakMongo(...)}} and 
> {{slingLaunchpadOakTar()}})



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6653) Make slingLaunchpadOak() private

[Konrad Windszus (JIRA)]

Konrad Windszus created SLING-6653:
--

 Summary: Make slingLaunchpadOak() private
 Key: SLING-6653
 URL: https://issues.apache.org/jira/browse/SLING-6653
 Project: Sling
  Issue Type: Improvement
  Components: Testing
Affects Versions: Testing PaxExam 0.0.2
Reporter: Konrad Windszus


The method {{slingLaunchpadOak()}} should never be used directly instead there 
should always be a concrete backend being set up (i.e. 
{{slingLaunchpadOakTar(...)}} or {{slingLaunchpadOakMongo(...)}} should be 
used). I would propose to make this method private and to always require the 
path to the working directory as argument. Then the 
{{LuceneIndexProviderService}} could be configured correctly i.e. as absolute 
path in slingLaunchpadOak(...) instead of doing it twice (once incorrect with a 
relative path in {{slingLaunchpadOak(...)}} and once correct with the absolute 
path in either {{slingLaunchpadOakMongo(...)}} and {{slingLaunchpadOakTar()}})



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Re: PaxExam based ITs create folders outside target

[Oliver Lietz]

On Thursday 16 March 2017 13:31:15 Konrad Windszus wrote:
> Hi,

Hi Konrad,

> it seems that PaxExam based ITs may create folders outside the target folder
> (see
> https://builds.apache.org/job/sling-bundles-extensions-validation-core-1.8/
> ws/) For Validation the folder
> sling/repository/index/lucene-1488547426482/data was obviously created by
> PaxExam.
> 
> Usually the repository lives below
> https://builds.apache.org/job/sling-bundles-extensions-validation-core-1.8/
> ws/target/paxexam/ValidationServiceIT/sling/repository/
> 
> I also sometimes have seen this locally but I fail to reproduce it reliably.
> Does anyone have an idea, why the lucene index is there?

that happend when configuration changed for LuceneIndexProviderService during 
container start and should be fixed in r1786426.

> Seems that PaxExam relies on relative paths somehow, which are sometimes
> relative to target and sometimes to the project root.

No, in the above case configuration from Option slingLaunchpadOak was present 
first and configuration with workingDirectory kicked in later.

Regards,
O.

> Thanks for any help
> Konrad
> 
> > On 16 Mar 2017, at 12:11, Apache Jenkins Server
> >  wrote:
> > 
> > See
> >  > .8/55/display/redirect?page=changes>
> > 
> > Changes:
> > 
> > [kwin] fix some more warnings
> > 
> > --
> > Started by an SCM change
> > Started by upstream project
> > "sling-bundles-extensions-validation-test-services-1.8" build number 28
> > originally caused by:
> > Started by upstream project "sling-bundles-extensions-validation-api-1.8"
> > build number 25> 
> > originally caused by:
> >  Started by an SCM change
> > 
> > [EnvInject] - Loading node environment variables.
> > Building remotely on H23 (ubuntu) in workspace
> >  > .8/ws/> Updating
> > https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/validatio
> > n/core at revision '2017-03-16T11:10:09.674 +' U
> > src/test/java/org/apache/sling/validation/impl/model/MergedValidationMode
> > lTest.java U
> > src/test/java/org/apache/sling/validation/impl/resourcemodel/ResourceVali
> > dationModelProviderImplTest.java U
> > src/test/java/org/apache/sling/validation/impl/ValidationServiceImplTest.
> > java U
> > src/main/java/org/apache/sling/validation/impl/ValidationServiceImpl.java
> > At revision 1787158
> > 
> > Parsing POMs
> > Established TCP socket on 34822
> > maven33-agent.jar already up to date
> > maven33-interceptor.jar already up to date
> > maven3-interceptor-commons.jar already up to date
> > [sling-bundles-extensions-validation-core-1.8] $
> > /home/jenkins/tools/java/latest1.8/bin/java -Xmx2g -Xms256m -cp
> > /home/jenkins/jenkins-slave/maven33-agent.jar:/home/jenkins/tools/maven/a
> > pache-maven-3.3.9/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/ma
> > ven/apache-maven-3.3.9/conf/logging jenkins.maven3.agent.Maven33Main
> > /home/jenkins/tools/maven/apache-maven-3.3.9
> > /home/jenkins/jenkins-slave/slave.jar
> > /home/jenkins/jenkins-slave/maven33-interceptor.jar
> > /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 34822
> > <===[JENKINS REMOTING CAPACITY]===>   channel started
> > Executing Maven:  -B -f
> >  > .8/ws/pom.xml>
> > -Dmaven.repo.local=/home/jenkins/jenkins-slave/maven-repositories/0 -U
> > clean deploy [INFO] Scanning for projects...
> > [INFO]
> > [INFO]
> > 
> > [INFO] Building Apache Sling Validation Framework Core Implementation
> > 1.0.0-SNAPSHOT [INFO]
> > 
> > [INFO] Downloading:
> > http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.
> > validation.api/1.0.0-SNAPSHOT/maven-metadata.xml [INFO] Downloaded:
> > http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.
> > validation.api/1.0.0-SNAPSHOT/maven-metadata.xml (1023 B at 2.2 KB/sec)
> > [INFO] Downloading:
> > http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.
> > validation.api/1.0.0-SNAPSHOT/org.apache.sling.validation.api-1.0.0-201703
> > 16.110912-1580.pom [INFO] Downloaded:
> > http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.
> > validation.api/1.0.0-SNAPSHOT/org.apache.sling.validation.api-1.0.0-201703
> > 16.110912-1580.pom (3 KB at 7.5 KB/sec) [INFO] Downloading:
> > http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.
> > validation.test-services/1.0.0-SNAPSHOT/maven-metadata.xml [INFO]
> > Downloaded:
> > http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.
> > validation.test-services/1.0.0-SNAPSHOT/maven-metadata.xml (2 KB at 

Re: PaxExam based ITs create folders outside target

[Konrad Windszus]

Probably this commit 
https://github.com/apache/sling/blame/trunk/testing/org.apache.sling.testing.paxexam/src/main/java/org/apache/sling/testing/paxexam/SlingOptions.java#L645
is not correct. The localIndexDir should be IMHO set as absolute path (not 
relative!) This is done correctly in 
https://github.com/apache/sling/blame/trunk/testing/org.apache.sling.testing.paxexam/src/main/java/org/apache/sling/testing/paxexam/SlingOptions.java#L879.
I am also not getting why the configuration is set two times.
IMHO this should be set only once in the slingLaunchpadOak() with an absolute 
path!

> On 16 Mar 2017, at 13:45, Konrad Windszus  wrote:
> 
> Maybe this is related to 
> https://issues.apache.org/jira/browse/SLING-4649?focusedCommentId=14508857=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14508857.
> It seems that the Lucene index relies on a framework property (named 
> repository.home) if this is not explicitly configured.
> Seems that Karaf does not support setting that, therefore the Lucene index is 
> created in the wrong directory (and sometime not correctly removed).
> I am still failing to reproduce locally though
> Konrad
> 
> 
>> On 16 Mar 2017, at 13:31, Konrad Windszus  wrote:
>> 
>> Hi,
>> it seems that PaxExam based ITs may create folders outside the target folder 
>> (see 
>> https://builds.apache.org/job/sling-bundles-extensions-validation-core-1.8/ws/)
>> For Validation the folder sling/repository/index/lucene-1488547426482/data 
>> was obviously created by PaxExam.
>> 
>> Usually the repository lives below 
>> https://builds.apache.org/job/sling-bundles-extensions-validation-core-1.8/ws/target/paxexam/ValidationServiceIT/sling/repository/
>> 
>> I also sometimes have seen this locally but I fail to reproduce it reliably.
>> Does anyone have an idea, why the lucene index is there?
>> Seems that PaxExam relies on relative paths somehow, which are sometimes 
>> relative to target and sometimes to the project root.
>> 
>> Thanks for any help
>> Konrad
>> 
>>> On 16 Mar 2017, at 12:11, Apache Jenkins Server  
>>> wrote:
>>> 
>>> See 
>>> 
>>> 
>>> Changes:
>>> 
>>> [kwin] fix some more warnings
>>> 
>>> --
>>> Started by an SCM change
>>> Started by upstream project 
>>> "sling-bundles-extensions-validation-test-services-1.8" build number 28
>>> originally caused by:
>>> Started by upstream project "sling-bundles-extensions-validation-api-1.8" 
>>> build number 25
>>> originally caused by:
>>> Started by an SCM change
>>> [EnvInject] - Loading node environment variables.
>>> Building remotely on H23 (ubuntu) in workspace 
>>> 
>>> Updating 
>>> https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/validation/core
>>>  at revision '2017-03-16T11:10:09.674 +'
>>> U 
>>> src/test/java/org/apache/sling/validation/impl/model/MergedValidationModelTest.java
>>> U 
>>> src/test/java/org/apache/sling/validation/impl/resourcemodel/ResourceValidationModelProviderImplTest.java
>>> U 
>>> src/test/java/org/apache/sling/validation/impl/ValidationServiceImplTest.java
>>> U 
>>> src/main/java/org/apache/sling/validation/impl/ValidationServiceImpl.java
>>> At revision 1787158
>>> 
>>> Parsing POMs
>>> Established TCP socket on 34822
>>> maven33-agent.jar already up to date
>>> maven33-interceptor.jar already up to date
>>> maven3-interceptor-commons.jar already up to date
>>> [sling-bundles-extensions-validation-core-1.8] $ 
>>> /home/jenkins/tools/java/latest1.8/bin/java -Xmx2g -Xms256m -cp 
>>> /home/jenkins/jenkins-slave/maven33-agent.jar:/home/jenkins/tools/maven/apache-maven-3.3.9/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/maven/apache-maven-3.3.9/conf/logging
>>>  jenkins.maven3.agent.Maven33Main 
>>> /home/jenkins/tools/maven/apache-maven-3.3.9 
>>> /home/jenkins/jenkins-slave/slave.jar 
>>> /home/jenkins/jenkins-slave/maven33-interceptor.jar 
>>> /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 34822
>>> <===[JENKINS REMOTING CAPACITY]===>   channel started
>>> Executing Maven:  -B -f 
>>> 
>>>  -Dmaven.repo.local=/home/jenkins/jenkins-slave/maven-repositories/0 -U 
>>> clean deploy
>>> [INFO] Scanning for projects...
>>> [INFO]  
>>>
>>> [INFO] 
>>> 
>>> [INFO] Building Apache Sling Validation Framework Core Implementation 
>>> 1.0.0-SNAPSHOT
>>> [INFO] 
>>> 
>>> [INFO] Downloading: 
>>> 

Re: PaxExam based ITs create folders outside target

[Konrad Windszus]

Maybe this is related to 
https://issues.apache.org/jira/browse/SLING-4649?focusedCommentId=14508857=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14508857.
It seems that the Lucene index relies on a framework property (named 
repository.home) if this is not explicitly configured.
Seems that Karaf does not support setting that, therefore the Lucene index is 
created in the wrong directory (and sometime not correctly removed).
I am still failing to reproduce locally though
Konrad


> On 16 Mar 2017, at 13:31, Konrad Windszus  wrote:
> 
> Hi,
> it seems that PaxExam based ITs may create folders outside the target folder 
> (see 
> https://builds.apache.org/job/sling-bundles-extensions-validation-core-1.8/ws/)
> For Validation the folder sling/repository/index/lucene-1488547426482/data 
> was obviously created by PaxExam.
> 
> Usually the repository lives below 
> https://builds.apache.org/job/sling-bundles-extensions-validation-core-1.8/ws/target/paxexam/ValidationServiceIT/sling/repository/
> 
> I also sometimes have seen this locally but I fail to reproduce it reliably.
> Does anyone have an idea, why the lucene index is there?
> Seems that PaxExam relies on relative paths somehow, which are sometimes 
> relative to target and sometimes to the project root.
> 
> Thanks for any help
> Konrad
> 
>> On 16 Mar 2017, at 12:11, Apache Jenkins Server  
>> wrote:
>> 
>> See 
>> 
>> 
>> Changes:
>> 
>> [kwin] fix some more warnings
>> 
>> --
>> Started by an SCM change
>> Started by upstream project 
>> "sling-bundles-extensions-validation-test-services-1.8" build number 28
>> originally caused by:
>> Started by upstream project "sling-bundles-extensions-validation-api-1.8" 
>> build number 25
>> originally caused by:
>> Started by an SCM change
>> [EnvInject] - Loading node environment variables.
>> Building remotely on H23 (ubuntu) in workspace 
>> 
>> Updating 
>> https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/validation/core
>>  at revision '2017-03-16T11:10:09.674 +'
>> U 
>> src/test/java/org/apache/sling/validation/impl/model/MergedValidationModelTest.java
>> U 
>> src/test/java/org/apache/sling/validation/impl/resourcemodel/ResourceValidationModelProviderImplTest.java
>> U 
>> src/test/java/org/apache/sling/validation/impl/ValidationServiceImplTest.java
>> U 
>> src/main/java/org/apache/sling/validation/impl/ValidationServiceImpl.java
>> At revision 1787158
>> 
>> Parsing POMs
>> Established TCP socket on 34822
>> maven33-agent.jar already up to date
>> maven33-interceptor.jar already up to date
>> maven3-interceptor-commons.jar already up to date
>> [sling-bundles-extensions-validation-core-1.8] $ 
>> /home/jenkins/tools/java/latest1.8/bin/java -Xmx2g -Xms256m -cp 
>> /home/jenkins/jenkins-slave/maven33-agent.jar:/home/jenkins/tools/maven/apache-maven-3.3.9/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/maven/apache-maven-3.3.9/conf/logging
>>  jenkins.maven3.agent.Maven33Main 
>> /home/jenkins/tools/maven/apache-maven-3.3.9 
>> /home/jenkins/jenkins-slave/slave.jar 
>> /home/jenkins/jenkins-slave/maven33-interceptor.jar 
>> /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 34822
>> <===[JENKINS REMOTING CAPACITY]===>   channel started
>> Executing Maven:  -B -f 
>> 
>>  -Dmaven.repo.local=/home/jenkins/jenkins-slave/maven-repositories/0 -U 
>> clean deploy
>> [INFO] Scanning for projects...
>> [INFO]   
>>   
>> [INFO] 
>> 
>> [INFO] Building Apache Sling Validation Framework Core Implementation 
>> 1.0.0-SNAPSHOT
>> [INFO] 
>> 
>> [INFO] Downloading: 
>> http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.validation.api/1.0.0-SNAPSHOT/maven-metadata.xml
>> [INFO] Downloaded: 
>> http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.validation.api/1.0.0-SNAPSHOT/maven-metadata.xml
>>  (1023 B at 2.2 KB/sec)
>> [INFO] Downloading: 
>> http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.validation.api/1.0.0-SNAPSHOT/org.apache.sling.validation.api-1.0.0-20170316.110912-1580.pom
>> [INFO] Downloaded: 
>> http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.validation.api/1.0.0-SNAPSHOT/org.apache.sling.validation.api-1.0.0-20170316.110912-1580.pom
>>  (3 KB at 7.5 KB/sec)
>> [INFO] Downloading: 
>> 

PaxExam based ITs create folders outside target

[Konrad Windszus]

Hi,
it seems that PaxExam based ITs may create folders outside the target folder 
(see 
https://builds.apache.org/job/sling-bundles-extensions-validation-core-1.8/ws/)
For Validation the folder sling/repository/index/lucene-1488547426482/data was 
obviously created by PaxExam.

Usually the repository lives below 
https://builds.apache.org/job/sling-bundles-extensions-validation-core-1.8/ws/target/paxexam/ValidationServiceIT/sling/repository/

I also sometimes have seen this locally but I fail to reproduce it reliably.
Does anyone have an idea, why the lucene index is there?
Seems that PaxExam relies on relative paths somehow, which are sometimes 
relative to target and sometimes to the project root.

Thanks for any help
Konrad

> On 16 Mar 2017, at 12:11, Apache Jenkins Server  
> wrote:
> 
> See 
> 
> 
> Changes:
> 
> [kwin] fix some more warnings
> 
> --
> Started by an SCM change
> Started by upstream project 
> "sling-bundles-extensions-validation-test-services-1.8" build number 28
> originally caused by:
> Started by upstream project "sling-bundles-extensions-validation-api-1.8" 
> build number 25
> originally caused by:
>  Started by an SCM change
> [EnvInject] - Loading node environment variables.
> Building remotely on H23 (ubuntu) in workspace 
> 
> Updating 
> https://svn.apache.org/repos/asf/sling/trunk/bundles/extensions/validation/core
>  at revision '2017-03-16T11:10:09.674 +'
> U 
> src/test/java/org/apache/sling/validation/impl/model/MergedValidationModelTest.java
> U 
> src/test/java/org/apache/sling/validation/impl/resourcemodel/ResourceValidationModelProviderImplTest.java
> U 
> src/test/java/org/apache/sling/validation/impl/ValidationServiceImplTest.java
> U 
> src/main/java/org/apache/sling/validation/impl/ValidationServiceImpl.java
> At revision 1787158
> 
> Parsing POMs
> Established TCP socket on 34822
> maven33-agent.jar already up to date
> maven33-interceptor.jar already up to date
> maven3-interceptor-commons.jar already up to date
> [sling-bundles-extensions-validation-core-1.8] $ 
> /home/jenkins/tools/java/latest1.8/bin/java -Xmx2g -Xms256m -cp 
> /home/jenkins/jenkins-slave/maven33-agent.jar:/home/jenkins/tools/maven/apache-maven-3.3.9/boot/plexus-classworlds-2.5.2.jar:/home/jenkins/tools/maven/apache-maven-3.3.9/conf/logging
>  jenkins.maven3.agent.Maven33Main 
> /home/jenkins/tools/maven/apache-maven-3.3.9 
> /home/jenkins/jenkins-slave/slave.jar 
> /home/jenkins/jenkins-slave/maven33-interceptor.jar 
> /home/jenkins/jenkins-slave/maven3-interceptor-commons.jar 34822
> <===[JENKINS REMOTING CAPACITY]===>   channel started
> Executing Maven:  -B -f 
> 
>  -Dmaven.repo.local=/home/jenkins/jenkins-slave/maven-repositories/0 -U clean 
> deploy
> [INFO] Scanning for projects...
> [INFO]
>  
> [INFO] 
> 
> [INFO] Building Apache Sling Validation Framework Core Implementation 
> 1.0.0-SNAPSHOT
> [INFO] 
> 
> [INFO] Downloading: 
> http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.validation.api/1.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Downloaded: 
> http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.validation.api/1.0.0-SNAPSHOT/maven-metadata.xml
>  (1023 B at 2.2 KB/sec)
> [INFO] Downloading: 
> http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.validation.api/1.0.0-SNAPSHOT/org.apache.sling.validation.api-1.0.0-20170316.110912-1580.pom
> [INFO] Downloaded: 
> http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.validation.api/1.0.0-SNAPSHOT/org.apache.sling.validation.api-1.0.0-20170316.110912-1580.pom
>  (3 KB at 7.5 KB/sec)
> [INFO] Downloading: 
> http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.validation.test-services/1.0.0-SNAPSHOT/maven-metadata.xml
> [INFO] Downloaded: 
> http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.validation.test-services/1.0.0-SNAPSHOT/maven-metadata.xml
>  (2 KB at 2.7 KB/sec)
> [INFO] Downloading: 
> http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.validation.test-services/1.0.0-SNAPSHOT/org.apache.sling.validation.test-services-1.0.0-20170316.110958-1573.pom
> [INFO] Downloaded: 
> http://repository.apache.org/snapshots/org/apache/sling/org.apache.sling.validation.test-services/1.0.0-SNAPSHOT/org.apache.sling.validation.test-services-1.0.0-20170316.110958-1573.pom
>  (5 KB at 12.2 KB/sec)
> [INFO] 

[jira] [Commented] (SLING-6652) Allow multiple adapters for Models with resourceType binding

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6652:


Registering multiple models on the same adapter is already supported via 
http://sling.apache.org/documentation/bundles/models.html#specifying-an-alternate-adapter-class-since-110.
 Maybe the same implementation picker can be used if multiple 
resource-type-based model registrations exist. The default implementation 
picker will always pick the implementation with the class name which comes 
first in an alphabetical order 
(https://github.com/apache/sling/blob/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/FirstImplementationPicker.java).

> Allow multiple adapters for Models with resourceType binding
> 
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Dirk Rudolph
>
> According to 
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
>  the AdapterImplementations support only mapping resourceType to Adapter 1:1. 
> I would like to propose extending that to support 1:n binding between 
> resourceType and adapter classes.
> My use case: 
> Lets assume I want to combine my models with the exporter framework to export 
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but 
> annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6519) Remove dependency to org.json

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-6519:


GSON would work for me. I think there's also Jackson in there, but I have no 
strong preference either way.

> Remove dependency to org.json
> -
>
> Key: SLING-6519
> URL: https://issues.apache.org/jira/browse/SLING-6519
> Project: Sling
>  Issue Type: Improvement
>  Components: IDE
>Reporter: Carsten Ziegeler
>Priority: Blocker
> Fix For: Sling Eclipse IDE 1.2.0
>
>
> Some IDE code is using org.json. We have to replace this. This is the list of 
> files using that code:
> ./tooling/ide/api/src/org/apache/sling/ide/osgi/impl/HttpOsgiClient.java:import
>  org.json.JSONArray;
> ./tooling/ide/api/src/org/apache/sling/ide/osgi/impl/HttpOsgiClient.java:import
>  org.json.JSONException;
> ./tooling/ide/api/src/org/apache/sling/ide/osgi/impl/HttpOsgiClient.java:import
>  org.json.JSONObject;
> ./tooling/ide/api/src/org/apache/sling/ide/osgi/impl/HttpOsgiClient.java:import
>  org.json.JSONTokener;
> ./tooling/ide/eclipse-test/src/org/apache/sling/ide/test/impl/helpers/ExternalSlingLaunchpad.java:import
>  org.json.JSONArray;
> ./tooling/ide/eclipse-test/src/org/apache/sling/ide/test/impl/helpers/ExternalSlingLaunchpad.java:import
>  org.json.JSONObject;
> ./tooling/ide/eclipse-test/src/org/apache/sling/ide/test/impl/helpers/ExternalSlingLaunchpad.java:import
>  org.json.JSONTokener;
> ./tooling/ide/impl-resource/src/org/apache/sling/ide/impl/resource/transport/GetNodeContentCommand.java:import
>  org.json.JSONArray;
> ./tooling/ide/impl-resource/src/org/apache/sling/ide/impl/resource/transport/GetNodeContentCommand.java:import
>  org.json.JSONObject;
> ./tooling/ide/impl-resource/src/org/apache/sling/ide/impl/resource/transport/ListChildrenCommand.java:import
>  org.json.JSONObject;



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6519) Remove dependency to org.json

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6519:


What about replacing it with Google GSON (https://github.com/google/gson) then? 
Its license is Apache 2.0 and it is part of Eclipse Orbit as well 
(http://download.eclipse.org/tools/orbit/downloads/drops/R20160520211859/).

> Remove dependency to org.json
> -
>
> Key: SLING-6519
> URL: https://issues.apache.org/jira/browse/SLING-6519
> Project: Sling
>  Issue Type: Improvement
>  Components: IDE
>Reporter: Carsten Ziegeler
>Priority: Blocker
> Fix For: Sling Eclipse IDE 1.2.0
>
>
> Some IDE code is using org.json. We have to replace this. This is the list of 
> files using that code:
> ./tooling/ide/api/src/org/apache/sling/ide/osgi/impl/HttpOsgiClient.java:import
>  org.json.JSONArray;
> ./tooling/ide/api/src/org/apache/sling/ide/osgi/impl/HttpOsgiClient.java:import
>  org.json.JSONException;
> ./tooling/ide/api/src/org/apache/sling/ide/osgi/impl/HttpOsgiClient.java:import
>  org.json.JSONObject;
> ./tooling/ide/api/src/org/apache/sling/ide/osgi/impl/HttpOsgiClient.java:import
>  org.json.JSONTokener;
> ./tooling/ide/eclipse-test/src/org/apache/sling/ide/test/impl/helpers/ExternalSlingLaunchpad.java:import
>  org.json.JSONArray;
> ./tooling/ide/eclipse-test/src/org/apache/sling/ide/test/impl/helpers/ExternalSlingLaunchpad.java:import
>  org.json.JSONObject;
> ./tooling/ide/eclipse-test/src/org/apache/sling/ide/test/impl/helpers/ExternalSlingLaunchpad.java:import
>  org.json.JSONTokener;
> ./tooling/ide/impl-resource/src/org/apache/sling/ide/impl/resource/transport/GetNodeContentCommand.java:import
>  org.json.JSONArray;
> ./tooling/ide/impl-resource/src/org/apache/sling/ide/impl/resource/transport/GetNodeContentCommand.java:import
>  org.json.JSONObject;
> ./tooling/ide/impl-resource/src/org/apache/sling/ide/impl/resource/transport/ListChildrenCommand.java:import
>  org.json.JSONObject;



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6519) Remove dependency to org.json

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-6519:


We include it in the p2 repo as part of the main repo. Since it's part of Orbit 
and not of the the p2 update sites from the release train we need to provide it 
ourselves.

> Remove dependency to org.json
> -
>
> Key: SLING-6519
> URL: https://issues.apache.org/jira/browse/SLING-6519
> Project: Sling
>  Issue Type: Improvement
>  Components: IDE
>Reporter: Carsten Ziegeler
>Priority: Blocker
> Fix For: Sling Eclipse IDE 1.2.0
>
>
> Some IDE code is using org.json. We have to replace this. This is the list of 
> files using that code:
> ./tooling/ide/api/src/org/apache/sling/ide/osgi/impl/HttpOsgiClient.java:import
>  org.json.JSONArray;
> ./tooling/ide/api/src/org/apache/sling/ide/osgi/impl/HttpOsgiClient.java:import
>  org.json.JSONException;
> ./tooling/ide/api/src/org/apache/sling/ide/osgi/impl/HttpOsgiClient.java:import
>  org.json.JSONObject;
> ./tooling/ide/api/src/org/apache/sling/ide/osgi/impl/HttpOsgiClient.java:import
>  org.json.JSONTokener;
> ./tooling/ide/eclipse-test/src/org/apache/sling/ide/test/impl/helpers/ExternalSlingLaunchpad.java:import
>  org.json.JSONArray;
> ./tooling/ide/eclipse-test/src/org/apache/sling/ide/test/impl/helpers/ExternalSlingLaunchpad.java:import
>  org.json.JSONObject;
> ./tooling/ide/eclipse-test/src/org/apache/sling/ide/test/impl/helpers/ExternalSlingLaunchpad.java:import
>  org.json.JSONTokener;
> ./tooling/ide/impl-resource/src/org/apache/sling/ide/impl/resource/transport/GetNodeContentCommand.java:import
>  org.json.JSONArray;
> ./tooling/ide/impl-resource/src/org/apache/sling/ide/impl/resource/transport/GetNodeContentCommand.java:import
>  org.json.JSONObject;
> ./tooling/ide/impl-resource/src/org/apache/sling/ide/impl/resource/transport/ListChildrenCommand.java:import
>  org.json.JSONObject;



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6618) Specify crx.default as workspace for AEM servers

[Konrad Windszus (JIRA)]

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

Konrad Windszus updated SLING-6618:
---
Priority: Blocker  (was: Major)

> Specify crx.default as workspace for AEM servers
> 
>
> Key: SLING-6618
> URL: https://issues.apache.org/jira/browse/SLING-6618
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.0.10
>Reporter: Karl Pauls
>Assignee: Karl Pauls
>Priority: Blocker
> Fix For: Sling Eclipse IDE 1.2.0
>
> Attachments: SLING-6618.patch
>
>
> The current impl-vlt does try to connect to two different repository urls - 
> one for sling and one for crx. In the case of the latter, it apparently needs 
> to subsequently give the default workspace name (crx.default) to the login 
> method - otherwise, trying to connect to the AEM server fails with 
> "precondition failed" messages.
> The full stack trace of the according {{RepositoryException}} looks like this
> {code}
> javax.jcr.lock.LockException: Precondition Failed
>   at 
> org.apache.jackrabbit.spi2dav.ExceptionConverter.generate(ExceptionConverter.java:109)
>   at 
> org.apache.jackrabbit.spi2dav.ExceptionConverter.generate(ExceptionConverter.java:51)
>   at 
> org.apache.jackrabbit.spi2dav.ExceptionConverter.generate(ExceptionConverter.java:45)
>   at 
> org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.obtain(RepositoryServiceImpl.java:809)
>   at 
> org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.obtain(RepositoryServiceImpl.java:753)
>   at 
> org.apache.jackrabbit.spi2davex.RepositoryServiceImpl.obtain(RepositoryServiceImpl.java:307)
>   at 
> org.apache.jackrabbit.jcr2spi.RepositoryImpl.login(RepositoryImpl.java:151)
>   at 
> org.apache.jackrabbit.commons.AbstractRepository.login(AbstractRepository.java:144)
>   at 
> org.apache.sling.ide.jcr.RepositoryUtils.getRepositoryAddress(RepositoryUtils.java:84)
>   at 
> org.apache.sling.ide.jcr.RepositoryUtils.getRepository(RepositoryUtils.java:44)
>   at 
> org.apache.sling.ide.impl.vlt.VltRepository.connect(VltRepository.java:70)
>   at 
> org.apache.sling.ide.impl.vlt.VltRepositoryFactory.connectRepository(VltRepositoryFactory.java:69)
>   at 
> org.apache.sling.ide.eclipse.core.ServerUtil.connectRepository(ServerUtil.java:146)
>   at 
> org.apache.sling.ide.eclipse.core.internal.SlingLaunchpadBehaviour.start(SlingLaunchpadBehaviour.java:95)
>   at 
> org.apache.sling.ide.eclipse.core.internal.SlingLaunchpadLaunchConfigurationDelegate.launch(SlingLaunchpadLaunchConfigurationDelegate.java:45)
>   at 
> org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:885)
>   at 
> org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:739)
>   at 
> org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConfiguration.java:731)
>   at 
> org.eclipse.wst.server.core.internal.Server.startImpl2(Server.java:3541)
>   at 
> org.eclipse.wst.server.core.internal.Server.startImpl(Server.java:3477)
>   at 
> org.eclipse.wst.server.core.internal.Server$StartJob.run(Server.java:367)
>   at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
> Caused by: org.apache.jackrabbit.webdav.DavException: Precondition Failed
>   at 
> org.apache.jackrabbit.webdav.client.methods.DavMethodBase.getResponseException(DavMethodBase.java:162)
>   at 
> org.apache.jackrabbit.webdav.client.methods.DavMethodBase.getResponseBodyAsMultiStatus(DavMethodBase.java:91)
>   at 
> org.apache.jackrabbit.spi2dav.RepositoryServiceImpl.obtain(RepositoryServiceImpl.java:781)
>   ... 18 more
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6519) Remove dependency to org.json

[Konrad Windszus (JIRA)]

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

Konrad Windszus commented on SLING-6519:


Since we only consume a dependency being approved by Eclipse and being provided 
from orbit (not part of our releases) I think this is not a blocker for the 
1.2.0 release, right?

> Remove dependency to org.json
> -
>
> Key: SLING-6519
> URL: https://issues.apache.org/jira/browse/SLING-6519
> Project: Sling
>  Issue Type: Improvement
>  Components: IDE
>Reporter: Carsten Ziegeler
>Priority: Blocker
> Fix For: Sling Eclipse IDE 1.2.0
>
>
> Some IDE code is using org.json. We have to replace this. This is the list of 
> files using that code:
> ./tooling/ide/api/src/org/apache/sling/ide/osgi/impl/HttpOsgiClient.java:import
>  org.json.JSONArray;
> ./tooling/ide/api/src/org/apache/sling/ide/osgi/impl/HttpOsgiClient.java:import
>  org.json.JSONException;
> ./tooling/ide/api/src/org/apache/sling/ide/osgi/impl/HttpOsgiClient.java:import
>  org.json.JSONObject;
> ./tooling/ide/api/src/org/apache/sling/ide/osgi/impl/HttpOsgiClient.java:import
>  org.json.JSONTokener;
> ./tooling/ide/eclipse-test/src/org/apache/sling/ide/test/impl/helpers/ExternalSlingLaunchpad.java:import
>  org.json.JSONArray;
> ./tooling/ide/eclipse-test/src/org/apache/sling/ide/test/impl/helpers/ExternalSlingLaunchpad.java:import
>  org.json.JSONObject;
> ./tooling/ide/eclipse-test/src/org/apache/sling/ide/test/impl/helpers/ExternalSlingLaunchpad.java:import
>  org.json.JSONTokener;
> ./tooling/ide/impl-resource/src/org/apache/sling/ide/impl/resource/transport/GetNodeContentCommand.java:import
>  org.json.JSONArray;
> ./tooling/ide/impl-resource/src/org/apache/sling/ide/impl/resource/transport/GetNodeContentCommand.java:import
>  org.json.JSONObject;
> ./tooling/ide/impl-resource/src/org/apache/sling/ide/impl/resource/transport/ListChildrenCommand.java:import
>  org.json.JSONObject;



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6652) Allow multiple adapters for Models with resourceType binding

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph commented on SLING-6652:
-

Currently only a warning is logged: "Skipped registering {} for resourceType {} 
under adaptable {} because of existing mapping to {}" but I don't see anyway to 
"specify" a order of registration so it should be supported to prevent 
non-deterministic behaviour.

> Allow multiple adapters for Models with resourceType binding
> 
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Dirk Rudolph
>
> According to 
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
>  the AdapterImplementations support only mapping resourceType to Adapter 1:1. 
> I would like to propose extending that to support 1:n binding between 
> resourceType and adapter classes.
> My use case: 
> Lets assume I want to combine my models with the exporter framework to export 
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but 
> annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (SLING-6345) Publishing transfers files like ".gitignore"

[Konrad Windszus (JIRA)]

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

Konrad Windszus edited comment on SLING-6345 at 3/16/17 9:51 AM:
-

Fixed in [r1787148|http://svn.apache.org/r1787148] by adding a new workspace 
preference page where the ignored file names can be maintained. By default it 
is: {{.svn;.DS_Store;.gitignore;.vlt;.vltignore}}


was (Author: kwin):
Fixed in [r1787148|http://svn.apache.org/r1787148].

> Publishing transfers files like ".gitignore"
> 
>
> Key: SLING-6345
> URL: https://issues.apache.org/jira/browse/SLING-6345
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Sling Eclipse IDE 1.2.0
>
>
> There should be a (configurable) blacklist of certain filenames which should 
> never be published to Sling. That blacklist should include ".gitignore" and 
> ".DS_Store" files by default and maybe some more.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-6345) Publishing transfers files like ".gitignore"

[Konrad Windszus (JIRA)]

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

Konrad Windszus resolved SLING-6345.

Resolution: Fixed

Fixed in [r1787148|http://svn.apache.org/r1787148].

> Publishing transfers files like ".gitignore"
> 
>
> Key: SLING-6345
> URL: https://issues.apache.org/jira/browse/SLING-6345
> Project: Sling
>  Issue Type: Bug
>  Components: IDE
>Affects Versions: Sling Eclipse IDE 1.1.0
>Reporter: Konrad Windszus
>Assignee: Konrad Windszus
> Fix For: Sling Eclipse IDE 1.2.0
>
>
> There should be a (configurable) blacklist of certain filenames which should 
> never be published to Sling. That blacklist should include ".gitignore" and 
> ".DS_Store" files by default and maybe some more.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (SLING-6652) Allow multiple Adapters for Models with resourceType binding

[Dirk Rudolph (JIRA)]

Dirk Rudolph created SLING-6652:
---

 Summary: Allow multiple Adapters for Models with resourceType 
binding
 Key: SLING-6652
 URL: https://issues.apache.org/jira/browse/SLING-6652
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Dirk Rudolph


According to 
http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
 the AdapterImplementations support only mapping resourceType to Adapter 1:1. I 
would like to propose extending that to support 1:n binding between 
resourceType and adapter classes.

My use case: 

Lets assume I want to combine my models with the exporter framework to export 2 
representations of a single resource:

* metadata
* data

To do so I would create 2 models, each bound to the same resourceType but 
annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-6652) Allow multiple adapters for Models with resourceType binding

[Dirk Rudolph (JIRA)]

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

Dirk Rudolph updated SLING-6652:

Summary: Allow multiple adapters for Models with resourceType binding  
(was: Allow multiple Adapters for Models with resourceType binding)

> Allow multiple adapters for Models with resourceType binding
> 
>
> Key: SLING-6652
> URL: https://issues.apache.org/jira/browse/SLING-6652
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Dirk Rudolph
>
> According to 
> http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/models/impl/src/main/java/org/apache/sling/models/impl/AdapterImplementations.java?view=markup#l59
>  the AdapterImplementations support only mapping resourceType to Adapter 1:1. 
> I would like to propose extending that to support 1:n binding between 
> resourceType and adapter classes.
> My use case: 
> Lets assume I want to combine my models with the exporter framework to export 
> 2 representations of a single resource:
> * metadata
> * data
> To do so I would create 2 models, each bound to the same resourceType but 
> annotated to be exported for different selectors. 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-535) Align Node and Property Stores with Dojo's upcoming JsonRestStore

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-535.

Resolution: Won't Do

Sling Dojo moved to attic.

> Align Node and Property Stores with Dojo's upcoming JsonRestStore
> -
>
> Key: SLING-535
> URL: https://issues.apache.org/jira/browse/SLING-535
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Lars Trieloff
>Assignee: Lars Trieloff
>Priority: Minor
>
> Dojo 1.2 will include (aside from widget beautification) a JsonRestStore that 
> works very closely to what we already have in the dojo extensions, but it 
> provides some additional features like object synchronization (which is good 
> performance-wise if you are doing many reads on a node) and integration with 
> Google Gears for offline support.
> Thanks to Michael Marth for spotting this and please assign this issue to me 
> if possible.
> http://www.sitepen.com/blog/2008/06/13/restful-json-dojo-data/



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-1723) jQuery JCR Explorer - step 2

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-1723.
-
Resolution: Won't Do

Explorer moved to attic.

> jQuery JCR Explorer - step 2
> 
>
> Key: SLING-1723
> URL: https://issues.apache.org/jira/browse/SLING-1723
> Project: Sling
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Clemens Wyss
>Assignee: Clemens Wyss
>Priority: Minor
> Fix For: Sling Explorer 1.0.6
>
>
> + switch between JCR and resource view on the repo
> + choose/change workspace
> + reference support
> + import/export subtrees
> + nt:file -> file upload
> + mixin-type specific editor widgets which are included "inline" in edit.esp. 
> E.g. (maybe the only ;-) ?): mixin:versionable could provide a 
> checkin/checkout button, dropdown list of its versions, ...



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-1859) Multi-value string properties are not displayed correctly

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-1859.
-
Resolution: Won't Fix

Explorer moved to attic.

> Multi-value string properties are not displayed correctly
> -
>
> Key: SLING-1859
> URL: https://issues.apache.org/jira/browse/SLING-1859
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Sling Explorer 1.0.0
>Reporter: Carsten Ziegeler
>Assignee: Clemens Wyss
>
> I have a node with a multi value string property, and the explorer displays 
> the value as "[Ljava.lang.Object;@1a6b7e", together with the hint "[not a 
> property!] 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (SLING-1648) Node move with :replace fails

[Oliver Lietz (JIRA)]

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

Oliver Lietz updated SLING-1648:

Affects Version/s: (was: Servlets Post 2.0.4)
  Component/s: (was: Servlets)

> Node move with :replace fails
> -
>
> Key: SLING-1648
> URL: https://issues.apache.org/jira/browse/SLING-1648
> Project: Sling
>  Issue Type: Bug
>Reporter: daniel parry
>Assignee: Eric Norman
> Attachments: SLING-1648.patch
>
>
> Following docs at 
> http://sling.apache.org/site/manipulating-content-the-slingpostservlet-servletspost.html
>  In trunk, Revision: 984520, steps to reproduce error:
> curl -uadmin:admin -Ftitle="test" -Ftext="test" http://localhost:8080/test1
> curl -uadmin:admin -Ftitle="test" -Ftext="test" http://localhost:8080/test2
> curl -uadmin:admin -F":operation=move" -F:dest="/test2" 
> http://localhost:8080/test1 (Not allowed to move without :replace as expected)
> curl -uadmin:admin -F":operation=move" -F":replace=true" -F:dest="/test2" 
> http://localhost:8080/test1 (This should work with :replace specified)
> However, error encountered:
> 
> 
> Error while processing /test1
> 
> 
> Error while processing /test1
> 
> 
> 
> Status
> 500
> 
> 
> Message
> javax.jcr.PathNotFoundException: 
> /test2
> 
> 
> Location
> /test1
> 
> 
> Parent Location
> /
> 
> 
> Path
> /test1
> 
> 
> Referer
> 
> 
> 
> ChangeLog
> 
> 
> 
> 
> Go Back
> Modified Resource
> Parent of Modified Resource
> 
> 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Resolved] (SLING-1648) Node move with :replace fails

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-1648.
-
Resolution: Fixed

Works with current Sling (Jackrabbit 2.14.0/Oak 1.6.1).

> Node move with :replace fails
> -
>
> Key: SLING-1648
> URL: https://issues.apache.org/jira/browse/SLING-1648
> Project: Sling
>  Issue Type: Bug
>Reporter: daniel parry
>Assignee: Eric Norman
> Attachments: SLING-1648.patch
>
>
> Following docs at 
> http://sling.apache.org/site/manipulating-content-the-slingpostservlet-servletspost.html
>  In trunk, Revision: 984520, steps to reproduce error:
> curl -uadmin:admin -Ftitle="test" -Ftext="test" http://localhost:8080/test1
> curl -uadmin:admin -Ftitle="test" -Ftext="test" http://localhost:8080/test2
> curl -uadmin:admin -F":operation=move" -F:dest="/test2" 
> http://localhost:8080/test1 (Not allowed to move without :replace as expected)
> curl -uadmin:admin -F":operation=move" -F":replace=true" -F:dest="/test2" 
> http://localhost:8080/test1 (This should work with :replace specified)
> However, error encountered:
> 
> 
> Error while processing /test1
> 
> 
> Error while processing /test1
> 
> 
> 
> Status
> 500
> 
> 
> Message
> javax.jcr.PathNotFoundException: 
> /test2
> 
> 
> Location
> /test1
> 
> 
> Parent Location
> /
> 
> 
> Path
> /test1
> 
> 
> Referer
> 
> 
> 
> ChangeLog
> 
> 
> 
> 
> Go Back
> Modified Resource
> Parent of Modified Resource
> 
> 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (SLING-6649) Enable Felix SCR BndTools plugin

[Carsten Ziegeler (JIRA)]

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

Carsten Ziegeler commented on SLING-6649:
-

I would prefer if we avoid this: if a project uses parent 30+ it should use the 
official annotations - if for any reason a project needs to update to parent 30 
but can't use the official annotations then it has to add the missing things to 
it's pom.
If we continue to support the old scr annotations ootb, we just delay the 
migration. And the migration is really not that difficult.

> Enable Felix SCR BndTools plugin
> 
>
> Key: SLING-6649
> URL: https://issues.apache.org/jira/browse/SLING-6649
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Affects Versions: Parent 30
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Parent 31
>
>
> The [Felix SCR BndTools 
> plugin|http://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/apache-felix-scr-bndtools-use.html]
>  is currently disabled in Sling Parent:
> {noformat}
> [...]
> 
> ${sling.bree}
> 
> 
> <_plugin>org.apache.felix.bundleplugin.BlueprintPlugin,aQute.lib.spring.SpringXMLType
> 
> [...]
> {noformat}
> I tried several configurations to restore a working build of 
> {{org.apache.sling.event}} with {{maven-scr-plugin}} *and* 
> {{maven-bundle-plugin}} including testing (missing SCR descriptors) to no 
> avail and finally removed {{maven-scr-plugin}} and enabled 
> {{org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin}} in [r1787036 
> |https://svn.apache.org/r1787036].
> Using Felix SCR BndTools plugin is a quick fix obviously before switching to 
> official OSGi annotations.
> We should enable Felix SCR BndTools plugin to not block modules upgrading to 
> Sling Parent >= 30 (without reconfiguring Maven Bundle Plugin in their own 
> POMs or switching to official OSGi annotations).



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)