I noticed this statement from some random guy on the internet:
http://www.liferay.com/community/forums/-/message_boards/message/2108515
excerpt: "Note that the export file will have all your docs and also
revision history, but there is no way to import back all your revision
history from an export file (it is not part of the jcr specifications)."
So if that is true then, guess I’m stuck recreating the versions manually,
*slow clap*. That makes sense.
>****Part 1:
>
>I receive an exception while trying to import the ³/jcr:system² node into
>³/³: javax.jcr.ItemExistsException: Node with the same UUID exists:node
>/jcr:system
>
>When I run through debug mode the node IDs are not equal causing
>Jackrabbit to throw the exception:
>existing.getId() = "deadbeef-cafe-babe-cafe-babecafebabe²
>id = null
>
>
>
>My simple import code:
>
>ByteArrayOutputStream out = new ByteArrayOutputStream();
> session.exportSystemView("/jcr:system", out, false,
> false);
> System.out.println("WAIT: "+ new
> String(out.toByteArray()));
>//Insert a breakpoint here to modify data before replacing the current
>data, simple test
>
> InputStream in = new
> ByteArrayInputStream(out.toByteArray());
> session.importXML("/", in,
>ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING);
> session.save();
>
>
>
>Jackrabbit code in SessionImporter (line 377 for Jackrabbit 2.6.5 (my
>current version) (also exists for the same line in 2.10.0¹s version)):
>
>if (!(existing.getId().equals(id)
> && (uuidBehavior ==
>ImportUUIDBehavior.IMPORT_UUID_COLLISION_REMOVE_EXISTING
> || uuidBehavior ==
>ImportUUIDBehavior.IMPORT_UUID_COLLISION_REPLACE_EXISTING))) {
> throw new ItemExistsException(
> "Node with the same UUID exists:" +
>existing);
> }
>
>
>I would venture to say the Node with the same UUID does not exist
>(assuming ID is equivalent to the UUID being reference by the errorŠ).
>The error description should be a bit different, or add more information.
>The XML I¹m trying got import is about 5,624 lines long, but I doubt
>people want to receive that in their inbox.
>
>****Part 2:
>
>When I import the ³/jcr:system² node into a subfolder (like /z,
>nt:unstructured) it only brings in the 2nd level of children from
>³/jcr:system² (jar:versionStorage, jar:activities, jcr:nodeTypes). It
>doesn¹t bring in any versions! The export has all the data but the import
>is deleting the important information. Some configuration for my current
>system:
>Repository.OPTION_XML_IMPORT_SUPPORTED is true
>
>In my repository XML I have the following that helps with importing the
>ACLs:
><Import>
> <ProtectedNodeImporter
>class="org.apache.jackrabbit.core.xml.AccessControlImporter"/>
> </Import>
>
>
>
>By default shouldn¹t Jackrabbit just import everything? Start with being
>able to import everything and narrow scope through configuration. At
>least then devs would be able to use expected features easily. I would
>prefer to just export ³/³ and import into ³/³, but:
>javax.jcr.nodetype.ConstraintViolationException: Unexpected node type
>{internal}ACL. Should be rep:AccessControl or rep:PrincipalAccessControl.
>
>
>Sincerely,
>-Annoyed I¹m still using this.
>
