+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 > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
