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

Support jars.extra.classpath in the Manifest editory to avoid confusion with additional.bundles #1407

Open
laeubi opened this issue Sep 14, 2024 · 3 comments

Comments

@laeubi
Copy link
Contributor

laeubi commented Sep 14, 2024

Currently there is no UI support for jars.extra.classpath in the Manifest editor and du to its prominent placing people instead use often additional.bundles to add something that should be there for compile but not imported (what serves a different purpose) leading to confusion.

Even though jars.extra.classpath theoretically supports different styles, we should only support the form where one can specify a single bundle platform:/plugin/<Bundle-SymbolicName> as this is also supported by Tycho and easy to adapt by other tools.

@merks
Copy link
Contributor

merks commented Sep 14, 2024

This is a good idea.

I'm not suggesting one needs to make things more complicated so this is just an FYI...

The scheme generally supports

platform:/plugins/<bsn>_<version>/

as parsed by org.eclipse.core.internal.boot.PlatformURLConnection.parse(String).

@laeubi
Copy link
Contributor Author

laeubi commented Sep 14, 2024

The scheme generally supports

Officially also relative path is supported as well as inner jars:

extra classpaths used to perform automated build. Classpath can either be relative paths, or platform urls referring to plug-ins and fragments of your development environment (e.g. ../someplugin/xyz.jar, platform:/plugins/org.apache.ant/ant.jar). Platform urls are recommended over relative paths;

I just think that if one really requires a version or relative path one can do it manually, but e.g additional bundles do only support a BSN and people seem happy with that already (but using it for a different purpose).

@merks
Copy link
Contributor

merks commented Sep 14, 2024

I 100% agree to keep this simple for the common case!

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

2 participants