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 <[email protected] > wrote: > > On Mon, Oct 24, 2011 at 11:19 PM, Daniel Kulp <[email protected]> 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" <[email protected]> wrote: >> -- >> Daniel Kulp >> [email protected] >> http://dankulp.com/blog >> Talend - http://www.talend.com >> > > Regards, > > Gert > >
