Hi Simon,
oh yes, I will probably publish a couple of EIK SNAPSHOTs, if you can
test it, it would be great.
Thanks !
Regards
JB
On 2014-02-04 00:16, siwatson wrote:
Hi JB,
Absolutely no apology needed. I only have to look at the number of
replies
you write on this forum to realise how busy
Hi JB,
Absolutely no apology needed. I only have to look at the number of replies
you write on this forum to realise how busy you are! If you are able to find
some time to review the status of EIK then I would be very grateful and I
think it would be useful to other developers. If I can help you t
Has anyone else experienced
"[ERROR] Failed to execute goal on project org.apache.karaf.shell.console:
Could not resolve dependencies for project
org.apache.karaf.shell:org.apache.karaf.shell.console:bundle:2.3.4-SNAPSHOT:
Could not find artifact
org.eclipse.osgi:org.eclipse.osgi:jar:3.7.0.v201101
Hi Simon,
It's my fault, I'm late on EIK release (busy with some releases, and
fixes).
I will review your Jira later today and tomorrow. I will keep you
posted.
Don't hesitate to ping me, please.
Regards
JB
On 2014-02-03 20:19, siwatson wrote:
Hi, I posted this to the users list last week
Hi, I posted this to the users list last week but didn't get any feedback,
and maybe it's better suited to the dev list anyway...
I'm hoping to migrate from Eclipse Virgo to Apache Karaf. Until now, we've
relied on Virgo's Eclipse IDE tooling to create bundles and deploy to a
local dev server, giv
As I mentioned earlier, I am not really interested in the release
version per se, but primary in the time to market and secondarily on
what it means in terms of maintenance.
As in all things, the key is balance.
Release often is guaranteed way of delivering value to users,
releasing too often may
So, start 4.x now! :) Release early, release often.
On Mon, Feb 3, 2014 at 12:09 PM, wrote:
> Good points Ioannis,
>
> my point is just about the "message" for we send to the users and community.
>
> You are right, it took long time to release Karaf 3.0.0, but it doesn't mean
> that it would
Good points Ioannis,
my point is just about the "message" for we send to the users and
community.
You are right, it took long time to release Karaf 3.0.0, but it doesn't
mean that it would be the same for 4.0.0.
My point is just to send a message for users/community like: "hey, we
did deep
> I would plan this for Karaf 4.0.0, even if it's internal.
While I don't have a strong objection on having it as part of a 4.x
release, that would mean that it will get pushed back way into the
future.
3.x release took us almost 3 years to get out and we stalled 2.3.x for
1.5 year in favour of 3.
I would do #2 first, even in the next patch releases. Having the feature
defined doesn’t cause any problems at all and that way external projects can
start relying on it, even if it is installed by default.
Dan
On Feb 3, 2014, at 9:52 AM, Ioannis Canellos wrote:
> A while back we discuss
-1
I would plan this for Karaf 4.0.0, even if it's internal.
It's an important jump internally in Karaf, and should be addressed in a
major release.
We just release Karaf 3.0.0, and we have to let people and other
projects to move smoothly (even if as you said, you should not have impact).
A while back we discussed about migration from Blueprint to SCR and we
all agreed that it was a nice thing to do.
The question is how to do it, without making maintenance hard and also
without taking ages to deliver this new feature.
I think that this should be done in 3 steps:
i) Migrate from Bl
KARAF - Monday, February 3, 2014
18 Issues with Attachments
(sorted oldest to newest)
[KARAF-222] Provide karaf:run, karaf:deploy, karaf:client Maven goals
(2010-09-25 - New Feature - james strachan)
https://issues.apache.org/jira/browse/KARAF-222
[KARAF-1027] Have
13 matches
Mail list logo
