"not completely trivial" is definitely a better term :-).
Thanks,
Raymond
----- Original Message -----
From: "ant elder" <[EMAIL PROTECTED]>
To: <tuscany-dev@ws.apache.org>
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: <tuscany-dev@ws.apache.org>; <[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]
