[Engine-devel] Improve classpath building

[Yair Zaslavsky]

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.