7:47 a.m.
The basic rules are:
* Do not share packages between modules. This will lead to breakage, and due to the ways
in which accessibility works in Java will have unintended consequences. Every class in a
module should be namespaced to the relevant package
* Split out your API from your impl (so don't put impl classes into the same package)
* Keep things simple, don't produce overly complex, hard to navigate hierarchies. In
general you should put all your public API into a single package. If you need to split it
up, split it up by function NOT by classification. For example, with security, we might
want to split up the API like:
org.jboss.seam.security.identity
org.jboss.seam.security.auth
or with JSF, like:
org.jboss.seam.faces.scopes
org.jboss.seam.faces.messages
I don't think splitting things up by classification makes life easy for the user, as
they struggle to find what they need, and understand how the various bits of the API inter
relate.
On 4 Apr 2010, at 07:24, Lincoln Baxter, III wrote:
On Sun, Apr 4, 2010 at 1:00 AM, Jason Porter
<lightguard.jp(a)gmail.com> wrote:
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.
Exactly! -- We should add decorators to the naming conventions established for
interceptors:
Regardless of module, the following naming standards should be followed for Interceptors
and Decorators:
org.jboss.seam.intercept.[name]Interceptor;
org.jboss.seam.decorate.[name]Decorator;
I don't necessarily agree on all Qualifiers & annotations; though, I don't
necessarily disagree either. I think packaging annotations and qualifiers with their
relevant packages is probably the best way to go, since they will be near other relevant
classes in the package. Interceptors and Decorators have the problem that users may need
to register them manually in beans.xml, thus, using a standard package will be a bigger
convenience, still not a technical necessity. Basically -- I'm asking to be convinced
;)
--Lincoln
On Sat, Apr 3, 2010 at 11:21, Dan Allen <dan.j.allen(a)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.
-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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Jason Porter
Software Engineer
Open Source Advocate
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev