[ovirt-devel] commons-collections v4.0

Wed May 7 18:34:03 UTC 2014

----- 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.

> 
> 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.
> 