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é <j...@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 <gno...@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é <j...@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é <j...@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.sobkow...@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é
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
