[Engine-devel] java 1.6 compatibility no more?
Hi, It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. Is this intentional? Laszlo
In fact, for both backend and frontend, Maven effective POM contains: <artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> </configuration> Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?) The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method. I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method). Vojtech ----- Original Message ----- From: "Laszlo Hornyak" <lhornyak@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Cc: "Vojtech Szocs" <vszocs@redhat.com> Sent: Wednesday, July 18, 2012 5:43:34 PM Subject: java 1.6 compatibility no more? Hi, It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. Is this intentional? Laszlo
On 07/18/2012 06:33 PM, Vojtech Szocs wrote:
In fact, for both backend and frontend, Maven effective POM contains:
<artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> </configuration>
Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?)
These maven settings just tell the java compiler to accept Java 6 syntax only and to generate a Java 6 compatible .class file format, but they don't restrict the set of APIs that can be used.
The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method.
I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method).
Vojtech
----- Original Message ----- From: "Laszlo Hornyak" <lhornyak@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Cc: "Vojtech Szocs" <vszocs@redhat.com> Sent: Wednesday, July 18, 2012 5:43:34 PM Subject: java 1.6 compatibility no more?
Hi,
It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. Is this intentional?
Laszlo _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
-- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
On 07/18/2012 08:21 PM, Juan Hernandez wrote:
On 07/18/2012 06:33 PM, Vojtech Szocs wrote:
In fact, for both backend and frontend, Maven effective POM contains:
<artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> </configuration>
Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?)
These maven settings just tell the java compiler to accept Java 6 syntax only and to generate a Java 6 compatible .class file format, but they don't restrict the set of APIs that can be used.
I think the question is if it makes any sense to keep/force java 6 compatibility for next version of ovirt, with java 6 EOL dates. a jenkins job compiling for java 6 compatibility is easy to create - question is if there is a reason to do it.
The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method.
I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method).
Vojtech
----- Original Message ----- From: "Laszlo Hornyak" <lhornyak@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Cc: "Vojtech Szocs" <vszocs@redhat.com> Sent: Wednesday, July 18, 2012 5:43:34 PM Subject: java 1.6 compatibility no more?
Hi,
It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. Is this intentional?
Laszlo _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 07/18/2012 08:21 PM, Juan Hernandez wrote:
On 07/18/2012 06:33 PM, Vojtech Szocs wrote:
In fact, for both backend and frontend, Maven effective POM contains:
<artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> </configuration>
Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?)
These maven settings just tell the java compiler to accept Java 6 syntax only and to generate a Java 6 compatible .class file format, but they don't restrict the set of APIs that can be used.
The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method.
I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method).
Vojtech
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
----- Original Message ----- From: "Laszlo Hornyak" <lhornyak@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Cc: "Vojtech Szocs" <vszocs@redhat.com> Sent: Wednesday, July 18, 2012 5:43:34 PM Subject: java 1.6 compatibility no more?
Hi,
It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. Is this intentional?
Laszlo _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well? If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance. Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build. Vojtech ----- Original Message ----- From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 7:59:45 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/18/2012 08:21 PM, Juan Hernandez wrote:
On 07/18/2012 06:33 PM, Vojtech Szocs wrote:
In fact, for both backend and frontend, Maven effective POM contains:
<artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> </configuration>
Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?)
These maven settings just tell the java compiler to accept Java 6 syntax only and to generate a Java 6 compatible .class file format, but they don't restrict the set of APIs that can be used.
The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method.
I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method).
Vojtech
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
----- Original Message ----- From: "Laszlo Hornyak" <lhornyak@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Cc: "Vojtech Szocs" <vszocs@redhat.com> Sent: Wednesday, July 18, 2012 5:43:34 PM Subject: java 1.6 compatibility no more?
Hi,
It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. Is this intentional?
Laszlo _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 07/19/2012 11:09 AM, Vojtech Szocs wrote:
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well?
If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance.
+1 here - whatever it takes ;)
Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build.
Vojtech
----- Original Message ----- From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 7:59:45 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/18/2012 08:21 PM, Juan Hernandez wrote:
On 07/18/2012 06:33 PM, Vojtech Szocs wrote:
In fact, for both backend and frontend, Maven effective POM contains:
<artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> </configuration>
Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?)
These maven settings just tell the java compiler to accept Java 6 syntax only and to generate a Java 6 compatible .class file format, but they don't restrict the set of APIs that can be used.
The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method.
I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method).
Vojtech
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
----- Original Message ----- From: "Laszlo Hornyak" <lhornyak@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Cc: "Vojtech Szocs" <vszocs@redhat.com> Sent: Wednesday, July 18, 2012 5:43:34 PM Subject: java 1.6 compatibility no more?
Hi,
It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. Is this intentional?
Laszlo _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 07/19/2012 10:09 AM, Vojtech Szocs wrote:
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well?
If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance.
Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build.
Don't we need that (the source part) to avoid Java 7 syntax in GWT code?
----- Original Message ----- From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 7:59:45 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/18/2012 08:21 PM, Juan Hernandez wrote:
On 07/18/2012 06:33 PM, Vojtech Szocs wrote:
In fact, for both backend and frontend, Maven effective POM contains:
<artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> </configuration>
Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?)
These maven settings just tell the java compiler to accept Java 6 syntax only and to generate a Java 6 compatible .class file format, but they don't restrict the set of APIs that can be used.
The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method.
I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method).
Vojtech
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
----- Original Message ----- From: "Laszlo Hornyak" <lhornyak@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Cc: "Vojtech Szocs" <vszocs@redhat.com> Sent: Wednesday, July 18, 2012 5:43:34 PM Subject: java 1.6 compatibility no more?
Hi,
It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. Is this intentional?
Laszlo _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
-- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
Don't we need that (the source part) to avoid Java 7 syntax in GWT code?
That's a very good point. In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail. So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however. We could do something like this: - let oVirt root POM declare source and target compliance to Java 7 - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6) (note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code) What do you think? Vojtech ----- Original Message ----- From: "Juan Hernandez" <jhernand@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "Yair Zaslavsky" <yzaslavs@redhat.com>, engine-devel@ovirt.org Sent: Thursday, July 19, 2012 11:01:00 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more? On 07/19/2012 10:09 AM, Vojtech Szocs wrote:
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well?
If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance.
Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build.
Don't we need that (the source part) to avoid Java 7 syntax in GWT code?
----- Original Message ----- From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 7:59:45 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/18/2012 08:21 PM, Juan Hernandez wrote:
On 07/18/2012 06:33 PM, Vojtech Szocs wrote:
In fact, for both backend and frontend, Maven effective POM contains:
<artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> </configuration>
Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?)
These maven settings just tell the java compiler to accept Java 6 syntax only and to generate a Java 6 compatible .class file format, but they don't restrict the set of APIs that can be used.
The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method.
I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method).
Vojtech
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
----- Original Message ----- From: "Laszlo Hornyak" <lhornyak@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Cc: "Vojtech Szocs" <vszocs@redhat.com> Sent: Wednesday, July 18, 2012 5:43:34 PM Subject: java 1.6 compatibility no more?
Hi,
It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. Is this intentional?
Laszlo _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
-- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
On 07/19/2012 02:31 PM, Vojtech Szocs wrote:
Don't we need that (the source part) to avoid Java 7 syntax in GWT code?
That's a very good point.
In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail.
So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however.
We could do something like this:
- let oVirt root POM declare source and target compliance to Java 7 - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6)
(note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code)
What do you think?
Vojtech
+1 - I really like this idea!
----- Original Message ----- From: "Juan Hernandez" <jhernand@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "Yair Zaslavsky" <yzaslavs@redhat.com>, engine-devel@ovirt.org Sent: Thursday, July 19, 2012 11:01:00 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/19/2012 10:09 AM, Vojtech Szocs wrote:
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well?
If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance.
Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build.
Don't we need that (the source part) to avoid Java 7 syntax in GWT code?
----- Original Message ----- From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 7:59:45 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/18/2012 08:21 PM, Juan Hernandez wrote:
On 07/18/2012 06:33 PM, Vojtech Szocs wrote:
In fact, for both backend and frontend, Maven effective POM contains:
<artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> </configuration>
Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?)
These maven settings just tell the java compiler to accept Java 6 syntax only and to generate a Java 6 compatible .class file format, but they don't restrict the set of APIs that can be used.
The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method.
I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method).
Vojtech
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
----- Original Message ----- From: "Laszlo Hornyak" <lhornyak@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Cc: "Vojtech Szocs" <vszocs@redhat.com> Sent: Wednesday, July 18, 2012 5:43:34 PM Subject: java 1.6 compatibility no more?
Hi,
It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. Is this intentional?
Laszlo _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 07/19/2012 01:39 PM, Yair Zaslavsky wrote:
On 07/19/2012 02:31 PM, Vojtech Szocs wrote:
Don't we need that (the source part) to avoid Java 7 syntax in GWT code?
That's a very good point.
In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail.
So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however.
We could do something like this:
- let oVirt root POM declare source and target compliance to Java 7 - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6)
(note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code)
What do you think?
Vojtech
+1 - I really like this idea!
+1 from me as well.
----- Original Message ----- From: "Juan Hernandez" <jhernand@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "Yair Zaslavsky" <yzaslavs@redhat.com>, engine-devel@ovirt.org Sent: Thursday, July 19, 2012 11:01:00 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/19/2012 10:09 AM, Vojtech Szocs wrote:
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well?
If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance.
Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build.
Don't we need that (the source part) to avoid Java 7 syntax in GWT code?
----- Original Message ----- From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 7:59:45 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/18/2012 08:21 PM, Juan Hernandez wrote:
On 07/18/2012 06:33 PM, Vojtech Szocs wrote:
In fact, for both backend and frontend, Maven effective POM contains:
<artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> </configuration>
Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?)
These maven settings just tell the java compiler to accept Java 6 syntax only and to generate a Java 6 compatible .class file format, but they don't restrict the set of APIs that can be used.
The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method.
I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method).
Vojtech
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
----- Original Message ----- From: "Laszlo Hornyak" <lhornyak@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Cc: "Vojtech Szocs" <vszocs@redhat.com> Sent: Wednesday, July 18, 2012 5:43:34 PM Subject: java 1.6 compatibility no more?
Hi,
It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. Is this intentional?
Laszlo
-- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
Hi, At the moment if you update the <source> and <target> settings of the compiler plugin to 1.7 in the root pom, the project will build fine, but some of the junit tests will fail. (some strange problem with bytecode manipulation see here http://code.google.com/p/powermock/issues/detail?id=355) Moving only the <source> does not work, moving only the <target> leaves the junit tests failing. So as you see I have rejected my own patch :-) http://gerrit.ovirt.org/6447/ Laszlo ----- Original Message -----
From: "Juan Hernandez" <jhernand@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 1:41:26 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/19/2012 01:39 PM, Yair Zaslavsky wrote:
On 07/19/2012 02:31 PM, Vojtech Szocs wrote:
Don't we need that (the source part) to avoid Java 7 syntax in GWT code?
That's a very good point.
In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail.
So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however.
We could do something like this:
- let oVirt root POM declare source and target compliance to Java 7 - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6)
(note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code)
What do you think?
Vojtech
+1 - I really like this idea!
+1 from me as well.
----- Original Message ----- From: "Juan Hernandez" <jhernand@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "Yair Zaslavsky" <yzaslavs@redhat.com>, engine-devel@ovirt.org Sent: Thursday, July 19, 2012 11:01:00 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/19/2012 10:09 AM, Vojtech Szocs wrote:
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well?
If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance.
Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build.
Don't we need that (the source part) to avoid Java 7 syntax in GWT code?
----- Original Message ----- From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 7:59:45 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/18/2012 08:21 PM, Juan Hernandez wrote:
On 07/18/2012 06:33 PM, Vojtech Szocs wrote:
In fact, for both backend and frontend, Maven effective POM contains:
<artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> </configuration>
Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?)
These maven settings just tell the java compiler to accept Java 6 syntax only and to generate a Java 6 compatible .class file format, but they don't restrict the set of APIs that can be used.
The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method.
I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method).
Vojtech
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
----- Original Message ----- From: "Laszlo Hornyak" <lhornyak@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Cc: "Vojtech Szocs" <vszocs@redhat.com> Sent: Wednesday, July 18, 2012 5:43:34 PM Subject: java 1.6 compatibility no more?
Hi,
It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. Is this intentional?
Laszlo
-- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Laszlo Hornyak" <lhornyak@redhat.com> To: "Juan Hernandez" <jhernand@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 3:04:17 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
Hi,
At the moment if you update the <source> and <target> settings of the compiler plugin to 1.7 in the root pom, the project will build fine, but some of the junit tests will fail. (some strange problem with bytecode manipulation see here http://code.google.com/p/powermock/issues/detail?id=355)
The real solution for this is to stop using powermock, an effort we've been pursuing for the last couple of months. After merging a couple more patches that were already approved and just waiting for merge on the subject (http://gerrit.ovirt.org/#/c/6280/ && http://gerrit.ovirt.org/#/c/6392/ - if one of the maintainers can lend a hand), we remain with two failures which both originate from the same place: org.ovirt.engine.api.restapi.resource.BackendResourceDebugDetailTest org.ovirt.engine.api.restapi.resource.BackendResourceInfoDetailTest Both of these failures are due to powermocking in AbstractBackendResourceLoggingTest. Basically, this test is used for testing that the logging in BaseBackendResource.detail(Throwable) method is done properly. Not sure how useful this is (perhaps someone more familiar with REST-API can shed some insight?), but if this is the only thing preventing us from moving to jdk-7... well..
Moving only the <source> does not work, moving only the <target> leaves the junit tests failing.
So as you see I have rejected my own patch :-) http://gerrit.ovirt.org/6447/
Laszlo
----- Original Message -----
From: "Juan Hernandez" <jhernand@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 1:41:26 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/19/2012 01:39 PM, Yair Zaslavsky wrote:
On 07/19/2012 02:31 PM, Vojtech Szocs wrote:
Don't we need that (the source part) to avoid Java 7 syntax in GWT code?
That's a very good point.
In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail.
So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however.
We could do something like this:
- let oVirt root POM declare source and target compliance to Java 7 - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6)
(note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code)
What do you think?
Vojtech
+1 - I really like this idea!
+1 from me as well.
----- Original Message ----- From: "Juan Hernandez" <jhernand@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "Yair Zaslavsky" <yzaslavs@redhat.com>, engine-devel@ovirt.org Sent: Thursday, July 19, 2012 11:01:00 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/19/2012 10:09 AM, Vojtech Szocs wrote:
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well?
If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance.
Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build.
Don't we need that (the source part) to avoid Java 7 syntax in GWT code?
----- Original Message ----- From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 7:59:45 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/18/2012 08:21 PM, Juan Hernandez wrote:
On 07/18/2012 06:33 PM, Vojtech Szocs wrote: > In fact, for both backend and frontend, Maven effective POM > contains: > > <artifactId>maven-compiler-plugin</artifactId> > <configuration> > <source>1.6</source> > <target>1.6</target> > </configuration> > > Therefore, according to Maven POM files, oVirt should be > build-able using Java 6, but it's not. (?)
These maven settings just tell the java compiler to accept Java 6 syntax only and to generate a Java 6 compatible .class file format, but they don't restrict the set of APIs that can be used.
> The problem is in backend/manager/modules/bll: > StorageDomainCommandBase class uses new Java 7 Long.compare() > static method. > > I think we should decide if we want to be compliant with Java > 7, or submit a patch that uses Java 6 API (Long.compareTo > instance method). > > Vojtech
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
> > > ----- Original Message ----- > From: "Laszlo Hornyak" <lhornyak@redhat.com> > To: "engine-devel" <engine-devel@ovirt.org> > Cc: "Vojtech Szocs" <vszocs@redhat.com> > Sent: Wednesday, July 18, 2012 5:43:34 PM > Subject: java 1.6 compatibility no more? > > Hi, > > It may be a historic moment, but for a few hours oVirt engine > is no longer building on java 1.6. > Is this intentional? > > Laszlo
-- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 19/07/12 14:41, Juan Hernandez wrote:
On 07/19/2012 01:39 PM, Yair Zaslavsky wrote:
On 07/19/2012 02:31 PM, Vojtech Szocs wrote:
Don't we need that (the source part) to avoid Java 7 syntax in GWT code?
That's a very good point.
In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail.
So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however.
We could do something like this:
- let oVirt root POM declare source and target compliance to Java 7 - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6)
(note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code)
What do you think?
Vojtech
+1 - I really like this idea!
+1 from me as well.
There are two calls to make when it comes to JDK7 (regardless of GWT - excuse me for taking this discussion some steps backwards) 1. Are we running with JRE 7? The answer is yes we agreed on that a few months ago. 2. Are we using code syntax which is incompatible with JDK6? I think the answer to the above should be no (at least for now - maybe until the next ovirt release?). There are two reason off the top of my head for that - If we find an issue it is easier to compare the issue on JDK6 vs. JDK7 if the code compiles on both. Open JDK7 is out for a year or so, It was packaged for fedora only in March 2012, I am not sure how ofter it is used in 'production' environment, I think we should at least keep ourself the option to roll-back in case we need it. Livnat
----- Original Message ----- From: "Juan Hernandez" <jhernand@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "Yair Zaslavsky" <yzaslavs@redhat.com>, engine-devel@ovirt.org Sent: Thursday, July 19, 2012 11:01:00 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/19/2012 10:09 AM, Vojtech Szocs wrote:
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well?
If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance.
Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build.
Don't we need that (the source part) to avoid Java 7 syntax in GWT code?
----- Original Message ----- From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 7:59:45 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/18/2012 08:21 PM, Juan Hernandez wrote:
On 07/18/2012 06:33 PM, Vojtech Szocs wrote:
In fact, for both backend and frontend, Maven effective POM contains:
<artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> </configuration>
Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?)
These maven settings just tell the java compiler to accept Java 6 syntax only and to generate a Java 6 compatible .class file format, but they don't restrict the set of APIs that can be used.
The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method.
I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method).
Vojtech
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
----- Original Message ----- From: "Laszlo Hornyak" <lhornyak@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Cc: "Vojtech Szocs" <vszocs@redhat.com> Sent: Wednesday, July 18, 2012 5:43:34 PM Subject: java 1.6 compatibility no more?
Hi,
It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. Is this intentional?
Laszlo
On Jul 19, 2012, at 14:14 , Livnat Peer wrote:
On 19/07/12 14:41, Juan Hernandez wrote:
On 07/19/2012 01:39 PM, Yair Zaslavsky wrote:
On 07/19/2012 02:31 PM, Vojtech Szocs wrote:
Don't we need that (the source part) to avoid Java 7 syntax in GWT code?
That's a very good point.
In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail.
So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however.
We could do something like this:
- let oVirt root POM declare source and target compliance to Java 7 - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6)
(note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code)
What do you think?
Vojtech
+1 - I really like this idea!
+1 from me as well.
There are two calls to make when it comes to JDK7 (regardless of GWT - excuse me for taking this discussion some steps backwards)
1. Are we running with JRE 7? The answer is yes we agreed on that a few months ago.
2. Are we using code syntax which is incompatible with JDK6?
I think the answer to the above should be no (at least for now - maybe until the next ovirt release?). +1 exactly. Why starting with jdk6 incompatible constructs unless there is a good (or at least any) reason for them…
There are two reason off the top of my head for that - If we find an issue it is easier to compare the issue on JDK6 vs. JDK7 if the code compiles on both.
Open JDK7 is out for a year or so, It was packaged for fedora only in March 2012, I am not sure how ofter it is used in 'production' environment, I think we should at least keep ourself the option to roll-back in case we need it.
Livnat
----- Original Message ----- From: "Juan Hernandez" <jhernand@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "Yair Zaslavsky" <yzaslavs@redhat.com>, engine-devel@ovirt.org Sent: Thursday, July 19, 2012 11:01:00 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/19/2012 10:09 AM, Vojtech Szocs wrote:
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well?
If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance.
Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build.
Don't we need that (the source part) to avoid Java 7 syntax in GWT code?
----- Original Message ----- From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 7:59:45 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/18/2012 08:21 PM, Juan Hernandez wrote:
On 07/18/2012 06:33 PM, Vojtech Szocs wrote: > In fact, for both backend and frontend, Maven effective POM contains: > > <artifactId>maven-compiler-plugin</artifactId> > <configuration> > <source>1.6</source> > <target>1.6</target> > </configuration> > > Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?)
These maven settings just tell the java compiler to accept Java 6 syntax only and to generate a Java 6 compatible .class file format, but they don't restrict the set of APIs that can be used.
> The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method. > > I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method). > > Vojtech
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
> > > ----- Original Message ----- > From: "Laszlo Hornyak" <lhornyak@redhat.com> > To: "engine-devel" <engine-devel@ovirt.org> > Cc: "Vojtech Szocs" <vszocs@redhat.com> > Sent: Wednesday, July 18, 2012 5:43:34 PM > Subject: java 1.6 compatibility no more? > > Hi, > > It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. > Is this intentional? > > Laszlo
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
On Jul 19, 2012, at 14:14 , Livnat Peer wrote:
On 19/07/12 14:41, Juan Hernandez wrote:
On 07/19/2012 01:39 PM, Yair Zaslavsky wrote:
On 07/19/2012 02:31 PM, Vojtech Szocs wrote:
Don't we need that (the source part) to avoid Java 7 syntax in GWT code?
That's a very good point.
In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail.
So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however.
We could do something like this:
- let oVirt root POM declare source and target compliance to Java 7 - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6)
(note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code)
What do you think?
Vojtech
+1 - I really like this idea!
+1 from me as well.
There are two calls to make when it comes to JDK7 (regardless of GWT - excuse me for taking this discussion some steps backwards)
1. Are we running with JRE 7? The answer is yes we agreed on that a few months ago.
2. Are we using code syntax which is incompatible with JDK6?
I think the answer to the above should be no (at least for now - maybe until the next ovirt release?). +1 exactly. Why starting with jdk6 incompatible constructs unless there is a good (or at least any) reason for them…
+1
There are two reason off the top of my head for that - If we find an issue it is easier to compare the issue on JDK6 vs. JDK7 if the code compiles on both.
Open JDK7 is out for a year or so, It was packaged for fedora only in March 2012, I am not sure how ofter it is used in 'production' environment, I think we should at least keep ourself the option to roll-back in case we need it.
Livnat
----- Original Message ----- From: "Juan Hernandez" <jhernand@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "Yair Zaslavsky" <yzaslavs@redhat.com>, engine-devel@ovirt.org Sent: Thursday, July 19, 2012 11:01:00 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/19/2012 10:09 AM, Vojtech Szocs wrote:
> As I previously emailed - JDK7 already fixed a known issue > with ldap and > DNS ,and made one of my patches at gerrit redundant. > Why not enjoy the bug fixes?
I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well?
If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance.
Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build.
Don't we need that (the source part) to avoid Java 7 syntax in GWT code?
----- Original Message ----- From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 7:59:45 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/18/2012 08:21 PM, Juan Hernandez wrote: > On 07/18/2012 06:33 PM, Vojtech Szocs wrote: >> In fact, for both backend and frontend, Maven effective POM >> contains: >> >> <artifactId>maven-compiler-plugin</artifactId> >> <configuration> >> <source>1.6</source> >> <target>1.6</target> >> </configuration> >> >> Therefore, according to Maven POM files, oVirt should be >> build-able using Java 6, but it's not. (?) > > These maven settings just tell the java compiler to accept > Java 6 syntax > only and to generate a Java 6 compatible .class file format, > but they > don't restrict the set of APIs that can be used. > >> The problem is in backend/manager/modules/bll: >> StorageDomainCommandBase class uses new Java 7 >> Long.compare() static method. >> >> I think we should decide if we want to be compliant with Java >> 7, or submit a patch that uses Java 6 API (Long.compareTo >> instance method). >> >> Vojtech
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
>> >> >> ----- Original Message ----- >> From: "Laszlo Hornyak" <lhornyak@redhat.com> >> To: "engine-devel" <engine-devel@ovirt.org> >> Cc: "Vojtech Szocs" <vszocs@redhat.com> >> Sent: Wednesday, July 18, 2012 5:43:34 PM >> Subject: java 1.6 compatibility no more? >> >> Hi, >> >> It may be a historic moment, but for a few hours oVirt engine >> is no longer building on java 1.6. >> Is this intentional? >> >> Laszlo
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 07/19/2012 03:34 PM, Ayal Baron wrote:
----- Original Message -----
On Jul 19, 2012, at 14:14 , Livnat Peer wrote:
On 19/07/12 14:41, Juan Hernandez wrote:
On 07/19/2012 01:39 PM, Yair Zaslavsky wrote:
On 07/19/2012 02:31 PM, Vojtech Szocs wrote:
> Don't we need that (the source part) to avoid Java 7 syntax in > GWT code?
That's a very good point.
In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail.
So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however.
We could do something like this:
- let oVirt root POM declare source and target compliance to Java 7 - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6)
(note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code)
What do you think?
Vojtech
+1 - I really like this idea!
+1 from me as well.
There are two calls to make when it comes to JDK7 (regardless of GWT - excuse me for taking this discussion some steps backwards)
1. Are we running with JRE 7? The answer is yes we agreed on that a few months ago.
2. Are we using code syntax which is incompatible with JDK6?
I think the answer to the above should be no (at least for now - maybe until the next ovirt release?). +1 exactly. Why starting with jdk6 incompatible constructs unless there is a good (or at least any) reason for them…
+1
+1 - there is merit keeping backward compatibility to allow comparing behavior while java 7 is still young.
On 21/07/12 15:15, Itamar Heim wrote:
On 07/19/2012 03:34 PM, Ayal Baron wrote:
----- Original Message -----
On Jul 19, 2012, at 14:14 , Livnat Peer wrote:
On 19/07/12 14:41, Juan Hernandez wrote:
On 07/19/2012 01:39 PM, Yair Zaslavsky wrote:
On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >> Don't we need that (the source part) to avoid Java 7 syntax in >> GWT code? > > That's a very good point. > > In general, GWT compiler supports Java 5 syntax (note that there > are no language changes between Java 5 and 6). For this reason, > our frontend code should be compliant with Java 5. If someone > uses new Java 7 language features in frontend code, GWT > compiler will throw an error and the build will fail. > > So the 'Java 5 only' limitation applies to frontend code and any > other code (e.g. shared modules) that is directly referenced by > frontend code. This shouldn't affect the backend, however. > > We could do something like this: > > - let oVirt root POM declare source and target compliance to > Java 7 > - let frontend modules POM (frontend/webadmin/modules/pom.xml) > declare source compliance to Java 5 (or 6) > > (note that target compliance can be left to Java 7 since > frontend compilation results in JavaScript code) > > What do you think? > > Vojtech
+1 - I really like this idea!
+1 from me as well.
There are two calls to make when it comes to JDK7 (regardless of GWT - excuse me for taking this discussion some steps backwards)
1. Are we running with JRE 7? The answer is yes we agreed on that a few months ago.
2. Are we using code syntax which is incompatible with JDK6?
I think the answer to the above should be no (at least for now - maybe until the next ovirt release?). +1 exactly. Why starting with jdk6 incompatible constructs unless there is a good (or at least any) reason for them…
+1
+1 - there is merit keeping backward compatibility to allow comparing behavior while java 7 is still young.
Since no one objected, we'll go with JDK6 syntax compatibility for Now. Kublin - can you please send a patch to remove the usage of Long.Compare in StorageDomainCommandBase Thanks, Livnat
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Itamar Heim" <iheim@redhat.com>, "Michael Kublin" <mkublin@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org Sent: Sunday, July 22, 2012 9:50:47 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 21/07/12 15:15, Itamar Heim wrote:
On 07/19/2012 03:34 PM, Ayal Baron wrote:
----- Original Message -----
On Jul 19, 2012, at 14:14 , Livnat Peer wrote:
On 19/07/12 14:41, Juan Hernandez wrote:
On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: > On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>> Don't we need that (the source part) to avoid Java 7 syntax >>> in >>> GWT code? >> >> That's a very good point. >> >> In general, GWT compiler supports Java 5 syntax (note that >> there >> are no language changes between Java 5 and 6). For this >> reason, >> our frontend code should be compliant with Java 5. If someone >> uses new Java 7 language features in frontend code, GWT >> compiler will throw an error and the build will fail. >> >> So the 'Java 5 only' limitation applies to frontend code and >> any >> other code (e.g. shared modules) that is directly referenced >> by >> frontend code. This shouldn't affect the backend, however. >> >> We could do something like this: >> >> - let oVirt root POM declare source and target compliance to >> Java 7 >> - let frontend modules POM >> (frontend/webadmin/modules/pom.xml) >> declare source compliance to Java 5 (or 6) >> >> (note that target compliance can be left to Java 7 since >> frontend compilation results in JavaScript code) >> >> What do you think? >> >> Vojtech > > +1 - I really like this idea!
+1 from me as well.
There are two calls to make when it comes to JDK7 (regardless of GWT - excuse me for taking this discussion some steps backwards)
1. Are we running with JRE 7? The answer is yes we agreed on that a few months ago.
2. Are we using code syntax which is incompatible with JDK6?
I think the answer to the above should be no (at least for now - maybe until the next ovirt release?). +1 exactly. Why starting with jdk6 incompatible constructs unless there is a good (or at least any) reason for them…
+1
+1 - there is merit keeping backward compatibility to allow comparing behavior while java 7 is still young.
Since no one objected, we'll go with JDK6 syntax compatibility for Now. I'm a very small fan of enforcing policy by reviewers. Not that the community reviews aren't great - but people miss things.
Here's my take on Maven's enforcer plugin to actually verify we aren't compiling with JDK 7: http://gerrit.ovirt.org/#/c/6523 comments welcome.
Kublin - can you please send a patch to remove the usage of Long.Compare in StorageDomainCommandBase
Thanks, Livnat
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 07/22/2012 07:38 PM, Allon Mureinik wrote:
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Itamar Heim" <iheim@redhat.com>, "Michael Kublin" <mkublin@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org Sent: Sunday, July 22, 2012 9:50:47 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 21/07/12 15:15, Itamar Heim wrote:
On 07/19/2012 03:34 PM, Ayal Baron wrote:
----- Original Message -----
On Jul 19, 2012, at 14:14 , Livnat Peer wrote:
On 19/07/12 14:41, Juan Hernandez wrote: > On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>> Don't we need that (the source part) to avoid Java 7 syntax >>>> in >>>> GWT code? >>> >>> That's a very good point. >>> >>> In general, GWT compiler supports Java 5 syntax (note that >>> there >>> are no language changes between Java 5 and 6). For this >>> reason, >>> our frontend code should be compliant with Java 5. If someone >>> uses new Java 7 language features in frontend code, GWT >>> compiler will throw an error and the build will fail. >>> >>> So the 'Java 5 only' limitation applies to frontend code and >>> any >>> other code (e.g. shared modules) that is directly referenced >>> by >>> frontend code. This shouldn't affect the backend, however. >>> >>> We could do something like this: >>> >>> - let oVirt root POM declare source and target compliance to >>> Java 7 >>> - let frontend modules POM >>> (frontend/webadmin/modules/pom.xml) >>> declare source compliance to Java 5 (or 6) >>> >>> (note that target compliance can be left to Java 7 since >>> frontend compilation results in JavaScript code) >>> >>> What do you think? >>> >>> Vojtech >> >> +1 - I really like this idea! > > +1 from me as well.
There are two calls to make when it comes to JDK7 (regardless of GWT - excuse me for taking this discussion some steps backwards)
1. Are we running with JRE 7? The answer is yes we agreed on that a few months ago.
2. Are we using code syntax which is incompatible with JDK6?
I think the answer to the above should be no (at least for now - maybe until the next ovirt release?). +1 exactly. Why starting with jdk6 incompatible constructs unless there is a good (or at least any) reason for them…
+1
+1 - there is merit keeping backward compatibility to allow comparing behavior while java 7 is still young.
Since no one objected, we'll go with JDK6 syntax compatibility for Now. I'm a very small fan of enforcing policy by reviewers. Not that the community reviews aren't great - but people miss things.
Here's my take on Maven's enforcer plugin to actually verify we aren't compiling with JDK 7: http://gerrit.ovirt.org/#/c/6523
we don't want to enforce compilation or run with JDK 6, only to preserve backward compatibility. I'm for jenkins to have a job to compile and run unitests with openjdk 6 to be on the safe side.
comments welcome.
Kublin - can you please send a patch to remove the usage of Long.Compare in StorageDomainCommandBase
Thanks, Livnat
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
On 07/22/2012 07:38 PM, Allon Mureinik wrote:
From: "Livnat Peer" <lpeer@redhat.com> To: "Itamar Heim" <iheim@redhat.com>, "Michael Kublin" <mkublin@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org Sent: Sunday, July 22, 2012 9:50:47 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 21/07/12 15:15, Itamar Heim wrote:
On 07/19/2012 03:34 PM, Ayal Baron wrote:
----- Original Message -----
On Jul 19, 2012, at 14:14 , Livnat Peer wrote:
> On 19/07/12 14:41, Juan Hernandez wrote: >> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>>> Don't we need that (the source part) to avoid Java 7 >>>>> syntax >>>>> in >>>>> GWT code? >>>> >>>> That's a very good point. >>>> >>>> In general, GWT compiler supports Java 5 syntax (note that >>>> there >>>> are no language changes between Java 5 and 6). For this >>>> reason, >>>> our frontend code should be compliant with Java 5. If >>>> someone >>>> uses new Java 7 language features in frontend code, GWT >>>> compiler will throw an error and the build will fail. >>>> >>>> So the 'Java 5 only' limitation applies to frontend code >>>> and >>>> any >>>> other code (e.g. shared modules) that is directly >>>> referenced >>>> by >>>> frontend code. This shouldn't affect the backend, however. >>>> >>>> We could do something like this: >>>> >>>> - let oVirt root POM declare source and target compliance >>>> to >>>> Java 7 >>>> - let frontend modules POM >>>> (frontend/webadmin/modules/pom.xml) >>>> declare source compliance to Java 5 (or 6) >>>> >>>> (note that target compliance can be left to Java 7 since >>>> frontend compilation results in JavaScript code) >>>> >>>> What do you think? >>>> >>>> Vojtech >>> >>> +1 - I really like this idea! >> >> +1 from me as well. > > > There are two calls to make when it comes to JDK7 (regardless > of > GWT - > excuse me for taking this discussion some steps backwards) > > 1. Are we running with JRE 7? > The answer is yes we agreed on that a few months ago. > > 2. Are we using code syntax which is incompatible with JDK6? > > I think the answer to the above should be no (at least for now > - > maybe > until the next ovirt release?). +1 exactly. Why starting with jdk6 incompatible constructs unless there is a good (or at least any) reason for them…
+1
+1 - there is merit keeping backward compatibility to allow comparing behavior while java 7 is still young.
Since no one objected, we'll go with JDK6 syntax compatibility for Now. I'm a very small fan of enforcing policy by reviewers. Not that the community reviews aren't great - but people miss
----- Original Message ----- things.
Here's my take on Maven's enforcer plugin to actually verify we aren't compiling with JDK 7: http://gerrit.ovirt.org/#/c/6523
we don't want to enforce compilation or run with JDK 6, only to preserve backward compatibility. I'm for jenkins to have a job to compile and run unitests with openjdk 6 to be on the safe side.
Instead of enforcing the compilation to be run with a specific jdk we can enforce that the code is java 6 compatible with: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.0.2</version> <configuration> <source>1.6</source> <target>1.6</target> </configuration> </plugin>
comments welcome.
Kublin - can you please send a patch to remove the usage of Long.Compare in StorageDomainCommandBase
Thanks, Livnat
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Ayal Baron" <abaron@redhat.com> To: "Itamar Heim" <iheim@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org, "Allon Mureinik" <amureini@redhat.com> Sent: Sunday, July 22, 2012 8:34:32 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
----- Original Message -----
On 07/22/2012 07:38 PM, Allon Mureinik wrote:
From: "Livnat Peer" <lpeer@redhat.com> To: "Itamar Heim" <iheim@redhat.com>, "Michael Kublin" <mkublin@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org Sent: Sunday, July 22, 2012 9:50:47 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 21/07/12 15:15, Itamar Heim wrote:
On 07/19/2012 03:34 PM, Ayal Baron wrote:
----- Original Message ----- > > On Jul 19, 2012, at 14:14 , Livnat Peer wrote: > >> On 19/07/12 14:41, Juan Hernandez wrote: >>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>>>> Don't we need that (the source part) to avoid Java 7 >>>>>> syntax >>>>>> in >>>>>> GWT code? >>>>> >>>>> That's a very good point. >>>>> >>>>> In general, GWT compiler supports Java 5 syntax (note >>>>> that >>>>> there >>>>> are no language changes between Java 5 and 6). For this >>>>> reason, >>>>> our frontend code should be compliant with Java 5. If >>>>> someone >>>>> uses new Java 7 language features in frontend code, GWT >>>>> compiler will throw an error and the build will fail. >>>>> >>>>> So the 'Java 5 only' limitation applies to frontend code >>>>> and >>>>> any >>>>> other code (e.g. shared modules) that is directly >>>>> referenced >>>>> by >>>>> frontend code. This shouldn't affect the backend, >>>>> however. >>>>> >>>>> We could do something like this: >>>>> >>>>> - let oVirt root POM declare source and target compliance >>>>> to >>>>> Java 7 >>>>> - let frontend modules POM >>>>> (frontend/webadmin/modules/pom.xml) >>>>> declare source compliance to Java 5 (or 6) >>>>> >>>>> (note that target compliance can be left to Java 7 since >>>>> frontend compilation results in JavaScript code) >>>>> >>>>> What do you think? >>>>> >>>>> Vojtech >>>> >>>> +1 - I really like this idea! >>> >>> +1 from me as well. >> >> >> There are two calls to make when it comes to JDK7 >> (regardless >> of >> GWT - >> excuse me for taking this discussion some steps backwards) >> >> 1. Are we running with JRE 7? >> The answer is yes we agreed on that a few months ago. >> >> 2. Are we using code syntax which is incompatible with JDK6? >> >> I think the answer to the above should be no (at least for >> now >> - >> maybe >> until the next ovirt release?). > +1 > exactly. Why starting with jdk6 incompatible constructs > unless > there > is a good (or at least any) reason for them…
+1
+1 - there is merit keeping backward compatibility to allow comparing behavior while java 7 is still young.
Since no one objected, we'll go with JDK6 syntax compatibility for Now. I'm a very small fan of enforcing policy by reviewers. Not that the community reviews aren't great - but people miss
----- Original Message ----- things.
Here's my take on Maven's enforcer plugin to actually verify we aren't compiling with JDK 7: http://gerrit.ovirt.org/#/c/6523
we don't want to enforce compilation or run with JDK 6, only to preserve backward compatibility. I'm for jenkins to have a job to compile and run unitests with openjdk 6 to be on the safe side.
Instead of enforcing the compilation to be run with a specific jdk we can enforce that the code is java 6 compatible with:
<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>2.0.2</version> <configuration> <source>1.6</source> <target>1.6</target> </configuration> </plugin>
No, this is not the issue we're discussing. The source and target configurations in the maven-compiler-plugin specify the language level compatibility (i.e., syntax) you're using. This setting only means you won't be able to use Java 7 new syntactic constructs like catching multiple exceptions with the pipe operator and shorthand generics. This has nothing to do with the JDK. The JDK is just a collection of jars, like any other jar, which just happen to contain some fundamental classes like Object, String and Long. Our case here is to force developers not use any methods/classes that aren't present in /JDK 6/. Just to prove the point - if you take a look at lines 367-368 of the master pom.xml, you'll notice we already have these settings, and have had them since oVirt's git repo was created.
comments welcome.
Kublin - can you please send a patch to remove the usage of Long.Compare in StorageDomainCommandBase
Thanks, Livnat
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Allon Mureinik" <amureini@redhat.com> Cc: "Livnat Peer" <lpeer@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org, "Michael Kublin" <mkublin@redhat.com> Sent: Sunday, July 22, 2012 7:41:00 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/22/2012 07:38 PM, Allon Mureinik wrote:
From: "Livnat Peer" <lpeer@redhat.com> To: "Itamar Heim" <iheim@redhat.com>, "Michael Kublin" <mkublin@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org Sent: Sunday, July 22, 2012 9:50:47 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 21/07/12 15:15, Itamar Heim wrote:
On 07/19/2012 03:34 PM, Ayal Baron wrote:
----- Original Message -----
On Jul 19, 2012, at 14:14 , Livnat Peer wrote:
> On 19/07/12 14:41, Juan Hernandez wrote: >> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>>> Don't we need that (the source part) to avoid Java 7 >>>>> syntax >>>>> in >>>>> GWT code? >>>> >>>> That's a very good point. >>>> >>>> In general, GWT compiler supports Java 5 syntax (note that >>>> there >>>> are no language changes between Java 5 and 6). For this >>>> reason, >>>> our frontend code should be compliant with Java 5. If >>>> someone >>>> uses new Java 7 language features in frontend code, GWT >>>> compiler will throw an error and the build will fail. >>>> >>>> So the 'Java 5 only' limitation applies to frontend code >>>> and >>>> any >>>> other code (e.g. shared modules) that is directly >>>> referenced >>>> by >>>> frontend code. This shouldn't affect the backend, however. >>>> >>>> We could do something like this: >>>> >>>> - let oVirt root POM declare source and target compliance >>>> to >>>> Java 7 >>>> - let frontend modules POM >>>> (frontend/webadmin/modules/pom.xml) >>>> declare source compliance to Java 5 (or 6) >>>> >>>> (note that target compliance can be left to Java 7 since >>>> frontend compilation results in JavaScript code) >>>> >>>> What do you think? >>>> >>>> Vojtech >>> >>> +1 - I really like this idea! >> >> +1 from me as well. > > > There are two calls to make when it comes to JDK7 (regardless > of > GWT - > excuse me for taking this discussion some steps backwards) > > 1. Are we running with JRE 7? > The answer is yes we agreed on that a few months ago. > > 2. Are we using code syntax which is incompatible with JDK6? > > I think the answer to the above should be no (at least for now > - > maybe > until the next ovirt release?). +1 exactly. Why starting with jdk6 incompatible constructs unless there is a good (or at least any) reason for them…
+1
+1 - there is merit keeping backward compatibility to allow comparing behavior while java 7 is still young.
Since no one objected, we'll go with JDK6 syntax compatibility for Now. I'm a very small fan of enforcing policy by reviewers. Not that the community reviews aren't great - but people miss
----- Original Message ----- things.
Here's my take on Maven's enforcer plugin to actually verify we aren't compiling with JDK 7: http://gerrit.ovirt.org/#/c/6523
we don't want to enforce compilation or run with JDK 6, only to preserve backward compatibility. I'm for jenkins to have a job to compile and run unitests with openjdk 6 to be on the safe side.
I don't understand this suggestion. What you're saying is that you can compile with whatever JDK you want, but: - it won't compile with JDKs prior to 6, since we're using 6's features. - you aren't allowed to use JDK 7 features, and if you do, you'll get an email from jenkins that you broke something and must fix it. To me, this sounds a lot like enforcing JDK 6 compatibility. /today/ if have way too many (i.e., >0) jenkins breaks, a lot of which could be avoided by not running with -DskipTetst or making sure to run with -Penable-dao-tests. I fear this suggestion will just add to this "noise", and could easily be avoided.
comments welcome.
Kublin - can you please send a patch to remove the usage of Long.Compare in StorageDomainCommandBase
Thanks, Livnat
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 07/23/2012 08:29 AM, Allon Mureinik wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Allon Mureinik" <amureini@redhat.com> Cc: "Livnat Peer" <lpeer@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org, "Michael Kublin" <mkublin@redhat.com> Sent: Sunday, July 22, 2012 7:41:00 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/22/2012 07:38 PM, Allon Mureinik wrote:
From: "Livnat Peer" <lpeer@redhat.com> To: "Itamar Heim" <iheim@redhat.com>, "Michael Kublin" <mkublin@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org Sent: Sunday, July 22, 2012 9:50:47 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 21/07/12 15:15, Itamar Heim wrote:
On 07/19/2012 03:34 PM, Ayal Baron wrote:
----- Original Message ----- > > On Jul 19, 2012, at 14:14 , Livnat Peer wrote: > >> On 19/07/12 14:41, Juan Hernandez wrote: >>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>>>> Don't we need that (the source part) to avoid Java 7 >>>>>> syntax >>>>>> in >>>>>> GWT code? >>>>> >>>>> That's a very good point. >>>>> >>>>> In general, GWT compiler supports Java 5 syntax (note that >>>>> there >>>>> are no language changes between Java 5 and 6). For this >>>>> reason, >>>>> our frontend code should be compliant with Java 5. If >>>>> someone >>>>> uses new Java 7 language features in frontend code, GWT >>>>> compiler will throw an error and the build will fail. >>>>> >>>>> So the 'Java 5 only' limitation applies to frontend code >>>>> and >>>>> any >>>>> other code (e.g. shared modules) that is directly >>>>> referenced >>>>> by >>>>> frontend code. This shouldn't affect the backend, however. >>>>> >>>>> We could do something like this: >>>>> >>>>> - let oVirt root POM declare source and target compliance >>>>> to >>>>> Java 7 >>>>> - let frontend modules POM >>>>> (frontend/webadmin/modules/pom.xml) >>>>> declare source compliance to Java 5 (or 6) >>>>> >>>>> (note that target compliance can be left to Java 7 since >>>>> frontend compilation results in JavaScript code) >>>>> >>>>> What do you think? >>>>> >>>>> Vojtech >>>> >>>> +1 - I really like this idea! >>> >>> +1 from me as well. >> >> >> There are two calls to make when it comes to JDK7 (regardless >> of >> GWT - >> excuse me for taking this discussion some steps backwards) >> >> 1. Are we running with JRE 7? >> The answer is yes we agreed on that a few months ago. >> >> 2. Are we using code syntax which is incompatible with JDK6? >> >> I think the answer to the above should be no (at least for now >> - >> maybe >> until the next ovirt release?). > +1 > exactly. Why starting with jdk6 incompatible constructs unless > there > is a good (or at least any) reason for them…
+1
+1 - there is merit keeping backward compatibility to allow comparing behavior while java 7 is still young.
Since no one objected, we'll go with JDK6 syntax compatibility for Now. I'm a very small fan of enforcing policy by reviewers. Not that the community reviews aren't great - but people miss
----- Original Message ----- things.
Here's my take on Maven's enforcer plugin to actually verify we aren't compiling with JDK 7: http://gerrit.ovirt.org/#/c/6523
we don't want to enforce compilation or run with JDK 6, only to preserve backward compatibility. I'm for jenkins to have a job to compile and run unitests with openjdk 6 to be on the safe side.
I don't understand this suggestion. What you're saying is that you can compile with whatever JDK you want, but: - it won't compile with JDKs prior to 6, since we're using 6's features. - you aren't allowed to use JDK 7 features, and if you do, you'll get an email from jenkins that you broke something and must fix it.
To me, this sounds a lot like enforcing JDK 6 compatibility.
its preserving jdk 6 compatibility for a few more months, not enforcing to use jdk 6 compiler.
/today/ if have way too many (i.e., >0) jenkins breaks, a lot of which could be avoided by not running with -DskipTetst or making sure to run with -Penable-dao-tests. I fear this suggestion will just add to this "noise", and could easily be avoided.
jenkins breaks should be visible at patch level prior to commit, something we are trying to resolve by adding more hardware to allow running the various tests at patch level rather than post commit only.
comments welcome.
Kublin - can you please send a patch to remove the usage of Long.Compare in StorageDomainCommandBase
Thanks, Livnat
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Allon Mureinik" <amureini@redhat.com> Cc: "Livnat Peer" <lpeer@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org, "Michael Kublin" <mkublin@redhat.com> Sent: Monday, July 23, 2012 8:43:02 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/23/2012 08:29 AM, Allon Mureinik wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Allon Mureinik" <amureini@redhat.com> Cc: "Livnat Peer" <lpeer@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org, "Michael Kublin" <mkublin@redhat.com> Sent: Sunday, July 22, 2012 7:41:00 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/22/2012 07:38 PM, Allon Mureinik wrote:
From: "Livnat Peer" <lpeer@redhat.com> To: "Itamar Heim" <iheim@redhat.com>, "Michael Kublin" <mkublin@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org Sent: Sunday, July 22, 2012 9:50:47 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 21/07/12 15:15, Itamar Heim wrote:
On 07/19/2012 03:34 PM, Ayal Baron wrote: > > > ----- Original Message ----- >> >> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: >> >>> On 19/07/12 14:41, Juan Hernandez wrote: >>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>>>>> Don't we need that (the source part) to avoid Java 7 >>>>>>> syntax >>>>>>> in >>>>>>> GWT code? >>>>>> >>>>>> That's a very good point. >>>>>> >>>>>> In general, GWT compiler supports Java 5 syntax (note >>>>>> that >>>>>> there >>>>>> are no language changes between Java 5 and 6). For this >>>>>> reason, >>>>>> our frontend code should be compliant with Java 5. If >>>>>> someone >>>>>> uses new Java 7 language features in frontend code, GWT >>>>>> compiler will throw an error and the build will fail. >>>>>> >>>>>> So the 'Java 5 only' limitation applies to frontend code >>>>>> and >>>>>> any >>>>>> other code (e.g. shared modules) that is directly >>>>>> referenced >>>>>> by >>>>>> frontend code. This shouldn't affect the backend, >>>>>> however. >>>>>> >>>>>> We could do something like this: >>>>>> >>>>>> - let oVirt root POM declare source and target compliance >>>>>> to >>>>>> Java 7 >>>>>> - let frontend modules POM >>>>>> (frontend/webadmin/modules/pom.xml) >>>>>> declare source compliance to Java 5 (or 6) >>>>>> >>>>>> (note that target compliance can be left to Java 7 since >>>>>> frontend compilation results in JavaScript code) >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Vojtech >>>>> >>>>> +1 - I really like this idea! >>>> >>>> +1 from me as well. >>> >>> >>> There are two calls to make when it comes to JDK7 >>> (regardless >>> of >>> GWT - >>> excuse me for taking this discussion some steps backwards) >>> >>> 1. Are we running with JRE 7? >>> The answer is yes we agreed on that a few months ago. >>> >>> 2. Are we using code syntax which is incompatible with JDK6? >>> >>> I think the answer to the above should be no (at least for >>> now >>> - >>> maybe >>> until the next ovirt release?). >> +1 >> exactly. Why starting with jdk6 incompatible constructs >> unless >> there >> is a good (or at least any) reason for them… > > +1
+1 - there is merit keeping backward compatibility to allow comparing behavior while java 7 is still young.
Since no one objected, we'll go with JDK6 syntax compatibility for Now. I'm a very small fan of enforcing policy by reviewers. Not that the community reviews aren't great - but people miss
----- Original Message ----- things.
Here's my take on Maven's enforcer plugin to actually verify we aren't compiling with JDK 7: http://gerrit.ovirt.org/#/c/6523
we don't want to enforce compilation or run with JDK 6, only to preserve backward compatibility. I'm for jenkins to have a job to compile and run unitests with openjdk 6 to be on the safe side.
I don't understand this suggestion. What you're saying is that you can compile with whatever JDK you want, but: - it won't compile with JDKs prior to 6, since we're using 6's features. - you aren't allowed to use JDK 7 features, and if you do, you'll get an email from jenkins that you broke something and must fix it.
To me, this sounds a lot like enforcing JDK 6 compatibility.
its preserving jdk 6 compatibility for a few more months, not enforcing to use jdk 6 compiler. Fair enough.
/today/ if have way too many (i.e., >0) jenkins breaks, a lot of which could be avoided by not running with -DskipTetst or making sure to run with -Penable-dao-tests. I fear this suggestion will just add to this "noise", and could easily be avoided.
jenkins breaks should be visible at patch level prior to commit, something we are trying to resolve by adding more hardware to allow running the various tests at patch level rather than post commit only.
I agree that this is an excellent goal, but I maintain that this is an uncomfortable way to work. I would still like a way to check, on my own machine, as part of my compilation process, that I'm not doing anything I shouldn't. Here's my second take on the issue, using Animal Sniffer (http://mojo.codehaus.org/animal-sniffer/): http://gerrit.ovirt.org/#/c/6540 Again, comments welcome.
comments welcome.
Kublin - can you please send a patch to remove the usage of Long.Compare in StorageDomainCommandBase
Thanks, Livnat
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 07/23/2012 11:46 AM, Allon Mureinik wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Allon Mureinik" <amureini@redhat.com> Cc: "Livnat Peer" <lpeer@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org, "Michael Kublin" <mkublin@redhat.com> Sent: Monday, July 23, 2012 8:43:02 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/23/2012 08:29 AM, Allon Mureinik wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Allon Mureinik" <amureini@redhat.com> Cc: "Livnat Peer" <lpeer@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org, "Michael Kublin" <mkublin@redhat.com> Sent: Sunday, July 22, 2012 7:41:00 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/22/2012 07:38 PM, Allon Mureinik wrote:
From: "Livnat Peer" <lpeer@redhat.com> To: "Itamar Heim" <iheim@redhat.com>, "Michael Kublin" <mkublin@redhat.com> Cc: "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org Sent: Sunday, July 22, 2012 9:50:47 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 21/07/12 15:15, Itamar Heim wrote: > On 07/19/2012 03:34 PM, Ayal Baron wrote: >> >> >> ----- Original Message ----- >>> >>> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: >>> >>>> On 19/07/12 14:41, Juan Hernandez wrote: >>>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >>>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>>>>>> Don't we need that (the source part) to avoid Java 7 >>>>>>>> syntax >>>>>>>> in >>>>>>>> GWT code? >>>>>>> >>>>>>> That's a very good point. >>>>>>> >>>>>>> In general, GWT compiler supports Java 5 syntax (note >>>>>>> that >>>>>>> there >>>>>>> are no language changes between Java 5 and 6). For this >>>>>>> reason, >>>>>>> our frontend code should be compliant with Java 5. If >>>>>>> someone >>>>>>> uses new Java 7 language features in frontend code, GWT >>>>>>> compiler will throw an error and the build will fail. >>>>>>> >>>>>>> So the 'Java 5 only' limitation applies to frontend code >>>>>>> and >>>>>>> any >>>>>>> other code (e.g. shared modules) that is directly >>>>>>> referenced >>>>>>> by >>>>>>> frontend code. This shouldn't affect the backend, >>>>>>> however. >>>>>>> >>>>>>> We could do something like this: >>>>>>> >>>>>>> - let oVirt root POM declare source and target compliance >>>>>>> to >>>>>>> Java 7 >>>>>>> - let frontend modules POM >>>>>>> (frontend/webadmin/modules/pom.xml) >>>>>>> declare source compliance to Java 5 (or 6) >>>>>>> >>>>>>> (note that target compliance can be left to Java 7 since >>>>>>> frontend compilation results in JavaScript code) >>>>>>> >>>>>>> What do you think? >>>>>>> >>>>>>> Vojtech >>>>>> >>>>>> +1 - I really like this idea! >>>>> >>>>> +1 from me as well. >>>> >>>> >>>> There are two calls to make when it comes to JDK7 >>>> (regardless >>>> of >>>> GWT - >>>> excuse me for taking this discussion some steps backwards) >>>> >>>> 1. Are we running with JRE 7? >>>> The answer is yes we agreed on that a few months ago. >>>> >>>> 2. Are we using code syntax which is incompatible with JDK6? >>>> >>>> I think the answer to the above should be no (at least for >>>> now >>>> - >>>> maybe >>>> until the next ovirt release?). >>> +1 >>> exactly. Why starting with jdk6 incompatible constructs >>> unless >>> there >>> is a good (or at least any) reason for them… >> >> +1 > > +1 - there is merit keeping backward compatibility to allow > comparing > behavior while java 7 is still young.
Since no one objected, we'll go with JDK6 syntax compatibility for Now. I'm a very small fan of enforcing policy by reviewers. Not that the community reviews aren't great - but people miss
----- Original Message ----- things.
Here's my take on Maven's enforcer plugin to actually verify we aren't compiling with JDK 7: http://gerrit.ovirt.org/#/c/6523
we don't want to enforce compilation or run with JDK 6, only to preserve backward compatibility. I'm for jenkins to have a job to compile and run unitests with openjdk 6 to be on the safe side.
I don't understand this suggestion. What you're saying is that you can compile with whatever JDK you want, but: - it won't compile with JDKs prior to 6, since we're using 6's features. - you aren't allowed to use JDK 7 features, and if you do, you'll get an email from jenkins that you broke something and must fix it.
To me, this sounds a lot like enforcing JDK 6 compatibility.
its preserving jdk 6 compatibility for a few more months, not enforcing to use jdk 6 compiler. Fair enough.
/today/ if have way too many (i.e., >0) jenkins breaks, a lot of which could be avoided by not running with -DskipTetst or making sure to run with -Penable-dao-tests. I fear this suggestion will just add to this "noise", and could easily be avoided.
jenkins breaks should be visible at patch level prior to commit, something we are trying to resolve by adding more hardware to allow running the various tests at patch level rather than post commit only.
I agree that this is an excellent goal, but I maintain that this is an uncomfortable way to work. I would still like a way to check, on my own machine, as part of my compilation process, that I'm not doing anything I shouldn't. Here's my second take on the issue, using Animal Sniffer (http://mojo.codehaus.org/animal-sniffer/): http://gerrit.ovirt.org/#/c/6540
Again, comments welcome.
Before going ahead I would check that using it doesn't increase the already long compilation time to an unacceptable level. Also need to make sure that the new dependency is available in the build environments we use. I am specially concerned about the Fedora build system, where we have the plugin but not the signatures for the JDKs. This means that we will need to ignore the plugin or build the signatures ourselves. Also take into account that every new maven plugin we add to the POMs introduces new potential problems with the maven eclipse support. I think we can leave the decision to each developer, maybe providing an script that calls "mvn animal-sniffer:check ..." with the right parameters, maybe with git pre-commit hook, to make it more automatic. This combined with the Jenkins checks can be a good compromise. -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
On 07/23/2012 01:22 PM, Juan Hernandez wrote:
On 07/23/2012 11:46 AM, Allon Mureinik wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Allon Mureinik" <amureini@redhat.com> Cc: "Livnat Peer" <lpeer@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org, "Michael Kublin" <mkublin@redhat.com> Sent: Monday, July 23, 2012 8:43:02 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/23/2012 08:29 AM, Allon Mureinik wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Allon Mureinik" <amureini@redhat.com> Cc: "Livnat Peer" <lpeer@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org, "Michael Kublin" <mkublin@redhat.com> Sent: Sunday, July 22, 2012 7:41:00 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/22/2012 07:38 PM, Allon Mureinik wrote:
----- Original Message ----- > From: "Livnat Peer" <lpeer@redhat.com> > To: "Itamar Heim" <iheim@redhat.com>, "Michael Kublin" > <mkublin@redhat.com> > Cc: "Juan Hernandez" <jhernand@redhat.com>, > engine-devel@ovirt.org > Sent: Sunday, July 22, 2012 9:50:47 AM > Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > On 21/07/12 15:15, Itamar Heim wrote: >> On 07/19/2012 03:34 PM, Ayal Baron wrote: >>> >>> >>> ----- Original Message ----- >>>> >>>> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: >>>> >>>>> On 19/07/12 14:41, Juan Hernandez wrote: >>>>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >>>>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>>>>>>> Don't we need that (the source part) to avoid Java 7 >>>>>>>>> syntax >>>>>>>>> in >>>>>>>>> GWT code? >>>>>>>> >>>>>>>> That's a very good point. >>>>>>>> >>>>>>>> In general, GWT compiler supports Java 5 syntax (note >>>>>>>> that >>>>>>>> there >>>>>>>> are no language changes between Java 5 and 6). For this >>>>>>>> reason, >>>>>>>> our frontend code should be compliant with Java 5. If >>>>>>>> someone >>>>>>>> uses new Java 7 language features in frontend code, GWT >>>>>>>> compiler will throw an error and the build will fail. >>>>>>>> >>>>>>>> So the 'Java 5 only' limitation applies to frontend code >>>>>>>> and >>>>>>>> any >>>>>>>> other code (e.g. shared modules) that is directly >>>>>>>> referenced >>>>>>>> by >>>>>>>> frontend code. This shouldn't affect the backend, >>>>>>>> however. >>>>>>>> >>>>>>>> We could do something like this: >>>>>>>> >>>>>>>> - let oVirt root POM declare source and target compliance >>>>>>>> to >>>>>>>> Java 7 >>>>>>>> - let frontend modules POM >>>>>>>> (frontend/webadmin/modules/pom.xml) >>>>>>>> declare source compliance to Java 5 (or 6) >>>>>>>> >>>>>>>> (note that target compliance can be left to Java 7 since >>>>>>>> frontend compilation results in JavaScript code) >>>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>>> Vojtech >>>>>>> >>>>>>> +1 - I really like this idea! >>>>>> >>>>>> +1 from me as well. >>>>> >>>>> >>>>> There are two calls to make when it comes to JDK7 >>>>> (regardless >>>>> of >>>>> GWT - >>>>> excuse me for taking this discussion some steps backwards) >>>>> >>>>> 1. Are we running with JRE 7? >>>>> The answer is yes we agreed on that a few months ago. >>>>> >>>>> 2. Are we using code syntax which is incompatible with JDK6? >>>>> >>>>> I think the answer to the above should be no (at least for >>>>> now >>>>> - >>>>> maybe >>>>> until the next ovirt release?). >>>> +1 >>>> exactly. Why starting with jdk6 incompatible constructs >>>> unless >>>> there >>>> is a good (or at least any) reason for them… >>> >>> +1 >> >> +1 - there is merit keeping backward compatibility to allow >> comparing >> behavior while java 7 is still young. > > Since no one objected, we'll go with JDK6 syntax compatibility > for > Now. I'm a very small fan of enforcing policy by reviewers. Not that the community reviews aren't great - but people miss things.
Here's my take on Maven's enforcer plugin to actually verify we aren't compiling with JDK 7: http://gerrit.ovirt.org/#/c/6523
we don't want to enforce compilation or run with JDK 6, only to preserve backward compatibility. I'm for jenkins to have a job to compile and run unitests with openjdk 6 to be on the safe side.
I don't understand this suggestion. What you're saying is that you can compile with whatever JDK you want, but: - it won't compile with JDKs prior to 6, since we're using 6's features. - you aren't allowed to use JDK 7 features, and if you do, you'll get an email from jenkins that you broke something and must fix it.
To me, this sounds a lot like enforcing JDK 6 compatibility.
its preserving jdk 6 compatibility for a few more months, not enforcing to use jdk 6 compiler. Fair enough.
/today/ if have way too many (i.e., >0) jenkins breaks, a lot of which could be avoided by not running with -DskipTetst or making sure to run with -Penable-dao-tests. I fear this suggestion will just add to this "noise", and could easily be avoided.
jenkins breaks should be visible at patch level prior to commit, something we are trying to resolve by adding more hardware to allow running the various tests at patch level rather than post commit only.
I agree that this is an excellent goal, but I maintain that this is an uncomfortable way to work. I would still like a way to check, on my own machine, as part of my compilation process, that I'm not doing anything I shouldn't. Here's my second take on the issue, using Animal Sniffer (http://mojo.codehaus.org/animal-sniffer/): http://gerrit.ovirt.org/#/c/6540
Again, comments welcome.
Before going ahead I would check that using it doesn't increase the already long compilation time to an unacceptable level.
Also need to make sure that the new dependency is available in the build environments we use. I am specially concerned about the Fedora build system, where we have the plugin but not the signatures for the JDKs. This means that we will need to ignore the plugin or build the signatures ourselves.
Also take into account that every new maven plugin we add to the POMs introduces new potential problems with the maven eclipse support.
I think we can leave the decision to each developer, maybe providing an script that calls "mvn animal-sniffer:check ..." with the right parameters, maybe with git pre-commit hook, to make it more automatic. This combined with the Jenkins checks can be a good compromise.
we really need the jenkins checks on patches... I'll try to push this some more.
----- Original Message -----
From: "Juan Hernandez" <jhernand@redhat.com> To: "Allon Mureinik" <amureini@redhat.com> Cc: "Itamar Heim" <iheim@redhat.com>, engine-devel@ovirt.org Sent: Monday, July 23, 2012 1:22:37 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/23/2012 11:46 AM, Allon Mureinik wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Allon Mureinik" <amureini@redhat.com> Cc: "Livnat Peer" <lpeer@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org, "Michael Kublin" <mkublin@redhat.com> Sent: Monday, July 23, 2012 8:43:02 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/23/2012 08:29 AM, Allon Mureinik wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Allon Mureinik" <amureini@redhat.com> Cc: "Livnat Peer" <lpeer@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org, "Michael Kublin" <mkublin@redhat.com> Sent: Sunday, July 22, 2012 7:41:00 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/22/2012 07:38 PM, Allon Mureinik wrote:
----- Original Message ----- > From: "Livnat Peer" <lpeer@redhat.com> > To: "Itamar Heim" <iheim@redhat.com>, "Michael Kublin" > <mkublin@redhat.com> > Cc: "Juan Hernandez" <jhernand@redhat.com>, > engine-devel@ovirt.org > Sent: Sunday, July 22, 2012 9:50:47 AM > Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > On 21/07/12 15:15, Itamar Heim wrote: >> On 07/19/2012 03:34 PM, Ayal Baron wrote: >>> >>> >>> ----- Original Message ----- >>>> >>>> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: >>>> >>>>> On 19/07/12 14:41, Juan Hernandez wrote: >>>>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >>>>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>>>>>>> Don't we need that (the source part) to avoid Java 7 >>>>>>>>> syntax >>>>>>>>> in >>>>>>>>> GWT code? >>>>>>>> >>>>>>>> That's a very good point. >>>>>>>> >>>>>>>> In general, GWT compiler supports Java 5 syntax (note >>>>>>>> that >>>>>>>> there >>>>>>>> are no language changes between Java 5 and 6). For this >>>>>>>> reason, >>>>>>>> our frontend code should be compliant with Java 5. If >>>>>>>> someone >>>>>>>> uses new Java 7 language features in frontend code, GWT >>>>>>>> compiler will throw an error and the build will fail. >>>>>>>> >>>>>>>> So the 'Java 5 only' limitation applies to frontend >>>>>>>> code >>>>>>>> and >>>>>>>> any >>>>>>>> other code (e.g. shared modules) that is directly >>>>>>>> referenced >>>>>>>> by >>>>>>>> frontend code. This shouldn't affect the backend, >>>>>>>> however. >>>>>>>> >>>>>>>> We could do something like this: >>>>>>>> >>>>>>>> - let oVirt root POM declare source and target >>>>>>>> compliance >>>>>>>> to >>>>>>>> Java 7 >>>>>>>> - let frontend modules POM >>>>>>>> (frontend/webadmin/modules/pom.xml) >>>>>>>> declare source compliance to Java 5 (or 6) >>>>>>>> >>>>>>>> (note that target compliance can be left to Java 7 >>>>>>>> since >>>>>>>> frontend compilation results in JavaScript code) >>>>>>>> >>>>>>>> What do you think? >>>>>>>> >>>>>>>> Vojtech >>>>>>> >>>>>>> +1 - I really like this idea! >>>>>> >>>>>> +1 from me as well. >>>>> >>>>> >>>>> There are two calls to make when it comes to JDK7 >>>>> (regardless >>>>> of >>>>> GWT - >>>>> excuse me for taking this discussion some steps backwards) >>>>> >>>>> 1. Are we running with JRE 7? >>>>> The answer is yes we agreed on that a few months ago. >>>>> >>>>> 2. Are we using code syntax which is incompatible with >>>>> JDK6? >>>>> >>>>> I think the answer to the above should be no (at least for >>>>> now >>>>> - >>>>> maybe >>>>> until the next ovirt release?). >>>> +1 >>>> exactly. Why starting with jdk6 incompatible constructs >>>> unless >>>> there >>>> is a good (or at least any) reason for them… >>> >>> +1 >> >> +1 - there is merit keeping backward compatibility to allow >> comparing >> behavior while java 7 is still young. > > Since no one objected, we'll go with JDK6 syntax compatibility > for > Now. I'm a very small fan of enforcing policy by reviewers. Not that the community reviews aren't great - but people miss things.
Here's my take on Maven's enforcer plugin to actually verify we aren't compiling with JDK 7: http://gerrit.ovirt.org/#/c/6523
we don't want to enforce compilation or run with JDK 6, only to preserve backward compatibility. I'm for jenkins to have a job to compile and run unitests with openjdk 6 to be on the safe side.
I don't understand this suggestion. What you're saying is that you can compile with whatever JDK you want, but: - it won't compile with JDKs prior to 6, since we're using 6's features. - you aren't allowed to use JDK 7 features, and if you do, you'll get an email from jenkins that you broke something and must fix it.
To me, this sounds a lot like enforcing JDK 6 compatibility.
its preserving jdk 6 compatibility for a few more months, not enforcing to use jdk 6 compiler. Fair enough.
/today/ if have way too many (i.e., >0) jenkins breaks, a lot of which could be avoided by not running with -DskipTetst or making sure to run with -Penable-dao-tests. I fear this suggestion will just add to this "noise", and could easily be avoided.
jenkins breaks should be visible at patch level prior to commit, something we are trying to resolve by adding more hardware to allow running the various tests at patch level rather than post commit only.
I agree that this is an excellent goal, but I maintain that this is an uncomfortable way to work. I would still like a way to check, on my own machine, as part of my compilation process, that I'm not doing anything I shouldn't. Here's my second take on the issue, using Animal Sniffer (http://mojo.codehaus.org/animal-sniffer/): http://gerrit.ovirt.org/#/c/6540
Again, comments welcome.
Before going ahead I would check that using it doesn't increase the already long compilation time to an unacceptable level. mvn clean install on my machine took just over 5 minutes - not too bad considering that up till a month ago or so it took 15-20 minutes to run the test suite.
Also need to make sure that the new dependency is available in the build environments we use.
Built it against brew's repo, seemed to work fine. If you have any more suggestions on how to check it, please advise.
I am specially concerned about the Fedora build system, where we have the plugin but not the signatures for the JDKs. The signatures are provided as part of the plugin - they are not taken directly from the JDK. Or am I missing something in your point?
This means that we will need to ignore the plugin or build the signatures ourselves. Not so - see above.
Also take into account that every new maven plugin we add to the POMs introduces new potential problems with the maven eclipse support.
True. IMHO, it's a small price to pay, but I guess that's why we discuss things upstream - to get different opinions ;-)
I think we can leave the decision to each developer, maybe providing an script that calls "mvn animal-sniffer:check ..." with the right parameters, maybe with git pre-commit hook, to make it more automatic.
I really don't like this approach, but again - difference of opinions :-) Let's gather somemore feedback before deciding either way?
This combined with the Jenkins checks can be a good compromise.
-- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
On 07/23/2012 01:02 PM, Allon Mureinik wrote:
----- Original Message -----
From: "Juan Hernandez" <jhernand@redhat.com> To: "Allon Mureinik" <amureini@redhat.com> Cc: "Itamar Heim" <iheim@redhat.com>, engine-devel@ovirt.org Sent: Monday, July 23, 2012 1:22:37 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/23/2012 11:46 AM, Allon Mureinik wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Allon Mureinik" <amureini@redhat.com> Cc: "Livnat Peer" <lpeer@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org, "Michael Kublin" <mkublin@redhat.com> Sent: Monday, July 23, 2012 8:43:02 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/23/2012 08:29 AM, Allon Mureinik wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Allon Mureinik" <amureini@redhat.com> Cc: "Livnat Peer" <lpeer@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org, "Michael Kublin" <mkublin@redhat.com> Sent: Sunday, July 22, 2012 7:41:00 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/22/2012 07:38 PM, Allon Mureinik wrote: > > > ----- Original Message ----- >> From: "Livnat Peer" <lpeer@redhat.com> >> To: "Itamar Heim" <iheim@redhat.com>, "Michael Kublin" >> <mkublin@redhat.com> >> Cc: "Juan Hernandez" <jhernand@redhat.com>, >> engine-devel@ovirt.org >> Sent: Sunday, July 22, 2012 9:50:47 AM >> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >> >> On 21/07/12 15:15, Itamar Heim wrote: >>> On 07/19/2012 03:34 PM, Ayal Baron wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> >>>>> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: >>>>> >>>>>> On 19/07/12 14:41, Juan Hernandez wrote: >>>>>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >>>>>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>>>>>>>> Don't we need that (the source part) to avoid Java 7 >>>>>>>>>> syntax >>>>>>>>>> in >>>>>>>>>> GWT code? >>>>>>>>> >>>>>>>>> That's a very good point. >>>>>>>>> >>>>>>>>> In general, GWT compiler supports Java 5 syntax (note >>>>>>>>> that >>>>>>>>> there >>>>>>>>> are no language changes between Java 5 and 6). For this >>>>>>>>> reason, >>>>>>>>> our frontend code should be compliant with Java 5. If >>>>>>>>> someone >>>>>>>>> uses new Java 7 language features in frontend code, GWT >>>>>>>>> compiler will throw an error and the build will fail. >>>>>>>>> >>>>>>>>> So the 'Java 5 only' limitation applies to frontend >>>>>>>>> code >>>>>>>>> and >>>>>>>>> any >>>>>>>>> other code (e.g. shared modules) that is directly >>>>>>>>> referenced >>>>>>>>> by >>>>>>>>> frontend code. This shouldn't affect the backend, >>>>>>>>> however. >>>>>>>>> >>>>>>>>> We could do something like this: >>>>>>>>> >>>>>>>>> - let oVirt root POM declare source and target >>>>>>>>> compliance >>>>>>>>> to >>>>>>>>> Java 7 >>>>>>>>> - let frontend modules POM >>>>>>>>> (frontend/webadmin/modules/pom.xml) >>>>>>>>> declare source compliance to Java 5 (or 6) >>>>>>>>> >>>>>>>>> (note that target compliance can be left to Java 7 >>>>>>>>> since >>>>>>>>> frontend compilation results in JavaScript code) >>>>>>>>> >>>>>>>>> What do you think? >>>>>>>>> >>>>>>>>> Vojtech >>>>>>>> >>>>>>>> +1 - I really like this idea! >>>>>>> >>>>>>> +1 from me as well. >>>>>> >>>>>> >>>>>> There are two calls to make when it comes to JDK7 >>>>>> (regardless >>>>>> of >>>>>> GWT - >>>>>> excuse me for taking this discussion some steps backwards) >>>>>> >>>>>> 1. Are we running with JRE 7? >>>>>> The answer is yes we agreed on that a few months ago. >>>>>> >>>>>> 2. Are we using code syntax which is incompatible with >>>>>> JDK6? >>>>>> >>>>>> I think the answer to the above should be no (at least for >>>>>> now >>>>>> - >>>>>> maybe >>>>>> until the next ovirt release?). >>>>> +1 >>>>> exactly. Why starting with jdk6 incompatible constructs >>>>> unless >>>>> there >>>>> is a good (or at least any) reason for them… >>>> >>>> +1 >>> >>> +1 - there is merit keeping backward compatibility to allow >>> comparing >>> behavior while java 7 is still young. >> >> Since no one objected, we'll go with JDK6 syntax compatibility >> for >> Now. > I'm a very small fan of enforcing policy by reviewers. > Not that the community reviews aren't great - but people miss > things. > > Here's my take on Maven's enforcer plugin to actually verify we > aren't compiling with JDK 7: > http://gerrit.ovirt.org/#/c/6523
we don't want to enforce compilation or run with JDK 6, only to preserve backward compatibility. I'm for jenkins to have a job to compile and run unitests with openjdk 6 to be on the safe side.
I don't understand this suggestion. What you're saying is that you can compile with whatever JDK you want, but: - it won't compile with JDKs prior to 6, since we're using 6's features. - you aren't allowed to use JDK 7 features, and if you do, you'll get an email from jenkins that you broke something and must fix it.
To me, this sounds a lot like enforcing JDK 6 compatibility.
its preserving jdk 6 compatibility for a few more months, not enforcing to use jdk 6 compiler. Fair enough.
/today/ if have way too many (i.e., >0) jenkins breaks, a lot of which could be avoided by not running with -DskipTetst or making sure to run with -Penable-dao-tests. I fear this suggestion will just add to this "noise", and could easily be avoided.
jenkins breaks should be visible at patch level prior to commit, something we are trying to resolve by adding more hardware to allow running the various tests at patch level rather than post commit only.
I agree that this is an excellent goal, but I maintain that this is an uncomfortable way to work. I would still like a way to check, on my own machine, as part of my compilation process, that I'm not doing anything I shouldn't. Here's my second take on the issue, using Animal Sniffer (http://mojo.codehaus.org/animal-sniffer/): http://gerrit.ovirt.org/#/c/6540
Again, comments welcome.
Before going ahead I would check that using it doesn't increase the already long compilation time to an unacceptable level. mvn clean install on my machine took just over 5 minutes - not too bad considering that up till a month ago or so it took 15-20 minutes to run the test suite.
Can you compare the build with and without animal-sniffer? Just to have an idea of what is the difference. Anyhow five minutes seems acceptable to me.
Also need to make sure that the new dependency is available in the build environments we use. Built it against brew's repo, seemed to work fine. If you have any more suggestions on how to check it, please advise.
That is very good. Actually building there would be even better.
I am specially concerned about the Fedora build system, where we have the plugin but not the signatures for the JDKs. The signatures are provided as part of the plugin - they are not taken directly from the JDK. Or am I missing something in your point?
I don't know very well this plugin, but it is my understanding that the signatures are additional dependencies that need to be downloaded from the maven repository. In your patch you are using the following: <signature> <groupId>org.jvnet.animal-sniffer</groupId> <artifactId>java1.6</artifactId> <version>1.0</version> </signature> This org.jvnet.animal-sniffer:java1.6:1.0 artifact is what I can't find in the Fedora build system. Not a big problem, this can be patched out while building the package, just a minor inconvenience.
This means that we will need to ignore the plugin or build the signatures ourselves. Not so - see above.
Also take into account that every new maven plugin we add to the POMs introduces new potential problems with the maven eclipse support.
True. IMHO, it's a small price to pay, but I guess that's why we discuss things upstream - to get different opinions ;-)
Well, for me personally the price is actually zero, as I don't use the Eclipse maven support ;-) . But I know that many people hates when they try to import the projects and they get errors because of plugins that Eclipse doesn't understand. Let's see what they think.
I think we can leave the decision to each developer, maybe providing an script that calls "mvn animal-sniffer:check ..." with the right parameters, maybe with git pre-commit hook, to make it more automatic. I really don't like this approach, but again - difference of opinions :-) Let's gather somemore feedback before deciding either way?
Yes, of course. In my opinion adding this check is a good idea, and you already cleared most of the objections.
This combined with the Jenkins checks can be a good compromise.
-- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
On 07/23/2012 02:31 PM, Juan Hernandez wrote:
Well, for me personally the price is actually zero, as I don't use the Eclipse maven support ;-) . But I know that many people hates when they try to import the projects and they get errors because of plugins that Eclipse doesn't understand. Let's see what they think.
ovirt should load in eclipse without any error, and we are working on cleaning this up as it currently requires manual work to clean up the errors to work in eclipse (which i find less than friendly to new community members)
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Juan Hernandez" <jhernand@redhat.com> Cc: "Allon Mureinik" <amureini@redhat.com>, engine-devel@ovirt.org Sent: Monday, July 23, 2012 2:44:02 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/23/2012 02:31 PM, Juan Hernandez wrote:
Well, for me personally the price is actually zero, as I don't use the Eclipse maven support ;-) . But I know that many people hates when they try to import the projects and they get errors because of plugins that Eclipse doesn't understand. Let's see what they think.
ovirt should load in eclipse without any error, and we are working on cleaning this up as it currently requires manual work to clean up the errors to work in eclipse (which i find less than friendly to new community members)
Agreed. I didn't notice any problems in working in Eclipse (I use Juno) + Maven + this plugin, but if anyone did, I'd appreciate the feedback.
----- Original Message -----
From: "Juan Hernandez" <jhernand@redhat.com> To: "Allon Mureinik" <amureini@redhat.com> Cc: engine-devel@ovirt.org Sent: Monday, July 23, 2012 2:31:24 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/23/2012 01:02 PM, Allon Mureinik wrote:
----- Original Message -----
From: "Juan Hernandez" <jhernand@redhat.com> To: "Allon Mureinik" <amureini@redhat.com> Cc: "Itamar Heim" <iheim@redhat.com>, engine-devel@ovirt.org Sent: Monday, July 23, 2012 1:22:37 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/23/2012 11:46 AM, Allon Mureinik wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Allon Mureinik" <amureini@redhat.com> Cc: "Livnat Peer" <lpeer@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org, "Michael Kublin" <mkublin@redhat.com> Sent: Monday, July 23, 2012 8:43:02 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/23/2012 08:29 AM, Allon Mureinik wrote:
----- Original Message ----- > From: "Itamar Heim" <iheim@redhat.com> > To: "Allon Mureinik" <amureini@redhat.com> > Cc: "Livnat Peer" <lpeer@redhat.com>, "Juan Hernandez" > <jhernand@redhat.com>, engine-devel@ovirt.org, "Michael > Kublin" <mkublin@redhat.com> > Sent: Sunday, July 22, 2012 7:41:00 PM > Subject: Re: [Engine-devel] java 1.6 compatibility no more? > > On 07/22/2012 07:38 PM, Allon Mureinik wrote: >> >> >> ----- Original Message ----- >>> From: "Livnat Peer" <lpeer@redhat.com> >>> To: "Itamar Heim" <iheim@redhat.com>, "Michael Kublin" >>> <mkublin@redhat.com> >>> Cc: "Juan Hernandez" <jhernand@redhat.com>, >>> engine-devel@ovirt.org >>> Sent: Sunday, July 22, 2012 9:50:47 AM >>> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >>> >>> On 21/07/12 15:15, Itamar Heim wrote: >>>> On 07/19/2012 03:34 PM, Ayal Baron wrote: >>>>> >>>>> >>>>> ----- Original Message ----- >>>>>> >>>>>> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: >>>>>> >>>>>>> On 19/07/12 14:41, Juan Hernandez wrote: >>>>>>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >>>>>>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>>>>>>>>> Don't we need that (the source part) to avoid Java 7 >>>>>>>>>>> syntax >>>>>>>>>>> in >>>>>>>>>>> GWT code? >>>>>>>>>> >>>>>>>>>> That's a very good point. >>>>>>>>>> >>>>>>>>>> In general, GWT compiler supports Java 5 syntax (note >>>>>>>>>> that >>>>>>>>>> there >>>>>>>>>> are no language changes between Java 5 and 6). For >>>>>>>>>> this >>>>>>>>>> reason, >>>>>>>>>> our frontend code should be compliant with Java 5. If >>>>>>>>>> someone >>>>>>>>>> uses new Java 7 language features in frontend code, >>>>>>>>>> GWT >>>>>>>>>> compiler will throw an error and the build will fail. >>>>>>>>>> >>>>>>>>>> So the 'Java 5 only' limitation applies to frontend >>>>>>>>>> code >>>>>>>>>> and >>>>>>>>>> any >>>>>>>>>> other code (e.g. shared modules) that is directly >>>>>>>>>> referenced >>>>>>>>>> by >>>>>>>>>> frontend code. This shouldn't affect the backend, >>>>>>>>>> however. >>>>>>>>>> >>>>>>>>>> We could do something like this: >>>>>>>>>> >>>>>>>>>> - let oVirt root POM declare source and target >>>>>>>>>> compliance >>>>>>>>>> to >>>>>>>>>> Java 7 >>>>>>>>>> - let frontend modules POM >>>>>>>>>> (frontend/webadmin/modules/pom.xml) >>>>>>>>>> declare source compliance to Java 5 (or 6) >>>>>>>>>> >>>>>>>>>> (note that target compliance can be left to Java 7 >>>>>>>>>> since >>>>>>>>>> frontend compilation results in JavaScript code) >>>>>>>>>> >>>>>>>>>> What do you think? >>>>>>>>>> >>>>>>>>>> Vojtech >>>>>>>>> >>>>>>>>> +1 - I really like this idea! >>>>>>>> >>>>>>>> +1 from me as well. >>>>>>> >>>>>>> >>>>>>> There are two calls to make when it comes to JDK7 >>>>>>> (regardless >>>>>>> of >>>>>>> GWT - >>>>>>> excuse me for taking this discussion some steps >>>>>>> backwards) >>>>>>> >>>>>>> 1. Are we running with JRE 7? >>>>>>> The answer is yes we agreed on that a few months ago. >>>>>>> >>>>>>> 2. Are we using code syntax which is incompatible with >>>>>>> JDK6? >>>>>>> >>>>>>> I think the answer to the above should be no (at least >>>>>>> for >>>>>>> now >>>>>>> - >>>>>>> maybe >>>>>>> until the next ovirt release?). >>>>>> +1 >>>>>> exactly. Why starting with jdk6 incompatible constructs >>>>>> unless >>>>>> there >>>>>> is a good (or at least any) reason for them… >>>>> >>>>> +1 >>>> >>>> +1 - there is merit keeping backward compatibility to allow >>>> comparing >>>> behavior while java 7 is still young. >>> >>> Since no one objected, we'll go with JDK6 syntax >>> compatibility >>> for >>> Now. >> I'm a very small fan of enforcing policy by reviewers. >> Not that the community reviews aren't great - but people miss >> things. >> >> Here's my take on Maven's enforcer plugin to actually verify >> we >> aren't compiling with JDK 7: >> http://gerrit.ovirt.org/#/c/6523 > > we don't want to enforce compilation or run with JDK 6, only > to > preserve > backward compatibility. > I'm for jenkins to have a job to compile and run unitests with > openjdk 6 > to be on the safe side.
I don't understand this suggestion. What you're saying is that you can compile with whatever JDK you want, but: - it won't compile with JDKs prior to 6, since we're using 6's features. - you aren't allowed to use JDK 7 features, and if you do, you'll get an email from jenkins that you broke something and must fix it.
To me, this sounds a lot like enforcing JDK 6 compatibility.
its preserving jdk 6 compatibility for a few more months, not enforcing to use jdk 6 compiler. Fair enough.
/today/ if have way too many (i.e., >0) jenkins breaks, a lot of which could be avoided by not running with -DskipTetst or making sure to run with -Penable-dao-tests. I fear this suggestion will just add to this "noise", and could easily be avoided.
jenkins breaks should be visible at patch level prior to commit, something we are trying to resolve by adding more hardware to allow running the various tests at patch level rather than post commit only.
I agree that this is an excellent goal, but I maintain that this is an uncomfortable way to work. I would still like a way to check, on my own machine, as part of my compilation process, that I'm not doing anything I shouldn't. Here's my second take on the issue, using Animal Sniffer (http://mojo.codehaus.org/animal-sniffer/): http://gerrit.ovirt.org/#/c/6540
Again, comments welcome.
Before going ahead I would check that using it doesn't increase the already long compilation time to an unacceptable level. mvn clean install on my machine took just over 5 minutes - not too bad considering that up till a month ago or so it took 15-20 minutes to run the test suite.
Can you compare the build with and without animal-sniffer? Just to have an idea of what is the difference. Anyhow five minutes seems acceptable to me.
The overhead is roughly 50 seconds: using [merged] commit hash 5845c732560dc325132661e1d1260de0a096c6b7 and the animal-sniffer patch rebased on top of it: mvn clean install -DskipTests: 2:55.76 minutes mvn clean install: 4:49.28 minutes using [merged] commit hash 5845c732560dc325132661e1d1260de0a096c6b7: mvn clean install -DskipTests: 2:05:40 minutes mvn clean install: 3:57.68 minutes [Note: this is done on my personal machine, with everything closed except the terminal running mvn, but this is still hardly a strict benchmark]
Also need to make sure that the new dependency is available in the build environments we use. Built it against brew's repo, seemed to work fine. If you have any more suggestions on how to check it, please advise.
That is very good. Actually building there would be even better.
I am specially concerned about the Fedora build system, where we have the plugin but not the signatures for the JDKs. The signatures are provided as part of the plugin - they are not taken directly from the JDK. Or am I missing something in your point?
I don't know very well this plugin, but it is my understanding that the signatures are additional dependencies that need to be downloaded from the maven repository. In your patch you are using the following:
<signature> <groupId>org.jvnet.animal-sniffer</groupId> <artifactId>java1.6</artifactId> <version>1.0</version> </signature>
This org.jvnet.animal-sniffer:java1.6:1.0 artifact is what I can't find in the Fedora build system. Not a big problem, this can be patched out while building the package, just a minor inconvenience.
Now I get your drift. Odd indeed, and I think this actually may spell a NACK for this patch - we don't want to add more inconveniences to the build process. Perhaps we should add this check as an optional step in maven, like you originally suggested? That way developers have a decent tool for performing this check, without having to necessarily interfere with the build system.
This means that we will need to ignore the plugin or build the signatures ourselves. Not so - see above.
Also take into account that every new maven plugin we add to the POMs introduces new potential problems with the maven eclipse support.
True. IMHO, it's a small price to pay, but I guess that's why we discuss things upstream - to get different opinions ;-)
Well, for me personally the price is actually zero, as I don't use the Eclipse maven support ;-) . But I know that many people hates when they try to import the projects and they get errors because of plugins that Eclipse doesn't understand. Let's see what they think.
I think we can leave the decision to each developer, maybe providing an script that calls "mvn animal-sniffer:check ..." with the right parameters, maybe with git pre-commit hook, to make it more automatic. I really don't like this approach, but again - difference of opinions :-) Let's gather somemore feedback before deciding either way?
Yes, of course. In my opinion adding this check is a good idea, and you already cleared most of the objections.
This combined with the Jenkins checks can be a good compromise.
-- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
On 07/23/2012 02:02 PM, Allon Mureinik wrote:
----- Original Message -----
From: "Juan Hernandez"<jhernand@redhat.com> To: "Allon Mureinik"<amureini@redhat.com> Cc: "Itamar Heim"<iheim@redhat.com>, engine-devel@ovirt.org Sent: Monday, July 23, 2012 1:22:37 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/23/2012 11:46 AM, Allon Mureinik wrote:
----- Original Message -----
From: "Itamar Heim"<iheim@redhat.com> To: "Allon Mureinik"<amureini@redhat.com> Cc: "Livnat Peer"<lpeer@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org, "Michael Kublin"<mkublin@redhat.com> Sent: Monday, July 23, 2012 8:43:02 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/23/2012 08:29 AM, Allon Mureinik wrote:
----- Original Message -----
From: "Itamar Heim"<iheim@redhat.com> To: "Allon Mureinik"<amureini@redhat.com> Cc: "Livnat Peer"<lpeer@redhat.com>, "Juan Hernandez" <jhernand@redhat.com>, engine-devel@ovirt.org, "Michael Kublin"<mkublin@redhat.com> Sent: Sunday, July 22, 2012 7:41:00 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/22/2012 07:38 PM, Allon Mureinik wrote: > > > ----- Original Message ----- >> From: "Livnat Peer"<lpeer@redhat.com> >> To: "Itamar Heim"<iheim@redhat.com>, "Michael Kublin" >> <mkublin@redhat.com> >> Cc: "Juan Hernandez"<jhernand@redhat.com>, >> engine-devel@ovirt.org >> Sent: Sunday, July 22, 2012 9:50:47 AM >> Subject: Re: [Engine-devel] java 1.6 compatibility no more? >> >> On 21/07/12 15:15, Itamar Heim wrote: >>> On 07/19/2012 03:34 PM, Ayal Baron wrote: >>>> >>>> >>>> ----- Original Message ----- >>>>> >>>>> On Jul 19, 2012, at 14:14 , Livnat Peer wrote: >>>>> >>>>>> On 19/07/12 14:41, Juan Hernandez wrote: >>>>>>> On 07/19/2012 01:39 PM, Yair Zaslavsky wrote: >>>>>>>> On 07/19/2012 02:31 PM, Vojtech Szocs wrote: >>>>>>>>>> Don't we need that (the source part) to avoid Java 7 >>>>>>>>>> syntax >>>>>>>>>> in >>>>>>>>>> GWT code? >>>>>>>>> >>>>>>>>> That's a very good point. >>>>>>>>> >>>>>>>>> In general, GWT compiler supports Java 5 syntax (note >>>>>>>>> that >>>>>>>>> there >>>>>>>>> are no language changes between Java 5 and 6). For this >>>>>>>>> reason, >>>>>>>>> our frontend code should be compliant with Java 5. If >>>>>>>>> someone >>>>>>>>> uses new Java 7 language features in frontend code, GWT >>>>>>>>> compiler will throw an error and the build will fail. >>>>>>>>> >>>>>>>>> So the 'Java 5 only' limitation applies to frontend >>>>>>>>> code >>>>>>>>> and >>>>>>>>> any >>>>>>>>> other code (e.g. shared modules) that is directly >>>>>>>>> referenced >>>>>>>>> by >>>>>>>>> frontend code. This shouldn't affect the backend, >>>>>>>>> however. >>>>>>>>> >>>>>>>>> We could do something like this: >>>>>>>>> >>>>>>>>> - let oVirt root POM declare source and target >>>>>>>>> compliance >>>>>>>>> to >>>>>>>>> Java 7 >>>>>>>>> - let frontend modules POM >>>>>>>>> (frontend/webadmin/modules/pom.xml) >>>>>>>>> declare source compliance to Java 5 (or 6) >>>>>>>>> >>>>>>>>> (note that target compliance can be left to Java 7 >>>>>>>>> since >>>>>>>>> frontend compilation results in JavaScript code) >>>>>>>>> >>>>>>>>> What do you think? >>>>>>>>> >>>>>>>>> Vojtech >>>>>>>> >>>>>>>> +1 - I really like this idea! >>>>>>> >>>>>>> +1 from me as well. >>>>>> >>>>>> >>>>>> There are two calls to make when it comes to JDK7 >>>>>> (regardless >>>>>> of >>>>>> GWT - >>>>>> excuse me for taking this discussion some steps backwards) >>>>>> >>>>>> 1. Are we running with JRE 7? >>>>>> The answer is yes we agreed on that a few months ago. >>>>>> >>>>>> 2. Are we using code syntax which is incompatible with >>>>>> JDK6? >>>>>> >>>>>> I think the answer to the above should be no (at least for >>>>>> now >>>>>> - >>>>>> maybe >>>>>> until the next ovirt release?). >>>>> +1 >>>>> exactly. Why starting with jdk6 incompatible constructs >>>>> unless >>>>> there >>>>> is a good (or at least any) reason for them… >>>> >>>> +1 >>> >>> +1 - there is merit keeping backward compatibility to allow >>> comparing >>> behavior while java 7 is still young. >> >> Since no one objected, we'll go with JDK6 syntax compatibility >> for >> Now. > I'm a very small fan of enforcing policy by reviewers. > Not that the community reviews aren't great - but people miss > things. > > Here's my take on Maven's enforcer plugin to actually verify we > aren't compiling with JDK 7: > http://gerrit.ovirt.org/#/c/6523
we don't want to enforce compilation or run with JDK 6, only to preserve backward compatibility. I'm for jenkins to have a job to compile and run unitests with openjdk 6 to be on the safe side.
I don't understand this suggestion. What you're saying is that you can compile with whatever JDK you want, but: - it won't compile with JDKs prior to 6, since we're using 6's features. - you aren't allowed to use JDK 7 features, and if you do, you'll get an email from jenkins that you broke something and must fix it.
To me, this sounds a lot like enforcing JDK 6 compatibility.
its preserving jdk 6 compatibility for a few more months, not enforcing to use jdk 6 compiler. Fair enough.
/today/ if have way too many (i.e.,>0) jenkins breaks, a lot of which could be avoided by not running with -DskipTetst or making sure to run with -Penable-dao-tests. I fear this suggestion will just add to this "noise", and could easily be avoided.
jenkins breaks should be visible at patch level prior to commit, something we are trying to resolve by adding more hardware to allow running the various tests at patch level rather than post commit only.
I agree that this is an excellent goal, but I maintain that this is an uncomfortable way to work. I would still like a way to check, on my own machine, as part of my compilation process, that I'm not doing anything I shouldn't. Here's my second take on the issue, using Animal Sniffer (http://mojo.codehaus.org/animal-sniffer/): http://gerrit.ovirt.org/#/c/6540
Again, comments welcome.
Before going ahead I would check that using it doesn't increase the already long compilation time to an unacceptable level. mvn clean install on my machine took just over 5 minutes - not too bad considering that up till a month ago or so it took 15-20 minutes to run the test suite.
Also need to make sure that the new dependency is available in the build environments we use.
Built it against brew's repo, seemed to work fine. If you have any more suggestions on how to check it, please advise.
I am specially concerned about the Fedora build system, where we have the plugin but not the signatures for the JDKs. The signatures are provided as part of the plugin - they are not taken directly from the JDK. Or am I missing something in your point?
This means that we will need to ignore the plugin or build the signatures ourselves. Not so - see above.
Also take into account that every new maven plugin we add to the POMs introduces new potential problems with the maven eclipse support.
True. IMHO, it's a small price to pay, but I guess that's why we discuss things upstream - to get different opinions ;-)
I think we can leave the decision to each developer, maybe providing an script that calls "mvn animal-sniffer:check ..." with the right parameters, maybe with git pre-commit hook, to make it more automatic.
I really don't like this approach, but again - difference of opinions :-) Let's gather somemore feedback before deciding either way?
I am in favor of having this more automatic (maybe via Jenkins job that will fail patches not compiling against JDK6, maybe some other way) rather than trusting the developers. Not that I don't trust oVirt developers, but we're all human and can make sometimes mistakes.
This combined with the Jenkins checks can be a good compromise.
+1 on jenkins, as I Expressed before
-- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Vojtech Szocs" <vszocs@redhat.com> To: "Juan Hernandez" <jhernand@redhat.com> Cc: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 2:31:40 PM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
Don't we need that (the source part) to avoid Java 7 syntax in GWT code?
That's a very good point.
In general, GWT compiler supports Java 5 syntax (note that there are no language changes between Java 5 and 6). This may be nitpicking, but there is a difference: Java 6 allows the @Override annotation for implementing interfaces, while Java 5 restricts it to actual overrides. This is widely used throughout our code, at least in the backend side.
For this reason, our frontend code should be compliant with Java 5. If someone uses new Java 7 language features in frontend code, GWT compiler will throw an error and the build will fail.
So the 'Java 5 only' limitation applies to frontend code and any other code (e.g. shared modules) that is directly referenced by frontend code. This shouldn't affect the backend, however.
We could do something like this:
- let oVirt root POM declare source and target compliance to Java 7 - let frontend modules POM (frontend/webadmin/modules/pom.xml) declare source compliance to Java 5 (or 6)
(note that target compliance can be left to Java 7 since frontend compilation results in JavaScript code)
What do you think?
Vojtech
----- Original Message ----- From: "Juan Hernandez" <jhernand@redhat.com> To: "Vojtech Szocs" <vszocs@redhat.com> Cc: "Yair Zaslavsky" <yzaslavs@redhat.com>, engine-devel@ovirt.org Sent: Thursday, July 19, 2012 11:01:00 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/19/2012 10:09 AM, Vojtech Szocs wrote:
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
I agree, but in that case, why not switch to '1.7' Java source/target compliance for oVirt Maven build as well?
If JDK6 cannot be used for building oVirt (because of missing Java 7 APIs, because of LDAP/DNS issues in JDK6, etc.), we should also update our Maven POM files. Currently, when I import oVirt projects into Eclipse (using Eclipse Maven plugin), I'm getting compile errors on 'bll' project. This is because our Maven POM files declare '1.6' Java source/target compliance.
Juan - you are right, but for me, it sounds quite strange to have '1.6' Java source/target compliance for Maven build, and use JDK7 to do the build.
Don't we need that (the source part) to avoid Java 7 syntax in GWT code?
----- Original Message ----- From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 7:59:45 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/18/2012 08:21 PM, Juan Hernandez wrote:
On 07/18/2012 06:33 PM, Vojtech Szocs wrote:
In fact, for both backend and frontend, Maven effective POM contains:
<artifactId>maven-compiler-plugin</artifactId> <configuration> <source>1.6</source> <target>1.6</target> </configuration>
Therefore, according to Maven POM files, oVirt should be build-able using Java 6, but it's not. (?)
These maven settings just tell the java compiler to accept Java 6 syntax only and to generate a Java 6 compatible .class file format, but they don't restrict the set of APIs that can be used.
The problem is in backend/manager/modules/bll: StorageDomainCommandBase class uses new Java 7 Long.compare() static method.
I think we should decide if we want to be compliant with Java 7, or submit a patch that uses Java 6 API (Long.compareTo instance method).
Vojtech
As I previously emailed - JDK7 already fixed a known issue with ldap and DNS ,and made one of my patches at gerrit redundant. Why not enjoy the bug fixes?
----- Original Message ----- From: "Laszlo Hornyak" <lhornyak@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Cc: "Vojtech Szocs" <vszocs@redhat.com> Sent: Wednesday, July 18, 2012 5:43:34 PM Subject: java 1.6 compatibility no more?
Hi,
It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. Is this intentional?
Laszlo _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
-- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 07/18/2012 06:43 PM, Laszlo Hornyak wrote:
Hi,
It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. Is this intentional?
Laszlo _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Laszlo, I assumed (maybe wrong) that our subscribers on engine-devel are aware they should use jdk7. We recently had several issues (for example - some ldap/dns issue) with JDK6 , that were fixed on JDK7.
Not against it, but then we have declare in the pom that java 1.6 is no longer working http://gerrit.ovirt.org/6447 Laszlo ----- Original Message -----
From: "Yair Zaslavsky" <yzaslavs@redhat.com> To: engine-devel@ovirt.org Sent: Thursday, July 19, 2012 7:42:48 AM Subject: Re: [Engine-devel] java 1.6 compatibility no more?
On 07/18/2012 06:43 PM, Laszlo Hornyak wrote:
Hi,
It may be a historic moment, but for a few hours oVirt engine is no longer building on java 1.6. Is this intentional?
Laszlo _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Laszlo, I assumed (maybe wrong) that our subscribers on engine-devel are aware they should use jdk7.
We recently had several issues (for example - some ldap/dns issue) with JDK6 , that were fixed on JDK7.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
participants (9)
-
Allon Mureinik -
Ayal Baron -
Itamar Heim -
Juan Hernandez -
Laszlo Hornyak -
Livnat Peer -
Michal Skrivanek -
Vojtech Szocs -
Yair Zaslavsky