cakesolutions / play-scala-template.g8 Goto Github PK

There are some useful tests contained in the Jenkinsfile, https://github.com/cakesolutions/play-scala-template.g8/blob/master/Jenkinsfile#L11 .

I think it would be useful to extract this out somehow (maybe a set of bash scripts), allowing a developer to easily verify the template locally.

there is an hard coded akkarepo string at

buildInfoPackage := "net.cakesolutions.akkarepo.build",

https://github.com/cakesolutions/play-scala-template.g8/blob/master/src/main/g8/project/ProjectPlugin.scala#L25

A set of default compiler options, and whether they fail the build or not, has to be decided upon. We also have to decide whether a linter is relevant.

• docker repo config
• labelling

How should we version our dependencies? Below is an interesting comment on an old PR from @Baccata its probably a good place to start

@carlpulley
I'd suggest that we place all versioning into a separate file. The sort of thing I've tended to do is as follows:

object Dependencies {
object akka {
private val version = "..."
val core = ... % version
}
val scalaCheck = ...
}
For single dependencies, what value do you see in separating version from the library dependency?

@Baccata

"I'd suggest that we place all versioning into a separate file."

I personally don't like indicating dependencies in another file. The reason for this is that I found myself time and again browsing through github to read build information, and then having to jump to another file to get the artifacts names and versions. I find having them in a clear separated version of the build.sbt to be better, as they are one of the key information to understand the code.

"For single dependencies, what value do you see in separating version from the library dependency?"

I just think it looks better like this after aligning the %. I'm not too fussed about it in all frankness, much less so than about listing artifacts in a separate file.

What catalyst does is expressing deps in two maps, one for artifacts orgs and names, one for versions.

@carlpulley
Thanks, I'll look at catalyst and pick your brains on Thursday!

I'm of a slightly different opinion here. I like to separate concerns - especially on larger projects where the build.sbt files can grow significantly and end up being in danger of adopting a dumping ground adjective.

I agree that versioning needs to be in one place, but I also want to reduce copy and paste errors with package and organisation names. Hence why I tend to favour abstracting the whole library dependency into one place.

@carlpulley
I've been thinking about your reasons for preferring one file with library dependencies. Surely, a tool such as IntelliJ (or similar) would have alleviated your browsing woes that you discuss above?

@Baccata
It is partly true. The problem arised from the last project I was on where the size of the team and the large number of separate codebases was making it impossible to review all PRs.

However, we would often find ourselves having to review random PRs on those codebases, and opening the "Dependencies.scala" file to understand where some features were coming from was often required, even when we weren't actively working on the related codebase and therefore had not necessarily checked it out.

Also, the separation of "Dependencies" into a separate file led us to think that we could factor those in a plugin, and the realisation of the pain induced by doing that came a bit later.

That being said, I acknowledge that this was a very particular project, and my preference for having the dependencies in the same file is personal in the same way some people will decide that the socks should go to the left drawer rather than the right drawer. What I'm trying to say is that the arguments around this decision are more subjective than the ones around other questions.

Surely, a tool such as IntelliJ (or similar) would have alleviated your browsing woes that you discuss above?
Now there's an interesting point. I'm reluctant to force anyone to use an IDE. I'm using it at work because I'm horribly reliant on the mouse, but some people are extremely productive with vim or emacs, and should be allowed to use those. Combining these with Ensime helps navigating the program, but not the build itself.

@jkpl
Surely, a tool such as IntelliJ (or similar) would have alleviated your browsing woes that you discuss above?
For some reason, I can't get IntelliJ to recognise custom Scala code used with SBT. I've seen other developers have the same problem.

@carlpulley 👍

@jkpl
On a side note, SBT is deprecating Build.scala support. I think they'll still support project/*.scala files to some extent, but it seems they're phasing towards pure *.sbt defined builds.

https://groups.google.com/forum/#!topic/sbt-dev/S-pr2nZQ3KY

@Baccata
Not really, looking at Eugene Yokota's comment, it looks like they're trying to reduce the number of ways "projects" can be defined.

• MDC logging
• Changeable log level without redeploy

• Create giter8 SBT Play Template
• Initial Cut of Play 2.5 outline
• some simple plugins added

Carl suggests that all resolves should be placed in .sbtopts and sbt.repositories file combinations.

Add in sbt launched End-to-End tests with docker compose environment.

• Gatling
• Docker Compose
• Health Checking
• Gatling tests as a Docker image

How should we mark and version releases,

• Which branching model
• What Plugins
• Labels / tags etc

• Swagger
  or
• Something better

Looking at line

I would have thought that we would probably default to an all rights reserved license, allowing any project maintainer to easily amend to a more permissive license. (IANAL), but I would imagine that once a piece of source code is issued with a permissive license, then that license would be applied forever (it's not possible to remove the permissions granted by that license).

I'm all for open software, but it should be a conscious choice by the owner/maintainer of the software in question.