----- Original Message ----- > From: "Mike Kolesnik" <[email protected]> > To: "Alon Bar-Lev" <[email protected]> > Cc: "Yevgeny Zaspitsky" <[email protected]>, [email protected] > Sent: Wednesday, May 7, 2014 9:34:03 PM > Subject: Re: [ovirt-devel] commons-collections v4.0 > > ----- Original Message ----- > > > > > > ----- Original Message ----- > > > From: "Yevgeny Zaspitsky" <[email protected]> > > > To: "Alon Bar-Lev" <[email protected]> > > > Cc: [email protected] > > > 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" <[email protected]> > > > To: "Yevgeny Zaspitsky" <[email protected]> > > > Cc: [email protected] > > > Sent: Sunday, April 13, 2014 7:22:18 PM > > > Subject: Re: [ovirt-devel] commons-collections v4.0 > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Yevgeny Zaspitsky" <[email protected]> > > > > To: [email protected] > > > > 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. > > > _______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
