[seam-dev] Meeting 2011-08-17

[Shane Bryzak]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20110817/8e5f85bc/attachment.html