I will look into the test case - from what you describe it should work
- so it might be a bug....
if the package is setup properly, it must remove the missing file.

regards, toby

On Wed, Sep 10, 2014 at 2:48 AM, Mathijs den Burger
<[email protected]> wrote:
> Hi Toby,
>
> On Tue, Sep 9, 2014 at 7:23 PM, Tobias Bocanegra <[email protected]> wrote:
>> Hi,
>>
>> On Tue, Sep 9, 2014 at 5:02 AM, Mathijs den Burger
>> <[email protected]> wrote:
>>> Hi Toby,
>>>
>>> The import code is something along the lines of:
>>>
>>>   private void importArchive(final Session session, final Archive
>>> archive, final ImportMode mode) throws ... {
>>>         archive.open(true);
>>>
>>>         ImportOptions options = new ImportOptions();
>>>         options.setImportMode(mode);
>>>
>>>         Importer importer = new Importer(options);
>>>         importer.run(archive, <some JCR node>);
>>>   }
>>>
>>> The archive implementations override getMetaInf to return some static setup:
>>>
>>>   class MyArchive extends AbstractArchive {
>>>
>>>       @Override
>>>       public MetaInf getMetaInf() {
>>>           DefaultMetaInf metaInf = new DefaultMetaInf();
>>>           metaInf.setSettings(VaultSettings.createDefault());
>>>
>>>           DefaultWorkspaceFilter includeAll = new DefaultWorkspaceFilter();
>>>           includeAll.add(PathFilterSet.INCLUDE_ALL);
>>>           metaInf.setFilter(includeAll);
>>>
>>>           return metaInf;
>>>       }
>>>
>> how you you actually provide the files for the archive?
>
> They are read from filesystem. The archive implementation is very
> similar to FileArchive (e.g. openInputStream and getInputSource read
> files, and Entry#getChildren iterates over the files in a directory).
> I rewrote getJcrRoot and getRoot so I don't need jcr_root and META-INF
> directories for my archive, but that does not seem relevant. I've also
> tried using a FileArchive as-is, with the same result: deleting a file
> and then reimporting the archive with less content does not delete the
> nt:file node created by the previous import.
>
> The following additional unit test in
> vault-core/src/test/java/org/apache/jackrabbit/vault/packaging/integration/ImportTests.java
> shows the point:
>
>     @Test
>     public void testReimportLess() throws IOException,
> RepositoryException, ConfigurationException {
>         ZipArchive archive = new
> ZipArchive(getTempFile("testpackages/tmp.zip"));
>         archive.open(true);
>         Node rootNode = admin.getRootNode();
>         ImportOptions opts = getDefaultOptions();
>         Importer importer = new Importer(opts);
>         importer.run(archive, rootNode);
>
>         assertNodeExists("/tmp/foo/bar/tobi");
>
>         ZipArchive archive2 = new
> ZipArchive(getTempFile("testpackages/tmp-less.zip"));
>         archive2.open(true);
>         importer.run(archive2, rootNode);
>
>         assertNodeMissing("/tmp/foo/bar/tobi");
>     }
>
> The 'testpackages/tmp-less.zip' file is a copy of
> 'testpackages/tmp.zip', but without the directory /tmp/foo/bar/tobi.
>
> The last assert fails: /tmp/foo/bar/tobi still exists after importing
> an archive that no longer contains it.
>
>>> But it seems the Importer is simply the wrong corner of FileVault to
>>> use when I want to keep a local directory in sync. AFAICS the Importer
>>> is only used in the context of installing Packages.
>>
>> well, but that's exactly what you want. the package manage is
>> specifically built to "assemble" packages that look like a zip of a
>> vlt checkout. and it also allows for installing packages that are
>> built that way.
>
> Is it also be possible to install a newer version of a package with
> less files/directories, in such a way that the nt:file/nt:folder nodes
> that used to be 'present' in the old package are deleted once the new
> package has been installed? Or should you then first remove the old
> package before installing the new package?
>
>> as you might know, we moved the entire vlt/packaging stuff from the
>> day/adobe code into jackrabbit. "we" still use the package manager for
>> all our content deployment and development. we also use maven plugins
>> to create and install packages automatically.
>
> That's why I can't imagine deletion of nt:file/nt:folder nodes via
> Packages or Archives is not possible :). How do "you" handle that
> case?
>
> regards,
> Mathijs

Reply via email to