Alon Bar-Lev has posted comments on this change.
Change subject: packaging: Find and check JVM during setup (#834436)
......................................................................
Patch Set 2:
> The engine-setup code that tries to find the JVM tries to
> locate a symlink that points to the actual location of
> the JVM. In Fedora, for example, the result will be this:
> /usr/lib/jvm/jre-1.7.0-openjdk.x86_64
Yes, I know.
But why won't we run on ppc machine? or any other architecture? We are noarch,
right?
> That symlink is provided by the java-1.7.0-package, and it won't
> change when the package is updated (it doesn't contain the micro version).
> This works with other distributions as well, for example in Debian the
> result will be this:
> /usr/lib/jvm/java-1.7.0-openjdk-amd64
> That won't change either when the package is updated, as it doesn't include
> the micro version.
Again, notice the architecture.
And, why won't we run on java-1.8.0?
> Doesn't this work in Gentoo?
*NO* Gentoo is not primitive as the redhat and debian.
> As far as I understand there is no way to query alternatives for a specific
> version,
> at least not in the flavour of alternatives in Fedora.
Right, this why this is soooo primitive. The environment has the ability to
set, but not query... very disappointing.
> You can of course run "alternatives --display java", but then you will need
> to parse
> the names of the directories and decide based on that.
Yes, I already looked at this and found it unusable, I even tried to figure out
how to parse the data files of alternatives, and found this unusable as well.
> I think that "java-config" is Gentoo only.
Right, but it is an example of asking the environment a query instead of trying
to hack an uncooperative environment. All I say is that you need to take into
account cooperative environments as well.
If we bootstrap always from sh script, and we had:
. /etc/vars
At vars we could ether provide value or $(program), which was a great solution
for all.
But since we use python and do not allow execution of code, we have a problem.
We can put /usr/share/engine/bin/engine_java with simple shell script that
outputs the JAVA_HOME.
It can hack the system or use utility to figure this out.
It can be call at common:
JAVA_HOME="$(engine_java)"
Or be called by python...
Anyway, just wanted to alert.
I don't really mind if only for the primitive systems we put a JAVA_HOME
constant in our configuration during installation.
But, I do want the option to acquire this at runtime from a program output, and
if this is implemented, it can be used for all cases.
> What Java program will you suggest to check the java version? Something like
> this?
> public static void main(String[] args) {
> System.out.println(System.getProperty("java.version"));
> }
> That will print "1.7.0_05-icedtea" and "1.7.0_05" in Gentoo and you will
> need still to parse it.
I thought of using RuntimeMXBean...
> Or are you proposing to do like autotools and check for specific features?
> That is overkill in my opinion.
autotools are good for build time, we are discussing runtime... :)
--
To view, visit http://gerrit.ovirt.org/7549
To unsubscribe, visit http://gerrit.ovirt.org/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: Ib279ea8111825ec35a25f9ba6ee37b481ed4354f
Gerrit-PatchSet: 2
Gerrit-Project: ovirt-engine
Gerrit-Branch: master
Gerrit-Owner: Juan Hernandez <[email protected]>
Gerrit-Reviewer: Alex Lourie <[email protected]>
Gerrit-Reviewer: Alon Bar-Lev <[email protected]>
Gerrit-Reviewer: Juan Hernandez <[email protected]>
Gerrit-Reviewer: Moran Goldboim <[email protected]>
Gerrit-Reviewer: oVirt Jenkins CI Server
_______________________________________________
Engine-patches mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-patches
