+1 for enabling code sharing and reducing the risk of reinventing wheels. Since all modules import this utils, it will be easier to see what is available instead of developing similar utils. Regards Emily
On Wed, May 18, 2011 at 7:32 AM, Mark Nuttall <[email protected]> wrote: > I'd like to see all the non-application-specific utility code moved from > application to utils, including IFile, IDirectory and > ManifestHeaderProcessor. Changing the package names would increase a few > bundle versions but I think it's the right thing to do. > > On 17 May 2011 13: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 > > > > > -- Thanks Emily ================= Emily Jiang [email protected]
