Re: [Proposal] Karaf with embedded JVM

2016-10-31 Thread Jean-Baptiste Onofré
Fair enough. Please, create a Jira to do this improvement. Regards JB On 10/31/2016 03:38 PM, Johannes Utzig wrote: It is true that it is very possible to just add this to setenv, but it is actually not all that easy to do if you take into account all the edge cases with spaces in paths,

Re: [Proposal] Karaf with embedded JVM

2016-10-31 Thread Johannes Utzig
It is true that it is very possible to just add this to setenv, but it is actually not all that easy to do if you take into account all the edge cases with spaces in paths, current working directory and so on. Shipping a solution directly with karaf might make this easier for other people. For

Re: [Proposal] Karaf with embedded JVM

2016-10-31 Thread Jean-Baptiste Onofré
I see your point, but as you will provide your own distribution, you can always override the default scripts with your definition and let the user with bin/setenv. My point is that what you are proposing make sense but very specific to your use case. You can create a Jira with such

Re: [Proposal] Karaf with embedded JVM

2016-10-31 Thread Sascha Vogt
Well, if you provide a product for someone else you need to clearly separate between files you ship and files the user is allowed to modify. We want to keep the setenv empty so the user can adjust things there and we don't have to worry during upgrades (at least not that much to worry, of course

Re: [Proposal] Karaf with embedded JVM

2016-10-31 Thread Jean-Baptiste Onofré
Ah, I understand now. It was also the purpose of the bin/setenv to be able to override Karaf defined location (like the Java). I'm not against to use $KARAF_HOME/java folder as JAVA_HOME if it's provided, but I don't see a huge value compared to define it in bin/setenv. Regards JB On

Re: [Proposal] Karaf with embedded JVM

2016-10-31 Thread Sascha Vogt
@Achim / @JB: Sorry for the misunderstanding. I didn't mean to ship a binary distribution with a JVM embedded, I meant to modify the scripts so that Karaf by default prefers a JVM if (and only if) one is present in a certain directory within KARAF_HOME. In case none is there, just follow the

Re: [Proposal] Karaf with embedded JVM

2016-10-31 Thread Achim Nierbeck
ah ... ok so I missed that part then ... :) 2016-10-31 13:47 GMT+01:00 Fabian Lange : > Hi Achim, > Karaf does not need to ship this and can leave those questions up to the > distributors using the feature. > > Fabian > > > On Mon, Oct 31, 2016 at 1:43 PM, Achim

Re: [Proposal] Karaf with embedded JVM

2016-10-31 Thread Jean-Baptiste Onofré
Hi Sascha, An "embedded" distribution of Karaf with JVM is a good idea. It sounds a bit like a docker image ;) However, unfortunately, I'm not sure it would be possible to provide such distribution directly at Karaf due to legal constraint. We can provide a script (like a dockerfiles I

Re: [Proposal] Karaf with embedded JVM

2016-10-31 Thread Fabian Lange
Hi Achim, Karaf does not need to ship this and can leave those questions up to the distributors using the feature. Fabian On Mon, Oct 31, 2016 at 1:43 PM, Achim Nierbeck wrote: > hmm ... even though I like the idea ... what Implications does it have for > > a) is it

Re: [Proposal] Karaf with embedded JVM

2016-10-31 Thread Achim Nierbeck
hmm ... even though I like the idea ... what Implications does it have for a) is it compliant with the ASF license? b) how about different JVMs and different processors ... don't we need to provide it for intel, arm, ppc? regards, Achim 2016-10-31 13:39 GMT+01:00 Fabian Lange

Re: [Proposal] Karaf with embedded JVM

2016-10-31 Thread Fabian Lange
Hi Sascha, i very much like the idea. It can be a very lightweight enhancement to the start scripts, because what it basically does is that it defines a "search list" for "JAVA_HOME". Maybe it is sufficient to add that feature to the scripts and every distributor can customize the directory they

[Proposal] Karaf with embedded JVM

2016-10-31 Thread Sascha Vogt
Hi all, we're workig on a Karaf based product and have the requirement to use the JVM we ship with the product. We thought that might also be interesting to others, so we wanted to share our proposal / current implementation (and are also willing to provide the required patches). Main idea is to