Cédric Damioli (JIRA) wrote:
[ http://issues.apache.org/jira/browse/JCR-134?page=comments#action_12457455 ]
Cédric Damioli commented on JCR-134:
The VH need only to be kept when there are remaining Version attached to it.
In many apps, it wo
[
http://issues.apache.org/jira/browse/JCR-134?page=comments#action_12457455 ]
Cédric Damioli commented on JCR-134:
The VH need only to be kept when there are remaining Version attached to it.
In many apps, it would be great to get rid of emp
[
http://issues.apache.org/jira/browse/JCR-134?page=comments#action_12457445 ]
Julian Reschke commented on JCR-134:
Isn't it a common use case that version histories need to be preserved even
after the last reference is gone? It seems to me
[
http://issues.apache.org/jira/browse/JCR-134?page=comments#action_12457436 ]
Tobias Bocanegra commented on JCR-134:
--
> - should the VH be deleted on node.removeMixin("mix:versionable") ?
>would it be safe ?
yes, unless it's not used
[
http://issues.apache.org/jira/browse/JCR-134?page=comments#action_12457427 ]
Cédric Damioli commented on JCR-134:
And about the two other points :
- should the VH be deleted on node.removeMixin("mix:versionable") ? would it
be safe ?
- m
[ http://issues.apache.org/jira/browse/JCR-97?page=all ]
Jan Kuzniak updated JCR-97:
---
Attachment: jackrabbit.core.cluster_imports.patch
Thank you, now I am starting to understand Jackrabbit desired code format
guidelines better. It would be great to put them
Hi I am using jackrabbit and require the ability to clone nodes and their
children from a development workspace to a live workspace.
I am having the following problem when trying to clone a simple node with a
single child using the 1.1.1 released version of Jackrabbit:
javax.jcr.ItemNotFoundExce
Hi,
On 12/11/06, Przemo Pakulski <[EMAIL PROTECTED]> wrote:
Btw, it seems that all initialization tests are only needed for api
tests. Now when api tests were extracted to separate project (JCR Tests)
and are not executed as part of the build, it could be simplified I think.
No, the api-tests
Move NamespaceMappings/Index from lucene to namespace registry.
---
Key: JCR-669
URL: http://issues.apache.org/jira/browse/JCR-669
Project: Jackrabbit
Issue Type: Improvement
Global exclude resolved the issue, thanks.
Btw, it seems that all initialization tests are only needed for api
tests. Now when api tests were extracted to separate project (JCR Tests)
and are not executed as part of the build, it could be simplified I think.
Additionally all initialization te
[
http://issues.apache.org/jira/browse/JCR-134?page=comments#action_12457333 ]
Tobias Bocanegra commented on JCR-134:
--
> but I think there is no easy and cheap way ATM to check all corresponding
> nodes on a node or
> version deletion.
you
[ http://issues.apache.org/jira/browse/JCR-97?page=comments#action_12457326
]
Jukka Zitting commented on JCR-97:
--
The jndi patch seems better, though some of the above concerns still apply.
There are also a few more specific issues:
1) There a
[ http://issues.apache.org/jira/browse/JCR-97?page=comments#action_12457318
]
Jukka Zitting commented on JCR-97:
--
[... oops, too fast send. Continued ...]
1) The patch is huge, 369KB. Splitting it to pieces based on the types of
changes, woul
[ http://issues.apache.org/jira/browse/JCR-97?page=comments#action_12457310
]
Jukka Zitting commented on JCR-97:
--
I agree with Stefan's concerns.
Looking at the new jackrabbitCoreFsDbCleanup.patch:
1) The patch is huge,
2) Splitting the line
[
http://issues.apache.org/jira/browse/JCR-134?page=comments#action_12457305 ]
Cédric Damioli commented on JCR-134:
On node.removeMixin("mix:versionable"), should the VersionHistory also be
deleted ?
May a Node be versionable in a workspace
Hi,
On 12/11/06, Miro Walker <[EMAIL PROTECTED]> wrote:
On 12/11/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> 3. Rearrange the versioning operations so that modifications in the
> version storage are always committed before modifications in the
> normal workspace.
Yeah - we discussed this as
[ http://issues.apache.org/jira/browse/JCR-610?page=all ]
Jukka Zitting resolved JCR-610.
---
Resolution: Fixed
Upgraded jackrabbit-core to use Derby 10.2.1.6 in revision 485605. Passes all
unit tests and seems to work fine with existing repositories, so lik
Jukka Zitting wrote:
I think I've now (as of revision 485595) solved the issue by using a
global exclude instead of true in the surefire
configuration.
That works for me too. Thanks a lot!
regards
marcel
Hi Jukka,
On 12/11/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:
I'll add a third one that doesn't really solve the underlying issue
about transactions, but would avoid the content integrity problems:
3. Rearrange the versioning operations so that modifications in the
version storage are always
Hi,
On 12/8/06, Jan Kuźniak <[EMAIL PROTECTED]> wrote:
Jukka Zitting wrote:
> Oh, bugger, you're right. It all boils down to the need to start the
> test suite with the test initialization code. Perhaps we could
> simplify that somehow...
There is an option to write Maven plugin that will execu
[ http://issues.apache.org/jira/browse/JCR-668?page=all ]
Marcel Reutegger resolved JCR-668.
--
Resolution: Fixed
Fixed in revision: 485577
> Allow pseudo properties in query relation
> -
>
> Key: J
Allow pseudo properties in query relation
-
Key: JCR-668
URL: http://issues.apache.org/jira/browse/JCR-668
Project: Jackrabbit
Issue Type: Improvement
Components: xpath
Affects Versions:
Hi,
On 12/8/06, Miro Walker <[EMAIL PROTECTED]> wrote:
The way jackrabbit is currently structured, if versioning is enabled
it is not possible to achieve a truly transactionally secure
repository.
Agreed.
The reason for this is that the version history and the workspace(s)
in which data are
23 matches
Mail list logo
