On 17/08/11 13:05, Dan Allen wrote:
On Tue, Aug 16, 2011 at 22:57, Shane Bryzak <sbryzak(a)redhat.com
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.
I consider that a bug (or a work in progress, depending on how you
look at it).
George suggested that we make solder a single jar, and to me it makes
sense considering it's a set of utility features, and it would solve
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
Again, I don't think one dependency is a holy grail. We are making an
optimization that I don't find necessary. Making an implementation
compile-scoped could be classified as careless programming (by some
strict architects, let's say).
That's fine as long as we're consistent with it.
If it's setup correctly, depending on seam-faces (the impl) should
make it a runtime dep, make the api compile time, make any dependent
api compile time and make any dependency impl runtime. If Maven
can't accommodate that, then it's just a pita (even then, the worse
thing that happens is that the user has two dependencies).
Maven won't allow this. If the dependency is runtime, it will be
totally ignored during the compile phase.
Principal Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597