Ticket #1023 (closed enhancement: fixed)

Opened 8 years ago

Last modified 8 years ago

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/eclipse-clue-bat.sh, 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 8 years ago 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 8 years ago by dscho

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

comment:3 Changed 8 years ago by curtis

  • Cc curtis added; ctrueden@… removed

See also  Eclipse bug 280542 for details of the problem.

comment:4 Changed 8 years ago by curtis

  • Blocking 1207 added

comment:5 Changed 8 years ago by curtis

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

comment:6 Changed 8 years ago 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 8 years ago 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 8 years ago 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 8 years ago by curtis

  • Milestone changed from imagej-2.0.0-beta4 to imagej-2.0.0-beta3
Note: See TracTickets for help on using tickets.