I think this would over-complicate things.  I've got no problem with telling our users that they must declare a dependency for a module's API, and a dependency for the IMPL they want to use, if that's what we decide.

On 17/08/11 13:12, John D. Ament wrote:

What if every module had a bom that was imported, or if this were handled in the seam-bom?

John

On Aug 16, 2011 11:06 PM, "Dan Allen" <dan.j.allen@gmail.com> 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).
>
>
>> 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).
>
> 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).
>
> -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