On 17/08/11 13:05, Dan Allen wrote:
On Tue, Aug 16, 2011 at 22:57, Shane Bryzak <sbryzak@redhat.com> wrote:
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 this problem.

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.

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.


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