Hi Alasdair, I moved the (majority of the) manifest parsing while moving the other parts, because they were actually too intimately coupled to easily crack them apart. So I am looking to follow up on the manifest parsing refactoring that you mentioned.
As far as I can tell the thing that is most annoying is the NameValueMap, NameValueList mostly unnecessary subclasses of the generic collections that crop up all over the place when using the API. Any other items? Regards, Valentin 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]
