[RESULT][VOTE] Release Apache Karaf version 3.0.0

[Jean-Baptiste Onofré]

Hi all,

I put [RESULT] in the subject just for the tracking.

I'm going to update the website and publish the documentation today or 
tomorrow.


Thanks all for this job and Merry Christmas !

Regards
JB

On 12/24/2013 06:44 PM, Jamie G. wrote:

Hi,


The vote has passed with the following result :


   +1 (binding): Jean-Baptiste Onofré, Achim Nierbeck, Andreas Pieber,
Freeman Fang, and Jamie Goodyear.




   +1 (non binding): David Bosschaert, Ehsan Zaery Moghaddam, Christian
Schneider, Heath Kesler, Johan Edstrom, Christoph Gritschenberger, and Jon
Anstey.


   +0: Ioannis Canellos


I will copy this release to the Karaf dist directory and

promote the artifacts to the central Maven repository.


On Tue, Dec 24, 2013 at 1:51 PM, Jamie G.  wrote:


+1 (signature scripts reported fine)

--Jamie


On Tue, Dec 24, 2013 at 4:44 AM, Freeman Fang wrote:


+1 (binding)
－
Freeman(Yue) Fang

Red Hat, Inc.
FuseSource is now part of Red Hat



On 2013-12-22, at 上午1:40, Jamie G. wrote:


Hi,

We resolved 1158 issues in this release:


http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0-release.page?view=markup


Dependency changes can be reviewed here:


http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup

(The website published table will be updated after vote)

Staging repository:
https://repository.apache.org/content/repositories/orgapachekaraf-013/

Git tag:
karaf-3.0.0

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.









--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [VOTE] Release Apache Karaf version 3.0.0

[Achim Nierbeck]

Good job everyone.
And merry Christmas.

Regards Achim

sent from mobile device
Am 24.12.2013 18:44 schrieb "Jamie G." :

> Hi,
>
>
> The vote has passed with the following result :
>
>
>   +1 (binding): Jean-Baptiste Onofré, Achim Nierbeck, Andreas Pieber,
> Freeman Fang, and Jamie Goodyear.
>
>
>
>
>   +1 (non binding): David Bosschaert, Ehsan Zaery Moghaddam, Christian
> Schneider, Heath Kesler, Johan Edstrom, Christoph Gritschenberger, and Jon
> Anstey.
>
>
>   +0: Ioannis Canellos
>
>
> I will copy this release to the Karaf dist directory and
>
> promote the artifacts to the central Maven repository.
>
>
> On Tue, Dec 24, 2013 at 1:51 PM, Jamie G. 
> wrote:
>
> > +1 (signature scripts reported fine)
> >
> > --Jamie
> >
> >
> > On Tue, Dec 24, 2013 at 4:44 AM, Freeman Fang  >wrote:
> >
> >> +1 (binding)
> >> －
> >> Freeman(Yue) Fang
> >>
> >> Red Hat, Inc.
> >> FuseSource is now part of Red Hat
> >>
> >>
> >>
> >> On 2013-12-22, at 上午1:40, Jamie G. wrote:
> >>
> >> > Hi,
> >> >
> >> > We resolved 1158 issues in this release:
> >> >
> >>
> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0-release.page?view=markup
> >> >
> >> > Dependency changes can be reviewed here:
> >> >
> >>
> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup
> >> > (The website published table will be updated after vote)
> >> >
> >> > Staging repository:
> >> >
> https://repository.apache.org/content/repositories/orgapachekaraf-013/
> >> >
> >> > Git tag:
> >> > karaf-3.0.0
> >> >
> >> > Please vote to approve this release:
> >> >
> >> > [ ] +1 Approve the release
> >> > [ ] -1 Veto the release (please provide specific comments)
> >> >
> >> > This vote will be open for 72 hours.
> >>
> >>
> >
>

Re: [VOTE] Release Apache Karaf version 3.0.0

[Jamie G.]

Hi,


The vote has passed with the following result :


  +1 (binding): Jean-Baptiste Onofré, Achim Nierbeck, Andreas Pieber,
Freeman Fang, and Jamie Goodyear.




  +1 (non binding): David Bosschaert, Ehsan Zaery Moghaddam, Christian
Schneider, Heath Kesler, Johan Edstrom, Christoph Gritschenberger, and Jon
Anstey.


  +0: Ioannis Canellos


I will copy this release to the Karaf dist directory and

promote the artifacts to the central Maven repository.


On Tue, Dec 24, 2013 at 1:51 PM, Jamie G.  wrote:

> +1 (signature scripts reported fine)
>
> --Jamie
>
>
> On Tue, Dec 24, 2013 at 4:44 AM, Freeman Fang wrote:
>
>> +1 (binding)
>> －
>> Freeman(Yue) Fang
>>
>> Red Hat, Inc.
>> FuseSource is now part of Red Hat
>>
>>
>>
>> On 2013-12-22, at 上午1:40, Jamie G. wrote:
>>
>> > Hi,
>> >
>> > We resolved 1158 issues in this release:
>> >
>> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0-release.page?view=markup
>> >
>> > Dependency changes can be reviewed here:
>> >
>> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup
>> > (The website published table will be updated after vote)
>> >
>> > Staging repository:
>> > https://repository.apache.org/content/repositories/orgapachekaraf-013/
>> >
>> > Git tag:
>> > karaf-3.0.0
>> >
>> > Please vote to approve this release:
>> >
>> > [ ] +1 Approve the release
>> > [ ] -1 Veto the release (please provide specific comments)
>> >
>> > This vote will be open for 72 hours.
>>
>>
>

Re: [VOTE] Release Apache Karaf version 3.0.0

[Jamie G.]

+1 (signature scripts reported fine)

--Jamie


On Tue, Dec 24, 2013 at 4:44 AM, Freeman Fang wrote:

> +1 (binding)
> －
> Freeman(Yue) Fang
>
> Red Hat, Inc.
> FuseSource is now part of Red Hat
>
>
>
> On 2013-12-22, at 上午1:40, Jamie G. wrote:
>
> > Hi,
> >
> > We resolved 1158 issues in this release:
> >
> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0-release.page?view=markup
> >
> > Dependency changes can be reviewed here:
> >
> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup
> > (The website published table will be updated after vote)
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachekaraf-013/
> >
> > Git tag:
> > karaf-3.0.0
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Veto the release (please provide specific comments)
> >
> > This vote will be open for 72 hours.
>
>

Re: [VOTE] Release Apache Karaf version 3.0.0

[Freeman Fang]

+1 (binding)
－
Freeman(Yue) Fang

Red Hat, Inc. 
FuseSource is now part of Red Hat



On 2013-12-22, at 上午1:40, Jamie G. wrote:

> Hi,
> 
> We resolved 1158 issues in this release:
> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0-release.page?view=markup
> 
> Dependency changes can be reviewed here:
> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup
> (The website published table will be updated after vote)
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-013/
> 
> Git tag:
> karaf-3.0.0
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> This vote will be open for 72 hours.

Re: [VOTE] Release Apache Karaf version 3.0.0

[Jean-Baptiste Onofré]

Fair enough.

I will fix your concerns for 3.0.1 as you are right.

Thanks to have spot that !

Regards
JB

On 12/23/2013 03:16 PM, Ioannis Canellos wrote:

Given the low popularity of the minimal release and given the fact
that issue can be worked around with internet access I'll change my
vote to +0.

We can fix the offline support as part of a 3.0.1 release.
I don't mind having a distribution that would be extra small and would
also require internet connection ( a net installer distro ), if its
size justifies the effort.



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [VOTE] Release Apache Karaf version 3.0.0

[Ioannis Canellos]

Given the low popularity of the minimal release and given the fact
that issue can be worked around with internet access I'll change my
vote to +0.

We can fix the offline support as part of a 3.0.1 release.
I don't mind having a distribution that would be extra small and would
also require internet connection ( a net installer distro ), if its
size justifies the effort.

-- 
Ioannis Canellos

Blog: http://iocanel.blogspot.com
Twitter: iocanel

Re: [VOTE] Release Apache Karaf version 3.0.0

[Jean-Baptiste Onofré]

I got your points.

Agree for 2 and 3, but I'm a bit concerned by the offline mode.

I would propose:
- provide the minimal distribution able to work offline
- provide a net distribution (if it makes sense) like the minimal 
distribution, but downloading the features/bundles from Internet


If you maintain your -1, I will cancel the release, fix the minimal 
distribution and add the net distribution.


Does it sound good to you ?

Regards
JB

On 12/23/2013 02:50 PM, Ioannis Canellos wrote:

Please find my comments inline:


2/ the minimal distribution didn't exist in Karaf 2.3.x, so we can't
consider that as a regression.


That's not quite accurate. The minimal distribution exists ever since
Karaf 2.1.x and all releases so far did manage to boot offline, but
additional features where downloaded from the internet.
 From my pov it is a regression and its a regression that that in the
past justified a (-1). We've cancelled at least one release in the
past due to this issue.


3/ agree that the featuresBoot for minimal distribution should be more
"minimal". I would keep config, kar, management, but I would remove ssh and
region for instance.


I would even remove config & kar and go just with management as was
the case with previous releases.


Minimal distribution is like this since 3.0.0.RC1 (it's not something that
we changed for 3.0.0).


3.0.0.RC1 did manage to boot offline without issues. This seems to be
broken post 3.0.0.RC1.



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [VOTE] Release Apache Karaf version 3.0.0

[Ioannis Canellos]

Please find my comments inline:

> 2/ the minimal distribution didn't exist in Karaf 2.3.x, so we can't
> consider that as a regression.

That's not quite accurate. The minimal distribution exists ever since
Karaf 2.1.x and all releases so far did manage to boot offline, but
additional features where downloaded from the internet.
>From my pov it is a regression and its a regression that that in the
past justified a (-1). We've cancelled at least one release in the
past due to this issue.

> 3/ agree that the featuresBoot for minimal distribution should be more
> "minimal". I would keep config, kar, management, but I would remove ssh and
> region for instance.

I would even remove config & kar and go just with management as was
the case with previous releases.

> Minimal distribution is like this since 3.0.0.RC1 (it's not something that
> we changed for 3.0.0).

3.0.0.RC1 did manage to boot offline without issues. This seems to be
broken post 3.0.0.RC1.

-- 
Ioannis Canellos

Blog: http://iocanel.blogspot.com
Twitter: iocanel

Re: [VOTE] Release Apache Karaf version 3.0.0

[Jean-Baptiste Onofré]

Where I'm agree with you is that the system folder should be quite empty 
in the minimal distribution.


I gonna improve this for 3.0.1 release.

Regards
JB

On 12/23/2013 01:42 PM, Ioannis Canellos wrote:

I see two problems here:
i) The bootFeatures in the minimal distro contain more features than it should.
ii) The minimal distro cannot boot offline (even if I remove all the
features that shouldn't be there).

I think that that the minimal distribution should be able to boot up,
without requiring access to any external repository. For extra
features (e.g. http, spring etc), yes I agree they should be get
downloaded from an external repo, but that should not be the case for
the boot stuff.

Shipping a 16 MB minimal distro, that cannot boot offline, is wrong imho.

I don't mind changing my vote to a +0, its just that in the past we
considered similar issues show stoppers and that's why I gave it a -1.



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [VOTE] Release Apache Karaf version 3.0.0

[Jean-Baptiste Onofré]

Hi Ioannis,

I would not cancel this vote about that for three reasons:

1/ the minimal distribution requiring a connection and cannot boot 
offline has been discussed and validated. It was one of the purpose to 
use pax-url-aether. It's exactly like a Unix minimal distribution: when 
you start Ubuntu minimal, it will start the bootstrap and download only 
deb package from Internet. It's exactly the purpose of Karaf minimal 
distribution.
2/ the minimal distribution didn't exist in Karaf 2.3.x, so we can't 
consider that as a regression.
3/ agree that the featuresBoot for minimal distribution should be more 
"minimal". I would keep config, kar, management, but I would remove ssh 
and region for instance.


Minimal distribution is like this since 3.0.0.RC1 (it's not something 
that we changed for 3.0.0).


That's why we should keep the vote running.

Regarding the minimal distribution:
1/ the minimal purpose is the one that we planned, so I would keep it 
like this, including downloading bundles/features at bootstrap (again as 
a Unix minimal distribution)
2/ if users want create a distribution on top of minimal, they can do 
that and populate the repo with the Karaf Maven plugin.
3/ I'm not against to create a new "distribution" like a minimal 
shipping the bundles in the system repository, but I don't see a huge 
plus value for that.


WDYT ?

Regards
JB

On 12/23/2013 01:42 PM, Ioannis Canellos wrote:

I see two problems here:
i) The bootFeatures in the minimal distro contain more features than it should.
ii) The minimal distro cannot boot offline (even if I remove all the
features that shouldn't be there).

I think that that the minimal distribution should be able to boot up,
without requiring access to any external repository. For extra
features (e.g. http, spring etc), yes I agree they should be get
downloaded from an external repo, but that should not be the case for
the boot stuff.

Shipping a 16 MB minimal distro, that cannot boot offline, is wrong imho.

I don't mind changing my vote to a +0, its just that in the past we
considered similar issues show stoppers and that's why I gave it a -1.



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [VOTE] Release Apache Karaf version 3.0.0

[Ioannis Canellos]

I see two problems here:
i) The bootFeatures in the minimal distro contain more features than it should.
ii) The minimal distro cannot boot offline (even if I remove all the
features that shouldn't be there).

I think that that the minimal distribution should be able to boot up,
without requiring access to any external repository. For extra
features (e.g. http, spring etc), yes I agree they should be get
downloaded from an external repo, but that should not be the case for
the boot stuff.

Shipping a 16 MB minimal distro, that cannot boot offline, is wrong imho.

I don't mind changing my vote to a +0, its just that in the past we
considered similar issues show stoppers and that's why I gave it a -1.

-- 
Ioannis Canellos

Blog: http://iocanel.blogspot.com
Twitter: iocanel

Re: [VOTE] Release Apache Karaf version 3.0.0

[Jean-Baptiste Onofré]

As a reminder, the minimal distribution is like an Unix minimal 
distribution: most of the bundles/features will be downloaded at bootstrap.


As a stage release, you have to add the staging repository in 
etc/org.ops4j.pax.url.mvn.cfg file.


Maybe, it's your issue ?

I gonna describe it in the users guide.

Regards
JB

On 12/23/2013 09:47 AM, Ioannis Canellos wrote:

-1

The minimal distribution does not work, which sounds like a show stopper?



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [VOTE] Release Apache Karaf version 3.0.0

[Jean-Baptiste Onofré]

It works for me (I just tried).

What's your issue ?

Regards
JB

On 12/23/2013 09:47 AM, Ioannis Canellos wrote:

-1

The minimal distribution does not work, which sounds like a show stopper?



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [VOTE] Release Apache Karaf version 3.0.0

[Jean-Baptiste Onofré]

Hi Ioannis,

let me take a look on that. I don't think it's a release stopper, we can 
fix that for 3.0.1 (that we can release quickly).


Regards
JB

On 12/23/2013 09:47 AM, Ioannis Canellos wrote:

-1

The minimal distribution does not work, which sounds like a show stopper?



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [VOTE] Release Apache Karaf version 3.0.0

[Ioannis Canellos]

-1

The minimal distribution does not work, which sounds like a show stopper?

-- 
Ioannis Canellos

Blog: http://iocanel.blogspot.com
Twitter: iocanel

Re: [VOTE] Release Apache Karaf version 3.0.0

[Andreas Pieber]

Compiling either the tag or the source archive works like a charm. Tested
with various use cases which also did what they should.

+1 (binding)

Kind regards,
Andreas


On Sun, Dec 22, 2013 at 4:32 AM, Jon Anstey  wrote:

> +1 non binding. Will be nice to see this one go out :-) Great job guys!
> On Dec 21, 2013 2:11 PM, "Jamie G."  wrote:
>
> > Hi,
> >
> > We resolved 1158 issues in this release:
> >
> >
> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0-release.page?view=markup
> >
> > Dependency changes can be reviewed here:
> >
> >
> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup
> > (The website published table will be updated after vote)
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachekaraf-013/
> >
> > Git tag:
> > karaf-3.0.0
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Veto the release (please provide specific comments)
> >
> > This vote will be open for 72 hours.
> >
>

Re: [VOTE] Release Apache Karaf version 3.0.0

[Jon Anstey]

+1 non binding. Will be nice to see this one go out :-) Great job guys!
On Dec 21, 2013 2:11 PM, "Jamie G."  wrote:

> Hi,
>
> We resolved 1158 issues in this release:
>
> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0-release.page?view=markup
>
> Dependency changes can be reviewed here:
>
> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup
> (The website published table will be updated after vote)
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-013/
>
> Git tag:
> karaf-3.0.0
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> This vote will be open for 72 hours.
>

Re: [VOTE] Release Apache Karaf version 3.0.0

[Christoph Gritschenberger]

OK maybe this issue's got something to do with my environment.
Cannot reproduce it anymore

Just downloaded the source-archive into a fresh ubuntu-vm and ran the 
build successfully,


so changing my vote to +1 (non-binding)

kind regards,
Christoph

On 2013-12-21 21:07, Christoph Gritschenberger wrote:

Sorry for being a bit of a grinch here:

-1, because an itest fails

Results :

Tests in error:
   testJMXSecurityAsAdmin(org.apache.karaf.itests.JMXSecurityTest):
Configuration org.apache.karaf.service.acl.command.1387655750210_36.x
deleted

Tests run: 93, Failures: 0, Errors: 1, Skipped: 2

I was able to reproduce it on fresh installs (the second build went OK
on both systems I tested this on).

I'll investigate the test-failure further later this evening.

kind regards,
christoph


On 2013-12-21 18:40, Jamie G. wrote:

Hi,

We resolved 1158 issues in this release:
http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0-release.page?view=markup


Dependency changes can be reviewed here:
http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup

(The website published table will be updated after vote)

Staging repository:
https://repository.apache.org/content/repositories/orgapachekaraf-013/

Git tag:
karaf-3.0.0

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.








smime.p7s
Description: S/MIME Cryptographic Signature

Re: [VOTE] Release Apache Karaf version 3.0.0

[Johan Edstrom]

+1 non binding

Sent from my pressure cooker.

On Dec 21, 2013, at 15:08, Heath Kesler  wrote:

> +1 non-binding
> On Dec 21, 2013 2:58 PM, "Christian Schneider" 
> wrote:
> 
>> +1 (non binding)
>> 
>> Built the tag on windows and did some tests on the binary including cxf.
>> Looks all very well.
>> Many thanks to the whole karaf team and especially to JB who put a
>> tremendous amount of work into this release.
>> 
>> Christian
>> 
>> Am 21.12.2013 18:40, schrieb Jamie G.:
>> 
>>> Hi,
>>> 
>>> We resolved 1158 issues in this release:
>>> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/
>>> webapp/index/community/download/karaf-3.0.0-release.page?view=markup
>>> 
>>> Dependency changes can be reviewed here:
>>> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/
>>> webapp/index/documentation/karaf-dependencies/karaf-deps-
>>> 3.0.x.page?view=markup
>>> (The website published table will be updated after vote)
>>> 
>>> Staging repository:
>>> https://repository.apache.org/content/repositories/orgapachekaraf-013/
>>> 
>>> Git tag:
>>> karaf-3.0.0
>>> 
>>> Please vote to approve this release:
>>> 
>>> [ ] +1 Approve the release
>>> [ ] -1 Veto the release (please provide specific comments)
>>> 
>>> This vote will be open for 72 hours.
>>> 
>>> 
>> 
>> --
>> Christian Schneider
>> http://www.liquid-reality.de
>> 
>> Open Source Architect
>> Talend Application Integration Division http://www.talend.com
>> 
>> 

Re: [VOTE] Release Apache Karaf version 3.0.0

[Achim Nierbeck]

Hi Kurt,

as it's still only contained in the staging repo, you'll need to adjust the
org.ops4j.pax.url.mvn.cfg to contain the staging repo. For example
something like this:

org.ops4j.pax.url.mvn.repositories= \

https://repository.apache.org/content/repositories/orgapachekaraf-013@id=karaf-snapshot,
\
http://repo1.maven.org/maven2@id=central, \

http://repository.springsource.com/maven/bundles/release@id=spring.ebr.release,
\

http://repository.springsource.com/maven/bundles/external@id=spring.ebr.external,
\
file:${karaf.home}/${karaf.default.repository}@id=system.repository, \
file:${karaf.data}/kar@id=kar.repository@multi

regards, Achim


2013/12/21 Kurt Westerfeld 

> I downloaded the candidate, and ran "feature:install war", and received a
> connection error on repo1.maven.org, which I started receiving a couple
> weeks ago.  I have redirected my local ~/.m2/settings.xml to
> central.maven.org, but it looks to me like the default repos should be
> adjusted:
>
> kurt@hiro:~/Downloads/apache-karaf-3.0.0 > bin/karaf
> __ __  
>/ //_/ __ _/ __/
>   / ,<  / __ `/ ___/ __ `/ /_
>  / /| |/ /_/ / /  / /_/ / __/
> /_/ |_|\__,_/_/   \__,_/_/
>
>   Apache Karaf (3.0.0)
>
> Hit '' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.
>
> karaf@root()> feature:install war
> Error executing command: Error resolving artifact
> org.apache.karaf.http:org.apache.karaf.http.core:jar:3.0.0: Could not
> transfer artifact
> org.apache.karaf.http:org.apache.karaf.http.core:jar:3.0.0 from/to central
> (
> http://repo1.maven.org/maven2/): Error transferring file: Connection
> refused
> karaf@root()>
>
>
>
> On Sat, Dec 21, 2013 at 12:40 PM, Jamie G. 
> wrote:
>
> > Hi,
> >
> > We resolved 1158 issues in this release:
> >
> >
> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0-release.page?view=markup
> >
> > Dependency changes can be reviewed here:
> >
> >
> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup
> > (The website published table will be updated after vote)
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachekaraf-013/
> >
> > Git tag:
> > karaf-3.0.0
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Veto the release (please provide specific comments)
> >
> > This vote will be open for 72 hours.
> >
>



-- 

Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
OPS4J Pax for Vaadin 
Commiter & Project Lead
blog 

Re: [VOTE] Release Apache Karaf version 3.0.0

[Kurt Westerfeld]

I downloaded the candidate, and ran "feature:install war", and received a
connection error on repo1.maven.org, which I started receiving a couple
weeks ago.  I have redirected my local ~/.m2/settings.xml to
central.maven.org, but it looks to me like the default repos should be
adjusted:

kurt@hiro:~/Downloads/apache-karaf-3.0.0 > bin/karaf
__ __  
   / //_/ __ _/ __/
  / ,<  / __ `/ ___/ __ `/ /_
 / /| |/ /_/ / /  / /_/ / __/
/_/ |_|\__,_/_/   \__,_/_/

  Apache Karaf (3.0.0)

Hit '' for a list of available commands
and '[cmd] --help' for help on a specific command.
Hit '' or type 'system:shutdown' or 'logout' to shutdown Karaf.

karaf@root()> feature:install war
Error executing command: Error resolving artifact
org.apache.karaf.http:org.apache.karaf.http.core:jar:3.0.0: Could not
transfer artifact
org.apache.karaf.http:org.apache.karaf.http.core:jar:3.0.0 from/to central (
http://repo1.maven.org/maven2/): Error transferring file: Connection refused
karaf@root()>



On Sat, Dec 21, 2013 at 12:40 PM, Jamie G.  wrote:

> Hi,
>
> We resolved 1158 issues in this release:
>
> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0-release.page?view=markup
>
> Dependency changes can be reviewed here:
>
> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup
> (The website published table will be updated after vote)
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-013/
>
> Git tag:
> karaf-3.0.0
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> This vote will be open for 72 hours.
>

Re: [VOTE] Release Apache Karaf version 3.0.0

[Heath Kesler]

+1 non-binding
On Dec 21, 2013 2:58 PM, "Christian Schneider" 
wrote:

> +1 (non binding)
>
> Built the tag on windows and did some tests on the binary including cxf.
> Looks all very well.
> Many thanks to the whole karaf team and especially to JB who put a
> tremendous amount of work into this release.
>
> Christian
>
> Am 21.12.2013 18:40, schrieb Jamie G.:
>
>> Hi,
>>
>> We resolved 1158 issues in this release:
>> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/
>> webapp/index/community/download/karaf-3.0.0-release.page?view=markup
>>
>> Dependency changes can be reviewed here:
>> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/
>> webapp/index/documentation/karaf-dependencies/karaf-deps-
>> 3.0.x.page?view=markup
>> (The website published table will be updated after vote)
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachekaraf-013/
>>
>> Git tag:
>> karaf-3.0.0
>>
>> Please vote to approve this release:
>>
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>>
>> This vote will be open for 72 hours.
>>
>>
>
> --
>  Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
>

Re: [VOTE] Release Apache Karaf version 3.0.0

[Christian Schneider]

+1 (non binding)

Built the tag on windows and did some tests on the binary including cxf. 
Looks all very well.
Many thanks to the whole karaf team and especially to JB who put a 
tremendous amount of work into this release.


Christian

Am 21.12.2013 18:40, schrieb Jamie G.:

Hi,

We resolved 1158 issues in this release:
http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0-release.page?view=markup

Dependency changes can be reviewed here:
http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup
(The website published table will be updated after vote)

Staging repository:
https://repository.apache.org/content/repositories/orgapachekaraf-013/

Git tag:
karaf-3.0.0

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.




--
 
Christian Schneider

http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [VOTE] Release Apache Karaf version 3.0.0

[Christian Schneider]

+1 (non binding)

Built the tag on windows and did some tests on the binary including cxf. 
Looks all very well.
Many thanks to the whole karaf team and especially to JB who put a 
tremendous amount of work into this release.


Christian

Am 21.12.2013 18:40, schrieb Jamie G.:

Hi,

We resolved 1158 issues in this release:
http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0-release.page?view=markup

Dependency changes can be reviewed here:
http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup
(The website published table will be updated after vote)

Staging repository:
https://repository.apache.org/content/repositories/orgapachekaraf-013/

Git tag:
karaf-3.0.0

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.




--
 
Christian Schneider

http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com

Re: [VOTE] Release Apache Karaf version 3.0.0

[Achim Nierbeck]

+1 (binding)

compiling tag worked right away.

regards, Achim


2013/12/21 Christoph Gritschenberger 

> Sorry for being a bit of a grinch here:
>
> -1, because an itest fails
>
> Results :
>
> Tests in error:
>   testJMXSecurityAsAdmin(org.apache.karaf.itests.JMXSecurityTest):
> Configuration org.apache.karaf.service.acl.command.1387655750210_36.x
> deleted
>
> Tests run: 93, Failures: 0, Errors: 1, Skipped: 2
>
> I was able to reproduce it on fresh installs (the second build went OK on
> both systems I tested this on).
>
> I'll investigate the test-failure further later this evening.
>
> kind regards,
> christoph
>
>
>
> On 2013-12-21 18:40, Jamie G. wrote:
>
>> Hi,
>>
>> We resolved 1158 issues in this release:
>> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/
>> webapp/index/community/download/karaf-3.0.0-release.page?view=markup
>>
>> Dependency changes can be reviewed here:
>> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/
>> webapp/index/documentation/karaf-dependencies/karaf-deps-
>> 3.0.x.page?view=markup
>> (The website published table will be updated after vote)
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachekaraf-013/
>>
>> Git tag:
>> karaf-3.0.0
>>
>> Please vote to approve this release:
>>
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>>
>> This vote will be open for 72 hours.
>>
>>
>


-- 

Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
OPS4J Pax for Vaadin 
Commiter & Project Lead
blog 

Re: [VOTE] Release Apache Karaf version 3.0.0

[Christoph Gritschenberger]

Sorry for being a bit of a grinch here:

-1, because an itest fails

Results :

Tests in error:
  testJMXSecurityAsAdmin(org.apache.karaf.itests.JMXSecurityTest): 
Configuration org.apache.karaf.service.acl.command.1387655750210_36.x 
deleted


Tests run: 93, Failures: 0, Errors: 1, Skipped: 2

I was able to reproduce it on fresh installs (the second build went OK 
on both systems I tested this on).


I'll investigate the test-failure further later this evening.

kind regards,
christoph


On 2013-12-21 18:40, Jamie G. wrote:

Hi,

We resolved 1158 issues in this release:
http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0-release.page?view=markup

Dependency changes can be reviewed here:
http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup
(The website published table will be updated after vote)

Staging repository:
https://repository.apache.org/content/repositories/orgapachekaraf-013/

Git tag:
karaf-3.0.0

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.





  




http://java.oracle.com/"/>

















































http://bugreport.sun.com/bugreport/"/>





  
  
  
  
  
javax.management.MBeanException: Configuration org.apache.karaf.service.acl.command.1387655750210_36.x deleted
	at org.apache.karaf.config.core.impl.ConfigMBeanImpl.getConfigs(ConfigMBeanImpl.java:75)
	at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at sun.reflect.misc.Trampoline.invoke(MethodUtil.java:75)
	at sun.reflect.GeneratedMethodAccessor25.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at sun.reflect.misc.MethodUtil.invoke(MethodUtil.java:279)
	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:112)
	at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:46)
	at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:237)
	at com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:83)
	at com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:206)
	at javax.management.StandardMBean.getAttribute(StandardMBean.java:372)
	at Proxy8161bf25_7a09_4f5b_bbb3_1dafd4742bc8.getAttribute(Unknown Source)
	at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:647)
	at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678)
	at sun.reflect.GeneratedMethodAccessor42.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.apache.karaf.management.boot.KarafMBeanServerBuilder$MBeanInvocationHandler.invoke(KarafMBeanServerBuilder.java:66)
	at com.sun.proxy.$Proxy14.getAttribute(Unknown Source)
	at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1464)
	at javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:97)
	at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1328)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1427)
	at javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:657)
	at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:322)
	at sun.rmi.transport.Transport$1.run(Transport.java:177)
	at sun.rmi.transport.Transport$1.run(Transport.java:174)
	at java.security.AccessController.doPrivileged(Native Method)
	at sun.rmi.transport.Transport.serviceCall(Transport.java:173)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:556)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:811)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:670)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(

Re: [VOTE] Release Apache Karaf version 3.0.0

[Ehsan Zaery Moghaddam]

+1 from me too.

I Think shifting to Git is a big step forward.

Ehsan


On Sat, Dec 21, 2013 at 9:20 PM, David Bosschaert <
david.bosscha...@gmail.com> wrote:

> +1 from me.
>
> Good work guys. 1158 issues - wow!
>
> David
>
> On 21 December 2013 17:40, Jamie G.  wrote:
> > Hi,
> >
> > We resolved 1158 issues in this release:
> >
> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0-release.page?view=markup
> >
> > Dependency changes can be reviewed here:
> >
> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup
> > (The website published table will be updated after vote)
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachekaraf-013/
> >
> > Git tag:
> > karaf-3.0.0
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Veto the release (please provide specific comments)
> >
> > This vote will be open for 72 hours.
>

Re: [VOTE] Release Apache Karaf version 3.0.0

[David Bosschaert]

+1 from me.

Good work guys. 1158 issues - wow!

David

On 21 December 2013 17:40, Jamie G.  wrote:
> Hi,
>
> We resolved 1158 issues in this release:
> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0-release.page?view=markup
>
> Dependency changes can be reviewed here:
> http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup
> (The website published table will be updated after vote)
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-013/
>
> Git tag:
> karaf-3.0.0
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> This vote will be open for 72 hours.

Re: [VOTE] Release Apache Karaf version 3.0.0

[Jean-Baptiste Onofré]

+1 (binding)

FYI, I'm updating and preparing the publication of users and developers 
guide, and better integration into the website.


Regards
JB

On 12/21/2013 06:40 PM, Jamie G. wrote:

Hi,

We resolved 1158 issues in this release:
http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0-release.page?view=markup

Dependency changes can be reviewed here:
http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup
(The website published table will be updated after vote)

Staging repository:
https://repository.apache.org/content/repositories/orgapachekaraf-013/

Git tag:
karaf-3.0.0

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

[VOTE] Release Apache Karaf version 3.0.0

[Jamie G.]

Hi,

We resolved 1158 issues in this release:
http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/community/download/karaf-3.0.0-release.page?view=markup

Dependency changes can be reviewed here:
http://svn.apache.org/viewvc/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page?view=markup
(The website published table will be updated after vote)

Staging repository:
https://repository.apache.org/content/repositories/orgapachekaraf-013/

Git tag:
karaf-3.0.0

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[Jamie G.]

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 (non-binding): N/A

Please note, as discussed above, we feel that as a technology preview
we can pass this majority vote - the known issues are listed on the
release notes page.

I will copy this release to the Karaf dist directory and promote the
artifacts to the central Maven repository.

On Fri, Mar 15, 2013 at 12:49 AM, Freeman Fang  wrote:
> +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, 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 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 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 continuing forward, marking
>> the above as known issues with this RC preview.
>>
>> Comments are encouraged.
>>
>> Cheers,
>> Jamie
>>
>> On Thu, Mar 14, 2013 at 8:12 AM, Jean-Baptiste Onofré 
>> wrote:
>>>
>>> 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 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, Mar 14, 2013 at 11:05 AM, Łukasz Dywicki
 wrote:

> 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ść napisana przez Christoph Gritschenberger <
> christoph.gritschenber...@gmail.com> w dniu 13 mar 2013, o godz.
>>
>> 10:31:
>>
>> +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 technology preview release candidate.
>>>
>>> Staging repository:
>>>
>> https://repository.apache.org/content/repositories/orgapachekaraf-019/
>>>
>>> Release tags:
>>> https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/
>>>
>>> 3.0.x Dependencies table:
>>>
>
>
> https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page
>>>
>>>
>>> Please vote to approve this release:
>>>
>>> [ ] +1 Approve the release
>>> [ ] -1 Veto the release (plea

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[Freeman Fang]

+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, 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 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 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 continuing forward, marking
> the above as known issues with this RC preview.
> 
> Comments are encouraged.
> 
> Cheers,
> Jamie
> 
> On Thu, Mar 14, 2013 at 8:12 AM, Jean-Baptiste Onofré 
> wrote:
>> 
>> 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 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, Mar 14, 2013 at 11:05 AM, Łukasz Dywicki
>>> wrote:
>>> 
 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ść napisana przez Christoph Gritschenberger <
 christoph.gritschenber...@gmail.com> w dniu 13 mar 2013, o godz.
> 
> 10:31:
> 
> +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 technology preview release candidate.
>> 
>> Staging repository:
>> 
> https://repository.apache.org/content/repositories/orgapachekaraf-019/
>> 
>> Release tags:
>> https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/
>> 
>> 3.0.x Dependencies table:
>> 
 
 
 https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page
>> 
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>> 
>> This vote will be open for 72 hours.
>> 
> 
 
>>> 
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
 
 
 
 --
 
 Apache Karaf  Committer & PMC
 OPS4J Pax Web  Committer &
 Project Lead
 OPS4J Pax for Vaadin 
 Commiter & Project Lead
 blog 
 
>>> 
>>> 
>> I'm fine to change it to +1

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[Jamie G.]

+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 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 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 continuing forward, marking
 the above as known issues with this RC preview.

 Comments are encouraged.

 Cheers,
 Jamie

 On Thu, Mar 14, 2013 at 8:12 AM, Jean-Baptiste Onofré 
 wrote:
>
> 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 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, Mar 14, 2013 at 11:05 AM, Łukasz Dywicki
>> wrote:
>>
>>> 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ść napisana przez Christoph Gritschenberger <
>>> christoph.gritschenber...@gmail.com> w dniu 13 mar 2013, o godz.

 10:31:

 +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 technology preview release candidate.
>
> Staging repository:
>
 https://repository.apache.org/content/repositories/orgapachekaraf-019/
>
> Release tags:
> https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/
>
> 3.0.x Dependencies table:
>
>>>
>>>
>>> https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page
>
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> This vote will be open for 72 hours.
>

>>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>>>
>>>
>>>
>>> --
>>>
>>> Apache Karaf  Committer & PMC
>>> OPS4J Pax Web  Committer &
>>> Project Lead
>>> OPS4J Pax for Vaadin 
>>> Commiter & Project Lead
>>> blog 
>>>
>>
>>
> I'm fine to change it to +1

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[Charles Moulliard]

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 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 continuing forward, marking
the above as known issues with this RC preview.

Comments are encouraged.

Cheers,
Jamie

On Thu, Mar 14, 2013 at 8:12 AM, Jean-Baptiste Onofré 
wrote:

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 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, Mar 14, 2013 at 11:05 AM, Łukasz Dywicki
wrote:


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ść napisana przez Christoph Gritschenberger <
christoph.gritschenber...@gmail.com> w dniu 13 mar 2013, o godz.

10:31:

+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 technology preview release candidate.

Staging repository:


https://repository.apache.org/content/repositories/orgapachekaraf-019/

Release tags:
https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/

3.0.x Dependencies table:




https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page


Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.








--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com



--

Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
OPS4J Pax for Vaadin 
Commiter & Project Lead
blog 





I'm fine to change it to +1

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[Andreas Pieber]

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 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 continuing forward, marking
> > the above as known issues with this RC preview.
> >
> > Comments are encouraged.
> >
> > Cheers,
> > Jamie
> >
> > On Thu, Mar 14, 2013 at 8:12 AM, Jean-Baptiste Onofré 
> > wrote:
> > > 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 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, Mar 14, 2013 at 11:05 AM, Łukasz Dywicki
> > >> wrote:
> > >>
> > >>> 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ść napisana przez Christoph Gritschenberger <
> > >>> christoph.gritschenber...@gmail.com> w dniu 13 mar 2013, o godz.
> > 10:31:
> > >>>
> >  +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 technology preview release candidate.
> > >
> > > Staging repository:
> > >
> > https://repository.apache.org/content/repositories/orgapachekaraf-019/
> > >
> > > Release tags:
> > > https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/
> > >
> > > 3.0.x Dependencies table:
> > >
> > >>>
> > >>>
> >
> https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page
> > >
> > >
> > > Please vote to approve this release:
> > >
> > > [ ] +1 Approve the release
> > > [ ] -1 Veto the release (please provide specific comments)
> > >
> > > This vote will be open for 72 hours.
> > >
> > 
> > 
> > >>>
> > >>>
> > >>
> > >>
> > >
> > > --
> > > Jean-Baptiste Onofré
> > > jbono...@apache.org
> > > http://blog.nanthrax.net
> > > Talend - http://www.talend.com
> >
>
>
>
> --
>
> Apache Karaf  Committer & PMC
> OPS4J Pax Web  Committer &
> Project Lead
> OPS4J Pax for Vaadin 
> Commiter & Project Lead
> blog 
>

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[Guillaume Nodet]

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 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 continuing forward, marking
> > the above as known issues with this RC preview.
> >
> > Comments are encouraged.
> >
> > Cheers,
> > Jamie
> >
> > On Thu, Mar 14, 2013 at 8:12 AM, Jean-Baptiste Onofré 
> > wrote:
> > > 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 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, Mar 14, 2013 at 11:05 AM, Łukasz Dywicki
> > >> wrote:
> > >>
> > >>> 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ść napisana przez Christoph Gritschenberger <
> > >>> christoph.gritschenber...@gmail.com> w dniu 13 mar 2013, o godz.
> > 10:31:
> > >>>
> >  +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 technology preview release candidate.
> > >
> > > Staging repository:
> > >
> > https://repository.apache.org/content/repositories/orgapachekaraf-019/
> > >
> > > Release tags:
> > > https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/
> > >
> > > 3.0.x Dependencies table:
> > >
> > >>>
> > >>>
> >
> https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page
> > >
> > >
> > > Please vote to approve this release:
> > >
> > > [ ] +1 Approve the release
> > > [ ] -1 Veto the release (please provide specific comments)
> > >
> > > This vote will be open for 72 hours.
> > >
> > 
> > 
> > >>>
> > >>>
> > >>
> > >>
> > >
> > > --
> > > Jean-Baptiste Onofré
> > > jbono...@apache.org
> > > http://blog.nanthrax.net
> > > Talend - http://www.talend.com
> >
>
>
>
> --
>
> Apache Karaf  Committer & PMC
> OPS4J Pax Web  Committer &
> Project Lead
> OPS4J Pax for Vaadin 
> Commiter & Project Lead
> blog 
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[Achim Nierbeck]

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 continuing forward, marking
> the above as known issues with this RC preview.
>
> Comments are encouraged.
>
> Cheers,
> Jamie
>
> On Thu, Mar 14, 2013 at 8:12 AM, Jean-Baptiste Onofré 
> wrote:
> > 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 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, Mar 14, 2013 at 11:05 AM, Łukasz Dywicki
> >> wrote:
> >>
> >>> 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ść napisana przez Christoph Gritschenberger <
> >>> christoph.gritschenber...@gmail.com> w dniu 13 mar 2013, o godz.
> 10:31:
> >>>
>  +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 technology preview release candidate.
> >
> > Staging repository:
> >
> https://repository.apache.org/content/repositories/orgapachekaraf-019/
> >
> > Release tags:
> > https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/
> >
> > 3.0.x Dependencies table:
> >
> >>>
> >>>
> https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page
> >
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Veto the release (please provide specific comments)
> >
> > This vote will be open for 72 hours.
> >
> 
> 
> >>>
> >>>
> >>
> >>
> >
> > --
> > Jean-Baptiste Onofré
> > jbono...@apache.org
> > http://blog.nanthrax.net
> > Talend - http://www.talend.com
>



-- 

Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
OPS4J Pax for Vaadin 
Commiter & Project Lead
blog 

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[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 continuing forward, marking
the above as known issues with this RC preview.

Comments are encouraged.

Cheers,
Jamie

On Thu, Mar 14, 2013 at 8:12 AM, Jean-Baptiste Onofré  wrote:
> 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 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, Mar 14, 2013 at 11:05 AM, Łukasz Dywicki
>> wrote:
>>
>>> 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ść napisana przez Christoph Gritschenberger <
>>> christoph.gritschenber...@gmail.com> w dniu 13 mar 2013, o godz. 10:31:
>>>
 +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 technology preview release candidate.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-019/
>
> Release tags:
> https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/
>
> 3.0.x Dependencies table:
>
>>>
>>> https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page
>
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> This vote will be open for 72 hours.
>


>>>
>>>
>>
>>
>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[Guillaume Nodet]

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 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, Mar 14, 2013 at 11:05 AM, Łukasz Dywicki  >wrote:
>
> > 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ść napisana przez Christoph Gritschenberger <
> > christoph.gritschenber...@gmail.com> w dniu 13 mar 2013, o godz. 10:31:
> >
> > > +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 technology preview release candidate.
> > >>
> > >> Staging repository:
> > >>
> https://repository.apache.org/content/repositories/orgapachekaraf-019/
> > >>
> > >> Release tags:
> > >> https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/
> > >>
> > >> 3.0.x Dependencies table:
> > >>
> >
> https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page
> > >>
> > >> Please vote to approve this release:
> > >>
> > >> [ ] +1 Approve the release
> > >> [ ] -1 Veto the release (please provide specific comments)
> > >>
> > >> This vote will be open for 72 hours.
> > >>
> > >
> > >
> >
> >
>
>
> --
> Charles Moulliard
> Apache Committer / Sr. Enterprise Architect (RedHat)
> Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[Jean-Baptiste Onofré]

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 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, Mar 14, 2013 at 11:05 AM, Łukasz Dywicki wrote:


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ść napisana przez Christoph Gritschenberger <
christoph.gritschenber...@gmail.com> w dniu 13 mar 2013, o godz. 10:31:


+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 technology preview release candidate.

Staging repository:
https://repository.apache.org/content/repositories/orgapachekaraf-019/

Release tags:
https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/

3.0.x Dependencies table:


https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page


Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.












--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[Charles Moulliard]

-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, Mar 14, 2013 at 11:05 AM, Łukasz Dywicki wrote:

> 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ść napisana przez Christoph Gritschenberger <
> christoph.gritschenber...@gmail.com> w dniu 13 mar 2013, o godz. 10:31:
>
> > +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 technology preview release candidate.
> >>
> >> Staging repository:
> >> https://repository.apache.org/content/repositories/orgapachekaraf-019/
> >>
> >> Release tags:
> >> https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/
> >>
> >> 3.0.x Dependencies table:
> >>
> https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page
> >>
> >> Please vote to approve this release:
> >>
> >> [ ] +1 Approve the release
> >> [ ] -1 Veto the release (please provide specific comments)
> >>
> >> This vote will be open for 72 hours.
> >>
> >
> >
>
>


-- 
Charles Moulliard
Apache Committer / Sr. Enterprise Architect (RedHat)
Twitter : @cmoulliard | Blog : http://cmoulliard.blogspot.com

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[Łukasz Dywicki]

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ść napisana przez Christoph Gritschenberger 
 w dniu 13 mar 2013, o godz. 10:31:

> +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 technology preview release candidate.
>> 
>> Staging repository:
>> https://repository.apache.org/content/repositories/orgapachekaraf-019/
>> 
>> Release tags:
>> https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/
>> 
>> 3.0.x Dependencies table:
>> https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page
>> 
>> Please vote to approve this release:
>> 
>> [ ] +1 Approve the release
>> [ ] -1 Veto the release (please provide specific comments)
>> 
>> This vote will be open for 72 hours.
>> 
> 
> 

Re: [DISCUSS] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)

[Jean-Baptiste Onofré]

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 "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 case, it will be an atomic bundle (but the name Utils
is probably not the best one ;)).

All depends what we put in Karaf Utils.



Definitely, I was referring to the current situtation which is only a set
of utility classes, no real services or apis.




Regards
JB


On 03/13/2013 04:35 PM, Guillaume Nodet wrote:


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 should
be (which is what an api package is), which is the exact opposite of a
utility library which tends to grow over time.


On Wed, Mar 13, 2013 at 4:28 PM, Guillaume Nodet 
wrote:





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 easily embed only the
packages they use.  It's really just a matter of not using
org.apache.karaf.util.* but org.apache.karaf.util.xxx in the definition
of
the private package.


  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 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 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: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 core services
- an end-user can use core services if he wants

   Fortunately trunk is a little simpler already:


- core contains OSGi services and mbeans (the mbeans are only
registered
as osgi services)
- commands contains the commands and uses the core services

This simplification is an example of how we can reduce the number of
modules without sacrificing maintainability. We might need an
improved
aries jmx where an admin can switch on and off jmx mbeans but apart
from
this I think the structure is fine.

   I'm not fully agree with Christian. OSGi doesn't mean that we have
to


expose all as OSGi, for instance, it doesn't make sense for Karaf
utils (we are not in a developer bullshit approach where we turn all
in OSGi just for "fun" or "elegance", we have to keep things simple,
maintainable, and coherent).

  I hope you do not really mean to say my opinion is a "developer

bullshit
aproach". My main focus is exactly to keep things simple,
maintainable
and coherent. Just more from a developer point of view than an admin
point of view.

Christian







  --

Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com





--

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/







--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com







--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [DISCUSS] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)

[Guillaume Nodet]

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 "exposes" a set of services that different other
> bundles use: in that case, it will be an atomic bundle (but the name Utils
> is probably not the best one ;)).
>
> All depends what we put in Karaf Utils.
>

Definitely, I was referring to the current situtation which is only a set
of utility classes, no real services or apis.


>
> Regards
> JB
>
>
> On 03/13/2013 04:35 PM, Guillaume Nodet wrote:
>
>> 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 should
>> be (which is what an api package is), which is the exact opposite of a
>> utility library which tends to grow over time.
>>
>>
>> On Wed, Mar 13, 2013 at 4:28 PM, Guillaume Nodet 
>> wrote:
>>
>>
>>>
>>>
>>> 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 easily embed only the
>>> packages they use.  It's really just a matter of not using
>>> org.apache.karaf.util.* but org.apache.karaf.util.xxx in the definition
>>> of
>>> the private package.
>>>
>>>
>>>  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 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 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: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 core services
 - an end-user can use core services if he wants

   Fortunately trunk is a little simpler already:

>>> - core contains OSGi services and mbeans (the mbeans are only
>>> registered
>>> as osgi services)
>>> - commands contains the commands and uses the core services
>>>
>>> This simplification is an example of how we can reduce the number of
>>> modules without sacrificing maintainability. We might need an
>>> improved
>>> aries jmx where an admin can switch on and off jmx mbeans but apart
>>> from
>>> this I think the structure is fine.
>>>
>>>   I'm not fully agree with Christian. OSGi doesn't mean that we have
>>> to
>>>
 expose all as OSGi, for instance, it doesn't make sense for Karaf
 utils (we are not in a developer bullshit approach where we turn all
 in OSGi just for "fun" or "elegance", we have to keep things simple,
 maintainable, and coherent).

  I hope you do not really mean to say my opinion is a "developer
>>> bullshit
>>> aproach". My main focus is exactly to keep things simple,
>>> maintainable
>>> and coherent. Just more from a developer point of view than an admin
>>> point of view.
>>>
>>> Christian
>>>
>>>
>>>
>>
>
>  --
 Jean-Baptiste Onofré
 jbono...@apache.org
 http://blog.nanthrax.net
 Talend - http://www.talend.com


>>>
>>>
>>> --
>>> 
>>> Guillaume Nodet
>>> 
>>> Red Hat, Open Source Integration
>>>
>>> Email: gno...@redhat.com
>>> Web: http://fusesource.com
>>> Blog: http://gnodet.blogspot.com/
>>>
>>>
>>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: [DISCUSS] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)

[Jean-Baptiste Onofré]

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 case, it will be an atomic bundle (but the name 
Utils is probably not the best one ;)).


All depends what we put in Karaf Utils.

Regards
JB

On 03/13/2013 04:35 PM, Guillaume Nodet wrote:

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 should
be (which is what an api package is), which is the exact opposite of a
utility library which tends to grow over time.


On Wed, Mar 13, 2013 at 4:28 PM, Guillaume Nodet  wrote:





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 easily embed only the
packages they use.  It's really just a matter of not using
org.apache.karaf.util.* but org.apache.karaf.util.xxx in the definition of
the private package.



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 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 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: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 core services
- an end-user can use core services if he wants

  Fortunately trunk is a little simpler already:

- core contains OSGi services and mbeans (the mbeans are only
registered
as osgi services)
- commands contains the commands and uses the core services

This simplification is an example of how we can reduce the number of
modules without sacrificing maintainability. We might need an improved
aries jmx where an admin can switch on and off jmx mbeans but apart
from
this I think the structure is fine.

  I'm not fully agree with Christian. OSGi doesn't mean that we have to

expose all as OSGi, for instance, it doesn't make sense for Karaf
utils (we are not in a developer bullshit approach where we turn all
in OSGi just for "fun" or "elegance", we have to keep things simple,
maintainable, and coherent).


I hope you do not really mean to say my opinion is a "developer
bullshit
aproach". My main focus is exactly to keep things simple, maintainable
and coherent. Just more from a developer point of view than an admin
point of view.

Christian








--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com





--

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/







--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [DISCUSS] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)

[Jean-Baptiste Onofré]

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, 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
structured like this:
- core provide OSGi services
- commands use the core services
- MBeans use the core services
- an end-user can use core services if he wants



Yes, and from a purely technical side, it's really nice.  As Ioannis said,
it can be troublesome for users that Karaf comes with 80 bundles ... It has
the nasty drawback of not looking lightweight anymore ...




Where I'm fully agree is to avoid to go too "deep" in granularity: we
already discussed of Karaf utils: it's a jar embedded in other bundles,
it's not a bundle exposing a service or API used by other bundles.

I'm not fully agree with Christian. OSGi doesn't mean that we have to
expose all as OSGi, for instance, it doesn't make sense for Karaf utils (we
are not in a developer bullshit approach where we turn all in OSGi just for
"fun" or "elegance", we have to keep things simple, maintainable, and
coherent).

My 0.02€

Regards
JB


On 03/13/2013 11:21 AM, Guillaume Nodet wrote:


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 projects like CXF or Camel, we develop for OSGi so we should try to
use it in the best way.

Let's consider the 3 different things we can have in OSGi : apis,
implementations and libraries.
We have basic rules:
* service api packages should be exported
* service implementation packages should be kept private
When a service bundle ships the api in the same bundle as the
implementation, the rule is to export and import the api package to let
the
framework use package substitution if needed.   For libraries, the rule is
to export the packages and not import those, as subsitution should never
occur.

One first case is service api and implementations.  A service bundle can
either provide its own API or the API be provided by a separate package.
   With the osgi compendium jar, it's recommended to not use it because it
breaks modularity: this bundle provides lots of different service apis, so
you can't change them one by one.  That's why osgi service implementation
usually ship their own API.   For apis we control, things are slightly
different, as we don't have those big bundles.  For those cases, the best
thing is actually to ship the API and the service implementation in
different bundles.  This allows updating the service implementation
without
requiring a refresh of the other bundles.

Let's now discuss the bundle lifecycle pov.  If a bundle providing a
service depends for the implementation on libraries packages provided by
external bundles, it breaks the abstraction and modularity to some degree
by exposing internal constraints.  Those constraints are better captured
by
service dependencies.
Let's take an example: we have bundle A and B depending on a library
provided by bundle C.  If you want to update C to provide a fix needed for
A, this will also impact B, which could cause a regression to B
functionality.  There are transient ways around that: i.e. deploy a new
version of bundle C or update C and only refresh A.  But those are only
transient as in felix, the wiring isn't retained across restarts.  And
this
can't really be controlled well with the tools we have at hand.
On the other hand, if both bundle A and B embeds the C library needed you
can update A and B independently, so a better modularity at the cost of
less code sharing.

So in an ideal OSGi world, service APIs would be shipped in individual
bundles, and service implementation would have no other constraints than
on
other services.

We're not in an ideal world though.  For big projects such as Camel, CXF,
ActiveMQ, there's not always a real API and other constraints may come in,
mostly that they are not architected purely for OSGi.
Anyway, for small library bundles that can easily be embedded, I think we
should do it: there's no drawbacks I can see, and it improves modularity.


On Wed, Mar 13, 2013 at 10:05 AM, Christian Schneider <
ch...@die-schneider.net> wrote:

  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 cont

Re: [DISCUSS] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)

[Guillaume Nodet]

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 should
be (which is what an api package is), which is the exact opposite of a
utility library which tends to grow over time.


On Wed, Mar 13, 2013 at 4:28 PM, Guillaume Nodet  wrote:

>
>
>
> 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 easily embed only the
> packages they use.  It's really just a matter of not using
> org.apache.karaf.util.* but org.apache.karaf.util.xxx in the definition of
> the private package.
>
>
>> 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 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 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: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 core services
>> - an end-user can use core services if he wants
>>
>>  Fortunately trunk is a little simpler already:
> - core contains OSGi services and mbeans (the mbeans are only
> registered
> as osgi services)
> - commands contains the commands and uses the core services
>
> This simplification is an example of how we can reduce the number of
> modules without sacrificing maintainability. We might need an improved
> aries jmx where an admin can switch on and off jmx mbeans but apart
> from
> this I think the structure is fine.
>
>  I'm not fully agree with Christian. OSGi doesn't mean that we have to
>> expose all as OSGi, for instance, it doesn't make sense for Karaf
>> utils (we are not in a developer bullshit approach where we turn all
>> in OSGi just for "fun" or "elegance", we have to keep things simple,
>> maintainable, and coherent).
>>
> I hope you do not really mean to say my opinion is a "developer
> bullshit
> aproach". My main focus is exactly to keep things simple, maintainable
> and coherent. Just more from a developer point of view than an admin
> point of view.
>
> Christian
>
>

>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbono...@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
> --
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>
>


-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: [DISCUSS] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)

[Christian Schneider]

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 in Karaf 2.x, modules on trunk are
structured like this:
- core provide OSGi services
- commands use the core services
- MBeans use the core services
- an end-user can use core services if he wants


Yes, and from a purely technical side, it's really nice.  As Ioannis said,
it can be troublesome for users that Karaf comes with 80 bundles ... It has
the nasty drawback of not looking lightweight anymore ...
I fully agree. We have to look into ways to reduce the numbers of 
bundles. I think though that we can already reduce the number on the

development side.

For example if we manage to provide a small api for the console then we 
could unify core and commands which would almost cut the number of karaf 
bundles

in half.

Christian


--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [DISCUSS] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)

[Guillaume Nodet]

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 easily embed only the
packages they use.  It's really just a matter of not using
org.apache.karaf.util.* but org.apache.karaf.util.xxx in the definition of
the private package.


> 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 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 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: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 core services
> - an end-user can use core services if he wants
>
>  Fortunately trunk is a little simpler already:
 - core contains OSGi services and mbeans (the mbeans are only registered
 as osgi services)
 - commands contains the commands and uses the core services

 This simplification is an example of how we can reduce the number of
 modules without sacrificing maintainability. We might need an improved
 aries jmx where an admin can switch on and off jmx mbeans but apart from
 this I think the structure is fine.

  I'm not fully agree with Christian. OSGi doesn't mean that we have to
> expose all as OSGi, for instance, it doesn't make sense for Karaf
> utils (we are not in a developer bullshit approach where we turn all
> in OSGi just for "fun" or "elegance", we have to keep things simple,
> maintainable, and coherent).
>
 I hope you do not really mean to say my opinion is a "developer bullshit
 aproach". My main focus is exactly to keep things simple, maintainable
 and coherent. Just more from a developer point of view than an admin
 point of view.

 Christian


>>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: [DISCUSS] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)

[Guillaume Nodet]

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
> structured like this:
> - core provide OSGi services
> - commands use the core services
> - MBeans use the core services
> - an end-user can use core services if he wants
>

Yes, and from a purely technical side, it's really nice.  As Ioannis said,
it can be troublesome for users that Karaf comes with 80 bundles ... It has
the nasty drawback of not looking lightweight anymore ...


>
> Where I'm fully agree is to avoid to go too "deep" in granularity: we
> already discussed of Karaf utils: it's a jar embedded in other bundles,
> it's not a bundle exposing a service or API used by other bundles.
>
> I'm not fully agree with Christian. OSGi doesn't mean that we have to
> expose all as OSGi, for instance, it doesn't make sense for Karaf utils (we
> are not in a developer bullshit approach where we turn all in OSGi just for
> "fun" or "elegance", we have to keep things simple, maintainable, and
> coherent).
>
> My 0.02€
>
> Regards
> JB
>
>
> On 03/13/2013 11:21 AM, Guillaume Nodet wrote:
>
>> 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 projects like CXF or Camel, we develop for OSGi so we should try to
>> use it in the best way.
>>
>> Let's consider the 3 different things we can have in OSGi : apis,
>> implementations and libraries.
>> We have basic rules:
>>* service api packages should be exported
>>* service implementation packages should be kept private
>> When a service bundle ships the api in the same bundle as the
>> implementation, the rule is to export and import the api package to let
>> the
>> framework use package substitution if needed.   For libraries, the rule is
>> to export the packages and not import those, as subsitution should never
>> occur.
>>
>> One first case is service api and implementations.  A service bundle can
>> either provide its own API or the API be provided by a separate package.
>>   With the osgi compendium jar, it's recommended to not use it because it
>> breaks modularity: this bundle provides lots of different service apis, so
>> you can't change them one by one.  That's why osgi service implementation
>> usually ship their own API.   For apis we control, things are slightly
>> different, as we don't have those big bundles.  For those cases, the best
>> thing is actually to ship the API and the service implementation in
>> different bundles.  This allows updating the service implementation
>> without
>> requiring a refresh of the other bundles.
>>
>> Let's now discuss the bundle lifecycle pov.  If a bundle providing a
>> service depends for the implementation on libraries packages provided by
>> external bundles, it breaks the abstraction and modularity to some degree
>> by exposing internal constraints.  Those constraints are better captured
>> by
>> service dependencies.
>> Let's take an example: we have bundle A and B depending on a library
>> provided by bundle C.  If you want to update C to provide a fix needed for
>> A, this will also impact B, which could cause a regression to B
>> functionality.  There are transient ways around that: i.e. deploy a new
>> version of bundle C or update C and only refresh A.  But those are only
>> transient as in felix, the wiring isn't retained across restarts.  And
>> this
>> can't really be controlled well with the tools we have at hand.
>> On the other hand, if both bundle A and B embeds the C library needed you
>> can update A and B independently, so a better modularity at the cost of
>> less code sharing.
>>
>> So in an ideal OSGi world, service APIs would be shipped in individual
>> bundles, and service implementation would have no other constraints than
>> on
>> other services.
>>
>> We're not in an ideal world though.  For big projects such as Camel, CXF,
>> ActiveMQ, there's not always a real API and other constraints may come in,
>> mostly that they are not architected purely for OSGi.
>> Anyway, for small library bundles that can easily be embedded, I think we
>> should do it: there's no drawbacks I can see, and it improves modularity.
>>
>>
>> On Wed, Mar 13, 2013 at 10:05 AM, Christian Schneider <
>> ch...@die-schneider.net> wrote:
>>
>>  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. 

Re: [DISCUSS] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)

[Jean-Baptiste Onofré]

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 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 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: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 core services
- an end-user can use core services if he wants


Fortunately trunk is a little simpler already:
- core contains OSGi services and mbeans (the mbeans are only registered
as osgi services)
- commands contains the commands and uses the core services

This simplification is an example of how we can reduce the number of
modules without sacrificing maintainability. We might need an improved
aries jmx where an admin can switch on and off jmx mbeans but apart from
this I think the structure is fine.


I'm not fully agree with Christian. OSGi doesn't mean that we have to
expose all as OSGi, for instance, it doesn't make sense for Karaf
utils (we are not in a developer bullshit approach where we turn all
in OSGi just for "fun" or "elegance", we have to keep things simple,
maintainable, and coherent).

I hope you do not really mean to say my opinion is a "developer bullshit
aproach". My main focus is exactly to keep things simple, maintainable
and coherent. Just more from a developer point of view than an admin
point of view.

Christian








--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [DISCUSS] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)

[Christian Schneider]

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 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: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 core services
- an end-user can use core services if he wants


Fortunately trunk is a little simpler already:
- core contains OSGi services and mbeans (the mbeans are only registered
as osgi services)
- commands contains the commands and uses the core services

This simplification is an example of how we can reduce the number of
modules without sacrificing maintainability. We might need an improved
aries jmx where an admin can switch on and off jmx mbeans but apart from
this I think the structure is fine.


I'm not fully agree with Christian. OSGi doesn't mean that we have to
expose all as OSGi, for instance, it doesn't make sense for Karaf
utils (we are not in a developer bullshit approach where we turn all
in OSGi just for "fun" or "elegance", we have to keep things simple,
maintainable, and coherent).

I hope you do not really mean to say my opinion is a "developer bullshit
aproach". My main focus is exactly to keep things simple, maintainable
and coherent. Just more from a developer point of view than an admin
point of view.

Christian






--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [DISCUSS] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)

[Jean-Baptiste Onofré]

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: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 core services
- an end-user can use core services if he wants


Fortunately trunk is a little simpler already:
- core contains OSGi services and mbeans (the mbeans are only registered
as osgi services)
- commands contains the commands and uses the core services

This simplification is an example of how we can reduce the number of
modules without sacrificing maintainability. We might need an improved
aries jmx where an admin can switch on and off jmx mbeans but apart from
this I think the structure is fine.


I'm not fully agree with Christian. OSGi doesn't mean that we have to
expose all as OSGi, for instance, it doesn't make sense for Karaf
utils (we are not in a developer bullshit approach where we turn all
in OSGi just for "fun" or "elegance", we have to keep things simple,
maintainable, and coherent).

I hope you do not really mean to say my opinion is a "developer bullshit
aproach". My main focus is exactly to keep things simple, maintainable
and coherent. Just more from a developer point of view than an admin
point of view.

Christian



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [DISCUSS] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)

[Christian Schneider]

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 core services
- an end-user can use core services if he wants


Fortunately trunk is a little simpler already:
- core contains OSGi services and mbeans (the mbeans are only registered 
as osgi services)

- commands contains the commands and uses the core services

This simplification is an example of how we can reduce the number of 
modules without sacrificing maintainability. We might need an improved 
aries jmx where an admin can switch on and off jmx mbeans but apart from 
this I think the structure is fine.


I'm not fully agree with Christian. OSGi doesn't mean that we have to 
expose all as OSGi, for instance, it doesn't make sense for Karaf 
utils (we are not in a developer bullshit approach where we turn all 
in OSGi just for "fun" or "elegance", we have to keep things simple, 
maintainable, and coherent).
I hope you do not really mean to say my opinion is a "developer bullshit 
aproach". My main focus is exactly to keep things simple, maintainable 
and coherent. Just more from a developer point of view than an admin 
point of view.


Christian

--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [DISCUSS] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)

[Jean-Baptiste Onofré]

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 core services
- MBeans use the core services
- an end-user can use core services if he wants

Where I'm fully agree is to avoid to go too "deep" in granularity: we 
already discussed of Karaf utils: it's a jar embedded in other bundles, 
it's not a bundle exposing a service or API used by other bundles.


I'm not fully agree with Christian. OSGi doesn't mean that we have to 
expose all as OSGi, for instance, it doesn't make sense for Karaf utils 
(we are not in a developer bullshit approach where we turn all in OSGi 
just for "fun" or "elegance", we have to keep things simple, 
maintainable, and coherent).


My 0.02€

Regards
JB

On 03/13/2013 11:21 AM, Guillaume Nodet wrote:

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 projects like CXF or Camel, we develop for OSGi so we should try to
use it in the best way.

Let's consider the 3 different things we can have in OSGi : apis,
implementations and libraries.
We have basic rules:
   * service api packages should be exported
   * service implementation packages should be kept private
When a service bundle ships the api in the same bundle as the
implementation, the rule is to export and import the api package to let the
framework use package substitution if needed.   For libraries, the rule is
to export the packages and not import those, as subsitution should never
occur.

One first case is service api and implementations.  A service bundle can
either provide its own API or the API be provided by a separate package.
  With the osgi compendium jar, it's recommended to not use it because it
breaks modularity: this bundle provides lots of different service apis, so
you can't change them one by one.  That's why osgi service implementation
usually ship their own API.   For apis we control, things are slightly
different, as we don't have those big bundles.  For those cases, the best
thing is actually to ship the API and the service implementation in
different bundles.  This allows updating the service implementation without
requiring a refresh of the other bundles.

Let's now discuss the bundle lifecycle pov.  If a bundle providing a
service depends for the implementation on libraries packages provided by
external bundles, it breaks the abstraction and modularity to some degree
by exposing internal constraints.  Those constraints are better captured by
service dependencies.
Let's take an example: we have bundle A and B depending on a library
provided by bundle C.  If you want to update C to provide a fix needed for
A, this will also impact B, which could cause a regression to B
functionality.  There are transient ways around that: i.e. deploy a new
version of bundle C or update C and only refresh A.  But those are only
transient as in felix, the wiring isn't retained across restarts.  And this
can't really be controlled well with the tools we have at hand.
On the other hand, if both bundle A and B embeds the C library needed you
can update A and B independently, so a better modularity at the cost of
less code sharing.

So in an ideal OSGi world, service APIs would be shipped in individual
bundles, and service implementation would have no other constraints than on
other services.

We're not in an ideal world though.  For big projects such as Camel, CXF,
ActiveMQ, there's not always a real API and other constraints may come in,
mostly that they are not architected purely for OSGi.
Anyway, for small library bundles that can easily be embedded, I think we
should do it: there's no drawbacks I can see, and it improves modularity.


On Wed, Mar 13, 2013 at 10:05 AM, Christian Schneider <
ch...@die-schneider.net> wrote:


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. Instead
of embedding I propose to check if we could just merge some of these libs.

Christian


On 13.03.2013 07:41, Guillaume Nodet wrote:


+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 works, I think going to the internet when starting is a
really bad idea.

karaf@root()> ins

Re: [DISCUSS] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)

[Guillaume Nodet]

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 deployment because a refresh is needed to solve those new
constraints.  So when possible, they should be avoided and optional stuff
be deployed as a separate bundle.


On Wed, Mar 13, 2013 at 11:21 AM, Guillaume Nodet  wrote:

> 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 projects like CXF or Camel, we develop for OSGi so we should try to
> use it in the best way.
>
> Let's consider the 3 different things we can have in OSGi : apis,
> implementations and libraries.
> We have basic rules:
>   * service api packages should be exported
>   * service implementation packages should be kept private
> When a service bundle ships the api in the same bundle as the
> implementation, the rule is to export and import the api package to let the
> framework use package substitution if needed.   For libraries, the rule is
> to export the packages and not import those, as subsitution should never
> occur.
>
> One first case is service api and implementations.  A service bundle can
> either provide its own API or the API be provided by a separate package.
>  With the osgi compendium jar, it's recommended to not use it because it
> breaks modularity: this bundle provides lots of different service apis, so
> you can't change them one by one.  That's why osgi service implementation
> usually ship their own API.   For apis we control, things are slightly
> different, as we don't have those big bundles.  For those cases, the best
> thing is actually to ship the API and the service implementation in
> different bundles.  This allows updating the service implementation without
> requiring a refresh of the other bundles.
>
> Let's now discuss the bundle lifecycle pov.  If a bundle providing a
> service depends for the implementation on libraries packages provided by
> external bundles, it breaks the abstraction and modularity to some degree
> by exposing internal constraints.  Those constraints are better captured by
> service dependencies.
> Let's take an example: we have bundle A and B depending on a library
> provided by bundle C.  If you want to update C to provide a fix needed for
> A, this will also impact B, which could cause a regression to B
> functionality.  There are transient ways around that: i.e. deploy a new
> version of bundle C or update C and only refresh A.  But those are only
> transient as in felix, the wiring isn't retained across restarts.  And this
> can't really be controlled well with the tools we have at hand.
> On the other hand, if both bundle A and B embeds the C library needed you
> can update A and B independently, so a better modularity at the cost of
> less code sharing.
>
> So in an ideal OSGi world, service APIs would be shipped in individual
> bundles, and service implementation would have no other constraints than on
> other services.
>
> We're not in an ideal world though.  For big projects such as Camel, CXF,
> ActiveMQ, there's not always a real API and other constraints may come in,
> mostly that they are not architected purely for OSGi.
> Anyway, for small library bundles that can easily be embedded, I think we
> should do it: there's no drawbacks I can see, and it improves modularity.
>
>
> On Wed, Mar 13, 2013 at 10:05 AM, Christian Schneider <
> ch...@die-schneider.net> wrote:
>
>> 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. Instead
>> of embedding I propose to check if we could just merge some of these libs.
>>
>> Christian
>>
>>
>> On 13.03.2013 07:41, Guillaume Nodet wrote:
>>
>>> +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 works, I think going to the internet when starting is
>>> a
>>> really bad idea.
>>>
>>> karaf@root()> instance:connect test
>>> undefined option -p
>>> Try  --help' for more information.
>>>
>>> On a side note, the completion usability is really lessened by the
>>> subshells.  We really need to fix that somehow.  Maybe by having
>>> subshells
>>> ending with ':'so that comp

Re: [DISCUSS] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)

[Ioannis Canellos]

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: iocanel
*

Re: [DISCUSS] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)

[Guillaume Nodet]

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 as I open it all projects depending on the console
> are flagged as broken as they do not see the embedded dependencies anymore.
>
> So while this may be a bug in m2e it shows the many problems developers
> face when embedding stuff.
> This is why I think it is the easier path to not embed and instead live
> with some more bundles and broken isolation in some cases.
>
> Generally speaking, I don't really want to favor ease of development wrt
to features.
I'm not using eclipse, so that's maybe why I haven't hit those problems.
 Maybe someone has a way around for eclipse.


> I think the more general problem here that also shows in ops4j is that
> projects introduce too many internal and external libs. Sometimes a lib
> from commons is used just to have a 10 line util function. So I think what
> we wall have to do is to try to keep dependencies as low as possible which
> is very hard ...


I think the point of utility classes is to avoid rewriting stuff and
copying things around.  That's really worthwhile and we should keep them.
 We also use some from felix utils and karaf utils, which at the time, I
specifically packaged as jars to avoid having them deployed as bundles.

I think my view is slightly different because I may be using karaf in a
much more dynamic way than the typical user, installing, updating,
uninstalling features and bundles on the fly using fabric.   In such
environments, having good modularity is much more important than any pain
at dev time.

I've seen the problems you mention during dev time too, but really, I'm
willing to suffer that pain.



>
>
> Christian
>
>
>
> On 13.03.2013 11:46, Guillaume Nodet wrote:
>
>> 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 to create the
>>> feature.
>>> So in the feature you have to use the bundle but exclude its dependencies
>>> so the feature does not additionally contain the original jar and the lib
>>> jar.
>>>
>>>
>>>  Bundles embedding dependencies should mark them as provided in their
>> pom :
>> it should prevent those dependencies to be used as transitive.  For jars
>> repackaged as bundles, the use of the shade maven plugin allows rewriting
>> a
>> pom without those dependencies.
>>
>>
>>  When the bundle that embeds the lib is the original project. Then the jar
>>> is not very suitable for usage outside osgi. You will easily get the same
>>> package from several jars.
>>>
>>>  That's the eternal problem with flat class loaders, but we're talking
>> about
>> bundles here, so their use outside OSGi is really anecdotic.  And that's
>> the nature of OSGi anyway, you have to live with the fact that you may
>> have
>> multiple versions of a single jar in your dependency tree, something that
>> maven does not really support anyway, but it's no specific to OSGi.
>>  Inside
>> a given project, it can always be controlled using the managed
>> dependencies
>> section.
>>
>>
>>  Sometimes I also got strange classloading problems when a lib is embedded
>>> by several bundles.
>>>
>>>  If the library surfaces to outside the bundle, i.e. by passing objects
>> to
>> other bundles, that means it should be flagged in the use clauses of the
>> exported API and imported as a bundle.  If the implementation is kept
>> internal for the implementation, there's no way it can happen (unless
>> there's a bug somewhere).
>>
>>
>>  So while in an ideal world OSGi dependency resolution based on pure
>>> packages should work with bundles embedding libs I thnk it is not such a
>>> good idea.
>>>
>>> Christian
>>>
>>>
>>> On 13.03.2013 11:21, Guillaume Nodet wrote:
>>>
>>>  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 projects like CXF or Camel, we develop for OSGi so we should try
 to
 use it in the best way.

 Let's consider the 3 different things we can have in OSGi : apis,
 implementations and libraries.
 We have basic rules:
 * service api packages should be exported
 * service implementation packages should be kept private
 When a service bundle ships the api in the same bundle as the
 implementation, the rule is to export and import the api package to let
 the
 frame

Re: [DISCUSS] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)

[Christian Schneider]

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 the embedded dependencies anymore.

So while this may be a bug in m2e it shows the many problems developers 
face when embedding stuff.
This is why I think it is the easier path to not embed and instead live 
with some more bundles and broken isolation in some cases.


I think the more general problem here that also shows in ops4j is that 
projects introduce too many internal and external libs. Sometimes a lib 
from commons is used just to have a 10 line util function. So I think 
what we wall have to do is to try to keep dependencies as low as 
possible which is very hard ...


Christian


On 13.03.2013 11:46, Guillaume Nodet wrote:

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 to create the
feature.
So in the feature you have to use the bundle but exclude its dependencies
so the feature does not additionally contain the original jar and the lib
jar.



Bundles embedding dependencies should mark them as provided in their pom :
it should prevent those dependencies to be used as transitive.  For jars
repackaged as bundles, the use of the shade maven plugin allows rewriting a
pom without those dependencies.



When the bundle that embeds the lib is the original project. Then the jar
is not very suitable for usage outside osgi. You will easily get the same
package from several jars.


That's the eternal problem with flat class loaders, but we're talking about
bundles here, so their use outside OSGi is really anecdotic.  And that's
the nature of OSGi anyway, you have to live with the fact that you may have
multiple versions of a single jar in your dependency tree, something that
maven does not really support anyway, but it's no specific to OSGi.  Inside
a given project, it can always be controlled using the managed dependencies
section.



Sometimes I also got strange classloading problems when a lib is embedded
by several bundles.


If the library surfaces to outside the bundle, i.e. by passing objects to
other bundles, that means it should be flagged in the use clauses of the
exported API and imported as a bundle.  If the implementation is kept
internal for the implementation, there's no way it can happen (unless
there's a bug somewhere).



So while in an ideal world OSGi dependency resolution based on pure
packages should work with bundles embedding libs I thnk it is not such a
good idea.

Christian


On 13.03.2013 11:21, Guillaume Nodet wrote:


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 projects like CXF or Camel, we develop for OSGi so we should try to
use it in the best way.

Let's consider the 3 different things we can have in OSGi : apis,
implementations and libraries.
We have basic rules:
* service api packages should be exported
* service implementation packages should be kept private
When a service bundle ships the api in the same bundle as the
implementation, the rule is to export and import the api package to let
the
framework use package substitution if needed.   For libraries, the rule is
to export the packages and not import those, as subsitution should never
occur.

One first case is service api and implementations.  A service bundle can
either provide its own API or the API be provided by a separate package.
   With the osgi compendium jar, it's recommended to not use it because it
breaks modularity: this bundle provides lots of different service apis, so
you can't change them one by one.  That's why osgi service implementation
usually ship their own API.   For apis we control, things are slightly
different, as we don't have those big bundles.  For those cases, the best
thing is actually to ship the API and the service implementation in
different bundles.  This allows updating the service implementation
without
requiring a refresh of the other bundles.

Let's now discuss the bundle lifecycle pov.  If a bundle providing a
service depends for the implementation on libraries packages provided by
external bundles, it breaks the abstraction and modularity to some degree
by exposing internal constraints.  Those constraints are better captured
by
service dependencies.
Let's take an example: we have bundle A and B depending on a library
provided by bundle C.  If you want to update C to provide a fix nee

Re: [DISCUSS] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)

[Guillaume Nodet]

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 to create the
> feature.
> So in the feature you have to use the bundle but exclude its dependencies
> so the feature does not additionally contain the original jar and the lib
> jar.
>
>
Bundles embedding dependencies should mark them as provided in their pom :
it should prevent those dependencies to be used as transitive.  For jars
repackaged as bundles, the use of the shade maven plugin allows rewriting a
pom without those dependencies.


> When the bundle that embeds the lib is the original project. Then the jar
> is not very suitable for usage outside osgi. You will easily get the same
> package from several jars.
>

That's the eternal problem with flat class loaders, but we're talking about
bundles here, so their use outside OSGi is really anecdotic.  And that's
the nature of OSGi anyway, you have to live with the fact that you may have
multiple versions of a single jar in your dependency tree, something that
maven does not really support anyway, but it's no specific to OSGi.  Inside
a given project, it can always be controlled using the managed dependencies
section.


> Sometimes I also got strange classloading problems when a lib is embedded
> by several bundles.
>

If the library surfaces to outside the bundle, i.e. by passing objects to
other bundles, that means it should be flagged in the use clauses of the
exported API and imported as a bundle.  If the implementation is kept
internal for the implementation, there's no way it can happen (unless
there's a bug somewhere).


> So while in an ideal world OSGi dependency resolution based on pure
> packages should work with bundles embedding libs I thnk it is not such a
> good idea.
>
> Christian
>
>
> On 13.03.2013 11:21, Guillaume Nodet wrote:
>
>> 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 projects like CXF or Camel, we develop for OSGi so we should try to
>> use it in the best way.
>>
>> Let's consider the 3 different things we can have in OSGi : apis,
>> implementations and libraries.
>> We have basic rules:
>>* service api packages should be exported
>>* service implementation packages should be kept private
>> When a service bundle ships the api in the same bundle as the
>> implementation, the rule is to export and import the api package to let
>> the
>> framework use package substitution if needed.   For libraries, the rule is
>> to export the packages and not import those, as subsitution should never
>> occur.
>>
>> One first case is service api and implementations.  A service bundle can
>> either provide its own API or the API be provided by a separate package.
>>   With the osgi compendium jar, it's recommended to not use it because it
>> breaks modularity: this bundle provides lots of different service apis, so
>> you can't change them one by one.  That's why osgi service implementation
>> usually ship their own API.   For apis we control, things are slightly
>> different, as we don't have those big bundles.  For those cases, the best
>> thing is actually to ship the API and the service implementation in
>> different bundles.  This allows updating the service implementation
>> without
>> requiring a refresh of the other bundles.
>>
>> Let's now discuss the bundle lifecycle pov.  If a bundle providing a
>> service depends for the implementation on libraries packages provided by
>> external bundles, it breaks the abstraction and modularity to some degree
>> by exposing internal constraints.  Those constraints are better captured
>> by
>> service dependencies.
>> Let's take an example: we have bundle A and B depending on a library
>> provided by bundle C.  If you want to update C to provide a fix needed for
>> A, this will also impact B, which could cause a regression to B
>> functionality.  There are transient ways around that: i.e. deploy a new
>> version of bundle C or update C and only refresh A.  But those are only
>> transient as in felix, the wiring isn't retained across restarts.  And
>> this
>> can't really be controlled well with the tools we have at hand.
>> On the other hand, if both bundle A and B embeds the C library needed you
>> can update A and B independently, so a better modularity at the cost of
>> less code sharing.
>>
>> So in an ideal OSGi world, service APIs would be shipped in individual
>> bundles, and service implementation would have no other constraints than
>> on
>> other services.
>>
>> We're not in an ideal world though.  For big projects s

Re: [DISCUSS] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)

[Christian Schneider]

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 
dependencies so the feature does not additionally contain the original 
jar and the lib jar.


When the bundle that embeds the lib is the original project. Then the 
jar is not very suitable for usage outside osgi. You will easily get the 
same package from several jars.


Sometimes I also got strange classloading problems when a lib is 
embedded by several bundles.


So while in an ideal world OSGi dependency resolution based on pure 
packages should work with bundles embedding libs I thnk it is not such a 
good idea.


Christian

On 13.03.2013 11:21, Guillaume Nodet wrote:

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 projects like CXF or Camel, we develop for OSGi so we should try to
use it in the best way.

Let's consider the 3 different things we can have in OSGi : apis,
implementations and libraries.
We have basic rules:
   * service api packages should be exported
   * service implementation packages should be kept private
When a service bundle ships the api in the same bundle as the
implementation, the rule is to export and import the api package to let the
framework use package substitution if needed.   For libraries, the rule is
to export the packages and not import those, as subsitution should never
occur.

One first case is service api and implementations.  A service bundle can
either provide its own API or the API be provided by a separate package.
  With the osgi compendium jar, it's recommended to not use it because it
breaks modularity: this bundle provides lots of different service apis, so
you can't change them one by one.  That's why osgi service implementation
usually ship their own API.   For apis we control, things are slightly
different, as we don't have those big bundles.  For those cases, the best
thing is actually to ship the API and the service implementation in
different bundles.  This allows updating the service implementation without
requiring a refresh of the other bundles.

Let's now discuss the bundle lifecycle pov.  If a bundle providing a
service depends for the implementation on libraries packages provided by
external bundles, it breaks the abstraction and modularity to some degree
by exposing internal constraints.  Those constraints are better captured by
service dependencies.
Let's take an example: we have bundle A and B depending on a library
provided by bundle C.  If you want to update C to provide a fix needed for
A, this will also impact B, which could cause a regression to B
functionality.  There are transient ways around that: i.e. deploy a new
version of bundle C or update C and only refresh A.  But those are only
transient as in felix, the wiring isn't retained across restarts.  And this
can't really be controlled well with the tools we have at hand.
On the other hand, if both bundle A and B embeds the C library needed you
can update A and B independently, so a better modularity at the cost of
less code sharing.

So in an ideal OSGi world, service APIs would be shipped in individual
bundles, and service implementation would have no other constraints than on
other services.

We're not in an ideal world though.  For big projects such as Camel, CXF,
ActiveMQ, there's not always a real API and other constraints may come in,
mostly that they are not architected purely for OSGi.
Anyway, for small library bundles that can easily be embedded, I think we
should do it: there's no drawbacks I can see, and it improves modularity.


On Wed, Mar 13, 2013 at 10:05 AM, Christian Schneider <
ch...@die-schneider.net> wrote:



--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

[DISCUSS] Bundle granularity (was Re: [VOTE] Release Apache Karaf version 3.0.0.RC1)

[Guillaume Nodet]

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 projects like CXF or Camel, we develop for OSGi so we should try to
use it in the best way.

Let's consider the 3 different things we can have in OSGi : apis,
implementations and libraries.
We have basic rules:
  * service api packages should be exported
  * service implementation packages should be kept private
When a service bundle ships the api in the same bundle as the
implementation, the rule is to export and import the api package to let the
framework use package substitution if needed.   For libraries, the rule is
to export the packages and not import those, as subsitution should never
occur.

One first case is service api and implementations.  A service bundle can
either provide its own API or the API be provided by a separate package.
 With the osgi compendium jar, it's recommended to not use it because it
breaks modularity: this bundle provides lots of different service apis, so
you can't change them one by one.  That's why osgi service implementation
usually ship their own API.   For apis we control, things are slightly
different, as we don't have those big bundles.  For those cases, the best
thing is actually to ship the API and the service implementation in
different bundles.  This allows updating the service implementation without
requiring a refresh of the other bundles.

Let's now discuss the bundle lifecycle pov.  If a bundle providing a
service depends for the implementation on libraries packages provided by
external bundles, it breaks the abstraction and modularity to some degree
by exposing internal constraints.  Those constraints are better captured by
service dependencies.
Let's take an example: we have bundle A and B depending on a library
provided by bundle C.  If you want to update C to provide a fix needed for
A, this will also impact B, which could cause a regression to B
functionality.  There are transient ways around that: i.e. deploy a new
version of bundle C or update C and only refresh A.  But those are only
transient as in felix, the wiring isn't retained across restarts.  And this
can't really be controlled well with the tools we have at hand.
On the other hand, if both bundle A and B embeds the C library needed you
can update A and B independently, so a better modularity at the cost of
less code sharing.

So in an ideal OSGi world, service APIs would be shipped in individual
bundles, and service implementation would have no other constraints than on
other services.

We're not in an ideal world though.  For big projects such as Camel, CXF,
ActiveMQ, there's not always a real API and other constraints may come in,
mostly that they are not architected purely for OSGi.
Anyway, for small library bundles that can easily be embedded, I think we
should do it: there's no drawbacks I can see, and it improves modularity.


On Wed, Mar 13, 2013 at 10:05 AM, Christian Schneider <
ch...@die-schneider.net> wrote:

> 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. Instead
> of embedding I propose to check if we could just merge some of these libs.
>
> Christian
>
>
> On 13.03.2013 07:41, Guillaume Nodet wrote:
>
>> +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 works, I think going to the internet when starting is a
>> really bad idea.
>>
>> karaf@root()> instance:connect test
>> undefined option -p
>> Try  --help' for more information.
>>
>> On a side note, the completion usability is really lessened by the
>> subshells.  We really need to fix that somehow.  Maybe by having subshells
>> ending with ':'so that completion would behave better.
>>
>> Another problem with subshells: when going out of a subshell, the scope
>> isn't modified. So it's effectively as if you were still inside the
>> subshell and you loose the default scope behavior, which is especially
>> troubling with the list command. I.e.:
>>   > feature
>>   > exit
>>   > list
>> the list command gives you the feature list and not the bundle list.
>>
>>   I think some bundles are too fine grained to be deployed as is.  I'm
>> mostly referring to org.ops4j.base/* and org.ops4j.pax.swissbox/* bundles
>> which are pure helper libraries and should imho be embedded whenever
>> possible.  I think we already had those discu

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[Christoph Gritschenberger]

+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 technology preview release candidate.

Staging repository:
https://repository.apache.org/content/repositories/orgapachekaraf-019/

Release tags:
https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/

3.0.x Dependencies table:
https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.






smime.p7s
Description: S/MIME Cryptographic Signature

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[Christian Schneider]

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. 
Instead of embedding I propose to check if we could just merge some of 
these libs.


Christian

On 13.03.2013 07:41, Guillaume Nodet wrote:

+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 works, I think going to the internet when starting is a
really bad idea.

karaf@root()> instance:connect test
undefined option -p
Try  --help' for more information.

On a side note, the completion usability is really lessened by the
subshells.  We really need to fix that somehow.  Maybe by having subshells
ending with ':'so that completion would behave better.

Another problem with subshells: when going out of a subshell, the scope
isn't modified. So it's effectively as if you were still inside the
subshell and you loose the default scope behavior, which is especially
troubling with the list command. I.e.:
  > feature
  > exit
  > list
the list command gives you the feature list and not the bundle list.

  I think some bundles are too fine grained to be deployed as is.  I'm
mostly referring to org.ops4j.base/* and org.ops4j.pax.swissbox/* bundles
which are pure helper libraries and should imho be embedded whenever
possible.  I think we already had those discussions, but ideally, library
bundles should be avoided.





On Tue, Mar 12, 2013 at 4: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 technology preview release candidate.

Staging repository:
https://repository.apache.org/content/repositories/orgapachekaraf-019/

Release tags:
https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/

3.0.x Dependencies table:

https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.







--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[Achim Nierbeck]

+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 have a 3.0 RC1

regards, Achim


2013/3/13 Guillaume Nodet 

> +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 works, I think going to the internet when starting is a
> really bad idea.
>
> karaf@root()> instance:connect test
> undefined option -p
> Try  --help' for more information.
>
> On a side note, the completion usability is really lessened by the
> subshells.  We really need to fix that somehow.  Maybe by having subshells
> ending with ':'so that completion would behave better.
>
> Another problem with subshells: when going out of a subshell, the scope
> isn't modified. So it's effectively as if you were still inside the
> subshell and you loose the default scope behavior, which is especially
> troubling with the list command. I.e.:
>  > feature
>  > exit
>  > list
> the list command gives you the feature list and not the bundle list.
>
>  I think some bundles are too fine grained to be deployed as is.  I'm
> mostly referring to org.ops4j.base/* and org.ops4j.pax.swissbox/* bundles
> which are pure helper libraries and should imho be embedded whenever
> possible.  I think we already had those discussions, but ideally, library
> bundles should be avoided.
>
>
>
>
>
> On Tue, Mar 12, 2013 at 4: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 technology preview release candidate.
> >
> > Staging repository:
> > https://repository.apache.org/content/repositories/orgapachekaraf-019/
> >
> > Release tags:
> > https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/
> >
> > 3.0.x Dependencies table:
> >
> >
> https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Veto the release (please provide specific comments)
> >
> > This vote will be open for 72 hours.
> >
>
>
>
> --
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
>
> Email: gno...@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/
>



-- 

Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
OPS4J Pax for Vaadin 
Commiter & Project Lead
blog 

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[Guillaume Nodet]

+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 works, I think going to the internet when starting is a
really bad idea.

karaf@root()> instance:connect test
undefined option -p
Try  --help' for more information.

On a side note, the completion usability is really lessened by the
subshells.  We really need to fix that somehow.  Maybe by having subshells
ending with ':'so that completion would behave better.

Another problem with subshells: when going out of a subshell, the scope
isn't modified. So it's effectively as if you were still inside the
subshell and you loose the default scope behavior, which is especially
troubling with the list command. I.e.:
 > feature
 > exit
 > list
the list command gives you the feature list and not the bundle list.

 I think some bundles are too fine grained to be deployed as is.  I'm
mostly referring to org.ops4j.base/* and org.ops4j.pax.swissbox/* bundles
which are pure helper libraries and should imho be embedded whenever
possible.  I think we already had those discussions, but ideally, library
bundles should be avoided.





On Tue, Mar 12, 2013 at 4: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 technology preview release candidate.
>
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-019/
>
> Release tags:
> https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/
>
> 3.0.x Dependencies table:
>
> https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
>
> This vote will be open for 72 hours.
>



-- 

Guillaume Nodet

Red Hat, Open Source Integration

Email: gno...@redhat.com
Web: http://fusesource.com
Blog: http://gnodet.blogspot.com/

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[Oliver Lietz]

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
> 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/repos/asf/karaf/site/trunk/src/main/webapp/index/
> >> com munity/download/karaf-3.0.0.RC1-release.page
> >> 
> >> NOTE: This is a technology preview release candidate.
> >> 
> >> Staging repository:
> >> https://repository.apache.org/content/repositories/orgapachekaraf-019/
> >> 
> >> Release tags:
> >> https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/
> >> 
> >> 3.0.x Dependencies table:
> >> https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/
> >> doc umentation/karaf-dependencies/karaf-deps-3.0.x.page
> >> 
> >> Please vote to approve this release:
> >> 
> >> [ ] +1 Approve the release
> >> [ ] -1 Veto the release (please provide specific comments)
> >> 
> >> This vote will be open for 72 hours.
> > 
> > build fails:
> > 
> > Tests in error:
> >listViaMBean:org.apache.karaf.itests.WebTest.listViaMBean:KarafTestCon
> >tainer{mvn:org.apache.karaf\/apache-
> > 
> > karaf\/3.0.0.RC1\/tar.gz}(org.apache.karaf.itests.WebTest):
> > org.apache.karaf:type=web,name=root
> > 
> > https://gist.github.com/oliverlietz/5142210

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[Jean-Baptiste Onofré]

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/repos/asf/karaf/site/trunk/src/main/webapp/index/com
munity/download/karaf-3.0.0.RC1-release.page

NOTE: This is a technology preview release candidate.

Staging repository:
https://repository.apache.org/content/repositories/orgapachekaraf-019/

Release tags:
https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/

3.0.x Dependencies table:
https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/doc
umentation/karaf-dependencies/karaf-deps-3.0.x.page

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.


build fails:

Tests in error:
   
listViaMBean:org.apache.karaf.itests.WebTest.listViaMBean:KarafTestContainer{mvn:org.apache.karaf\/apache-
karaf\/3.0.0.RC1\/tar.gz}(org.apache.karaf.itests.WebTest):
org.apache.karaf:type=web,name=root

https://gist.github.com/oliverlietz/5142210



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[Oliver Lietz]

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 technology preview release candidate.
> 
> Staging repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-019/
> 
> Release tags:
> https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/
> 
> 3.0.x Dependencies table:
> https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/doc
> umentation/karaf-dependencies/karaf-deps-3.0.x.page
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Veto the release (please provide specific comments)
> 
> This vote will be open for 72 hours.

build fails:

Tests in error: 
  
listViaMBean:org.apache.karaf.itests.WebTest.listViaMBean:KarafTestContainer{mvn:org.apache.karaf\/apache-
karaf\/3.0.0.RC1\/tar.gz}(org.apache.karaf.itests.WebTest): 
org.apache.karaf:type=web,name=root

https://gist.github.com/oliverlietz/5142210

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[Jean-Baptiste Onofré]

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/?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 12.03.2013 09:56, Christian Schneider wrote:

+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 was not
able to reproduce this in subsequent runs though.
If someone wants to also try it:
https://github.com/cschneider/Karaf-Tutorial/tree/master/voting

Christian

On 12.03.2013 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 technology preview release candidate.

Staging repository:
https://repository.apache.org/content/repositories/orgapachekaraf-019/

Release tags:
https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/

3.0.x Dependencies table:
https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page


Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.








--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[Christian Schneider]

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 12.03.2013 09:56, Christian Schneider wrote:

+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 was not 
able to reproduce this in subsequent runs though.
If someone wants to also try it: 
https://github.com/cschneider/Karaf-Tutorial/tree/master/voting


Christian

On 12.03.2013 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 technology preview release candidate.

Staging repository:
https://repository.apache.org/content/repositories/orgapachekaraf-019/

Release tags:
https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/

3.0.x Dependencies table:
https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page 



Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.






--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[Christian Schneider]

+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 was not able 
to reproduce this in subsequent runs though.
If someone wants to also try it: 
https://github.com/cschneider/Karaf-Tutorial/tree/master/voting


Christian

On 12.03.2013 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 technology preview release candidate.

Staging repository:
https://repository.apache.org/content/repositories/orgapachekaraf-019/

Release tags:
https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/

3.0.x Dependencies table:
https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.



--
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
http://www.talend.com

Re: [VOTE] Release Apache Karaf version 3.0.0.RC1

[Jean-Baptiste Onofré]

+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 technology preview release candidate.

Staging repository:
https://repository.apache.org/content/repositories/orgapachekaraf-019/

Release tags:
https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/

3.0.x Dependencies table:
https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

[VOTE] Release Apache Karaf version 3.0.0.RC1

[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/community/download/karaf-3.0.0.RC1-release.page

NOTE: This is a technology preview release candidate.

Staging repository:
https://repository.apache.org/content/repositories/orgapachekaraf-019/

Release tags:
https://svn.apache.org/repos/asf/karaf/tags/karaf-3.0.0.RC1/

3.0.x Dependencies table:
https://svn.apache.org/repos/asf/karaf/site/trunk/src/main/webapp/index/documentation/karaf-dependencies/karaf-deps-3.0.x.page

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.