Hi,
On Fri, Mar 14, 2014 at 12:37 AM, Chetan Mehrotra
wrote:
> I need to write couple of integration testcase related to checking
> OSGi configuration support (OAK-1502) in oak-pojosr module. It would
> be much much more faster and convenient for me if I can write these
> testcases in groovy.
>
>
Hi,
On Fri, Mar 14, 2014 at 2:43 PM, Michael Dürig wrote:
>
>
> On 14.3.14 1:06 , Tobias Bocanegra wrote:
>>
>> Hi,
>>
>> I tried to create users concurrently, and I get a constraint violation:
>>
>> "Cannot create user/group: Intermediate folders must be of type
>> rep:AuthorizableFolder."
>>
>>
On 14.3.14 1:06 , Tobias Bocanegra wrote:
Hi,
I tried to create users concurrently, and I get a constraint violation:
"Cannot create user/group: Intermediate folders must be of type
rep:AuthorizableFolder."
on the "addExistingNode" parent, because the User validator traverses
up the followin
Thanks for your response, Davide, I did get the propertyIndex to work!
I have one question however:
I can only get the query to work when querying for nt:unstructured, but
not for nt:base. Is this the expected behaviour?
I can create my index either with the „declaringNodeTypes“ property set to
„
Hi,
I created https://issues.apache.org/jira/browse/OAK-1541 and added an
additional test that shows the same problem.
it looks like the 'UserValidator' is executed before the merge
conflict is resolved. As I don't fully understand how it should work,
maybe someone that implemented the merging co
Hi,
On Fri, Mar 14, 2014 at 2:17 AM, Chetan Mehrotra
wrote:
> I was trying to run the IT test locally before I push in my changes
> related to DataStore. However it seems that testcase are currently
> failing even without my change.
> [...]
> On debugging it seems to be a failure in SegmentMicroK
On 14.3.14 10:36 , Chetan Mehrotra wrote:
On Fri, Mar 14, 2014 at 1:36 PM, Davide Giannella
wrote:
Personally I don't mind but it would complicate the life of someone who
doesn't know groovy and has to maintain the code later on.
I understand the concern here. However Groovy is much more ea
On Fri, Mar 14, 2014 at 1:36 PM, Davide Giannella
wrote:
> Personally I don't mind but it would complicate the life of someone who
> doesn't know groovy and has to maintain the code later on.
I understand the concern here. However Groovy is much more easier to
understand for a Java developer comp
On 2014-03-14 09:06, Davide Giannella wrote:
On 14/03/2014 04:37, Chetan Mehrotra wrote:
Just testing the waters here :)
I need to write couple of integration testcase related to checking
OSGi configuration support (OAK-1502) in oak-pojosr module. It would
be much much more faster and convenien
On 13/03/2014 17:41, Ben Zahler wrote:
> I execute the following query:
> String expression = "SELECT * FROM [nt:base] WHERE trainingProperty >
> 10";
> Query query = queryManager.createQuery(expression,Query.JCR_SQL2);
>
> As expected, I get the message
> WARN o.a.j.o.s.q.Cursors$TraversingCurs
On 14/03/2014 04:37, Chetan Mehrotra wrote:
> Just testing the waters here :)
>
> I need to write couple of integration testcase related to checking
> OSGi configuration support (OAK-1502) in oak-pojosr module. It would
> be much much more faster and convenient for me if I can write these
> testcas
11 matches
Mail list logo
