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

Bump versions for Scala, Akka and Scalatest. #65

Open
wants to merge 28 commits into
base: master
Choose a base branch
from

Conversation

davidmweber
Copy link

This brings the packages up to current versions.

@davidmweber
Copy link
Author

Akka 2.4.1 does not support Scala 2.10. Do you still want to support this Scala version?

@chrisdinn
Copy link
Owner

@damienlevin @gramk

What do you guys think?

@damienlevin
Copy link
Collaborator

I really like the cleanups but I'm not a fan of the package change, what's the motivation ?
I'm ok to drop 2.10 on master but we should create a 2.10 branch and document it in the README.

@davidmweber
Copy link
Author

My package names were somewhat arbitrary (digital-achiever as a "-" so it is a no-go). My primary motivation was to lay things out more conventionally (files in a directory that has the same hierarchy as the package) and with a package name that is OK for Maven. Also, sbt's publishLocal wants the package to match the actual organisation specified in the sbt file.

So really not fussy about the actual name :). Let me know what works for you and I will refactor.

@chrisdinn
Copy link
Owner

Those package names (and matching directory tree) are Java-isms not required in Scala. Unless this has changed lately in some official way, I'd prefer not to use a fully-qualified package name.

I'm not sure about the impact on publishLocal, but I've never had any problem building/publishing Scala libs this way.

The rest of the cleanup looks good to me. If you want a quick merge you can separate these issues and we can discuss package naming in another PR.

@davidmweber
Copy link
Author

I have had some issues with package names not matching organisation in Ivy. sbt publishLocal puts the package in a directory that matches the organisation but the compiler looks for the jar in the heirarchy of the package... I think it is prudent to just pick a package name/heirarchy that matches the organisation and does not offend anyone unduly. The change will take me 5 mins

@chrisdinn
Copy link
Owner

Are you certain you've correctly identified the source of your problem? If you are correct, libs like Akka also have this problem. I'm assuming they either don't experience it, mitigate it somehow (we could do the same here) or don't deem the limitation worth changing package names for. Is the approach in this library any more offensive?

In Akka's case, the organization is "com.typesafe.akka" but the package names are short and sweet (ie. akka.actor).

@davidmweber
Copy link
Author

Brain fart here.... Do you want the package to be just brando? And are you happy to put it in a separate directory?

@Tolsi
Copy link

Tolsi commented Oct 8, 2016

so?

@chrisdinn
Copy link
Owner

Hey, do you think you can fix the Travis failure?

@aszmyd aszmyd deleted the branch chrisdinn:master April 22, 2021 12:40
@aszmyd aszmyd deleted the master branch April 22, 2021 12:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants