search

imglib / imglib2-ij

Translation between ImgLib & ImageJ data structures (both 1.x and 2)
Other
4 stars 8 forks source link

Prepare imglib2-ij for modularization #37

Open tpietzsch opened 10 months ago

tpietzsch commented 10 months ago
acardona commented 10 months ago

Changing the package name will break all existing documentation and tutorials online. Is this necessary?

On Fri, 5 Jan 2024, 16:23 Tobias Pietzsch, @.***> wrote:

We'll start by fixing imglib2-ij.

  • Set net.imglib2.ij.
  • Move all classes under the net.imglib2.ij package.

To update dependant projects, we need tooling to

  • Find and fix import statements that reference imglib2-ij classes.
  • Find and fix fully qualified uses of imglib2-ij classes.
  • Create PRs to the dependant projects.

Find and fix import statements that reference imglib2-ij classes.

  • Clone all relevant candidate repos.
  • List types (and interfaces, and enums) of imglib2-ij.

— Reply to this email directly, view it on GitHub https://github.com/imglib/imglib2-ij/issues/37, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMKGTNUJCGDSRTMJSPTATYNASJNAVCNFSM6AAAAABBOU6OBSVHI2DSMVQWIX3LMV43ASLTON2WKOZSGA3DONRUGM2TGNQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

tpietzsch commented 10 months ago

Yes, it is necessary. JPMS requires that there are no split packages between artefacts. (The same is true for OSGi. If I remember correctly, KNIME image processing for example had to work around this by having their own version of imglib2-ij.)

Breaking documentation and examples is a very good point. I did not think of that. We should also have scripts to update these. However its more difficult to gather all relevant repositories. (For code, we can at least harvest everything managed by pom-scijava.) Feel free to start putting inks in the comments of this issue!

acardona commented 10 months ago

Will also brake all user scripts. Most aren't under version control. Might want to make this a breaking change with a separate Fiji version, leaving the old untouched and not receiving more updates, to avoid chaos and confusion.

On Sun, 7 Jan 2024, 21:47 Tobias Pietzsch, @.***> wrote:

Yes, it is necessary. JPMS requires that there are no split packages between artefacts. (The same is true for OSGi. If I remember correctly, KNIME image processing for example had to work around this by having their own version of imglib2-ij.)

Breaking documentation and examples is a very good point. I did not think of that. We should also have scripts to update these. However its more difficult to gather all relevant repositories. (For code, we can at least harvest everything managed by pom-scijava.) Feel free to start putting inks in the comments of this issue!

— Reply to this email directly, view it on GitHub https://github.com/imglib/imglib2-ij/issues/37#issuecomment-1880186280, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMKGVF3SLY4NFJIRHPTC3YNMJYRAVCNFSM6AAAAABBOU6OBSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOBQGE4DMMRYGA . You are receiving this because you commented.Message ID: @.***>

tpietzsch commented 10 months ago

Another good point.

Maybe another solution might be to have a new artefact (imglib2-ij2 or similar) with the new package name and also leave the old imglib2-ij.jar with deprecated classes. This would keep existing scripts working, and postpone the separate Fiji version until all of Fiji wants to run modularized. I would still want to move as much code and documentation as possible to the new package name. What do you think about that?

I would be also very interested in @ctrueden thoughts on this.