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

Migrate the core logic of the Updater to the UpdateService #3

Open
ctrueden opened this Issue Apr 30, 2014 · 2 comments

Comments

Projects
None yet
1 participant
@ctrueden
Copy link
Member

ctrueden commented Apr 30, 2014

In line with the rest of our architecture, the update functionality should be exposed as API methods of the UpdateService.

@ctrueden

This comment has been minimized.

Copy link
Member Author

ctrueden commented Apr 30, 2014

@ctrueden

This comment has been minimized.

Copy link
Member Author

ctrueden commented May 1, 2014

To be clear: I am in favor of exposing the updater functionality as UpdateService API, but we probably want it to be possible to use the UpdateService without spinning up a full SciJava context. We have found that in practice, context creation becomes rather finicky when there are a lot of services involved (each with the potential of getting hosed up in various ways). So at minimum: the UpdateService should minimize its service dependencies so you can spin up a very minimal context for working with it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.