Hi, I agree to moving the IOUtils and although I haven't looked at the RememberingInputStream it sounds like it would be worth moving too.
I would like the manifest parsing code to move into the util component, but I never really liked the API. It always felt a little weird, so I would like to see that tidied up if any move occurred. Alasdair On 17 May 2011 16:44, Timothy Ward <[email protected]> wrote: > > Hi > > I'm +1 for moving IFile, but mostly because I'd like to move IOUtils into the > util bundle at the same time. This would be useful for some of the work in > the JPA container. I'd also like to move the RememberingInputStream out of > the JPA container to the util bundle where it could be used by other people. > > Another package in application.utils that I think should move is > org.apache.aries.application.utils.manifest. The ManifestHeaderProcessor > would be useful in the JPA container and blueprint container bundles for > deciphering bundle headers. > > Regards, > > Tim > > ---------------------------------------- >> Subject: Re: [DISCUSS] Move IFile API to org.apache.aries.util >> From: [email protected] >> Date: Tue, 17 May 2011 15:09:21 +0100 >> To: [email protected] >> >> There is a lot of cases in the private code base I work with that use IFiles >> independently of the application model, but not so much in Apache Aries >> itself admittedly. >> >> On 17 May 2011, at 12:46, Guillaume Nodet wrote: >> >> > Which other piece would be a candidate for reusing this API ? If >> > there's a single piece of code using it, it's not really reused. >> > >> > On Tue, May 17, 2011 at 13:25, Valentin Mahrwald >> > wrote: >> >> Right, let's have the discussion then :) >> >> >> >> The arguments I can see for moving are along the lines of: The IFile API >> >> has really nothing much to do with the rest of the application model and >> >> putting it along side loads of application specific classes severely >> >> limits reusability. The util bundle would be an obvious choice to put >> >> things into, and I imagine it would not get to unwieldy with this change >> >> (although splitting it out entirely would also be fine from my point of >> >> view). >> >> >> >> Reasons against it certainly would be the fact that this is a full scale >> >> breaking change. >> >> >> >> Despite that I would propose to move things now and have it in place for >> >> the next 0.x or 1.0 release, rather than be stuck with it in the arguably >> >> wrong place. >> >> >> >> What do people think? >> >> >> >> Valentin >> >> >> >> On 16 May 2011, at 20:11, Alasdair Nottingham wrote: >> >> >> >>> Hi, >> >>> >> >>> I would hold off on a move for now. We have a JIRA that mentions it, but >> >>> I think we should discuss it first. >> >>> >> >>> Alasdair >> >>> >> >>> Alasdair Nottingham >> >>> >> >>> On 16 May 2011, at 11:46, "Valentin Mahrwald (JIRA)" wrote: >> >>> >> >>>> >> >>>> [ >> >>>> https://issues.apache.org/jira/browse/ARIES-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13033960#comment-13033960 >> >>>> ] >> >>>> >> >>>> Valentin Mahrwald commented on ARIES-652: >> >>>> ----------------------------------------- >> >>>> >> >>>> Also, the IFile API should probably live in org.apache.aries.util (or >> >>>> even on its own) so it is reusable without the application API. Any >> >>>> objections? >> >>>> >> >>>>> Improvements to IFile API >> >>>>> ------------------------- >> >>>>> >> >>>>> Key: ARIES-652 >> >>>>> URL: https://issues.apache.org/jira/browse/ARIES-652 >> >>>>> Project: Aries >> >>>>> Issue Type: Improvement >> >>>>> Components: Application >> >>>>> Reporter: Valentin Mahrwald >> >>>>> Assignee: Valentin Mahrwald >> >>>>> >> >>>>> Currently the IFile API suffers from a number of capability / >> >>>>> performance problems: >> >>>>> - it is not possible with the API to open a zipfile as an IDirectory >> >>>>> if the directory that contains the zipfile was opened as an IDirectory >> >>>>> already >> >>>>> - it is not possible to open a zipfile nested in a zipfile with the >> >>>>> API at all >> >>>>> - operation on zipfile IDirectories are an order of magnitude slower >> >>>>> than using zipfile directly because the zipfile is opened and closed >> >>>>> for most operations! >> >>>> >> >>>> -- >> >>>> This message is automatically generated by JIRA. >> >>>> For more information on JIRA, see: >> >>>> http://www.atlassian.com/software/jira >> >> >> >> >> > >> > >> > >> > -- >> > Cheers, >> > Guillaume Nodet >> > ------------------------ >> > Blog: http://gnodet.blogspot.com/ >> > ------------------------ >> > Open Source SOA >> > http://fusesource.com >> > >> > Connect at CamelOne May 24-26 >> > The Open Source Integration Conference >> > http://camelone.com/ >> > -- Alasdair Nottingham [email protected]
