Component split about zend-cache HOT 16 OPEN

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.

from zend-cache.

👍 It's the logical continuation of the hard work done by @weierophinney.

from zend-cache.

@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

from zend-cache.

@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

from zend-cache.

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...

from zend-cache.

@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?

from zend-cache.

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?

from zend-cache.

@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

from zend-cache.

@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.

from zend-cache.

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?

from zend-cache.

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

Thanks for review 😃

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.

from zend-cache.

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.

from zend-cache.

@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.

from zend-cache.

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?

from zend-cache.

@boesing We can when we bump to PHP 7.1.

from zend-cache.

This repository has been closed and moved to laminas/laminas-cache; a new issue has been opened at laminas/laminas-cache#7.

from zend-cache.