[TYPO3-team-core-v5] Reverted change to TYPO3.DocTools

[Karsten Dambekalns]

Hi.

On 15.05.2012, at 20:46, Christopher Hlubek wrote:
> the Flow3Org distribution using always master on any package is the problem.

Depends. First of all it's a problem that no one really takes the CI tests serious, it seems.

> I don't like the constant submodule pointer updates. For me it's impossible to have a running Phoenix instance for the latest distribution commits (I tried really hard yesterday). We should only update submodule pointer if functional tests / unit tests still run.

Unit tests did run, it was a mistake to not run the functional tests as well. I have a better concept for the build pipeline on my list anyway.

> Besides that we could use a separate package for the job queue feature in DocTools, but it brings me back to the question how to deal with optional dependencies (which is totally valid for me).

Right, a separate package (like TYPO3.DocTools.RenderQueue or whatever fits best) would be the way to go. Optional dependencies (in the sense of "suggested packages" will be in 1.2 anyway. What needs a lot more thought (and maybe cannot be solved at all) is a way to avoid something like that error without splitting into more packages.

The problem was that FLOW3 reflects all classes, and a class implementing an interface requires that interface to exist. The only ways around that would be a safeguard around the class definition (ugly as hell!) or some way to tell FLOW3 not to reflect that class in that file because it will break (complex and bound to break!?).

That being said, we need to find a way to support such dependencies - if only it is a best practice.

Regards,
Karsten
-- 
Karsten Dambekalns
TYPO3 Core Developer, FLOW3 / Phoenix Team

TYPO3 .... inspiring people to share!
Get involved: typo3.org