Using Netbeans platform as modular basis?

[Yili Zhao]

Hi,
Because Netbeans is a wonderful modular framework, so I just wonder
that is there any discuss about
use Netbeans platform as modular basis?

--
Yili Zhao

[Grant B. Harris]

Yili Zhao -- --

This is a timely question, and something that I have been looking into extensively.  There are numerous ways we might possibly utilize some of the NetBeans modules, perhaps organized into three levels:

 

1) The NetBeans Lookup API can be utilized for a number of purposes:

• as a service loader/ global lookup. (@ServiceProvider annotation is esp. handy)
• as a dependency injection mechanism (e.g. injectable singletons)
• it provides a LookupListener mechanism which enables

-         publish/subscribe ‘event bus’

-         selection management (for ‘context aware actions’ and tools, etc).

-         class reloading

• it provides an easy way to design extensible APIs (as a way to implement the 'capability pattern’)

 

(See: AboutLookup, What is a Lookup?)  In addition to Lookup, there are other parts of the Utilities API that could also be utilized at this level.

 

2) The NetBeans Module System

 

The NB ‘runtime container’ provides much of the functionality of OSGi like dependency resolution, versioning, visibility (import/export)… NetBeans has recently adapted to/incorporated OSGi in a variety of ways, making it much less of an either/or situation. (See OSGiAndNetBeans)  The NB Module System could provide the foundation for a robust modular architecture, should we decide we need this level of complexity.  (See: NetBeans Runtime Container, the module system, Modules API, DevFaqClassLoaders)

 

3) NetBeans Platform Application

 

As you probably know, the NetBeans IDE is build on top of the NB Platform.  NetBeans Platform provides a robust application framework.  (There are many examples, especially interesting is imagine.)  Whether or not we develop a version of ImageJ using a ‘rich client platform’, my hope is that we can architect ImageJ components so that can be incorporated into an RCP application - for instance, neurospy has incorporated ImageJ in some ways interesting ways, and Bio7 is an Eclipse-RCP-based that has actually has ImageJ embedded in it.  A Platform-based application could provide a programmable/extensible image processing platform that leverages the power of the NetBeans IDE.  (BTW, building an application on the NB Platform does not lock developers into using NetBeans IDE.)

 

For more of my NetBeans-related reseach, see:[http://imagejdev.org/gbh/netbeans]

 

I'm also experimenting with a project by one of the NetBeans core developers (Jesse Glick) called Sezpoz.    It  provides “modular, declarative registration of  services, simple syntax verified at compile time, with service metadata inspectable prior to class loading” without using bytecode processing.  (Also, see Declarative Registration Using Annotations)

 

I’m very interested to hear your thoughts on this.  Have you used any of the NetBeans Modules for application development (other than the IDE)??

 

-- Grant Harris

[Dimiter Prodanov]

Hi Grant,

This sounds interesting but may be an overkill. Most of the people
including me are interested in application development.
If the API is complicated too much its practical utility will drop
significantly.
Look for example at the 10s of subprojects of Apache in java: it is
difficult even to memorize their name let alone understand what they
are used to.

best regards,

Dimiter

> --
> You received this message because you are subscribed to the Google Groups
> "ImageJX" group.
> To post to this group, send email to ima...@googlegroups.com.
> To unsubscribe from this group, send email to
> imagejx+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/imagejx?hl=en.
>

[Curtis Rueden]

Hi Dimiter & everyone,

This sounds interesting but may be an overkill. Most of the people
including me are interested in application development.
If the API is complicated too much its practical utility will drop
significantly.

Yes, we agree that API should be kept simple. And actually, one of our big goals is to simplify how ImageJ scripts and plugins are developed. Simplicity is a serious consideration for us.

It is not our wish to introduce change for change's sake, or add superfluous dependencies on external libraries. However, we do seek to leverage technologies and introduce change (preserving backward compatibility whenever possible) for the sake of simplifying and enriching ImageJ-based development. It should be possible to continue using the same ImageJ you are familiar with, but we hope new features introduced will be compelling enough to justify any learning curve needed to adopt them.

For example, Grant and Johannes have developed a declarative plugin mechanism that obviates the need to write code referencing GenericDialogs. E.g., in your plugin class, you would declare some instance fields like:

@Parameter
public String firstName = "Curtis";
@Parameter(label = "Your last name", columns = 15)
public String lastName = "Rueden";
@Parameter
public ImagePlus inputImage;

The plugin infrastructure automatically takes care of prompting for these parameter values using a GenericDialog, harvesting from a configuration file or macro options in batch mode, etc., without the plugin's run() method ever needing to assign values or harvest anything to populate these fields. You can just write code assuming the fields are set correctly from the beginning. Is that not simpler than the current approach?

Anyway, regarding Netbeans, it seems premature to assume at a high level that the use of any Netbeans component will complicate matters rather than simplify them. To be blunt, there is a rich landscape of Java development tools out there, and we plan to take advantage of those which are robust and mature. We want to leverage the infrastructural work others have done over the past decade, but of course we are carefully considering each technology before embracing it.

For example, I have restructured most of LOCI's Java projects to use Maven, which has greatly simplified and standardized builds, reducing the need for custom Ant scripts while introducing lots of useful new functionality (I can elaborate if anyone is interested). I am planning to do the same for the ImageJDev ImageJ repository, since it will greatly ease dependency management.

Regarding the specific Netbeans technologies Grant mentioned:

• Netbeans Lookup would make it easier/simpler to load plugins efficiently—not more complex—so seems like a win to me, especially since the approach we are pursuing will allow plugins to (optionally) self-declare their additions to the GUI including menu items, toolbar icons, etc., more flexibly than the current plugin logic. More importantly, developers of ImageJ plugins will not need to know anything about how the plugins are discovered—that logic is purely internal to ImageJ.
  
• Adding Netbeans Runtime and/or OSGi metadata to JAR files will help to modularize the functionality for external developers, so I don't see a downside—the JAR will still work fine "as normal." For people who don't care about OSGi, nothing changes.
  
• Use of the Netbeans Platform would mostly be of benefit to the creation of a Swing-based GUI, and/or the ability to embed ImageJ components in other applications. If you want to see how powerful this can be, check out the Bio7 screenshots: http://129.70.40.49/modelling/?page_id=14. That said, we are not set on using the Netbeans Platform, and right now are actually leaning toward use of individual components as appropriate.

From our discussion with the community, it is clear that ImageJ development—both plugins, and on the core itself—must be straightforward with various development workflows, especially: command line, Fiji Script Editor, ImageJ macro editor, Eclipse, and Netbeans. We absolutely do not want to "lock in" anyone to particular development style.

Another important consideration is licensing. Since ImageJ was historically developed at NIH it currently disclaims all copyright. But due to the distributed development taking place now, that situation must change: moving forward, a BSD license is the natural choice to allow everyone to continue to use ImageJ without restriction. Consequently, any dependencies we introduce must be compatible with that license—e.g., other BSD libraries, Apache 2, and LGPL are OK, but GPL is not.

Look for example at the 10s of subprojects of Apache in java: it is
difficult even to memorize their name let alone understand what they
are used to.

Sorry, I don't understand this argument. "Apache" is not one monolithic project, but rather a community of many projects. To me that seems similar to saying you don't have all the projects on SourceForge memorized (though to be fair, the Apache foundation is much more selective than SourceForge).

In short, I strongly encourage everyone to consider the specific technologies being proposed rather than merely making blanket statements about third party dependencies being dangerous or overkill. At the ImageJ conference in October we will demo some of the benefits of these technologies, particularly the imglib library (http://pacific.mpi-cbg.de/wiki/index.php/Imglib), the new plugin loading mechanism, and Bio-Formats for core I/O.

-Curtis

[Dimiter Prodanov]

Hi Curtis,

>>
From our discussion with the community, it is clear that ImageJ
development—both plugins, and on the core itself—must be
straightforward with various development workflows, especially:
command line, Fiji Script Editor, ImageJ macro editor, Eclipse, and
Netbeans. We absolutely do not want to "lock in" anyone to particular
development style.
<<

I agree 100% with this. We should not lock people into particular
development pattern.

I am also thinking that BSD is a good choice. In this manner the
developers/companies can keep the IP and this will make IJ more
attractive as a platform.

I have specific experience with Apache java projects and must say that
the code structure is complicated. So I don't make an unsupported
statement. I am personally using Eclipse but had also experience with
the first versions of Netbeans.

I am writing something similar to the imglib. Again Java Generics
pushed to the limit :) but my emphasis is more on generic iterators,
image addressability and n-D structuring elements. I will be curious
to compare the approaches.
I want to have a generic solution for n-D image manipulation.

If you are interested I can keep you informed.

best regards,

Dimiter

[Curtis Rueden]

Hi Dimiter,

I am writing something similar to the imglib. Again Java Generics
pushed to the limit :) but my emphasis is more on generic iterators,
image addressability and n-D structuring elements. I will be curious
to compare the approaches.
I want to have a generic solution for n-D image manipulation.

If you are interested I can keep you informed.

Sure, it sounds interesting. Perhaps we can spend some time going over it at the ImageJ Conference.

-Curtis