New package name and new group id

[dwijnand]

Following the decision in "Should the Scala Platform modules use the Scala namespace?" this library needs to switch away from being defined in the scala package.

It would be preferable, to avoid jar hell, if it also at the same time switched to a new groupId (organization in sbt nomenclature). One that you and future maintainers of this library would have authority to use when making releases to Sonatype's Maven Central.

[mdedetrich]

@dwijnand So to be clear, the decision is that there is basically no restrictions on namespace, just that it can't be scala?

[dwijnand]

Yeah, it can't be scala or a package nested in scala.

[mdedetrich]

@dwijnand Regarding the organisation, I can change it to something else (although I would have to go through the hassle of getting another domain name to register the group Id for sonatype), but I was under the impression we would get permissions to publish artifacts to some official repo, or am I wrong?

[dwijnand]

I'm not the authority you seek, as I'm not in charge or even on the SPP committee.

But from my understanding the official repository for SPP modules would be Maven Central.

An alternative you might want to consider to a newly authorised groupId is to use another artifactId. So you would continue to publish under "org.mdedetrich", but not as "scala-json-ast".

[mdedetrich]

@dwijnand I will wait for @jvican then, don't want to spend time changing stuff around if its going to change again

[jvican]

@mdedetrich For the group id, we'll use the official Scala Platform group id though you can opt-in to use yours. Regarding package names, yeah, I think it's reasonable that Scala Platform modules don't use the scala namespace. To avoid major issues in the future, I think it would make sense to create independent namespaces. I'll comment on that Discourse thread soon, I forgot to do so two weeks ago.

You can continue to use scala-json-ast as artifact id as you want, the only constrain is that the namespace is not scala.

[mdedetrich]

@jvican Can you give an update on the scala platform group id?

[jvican]

Hello Matthew, thanks for the ping!

@mdedetrich I've been reworking the sbt-platform plugin completely for several reasons, particularly to make it easier for authors to use and to expose some of its functionality to the Scala community via sbt-release-early. Currently, I'm waiting on this https://github.com/sbt/sbt-bintray/pull/102 to be merged and a new version of sbt-bintray to be released.

As soon as this is out, I would happily create a PR adding sbt-platform support to this module. Sorry for the delay.

Regarding the release, we cannot have a stable release until this library is finishes the incubation period and it's finally added to the Scala Platform. I will call on a Scala Platform meeting soon to decide on this and the future ofbetter-files.

All the Scala platform modules will have their own namespace. Currently, I see you have package scala.json.ast. As we agreed on https://contributors.scala-lang.org/t/should-the-scala-platform-modules-use-the-scala-namespace-or-a-common-namespace/422, the Scala modules will not use the Scala namespace nor a Platform-specific one, so you're free to choose whichever you want. An idea: scalajson.ast.

The Scala Platform group id used to publish will be org.scala-lang.platform, since it's the domain we own for all the Scala Platform docs.

[mdedetrich]

@jvican Cool thanks for the update, just wanted to see what was happening and if I wasn't blocking anything

[eed3si9n]

What's the status on this issue?

[mdedetrich]

@eed3si9n I can finalize the package name (will probably be json.ast) however I can't standardize the group id yet because the sbt-platform hasn't been released yet by @jvican. I can spend time this week to change the package name, so the only possible upgrade in the future would be the group id change (this however assumes it passes the incubation period without any changes in the actual code)

[SethTisue]

a group id change later is not especially problematic, I think, since downstream, only builds are affected not code, and it's easy enough to also change a group id when changing a version number thanks commenters below for setting me straight

[mdedetrich]

@SethTisue Yup, I can do the group id change without problems. The only issue is that I can't completely guarantee that the library won't change before the final release, since its still in incubation period (I just suspect its highly unlikely that it will change)

[dwijnand]

I'd advise against json.ast as a package name as I suspect it'll clash easily with people defining val json values of JSON ASTs, requiring them to always refer to this library as _root_.json.ast.

@SethTisue If sbt 1.0.0 ships with one groupId and then this library changes groupId but not package name, then plugins using the new groupId will trigger jar hell. That's why I advise to change both at the same time.

[ktoso]

As someone who has pondered such package / groupId name changes many times I have to agree with @dwijnand that changing them independently does cause room for jar hell for users of libraries.

If for any reason at all the final artifact (changed groupId) would have slightly changed things, it will lead to class cast issues in user code - the story under which this happens is this: since dependency resolvers don't know the "new groupId" is actually "the same thing" it would not evict, or remove that artifact. So library that depended on old-id pulls in the old thing (package + class name "known.Known"), and then the user pulls in new library, that uses the new artifact groupId. The dependency resolver does not know it is a "actually new version of that old-id", so both libraries are included. The new lib however contains the same "known.Known" class which may have changes in it - causing class cast issues in runtime. It is impossible for library maintainers to fix this, and users would have to be aware of this and resolve this manually.

With the above scenario in mind, I advice doing the package + groupId change at the same time. What is blocking making that decision at the same time, and unblocking sbt while we're at it?

[mdedetrich]

@dwijnand What would you recommend as a package name then?

@ktoso

What is blocking making that decision at the same time, and unblocking sbt while we're at it?

The scala center (I think @jvican ) needs to release an sbt-release plugin which is what would publish my package under the official group id. I will try and message/email @jvican

[dwijnand]

scalajsonast, or perhaps some artistic contraction of that.. scajast..

It's your library, you get to pick to call it whatever you want. You could also try some name generators.

[farmdawgnation]

scajast has a nice ring to it

[mdedetrich]

Closed in favour of #14 (where you can vote for the name of the library as well as the root package)