On Sun, Apr 4, 2010 at 10:40 AM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
IMO -- If we having a naming conflict, then we have a problem -- We
should
put in an effort across modules to coordinate naming and functionality. If
there are two modules providing the @Secure or two modules providing the
@Conversational attribute, then we probably have duplicate functionality,
and need to re-think where that functionality should go, in a common place;
new modules could even be spawned for such reusable functionality.
These types of naming conflicts will also cause usability issues when
people try to use both modules -- package differences aside, you'll still
have to be referencing them by the fully qualified name, and that's not
cool.
We shouldn't be duplicating much of anything.
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).
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
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.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen