erikhofer
commented
7 years ago The library approach would be more convenient. For the server this would be no problem at all. For the client it would be possible as well with npm link.
However, if we base the client on angular-seed-advanced it is not trivial to (1) make the client an npm library module and (2) make another client that consumes this library and is based on angular-seed-advanced as well. Also, their has to be a runnable non-customized client. Would it build directly from the client project (that can also produce a library) or do we need another sub-project that consumes the library but adds nothing other than a build script for a runnable client?
Forking on the other hand is trivial to set up but less convenient to develop with. Changes to the upstream have to be commited and can then be pulled locally. You cannot pull uncommitted changes (there is an approach but it seems cheesy).
Another advantage of forking is that arbitrary changes can be introduced by the costomization easily. For the server this is not an issue because Spring is already very flexible. In the client we can use depency injection to replace e.g. service implementations and other things in the code (that have to be desinged to support this beforehand). But if it comes to other things, especially resource files (this includes templates) it becomes non-trivial. Some things might even be impossible without build-time source processing.
This appliaction is not intended to be used in production directly. It is an abstract multi-purpose codebase that can be customized. To build a real community, it is (probably) necessary to narrow down the "topic" of products (i.e. tools or gluten-free). Also, the client should be able to be tailored to this topic, eg. custom color scheme, additional content and to the maintainer of the application, eg. legal texts like privacy policy.
Because of this, it must be able to build a custom application based on this open-source project.
Options:
Considerations: