Project Architecture

[omzmarlon]

Setup Project Architecture and dependencies.

[tomyang729]

Double check all the libraryDeps are compatible with each other. ie). Play Slick currently supports Slick 3.1 with Play 2.5, for Scala 2.11. So Slick 3.2 won't work

[omzmarlon]

So we have to use 3.1?

[omzmarlon]

@tomyang729 what do you think?

[tomyang729]

It looks good to me. And yes, I think we have to use Slick 3.1 (not sure why the Play docs uses 2.0.0 as example https://www.playframework.com/documentation/2.5.x/PlaySlick)

But I'll change the slick dependency to 3.1

[omzmarlon]

The documentation seems to be not sync-ed in many places.. Oh and I have made master to be a protected branch, so any push must branch out, pull request, review, before merging to master

[tomyang729]

Maybe we can re-structure our folder structure: *play/ managementapp/ profile/ *quiz/ core/ **common/ (there must be a better name) profile/ quiz/

In this way, we can simplify the build.sbt (since right now there are lot of duplication, play ones and core ones are the same respectively) And we only need two modules -- play and core Does that work? I'm not too sure

[omzmarlon]

The idea of separating each core, play into a single folder is that each of them is a single decoupled module that can be used or discarded. With above approach, we are bundling everything about play into one giant module. There's indeed a lot of duplicate code in build.sbt. we just need to refactor out some common settings like the commonBuildSetting one

[omzmarlon]

@tomyang729 I re-thought about this issue. I think it is perfectly ok if want to put all these separations into one module(play, or whatever we call it), but we need to at least separate these quiz/profile core/play dirs in such a way that library/framework/or any other dependencies can be separated. Otherwise we would have disadvantage: 1.everything inside the big module depends on all included libraries(accessing code that should not be accessed, hard to manage, creates unnecessary dependencies), 2.everything share the same settings(really bad, different package may need different settings), 3. Each different modules may want to use different db access tools, machine learning tools, or any other libs/frameworks In general I think it is good practice to at least let each dir manage its own dependencies and settings and what it wants to use in its packages, instead of let everything to be decided by its containing module

[omzmarlon]

Basic structure has been set-up by separating play and core