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

New mvn scheme to replace lib scheme. #1916

Open
jurgenvinju opened this issue Feb 8, 2024 · 16 comments · May be fixed by #1969
Open

New mvn scheme to replace lib scheme. #1916

jurgenvinju opened this issue Feb 8, 2024 · 16 comments · May be fixed by #1969

Comments

@jurgenvinju
Copy link
Member

jurgenvinju commented Feb 8, 2024

The current plan is to slowly move away from the lib:// scheme with the following idea:

  • RASCAL.MF will only name the library dependencies by string name, not by URI
  • Or/And: Require-Libraries will dissappear completely as feature
  • Replaced by the dependencies of pom.xml
  • And a new library scheme will unambiguously define the location of a mvn jar like so: mvn://package-id/project-id#VERSION-CONSTRAINT
  • The project configuration code that produces pathConfig instances will create the mvn URIs.
  • The mvn URI resolver will look in the .m2 cache and otherwise try to use mvn to download the artefacts, or otherwise throw IO exceptions.
  • Even though mvn URIs are also not universal (dependent on the repositories configuration in the local pom.xml), at least they are precise and they are deterministic. As long as projects do not move between different repo's they are reasonable.

That's the plan.

Originally posted by @jurgenvinju in usethesource/rascal-language-servers#110 (comment)

@jurgenvinju
Copy link
Member Author

@DavyLandman
Copy link
Member

Can we merge this with this discssion? #1886

@jurgenvinju
Copy link
Member Author

merged here. We can start by implementing mvn:/// with an eye for efficiency. This is going to be an often-used scheme.

@DavyLandman
Copy link
Member

I like the idea of this. my only addition is, maybe not use the fragment for the version?

@jurgenvinju
Copy link
Member Author

pip uses the @ sign for versions: pip install -U git+https://github.com/AdaCore/[email protected] Which is also sweet. But @ is not reserved as a separator in URI's like # is.

@jurgenvinju
Copy link
Member Author

image

That's the way it's done in the mvn community when they want to use URIs for packages

@DavyLandman
Copy link
Member

DavyLandman commented Feb 9, 2024

image

That's the way it's done in the mvn community when they want to use URIs for packages

whats the source? I don't think that maven plugin you mentioned reflects the maven community.

@DavyLandman
Copy link
Member

DavyLandman commented Feb 9, 2024

For example, gradle uses <groupId>:<artifactId>:<version> (like: io.micronaut.test:micronaut-test-spock:1.1.3)

so does maven itself as well: if you run mvn dependency:tree for example:

[INFO] --- dependency:3.6.0:tree (default-cli) @ nescio-core ---
[INFO] engineering.swat:nescio-core:jar:1.1.0-SNAPSHOT
[INFO] +- org.rascalmpl:rascal:jar:0.33.7:compile
[INFO] +- org.rascalmpl:rascal-lsp:jar:2.18.0:compile
[INFO] +- org.rascalmpl:typepal:jar:0.8.9:compile
[INFO] \- junit:junit:jar:4.13.1:test
[INFO]    \- org.hamcrest:hamcrest-core:jar:1.3:test

So that would mean either it's mvn://org.rascalmpl:typepal:0.8.9/ or it's mvn:///org.rascalmpl/typepal/0.8.9/ ?

@jurgenvinju
Copy link
Member Author

jurgenvinju commented Feb 9, 2024

yes I saw that too, but printing is not enough. We have to be sure it also parses unambiguously. This depends on the restrictions we have on group id's and artifact id's, and that intersected with the constraints on authorities in URIs. If we are lucky we do not need any encodings; the group/artifact id's are then fully contained in the authority character class, and we have characters left outside of that intersection in authorities that we can use as separators.

Source material:

I think that mvn://org.rascalmpl:typepal:0.8.9/ that you proposed is allowed according to that documentation!

@jurgenvinju
Copy link
Member Author

Definitely, I'd like the root of a file system to be encoded in the authority/host field of the URI. The files inside of the jar can go in the path then. Otherwise, the file system metaphor breaks inside Rascal (we don't know what a root is anymore).

@jurgenvinju
Copy link
Member Author

I'd also like to propose we do not support any shorthands, so no:

  • |mvn://project-id:version/
  • |mvn://group-id:project-id|
    etc.

The mvn scheme should unambiguously declare which package to use and which version, leading to an unambiguously identified jar file in the local repository.

@DavyLandman
Copy link
Member

DavyLandman commented Feb 9, 2024

yes I saw that too, but printing is not enough. We have to be sure it also parses unambiguously.

For gradle their syntax is not printing, it's how you describe dependencies.

This depends on the restrictions we have on group id's and artifact id's, and that intersected with the constraints on authorities in URIs. If we are lucky we do not need any encodings; the group/artifact id's are then fully contained in the authority character class, and we have characters left outside of that intersection in authorities that we can use as separators.

I think the biggest problem is that : in authority has a special meaning. It's either for seperating user & password before the @ sign or specifiying the port. (see https://datatracker.ietf.org/doc/html/rfc3986#section-3.2 ) so for example: http://user:[email protected]:8080/

Definitely, I'd like the root of a file system to be encoded in the authority/host field of the URI. The files inside of the jar can go in the path then. Otherwise, the file system metaphor breaks inside Rascal (we don't know what a root is anymore).

Agreed, I prefer that as well.

The mvn scheme should unambiguously declare which package to use and which version, leading to an unambiguously identified jar file in the local repository.

Agree.

@jurgenvinju
Copy link
Member Author

jurgenvinju commented Feb 9, 2024

section-2.3 says we only have these characters if we want to stay out of accidental other interpretations: unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"

And mvn says this: These identifiers should be comprised of lowercase letters, digits, and hyphens only

So the intersection is: [a-z0-9\-] and we have [\.\_~] as possible separators between project id, group id and version.

@jurgenvinju
Copy link
Member Author

What the URI standard does not say is that authorities in VScode will be normalized to lowercase characters anyway.

@DavyLandman
Copy link
Member

DavyLandman commented Feb 9, 2024

but . are already used in maven ids, so we only have _ and ~ as possible separator chars?

@jurgenvinju
Copy link
Member Author

theoretically yes. so it seems we should use the path component / anyway? mvn:///group/project/version/root or ``mvn://group/project/version/root`?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants