New Yawik Project Structure Discussion

[kilip]

@cbleek report:

I'm using apache, which cannot write into var/log. So the first thing I've done was chown -R www-data var

The next thing is the connection to the DB. If no yawik.config.global.php exists, the install module should be executed. I get the error:

[2018-10-24 19-51-26] Zend\ServiceManager\Exception\ServiceNotCreatedException: Service with name "Core/DocumentManager" could not be created. Reason: No suitable servers found (serverSelectionTryOnce set): [connection refused calling ismaster on 'localhost:27017'] #13053 in /home/cbleek/Projects/YAWIK-NEU/vendor/zendframework/zend-servicemanager/src/ServiceManager.php:771 caused by MongoDB\Driver\Exception\ConnectionTimeoutException: No suitable servers found (serverSelectionTryOnce set): [connection refused calling ismaster on 'localhost:27017'] #13053 in /home/cbleek/Projects/YAWIK-NEU/vendor/mongodb/mongodb/src/Collection.php:906 @ http://new.cb2.yawik.org/favicon.ico @@ exception--2018-10-24--19-50--23496f4885.html

should we test in parallel, or do you think it's too soon?

[kilip]

@cbleek this error raised when there are no valid connection exists. I have fix this error in this commit

composer update yawik/* command in your fresh yawik dir should fix this issue.

[kilip]

@cbleek since this project is not stable yet, in order to test I suggest you to git clone this project.

[kilip]

@TiSiE

When we're at it, we should split all modules into separate repositories and abandon the current YAWIK repository. But that can also be done later on....

I think we should keep the current repository, it would be easier for us if we want to working with the 2 module or more in the same time. For example we can detect error's or bugs when we change or add something in the Core module which have effect in another module, and fix this error directly. We can found this case in your your latest commit:

Another reason is issue tracking. It would be easier for user just to use our current issue tracking without having to decide in which module they should report an issue.

All modules should be installed in the modules folder via the composer-installer component. And installing a module must then call the "assets:install" and clear the config cache and so on...

Agree!

zend-framework/console is not deprecated, only zend-framework/zf-mvc-console is. As I am not very familiar with symfony (except for the doctrine mongo odm) I prefer zfcampus/zf-console. Integrating this in a zend framework application is also very convenient...

Agree!

[cbleek]

A central location for issues is important. And Travis tests, which include all modules, are too. So let's implement Toni's suggestion.

[TiSiE]

it would be easier for us if we want to working with the 2 module or more in the same time. For example we can detect error's or bugs when we change or add something in the Core module
which have effect in another module, and fix this error directly.

It's just the same when working with multiple repositories. In the development environment, all modules will be checked out on the develop branch anyway. Instead of making multiple commits per module in one repository, it's just making one commit in each module repository.

Also, when keeping our big repository, what's all the fuzz about splitting it up in the first place?

And for the compatibility issue: Each module repository will have its own stable version. And in its composer.json, it will require the stable versions of the other modules it needs to function properly. That means, if a feature in the Jobs module requires a change in the Core module, the release of the next stable Jobs module version must wait until the required change is released in the core module. It's not as convenient as now, when we can run a Yawik instance on the develop branch, but will make the overall end user experience better in the long run.

Another reason is issue tracking. It would be easier for user just to use our current issue tracking without having to decide in which module they should report an issue.

We will have a yawik/yawik (or yawik/skeleton) repository, which can be used for that. It will mean more work for us to relate the issues to the right repository, but with githubs internal linking system it should not be that big deal.

And Travis tests, which include all modules, are too.

With separate modules we will not need a travis test for the whole thing. Because all modules rely on the stable versions of the other modules, which are tested on their own. That's the main concept of UNIT testing anyway. But when a whole test is still wanted, we can set a travis test up for the yawik/yawik repository.