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 Chetan Mehrotra <ch...@gmail.com> on 2014/05/22 18:37:57 UTC
Embedding Groovy in oak-run for Oak Shell (OAK-1805)
Hi,
Currently Marcel has implemented a Java based basic shell access to
Oak in OAK-1805. I have reworked the logic and used Groovysh [1] to
provide a richer shell experience.
* The shell is branded for Oak
* Makes use of all the features provided by groovysh command
completion, history, colored output etc
* Full power of Groovy!
* Most of current command implemented by Marcel ported
* Ability to execute script at command line itself similar to Mongo shell
Things to considers
* Requires groovy jar to be embedded increasing the size ~6 mb
* Some of commands need to be written in groovy
Sample output
{noformat}
$ java -jar oak-run-1.1-SNAPSHOT.jar console mongodb://localhost:27017/oak
Apache Jackrabbit Oak 1.1-SNAPSHOT
Jackrabbit Oak Shell (Apache Jackrabbit Oak 1.1-SNAPSHOT, JVM: 1.6.0_45)
Type ':help' or ':h' for help.
-------------------------------------------------------------------------------------------------------------------
/> ls
:async
apps
bin
etc
/> cd
:async apps bin etc
home jcr:system
libs oak:index rep:policy rep:repoPolicy
system tmp
var
/> cd var
/var>
{noformat}
Adding groovy would increase size of oak-run by ~6 mb (from 27 to 34)
and also requires some of the code logic to be implemented in Groovy,
So would it be ok to apply the patch
Thoughts?
Chetan Mehrotra
PS: Details are also provided in bug note
[1] http://groovy.codehaus.org/Groovy+Shell
[2] http://groovy.codehaus.org/JSR-223+access+to+other+JVM+languages
Re: Embedding Groovy in oak-run for Oak Shell (OAK-1805)
Posted by Marcel Reutegger <mr...@adobe.com>.
Hi,
the different lucene versions are indeed a problem. currently we use
a separate profile in oak-run to create an oak specific artifact with
lucene 4.x.
I think for now we should just add the new dependency and then think
aboout splitting up the module if necessary.
other opinions?
Regards
Marcel
On 23/05/14 06:59, "Chetan Mehrotra" <ch...@gmail.com> wrote:
>On Fri, May 23, 2014 at 12:05 AM, Marcel Reutegger <mr...@adobe.com>
>wrote:
>> but the
>> resulting jar file is indeed quite big. Do we really need
>> all the jars we currently embed?
>
>Yes currently we are embedding quite a few jars. Looking at oak-run I
>see it embed following major types of deps
>1. JR2 jars (required for benchmark and also upgrade)
>2. Lucene 3.6.x jars for JR2
>3. H2 and related DBCP jars for RDB
>4. Oak jars
>5. Logback/jopt etc required for standalone usage
>6. Now groovy
>
>> Alternatively we may
>> want to consider a new module. E.g. oak-console with only
>> the required jar files to run the console.
>
>Might be better to go this way as we anyway have to start using Lucene
>4.x to allow say a command to dump the Lucene directory content. Given
>oak-run would be used for benchmark and upgrade it has to package Jr2
>and Lucene 3.6.x. So for pure oak related feature set we might require
>a new module.
>
>Chetan Mehrotra
Re: Embedding Groovy in oak-run for Oak Shell (OAK-1805)
Posted by Chetan Mehrotra <ch...@gmail.com>.
On Fri, May 23, 2014 at 12:05 AM, Marcel Reutegger <mr...@adobe.com> wrote:
> but the
> resulting jar file is indeed quite big. Do we really need
> all the jars we currently embed?
Yes currently we are embedding quite a few jars. Looking at oak-run I
see it embed following major types of deps
1. JR2 jars (required for benchmark and also upgrade)
2. Lucene 3.6.x jars for JR2
3. H2 and related DBCP jars for RDB
4. Oak jars
5. Logback/jopt etc required for standalone usage
6. Now groovy
> Alternatively we may
> want to consider a new module. E.g. oak-console with only
> the required jar files to run the console.
Might be better to go this way as we anyway have to start using Lucene
4.x to allow say a command to dump the Lucene directory content. Given
oak-run would be used for benchmark and upgrade it has to package Jr2
and Lucene 3.6.x. So for pure oak related feature set we might require
a new module.
Chetan Mehrotra
Re: Embedding Groovy in oak-run for Oak Shell (OAK-1805)
Posted by Marcel Reutegger <mr...@adobe.com>.
Hi Chetan,
I gave it a try and it looks very nice. Much better
experience than with the basic shell I started.
I¹m not too worried about the size increase, but the
resulting jar file is indeed quite big. Do we really need
all the jars we currently embed? Alternatively we may
want to consider a new module. E.g. oak-console with only
the required jar files to run the console.
Regards
Marcel
On 22/05/14 18:37, "Chetan Mehrotra" <ch...@gmail.com> wrote:
>Hi,
>
>Currently Marcel has implemented a Java based basic shell access to
>Oak in OAK-1805. I have reworked the logic and used Groovysh [1] to
>provide a richer shell experience.
>
>
>* The shell is branded for Oak
>* Makes use of all the features provided by groovysh command
>completion, history, colored output etc
>* Full power of Groovy!
>* Most of current command implemented by Marcel ported
>* Ability to execute script at command line itself similar to Mongo shell
>
>Things to considers
>* Requires groovy jar to be embedded increasing the size ~6 mb
>* Some of commands need to be written in groovy
>
>Sample output
>
>{noformat}
>$ java -jar oak-run-1.1-SNAPSHOT.jar console mongodb://localhost:27017/oak
>Apache Jackrabbit Oak 1.1-SNAPSHOT
>Jackrabbit Oak Shell (Apache Jackrabbit Oak 1.1-SNAPSHOT, JVM: 1.6.0_45)
>Type ':help' or ':h' for help.
>--------------------------------------------------------------------------
>-----------------------------------------
>/> ls
>:async
>apps
>bin
>etc
>/> cd
>:async apps bin etc
>home jcr:system
>libs oak:index rep:policy rep:repoPolicy
>system tmp
>var
>/> cd var
>/var>
>{noformat}
>
>Adding groovy would increase size of oak-run by ~6 mb (from 27 to 34)
>and also requires some of the code logic to be implemented in Groovy,
>So would it be ok to apply the patch
>
>Thoughts?
>
>Chetan Mehrotra
>PS: Details are also provided in bug note
>[1] http://groovy.codehaus.org/Groovy+Shell
>[2] http://groovy.codehaus.org/JSR-223+access+to+other+JVM+languages
Re: Embedding Groovy in oak-run for Oak Shell (OAK-1805)
Posted by Chetan Mehrotra <ch...@gmail.com>.
For me more than size the problem is usage of Lucene To use full power
of Oak we need to include Lucene 4.x and thus would need to drop JR2.
So probably have two modules
1. oak-run - server, benchmarking, console, debugging, scalability, backup
2. oak-migration - upgrade, jr2 specific benchmarking (possibly by
including the oak-run classes only
Various sub features in oak-run together do not still add much
complexity and are neatly seperated via various main methods. So
should be ok for now
Chetan Mehrotra
On Tue, May 27, 2014 at 7:17 PM, Michael Dürig <md...@apache.org> wrote:
>
>
> On 27.5.14 3:33 , Jukka Zitting wrote:
>>
>> Hi,
>>
>> On Mon, May 26, 2014 at 9:12 AM, Michael Dürig <md...@apache.org> wrote:
>>>
>>> Apart from that - and this is probably a separate discussion - I also
>>> think
>>> we should split oak-run up as it is getting too heavy.
>>
>>
>> Too heavy in which way?
>
>
> Functionality wise. It is growing into a "chief cook and bottle washer". It
> already does backup, benchmarking, simple console, debugging, server,
> upgrade, and scalability testing. There is also the Groovy Console coming
> along and probably a couple of repair tools. Also I'd prefer Scala or Frege
> to Groovy. Others probably Clojure or Jython.
>
> Michael
Re: Embedding Groovy in oak-run for Oak Shell (OAK-1805)
Posted by Chetan Mehrotra <ch...@gmail.com>.
fwiw I would (for a change :) ) would like to avoid OSGi here and keep
things as they are for following reasons
1. JR2 is not OSGi friendly and we use some of the internal classes
for upgrade which would be problematic in OSGI
2. For debug and console we rely on some non exported packages. Using
them in OSGi would again be tricky
Chetan Mehrotra
On Tue, May 27, 2014 at 8:23 PM, Michael Dürig <md...@apache.org> wrote:
>
>
> On 27.5.14 4:48 , Jukka Zitting wrote:
>>
>> Hi,
>>
>> On Tue, May 27, 2014 at 10:36 AM, Michael Dürig <md...@apache.org>
>> wrote:
>> We can turn the jar in to an OSGi container, but why not ship
>> everything everything we can by default?
>
>
> Because
>
>
>>> increase flexibility, test and showcase OSGi readiness of Oak,
>>> resolve version conflicts (e.g. Lucene), let others easily plug in
>>> their own stuff (e.g scripting language through JSR-223).
>
>
> Michael
Re: Embedding Groovy in oak-run for Oak Shell (OAK-1805)
Posted by Michael Dürig <md...@apache.org>.
On 27.5.14 5:33 , Jukka Zitting wrote:
> Hi,
>
> On Tue, May 27, 2014 at 11:24 AM, Michael Dürig <md...@apache.org> wrote:
>> Users needn't be aware of the OSGi container inside if they just want to
>> quickly try something out. Running with e.g. the benchmark option would
>> still run the benchmark suite. The difference would be that in the
>> background we would start an OSGi container, deploy the relevant bundles and
>> off we go.
>
> So if I understand correctly, you wouldn't actually "split oak-run up"
> but rather just refactor it internally? It would still have all the
> current functionality, just packaged in a way that makes
> deployment-/runtime customizations/extensions easier (and avoids
> things like the Lucene version conflict).
Right. My initial idea was probably a bit blurry and clumsily brought
forward but this is what it comes down to.
Michael
>
> BR,
>
> Jukka Zitting
>
Re: Embedding Groovy in oak-run for Oak Shell (OAK-1805)
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, May 27, 2014 at 11:24 AM, Michael Dürig <md...@apache.org> wrote:
> Users needn't be aware of the OSGi container inside if they just want to
> quickly try something out. Running with e.g. the benchmark option would
> still run the benchmark suite. The difference would be that in the
> background we would start an OSGi container, deploy the relevant bundles and
> off we go.
So if I understand correctly, you wouldn't actually "split oak-run up"
but rather just refactor it internally? It would still have all the
current functionality, just packaged in a way that makes
deployment-/runtime customizations/extensions easier (and avoids
things like the Lucene version conflict).
BR,
Jukka Zitting
Re: Embedding Groovy in oak-run for Oak Shell (OAK-1805)
Posted by Michael Dürig <md...@apache.org>.
On 27.5.14 5:13 , Jukka Zitting wrote:
> Hi,
>
> On Tue, May 27, 2014 at 10:53 AM, Michael Dürig <md...@apache.org> wrote:
>> Because
>>
>>>> increase flexibility, test and showcase OSGi readiness of Oak,
>>>> resolve version conflicts (e.g. Lucene), let others easily plug in
>>>> their own stuff (e.g scripting language through JSR-223).
>
> Fair enough, but doing this does introduce a major entry barrier to
> just quickly trying things out, which IMHO is a big problem.
>
> I have no objections to shipping an OSGi container if people find that
> useful, but I do object to dropping functionality because of that. How
> about doing something like that in a separate component and leave
> oak-run as-is?
Users needn't be aware of the OSGi container inside if they just want to
quickly try something out. Running with e.g. the benchmark option would
still run the benchmark suite. The difference would be that in the
background we would start an OSGi container, deploy the relevant bundles
and off we go. We could even add all of the bundles all the time for
simplicity. This still serves all the purposes I outlined above. I.e.
easy to add own stuff and so on...
Michael
Re: Embedding Groovy in oak-run for Oak Shell (OAK-1805)
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, May 27, 2014 at 10:53 AM, Michael Dürig <md...@apache.org> wrote:
> Because
>
>>> increase flexibility, test and showcase OSGi readiness of Oak,
>>> resolve version conflicts (e.g. Lucene), let others easily plug in
>>> their own stuff (e.g scripting language through JSR-223).
Fair enough, but doing this does introduce a major entry barrier to
just quickly trying things out, which IMHO is a big problem.
I have no objections to shipping an OSGi container if people find that
useful, but I do object to dropping functionality because of that. How
about doing something like that in a separate component and leave
oak-run as-is?
BR,
Jukka Zitting
Re: Embedding Groovy in oak-run for Oak Shell (OAK-1805)
Posted by Michael Dürig <md...@apache.org>.
On 27.5.14 4:48 , Jukka Zitting wrote:
> Hi,
>
> On Tue, May 27, 2014 at 10:36 AM, Michael Dürig <md...@apache.org> wrote:
> We can turn the jar in to an OSGi container, but why not ship
> everything everything we can by default?
Because
>> increase flexibility, test and showcase OSGi readiness of Oak,
>> resolve version conflicts (e.g. Lucene), let others easily plug in
>> their own stuff (e.g scripting language through JSR-223).
Michael
Re: Embedding Groovy in oak-run for Oak Shell (OAK-1805)
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, May 27, 2014 at 10:36 AM, Michael Dürig <md...@apache.org> wrote:
> This is not about different jars but about setting it up as a OSGi container
> into which the respective bundles could get deployed.
We can turn the jar in to an OSGi container, but why not ship
everything everything we can by default?
I definitely want to avoid the situation like in Sling where getting
the software to work requires non-trivial compilation of multiple
different components. I should be able to simply download the latest
version of Oak and have it working right out of the box with no extra
steps.
BR,
Jukka Zitting
Re: Embedding Groovy in oak-run for Oak Shell (OAK-1805)
Posted by Michael Dürig <md...@apache.org>.
On 27.5.14 4:26 , Jukka Zitting wrote:
> Hi,
>
> On Tue, May 27, 2014 at 9:47 AM, Michael Dürig <md...@apache.org> wrote:
>> On 27.5.14 3:33 , Jukka Zitting wrote:
>>> Too heavy in which way?
>>
>> Functionality wise. It is growing into a "chief cook and bottle washer". It
>> already does backup, benchmarking, simple console, debugging, server,
>> upgrade, and scalability testing.
>
> How would splitting those responsibilities to different jars make any
> difference? I.e. what's the essential difference between:
This is not about different jars but about setting it up as a OSGi
container into which the respective bundles could get deployed. This
would certainly increase complexity but also increase flexibility, test
and showcase OSGi readiness of Oak, resolve version conflicts (e.g.
Lucene), let others easily plug in their own stuff (e.g scripting
language through JSR-223).
Michael
Re: Embedding Groovy in oak-run for Oak Shell (OAK-1805)
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, May 27, 2014 at 9:47 AM, Michael Dürig <md...@apache.org> wrote:
> On 27.5.14 3:33 , Jukka Zitting wrote:
>> Too heavy in which way?
>
> Functionality wise. It is growing into a "chief cook and bottle washer". It
> already does backup, benchmarking, simple console, debugging, server,
> upgrade, and scalability testing.
How would splitting those responsibilities to different jars make any
difference? I.e. what's the essential difference between:
$ java -jar oak-run.jar backup ...
and
$ java -jar oak-backup.jar ...
I rather prefer the former as it gives me everything in one package
and reduces maintenance overhead.
BR,
Jukka Zitting
Re: Embedding Groovy in oak-run for Oak Shell (OAK-1805)
Posted by Michael Dürig <md...@apache.org>.
On 27.5.14 3:33 , Jukka Zitting wrote:
> Hi,
>
> On Mon, May 26, 2014 at 9:12 AM, Michael Dürig <md...@apache.org> wrote:
>> Apart from that - and this is probably a separate discussion - I also think
>> we should split oak-run up as it is getting too heavy.
>
> Too heavy in which way?
Functionality wise. It is growing into a "chief cook and bottle washer".
It already does backup, benchmarking, simple console, debugging, server,
upgrade, and scalability testing. There is also the Groovy Console
coming along and probably a couple of repair tools. Also I'd prefer
Scala or Frege to Groovy. Others probably Clojure or Jython.
Michael
Re: Embedding Groovy in oak-run for Oak Shell (OAK-1805)
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Mon, May 26, 2014 at 9:12 AM, Michael Dürig <md...@apache.org> wrote:
> Apart from that - and this is probably a separate discussion - I also think
> we should split oak-run up as it is getting too heavy.
Too heavy in which way? If you refer to the size of the jar, I fail to
see how it's relevant given modern network speeds and disk sizes.
BR,
Jukka Zitting
Re: Embedding Groovy in oak-run for Oak Shell (OAK-1805)
Posted by Felix Meschberger <fm...@adobe.com>.
Hehe, yes, I constantly mix these two up ;-)
Thanks
Felix
Am 26.05.2014 um 22:51 schrieb Carsten Ziegeler <cz...@apache.org>:
> 2014-05-27 3:37 GMT+02:00 Felix Meschberger <fm...@adobe.com>:
>
>> That sounds like an excellent idea.
>>
>> You might want to leverage the Sling Launchpad for this (along with OSGi
>> Installer). Alternatively, and probably actually easier for you to define
>> the modules/blocks, Apache Kafka:
>
>
> I guess you mean Apache Karaf :)
>
> Regards
> Carsten
>
>
>> Kafka has the notion of "Features" which are described in simple XML terms
>> and which allow to dynamically install these features along with
>> dependencies.
>>
>> Regards
>> Felix
>>
>>>
>>> Michael
>>>
>>> On 22.5.14 6:37 , Chetan Mehrotra wrote:
>>>> Hi,
>>>>
>>>> Currently Marcel has implemented a Java based basic shell access to
>>>> Oak in OAK-1805. I have reworked the logic and used Groovysh [1] to
>>>> provide a richer shell experience.
>>>>
>>>>
>>>> * The shell is branded for Oak
>>>> * Makes use of all the features provided by groovysh command
>>>> completion, history, colored output etc
>>>> * Full power of Groovy!
>>>> * Most of current command implemented by Marcel ported
>>>> * Ability to execute script at command line itself similar to Mongo
>> shell
>>>>
>>>> Things to considers
>>>> * Requires groovy jar to be embedded increasing the size ~6 mb
>>>> * Some of commands need to be written in groovy
>>>>
>>>> Sample output
>>>>
>>>> {noformat}
>>>> $ java -jar oak-run-1.1-SNAPSHOT.jar console
>> mongodb://localhost:27017/oak
>>>> Apache Jackrabbit Oak 1.1-SNAPSHOT
>>>> Jackrabbit Oak Shell (Apache Jackrabbit Oak 1.1-SNAPSHOT, JVM: 1.6.0_45)
>>>> Type ':help' or ':h' for help.
>>>>
>> -------------------------------------------------------------------------------------------------------------------
>>>> /> ls
>>>> :async
>>>> apps
>>>> bin
>>>> etc
>>>> /> cd
>>>> :async apps bin etc
>>>> home jcr:system
>>>> libs oak:index rep:policy rep:repoPolicy
>>>> system tmp
>>>> var
>>>> /> cd var
>>>> /var>
>>>> {noformat}
>>>>
>>>> Adding groovy would increase size of oak-run by ~6 mb (from 27 to 34)
>>>> and also requires some of the code logic to be implemented in Groovy,
>>>> So would it be ok to apply the patch
>>>>
>>>> Thoughts?
>>>>
>>>> Chetan Mehrotra
>>>> PS: Details are also provided in bug note
>>>> [1] http://groovy.codehaus.org/Groovy+Shell
>>>> [2] http://groovy.codehaus.org/JSR-223+access+to+other+JVM+languages
>>>>
>>
>>
>
>
> --
> Carsten Ziegeler
> cziegeler@apache.org
Re: Embedding Groovy in oak-run for Oak Shell (OAK-1805)
Posted by Carsten Ziegeler <cz...@apache.org>.
2014-05-27 3:37 GMT+02:00 Felix Meschberger <fm...@adobe.com>:
> That sounds like an excellent idea.
>
> You might want to leverage the Sling Launchpad for this (along with OSGi
> Installer). Alternatively, and probably actually easier for you to define
> the modules/blocks, Apache Kafka:
I guess you mean Apache Karaf :)
Regards
Carsten
> Kafka has the notion of "Features" which are described in simple XML terms
> and which allow to dynamically install these features along with
> dependencies.
>
> Regards
> Felix
>
> >
> > Michael
> >
> > On 22.5.14 6:37 , Chetan Mehrotra wrote:
> >> Hi,
> >>
> >> Currently Marcel has implemented a Java based basic shell access to
> >> Oak in OAK-1805. I have reworked the logic and used Groovysh [1] to
> >> provide a richer shell experience.
> >>
> >>
> >> * The shell is branded for Oak
> >> * Makes use of all the features provided by groovysh command
> >> completion, history, colored output etc
> >> * Full power of Groovy!
> >> * Most of current command implemented by Marcel ported
> >> * Ability to execute script at command line itself similar to Mongo
> shell
> >>
> >> Things to considers
> >> * Requires groovy jar to be embedded increasing the size ~6 mb
> >> * Some of commands need to be written in groovy
> >>
> >> Sample output
> >>
> >> {noformat}
> >> $ java -jar oak-run-1.1-SNAPSHOT.jar console
> mongodb://localhost:27017/oak
> >> Apache Jackrabbit Oak 1.1-SNAPSHOT
> >> Jackrabbit Oak Shell (Apache Jackrabbit Oak 1.1-SNAPSHOT, JVM: 1.6.0_45)
> >> Type ':help' or ':h' for help.
> >>
> -------------------------------------------------------------------------------------------------------------------
> >> /> ls
> >> :async
> >> apps
> >> bin
> >> etc
> >> /> cd
> >> :async apps bin etc
> >> home jcr:system
> >> libs oak:index rep:policy rep:repoPolicy
> >> system tmp
> >> var
> >> /> cd var
> >> /var>
> >> {noformat}
> >>
> >> Adding groovy would increase size of oak-run by ~6 mb (from 27 to 34)
> >> and also requires some of the code logic to be implemented in Groovy,
> >> So would it be ok to apply the patch
> >>
> >> Thoughts?
> >>
> >> Chetan Mehrotra
> >> PS: Details are also provided in bug note
> >> [1] http://groovy.codehaus.org/Groovy+Shell
> >> [2] http://groovy.codehaus.org/JSR-223+access+to+other+JVM+languages
> >>
>
>
--
Carsten Ziegeler
cziegeler@apache.org
Re: Embedding Groovy in oak-run for Oak Shell (OAK-1805)
Posted by Felix Meschberger <fm...@adobe.com>.
Hi
Am 26.05.2014 um 06:12 schrieb Michael Dürig <md...@apache.org>:
>
> Hi,
>
> Not embarking on the language war train, I think this is a good addition and we should go forward with it.
>
> Apart from that - and this is probably a separate discussion - I also think we should split oak-run up as it is getting too heavy. Couldn't we make it into a rather bare bone OSGi container where users could select what to run with on the command line (package manager like, that is)? E.g. whether to have benchmarks, scalability, server, ... With such a setup we could also make the languages a scripting console supports pluggable while at the same time keeping the oak-run module clean and mean.
That sounds like an excellent idea.
You might want to leverage the Sling Launchpad for this (along with OSGi Installer). Alternatively, and probably actually easier for you to define the modules/blocks, Apache Kafka: Kafka has the notion of "Features" which are described in simple XML terms and which allow to dynamically install these features along with dependencies.
Regards
Felix
>
> Michael
>
> On 22.5.14 6:37 , Chetan Mehrotra wrote:
>> Hi,
>>
>> Currently Marcel has implemented a Java based basic shell access to
>> Oak in OAK-1805. I have reworked the logic and used Groovysh [1] to
>> provide a richer shell experience.
>>
>>
>> * The shell is branded for Oak
>> * Makes use of all the features provided by groovysh command
>> completion, history, colored output etc
>> * Full power of Groovy!
>> * Most of current command implemented by Marcel ported
>> * Ability to execute script at command line itself similar to Mongo shell
>>
>> Things to considers
>> * Requires groovy jar to be embedded increasing the size ~6 mb
>> * Some of commands need to be written in groovy
>>
>> Sample output
>>
>> {noformat}
>> $ java -jar oak-run-1.1-SNAPSHOT.jar console mongodb://localhost:27017/oak
>> Apache Jackrabbit Oak 1.1-SNAPSHOT
>> Jackrabbit Oak Shell (Apache Jackrabbit Oak 1.1-SNAPSHOT, JVM: 1.6.0_45)
>> Type ':help' or ':h' for help.
>> -------------------------------------------------------------------------------------------------------------------
>> /> ls
>> :async
>> apps
>> bin
>> etc
>> /> cd
>> :async apps bin etc
>> home jcr:system
>> libs oak:index rep:policy rep:repoPolicy
>> system tmp
>> var
>> /> cd var
>> /var>
>> {noformat}
>>
>> Adding groovy would increase size of oak-run by ~6 mb (from 27 to 34)
>> and also requires some of the code logic to be implemented in Groovy,
>> So would it be ok to apply the patch
>>
>> Thoughts?
>>
>> Chetan Mehrotra
>> PS: Details are also provided in bug note
>> [1] http://groovy.codehaus.org/Groovy+Shell
>> [2] http://groovy.codehaus.org/JSR-223+access+to+other+JVM+languages
>>
Re: Embedding Groovy in oak-run for Oak Shell (OAK-1805)
Posted by Michael Dürig <md...@apache.org>.
Hi,
Not embarking on the language war train, I think this is a good addition
and we should go forward with it.
Apart from that - and this is probably a separate discussion - I also
think we should split oak-run up as it is getting too heavy. Couldn't we
make it into a rather bare bone OSGi container where users could select
what to run with on the command line (package manager like, that is)?
E.g. whether to have benchmarks, scalability, server, ... With such a
setup we could also make the languages a scripting console supports
pluggable while at the same time keeping the oak-run module clean and mean.
Michael
On 22.5.14 6:37 , Chetan Mehrotra wrote:
> Hi,
>
> Currently Marcel has implemented a Java based basic shell access to
> Oak in OAK-1805. I have reworked the logic and used Groovysh [1] to
> provide a richer shell experience.
>
>
> * The shell is branded for Oak
> * Makes use of all the features provided by groovysh command
> completion, history, colored output etc
> * Full power of Groovy!
> * Most of current command implemented by Marcel ported
> * Ability to execute script at command line itself similar to Mongo shell
>
> Things to considers
> * Requires groovy jar to be embedded increasing the size ~6 mb
> * Some of commands need to be written in groovy
>
> Sample output
>
> {noformat}
> $ java -jar oak-run-1.1-SNAPSHOT.jar console mongodb://localhost:27017/oak
> Apache Jackrabbit Oak 1.1-SNAPSHOT
> Jackrabbit Oak Shell (Apache Jackrabbit Oak 1.1-SNAPSHOT, JVM: 1.6.0_45)
> Type ':help' or ':h' for help.
> -------------------------------------------------------------------------------------------------------------------
> /> ls
> :async
> apps
> bin
> etc
> /> cd
> :async apps bin etc
> home jcr:system
> libs oak:index rep:policy rep:repoPolicy
> system tmp
> var
> /> cd var
> /var>
> {noformat}
>
> Adding groovy would increase size of oak-run by ~6 mb (from 27 to 34)
> and also requires some of the code logic to be implemented in Groovy,
> So would it be ok to apply the patch
>
> Thoughts?
>
> Chetan Mehrotra
> PS: Details are also provided in bug note
> [1] http://groovy.codehaus.org/Groovy+Shell
> [2] http://groovy.codehaus.org/JSR-223+access+to+other+JVM+languages
>