Task #10020 (closed)
Remove non-Pipes BF-ITK implementations
| Reported by: | mhiner-x | Owned by: | mhiner-x |
|---|---|---|---|
| Priority: | major | Milestone: | Unscheduled |
| Component: | Bio-Formats | Version: | n.a. |
| Keywords: | n.a. | Cc: | mlinkert, cxallan, crueden-x, jamoore |
| Resources: | n.a. | Referenced By: | n.a. |
| References: | n.a. | Remaining Time: | n.a. |
| Sprint: | n.a. |
Description
BF-ITK-Pipes is currently the recommended ITK plug-in for using Bio-Formats in ITK applications.
The Jace and JNI implementations are not fully functional and thus should no longer be supported. It is confusing for users to have multiple copies of these plug-ins. Further, ITKBridgeJNI is failing findbugs tests and must either be removed or fixed.
There is no reason to try to maintain these plug-ins when the Pipes implementation is working and supported. Thus the Jace and JNI implementations should be removed, and "native/bf-itk-pipes" should be moved to simply "native/bf-itk".
BF-ITK documentation will also need to be updated as appropriate.
Change History (5)
comment:1 Changed 11 years ago by mlinkert
- Cc jmoore added
comment:2 Changed 11 years ago by mhiner-x
Thanks for clarifying the justification on this ticket.
We decided that bf-itk-pipes should be (and has been) the sole actively supported BF-ITK implementation.
It's still valuable to eliminate potential confusion for users as to the presence of three plug-in options, and to avoid future maintenance of unsupported code, so the JNI and Jace implementations will still be removed.
comment:3 Changed 11 years ago by mhiner-x
comment:4 Changed 11 years ago by mhiner-x
- Resolution set to fixed
- Status changed from new to closed
Merged in develop, but not in 4.4 as the removal and movement of bf-itk implementations (and corresponding bridge class) constitutes an API change to Bio-Formats.
To be clear, the findbugs issues with ITKBridgeJNI are fixed here: https://github.com/openmicroscopy/bioformats/pull/286
The issue that Josh and I had was that all of the methods in that class are static, so at least from my perspective that's the only thing that would need to be fixed in the JNI implementation if it were to still be maintained.