Please correct me if I'm wrong but aren't we talking about a problem that
(at least conceptually) has been solved? Package management has been around
in Linux for quite some time. Can't features just mimic the same behavior?
>From my perspective features are quite similar to virtual packages in
Deb
installed by given feature
even if in use
Does it make sense?
On Tue, Apr 14, 2015 at 9:11 AM, Christian Schneider <
ch...@die-schneider.net> wrote:
> Very well possible. What is the algorithm in Linux?
>
> Christian
>
> On 14.04.2015 09:06, Milen Dyankov wrote
AIK this is not
something provided in K3
Best,
Milen
On Tue, Apr 14, 2015 at 11:14 AM, Jean-Baptiste Onofré
wrote:
> Hi Milen,
>
> we already have the Jira about what you propose, and it's not K4 related:
> it's already for K3.
>
> Regards
> JB
>
>
> On
Comparing to SpringBoot is exactly what I wanted to write about.
But from psychological point of view, it has to be able to put everything
in a single executable jar to be able to convince people.
I recently used both SpringBoot and Felix in a demo and some feedback I had
was "see but SpringBoot
Not sure if I understand everything correctly but as Achim pointed out -
the order of deployment should have nothing to do with your dependency
graph.
Once you deploy your bundles (in whatever order) they need to be resolved
and then started. If they can not be resolved (due to missing dependencie
Guys,
I'm following this discussion and jumping back and forth between "I'm
totally lost" and "oh I get it"!
I get all the tech part, all the maven, annotations, 3rd party
technologies, Blueprint vs. DS vs. ... and all other tech concerns.
What I don't get is the business / purpose part. Who is
I might be wrong but I think the whole success of SpringBoot (apart from
having the "Spring" in it) is the microservices hype!
it's quick and easy but most usecases follow the "create one (or very few)
service(s), pack them as single executable and access them via REST"
pattern. We can obviously do
t talking of microservices, new developers to Karaf (and
> OSGi generally speaking) are frustrated by the effort on non business code
> to do (I have to write an Activator, or a descriptor, etc, etc).
> So, a tooling to simplify this is still a valid addition IMHO.
>
> Regards
> J
; karaf, but it's another point
> 2/ the value of karaf-boot annotations and plugin is first to simplify the
> bundle/artifact ready to be deploy-able into Karaf (generate the "plumbing"
> easily for developers).
>
> Regards
> JB
>
>
> On 09/10/2015 06:50 P
And how to you deal with jpa, jta, rest, etc with SCR annotations ?
>
> Regards
> JB
>
>
> On 09/10/2015 07:16 PM, Milen Dyankov wrote:
>
>> So correct me if I'm wrong but if I get the sample you provided in the
>> first mail and replace:
>> - the par
n, I'm ready to go.
> >>>>>
> >>>>>
> >>>>
> >>>> I'm sorry but this is a too big cannon you use to shoot on sparrows.
> >>>> Think minimalistic and modular. With the karaf-boot-*-starter boms we
> >>&
Can someone please point me to an example use case that is "easy" to do
with SpringBoot but "hard" with Karaf? Some of you mentioned you know
people that have concidered Karaf but went with SpringBoot because it's
easier. Is there anything more concrete than the subjective "easy" vs.
"hard" judgmen
Thanks for your examples Jean-Baptiste! I was tinning more about practical
business use cases, but let me comment on those.
First though a little disclaimer. Even though I'm familiar with how
Blueprint works in general, I have not used it for anything serious. For me
it has always been too Spring'
You have 2 steps presentation then ;)
*what OSGi is *
Bundle resolving lifecycle, requirements and capabilities, service
registry, whiteboard pattern, config admin, ... Basically those things that
make OSGi unique. If you wish to compare with microservices you may have a
look at
http://www.slides
Hi Morgan,
I just tried it on my phone and it seems ... how to say ... less readable
then the current site. Also the navigation does not seem to work at all on
my phone. I'll try to check it out on my laptop soon and provide more
feedback.
Best,
Milen
4 paź 2015 13:18 "Morgan Hautman" napisał(a):
Hi,
I'm not sure if this qualifies for -1 but it seams everything except home
page is not mobile device friendly. I really like the home page but the
rest is kind of cut in half if you browse it with mobile device. The only
fully visible part is the menu. IMHO this needs to be fixed. May be it's
j
the way, does the current website work fine on mobile ?
>
> Thanks
> Regards
> JB
>
> On 01/13/2016 09:16 PM, Milen Dyankov wrote:
>
>> Hi,
>>
>> I'm not sure if this qualifies for -1 but it seams everything except home
>> page is not mobile device f
+1
Looks much better now! Thank you for fixing it!
I only noticed one minor and easy to fix issue - all links to the projects
on home page go to the top of the projects page. Please add "#boot",
"#cellar", ... to them. It's especially important for mobile devices since
now the menu on product pag
Guys,
Allow me to provide my 2 cents in this discussion.
One - I think we have more than enough arogancie and blame games in the
OSGi community. We really don't need more of those. It would be nice if
everyone could remain calm and watch their language even if they have a
point as far as the fact
For me personally IDE support is irrelevant. BND is a command like tool and
while support for it in IDEs is different at the end of the day all you
need is a properties file editor. You don't get code competition for POMs
neither so there is absolutely no difference (in terms of amount of work
need
*358 additions* and *57 deletions*.
I feel your pain :)
On Tue, Feb 16, 2016 at 5:42 PM, Christian Schneider <
ch...@die-schneider.net> wrote:
> According to the discussion and the votes JB summarized we decided to roll
> back my change to use bnd files.
> I removed all bnd files and put the sa
I personally think DS is pretty much what OSGi Alliance is going to promote
(together with the enRoute project) and from that perspective if any
component framework's user base is going to grow that would be DS. But if
you guys want to still do it the "hard way" that's fine too. It just means
less
;t depend on blueprint
> (blueprint is not defined as a and so not in the manifest,
> even for the command extender).
>
> Regards
> JB
>
>
> On 03/18/2016 07:14 PM, Milen Dyankov wrote:
>
>> I personally think DS is pretty much what OSGi Alliance is going to
>
and shell-compat
> features, Karaf is still running without these dependencies.
>
> Regards
> JB
>
>
> On 03/18/2016 07:24 PM, Milen Dyankov wrote:
>
>> This is what I mean:
>>
>> karaf@root()> bundle:info 44
>>
>> Apache Karaf :: Shell :: Core
+1
17 mar 2016 16:44 "Christian Schneider"
napisał(a):
> We currently use some custom Activator base classes to wire the karaf
> bundles. The goal of this was to avoid depending on blueprint
> as it is a quite heavy dependency and makes it harder to use a different
> blueprint impl or version.
>
Hi guys,
what is the current status of Karaf boot?
Is it something that average developer can play with? Any usage samples?
Any docs / notes?
I looked at https://github.com/jbonofre/karaf-boot but this looks very
simple and it does not give a starting point if I want to build something
on my own
I have 2 things to say to that
- I agree with all the pain points you've identified (experienced them
myself)
- I'd prefer to fix things instead of claim them useless due to
malfunctioning
Perhaps a middle ground would be a good starting point? Something like how
bndrun resolution works. I mean:
I like the idea of reducing the number of files in etc folder.
However I would vote against it until there is a good documentation of how
to configure everything that's in those removed files. That is what can be
configured, where, how it differs in clustered env, ...
Once that is place that is eas
>
> I was able to modify above files, because I saw them being present.
That was exactly my point regarding documentation. I'd imagine a lot of
people would not be even aware something is configurable and can waste time
digging or what's worse, reinvent the wheel. For someone who is been
playing
I support Christian's idea regarding and
I'm not so sure about the configurator - I find it a bit confusing on first
read but I haven't paid too much attention to it.
However I like the direction. In fact I was about to ask in this list if
making "features" an independent (from Karaf) OSGi proje
ll with Karaf.
>
> regarding features, yeah why not. It could be a real improvement to have a
> spec for this and it being a ref-implementation.
> But wasn't there some sort of spec for a similar thing? AFAIK there had
> been some talks about this
> in the past.
>
> re
Hi folks,
what is the plan for Karaf Cave? Don see it in the Releases schedule JB
sent some time ago. Quick look at Github shows last commit was 9 moths ago?
Do you plan to release 4.1 compatible version?
Or let me ask differently, Is it good idea to build something on top of it?
Or should I simp
ures. The release should follow pretty soon.
>
> Regards
> JB
>
>
> On 04/13/2017 08:49 PM, Milen Dyankov wrote:
>
>> Hi folks,
>>
>> what is the plan for Karaf Cave? Don see it in the Releases schedule JB
>> sent some time ago. Quick look at Github shows
See https://thoeni.io/post/macos-sierra-java/
On Wed, Apr 19, 2017 at 9:01 PM, Achim Nierbeck
wrote:
> Hi,
>
> first you should post your question on the users list, issues is actually
> for the issue tracker :)
> second, I'm using macOS Sierra, and everything is running fine so I can not
> repr
Hi Karaf developers,
I'd like to ask you to have a look at something I've been working on. It's
a PoC called Eccentric Modularity (EM) and it's available here
https://github.com/azzazzel/EM
The basic idea is to provide a jump start into modularity (particularly in
the scope of resolving dependenc
resolved from my POM.
On Wed, Jun 14, 2017 at 3:44 PM, Jean-Baptiste Onofré
wrote:
> Hi,
>
> it sounds interesting but I don't really get the relationship. You don't
> use Karaf now right ?
>
> I would love to chat with you about this.
> Regards
> JB
>
> On
d it.
> I did this for the bnd-maven-plugin so each project just needs a bnd.bnd
> file if it wants to override defaults.
>
> Christian
>
> 2017-06-14 13:46 GMT+02:00 Milen Dyankov :
>
> > Hi Karaf developers,
> >
> > I'd like to ask you to have a look at somet
welcome.
Best,
Milen
14 cze 2017 18:59 "Scott Lewis" napisał(a):
On 6/14/2017 4:46 AM, Milen Dyankov wrote:
> Hi Karaf developers,
>
> I'd like to ask you to have a look at something I've been working on. It's
> a PoC called Eccentric Modularity
ned with reasonable simplicity.
>
> Christian
>
> 2017-06-14 21:52 GMT+02:00 Milen Dyankov :
>
> > Thanks for your comments Christian,
> >
> > I understand this goes too far into making things simple to be useful for
> > OSGi veterans. And that's OK.
ter the upcoming ECF release (June 28 I think).
Scott
[1] https://github.com/ECF/JaxRSProviders
So for
> now I just decided to go with what I know works. But if you have practical
> experience with this spec, pull request would be more than welcome.
>
> Best,
> Milen
>
>
>
>
Do you want this to happen at runtime or build time? Can you be more
specific about what exactly the terms "export" and "import" mean in your
particular case?
On Tue, Jul 25, 2017 at 11:32 AM, Dominik Marciniszyn <
marciniszyn.domi...@gmail.com> wrote:
> Hi,
>
> I have a few modules and each of t
Hi,
I have this usecase that I need something to which I can throw a bunch of
bundles and then say "give me ALL bundles that fulfill this requirement". I
need that thing embedded in my code but able to persist and update the
information (index) between executions.
I was thinking of embedding Cave
42 matches
Mail list logo
