Component split

[marc-mabe]

I would like to get your opinions about splitting zend-cache into different components. The reason for that is simply a testing and dependency hell.

• It's not possible to define a required extension in composer.json so all adapters have to manually check if the current environment is matching the requirements
• Testing against all adapters is a nightmare and takes very long.
  • The travis.yml file al already very complex but it still doesn't test all common cases.
  • Some extensions are missing or not 100% compatible for PHP-7 which makes things here more complicated.
  • Doesn't test against different (most common) extension versions
  • Nearly impossible to run tests for ZendServer adapters
• another reason is that normally you only need 1 or 2 adapters but that's not very important as zend-cache doesn't install so many files per adapter.

In my opinion it makes sense to split parts into it's own repository as long as the part requires a non standard extension or another currently optional dependency.

Thoughts ?

This is a structure how this could look like:

zendframework/zend-cache

• Exceptions
• Patterns
• Service
• Factories
• Storage Interfaces
• Storage Plugins
  • all except the Serializer plugin
• Storage Adapters
  • BlackHole
  • Filesystem
  • Memory

    zendframework/zend-cache-serializer

• adds the serializer storage plugin which requires zend-serializer

  zendframework/zend-cache-apc

• adds the Apc storage adapter requires the apc extension (or compatible extension)

  zendframework/zend-cache-apcu

• adds the Apcu storage adapter requires the apcu extension

  zendframework/zend-cache-dba

• adds the Dba storage adapter requires the dba extension

  zendframework/zend-cache-memcache

• adds the Memcache storage adapter requires the memcache extension

  zendframework/zend-cache-memcached

• adds the Memcached storage adapter requires the memcached extension

  zendframework/zend-cache-mongo

• adds the Mongo storage adapter requires the mongo extension
• It's currently the MongoDb adapter but there is also another extension called mongodb

  zendframework/zend-cache-redis

• adds the Redis storage adapter requires the redis extension

  zendframework/zend-cache-session

• adds the Session storage adapter requires the zend-session

  zendframework/zend-cache-wincache

• adds the WinCache storage adapter requires the wincache extension

  zendframework/zend-cache-xcache

• adds the XCache storage adapter requires the xcache extension

  zendframework/zend-cache-zendserver

• adds the ZendDataCacheDisk and ZendDataCacheShm storage adapter requires the zend data cache extension
• This is currently called ZendServerDisk / ZendServerShm because the extension is part of Zend Server

[weierophinney]

This makes a ton of sense as far as I'm concerned; it's exactly what we're doing in zend-mvc currently.

I'd recommend:

• Start creating the new packages. IIRC, you have the ability to create repos, @marc-mabe, so you can either create them directly here, or create them first under your username, and then move them to this organization. When each has a stable tag, ping me so I can add them to packagist.
• On the develop branch of this repo, as we add the new packages to packagist, remove the adapter and related files via a pull request, and add the new package as a suggestion.

With regards to the AdapterPluginManager, the new components should be made compatible with zend-component-installer. In doing so, you can have the Module class return configuration for the adapter plugin being exposed. (You should likely also do a ConfigProvider so folks can use it with Expressive!) I can provide more guidance on this aspect as needed.

[neeckeloo]

:+1: It's the logical continuation of the hard work done by @weierophinney.

[marc-mabe]

@weierophinney sorry for the late response. Nice to hear your ACK.

There are some details I like to discuss before:

• Should we introduce a test repo zend-cache-test which includes common tests like https://github.com/zendframework/zend-cache/blob/master/test/Storage/Adapter/CommonAdapterTest.php that can be re-used by all other sub-components?
• If I understand correctly the component installer is used to install ZF components within ZF applications but using zend-cache as a component in another context this approach doesn't work.
  • Instead it should be possible for sub-components to inject itself into the *PluginManager by using composer autoload -> files. This way a sub-component would be available out-of-the-box just by adding it by composer.
• I have a lot of open PRs ready which I would like to merge before but reviewing takes ages. I don't think it would be a good idea to merge my own stuff but currently my speed of operation goes down a lot just for waiting for someone else that is able to review my own stuff and pinging and pinging again.

Cheers

[marc-mabe]

@weierophinney @Ocramius Today I had some time and moved already a lot of repos from zend-cache into it's own. Could you please take a look if that's on a good way? Thanks!

• https://github.com/marc-mabe/zend-cache
• https://github.com/marc-mabe/zend-cache-test (Reusable testing utilities / common test classes ...)
• https://github.com/marc-mabe/zend-cache-serializer
• https://github.com/marc-mabe/zend-cache-apc
• https://github.com/marc-mabe/zend-cache-apcu
• https://github.com/marc-mabe/zend-cache-memcache
• https://github.com/marc-mabe/zend-cache-memcached
• https://github.com/marc-mabe/zend-cache-dba
• https://github.com/marc-mabe/zend-cache-xcache

Cheers

[Ocramius]

Sorry, I didn't join the discussion before.

Yes, this looks good, especially if we can manage to make the extension dependencies required when picking single packages (that would require requesting the single packages via composer, manually).

Unsure if the serializer needs to be extracted: probably worth keeping test, cache and serializer in a single package, while the adapters move each to a single component if they require particular extensions.

I'm also not sure if it's worth splitting out cache components that don't require extensions...

[marc-mabe]

@Ocramius Thanks for your comment!

I have moved the serializer plugin into another package as it requires the zend-serializer package. Same (will) happen to the session adapter which requires zend-session.

I'm also not sure if it's worth splitting out cache components that don't require extensions...

It's all about splitting out the parts require special dependencies. I have one exception only, the zend-cache-test package. This package contains some reusable / common tests and will be used by all other zend-cache* packages in development. The reason for that is that I want to have this dependency only for development require-dev and not on normal installations.

The following packages also needs to be moved:

• the redis storage adapter
• the mongodb storage adapter
  • Also I like to rename this to just mongo storage adapter as it's using ext-mongo and not ext-mongodb
• The session storage adapter

Everything else should be kept in the main repo as it doesn't have special dependencies.

Right now I have one problem that I don't know how to solve: The component contains a factory StorageFactory used to instantiate storage adapters and plugins like

StorageFactory::factory([
    'adapter' => [
        'name'    => 'apc',
        'options' => ['ttl' => 3600],
    ],
    'plugins' => [
        'exception_handler' => ['throw_exceptions' => false],
    ],
]);

But how can I register the services on installation using the zend-component-installer?

[Ocramius]

I have moved the serializer plugin into another package as it requires the zend-serializer package. Same (will) happen to the session adapter which requires zend-session.

Makes sense

Yes that's basically all about. I have one exception only, the zend-cache-test package. This package contains some reusable / common tests and will be used by all other zend-cache* packages in development. The reason for that is that I want to have this dependency only for development require-dev and not on normal installations.

Can't we just use the .gitattributes, as we already did thus far?

[marc-mabe]

@Ocramius There are actually the following problems:

• These test files are located in tests/ and so will not be auto-loadable by composer as it's defined in autoload-dev.
• If I move them into src/ and add to .gitattributes
  • Files are not available on downloading compressed package (Or am I wrong?)
  • We get test files in src/ not usable as part of package as it depends on PHPUnit but this is defined in require-dev

[marc-mabe]

@Ocramius Also moved the zend-server adapters to an own repo and after several hours I could make the tests run on travis by installing Zend-Server, rewriting phpunit start script and testing over HTTP call :)

@weierophinney Please could you take a look at https://github.com/marc-mabe/zend-cache-zendserver/blob/master/.travis.yml and validate if that is ok and allowed how I run the tests.

Thanks.

[weierophinney]

I love the idea of separating out the various storage adapters to their own repositories. That way users are only getting code related to the adapter(s) they use, and we can have much easier, more targeted instructions on contributing (typically via vagrant and/or docker).

I've looked at the zend-cache-zendserver Travis setup, and it looks reasonable.

Would this split target a v3 release, then? And I assume we'd want each adapter brought into the zendframework organization, and tagged with a stable 1.0.0 release before removing them here, correct?

[marc-mabe]

I've looked at the zend-cache-zendserver Travis setup, and it looks reasonable.

Thanks for review :smiley:

Would this split target a v3 release, then?

Yea, also I have one or two other things I want to archive for 3.0 because small BC break.

And I assume we'd want each adapter brought into the zendframework organization, and tagged with a stable 1.0.0 release before removing them here, correct?

Yes, of course before tagging a stable version of zend-cache with adapters removed the adapters have to have a stable version already and everything has to be in zendframework organization. I was planning to start with adapter versions with version 3.0 as the adapters had stable versions before within zend-cache.

[marc-mabe]

Does anyone have an idea or knows someone how would be able to test the WinCache adapter. I don't have a windows system at hand and even if so I would not like to fight setting up a microsoft webserver an windows in my free time.

[weierophinney]

@marc-mabe The only thing I can think of is to use a Windows vagrant image as a base, and then have the Vagrantfile download and install PHP to it. IIRC, Travis has windows images, too, which might make this possible there.

[boesing]

As the support for APC dropped years ago and there is no compatible PHP 7+ version, shouldn't we drop support for that extension at all?

[weierophinney]

@boesing We can when we bump to PHP 7.1.

[weierophinney]

This repository has been closed and moved to laminas/laminas-cache; a new issue has been opened at https://github.com/laminas/laminas-cache/issues/7.