Would 1 and 2, be on the same maven project ? If a utility is really useful for others, maybe it could be on it's own maven project to avoid circular reference in the future when other modules want to reuse these utilities.
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]
-- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
