You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Valentin Mahrwald <vm...@googlemail.com> on 2011/05/17 13:25:58 UTC
[DISCUSS] Move IFile API to org.apache.aries.util
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)" <ji...@apache.org> 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
Re: [DISCUSS] Move IFile API to org.apache.aries.util
Posted by Valentin Mahrwald <vm...@googlemail.com>.
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 <mn...@apache.org> 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 <vm...@googlemail.com> 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)" <ji...@apache.org>
>>> 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
> ejiang@apache.org
Re: [DISCUSS] Move IFile API to org.apache.aries.util
Posted by Emily Jiang <em...@googlemail.com>.
+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 <mn...@apache.org> 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 <vm...@googlemail.com> 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)" <ji...@apache.org>
> > 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
ejiang@apache.org
Re: [DISCUSS] Move IFile API to org.apache.aries.util
Posted by Mark Nuttall <mn...@apache.org>.
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 <vm...@googlemail.com> 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)" <ji...@apache.org>
> 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
>
>
Re: [DISCUSS] Move IFile API to org.apache.aries.util
Posted by Valentin Mahrwald <vm...@googlemail.com>.
In my mind moving the classes to another bundle went hand in hand with renaming org.apache.aries.application.filesystem to org.apache.aries.util.filesystem (or something similar without application in it).
I would prefer doing that to keeping the package name with 'application' in it. However, I can see there is a case as well for being less breaking :)
Regards,
Valentin
On 17 May 2011, at 13:34, Alasdair Nottingham wrote:
> 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 <vm...@googlemail.com> 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)" <ji...@apache.org> 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
> not@apache.org
Re: [DISCUSS] Move IFile API to org.apache.aries.util
Posted by Alasdair Nottingham <no...@apache.org>.
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 <vm...@googlemail.com> 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)" <ji...@apache.org> 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
not@apache.org
Re: [DISCUSS] Move IFile API to org.apache.aries.util
Posted by Holly Cummins <cu...@uk.ibm.com>.
Valentin wrote:
> 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?
+1 for sorting out the NameValueMap, NameValueList subclasses. If we can
get rid of some of the six-deep angle bracket nests the generics cause on
some of those method calls that would be an added bonus.
Holly
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: [DISCUSS] Move IFile API to org.apache.aries.util
Posted by Valentin Mahrwald <vm...@googlemail.com>.
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 <ti...@apache.org> 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: vmahrwald@googlemail.com
>>> Date: Tue, 17 May 2011 15:09:21 +0100
>>> To: dev@aries.apache.org
>>>
>>> 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
> not@apache.org
Re: [DISCUSS] Move IFile API to org.apache.aries.util
Posted by Valentin Mahrwald <vm...@googlemail.com>.
+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 <ti...@apache.org> 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: vmahrwald@googlemail.com
>>> Date: Tue, 17 May 2011 15:09:21 +0100
>>> To: dev@aries.apache.org
>>>
>>> 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
> not@apache.org
Re: [DISCUSS] Move IFile API to org.apache.aries.util
Posted by Alasdair Nottingham <no...@apache.org>.
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 <ti...@apache.org> 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: vmahrwald@googlemail.com
>> Date: Tue, 17 May 2011 15:09:21 +0100
>> To: dev@aries.apache.org
>>
>> 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
not@apache.org
RE: [DISCUSS] Move IFile API to org.apache.aries.util
Posted by Timothy Ward <ti...@apache.org>.
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: vmahrwald@googlemail.com
> Date: Tue, 17 May 2011 15:09:21 +0100
> To: dev@aries.apache.org
>
> 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/
>
Re: [DISCUSS] Move IFile API to org.apache.aries.util
Posted by Valentin Mahrwald <vm...@googlemail.com>.
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
> <vm...@googlemail.com> 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)" <ji...@apache.org> 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/
Re: [DISCUSS] Move IFile API to org.apache.aries.util
Posted by Alasdair Nottingham <no...@apache.org>.
I don't think the lack of reuse by aries should prevent us moving the
code. The question we should be asking isn't do WE reuse it, but do we
think it is a useful utility. I would like to see it broken out of the
application module, there are a few other utilities I think are more
useful.
Alasdair
On 17 May 2011 12:46, Guillaume Nodet <gn...@gmail.com> 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
> <vm...@googlemail.com> 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)" <ji...@apache.org> 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
not@apache.org
Re: [DISCUSS] Move IFile API to org.apache.aries.util
Posted by Guillaume Nodet <gn...@gmail.com>.
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
<vm...@googlemail.com> 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)" <ji...@apache.org> 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/