Hi Sebastien, thanks. Here are the processors in the policy-xml - https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/policy-xml/src/main/java/org/apache/tuscany/sca/policy/xml/PolicySetProcessor.java - https://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/policy-xml/src/main/java/org/apache/tuscany/sca/policy/xml/PolicyIntentProcessor.java
Right now these two have copies of getQName, getName, getQNameValue copied over. These seem to be pretty generic and useful util kind of methods. Thanks - Venkat On 8/8/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
