<div class="gmail_quote">On Sun, Apr 4, 2010 at 1:00 AM, Jason Porter <span dir="ltr"><<a href="http://lightguard.jp">lightguard.jp</a>@<a href="http://gmail.com">gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Sat, Apr 3, 2010 at 11:21, Dan Allen <span dir="ltr"><<a href="mailto:dan.j.allen@gmail.com" target="_blank">dan.j.allen@gmail.com</a>></span> wrote:<br></div><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Module writers,<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
</blockquote><div><br></div></div><div>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.</div>
</div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div><div>
<br></div><div>-Dan</div><div><br></div></div>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br><br><a href="http://mojavelinux.com">http://mojavelinux.com</a><br>
<a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br><a href="http://www.google.com/profiles/dan.j.allen">http://www.google.com/profiles/dan.j.allen</a><br>