[ovirt-devel] commons-collections v4.0

Thu May 8 04:18:51 UTC 2014

----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Yevgeny Zaspitsky" <yzaspits at redhat.com>
> > To: "Alon Bar-Lev" <alonbl at redhat.com>, "Mike Kolesnik"
> > <mkolesni at redhat.com>
> > Cc: devel at 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 at redhat.com>
> > Date: 07/05/2014  21:41  (GMT+02:00)
> > To: Mike Kolesnik <mkolesni at redhat.com>
> > Cc: Yevgeny Zaspitsky <yzaspits at redhat.com>,devel at ovirt.org
> > Subject: Re: [ovirt-devel] commons-collections v4.0
> >  
> > 
> > 
> > ----- 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.
> > > > 
> > > 
> > 
> 