Closed axle-h closed 6 years ago
You're right axle, I should have done that. I was relatively new to software development when I began writing this and didn't realize the consequences of not having a unique prefix. I also don't do Scala development so I wasn't aware that would be an issue.
My thinking now is it would be best to make the change with the next release instead of waiting, since it's going to have to happen eventually. I was hesitant to change things when I first realized this could be a problem since I didn't want to force people to update every single import. But comparing that to the issue you just mentioned, it sounds like it needs to be done.
The only prefix I can think of is "com.github.jrachiele" since I don't currently own my own domain. Not a big fan of that, but if you've got any better ideas let me know.
I was looking at https://github.com/haifengl/smile and he simply prefaces his packages, like math, with the word smile. I'm wondering if just naming it "timeseries.math" or "java.timeseries.math" would be a good way to go. Feedback welcome.
I wouldn't bother too much about the domain ownership stuff for package names. That's meant for the maven groupId. I wouldn't go with "java.timeseries" as you'd be implying your package be part of the JDK. I also wouldn't go with just "timeseries" as you'd expect some applications that consume your library to have their own timeseries package somewhere, causing issues with scope for the parent package. I reckon your best options are "com.github.jrachiele", "org.timeseries" or "org.jrachiele.timeseries". E.g. of the random org prefix is joda-time, whose packages are org.joda.time.*.
Thanks for the advice axle. I'll probably go with "com.github.jrachiele" since it has the least element of surprise.
I ended up changing my github username to signaflo, and have prepended all packages with com.github.signaflo.
It's very common for scala developers to use the
scala.math
package without the scala prefix as it's imported by default. Naming your package math conflicts with this such that simply adding java-timeseries as a dependency will break the build. Maybe you should have prefixed it with your own vendor prefix to avoid these conflicts?