You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Matt Benson <gu...@yahoo.com> on 2009/02/24 23:19:34 UTC
explicitly specified archive input
I'm thinking maybe what we need here [1] is a way to wrap arbitrary resource collections with archival information, like extracting the archive attribute getters of ArchiveFileSet to an ArchivalResourceCollection interface, implemented by ArchiveFileSet as well as sugg. ArchivalResources which would take any embedded Resource(s)... then filelists or explicit <file> resources could be used (these should fail if missing I think). Then to create archives, archival tasks would look not for ArchiveFileSet per se but ArchivalResourceCollection or ArchiveInput or whatever we want to call it. What holes have I missed in this approach?
-Matt
[1] https://issues.apache.org/bugzilla/show_bug.cgi?id=32526
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: explicitly specified archive input
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-02-24, Matt Benson <gu...@yahoo.com> wrote:
> I'm thinking maybe what we need here [1] is a way to wrap arbitrary
> resource collections with archival information, like extracting the
> archive attribute getters of ArchiveFileSet to an
> ArchivalResourceCollection interface, implemented by ArchiveFileSet
> as well as sugg. ArchivalResources which would take any embedded
> Resource(s)... then filelists or explicit <file> resources could be
> used (these should fail if missing I think).
That's what I hinted at with my comment about filelists (I thought
filelists would fail if missing as well). So yes, the bigger problem
for the more strict collections is/was that you loose information.
> Then to create archives, archival tasks would look not for
> ArchiveFileSet per se but ArchivalResourceCollection or ArchiveInput
> or whatever we want to call it. What holes have I missed in this
> approach?
If you want to use that approach (and I don't think you are miissing
anything), please don't use instanceof checks but rather the
Resource.as method I introduced when I extraced the mapping logic -
that way one can write decorators for new interfaces without having to
implement all the other interafaces as well.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org