date:20151209

[jira] [Comment Edited] (SLING-5367) Allow specification of include/exclude patterns at request level

2015-12-09 Thread Marius Petria (JIRA)


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

Marius Petria edited comment on SLING-5367 at 12/9/15 8:57 AM:
---

We will have three types of modifiers for a package
1. package builder filters (applied to all package created by that package 
builder)
2. request filters (applied to request)
3. isDeep (applied to current request)

a. include filters include just the matched content
b. isDeep - is equivalent with a shallow distribution + include root path

{noformat}
- content
  - parent1
 - jcr:content
 - child
- jcr:content
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] isDeep=false 

DISTRIBUTED [/content/page]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent] isDeep=true 

DISTRIBUTED [/content/page]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=false 

DISTRIBUTED [/content/page, /content/page/jcr:content]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=true 

DISTRIBUTED [/content/page/jcr:content]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] isDeep=true 

DISTRIBUTED [/content/page/*]
{noformat}


was (Author: mpetria):
We will have three types of modifiers for a package
1. package builder filters (applied to all package created by that package 
builder)
2. request filters (applied to request)
3. isDeep (applied to current request)

a. include filters include just the matched content
b. isDeep - is equivalent with a shallow distribution + include root path

{noformat}
- content
  - parent1
 - jcr:content
 - child
- jcr:content
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] isDeep=false 

DISTRIBUTED [/content/page]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent] isDeep=true 

DISTRIBUTED [/content/page]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=false 

DISTRIBUTED [/content/page, /content/page/jcr:content\
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=true 

DISTRIBUTED [/content/page/jcr:content]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] isDeep=true 

DISTRIBUTED [/content/page/*]
{noformat}

> Allow specification of include/exclude patterns at request level
> 
>
> Key: SLING-5367
> URL: https://issues.apache.org/jira/browse/SLING-5367
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>
> We should allow filters to be specified at request level
> {noformat}
>  * | Pattern| Matches
>  * | /foo   | exactly "/foo"
>  * | /foo.* | all paths starting with "/foo"
>  * | ^.* /foo[^/]*$ | all files starting with "foo"
>  * | /foo/[^/]*$| all direct children of /foo
>  * | /foo/.*| all children of /foo
>  * | /foo(/.*)? | all children of /foo and foo itself
> {noformat}
> [1] 
> https://svn.apache.org/repos/asf/jackrabbit/commons/filevault/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/filter/DefaultPathFilter.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SLING-5367) Allow specification of include/exclude patterns at request level

2015-12-09 Thread Marius Petria (JIRA)


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

Marius Petria edited comment on SLING-5367 at 12/9/15 8:57 AM:
---

We will have three types of modifiers for a package
1. package builder filters (applied to all package created by that package 
builder)
2. request filters (applied to request)
3. isDeep (applied to current request)

a. include filters include just the matched content
b. isDeep - is equivalent with a shallow distribution + include root path

{noformat}
- content
  - parent1
 - jcr:content
 - child
- jcr:content
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] isDeep=false 

DISTRIBUTED [/content/page]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent] isDeep=true 

DISTRIBUTED [/content/page]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=false 

DISTRIBUTED [/content/page, /content/page/jcr:content\
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=true 

DISTRIBUTED [/content/page/jcr:content]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] isDeep=true 

DISTRIBUTED [/content/page/*]
{noformat}


was (Author: mpetria):
We will have three types of modifiers for a package
1. package builder filters (applied to all package created by that package 
builder)
2. request filters (applied to request)
3. isDeep (applied to current request)

a. include filters include just the matched content
b. isDeep - ads an include filter just for root

{noformat}
- content
  - parent1
 - jcr:content
 - child
- jcr:content
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=false 

DISTRIBUTED
/content/page
/content/page/jcr:content
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=true 

DISTRIBUTED
/content/page/jcr:content
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] isDeep=true 

DISTRIBUTED
/content/page/*
{noformat}

> Allow specification of include/exclude patterns at request level
> 
>
> Key: SLING-5367
> URL: https://issues.apache.org/jira/browse/SLING-5367
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>
> We should allow filters to be specified at request level
> {noformat}
>  * | Pattern| Matches
>  * | /foo   | exactly "/foo"
>  * | /foo.* | all paths starting with "/foo"
>  * | ^.* /foo[^/]*$ | all files starting with "foo"
>  * | /foo/[^/]*$| all direct children of /foo
>  * | /foo/.*| all children of /foo
>  * | /foo(/.*)? | all children of /foo and foo itself
> {noformat}
> [1] 
> https://svn.apache.org/repos/asf/jackrabbit/commons/filevault/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/filter/DefaultPathFilter.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-4386) Multi-tenant content model prototype

2015-12-09 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz commented on SLING-4386:


This prototype does not allow for tenant-specific servlets, only scripts can be 
selected based on content-driven tenants. You can register a servlet as usual 
but it will be global to all tenants.

> Multi-tenant content model prototype
> 
>
> Key: SLING-4386
> URL: https://issues.apache.org/jira/browse/SLING-4386
> Project: Sling
>  Issue Type: Task
>  Components: General
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>
> I'm working on a prototype for [1], will use this issue to keep track of 
> progress.
> [1] 
> https://cwiki.apache.org/confluence/display/SLING/Ideas+for+a+multi-tenant+and+multi-module+content+model



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SLING-5367) Allow specification of include/exclude patterns at request level

2015-12-09 Thread Marius Petria (JIRA)


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

Marius Petria edited comment on SLING-5367 at 12/9/15 9:03 AM:
---

We will have three types of modifiers for a package
1. package builder filters (applied to all package created by that package 
builder)
2. request filters (applied to request)
3. isDeep (applied to current request)

a. include filters include just the matched content
b. isDeep - is equivalent with a shallow distribution + include root path

{noformat}
- content
  - parent
 - jcr:content
 - child
- jcr:content
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] isDeep=false 

DISTRIBUTED [/content/page]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent] isDeep=true 

DISTRIBUTED [/content/parent]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=false 

DISTRIBUTED [/content/parent, /content/parent/jcr:content]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=true 

DISTRIBUTED [/content/parent/jcr:content]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] isDeep=true 

DISTRIBUTED [/content/parent/*]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] excludes=[/content/parent/child/.*] 
isDeep=true 

DISTRIBUTED [/content/parent, /content/parent/jcr:content, 
/content/parent/child]
{noformat}


was (Author: mpetria):
We will have three types of modifiers for a package
1. package builder filters (applied to all package created by that package 
builder)
2. request filters (applied to request)
3. isDeep (applied to current request)

a. include filters include just the matched content
b. isDeep - is equivalent with a shallow distribution + include root path

{noformat}
- content
  - parent1
 - jcr:content
 - child
- jcr:content
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] isDeep=false 

DISTRIBUTED [/content/page]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent] isDeep=true 

DISTRIBUTED [/content/page]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=false 

DISTRIBUTED [/content/page, /content/page/jcr:content]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=true 

DISTRIBUTED [/content/page/jcr:content]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] isDeep=true 

DISTRIBUTED [/content/page/*]
{noformat}

> Allow specification of include/exclude patterns at request level
> 
>
> Key: SLING-5367
> URL: https://issues.apache.org/jira/browse/SLING-5367
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>
> We should allow filters to be specified at request level
> {noformat}
>  * | Pattern| Matches
>  * | /foo   | exactly "/foo"
>  * | /foo.* | all paths starting with "/foo"
>  * | ^.* /foo[^/]*$ | all files starting with "foo"
>  * | /foo/[^/]*$| all direct children of /foo
>  * | /foo/.*| all children of /foo
>  * | /foo(/.*)? | all children of /foo and foo itself
> {noformat}
> [1] 
> https://svn.apache.org/repos/asf/jackrabbit/commons/filevault/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/filter/DefaultPathFilter.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SLING-5367) Allow specification of include/exclude patterns at request level

2015-12-09 Thread Marius Petria (JIRA)


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

Marius Petria edited comment on SLING-5367 at 12/9/15 9:05 AM:
---

We will have three types of modifiers for a package
1. package builder filters (applied to all package created by that package 
builder)
2. request filters (applied to request)
3. isDeep (applied to current request)

a. include filters include just the matched content
b. a deep request + an include filter = a shallow request (the deep request 
means it is the entire subtree but only the included filter should be packaged, 
so basically it is equivalent to a shallow request for just that path)

{noformat}
- content
  - parent
 - jcr:content
 - child
- jcr:content
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] isDeep=false 

DISTRIBUTED [/content/page]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent] isDeep=true 

DISTRIBUTED [/content/parent]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=false 

DISTRIBUTED [/content/parent, /content/parent/jcr:content]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=true 

DISTRIBUTED [/content/parent/jcr:content]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] isDeep=true 

DISTRIBUTED [/content/parent/*]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] excludes=[/content/parent/child/.*] 
isDeep=true 

DISTRIBUTED [/content/parent, /content/parent/jcr:content, 
/content/parent/child]
{noformat}


was (Author: mpetria):
We will have three types of modifiers for a package
1. package builder filters (applied to all package created by that package 
builder)
2. request filters (applied to request)
3. isDeep (applied to current request)

a. include filters include just the matched content
b. isDeep - is equivalent with a shallow distribution + include root path

{noformat}
- content
  - parent
 - jcr:content
 - child
- jcr:content
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] isDeep=false 

DISTRIBUTED [/content/page]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent] isDeep=true 

DISTRIBUTED [/content/parent]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=false 

DISTRIBUTED [/content/parent, /content/parent/jcr:content]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=true 

DISTRIBUTED [/content/parent/jcr:content]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] isDeep=true 

DISTRIBUTED [/content/parent/*]
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] excludes=[/content/parent/child/.*] 
isDeep=true 

DISTRIBUTED [/content/parent, /content/parent/jcr:content, 
/content/parent/child]
{noformat}

> Allow specification of include/exclude patterns at request level
> 
>
> Key: SLING-5367
> URL: https://issues.apache.org/jira/browse/SLING-5367
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>
> We should allow filters to be specified at request level
> {noformat}
>  * | Pattern| Matches
>  * | /foo   | exactly "/foo"
>  * | /foo.* | all paths starting with "/foo"
>  * | ^.* /foo[^/]*$ | all files starting with "foo"
>  * | /foo/[^/]*$| all direct children of /foo
>  * | /foo/.*| all children of /foo
>  * | /foo(/.*)? | all children of /foo and foo itself
> {noformat}
> [1] 
> https://svn.apache.org/repos/asf/jackrabbit/commons/filevault/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/filter/DefaultPathFilter.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5368) Update to Sling Event 4.0.0

2015-12-09 Thread Carsten Ziegeler (JIRA)

Carsten Ziegeler created SLING-5368:
---

 Summary: Update to Sling Event 4.0.0
 Key: SLING-5368
 URL: https://issues.apache.org/jira/browse/SLING-5368
 Project: Sling
  Issue Type: Improvement
  Components: Distribution
Reporter: Carsten Ziegeler
Assignee: Marius Petria
 Fix For: Content Distribution Core 0.1.12


The distribution should use the latest in Eventing and make sure that it's not 
using any deprecated/removed functionality

[~mpetria] Could you please update the dependency to Sling event 4.0.0?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [apachecms] contributing documentation for non commiters

2015-12-09 Thread Bertrand Delacretaz

Hi,

On Tue, Dec 8, 2015 at 10:02 AM, Nicolas Peltier  wrote:
> ...So i basically added a mdtext file, and modified another with a link to 
> it, ideally i’d only need to visualize
> the changes on those two files. Can someone tell me how to (simply) do 
> this?...

As per http://www.apache.org/dev/cmsref.html#non-committer has
instructions on how to do this, I haven't tested them.

The CMS has its own flavor of markdown so you might not be able to
fully validate your content without it. But we can also slightly tweak
patches that you would provide, if needed. Let's not get in the way of
people who want to contribute docs ;-)

-Bertrand

[jira] [Created] (SLING-5367) Allow specification of include/exclude patterns at request level

2015-12-09 Thread Marius Petria (JIRA)

Marius Petria created SLING-5367:


 Summary: Allow specification of include/exclude patterns at 
request level
 Key: SLING-5367
 URL: https://issues.apache.org/jira/browse/SLING-5367
 Project: Sling
  Issue Type: Improvement
  Components: Distribution
Reporter: Marius Petria


We should allow filters to be specified at request level
{noformat}
 * | Pattern| Matches
 * | /foo   | exactly "/foo"
 * | /foo.* | all paths starting with "/foo"
 * | ^.* /foo[^/]*$ | all files starting with "foo"
 * | /foo/[^/]*$| all direct children of /foo
 * | /foo/.*| all children of /foo
 * | /foo(/.*)? | all children of /foo and foo itself
{noformat}


[1] 
https://svn.apache.org/repos/asf/jackrabbit/commons/filevault/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/filter/DefaultPathFilter.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SLING-5367) Allow specification of include/exclude patterns at request level

2015-12-09 Thread Marius Petria (JIRA)


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

Marius Petria edited comment on SLING-5367 at 12/9/15 8:54 AM:
---

We will have three types of modifiers for a package
1. package builder filters (applied to all package created by that package 
builder)
2. request filters (applied to request)
3. isDeep (applied to current request)

a. include filters include just the matched content
b. isDeep - ads an include filter just for root

{noformat}
- content
  - parent1
 - jcr:content
 - child
- jcr:content
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=false 

DISTRIBUTED
/content/page
/content/page/jcr:content
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=true 

DISTRIBUTED
/content/page/jcr:content
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] isDeep=true 

DISTRIBUTED
/content/page/*
{noformat}


was (Author: mpetria):
We will have three types of modifiers for a package
1. package builder filters (applied to all package created by that package 
builder)
2. request filters (applied to request)
3. isDeep (applied to current request)

a. include filters include just the matched content
b. isDeep - ads an include filter just for root

{noformat}
- content
  - parent1
 - jcr:content
 - child
- jcr:content
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=false 

DISTRIBUTED
/content/page
/content/page/jcr:content
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=true 

DISTRIBUTED
/content/page/jcr:content
{noformat}

> Allow specification of include/exclude patterns at request level
> 
>
> Key: SLING-5367
> URL: https://issues.apache.org/jira/browse/SLING-5367
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>
> We should allow filters to be specified at request level
> {noformat}
>  * | Pattern| Matches
>  * | /foo   | exactly "/foo"
>  * | /foo.* | all paths starting with "/foo"
>  * | ^.* /foo[^/]*$ | all files starting with "foo"
>  * | /foo/[^/]*$| all direct children of /foo
>  * | /foo/.*| all children of /foo
>  * | /foo(/.*)? | all children of /foo and foo itself
> {noformat}
> [1] 
> https://svn.apache.org/repos/asf/jackrabbit/commons/filevault/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/filter/DefaultPathFilter.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5367) Allow specification of include/exclude patterns at request level

2015-12-09 Thread Marius Petria (JIRA)


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

Marius Petria commented on SLING-5367:
--

We will have three types of modifiers for a package
1. package builder filters (applied to all package created by that package 
builder)
2. request filters (applied to request)
3. isDeep (applied to current request)

{noformat}
- content
  - parent1
 - jcr:content
 - child
- jcr:content
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=false 

DISTRIBUTED
/content/page
/content/page/jcr:content
{noformat}

> Allow specification of include/exclude patterns at request level
> 
>
> Key: SLING-5367
> URL: https://issues.apache.org/jira/browse/SLING-5367
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>
> We should allow filters to be specified at request level
> {noformat}
>  * | Pattern| Matches
>  * | /foo   | exactly "/foo"
>  * | /foo.* | all paths starting with "/foo"
>  * | ^.* /foo[^/]*$ | all files starting with "foo"
>  * | /foo/[^/]*$| all direct children of /foo
>  * | /foo/.*| all children of /foo
>  * | /foo(/.*)? | all children of /foo and foo itself
> {noformat}
> [1] 
> https://svn.apache.org/repos/asf/jackrabbit/commons/filevault/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/filter/DefaultPathFilter.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

CI build for contrib

2015-12-09 Thread Carsten Ziegeler

Hi,

we have the CI builds for our contrib part, however it seems that
something is always failing there (might be different all the time) and
no one really looks into this - we have a similar problem with the main
part but here at least we try from time to time to fix the problems.

What is the point of having a CI build if no one cares? It just adds to
the volume of mails that get ignored, increases the noise of CI mails
which I think in turn lead to ignoring all CI mails including the one
from the main section.

How about disabling these jobs for contrib?

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

[jira] [Comment Edited] (SLING-5367) Allow specification of include/exclude patterns at request level

2015-12-09 Thread Marius Petria (JIRA)


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

Marius Petria edited comment on SLING-5367 at 12/9/15 8:53 AM:
---

We will have three types of modifiers for a package
1. package builder filters (applied to all package created by that package 
builder)
2. request filters (applied to request)
3. isDeep (applied to current request)

a. include filters include just the matched content
b. isDeep - ads an include filter just for root

{noformat}
- content
  - parent1
 - jcr:content
 - child
- jcr:content
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=false 

DISTRIBUTED
/content/page
/content/page/jcr:content
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=true 

DISTRIBUTED
/content/page/jcr:content
{noformat}


was (Author: mpetria):
We will have three types of modifiers for a package
1. package builder filters (applied to all package created by that package 
builder)
2. request filters (applied to request)
3. isDeep (applied to current request)

{noformat}
- content
  - parent1
 - jcr:content
 - child
- jcr:content
{noformat}

{noformat}
DISTRIBUTE paths=[/content/parent] includes=[/content/parent/jcr:content] 
isDeep=false 

DISTRIBUTED
/content/page
/content/page/jcr:content
{noformat}

> Allow specification of include/exclude patterns at request level
> 
>
> Key: SLING-5367
> URL: https://issues.apache.org/jira/browse/SLING-5367
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>
> We should allow filters to be specified at request level
> {noformat}
>  * | Pattern| Matches
>  * | /foo   | exactly "/foo"
>  * | /foo.* | all paths starting with "/foo"
>  * | ^.* /foo[^/]*$ | all files starting with "foo"
>  * | /foo/[^/]*$| all direct children of /foo
>  * | /foo/.*| all children of /foo
>  * | /foo(/.*)? | all children of /foo and foo itself
> {noformat}
> [1] 
> https://svn.apache.org/repos/asf/jackrabbit/commons/filevault/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/filter/DefaultPathFilter.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: CI build for contrib

2015-12-09 Thread Bertrand Delacretaz

On Wed, Dec 9, 2015 at 11:32 AM, Carsten Ziegeler  wrote:
> ...How about disabling these jobs for contrib?...

+1 as far as I'm concerned, I'm not looking at them currently.

-Bertrand

Re: CI build for contrib

2015-12-09 Thread Oliver Lietz

On Wednesday 09 December 2015 11:32:59 Carsten Ziegeler wrote:
> Hi,
> 
> we have the CI builds for our contrib part, however it seems that
> something is always failing there (might be different all the time) and
> no one really looks into this - we have a similar problem with the main
> part but here at least we try from time to time to fix the problems.
> 
> What is the point of having a CI build if no one cares? It just adds to
> the volume of mails that get ignored, increases the noise of CI mails
> which I think in turn lead to ignoring all CI mails including the one
> from the main section.
> 
> How about disabling these jobs for contrib?

-1

At least for me they are helpful. We should fix the tests here also or remove 
broken modules (from CI).

O.

> Carsten

[jira] [Assigned] (SLING-5348) Support Authentication in teleporter mechanism using SlingJunitServlet

2015-12-09 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz reassigned SLING-5348:
--

Assignee: Bertrand Delacretaz

> Support Authentication in teleporter mechanism using SlingJunitServlet
> --
>
> Key: SLING-5348
> URL: https://issues.apache.org/jira/browse/SLING-5348
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Sufyan Haroon
>Assignee: Bertrand Delacretaz
> Attachments: patchSupportAuthenticationThroughSlingJunitServlet.txt
>
>
> Currently, junit servlet path to be used by teleporter mechanism is hard 
> coded and points to "system/sling/junit". Junit Servlet at this does not 
> require authentication. 
> Teleporter mechanism should allow configuring Junit servlet path to be used 
> for executing tests so that if authentication is needed to run tests, one 
> configure the path to SlingJunitServlet and execute authenticated tests.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5294) Make test resources available to teleported tests

2015-12-09 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz updated SLING-5294:
---
Fix Version/s: (was: JUnit Core 1.0.14)

> Make test resources available to teleported tests
> -
>
> Key: SLING-5294
> URL: https://issues.apache.org/jira/browse/SLING-5294
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Thierry Ygé
>Assignee: Bertrand Delacretaz
> Attachments: ClientSideTeleporter.java_patch, 
> ClientSideTeleporter.java_patch_v2
>
>
> Currently you can add classes to the bundle, but not resources.
> It would be nice to simply add the following code (see attached diff).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5294) Make test resources available to teleported tests

2015-12-09 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz updated SLING-5294:
---
Fix Version/s: (was: JUnit Tests Teleporter 1.0.4)

> Make test resources available to teleported tests
> -
>
> Key: SLING-5294
> URL: https://issues.apache.org/jira/browse/SLING-5294
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Thierry Ygé
>Assignee: Bertrand Delacretaz
> Fix For: JUnit Core 1.0.14
>
> Attachments: ClientSideTeleporter.java_patch, 
> ClientSideTeleporter.java_patch_v2
>
>
> Currently you can add classes to the bundle, but not resources.
> It would be nice to simply add the following code (see attached diff).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5365) ClientSideTeleporter: optionally add Import-Package statements

2015-12-09 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz updated SLING-5365:
---
Affects Version/s: (was: JUnit Tests Teleporter 1.0.2)
   JUnit Tests Teleporter 1.0.4

> ClientSideTeleporter: optionally add Import-Package statements
> --
>
> Key: SLING-5365
> URL: https://issues.apache.org/jira/browse/SLING-5365
> Project: Sling
>  Issue Type: New Feature
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> The ClientSideTeleporter should allow for optionally adding Import-Package 
> statements to the generated test bundle.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5352) TeleporterRule should also work as a ClassRule

2015-12-09 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz commented on SLING-5352:


Have you tried running a teleported test from an IDE using this @ClassRule? 

So far I have not used that on purpose, as the test results were confused in my 
(Eclipse Luna) IDE for a class that has multiple tests.

Also, did you verify that the static bundleSymbolicName gets reset to null 
after running a test class? From the code it looks to me like as soon as that's 
set it will never be reset.

> TeleporterRule should also work as a ClassRule
> --
>
> Key: SLING-5352
> URL: https://issues.apache.org/jira/browse/SLING-5352
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Thierry Ygé
> Attachments: clientsideteleporter_patch.txt
>
>
> Currently it's not possible to use the TeleporterRule as Rule and ClassRule 
> annotation. 
> The idea is that BeforeClass will create the bundle and install it.
> AfterClass will uninstall it. This will optimize the processing and avoid a 
> lot of round trip  and waits. It still allow to use it as in the original 
> version with only Rule annotation.
> I have made some test , and will attach my suggested solution. It allow to 
> use it as before:
> {code}
> @Rule
> public TeleporterRule classRule = 
> TeleporterRule.forClass(SomeMoreTest.class, "Launchpad");
> {code}
> or as follow with a ClassRule annotation:
> {code}
> @ClassRule
> public static TeleporterRule classRule = 
> TeleporterRule.forClass(SomeTest.class, "Launchpad");
> @Rule
> public TeleporterRule teleporterRule = classRule;
> {code}
> The changes are not so big, it only need a static field to store the bundle  
> symbolic name value in the case it is used with the ClassRule annotation. 
> Then adapt the logic in the statement to differentiate between ClassRule and 
> Rule usages.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5352) TeleporterRule should also work as a ClassRule

2015-12-09 Thread Julian Sedding (JIRA)


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

Julian Sedding commented on SLING-5352:
---

I am not happy that the patch requires setting both a @ClassRule and a @Rule. I 
understand where this requirement comes from, and my impression is that this 
cannot be solved with a Rule. I think we would need to implement a Runner to 
achieve the use-case of starting a server per test class and executing 
execution of each individual test method remotely. I do hope that I am wrong, 
however.

> TeleporterRule should also work as a ClassRule
> --
>
> Key: SLING-5352
> URL: https://issues.apache.org/jira/browse/SLING-5352
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Thierry Ygé
> Attachments: clientsideteleporter_patch.txt
>
>
> Currently it's not possible to use the TeleporterRule as Rule and ClassRule 
> annotation. 
> The idea is that BeforeClass will create the bundle and install it.
> AfterClass will uninstall it. This will optimize the processing and avoid a 
> lot of round trip  and waits. It still allow to use it as in the original 
> version with only Rule annotation.
> I have made some test , and will attach my suggested solution. It allow to 
> use it as before:
> {code}
> @Rule
> public TeleporterRule classRule = 
> TeleporterRule.forClass(SomeMoreTest.class, "Launchpad");
> {code}
> or as follow with a ClassRule annotation:
> {code}
> @ClassRule
> public static TeleporterRule classRule = 
> TeleporterRule.forClass(SomeTest.class, "Launchpad");
> @Rule
> public TeleporterRule teleporterRule = classRule;
> {code}
> The changes are not so big, it only need a static field to store the bundle  
> symbolic name value in the case it is used with the ClassRule annotation. 
> Then adapt the logic in the statement to differentiate between ClassRule and 
> Rule usages.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: CI build for contrib

2015-12-09 Thread Bertrand Delacretaz

On Wed, Dec 9, 2015 at 12:37 PM, Oliver Lietz  wrote:
> ...At least for me they are helpful. We should fix the tests here also or 
> remove
> broken modules (from CI)

Of course we should, if someone has time to do that that's great. I
have more urgent things on my list at the moment, cannot help with
that.

-Bertrand

[jira] [Commented] (SLING-5348) Support Authentication in teleporter mechanism using SlingJunitServlet

2015-12-09 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz commented on SLING-5348:


Thanks very much for your contribution - I have committed a slightly modified 
version at http://svn.apache.org/r1718828 , please cross-check.

> Support Authentication in teleporter mechanism using SlingJunitServlet
> --
>
> Key: SLING-5348
> URL: https://issues.apache.org/jira/browse/SLING-5348
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Sufyan Haroon
>Assignee: Bertrand Delacretaz
> Attachments: patchSupportAuthenticationThroughSlingJunitServlet.txt
>
>
> Currently, junit servlet path to be used by teleporter mechanism is hard 
> coded and points to "system/sling/junit". Junit Servlet at this does not 
> require authentication. 
> Teleporter mechanism should allow configuring Junit servlet path to be used 
> for executing tests so that if authentication is needed to run tests, one 
> configure the path to SlingJunitServlet and execute authenticated tests.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: CI build for contrib

2015-12-09 Thread Robert Munteanu

On Wed, Dec 9, 2015 at 3:11 PM, Oliver Lietz  wrote:
> On Wednesday 09 December 2015 11:32:59 Carsten Ziegeler wrote:
>> Hi,
>>
>> we have the CI builds for our contrib part, however it seems that
>> something is always failing there (might be different all the time) and
>> no one really looks into this - we have a similar problem with the main
>> part but here at least we try from time to time to fix the problems.
>
> The Sling Lauchpad Karaf ITs fail because Jenkins is not using the latest
> Features snapshot (missing Guava bundle, Jackrabbit should be at 2.11.3).
>
> Robert, do you have an idea why it is not picked up by Jenkins?
>

Is the feature built in the same reactor?

If it is not in the same reactor, is the job invoked with -U and the
feature deployed on the Apache Nexus instance?

Robert



-- 
Sent from my (old) computer

[jira] [Updated] (SLING-5294) Make test resources available to teleported tests

2015-12-09 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz updated SLING-5294:
---
Affects Version/s: (was: JUnit Tests Teleporter 1.0.2)
   JUnit Tests Teleporter 1.0.4

> Make test resources available to teleported tests
> -
>
> Key: SLING-5294
> URL: https://issues.apache.org/jira/browse/SLING-5294
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Thierry Ygé
>Assignee: Bertrand Delacretaz
> Fix For: JUnit Core 1.0.14
>
> Attachments: ClientSideTeleporter.java_patch, 
> ClientSideTeleporter.java_patch_v2
>
>
> Currently you can add classes to the bundle, but not resources.
> It would be nice to simply add the following code (see attached diff).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5365) ClientSideTeleporter: optionally add Import-Package statements

2015-12-09 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz updated SLING-5365:
---
Fix Version/s: (was: JUnit Tests Teleporter 1.0.4)

> ClientSideTeleporter: optionally add Import-Package statements
> --
>
> Key: SLING-5365
> URL: https://issues.apache.org/jira/browse/SLING-5365
> Project: Sling
>  Issue Type: New Feature
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> The ClientSideTeleporter should allow for optionally adding Import-Package 
> statements to the generated test bundle.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5329) Add add a method to add custom manifest entries

2015-12-09 Thread JIRA


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

Thierry Ygé commented on SLING-5329:


[~bdelacretaz] it seems the same as SLING-5329, which is now resolved.


> Add add a method to add custom manifest entries
> ---
>
> Key: SLING-5329
> URL: https://issues.apache.org/jira/browse/SLING-5329
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Thierry Ygé
>
> Currently it is not possible to add any value to the generated manifest in 
> the ClientSideTeleporter, which uses TinyBundle.
> It would allow to add for example the Sling-Initial-Content information, so 
> when the ClientSideTeleporter install the bundle on the serverside, it would 
> also install content. Maybe other needs in the future will require to add 
> values in the manifest.
> I will open also another issue to suggest to implement a new method to 
> include easily test content to the generated bundle.
> cc [~bdelacretaz] [~radu.cotescu]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: CI build for contrib

2015-12-09 Thread Oliver Lietz

On Wednesday 09 December 2015 11:32:59 Carsten Ziegeler wrote:
> Hi,
> 
> we have the CI builds for our contrib part, however it seems that
> something is always failing there (might be different all the time) and
> no one really looks into this - we have a similar problem with the main
> part but here at least we try from time to time to fix the problems.

The Sling Lauchpad Karaf ITs fail because Jenkins is not using the latest 
Features snapshot (missing Guava bundle, Jackrabbit should be at 2.11.3).

Robert, do you have an idea why it is not picked up by Jenkins?

O.

> What is the point of having a CI build if no one cares? It just adds to
> the volume of mails that get ignored, increases the noise of CI mails
> which I think in turn lead to ignoring all CI mails including the one
> from the main section.
> 
> How about disabling these jobs for contrib?
> 
> Carsten

[jira] [Updated] (SLING-5294) Make test resources available to teleported tests

2015-12-09 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz updated SLING-5294:
---
Affects Version/s: (was: JUnit Tests Teleporter 1.0.4)
   JUnit Tests Teleporter 1.0.2

> Make test resources available to teleported tests
> -
>
> Key: SLING-5294
> URL: https://issues.apache.org/jira/browse/SLING-5294
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.2
>Reporter: Thierry Ygé
>Assignee: Bertrand Delacretaz
> Attachments: ClientSideTeleporter.java_patch, 
> ClientSideTeleporter.java_patch_v2
>
>
> Currently you can add classes to the bundle, but not resources.
> It would be nice to simply add the following code (see attached diff).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5365) ClientSideTeleporter: optionally add Import-Package statements

2015-12-09 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz updated SLING-5365:
---
Fix Version/s: JUnit Tests Teleporter 1.0.6

> ClientSideTeleporter: optionally add Import-Package statements
> --
>
> Key: SLING-5365
> URL: https://issues.apache.org/jira/browse/SLING-5365
> Project: Sling
>  Issue Type: New Feature
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: JUnit Tests Teleporter 1.0.6
>
>
> The ClientSideTeleporter should allow for optionally adding Import-Package 
> statements to the generated test bundle.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5348) Support Authentication in teleporter mechanism using SlingJunitServlet

2015-12-09 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz updated SLING-5348:
---
Fix Version/s: JUnit Tests Teleporter 1.0.6

> Support Authentication in teleporter mechanism using SlingJunitServlet
> --
>
> Key: SLING-5348
> URL: https://issues.apache.org/jira/browse/SLING-5348
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Sufyan Haroon
>Assignee: Bertrand Delacretaz
> Fix For: JUnit Tests Teleporter 1.0.6
>
> Attachments: patchSupportAuthenticationThroughSlingJunitServlet.txt
>
>
> Currently, junit servlet path to be used by teleporter mechanism is hard 
> coded and points to "system/sling/junit". Junit Servlet at this does not 
> require authentication. 
> Teleporter mechanism should allow configuring Junit servlet path to be used 
> for executing tests so that if authentication is needed to run tests, one 
> configure the path to SlingJunitServlet and execute authenticated tests.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5294) Make test resources available to teleported tests

2015-12-09 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz updated SLING-5294:
---
Fix Version/s: JUnit Tests Teleporter 1.0.4
   JUnit Core 1.0.14

> Make test resources available to teleported tests
> -
>
> Key: SLING-5294
> URL: https://issues.apache.org/jira/browse/SLING-5294
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.2
>Reporter: Thierry Ygé
>Assignee: Bertrand Delacretaz
> Fix For: JUnit Tests Teleporter 1.0.4, JUnit Core 1.0.14
>
> Attachments: ClientSideTeleporter.java_patch, 
> ClientSideTeleporter.java_patch_v2
>
>
> Currently you can add classes to the bundle, but not resources.
> It would be nice to simply add the following code (see attached diff).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (SLING-5329) Add add a method to add custom manifest entries

2015-12-09 Thread JIRA


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

Thierry Ygé edited comment on SLING-5329 at 12/9/15 12:15 PM:
--

[~bdelacretaz] it seems the same as SLING-5365, which is now resolved.



was (Author: petitbear68):
[~bdelacretaz] it seems the same as SLING-5329, which is now resolved.


> Add add a method to add custom manifest entries
> ---
>
> Key: SLING-5329
> URL: https://issues.apache.org/jira/browse/SLING-5329
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Thierry Ygé
>
> Currently it is not possible to add any value to the generated manifest in 
> the ClientSideTeleporter, which uses TinyBundle.
> It would allow to add for example the Sling-Initial-Content information, so 
> when the ClientSideTeleporter install the bundle on the serverside, it would 
> also install content. Maybe other needs in the future will require to add 
> values in the manifest.
> I will open also another issue to suggest to implement a new method to 
> include easily test content to the generated bundle.
> cc [~bdelacretaz] [~radu.cotescu]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5365) ClientSideTeleporter: optionally add headers to the generated bundle

2015-12-09 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz updated SLING-5365:
---
Summary: ClientSideTeleporter: optionally add headers to the generated 
bundle  (was: ClientSideTeleporter: optionally add Import-Package statements)

> ClientSideTeleporter: optionally add headers to the generated bundle
> 
>
> Key: SLING-5365
> URL: https://issues.apache.org/jira/browse/SLING-5365
> Project: Sling
>  Issue Type: New Feature
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
> Fix For: JUnit Tests Teleporter 1.0.6
>
>
> The ClientSideTeleporter should allow for optionally adding Import-Package 
> statements to the generated test bundle.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (SLING-5352) TeleporterRule should also work as a ClassRule

2015-12-09 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz updated SLING-5352:
---
Summary: TeleporterRule should also work as a ClassRule  (was: Make 
ClientSideTeleporter more efficient by making it compatible with ClassRule 
annotation)

> TeleporterRule should also work as a ClassRule
> --
>
> Key: SLING-5352
> URL: https://issues.apache.org/jira/browse/SLING-5352
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Thierry Ygé
> Attachments: clientsideteleporter_patch.txt
>
>
> Currently it's not possible to use the TeleporterRule as Rule and ClassRule 
> annotation. 
> The idea is that BeforeClass will create the bundle and install it.
> AfterClass will uninstall it. This will optimize the processing and avoid a 
> lot of round trip  and waits. It still allow to use it as in the original 
> version with only Rule annotation.
> I have made some test , and will attach my suggested solution. It allow to 
> use it as before:
> {code}
> @Rule
> public TeleporterRule classRule = 
> TeleporterRule.forClass(SomeMoreTest.class, "Launchpad");
> {code}
> or as follow with a ClassRule annotation:
> {code}
> @ClassRule
> public static TeleporterRule classRule = 
> TeleporterRule.forClass(SomeTest.class, "Launchpad");
> @Rule
> public TeleporterRule teleporterRule = classRule;
> {code}
> The changes are not so big, it only need a static field to store the bundle  
> symbolic name value in the case it is used with the ClassRule annotation. 
> Then adapt the logic in the statement to differentiate between ClassRule and 
> Rule usages.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5329) Add add a method to add custom manifest entries

2015-12-09 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz resolved SLING-5329.

Resolution: Won't Fix

Yes SLING-5365 is the generic variant of this, marking this one won't fix.

> Add add a method to add custom manifest entries
> ---
>
> Key: SLING-5329
> URL: https://issues.apache.org/jira/browse/SLING-5329
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Thierry Ygé
>Assignee: Bertrand Delacretaz
>
> Currently it is not possible to add any value to the generated manifest in 
> the ClientSideTeleporter, which uses TinyBundle.
> It would allow to add for example the Sling-Initial-Content information, so 
> when the ClientSideTeleporter install the bundle on the serverside, it would 
> also install content. Maybe other needs in the future will require to add 
> values in the manifest.
> I will open also another issue to suggest to implement a new method to 
> include easily test content to the generated bundle.
> cc [~bdelacretaz] [~radu.cotescu]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (SLING-5329) Add add a method to add custom manifest entries

2015-12-09 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz reassigned SLING-5329:
--

Assignee: Bertrand Delacretaz

> Add add a method to add custom manifest entries
> ---
>
> Key: SLING-5329
> URL: https://issues.apache.org/jira/browse/SLING-5329
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Thierry Ygé
>Assignee: Bertrand Delacretaz
>
> Currently it is not possible to add any value to the generated manifest in 
> the ClientSideTeleporter, which uses TinyBundle.
> It would allow to add for example the Sling-Initial-Content information, so 
> when the ClientSideTeleporter install the bundle on the serverside, it would 
> also install content. Maybe other needs in the future will require to add 
> values in the manifest.
> I will open also another issue to suggest to implement a new method to 
> include easily test content to the generated bundle.
> cc [~bdelacretaz] [~radu.cotescu]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-4003) Investigate compatibility with m2eclipse-tycho 0.7.0 or newer

2015-12-09 Thread Robert Munteanu (JIRA)


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

Robert Munteanu commented on SLING-4003:


Posted question on [dev@felix: How do the maven-scr-plugin and 
maven-bundle-plugin cooperate?|http://markmail.org/message/khgtoiuwsrkasuov]

> Investigate compatibility with m2eclipse-tycho 0.7.0 or newer
> -
>
> Key: SLING-4003
> URL: https://issues.apache.org/jira/browse/SLING-4003
> Project: Sling
>  Issue Type: Task
>  Components: IDE
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>Priority: Minor
> Fix For: Sling Eclipse IDE 1.1.0
>
>
> With commit 
> [85cd048f|https://github.com/tesla/m2eclipse-tycho/commit/85cd048ffcd47020992bdec2cd44f1a4945173bf]
>  m2eclipse-tycho will no longer regenerate the bundle's manifest on each 
> change. This will result in improved performance. 
> However, it might also mean that when a new SCR component is added the 
> manifest's Service-Component will not get updated with the location of the 
> newly generated descriptor files.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5352) TeleporterRule should also work as a ClassRule

2015-12-09 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz commented on SLING-5352:


bq. I am not happy that the patch requires setting both a @ClassRule and a 
@Rule.

Ah of course, if that's the case that's not good.

>From my point of view this is definitely an optimization and I'm not sure if 
>that's needed. Looking at the {{testing/samples/bundle-with-it}} module for 
>example:

{code}
Running org.apache.sling.testing.samples.bundlewit.ResourceMimeTypeDetectorIT
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.085 sec - in 
org.apache.sling.testing.samples.bundlewit.ResourceMimeTypeDetectorIT
{code}

That's 85 msec to execute two teleported tests on my 2 years old laptop, 
including the creation, installation, waiting and removal of two test bundles. 
Doesn't look like a problem to me, unless the test bundles are huge which would 
be a bad sign anyway.

So although creating a bundle for each test is not optimal, it doesn't seem to 
be an actual problem - I'd be open to improving that providing there are no 
downsides at all, and from my previous tests it looks like a ClassRule would 
confuse Eclipse when running tests from that IDE. Happy to be proven wrong (in 
code ;-)

> TeleporterRule should also work as a ClassRule
> --
>
> Key: SLING-5352
> URL: https://issues.apache.org/jira/browse/SLING-5352
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Thierry Ygé
> Attachments: clientsideteleporter_patch.txt
>
>
> Currently it's not possible to use the TeleporterRule as Rule and ClassRule 
> annotation. 
> The idea is that BeforeClass will create the bundle and install it.
> AfterClass will uninstall it. This will optimize the processing and avoid a 
> lot of round trip  and waits. It still allow to use it as in the original 
> version with only Rule annotation.
> I have made some test , and will attach my suggested solution. It allow to 
> use it as before:
> {code}
> @Rule
> public TeleporterRule classRule = 
> TeleporterRule.forClass(SomeMoreTest.class, "Launchpad");
> {code}
> or as follow with a ClassRule annotation:
> {code}
> @ClassRule
> public static TeleporterRule classRule = 
> TeleporterRule.forClass(SomeTest.class, "Launchpad");
> @Rule
> public TeleporterRule teleporterRule = classRule;
> {code}
> The changes are not so big, it only need a static field to store the bundle  
> symbolic name value in the case it is used with the ClassRule annotation. 
> Then adapt the logic in the statement to differentiate between ClassRule and 
> Rule usages.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5352) TeleporterRule should also work as a ClassRule

2015-12-09 Thread JIRA


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

Thierry Ygé commented on SLING-5352:


It's clear that with a super tiny bundle with only 1 test , it will have no 
impact, but usually it's not the reality in IT tests, in my case I have a test 
class that have about 40 tests, and it also embed content to be installed, in 
that case, it would be really helpful and so reduce time, knowing that we will 
also have many serverside tests in general, it would not only benefit that one 
class I have.

The change is minimal, and it still allow to use it as usual, so I don't see a 
reason not to apply it.


> TeleporterRule should also work as a ClassRule
> --
>
> Key: SLING-5352
> URL: https://issues.apache.org/jira/browse/SLING-5352
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Thierry Ygé
> Attachments: clientsideteleporter_patch.txt
>
>
> Currently it's not possible to use the TeleporterRule as Rule and ClassRule 
> annotation. 
> The idea is that BeforeClass will create the bundle and install it.
> AfterClass will uninstall it. This will optimize the processing and avoid a 
> lot of round trip  and waits. It still allow to use it as in the original 
> version with only Rule annotation.
> I have made some test , and will attach my suggested solution. It allow to 
> use it as before:
> {code}
> @Rule
> public TeleporterRule classRule = 
> TeleporterRule.forClass(SomeMoreTest.class, "Launchpad");
> {code}
> or as follow with a ClassRule annotation:
> {code}
> @ClassRule
> public static TeleporterRule classRule = 
> TeleporterRule.forClass(SomeTest.class, "Launchpad");
> @Rule
> public TeleporterRule teleporterRule = classRule;
> {code}
> The changes are not so big, it only need a static field to store the bundle  
> symbolic name value in the case it is used with the ClassRule annotation. 
> Then adapt the logic in the statement to differentiate between ClassRule and 
> Rule usages.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5352) TeleporterRule should also work as a ClassRule

2015-12-09 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz commented on SLING-5352:


bq. ...I have a test class that have about 40 tests, and it also embed content 
to be installed...

Did you measure the tests execution times?

bq. The change is minimal...

And did you confirm that it does not affect executing tests from an IDE? I 
haven't verified lately but my comment in ClientSideTeleporter speaks against 
ClassRule.

> TeleporterRule should also work as a ClassRule
> --
>
> Key: SLING-5352
> URL: https://issues.apache.org/jira/browse/SLING-5352
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Thierry Ygé
> Attachments: clientsideteleporter_patch.txt
>
>
> Currently it's not possible to use the TeleporterRule as Rule and ClassRule 
> annotation. 
> The idea is that BeforeClass will create the bundle and install it.
> AfterClass will uninstall it. This will optimize the processing and avoid a 
> lot of round trip  and waits. It still allow to use it as in the original 
> version with only Rule annotation.
> I have made some test , and will attach my suggested solution. It allow to 
> use it as before:
> {code}
> @Rule
> public TeleporterRule classRule = 
> TeleporterRule.forClass(SomeMoreTest.class, "Launchpad");
> {code}
> or as follow with a ClassRule annotation:
> {code}
> @ClassRule
> public static TeleporterRule classRule = 
> TeleporterRule.forClass(SomeTest.class, "Launchpad");
> @Rule
> public TeleporterRule teleporterRule = classRule;
> {code}
> The changes are not so big, it only need a static field to store the bundle  
> symbolic name value in the case it is used with the ClassRule annotation. 
> Then adapt the logic in the statement to differentiate between ClassRule and 
> Rule usages.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: CI build for contrib

2015-12-09 Thread Oliver Lietz

On Wednesday 09 December 2015 15:14:51 Robert Munteanu wrote:
> On Wed, Dec 9, 2015 at 3:11 PM, Oliver Lietz  wrote:
> > On Wednesday 09 December 2015 11:32:59 Carsten Ziegeler wrote:
> >> Hi,
> >> 
> >> we have the CI builds for our contrib part, however it seems that
> >> something is always failing there (might be different all the time) and
> >> no one really looks into this - we have a similar problem with the main
> >> part but here at least we try from time to time to fix the problems.
> > 
> > The Sling Lauchpad Karaf ITs fail because Jenkins is not using the latest
> > Features snapshot (missing Guava bundle, Jackrabbit should be at 2.11.3).
> > 
> > Robert, do you have an idea why it is not picked up by Jenkins?
> 
> Is the feature built in the same reactor?

I _guess_ so, cannot view the job configuration. Carsten, can you give me 
karma for Jenkins? 
https://wiki.apache.org/general/Jenkins#How_do_I_get_an_account

Thanks,
O.

> If it is not in the same reactor, is the job invoked with -U and the
> feature deployed on the Apache Nexus instance?
> 
> Robert

Re: CI build for contrib

2015-12-09 Thread Carsten Ziegeler

Oliver Lietz wrote
> On Wednesday 09 December 2015 15:14:51 Robert Munteanu wrote:
>> On Wed, Dec 9, 2015 at 3:11 PM, Oliver Lietz  wrote:
>>> On Wednesday 09 December 2015 11:32:59 Carsten Ziegeler wrote:
 Hi,

 we have the CI builds for our contrib part, however it seems that
 something is always failing there (might be different all the time) and
 no one really looks into this - we have a similar problem with the main
 part but here at least we try from time to time to fix the problems.
>>>
>>> The Sling Lauchpad Karaf ITs fail because Jenkins is not using the latest
>>> Features snapshot (missing Guava bundle, Jackrabbit should be at 2.11.3).
>>>
>>> Robert, do you have an idea why it is not picked up by Jenkins?
>>
>> Is the feature built in the same reactor?
> 
> I _guess_ so, cannot view the job configuration. Carsten, can you give me 
> karma for Jenkins? 
> https://wiki.apache.org/general/Jenkins#How_do_I_get_an_account
> 
Done. Not sure if it is in effect immediately though

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

[jira] [Commented] (SLING-5352) TeleporterRule should also work as a ClassRule

2015-12-09 Thread JIRA


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

Thierry Ygé commented on SLING-5352:


With @ClassRule solution my test takes

[INFO] Total time: 10.034 s
[INFO] Finished at: 2015-12-09T16:56:32+01:00
[INFO] Final Memory: 34M/443M

without it takes:
[INFO] Total time: 18.178 s
[INFO] Finished at: 2015-12-09T16:57:59+01:00
[INFO] Final Memory: 35M/444M

So about 8 seconds different (which is close to 50% time saved) for 56 tests in 
my current test class.

Is that enough to show it would help ? :)

> TeleporterRule should also work as a ClassRule
> --
>
> Key: SLING-5352
> URL: https://issues.apache.org/jira/browse/SLING-5352
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Thierry Ygé
> Attachments: clientsideteleporter_patch.txt
>
>
> Currently it's not possible to use the TeleporterRule as Rule and ClassRule 
> annotation. 
> The idea is that BeforeClass will create the bundle and install it.
> AfterClass will uninstall it. This will optimize the processing and avoid a 
> lot of round trip  and waits. It still allow to use it as in the original 
> version with only Rule annotation.
> I have made some test , and will attach my suggested solution. It allow to 
> use it as before:
> {code}
> @Rule
> public TeleporterRule classRule = 
> TeleporterRule.forClass(SomeMoreTest.class, "Launchpad");
> {code}
> or as follow with a ClassRule annotation:
> {code}
> @ClassRule
> public static TeleporterRule classRule = 
> TeleporterRule.forClass(SomeTest.class, "Launchpad");
> @Rule
> public TeleporterRule teleporterRule = classRule;
> {code}
> The changes are not so big, it only need a static field to store the bundle  
> symbolic name value in the case it is used with the ClassRule annotation. 
> Then adapt the logic in the statement to differentiate between ClassRule and 
> Rule usages.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (SLING-5367) Allow specification of include/exclude patterns at request level

2015-12-09 Thread Marius Petria (JIRA)


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

Marius Petria resolved SLING-5367.
--
   Resolution: Fixed
 Assignee: Marius Petria
Fix Version/s: Content Distribution Core 0.1.12

Committed revision 1718890.

> Allow specification of include/exclude patterns at request level
> 
>
> Key: SLING-5367
> URL: https://issues.apache.org/jira/browse/SLING-5367
> Project: Sling
>  Issue Type: Improvement
>  Components: Distribution
>Reporter: Marius Petria
>Assignee: Marius Petria
> Fix For: Content Distribution Core 0.1.12
>
>
> We should allow filters to be specified at request level
> {noformat}
>  * | Pattern| Matches
>  * | /foo   | exactly "/foo"
>  * | /foo.* | all paths starting with "/foo"
>  * | ^.* /foo[^/]*$ | all files starting with "foo"
>  * | /foo/[^/]*$| all direct children of /foo
>  * | /foo/.*| all children of /foo
>  * | /foo(/.*)? | all children of /foo and foo itself
> {noformat}
> [1] 
> https://svn.apache.org/repos/asf/jackrabbit/commons/filevault/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/fs/filter/DefaultPathFilter.java



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5352) TeleporterRule should also work as a ClassRule

2015-12-09 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz commented on SLING-5352:


bq. Is that enough to show it would help?

Yes, definitely qualifies for optimization, thanks for testing!

I'll have a look at the possible IDE confusion that I noted before.

> TeleporterRule should also work as a ClassRule
> --
>
> Key: SLING-5352
> URL: https://issues.apache.org/jira/browse/SLING-5352
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Thierry Ygé
> Attachments: clientsideteleporter_patch.txt
>
>
> Currently it's not possible to use the TeleporterRule as Rule and ClassRule 
> annotation. 
> The idea is that BeforeClass will create the bundle and install it.
> AfterClass will uninstall it. This will optimize the processing and avoid a 
> lot of round trip  and waits. It still allow to use it as in the original 
> version with only Rule annotation.
> I have made some test , and will attach my suggested solution. It allow to 
> use it as before:
> {code}
> @Rule
> public TeleporterRule classRule = 
> TeleporterRule.forClass(SomeMoreTest.class, "Launchpad");
> {code}
> or as follow with a ClassRule annotation:
> {code}
> @ClassRule
> public static TeleporterRule classRule = 
> TeleporterRule.forClass(SomeTest.class, "Launchpad");
> @Rule
> public TeleporterRule teleporterRule = classRule;
> {code}
> The changes are not so big, it only need a static field to store the bundle  
> symbolic name value in the case it is used with the ClassRule annotation. 
> Then adapt the logic in the statement to differentiate between ClassRule and 
> Rule usages.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (SLING-5369) Update to JUnit 4.12

2015-12-09 Thread JIRA

Thierry Ygé created SLING-5369:
--

 Summary: Update to JUnit 4.12
 Key: SLING-5369
 URL: https://issues.apache.org/jira/browse/SLING-5369
 Project: Sling
  Issue Type: Improvement
  Components: Testing
Affects Versions: JUnit Core 1.0.14
Reporter: Thierry Ygé


Currently JUnit Core is based on JUnit 4.11, in SLING-5352, some improvement 
could benefit from the enhancement implemented  in JUnit 4.12 related to 
possibility to combine both ClassRule and Rule annotation for a static field.

That would be a great help to simplify the use case discussed in SLING-5352.

simply update the version on the pom.xml would be sufficient.

from  4.11
{noformat}
...

4.11
1.3
0.6.2.201302030002

...
{noformat}

to 4.12

{noformat}
...

4.12
1.3
0.6.2.201302030002

...
{noformat}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5352) TeleporterRule should also work as a ClassRule

2015-12-09 Thread JIRA


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

Thierry Ygé commented on SLING-5352:


[~bdelacretaz] Note also that is we could use junit 4.12 we could also simply 
use both annotation combined for the same field as described in 
https://github.com/junit-team/junit/pull/932

So below would work:
{code}
@Rule
@ClassRule
public static TeleporterRule classRule = 
TeleporterRule.forClass(SomeTest.class, "Launchpad");
{code}


It works on my maven side , but not on the serverside, I guess it is due to the 
version of junit embedded in Sling JUnit Core version which I think is 4.11 at 
the moment (see 
http://svn.apache.org/repos/asf/sling/trunk/testing/junit/core/pom.xml), so 
that would be a easy fix, should I open another jira for that too ? 

About Eclipse IDE, I see also it's not able to run test that contains 
ClassRule, maybe due to the version of Test runner on Eclipse ? (I tested with 
Eclipse Mars release). It's odd that it works with maven command but not in 
Eclipse IDE. Maybe we need to file a bug for it.



> TeleporterRule should also work as a ClassRule
> --
>
> Key: SLING-5352
> URL: https://issues.apache.org/jira/browse/SLING-5352
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: JUnit Tests Teleporter 1.0.4
>Reporter: Thierry Ygé
> Attachments: clientsideteleporter_patch.txt
>
>
> Currently it's not possible to use the TeleporterRule as Rule and ClassRule 
> annotation. 
> The idea is that BeforeClass will create the bundle and install it.
> AfterClass will uninstall it. This will optimize the processing and avoid a 
> lot of round trip  and waits. It still allow to use it as in the original 
> version with only Rule annotation.
> I have made some test , and will attach my suggested solution. It allow to 
> use it as before:
> {code}
> @Rule
> public TeleporterRule classRule = 
> TeleporterRule.forClass(SomeMoreTest.class, "Launchpad");
> {code}
> or as follow with a ClassRule annotation:
> {code}
> @ClassRule
> public static TeleporterRule classRule = 
> TeleporterRule.forClass(SomeTest.class, "Launchpad");
> @Rule
> public TeleporterRule teleporterRule = classRule;
> {code}
> The changes are not so big, it only need a static field to store the bundle  
> symbolic name value in the case it is used with the ClassRule annotation. 
> Then adapt the logic in the statement to differentiate between ClassRule and 
> Rule usages.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (SLING-5356) Extract and generalize the Sling Mocks ContentBuilder

2015-12-09 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz reassigned SLING-5356:
--

Assignee: Bertrand Delacretaz

> Extract and generalize the Sling Mocks ContentBuilder
> -
>
> Key: SLING-5356
> URL: https://issues.apache.org/jira/browse/SLING-5356
> Project: Sling
>  Issue Type: New Feature
>  Components: General
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> As discussed recently on our dev list the {{ContentBuilder}} currently 
> provided by the Sling Mocks library [1] can be very useful in testing. 
> In order to make it usable for both client-side and server-side testing (as 
> well as in server-side code) I'm planning to
> * Extract it into its own module
> * Define an API that allows for creating nodes and properties, importing JSON 
> and other files via the Sling ContentLoader and providing a simple a way to 
> cleanup the test content
> * Implement (first) a server-side version of that API
> * Implement (as a second priority) a client-side version that can be used in 
> test run via HTTP
> This shouldn't affect the existing Sling Mocks library users, except maybe 
> forcing them to rebuild their tests to use the new API.
> [1] 
> https://sling.apache.org/documentation/development/sling-mock.html#building-content



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (SLING-5356) Extract and generalize the Sling Mocks ContentBuilder

2015-12-09 Thread Bertrand Delacretaz (JIRA)


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

Bertrand Delacretaz commented on SLING-5356:


I have commited a first work-in-progress version at 
http://svn.apache.org/r1718908.

For now the interesting bits are the ResourceBuilder interface, demonstrated by 
the ResourceBuilderImplTest.

Building a small tree looks like this:

{code}
builder
.resource("a/b/c", "title", "foo", "count", 21)
.siblingsMode()
.resource("1")
.resource("2")
.resource("3")
.hierarchyMode()
.resource("with")
.resource("more/here", "it", "worked")
.resource("deepest", "it", "worked")
.commit();
{code}

As a next step I'm planning to add support for loading ContentLoader definition 
files.

> Extract and generalize the Sling Mocks ContentBuilder
> -
>
> Key: SLING-5356
> URL: https://issues.apache.org/jira/browse/SLING-5356
> Project: Sling
>  Issue Type: New Feature
>  Components: General
>Reporter: Bertrand Delacretaz
>Assignee: Bertrand Delacretaz
>Priority: Minor
>
> As discussed recently on our dev list the {{ContentBuilder}} currently 
> provided by the Sling Mocks library [1] can be very useful in testing. 
> In order to make it usable for both client-side and server-side testing (as 
> well as in server-side code) I'm planning to
> * Extract it into its own module
> * Define an API that allows for creating nodes and properties, importing JSON 
> and other files via the Sling ContentLoader and providing a simple a way to 
> cleanup the test content
> * Implement (first) a server-side version of that API
> * Implement (as a second priority) a client-side version that can be used in 
> test run via HTTP
> This shouldn't affect the existing Sling Mocks library users, except maybe 
> forcing them to rebuild their tests to use the new API.
> [1] 
> https://sling.apache.org/documentation/development/sling-mock.html#building-content



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

49 matches

Mail list logo