[Engine-devel] Improve classpath building
Hello all, I would like to propose an improvement in the way we build class-paths in the tools associated to the engine. At the moment we have at least two different ways to build classpaths: 1. Hard coded in the scripts, with maybe some variables: CP=$EAR_LIB/engine-encryptutils.jar:$EAR_LIB/engine-compat.jar:... This depends a lot on where we place the jar files, and we need to place them in different places in different environments if we want to adhere to common packaging practices. 2. Use the build-classpath script: CP=`build-classpath engine-encryptutils engine-compat ...` This depends less on the place we put them, but it doesn't work in development environments where some jars are not installed to the proper system locations. None of these is good for all environments. I would like to replace this classpath building logic with an script that performs the task in an smarter way and that works in all our environments (production, development, Fedora, RHEL, etc). My proposal is to create a "engine-java" script that we should use always when invoking java programs. This script will receive the same parameters that the "java" launcher receives, but the "-cp" or "-classpath" options will contain not the absolute name of the jar files, but just a simple jar name instead, something like "commons-logging", "commons-codec" or "engineencryptutils". The script will extract the "-cp" or "-classpath" options given and use them to do a search of the jar files in the locations where they can be in different environments: /usr/share/java /usr/share/java/ovirt-engine /usr/share/ovirt-engine/engine.ear /usr/share/ovirt-engine/engine.ear/lib <your jboss development installation>/engine.ear <your jboss development installation>/engine.ear/lib In addition the script will check that all the give jar files exist and will abort the execution if any of them is missing. Find attached the initial version of the proposed script. Let me know what you think. Regards, Juan Hernandez -- 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.
----- Original Message -----
From: "Juan Hernandez" <jhernand@redhat.com> To: engine-devel@ovirt.org Sent: Tuesday, June 5, 2012 3:53:08 PM Subject: [Engine-devel] Improve classpath building
Hello all,
I would like to propose an improvement in the way we build class-paths in the tools associated to the engine. At the moment we have at least two different ways to build classpaths:
1. Hard coded in the scripts, with maybe some variables:
CP=$EAR_LIB/engine-encryptutils.jar:$EAR_LIB/engine-compat.jar:...
This depends a lot on where we place the jar files, and we need to place them in different places in different environments if we want to adhere to common packaging practices.
2. Use the build-classpath script:
CP=`build-classpath engine-encryptutils engine-compat ...`
This depends less on the place we put them, but it doesn't work in development environments where some jars are not installed to the proper system locations.
None of these is good for all environments.
I would like to replace this classpath building logic with an script that performs the task in an smarter way and that works in all our environments (production, development, Fedora, RHEL, etc).
In general it looks like a very good idea. Running the utilities in a development environment today is a real pain, so such a change will save a lot of time both when setting the development environment, and when testing changes. Didn't review all the whole source code, but from a quick glance I saw the preferredJars dictionary. IMO it is better to put this configuration in a configuration file, instead of a dictionary. Also, I would allow to change the path to this file, to allow developers to create a custom file (if they need one).
My proposal is to create a "engine-java" script that we should use always when invoking java programs. This script will receive the same parameters that the "java" launcher receives, but the "-cp" or "-classpath" options will contain not the absolute name of the jar files, but just a simple jar name instead, something like "commons-logging", "commons-codec" or "engineencryptutils". The script will extract the "-cp" or "-classpath" options given and use them to do a search of the jar files in the locations where they can be in different environments:
/usr/share/java /usr/share/java/ovirt-engine /usr/share/ovirt-engine/engine.ear /usr/share/ovirt-engine/engine.ear/lib <your jboss development installation>/engine.ear <your jboss development installation>/engine.ear/lib
In addition the script will check that all the give jar files exist and will abort the execution if any of them is missing.
Find attached the initial version of the proposed script.
Let me know what you think.
Regards, Juan Hernandez
-- 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 06/05/2012 03:03 PM, Oved Ourfalli wrote:
----- Original Message -----
From: "Juan Hernandez"<jhernand@redhat.com> To: engine-devel@ovirt.org Sent: Tuesday, June 5, 2012 3:53:08 PM Subject: [Engine-devel] Improve classpath building
Hello all,
I would like to propose an improvement in the way we build class-paths in the tools associated to the engine. At the moment we have at least two different ways to build classpaths:
1. Hard coded in the scripts, with maybe some variables:
CP=$EAR_LIB/engine-encryptutils.jar:$EAR_LIB/engine-compat.jar:...
This depends a lot on where we place the jar files, and we need to place them in different places in different environments if we want to adhere to common packaging practices.
2. Use the build-classpath script:
CP=`build-classpath engine-encryptutils engine-compat ...`
This depends less on the place we put them, but it doesn't work in development environments where some jars are not installed to the proper system locations.
None of these is good for all environments.
I would like to replace this classpath building logic with an script that performs the task in an smarter way and that works in all our environments (production, development, Fedora, RHEL, etc).
In general it looks like a very good idea. Running the utilities in a development environment today is a real pain, so such a change will save a lot of time both when setting the development environment, and when testing changes.
Didn't review all the whole source code, but from a quick glance I saw the preferredJars dictionary. IMO it is better to put this configuration in a configuration file, instead of a dictionary. Also, I would allow to change the path to this file, to allow developers to create a custom file (if they need one).
The idea of using a configuration file is nice, but I would make it completely optional, and would try to make every effort (almost) to make the script work without need for additional configuration.
My proposal is to create a "engine-java" script that we should use always when invoking java programs. This script will receive the same parameters that the "java" launcher receives, but the "-cp" or "-classpath" options will contain not the absolute name of the jar files, but just a simple jar name instead, something like "commons-logging", "commons-codec" or "engineencryptutils". The script will extract the "-cp" or "-classpath" options given and use them to do a search of the jar files in the locations where they can be in different environments:
/usr/share/java /usr/share/java/ovirt-engine /usr/share/ovirt-engine/engine.ear /usr/share/ovirt-engine/engine.ear/lib <your jboss development installation>/engine.ear <your jboss development installation>/engine.ear/lib
In addition the script will check that all the give jar files exist and will abort the execution if any of them is missing.
Find attached the initial version of the proposed script.
Let me know what you think.
Regards, Juan Hernandez
-- 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
-- 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.
----- Original Message -----
From: "Juan Hernandez" <jhernand@redhat.com> To: "Oved Ourfalli" <ovedo@redhat.com> Cc: engine-devel@ovirt.org Sent: Tuesday, June 5, 2012 6:23:52 PM Subject: Re: [Engine-devel] Improve classpath building
On 06/05/2012 03:03 PM, Oved Ourfalli wrote:
----- Original Message -----
From: "Juan Hernandez"<jhernand@redhat.com> To: engine-devel@ovirt.org Sent: Tuesday, June 5, 2012 3:53:08 PM Subject: [Engine-devel] Improve classpath building
Hello all,
I would like to propose an improvement in the way we build class-paths in the tools associated to the engine. At the moment we have at least two different ways to build classpaths:
1. Hard coded in the scripts, with maybe some variables:
CP=$EAR_LIB/engine-encryptutils.jar:$EAR_LIB/engine-compat.jar:...
This depends a lot on where we place the jar files, and we need to place them in different places in different environments if we want to adhere to common packaging practices.
2. Use the build-classpath script:
CP=`build-classpath engine-encryptutils engine-compat ...`
This depends less on the place we put them, but it doesn't work in development environments where some jars are not installed to the proper system locations.
None of these is good for all environments.
I would like to replace this classpath building logic with an script that performs the task in an smarter way and that works in all our environments (production, development, Fedora, RHEL, etc).
In general it looks like a very good idea. Running the utilities in a development environment today is a real pain, so such a change will save a lot of time both when setting the development environment, and when testing changes.
Didn't review all the whole source code, but from a quick glance I saw the preferredJars dictionary. IMO it is better to put this configuration in a configuration file, instead of a dictionary. Also, I would allow to change the path to this file, to allow developers to create a custom file (if they need one).
The idea of using a configuration file is nice, but I would make it completely optional, and would try to make every effort (almost) to make the script work without need for additional configuration.
good enough :-)
My proposal is to create a "engine-java" script that we should use always when invoking java programs. This script will receive the same parameters that the "java" launcher receives, but the "-cp" or "-classpath" options will contain not the absolute name of the jar files, but just a simple jar name instead, something like "commons-logging", "commons-codec" or "engineencryptutils". The script will extract the "-cp" or "-classpath" options given and use them to do a search of the jar files in the locations where they can be in different environments:
/usr/share/java /usr/share/java/ovirt-engine /usr/share/ovirt-engine/engine.ear /usr/share/ovirt-engine/engine.ear/lib <your jboss development installation>/engine.ear <your jboss development installation>/engine.ear/lib
In addition the script will check that all the give jar files exist and will abort the execution if any of them is missing.
Find attached the initial version of the proposed script.
Let me know what you think.
Regards, Juan Hernandez
-- 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
-- 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 06/05/2012 03:53 PM, Juan Hernandez wrote:
Hello all,
I would like to propose an improvement in the way we build class-paths in the tools associated to the engine. At the moment we have at least two different ways to build classpaths:
1. Hard coded in the scripts, with maybe some variables:
CP=$EAR_LIB/engine-encryptutils.jar:$EAR_LIB/engine-compat.jar:...
This depends a lot on where we place the jar files, and we need to place them in different places in different environments if we want to adhere to common packaging practices.
2. Use the build-classpath script:
CP=`build-classpath engine-encryptutils engine-compat ...`
This depends less on the place we put them, but it doesn't work in development environments where some jars are not installed to the proper system locations.
None of these is good for all environments.
I would like to replace this classpath building logic with an script that performs the task in an smarter way and that works in all our environments (production, development, Fedora, RHEL, etc).
My proposal is to create a "engine-java" script that we should use always when invoking java programs. This script will receive the same parameters that the "java" launcher receives, but the "-cp" or "-classpath" options will contain not the absolute name of the jar files, but just a simple jar name instead, something like "commons-logging", "commons-codec" or "engineencryptutils". The script will extract the "-cp" or "-classpath" options given and use them to do a search of the jar files in the locations where they can be in different environments:
/usr/share/java /usr/share/java/ovirt-engine /usr/share/ovirt-engine/engine.ear /usr/share/ovirt-engine/engine.ear/lib <your jboss development installation>/engine.ear <your jboss development installation>/engine.ear/lib
In addition the script will check that all the give jar files exist and will abort the execution if any of them is missing.
Find attached the initial version of the proposed script.
Let me know what you think.
Excellent idea! I would like to add - I already saw the work you did on engine-manage-domains. When we work on development machines, we might have the jars reside in different places. I wanted to create a script that will allow for example to use build-classpath on spring-ldap-core, but I did not have a soft link for that in /usr/share/java (is that what I needed to do?) I guess we will have to differentiate between the need of dev and production for this script.
Regards, Juan Hernandez
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 06/05/2012 04:41 PM, Yair Zaslavsky wrote:
On 06/05/2012 03:53 PM, Juan Hernandez wrote:
Hello all,
I would like to propose an improvement in the way we build class-paths in the tools associated to the engine. At the moment we have at least two different ways to build classpaths:
1. Hard coded in the scripts, with maybe some variables:
CP=$EAR_LIB/engine-encryptutils.jar:$EAR_LIB/engine-compat.jar:...
This depends a lot on where we place the jar files, and we need to place them in different places in different environments if we want to adhere to common packaging practices.
2. Use the build-classpath script:
CP=`build-classpath engine-encryptutils engine-compat ...`
This depends less on the place we put them, but it doesn't work in development environments where some jars are not installed to the proper system locations.
None of these is good for all environments.
I would like to replace this classpath building logic with an script that performs the task in an smarter way and that works in all our environments (production, development, Fedora, RHEL, etc).
My proposal is to create a "engine-java" script that we should use always when invoking java programs. This script will receive the same parameters that the "java" launcher receives, but the "-cp" or "-classpath" options will contain not the absolute name of the jar files, but just a simple jar name instead, something like "commons-logging", "commons-codec" or "engineencryptutils". The script will extract the "-cp" or "-classpath" options given and use them to do a search of the jar files in the locations where they can be in different environments:
/usr/share/java /usr/share/java/ovirt-engine /usr/share/ovirt-engine/engine.ear /usr/share/ovirt-engine/engine.ear/lib <your jboss development installation>/engine.ear <your jboss development installation>/engine.ear/lib
In addition the script will check that all the give jar files exist and will abort the execution if any of them is missing.
Find attached the initial version of the proposed script.
Let me know what you think.
Excellent idea! I would like to add - I already saw the work you did on engine-manage-domains. When we work on development machines, we might have the jars reside in different places.
Yes, this is one of the motivations for this new engine-java script, the fact that we can't expect the build-classpath script to work in all environments, specially development environments.
I wanted to create a script that will allow for example to use build-classpath on spring-ldap-core, but I did not have a soft link for that in /usr/share/java (is that what I needed to do?)
Yes, just create the link in /usr/share/java and it should work. If you want to keep it compatible with the Fedora spring-ldap package create it as "/usr/share/java/spring-ldap/spring-ldap-core.jar", then you should be able to use it with "build-classpath spring-ldap/spring-ldap-core".
I guess we will have to differentiate between the need of dev and production for this script.
I would rather try to make it work in all the environments without change, but I know that is quite difficult. -- 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 06/05/2012 06:04 PM, Juan Hernandez wrote:
On 06/05/2012 04:41 PM, Yair Zaslavsky wrote:
On 06/05/2012 03:53 PM, Juan Hernandez wrote:
Hello all,
I would like to propose an improvement in the way we build class-paths in the tools associated to the engine. At the moment we have at least two different ways to build classpaths:
1. Hard coded in the scripts, with maybe some variables:
CP=$EAR_LIB/engine-encryptutils.jar:$EAR_LIB/engine-compat.jar:...
This depends a lot on where we place the jar files, and we need to place them in different places in different environments if we want to adhere to common packaging practices.
2. Use the build-classpath script:
CP=`build-classpath engine-encryptutils engine-compat ...`
This depends less on the place we put them, but it doesn't work in development environments where some jars are not installed to the proper system locations.
None of these is good for all environments.
I would like to replace this classpath building logic with an script that performs the task in an smarter way and that works in all our environments (production, development, Fedora, RHEL, etc).
My proposal is to create a "engine-java" script that we should use always when invoking java programs. This script will receive the same parameters that the "java" launcher receives, but the "-cp" or "-classpath" options will contain not the absolute name of the jar files, but just a simple jar name instead, something like "commons-logging", "commons-codec" or "engineencryptutils". The script will extract the "-cp" or "-classpath" options given and use them to do a search of the jar files in the locations where they can be in different environments:
/usr/share/java /usr/share/java/ovirt-engine /usr/share/ovirt-engine/engine.ear /usr/share/ovirt-engine/engine.ear/lib <your jboss development installation>/engine.ear <your jboss development installation>/engine.ear/lib
In addition the script will check that all the give jar files exist and will abort the execution if any of them is missing.
Find attached the initial version of the proposed script.
Let me know what you think.
Excellent idea! I would like to add - I already saw the work you did on engine-manage-domains. When we work on development machines, we might have the jars reside in different places.
Yes, this is one of the motivations for this new engine-java script, the fact that we can't expect the build-classpath script to work in all environments, specially development environments.
I wanted to create a script that will allow for example to use build-classpath on spring-ldap-core, but I did not have a soft link for that in /usr/share/java (is that what I needed to do?)
Yes, just create the link in /usr/share/java and it should work. If you want to keep it compatible with the Fedora spring-ldap package create it as "/usr/share/java/spring-ldap/spring-ldap-core.jar", then you should be able to use it with "build-classpath spring-ldap/spring-ldap-core".
I guess we will have to differentiate between the need of dev and production for this script.
I would rather try to make it work in all the environments without change, but I know that is quite difficult.
Juan - and still, I feel this will be a great improvement. Maybe what should be done is have, for example a script called - engine-manage-domains-devel - this script will run "engine-java-devel" which will create the needed soft-links for developers, and then will run engine-manage-domains. Engine-manage-domains will run engine-java. Engine-java will check if the soft links already exist, and if they exist - will not create them. Maybe this way we can utilize engine-manage-domains-devel to use engine-manage-domains with minimal changes.
On 06/05/2012 02:53 PM, Juan Hernandez wrote:
Hello all,
I would like to propose an improvement in the way we build class-paths in the tools associated to the engine. At the moment we have at least two different ways to build classpaths:
1. Hard coded in the scripts, with maybe some variables:
CP=$EAR_LIB/engine-encryptutils.jar:$EAR_LIB/engine-compat.jar:...
This depends a lot on where we place the jar files, and we need to place them in different places in different environments if we want to adhere to common packaging practices.
2. Use the build-classpath script:
CP=`build-classpath engine-encryptutils engine-compat ...`
This depends less on the place we put them, but it doesn't work in development environments where some jars are not installed to the proper system locations.
None of these is good for all environments.
I would like to replace this classpath building logic with an script that performs the task in an smarter way and that works in all our environments (production, development, Fedora, RHEL, etc).
My proposal is to create a "engine-java" script that we should use always when invoking java programs. This script will receive the same parameters that the "java" launcher receives, but the "-cp" or "-classpath" options will contain not the absolute name of the jar files, but just a simple jar name instead, something like "commons-logging", "commons-codec" or "engineencryptutils". The script will extract the "-cp" or "-classpath" options given and use them to do a search of the jar files in the locations where they can be in different environments:
/usr/share/java /usr/share/java/ovirt-engine /usr/share/ovirt-engine/engine.ear /usr/share/ovirt-engine/engine.ear/lib <your jboss development installation>/engine.ear <your jboss development installation>/engine.ear/lib
In addition the script will check that all the give jar files exist and will abort the execution if any of them is missing.
Find attached the initial version of the proposed script.
Let me know what you think.
Regards, Juan Hernandez
I submitted the following draft to gerrit, in case you want to take a look at the current state of the script: http://gerrit.ovirt.org/#/c/5129 -- 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.
participants (3)
-
Juan Hernandez -
Oved Ourfalli -
Yair Zaslavsky