<html><body bgcolor="#FFFFFF"><div>For my $0.02, I wish more people would split their runtime and compile time deps. Too often people add the runtime which pulls in the compile time and the user builds against the runtime classes. Part of this problem, imo, comes from maven resolving compile transitively. If you depend on it to compile, state it, and don't bleed your runtime into mine if it's swappable. I think Sonatype would probably agree. <br><br>Sent from my iPhone</div><div><br>On Aug 16, 2011, at 21:15, Shane Bryzak <<a href="mailto:sbryzak@redhat.com">sbryzak@redhat.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>
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.<br>
<br>
On 17/08/11 13:12, John D. Ament wrote:
<blockquote cite="mid:CAOqetn86uMe_iSNTRtCALy4tPGyCDDeo=6wB=zOb8VvrfOnYSA@mail.gmail.com" type="cite">
<p>What if every module had a bom that was imported, or if this
were handled in the seam-bom?</p>
<p>John</p>
<div class="gmail_quote">On Aug 16, 2011 11:06 PM, "Dan Allen"
<<a moz-do-not-send="true" href="mailto:dan.j.allen@gmail.com"><a href="mailto:dan.j.allen@gmail.com">dan.j.allen@gmail.com</a></a>>
wrote:<br type="attribution">
> On Tue, Aug 16, 2011 at 22:57, Shane Bryzak <<a moz-do-not-send="true" href="mailto:sbryzak@redhat.com"><a href="mailto:sbryzak@redhat.com">sbryzak@redhat.com</a></a>>
wrote:<br>
> <br>
>> Of course, but we break that rule. Solder is one
example, there's<br>
>> multiple utility classes in the implementation that are
required to compile<br>
>> other modules.<br>
>><br>
> <br>
> I consider that a bug (or a work in progress, depending on
how you look at<br>
> it).<br>
> <br>
> <br>
>> Also, by making the implementation runtime-only, the
user is forced to<br>
>> declare two dependencies for their project, one for the
API and one for the<br>
>> implementation. If the implementation was
compile-scoped, they could just<br>
>> declare the implementation dependency and the API would
then be pulled in<br>
>> automatically. This is the kind of stuff we need to
discuss and come to a<br>
>> resolution on.<br>
>><br>
> <br>
> Again, I don't think one dependency is a holy grail. We are
making an<br>
> optimization that I don't find necessary. Making an
implementation<br>
> compile-scoped could be classified as careless programming
(by some strict<br>
> architects, let's say).<br>
> <br>
> If it's setup correctly, depending on seam-faces (the impl)
should make it a<br>
> runtime dep, make the api compile time, make any dependent
api compile time<br>
> and make any dependency impl runtime. If Maven can't
accommodate that, then<br>
> it's just a pita (even then, the worse thing that happens
is that the user<br>
> has two dependencies).<br>
> <br>
> -Dan<br>
> <br>
> -- <br>
> Dan Allen<br>
> Principal Software Engineer, Red Hat | Author of Seam in
Action<br>
> Registered Linux User #231597<br>
> <br>
> <a moz-do-not-send="true" href="http://www.google.com/profiles/dan.j.allen#about"><a href="http://www.google.com/profiles/dan.j.allen#about">http://www.google.com/profiles/dan.j.allen#about</a></a><br>
> <a moz-do-not-send="true" href="http://mojavelinux.com"><a href="http://mojavelinux.com">http://mojavelinux.com</a></a><br>
> <a moz-do-not-send="true" href="http://mojavelinux.com/seaminaction"><a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a></a><br>
</div>
</blockquote>
<br>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>seam-dev mailing list</span><br><span><a href="mailto:seam-dev@lists.jboss.org">seam-dev@lists.jboss.org</a></span><br><span><a href="https://lists.jboss.org/mailman/listinfo/seam-dev">https://lists.jboss.org/mailman/listinfo/seam-dev</a></span><br></div></blockquote></body></html>