3:39 a.m.
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" <alonbl(a)redhat.com>
To: "Yevgeny Zaspitsky" <yzaspits(a)redhat.com>
Cc: devel(a)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(a)redhat.com>
To: devel(a)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(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel