Build failed in Jenkins: sling-trunk-1.7 #381

See Changes: [cziegeler] Use released versions -- [...truncated 46183 lines...] [INFO] Checking legal files in: org.apache.sling.launchpad.testing-7-SNAPSHOT-sources.jar [INFO] Installing

Jenkins build is back to stable : sling-trunk-1.7 » Apache Sling Sample Integration Tests #381

See

Build failed in Jenkins: sling-trunk-1.7 » Apache Sling Launchpad Testing WAR version #381

See -- [INFO] Deleting (includes = [de

Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing #381

See

[jira] [Comment Edited] (SLING-2986) Merged Resource Provider

[ https://issues.apache.org/jira/browse/SLING-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13805207#comment-13805207 ] Gilles Knobloch edited comment on SLING-2986 at 10/25/13 10:28 AM: -

[jira] [Commented] (SLING-2986) Merged Resource Provider

[ https://issues.apache.org/jira/browse/SLING-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13805207#comment-13805207 ] Gilles Knobloch commented on SLING-2986: [~jsedding], I adressed both of your comm

Build failed in Jenkins: sling-trunk-1.6 » Apache Sling Launchpad Testing WAR version #2015

See -- [INFO] Deleting [INFO] De

Build failed in Jenkins: sling-trunk-1.6 #2015

See Changes: [cziegeler] Use released versions -- [...truncated 39126 lines...] [INFO] Checking legal files in: org.apache.sling.launchpad.testing-7-SNAPSHOT-sources.jar [INFO] Installing

Jenkins build is still unstable: sling-trunk-1.6 » Apache Sling Launchpad Testing #2015

See

[jira] [Resolved] (SLING-3205) maven-launchpad-plugin:run does not take run modes into account

[ https://issues.apache.org/jira/browse/SLING-3205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz resolved SLING-3205. Resolution: Fixed Implemented in revision 1535709 Corresponding integration enable

Re: Is maven-launchpad-plugin:run supposed to support run modes?

On Wed, Oct 23, 2013 at 5:03 PM, Bertrand Delacretaz wrote: > ...Before I dig deeper, is this supposed to work?... I did dig (much) deeper, and that didn't work. Fixed in SLING-3205. -Bertrand

[jira] [Resolved] (SLING-3155) Switch launchpad between Jackrabbit and Oak based on run modes

[ https://issues.apache.org/jira/browse/SLING-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz resolved SLING-3155. Resolution: Fixed The -Dsling.run.modes=jackrabbit (or oak) option now works both i

[jira] [Commented] (SLING-2986) Merged Resource Provider

[ https://issues.apache.org/jira/browse/SLING-2986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13805279#comment-13805279 ] Julian Sedding commented on SLING-2986: --- Looks good, thanks! > Merged Resource Prov

Build failed in Jenkins: sling-trunk-1.7 #382

See Changes: [bdelacretaz] SLING-3205 - re-enable InactiveRunModeTest [bdelacretaz] SLING-3205 - use latest maven-launchpad-plugin [bdelacretaz] SLING-3205 - provide bundle resources under resources/install to support run modes [czie

Jenkins build is still unstable: sling-trunk-1.7 » Apache Sling Launchpad Testing #382

See

Build failed in Jenkins: sling-trunk-1.7 » Apache Sling Launchpad Testing WAR version #382

See -- [INFO] Deleting [INFO] Del

Jenkins build is still unstable: sling-oak-it-1.6 » Apache Sling Launchpad Testing #3

See

Jenkins build is back to stable : sling-trunk-1.6 » Apache Sling Launchpad Testing #2016

See

Jenkins build is still unstable: sling-oak-it-1.6 #3

See

Build failed in Jenkins: sling-trunk-1.6 #2016

See Changes: [bdelacretaz] SLING-3205 - re-enable InactiveRunModeTest [bdelacretaz] SLING-3205 - use latest maven-launchpad-plugin [bdelacretaz] SLING-3205 - provide bundle resources under resources/install to support run modes [czi

Build failed in Jenkins: sling-trunk-1.6 » Apache Sling Launchpad Testing WAR version #2016

See -- [INFO] Deleting [INFO] De

Re: Scalabilty of EventListener

On 24.10.2013, at 16:55, Justin Edelson wrote: > Given that there's already an expression syntax defined in the > EventAdmin specification, wouldn't it make more sense for Oak to just > use OSGi Events? That's the only way I personally could forsee us > being in a position to deprecate/remote the