On 4 Apr 2010, at 20:26, Jason Porter <lightguard.jp(a)gmail.com> wrote:
On Sun, Apr 4, 2010 at 09:23, Dan Allen <dan.j.allen(a)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