On 30/03/2009, Christian Grobmeier <grobme...@gmail.com> wrote: > Hi, > > > > The current ChangeSet API allows for: > > + deletion of entries by name > > + addition of entries by ArchiveEntry and InputStream. > > > > This is fine as far as it goes, but I think it would be useful to add: > > + addition of entries by File > > + replacement of an existing named entry by File or Entry+InputStream > > > Sounds good, esspecially the replacement. > About additions by file - we use only streams in the api, is it good > to start with File now?
I think it would be useful to add File to the putxxx() methods, but I suggest we track that in a separate e-mail thread. > I think this is useful too, having in mind that I wanted to propose > some util classes which allow creating zip files on File basis. > > > > > > It may also be useful to allow the location of new entries to be > > specified. For example, one might want to add META-INF data at the > > front of an archive. It would be useful to specify the locations as: > > + start > > + end > > > I am not sure about this. I cannot imagine a use case for that. Start is definitely useful for things such as META-INF and NOTICE, LICENSE, README files. Otherwise, the default should be end of file. If I remember correctly, "ar" files have ordering requirements, but these are complicated, so are probably best dealt with by the appropriate utility on the OS. > > > I think it would be quite easy to implement: > > + open output file, add any starting entries > > + for each input entry, either copy, skip or replace with new entry > > + at end of input, add any final entries. > > + close archive files > > > > This could be achieved with: > > + HashSet containing names to be deleted > > + HashMap containing new entries for existing names > > + 2 Lists for new entries. > > > > Using Hashes would avoid scanning the list. > > Also, I don't think any of the above would need to be updated during > > perform(), which would allow them to be re-used on another archive. > > > That would be cool. Actually I was thinking about your suggestion with using > a copy of the Set to operate on. This would resolve this too. Indeed. > > Christian > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
