-
Notifications
You must be signed in to change notification settings - Fork 52
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
[Enhancement] ternModuleInstalls to support folders within a plug-in JAR #332
Comments
@demonfiddler I'm very busy, do you think it's possible to do a PR with your idea? Thanks! |
@angelozerr I'll ask my boss whether we could do this as a contribution to the project. Cheers :-) |
@angelozerr I have the necessary changes finalised, just awaiting legal approval before I can submit a PR. |
Great! |
demonfiddler
added a commit
to demonfiddler/tern.java
that referenced
this issue
Nov 3, 2015
Pull request #361 submitted. |
Resubmitted Pull Request (#365) |
angelozerr
added a commit
that referenced
this issue
Nov 10, 2015
[Enhancement][REDO] ternModuleInstalls to support folders within a plug-in JAR per Issue #332
demonfiddler
added a commit
to demonfiddler/tern.java
that referenced
this issue
Nov 12, 2015
…ample to contribute a plug-in folder rather than a ZIP file.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The tern.eclipse.ide.core.ternModuleInstalls extension point has a plugin.xml#/plugin/extension[@point='tern.eclipse.ide.core.ternModuleInstalls']/moduleInstall@src attribute which currently provides the plug-in-relative path to a ZIP file containing the Tern module(s) to be deployed to the Tern repository. The plug-in is expected to be installed as a directory rather than a JAR.
It would be more elegant, convenient and OSGI compliant if the src path could alternatively be the path, relative to the plug-in root, of a folder containing the modules for deployment. It is rather more work for a developer to create a plug-in that contains a ZIP of some of its content rather than simply containing that content directly in the deployed plug-in directory or JAR. This approach would also enable the plug-in to be installed as a JAR, which is much preferable.
Implementation note: you can use org.osgi.framework.Bundle.getEntryPaths(String path) : Enumeration and getEntry(String path) : URL to read the structure and entries from the src path within the plug-in, and this approach would work regardless of whether the bundle is deployed as a directory or an archive. If this enhancement were to be implemented I can't imagine anyone using the ZIP format, so you could drop it and simplify the code somewhat.
The text was updated successfully, but these errors were encountered: