[seam-dev] package naming conventions

[Lincoln Baxter, III]

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 2:22 AM, Dan Allen <dan.j.allen at gmail.com> wrote:

> On Sun, Apr 4, 2010 at 1:00 AM, Jason Porter <lightguard.jp at gmail.com>wrote:
>
>> On Sat, Apr 3, 2010 at 11:21, Dan Allen <dan.j.allen at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>


-- 
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20100404/b10f7ff5/attachment-0001.html