Clean up name delegation in the plugin. A few rules:

[jsuereth]

• Each configuration should have its own name and normalizedName instance
• Debian/Rpm delegate to Linux which delegates to project name.
• Universal has its own name, which is used for generating BASH/BAT files
• Separate key for the package filename now
• Windows has its own name/normalized name which delegates to raw.

Fixes #188

[jsuereth]

Review by @muuki88 cc> @timperrett

[muuki88]

so if I specify name in RPM := "xyz" it will still work?

[jsuereth]

it should. It will get normalized, which is something we may want to rethink soon.

[muuki88]

Hmmm. I'm thinking about introducing a new Setting packageName. By default this is the normalizedName, but you can override it. So setting packageName would by pass all name and normalizedName tasks, which IMHO seem to cause all this troubles.

Then we can just use packageName everywhere without a scope, right? If I run debian:* packageName will automatically be resolved in the debian scope.

[kardapoltsev]

Excuse me that was a stupid mistake on buttons).

[jsuereth]

@muuki88 Yeah, I think that's a far better idea.

What we should do perhaps:

name in <Scope> - A name used when creating the file for a package
packageName - The name we use for the script/directory/etc. of an archetype (like the JavaArchetype.

Sound reasonable?

[kardapoltsev]

Sure!)

[timperrett]

+1 for packageName, that would be vastly simpler

[muuki88]

I merged the current master into this pr. What has to be done here?

[fiadliel]

Project.normalizeModuleID only exists in SBT 0.13. Possibly use StringUtilities.normalize instead (it's deprecated, but present in SBT 0.12)?

[muuki88]

What are you referring to?

I went through the discussion and will start to implement the packageName setting soon.

[pcting]

@jsuereth, so this is my use case: #296

What are your thoughts on adding additional keys such as logPath and applicationPath and have their values defaulted to packageName? This will allow the log directory and application install directory to be different.

What I don't like about this is that there's already a defaultLinuxLogsLocation and a defaultLinuxInstallLocation, which may cause a lot of user confusion.

[muuki88]

@pcting , once we detangled everything from the normalizedName key, it should be easier to add configuration settings like this. Thanks for your feedback :)

[jsuereth]

@muuki88 your changes LGTM!!

[muuki88]

So, this should be it. I'm currently working on a documentation, which will also be the starting point for the next configuration refactorings. @jsuereth , @aparkinson , @kardapoltsev I added a lot of tests, but nothing guaranteed .

[muuki88]

One last thing @jsuereth . Is this binary compatible? Can it be merged in the 0.7.x branch?

[jsuereth]

@muuki88 Yeah, as long as it's just new keys and modifying existing Setting[_] objects, it's BC. Method changes, or removal of keys is how you break BC. The sbt Setting[] + Key[] setup leads us a bit more resiliency to bin-compat, but glad you asked.