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.
--Lincoln
On Sun, Apr 4, 2010 at 1:00 AM, Jason Porter <lightguard.jp@gmail.com> wrote:
On Sat, Apr 3, 2010 at 11:21, Dan Allen <dan.j.allen@gmail.com> wrote:Module writers,For as much as we all enjoy discussing things like naming conventions (not), I do feel that we need to establish some consistency across modules. Rather than devising some arbitrary scheme, I'd rather build on the package name choices that are coming out of the modules and try to align on what seems natural.Tihomir raised an important point with respect to qualifiers. When doing XML Bean Config, the configuration is clearer if qualifiers are in their own package so they can be bound to a unique namespace prefix. This helps distinguish the qualifier elements from the class elements (like class name, method, field, etc). As for other annotations, Seam has traditionally put them in the "annotations" subpackage, which Shane has done in remoting and security.As a consumer I would love to see all qualifiers/annotations/interceptors/decorators/etc in the same package, it just makes things easier to find when you're looking for classes or javadoc. This is also probably easier for people migrating from Seam2 to understand how to easily migrate.Are you suggesting using the same package across all modules, or do you mean all qualifiers (for instance) in the same package in a single module? Sharing packages between modules seems to me like a bad idea because that would create too many conflicts. I think modules have to at least use their own base package.If we are already on the same page in that respect, and you are just saying that within a single module the general types should be grouped together, I'd agree that should be the default approach, with exceptions where necessary.Remember, if you aren't sure what to use in a particular case, you can always ask. When you do, give a list of proposals and leverage the feedback to be the choice people would most expect.-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
_______________________________________________
seam-dev mailing list
seam-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev