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 <[email protected]
<mailto:[email protected]>> 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
--
Dan Allen
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://www.google.com/profiles/dan.j.allen#about
http://mojavelinux.com
http://mojavelinux.com/seaminaction
_______________________________________________
seam-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/seam-dev
