See
https://builds.apache.org/job/sling-trunk-1.7/org.apache.sling$org.apache.sling.testing.samples.integrationtests/332/
See https://builds.apache.org/job/sling-trunk-1.7/332/changes
We need another binding vote, anyone?
Thanks
2013/10/8 Karl Pauls karlpa...@gmail.com
+1
regards,
Karl
On Tue, Oct 8, 2013 at 12:54 PM, Carsten Ziegeler cziege...@apache.org
wrote:
Hi,
it's time for a new engine release:
Sling Engine 2.2.10
Hi,
The discovery's ClusterView contains a 'getId()' which returns the current
ClusterView's ID. I'm not sure this ID is any good though. First, it is only
valid for the lifetime of the ClusterView - ie if an instance joins a cluster,
a new ClusterView is created, with a new ID. Second, what
Hi,
yes, I totally agree either we have the id stable or its of no use - I
thought that it is stable, actually :) But fortunately the javadocs are
unclear about this.
I guess it heavily depends on the used implementation whether a stable id
is easy to implement or not - I could imagine use cases
On 10/11/13 1:35 PM, Carsten Ziegeler cziege...@apache.org wrote:
Hi,
yes, I totally agree either we have the id stable or its of no use - I
thought that it is stable, actually :) But fortunately the javadocs are
unclear about this.
I guess it heavily depends on the used implementation whether a
Rethink this, I guess my use cases call more for a cluster name or cluster
description - which is a user created information.
The more I think about it, the more I tend to agree that we should
deprecate it and clearly state that the id is not guaranteed to be stable
(for people using is already).
[
https://issues.apache.org/jira/browse/SLING-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-3162:
---
Fix Version/s: Sling Eclipse IDE 1.0.0
Agreed, I would contribute it at least to the Java
[
https://issues.apache.org/jira/browse/SLING-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792646#comment-13792646
]
Carsten Ziegeler commented on SLING-3160:
-
I've applied a potential fix in rev
[
https://issues.apache.org/jira/browse/SLING-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler reassigned SLING-3160:
---
Assignee: Carsten Ziegeler
Creating ResourceResolverFactory as ServiceFactory leads
FYI: Created https://issues.apache.org/jira/browse/SLING-3164 for this.
Without objections I will go ahead and adjust the javadoc of the API..
Cheers,
Stefan
On 10/11/13 2:45 PM, Carsten Ziegeler cziege...@apache.org wrote:
Rethink this, I guess my use cases call more for a cluster name or
Stefan Egli created SLING-3164:
--
Summary: Clarify and deprecate ClusterView.getId
Key: SLING-3164
URL: https://issues.apache.org/jira/browse/SLING-3164
Project: Sling
Issue Type: Bug
Justin Edelson created SLING-3165:
-
Summary: Cannot remove Bundle or Content Package Module from Server
Key: SLING-3165
URL: https://issues.apache.org/jira/browse/SLING-3165
Project: Sling
Hi
Am 11.10.2013 um 05:45 schrieb Carsten Ziegeler:
Rethink this, I guess my use cases call more for a cluster name or cluster
description - which is a user created information.
The more I think about it, the more I tend to agree that we should
deprecate it and clearly state that the id is
[
https://issues.apache.org/jira/browse/SLING-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792798#comment-13792798
]
Stefan Seifert commented on SLING-3028:
---
some feedback from my side. i have not used
[
https://issues.apache.org/jira/browse/SLING-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792803#comment-13792803
]
Stefan Seifert commented on SLING-3028:
---
i forgot to mention - besides this mostly
[
https://issues.apache.org/jira/browse/SLING-1778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13792811#comment-13792811
]
Stefan Seifert commented on SLING-1778:
---
fyi - if started some more work on this
On Fri, Sep 27, 2013 at 11:59 AM, Carsten Ziegeler
cziege...@apache.org wrote:
...Not quite the same - but we might be able to share code /
functionality...
Yeah that's my main concern: the merging/overriding logic should use
the same code.
-Bertrand
yes, i think this is a good thought as
Based on the information in SLING-387[0], there is the possibility of
getting into a situation where the selection of the script is difficult
to predict. Basically if you have a resource that has two scripts:
/path/to/resource/print.esp
/path/to/resource/print.jsp
The script resolver
On 11.10.2013, at 12:40, dan mcweeney mcwee...@adobe.com wrote:
Based on the information in SLING-387[0], there is the possibility of
getting into a situation where the selection of the script is difficult
to predict. Basically if you have a resource that has two scripts:
If someone wanted to use two rendering technologies side by side. This is
especially important when introducing a new type of rendering engine. You
might want to show people the new ones but keep them out of the way on
upgrade / new install.
-d
On 10/11/13 6:03 PM, Alexander Klimetschek
On 11.10.2013, at 15:10, Dan McWeeney mcwee...@adobe.com wrote:
If someone wanted to use two rendering technologies side by side. This is
especially important when introducing a new type of rendering engine. You
might want to show people the new ones but keep them out of the way on
upgrade /
+1
On Tue, Oct 8, 2013 at 6:54 AM, Carsten Ziegeler cziege...@apache.org wrote:
Hi,
it's time for a new engine release:
Sling Engine 2.2.10
https://issues.apache.org/jira/browse/SLING/fixforversion/12324111
Staging repository:
Hi
Am 11.10.2013 um 12:40 schrieb dan mcweeney:
Based on the information in SLING-387[0], there is the possibility of
getting into a situation where the selection of the script is difficult
to predict. Basically if you have a resource that has two scripts:
/path/to/resource/print.esp
24 matches
Mail list logo
