[
https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477963
]
Marcel Reutegger commented on JCR-741:
--
Not convinced. If the node type allows multiple property definitions
Hi,
I have posted a candidate for the Apache Jackrabbit 1.2.3 release at
http://people.apache.org/~jukka/jackrabbit/1.2.3/
See the included RELEASE-NOTES.txt file for details on release
contents and latest changes. The release was made from the 1.2 branch
after merging all the bug fixes
Hi,
On 3/5/07, Jukka Zitting [EMAIL PROTECTED] wrote:
Please vote on releasing these packages as Apache Jackrabbit 1.2.3.
[x] +1 Release the packages as Apache Jackrabbit 1.2.3
BR,
Jukka Zitting
[x] +1 Release the packages as Apache Jackrabbit 1.2.3
--
GIT Consultors S.L.
c\ Francesc Rover 2-B
07003 Palma de Mallorca
(Illes Balears)
More verbose message on reference constraint violation
--
Key: JCR-776
URL: https://issues.apache.org/jira/browse/JCR-776
Project: Jackrabbit
Issue Type: Improvement
Components:
[
https://issues.apache.org/jira/browse/JCR-776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christoph Kiehl updated JCR-776:
Attachment: patch.txt
This patch is just a proposal. Please review
More verbose message on
[
https://issues.apache.org/jira/browse/JCR-741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12478035
]
Julian Reschke commented on JCR-741:
my point is to possibly avoid a call (by an spi implementation) to the store
Hi all,
When checking in a versionable Node A, with a child B
(OnParentVersion=COPY) of whatever nodetype, the corresponding
nt:frozenNode has a child node B of type nt:frozenNode and not of
its initial nodetype.
From the JCR spec, section 8.2.11.1 : On checkin of N, C and all its
descendent
hi,
there was a lot of arguing respecting how to organize the version
storage. i don't know if it's explicitly mentioned in the spec, but
the problem is, that the frozen nodes can't have neither the original
uuid nor primary or mixin types, because constraints can't be enforced
(e.g. missing
On 3/5/07, Cédric Damioli [EMAIL PROTECTED] wrote:
When checking in a versionable Node A, with a child B
(OnParentVersion=COPY) of whatever nodetype, the corresponding
nt:frozenNode has a child node B of type nt:frozenNode and not of
its initial nodetype.
I recently noticed this too and, if I
10 matches
Mail list logo
