NOTICE! This is a static HTML version of a legacy ImageJ Trac ticket.

The ImageJ project now uses GitHub Issues for issue tracking.

Please file all new issues there.

Ticket #1023 (closed enhancement: fixed)

Opened 2012-02-27T16:47:09-06:00

Last modified 2012-06-21T12:20:38-05:00

Detect when sezpoz was not run properly (e.g. when compiled in Eclipse)

Reported by: dscho Owned by: dscho
Priority: major Milestone: imagej2-b3-headless
Component: Plugin Framework Version:
Severity: minor Keywords:
Cc: curtis Blocked By:
Blocking: #1207


If Eclipse messes up its configuration, or if it was not set as specified by bin/, sezpoz has no chance to list the classes annotated by sezpoz-aware annotations.

To reduce the surprises of non-core developers, let's be helpful and find a way to detect that situation and complain loudly.

Should it turn out to be too painful to force users to activate the annotation processing that Eclipse so blatantly neglects (it is part of the Java specification that these processors must be run), we might need to add some class file processing of our own. However, that would imply writing our own class file parser (probably based on the Updater's ByteCodeAnalyzer), as loading all the classes is both prohibitively slow and might even bust the memory limitation for class loading.

Change History

comment:1 Changed 2012-02-29T17:51:45-06:00 by dscho

  • Cc ctrueden@… added
  • Status changed from new to accepted

I have a hacky version of this in my branch 'delegation-tool' because I was sick and tired of Eclipse not realizing that it forgot to run the annotation processors.

But then I got an idea: rather than detecting whether sezpoz ran and trying to hack a way into IJ2 to find out whether sezpoz ran and is up-to-date, why not add our own annotation processor that simply writes the timestamp of the newest .class file into the MANIFEST.MF?

Since Eclipse generates MANIFEST.MF we can easily verify whether that timestamp is up-to-date for all the non-.jar elements in the classpath. If it is not, annotation processing was not run properly and we can complain loudly about it.

comment:2 Changed 2012-03-02T18:00:38-06:00 by dscho

The stuff moved to the 'eclipse-helper' branch in the Git repository.

comment:3 Changed 2012-04-17T09:57:27-05:00 by curtis

  • Cc curtis added; ctrueden@… removed

See also  Eclipse bug 280542 for details of the problem.

comment:4 Changed 2012-06-05T15:27:22-05:00 by curtis

  • Blocking 1207 added

comment:5 Changed 2012-06-05T15:30:06-05:00 by curtis

  • Milestone changed from imagej-2.0.0 to imagej-2.0.0-beta4

comment:6 Changed 2012-06-08T12:23:51-05:00 by dscho

I think we need to increase the priority of this, since it bit me several times during the last weeks...

comment:7 Changed 2012-06-14T21:03:33-05:00 by dscho

I think it is done: the current version of the 'eclipse-helper' branch seems to do the job for me.

comment:8 Changed 2012-06-21T12:19:08-05:00 by dscho

  • Status changed from accepted to closed
  • Resolution set to fixed

This branch was merged in 8fb7fb69ecafb56e39414c023419166386de8216. The only problem I see is that it adds tools.jar as a system dependency (but only if $java_home/../lib/tools.jar is found). This might be a little tricky in setups where java_home does not point to a JDK but instead a JRE. But let's cross that bridge only if we ever get there.

comment:9 Changed 2012-06-21T12:20:38-05:00 by curtis

  • Milestone changed from imagej-2.0.0-beta4 to imagej-2.0.0-beta3