You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2007/07/03 12:38:45 UTC
Making the base artifact processor utilities more readily available
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.
Simon
Re: Making the base artifact processor utilities more readily available
Posted by Luciano Resende <lu...@gmail.com>.
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 <en...@gmail.com> 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" <si...@googlemail.com>
> To: <tu...@ws.apache.org>; <an...@gmail.com>
> 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 <an...@apache.org> wrote:
> >>
> >> On 7/3/07, Simon Laws <si...@googlemail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Making the base artifact processor utilities more readily available
Posted by Venkata Krishnan <fo...@gmail.com>.
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 <js...@apache.org> 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 <si...@googlemail.com> wrote:
> >
> >> On 7/3/07, Raymond Feng <en...@gmail.com> wrote:
> >>
> >>> "not completely trivial" is definitely a better term :-).
> >>>
> >>> Thanks,
> >>> Raymond
> >>>
> >>> ----- Original Message -----
> >>> From: "ant elder" <an...@apache.org>
> >>> To: <tu...@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 <en...@gmail.com> 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" <si...@googlemail.com>
> >>>>> To: <tu...@ws.apache.org>; <an...@gmail.com>
> >>>>> 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 <an...@apache.org> wrote:
> >>>>>>
> >>>>>>> On 7/3/07, Simon Laws <si...@googlemail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> >>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>
> >>> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Making the base artifact processor utilities more readily available
Posted by Simon Laws <si...@googlemail.com>.
On 8/8/07, Jean-Sebastien Delfino <js...@apache.org> 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 <si...@googlemail.com> wrote:
> >
> >> On 7/3/07, Raymond Feng <en...@gmail.com> wrote:
> >>
> >>> "not completely trivial" is definitely a better term :-).
> >>>
> >>> Thanks,
> >>> Raymond
> >>>
> >>> ----- Original Message -----
> >>> From: "ant elder" <an...@apache.org>
> >>> To: <tu...@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 <en...@gmail.com> 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" <si...@googlemail.com>
> >>>>> To: <tu...@ws.apache.org>; <an...@gmail.com>
> >>>>> 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 <an...@apache.org> wrote:
> >>>>>>
> >>>>>>> On 7/3/07, Simon Laws <si...@googlemail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> >>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>>
> >>> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Ok, thanks Sebastien. Mine are in
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/binding-sca-xml/src/main/java/org/apache/tuscany/sca/binding/sca/xml/SCABindingProcessor.java
See the comment toward the bottom of this file.
Simon
Re: Making the base artifact processor utilities more readily available
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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 <si...@googlemail.com> wrote:
>
>> On 7/3/07, Raymond Feng <en...@gmail.com> wrote:
>>
>>> "not completely trivial" is definitely a better term :-).
>>>
>>> Thanks,
>>> Raymond
>>>
>>> ----- Original Message -----
>>> From: "ant elder" <an...@apache.org>
>>> To: <tu...@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 <en...@gmail.com> 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" <si...@googlemail.com>
>>>>> To: <tu...@ws.apache.org>; <an...@gmail.com>
>>>>> 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 <an...@apache.org> wrote:
>>>>>>
>>>>>>> On 7/3/07, Simon Laws <si...@googlemail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
>>>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>>>
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Making the base artifact processor utilities more readily available
Posted by Venkata Krishnan <fo...@gmail.com>.
+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 <si...@googlemail.com> wrote:
> On 7/3/07, Raymond Feng <en...@gmail.com> wrote:
> >
> > "not completely trivial" is definitely a better term :-).
> >
> > Thanks,
> > Raymond
> >
> > ----- Original Message -----
> > From: "ant elder" <an...@apache.org>
> > To: <tu...@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 <en...@gmail.com> 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" <si...@googlemail.com>
> > >> To: <tu...@ws.apache.org>; <an...@gmail.com>
> > >> 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 <an...@apache.org> wrote:
> > >> >>
> > >> >> On 7/3/07, Simon Laws <si...@googlemail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> > >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >>
> > >>
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> > 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Making the base artifact processor utilities more readily available
Posted by Simon Laws <si...@googlemail.com>.
On 7/3/07, Raymond Feng <en...@gmail.com> wrote:
>
> "not completely trivial" is definitely a better term :-).
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "ant elder" <an...@apache.org>
> To: <tu...@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 <en...@gmail.com> 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" <si...@googlemail.com>
> >> To: <tu...@ws.apache.org>; <an...@gmail.com>
> >> 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 <an...@apache.org> wrote:
> >> >>
> >> >> On 7/3/07, Simon Laws <si...@googlemail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> >> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> 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
Re: Making the base artifact processor utilities more readily available
Posted by Raymond Feng <en...@gmail.com>.
"not completely trivial" is definitely a better term :-).
Thanks,
Raymond
----- Original Message -----
From: "ant elder" <an...@apache.org>
To: <tu...@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 <en...@gmail.com> 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" <si...@googlemail.com>
>> To: <tu...@ws.apache.org>; <an...@gmail.com>
>> 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 <an...@apache.org> wrote:
>> >>
>> >> On 7/3/07, Simon Laws <si...@googlemail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Making the base artifact processor utilities more readily available
Posted by ant elder <an...@apache.org>.
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 <en...@gmail.com> 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" <si...@googlemail.com>
> To: <tu...@ws.apache.org>; <an...@gmail.com>
> 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 <an...@apache.org> wrote:
> >>
> >> On 7/3/07, Simon Laws <si...@googlemail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Making the base artifact processor utilities more readily available
Posted by Raymond Feng <en...@gmail.com>.
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" <si...@googlemail.com>
To: <tu...@ws.apache.org>; <an...@gmail.com>
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 <an...@apache.org> wrote:
>>
>> On 7/3/07, Simon Laws <si...@googlemail.com> 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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Making the base artifact processor utilities more readily available
Posted by Simon Laws <si...@googlemail.com>.
On 7/3/07, ant elder <an...@apache.org> wrote:
>
> On 7/3/07, Simon Laws <si...@googlemail.com> 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
Re: Making the base artifact processor utilities more readily available
Posted by ant elder <an...@apache.org>.
On 7/3/07, Simon Laws <si...@googlemail.com> 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