On 16 Apr 2010, at 20:19, Lincoln Baxter, III wrote:
Ugh, though using this package convention means that hiding classes
via package-private is less appealing.
It also goes against all guidelines for designing modular software, and will make adopting
either Jigsaw or OSGi much harder.
Watch a presentation on either for why :-)
On Fri, Apr 16, 2010 at 3:17 PM, Lincoln Baxter, III <lincolnbaxter(a)gmail.com>
I should add that I'm fine with using whatever packaging schema the Interceptor would
reside in without such a convention, but this protects us from refactoring, so I think
it's a good idea.
I don't understand how this "protects us from refactoring" - can you explain
what you mean?
On Fri, Apr 16, 2010 at 3:16 PM, Lincoln Baxter, III <lincolnbaxter(a)gmail.com>
Ok - so this means we are back to square one. Can we discuss and agree on the following
All @Interceptor classes must:
• Adhere to the following package and naming scheme:
No, why would we want to do this? Classes defined in a module should reside in a package
owned by that package. It prevents any risk of namespace clashes
• Warn users (or Error out when appropriate) if they are using
interceptable @Annotations when the @Inteceptor itself is not registered, and provide
instructions to correct the configuration:
(@Interceptor registration can be checked in the Extension class AfterBeanDiscovery via
Yes. We need a util method for this.
All @Decorator classes must:
• Adhere to the following package and naming scheme: org.jboss.seam.decorate.*Decorator
Let's discuss and resolve, since we're starting to release,
and this is important. (Affects Faces directly.)
This is all in the guidelines already...