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

Dependencies on other update sites #89

Open
StephanPreibisch opened this issue Jul 23, 2020 · 3 comments
Open

Dependencies on other update sites #89

StephanPreibisch opened this issue Jul 23, 2020 · 3 comments
Milestone

Comments

@StephanPreibisch
Copy link
Member

Hi, it would be awesome if an update site could define another update site it depends on. In this specific case I have all the N5 libraries on the BigStitcher update site. Instead, I would love that when someones clicks the BigStitcher update site, the N5 update site is selected by default. Would this be possible somehow?

Thanks so much,
Stephan

@ctrueden
Copy link
Member

ctrueden commented Jul 23, 2020

General answer replicated from this post:

There is no formal support for dependencies across update sites. That is, there is no way to enforce an update site needing another update site to be enabled as well. (The only “solution” I know of is: code on the OpenSPIM update site has a horrible hack to force-enable the Micro-Manager update site… but this hack causes problems and I would not recommend replicating it.)

At the moment, your options are either: A) tell users they must enable the upstream update site also in order to use your update site; or B) upload the common third party dependencies to your update site as well, doing your best to ensure they are of the same/compatible versions as those on the upstream update site; or C) tell users they cannot have both update sites enabled at the same time, if the versions are not actually compatible.

If you choose route (B), the pom-scijava BOM is here to help you.

As for the future of Update Sites: some discussion happened on this thread. And we can certainly discuss further. My current thinking is that we should move away from update sites toward plugin-based granularity of installation, like how Icy does it. And that plugins should be published on maven.scijava.org (or Central), and the new slimmer Updater should just know which Maven coordinates correspond to installable ImageJ plugins.

In the meantime, specifically about N5: let's just ship them with Fiji, no? There should be no problems doing that, as long as @axtimwalde is OK with it. We're already testing them as part of the melting pot, so I don't foresee any conflicts.

@axtimwalde
Copy link
Member

I am ok with that, which is why I added them to pom-scijava. But I couldn't wait for it :). Fiji would have to ship with imagej-updater-0.10.5, so I can use the opportunity to move the licenses to an appropriate place.

@ctrueden
Copy link
Member

ctrueden commented Aug 2, 2020

@axtimwalde In case you didn't already notice: the big Fiji update has now happened. It now ships imagej-updater 0.10.5 as well as the N5 libraries.

@ctrueden ctrueden added this to the maven milestone Oct 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants