-
Notifications
You must be signed in to change notification settings - Fork 7
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
Use OSGi bundles #750
Comments
I think it will be quite easy to migrate as well. We can ship plugins with both their existing meta-data and the OSGi meta-data and load them either way. |
Using OSGi and proper services for plugins would mean we could upgrade to Dagger 2 as well (as we can stop abusing it for plugins) |
csmith
added a commit
to csmith/DMDirc
that referenced
this issue
Jan 2, 2017
This won't affect normal use of the client, other than it having a few extra unused classes and some additional lines in the manifest. Issue DMDirc#750
csmith
added a commit
to csmith/DMDirc-Util
that referenced
this issue
Jan 2, 2017
csmith
added a commit
to csmith/DMDirc
that referenced
this issue
Jan 3, 2017
csmith
added a commit
to csmith/DMDirc
that referenced
this issue
Jan 4, 2017
csmith
added a commit
to csmith/DMDirc
that referenced
this issue
Jan 7, 2017
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I think we should look at switching DMDirc to use an OSGi framework for both the client itself and for plugins.
The OSGi framework could replace a lot of stuff we do ourselves, such as:
It would also support some new features:
As well as all that, it allows us to split the client up more into separate components without being a pain in the ass, stop bundling all of our dependencies explicitly in a giant jar, share libraries between plugins, etc.
The text was updated successfully, but these errors were encountered: