It shouldn't be a breaking change unless we change the package name at the same time.
On 17 May 2011 12:25, Valentin Mahrwald <[email protected]> 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)" <[email protected]> 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 > > -- Alasdair Nottingham [email protected]
