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

Should OSGiRepo be able to use the name derived from the R5 index file #2464

Closed
rotty3000 opened this issue Jun 8, 2018 · 6 comments
Closed

Comments

@rotty3000
Copy link
Contributor

OSGiRepository only derives it's name from it's configuration.

Due to the mechanics of how standalone workspaces work, this leads to synthetic names being used which prove to be rather meaningless and possibly even lead to confusion.

I'm wondering if there's any use in, in the absence of a configured name, making the OSGiRepository able to lift the repository name out of the index file when only a single location is configured.

@bjhargrave
Copy link
Member

bjhargrave commented Jun 8, 2018 via email

@pkriens
Copy link
Member

pkriens commented Jun 8, 2018

Good point BJ.

And it would not be trivial. An OSGi repo can have multiple urls. So which name to pick?

This code works in stream mode parsing all the provided urls in parallel. So picking out the first or last name is not straightforward because the return is List.

@pkriens
Copy link
Member

pkriens commented Jun 8, 2018

it is also used as a cache directory name. Probably do not want to allow an external party to control file system access.

@bjhargrave
Copy link
Member

bjhargrave commented Jun 8, 2018 via email

@pkriens
Copy link
Member

pkriens commented Jun 8, 2018

We could sanitize but sounds like a lot of work for little worth

@rotty3000
Copy link
Contributor Author

@timothyjward if you are satisfied with the arguments against presented here I'm agreeable to drop this as well.

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