12:21 p.m.
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.
So far we have:
= use org.jboss.seam.[module] as your root namespace, where [module] is the
SVN folder of your module
= put qualifiers in the "qualifiers" sub-package (should it be singular
instead?)
= put annotations in the "annotations" sub-package (should it be singular
instead?)
= put event types in the "events" sub-package (should it be singular
instead?)
= where applicable, try to align your packages with those in CDI/Weld (for
instance, context implementations go in the "context" package)
We'll keep the conventions to the smallest amount possible. If you have
suggestions or changes, please bring them forward. It's up to you. But let's
remember that what we choose isn't all that important. We just don't want be
doing totally different things.
-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
1:35 p.m.
Where in the event hierarhy does "subfunction" go if the module does
many things? event.subfunction. or subfunction.event.?
On 4/3/10, 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.
So far we have:
= use org.jboss.seam.[module] as your root namespace, where [module] is the
SVN folder of your module
= put qualifiers in the "qualifiers" sub-package (should it be singular
instead?)
= put annotations in the "annotations" sub-package (should it be singular
instead?)
= put event types in the "events" sub-package (should it be singular
instead?)
= where applicable, try to align your packages with those in CDI/Weld (for
instance, context implementations go in the "context" package)
We'll keep the conventions to the smallest amount possible. If you have
suggestions or changes, please bring them forward. It's up to you. But let's
remember that what we choose isn't all that important. We just don't want be
doing totally different things.
-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
--
Sent from my mobile device
---
Nik
2:44 p.m.
On Sat, Apr 3, 2010 at 2:35 PM, Nicklas Karlsson <nickarls(a)gmail.com> wrote:
Where in the event hierarhy does "subfunction" go if the
module does
many things? event.subfunction. or subfunction.event.?
I'd say if you've got a fairly substantial number of classes for a
particular function, then you should group them [function].event. I would
say certainly use your judgment there. What we want to establish is a
general structure. That's just my suggestion. If you have a different
viewpoint, please share.
Btw, the main reason this issue comes up in Seam 3 is because the source
code is now modularized :) In Seam 2, most of the classes were together and
it was more obvious where to stick things.
-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
midnight
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.
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.
-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
1:22 a.m.
On Sun, Apr 4, 2010 at 1:00 AM, Jason Porter <lightguard.jp(a)gmail.com>wrote:
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.
>
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
9:40 a.m.
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(a)gmail.com> wrote:
On Sun, Apr 4, 2010 at 1:00 AM, Jason Porter
<lightguard.jp(a)gmail.com>wrote:
> 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.
>>
>
> 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
10:23 a.m.
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
2:26 p.m.
On Sun, Apr 4, 2010 at 09:23, Dan Allen <dan.j.allen(a)gmail.com> wrote:
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).
Originally I was thinking differently, but I'm good with this. It's still
easy to understand, and to a degree still follows the Seam2 package
structure so it shouldn't be that difficult to understand how to migrate.
It also helps by knowing exactly which modules you're using just by looking
at the imports. Hopefully the overlap and dependencies between modules is
kept to a minimum.
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
If there's a need to have common intercepters / decorators I'd say put them
here, otherwise go with option b. Option B is consistent with what is being
done above, so there's no ambiguity.
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.
I agree, I dislike long conversations of this nature :) I say we're good
with this, time to move on.
--
Jason Porter
Software Engineer
Open Source Advocate
PGP key id: 926CCFF5
PGP key available at: keyserver.net, pgp.mit.edu
3:21 p.m.
On 4 Apr 2010, at 20:26, Jason Porter <lightguard.jp(a)gmail.com> wrote:
On Sun, Apr 4, 2010 at 09:23, Dan Allen <dan.j.allen(a)gmail.com> wrote:
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).
Originally I was thinking differently, but I'm good with this. It's
still easy to understand, and to a degree still follows the Seam2
package structure so it shouldn't be that difficult to understand
how to migrate. It also helps by knowing exactly which modules
you're using just by looking at the imports. Hopefully the overlap
and dependencies between modules is kept to a minimum.
Module name in package makes sense to me.
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
If there's a need to have common intercepters / decorators I'd say
put them here, otherwise go with option b. Option B is consistent
with what is being done above, so there's no ambiguity.
Just thinking, with the current modularisatipn of Seam, would there
ever be "common" interceptors / decorators? If there are then i am
fine with option a but I would think most, if not all, would fall into
option b.
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.
I agree, I dislike long conversations of this nature :) I say we're
good with this, time to move on.
Ken Finnigan
1:24 a.m.
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"
1:32 a.m.
On Sun, Apr 4, 2010 at 2:24 AM, Lincoln Baxter, III <lincolnbaxter(a)gmail.com
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 do agree we can make a different case for interceptors and decorators as
we do for qualifiers, events and other annotations. Interceptors and
decorators need to be easy to type in XML, whereas qualifiers, events and
other annotations just need to be IDE friendly (and can have a more variant
classification structure).
While I've submitted my support for convention Lincoln suggests above, I'm
also open to adding the module short name:
org.jboss.seam.[module].intercept.[name]Interceptor
org.jboss.seam.[module].intercept.[name]Interceptor
I do think we should agree on one of these two proposals for interceptors
and decorators specifically.
-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
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
12:40 p.m.
Good suggestions. We should merge these into the guidelines page.
I have also updated the intro guidelines page to clarify that it's an open
book and we are willing to discuss it if you don't agree (within reason).
http://seamframework.org/Seam3/DevelopmentGuidelines
-Dan
On Wed, Apr 7, 2010 at 8:47 AM, Pete Muir <pmuir(a)redhat.com> wrote:
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
_______________________________________________
seam-dev mailing list
seam-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/seam-dev
--
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
5377
days inactive
5381
days old
12 comments
6 participants
participants (6)
-
Dan Allen -
Jason Porter -
Ken Finnigan -
Lincoln Baxter, III -
Nicklas Karlsson -
Pete Muir