[ovirt-devel] commons-collections v4.0

[Alon Bar-Lev]

----- Original Message -----
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "Alon Bar-Lev" <alonbl at redhat.com>
> Cc: "Yevgeny Zaspitsky" <yzaspits at redhat.com>, devel at 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 at redhat.com>
> > > To: "Alon Bar-Lev" <alonbl at redhat.com>
> > > Cc: devel at 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 at redhat.com>
> > > To: "Yevgeny Zaspitsky" <yzaspits at redhat.com>
> > > Cc: devel at 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 at redhat.com>
> > > > To: devel at 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.
> > 
>