Venkata Krishnan wrote:
+1 to move some commonly useful parts to utils area. I have also
ended up copying some bits of code into processors in the policy-xml
module.
- Venkat
On 8/7/07, Simon Laws <[EMAIL PROTECTED]> wrote:
On 7/3/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
"not completely trivial" is definitely a better term :-).
Thanks,
Raymond
----- Original Message -----
From: "ant elder" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, July 03, 2007 10:55 AM
Subject: Re: Making the base artifact processor utilities more readily
available
How strict would it be on the error-prone bit be in "Only expose the
utility/helper classes if they are common and error-prone"? For example,
there's an AbstractImplementation class here which I think is useful and
i've used multiple times, but its arguable how error-prone the code is.
https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/extension-helper/src/main/java/org/apache/tuscany/sca/spi/utils/AbstractImplementation.java
How about "not completely trivial" instead of "error-prone"?
...ant
On 7/3/07, Raymond Feng <[EMAIL PROTECTED]> wrote:
Hi,
At this moment, we use the term "SPI" to represent all the interfaces
and
classes accessible to the extension developers. I think it can be
further
divided into two categories.
1) The contract interfaces/classes
2) The utility/helper classes
1 is mandatory while 2 is optional to extension developers. I'm fine to
expose the helper/utility classes as long as the following criteria are
meet:
a) Make it obvious (for example, using util. as part of the package
name)
for extension developers to understand they are optional helper/utility
classes which are not part of the contract
b) Only expose the utility/helper classes if they are common and
error-prone
to implement by individual extensions.
Thanks,
Raymond
----- Original Message -----
From: "Simon Laws" <[EMAIL PROTECTED]>
To: <[email protected]>; <[EMAIL PROTECTED]>
Sent: Tuesday, July 03, 2007 7:12 AM
Subject: Re: Making the base artifact processor utilities more readily
available
On 7/3/07, ant elder <[EMAIL PROTECTED]> wrote:
On 7/3/07, Simon Laws <[EMAIL PROTECTED]> wrote:
In writing the Topology mode I had to make a copy of the base
artifact
processor as it only has package visibilityIt has lots of useful
utilities
alongside the assembly specific bits. How about we separate the
utilities
from the assemly specific bits and make the utilities more widely
available.
For example, we could separate the utilites for reading XML
elements
from
those that read specific assembly elements into a more fundamental
base
class.
I think this would be good (but its only fare to note that there's
at
least
one who's away on holiday right now who may not be so keen). One of
the
issues is should the SPI be just interfaces or can it also have
abstract
or
utility helper classes as well. Some of those type of classes could
make
using the existing SPI much easier IMHO and could make things like
the
extension helper redundant.
...ant
To date the SPI (as described in the 0.90 CHANGES document) has been
fairly
consistent in that it has concentrated on interfaces. It's always
easy
to
find the exception that proves the rule as there are classes in there
but
generally it's interfaces. I think it would be useful to expose
those
utilities that we don't expect to change much and allow people access
to
them. I am completely happy to wait on this though. As I say I took a
copy
at the moment in order to avoid any untoward changes. Not ideal but
there
you go. This case is interesting though as the class I want to use is
part
of assembly.xml which we didn't declare as being part of the SPI
currently.
Simon.
Simon
---------------------------------------------------------------------
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]
I've just got back to this. I'm moving the SCA Binding implementation out
of core and the processor currently extends BaseArtifactProcessor which has
package scope.
Now quite a lot of the bits in BaseArtifactProcessor are generally useful,
e.g. getting QNames, reading policies, while others are more specific, e.g.
reading wire details. So, based on Raymond's previous comments, we could
create a o.a.t.s.assembly.xml.utils.BaseArtifactProcessor to hold the
things that are useful across extensions and maintain the current
BaseArtifactProcessor with package scope as being specific to the assembly
model.
I've currently copied all the code I need but it would be nice not to have
to do that.
Simon
I'll take a look at this. Could you please give me pointers to the
actual classes/methods you had to copy? Thanks.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
