You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Jean-Baptiste Onofré <jb...@nanthrax.net> on 2016/08/24 04:47:26 UTC

[VOTE] Apache Karaf (Container) 4.0.6 release

Hi all,

I submit Karaf (Container) 4.0.6 release to your vote.

Release Notes:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12335477

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

Git Tag:
karaf-4.0.6

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't approve the release (please provide specific comments)

This vote will be open for at least 72 hours.

Thanks,
Regards
JB
-- 
Jean-Baptiste Onofr�
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

[RESULT][VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi all,

this vote passed with the following result:

+1 (binding): Guillaume Nodet, Freeman Fang, Jean-Baptiste Onofr�
+1 (non binding): Andrea Cosentino, Fabian Lange, Krzysztof Sobkowiak

I will promote the artifacts on Central, update Jira and the website, 
then I will announce the release.

Regarding the issue identified during the release vote, I already fixed 
it in Pax Web. As I said, I will release Pax Web 4.2.9, then I will 
update in Karaf and very soon prepare a Karaf 4.0.7 for vote.

Thanks all for your vote and your commitment to review and test the release.

Regards
JB

On 08/24/2016 06:47 AM, Jean-Baptiste Onofr� wrote:
> Hi all,
>
> I submit Karaf (Container) 4.0.6 release to your vote.
>
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12335477
>
>
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1071/
>
> Git Tag:
> karaf-4.0.6
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks,
> Regards
> JB

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

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+1 (binding)

Regards
JB

On 08/24/2016 06:47 AM, Jean-Baptiste Onofr� wrote:
> Hi all,
>
> I submit Karaf (Container) 4.0.6 release to your vote.
>
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12335477
>
>
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1071/
>
> Git Tag:
> karaf-4.0.6
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks,
> Regards
> JB

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

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Freeman Fang <fr...@gmail.com>.
+1 (binding)

Thanks!
-------------
Freeman(Yue) Fang

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



> On Aug 24, 2016, at 12:47 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> 
> Hi all,
> 
> I submit Karaf (Container) 4.0.6 release to your vote.
> 
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12335477
> 
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1071/
> 
> Git Tag:
> karaf-4.0.6
> 
> Please vote to approve this release:
> 
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
> 
> This vote will be open for at least 72 hours.
> 
> Thanks,
> Regards
> JB
> -- 
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com


Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Andrea Cosentino <an...@yahoo.com.INVALID>.
+1 (non-binding).

Thanks JB!
 --
Andrea Cosentino 
----------------------------------
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1985@yahoo.com
Twitter: @oscerd2
Github: oscerd



On Wednesday, August 24, 2016 10:17 AM, Guillaume Nodet <gn...@apache.org> wrote:
+1


2016-08-24 6:47 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:

> Hi all,
>
> I submit Karaf (Container) 4.0.6 release to your vote.
>
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
> ctId=12311140&version=12335477
>
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1071/
>
> Git Tag:
> karaf-4.0.6
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks,
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

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

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Guillaume Nodet <gn...@apache.org>.
+1

2016-08-24 6:47 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:

> Hi all,
>
> I submit Karaf (Container) 4.0.6 release to your vote.
>
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
> ctId=12311140&version=12335477
>
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1071/
>
> Git Tag:
> karaf-4.0.6
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks,
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

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

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Fabian Lange <fa...@codecentric.de>.
Hi

JB, this time my upgrade was very smooth. Plugged in the new repo compile,
build and test worked. Bundling also produced the expected contents.

The changes I can relate to seem to be correct and working. Thank you for
the release

+1 (non-binding)

Fabian

On Wed, Aug 24, 2016 at 6:47 AM, Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:

> Hi all,
>
> I submit Karaf (Container) 4.0.6 release to your vote.
>
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?proje
> ctId=12311140&version=12335477
>
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1071/
>
> Git Tag:
> karaf-4.0.6
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks,
> Regards
> JB
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Markus Rathgeb <ma...@gmail.com>.
The Eclipse SmartHome project is not using Provide-Capability in the
manifest of their bundles (IIRC this does not exist for OSGI R4.2).

Using Karaf K405 all my custom distributions are working as expected.
Using Karaf K406 my custom distributions does not start anymore.

Because the feature resolver complains about missing osgi.services

===
2016-08-25 09:54:02,528 | ERROR | pool-7-thread-1  |
BootFeaturesInstaller            | 8 - org.apache.karaf.features.core
- 4.0.6 | Error installing boot features
org.osgi.service.resolver.ResolutionException: Unable to resolve root:
missing requirement [root] osgi.identity; osgi.identity=dummy;
type=karaf.feature; version="[1.1.0.SNAPSHOT,1.1.0.SNAPSHOT]";
filter:="(&(osgi.identity=dummy)(type=karaf.feature)(version>=1.1.0.SNAPSHOT)(version<=1.1.0.SNAPSHOT))"
[caused by: Unable to resolve dummy/1.1.0.SNAPSHOT: missing
requirement [dummy/1.1.0.SNAPSHOT] osgi.identity; osgi.identity=foo;
type=osgi.bundle; version="[1.1.0.201608240913,1.1.0.201608240913]";
resolution:=mandatory [caused by: Unable to resolve
foo/1.1.0.201608240913: missing requirement [foo/1.1.0.201608240913]
osgi.service; filter:="(objectClass=org.eclipse.smarthome.core.items.ItemRegistry)";
effective:=active]]
at org.apache.felix.resolver.ResolutionError.toException(ResolutionError.java:42)[8:org.apache.karaf.features.core:4.0.6]
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:235)[8:org.apache.karaf.features.core:4.0.6]
at org.apache.felix.resolver.ResolverImpl.resolve(ResolverImpl.java:158)[8:org.apache.karaf.features.core:4.0.6]
at org.apache.karaf.features.internal.region.SubsystemResolver.resolve(SubsystemResolver.java:216)[8:org.apache.karaf.features.core:4.0.6]
at org.apache.karaf.features.internal.service.Deployer.deploy(Deployer.java:263)[8:org.apache.karaf.features.core:4.0.6]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl.doProvision(FeaturesServiceImpl.java:1176)[8:org.apache.karaf.features.core:4.0.6]
at org.apache.karaf.features.internal.service.FeaturesServiceImpl$1.call(FeaturesServiceImpl.java:1074)[8:org.apache.karaf.features.core:4.0.6]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_102]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_102]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_102]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_102]
===

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Achim Nierbeck <bc...@googlemail.com>.
great :)

2016-08-25 10:02 GMT+02:00 Markus Rathgeb <ma...@gmail.com>:

> Hi Achim,
>
> > @Markus, you should consider to have a specialized Jenkins to verify your
> > applications with recent snapshots so we can find those things earlier ;)
>
> You are right.
> I will setup one!
>



-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Markus Rathgeb <ma...@gmail.com>.
Hi Achim,

> @Markus, you should consider to have a specialized Jenkins to verify your
> applications with recent snapshots so we can find those things earlier ;)

You are right.
I will setup one!

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Achim Nierbeck <bc...@googlemail.com>.
Thanks ... it's a rather intrusive behavioral change :)
best to fix it now.

@Markus, you should consider to have a specialized Jenkins to verify your
applications with recent snapshots so we can find those things earlier ;)

regards, Achim


2016-08-25 9:57 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:

> OK, let me find the change in cause.
>
> I keep you posted. Then, I will cancel the release.
>
> Regards
> JB
>
>
> On 08/25/2016 09:52 AM, Markus Rathgeb wrote:
>
>> Hi,
>>
>> I was able to reproduce the issue Markus described with his test.
>>>> One thing that crosses my mind, did we change something with the feature
>>>> resolver? Cause I can't remember that the pax-web-api did actually
>>>> contain
>>>> a provide-capability for the WebContainer Service.
>>>>
>>>
>> The feature that should be verified is using the pax-http-whiteboard
>> and the http feature as dependency.
>> See: https://github.com/maggu2810/k406-staging/blob/94794b8/featu
>> re/src/main/feature/feature.xml#L10
>>
>> So at least one bundle in that features should contain the
>> WebContainer service, shouldn't it?
>> The feature will introduce a lot more Pax Web bundles (not only the
>> API), so the WebContainer implementation should be available.
>>
>> Do we consider as release blocker ?
>>>>
>>>
>> If the verification of features is broken (and not only related to my
>> features) I assume we should fix it for a release. Shouldn't we?
>>
>> Best regards,
>> Markus
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
OK, let me find the change in cause.

I keep you posted. Then, I will cancel the release.

Regards
JB

On 08/25/2016 09:52 AM, Markus Rathgeb wrote:
> Hi,
>
>>> I was able to reproduce the issue Markus described with his test.
>>> One thing that crosses my mind, did we change something with the feature
>>> resolver? Cause I can't remember that the pax-web-api did actually contain
>>> a provide-capability for the WebContainer Service.
>
> The feature that should be verified is using the pax-http-whiteboard
> and the http feature as dependency.
> See: https://github.com/maggu2810/k406-staging/blob/94794b8/feature/src/main/feature/feature.xml#L10
>
> So at least one bundle in that features should contain the
> WebContainer service, shouldn't it?
> The feature will introduce a lot more Pax Web bundles (not only the
> API), so the WebContainer implementation should be available.
>
>>> Do we consider as release blocker ?
>
> If the verification of features is broken (and not only related to my
> features) I assume we should fix it for a release. Shouldn't we?
>
> Best regards,
> Markus
>

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

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Markus Rathgeb <ma...@gmail.com>.
Hi,

>> I was able to reproduce the issue Markus described with his test.
>> One thing that crosses my mind, did we change something with the feature
>> resolver? Cause I can't remember that the pax-web-api did actually contain
>> a provide-capability for the WebContainer Service.

The feature that should be verified is using the pax-http-whiteboard
and the http feature as dependency.
See: https://github.com/maggu2810/k406-staging/blob/94794b8/feature/src/main/feature/feature.xml#L10

So at least one bundle in that features should contain the
WebContainer service, shouldn't it?
The feature will introduce a lot more Pax Web bundles (not only the
API), so the WebContainer implementation should be available.

>> Do we consider as release blocker ?

If the verification of features is broken (and not only related to my
features) I assume we should fix it for a release. Shouldn't we?

Best regards,
Markus

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by "Jamie G." <ja...@gmail.com>.
+1 Sounds like a plan.

Cheers,
Jamie

On Fri, Aug 26, 2016 at 10:42 AM, Andrea Cosentino
<an...@yahoo.com.invalid> wrote:
> +1 for me :-)
>
> Thanks JB
>  --
> Andrea Cosentino
> ----------------------------------
> Apache Camel PMC Member
> Apache Karaf Committer
> Apache Servicemix Committer
> Email: ancosen1985@yahoo.com
> Twitter: @oscerd2
> Github: oscerd
>
>
>
> On Friday, August 26, 2016 4:17 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Well guys,
>
> I investigated.
>
> Actually, Pax Web 4.2.8 already provides the capability header in the
> MANIFEST. Unfortunately, the WebContainer service is not part of this
> header :(
> So basically, we could consider this as a bug in Pax Web.
>
> It requires a new Pax Web 4.2.9 release.
>
> What I'm proposing:
> - let's continue the Karaf 4.0.6 vote ending and release this version
> - in the mean time, I'm preparing Pax Web 4.2.9 release
> - once, Pax Web 4.2.9 will be released, I will quickly prepare Karaf
> 4.0.7 including Pax Web 4.2.9
>
> I think it makes sense to move this way.
>
> Deal ?
>
> Regards
> JB
>
>
> On 08/26/2016 02:36 PM, Jean-Baptiste Onofré wrote:
>> Fair enough, but we have to stand quickly.
>>
>> IMHO, as it doesn't cost so much, I would cancel this vote and fix that
>> in Pax Web.
>>
>> I can do it today and start a new vote tonight or tomorrow.
>>
>> Regards
>> JB
>>
>> On 08/26/2016 02:31 PM, Achim Nierbeck wrote:
>>> That's a good question.
>>> In light of that question, it might be good to cancel this vote so we can
>>> fix those capabilities on Pax-Web and redo the release on a Pax-Web 4.2.9
>>>
>>> Thoughts?
>>>
>>> regards, Achim
>>>
>>>
>>> 2016-08-26 14:23 GMT+02:00 Markus Rathgeb <ma...@gmail.com>:
>>>
>>>>> I propose:
>>>>> - don't cancel this vote as it's an expected behavior
>>>>> - fix the service capability in Pax Web
>>>>
>>>>> Thoughts ?
>>>>
>>>> One remaining question:
>>>> The Pax Web version and so the Pax Web features that are shipped with
>>>> Karaf 4.0.6 will contain the service capability or do not have the
>>>> capability?
>>>>
>>>
>>>
>>>
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Kevin Carr <ks...@gmail.com>.
+1

On Fri, Aug 26, 2016, 9:17 AM Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:

> Well guys,
>
> I investigated.
>
> Actually, Pax Web 4.2.8 already provides the capability header in the
> MANIFEST. Unfortunately, the WebContainer service is not part of this
> header :(
> So basically, we could consider this as a bug in Pax Web.
>
> It requires a new Pax Web 4.2.9 release.
>
> What I'm proposing:
> - let's continue the Karaf 4.0.6 vote ending and release this version
> - in the mean time, I'm preparing Pax Web 4.2.9 release
> - once, Pax Web 4.2.9 will be released, I will quickly prepare Karaf
> 4.0.7 including Pax Web 4.2.9
>
> I think it makes sense to move this way.
>
> Deal ?
>
> Regards
> JB
>
> On 08/26/2016 02:36 PM, Jean-Baptiste Onofré wrote:
> > Fair enough, but we have to stand quickly.
> >
> > IMHO, as it doesn't cost so much, I would cancel this vote and fix that
> > in Pax Web.
> >
> > I can do it today and start a new vote tonight or tomorrow.
> >
> > Regards
> > JB
> >
> > On 08/26/2016 02:31 PM, Achim Nierbeck wrote:
> >> That's a good question.
> >> In light of that question, it might be good to cancel this vote so we
> can
> >> fix those capabilities on Pax-Web and redo the release on a Pax-Web
> 4.2.9
> >>
> >> Thoughts?
> >>
> >> regards, Achim
> >>
> >>
> >> 2016-08-26 14:23 GMT+02:00 Markus Rathgeb <ma...@gmail.com>:
> >>
> >>>> I propose:
> >>>> - don't cancel this vote as it's an expected behavior
> >>>> - fix the service capability in Pax Web
> >>>
> >>>> Thoughts ?
> >>>
> >>> One remaining question:
> >>> The Pax Web version and so the Pax Web features that are shipped with
> >>> Karaf 4.0.6 will contain the service capability or do not have the
> >>> capability?
> >>>
> >>
> >>
> >>
> >
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Andrea Cosentino <an...@yahoo.com.INVALID>.
+1 for me :-)

Thanks JB
 --
Andrea Cosentino 
----------------------------------
Apache Camel PMC Member
Apache Karaf Committer
Apache Servicemix Committer
Email: ancosen1985@yahoo.com
Twitter: @oscerd2
Github: oscerd



On Friday, August 26, 2016 4:17 PM, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
Well guys,

I investigated.

Actually, Pax Web 4.2.8 already provides the capability header in the 
MANIFEST. Unfortunately, the WebContainer service is not part of this 
header :(
So basically, we could consider this as a bug in Pax Web.

It requires a new Pax Web 4.2.9 release.

What I'm proposing:
- let's continue the Karaf 4.0.6 vote ending and release this version
- in the mean time, I'm preparing Pax Web 4.2.9 release
- once, Pax Web 4.2.9 will be released, I will quickly prepare Karaf 
4.0.7 including Pax Web 4.2.9

I think it makes sense to move this way.

Deal ?

Regards
JB


On 08/26/2016 02:36 PM, Jean-Baptiste Onofré wrote:
> Fair enough, but we have to stand quickly.
>
> IMHO, as it doesn't cost so much, I would cancel this vote and fix that
> in Pax Web.
>
> I can do it today and start a new vote tonight or tomorrow.
>
> Regards
> JB
>
> On 08/26/2016 02:31 PM, Achim Nierbeck wrote:
>> That's a good question.
>> In light of that question, it might be good to cancel this vote so we can
>> fix those capabilities on Pax-Web and redo the release on a Pax-Web 4.2.9
>>
>> Thoughts?
>>
>> regards, Achim
>>
>>
>> 2016-08-26 14:23 GMT+02:00 Markus Rathgeb <ma...@gmail.com>:
>>
>>>> I propose:
>>>> - don't cancel this vote as it's an expected behavior
>>>> - fix the service capability in Pax Web
>>>
>>>> Thoughts ?
>>>
>>> One remaining question:
>>> The Pax Web version and so the Pax Web features that are shipped with
>>> Karaf 4.0.6 will contain the service capability or do not have the
>>> capability?
>>>
>>
>>
>>
>

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

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Well guys,

I investigated.

Actually, Pax Web 4.2.8 already provides the capability header in the 
MANIFEST. Unfortunately, the WebContainer service is not part of this 
header :(
So basically, we could consider this as a bug in Pax Web.

It requires a new Pax Web 4.2.9 release.

What I'm proposing:
- let's continue the Karaf 4.0.6 vote ending and release this version
- in the mean time, I'm preparing Pax Web 4.2.9 release
- once, Pax Web 4.2.9 will be released, I will quickly prepare Karaf 
4.0.7 including Pax Web 4.2.9

I think it makes sense to move this way.

Deal ?

Regards
JB

On 08/26/2016 02:36 PM, Jean-Baptiste Onofr� wrote:
> Fair enough, but we have to stand quickly.
>
> IMHO, as it doesn't cost so much, I would cancel this vote and fix that
> in Pax Web.
>
> I can do it today and start a new vote tonight or tomorrow.
>
> Regards
> JB
>
> On 08/26/2016 02:31 PM, Achim Nierbeck wrote:
>> That's a good question.
>> In light of that question, it might be good to cancel this vote so we can
>> fix those capabilities on Pax-Web and redo the release on a Pax-Web 4.2.9
>>
>> Thoughts?
>>
>> regards, Achim
>>
>>
>> 2016-08-26 14:23 GMT+02:00 Markus Rathgeb <ma...@gmail.com>:
>>
>>>> I propose:
>>>> - don't cancel this vote as it's an expected behavior
>>>> - fix the service capability in Pax Web
>>>
>>>> Thoughts ?
>>>
>>> One remaining question:
>>> The Pax Web version and so the Pax Web features that are shipped with
>>> Karaf 4.0.6 will contain the service capability or do not have the
>>> capability?
>>>
>>
>>
>>
>

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

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Fair enough, but we have to stand quickly.

IMHO, as it doesn't cost so much, I would cancel this vote and fix that 
in Pax Web.

I can do it today and start a new vote tonight or tomorrow.

Regards
JB

On 08/26/2016 02:31 PM, Achim Nierbeck wrote:
> That's a good question.
> In light of that question, it might be good to cancel this vote so we can
> fix those capabilities on Pax-Web and redo the release on a Pax-Web 4.2.9
>
> Thoughts?
>
> regards, Achim
>
>
> 2016-08-26 14:23 GMT+02:00 Markus Rathgeb <ma...@gmail.com>:
>
>>> I propose:
>>> - don't cancel this vote as it's an expected behavior
>>> - fix the service capability in Pax Web
>>
>>> Thoughts ?
>>
>> One remaining question:
>> The Pax Web version and so the Pax Web features that are shipped with
>> Karaf 4.0.6 will contain the service capability or do not have the
>> capability?
>>
>
>
>

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

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Achim Nierbeck <bc...@googlemail.com>.
That's a good question.
In light of that question, it might be good to cancel this vote so we can
fix those capabilities on Pax-Web and redo the release on a Pax-Web 4.2.9

Thoughts?

regards, Achim


2016-08-26 14:23 GMT+02:00 Markus Rathgeb <ma...@gmail.com>:

> > I propose:
> > - don't cancel this vote as it's an expected behavior
> > - fix the service capability in Pax Web
>
> > Thoughts ?
>
> One remaining question:
> The Pax Web version and so the Pax Web features that are shipped with
> Karaf 4.0.6 will contain the service capability or do not have the
> capability?
>



-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Markus Rathgeb <ma...@gmail.com>.
> I propose:
> - don't cancel this vote as it's an expected behavior
> - fix the service capability in Pax Web

> Thoughts ?

One remaining question:
The Pax Web version and so the Pax Web features that are shipped with
Karaf 4.0.6 will contain the service capability or do not have the
capability?

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Correct, the verify failed on a custom feature.

I propose:
- don't cancel this vote as it's an expected behavior
- fix the service capability in Pax Web
- add an option on the GenerateFeaturesMojo to be able to use a 
namespace different from 1.4.0 (responsibility of the user)

Thoughts ?

For Markus, the workaround is:
- still use Karaf 4.0.6
- don't use the generate features MOJO and rather a "static" 
features.xml containing xmlns 1.2.0
- the verify will work

Regards
JB

On 08/25/2016 04:12 PM, Guillaume Nodet wrote:
> Agreed, so the problem was caused by a custom feature ?
> I thought it was directly the pax-web feature.
>
> In that case, I agree, that's exactly the behavior we wanted I think.
>
> On a side note, if pax-web does not expose the service capability, it
> should also be fixed ;-)
>
> Guillaume
>
> 2016-08-25 15:55 GMT+02:00 Jean-Baptiste Onofr� <jb...@nanthrax.net>:
>
>> After digging a bit, I don't think it's actually a bug.
>>
>> Let me explain and see we all agree ;)
>>
>> Previously to the commit, the service enforcement was "enabled" only for
>> features XML using xmlns 1.3.0 (not 1.4.0). The commit fixed service
>> enforcement also for xmlns 1.4.0 (which makes sense).
>>
>> In Markus' use case, he said he tried xmlns 1.2.0 and it failed. However,
>> as he's using Karaf Maven plugin to generate the descriptor, by default,
>> even if the "source" features XML contains xmlns 1.2.0, the generated one
>> is using xmlns 1.4.0.
>>
>> That's why it worked before and not after the commit.
>>
>> Due to that, I don't think we have to consider it as a bug:
>> 1. If we don't want service enforcement, than, we have to use a feature
>> with xmlns 1.2.0
>> 2. Actually using features xmlns 1.3.0 or 1.4.0 means we want resolver
>> features including services enforcement.
>>
>> WDYT ?
>>
>> Regards
>> JB
>>
>>
>> On 08/25/2016 03:41 PM, Jean-Baptiste Onofr� wrote:
>>
>>> It looks like the commit in cause is the following:
>>>
>>> ---------------------
>>> 5c5828322ad898e80e66923edeb29e1a25b774cb is the first bad commit
>>> commit 5c5828322ad898e80e66923edeb29e1a25b774cb
>>> Author: Guillaume Nodet <gn...@apache.org>
>>> Date:   Fri Jul 22 12:33:17 2016 +0200
>>>
>>>     [KARAF-4632] Default serviceRequirements should handle 1.4.0 schema
>>>
>>> :040000 040000 d038cf82d490d3cd0c7df97376575e323ef2382f
>>> 2e6efa64dfd142e722970949b05dcc1e152a3cd8 M      features
>>> ----------------------
>>>
>>> I'm testing a revert.
>>>
>>> Regards
>>> JB
>>>
>>> On 08/25/2016 11:03 AM, Jean-Baptiste Onofr� wrote:
>>>
>>>> No, I don't think it's related as it's not a change in 4.0.6.
>>>>
>>>> I think it's a combination between the features resolver and the
>>>> karaf-maven-plugin.
>>>>
>>>> I'm pretty close in the bisect now ;)
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 08/25/2016 10:46 AM, Markus Rathgeb wrote:
>>>>
>>>>> I found this one:
>>>>>
>>>>> # By default, the feature resolver checks the service
>>>>> requirements/capabilities of
>>>>> # bundles for new features (xml schema >= 1.3.0) in order to
>>>>> automatically installs
>>>>> # the required bundles.
>>>>> # The following flag can have those values:
>>>>> #   - disable: service requirements are completely ignored
>>>>> #   - default: service requirements are ignored for old features
>>>>> #   - enforce: service requirements are always verified
>>>>> #
>>>>> #serviceRequirements=default
>>>>>
>>>>> Do you think this one could be related?
>>>>>
>>>>> Changing the xmlns from v1.4.0 to v1.2.0 does not result in a
>>>>> successful verification.
>>>>>
>>>>> -<features xmlns="http://karaf.apache.org/xmlns/features/v1.4.0"
>>>>> name="${project.artifactId}-${project.version}">
>>>>> +<features xmlns="http://karaf.apache.org/xmlns/features/v1.2.0"
>>>>> name="${project.artifactId}-${project.version}">
>>>>>
>>>>> 2016-08-25 10:40 GMT+02:00 Jean-Baptiste Onofr� <jb...@nanthrax.net>:
>>>>>
>>>>>> Hi Guillaume,
>>>>>>
>>>>>> I'm on git biset to identify the guilty ;)
>>>>>>
>>>>>> And yes, I will recut a release.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>>
>>>>>> On 08/25/2016 10:25 AM, Guillaume Nodet wrote:
>>>>>>
>>>>>>>
>>>>>>> Yeah, if it breaks compatibility, we should recut a release ?
>>>>>>> Has anyone identified the culprit commit yet ?
>>>>>>>
>>>>>>> 2016-08-25 9:39 GMT+02:00 Jean-Baptiste Onofr� <jb...@nanthrax.net>:
>>>>>>>
>>>>>>> I think it's a change in the karaf-maven-plugin.
>>>>>>>>
>>>>>>>> And yes, I reproduce Markus' issue as well.
>>>>>>>>
>>>>>>>> Do we consider as release blocker ?
>>>>>>>>
>>>>>>>> If so, I will fix it today and submit a new vote.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> JB
>>>>>>>>
>>>>>>>>
>>>>>>>> On 08/25/2016 09:34 AM, Achim Nierbeck wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I was able to reproduce the issue Markus described with his test.
>>>>>>>>> One thing that crosses my mind, did we change something with the
>>>>>>>>> feature
>>>>>>>>> resolver? Cause I can't remember that the pax-web-api did actually
>>>>>>>>> contain
>>>>>>>>> a provide-capability for the WebContainer Service.
>>>>>>>>>
>>>>>>>>> regards, Achim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2016-08-25 0:44 GMT+02:00 Krzysztof Sobkowiak
>>>>>>>>> <krzys.sobkowiak@gmail.com
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> :
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> +1 (non-binding)
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ServiceMix 7.x tests ok. Thanks!!!
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Krzysztof
>>>>>>>>>>
>>>>>>>>>> On 24.08.2016 06:47, Jean-Baptiste Onofr� wrote:
>>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> I submit Karaf (Container) 4.0.6 release to your vote.
>>>>>>>>>>>
>>>>>>>>>>> Release Notes:
>>>>>>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>>>>>>>>>>>
>>>>>>>>>>> projectId=12311140&version=12335477
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Staging Repository:
>>>>>>>>>>>
>>>>>>>>>>> https://repository.apache.org/content/repositories/orgapache
>>>>>>>>>>> karaf-1071/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Git Tag:
>>>>>>>>>>> karaf-4.0.6
>>>>>>>>>>>
>>>>>>>>>>> Please vote to approve this release:
>>>>>>>>>>>
>>>>>>>>>>> [ ] +1 Approve the release
>>>>>>>>>>> [ ] -1 Don't approve the release (please provide specific
>>>>>>>>>>> comments)
>>>>>>>>>>>
>>>>>>>>>>> This vote will be open for at least 72 hours.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Regards
>>>>>>>>>>> JB
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Krzysztof Sobkowiak (@ksobkowiak)
>>>>>>>>>>
>>>>>>>>>> JEE & OSS Architect, Integration Architect
>>>>>>>>>> Apache Software Foundation Member (http://apache.org/)
>>>>>>>>>> Apache ServiceMix Committer & PMC Member
>>>>>>>>>> (http://servicemix.apache.org/)
>>>>>>>>>> Senior Solution Architect @ Capgemini SSC
>>>>>>>>>> (http://www.capgeminisoftware.
>>>>>>>>>> pl/)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>> Jean-Baptiste Onofr�
>>>>>>>> jbonofre@apache.org
>>>>>>>> http://blog.nanthrax.net
>>>>>>>> Talend - http://www.talend.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Jean-Baptiste Onofr�
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>
>>>>
>>>
>> --
>> Jean-Baptiste Onofr�
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>

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

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Markus,

Just stay with features 1.2.0 for now, or add the capabilities in the 
features XML (1.3.0 or 1.4.0).

Regards
JB

On 08/25/2016 04:17 PM, Markus Rathgeb wrote:
> So, is there a way to use 1.3.0 (IIRC prerequisite and dependency has
> been added there) or newer without adding the capability instruction
> to every feature using a bundle without that information in the
> manifest?
> I see there is a configuration for the runtime, but is there one for
> the plugin to control the verification?
>
> I have to use a dozen of third party bundles that miss that
> information and that change frequently, adding the capability to the
> feature is a too time consuming effort.
>
> 2016-08-25 16:12 GMT+02:00 Guillaume Nodet <gn...@apache.org>:
>> Agreed, so the problem was caused by a custom feature ?
>> I thought it was directly the pax-web feature.
>>
>> In that case, I agree, that's exactly the behavior we wanted I think.
>>
>> On a side note, if pax-web does not expose the service capability, it
>> should also be fixed ;-)
>>
>> Guillaume
>>
>> 2016-08-25 15:55 GMT+02:00 Jean-Baptiste Onofr� <jb...@nanthrax.net>:
>>
>>> After digging a bit, I don't think it's actually a bug.
>>>
>>> Let me explain and see we all agree ;)
>>>
>>> Previously to the commit, the service enforcement was "enabled" only for
>>> features XML using xmlns 1.3.0 (not 1.4.0). The commit fixed service
>>> enforcement also for xmlns 1.4.0 (which makes sense).
>>>
>>> In Markus' use case, he said he tried xmlns 1.2.0 and it failed. However,
>>> as he's using Karaf Maven plugin to generate the descriptor, by default,
>>> even if the "source" features XML contains xmlns 1.2.0, the generated one
>>> is using xmlns 1.4.0.
>>>
>>> That's why it worked before and not after the commit.
>>>
>>> Due to that, I don't think we have to consider it as a bug:
>>> 1. If we don't want service enforcement, than, we have to use a feature
>>> with xmlns 1.2.0
>>> 2. Actually using features xmlns 1.3.0 or 1.4.0 means we want resolver
>>> features including services enforcement.
>>>
>>> WDYT ?
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 08/25/2016 03:41 PM, Jean-Baptiste Onofr� wrote:
>>>
>>>> It looks like the commit in cause is the following:
>>>>
>>>> ---------------------
>>>> 5c5828322ad898e80e66923edeb29e1a25b774cb is the first bad commit
>>>> commit 5c5828322ad898e80e66923edeb29e1a25b774cb
>>>> Author: Guillaume Nodet <gn...@apache.org>
>>>> Date:   Fri Jul 22 12:33:17 2016 +0200
>>>>
>>>>     [KARAF-4632] Default serviceRequirements should handle 1.4.0 schema
>>>>
>>>> :040000 040000 d038cf82d490d3cd0c7df97376575e323ef2382f
>>>> 2e6efa64dfd142e722970949b05dcc1e152a3cd8 M      features
>>>> ----------------------
>>>>
>>>> I'm testing a revert.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 08/25/2016 11:03 AM, Jean-Baptiste Onofr� wrote:
>>>>
>>>>> No, I don't think it's related as it's not a change in 4.0.6.
>>>>>
>>>>> I think it's a combination between the features resolver and the
>>>>> karaf-maven-plugin.
>>>>>
>>>>> I'm pretty close in the bisect now ;)
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>> On 08/25/2016 10:46 AM, Markus Rathgeb wrote:
>>>>>
>>>>>> I found this one:
>>>>>>
>>>>>> # By default, the feature resolver checks the service
>>>>>> requirements/capabilities of
>>>>>> # bundles for new features (xml schema >= 1.3.0) in order to
>>>>>> automatically installs
>>>>>> # the required bundles.
>>>>>> # The following flag can have those values:
>>>>>> #   - disable: service requirements are completely ignored
>>>>>> #   - default: service requirements are ignored for old features
>>>>>> #   - enforce: service requirements are always verified
>>>>>> #
>>>>>> #serviceRequirements=default
>>>>>>
>>>>>> Do you think this one could be related?
>>>>>>
>>>>>> Changing the xmlns from v1.4.0 to v1.2.0 does not result in a
>>>>>> successful verification.
>>>>>>
>>>>>> -<features xmlns="http://karaf.apache.org/xmlns/features/v1.4.0"
>>>>>> name="${project.artifactId}-${project.version}">
>>>>>> +<features xmlns="http://karaf.apache.org/xmlns/features/v1.2.0"
>>>>>> name="${project.artifactId}-${project.version}">
>>>>>>
>>>>>> 2016-08-25 10:40 GMT+02:00 Jean-Baptiste Onofr� <jb...@nanthrax.net>:
>>>>>>
>>>>>>> Hi Guillaume,
>>>>>>>
>>>>>>> I'm on git biset to identify the guilty ;)
>>>>>>>
>>>>>>> And yes, I will recut a release.
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>>
>>>>>>> On 08/25/2016 10:25 AM, Guillaume Nodet wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> Yeah, if it breaks compatibility, we should recut a release ?
>>>>>>>> Has anyone identified the culprit commit yet ?
>>>>>>>>
>>>>>>>> 2016-08-25 9:39 GMT+02:00 Jean-Baptiste Onofr� <jb...@nanthrax.net>:
>>>>>>>>
>>>>>>>> I think it's a change in the karaf-maven-plugin.
>>>>>>>>>
>>>>>>>>> And yes, I reproduce Markus' issue as well.
>>>>>>>>>
>>>>>>>>> Do we consider as release blocker ?
>>>>>>>>>
>>>>>>>>> If so, I will fix it today and submit a new vote.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 08/25/2016 09:34 AM, Achim Nierbeck wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I was able to reproduce the issue Markus described with his test.
>>>>>>>>>> One thing that crosses my mind, did we change something with the
>>>>>>>>>> feature
>>>>>>>>>> resolver? Cause I can't remember that the pax-web-api did actually
>>>>>>>>>> contain
>>>>>>>>>> a provide-capability for the WebContainer Service.
>>>>>>>>>>
>>>>>>>>>> regards, Achim
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2016-08-25 0:44 GMT+02:00 Krzysztof Sobkowiak
>>>>>>>>>> <krzys.sobkowiak@gmail.com
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> :
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> +1 (non-binding)
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ServiceMix 7.x tests ok. Thanks!!!
>>>>>>>>>>>
>>>>>>>>>>> Regards
>>>>>>>>>>> Krzysztof
>>>>>>>>>>>
>>>>>>>>>>> On 24.08.2016 06:47, Jean-Baptiste Onofr� wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> I submit Karaf (Container) 4.0.6 release to your vote.
>>>>>>>>>>>>
>>>>>>>>>>>> Release Notes:
>>>>>>>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>>>>>>>>>>>>
>>>>>>>>>>>> projectId=12311140&version=12335477
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Staging Repository:
>>>>>>>>>>>>
>>>>>>>>>>>> https://repository.apache.org/content/repositories/orgapache
>>>>>>>>>>>> karaf-1071/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Git Tag:
>>>>>>>>>>>> karaf-4.0.6
>>>>>>>>>>>>
>>>>>>>>>>>> Please vote to approve this release:
>>>>>>>>>>>>
>>>>>>>>>>>> [ ] +1 Approve the release
>>>>>>>>>>>> [ ] -1 Don't approve the release (please provide specific
>>>>>>>>>>>> comments)
>>>>>>>>>>>>
>>>>>>>>>>>> This vote will be open for at least 72 hours.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Regards
>>>>>>>>>>>> JB
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Krzysztof Sobkowiak (@ksobkowiak)
>>>>>>>>>>>
>>>>>>>>>>> JEE & OSS Architect, Integration Architect
>>>>>>>>>>> Apache Software Foundation Member (http://apache.org/)
>>>>>>>>>>> Apache ServiceMix Committer & PMC Member
>>>>>>>>>>> (http://servicemix.apache.org/)
>>>>>>>>>>> Senior Solution Architect @ Capgemini SSC
>>>>>>>>>>> (http://www.capgeminisoftware.
>>>>>>>>>>> pl/)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>> Jean-Baptiste Onofr�
>>>>>>>>> jbonofre@apache.org
>>>>>>>>> http://blog.nanthrax.net
>>>>>>>>> Talend - http://www.talend.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> Jean-Baptiste Onofr�
>>>>>>> jbonofre@apache.org
>>>>>>> http://blog.nanthrax.net
>>>>>>> Talend - http://www.talend.com
>>>>>>>
>>>>>>
>>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofr�
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Red Hat, Open Source Integration
>>
>> Email: gnodet@redhat.com
>> Web: http://fusesource.com
>> Blog: http://gnodet.blogspot.com/

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

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Markus Rathgeb <ma...@gmail.com>.
So, is there a way to use 1.3.0 (IIRC prerequisite and dependency has
been added there) or newer without adding the capability instruction
to every feature using a bundle without that information in the
manifest?
I see there is a configuration for the runtime, but is there one for
the plugin to control the verification?

I have to use a dozen of third party bundles that miss that
information and that change frequently, adding the capability to the
feature is a too time consuming effort.

2016-08-25 16:12 GMT+02:00 Guillaume Nodet <gn...@apache.org>:
> Agreed, so the problem was caused by a custom feature ?
> I thought it was directly the pax-web feature.
>
> In that case, I agree, that's exactly the behavior we wanted I think.
>
> On a side note, if pax-web does not expose the service capability, it
> should also be fixed ;-)
>
> Guillaume
>
> 2016-08-25 15:55 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>
>> After digging a bit, I don't think it's actually a bug.
>>
>> Let me explain and see we all agree ;)
>>
>> Previously to the commit, the service enforcement was "enabled" only for
>> features XML using xmlns 1.3.0 (not 1.4.0). The commit fixed service
>> enforcement also for xmlns 1.4.0 (which makes sense).
>>
>> In Markus' use case, he said he tried xmlns 1.2.0 and it failed. However,
>> as he's using Karaf Maven plugin to generate the descriptor, by default,
>> even if the "source" features XML contains xmlns 1.2.0, the generated one
>> is using xmlns 1.4.0.
>>
>> That's why it worked before and not after the commit.
>>
>> Due to that, I don't think we have to consider it as a bug:
>> 1. If we don't want service enforcement, than, we have to use a feature
>> with xmlns 1.2.0
>> 2. Actually using features xmlns 1.3.0 or 1.4.0 means we want resolver
>> features including services enforcement.
>>
>> WDYT ?
>>
>> Regards
>> JB
>>
>>
>> On 08/25/2016 03:41 PM, Jean-Baptiste Onofré wrote:
>>
>>> It looks like the commit in cause is the following:
>>>
>>> ---------------------
>>> 5c5828322ad898e80e66923edeb29e1a25b774cb is the first bad commit
>>> commit 5c5828322ad898e80e66923edeb29e1a25b774cb
>>> Author: Guillaume Nodet <gn...@apache.org>
>>> Date:   Fri Jul 22 12:33:17 2016 +0200
>>>
>>>     [KARAF-4632] Default serviceRequirements should handle 1.4.0 schema
>>>
>>> :040000 040000 d038cf82d490d3cd0c7df97376575e323ef2382f
>>> 2e6efa64dfd142e722970949b05dcc1e152a3cd8 M      features
>>> ----------------------
>>>
>>> I'm testing a revert.
>>>
>>> Regards
>>> JB
>>>
>>> On 08/25/2016 11:03 AM, Jean-Baptiste Onofré wrote:
>>>
>>>> No, I don't think it's related as it's not a change in 4.0.6.
>>>>
>>>> I think it's a combination between the features resolver and the
>>>> karaf-maven-plugin.
>>>>
>>>> I'm pretty close in the bisect now ;)
>>>>
>>>> Regards
>>>> JB
>>>>
>>>> On 08/25/2016 10:46 AM, Markus Rathgeb wrote:
>>>>
>>>>> I found this one:
>>>>>
>>>>> # By default, the feature resolver checks the service
>>>>> requirements/capabilities of
>>>>> # bundles for new features (xml schema >= 1.3.0) in order to
>>>>> automatically installs
>>>>> # the required bundles.
>>>>> # The following flag can have those values:
>>>>> #   - disable: service requirements are completely ignored
>>>>> #   - default: service requirements are ignored for old features
>>>>> #   - enforce: service requirements are always verified
>>>>> #
>>>>> #serviceRequirements=default
>>>>>
>>>>> Do you think this one could be related?
>>>>>
>>>>> Changing the xmlns from v1.4.0 to v1.2.0 does not result in a
>>>>> successful verification.
>>>>>
>>>>> -<features xmlns="http://karaf.apache.org/xmlns/features/v1.4.0"
>>>>> name="${project.artifactId}-${project.version}">
>>>>> +<features xmlns="http://karaf.apache.org/xmlns/features/v1.2.0"
>>>>> name="${project.artifactId}-${project.version}">
>>>>>
>>>>> 2016-08-25 10:40 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>>>>
>>>>>> Hi Guillaume,
>>>>>>
>>>>>> I'm on git biset to identify the guilty ;)
>>>>>>
>>>>>> And yes, I will recut a release.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>>
>>>>>> On 08/25/2016 10:25 AM, Guillaume Nodet wrote:
>>>>>>
>>>>>>>
>>>>>>> Yeah, if it breaks compatibility, we should recut a release ?
>>>>>>> Has anyone identified the culprit commit yet ?
>>>>>>>
>>>>>>> 2016-08-25 9:39 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>>>>>>
>>>>>>> I think it's a change in the karaf-maven-plugin.
>>>>>>>>
>>>>>>>> And yes, I reproduce Markus' issue as well.
>>>>>>>>
>>>>>>>> Do we consider as release blocker ?
>>>>>>>>
>>>>>>>> If so, I will fix it today and submit a new vote.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> JB
>>>>>>>>
>>>>>>>>
>>>>>>>> On 08/25/2016 09:34 AM, Achim Nierbeck wrote:
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I was able to reproduce the issue Markus described with his test.
>>>>>>>>> One thing that crosses my mind, did we change something with the
>>>>>>>>> feature
>>>>>>>>> resolver? Cause I can't remember that the pax-web-api did actually
>>>>>>>>> contain
>>>>>>>>> a provide-capability for the WebContainer Service.
>>>>>>>>>
>>>>>>>>> regards, Achim
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2016-08-25 0:44 GMT+02:00 Krzysztof Sobkowiak
>>>>>>>>> <krzys.sobkowiak@gmail.com
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> :
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> +1 (non-binding)
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ServiceMix 7.x tests ok. Thanks!!!
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Krzysztof
>>>>>>>>>>
>>>>>>>>>> On 24.08.2016 06:47, Jean-Baptiste Onofré wrote:
>>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> I submit Karaf (Container) 4.0.6 release to your vote.
>>>>>>>>>>>
>>>>>>>>>>> Release Notes:
>>>>>>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>>>>>>>>>>>
>>>>>>>>>>> projectId=12311140&version=12335477
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Staging Repository:
>>>>>>>>>>>
>>>>>>>>>>> https://repository.apache.org/content/repositories/orgapache
>>>>>>>>>>> karaf-1071/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Git Tag:
>>>>>>>>>>> karaf-4.0.6
>>>>>>>>>>>
>>>>>>>>>>> Please vote to approve this release:
>>>>>>>>>>>
>>>>>>>>>>> [ ] +1 Approve the release
>>>>>>>>>>> [ ] -1 Don't approve the release (please provide specific
>>>>>>>>>>> comments)
>>>>>>>>>>>
>>>>>>>>>>> This vote will be open for at least 72 hours.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Regards
>>>>>>>>>>> JB
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Krzysztof Sobkowiak (@ksobkowiak)
>>>>>>>>>>
>>>>>>>>>> JEE & OSS Architect, Integration Architect
>>>>>>>>>> Apache Software Foundation Member (http://apache.org/)
>>>>>>>>>> Apache ServiceMix Committer & PMC Member
>>>>>>>>>> (http://servicemix.apache.org/)
>>>>>>>>>> Senior Solution Architect @ Capgemini SSC
>>>>>>>>>> (http://www.capgeminisoftware.
>>>>>>>>>> pl/)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>> Jean-Baptiste Onofré
>>>>>>>> jbonofre@apache.org
>>>>>>>> http://blog.nanthrax.net
>>>>>>>> Talend - http://www.talend.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Jean-Baptiste Onofré
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>
>>>>
>>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Red Hat, Open Source Integration
>
> Email: gnodet@redhat.com
> Web: http://fusesource.com
> Blog: http://gnodet.blogspot.com/

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Guillaume Nodet <gn...@apache.org>.
Agreed, so the problem was caused by a custom feature ?
I thought it was directly the pax-web feature.

In that case, I agree, that's exactly the behavior we wanted I think.

On a side note, if pax-web does not expose the service capability, it
should also be fixed ;-)

Guillaume

2016-08-25 15:55 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:

> After digging a bit, I don't think it's actually a bug.
>
> Let me explain and see we all agree ;)
>
> Previously to the commit, the service enforcement was "enabled" only for
> features XML using xmlns 1.3.0 (not 1.4.0). The commit fixed service
> enforcement also for xmlns 1.4.0 (which makes sense).
>
> In Markus' use case, he said he tried xmlns 1.2.0 and it failed. However,
> as he's using Karaf Maven plugin to generate the descriptor, by default,
> even if the "source" features XML contains xmlns 1.2.0, the generated one
> is using xmlns 1.4.0.
>
> That's why it worked before and not after the commit.
>
> Due to that, I don't think we have to consider it as a bug:
> 1. If we don't want service enforcement, than, we have to use a feature
> with xmlns 1.2.0
> 2. Actually using features xmlns 1.3.0 or 1.4.0 means we want resolver
> features including services enforcement.
>
> WDYT ?
>
> Regards
> JB
>
>
> On 08/25/2016 03:41 PM, Jean-Baptiste Onofré wrote:
>
>> It looks like the commit in cause is the following:
>>
>> ---------------------
>> 5c5828322ad898e80e66923edeb29e1a25b774cb is the first bad commit
>> commit 5c5828322ad898e80e66923edeb29e1a25b774cb
>> Author: Guillaume Nodet <gn...@apache.org>
>> Date:   Fri Jul 22 12:33:17 2016 +0200
>>
>>     [KARAF-4632] Default serviceRequirements should handle 1.4.0 schema
>>
>> :040000 040000 d038cf82d490d3cd0c7df97376575e323ef2382f
>> 2e6efa64dfd142e722970949b05dcc1e152a3cd8 M      features
>> ----------------------
>>
>> I'm testing a revert.
>>
>> Regards
>> JB
>>
>> On 08/25/2016 11:03 AM, Jean-Baptiste Onofré wrote:
>>
>>> No, I don't think it's related as it's not a change in 4.0.6.
>>>
>>> I think it's a combination between the features resolver and the
>>> karaf-maven-plugin.
>>>
>>> I'm pretty close in the bisect now ;)
>>>
>>> Regards
>>> JB
>>>
>>> On 08/25/2016 10:46 AM, Markus Rathgeb wrote:
>>>
>>>> I found this one:
>>>>
>>>> # By default, the feature resolver checks the service
>>>> requirements/capabilities of
>>>> # bundles for new features (xml schema >= 1.3.0) in order to
>>>> automatically installs
>>>> # the required bundles.
>>>> # The following flag can have those values:
>>>> #   - disable: service requirements are completely ignored
>>>> #   - default: service requirements are ignored for old features
>>>> #   - enforce: service requirements are always verified
>>>> #
>>>> #serviceRequirements=default
>>>>
>>>> Do you think this one could be related?
>>>>
>>>> Changing the xmlns from v1.4.0 to v1.2.0 does not result in a
>>>> successful verification.
>>>>
>>>> -<features xmlns="http://karaf.apache.org/xmlns/features/v1.4.0"
>>>> name="${project.artifactId}-${project.version}">
>>>> +<features xmlns="http://karaf.apache.org/xmlns/features/v1.2.0"
>>>> name="${project.artifactId}-${project.version}">
>>>>
>>>> 2016-08-25 10:40 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>>>
>>>>> Hi Guillaume,
>>>>>
>>>>> I'm on git biset to identify the guilty ;)
>>>>>
>>>>> And yes, I will recut a release.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>> On 08/25/2016 10:25 AM, Guillaume Nodet wrote:
>>>>>
>>>>>>
>>>>>> Yeah, if it breaks compatibility, we should recut a release ?
>>>>>> Has anyone identified the culprit commit yet ?
>>>>>>
>>>>>> 2016-08-25 9:39 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>>>>>
>>>>>> I think it's a change in the karaf-maven-plugin.
>>>>>>>
>>>>>>> And yes, I reproduce Markus' issue as well.
>>>>>>>
>>>>>>> Do we consider as release blocker ?
>>>>>>>
>>>>>>> If so, I will fix it today and submit a new vote.
>>>>>>>
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>>
>>>>>>> On 08/25/2016 09:34 AM, Achim Nierbeck wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I was able to reproduce the issue Markus described with his test.
>>>>>>>> One thing that crosses my mind, did we change something with the
>>>>>>>> feature
>>>>>>>> resolver? Cause I can't remember that the pax-web-api did actually
>>>>>>>> contain
>>>>>>>> a provide-capability for the WebContainer Service.
>>>>>>>>
>>>>>>>> regards, Achim
>>>>>>>>
>>>>>>>>
>>>>>>>> 2016-08-25 0:44 GMT+02:00 Krzysztof Sobkowiak
>>>>>>>> <krzys.sobkowiak@gmail.com
>>>>>>>>
>>>>>>>>>
>>>>>>>>> :
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> +1 (non-binding)
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ServiceMix 7.x tests ok. Thanks!!!
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Krzysztof
>>>>>>>>>
>>>>>>>>> On 24.08.2016 06:47, Jean-Baptiste Onofré wrote:
>>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> I submit Karaf (Container) 4.0.6 release to your vote.
>>>>>>>>>>
>>>>>>>>>> Release Notes:
>>>>>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>>>>>>>>>>
>>>>>>>>>> projectId=12311140&version=12335477
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Staging Repository:
>>>>>>>>>>
>>>>>>>>>> https://repository.apache.org/content/repositories/orgapache
>>>>>>>>>> karaf-1071/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Git Tag:
>>>>>>>>>> karaf-4.0.6
>>>>>>>>>>
>>>>>>>>>> Please vote to approve this release:
>>>>>>>>>>
>>>>>>>>>> [ ] +1 Approve the release
>>>>>>>>>> [ ] -1 Don't approve the release (please provide specific
>>>>>>>>>> comments)
>>>>>>>>>>
>>>>>>>>>> This vote will be open for at least 72 hours.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Regards
>>>>>>>>>> JB
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Krzysztof Sobkowiak (@ksobkowiak)
>>>>>>>>>
>>>>>>>>> JEE & OSS Architect, Integration Architect
>>>>>>>>> Apache Software Foundation Member (http://apache.org/)
>>>>>>>>> Apache ServiceMix Committer & PMC Member
>>>>>>>>> (http://servicemix.apache.org/)
>>>>>>>>> Senior Solution Architect @ Capgemini SSC
>>>>>>>>> (http://www.capgeminisoftware.
>>>>>>>>> pl/)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>> Jean-Baptiste Onofré
>>>>>>> jbonofre@apache.org
>>>>>>> http://blog.nanthrax.net
>>>>>>> Talend - http://www.talend.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> Jean-Baptiste Onofré
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>
>>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

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

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
After digging a bit, I don't think it's actually a bug.

Let me explain and see we all agree ;)

Previously to the commit, the service enforcement was "enabled" only for 
features XML using xmlns 1.3.0 (not 1.4.0). The commit fixed service 
enforcement also for xmlns 1.4.0 (which makes sense).

In Markus' use case, he said he tried xmlns 1.2.0 and it failed. 
However, as he's using Karaf Maven plugin to generate the descriptor, by 
default, even if the "source" features XML contains xmlns 1.2.0, the 
generated one is using xmlns 1.4.0.

That's why it worked before and not after the commit.

Due to that, I don't think we have to consider it as a bug:
1. If we don't want service enforcement, than, we have to use a feature 
with xmlns 1.2.0
2. Actually using features xmlns 1.3.0 or 1.4.0 means we want resolver 
features including services enforcement.

WDYT ?

Regards
JB

On 08/25/2016 03:41 PM, Jean-Baptiste Onofr� wrote:
> It looks like the commit in cause is the following:
>
> ---------------------
> 5c5828322ad898e80e66923edeb29e1a25b774cb is the first bad commit
> commit 5c5828322ad898e80e66923edeb29e1a25b774cb
> Author: Guillaume Nodet <gn...@apache.org>
> Date:   Fri Jul 22 12:33:17 2016 +0200
>
>     [KARAF-4632] Default serviceRequirements should handle 1.4.0 schema
>
> :040000 040000 d038cf82d490d3cd0c7df97376575e323ef2382f
> 2e6efa64dfd142e722970949b05dcc1e152a3cd8 M      features
> ----------------------
>
> I'm testing a revert.
>
> Regards
> JB
>
> On 08/25/2016 11:03 AM, Jean-Baptiste Onofr� wrote:
>> No, I don't think it's related as it's not a change in 4.0.6.
>>
>> I think it's a combination between the features resolver and the
>> karaf-maven-plugin.
>>
>> I'm pretty close in the bisect now ;)
>>
>> Regards
>> JB
>>
>> On 08/25/2016 10:46 AM, Markus Rathgeb wrote:
>>> I found this one:
>>>
>>> # By default, the feature resolver checks the service
>>> requirements/capabilities of
>>> # bundles for new features (xml schema >= 1.3.0) in order to
>>> automatically installs
>>> # the required bundles.
>>> # The following flag can have those values:
>>> #   - disable: service requirements are completely ignored
>>> #   - default: service requirements are ignored for old features
>>> #   - enforce: service requirements are always verified
>>> #
>>> #serviceRequirements=default
>>>
>>> Do you think this one could be related?
>>>
>>> Changing the xmlns from v1.4.0 to v1.2.0 does not result in a
>>> successful verification.
>>>
>>> -<features xmlns="http://karaf.apache.org/xmlns/features/v1.4.0"
>>> name="${project.artifactId}-${project.version}">
>>> +<features xmlns="http://karaf.apache.org/xmlns/features/v1.2.0"
>>> name="${project.artifactId}-${project.version}">
>>>
>>> 2016-08-25 10:40 GMT+02:00 Jean-Baptiste Onofr� <jb...@nanthrax.net>:
>>>> Hi Guillaume,
>>>>
>>>> I'm on git biset to identify the guilty ;)
>>>>
>>>> And yes, I will recut a release.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 08/25/2016 10:25 AM, Guillaume Nodet wrote:
>>>>>
>>>>> Yeah, if it breaks compatibility, we should recut a release ?
>>>>> Has anyone identified the culprit commit yet ?
>>>>>
>>>>> 2016-08-25 9:39 GMT+02:00 Jean-Baptiste Onofr� <jb...@nanthrax.net>:
>>>>>
>>>>>> I think it's a change in the karaf-maven-plugin.
>>>>>>
>>>>>> And yes, I reproduce Markus' issue as well.
>>>>>>
>>>>>> Do we consider as release blocker ?
>>>>>>
>>>>>> If so, I will fix it today and submit a new vote.
>>>>>>
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>>
>>>>>> On 08/25/2016 09:34 AM, Achim Nierbeck wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I was able to reproduce the issue Markus described with his test.
>>>>>>> One thing that crosses my mind, did we change something with the
>>>>>>> feature
>>>>>>> resolver? Cause I can't remember that the pax-web-api did actually
>>>>>>> contain
>>>>>>> a provide-capability for the WebContainer Service.
>>>>>>>
>>>>>>> regards, Achim
>>>>>>>
>>>>>>>
>>>>>>> 2016-08-25 0:44 GMT+02:00 Krzysztof Sobkowiak
>>>>>>> <krzys.sobkowiak@gmail.com
>>>>>>>>
>>>>>>>> :
>>>>>>>
>>>>>>>
>>>>>>> +1 (non-binding)
>>>>>>>>
>>>>>>>>
>>>>>>>> ServiceMix 7.x tests ok. Thanks!!!
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Krzysztof
>>>>>>>>
>>>>>>>> On 24.08.2016 06:47, Jean-Baptiste Onofr� wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> I submit Karaf (Container) 4.0.6 release to your vote.
>>>>>>>>>
>>>>>>>>> Release Notes:
>>>>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>>>>>>>>>
>>>>>>>> projectId=12311140&version=12335477
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Staging Repository:
>>>>>>>>>
>>>>>>>>> https://repository.apache.org/content/repositories/orgapachekaraf-1071/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Git Tag:
>>>>>>>>> karaf-4.0.6
>>>>>>>>>
>>>>>>>>> Please vote to approve this release:
>>>>>>>>>
>>>>>>>>> [ ] +1 Approve the release
>>>>>>>>> [ ] -1 Don't approve the release (please provide specific
>>>>>>>>> comments)
>>>>>>>>>
>>>>>>>>> This vote will be open for at least 72 hours.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Regards
>>>>>>>>> JB
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Krzysztof Sobkowiak (@ksobkowiak)
>>>>>>>>
>>>>>>>> JEE & OSS Architect, Integration Architect
>>>>>>>> Apache Software Foundation Member (http://apache.org/)
>>>>>>>> Apache ServiceMix Committer & PMC Member
>>>>>>>> (http://servicemix.apache.org/)
>>>>>>>> Senior Solution Architect @ Capgemini SSC
>>>>>>>> (http://www.capgeminisoftware.
>>>>>>>> pl/)
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> Jean-Baptiste Onofr�
>>>>>> jbonofre@apache.org
>>>>>> http://blog.nanthrax.net
>>>>>> Talend - http://www.talend.com
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Jean-Baptiste Onofr�
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>
>

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

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
It looks like the commit in cause is the following:

---------------------
5c5828322ad898e80e66923edeb29e1a25b774cb is the first bad commit
commit 5c5828322ad898e80e66923edeb29e1a25b774cb
Author: Guillaume Nodet <gn...@apache.org>
Date:   Fri Jul 22 12:33:17 2016 +0200

     [KARAF-4632] Default serviceRequirements should handle 1.4.0 schema

:040000 040000 d038cf82d490d3cd0c7df97376575e323ef2382f 
2e6efa64dfd142e722970949b05dcc1e152a3cd8 M      features
----------------------

I'm testing a revert.

Regards
JB

On 08/25/2016 11:03 AM, Jean-Baptiste Onofr� wrote:
> No, I don't think it's related as it's not a change in 4.0.6.
>
> I think it's a combination between the features resolver and the
> karaf-maven-plugin.
>
> I'm pretty close in the bisect now ;)
>
> Regards
> JB
>
> On 08/25/2016 10:46 AM, Markus Rathgeb wrote:
>> I found this one:
>>
>> # By default, the feature resolver checks the service
>> requirements/capabilities of
>> # bundles for new features (xml schema >= 1.3.0) in order to
>> automatically installs
>> # the required bundles.
>> # The following flag can have those values:
>> #   - disable: service requirements are completely ignored
>> #   - default: service requirements are ignored for old features
>> #   - enforce: service requirements are always verified
>> #
>> #serviceRequirements=default
>>
>> Do you think this one could be related?
>>
>> Changing the xmlns from v1.4.0 to v1.2.0 does not result in a
>> successful verification.
>>
>> -<features xmlns="http://karaf.apache.org/xmlns/features/v1.4.0"
>> name="${project.artifactId}-${project.version}">
>> +<features xmlns="http://karaf.apache.org/xmlns/features/v1.2.0"
>> name="${project.artifactId}-${project.version}">
>>
>> 2016-08-25 10:40 GMT+02:00 Jean-Baptiste Onofr� <jb...@nanthrax.net>:
>>> Hi Guillaume,
>>>
>>> I'm on git biset to identify the guilty ;)
>>>
>>> And yes, I will recut a release.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 08/25/2016 10:25 AM, Guillaume Nodet wrote:
>>>>
>>>> Yeah, if it breaks compatibility, we should recut a release ?
>>>> Has anyone identified the culprit commit yet ?
>>>>
>>>> 2016-08-25 9:39 GMT+02:00 Jean-Baptiste Onofr� <jb...@nanthrax.net>:
>>>>
>>>>> I think it's a change in the karaf-maven-plugin.
>>>>>
>>>>> And yes, I reproduce Markus' issue as well.
>>>>>
>>>>> Do we consider as release blocker ?
>>>>>
>>>>> If so, I will fix it today and submit a new vote.
>>>>>
>>>>> Regards
>>>>> JB
>>>>>
>>>>>
>>>>> On 08/25/2016 09:34 AM, Achim Nierbeck wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I was able to reproduce the issue Markus described with his test.
>>>>>> One thing that crosses my mind, did we change something with the
>>>>>> feature
>>>>>> resolver? Cause I can't remember that the pax-web-api did actually
>>>>>> contain
>>>>>> a provide-capability for the WebContainer Service.
>>>>>>
>>>>>> regards, Achim
>>>>>>
>>>>>>
>>>>>> 2016-08-25 0:44 GMT+02:00 Krzysztof Sobkowiak
>>>>>> <krzys.sobkowiak@gmail.com
>>>>>>>
>>>>>>> :
>>>>>>
>>>>>>
>>>>>> +1 (non-binding)
>>>>>>>
>>>>>>>
>>>>>>> ServiceMix 7.x tests ok. Thanks!!!
>>>>>>>
>>>>>>> Regards
>>>>>>> Krzysztof
>>>>>>>
>>>>>>> On 24.08.2016 06:47, Jean-Baptiste Onofr� wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> I submit Karaf (Container) 4.0.6 release to your vote.
>>>>>>>>
>>>>>>>> Release Notes:
>>>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>>>>>>>>
>>>>>>> projectId=12311140&version=12335477
>>>>>>>
>>>>>>>>
>>>>>>>> Staging Repository:
>>>>>>>>
>>>>>>>> https://repository.apache.org/content/repositories/orgapachekaraf-1071/
>>>>>>>>
>>>>>>>>
>>>>>>>> Git Tag:
>>>>>>>> karaf-4.0.6
>>>>>>>>
>>>>>>>> Please vote to approve this release:
>>>>>>>>
>>>>>>>> [ ] +1 Approve the release
>>>>>>>> [ ] -1 Don't approve the release (please provide specific comments)
>>>>>>>>
>>>>>>>> This vote will be open for at least 72 hours.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Regards
>>>>>>>> JB
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Krzysztof Sobkowiak (@ksobkowiak)
>>>>>>>
>>>>>>> JEE & OSS Architect, Integration Architect
>>>>>>> Apache Software Foundation Member (http://apache.org/)
>>>>>>> Apache ServiceMix Committer & PMC Member
>>>>>>> (http://servicemix.apache.org/)
>>>>>>> Senior Solution Architect @ Capgemini SSC
>>>>>>> (http://www.capgeminisoftware.
>>>>>>> pl/)
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> Jean-Baptiste Onofr�
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Jean-Baptiste Onofr�
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>

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

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
No, I don't think it's related as it's not a change in 4.0.6.

I think it's a combination between the features resolver and the 
karaf-maven-plugin.

I'm pretty close in the bisect now ;)

Regards
JB

On 08/25/2016 10:46 AM, Markus Rathgeb wrote:
> I found this one:
>
> # By default, the feature resolver checks the service
> requirements/capabilities of
> # bundles for new features (xml schema >= 1.3.0) in order to
> automatically installs
> # the required bundles.
> # The following flag can have those values:
> #   - disable: service requirements are completely ignored
> #   - default: service requirements are ignored for old features
> #   - enforce: service requirements are always verified
> #
> #serviceRequirements=default
>
> Do you think this one could be related?
>
> Changing the xmlns from v1.4.0 to v1.2.0 does not result in a
> successful verification.
>
> -<features xmlns="http://karaf.apache.org/xmlns/features/v1.4.0"
> name="${project.artifactId}-${project.version}">
> +<features xmlns="http://karaf.apache.org/xmlns/features/v1.2.0"
> name="${project.artifactId}-${project.version}">
>
> 2016-08-25 10:40 GMT+02:00 Jean-Baptiste Onofr� <jb...@nanthrax.net>:
>> Hi Guillaume,
>>
>> I'm on git biset to identify the guilty ;)
>>
>> And yes, I will recut a release.
>>
>> Regards
>> JB
>>
>>
>> On 08/25/2016 10:25 AM, Guillaume Nodet wrote:
>>>
>>> Yeah, if it breaks compatibility, we should recut a release ?
>>> Has anyone identified the culprit commit yet ?
>>>
>>> 2016-08-25 9:39 GMT+02:00 Jean-Baptiste Onofr� <jb...@nanthrax.net>:
>>>
>>>> I think it's a change in the karaf-maven-plugin.
>>>>
>>>> And yes, I reproduce Markus' issue as well.
>>>>
>>>> Do we consider as release blocker ?
>>>>
>>>> If so, I will fix it today and submit a new vote.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 08/25/2016 09:34 AM, Achim Nierbeck wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I was able to reproduce the issue Markus described with his test.
>>>>> One thing that crosses my mind, did we change something with the feature
>>>>> resolver? Cause I can't remember that the pax-web-api did actually
>>>>> contain
>>>>> a provide-capability for the WebContainer Service.
>>>>>
>>>>> regards, Achim
>>>>>
>>>>>
>>>>> 2016-08-25 0:44 GMT+02:00 Krzysztof Sobkowiak <krzys.sobkowiak@gmail.com
>>>>>>
>>>>>> :
>>>>>
>>>>>
>>>>> +1 (non-binding)
>>>>>>
>>>>>>
>>>>>> ServiceMix 7.x tests ok. Thanks!!!
>>>>>>
>>>>>> Regards
>>>>>> Krzysztof
>>>>>>
>>>>>> On 24.08.2016 06:47, Jean-Baptiste Onofr� wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I submit Karaf (Container) 4.0.6 release to your vote.
>>>>>>>
>>>>>>> Release Notes:
>>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>>>>>>>
>>>>>> projectId=12311140&version=12335477
>>>>>>
>>>>>>>
>>>>>>> Staging Repository:
>>>>>>>
>>>>>>> https://repository.apache.org/content/repositories/orgapachekaraf-1071/
>>>>>>>
>>>>>>> Git Tag:
>>>>>>> karaf-4.0.6
>>>>>>>
>>>>>>> Please vote to approve this release:
>>>>>>>
>>>>>>> [ ] +1 Approve the release
>>>>>>> [ ] -1 Don't approve the release (please provide specific comments)
>>>>>>>
>>>>>>> This vote will be open for at least 72 hours.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Krzysztof Sobkowiak (@ksobkowiak)
>>>>>>
>>>>>> JEE & OSS Architect, Integration Architect
>>>>>> Apache Software Foundation Member (http://apache.org/)
>>>>>> Apache ServiceMix Committer & PMC Member
>>>>>> (http://servicemix.apache.org/)
>>>>>> Senior Solution Architect @ Capgemini SSC
>>>>>> (http://www.capgeminisoftware.
>>>>>> pl/)
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Jean-Baptiste Onofr�
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>>
>>>
>>
>> --
>> Jean-Baptiste Onofr�
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com

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

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Markus Rathgeb <ma...@gmail.com>.
https://issues.apache.org/jira/browse/KARAF-3520

2016-08-25 10:46 GMT+02:00 Markus Rathgeb <ma...@gmail.com>:
> I found this one:
>
> # By default, the feature resolver checks the service
> requirements/capabilities of
> # bundles for new features (xml schema >= 1.3.0) in order to
> automatically installs
> # the required bundles.
> # The following flag can have those values:
> #   - disable: service requirements are completely ignored
> #   - default: service requirements are ignored for old features
> #   - enforce: service requirements are always verified
> #
> #serviceRequirements=default
>
> Do you think this one could be related?
>
> Changing the xmlns from v1.4.0 to v1.2.0 does not result in a
> successful verification.
>
> -<features xmlns="http://karaf.apache.org/xmlns/features/v1.4.0"
> name="${project.artifactId}-${project.version}">
> +<features xmlns="http://karaf.apache.org/xmlns/features/v1.2.0"
> name="${project.artifactId}-${project.version}">
>
> 2016-08-25 10:40 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>> Hi Guillaume,
>>
>> I'm on git biset to identify the guilty ;)
>>
>> And yes, I will recut a release.
>>
>> Regards
>> JB
>>
>>
>> On 08/25/2016 10:25 AM, Guillaume Nodet wrote:
>>>
>>> Yeah, if it breaks compatibility, we should recut a release ?
>>> Has anyone identified the culprit commit yet ?
>>>
>>> 2016-08-25 9:39 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>>
>>>> I think it's a change in the karaf-maven-plugin.
>>>>
>>>> And yes, I reproduce Markus' issue as well.
>>>>
>>>> Do we consider as release blocker ?
>>>>
>>>> If so, I will fix it today and submit a new vote.
>>>>
>>>> Regards
>>>> JB
>>>>
>>>>
>>>> On 08/25/2016 09:34 AM, Achim Nierbeck wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I was able to reproduce the issue Markus described with his test.
>>>>> One thing that crosses my mind, did we change something with the feature
>>>>> resolver? Cause I can't remember that the pax-web-api did actually
>>>>> contain
>>>>> a provide-capability for the WebContainer Service.
>>>>>
>>>>> regards, Achim
>>>>>
>>>>>
>>>>> 2016-08-25 0:44 GMT+02:00 Krzysztof Sobkowiak <krzys.sobkowiak@gmail.com
>>>>>>
>>>>>> :
>>>>>
>>>>>
>>>>> +1 (non-binding)
>>>>>>
>>>>>>
>>>>>> ServiceMix 7.x tests ok. Thanks!!!
>>>>>>
>>>>>> Regards
>>>>>> Krzysztof
>>>>>>
>>>>>> On 24.08.2016 06:47, Jean-Baptiste Onofré wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I submit Karaf (Container) 4.0.6 release to your vote.
>>>>>>>
>>>>>>> Release Notes:
>>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>>>>>>>
>>>>>> projectId=12311140&version=12335477
>>>>>>
>>>>>>>
>>>>>>> Staging Repository:
>>>>>>>
>>>>>>> https://repository.apache.org/content/repositories/orgapachekaraf-1071/
>>>>>>>
>>>>>>> Git Tag:
>>>>>>> karaf-4.0.6
>>>>>>>
>>>>>>> Please vote to approve this release:
>>>>>>>
>>>>>>> [ ] +1 Approve the release
>>>>>>> [ ] -1 Don't approve the release (please provide specific comments)
>>>>>>>
>>>>>>> This vote will be open for at least 72 hours.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Regards
>>>>>>> JB
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Krzysztof Sobkowiak (@ksobkowiak)
>>>>>>
>>>>>> JEE & OSS Architect, Integration Architect
>>>>>> Apache Software Foundation Member (http://apache.org/)
>>>>>> Apache ServiceMix Committer & PMC Member
>>>>>> (http://servicemix.apache.org/)
>>>>>> Senior Solution Architect @ Capgemini SSC
>>>>>> (http://www.capgeminisoftware.
>>>>>> pl/)
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Jean-Baptiste Onofré
>>>> jbonofre@apache.org
>>>> http://blog.nanthrax.net
>>>> Talend - http://www.talend.com
>>>>
>>>
>>>
>>>
>>
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Markus Rathgeb <ma...@gmail.com>.
I found this one:

# By default, the feature resolver checks the service
requirements/capabilities of
# bundles for new features (xml schema >= 1.3.0) in order to
automatically installs
# the required bundles.
# The following flag can have those values:
#   - disable: service requirements are completely ignored
#   - default: service requirements are ignored for old features
#   - enforce: service requirements are always verified
#
#serviceRequirements=default

Do you think this one could be related?

Changing the xmlns from v1.4.0 to v1.2.0 does not result in a
successful verification.

-<features xmlns="http://karaf.apache.org/xmlns/features/v1.4.0"
name="${project.artifactId}-${project.version}">
+<features xmlns="http://karaf.apache.org/xmlns/features/v1.2.0"
name="${project.artifactId}-${project.version}">

2016-08-25 10:40 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
> Hi Guillaume,
>
> I'm on git biset to identify the guilty ;)
>
> And yes, I will recut a release.
>
> Regards
> JB
>
>
> On 08/25/2016 10:25 AM, Guillaume Nodet wrote:
>>
>> Yeah, if it breaks compatibility, we should recut a release ?
>> Has anyone identified the culprit commit yet ?
>>
>> 2016-08-25 9:39 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:
>>
>>> I think it's a change in the karaf-maven-plugin.
>>>
>>> And yes, I reproduce Markus' issue as well.
>>>
>>> Do we consider as release blocker ?
>>>
>>> If so, I will fix it today and submit a new vote.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> On 08/25/2016 09:34 AM, Achim Nierbeck wrote:
>>>
>>>> Hi,
>>>>
>>>> I was able to reproduce the issue Markus described with his test.
>>>> One thing that crosses my mind, did we change something with the feature
>>>> resolver? Cause I can't remember that the pax-web-api did actually
>>>> contain
>>>> a provide-capability for the WebContainer Service.
>>>>
>>>> regards, Achim
>>>>
>>>>
>>>> 2016-08-25 0:44 GMT+02:00 Krzysztof Sobkowiak <krzys.sobkowiak@gmail.com
>>>>>
>>>>> :
>>>>
>>>>
>>>> +1 (non-binding)
>>>>>
>>>>>
>>>>> ServiceMix 7.x tests ok. Thanks!!!
>>>>>
>>>>> Regards
>>>>> Krzysztof
>>>>>
>>>>> On 24.08.2016 06:47, Jean-Baptiste Onofré wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I submit Karaf (Container) 4.0.6 release to your vote.
>>>>>>
>>>>>> Release Notes:
>>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>>>>>>
>>>>> projectId=12311140&version=12335477
>>>>>
>>>>>>
>>>>>> Staging Repository:
>>>>>>
>>>>>> https://repository.apache.org/content/repositories/orgapachekaraf-1071/
>>>>>>
>>>>>> Git Tag:
>>>>>> karaf-4.0.6
>>>>>>
>>>>>> Please vote to approve this release:
>>>>>>
>>>>>> [ ] +1 Approve the release
>>>>>> [ ] -1 Don't approve the release (please provide specific comments)
>>>>>>
>>>>>> This vote will be open for at least 72 hours.
>>>>>>
>>>>>> Thanks,
>>>>>> Regards
>>>>>> JB
>>>>>>
>>>>>
>>>>> --
>>>>> Krzysztof Sobkowiak (@ksobkowiak)
>>>>>
>>>>> JEE & OSS Architect, Integration Architect
>>>>> Apache Software Foundation Member (http://apache.org/)
>>>>> Apache ServiceMix Committer & PMC Member
>>>>> (http://servicemix.apache.org/)
>>>>> Senior Solution Architect @ Capgemini SSC
>>>>> (http://www.capgeminisoftware.
>>>>> pl/)
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>> --
>>> Jean-Baptiste Onofré
>>> jbonofre@apache.org
>>> http://blog.nanthrax.net
>>> Talend - http://www.talend.com
>>>
>>
>>
>>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Guillaume,

I'm on git biset to identify the guilty ;)

And yes, I will recut a release.

Regards
JB

On 08/25/2016 10:25 AM, Guillaume Nodet wrote:
> Yeah, if it breaks compatibility, we should recut a release ?
> Has anyone identified the culprit commit yet ?
>
> 2016-08-25 9:39 GMT+02:00 Jean-Baptiste Onofr� <jb...@nanthrax.net>:
>
>> I think it's a change in the karaf-maven-plugin.
>>
>> And yes, I reproduce Markus' issue as well.
>>
>> Do we consider as release blocker ?
>>
>> If so, I will fix it today and submit a new vote.
>>
>> Regards
>> JB
>>
>>
>> On 08/25/2016 09:34 AM, Achim Nierbeck wrote:
>>
>>> Hi,
>>>
>>> I was able to reproduce the issue Markus described with his test.
>>> One thing that crosses my mind, did we change something with the feature
>>> resolver? Cause I can't remember that the pax-web-api did actually contain
>>> a provide-capability for the WebContainer Service.
>>>
>>> regards, Achim
>>>
>>>
>>> 2016-08-25 0:44 GMT+02:00 Krzysztof Sobkowiak <krzys.sobkowiak@gmail.com
>>>> :
>>>
>>> +1 (non-binding)
>>>>
>>>> ServiceMix 7.x tests ok. Thanks!!!
>>>>
>>>> Regards
>>>> Krzysztof
>>>>
>>>> On 24.08.2016 06:47, Jean-Baptiste Onofr� wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I submit Karaf (Container) 4.0.6 release to your vote.
>>>>>
>>>>> Release Notes:
>>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>>>>>
>>>> projectId=12311140&version=12335477
>>>>
>>>>>
>>>>> Staging Repository:
>>>>> https://repository.apache.org/content/repositories/orgapachekaraf-1071/
>>>>>
>>>>> Git Tag:
>>>>> karaf-4.0.6
>>>>>
>>>>> Please vote to approve this release:
>>>>>
>>>>> [ ] +1 Approve the release
>>>>> [ ] -1 Don't approve the release (please provide specific comments)
>>>>>
>>>>> This vote will be open for at least 72 hours.
>>>>>
>>>>> Thanks,
>>>>> Regards
>>>>> JB
>>>>>
>>>>
>>>> --
>>>> Krzysztof Sobkowiak (@ksobkowiak)
>>>>
>>>> JEE & OSS Architect, Integration Architect
>>>> Apache Software Foundation Member (http://apache.org/)
>>>> Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
>>>> Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.
>>>> pl/)
>>>>
>>>>
>>>
>>>
>>>
>> --
>> Jean-Baptiste Onofr�
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com
>>
>
>
>

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

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Guillaume Nodet <gn...@apache.org>.
Yeah, if it breaks compatibility, we should recut a release ?
Has anyone identified the culprit commit yet ?

2016-08-25 9:39 GMT+02:00 Jean-Baptiste Onofré <jb...@nanthrax.net>:

> I think it's a change in the karaf-maven-plugin.
>
> And yes, I reproduce Markus' issue as well.
>
> Do we consider as release blocker ?
>
> If so, I will fix it today and submit a new vote.
>
> Regards
> JB
>
>
> On 08/25/2016 09:34 AM, Achim Nierbeck wrote:
>
>> Hi,
>>
>> I was able to reproduce the issue Markus described with his test.
>> One thing that crosses my mind, did we change something with the feature
>> resolver? Cause I can't remember that the pax-web-api did actually contain
>> a provide-capability for the WebContainer Service.
>>
>> regards, Achim
>>
>>
>> 2016-08-25 0:44 GMT+02:00 Krzysztof Sobkowiak <krzys.sobkowiak@gmail.com
>> >:
>>
>> +1 (non-binding)
>>>
>>> ServiceMix 7.x tests ok. Thanks!!!
>>>
>>> Regards
>>> Krzysztof
>>>
>>> On 24.08.2016 06:47, Jean-Baptiste Onofré wrote:
>>>
>>>> Hi all,
>>>>
>>>> I submit Karaf (Container) 4.0.6 release to your vote.
>>>>
>>>> Release Notes:
>>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>>>>
>>> projectId=12311140&version=12335477
>>>
>>>>
>>>> Staging Repository:
>>>> https://repository.apache.org/content/repositories/orgapachekaraf-1071/
>>>>
>>>> Git Tag:
>>>> karaf-4.0.6
>>>>
>>>> Please vote to approve this release:
>>>>
>>>> [ ] +1 Approve the release
>>>> [ ] -1 Don't approve the release (please provide specific comments)
>>>>
>>>> This vote will be open for at least 72 hours.
>>>>
>>>> Thanks,
>>>> Regards
>>>> JB
>>>>
>>>
>>> --
>>> Krzysztof Sobkowiak (@ksobkowiak)
>>>
>>> JEE & OSS Architect, Integration Architect
>>> Apache Software Foundation Member (http://apache.org/)
>>> Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
>>> Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.
>>> pl/)
>>>
>>>
>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 
------------------------
Guillaume Nodet
------------------------
Red Hat, Open Source Integration

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

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
I think it's a change in the karaf-maven-plugin.

And yes, I reproduce Markus' issue as well.

Do we consider as release blocker ?

If so, I will fix it today and submit a new vote.

Regards
JB

On 08/25/2016 09:34 AM, Achim Nierbeck wrote:
> Hi,
>
> I was able to reproduce the issue Markus described with his test.
> One thing that crosses my mind, did we change something with the feature
> resolver? Cause I can't remember that the pax-web-api did actually contain
> a provide-capability for the WebContainer Service.
>
> regards, Achim
>
>
> 2016-08-25 0:44 GMT+02:00 Krzysztof Sobkowiak <kr...@gmail.com>:
>
>> +1 (non-binding)
>>
>> ServiceMix 7.x tests ok. Thanks!!!
>>
>> Regards
>> Krzysztof
>>
>> On 24.08.2016 06:47, Jean-Baptiste Onofr� wrote:
>>> Hi all,
>>>
>>> I submit Karaf (Container) 4.0.6 release to your vote.
>>>
>>> Release Notes:
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?
>> projectId=12311140&version=12335477
>>>
>>> Staging Repository:
>>> https://repository.apache.org/content/repositories/orgapachekaraf-1071/
>>>
>>> Git Tag:
>>> karaf-4.0.6
>>>
>>> Please vote to approve this release:
>>>
>>> [ ] +1 Approve the release
>>> [ ] -1 Don't approve the release (please provide specific comments)
>>>
>>> This vote will be open for at least 72 hours.
>>>
>>> Thanks,
>>> Regards
>>> JB
>>
>> --
>> Krzysztof Sobkowiak (@ksobkowiak)
>>
>> JEE & OSS Architect, Integration Architect
>> Apache Software Foundation Member (http://apache.org/)
>> Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
>> Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.
>> pl/)
>>
>
>
>

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

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi,

I was able to reproduce the issue Markus described with his test.
One thing that crosses my mind, did we change something with the feature
resolver? Cause I can't remember that the pax-web-api did actually contain
a provide-capability for the WebContainer Service.

regards, Achim


2016-08-25 0:44 GMT+02:00 Krzysztof Sobkowiak <kr...@gmail.com>:

> +1 (non-binding)
>
> ServiceMix 7.x tests ok. Thanks!!!
>
> Regards
> Krzysztof
>
> On 24.08.2016 06:47, Jean-Baptiste Onofré wrote:
> > Hi all,
> >
> > I submit Karaf (Container) 4.0.6 release to your vote.
> >
> > Release Notes:
> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?
> projectId=12311140&version=12335477
> >
> > Staging Repository:
> > https://repository.apache.org/content/repositories/orgapachekaraf-1071/
> >
> > Git Tag:
> > karaf-4.0.6
> >
> > Please vote to approve this release:
> >
> > [ ] +1 Approve the release
> > [ ] -1 Don't approve the release (please provide specific comments)
> >
> > This vote will be open for at least 72 hours.
> >
> > Thanks,
> > Regards
> > JB
>
> --
> Krzysztof Sobkowiak (@ksobkowiak)
>
> JEE & OSS Architect, Integration Architect
> Apache Software Foundation Member (http://apache.org/)
> Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
> Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.
> pl/)
>



-- 

Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Krzysztof Sobkowiak <kr...@gmail.com>.
+1 (non-binding)

ServiceMix 7.x tests ok. Thanks!!!

Regards
Krzysztof

On 24.08.2016 06:47, Jean-Baptiste Onofr� wrote:
> Hi all,
>
> I submit Karaf (Container) 4.0.6 release to your vote.
>
> Release Notes:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12311140&version=12335477
>
> Staging Repository:
> https://repository.apache.org/content/repositories/orgapachekaraf-1071/
>
> Git Tag:
> karaf-4.0.6
>
> Please vote to approve this release:
>
> [ ] +1 Approve the release
> [ ] -1 Don't approve the release (please provide specific comments)
>
> This vote will be open for at least 72 hours.
>
> Thanks,
> Regards
> JB

-- 
Krzysztof Sobkowiak (@ksobkowiak)

JEE & OSS Architect, Integration Architect
Apache Software Foundation Member (http://apache.org/)
Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/)
Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Markus Rathgeb <ma...@gmail.com>.
Hi,

> can you explain how to reproduce it ?

Yes, I created a sample / dummy project to reproduce it.

Please have a look at:
https://github.com/maggu2810/k406-staging

I used profiles to switch between K405 and K406.

> Is it specific on 4.0.6 or does it happen with 4.0.5 as well ?

* K405 success
* K406 failure

To test:
mvn clean install -PK405
mvn clean install -PK406

Best regards,
Markus

>
> Thanks,
> Regards
> JB
>
>
> On 08/24/2016 11:19 AM, Markus Rathgeb wrote:
>>
>> Hello,
>>
>> I see this error about missing "osgi.service"
>> (filter:="(objectClass=...)";effective:=active) for a lot of features
>> at verification now.
>>
>> I assume it fails for all features that contains a bundle that
>> "Require-Capability" contains this requirement, but the bundle
>> containing this service does not provide it by the
>> "Provide-Capability" information.
>>
>> The Require-Capability and Provide-Capability information in the
>> manifest is added by Bnd (e.g. using maven-bundle-plugin) but there
>> are other bundles (for me third party ones) not using Bnd and this
>> information is missing.
>>
>> Do you know if it is possible to instruct the feature resolver to
>> satisfy a osgi.service required capability if a implementation of the
>> class is present or looking also at the DS files, too?
>>
>> 2016-08-24 10:22 GMT+02:00 Markus Rathgeb <ma...@gmail.com>:
>>>
>>> Hello,
>>>
>>> I use a component that imports the Pax Web WebContainer class and
>>> depends on a service reference.
>>>
>>> ===
>>> import org.ops4j.pax.web.service.WebContainer;
>>> ...
>>>
>>> @Component(immediate = true)
>>> public class Web {
>>>
>>>     @Reference
>>>     private WebContainer webContainer;
>>> ...
>>> ===
>>>
>>> My feature looks like this one:
>>>
>>> ===
>>>   <feature>
>>>    <bundle>mvn:.../.../${project.version}</bundle>
>>>     <feature>scr</feature>
>>>     <feature>shell</feature>
>>>     <feature>http</feature>
>>>     <feature>pax-http-whiteboard</feature>
>>>   </feature>
>>> ===
>>>
>>> The verification works using K405.
>>> The verification fails using K406 staging
>>>
>>> (IIRC)
>>> K405 is using Pax Web 4.2.6
>>> K406 is using Pax Web 4.2.8
>>>
>>> The error on feature verification is:
>>> missing requirement [...] osgi.service;
>>> filter:="(objectClass=org.ops4j.pax.web.service.WebContainer)";
>>> effective:=active]]
>>>
>>> So, why is the WebContainer service not satisfied anymore?
>>> Is this a change in the Pax Web features (but pax-http and
>>> pax-http-whiteboard should satisfy the WebContainer, shouldn't it) or
>>> in the feature verification?
>>>
>>> Thanks in advance,
>>> Markus
>
>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Markus,

can you explain how to reproduce it ?

Is it specific on 4.0.6 or does it happen with 4.0.5 as well ?

Thanks,
Regards
JB

On 08/24/2016 11:19 AM, Markus Rathgeb wrote:
> Hello,
>
> I see this error about missing "osgi.service"
> (filter:="(objectClass=...)";effective:=active) for a lot of features
> at verification now.
>
> I assume it fails for all features that contains a bundle that
> "Require-Capability" contains this requirement, but the bundle
> containing this service does not provide it by the
> "Provide-Capability" information.
>
> The Require-Capability and Provide-Capability information in the
> manifest is added by Bnd (e.g. using maven-bundle-plugin) but there
> are other bundles (for me third party ones) not using Bnd and this
> information is missing.
>
> Do you know if it is possible to instruct the feature resolver to
> satisfy a osgi.service required capability if a implementation of the
> class is present or looking also at the DS files, too?
>
> 2016-08-24 10:22 GMT+02:00 Markus Rathgeb <ma...@gmail.com>:
>> Hello,
>>
>> I use a component that imports the Pax Web WebContainer class and
>> depends on a service reference.
>>
>> ===
>> import org.ops4j.pax.web.service.WebContainer;
>> ...
>>
>> @Component(immediate = true)
>> public class Web {
>>
>>     @Reference
>>     private WebContainer webContainer;
>> ...
>> ===
>>
>> My feature looks like this one:
>>
>> ===
>>   <feature>
>>    <bundle>mvn:.../.../${project.version}</bundle>
>>     <feature>scr</feature>
>>     <feature>shell</feature>
>>     <feature>http</feature>
>>     <feature>pax-http-whiteboard</feature>
>>   </feature>
>> ===
>>
>> The verification works using K405.
>> The verification fails using K406 staging
>>
>> (IIRC)
>> K405 is using Pax Web 4.2.6
>> K406 is using Pax Web 4.2.8
>>
>> The error on feature verification is:
>> missing requirement [...] osgi.service;
>> filter:="(objectClass=org.ops4j.pax.web.service.WebContainer)";
>> effective:=active]]
>>
>> So, why is the WebContainer service not satisfied anymore?
>> Is this a change in the Pax Web features (but pax-http and
>> pax-http-whiteboard should satisfy the WebContainer, shouldn't it) or
>> in the feature verification?
>>
>> Thanks in advance,
>> Markus

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

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Markus Rathgeb <ma...@gmail.com>.
Hello,

I see this error about missing "osgi.service"
(filter:="(objectClass=...)";effective:=active) for a lot of features
at verification now.

I assume it fails for all features that contains a bundle that
"Require-Capability" contains this requirement, but the bundle
containing this service does not provide it by the
"Provide-Capability" information.

The Require-Capability and Provide-Capability information in the
manifest is added by Bnd (e.g. using maven-bundle-plugin) but there
are other bundles (for me third party ones) not using Bnd and this
information is missing.

Do you know if it is possible to instruct the feature resolver to
satisfy a osgi.service required capability if a implementation of the
class is present or looking also at the DS files, too?

2016-08-24 10:22 GMT+02:00 Markus Rathgeb <ma...@gmail.com>:
> Hello,
>
> I use a component that imports the Pax Web WebContainer class and
> depends on a service reference.
>
> ===
> import org.ops4j.pax.web.service.WebContainer;
> ...
>
> @Component(immediate = true)
> public class Web {
>
>     @Reference
>     private WebContainer webContainer;
> ...
> ===
>
> My feature looks like this one:
>
> ===
>   <feature>
>    <bundle>mvn:.../.../${project.version}</bundle>
>     <feature>scr</feature>
>     <feature>shell</feature>
>     <feature>http</feature>
>     <feature>pax-http-whiteboard</feature>
>   </feature>
> ===
>
> The verification works using K405.
> The verification fails using K406 staging
>
> (IIRC)
> K405 is using Pax Web 4.2.6
> K406 is using Pax Web 4.2.8
>
> The error on feature verification is:
> missing requirement [...] osgi.service;
> filter:="(objectClass=org.ops4j.pax.web.service.WebContainer)";
> effective:=active]]
>
> So, why is the WebContainer service not satisfied anymore?
> Is this a change in the Pax Web features (but pax-http and
> pax-http-whiteboard should satisfy the WebContainer, shouldn't it) or
> in the feature verification?
>
> Thanks in advance,
> Markus

Re: [VOTE] Apache Karaf (Container) 4.0.6 release

Posted by Markus Rathgeb <ma...@gmail.com>.
Hello,

I use a component that imports the Pax Web WebContainer class and
depends on a service reference.

===
import org.ops4j.pax.web.service.WebContainer;
...

@Component(immediate = true)
public class Web {

    @Reference
    private WebContainer webContainer;
...
===

My feature looks like this one:

===
  <feature>
   <bundle>mvn:.../.../${project.version}</bundle>
    <feature>scr</feature>
    <feature>shell</feature>
    <feature>http</feature>
    <feature>pax-http-whiteboard</feature>
  </feature>
===

The verification works using K405.
The verification fails using K406 staging

(IIRC)
K405 is using Pax Web 4.2.6
K406 is using Pax Web 4.2.8

The error on feature verification is:
missing requirement [...] osgi.service;
filter:="(objectClass=org.ops4j.pax.web.service.WebContainer)";
effective:=active]]

So, why is the WebContainer service not satisfied anymore?
Is this a change in the Pax Web features (but pax-http and
pax-http-whiteboard should satisfy the WebContainer, shouldn't it) or
in the feature verification?

Thanks in advance,
Markus