added a comment - - edited
The situation I have, simplified, looks like this:
ear-project DEPENDS ON
jar-project DEPENDS ON
ejb-project-1-client DEPENDS ON
In the ear project, jars are supposed to go into APP-INF/lib. I use <defaultLibBundleDir>, and it works for most things, but not ejb-client dependencues. Apparently, the maven-ear-plugin takes any dependency specified with a classifier of ejb-client, and puts it into the root ot the ear, unless you tell it to do otherwise, for a specific artifact. This behavior contrasts with the usual jar-packaging behavior, in that defaultLibBundleDir permits specifying a default location for jars in general.
As James Olsen says, specifying the jar-project's dependency as client instead of ejb-client evades the maven-ear-plugin's classification of the dependency as an ejb client, and therefore permits it to be packaged where defaultLibBundleDir says it should. That's all very fine for the jar-project DEPENDS ON ejb-project-1 case above. But what about the transitive dependency in my example above. ejb-project1-client DEPENDS-ON ejb-project-2-client? I may or may not control that dependency, and to the extent that I do not, what are my options?
If the only option at that point is to explicitly list all of the ejb-client artifacts on which I transitively depend, in the pom of every ear I build from jars that depend on clients with such transitive dependencies, then I suggest that this issue may be of greater import than its present classification of "Minor/Improvement." Forcing projects to violate the hiding of transitive Maven dependencies seems reasonably serious.
Also, I've had a look in the maven-ear-plugin code, and it seems very easy to fix, at least if you agree with me about the right way to address it. Given that there's a defaultLibBundleDir for specifying the default location of jar files, and given that someone seems to have found a reason for putting ejb client jars somewhere else regardless of this setting, why not add a defaultEjbClientBundleDir parameter? It looks to me as though the code change would be nearly trivial. There's even already a parameter for passing on a default packaging location, in constructing the object representing the ejb-client. It's just that it's always set to null at present.