karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gert Vanthienen <gert.vanthie...@gmail.com>
Subject Re: Features
Date Mon, 24 Oct 2011 22:11:57 GMT
Reply versus reply all seems to become a difficult thing for my mind at this
time of the day ;)

Regards,

Gert Vanthienen
------------------------
FuseSource
Web: http://fusesource.com
Blog: http://gertvanthienen.blogspot.com/


On Tue, Oct 25, 2011 at 12:09 AM, Gert Vanthienen <gert.vanthienen@gmail.com
> wrote:

>
> On Mon, Oct 24, 2011 at 11:19 PM, Daniel Kulp <dkulp@apache.org> wrote:
>
>> On Monday, October 24, 2011 11:10:34 PM Gert Vanthienen wrote:
>> > LS,
>> >
>> > Reading back on this thread, I see a few suggestions that we might want
>> to
>> > consider translating into JIRA issues that we can fix in a next version
>> of
>> > Karaf.
>> >
>> > 1. Improve the features Maven plugin to be aware of feature versions
>> while
>> > filling the features repository (a suggested by Dan Kulp)
>> > 2. Improve the features descriptor to allow specifying a requirement
>> (other
>> > descriptor) with a version range and only install an additional features
>> url
>> > if the requirement is not met (to avoid installing more than one version
>> of
>> > the same descriptor)
>>
>> +1.   Honestly, I'd like to see that on bundles as well:
>>
>> <bundle>mvn:org.apache.ws.security/wss4j/[1.6,1.7)</bundle>
>>
>> Useful when not using the OBR.
>>
>>
> Absolutely - we do want to make sure it can do that without requiring full
> Maven resolution with metadata and things like that, as that information is
> currently not available in the system folder.  Perhaps an implementation
> that looks in the system folder for a bundle matching this requirement and
> then falls back to e.g. the 1.6 version when there's no bundle there?
>
>
>>
>> > 3. Allow the features service to resolve all boot features with a single
>> obr
>> > in-memory repository to ensure picking up the latest and greatest from
>> the
>> > available bundles
>>
>> #3, while interesting, leads to a bunch of other issues that would require
>> a
>> lot more testing and likely a lot of changes to the other project
>> features.xml
>> files.   I was chatting with gnodet about this the other day as well.
>> The
>> OBR stuff really only considers imports and dependencies that are not
>> marked
>> optional.   Thus, with something like CXF that has a bunch of things that
>> are
>> optional, if you use the OBR, a lot of things that used to work would no
>> longer work.
>>
>
> There's an option available for the org.apache.karaf.features.obr PID that
> allows the OBR resolver to take optional imports into account as well and
> try to resolve as many of those as possible, this has been implemented to
> allow using the OBR resolver in e.g. ServiceMix where we were bumping into
> similar issues with optional imports as the ones you're looking at with CXF
> probably.
>
>
>>
>> It might be good if the OBR resolver was able to look at the locally
>> available
>> bundles to resolve the imports as well.   Doesn't need to go out to the
>> internet and such, but at least check what has been pre-installed into the
>> system dir.
>>
>
> Yeah, that's why I suggested to do it for the boot features as a whole - a
> lot of those bundles, in a typical scenario, will already be sitting in the
> local system folder anyway and if they're not there, the boot features
> installation would be downloading them anyway so there's not much overhead
> there in just doing the OBR resolution on those bundles as a whole instead
> of by feature (as it is implemented now).
>
>
>>
>> Dan
>>
>>
>> >
>> > #1 looks very reasonable to me, so I'll raise that his in the morning.
>>  How
>> > about the other two?  Any other suggestions to fix some of the problems
>> > mentioned in this thread?
>> >
>> > Regards,
>> >
>> > Gert
>> > On Oct 19, 2011 6:11 PM, "Johan Edstrom" <seijoed@gmail.com> wrote:
>> --
>> Daniel Kulp
>> dkulp@apache.org
>> http://dankulp.com/blog
>> Talend - http://www.talend.com
>>
>
> Regards,
>
> Gert
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message