On 4 Apr 2010, at 20:26, Jason Porter <lightguard.jp@gmail.com> wrote:


On Sun, Apr 4, 2010 at 09:23, Dan Allen <dan.j.allen@gmail.com> wrote:
Yes, I agree we should avoid duplicate class names in the public API as a general rule, because we've seen the confusion that has caused in the Java EE API (@ManagedBean, @*Scoped, etc). But still, too much package sharing can also be confusing for the developer because it becomes somewhat unclear which modules are providing which classes. So we are agreeing that modules use the base name space of org.jboss.seam.[module], correct? (With the special case of interceptors/decorators, see next).

Originally I was thinking differently, but I'm good with this.  It's still easy to understand, and to a degree still follows the Seam2 package structure so it shouldn't be that difficult to understand how to migrate.  It also helps by knowing exactly which modules you're using just by looking at the imports.  Hopefully the overlap and dependencies between modules is kept to a minimum.

Module name in package makes sense to me.

 
 
That said, Shane had brought up that interceptors and decorators should at least be under the module's base package (the second proposed convention for interceptors/decorators above). We need a vote on that convention:

a) org.jboss.seam.intercept  / org.jboss.seam.decorate

If there's a need to have common intercepters / decorators I'd say put them here, otherwise go with option b.  Option B is consistent with what is being done above, so there's no ambiguity.

Just thinking, with the current modularisatipn of Seam, would there ever be "common" interceptors / decorators? If there are then i am fine with option a but I would think most, if not all, would fall into option b.

 
b) org.jboss.seam.[module].intercept / org.jboss.seam.[module].decorate

Let's find a common ground quickly on this...it's not worth dragging out.

I agree, I dislike long conversations of this nature :) I say we're good with this, time to move on.

Ken Finnigan