Hello, <br><br><div class="gmail_quote">2011/8/17 Rudy Godoy Guillén <span dir="ltr"><<a href="mailto:rudy@stone-head.org">rudy@stone-head.org</a>></span><br><br><removing some bits><br><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><div class="gmail_quote">I've managed to isolate the problem. The error is related to the jar files on clc/lib. The Debian build uses debian/build-jars to make symlinks to installed Java libs, however the "normal" upstream ant build downloads from eucalyptus and builds them correctly. <br>


<br>Currently I've the following version from sid:<br>- groovy 1.8.1<br><br>cloud-lib.tar.gz ships:<br>- groovy 1.7.0<br><br>The packaging build error, at the end, is related to Jar Index conflict. According it's definition there's a difference between what is expected and what is in the INDEX.LIST for that class in the jar file. I'm about to identify if this is related to the groovy version or to other class.</div>
<br>
<div class="gmail_quote"><br></div><div class="gmail_quote">Best regards,</div><div class="gmail_quote">Rudy</div><div class="gmail_quote"><br><div class="gmail_quote">/home/rudy/debian/devel/soc-2011/eucalyptus/pkg-eucalyptus/build-area/eucalyptus-2.0.3/clc/modules/msgs/src/main/java/\</div>
<div class="im">
<div class="gmail_quote">org/apache/tools/ant/util/DateUtils.java</div><div class="gmail_quote">org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:</div></div><div class="gmail_quote">General error during conversion: Invalid index</div>

<div class="gmail_quote"><br></div><div class="gmail_quote">sun.misc.InvalidJarIndexException: Invalid index</div><div class="gmail_quote">        at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:870)</div>

<div class="gmail_quote">        at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:779)</div><div class="gmail_quote">        at sun.misc.URLClassPath.getResource(URLClassPath.java:185)</div><div class="gmail_quote">

        at java.net.URLClassLoader$1.run(URLClassLoader.java:209)</div><div class="gmail_quote">        at java.security.AccessController.doPrivileged(Native Method)</div><div class="gmail_quote">        at java.net.URLClassLoader.findClass(URLClassLoader.java:205)</div>

<div class="gmail_quote">        at java.lang.ClassLoader.loadClass(ClassLoader.java:321)</div><div class="gmail_quote">        at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:673)</div><div class="gmail_quote">

        at groovy.lang.GroovyClassLoader.loadClass(GroovyClassLoader.java:540)</div><div class="gmail_quote">        at org.codehaus.groovy.control.ResolveVisitor.resolveToClass(ResolveVisitor.java:663)</div><div class="gmail_quote">

        at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:268)</div><div class="gmail_quote">        at org.codehaus.groovy.control.ResolveVisitor.resolveFromStaticInnerClasses(ResolveVisitor.java:446)</div>

<div class="gmail_quote">        at org.codehaus.groovy.control.ResolveVisitor.resolve(ResolveVisitor.java:268)</div><div class="gmail_quote">        at org.codehaus.groovy.control.ResolveVisitor.visitClass(ResolveVisitor.java:1128)</div>

<div><br></div></div><div><div></div><div class="h5"><br>-- <br>Rudy Godoy<br><a href="http://stone-head.org" target="_blank">http://stone-head.org</a><br>
<br>
</div></div></blockquote></div><br><br>After some time trying to figure out what the problem is I did the simple thing and told the build not to use the debian/build-jars file to link with system-wide jars (installed by the dependencies). The build was successful and I'm about to install it and test. I'll also commit this change to the repo. <br>
<br>For this problem to be eliminated, given we want to use java package dependencies for the build system, we need to figure which is the class (jar) file that makes the JarIndex fail. There are ways to do it using Eclipse, which seems to be the most accurate we can get so far according my research on the subject.<br>
<br>Though this is not a definitive solution it seems to work. We now should focus on upgrading the packaging system and tackle those remaining bits.<br><br>Have a nice weekend.<br clear="all"><br>-- <br>Rudy Godoy<br><a href="http://stone-head.org" target="_blank">http://stone-head.org</a><br>
<br>