Re: sling ci builds per module

[Robert Munteanu]

On Thu, 2016-09-29 at 15:16 +0200, Oliver Lietz wrote:
> > Do you want me to set per-module build jobs for the Karaf build as
> > well?
> 
> Yes, please. Didn't look into build job before holidays because of
> used 
> bundles under vote (in features).

Done. Now remember, if it fails you can't disable it since it's all
automated so you have to fix it :-) .

Robert

[jira] [Commented] (SLING-6080) oak-server ITs fail under Java 7

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-6080:


I've changed the tests to run on Java 8 only ( https://svn.apache.org/r1762838 
), but it would be good to enable them for Java 7 as well.

[~olli] - what would you suggest here?

> oak-server ITs fail under Java 7
> 
>
> Key: SLING-6080
> URL: https://issues.apache.org/jira/browse/SLING-6080
> Project: Sling
>  Issue Type: Bug
>  Components: JCR
>Reporter: Robert Munteanu
> Fix For: JCR Oak Server 1.1.2
>
>
> The oak-server build fails with Java 7 since the pax-exam config pulls in the 
> jetty bundle ( via slingJcr → webconsole → http ).



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

[jira] [Created] (SLING-6080) oak-server ITs fail under Java 7

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-6080:
--

 Summary: oak-server ITs fail under Java 7
 Key: SLING-6080
 URL: https://issues.apache.org/jira/browse/SLING-6080
 Project: Sling
  Issue Type: Bug
  Components: JCR
Reporter: Robert Munteanu
 Fix For: JCR Oak Server 1.1.2


The oak-server build fails with Java 7 since the pax-exam config pulls in the 
jetty bundle ( via slingJcr → webconsole → http ).



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

[jira] [Created] (SLING-6079) commons.messaging.mail build fails on Jenkins

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-6079:
--

 Summary: commons.messaging.mail build fails on Jenkins
 Key: SLING-6079
 URL: https://issues.apache.org/jira/browse/SLING-6079
 Project: Sling
  Issue Type: Bug
  Components: Commons
Reporter: Robert Munteanu
Assignee: Oliver Lietz


The build fails on jenkins, apparently due to the same root cause as SLING-6704:

{noformat}java.io.IOException: Error resolving artifact 
org.apache.sling:org.apache.sling.commons.messaging:jar:0.0.1-SNAPSHOT: Could 
not find artifact 
org.apache.sling:org.apache.sling.commons.messaging:jar:0.0.1-SNAPSHOT{noformat}

However, when I try the same approach:

{noformat}diff --git 
a/bundles/commons/org.apache.sling.commons.messaging.mail/src/test/java/org/apache/sling/commons/messaging/mail/MailTestSupport.java
 
b/bundles/commons/org.apache.sling.commons.messaging.mail/src/test/java/org/apache/sling/commons/messaging/mail/MailTestSupport.java
index a1edb6c..d045f80 100644
--- 
a/bundles/commons/org.apache.sling.commons.messaging.mail/src/test/java/org/apache/sling/commons/messaging/mail/MailTestSupport.java
+++ 
b/bundles/commons/org.apache.sling.commons.messaging.mail/src/test/java/org/apache/sling/commons/messaging/mail/MailTestSupport.java
@@ -36,6 +36,7 @@ import static org.ops4j.pax.exam.CoreOptions.junitBundles;
 import static org.ops4j.pax.exam.CoreOptions.mavenBundle;
 import static org.ops4j.pax.exam.CoreOptions.options;
 import static org.ops4j.pax.exam.CoreOptions.provision;
+import static org.ops4j.pax.exam.CoreOptions.repository;
 import static org.ops4j.pax.exam.CoreOptions.wrappedBundle;
 
 public abstract class MailTestSupport {
@@ -78,6 +79,8 @@ public abstract class MailTestSupport {
 protected Option[] baseConfiguration() {
 final String filename = System.getProperty("bundle.filename");
 return options(
+repository("https://repo.maven.apache.org/maven2/;).id("central"),
+
repository("https://repository.apache.org/snapshots/;).id("apache-snapshots").allowSnapshots(),
 junitBundles(),
 provision(
 
wrappedBundle(mavenBundle().groupId("org.subethamail").artifactId("subethasmtp").versionAsInProject()),{noformat}

it fails to find a pax-exam bundle:

{noformat}java.io.IOException: Error resolving artifact 
org.ops4j.pax.exam:pax-exam-inject:jar:4.9.1: Could not find artifact 
org.ops4j.pax.exam:pax-exam-inject:jar:4.9.1{noformat}



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

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

[Robert Munteanu (JIRA)]

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

Robert Munteanu commented on SLING-6061:


The above items are complete, but a couple of jobs are still unstable, 
including the launchpad.

See the following view for all the builds needing attention

https://builds.apache.org/view/S-Z/view/Sling-Dashboard/

Will let this bake for a while and also try to reduce/remove the 
failing/unstable builds.

> Create per-module Jenkins jobs
> --
>
> Key: SLING-6061
> URL: https://issues.apache.org/jira/browse/SLING-6061
> Project: Sling
>  Issue Type: Improvement
>  Components: General
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>
> As discussed on [dev@sling: CI alternatives for 
> Sling|http://markmail.org/message/mdn4anwe6kxqxa2z] we should investigate 
> generating per-module builds instead of having 'full' builds.
> The reason is that our currently large builds are slow and feedback is 
> useless since most of the times at least one module is failing.
> We will first prototype a build using the Jenkins [Job DSL 
> Plugin|https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin], which 
> will allow us to programatically define what build jobs are generated and 
> their configuration.
> The proposed approach is to gradually transfer project from a large job to 
> per-module jobs, using the following mechanism ( details to be filled in ):
> * create a mechanism which will allow us to skip building some modules on 
> Jenkins
> * create a Jenkins DSL Job config in SVN which will generate builds for 
> specific modules ( the i18n module is a good candidate, since it is flaky on 
> Jenkins recently )
> * exclude the 'modularised' build modules from the main build
> In time, we will move out all bundle modules from the current reactor and we 
> should have the following main classes of build jobs:
> * bundles
> * launchpads ( main, contrib, etc )
> * utility modules ( testing )
> * integration tests
> * tooling/maven
> * tooling/ide
> Note that this does not exclude 'bigger' modules like for instance Sightly 
> which contain bundles, content and integration tests. At first I'd like to 
> get a feel of what solution is best for us.



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

Re: pipes release 0.0.10

[Oliver Lietz]

On Thursday 29 September 2016 18:39:31 Nicolas Peltier wrote:
> Hi Oliver,
> 
> fine with me :-)

Looking closer... I *wonder* if not all pipes but BasePipe, ContainerPipe and 
ReferencePipe should go to impl. Or are they meant to be extended?

Thanks,
O.

> Nicolas
> 
> > On Sep 29, 2016, at 8:37 PM, Oliver Lietz  wrote:
> > 
> > On Thursday 29 September 2016 16:23:27 Nicolas Peltier wrote:
> >> Hi,
> > 
> > Hi Nicolas,
> > 
> >> can someone that has time :-S please
> >> resolve https://issues.apache.org/jira/browse/SLING-6073 (patch
> >> attached),
> >> and release 0.0.10 that correspond to what was presented at the adaptTo?
> > 
> > I've moved DefaultOutputWriter and PlumberServlet to package impl (as
> > discussed at adaptTo()), please check if it works for you.
> > 
> > Regards,
> > O.
> > 
> >> Thanks a lot!
> >> 
> >> Nicolas

Re: pipes release 0.0.10

[Nicolas Peltier]

Hi Oliver,

fine with me :-)

Nicolas
> On Sep 29, 2016, at 8:37 PM, Oliver Lietz  wrote:
> 
> On Thursday 29 September 2016 16:23:27 Nicolas Peltier wrote:
>> Hi,
> 
> Hi Nicolas,
> 
>> can someone that has time :-S please
>> resolve https://issues.apache.org/jira/browse/SLING-6073 (patch attached),
>> and release 0.0.10 that correspond to what was presented at the adaptTo?
> 
> I've moved DefaultOutputWriter and PlumberServlet to package impl (as 
> discussed at adaptTo()), please check if it works for you.
> 
> Regards,
> O.
> 
>> Thanks a lot!
>> 
>> Nicolas
> 

Re: pipes release 0.0.10

[Oliver Lietz]

On Thursday 29 September 2016 16:23:27 Nicolas Peltier wrote:
> Hi,

Hi Nicolas,

> can someone that has time :-S please
> resolve https://issues.apache.org/jira/browse/SLING-6073 (patch attached),
> and release 0.0.10 that correspond to what was presented at the adaptTo?

I've moved DefaultOutputWriter and PlumberServlet to package impl (as 
discussed at adaptTo()), please check if it works for you.

Regards,
O.

> Thanks a lot!
> 
> Nicolas

Re: pipes release 0.0.10

[Oliver Lietz]

On Thursday 29 September 2016 16:23:27 Nicolas Peltier wrote:
> Hi,

Hi Nicolas,

> can someone that has time :-S please
> resolve https://issues.apache.org/jira/browse/SLING-6073 (patch attached),
> and release 0.0.10 that correspond to what was presented at the adaptTo?

I will not receive mails to "Oliver Lietz " unless you also 
mail to dev@ or any of my private addresses. 8D

Patch is applied, will try to find some time to do the release.

Regards,
O.

> Thanks a lot!
> 
> Nicolas

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

[Oliver Lietz (JIRA)]

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

Oliver Lietz updated SLING-6073:

Affects Version/s: (was: Pipes 0.0.10)

> pipe writer and additionalbindings configurations added through POST break 
> the pipe
> ---
>
> Key: SLING-6073
> URL: https://issues.apache.org/jira/browse/SLING-6073
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Nicolas Peltier
>Assignee: Oliver Lietz
> Fix For: Pipes 0.0.10
>
> Attachments: SLING-6073.patch
>
>
> if POST contains protected properties (like jcr:created / jcr:createdBy), 
> those properties shouldn't be taken in account by writer or 
> additionalbinding, like it is done in other places



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

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

[Oliver Lietz (JIRA)]

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

Oliver Lietz updated SLING-6073:

Component/s: Extensions

> pipe writer and additionalbindings configurations added through POST break 
> the pipe
> ---
>
> Key: SLING-6073
> URL: https://issues.apache.org/jira/browse/SLING-6073
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Nicolas Peltier
>Assignee: Oliver Lietz
> Fix For: Pipes 0.0.10
>
> Attachments: SLING-6073.patch
>
>
> if POST contains protected properties (like jcr:created / jcr:createdBy), 
> those properties shouldn't be taken in account by writer or 
> additionalbinding, like it is done in other places



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

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

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-6073.
-
   Resolution: Fixed
Fix Version/s: Pipes 0.0.10

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

> pipe writer and additionalbindings configurations added through POST break 
> the pipe
> ---
>
> Key: SLING-6073
> URL: https://issues.apache.org/jira/browse/SLING-6073
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Pipes 0.0.10
>Reporter: Nicolas Peltier
>Assignee: Oliver Lietz
> Fix For: Pipes 0.0.10
>
> Attachments: SLING-6073.patch
>
>
> if POST contains protected properties (like jcr:created / jcr:createdBy), 
> those properties shouldn't be taken in account by writer or 
> additionalbinding, like it is done in other places



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

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

[Oliver Lietz (JIRA)]

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

Oliver Lietz reassigned SLING-6073:
---

Assignee: Oliver Lietz

> pipe writer and additionalbindings configurations added through POST break 
> the pipe
> ---
>
> Key: SLING-6073
> URL: https://issues.apache.org/jira/browse/SLING-6073
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Pipes 0.0.10
>Reporter: Nicolas Peltier
>Assignee: Oliver Lietz
> Attachments: SLING-6073.patch
>
>
> if POST contains protected properties (like jcr:created / jcr:createdBy), 
> those properties shouldn't be taken in account by writer or 
> additionalbinding, like it is done in other places



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

[jira] [Resolved] (SLING-6075) Update Thymeleaf to 3.0.2

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-6075.
-
Resolution: Done

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

> Update Thymeleaf to 3.0.2
> -
>
> Key: SLING-6075
> URL: https://issues.apache.org/jira/browse/SLING-6075
> Project: Sling
>  Issue Type: Improvement
>  Components: Scripting
>Affects Versions: Scripting Thymeleaf 1.0.0
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
> Fix For: Scripting Thymeleaf 1.0.2
>
>
> http://forum.thymeleaf.org/Thymeleaf-3-0-2-JUST-PUBLISHED-td4029985.html



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

pipes release 0.0.10

[Nicolas Peltier]

Hi,

can someone that has time :-S please
resolve https://issues.apache.org/jira/browse/SLING-6073 (patch attached), and
release 0.0.10 that correspond to what was presented at the adaptTo?

Thanks a lot!

Nicolas

[jira] [Resolved] (SLING-6077) sling-mock: ResourceResolverFactory is registered twice

[Stefan Seifert (JIRA)]

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

Stefan Seifert resolved SLING-6077.
---
Resolution: Fixed

Completed: At revision: 1762809  

to be precise this was not an error in sling-mock itself, but in the underlying 
{{org.apache.sling.resourceresolver}} and {{org.apache.sling.jcr.resource}} 
implementations that where used. fixed by updating to a slightly newer version 
of both.

> sling-mock: ResourceResolverFactory is registered twice
> ---
>
> Key: SLING-6077
> URL: https://issues.apache.org/jira/browse/SLING-6077
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing Sling Mock 2.1.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: mocks
> Fix For: Testing Sling Mock 2.1.2
>
>
> when using sling mocks the ResourceResolverFactory service is registered 
> twice. this is not obvious because everything is well for most operations.
> but if an OSGi service references it like this:
> {code:java}
> @Reference
> private ResourceResolverFactory factory;
> {code}
> it fails because multiple references exist (i'm not sure if this is 100% 
> correct in the osgi-mock, need to look up the DS spec).



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

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

[Nicolas Peltier (JIRA)]

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

Nicolas Peltier updated SLING-6073:
---
Attachment: SLING-6073.patch

> pipe writer and additionalbindings configurations added through POST break 
> the pipe
> ---
>
> Key: SLING-6073
> URL: https://issues.apache.org/jira/browse/SLING-6073
> Project: Sling
>  Issue Type: Bug
>Affects Versions: Pipes 0.0.10
>Reporter: Nicolas Peltier
> Attachments: SLING-6073.patch
>
>
> if POST contains protected properties (like jcr:created / jcr:createdBy), 
> those properties shouldn't be taken in account by writer or 
> additionalbinding, like it is done in other places



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

[jira] [Created] (SLING-6078) add a fluent api to generate a sling pipe

[Nicolas Peltier (JIRA)]

Nicolas Peltier created SLING-6078:
--

 Summary: add a fluent api to generate a sling pipe
 Key: SLING-6078
 URL: https://issues.apache.org/jira/browse/SLING-6078
 Project: Sling
  Issue Type: Improvement
  Components: Extensions
Reporter: Nicolas Peltier


it would be cool that plumber or sthing like PipeBuilder allows to generate a 
pipe, writing the serialization of it, with simple API
(thx [~bdelacretaz] for the idea!)



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

[jira] [Resolved] (SLING-6069) Error: Multiple matches found for unary reference 'factory'

[Stefan Seifert (JIRA)]

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

Stefan Seifert resolved SLING-6069.
---
Resolution: Duplicate

duplicate of SLING-6077

> Error: Multiple matches found for unary reference 'factory' 
> 
>
> Key: SLING-6069
> URL: https://issues.apache.org/jira/browse/SLING-6069
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing Sling Mock 2.1.0, Testing Sling Mock Oak 2.0.2
>Reporter: Christoph Thodte
>
> When starting with a simple test using a the special rs type 
> ResourceResolverType.JCR_OAK
> {code:java}
> public class FormularServiceTest {
> @Rule
> public final SlingContext slingContext = new 
> SlingContext(ResourceResolverType.JCR_OAK);
> @Test
> public void testFormService() {
> FormularService formularService = 
> slingContext.registerInjectActivateService(new FormularService());
> FormModel form = formularService.findFormByFormId("331");
> Assert.assertNotNull(form);
> }
> ...
> {code}
> I get the error 
> org.apache.sling.testing.mock.osgi.ReferenceViolationException: Multiple 
> matches found for unary reference 'factory' for class 
> de.htsolutions.formver.service.FormularService
>   at 
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.injectServiceReference(OsgiServiceUtil.java:416)
>   at 
> org.apache.sling.testing.mock.osgi.OsgiServiceUtil.injectServices(OsgiServiceUtil.java:389)
>   at 
> org.apache.sling.testing.mock.osgi.MockOsgi.injectServices(MockOsgi.java:146)
> I debug the code and I find that the reason is that there are two 
> resourceresolver in context not only one.
> What's the problem here? Is it a bug? Problem in setup?



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

[jira] [Commented] (SLING-6077) sling-mock: ResourceResolverFactory is registered twice

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6077:
---

ah yes, missed that

> sling-mock: ResourceResolverFactory is registered twice
> ---
>
> Key: SLING-6077
> URL: https://issues.apache.org/jira/browse/SLING-6077
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing Sling Mock 2.1.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: mocks
> Fix For: Testing Sling Mock 2.1.2
>
>
> when using sling mocks the ResourceResolverFactory service is registered 
> twice. this is not obvious because everything is well for most operations.
> but if an OSGi service references it like this:
> {code:java}
> @Reference
> private ResourceResolverFactory factory;
> {code}
> it fails because multiple references exist (i'm not sure if this is 100% 
> correct in the osgi-mock, need to look up the DS spec).



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

[jira] [Commented] (SLING-6077) sling-mock: ResourceResolverFactory is registered twice

[Christoph Thodte (JIRA)]

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

Christoph Thodte commented on SLING-6077:
-

my case can be closed?
SLING-6069

> sling-mock: ResourceResolverFactory is registered twice
> ---
>
> Key: SLING-6077
> URL: https://issues.apache.org/jira/browse/SLING-6077
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing Sling Mock 2.1.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: mocks
> Fix For: Testing Sling Mock 2.1.2
>
>
> when using sling mocks the ResourceResolverFactory service is registered 
> twice. this is not obvious because everything is well for most operations.
> but if an OSGi service references it like this:
> {code:java}
> @Reference
> private ResourceResolverFactory factory;
> {code}
> it fails because multiple references exist (i'm not sure if this is 100% 
> correct in the osgi-mock, need to look up the DS spec).



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

[jira] [Commented] (SLING-6077) sling-mock: ResourceResolverFactory is registered twice

[Stefan Seifert (JIRA)]

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

Stefan Seifert commented on SLING-6077:
---

problem does not exist in sling-mock 1.x, added unit test to make sure in rev. 
1762796 


> sling-mock: ResourceResolverFactory is registered twice
> ---
>
> Key: SLING-6077
> URL: https://issues.apache.org/jira/browse/SLING-6077
> Project: Sling
>  Issue Type: Bug
>  Components: Testing
>Affects Versions: Testing Sling Mock 2.1.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>  Labels: mocks
> Fix For: Testing Sling Mock 2.1.2
>
>
> when using sling mocks the ResourceResolverFactory service is registered 
> twice. this is not obvious because everything is well for most operations.
> but if an OSGi service references it like this:
> {code:java}
> @Reference
> private ResourceResolverFactory factory;
> {code}
> it fails because multiple references exist (i'm not sure if this is 100% 
> correct in the osgi-mock, need to look up the DS spec).



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

[jira] [Created] (SLING-6077) sling-mock: ResourceResolverFactory is registered twice

[Stefan Seifert (JIRA)]

Stefan Seifert created SLING-6077:
-

 Summary: sling-mock: ResourceResolverFactory is registered twice
 Key: SLING-6077
 URL: https://issues.apache.org/jira/browse/SLING-6077
 Project: Sling
  Issue Type: Bug
  Components: Testing
Affects Versions: Testing Sling Mock 2.1.0
Reporter: Stefan Seifert
Assignee: Stefan Seifert
 Fix For: Testing Sling Mock 2.1.2


when using sling mocks the ResourceResolverFactory service is registered twice. 
this is not obvious because everything is well for most operations.

but if an OSGi service references it like this:
{code:java}
@Reference
private ResourceResolverFactory factory;
{code}

it fails because multiple references exist (i'm not sure if this is 100% 
correct in the osgi-mock, need to look up the DS spec).



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

[jira] [Closed] (SLING-5995) IdMapService should move to new ResourceChangeListener API

[Stefan Egli (JIRA)]

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

Stefan Egli closed SLING-5995.
--

> IdMapService should move to new ResourceChangeListener API
> --
>
> Key: SLING-5995
> URL: https://issues.apache.org/jira/browse/SLING-5995
> Project: Sling
>  Issue Type: Task
>  Components: Extensions
>Affects Versions: Discovery Commons 1.0.12, Discovery Oak 1.2.10
>Reporter: Hanish Bansal
>Assignee: Stefan Egli
> Fix For: Discovery Oak 1.2.14, Discovery Commons 1.0.16
>
>
> org.apache.sling.discovery.commons.providers.spi.base.IdMapService currently 
> implements org.osgi.service.event.EventHandler Interface. We should start 
> using the new ResourceChangeListener API.
> See [0] for details :
> https://issues.apache.org/jira/browse/SLING-5994



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

[jira] [Closed] (SLING-6065) in discovery: avoid OakViewChecker issueHeartbeat: discoveryService is null

[Stefan Egli (JIRA)]

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

Stefan Egli closed SLING-6065.
--

> in discovery: avoid OakViewChecker issueHeartbeat: discoveryService is null
> ---
>
> Key: SLING-6065
> URL: https://issues.apache.org/jira/browse/SLING-6065
> Project: Sling
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: Discovery Oak 1.2.10
>Reporter: Stefan Egli
>Assignee: Stefan Egli
> Fix For: Discovery Oak 1.2.14
>
>
> At startup the following log line sometimes appears:
> {noformat}
> 21.09.2016 16:05:08.594 *ERROR* [FelixStartLevel] 
> org.apache.sling.discovery.oak.pinger.OakViewChecker issueHeartbeat: 
> discoveryService is null
> {noformat}



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

[jira] [Closed] (SLING-5709) OakViewChecker#updateProperties() issueHeartbeat: discoveryService is null

[Stefan Egli (JIRA)]

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

Stefan Egli closed SLING-5709.
--

> OakViewChecker#updateProperties() issueHeartbeat: discoveryService is null
> --
>
> Key: SLING-5709
> URL: https://issues.apache.org/jira/browse/SLING-5709
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Base 1.1.2, Discovery Oak 1.2.6
> Environment: Karaf 4.0.5
>Reporter: Oliver Lietz
>Assignee: Stefan Egli
> Fix For: Discovery Oak 1.2.14
>
>
> {noformat}
> 2016-05-03 08:12:21,647 | ERROR | odeStoreService) | OakViewChecker   
> | issueHeartbeat: discoveryService is null
> {noformat}
> * {{org.apache.sling.discovery.base/1.1.3-SNAPSHOT}}
> * {{org.apache.sling.discovery.oak/1.2.7-SNAPSHOT}}



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

[jira] [Closed] (SLING-6055) Discovery: Use test scope for sling-mock dependency

[Stefan Egli (JIRA)]

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

Stefan Egli closed SLING-6055.
--

> Discovery: Use test scope for sling-mock dependency
> ---
>
> Key: SLING-6055
> URL: https://issues.apache.org/jira/browse/SLING-6055
> Project: Sling
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: Discovery Impl 1.2.8, Discovery Oak 1.2.10
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
>Priority: Minor
> Fix For: Discovery Impl 1.2.10, Discovery Oak 1.2.14
>
>
> currently the projects
> * {{org.apache.sling.discovery.impl}}
> * {{org.apache.sling.discovery.oak}}
> include sling-mock oak with "compile" dependency. this should be "test" 
> dependency.



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

Sling tracer doesn't record for Sling requests?

[Bertrand Delacretaz]

Hi (Chetan mostly I suppose),

I played with the Sling Tracer snapshot installed in the current trunk
launchpad, and it looks like the requests that hit the
SlingMainServlet are not recorded, am I doing something wrong?

In the example below, the second response doesn't have a
Sling-Tracer-Request-Id header.

-Bertrand

$ curl -u admin:admin -D - -H "Sling-Tracer-Record:true"
"http://localhost:8080/system/console?trace=oak-writes;
HTTP/1.1 302 Found
Date: Thu, 29 Sep 2016 14:49:15 GMT
Sling-Tracer-Request-Id: f5de031a-093a-4803-a8ce-630fdb63e554
Sling-Tracer-Protocol-Version: 1
Location: http://localhost:8080/system/console/bundles
Content-Length: 0

$ curl -u admin:admin -D - -H "Sling-Tracer-Record:true"
"http://localhost:8080/.json?trace=oak-writes;
HTTP/1.1 200 OK
Date: Thu, 29 Sep 2016 14:49:18 GMT
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Type: application/json;charset=utf-8
Content-Length: 141

{"jcr:primaryType":"rep:root","jcr:mixinTypes...

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

[Stefan Egli]

The vote passed with 3 binding votes, thx for voting!
I'll do the same procedure as every time and push the releases.
Cheers,
Stefan

On 26/09/16 12:08, "Stefan Egli"  wrote:

>Hi,
>
>We solved 4 issues in these 2 related releases:
>
>https://issues.apache.org/jira/browse/SLING/fixforversion/12338296
>https://issues.apache.org/jira/browse/SLING/fixforversion/12338297
>
>Staging repository:
>https://repository.apache.org/content/repositories/orgapachesling-1526
>
>You can use this UNIX script to download the release and verify the
>signatures:
>http://svn.apache.org/repos/asf/sling/trunk/check_staged_release.sh
>
>Usage:
>sh check_staged_release.sh 1526 /tmp/sling-staging
>
>Please vote to approve this release:
>
>  [ ] +1 Approve the release
>  [ ]  0 Don't care
>  [ ] -1 Don't release, because ...
>
>This majority vote is open for at least 72 hours.
>
>Cheers,
>Stefan
>
>

[jira] [Resolved] (SLING-6076) Add Maven repository apache-snapshots to base configuration

[Oliver Lietz (JIRA)]

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

Oliver Lietz resolved SLING-6076.
-
Resolution: Done

[r1762782|https://svn.apache.org/r1762782] Thanks, [~rombert]!

> Add Maven repository apache-snapshots to base configuration
> ---
>
> Key: SLING-6076
> URL: https://issues.apache.org/jira/browse/SLING-6076
> Project: Sling
>  Issue Type: Improvement
>  Components: Testing
>Affects Versions: Testing PaxExam 0.0.2
>Reporter: Oliver Lietz
>Assignee: Oliver Lietz
>Priority: Minor
> Fix For: Testing PaxExam 0.0.4
>
>




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

[jira] [Created] (SLING-6076) Add Maven repository apache-snapshots to base configuration

[Oliver Lietz (JIRA)]

Oliver Lietz created SLING-6076:
---

 Summary: Add Maven repository apache-snapshots to base 
configuration
 Key: SLING-6076
 URL: https://issues.apache.org/jira/browse/SLING-6076
 Project: Sling
  Issue Type: Improvement
  Components: Testing
Affects Versions: Testing PaxExam 0.0.2
Reporter: Oliver Lietz
Assignee: Oliver Lietz
Priority: Minor
 Fix For: Testing PaxExam 0.0.4






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

[jira] [Resolved] (SLING-6074) Healthcheck ITs fail in isolated job on Jenkins

[Robert Munteanu (JIRA)]

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

Robert Munteanu resolved SLING-6074.

Resolution: Fixed

[~bdelacretaz] - that did it, thanks!

[~olli] - you might want to pick up that change in the pax-exam supporting 
module as well.

https://svn.apache.org/r1762778

> Healthcheck ITs fail in isolated job on Jenkins
> ---
>
> Key: SLING-6074
> URL: https://issues.apache.org/jira/browse/SLING-6074
> Project: Sling
>  Issue Type: Bug
>  Components: Health Check
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>
> Since moving to per-module builds in the ASF Jenkins instance the health 
> check ITs fail, both for Java 7 and Java 8.
> As far as I what happens is:
> - the ITs reference SNAPSHOT versions of the HC bundles
> - these snapshots are referenced from Pax-Exam tests
> - Pax-Exam tries to reference them using the default Maven settings ( 
> ~/.m2/respository and Maven Central ).
> But since the snapshots are deployed on repository.apache.org this does not 
> work. This used to work when using reactor builds since the dependencies 
> would be installed locally.
> The concrete error message is
> {noformat}1240 [main] WARN org.ops4j.pax.url.mvn.internal.AetherBasedResolver 
> - Error resolving 
> artifactorg.apache.sling:org.apache.sling.hc.samples:jar:1.0.7-SNAPSHOT:Could 
> not find artifact 
> org.apache.sling:org.apache.sling.hc.samples:jar:1.0.7-SNAPSHOT in central 
> (http://repo1.maven.org/maven2/)
> org.sonatype.aether.resolution.ArtifactResolutionException: Could not find 
> artifact org.apache.sling:org.apache.sling.hc.samples:jar:1.0.7-SNAPSHOT in 
> central (http://repo1.maven.org/maven2/){noformat}
> One possible way out is to modify the pax-exam tests to take into account 
> repository.apache.org.
> [~bdelacretaz], [~olli] as you know HC and respectively Pax-Exam better, how 
> do you suggest we approach this?



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

[jira] [Assigned] (SLING-6074) Healthcheck ITs fail in isolated job on Jenkins

[Robert Munteanu (JIRA)]

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

Robert Munteanu reassigned SLING-6074:
--

Assignee: Robert Munteanu

> Healthcheck ITs fail in isolated job on Jenkins
> ---
>
> Key: SLING-6074
> URL: https://issues.apache.org/jira/browse/SLING-6074
> Project: Sling
>  Issue Type: Bug
>  Components: Health Check
>Reporter: Robert Munteanu
>Assignee: Robert Munteanu
>
> Since moving to per-module builds in the ASF Jenkins instance the health 
> check ITs fail, both for Java 7 and Java 8.
> As far as I what happens is:
> - the ITs reference SNAPSHOT versions of the HC bundles
> - these snapshots are referenced from Pax-Exam tests
> - Pax-Exam tries to reference them using the default Maven settings ( 
> ~/.m2/respository and Maven Central ).
> But since the snapshots are deployed on repository.apache.org this does not 
> work. This used to work when using reactor builds since the dependencies 
> would be installed locally.
> The concrete error message is
> {noformat}1240 [main] WARN org.ops4j.pax.url.mvn.internal.AetherBasedResolver 
> - Error resolving 
> artifactorg.apache.sling:org.apache.sling.hc.samples:jar:1.0.7-SNAPSHOT:Could 
> not find artifact 
> org.apache.sling:org.apache.sling.hc.samples:jar:1.0.7-SNAPSHOT in central 
> (http://repo1.maven.org/maven2/)
> org.sonatype.aether.resolution.ArtifactResolutionException: Could not find 
> artifact org.apache.sling:org.apache.sling.hc.samples:jar:1.0.7-SNAPSHOT in 
> central (http://repo1.maven.org/maven2/){noformat}
> One possible way out is to modify the pax-exam tests to take into account 
> repository.apache.org.
> [~bdelacretaz], [~olli] as you know HC and respectively Pax-Exam better, how 
> do you suggest we approach this?



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

Re: sling ci builds per module

[Oliver Lietz]

On Thursday 29 September 2016 11:56:13 Robert Munteanu wrote:
> Hi,
> 
> (@Stefan - thanks for summing up what we discussed and following up on
> the dev list)

+1 indeed, much appreciated (also all the work done for and at adaptTo())!

> This is mostly done for the 'main' build, I'm still ironing out some
> dependency issues between jobs(1) but should be stable.
> 
> I'll disable the sling-trunk-1.8 job and see how well this setup runs
> for a couple of days and then move on the contrib and sample trees.
> 
> Olli, AFAICT the karaf part does not have a Jenkins build set up ATM.

Right. I moved it out of contrib next to launchpad.

> Do you want me to set per-module build jobs for the Karaf build as
> well?

Yes, please. Didn't look into build job before holidays because of used 
bundles under vote (in features).

Thanks, Robert!

O.

> On Wed, 2016-09-28 at 22:52 +, Stefan Seifert wrote:
> > discussed at the Sling Committer Round Table @ adaptTo() 2016
> > 
> > we all agreed that we need CI build individually per module/bundle,
> > not a big build for all bundles at once.
> > 
> > benefits:
> > - much faster feedback in case of a broken build, and much more
> > specific
> > - if one module is broken only it's own CI build is affected, all
> > other are still green
> > - CI build for one module is much faster, leading to much shorter
> > debugging cycles in case of problems
> > - it's much easier to use tools like travis without having to work
> > around build time and log output size limitations
> > 
> > alternatives discussed:
> > - we were very unhappy with the apache Jenkins lately, but the reason
> > may be that the single full CI build was just too big and fragile
> > - travis would be a simple option to use esp. when sling is migrated
> > to git and we have one single git repo per module. bertrand pointed
> > out there is an official support from ASF to use travis.
> > - we could ask infra to support us with our own jenkins instance we
> > maintain ourselves. but we do not want to go this way due to its
> > maintance efforts unless there is no other way.
> > - we decided to stick with the ASF Jenkins for now, and got the way
> > to CI builds for each module which robert has already started in
> > SLING-6061
> > 
> > robert currently uses the jenkins job DSL plugin to auto-generate new
> > jobs and update existing jobs to the current job definition. the
> > source script and job definition template is maintained in svn, as
> > soon as this is changed all auto-generated jobs get updated. and
> > alternative would be to use the Jenkins pipeline plugin, but
> > currently we think creating individual jobs is easier for us to
> > understand and maintain.
> > 
> > some requirements for the ci build ans integration:
> > 
> > - it would be nice to have a CI build notification within the github
> > mirrors of the git modules showing red/green status on each commit
> > (which is available e.g. for travis - is it possible with the ASF
> > Jenkins as well?)
> 
> This is a bit linked to the Github migration, but the build status
> plugin is enabled for the ASF jenkins instance, so we can reference it.
> 
> We would still need to auto-generate a README file for each modules
> referencing the active build jobs.
> 
> > - if new branches are created or PRs are submitted a CI build should
> > run for them as well, reporting it's status in the github views
> 
> This is doable once we move to Github with the current setup.
> 
> Once thing I haven't fully figured out yet is show to test such a setup
> including the Sling Launchpad tests ( which would be nice ).
> 
> The pipeline approach might be better suited here, but let's see once
> we move to git. The benefit of using the dsl plugin is that I can
> change the job type (losing job history though ).
> 
> > - the CI build should run for the supported JDKs for each module,
> > e.g. java7+java8 or java8-only
> 
> This is already solved in the current setup.
> 
> > - from the git project it the Jenkins CI job should be easy found. if
> > a common naming scheme for the Jenkins jobs is used which e.g.
> > include the git repo name this should be easy.
> 
> Yes, definitely doable.
> 
> > - each CI job has to deploy the current module's snapshot to the
> > apache maven snapshot repo, to make it available to other builds.
> 
> Solved in the current setup, and if we have multiple jobs for various
> JDK versions only the one with the lowest JDK version is deployed, for
> maximum compatibility.
> 
> Thanks,
> 
> Robert
> 
> 1 - the dependencies are mostly inferred automatically by the maven
> plugin supplied by Jenkins, but at the moment it's not able to detect
> when a module is referenced in a launchpad via the provisioning module.
> I will establish module → launchpad dependencies manually for now, with
> a wide approach of 'modules in bundles/ and installer/ will trigger an
> org.apache.sling.launchpad build' . We'll see if we need something more
> fine-grained.

Re: Resource packaging/content packaging in Sling

[Robert Munteanu]

On Wed, 2016-09-28 at 21:49 +, Stefan Seifert wrote:
> wcm.io also has a content package plugin [4] which already replaces
> parts oft he adobe content package maven plugin (upload/download
> package part), but not yet the part building the ZIP package from the
> VLT file layout. it could be contributed to sling easily.

As a side note, I found that the way the Adobe content-package-maven-
plugin configures resources to be included in content package is quite
cumbersome:

- overriding resource directories
- manually exclude .vlt files
- requires maven-resources-plugin extra execution to copy META-
INF/vault

We should provide a much simpler out-of-the box experience.

Robert

Re: sling ci builds per module

[Robert Munteanu]

Hi,

(@Stefan - thanks for summing up what we discussed and following up on
the dev list)

This is mostly done for the 'main' build, I'm still ironing out some
dependency issues between jobs(1) but should be stable.

I'll disable the sling-trunk-1.8 job and see how well this setup runs
for a couple of days and then move on the contrib and sample trees.

Olli, AFAICT the karaf part does not have a Jenkins build set up ATM.
Do you want me to set per-module build jobs for the Karaf build as
well?

On Wed, 2016-09-28 at 22:52 +, Stefan Seifert wrote:
> discussed at the Sling Committer Round Table @ adaptTo() 2016
> 
> we all agreed that we need CI build individually per module/bundle,
> not a big build for all bundles at once.
> 
> benefits:
> - much faster feedback in case of a broken build, and much more
> specific
> - if one module is broken only it's own CI build is affected, all
> other are still green
> - CI build for one module is much faster, leading to much shorter
> debugging cycles in case of problems
> - it's much easier to use tools like travis without having to work
> around build time and log output size limitations
> 
> alternatives discussed:
> - we were very unhappy with the apache Jenkins lately, but the reason
> may be that the single full CI build was just too big and fragile
> - travis would be a simple option to use esp. when sling is migrated
> to git and we have one single git repo per module. bertrand pointed
> out there is an official support from ASF to use travis.
> - we could ask infra to support us with our own jenkins instance we
> maintain ourselves. but we do not want to go this way due to its
> maintance efforts unless there is no other way.
> - we decided to stick with the ASF Jenkins for now, and got the way
> to CI builds for each module which robert has already started in
> SLING-6061
> 
> robert currently uses the jenkins job DSL plugin to auto-generate new
> jobs and update existing jobs to the current job definition. the
> source script and job definition template is maintained in svn, as
> soon as this is changed all auto-generated jobs get updated. and
> alternative would be to use the Jenkins pipeline plugin, but
> currently we think creating individual jobs is easier for us to
> understand and maintain.
> 
> some requirements for the ci build ans integration:
> 
> - it would be nice to have a CI build notification within the github
> mirrors of the git modules showing red/green status on each commit
> (which is available e.g. for travis - is it possible with the ASF
> Jenkins as well?)

This is a bit linked to the Github migration, but the build status
plugin is enabled for the ASF jenkins instance, so we can reference it.

We would still need to auto-generate a README file for each modules
referencing the active build jobs.

> 
> - if new branches are created or PRs are submitted a CI build should
> run for them as well, reporting it's status in the github views

This is doable once we move to Github with the current setup.

Once thing I haven't fully figured out yet is show to test such a setup
including the Sling Launchpad tests ( which would be nice ).

The pipeline approach might be better suited here, but let's see once
we move to git. The benefit of using the dsl plugin is that I can
change the job type (losing job history though ).

> 
> - the CI build should run for the supported JDKs for each module,
> e.g. java7+java8 or java8-only

This is already solved in the current setup.

> 
> - from the git project it the Jenkins CI job should be easy found. if
> a common naming scheme for the Jenkins jobs is used which e.g.
> include the git repo name this should be easy.

Yes, definitely doable.

> 
> - each CI job has to deploy the current module's snapshot to the
> apache maven snapshot repo, to make it available to other builds.

Solved in the current setup, and if we have multiple jobs for various
JDK versions only the one with the lowest JDK version is deployed, for
maximum compatibility.

Thanks,

Robert

1 - the dependencies are mostly inferred automatically by the maven
plugin supplied by Jenkins, but at the moment it's not able to detect
when a module is referenced in a launchpad via the provisioning module.
I will establish module → launchpad dependencies manually for now, with
a wide approach of 'modules in bundles/ and installer/ will trigger an
org.apache.sling.launchpad build' . We'll see if we need something more
fine-grained.

removal of it-jackrabbit-oak

[Oliver Lietz]

Hi all,

since we do no longer support Jackrabbit (2 and use Oak instead) and the ITs 
for Oak are in the oak-server module itself now, there is no need for it-
jackrabbit-oak anymore. I will remove the module in the next days if no one 
objects.

Regards,
O.

[jira] [Created] (SLING-6075) Update Thymeleaf to 3.0.2

[Oliver Lietz (JIRA)]

Oliver Lietz created SLING-6075:
---

 Summary: Update Thymeleaf to 3.0.2
 Key: SLING-6075
 URL: https://issues.apache.org/jira/browse/SLING-6075
 Project: Sling
  Issue Type: Improvement
  Components: Scripting
Affects Versions: Scripting Thymeleaf 1.0.0
Reporter: Oliver Lietz
Assignee: Oliver Lietz
 Fix For: Scripting Thymeleaf 1.0.2


http://forum.thymeleaf.org/Thymeleaf-3-0-2-JUST-PUBLISHED-td4029985.html



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

Re: moving sling to git

[Ian Boston]

Hi,


On 29 September 2016 at 10:06, Oliver Lietz  wrote:

> On Thursday 29 September 2016 09:27:30 Ian Boston wrote:
> > Hi,
> > I fully support moving to Git.
> >
> > I think it would be a mistake to attempt to split the repository into
> 100s
> > of separate Git repositories as it will make it near impossible for any
> > outsider to work on the code base. I say that from a position of
> > experiencing exactly the same style of re-organisation on a large code
> base
> > with a similar number of modules. Finding the root cause of a problem
> takes
> > an order of magnitude more time, and if a pull request has to be applied
> to
> > several repositories at the same time, good luck. IIUC those that work on
> > all of the code base on a daily basis, have no problem.
> >
> > Quite apart from the infra issues.
> >
> > Do it with 1 repo, under the ASF banner, not in a independent GitHub
> > organisation.
> >
> > It sounds like this was a long and complex offline discussion.
>
> Quoting Stefan: "we discussed again the long-debate topic moving from svn
> to
> git."
>
> > I do hope a
> > decisions of this magnitude was not made, at that time, excluding those
> > members of the community, committers, PMC and ASF Members who were not
> able
> > to attend the adaptTo conference.
>
> https://issues.apache.org/jira/browse/SLING-3987
> https://cwiki.apache.org/confluence/display/SLING/Move+
> from+Subversion+to+Git



Thank you for the pointers

I had searched the archives with [1] but only found [2], hence my concern
that Sling had reverted to offline decision making, given the activity
landing in my inbox from adaptTo.

My concern was unfounded. There has been discussion online and the decision
has been made.
I missed it all due to other commitments.
Ignore my comments on the detail.

Best Regards
Ian

1
http://markmail.org/search/?q=sling-dev+list%3Aorg.apache.incubator.sling-dev+github+-from%3A%22jira%40apache.org%22+-from%3A%22*%40git.apache.org%22#query:sling-dev%20list%3Aorg.apache.incubator.sling-dev%20github%20-from%3Ajira%40apache.org%20-from%3A*%40git.apache.org%20order%3Adate-backward+page:1+state:facets
2 http://markmail.org/thread/u32gblzpjairkc3a


>
>
> Regards,
> O.
>
> > Best Regards
> > Ian
> >
> > On 28 September 2016 at 23:34, Stefan Seifert 
> >
> > wrote:
> > > discussed at the Sling Committer Round Table @ adaptTo() 2016
> > >
> > > we discussed again the long-debate topic moving from svn to git. no
> > > commiter hat and objection that moving to git creates a real problem.
> all
> > > agreed it would be nice to move to git.
> > >
> > > aspects that where discussed:
> > >
> > > - every module should get it's own git project
> > >
> > >   - including special cases where a module is only a integration test
> > >
> > > project
> > >
> > >   - this ensures thare is only one "releaseable" artefact per git
> > >
> > > repository
> > >
> > >   - and git branching/tagging works as expected
> > >   - most sling modules are quite independent anyway
> > >
> > > - we need a replacement for the reactor poms
> > >
> > >   - to build groups of related projects, e.g. sling distribution, sling
> > >
> > > models, testing mocks etc.
> > >
> > >   - and to build all sling sources together
> > >   - goal is to have an additional git project for each reactor
> > >
> > > pom/suitable grouping of git projects
> > >
> > >   - as multi repo tooling support e.g. google repo [1] or gitslave [2]
> > >
> > > could be used
> > >
> > >   - which solution is chosen is not important for the first step and
> the
> > >
> > > initial migration - we can solve this late, it's mainly for convenience
> > >
> > > - this apporach results in a HUGE number of git repos - perhaps 300-350
> > > including reactor poms
> > >
> > >   - because sling is so modular, and has so many bundles already
> > >
> > > - in the apache github mirror there is only one organization "apache"
> > >
> > >   - all 350 sling projects would be part of this main organization,
> > >
> > > together with all other apache git projects that are already listed
> there
> > >
> > >   - other projects like commons, cordova, couchdb are examples haven
> > >
> > > already a lot of individual git repos
> > >
> > >   - asf currently does not allow apache projects to create their own
> > >
> > > github organizsation, mainly due to infra restrictions
> > >
> > > - name pattern for the git repository should be something like
> > > "sling-"
> > >
> > >   - we drop the folder grouping from svn today in "extensions",
> > >
> > > "servlets", "commons" etc. only the hierarchy of artifactId is
> relevant.
> > >
> > >   - with the prefix "sling-" they
> > >   - question: how are "contrib" and "samples" repos marked? by another
> > >
> > > prefix like "sling-contrib-" and "sling-samples"?
> > >
> > > - no "self-service" for creating git repos
> > >
> > >   - a big problem ist hat asf infra currently does not provide a
> > >
> > > 

Re: moving sling to git

[Oliver Lietz]

On Thursday 29 September 2016 09:27:30 Ian Boston wrote:
> Hi,
> I fully support moving to Git.
> 
> I think it would be a mistake to attempt to split the repository into 100s
> of separate Git repositories as it will make it near impossible for any
> outsider to work on the code base. I say that from a position of
> experiencing exactly the same style of re-organisation on a large code base
> with a similar number of modules. Finding the root cause of a problem takes
> an order of magnitude more time, and if a pull request has to be applied to
> several repositories at the same time, good luck. IIUC those that work on
> all of the code base on a daily basis, have no problem.
> 
> Quite apart from the infra issues.
> 
> Do it with 1 repo, under the ASF banner, not in a independent GitHub
> organisation.
> 
> It sounds like this was a long and complex offline discussion.

Quoting Stefan: "we discussed again the long-debate topic moving from svn to 
git."

> I do hope a
> decisions of this magnitude was not made, at that time, excluding those
> members of the community, committers, PMC and ASF Members who were not able
> to attend the adaptTo conference.

https://issues.apache.org/jira/browse/SLING-3987
https://cwiki.apache.org/confluence/display/SLING/Move+from+Subversion+to+Git

Regards,
O.
 
> Best Regards
> Ian
> 
> On 28 September 2016 at 23:34, Stefan Seifert 
> 
> wrote:
> > discussed at the Sling Committer Round Table @ adaptTo() 2016
> > 
> > we discussed again the long-debate topic moving from svn to git. no
> > commiter hat and objection that moving to git creates a real problem. all
> > agreed it would be nice to move to git.
> > 
> > aspects that where discussed:
> > 
> > - every module should get it's own git project
> > 
> >   - including special cases where a module is only a integration test
> > 
> > project
> > 
> >   - this ensures thare is only one "releaseable" artefact per git
> > 
> > repository
> > 
> >   - and git branching/tagging works as expected
> >   - most sling modules are quite independent anyway
> > 
> > - we need a replacement for the reactor poms
> > 
> >   - to build groups of related projects, e.g. sling distribution, sling
> > 
> > models, testing mocks etc.
> > 
> >   - and to build all sling sources together
> >   - goal is to have an additional git project for each reactor
> > 
> > pom/suitable grouping of git projects
> > 
> >   - as multi repo tooling support e.g. google repo [1] or gitslave [2]
> > 
> > could be used
> > 
> >   - which solution is chosen is not important for the first step and the
> > 
> > initial migration - we can solve this late, it's mainly for convenience
> > 
> > - this apporach results in a HUGE number of git repos - perhaps 300-350
> > including reactor poms
> > 
> >   - because sling is so modular, and has so many bundles already
> > 
> > - in the apache github mirror there is only one organization "apache"
> > 
> >   - all 350 sling projects would be part of this main organization,
> > 
> > together with all other apache git projects that are already listed there
> > 
> >   - other projects like commons, cordova, couchdb are examples haven
> > 
> > already a lot of individual git repos
> > 
> >   - asf currently does not allow apache projects to create their own
> > 
> > github organizsation, mainly due to infra restrictions
> > 
> > - name pattern for the git repository should be something like
> > "sling-"
> > 
> >   - we drop the folder grouping from svn today in "extensions",
> > 
> > "servlets", "commons" etc. only the hierarchy of artifactId is relevant.
> > 
> >   - with the prefix "sling-" they
> >   - question: how are "contrib" and "samples" repos marked? by another
> > 
> > prefix like "sling-contrib-" and "sling-samples"?
> > 
> > - no "self-service" for creating git repos
> > 
> >   - a big problem ist hat asf infra currently does not provide a
> > 
> > "self-service" for creating new asf git projects
> > 
> >   - whenever a new sling module is created a ticket a INFRA is needed to
> > 
> > create it, process is blocked until the involved manual steps are
> > completed
> > 
> >   - perhaps we can talk to infra providing a better solution here,
> > 
> > pointing at the 350 git repos we already need only for the start
> > 
> >   - if this is not solved just creating a new project/module is more
> > 
> > complicated than required
> > 
> > - only one git repo for contrib and samples?
> > 
> >   - we briefly discussed to use only one big repo for contrib and samples
> > 
> > as a workaround fort the "no self-service" problem, it would then be easy
> > to create new modules at least there
> > 
> >   - but this is perhaps not a good solution, because it again creates all
> > 
> > problems that arise when multiple releasible artifacts are put together in
> > one git repo
> > 
> >   - and it would make it harder to move something from contrib to "full
> > 
> > supported"
> > 
> > - committer whiteboards
> > 

RE: Sling Committer Round Table @ adaptTo() 2016

[Stefan Seifert]

general note about my topic notes which i posted as separate mail threads:

in some places i've used the word "decided" which is formally not correct as no 
official vote in this list was taken and only a subset of PMC members was 
present. so read it as "proposal on which all attendees thought it was a good 
idea".

and i forgot to mention the participants (sling comitter and others):
Konrad Windszus, Georg Henzler, Robert Munteanu, Bertrand Delacretaz, Dominik 
Süß, Nicolas Peltier, Chetan Mehrotra, Carsten Ziegeler, Stefan Seifert, Oliver 
Lietz, Michael Dürig (partially).

stefan


>-Original Message-
>From: Stefan Seifert [mailto:sseif...@pro-vision.de]
>Sent: Wednesday, September 28, 2016 11:14 PM
>To: dev@sling.apache.org
>Subject: Sling Committer Round Table @ adaptTo() 2016
>
>yesterday we the "Sling Committer Round Table" took place at the adaptTo()
>2016 conference, and it was a very nice meeting [1].
>
>i took notes about the topics we discussed and will open a separate mail
>thread for each topic.
>
>one of the topics was: more frequent face-to-face meetings (more than only
>once a year here in berlin). the general opinion on this is positive, rooms
>are available as well e.g. in essen, berlin or basel. so we just need to do
>it!
>
>stefan
>
>[1] https://adapt.to/2016/en/conference/gallery/sling-committer-round-
>table.html
>
>

Re: moving sling to git

[Oliver Lietz]

On Wednesday 28 September 2016 22:34:48 Stefan Seifert wrote:
> discussed at the Sling Committer Round Table @ adaptTo() 2016
> 
> we discussed again the long-debate topic moving from svn to git. no commiter
> hat and objection that moving to git creates a real problem. all agreed it
> would be nice to move to git.
> 
> aspects that where discussed:
> 
> - every module should get it's own git project
>   - including special cases where a module is only a integration test
> project - this ensures thare is only one "releaseable" artefact per git
> repository - and git branching/tagging works as expected
>   - most sling modules are quite independent anyway
> 
> - we need a replacement for the reactor poms
>   - to build groups of related projects, e.g. sling distribution, sling
> models, testing mocks etc. - and to build all sling sources together
>   - goal is to have an additional git project for each reactor pom/suitable
> grouping of git projects - as multi repo tooling support e.g. google repo
> [1] or gitslave [2] could be used - which solution is chosen is not
> important for the first step and the initial migration - we can solve this
> late, it's mainly for convenience
> 
> - this apporach results in a HUGE number of git repos - perhaps 300-350
> including reactor poms - because sling is so modular, and has so many
> bundles already
> 
> - in the apache github mirror there is only one organization "apache"
>   - all 350 sling projects would be part of this main organization, together
> with all other apache git projects that are already listed there - other
> projects like commons, cordova, couchdb are examples haven already a lot of
> individual git repos - asf currently does not allow apache projects to
> create their own github organizsation, mainly due to infra restrictions
> 
> - name pattern for the git repository should be something like
> "sling-" - we drop the folder grouping from svn today in
> "extensions", "servlets", "commons" etc. only the hierarchy of artifactId
> is relevant. - with the prefix "sling-" they
>   - question: how are "contrib" and "samples" repos marked? by another
> prefix like "sling-contrib-" and "sling-samples"?
> 
> - no "self-service" for creating git repos
>   - a big problem ist hat asf infra currently does not provide a
> "self-service" for creating new asf git projects - whenever a new sling
> module is created a ticket a INFRA is needed to create it, process is
> blocked until the involved manual steps are completed - perhaps we can talk
> to infra providing a better solution here, pointing at the 350 git repos we
> already need only for the start - if this is not solved just creating a new
> project/module is more complicated than required
> 
> - only one git repo for contrib and samples?
>   - we briefly discussed to use only one big repo for contrib and samples as
> a workaround fort the "no self-service" problem, it would then be easy to
> create new modules at least there - but this is perhaps not a good
> solution, because it again creates all problems that arise when multiple
> releasible artifacts are put together in one git repo - and it would make
> it harder to move something from contrib to "full supported"

I really prefer the simple rule "one module : one repo".

You should be able to start new modules/repos anywhere and later make them an 
official ASF/Sling master repo.

> - committer whiteboards
>   - we also need a solution for the comitter whiteboards
>   - they should be cleaned up before migration leaving only what is still
> relevant

Per committer whiteboards can easily moved to personal repos on GitHub, 
Bitbucket or whatever.

> - migration process
>   - the migration process has to be fully scripted, and tested several time
> in a "lab environment" - we should avoid migration approached that need
> restructuring the svn hierarchy before migration (e.g. "flat list of all
> modules"), because this make impact the migration of svn history to the
> individual git repos - we may need to write our own migration script
> handling the specifics of the current svn folder structure and creating the
> full list of individual git repos locally from it (first migrate to a
> single git repo and then splitting it up preserving history for each
> modules folder). those local created git repos can then be pushed to the
> individual asf git repos.
> 
> - contact infra
>   - before we take further steps we should ask infra for it's opinion
>   - e.g. by creating a jira ticket and describing the planned steps, and
> that this would result in a huge number of repos

https://issues.apache.org/jira/browse/SLING-3987
https://cwiki.apache.org/confluence/display/SLING/Move+from+Subversion+to+Git

Regards,
O.

> stefan
> 
> [1] https://code.google.com/p/git-repo/
> [2] http://gitslave.sourceforge.net/

[jira] [Commented] (SLING-6070) Reduce temporary storage required in JcrResourceListener, call reportChanges earlier

[Stefan Egli (JIRA)]

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

Stefan Egli commented on SLING-6070:


See 
[sub-discussion|https://issues.apache.org/jira/browse/OAK-4581?focusedCommentId=15522741=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15522741]
 in length ticket OAK-4581 which suggests to get rid of the OakResourceListener 
but pointed at reasons for its introduction, which included the high memory 
consumption which SLING-6070 is trying to get rid of.

> Reduce temporary storage required in JcrResourceListener, call reportChanges 
> earlier
> 
>
> Key: SLING-6070
> URL: https://issues.apache.org/jira/browse/SLING-6070
> Project: Sling
>  Issue Type: Improvement
>  Components: JCR
>Affects Versions: JCR Resource 2.8.0
>Reporter: Stefan Egli
> Fix For: JCR Resource 2.8.2
>
>
> As noticed in OAK-4581 
> ([here|https://issues.apache.org/jira/browse/OAK-4581?focusedCommentId=15525601=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15525601])
>  one advantage of using OakResourceListener over JcrResourceListener (hence 
> the term 'optimize for oak' of the config parameter) is that 
> OakResourceListener uses a NodeObserver, which calls added/removed/changed 
> after each child traversal has finished. This will in turn be used by the 
> OakResourceListener to call ObservationReporter.reportChanges. In the 
> JcrResourceListener.onEvent case however this is not possible, as the events 
> are delivered for each node/property individually, and they first have to be 
> 'mapped' to ResourceChanges. This is currently done by keeping maps of 
> added/removed/changed ResourceChanges and only after all events (that are 
> passed in 1 onEvent) are processed is reportChanges invoked. This has the 
> downside of a potentially very large temporary memory usage (these maps can 
> get big).
> A suggested improvement is to follow the same pattern as is done in the 
> OakResourceListener/NodeObserver pair: to forward the events (by callling 
> reportChanges) as early as possible. Since Oak uses a breadth-first tree 
> traversal when compiling the jcr events, this fact can be used to detect the 
> earliest possible moment to forward events, which is as soon as a child 
> traversal has finished. That way, only parent changes need to be kept, not 
> the entire tree of changes.



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

Re: Replace sling launchpad with karaf?

[Ian Boston]

Hi,
Did you discuss Crankstart provisioning models ?
They appear to extremely powerful way of defining many configurations,
storing them in SVN and running them without depending on some other
launchpad. The MoM integration tests under contrib use a provisioning model
to define a minimalist OSGi container.
I was under the impression that the Sling launchpad did many custom things,
not present in a generic OSGi container bootstrap.
Best Regards
Ian

On 28 September 2016 at 22:39, Stefan Seifert 
wrote:

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

Re: Integration tests near to modules

[Oliver Lietz]

On Thursday 29 September 2016 09:16:36 Ian Boston wrote:
> Hi,
> It cant have been decided, as it wasn't, yet, discussed on-list.
> I don't have strong feelings about the subject of the "decision".
> Best Regards
> Ian

Hi Ian,

the topic was discussed already on list (and face-to-face) and there have been 
efforts in the last months to move ITs closer or even into the modules itself 
at several places – and I don't think we need a formal decision here, so:

s/decided/underlined/g

Regards,
O.

> On 28 September 2016 at 23:06, Stefan Seifert 
> 
> wrote:
> > discussed at the Sling Committer Round Table @ adaptTo() 2016
> > 
> > in sling there is a big integration test project that tests the core sling
> > functionality and the different sling bundles playing together. a problem
> > with this apporach ist hat different aspects are mixed in one project, and
> > if a new module is released it may be required to release the integration
> > test project as well.
> > 
> > a goal would be to move most of module-specific integration tests "near to
> > the module" or just in the module project itself, using one oft the
> > numerous available integration test tool support available in sling today.
> > this is already the case for several new and complex modules.
> > 
> > it was decided that no new integration tests should be added to this
> > central integration test project. exceptions are integration tests
> > covering
> > core sling functionality e.g. resource resolving, script resolution.
> > 
> > stefan
> > 
> > [1] https://svn.apache.org/repos/asf/sling/trunk/launchpad/
> > integration-tests

Re: moving sling to git

[Ian Boston]

Hi,
I fully support moving to Git.

I think it would be a mistake to attempt to split the repository into 100s
of separate Git repositories as it will make it near impossible for any
outsider to work on the code base. I say that from a position of
experiencing exactly the same style of re-organisation on a large code base
with a similar number of modules. Finding the root cause of a problem takes
an order of magnitude more time, and if a pull request has to be applied to
several repositories at the same time, good luck. IIUC those that work on
all of the code base on a daily basis, have no problem.

Quite apart from the infra issues.

Do it with 1 repo, under the ASF banner, not in a independent GitHub
organisation.

It sounds like this was a long and complex offline discussion. I do hope a
decisions of this magnitude was not made, at that time, excluding those
members of the community, committers, PMC and ASF Members who were not able
to attend the adaptTo conference.

Best Regards
Ian

On 28 September 2016 at 23:34, Stefan Seifert 
wrote:

> discussed at the Sling Committer Round Table @ adaptTo() 2016
>
> we discussed again the long-debate topic moving from svn to git. no
> commiter hat and objection that moving to git creates a real problem. all
> agreed it would be nice to move to git.
>
> aspects that where discussed:
>
> - every module should get it's own git project
>   - including special cases where a module is only a integration test
> project
>   - this ensures thare is only one "releaseable" artefact per git
> repository
>   - and git branching/tagging works as expected
>   - most sling modules are quite independent anyway
>
> - we need a replacement for the reactor poms
>   - to build groups of related projects, e.g. sling distribution, sling
> models, testing mocks etc.
>   - and to build all sling sources together
>   - goal is to have an additional git project for each reactor
> pom/suitable grouping of git projects
>   - as multi repo tooling support e.g. google repo [1] or gitslave [2]
> could be used
>   - which solution is chosen is not important for the first step and the
> initial migration - we can solve this late, it's mainly for convenience
>
> - this apporach results in a HUGE number of git repos - perhaps 300-350
> including reactor poms
>   - because sling is so modular, and has so many bundles already
>
> - in the apache github mirror there is only one organization "apache"
>   - all 350 sling projects would be part of this main organization,
> together with all other apache git projects that are already listed there
>   - other projects like commons, cordova, couchdb are examples haven
> already a lot of individual git repos
>   - asf currently does not allow apache projects to create their own
> github organizsation, mainly due to infra restrictions
>
> - name pattern for the git repository should be something like
> "sling-"
>   - we drop the folder grouping from svn today in "extensions",
> "servlets", "commons" etc. only the hierarchy of artifactId is relevant.
>   - with the prefix "sling-" they
>   - question: how are "contrib" and "samples" repos marked? by another
> prefix like "sling-contrib-" and "sling-samples"?
>
> - no "self-service" for creating git repos
>   - a big problem ist hat asf infra currently does not provide a
> "self-service" for creating new asf git projects
>   - whenever a new sling module is created a ticket a INFRA is needed to
> create it, process is blocked until the involved manual steps are completed
>   - perhaps we can talk to infra providing a better solution here,
> pointing at the 350 git repos we already need only for the start
>   - if this is not solved just creating a new project/module is more
> complicated than required
>
> - only one git repo for contrib and samples?
>   - we briefly discussed to use only one big repo for contrib and samples
> as a workaround fort the "no self-service" problem, it would then be easy
> to create new modules at least there
>   - but this is perhaps not a good solution, because it again creates all
> problems that arise when multiple releasible artifacts are put together in
> one git repo
>   - and it would make it harder to move something from contrib to "full
> supported"
>
> - committer whiteboards
>   - we also need a solution for the comitter whiteboards
>   - they should be cleaned up before migration leaving only what is still
> relevant
>
> - migration process
>   - the migration process has to be fully scripted, and tested several
> time in a "lab environment"
>   - we should avoid migration approached that need restructuring the svn
> hierarchy before migration (e.g. "flat list of all modules"), because this
> make impact the migration of svn history to the individual git repos
>   - we may need to write our own migration script handling the specifics
> of the current svn folder structure and creating the full list of
> individual git repos locally from it (first 

[jira] [Commented] (SLING-6074) Healthcheck ITs fail in isolated job on Jenkins

[Bertrand Delacretaz (JIRA)]

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

Bertrand Delacretaz commented on SLING-6074:


bq. One possible way out is to modify the pax-exam tests to take into account 
repository.apache.org.

I suppose the Pax Exam config described at 
https://ops4j1.jira.com/wiki/display/paxexam/Configure+Maven+repositories would 
work for that but I've never tried it.

> Healthcheck ITs fail in isolated job on Jenkins
> ---
>
> Key: SLING-6074
> URL: https://issues.apache.org/jira/browse/SLING-6074
> Project: Sling
>  Issue Type: Bug
>  Components: Health Check
>Reporter: Robert Munteanu
>
> Since moving to per-module builds in the ASF Jenkins instance the health 
> check ITs fail, both for Java 7 and Java 8.
> As far as I what happens is:
> - the ITs reference SNAPSHOT versions of the HC bundles
> - these snapshots are referenced from Pax-Exam tests
> - Pax-Exam tries to reference them using the default Maven settings ( 
> ~/.m2/respository and Maven Central ).
> But since the snapshots are deployed on repository.apache.org this does not 
> work. This used to work when using reactor builds since the dependencies 
> would be installed locally.
> The concrete error message is
> {noformat}1240 [main] WARN org.ops4j.pax.url.mvn.internal.AetherBasedResolver 
> - Error resolving 
> artifactorg.apache.sling:org.apache.sling.hc.samples:jar:1.0.7-SNAPSHOT:Could 
> not find artifact 
> org.apache.sling:org.apache.sling.hc.samples:jar:1.0.7-SNAPSHOT in central 
> (http://repo1.maven.org/maven2/)
> org.sonatype.aether.resolution.ArtifactResolutionException: Could not find 
> artifact org.apache.sling:org.apache.sling.hc.samples:jar:1.0.7-SNAPSHOT in 
> central (http://repo1.maven.org/maven2/){noformat}
> One possible way out is to modify the pax-exam tests to take into account 
> repository.apache.org.
> [~bdelacretaz], [~olli] as you know HC and respectively Pax-Exam better, how 
> do you suggest we approach this?



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

Re: Integration tests near to modules

[Ian Boston]

Hi,
It cant have been decided, as it wasn't, yet, discussed on-list.
I don't have strong feelings about the subject of the "decision".
Best Regards
Ian

On 28 September 2016 at 23:06, Stefan Seifert 
wrote:

> discussed at the Sling Committer Round Table @ adaptTo() 2016
>
> in sling there is a big integration test project that tests the core sling
> functionality and the different sling bundles playing together. a problem
> with this apporach ist hat different aspects are mixed in one project, and
> if a new module is released it may be required to release the integration
> test project as well.
>
> a goal would be to move most of module-specific integration tests "near to
> the module" or just in the module project itself, using one oft the
> numerous available integration test tool support available in sling today.
> this is already the case for several new and complex modules.
>
> it was decided that no new integration tests should be added to this
> central integration test project. exceptions are integration tests covering
> core sling functionality e.g. resource resolving, script resolution.
>
> stefan
>
> [1] https://svn.apache.org/repos/asf/sling/trunk/launchpad/
> integration-tests
>
>
>

[jira] [Created] (SLING-6074) Healthcheck ITs fail in isolated job on Jenkins

[Robert Munteanu (JIRA)]

Robert Munteanu created SLING-6074:
--

 Summary: Healthcheck ITs fail in isolated job on Jenkins
 Key: SLING-6074
 URL: https://issues.apache.org/jira/browse/SLING-6074
 Project: Sling
  Issue Type: Bug
  Components: Health Check
Reporter: Robert Munteanu


Since moving to per-module builds in the ASF Jenkins instance the health check 
ITs fail, both for Java 7 and Java 8.

As far as I what happens is:

- the ITs reference SNAPSHOT versions of the HC bundles
- these snapshots are referenced from Pax-Exam tests
- Pax-Exam tries to reference them using the default Maven settings ( 
~/.m2/respository and Maven Central ).

But since the snapshots are deployed on repository.apache.org this does not 
work. This used to work when using reactor builds since the dependencies would 
be installed locally.

The concrete error message is

{noformat}1240 [main] WARN org.ops4j.pax.url.mvn.internal.AetherBasedResolver - 
Error resolving 
artifactorg.apache.sling:org.apache.sling.hc.samples:jar:1.0.7-SNAPSHOT:Could 
not find artifact 
org.apache.sling:org.apache.sling.hc.samples:jar:1.0.7-SNAPSHOT in central 
(http://repo1.maven.org/maven2/)
org.sonatype.aether.resolution.ArtifactResolutionException: Could not find 
artifact org.apache.sling:org.apache.sling.hc.samples:jar:1.0.7-SNAPSHOT in 
central (http://repo1.maven.org/maven2/){noformat}

One possible way out is to modify the pax-exam tests to take into account 
repository.apache.org.

[~bdelacretaz], [~olli] as you know HC and respectively Pax-Exam better, how do 
you suggest we approach this?



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