BAR libs: Use new SciJava Common discovery mechanism

[tferr]

Thanks to @ctrueden, the script_templates strategy (that we're already using) can now be generalized to any path. @m-entrup tested the new discovery mechanism and everything seems to work well, so we should ditch the legacy way of directory mirroring, in favor of the new mechanism, as noted by @imagejan.

I really want to implement this, but unfortunately, I may not have time to work on this immediately, so any PRs are welcomed!

[tferr]

I just tested it and it this feature is really nice actually. The only thing is that once distributed placed in jar, the updater is no longer aware of individual script files.
Or am I missing something?

I will probably adopt the new discovery mechanism because of uploading single files is much more cumbersome, but I always thought it was an advantage for users to sub-select what they want to receive from individual update-sites, but perhaps such granularity is out of the scope of the updater?
@imagejan, @m-entrup perhaps you guys have some thoughts on this?

[ctrueden]

The fundamental unit of currency in the Updater is the file. If you want to have a per-script granularity, then you should upload your scripts bare. However, then you do lose the advantage of versioned JAR files. I guess you could wrap each script in its own JAR file, although that seems like overkill to me.

Note that I recently did some work (when prompted by @imagejan) to make shift+click on a JARified script still open it properly in the Script Editor. I did cut new releases of the relevant components, but they have not yet been uploaded to users.

[tferr]

Note that I recently did some work (when prompted by @imagejan) to make shift+click on a JARified script still open it properly in the Script Editor

Yes, that was the only thing stopping me from adopting jar files. Opened this issue asa I noticed your post in the forum.

Done for Data_Analysis scripts. Will JARify other directories ASA I find more time (there are several URLs that need to be updated, both in the markdown and mediawiki page).

[m-entrup]

I think distributing JAR files with the update is superior to distributing single files. When the complexity of a single script grows, splitting it into several files is the best approach to keep it neat. Additionally parts of a multi file script can be easily reused.
Currently I'm looking for a simple way to automatically create a documentation from my Jython scripts doc strings. Adding such docs to the JAR file and make it accessible from ImageJ would be a great benefit.

[ctrueden]

Currently I'm looking for a simple way to automatically create a documentation from my Jython scripts doc strings. Adding such docs to the JAR file and make it accessible from ImageJ would be a great benefit.

@m-entrup Nice idea; how about filing an issue in scijava-common for that? If you could give some specific example of your desired syntax, and what you would want to be automatically produced, that would also be helpful.

[m-entrup]

I found epydoc that creates a nice API documentation just by parsing the doc strings. It can create HTML and PDF output.

From inside ImageJ it could be best to use the __doc__ property of a function. Here is an example that I tried in the script editor:

from EFTEMj_pyLib import Tools as tools
print tools.batch_open_images.__doc__ 

The result is:

Open all files in the given folder.
    :param path: The path from were to open the images. String and java.io.File are allowed.
    :param file_type: Only accept files with the given extension (default: None).
    :param name_filter: Only accept files that contain the given string (default: None).
    :param recursive: Process directories recursively (default: False).

Thanks to StackOverflow I even found a way to list the doc strings of all functions contained in a module:

from EFTEMj_pyLib import Tools as tools

def get_funcs(module):
    import types
    return [module.__dict__.get(a) for a in dir(module)
                if isinstance(module.__dict__.get(a), types.FunctionType)
               ]

for func in get_funcs(tools):
    print func.__name__
    print func.__doc__

(The source code of the module: Tools.py)

I will soon fill an issue for that. But first I have to play around with it a bit further.