Skip to content

Commit

Permalink
Moved files to a named package
Browse files Browse the repository at this point in the history
  • Loading branch information
Richard Domander committed Nov 25, 2015
1 parent c772a10 commit 6289c5b
Show file tree
Hide file tree
Showing 6 changed files with 14 additions and 0 deletions.
4 changes: 4 additions & 0 deletions .gitignore
View file
Expand Up @@ -3,5 +3,9 @@
/.project
/.settings/

# IntelliJ #
/.idea/
*.iml

# Maven #
/target/
2 changes: 2 additions & 0 deletions src/main/java/Clean_Up_Local_Thickness.java → ...alThickness/Clean_Up_Local_Thickness.java
View file
@@ -1,3 +1,5 @@
package net.imagej.localThickness;

import ij.IJ;
import ij.ImagePlus;
import ij.ImageStack;
Expand Down
2 changes: 2 additions & 0 deletions src/main/java/Distance_Ridge.java → ...imagej/localThickness/Distance_Ridge.java
View file
@@ -1,3 +1,5 @@
package net.imagej.localThickness;

import ij.IJ;
import ij.ImagePlus;
import ij.ImageStack;
Expand Down
2 changes: 2 additions & 0 deletions src/main/java/EDT_S1D.java → ...va/net/imagej/localThickness/EDT_S1D.java
View file
@@ -1,3 +1,5 @@
package net.imagej.localThickness;

import ij.IJ;
import ij.ImagePlus;
import ij.ImageStack;
Expand Down
2 changes: 2 additions & 0 deletions src/main/java/Local_Thickness_Driver.java → ...ocalThickness/Local_Thickness_Driver.java
View file
@@ -1,3 +1,5 @@
package net.imagej.localThickness;

import ij.IJ;
import ij.ImagePlus;
import ij.Prefs;
Expand Down
2 changes: 2 additions & 0 deletions src/main/java/Local_Thickness_Parallel.java → ...alThickness/Local_Thickness_Parallel.java
View file
@@ -1,3 +1,5 @@
package net.imagej.localThickness;

import ij.IJ;
import ij.ImagePlus;
import ij.ImageStack;
Expand Down

6 comments on commit 6289c5b

@rimadoma
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Moved the classes to a named packaged because since Java 1.4 classes in the default package can not be accessed from the outside
  • I'm proposing a naming convention for plugin packages here: net.imagej.

@ctrueden
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to choose a different package name than net.imagej.localThickness. The net.imagej package is for core ImageJ2 code. This is an ImageJ1 plugin.

We should settle on a common package prefix that makes sense for all plugins. The subpackage localThickness is just fine beneath that. For Fiji we have used sc.fiji in modern times—some older stuff has older conventions in need of update. Since LocalThickness currently lives in the fiji org, I vote for sc.fiji for the prefix here.

However, it does raise a larger question: what about plugins which we want to belong to multiple different distributions of ImageJ?

My suggestion right now would be for BoneJ to be an update site on top of ImageJ—and maybe even on top of Fiji. In which case, there is no disagreement: LocalThickness is part of the Fiji layer. And BoneJ-specific plugins not present in Fiji can use org.bonej for their package prefix and live in the bonej-org GitHub org.

What do you think @rimadoma @mdoube ?

@mdoube
Copy link
Member

@mdoube mdoube commented on 6289c5b Nov 26, 2015 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ctrueden
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main thing for BoneJ is that if someone has vanilla ImageJ2 and adds only the BoneJ update site, all the dependencies, no matter what their namespace, are pulled in.

To accomplish that, you'll have to upload all of BoneJ's components to the BoneJ update site directly. In other words: there will then be duplicate(ish) stuff on the Fiji and BoneJ update sites. This is necessary because there is currently no mechanism for update sites to declare dependency on other update sites.

How important is it to you that BoneJ be usable independent from Fiji? I.e., that it not be "built on top of Fiji"?

If the answer is "very important" then we might want to create some shared org for "stuff built on top of ImageJ2 that is not core ImageJ2 but is common to multiple distributions of ImageJ" (in this case BoneJ and Fiji). And then it can have its own package prefix etc.

Thoughts?

@mdoube
Copy link
Member

@mdoube mdoube commented on 6289c5b Dec 4, 2015 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ctrueden
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an important discussion, which I would like to move to the forum. I will reply there in a new thread.

Please sign in to comment.