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]
