I propose to deprecate ContainerAwareCommand, that would IMO be a great step in order to fully avoid ContainerAware stuff in final applications as well as in the core.

Motivation:

• This class is part of the FrameworkBundle, it can live without it
• Injecting the container is weird, as of 3.3 we have all in hands to avoid doing so
• Same reasons that make a class better when it has explicit dependencies: it's clear what a command provides and what it doesn't, just by looking at its dependencies
• Extending ContainerAwareCommand is almost a convention when writing commands in the full-stack framework and most often there's no strong reason behind it (or not at all): commands can just be services and explicitly declare their dependencies as any other
• Yet creating a container aware command is an easy way to get a working command with no configuration since the container is auto injected, that is especially useful for newcomers. But what about a AutowiredCommandInterface which would be automatically registered as an autowired service instead?

Steps would be:

• Change FrameworkBundle commands to make them services
• Find a good replacement to get command with dependencies without config (autowiring) for newcomers and RAD
• Deprecate the class

What do you think? I'd be glad to do it.