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