https://maven.apache.org/guides/mini/guide-naming-convention...
These problems simply wouldn't exist.
Java and .NET have a couple of good ideas even if they aren't fashionable any longer.
For extra bonus points, the Java directory structure being built around it is just silly, related code ends up far away in the directory tree, just because you went through a rebranding or a merger.
Seems to be working for multiple decades without issues ?. If an organization is acquired (like Sun), they still have access to their namespace. It doesn't magically go away.
> For extra bonus points, the Java directory structure being built around it is just silly, related code ends up far away in the directory tree..
This is just your opinion. Many people like this systematic nature of directory hierarchy for segregation. Also, you do not require to follow this source language convention in case you don't like it. It is only required that the compiled class be in a nested directory structure for class-loader pickup
Ie You can still you put custom_src/foo/MyClass.java with package com.bingo.tringo;, it’ll still compile, and Maven will output: target/classes/com/bingo/tringo/MyClass.class
I noted a pretty damn big issue that invalidates the whole idea that the domain is a stable identifier. It's a big problem in practice, even if you're happy with keeping the old domains you may want to transfer code to someone else without giving them your domain. The solution is apparently to pretend that the problem doesn't exist. Which may be fine for Java but shouldn't be a trap that other languages need to repeat.
Something like
- maintainers of package com.foo.pkg want to transfer it to com.bar.pgk
- com.bar creates their own pgk clone and marks it as a successor to com.foo.pkg (with a specific version)
- com.foo.pkg pushes an update with that specific version marked as superseded by com.bar.pgk
- package managers warn users at update time that a change in namespace happened and ask for consent
This could be extended to multiple forks to let the user choose
I feel it would work fine
> The solution is apparently to pretend that the problem doesn't exist.
No, the problem really doesn't exist.
somecrate = { git = "https://...." }
other-crate = { version = "1.0", registry = "my-registry" }
https://doc.rust-lang.org/cargo/reference/source-replacement...
crates.io could be updated to support alternative registries.
There are advantages to systems like this such as trust (I can tell that you.example/pkg1 and you.example/pkg2 are owned by the same person) and decentralization. But I don't think it helps with the later packages having ugly names.
It would be confusing and counterproductive to introduce, say multimedia_libs/ffmpeg because codec_libs/ffmpeg was discontinued.
A level of hierarchy does when projects in genuinely unrelated categories share a package name.
It's just like giving external users self-modifing code access - asm, lisp, js - let's they upload it and we execute ;)
#DONOTSENDCODE Manifesto, where ?
Wouldn't reusing the name of a package that is no longer maintained create chaos for programs that use the discontinued package.
Maybe it's not simply one-sided gatekeeping from the former managers of the package?
It doesn't matter what you call it, and what the files are called; two COM objects could both be FFMPEG.DLL or whatever (obviously not installed in the same directory).
When it comes to packages, users interact with the names and are used to writing names into their code when they specify dependencies, so it's not a complete no-brainer solution; but maybe some idea from that solution space could be worked into a package management system.
stmw•4mo ago