Of course, but we break that rule.  Solder is one example, there's multiple utility classes in the implementation that are required to compile other modules.  Also, by making the implementation runtime-only, the user is forced to declare two dependencies for their project, one for the API and one for the implementation.  If the  implementation was compile-scoped, they could just declare the implementation dependency and the API would then be pulled in automatically.  This is the kind of stuff we need to discuss and come to a resolution on.

On 17/08/11 12:48, Dan Allen wrote:
On Tue, Aug 16, 2011 at 22:27, Shane Bryzak <sbryzak@redhat.com> wrote:
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?


Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597