On Tuesday, October 25, 2011 12:11:57 AM Gert Vanthienen wrote: > Reply versus reply all seems to become a difficult thing for my mind at this > time of the day ;)
LOL.... inline.... > >> > 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?> At that point, if there is a mvn URL, could it resolve it via the mvn mechanisms? AKA, get the mavenmetadata.xml and look for the latest? Another option may be something like: <bundle range="[1.6,1.7)">mvn:org.apache.ws.security/wss4j/1.6.2</bundle> Where we specify an exact version, but provide an optional range that we would find "acceptable". This may be slightly more backwords compatible too if the current versions ignore unknown attributes. (I'm really not sure) > >> > 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. Well, I think there needs to be something in between. If you resolve ALL the optionals, it will definitely take a lot longer and likely grab a LOT more bundles. Especially if you have a full OBR there. CXF would pull in all kinds of stuff like eclipse stuff and sdo and jibx and all kinds of stuff that wouldn't be there if not using an OBR. It's basically "resolve the optionals for which we have the jars already there". If not already there, don't bother. Dan > >> 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 -- Daniel Kulp [email protected] http://dankulp.com/blog Talend - http://www.talend.com
