Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update sites' jars should be semver compatible with Fiji/ImageJ #30

Open
hinerm opened this issue Jun 19, 2014 · 2 comments
Open

Update sites' jars should be semver compatible with Fiji/ImageJ #30

hinerm opened this issue Jun 19, 2014 · 2 comments

Comments

@hinerm
Copy link
Member

hinerm commented Jun 19, 2014

We should enforce that dependencies included in update sites do not shadow libraries from the Fiji or ImageJ update sites if they are not semver compatible.

For example, SCIFIO depended on an old version of pom-scijava which was pulling in an old scijava-common. So even though the SCIFIO jar itself was fine in Fiji, on the SCIFIO-dev update site the scijava-common artifact was being overridden, creating a state where Fiji could not even launch.

@ctrueden
Copy link
Member

More generally, we probably want to prevent any update site with shadowed JARs from overwriting ImageJ (and eventually Fiji) core JAR files, if the shadowed versions are older.

For example, the LLTT update site is currently broken because it ships outdated snapshots of ImgLib2. Even if we had a rule preventing upload of currently-out-of-date dependencies, they might still become out of date later, when we release, deploy and upload newer versions of those libraries to the core ImageJ & Fiji update sites, leaving the update site in question in the dust. Anyone who enables that update site after that point would be in for an unpleasant experience.

@ctrueden
Copy link
Member

The other possibility that @dscho and I discussed F2F is enforcing these rules not for core ImageJ and Fiji specifically, but rather for any libraries matching the SemVer versioning convention. But it gets tricky.

I guess one question is: how do we want to manage update sites which depend on other update sites? Because that's what this issue really comes down to...

@dscho dscho removed their assignment Nov 9, 2014
@ctrueden ctrueden reopened this Oct 11, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants