On 27.5.14 5:33 , Jukka Zitting wrote:
Hi,
On Tue, May 27, 2014 at 11:24 AM, Michael Dürig 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 wou
Hi,
On Tue, May 27, 2014 at 11:24 AM, Michael Dürig 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 woul
On 27.5.14 5:13 , Jukka Zitting wrote:
Hi,
On Tue, May 27, 2014 at 10:53 AM, Michael Dürig 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-22
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
t
Hi,
On Tue, May 27, 2014 at 10:53 AM, Michael Dürig 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 th
On 27.5.14 4:48 , Jukka Zitting wrote:
Hi,
On Tue, May 27, 2014 at 10:36 AM, Michael Dürig 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 c
Hi,
On Tue, May 27, 2014 at 10:36 AM, Michael Dürig 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?
Hehe, yes, I constantly mix these two up ;-)
Thanks
Felix
Am 26.05.2014 um 22:51 schrieb Carsten Ziegeler :
> 2014-05-27 3:37 GMT+02:00 Felix Meschberger :
>
>> That sounds like an excellent idea.
>>
>> You might want to leverage the Sling Launchpad for this (along with OSGi
>> Installer). Alt
On 27.5.14 4:26 , Jukka Zitting wrote:
Hi,
On Tue, May 27, 2014 at 9:47 AM, Michael Dürig 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, de
Hi,
On Tue, May 27, 2014 at 9:47 AM, Michael Dürig 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 sca
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
On 27.5.14 3:33 , Jukka Zitting wrote:
Hi,
On Mon, May 26, 2014 at 9:12 AM, Michael Dürig 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 in
Hi,
On Mon, May 26, 2014 at 9:12 AM, Michael Dürig 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 mode
2014-05-27 3:37 GMT+02:00 Felix Meschberger :
> 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
Hi
Am 26.05.2014 um 06:12 schrieb Michael Dürig :
>
> 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 get
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
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
M
On Fri, May 23, 2014 at 12:05 AM, Marcel Reutegger 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
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 ne
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
20 matches
Mail list logo
