[
https://issues.apache.org/jira/browse/SLING-11705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konrad Windszus updated SLING-11705:
------------------------------------
Description:
FileVault supports multiple and overlapping serializations of nodes
(https://jackrabbit.apache.org/filevault/vaultfs.html).
Currently this is partially re-implemented in
*
https://github.com/apache/sling-ide-tooling/blob/18c02373401bfd087847ac34eb384b91d6048405/shared/impl-vlt/src/main/java/org/apache/sling/ide/impl/vlt/AddOrUpdateNodeCommand.java#L184
*
https://github.com/apache/sling-ide-tooling/blob/18c02373401bfd087847ac34eb384b91d6048405/shared/impl-vlt/src/main/java/org/apache/sling/ide/impl/vlt/serialization/VltSerializationDataBuilder.java#L119
Instead of reproducing the FileVault logic in order to be able to sync
FileVault content packages correctly it would be good to rely more on FileVault
classes to do the job of import/export particularly for the tricky case where
more than 1 file determines the properties of a single node.
Also in case of an update of a raw .content.xml file in Eclipse this is first
- deserialized into ResourceProxy objects
- copied from ResourceProxy object to the remote repo.
While during the import of the content package this import is being taken care
of by FileVault.
The ResourceProxy should merely be used to create an abstraction from the
serialization files and to update/create serialization files based on it.
At the same time the Sling POST servlet based implementation can probably be
removed as those can only ever be synced with Eclipse (and therefore were
probably never used in reality). The only other packaging formats for resources
is IMHO Sling Initial Content being part of OSGi bundles but that doesn't
define an incremental API so syncing is always done via the full bundles.
was:
FileVault supports multiple and overlapping serializations of nodes
(https://jackrabbit.apache.org/filevault/vaultfs.html).
Currently this is partially re-implemented in
*
https://github.com/apache/sling-ide-tooling/blob/18c02373401bfd087847ac34eb384b91d6048405/shared/impl-vlt/src/main/java/org/apache/sling/ide/impl/vlt/AddOrUpdateNodeCommand.java#L184
*
https://github.com/apache/sling-ide-tooling/blob/18c02373401bfd087847ac34eb384b91d6048405/shared/impl-vlt/src/main/java/org/apache/sling/ide/impl/vlt/serialization/VltSerializationDataBuilder.java#L119
Instead of reproducing the FileVault logic in order to be able to sync
FileVault content packages correctly it would be good to rely more on FileVault
classes to do the job of import/export particularly for the tricky case where
more than 1 file determines the properties of a single node.
Also in case of an update of a raw .content.xml file in Eclipse this is first
- deserialized into ResourceProxy objects
- copied from ResourceProxy object to the remote repo.
While during the import of the content package this import is being taken care
of by FileVault.
The ResourceProxy should merely be used to create an abstraction from the
serialization files and to update/create serialization files based on it.
At the same time the Sling POST servlet based implementation can probably be
removed as those can only ever be synced with Eclipse (and therefore were
probably never used in reality)
> Transfer based on serialized files instead of abstraction ResourceProxy
> -----------------------------------------------------------------------
>
> Key: SLING-11705
> URL: https://issues.apache.org/jira/browse/SLING-11705
> Project: Sling
> Issue Type: Improvement
> Components: IDE
> Reporter: Konrad Windszus
> Priority: Major
>
> FileVault supports multiple and overlapping serializations of nodes
> (https://jackrabbit.apache.org/filevault/vaultfs.html).
> Currently this is partially re-implemented in
> *
> https://github.com/apache/sling-ide-tooling/blob/18c02373401bfd087847ac34eb384b91d6048405/shared/impl-vlt/src/main/java/org/apache/sling/ide/impl/vlt/AddOrUpdateNodeCommand.java#L184
> *
> https://github.com/apache/sling-ide-tooling/blob/18c02373401bfd087847ac34eb384b91d6048405/shared/impl-vlt/src/main/java/org/apache/sling/ide/impl/vlt/serialization/VltSerializationDataBuilder.java#L119
> Instead of reproducing the FileVault logic in order to be able to sync
> FileVault content packages correctly it would be good to rely more on
> FileVault classes to do the job of import/export particularly for the tricky
> case where more than 1 file determines the properties of a single node.
> Also in case of an update of a raw .content.xml file in Eclipse this is first
> - deserialized into ResourceProxy objects
> - copied from ResourceProxy object to the remote repo.
> While during the import of the content package this import is being taken
> care of by FileVault.
> The ResourceProxy should merely be used to create an abstraction from the
> serialization files and to update/create serialization files based on it.
> At the same time the Sling POST servlet based implementation can probably be
> removed as those can only ever be synced with Eclipse (and therefore were
> probably never used in reality). The only other packaging formats for
> resources is IMHO Sling Initial Content being part of OSGi bundles but that
> doesn't define an incremental API so syncing is always done via the full
> bundles.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
