<div dir="ltr">Hi Jay,<div><br></div><div><div>> I typically deploy JEX as a runnable jar via the Eclipse export.</div><div>> However, the exported jar fails to run while the Eclipse project</div><div>> encounters no such issue. The export process seems to break the IJ2</div>

<div>> portion of the application making it impossible at the moment to</div><div>> attempt to deploy the JEX version with the IJ2 enhancements. I've</div><div>> isolated the issue to being purely related to the IJ2 set of jars that</div>

<div>> I included into the project.</div></div><div><br></div><div>This problem is almost certainly due to the fact that the SciJava Common plugin mechanism stores a file in each JAR at: /META-INF/json/org.scijava.plugin.Plugin. And when combining multiple JARs into an uber-JAR, those files need to be aggregated together rather than overwriting one another. We ran into the very same problem using the maven-assembly-plugin to build an uber-JAR. Our workaround is here:</div>

<div><br></div><div><a href="https://github.com/imagej/imagej/blob/imagej-2.0.0-beta-7.6/bin/gen-jar-with-deps.sh">https://github.com/imagej/imagej/blob/imagej-2.0.0-beta-7.6/bin/gen-jar-with-deps.sh</a><br></div><div><br>

</div><div>Which calls the AnnotationCombiner class from SciJava Common:</div><div><a href="https://github.com/scijava/scijava-common/blob/scijava-common-2.9.0/src/main/java/org/scijava/annotations/AnnotationCombiner.java">https://github.com/scijava/scijava-common/blob/scijava-common-2.9.0/src/main/java/org/scijava/annotations/AnnotationCombiner.java</a></div>

<div><br></div><div>In the future we will look into switching to maven-shade-plugin to create such an uber-JAR.</div><div><br></div><div>But I still don't know if/how you can do that with Eclipse's "Export executable JAR" feature.</div>

<div><br></div><div><div>> I also noticed that the during the successful eclipse run there is a</div><div>> line which reads... [WARNING] Overridden plugin</div><div>> ij.plugin.LutLoader("3-3-2 RGB") is blacklisted  Do you think there is</div>

<div>> any connection?</div></div><div><br></div><div>Nope, that warning is unrelated and can be safely ignored.</div><div><br></div><div><div>> I know that Eclipse, when it exports a runnable jar, creates a</div><div>

> relatively non-standard jar hierarchy (jarinjar), which might be the</div><div>> issue</div></div><div><br></div><div>Hmm, in that case, it may be possible to improve SciJava Common to find such META-INF in nested JARs. Feel free to file a PR against scijava-common (<a href="https://github.com/scijava/scijava-common">https://github.com/scijava/scijava-common</a>) for this feature if you really need it.</div>

<div><br></div><div>To pursue that, you'd want to inspect your uber-JAR using the Java JAR command line tool (e.g., "jar tf myUberJar.jar") to see exactly what got put in there. Maybe unpack it ("jar xf myUberJar.jar") and then examine any nested JARs, as well.</div>

<div><br></div><div>The relevant code in scijava-common is here:</div><div><a href="https://github.com/scijava/scijava-common/blob/scijava-common-2.9.0/src/main/java/org/scijava/annotations/Index.java#L130">https://github.com/scijava/scijava-common/blob/scijava-common-2.9.0/src/main/java/org/scijava/annotations/Index.java#L130</a><br>

</div><div><br></div><div>The code uses ClassLoader.getResources() to access all annotations within META-INF/json across all JAR files on the classpath. If Eclipse really embeds JARs inside other JARs, you'd have to smarten up that method to support that somehow, which would be an unfortunate addition in complexity.</div>

<div><br></div><div>Easier would be to avoid using uber-JARs at all and instead just ship with all your JAR libraries separately. Then all the annotations will be discovered as expected.</div><div><br></div><div>Or you could somehow run the AnnotationCombiner across all of your JARs when building your uber-JAR, perhaps using the maven-shade-plugin. If you structured JEX as a Maven project it would be relatively straightforward to use that, and do your releases from the command line, too.</div>

<div><br></div><div>Sorry I can't be more helpful, but we really avoid doing things in ways that cannot be automated from the command line.</div><div><br></div><div>Regards,</div><div>Curtis</div><div><br></div></div>

<div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 20, 2014 at 10:45 PM, Jay Warrick <span dir="ltr"><<a href="mailto:jay.w.warrick@gmail.com" target="_blank">jay.w.warrick@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Guys,<div><br></div><div>I have had some success with incorporating IJ2 plugins but ran into an issue during deployment that I wonder if you have run into before. I typically deploy JEX as a runnable jar via the Eclipse export. However, the exported jar fails to run while the Eclipse project encounters no such issue. The export process seems to break the IJ2 portion of the application making it impossible at the moment to attempt to deploy the JEX version with the IJ2 enhancements. I've isolated the issue to being purely related to the IJ2 set of jars that I included into the project. I did this by making a separate project with only IJ2 jars (which also includes the IJ1 jar) and a simple static main that uses IJ2 to run the "Fill" plugin on a tif that is on my computer. The program runs successfully when run from eclipse but produces an error when exported and run as a runnable jar. Here is the script, the output from the Eclipse run, output from the jar run, and list of imported jars for the simple test project. Note that I had to add the "static{DefaultLegacyService.preinit();}" to the class to get things to work in the presence of the IJ1 jar that is included.</div>

<div><br></div><div></div></div><br><div style="word-wrap:break-word"><div></div></div>
<br><div style="word-wrap:break-word"><div></div></div>
<br><div style="word-wrap:break-word"><div></div></div>
<br><div style="word-wrap:break-word"><div></div><div><br></div><div><div>Do you have any suggestions? I appears that it thinks that the DefaultLUTService is invalid per "Caused by: java.lang.IllegalArgumentException: Invalid service: imagej.data.lut.DefaultLUTService". I also noticed that the during the successful eclipse run there is a line which reads... <span style="color:rgb(255,38,0);font-family:Monaco;font-size:11px">[WARNING] Overridden plugin ij.plugin.LutLoader("3-3-2 RGB") is blacklisted</span>  Do you think there is any connection?</div>

<div><br></div><div>I know that Eclipse, when it exports a runnable jar, creates a relatively non-standard jar hierarchy (jarinjar), which might be the issue given the "<span style="font-family:Menlo;font-size:11px">Caused by: java.lang.IllegalArgumentException: URI is not hierarchical</span><span style="font-family:Menlo;font-size:11px;white-space:pre-wrap">    </span><span style="font-family:Menlo;font-size:11px">at java.io.File.<init>(File.java:418)</span>" error.</div>

</div><div><br></div><div>I'm not well versed enough in maven or other such dependency management systems to be able to export something for you to import (unless it is super easy and I just don't know the correct menu options :-) But, in case it helps, this is how I built the small test project. To import the jars, I import the jar files as files directly into a package called lib so the jar files are not just referenced but actually a part of the project (probably not best practice but found it effective for our project and haven't had issues with the other 25 jars that we use in the JEX project). Then I configure the build path and "Add Jars" selecting the jars that are imported into the project. During export, I choose to package required libraries into generated jar. </div>

<div><br></div><div>Thanks for any insight,</div><div><br></div><div>Jay</div></div><br></blockquote></div><br></div>