Another thing to add to the agenda which we need to discuss is
dependency scopes. In particular, we need to review our previous
decision to make the implementation component of a module
runtime-scoped, in light of the fact that we now no longer have
combined jars.
Isn't the idea of having an API and implementation split is that you should not be compiling against anything in the implementation? Of course, an end user can choose to override that convention to make the implementation a compile-time scope, but we don't want to encourage that, do we?
I'll add to that that I really, really don't think that having a single dependency declaration is a holy grail. We have gone to great lengths to have an API for Seam 3 and I think we should advocating the use of it (as separate from the implementation). It's a minor inconvenience to add to the POM (a complexity that Forge can tare), but far less convenient than slipping into a dependency on an implementation class.
I do agree that we need to revisit it how it all works, but the goal should be so that the API can be honored and that adding a dependency is consistent from module to module.
-Dan