Here are a few issues with observing the convention that I have
discovered so far:
1. BindingImpl is in org.apache.tuscany.assembly.impl but is
exposed as a subclassing extension point for binding extensions.
2. AbstractInvocationHandler and MessageImpl are in the
org.apache.tuscany.invocation interface package. The first
of these is intended for suclassing, so could be considered
an SPI, but the second is not.
3. DefaultAssemblyFactory is in the interface package
org.apache.tuscany.assembly, but it extends from AssemblyFactoryImpl
which is in the implementation package org.apache.tuscany.assembly.impl.
This means that "impl" code is showing up indirectly as part of an
SPI interface. The same arrangement is used for DefaultPolicyFactory,
DefaultWSDLFactory, and DefaultWebServiceBindingFactory.
4. There's a PrintUtil class in the org.apache.tuscany.assembly.util
package. Why isn't this in the impl subpackage?
5. The org.apache.tuscany.assembly.xml package seems to contain
implementation classes that aren't in an "impl" subpackage.
6. The bindings don't seem to follow the "impl" subpackage convention,
except for binding-ws.
7. None of the core subpackages follow the "impl" subpackage
convention. They are called component, event, invocation, runtime,
store, util, and work.
8. I'm not sure whether the core-databinding module follows the
convention. There is no "impl" subpackage, but there seems to be
some implementation code.
9. core-spring nearly follows the convention, with everything in "impl"
subpackages except for one class ComponentContext in the "runtime"
subpackage.
I haven't had time yet to go through the other modules whose names
start from d to z. From the above examples, it appears that we don't
have very much consistency at the moment.
Simon
Raymond Feng wrote:
I'll make the changes after I clean up the code.
Thanks,
Raymond
----- Original Message ----- From: "ant elder" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Friday, May 04, 2007 9:32 AM
Subject: Re: Interfaces for implementation/binding extensions to provide
runtime behaviors
On 5/4/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Simon Nash wrote:
> At the moment these interfaces are in the org.apache.tuscany.core
> package. This package name is also used by core implementation code,
> which is confusing.
>
> Is it the intention to change the package name for these SPI
interfaces
> to something else to avoid confusion between SPIs and implementation?
> For example, the SPIs could have a package name containing "spi".
>
> I think it's inmportant to do this in order to clearly separate SPI
> interfaces from implementation code.
>
> Simon
>
Good point, SPI interfaces and their implementations should be in
different packages.
I'm not too keen on adding .spi. to all the packages containing our
interfaces. I would prefer to have a simpler scheme:
o.a.t.core is the SPI
o.a.t.core.impl is the implementation
Same for our models:
o.a.t.contribution, o.a.t.assembly for the interfaces
o.a.t.contribution.impl , o.a.t.assembly.impl for the implementations
I see two benefits to that:
- the packages that most people use are simpler
- if you are using classes in .impl. you are warned that you're using
the implementations directly.
Sounds good to me.
...ant
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
