Thank you a lot for your time. Your really illuminated my brain. My mistake was to try to make the EAR module of my project in such a way that other artifacts can depend on it. But that is no the purpose of EAR modules. So, there is no risk to append, after the dependencies intended to add content to the EAR, some dependencies to artifacts that are already dependencies of the before dependencies just to override its scope to 'provided'. The maven-ear-plugin takes advantage of the maven dependency management, but uses it for a very different purpose: to make an archive and not an artifact to which other artifacts can depend upon. So the maven terms has a different meaning in POMs intended to be an artifact to which others can depend upon than in POMs intended to build assemblies.
Nevertheless, there is something that makes noise in my brain. It would be better if the two kinds of dependencies; the ones intended to add content to the EAR, let's call them 'content' dependencies, and the ones intended to override the scope of the dependencies of the 'content' dependencies; would be clearly distinguishable by means of the maven language instead of comments. I think that the source of this trouble is the low cohesion of the <scope> element. It tries to specify two aspects of an artifact with a single value. Two aspects that should be independent of each other and that should be determined in different circumstances. - The first aspect is the classification of the dependency as required during runtime only or during compilation also. This aspect depends only and exclusively on the source code of the artifact for which we are specifying the dependencies. It does not depend in any way on the deployment. - And the second aspect tells the packager plugin if it has to add the dependency to the archive or not. This aspect has nothing to do with the source code, but only with the deployment. The creator of the artifact should not necessarily know the way his artifact and their dependencies will be deployed, and therefore, this aspect should not be specified by him, but by responsible of the deployment trough some kind of descriptor. In our case, the EAR module POM.
