You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Davide Giannella <da...@apache.org> on 2015/07/20 14:39:14 UTC
oak-run 50MB
Hello folks,
oak-run is 50MB+. Shall we look into how to potentially split what this
module provides in something more precise and maybe delete some parts no
longer used/supported?
Off the top of my head oak-run provides:
- utility tools for segment, mongo and datastore
- micro benchmarking
- scalability benchmarking
- rough http server
So the question is: shall we look into the details for splitting it into
smaller modules? I don't think oak-run is an appropriate name either.
Davide
Re: oak-run 50MB
Posted by Davide Giannella <da...@apache.org>.
On 11/12/2015 09:30, Michael Dürig wrote:
> >...I will file separate tickets for the actual actions, around moving
> each
>> individual functionality to own bundle if no one will object.
>
> +1, good having someone driving this.
Please all, have a look at
https://issues.apache.org/jira/browse/OAK-3134 and children tickets for
individual actions. Amend as needed if you see it fits.
One questions left on the topic: shall we remove/deprecate the "Server"
functionality? Is there anyone using it?
Cheers
Davide
Re: oak-run 50MB
Posted by Michael Dürig <md...@apache.org>.
On 10.12.15 11:38 , Davide Giannella wrote:
> On 22/07/2015 10:23, Davide Giannella wrote:
>> On 20/07/2015 14:12, Julian Sedding wrote:
>>> +1 It sounds sensible to split this up. It seems that it has evolved
>>> into a collection of functionality that shares mostly the fact that
>>> they are run on the command line. I would like to see the logic used
>>> to bootstrap various Oak setups based on command line parameters to be
>>> extracted and re-used.
>> I've created https://issues.apache.org/jira/browse/OAK-3134 to keep
>> track of an initial investigation.
>>
>> Can I ask everyone to jump on it adding their own knowledge and suggestions?
>>
>
> As we're speaking of modularisation I'm reviving this thread. Please
> see the ticket https://issues.apache.org/jira/browse/OAK-3134 for details.
>
> I will file separate tickets for the actual actions, around moving each
> individual functionality to own bundle if no one will object.
+1, good having someone driving this.
Michael
>
> Cheers
> Davide
>
>
Re: oak-run 50MB
Posted by Davide Giannella <da...@apache.org>.
On 11/12/2015 09:31, Michael Dürig wrote:
>
>
> +1, see https://issues.apache.org/jira/browse/OAK-2847.
I've turned OAK-2847 into Epic and moved OAK-3766 as actual action of
it. We have to decide when we want to do this :)
Davide
Re: oak-run 50MB
Posted by Michael Dürig <md...@apache.org>.
On 11.12.15 8:29 , Thomas Mueller wrote:
> Hi,
>
> Could we get rid of unused stuff? Like Hadoop (7 MB!). Do we need Solr
> (2.3 MB), Tika, Zookeeper, Jetty, H2 (the SQL part)? Do we need the
> Jackrabbit remoting stuff? I guess we need Groovy (4 MB) and Lucene (4 MB).
>
> Of those 50MB, just 8% is Oak, and the rest is dependencies.
+1, see https://issues.apache.org/jira/browse/OAK-2847.
Michael
>
>
> Regards,
> Thomas
>
>
>
>
>
>
> On 10/12/15 11:38, "Davide Giannella" <da...@apache.org> wrote:
>
>> On 22/07/2015 10:23, Davide Giannella wrote:
>>> On 20/07/2015 14:12, Julian Sedding wrote:
>>>> +1 It sounds sensible to split this up. It seems that it has evolved
>>>> into a collection of functionality that shares mostly the fact that
>>>> they are run on the command line. I would like to see the logic used
>>>> to bootstrap various Oak setups based on command line parameters to be
>>>> extracted and re-used.
>>> I've created https://issues.apache.org/jira/browse/OAK-3134 to keep
>>> track of an initial investigation.
>>>
>>> Can I ask everyone to jump on it adding their own knowledge and
>>> suggestions?
>>>
>>
>> As we're speaking of modularisation I'm reviving this thread. Please
>> see the ticket https://issues.apache.org/jira/browse/OAK-3134 for details.
>>
>> I will file separate tickets for the actual actions, around moving each
>> individual functionality to own bundle if no one will object.
>>
>> Cheers
>> Davide
>>
>>
>
Re: oak-run 50MB
Posted by Davide Giannella <da...@apache.org>.
On 11/12/2015 07:29, Thomas Mueller wrote:
> Hi,
>
> Could we get rid of unused stuff? Like Hadoop (7 MB!). Do we need Solr
> (2.3 MB), Tika, Zookeeper, Jetty, H2 (the SQL part)? Do we need the
> Jackrabbit remoting stuff? I guess we need Groovy (4 MB) and Lucene (4 MB).
>
> Of those 50MB, just 8% is Oak, and the rest is dependencies.
>
thanks for the investigation Thomas. Filed
https://issues.apache.org/jira/browse/OAK-3766.
IMO if the dependency is not used, simply remove it. It can be added
later on if there will be the need.
Cheers
Davide
Re: oak-run 50MB
Posted by Thomas Mueller <mu...@adobe.com>.
Hi,
Could we get rid of unused stuff? Like Hadoop (7 MB!). Do we need Solr
(2.3 MB), Tika, Zookeeper, Jetty, H2 (the SQL part)? Do we need the
Jackrabbit remoting stuff? I guess we need Groovy (4 MB) and Lucene (4 MB).
Of those 50MB, just 8% is Oak, and the rest is dependencies.
Regards,
Thomas
On 10/12/15 11:38, "Davide Giannella" <da...@apache.org> wrote:
>On 22/07/2015 10:23, Davide Giannella wrote:
>> On 20/07/2015 14:12, Julian Sedding wrote:
>>> +1 It sounds sensible to split this up. It seems that it has evolved
>>> into a collection of functionality that shares mostly the fact that
>>> they are run on the command line. I would like to see the logic used
>>> to bootstrap various Oak setups based on command line parameters to be
>>> extracted and re-used.
>> I've created https://issues.apache.org/jira/browse/OAK-3134 to keep
>> track of an initial investigation.
>>
>> Can I ask everyone to jump on it adding their own knowledge and
>>suggestions?
>>
>
>As we're speaking of modularisation I'm reviving this thread. Please
>see the ticket https://issues.apache.org/jira/browse/OAK-3134 for details.
>
>I will file separate tickets for the actual actions, around moving each
>individual functionality to own bundle if no one will object.
>
>Cheers
>Davide
>
>
Re: oak-run 50MB
Posted by Davide Giannella <da...@apache.org>.
On 22/07/2015 10:23, Davide Giannella wrote:
> On 20/07/2015 14:12, Julian Sedding wrote:
>> +1 It sounds sensible to split this up. It seems that it has evolved
>> into a collection of functionality that shares mostly the fact that
>> they are run on the command line. I would like to see the logic used
>> to bootstrap various Oak setups based on command line parameters to be
>> extracted and re-used.
> I've created https://issues.apache.org/jira/browse/OAK-3134 to keep
> track of an initial investigation.
>
> Can I ask everyone to jump on it adding their own knowledge and suggestions?
>
As we're speaking of modularisation I'm reviving this thread. Please
see the ticket https://issues.apache.org/jira/browse/OAK-3134 for details.
I will file separate tickets for the actual actions, around moving each
individual functionality to own bundle if no one will object.
Cheers
Davide
Re: oak-run 50MB
Posted by Davide Giannella <da...@apache.org>.
On 20/07/2015 14:12, Julian Sedding wrote:
> +1 It sounds sensible to split this up. It seems that it has evolved
> into a collection of functionality that shares mostly the fact that
> they are run on the command line. I would like to see the logic used
> to bootstrap various Oak setups based on command line parameters to be
> extracted and re-used.
I've created https://issues.apache.org/jira/browse/OAK-3134 to keep
track of an initial investigation.
Can I ask everyone to jump on it adding their own knowledge and suggestions?
Cheers
Davide
Re: oak-run 50MB
Posted by Julian Sedding <js...@gmail.com>.
+1 It sounds sensible to split this up. It seems that it has evolved
into a collection of functionality that shares mostly the fact that
they are run on the command line. I would like to see the logic used
to bootstrap various Oak setups based on command line parameters to be
extracted and re-used.
Regards
Julian
On Mon, Jul 20, 2015 at 2:39 PM, Davide Giannella <da...@apache.org> wrote:
> Hello folks,
>
> oak-run is 50MB+. Shall we look into how to potentially split what this
> module provides in something more precise and maybe delete some parts no
> longer used/supported?
>
> Off the top of my head oak-run provides:
>
> - utility tools for segment, mongo and datastore
> - micro benchmarking
> - scalability benchmarking
> - rough http server
>
> So the question is: shall we look into the details for splitting it into
> smaller modules? I don't think oak-run is an appropriate name either.
>
> Davide
>
>