Re: [ovirt-devel] commons-collections v4.0
Am 07.05.2014 20:41, schrieb Alon Bar-Lev: > 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. Exactly, if you want to take this serious, you must provide someone who monitors any upstream project you might include and especially backport security patches, maybe on your own, when talking about "enterprise grade software". So any included hard dependency that will be shipped by ovirt must also be maintainable by ovirt. So it's always a good choice to have as little deps as possible but of course you always have _some_ . Where to draw the line is a very difficult task and should be very well reviewed. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] commons-collections v4.0
- Original Message - > From: "Mike Kolesnik" > To: "Alon Bar-Lev" > Cc: "yzaspits" , devel@ovirt.org > Sent: Thursday, May 8, 2014 7:18:51 AM > Subject: Re: [ovirt-devel] commons-collections v4.0 > > - Original Message - > > > > > > - Original Message - > > > From: "Yevgeny Zaspitsky" > > > To: "Alon Bar-Lev" , "Mike Kolesnik" > > > > > > Cc: devel@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 >=. Explicit version is at if you pack it within your application, there is no point in that. Think of how RHEL is provided, think of Fedora, in all cases there are components working together and each can be updated independently, and amazingly - it works. You can think of Windows with all of its libraries and interfaces (Microsoft or 3rd party), that application use, and it does work without every [sane] application pulls the entire dependencies. For some reason only people with Java background (including the J2EE designers) assume that Java developers cannot be trusted for not breaking backward compatibility in minor versions. This is not technical assumption but human assumption, as there is no technical reason for Java library to break backward compatibility within minor releases, so what does it tells us about what Java developers thinks of them-selves? Java will be ready for enterprise only when this is resolved. I hope all the dependencies we are using are at the quality level that enables us to to trust their developers. > > > > > > > > > > > > Sent from Samsung Mobile > > > > > > Original message > > > From: Alon Bar-Lev > > > Date: 07/05/2014 21:41 (GMT+02:00) > > > To: Mike Kolesnik > > > Cc: Yevgeny Zaspitsky ,devel@ovirt.org > > > Subject: Re: [ovirt-devel] commons-collections v4.0 > > > > > > > > > > > > - Original Message - > > > > From: "Mike Kolesnik" > > > > To: "Alon Bar-Lev" > > > > Cc: "Yevgeny Zaspitsky" , devel@ovirt.org > > > > Sent: Wednesday, May 7, 2014 9:34:03 PM > > > > Subject: Re: [ovirt-deve
Re: [ovirt-devel] commons-collections v4.0
- Original Message - > > > - Original Message - > > From: "Yevgeny Zaspitsky" > > To: "Alon Bar-Lev" , "Mike Kolesnik" > > > > Cc: devel@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 > > Date: 07/05/2014 21:41 (GMT+02:00) > > To: Mike Kolesnik > > Cc: Yevgeny Zaspitsky ,devel@ovirt.org > > Subject: Re: [ovirt-devel] commons-collections v4.0 > > > > > > > > - Original Message - > > > From: "Mike Kolesnik" > > > To: "Alon Bar-Lev" > > > Cc: "Yevgeny Zaspitsky" , devel@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" > > > > > To: "Alon Bar-Lev" > > > > > Cc: devel@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. > > > > > >
Re: [ovirt-devel] commons-collections v4.0
- Original Message - > From: "Yevgeny Zaspitsky" > To: "Alon Bar-Lev" , "Mike Kolesnik" > Cc: devel@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. 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. > > > Sent from Samsung Mobile > > Original message > From: Alon Bar-Lev > Date: 07/05/2014 21:41 (GMT+02:00) > To: Mike Kolesnik > Cc: Yevgeny Zaspitsky ,devel@ovirt.org > Subject: Re: [ovirt-devel] commons-collections v4.0 > > > > - Original Message - > > From: "Mike Kolesnik" > > To: "Alon Bar-Lev" > > Cc: "Yevgeny Zaspitsky" , devel@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" > > > > To: "Alon Bar-Lev" > > > > Cc: devel@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. > > &
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. Sent from Samsung Mobile Original message From: Alon Bar-Lev Date: 07/05/2014 21:41 (GMT+02:00) To: Mike Kolesnik Cc: Yevgeny Zaspitsky ,devel@ovirt.org Subject: Re: [ovirt-devel] commons-collections v4.0 - Original Message - > From: "Mike Kolesnik" > To: "Alon Bar-Lev" > Cc: "Yevgeny Zaspitsky" , devel@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" > > > To: "Alon Bar-Lev" > > > Cc: devel@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 w
Re: [ovirt-devel] commons-collections v4.0
- Original Message - > From: "Mike Kolesnik" > To: "Alon Bar-Lev" > Cc: "Yevgeny Zaspitsky" , devel@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" > > > To: "Alon Bar-Lev" > > > Cc: devel@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" > > > To: "Yevgeny Zaspitsky" > > > Cc: devel@ovirt.org > > > Sent: Sunday, April 13, 2014 7:22:18 PM > > > Subject: Re: [ovirt-devel] commons-collections v4.0 > > > > > > > > > > > > - Original Message - > > > > From: "Yevgeny Zaspitsky" > > > > To: devel@ovirt.org > > > > Sent: Sun
Re: [ovirt-devel] commons-collections v4.0
- Original Message - > > > - Original Message - > > From: "Yevgeny Zaspitsky" > > To: "Alon Bar-Lev" > > Cc: devel@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" > > To: "Yevgeny Zaspitsky" > > Cc: devel@ovirt.org > > Sent: Sunday, April 13, 2014 7:22:18 PM > > Subject: Re: [ovirt-devel] commons-collections v4.0 > > > > > > > > - Original Message - > > > From: "Yevgeny Zaspitsky" > > > To: devel@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 > > > (refa
Re: [ovirt-devel] commons-collections v4.0
+1! Am 22.04.2014 10:48, schrieb Alon Bar-Lev: >> 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. > >> > 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. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] commons-collections v4.0
- Original Message - > From: "Yevgeny Zaspitsky" > To: "Alon Bar-Lev" > Cc: devel@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. > 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. > 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. Regards, Alon > Best regards, > > Yevgeny Zaspitsky > Senior Software Engineer > Red Hat Israel > > > - Original Message - > From: "Alon Bar-Lev" > To: "Yevgeny Zaspitsky" > Cc: devel@ovirt.org > Sent: Sunday, April 13, 2014 7:22:18 PM > Subject: Re: [ovirt-devel] commons-collections v4.0 > > > > - Original Message - > > From: "Yevgeny Zaspitsky" > > To: devel@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. > > > > Best regards, > > > > Yevgeny Zaspitsky > > Senior Software Engineer > > Red Hat > > > > > > ___ > > Devel mailing list > > Devel@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/devel > > > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
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. 2. Run-time - relies on JBoss own dependencies that bring commons-collection v3.2.1-redhat-2. 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. Why do we avoid "to maintain our own packaging"? IMHO Ovirt own dependencies could be packed in the war, can't they? Best regards, Yevgeny Zaspitsky Senior Software Engineer Red Hat Israel - Original Message - From: "Alon Bar-Lev" To: "Yevgeny Zaspitsky" Cc: devel@ovirt.org Sent: Sunday, April 13, 2014 7:22:18 PM Subject: Re: [ovirt-devel] commons-collections v4.0 - Original Message - > From: "Yevgeny Zaspitsky" > To: devel@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. > > Best regards, > > Yevgeny Zaspitsky > Senior Software Engineer > Red Hat > > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] commons-collections v4.0
- Original Message - > From: "Yevgeny Zaspitsky" > To: devel@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. > > Best regards, > > Yevgeny Zaspitsky > Senior Software Engineer > Red Hat > > > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[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? 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. Best regards, Yevgeny Zaspitsky Senior Software Engineer Red Hat ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
