From the discussion I have not heard a strong objection to moving things to 
util and a lot of support for doing so. I also found the old JIRA (ARIES-582) 
that actually was raised for that. So I'll look to get it done under that one :)

Regards,

Valentin

On 18 May 2011, at 09:29, Emily Jiang wrote:

> +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]

Reply via email to