Definitely not ;-)
https://github.com/apache/karaf/blob/master/features/core/src/main/java/org/apache/karaf/features/internal/service/Overrides.java#L97
2016-10-06 16:56 GMT+02:00 Benjamin Graf :
> Hi Guillaume,
>
> btw. is override generic enough to work on symbolic name rather than
> version r
Hi Guillaume,
btw. is override generic enough to work on symbolic name rather than
version ranges?
Override
mvn:org.apache.geronimo.specs/geronimo-jms_1.1_spec/1.1.1
With
mvn:org.apache.geronimo.specs/geronimo-jms_2.0_spec/1.0-alpha-2
Regards
Benjamin
Am 06.10.2016 um 16:14 schrieb Guillaum
Hi Guillaume,
blacklisting was a good and cheap idea. But I think this feature leaks
documentation I only found the commits in git to look how to use it. :-)
Thx Benjamin
Am 06.10.2016 um 16:14 schrieb Guillaume Nodet:
> I suppose one easy way is to simply blacklist the jms api 1.1 bundles,
> so
I suppose one easy way is to simply blacklist the jms api 1.1 bundles, so
that they will not be included in any resolution, or use an override to
automatically use jms 2.0 instead.
2016-10-06 16:09 GMT+02:00 Benjamin Graf :
> Hello,
>
> I'm actually playing with integrating ActiveMQ Artemis (1.5-
Hi Benjamin,
The feature resolver will try to find the feature matching the
requirements, so it's not necessary the "highest" one in the range.
For instance, if you have another feature installing spring-jms 3.2.18,
and then you install your feature containing sring-jms feature with
version
Hello,
I'm actually playing with integrating ActiveMQ Artemis (1.5-SNAPSHOT)
with Camel (2.17.3) on Karaf (4.0.8-SNAPSHOT). To get some conflicts
workarounded I'm deleting jms 1.1 API bundle from camel-jms feature
(2.17.3) and also from latest spring-jms feature (4.2.5.RELEASE_1). But
the jms bund