I figured out why that was happening - it turns out we had packages listed in
org.osgi.framework.system.packages.extra in custom.properties that were
overriding the defaults in config.properties. As such, Xerces was never
being exported, and org.apache.xerces.util isn't in boot delegation so we
thanks! Let me know what i can do to help...
--
View this message in context:
http://karaf.922171.n3.nabble.com/Karaf-4-0-6-tp4047757p4047766.html
Sent from the Karaf - User mailing list archive at Nabble.com.
By the way: Also for Maven a version 1.0 generally means 1.0 or a
later version, if 1.0 is not available.
https://docs.oracle.com/middleware/1212/core/MAVEN/maven_version.htm#MAVEN402
2016-08-30 21:59 GMT+02:00 Jean-Baptiste Onofré :
> By the way: it's the OSGi convention. The
I see. Well, I guess if it is the OSGi convention it makes sense. It's
surprising to me though. I've worked with OSGi and Karaf for years and I
always assumed that if you specified an exact version it would look only for
that version. Perhaps, because I've never had more than two versions of a
By the way: it's the OSGi convention. The same apply to import package.
Something like:
Import-Package: com.foo;version="1.0.0"
means [1.0.0,)
If you want to narrow to 1.0.0 only then you have to use [1.0.0,1.0.0]
Regards
JB
On 08/30/2016 09:24 PM, oski_bear wrote:
Thanks Guillaume,
The
OK, thanks. I remember I did a change on in feature (to be
able to automatically generate corresponding cfg file). And I found an
issue about factory at that time. Let me check. I keep you posted.
Regards
JB
On 08/30/2016 09:04 PM, AndyPhillips404 wrote:
Sorry, to be honest, i'm not sure.
Thanks Guillaume,
The version range helped. Though, I think it's confusing that explicitly
setting a version translates to >=. After all I am using the "=" symbol not
the ">=" symbol.
I'm going to investigate the other issues a bit more and get back to you.
Thanks again
--
View this message
Sorry, to be honest, i'm not sure. I know i tested this part of the code in
the early 4.0.X (4.0.3 maybe?). I checked my SVN logs of this module and
the last commit was Jan of 2016 when i know it was working properly.
--
View this message in context:
Yes, I have observed the same behavior. I assumed I was doing something wrong
and removed the config from the feature.xml.
Erwin
> On Aug 30, 2016, at 11:39, AndyPhillips404 wrote:
>
> I have noticed in Karaf 4.0.5 and .6 that implementing configurations for
>
Hi Andy,
since when do you observe this behavior ?
Thanks,
Regards
JB
On 08/30/2016 05:39 PM, AndyPhillips404 wrote:
I have noticed in Karaf 4.0.5 and .6 that implementing configurations for
factoryConfigurations in the features resolver doesn't appear to work as
expected anymore.
When you
I have noticed in Karaf 4.0.5 and .6 that implementing configurations for
factoryConfigurations in the features resolver doesn't appear to work as
expected anymore.
When you add a config to the feature xml, that is a factoryConfiguration, it
creates two instances. I think this is because the
It's traditional. We wait for the last minute to get our talk proposals
in for conferences.
Well, the last minute has arrived. The CFP for ApacheCon Seville closes
on September 9th, which is less than 2 weeks away. It's time to get your
talks in, so that we can make this the best ApacheCon yet.
2016-08-30 7:04 GMT+02:00 oski_bear :
> I'm having a hard time with feature installation in Karaf 4.0.5. The latest
> issue seems to be that Karaf 4.0.5 disregards the version specified for a
> prerequisite feature. E.g.
>
>
13 matches
Mail list logo