Skip to content

Updating my local version#1

Merged
kmader merged 33 commits into
4Quant:masterfrom
scijava:master
Dec 5, 2014
Merged

Updating my local version#1
kmader merged 33 commits into
4Quant:masterfrom
scijava:master

Conversation

@kmader
Copy link
Copy Markdown

@kmader kmader commented Dec 5, 2014

No description provided.

dscho and others added 30 commits October 7, 2014 18:11
Samuel Inverso noticed, and Mark Hiner diagnosed, that compiling SciJava
plugins using javac without specifying an output directory will write the
annotation index into an incorrect location (instead of META-INF/json/ it
is written into the top-level directory).

This can be verified using a very simple example x1.java file:

-- snip --
import org.scijava.plugin.Plugin;
import org.scijava.plugin.SciJavaPlugin;

@plugin(type = SciJavaPlugin.class)
public class x1 implements SciJavaPlugin { }
-- snap --

The reason is that javac's DefaultFileManager will strip out any
subdirectory in the path passed to the createResource() method unless
an output directory is specified.

Work around that by detecting the situation and creating the subdirectory
explicitly.

This fixes imagej/imagej-launcher#22.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Kevin Mader reported that certain @interfaces were not handled gracefully
because the annotation processor would encounter AnnotationValue instances
and not know how to handle them.

This fixes #130.

Without these changes, the example provided below yielded the following
exception:

	error: java.io.IOException: Cannot handle object of type class com.sun.tools.javac.code.Attribute$Constant
		at org.scijava.annotations.AbstractIndexWriter.writeObject(AbstractIndexWriter.java:252)
		at org.scijava.annotations.AbstractIndexWriter.writeArray(AbstractIndexWriter.java:306)
		at org.scijava.annotations.AbstractIndexWriter.writeObject(AbstractIndexWriter.java:243)
		at org.scijava.annotations.AbstractIndexWriter.writeMap(AbstractIndexWriter.java:288)
		at org.scijava.annotations.AbstractIndexWriter.writeObject(AbstractIndexWriter.java:249)
		at org.scijava.annotations.AbstractIndexWriter.writeMap(AbstractIndexWriter.java:288)
		at org.scijava.annotations.AbstractIndexWriter.writeObject(AbstractIndexWriter.java:249)
		at org.scijava.annotations.AbstractIndexWriter.write(AbstractIndexWriter.java:99)
		at org.scijava.annotations.AnnotationProcessor.process(AnnotationProcessor.java:91)
		at com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:627)
		...

-- snip BlockIdentity.java --
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;

import org.scijava.annotations.Indexable;

@target(ElementType.TYPE)
@retention(RetentionPolicy.RUNTIME)
@indexable
public @interface BlockIdentity {
    String blockName();
    String desc() default "";
    String[] inputNames();
    String[] outputNames();
}
-- snap --

-- snip Test.java --
@Blockidentity(blockName = "GrowRegionsBlock",
            inputNames= {"labeled image", "mask image"},
            outputNames= {"filled labels", "filled neighborhood"})
public class Test {}
-- snap --

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Adapt instances of AnnotationValue in the annotation processor
Once the test ran successfully, bar is distinctively different from 0...

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The most generic way to provide a bunch of Strings to persist is by
passing an Iterable<String> for writing and handling an Iterable<String>
when reading.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is similar to the LinkedHashMap structure, except that an
already-existing item can be easily put to the front of the list, or the
back.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The newly-introduced History class maintains the history of most recently
executed statements and has functionality to persist and retrieve the list
from the preferences.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The newly-introduced ScriptInterpreter class provides all the
functionality of a script interpreter sans the graphical user interface.
It can execute statements and persists a history of most recently
executed statements.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It simplifies things downstream to be able to query the associated
ScriptLanguage later, since it is known at construction time anyway.

This does *not* persist the most recently used interpreter language!
The 'current command' is the command that is not yet in the history. It
is very convenient to be able to go back in history, just to have a
look, before continuing to craft the current command (and it would be
annoying if it was lost when going back in history). Of course, if the
user decides to execute a different command from the history instead,
the edits to the 'current command' are lost.

This behavior is most in line with the Unix shell behavior power users
might be used to.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Add the user-interface independent part of a generic script interpreter
Signed-off-by: Jenkins <jenkins@dev.loci.wisc.edu>
Sure, there is BeanShell. But that would add another dependency to
the project! The ReflectedUniverse is simple, tried and true.

Sure, you almost never want to actually use it, since compile-time
safety is much preferred. But when you _do_ need to do some big
reflection thing, it is quite handy.

For example: suppose you want to remove a dependency from a project,
and deprecate the methods that used it. You can leave the methods as
is, so that they behave exactly the same way, but wrap the offending
code in a ReflectedUniverse to avoid the compile-time dependency. That
way, the deprecated methods will continue to work at least in the case
where the removed dependency is still present on the classpath.
The LogService was only used for debugging, and only to emit the same
information already thrown by the checked ReflectException. In other
words: totally superfluous.

The only really valid usage was in the main method, which is merely a
test driver. That method uses System.out.println elsewhere, so using
System.err.println for that one situation is more consistent anyway.
Signed-off-by: Jenkins <jenkins@imagej.net>
See: http://fiji.sc/bugzilla/show_bug.cgi?id=944

Of course, it is quite odd for the child module to be null. It may be a
symptom of a larger issue. But it's still better not to throw NPE here.
Theoretically, no object should have a null title. But just in case,
let's use the null-friendly MiscUtils.compare method for titles, too.
Since it is possible for getIdentifier() to return null, we need to
guard against that circumstance, and only return non-null identifiers.
ctrueden and others added 3 commits November 12, 2014 11:03
Fix annotation processing when running javac without -d <directory>
Updated to pom-scijava 5.1
Signed-off-by: Jenkins <jenkins@imagej.net>
kmader added a commit that referenced this pull request Dec 5, 2014
Updating my local version
@kmader kmader merged commit 0526b88 into 4Quant:master Dec 5, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants