+1 for making the manifest parsing nicer. On 17 May 2011, at 18:48, Alasdair Nottingham wrote:
> 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]
