Re: [ovirt-devel] commons-collections v4.0
----_com.android.email_1462209507407830 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 T24gdGhlIG90aGVyIGhhbmQsIGNoYW5naW5nIGEgamFyIGluIHRoZSBydW50aW1lIGVudmlyb25t ZW50IHdpdGhvdXQgY29tcGlsaW5nIGFuZCBydW5uaW5nIHRlc3Qgd2l0aCB0aGUgbmV3IGphciBj b3VsZCBsZWFkIGFuIGFwcGxpY2F0aW9uIHRvIHN0b3AgZnVuY3Rpb25pbmcgaW4gYSBjdXN0b21l ciBlbnZpcm9ubWVudC4KQWxzbyBub3QgZXZlcnkgYnVnIGZvdW5kIGluIGEgZGVwZW5kZW5jeSBq YXIgd291bGQgY2F1c2UgYSBwcm9ibGVtIGluIHRoZSBhcHBsaWNhdGlvbi4gKEFuIGFwcGxpY2F0 aW9uIG1pZ2h0IG5vdCB1c2UgdGhlIHByb2JsZW1hdGljIHBhcnQgb2YgdGhlIGRlcGVuZGVuY3ku KQpJJ2QgYmV0dGVyIHRydXN0IHRoZSB0ZXN0IHN1aXRlIChhdXRvbWF0aWMgYW5kIG1hbnVhbCkg dGhhdCB3ZSBydW4gb24gdGhlIGNvbXBpbGVkIGFwcGxpY2F0aW9uIHdpdGggYWxsIHRoZSBkZXBl bmRlbmNpZXMgdGhhdCB0aGUgZGV2ZWxvcGVycyBjaG9vc2UgYXQgdGhlIGRldmVsb3BtZW50IHRp bWUgYW5kIHRoZW4gZGVsaXZlciB0aGF0ICh3aXRoIGl0cyBkZXBlbmRlbmNpZXMgYXMgYSBzaW5n bGUgcGFja2FnZSkgdG8gdGhlIGN1c3RvbWVycy4KRXZlcnkgYnVnIGluIGEgZGVwZW5kZW5jeSBz aG91bGQgYmUgZXZhbHVhdGVkIHdpdGhpbiB0aGUgZ2l2ZW4gYXBwbGljYXRpb24gc2NvcGUgYW5k IG9ubHkgaWYgcHJvdmVuIGFzIHRoZSBnaXZlbiBhcHBsaWNhdGlvbiBwcm9ibGVtIG9ubHkgdGhl biB0aGUgYXBwbGljYXRpb24gc2hvdWxkIGJlIHJlbGVhc2VkLgoKClNlbnQgZnJvbSBTYW1zdW5n IE1vYmlsZQoKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQpGcm9tOiBBbG9uIEJh ci1MZXYgPGFsb25ibEByZWRoYXQuY29tPiAKRGF0ZTogMDcvMDUvMjAxNCAgMjE6NDEgIChHTVQr MDI6MDApIApUbzogTWlrZSBLb2xlc25payA8bWtvbGVzbmlAcmVkaGF0LmNvbT4gCkNjOiBZZXZn ZW55IFphc3BpdHNreSA8eXphc3BpdHNAcmVkaGF0LmNvbT4sZGV2ZWxAb3ZpcnQub3JnIApTdWJq ZWN0OiBSZTogW292aXJ0LWRldmVsXSBjb21tb25zLWNvbGxlY3Rpb25zIHY0LjAgCiAKCgotLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gRnJvbTogIk1pa2UgS29sZXNuaWsiIDxta29sZXNu aUByZWRoYXQuY29tPgo+IFRvOiAiQWxvbiBCYXItTGV2IiA8YWxvbmJsQHJlZGhhdC5jb20+Cj4g Q2M6ICJZZXZnZW55IFphc3BpdHNreSIgPHl6YXNwaXRzQHJlZGhhdC5jb20+LCBkZXZlbEBvdmly dC5vcmcKPiBTZW50OiBXZWRuZXNkYXksIE1heSA3LCAyMDE0IDk6MzQ6MDMgUE0KPiBTdWJqZWN0 OiBSZTogW292aXJ0LWRldmVsXSBjb21tb25zLWNvbGxlY3Rpb25zIHY0LjAKPiAKPiAtLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gPiAKPiA+IAo+ID4gLS0tLS0gT3JpZ2luYWwgTWVzc2Fn ZSAtLS0tLQo+ID4gPiBGcm9tOiAiWWV2Z2VueSBaYXNwaXRza3kiIDx5emFzcGl0c0ByZWRoYXQu Y29tPgo+ID4gPiBUbzogIkFsb24gQmFyLUxldiIgPGFsb25ibEByZWRoYXQuY29tPgo+ID4gPiBD YzogZGV2ZWxAb3ZpcnQub3JnCj4gPiA+IFNlbnQ6IFR1ZXNkYXksIEFwcmlsIDIyLCAyMDE0IDEx OjM5OjExIEFNCj4gPiA+IFN1YmplY3Q6IFJlOiBbb3ZpcnQtZGV2ZWxdIGNvbW1vbnMtY29sbGVj dGlvbnMgdjQuMAo+ID4gPiAKPiA+ID4gVGhhdCBtZWFucyB0aGF0IHdlIG1hbmFnZSAyIHNlcGFy YXRlIGVudmlyb25tZW50czoKPiA+ID4gMS4gRGV2ZWxvcG1lbnQgLSByZWxpZXMgb24gcG9tIGZp bGVzLiBFLmcuIHVuaXQgdGVzdHMgcnVuIHdpdGgKPiA+ID4gY29tbW9ucy1jb2xsZWN0aW9ucyB2 My4xIChhbmQgd2hlbiBJIGFkZCB2NC4wKSBhbmQgc3VjY2VlZC4KPiA+IAo+ID4gZGV2ZW52IHdp bGwgdXNlIHJ1bnRpbWUgb3B0aW9uLgo+ID4geW91IGFyZSByaWdodCBhYm91dCB0aGUgdW5pdCB0 ZXN0cywgdGhlc2UgcmVsYXlzIG9uIHRoZSBwb21zLgo+IAo+IEkgdXNlIGRldmVudiBhbmQgaXQg YWx3YXlzIHVzZXMgdGhlIGRldiBvcHRpb24gbm90IHRoZSBydW50aW1lLgo+IFNvIGJhc2ljYWxs eSBkZXZlbG9wZXJzIGFyZSB1c2luZyB0aGUgcG9tIHNwZWNpZmllZCB2ZXJzaW9ucyBhbmQgbm90 IHdoYXQKPiB1c2VkIGluIHJ1bnRpbWUuCj4gCj4gRXZlbiBtb3JlIHNvLCBpbiBydW50aW1lIGl0 IGhpZ2hseSBkZXBlbmRzIG9uIHdoYXQgT1MgeW91J3JlIHVzaW5nLCBzbwo+IHNvbWVvbmUKPiBk ZXZlbG9waW5nIG9uIEYxOSBtaWdodCBub3QgYmUgdXNpbmcgc2FtZSB2ZXJzaW9ucyBhcyBhIGRl dmVsb3BlciBvbiBGMjAgYW5kCj4gYm90aCBhcmUgcHJvYmFibHkgdmVyeSBkaWZmZXJlbnQgdmVy c2lvbnMgdGhhbiBvbiBSSEVML0NlbnRPUy4KPiBJIHdvbid0IGV2ZW4gbWVudGlvbiBvdGhlciBP U2BzLgo+IAo+ID4gCj4gPiA+IDIuIFJ1bi10aW1lIC0gcmVsaWVzIG9uIEpCb3NzIG93biBkZXBl bmRlbmNpZXMgdGhhdCBicmluZwo+ID4gPiBjb21tb25zLWNvbGxlY3Rpb24KPiA+ID4gdjMuMi4x LXJlZGhhdC0yLgo+ID4gCj4gPiBpbiByaGVsIGNhc2UsIHllcy4KPiA+IAo+ID4gPiBUaGlzIGtp bmQgb2YgZGlzY3JlcGFuY2llcyBtaWdodCBiZSBmb3VuZCBpbiBvdGhlciBsaWJyYXJpZXMgYXMg d2UgZG8gbm90Cj4gPiA+IHN5bmNocm9uaXplIG91ciBwb20gZmlsZXMgd2l0aCB0aGUgSkJvc3Mg Y3VycmVudCB2ZXJzaW9uIGRlcGVuZGVuY2llcy4KPiA+ID4gSU1ITyB0aGF0IGNvdWxkIGxlYWQg dG8gc29tZSB2ZXJ5IGRpZmZpY3VsdCBidWdzIHRoYXQgd2Ugd29uJ3QgYmUgYWJsZSB0bwo+ID4g PiBzaW11bGF0ZSBpbiBvdXIgdW5pdCB0ZXN0cy4KPiA+IAo+ID4gY29ycmVjdCwgYnV0IHRoZSBq YXZhIHdheSB0byBwdWxsIGRlcGVuZGVuY2llcyBhdCB3aWxsIHdpdGhvdXQgYmVpbmcgYWJsZQo+ ID4gdG8KPiA+IGZpeCB6LXN0cmVhbSB1c2luZyBjZW50cmFsIHBhY2thZ2UgbWFuYWdlbWVudCB0 b29scyBpcyBtb3JlIHNldmVyZSB0aGFuCj4gPiB1bml0Cj4gPiB0ZXN0cyBub3Qgd29ya2luZy9u b3Qgd29ya2luZy4KPiA+IAo+ID4gZm9yIGV4YW1wbGUsIHlvdXIgYXBwbGljYXRpb24gdXNlcyB4 LmphciBhbmQgYWN0dWFsbHkgZGVsaXZlcnMgeC5qYXIuLi4gc28KPiA+IGZyb20gcmVsZWFzZSB0 byBldGVybml0eSBpdCBpcyB5b3VyIHJlc3BvbnNpYmlsaXR5IHRvIHRyYWNrIHguamFyIGZvcgo+ ID4gc2V2ZXJlCj4gPiBzdGFiaWxpdHkgYnVncyBhbmQgc2VjdXJpdHkgYnVncywgYW5kIHJlbGVh c2UgeW91ciBlbnRpcmUgYXBwbGljYXRpb24gZWFjaAo+ID4gdGltZSBmb3VuZCwgbm93IG11bHRp cGxlIGl0IHdpdGggdGhlICMgb2YgY29tcG9uZW50cyBhcHBsaWNhdGlvbiBpcyB1c2luZwo+ID4g YW5kIHNlZSBob3cgbXVjaCBlZmZvcnQgeW91IGhhdmUganVzdCB0byBtYWludGFpbiBzdGFiaWxp dHkgYW5kIHNlY3VyaXR5IGlmCj4gPiB5b3UgZW1iZWQgM3JkIHBhcnR5IGNvbXBvbmVudHMgd2l0 aG91dCB5b3VyIGFwcGxpY2F0aW9uLgo+IAo+IFllcywgaWYgeW91IHVzZSBwYWNrYWdlIFggdGhl biB5b3UncmUgdXNpbmcgdGhhdCBzcGVjaWZpYyB2ZXJzaW9uIHdpdGggaXQncwo+IGJlaGF2aW91 ciBhbmQgQVBJLCB0aGlzIGlzIHdoeSBkZXBlbmRlbmNpZXMgYXJlbid0IHVwZGF0ZWQgbGlnaHQg aGVhZGVkbHkgYnV0Cj4gd2l0aCB0ZXN0aW5nIHRvIHNlZSB0aGF0IG5vdGhpbmcgYnJva2UgKHNp bmNlIHN0dWZmIGRvZXMgYnJlYWssIGV2ZW4gaW4gbWlub3IKPiB2ZXJzaW9uLCBhcyB3ZSBsZWF2 ZSBpbiBhIG5vdCBzbyBwZXJmZWN0IHdvcmxkKS4KPiAKPiA+IAo+ID4gPiBXaHkgZG8gd2UgYXZv aWQgInRvIG1haW50YWluIG91ciBvd24gcGFja2FnaW5nIj8gSU1ITyBPdmlydCBvd24KPiA+ID4g ZGVwZW5kZW5jaWVzCj4gPiA+IGNvdWxkIGJlIHBhY2tlZCBpbiB0aGUgd2FyLCBjYW4ndCB0aGV5 Pwo+ID4gCj4gPiB5ZXMgdGhleSBjb3VsZCwgYnV0IHRoaXMgaXMgbm90IHN1aXRhYmxlIGZvciBl bnRlcnByaXNlIGdyYWRlCj4gPiBpbXBsZW1lbnRhdGlvbnMsIG1haW5seSBwZXIgd2hhdCBJIGRl c2NyaWJlZCBhYm92ZS4KPiAKPiBTb3JyeSBidXQgQUZBSUsgZW50ZXJwcmlzZSBncmFkZSBzb2Z0 d2FyZSByZWxlYXNlIGZpeGVzIGZvciB0aGVpciBzb2Z0d2FyZQo+IG9uIGEgdGltZWx5IGJhc2lz IGFuZCBoYXZlIHByb2Nlc3NlcyBpbiBwbGFjZSB0byBtYW5hZ2UgdXBncmFkZXMgb2YKPiBmdW5j dGlvbmFsaXR5Lgo+IAo+IFdoYXQgY3VycmVudGx5IGlzIGRvbmUgaXMgcmVseWluZyBvbiBjb3Vy dGVzeSBvZiBvdGhlciBwZW9wbGUgdG8gcmVsZWFzZSBhCj4gImZpeCIgdGhhdCBhbHJlYWR5IGV4 aXN0cyBhIGxvbmcgdGltZS4KPiBBbmQgb2YgY291cnNlLCBhcyBJIG1lbnRpb25lZCwgdGhlIGFw cGxpY2F0aW9uIG5lZWRzIHRvIGJlIHRlc3RlZCB3aXRoIHRoZQo+IHVwZGF0ZWQgbGlicmFyeS4K PiBJTU8gbmVnbGVjdGluZyB0aGlzIGFuZCBsZWF2aW5nIHRoaXMgb3V0IG9mIGJhbmQgZm9yICJl bnRlcnByaXNlIGdyYWRlIgo+IHNvZnR3YXJlIGlzIG11Y2ggd29yc2UgdGhhbiBhY3R1YWxseSB0 ZXN0aW5nIHRvIHNlZSB0aGF0IGl0IGlzIHdvcmtpbmcgYW5kCj4ganVzdCBsZWF2aW5nIGl0IGFs bCB0byBjaGFuY2UuCgrigI5XZWxsLCB0YWtlIHRoZSByZWNlbnQgZXhhbXBsZSBvZiBvcGVuc3Ns IGlzc3VlIHRoYXQgd2FzIGZvdW5kLgpOb3csIGltYWdpbmUgdGhhdCBhbGwgcHJvZHVjdHMgdGhh dCB1c2Ugb3BlbnNzbCBzaG91bGQgaGF2ZSBiZWVuIHJlLXJlbGVhc2VkLgpJIHRoaW5rIHRoaXMg aXMgZW5vdWdoIHRvIHVuZGVyc3RhbmQgaG93IHdyb25nIHRoaXMgaXMuCgo+IAo+ID4gCj4gPiBS ZWdhcmRzLAo+ID4gQWxvbgo+ID4gCj4gPiA+IEJlc3QgcmVnYXJkcywKPiA+ID4gX19fX19fX19f X19fX19fX19fX18KPiA+ID4gWWV2Z2VueSBaYXNwaXRza3kKPiA+ID4gU2VuaW9yIFNvZnR3YXJl IEVuZ2luZWVyCj4gPiA+IFJlZCBIYXQgSXNyYWVsCj4gPiA+IAo+ID4gPiAKPiA+ID4gLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo+ID4gPiBGcm9tOiAiQWxvbiBCYXItTGV2IiA8YWxvbmJs QHJlZGhhdC5jb20+Cj4gPiA+IFRvOiAiWWV2Z2VueSBaYXNwaXRza3kiIDx5emFzcGl0c0ByZWRo YXQuY29tPgo+ID4gPiBDYzogZGV2ZWxAb3ZpcnQub3JnCj4gPiA+IFNlbnQ6IFN1bmRheSwgQXBy aWwgMTMsIDIwMTQgNzoyMjoxOCBQTQo+ID4gPiBTdWJqZWN0OiBSZTogW292aXJ0LWRldmVsXSBj b21tb25zLWNvbGxlY3Rpb25zIHY0LjAKPiA+ID4gCj4gPiA+IAo+ID4gPiAKPiA+ID4gLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo+ID4gPiA+IEZyb206ICJZZXZnZW55IFphc3BpdHNreSIg PHl6YXNwaXRzQHJlZGhhdC5jb20+Cj4gPiA+ID4gVG86IGRldmVsQG92aXJ0Lm9yZwo+ID4gPiA+ IFNlbnQ6IFN1bmRheSwgQXByaWwgMTMsIDIwMTQgNzoxMzoxMCBQTQo+ID4gPiA+IFN1YmplY3Q6 IFtvdmlydC1kZXZlbF0gY29tbW9ucy1jb2xsZWN0aW9ucyB2NC4wCj4gPiA+ID4gCj4gPiA+ID4g SGkgQWxsLAo+ID4gPiA+IAo+ID4gPiA+IEknZCBsaWtlIHRvIGFkZCB0aGUgbmV3IHZlcnNpb24g KDQuMCkgb2YgQXBhY2hlIGNvbW1vbnMtY29sbGVjdGlvbnMKPiA+ID4gPiBsaWJyYXJ5Cj4gPiA+ ID4gdG8gdGhlIGRlcGVuZGVuY2llcyBvZiB0aGUgcHJvamVjdCAod2UgdXNlIDMuMSBjdXJyZW50 bHkpLgo+ID4gPiA+IFRoZSBuZXcgdmVyc2lvbiB1c2VzIHRoZSBnZW5lcmljcyBmZWF0dXJlcyBv ZiBKYXZhIDUgc28gdGhhdCBtYWtlIHRoZQo+ID4gPiA+IGNvZGUKPiA+ID4gPiBtb3JlIHR5cGUg c2FmZS4gWW91IGNhbiBmaW5kIHRoZSBmdWxsIGxpc3Qgb2YgY2hhbmdlcyBvbgo+ID4gPiA+IGh0 dHBzOi8vY29tbW9ucy5hcGFjaGUub3JnL3Byb3Blci9jb21tb25zLWNvbGxlY3Rpb25zL3JlbGVh c2VfNF8wLmh0bWwuCj4gPiA+ID4gVGhlIG5ldyBBUEkgaXMgYmFzZWQgb24gdGhlIG9yaWdpbmFs IGJ1dCBpdCBpc24ndCBmdWxseSBjb21wYXRpYmxlIHdpdGgKPiA+ID4gPiBpdC4KPiA+ID4gPiBT byBpbiBvcmRlciB0byBtYWtlIHRoZSBtaWdyYXRpb24gdG8gdGhlIG5ldyBBUEkgZWFzaWVyLCB0 aGUgcGFja2FnZQo+ID4gPiA+IGhhcwo+ID4gPiA+IGJlZW4gY2hhbmdlZCB0byBvcmcuYXBhY2hl LmNvbW1vbnMuY29sbGVjdGlvbnM0LiBUaGF0IGFsbG93cyBoYXZpbmcKPiA+ID4gPiBib3RoCj4g PiA+ID4gdmVyc2lvbiBvZiB0aGUgbGlicmFyeSBpbiB0aGUgY2xhc3NwYXRoIGF0IHRoZSBzdGFy dGluZyBwb2ludCBhbmQgbW92ZQo+ID4gPiA+IChyZWZhY3RvcikgdG93YXJkcyB0aGUgbmV3IHZl cnNpb24gZ3JhZHVhbGx5Lgo+ID4gPiA+IAo+ID4gPiA+IEkgaGF2ZSBjb3VwbGUgb2YgcXVlc3Rp b25zIHJlZ2FyZGluZyB0aGUgbmV3IGRlcGVuZGVuY3k6Cj4gPiA+ID4gMS4gSXMgdGhlcmUgYW55 dGhpbmcgdGhhdCBjb3VsZCBwcmV2ZW50IGFkZGluZyB0aGUgbmV3IGRlcGVuZGVuY3k/Cj4gPiA+ IAo+ID4gPiBXZSB0cnkgdG8gYXZvaWQgaW50cm9kdWNpbmcgb3VyIG93biBkZXBlbmRlbmNpZXMs IGluIHRoaXMgY2FzZSB3ZSB1c2UKPiA+ID4gd2hhdGV2ZXIgamJvc3MgcHJvdmlkZXMgd2hpY2gg aXMgdmVyeSBjb21mb3J0YWJsZSBhcyB3ZSBkbyBub3QgbmVlZCB0bwo+ID4gPiBtYWludGFpbiBv dXIgb3duIHBhY2thZ2luZy4KPiA+ID4gCj4gPiA+IEN1cnJlbnRseSB0aGUgamJlYXAgZG9lcyBu b3QgcHJvdmlkZSA0LjAsIGl0IGRvZXMgc3VwcG9ydCAzLjIuMS1yZWRoYXQtMiwKPiA+ID4gc28K PiA+ID4gYmV0dGVyIHRvIGF2b2lkIHRoaXMgdW50aWwgd2Ugc3dpdGNoIHRvIG1vcmUgcmVjZW50 IHZlcnNpb24gb2YgamJvc3MuCj4gPiA+IAo+ID4gPiBBbHRlcm5hdGl2ZWx5IHdlIGNvdWxkIGVu am95IHN0YW5kYWxvbmUgcnBtIHdpdGhpbiByaGVsL2NlbnRvcyBpZgo+ID4gPiBhdmFpbGFibGUs Cj4gPiA+IGhvd2V2ZXIgbm9uIGV4aXN0Lgo+ID4gPiAKPiA+ID4gPiAyLiBJIGRpZCB0aGUgY2hh bmdlIChodHRwOi8vZ2Vycml0Lm92aXJ0Lm9yZy8yNjc0NSkuCj4gPiA+ID7CoMKgwqAgVGhlIHVu aXQgdGVzdHMgdGhhdCB1c2UgdGhlIG5ldyBkZXBlbmRlbmN5IHBhc3MgbG9jYWxseSBhbmQgaW4K PiA+ID4gPsKgwqDCoCBKZW5raW5zCj4gPiA+ID7CoMKgwqAgZW52aXJvbm1lbnRzLgo+ID4gPiA+ wqDCoMKgIEhvd2V2ZXIgd2hlbiBJIHRyeSB0byBydW4gYSBjb2RlIHRoYXQgaXMgZGVwZW5kZW50 IG9uIHRoZSBuZXdseQo+ID4gPiA+wqDCoMKgIGFkZGVkCj4gPiA+ID7CoMKgwqAgbGlicmFyeSBO b0NsYXNzRGVmRm91bmRFcnJvciBiZWluZyB0aHJvd24uCj4gPiA+ID7CoMKgwqAgQWxzbyBJIGNh bid0IGZpbmQgY29tbW9ucy1jb2xsZWN0aW9uczQgamFyIHVuZGVyIHRoZSBpbnN0YWxsYXRpb24K PiA+ID4gPsKgwqDCoCBkaXJlY3RvcnkuIEkgdXNlICJtYWtlIGNsZWFuIGluc3RhbGwtZGV2IiBj b21tYW5kIGZvciBidWlsZGluZy4KPiA+ID4gPiAKPiA+ID4gPiBQbGVhc2UgYWR2aXNlLgo+ID4g Cj4gCg== ----_com.android.email_1462209507407830 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5PbiB0aGUgb3RoZXIgaGFu ZCwgY2hhbmdpbmcgYSBqYXIgaW4gdGhlIHJ1bnRpbWUgZW52aXJvbm1lbnQgd2l0aG91dCBjb21w aWxpbmcgYW5kIHJ1bm5pbmcgdGVzdCB3aXRoIHRoZSBuZXcgamFyIGNvdWxkIGxlYWQgYW4gYXBw bGljYXRpb24gdG8gc3RvcCBmdW5jdGlvbmluZyBpbiBhIGN1c3RvbWVyIGVudmlyb25tZW50Ljwv ZGl2PjxkaXY+QWxzbyBub3QgZXZlcnkgYnVnIGZvdW5kIGluIGEgZGVwZW5kZW5jeSBqYXIgd291 bGQgY2F1c2UgYSBwcm9ibGVtIGluIHRoZSBhcHBsaWNhdGlvbi4gKEFuIGFwcGxpY2F0aW9uIG1p Z2h0IG5vdCB1c2UgdGhlIHByb2JsZW1hdGljIHBhcnQgb2YgdGhlIGRlcGVuZGVuY3kuKTwvZGl2 PjxkaXY+SSdkIGJldHRlciB0cnVzdCB0aGUgdGVzdCBzdWl0ZSAoYXV0b21hdGljIGFuZCBtYW51 YWwpIHRoYXQgd2UgcnVuIG9uIHRoZSBjb21waWxlZCBhcHBsaWNhdGlvbiB3aXRoIGFsbCB0aGUg ZGVwZW5kZW5jaWVzIHRoYXQgdGhlIGRldmVsb3BlcnMgY2hvb3NlIGF0IHRoZSBkZXZlbG9wbWVu dCB0aW1lIGFuZCB0aGVuIGRlbGl2ZXIgdGhhdCAod2l0aCBpdHMgZGVwZW5kZW5jaWVzIGFzIGEg c2luZ2xlIHBhY2thZ2UpIHRvIHRoZSBjdXN0b21lcnMuPC9kaXY+PGRpdj5FdmVyeSBidWcgaW4g YSBkZXBlbmRlbmN5IHNob3VsZCBiZSBldmFsdWF0ZWQgd2l0aGluIHRoZSBnaXZlbiBhcHBsaWNh dGlvbiBzY29wZSBhbmQgb25seSBpZiBwcm92ZW4gYXMgdGhlIGdpdmVuIGFwcGxpY2F0aW9uIHBy b2JsZW0gb25seSB0aGVuIHRoZSBhcHBsaWNhdGlvbiBzaG91bGQgYmUgcmVsZWFzZWQuPC9kaXY+ PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6 NzUlO2NvbG9yOiM1NzU3NTciPlNlbnQgZnJvbSBTYW1zdW5nIE1vYmlsZTwvZGl2PjwvZGl2Pjxi cj48YnI+PGJyPi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08YnI+RnJvbTogQWxv biBCYXItTGV2ICZsdDthbG9uYmxAcmVkaGF0LmNvbSZndDsgPGJyPkRhdGU6IDA3LzA1LzIwMTQg IDIxOjQxICAoR01UKzAyOjAwKSA8YnI+VG86IE1pa2UgS29sZXNuaWsgJmx0O21rb2xlc25pQHJl ZGhhdC5jb20mZ3Q7IDxicj5DYzogWWV2Z2VueSBaYXNwaXRza3kgJmx0O3l6YXNwaXRzQHJlZGhh dC5jb20mZ3Q7LGRldmVsQG92aXJ0Lm9yZyA8YnI+U3ViamVjdDogUmU6IFtvdmlydC1kZXZlbF0g Y29tbW9ucy1jb2xsZWN0aW9ucyB2NC4wIDxicj4gPGJyPjxicj48YnI+PGJyPi0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgLS0tLS08YnI+Jmd0OyBGcm9tOiAiTWlrZSBLb2xlc25payIgJmx0O21rb2xl c25pQHJlZGhhdC5jb20mZ3Q7PGJyPiZndDsgVG86ICJBbG9uIEJhci1MZXYiICZsdDthbG9uYmxA cmVkaGF0LmNvbSZndDs8YnI+Jmd0OyBDYzogIllldmdlbnkgWmFzcGl0c2t5IiAmbHQ7eXphc3Bp dHNAcmVkaGF0LmNvbSZndDssIGRldmVsQG92aXJ0Lm9yZzxicj4mZ3Q7IFNlbnQ6IFdlZG5lc2Rh eSwgTWF5IDcsIDIwMTQgOTozNDowMyBQTTxicj4mZ3Q7IFN1YmplY3Q6IFJlOiBbb3ZpcnQtZGV2 ZWxdIGNvbW1vbnMtY29sbGVjdGlvbnMgdjQuMDxicj4mZ3Q7IDxicj4mZ3Q7IC0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgLS0tLS08YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0 OyAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPGJyPiZndDsgJmd0OyAmZ3Q7IEZyb206ICJZ ZXZnZW55IFphc3BpdHNreSIgJmx0O3l6YXNwaXRzQHJlZGhhdC5jb20mZ3Q7PGJyPiZndDsgJmd0 OyAmZ3Q7IFRvOiAiQWxvbiBCYXItTGV2IiAmbHQ7YWxvbmJsQHJlZGhhdC5jb20mZ3Q7PGJyPiZn dDsgJmd0OyAmZ3Q7IENjOiBkZXZlbEBvdmlydC5vcmc8YnI+Jmd0OyAmZ3Q7ICZndDsgU2VudDog VHVlc2RheSwgQXByaWwgMjIsIDIwMTQgMTE6Mzk6MTEgQU08YnI+Jmd0OyAmZ3Q7ICZndDsgU3Vi amVjdDogUmU6IFtvdmlydC1kZXZlbF0gY29tbW9ucy1jb2xsZWN0aW9ucyB2NC4wPGJyPiZndDsg Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyBUaGF0IG1lYW5zIHRoYXQgd2UgbWFuYWdlIDIg c2VwYXJhdGUgZW52aXJvbm1lbnRzOjxicj4mZ3Q7ICZndDsgJmd0OyAxLiBEZXZlbG9wbWVudCAt IHJlbGllcyBvbiBwb20gZmlsZXMuIEUuZy4gdW5pdCB0ZXN0cyBydW4gd2l0aDxicj4mZ3Q7ICZn dDsgJmd0OyBjb21tb25zLWNvbGxlY3Rpb25zIHYzLjEgKGFuZCB3aGVuIEkgYWRkIHY0LjApIGFu ZCBzdWNjZWVkLjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBkZXZlbnYgd2lsbCB1c2UgcnVu dGltZSBvcHRpb24uPGJyPiZndDsgJmd0OyB5b3UgYXJlIHJpZ2h0IGFib3V0IHRoZSB1bml0IHRl c3RzLCB0aGVzZSByZWxheXMgb24gdGhlIHBvbXMuPGJyPiZndDsgPGJyPiZndDsgSSB1c2UgZGV2 ZW52IGFuZCBpdCBhbHdheXMgdXNlcyB0aGUgZGV2IG9wdGlvbiBub3QgdGhlIHJ1bnRpbWUuPGJy PiZndDsgU28gYmFzaWNhbGx5IGRldmVsb3BlcnMgYXJlIHVzaW5nIHRoZSBwb20gc3BlY2lmaWVk IHZlcnNpb25zIGFuZCBub3Qgd2hhdDxicj4mZ3Q7IHVzZWQgaW4gcnVudGltZS48YnI+Jmd0OyA8 YnI+Jmd0OyBFdmVuIG1vcmUgc28sIGluIHJ1bnRpbWUgaXQgaGlnaGx5IGRlcGVuZHMgb24gd2hh dCBPUyB5b3UncmUgdXNpbmcsIHNvPGJyPiZndDsgc29tZW9uZTxicj4mZ3Q7IGRldmVsb3Bpbmcg b24gRjE5IG1pZ2h0IG5vdCBiZSB1c2luZyBzYW1lIHZlcnNpb25zIGFzIGEgZGV2ZWxvcGVyIG9u IEYyMCBhbmQ8YnI+Jmd0OyBib3RoIGFyZSBwcm9iYWJseSB2ZXJ5IGRpZmZlcmVudCB2ZXJzaW9u cyB0aGFuIG9uIFJIRUwvQ2VudE9TLjxicj4mZ3Q7IEkgd29uJ3QgZXZlbiBtZW50aW9uIG90aGVy IE9TYHMuPGJyPiZndDsgPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgMi4gUnVuLXRp bWUgLSByZWxpZXMgb24gSkJvc3Mgb3duIGRlcGVuZGVuY2llcyB0aGF0IGJyaW5nPGJyPiZndDsg Jmd0OyAmZ3Q7IGNvbW1vbnMtY29sbGVjdGlvbjxicj4mZ3Q7ICZndDsgJmd0OyB2My4yLjEtcmVk aGF0LTIuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IGluIHJoZWwgY2FzZSwgeWVzLjxicj4m Z3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IFRoaXMga2luZCBvZiBkaXNjcmVwYW5jaWVzIG1p Z2h0IGJlIGZvdW5kIGluIG90aGVyIGxpYnJhcmllcyBhcyB3ZSBkbyBub3Q8YnI+Jmd0OyAmZ3Q7 ICZndDsgc3luY2hyb25pemUgb3VyIHBvbSBmaWxlcyB3aXRoIHRoZSBKQm9zcyBjdXJyZW50IHZl cnNpb24gZGVwZW5kZW5jaWVzLjxicj4mZ3Q7ICZndDsgJmd0OyBJTUhPIHRoYXQgY291bGQgbGVh ZCB0byBzb21lIHZlcnkgZGlmZmljdWx0IGJ1Z3MgdGhhdCB3ZSB3b24ndCBiZSBhYmxlIHRvPGJy PiZndDsgJmd0OyAmZ3Q7IHNpbXVsYXRlIGluIG91ciB1bml0IHRlc3RzLjxicj4mZ3Q7ICZndDsg PGJyPiZndDsgJmd0OyBjb3JyZWN0LCBidXQgdGhlIGphdmEgd2F5IHRvIHB1bGwgZGVwZW5kZW5j aWVzIGF0IHdpbGwgd2l0aG91dCBiZWluZyBhYmxlPGJyPiZndDsgJmd0OyB0bzxicj4mZ3Q7ICZn dDsgZml4IHotc3RyZWFtIHVzaW5nIGNlbnRyYWwgcGFja2FnZSBtYW5hZ2VtZW50IHRvb2xzIGlz IG1vcmUgc2V2ZXJlIHRoYW48YnI+Jmd0OyAmZ3Q7IHVuaXQ8YnI+Jmd0OyAmZ3Q7IHRlc3RzIG5v dCB3b3JraW5nL25vdCB3b3JraW5nLjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBmb3IgZXhh bXBsZSwgeW91ciBhcHBsaWNhdGlvbiB1c2VzIHguamFyIGFuZCBhY3R1YWxseSBkZWxpdmVycyB4 Lmphci4uLiBzbzxicj4mZ3Q7ICZndDsgZnJvbSByZWxlYXNlIHRvIGV0ZXJuaXR5IGl0IGlzIHlv dXIgcmVzcG9uc2liaWxpdHkgdG8gdHJhY2sgeC5qYXIgZm9yPGJyPiZndDsgJmd0OyBzZXZlcmU8 YnI+Jmd0OyAmZ3Q7IHN0YWJpbGl0eSBidWdzIGFuZCBzZWN1cml0eSBidWdzLCBhbmQgcmVsZWFz ZSB5b3VyIGVudGlyZSBhcHBsaWNhdGlvbiBlYWNoPGJyPiZndDsgJmd0OyB0aW1lIGZvdW5kLCBu b3cgbXVsdGlwbGUgaXQgd2l0aCB0aGUgIyBvZiBjb21wb25lbnRzIGFwcGxpY2F0aW9uIGlzIHVz aW5nPGJyPiZndDsgJmd0OyBhbmQgc2VlIGhvdyBtdWNoIGVmZm9ydCB5b3UgaGF2ZSBqdXN0IHRv IG1haW50YWluIHN0YWJpbGl0eSBhbmQgc2VjdXJpdHkgaWY8YnI+Jmd0OyAmZ3Q7IHlvdSBlbWJl ZCAzcmQgcGFydHkgY29tcG9uZW50cyB3aXRob3V0IHlvdXIgYXBwbGljYXRpb24uPGJyPiZndDsg PGJyPiZndDsgWWVzLCBpZiB5b3UgdXNlIHBhY2thZ2UgWCB0aGVuIHlvdSdyZSB1c2luZyB0aGF0 IHNwZWNpZmljIHZlcnNpb24gd2l0aCBpdCdzPGJyPiZndDsgYmVoYXZpb3VyIGFuZCBBUEksIHRo aXMgaXMgd2h5IGRlcGVuZGVuY2llcyBhcmVuJ3QgdXBkYXRlZCBsaWdodCBoZWFkZWRseSBidXQ8 YnI+Jmd0OyB3aXRoIHRlc3RpbmcgdG8gc2VlIHRoYXQgbm90aGluZyBicm9rZSAoc2luY2Ugc3R1 ZmYgZG9lcyBicmVhaywgZXZlbiBpbiBtaW5vcjxicj4mZ3Q7IHZlcnNpb24sIGFzIHdlIGxlYXZl IGluIGEgbm90IHNvIHBlcmZlY3Qgd29ybGQpLjxicj4mZ3Q7IDxicj4mZ3Q7ICZndDsgPGJyPiZn dDsgJmd0OyAmZ3Q7IFdoeSBkbyB3ZSBhdm9pZCAidG8gbWFpbnRhaW4gb3VyIG93biBwYWNrYWdp bmciPyBJTUhPIE92aXJ0IG93bjxicj4mZ3Q7ICZndDsgJmd0OyBkZXBlbmRlbmNpZXM8YnI+Jmd0 OyAmZ3Q7ICZndDsgY291bGQgYmUgcGFja2VkIGluIHRoZSB3YXIsIGNhbid0IHRoZXk/PGJyPiZn dDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IHllcyB0aGV5IGNvdWxkLCBidXQgdGhpcyBpcyBub3Qgc3Vp dGFibGUgZm9yIGVudGVycHJpc2UgZ3JhZGU8YnI+Jmd0OyAmZ3Q7IGltcGxlbWVudGF0aW9ucywg bWFpbmx5IHBlciB3aGF0IEkgZGVzY3JpYmVkIGFib3ZlLjxicj4mZ3Q7IDxicj4mZ3Q7IFNvcnJ5 IGJ1dCBBRkFJSyBlbnRlcnByaXNlIGdyYWRlIHNvZnR3YXJlIHJlbGVhc2UgZml4ZXMgZm9yIHRo ZWlyIHNvZnR3YXJlPGJyPiZndDsgb24gYSB0aW1lbHkgYmFzaXMgYW5kIGhhdmUgcHJvY2Vzc2Vz IGluIHBsYWNlIHRvIG1hbmFnZSB1cGdyYWRlcyBvZjxicj4mZ3Q7IGZ1bmN0aW9uYWxpdHkuPGJy PiZndDsgPGJyPiZndDsgV2hhdCBjdXJyZW50bHkgaXMgZG9uZSBpcyByZWx5aW5nIG9uIGNvdXJ0 ZXN5IG9mIG90aGVyIHBlb3BsZSB0byByZWxlYXNlIGE8YnI+Jmd0OyAiZml4IiB0aGF0IGFscmVh ZHkgZXhpc3RzIGEgbG9uZyB0aW1lLjxicj4mZ3Q7IEFuZCBvZiBjb3Vyc2UsIGFzIEkgbWVudGlv bmVkLCB0aGUgYXBwbGljYXRpb24gbmVlZHMgdG8gYmUgdGVzdGVkIHdpdGggdGhlPGJyPiZndDsg dXBkYXRlZCBsaWJyYXJ5Ljxicj4mZ3Q7IElNTyBuZWdsZWN0aW5nIHRoaXMgYW5kIGxlYXZpbmcg dGhpcyBvdXQgb2YgYmFuZCBmb3IgImVudGVycHJpc2UgZ3JhZGUiPGJyPiZndDsgc29mdHdhcmUg aXMgbXVjaCB3b3JzZSB0aGFuIGFjdHVhbGx5IHRlc3RpbmcgdG8gc2VlIHRoYXQgaXQgaXMgd29y a2luZyBhbmQ8YnI+Jmd0OyBqdXN0IGxlYXZpbmcgaXQgYWxsIHRvIGNoYW5jZS48YnI+PGJyPuKA jldlbGwsIHRha2UgdGhlIHJlY2VudCBleGFtcGxlIG9mIG9wZW5zc2wgaXNzdWUgdGhhdCB3YXMg Zm91bmQuPGJyPk5vdywgaW1hZ2luZSB0aGF0IGFsbCBwcm9kdWN0cyB0aGF0IHVzZSBvcGVuc3Ns IHNob3VsZCBoYXZlIGJlZW4gcmUtcmVsZWFzZWQuPGJyPkkgdGhpbmsgdGhpcyBpcyBlbm91Z2gg dG8gdW5kZXJzdGFuZCBob3cgd3JvbmcgdGhpcyBpcy48YnI+PGJyPiZndDsgPGJyPiZndDsgJmd0 OyA8YnI+Jmd0OyAmZ3Q7IFJlZ2FyZHMsPGJyPiZndDsgJmd0OyBBbG9uPGJyPiZndDsgJmd0OyA8 YnI+Jmd0OyAmZ3Q7ICZndDsgQmVzdCByZWdhcmRzLDxicj4mZ3Q7ICZndDsgJmd0OyBfX19fX19f X19fX19fX19fX19fXzxicj4mZ3Q7ICZndDsgJmd0OyBZZXZnZW55IFphc3BpdHNreTxicj4mZ3Q7 ICZndDsgJmd0OyBTZW5pb3IgU29mdHdhcmUgRW5naW5lZXI8YnI+Jmd0OyAmZ3Q7ICZndDsgUmVk IEhhdCBJc3JhZWw8YnI+Jmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7 ICZndDsgJmd0OyAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPGJyPiZndDsgJmd0OyAmZ3Q7 IEZyb206ICJBbG9uIEJhci1MZXYiICZsdDthbG9uYmxAcmVkaGF0LmNvbSZndDs8YnI+Jmd0OyAm Z3Q7ICZndDsgVG86ICJZZXZnZW55IFphc3BpdHNreSIgJmx0O3l6YXNwaXRzQHJlZGhhdC5jb20m Z3Q7PGJyPiZndDsgJmd0OyAmZ3Q7IENjOiBkZXZlbEBvdmlydC5vcmc8YnI+Jmd0OyAmZ3Q7ICZn dDsgU2VudDogU3VuZGF5LCBBcHJpbCAxMywgMjAxNCA3OjIyOjE4IFBNPGJyPiZndDsgJmd0OyAm Z3Q7IFN1YmplY3Q6IFJlOiBbb3ZpcnQtZGV2ZWxdIGNvbW1vbnMtY29sbGVjdGlvbnMgdjQuMDxi cj4mZ3Q7ICZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IDxi cj4mZ3Q7ICZndDsgJmd0OyAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tPGJyPiZndDsgJmd0 OyAmZ3Q7ICZndDsgRnJvbTogIllldmdlbnkgWmFzcGl0c2t5IiAmbHQ7eXphc3BpdHNAcmVkaGF0 LmNvbSZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUbzogZGV2ZWxAb3ZpcnQub3JnPGJyPiZn dDsgJmd0OyAmZ3Q7ICZndDsgU2VudDogU3VuZGF5LCBBcHJpbCAxMywgMjAxNCA3OjEzOjEwIFBN PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgU3ViamVjdDogW292aXJ0LWRldmVsXSBjb21tb25zLWNv bGxlY3Rpb25zIHY0LjA8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OyBIaSBBbGwsPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7ICZn dDsgSSdkIGxpa2UgdG8gYWRkIHRoZSBuZXcgdmVyc2lvbiAoNC4wKSBvZiBBcGFjaGUgY29tbW9u cy1jb2xsZWN0aW9uczxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGxpYnJhcnk8YnI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyB0byB0aGUgZGVwZW5kZW5jaWVzIG9mIHRoZSBwcm9qZWN0ICh3ZSB1c2UgMy4x IGN1cnJlbnRseSkuPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgVGhlIG5ldyB2ZXJzaW9uIHVzZXMg dGhlIGdlbmVyaWNzIGZlYXR1cmVzIG9mIEphdmEgNSBzbyB0aGF0IG1ha2UgdGhlPGJyPiZndDsg Jmd0OyAmZ3Q7ICZndDsgY29kZTxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1vcmUgdHlwZSBzYWZl LiBZb3UgY2FuIGZpbmQgdGhlIGZ1bGwgbGlzdCBvZiBjaGFuZ2VzIG9uPGJyPiZndDsgJmd0OyAm Z3Q7ICZndDsgaHR0cHM6Ly9jb21tb25zLmFwYWNoZS5vcmcvcHJvcGVyL2NvbW1vbnMtY29sbGVj dGlvbnMvcmVsZWFzZV80XzAuaHRtbC48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGUgbmV3IEFQ SSBpcyBiYXNlZCBvbiB0aGUgb3JpZ2luYWwgYnV0IGl0IGlzbid0IGZ1bGx5IGNvbXBhdGlibGUg d2l0aDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGl0Ljxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IFNv IGluIG9yZGVyIHRvIG1ha2UgdGhlIG1pZ3JhdGlvbiB0byB0aGUgbmV3IEFQSSBlYXNpZXIsIHRo ZSBwYWNrYWdlPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgaGFzPGJyPiZndDsgJmd0OyAmZ3Q7ICZn dDsgYmVlbiBjaGFuZ2VkIHRvIG9yZy5hcGFjaGUuY29tbW9ucy5jb2xsZWN0aW9uczQuIFRoYXQg YWxsb3dzIGhhdmluZzxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IGJvdGg8YnI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyB2ZXJzaW9uIG9mIHRoZSBsaWJyYXJ5IGluIHRoZSBjbGFzc3BhdGggYXQgdGhlIHN0 YXJ0aW5nIHBvaW50IGFuZCBtb3ZlPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgKHJlZmFjdG9yKSB0 b3dhcmRzIHRoZSBuZXcgdmVyc2lvbiBncmFkdWFsbHkuPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsg PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgSSBoYXZlIGNvdXBsZSBvZiBxdWVzdGlvbnMgcmVnYXJk aW5nIHRoZSBuZXcgZGVwZW5kZW5jeTo8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAxLiBJcyB0aGVy ZSBhbnl0aGluZyB0aGF0IGNvdWxkIHByZXZlbnQgYWRkaW5nIHRoZSBuZXcgZGVwZW5kZW5jeT88 YnI+Jmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IFdlIHRyeSB0byBhdm9pZCBpbnRy b2R1Y2luZyBvdXIgb3duIGRlcGVuZGVuY2llcywgaW4gdGhpcyBjYXNlIHdlIHVzZTxicj4mZ3Q7 ICZndDsgJmd0OyB3aGF0ZXZlciBqYm9zcyBwcm92aWRlcyB3aGljaCBpcyB2ZXJ5IGNvbWZvcnRh YmxlIGFzIHdlIGRvIG5vdCBuZWVkIHRvPGJyPiZndDsgJmd0OyAmZ3Q7IG1haW50YWluIG91ciBv d24gcGFja2FnaW5nLjxicj4mZ3Q7ICZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgQ3VycmVu dGx5IHRoZSBqYmVhcCBkb2VzIG5vdCBwcm92aWRlIDQuMCwgaXQgZG9lcyBzdXBwb3J0IDMuMi4x LXJlZGhhdC0yLDxicj4mZ3Q7ICZndDsgJmd0OyBzbzxicj4mZ3Q7ICZndDsgJmd0OyBiZXR0ZXIg dG8gYXZvaWQgdGhpcyB1bnRpbCB3ZSBzd2l0Y2ggdG8gbW9yZSByZWNlbnQgdmVyc2lvbiBvZiBq Ym9zcy48YnI+Jmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IEFsdGVybmF0aXZlbHkg d2UgY291bGQgZW5qb3kgc3RhbmRhbG9uZSBycG0gd2l0aGluIHJoZWwvY2VudG9zIGlmPGJyPiZn dDsgJmd0OyAmZ3Q7IGF2YWlsYWJsZSw8YnI+Jmd0OyAmZ3Q7ICZndDsgaG93ZXZlciBub24gZXhp c3QuPGJyPiZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDIuIEkgZGlkIHRo ZSBjaGFuZ2UgKGh0dHA6Ly9nZXJyaXQub3ZpcnQub3JnLzI2NzQ1KS48YnI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgdW5pdCB0ZXN0cyB0aGF0IHVzZSB0aGUgbmV3 IGRlcGVuZGVuY3kgcGFzcyBsb2NhbGx5IGFuZCBpbjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7IEplbmtpbnM8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyBlbnZpcm9ubWVudHMuPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsm bmJzcDsgSG93ZXZlciB3aGVuIEkgdHJ5IHRvIHJ1biBhIGNvZGUgdGhhdCBpcyBkZXBlbmRlbnQg b24gdGhlIG5ld2x5PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsmbmJzcDsmbmJzcDsmbmJzcDsgYWRk ZWQ8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBsaWJyYXJ5IE5vQ2xh c3NEZWZGb3VuZEVycm9yIGJlaW5nIHRocm93bi48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyBBbHNvIEkgY2FuJ3QgZmluZCBjb21tb25zLWNvbGxlY3Rpb25zNCBqYXIg dW5kZXIgdGhlIGluc3RhbGxhdGlvbjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGRpcmVjdG9yeS4gSSB1c2UgIm1ha2UgY2xlYW4gaW5zdGFsbC1kZXYiIGNvbW1hbmQg Zm9yIGJ1aWxkaW5nLjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7IFBsZWFzZSBhZHZpc2UuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyA8YnI+PC9ib2R5Pg== ----_com.android.email_1462209507407830--
----- Original Message -----
From: "Yevgeny Zaspitsky" <yzaspits@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com>, "Mike Kolesnik" <mkolesni@redhat.com> Cc: devel@ovirt.org Sent: Thursday, May 8, 2014 1:11:41 AM Subject: Re: [ovirt-devel] commons-collections v4.0
On the other hand, changing a jar in the runtime environment without compiling and running test with the new jar could lead an application to stop functioning in a customer environment. Also not every bug found in a dependency jar would cause a problem in the application. (An application might not use the problematic part of the dependency.) I'd better trust the test suite (automatic and manual) that we run on the compiled application with all the dependencies that the developers choose at the development time and then deliver that (with its dependencies as a single package) to the customers. Every bug in a dependency should be evaluated within the given application scope and only if proven as the given application problem only then the application should be released.
So what you basically claim is that java developers and technology is not mature enough to keep backward compatibility, so each java developer should freeze a snapshot in time for his application to work. I truly hope this is not the case. And for addressing your claim explicitly, what you can test at single point in time, does not mean that it is definite as well, at customer site bugs may be found also in the packages that you do test.
Sent from Samsung Mobile
-------- Original message -------- From: Alon Bar-Lev <alonbl@redhat.com> Date: 07/05/2014 21:41 (GMT+02:00) To: Mike Kolesnik <mkolesni@redhat.com> Cc: Yevgeny Zaspitsky <yzaspits@redhat.com>,devel@ovirt.org Subject: Re: [ovirt-devel] commons-collections v4.0
----- Original Message -----
From: "Mike Kolesnik" <mkolesni@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Yevgeny Zaspitsky" <yzaspits@redhat.com>, devel@ovirt.org Sent: Wednesday, May 7, 2014 9:34:03 PM Subject: Re: [ovirt-devel] commons-collections v4.0
----- Original Message -----
----- Original Message -----
From: "Yevgeny Zaspitsky" <yzaspits@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: devel@ovirt.org Sent: Tuesday, April 22, 2014 11:39:11 AM Subject: Re: [ovirt-devel] commons-collections v4.0
That means that we manage 2 separate environments: 1. Development - relies on pom files. E.g. unit tests run with commons-collections v3.1 (and when I add v4.0) and succeed.
devenv will use runtime option. you are right about the unit tests, these relays on the poms.
I use devenv and it always uses the dev option not the runtime. So basically developers are using the pom specified versions and not what used in runtime.
Even more so, in runtime it highly depends on what OS you're using, so someone developing on F19 might not be using same versions as a developer on F20 and both are probably very different versions than on RHEL/CentOS. I won't even mention other OS`s.
2. Run-time - relies on JBoss own dependencies that bring commons-collection v3.2.1-redhat-2.
in rhel case, yes.
This kind of discrepancies might be found in other libraries as we do not synchronize our pom files with the JBoss current version dependencies. IMHO that could lead to some very difficult bugs that we won't be able to simulate in our unit tests.
correct, but the java way to pull dependencies at will without being able to fix z-stream using central package management tools is more severe than unit tests not working/not working.
for example, your application uses x.jar and actually delivers x.jar... so from release to eternity it is your responsibility to track x.jar for severe stability bugs and security bugs, and release your entire application each time found, now multiple it with the # of components application is using and see how much effort you have just to maintain stability and security if you embed 3rd party components without your application.
Yes, if you use package X then you're using that specific version with it's behaviour and API, this is why dependencies aren't updated light headedly but with testing to see that nothing broke (since stuff does break, even in minor version, as we leave in a not so perfect world).
Why do we avoid "to maintain our own packaging"? IMHO Ovirt own dependencies could be packed in the war, can't they?
yes they could, but this is not suitable for enterprise grade implementations, mainly per what I described above.
Sorry but AFAIK enterprise grade software release fixes for their software on a timely basis and have processes in place to manage upgrades of functionality.
What currently is done is relying on courtesy of other people to release a "fix" that already exists a long time. And of course, as I mentioned, the application needs to be tested with the updated library. IMO neglecting this and leaving this out of band for "enterprise grade" software is much worse than actually testing to see that it is working and just leaving it all to chance.
Well, take the recent example of openssl issue that was found. Now, imagine that all products that use openssl should have been re-released. I think this is enough to understand how wrong this is.
Regards, Alon
Best regards, ____________________ Yevgeny Zaspitsky Senior Software Engineer Red Hat Israel
----- Original Message ----- From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Yevgeny Zaspitsky" <yzaspits@redhat.com> Cc: devel@ovirt.org Sent: Sunday, April 13, 2014 7:22:18 PM Subject: Re: [ovirt-devel] commons-collections v4.0
----- Original Message -----
From: "Yevgeny Zaspitsky" <yzaspits@redhat.com> To: devel@ovirt.org Sent: Sunday, April 13, 2014 7:13:10 PM Subject: [ovirt-devel] commons-collections v4.0
Hi All,
I'd like to add the new version (4.0) of Apache commons-collections library to the dependencies of the project (we use 3.1 currently). The new version uses the generics features of Java 5 so that make the code more type safe. You can find the full list of changes on https://commons.apache.org/proper/commons-collections/release_4_0.html. The new API is based on the original but it isn't fully compatible with it. So in order to make the migration to the new API easier, the package has been changed to org.apache.commons.collections4. That allows having both version of the library in the classpath at the starting point and move (refactor) towards the new version gradually.
I have couple of questions regarding the new dependency: 1. Is there anything that could prevent adding the new dependency?
We try to avoid introducing our own dependencies, in this case we use whatever jboss provides which is very comfortable as we do not need to maintain our own packaging.
Currently the jbeap does not provide 4.0, it does support 3.2.1-redhat-2, so better to avoid this until we switch to more recent version of jboss.
Alternatively we could enjoy standalone rpm within rhel/centos if available, however non exist.
2. I did the change (http://gerrit.ovirt.org/26745). The unit tests that use the new dependency pass locally and in Jenkins environments. However when I try to run a code that is dependent on the newly added library NoClassDefFoundError being thrown. Also I can't find commons-collections4 jar under the installation directory. I use "make clean install-dev" command for building.
Please advise.
----- Original Message -----
----- Original Message -----
From: "Yevgeny Zaspitsky" <yzaspits@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com>, "Mike Kolesnik" <mkolesni@redhat.com> Cc: devel@ovirt.org Sent: Thursday, May 8, 2014 1:11:41 AM Subject: Re: [ovirt-devel] commons-collections v4.0
On the other hand, changing a jar in the runtime environment without compiling and running test with the new jar could lead an application to stop functioning in a customer environment. Also not every bug found in a dependency jar would cause a problem in the application. (An application might not use the problematic part of the dependency.) I'd better trust the test suite (automatic and manual) that we run on the compiled application with all the dependencies that the developers choose at the development time and then deliver that (with its dependencies as a single package) to the customers. Every bug in a dependency should be evaluated within the given application scope and only if proven as the given application problem only then the application should be released.
So what you basically claim is that java developers and technology is not mature enough to keep backward compatibility, so each java developer should freeze a snapshot in time for his application to work.
I truly hope this is not the case.
There can always be regressions as you're well aware, and I don't know but usually people who develop the libraries are not Einstein so yes, they do break backwards compatibility on occasions, sometimes even on purpose (deprecation).
And for addressing your claim explicitly, what you can test at single point in time, does not mean that it is definite as well, at customer site bugs may be found also in the packages that you do test.
Well, when you test on site by dev & qa you make sure you send something to the customer - X. When the dependencies are updated out of band, the customer actually is using X'. I can see at least 2 things wrong here: 1. You're putting the customer in a position of a tester for the X' application. 2. If customer finds a bug he actually found it on X', whereas the developer who would be assigned to the bug could be using X'' by now. If you're so keen on packaging a jar outside WAR file, we need to specify explicit version and not >=.
Sent from Samsung Mobile
-------- Original message -------- From: Alon Bar-Lev <alonbl@redhat.com> Date: 07/05/2014 21:41 (GMT+02:00) To: Mike Kolesnik <mkolesni@redhat.com> Cc: Yevgeny Zaspitsky <yzaspits@redhat.com>,devel@ovirt.org Subject: Re: [ovirt-devel] commons-collections v4.0
----- Original Message -----
From: "Mike Kolesnik" <mkolesni@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Yevgeny Zaspitsky" <yzaspits@redhat.com>, devel@ovirt.org Sent: Wednesday, May 7, 2014 9:34:03 PM Subject: Re: [ovirt-devel] commons-collections v4.0
----- Original Message -----
----- Original Message -----
From: "Yevgeny Zaspitsky" <yzaspits@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: devel@ovirt.org Sent: Tuesday, April 22, 2014 11:39:11 AM Subject: Re: [ovirt-devel] commons-collections v4.0
That means that we manage 2 separate environments: 1. Development - relies on pom files. E.g. unit tests run with commons-collections v3.1 (and when I add v4.0) and succeed.
devenv will use runtime option. you are right about the unit tests, these relays on the poms.
I use devenv and it always uses the dev option not the runtime. So basically developers are using the pom specified versions and not what used in runtime.
Even more so, in runtime it highly depends on what OS you're using, so someone developing on F19 might not be using same versions as a developer on F20 and both are probably very different versions than on RHEL/CentOS. I won't even mention other OS`s.
2. Run-time - relies on JBoss own dependencies that bring commons-collection v3.2.1-redhat-2.
in rhel case, yes.
This kind of discrepancies might be found in other libraries as we do not synchronize our pom files with the JBoss current version dependencies. IMHO that could lead to some very difficult bugs that we won't be able to simulate in our unit tests.
correct, but the java way to pull dependencies at will without being able to fix z-stream using central package management tools is more severe than unit tests not working/not working.
for example, your application uses x.jar and actually delivers x.jar... so from release to eternity it is your responsibility to track x.jar for severe stability bugs and security bugs, and release your entire application each time found, now multiple it with the # of components application is using and see how much effort you have just to maintain stability and security if you embed 3rd party components without your application.
Yes, if you use package X then you're using that specific version with it's behaviour and API, this is why dependencies aren't updated light headedly but with testing to see that nothing broke (since stuff does break, even in minor version, as we leave in a not so perfect world).
Why do we avoid "to maintain our own packaging"? IMHO Ovirt own dependencies could be packed in the war, can't they?
yes they could, but this is not suitable for enterprise grade implementations, mainly per what I described above.
Sorry but AFAIK enterprise grade software release fixes for their software on a timely basis and have processes in place to manage upgrades of functionality.
What currently is done is relying on courtesy of other people to release a "fix" that already exists a long time. And of course, as I mentioned, the application needs to be tested with the updated library. IMO neglecting this and leaving this out of band for "enterprise grade" software is much worse than actually testing to see that it is working and just leaving it all to chance.
Well, take the recent example of openssl issue that was found. Now, imagine that all products that use openssl should have been re-released. I think this is enough to understand how wrong this is.
Regards, Alon
Best regards, ____________________ Yevgeny Zaspitsky Senior Software Engineer Red Hat Israel
----- Original Message ----- From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Yevgeny Zaspitsky" <yzaspits@redhat.com> Cc: devel@ovirt.org Sent: Sunday, April 13, 2014 7:22:18 PM Subject: Re: [ovirt-devel] commons-collections v4.0
----- Original Message -----
From: "Yevgeny Zaspitsky" <yzaspits@redhat.com> To: devel@ovirt.org Sent: Sunday, April 13, 2014 7:13:10 PM Subject: [ovirt-devel] commons-collections v4.0
Hi All,
I'd like to add the new version (4.0) of Apache commons-collections library to the dependencies of the project (we use 3.1 currently). The new version uses the generics features of Java 5 so that make the code more type safe. You can find the full list of changes on https://commons.apache.org/proper/commons-collections/release_4_0.html. The new API is based on the original but it isn't fully compatible with it. So in order to make the migration to the new API easier, the package has been changed to org.apache.commons.collections4. That allows having both version of the library in the classpath at the starting point and move (refactor) towards the new version gradually.
I have couple of questions regarding the new dependency: 1. Is there anything that could prevent adding the new dependency?
We try to avoid introducing our own dependencies, in this case we use whatever jboss provides which is very comfortable as we do not need to maintain our own packaging.
Currently the jbeap does not provide 4.0, it does support 3.2.1-redhat-2, so better to avoid this until we switch to more recent version of jboss.
Alternatively we could enjoy standalone rpm within rhel/centos if available, however non exist.
2. I did the change (http://gerrit.ovirt.org/26745). The unit tests that use the new dependency pass locally and in Jenkins environments. However when I try to run a code that is dependent on the newly added library NoClassDefFoundError being thrown. Also I can't find commons-collections4 jar under the installation directory. I use "make clean install-dev" command for building.
Please advise.
----- Original Message -----
From: "Mike Kolesnik" <mkolesni@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "yzaspits" <yzaspits@redhat.com>, devel@ovirt.org Sent: Thursday, May 8, 2014 7:18:51 AM Subject: Re: [ovirt-devel] commons-collections v4.0
----- Original Message -----
----- Original Message -----
From: "Yevgeny Zaspitsky" <yzaspits@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com>, "Mike Kolesnik" <mkolesni@redhat.com> Cc: devel@ovirt.org Sent: Thursday, May 8, 2014 1:11:41 AM Subject: Re: [ovirt-devel] commons-collections v4.0
On the other hand, changing a jar in the runtime environment without compiling and running test with the new jar could lead an application to stop functioning in a customer environment. Also not every bug found in a dependency jar would cause a problem in the application. (An application might not use the problematic part of the dependency.) I'd better trust the test suite (automatic and manual) that we run on the compiled application with all the dependencies that the developers choose at the development time and then deliver that (with its dependencies as a single package) to the customers. Every bug in a dependency should be evaluated within the given application scope and only if proven as the given application problem only then the application should be released.
So what you basically claim is that java developers and technology is not mature enough to keep backward compatibility, so each java developer should freeze a snapshot in time for his application to work.
I truly hope this is not the case.
There can always be regressions as you're well aware, and I don't know but usually people who develop the libraries are not Einstein so yes, they do break backwards compatibility on occasions, sometimes even on purpose (deprecation).
And for addressing your claim explicitly, what you can test at single point in time, does not mean that it is definite as well, at customer site bugs may be found also in the packages that you do test.
Well, when you test on site by dev & qa you make sure you send something to the customer - X. When the dependencies are updated out of band, the customer actually is using X'. I can see at least 2 things wrong here: 1. You're putting the customer in a position of a tester for the X' application. 2. If customer finds a bug he actually found it on X', whereas the developer who would be assigned to the bug could be using X'' by now.
If you're so keen on packaging a jar outside WAR file, we need to specify explicit version and not >=.
Explicit version is at if you pack it within your application, there is no point in that. Think of how RHEL is provided, think of Fedora, in all cases there are components working together and each can be updated independently, and amazingly - it works. You can think of Windows with all of its libraries and interfaces (Microsoft or 3rd party), that application use, and it does work without every [sane] application pulls the entire dependencies. For some reason only people with Java background (including the J2EE designers) assume that Java developers cannot be trusted for not breaking backward compatibility in minor versions. This is not technical assumption but human assumption, as there is no technical reason for Java library to break backward compatibility within minor releases, so what does it tells us about what Java developers thinks of them-selves? Java will be ready for enterprise only when this is resolved. I hope all the dependencies we are using are at the quality level that enables us to to trust their developers.
Sent from Samsung Mobile
-------- Original message -------- From: Alon Bar-Lev <alonbl@redhat.com> Date: 07/05/2014 21:41 (GMT+02:00) To: Mike Kolesnik <mkolesni@redhat.com> Cc: Yevgeny Zaspitsky <yzaspits@redhat.com>,devel@ovirt.org Subject: Re: [ovirt-devel] commons-collections v4.0
----- Original Message -----
From: "Mike Kolesnik" <mkolesni@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: "Yevgeny Zaspitsky" <yzaspits@redhat.com>, devel@ovirt.org Sent: Wednesday, May 7, 2014 9:34:03 PM Subject: Re: [ovirt-devel] commons-collections v4.0
----- Original Message -----
----- Original Message -----
From: "Yevgeny Zaspitsky" <yzaspits@redhat.com> To: "Alon Bar-Lev" <alonbl@redhat.com> Cc: devel@ovirt.org Sent: Tuesday, April 22, 2014 11:39:11 AM Subject: Re: [ovirt-devel] commons-collections v4.0
That means that we manage 2 separate environments: 1. Development - relies on pom files. E.g. unit tests run with commons-collections v3.1 (and when I add v4.0) and succeed.
devenv will use runtime option. you are right about the unit tests, these relays on the poms.
I use devenv and it always uses the dev option not the runtime. So basically developers are using the pom specified versions and not what used in runtime.
Even more so, in runtime it highly depends on what OS you're using, so someone developing on F19 might not be using same versions as a developer on F20 and both are probably very different versions than on RHEL/CentOS. I won't even mention other OS`s.
2. Run-time - relies on JBoss own dependencies that bring commons-collection v3.2.1-redhat-2.
in rhel case, yes.
This kind of discrepancies might be found in other libraries as we do not synchronize our pom files with the JBoss current version dependencies. IMHO that could lead to some very difficult bugs that we won't be able to simulate in our unit tests.
correct, but the java way to pull dependencies at will without being able to fix z-stream using central package management tools is more severe than unit tests not working/not working.
for example, your application uses x.jar and actually delivers x.jar... so from release to eternity it is your responsibility to track x.jar for severe stability bugs and security bugs, and release your entire application each time found, now multiple it with the # of components application is using and see how much effort you have just to maintain stability and security if you embed 3rd party components without your application.
Yes, if you use package X then you're using that specific version with it's behaviour and API, this is why dependencies aren't updated light headedly but with testing to see that nothing broke (since stuff does break, even in minor version, as we leave in a not so perfect world).
Why do we avoid "to maintain our own packaging"? IMHO Ovirt own dependencies could be packed in the war, can't they?
yes they could, but this is not suitable for enterprise grade implementations, mainly per what I described above.
Sorry but AFAIK enterprise grade software release fixes for their software on a timely basis and have processes in place to manage upgrades of functionality.
What currently is done is relying on courtesy of other people to release a "fix" that already exists a long time. And of course, as I mentioned, the application needs to be tested with the updated library. IMO neglecting this and leaving this out of band for "enterprise grade" software is much worse than actually testing to see that it is working and just leaving it all to chance.
Well, take the recent example of openssl issue that was found. Now, imagine that all products that use openssl should have been re-released. I think this is enough to understand how wrong this is.
Regards, Alon
Best regards, ____________________ Yevgeny Zaspitsky Senior Software Engineer Red Hat Israel
----- Original Message ----- From: "Alon Bar-Lev" <alonbl@redhat.com> To: "Yevgeny Zaspitsky" <yzaspits@redhat.com> Cc: devel@ovirt.org Sent: Sunday, April 13, 2014 7:22:18 PM Subject: Re: [ovirt-devel] commons-collections v4.0
----- Original Message ----- > From: "Yevgeny Zaspitsky" <yzaspits@redhat.com> > To: devel@ovirt.org > Sent: Sunday, April 13, 2014 7:13:10 PM > Subject: [ovirt-devel] commons-collections v4.0 > > Hi All, > > I'd like to add the new version (4.0) of Apache > commons-collections > library > to the dependencies of the project (we use 3.1 currently). > The new version uses the generics features of Java 5 so that make > the > code > more type safe. You can find the full list of changes on > https://commons.apache.org/proper/commons-collections/release_4_0.html. > The new API is based on the original but it isn't fully > compatible > with > it. > So in order to make the migration to the new API easier, the > package > has > been changed to org.apache.commons.collections4. That allows > having > both > version of the library in the classpath at the starting point and > move > (refactor) towards the new version gradually. > > I have couple of questions regarding the new dependency: > 1. Is there anything that could prevent adding the new > dependency?
We try to avoid introducing our own dependencies, in this case we use whatever jboss provides which is very comfortable as we do not need to maintain our own packaging.
Currently the jbeap does not provide 4.0, it does support 3.2.1-redhat-2, so better to avoid this until we switch to more recent version of jboss.
Alternatively we could enjoy standalone rpm within rhel/centos if available, however non exist.
> 2. I did the change (http://gerrit.ovirt.org/26745). > The unit tests that use the new dependency pass locally and in > Jenkins > environments. > However when I try to run a code that is dependent on the > newly > added > library NoClassDefFoundError being thrown. > Also I can't find commons-collections4 jar under the > installation > directory. I use "make clean install-dev" command for > building. > > Please advise.
participants (3)
-
Alon Bar-Lev -
Mike Kolesnik -
Yevgeny Zaspitsky