Hi Michael, Sorry to hear that the POM version detection is not working for KNIME. If the problem is *only* with the deprecated static VERSION, we plan to eliminate that soon anyway. But if the ImageJ#getVersion() method always returns null, that is a bad thing and we will need to fix it.
To debug this, I would need to set up a KNIP developer environment on my machine here so that I can reproduce and debug the issue. Are there instructions for doing that online? Thanks, Curtis P.S. Please CC imagej-devel on replies. Sometimes other developers may reply more quickly than I do, so it may save you time. On Mon, Sep 17, 2012 at 2:15 AM, Michael Zinsmaier <[email protected] > wrote: > Hi Curtis, > > thanks for your reply and the explenation. Unfortunately I have already a > new issue. We tried to migrate the KNIME Image Extension > to the beta 4 version of ImageJ and we have some problems with the > introduced integration of the POM file. The getPOM method > does not work in the plugin/eclipse environment that is used by KNIME I > think this might be related to some OSGI stuff having separate > class loaders for each plugin... > In any case getPOM does not find the POM file although it is packed into > the ImageJ jar file. Especially the static loading of the version number > causes therefore some problems for us. > > /** @deprecated Use {@link ImageJ#getVersion()} instead. */ > @Deprecated > public static final String VERSION = POM.getPOM(ImageJ.class, > "net.imagej", "ij-core").getVersion(); > > Do you have an idea how this could be resolved? > > Best regards, > Michael > > Hi Michael, > > >> There seems to be an issue with the InputHarvester and the SwingPanel if >> the object types of primitive java types are used as input parameters (e.g. >> Boolean instead of boolean). > > > Sorry for the delay in my reply. I fixed the bug shortly after sending > my first mail, but was waiting to reply back until I did some more thorough > investigation of the widget framework. > > In short, the NPE is fixed, and both plugins will work now. > > The long story is that despite that, there is one remaining issue of > sorts with certain types of widgets. The toggle widget (with big B > Booleans) is one of them, and the choice widget is another. The issue is > that in some cases, the widget is not totally capable of reflecting the > model state. > > In the case of Boolean, the widget model may begin with a null value, > but the toggle widget is only capable of displaying false or true. It will > display unchecked for null, and if the user presses OK right away, the > Boolean will be null (the widget changes nothing right now). But if you > check and then uncheck the box again, the parameter value goes from null to > true, and then from true to false. There is no way to set it back to null. > > In the case of the choice widget, the model may begin with a value that > is not on the list of allowed choices (again, null in particular is a big > offender here). The choice widget immediately constrains the dropdown box > to the first item on the list and overwrites the model. So the widget ends > up being the reason the parameter doesn't end up with an (invalid) null > value. > > This behavior is inconsistent, and ideally the model itself would > enforce value constraints, and the widgets would not overwrite them. > > However, given the amount of time needed to correct this admittedly > rather trivial inconsistency/deficiency, we are not going to worry about it > for the time being. > > Please let us know if you have any other questions or problems with > ImageJ2! > > Regards, > Curtis > > > On Thu, Aug 23, 2012 at 9:57 AM, Curtis Rueden <[email protected]> wrote: > >> Hi Michael, >> >> >>> There seems to be an issue with the InputHarvester and the SwingPanel if >>> the object types of primitive java types are used as input parameters (e.g. >>> Boolean instead of boolean). >> >> >> Thanks for the report. It's definitely a bug due to our recent >> refactoring of the widget system. Both Boolean and boolean are supposed to >> work. I'll look into fixing it today. >> >> -Curtis >> >> P.S. Hopefully I will have time to respond to your ImgLib mail from >> yesterday, too. I really appreciate you taking the time to look at and >> improve the Projector logic. We did the minimum necessary at the time to >> get something working, but currently everything is planar, and there is no >> built-in (i.e., ImgLib2) zoom capability, which we will eventually need. >> >> >> On Thu, Aug 23, 2012 at 8:24 AM, Michael Zinsmaier < >> [email protected]> wrote: >> >>> Hi Curtis, >>> >>> I try currently to integrate the new imglib and ImageJ2 version (stuff >>> from yesterday) into the KNIME ImageJ2 plugin. >>> There seems to be an issue with the InputHarvester and the SwingPanel if >>> the object types of primitive java types are >>> used as input parameters (e.g. Boolean instead of boolean). >>> >>> The following plugin works fine: >>> >>> @Plugin(menu = {@Menu(label = "works")}, >>> headless=true) >>> public class Working<T extends RealType<T>> implements RunnablePlugin { >>> >>> @Parameter(type = ItemIO.INPUT) >>> private boolean test; >>> >>> @Parameter(type = ItemIO.OUTPUT) >>> private String output; >>> >>> public void run() { >>> if (test) { >>> output = "plugins can be defined as fragments of >>> imagej.core"; >>> } >>> } >>> >>> } >>> >>> >>> while this plugin (Boolean instead of boolean) cannot be executed and >>> results in a null pointer exception. >>> >>> >>> @Plugin(menu = {@Menu(label = "works not")}, >>> headless=true) >>> public class NotWorking<T extends RealType<T>> implements RunnablePlugin >>> { >>> >>> @Parameter(type = ItemIO.INPUT) >>> private Boolean test; >>> >>> @Parameter(type = ItemIO.OUTPUT) >>> private String output; >>> >>> public void run() { >>> if (test) { >>> output = "plugins can be defined as fragments of >>> imagej.core"; >>> } >>> } >>> >>> } >>> >>> Are only primitive types supported or is it a bug? >>> >>> Regards >>> Michael >>> >> >> > >
_______________________________________________ ImageJ-devel mailing list [email protected] http://imagej.net/mailman/listinfo/imagej-devel
