Prepare java-wasm artifact for release

[headius]

Additional tweaks to get a deployable Maven artifact for the java-wasm artifact.

I'll mark this as non-draft when I'm satisfied the artifact is ready to get pushed to Maven Central.

This PR makes the following changes:

• Set up deployment to org.ruby-lang Maven namespace
• Switch all Java packages from org.prism and org.jruby to org.ruby_lang.
• Update JRuby dependencies based on JRuby 10.1

[headius]

I've threaded the needle and gotten snapshots deployed for this all the way into the wasm_prism branch of JRuby, which integrates it all and adds a CI job to test it.

jruby/jruby#9184

Coordinating the release of non-snapshot artifacts will take some additional work. Assuming TruffleRuby is not planning on using this (it depends on JRuby maven artifacts currently) I will proceed to do clean-up from here.

This PR is focused more on getting Prism available to use as JRuby's internal parser. Later work will handle packaging a separate build of the prism/wasm stuff for the gem.

[headius]

I believe I've made the final changes needed to get this artifact published for JRuby internal parser use.

• The library will be published to Maven Central as "org.ruby-lang:prism-parser" for now, as it does not separate the WASM backend from the native backend. A future release will depend upon subcomponents "prism-parser-api", "prism-parser-native" and "prism-parser-wasm", so the impact to consumers will be minimal.
• The library is JRuby-specific, as described in Eliminate templated STRING_TYPE and use a factory #4009. We'll discuss how to eliminate that JRuby dependency for a future release.
• The runtime dependency on JRuby is specified as "provided" in the Maven descriptor, which means it is used for compilation but expected to be provided by the host environment (e.g. when loaded into JRuby itself).

There's a few open questions that I need some guidance on:

• CI testing? I can at least set up a job to at least run the base test cases for the WASM artifact, but they're fairly minimal. Once we have JRuby 100% passing on the Prism parser (we lagged behind a bit), I could set up a more comprehensive test.
• Versioning/releasing? Currently the version is still 0.0.1-SNAPSHOT. It would be nice to be able to version and release this library independently of Prism, so neither directly depends on the the other to be released at the same time, but I'm not sure what that version string should look like nor what the process should be.

Barring those questions, I could publish our first official Java API for Prism any time.

[headius]

I don't see how my changes could cause the failures here:

CRuby bindings / test-all (parse.y)
CRuby bindings / test-all (prism)
Main / gem-install (truffleruby, ubuntu-latest, ..)

[eregon]

Barring those questions, I could publish our first official Java API for Prism any time.

Since there is AFAIK no demand for that, I think it would be better to wait.
For example the resolution of #3962 and #4009 might depend on the actual requirements, e.g. whether the users would want all fields or only semantics fields, etc.
That's a lot of complexity which seems unwise to add now without a known use case.

Regarding the usage in JRuby, it seems clear for now there needs to be 2 instances of libprism (as WASM or native), one which only serializes semantic fields and is used as the JRuby parser, and one to implement the Ruby API of Prism (though see #3962 (comment)). The second one has no use of Loader.java.
The Loader.java API has always been designed with the 2 main users in mind, as a parser for TruffleRuby and JRuby, it is not meant as a general Java API for Prism. Maybe it could be evolved as such, but without a convincing use case and known users I don't think it's worth the effort and complexity.

As such I think this would be better published under org.jruby than org.ruby_lang.

[eregon]

As such I think this would be better published under org.jruby than org.ruby_lang.

One more reason for that is the Java API so far did not need to bother about compatibility, preferring to keep the code clean and simple. If it's published under org.jruby I don't see it as a problem, but under org.ruby_lang it might create the wrong impression that that Java API is stable, when it for sure isn't (i.e. it will have incompatible changes if e.g. the proposal from #4009 is implemented).

[headius]

See #4009 for reasons why this will remain under org.ruby-lang namespace and an alternative approach to eliminating the templated string type.

[headius]

Since there is AFAIK no demand for that, I think it would be better to wait.

JRuby needs this and it makes no sense to publish an API that is 99% ruby-lang.org code under org.jruby. As a counterexample, publishing under org.jruby would indicate that the JRuby team is the primary group responsible for Prism issues. That's clearly not the case.

The artifact should be published under org.ruby-lang.

If it makes you feel better, we can publish as a 0.x release to indicate that it is still in pre-release territory. But as I mentioned in #4009 and our chat, I want this to become a useful API for other JVM consumers of Ruby's source code. There's really no alternative for anyone building JVM-based tooling that wants to keep up with the latest language changes.

Regarding the usage in JRuby, it seems clear for now there needs to be 2 instances of libprism

I believe that was already settled and I accepted that there would need to be two different builds, one for the internal use of JRuby and one for the gem API.

without a convincing use case and known users

I believe the ability to write up-to-date Ruby tooling using the JVM is a pretty convincing use case. It's hard to have known users without a published artifact.

And if it's going to be identical regardless of which namespace it goes under, I think it should go under the namespace that represents the bulk of the code we're shipping.

[eregon]

Alright. Re versioning, see #4009 (comment).