Hi,
The vote has passed with the following result :
+1 (binding): Jean-Baptiste Onofré, Guillaume Nodet, Achim Nierbeck,
Charles Moulliard, Andreas Pieber, Jamie Goodyear, and Freeman Fang.
+1 (non binding): Christian Schneider, Christoph Gritschenberger,
-1 (binding): Łukasz Dywicki
-1 (
+1
－
Freeman(Yue) Fang
Red Hat, Inc.
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: @Freeman小屋
On 2013-3-15, at 上午10:06, Jamie G. wrote:
> +1
+1, I'm going to add a note for the above issues.
Note: Ran the check release scripts, and it all looked fine.
Cheers,
Jamie
On Thu, Mar 14, 2013 at 8:30 PM, Charles Moulliard wrote:
> On 14/03/13 20:44, Guillaume Nodet wrote:
>>
>> I agree.
>>
>> Charles, do you mind changing your -1 to someth
On 14/03/13 20:44, Guillaume Nodet wrote:
I agree.
Charles, do you mind changing your -1 to something else, provided we give a
big warning when announcing that it's not stable and only meant to be a
tech preview ?
On Thu, Mar 14, 2013 at 8:41 PM, Achim Nierbeck wrote:
Hi,
I'm with Jamie her
I also second Jamie on this one. +1 for the RC1 "tech preview" release.
Kind regards,
Andreas
On Thu, Mar 14, 2013 at 8:41 PM, Achim Nierbeck wrote:
> Hi,
>
> I'm with Jamie here, we're longing for this RC now for quite some time and
> actually I'm personally quite happy that we did get some im
I agree.
Charles, do you mind changing your -1 to something else, provided we give a
big warning when announcing that it's not stable and only meant to be a
tech preview ?
On Thu, Mar 14, 2013 at 8:41 PM, Achim Nierbeck wrote:
> Hi,
>
> I'm with Jamie here, we're longing for this RC now for qui
Hi,
I'm with Jamie here, we're longing for this RC now for quite some time and
actually I'm personally quite happy that we did get some immediate feedback
of things that don't work :D
Since it's a RC I also tend to get on with it.
Let's focus on stabilizing now!
regards, Achim
2013/3/14 Jamie G
The vote for Apache Karaf 3.0.0.RC1 is still active.
At the current moment I'm torn between holding off this build
candidate for those immediate issues to be resolved, OR allowing the
RC to continue as it's a technology preview build not intended for
production. Personally I'm leaning towards cont
That's what I raised earlier. Wait a bit and see if they are installed.
For some reason, it goes to the internet before checking the system folder
and it takes time for nothing.
On Thu, Mar 14, 2013 at 11:34 AM, Charles Moulliard wrote:
> -1
>
> I don't know if this is a "internet" side effect
Thanks for the update. I gonna take a look what is populated in system
repo (and if system repo is correctly used).
Regards
JB
On 03/14/2013 11:34 AM, Charles Moulliard wrote:
-1
I don't know if this is a "internet" side effect but some basics
functionalities are not longer there when we star
-1
I don't know if this is a "internet" side effect but some basics
functionalities are not longer there when we start Karaf 3.0.0.RC1 without
internet connection (log:display subshell is not there, shortcuts have
disapeared, ...)
https://gist.github.com/cmoulliard/b9f75b98bcb0a5e78d96
On Thu,
I have mixed feelings about putting my vote here.. but I have to do this:
-1 From me
Minimal distro have broken instance script, basically it doesn't work.
Best regards,
Łukasz Dywicki
--
l...@code-house.org
Twitter: ldywicki
Blog: http://dywicki.pl
Code-House - http://code-house.org
Wiadomość
OK, catcha ;)
Thanks
Regards
JB
On 03/13/2013 05:36 PM, Guillaume Nodet wrote:
On Wed, Mar 13, 2013 at 4:57 PM, Jean-Baptiste Onofré wrote:
I'm not sure to follow you.
For API, I'm agree with you. For instance, the Properties (now in Felix
Utils) case is a good example: different bundles use
On Wed, Mar 13, 2013 at 4:57 PM, Jean-Baptiste Onofré wrote:
> I'm not sure to follow you.
>
> For API, I'm agree with you. For instance, the Properties (now in Felix
> Utils) case is a good example: different bundles use "Karaf" Properties,
> and so we embed the API.
>
> Now, if Karaf utils may "
I'm not sure to follow you.
For API, I'm agree with you. For instance, the Properties (now in Felix
Utils) case is a good example: different bundles use "Karaf" Properties,
and so we embed the API.
Now, if Karaf utils may "exposes" a set of services that different other
bundles use: in that
I don't think that the number of bundles is an issue: if the user uses
bundle:list (without -t 0), he doesn't see that ;)
For instance, in some projects, like ACE or Aries, we have a lot of
bundles, and it's not a big deal.
Regards
JB
On 03/13/2013 04:26 PM, Guillaume Nodet wrote:
On Wed, M
Actually, I think I was not really clear.
What I mean is that the larger util is, the less it makes sense to make it
a bundle, because the more it breaks any kind of modularity by becoming a
dependency of more and more bundles.
The more often a bundle is used as a dependency, the more stable it sho
On 13.03.2013 16:26, Guillaume Nodet wrote:
On Wed, Mar 13, 2013 at 4:01 PM, Jean-Baptiste Onofré wrote:
Thanks Guillaume for this remember (or introduction for some of us I think
;)).
I think that on trunk we made some progress in the way that you describe.
For instance, unlike that we have i
On Wed, Mar 13, 2013 at 4:25 PM, Jean-Baptiste Onofré wrote:
> I think it makes sense if utils is "larger". Currently, the coverage is so
> low that I think it's a overhead.
>
>
I disagree. If utils becomes bigger, and maybe it should to avoid
duplication of code throughout karaf, bundles can eas
On Wed, Mar 13, 2013 at 4:01 PM, Jean-Baptiste Onofré wrote:
> Thanks Guillaume for this remember (or introduction for some of us I think
> ;)).
>
> I think that on trunk we made some progress in the way that you describe.
> For instance, unlike that we have in Karaf 2.x, modules on trunk are
> st
I think it makes sense if utils is "larger". Currently, the coverage is
so low that I think it's a overhead.
On the other hand, I'm pretty sure that some more code can be moved into
utils ;)
Regards
JB
On 03/13/2013 04:21 PM, Christian Schneider wrote:
Honestly I would prefer utils to be a
Honestly I would prefer utils to be a bundle but it is also ok like it is.
Christian
On 13.03.2013 16:19, Jean-Baptiste Onofré wrote:
No Christian, don't take my wrong: I mean that sometime all (and I
include myself in all) we think that we do something simpler, more
elegant, but for the other
No Christian, don't take my wrong: I mean that sometime all (and I
include myself in all) we think that we do something simpler, more
elegant, but for the others, it's not ;)
Karaf utils is a good example I think.
Regards
JB
On 03/13/2013 04:16 PM, Christian Schneider wrote:
On 13.03.2013 16
On 13.03.2013 16:01, Jean-Baptiste Onofré wrote:
I think that on trunk we made some progress in the way that you
describe. For instance, unlike that we have in Karaf 2.x, modules on
trunk are structured like this:
- core provide OSGi services
- commands use the core services
- MBeans use the
Thanks Guillaume for this remember (or introduction for some of us I
think ;)).
I think that on trunk we made some progress in the way that you
describe. For instance, unlike that we have in Karaf 2.x, modules on
trunk are structured like this:
- core provide OSGi services
- commands use the
Ah, and one additional thing I haven't mentioned is the use of optional
imports, especially for libraries. It makes modularity much more
complicated as any kind of resolver will need additional input to know if
those imports should be satisfied or not, and it also disturbs existing
bundles during
The more complex the wiring is, the largest the number of potential issues.
Let's keep things as simple as possible.
Moreover, I find the large number of bundles, as a result of unwinding libs
intimidating to the new users.
--
*Ioannis Canellos*
*
**
Blog: http://iocanel.blogspot.com
**
Twitter
On Wed, Mar 13, 2013 at 12:16 PM, Christian Schneider <
ch...@die-schneider.net> wrote:
> Another problem is that at least eclipse + m2e does not cope very well
> with provided scope and embedded bundles.
>
> So for example I still can not have the karaf console project open in
> eclipse. As soon
Another problem is that at least eclipse + m2e does not cope very well
with provided scope and embedded bundles.
So for example I still can not have the karaf console project open in
eclipse. As soon as I open it all projects depending on the console
are flagged as broken as they do not see th
On Wed, Mar 13, 2013 at 11:32 AM, Christian Schneider <
ch...@die-schneider.net> wrote:
> I have experienced some problems when libs were embedded in bundles:
>
> When the bundle is a separate project from the original jar that does not
> embed the lib then the maven dependencies can not be used t
I have experienced some problems when libs were embedded in bundles:
When the bundle is a separate project from the original jar that does
not embed the lib then the maven dependencies can not be used to create
the feature.
So in the feature you have to use the bundle but exclude its
dependenc
Starting a new thread for discussing those points.
The idea for OSGi is modularity, but it should be done at the right level.
And modularity is different from code sharing.
In OSGi, the main idea is to have bundles exposing API and services.
That's the way we leverage the most of OSGi.
Unlike p
+1
kind regards,
christoph
On 2013-03-12 04:26, Jamie G. wrote:
Hi,
We resolved 964 issues in this release (web page will be published
post RC promotion):
https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0.RC1-release.page
NOTE: This is a te
I do not agree with embedding bundles except for some rare cases. They
make it much more difficult to work with those projects. In maven you
always
get the list of dependencies including the embedded ones unless you
exclude them.
I agree though that ops4j contains too many fine grained bundles.
+1
Also some comments :)
I second Guillaume on the fine grained "utility bundles", their
just polluting the list command ;)
The Felis webconsole works, but the admin plugin is gone. Dunno what
happened to that.
It's OK for a RC1 but for a Release this would be -1 ;)
Besides that, great that we ha
+1
A few comments though
When I started the first time, karaf failed to install the additional
features (ssh, management, etc...)
I then removed my ~/.m2/settings.xml which were pointing to a nexus and
restarted from clean. That worked, but the bundles took a long time to
install. While it work
Am Tuesday, 12. March 2013 schrieb Jean-Baptiste Onofré:
> Hi,
hello JB,
> it's random test failures.
>
> Could you try a couple of more times ?
random, indeed. What is causing this random failures? Is it related to Pax Web
where I've also random test failures?
thanks,
O.
> Thanks,
> Regards
Hi,
it's random test failures.
Could you try a couple of more times ?
Thanks,
Regards
JB
On 03/12/2013 12:41 PM, Oliver Lietz wrote:
Am Tuesday, 12. March 2013 schrieb Jamie G.:
Hi,
We resolved 964 issues in this release (web page will be published
post RC promotion):
https://svn.apache.org
Am Tuesday, 12. March 2013 schrieb Jamie G.:
> Hi,
>
> We resolved 964 issues in this release (web page will be published
> post RC promotion):
> https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/com
> munity/download/karaf-3.0.0.RC1-release.page
>
> NOTE: This is a technolo
Yes, it's what I'm doing (I was supposed to do it yesterday evening, but
not had time).
Regards
JB
On 03/12/2013 10:13 AM, Christian Schneider wrote:
One small organizational issue. We have 9 issues open for 3.0.0.RC1.
Should we just move them to 3.0.0?
https://issues.apache.org/jira/issues/?j
One small organizational issue. We have 9 issues open for 3.0.0.RC1.
Should we just move them to 3.0.0?
https://issues.apache.org/jira/issues/?jql=project%20%3D%20KARAF%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20%223.0.0.RC1%22%20ORDER%20BY%20priority%20DESC
Christian
On 1
+1 (non binding)
Tested with my (not yet released) voting tutorial. It contains a web UI,
a cxf rest service and a camel route using the twitter component.
So it should cover a fair amount of karaf. I used cxf 2.7.3 and camel
2.10.3.
Strangely on my first test run I got a NPE in blueprint. I
+1 (binding)
Regards
JB
On 03/12/2013 04:26 AM, Jamie G. wrote:
Hi,
We resolved 964 issues in this release (web page will be published
post RC promotion):
https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0.RC1-release.page
NOTE: This is a te
Hi,
We resolved 964 issues in this release (web page will be published
post RC promotion):
https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0.RC1-release.page
NOTE: This is a technology preview release candidate.
Staging repository:
https://rep
44 matches
Mail list logo
