You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@apache.org> on 2009/05/06 08:39:54 UTC
Re: Merging model and model-xml modules into one
On Thu, Apr 30, 2009 at 8:24 AM, ant elder <an...@apache.org> wrote:
> processing. I wonder if there is still some refactoring that could be
> done here - it sounds like the "contribution" module includes the
> model code for the sca-contribution.xml and
> sca-contribution-generated.xml files as well as the code for the
> contribution service and its SPIs and extension points - perhaps the
> model code should be separated from the contribution service so there
> is module for the contribution service and another module for the
> sca-contribution model, and then the existing contribution-xml module
> gets merged into the new model module. (Which fits in nicely with a
> conversation from 2 years ago!
> http://apache.markmail.org/message/nncxz73tbozov44y)
>
> ...ant
>
No replies to that so i'll assume its reasonable and add it to the
list of tidying up I'm doing.
...ant
Re: Merging model and model-xml modules into one
Posted by ant elder <an...@gmail.com>.
On Thu, May 7, 2009 at 8:33 AM, ant elder <an...@gmail.com> wrote:
> On Wed, May 6, 2009 at 6:03 PM, Simon Laws <si...@googlemail.com>
> wrote:
>
> > So how about
> >
> > contribution-metadata - I can never find this stuff
> > contribution (or core-contribution or contribution-runtime) for all
> > the spi/infrastructure type of stuff
> > contribution-xxxx
> >
>
> Thats starting to look much cleaner to me.
>
> There are three contribution-xxxx modules - contribution-java,
> contribution-namespace, contribution-osgi. Do we really need the -java
> and -namespace ones as separate modules? Unless there are real use
> cases or problems solved by keeping them separate i think they should
> be merged with one of the other contribution modules.
>
> ...ant
>
In r773311 I've redone the module merge for this to include the svn history.
Now i'll review all the classes in that one module to try to work out what
should be there or moved to a separate module. The build is working for me
except fo a test fail on node-launcher-equinox, but that was failing for me
before these changes but i look at that too.
...ant
Re: Merging model and model-xml modules into one
Posted by ant elder <an...@apache.org>.
On Wed, May 6, 2009 at 5:09 PM, Raymond Feng <en...@gmail.com> wrote:
> I don't think we use the contribution service any more in 2.x. The workspace
> modules are now in charge of contribution processing.
>
That brings up an interesting point :-) Another place i think we can
be tidying up is with how the workspace, implementation-node and Node
APIs work. I was leaving this till after some of the other refactoring
threads have quietened down but as its come up here i'll start a new
thread about it - see the email "Node usage of the workspace and
implementation-node modules".
...ant
Re: Merging model and model-xml modules into one
Posted by Simon Laws <si...@googlemail.com>.
On Mon, May 11, 2009 at 10:44 AM, ant elder <an...@gmail.com> wrote:
> On Wed, May 6, 2009 at 6:03 PM, Simon Laws <si...@googlemail.com> wrote:
>
>> So how about
>>
>> contribution-metadata - I can never find this stuff
>> contribution (or core-contribution or contribution-runtime) for all
>> the spi/infrastructure type of stuff
>> contribution-xxxx
>>
>> Simon
>>
>
> Continuing with these changes, to clarify what we think are -metadata
> classes, spi/infrastructure, etc, it looks like we have the following
> functions in the contribution module:
>
> - model and xml processors for the sca-contribution.xml file
> - generic code shared by all the model/xml modules like
> BaseStAXArtifactProcessor
> - runtime contribution service classes
>
> so would it be reasonable to split the current contribution module up
> like that?
>
> Does the generic code like BaseStAXArtifactProcessor need to be in its
> own contribution-xxx module or could it be somewhere shared like the
> existing spi module?
>
> ...ant
>
Ok, looking at it now the name "contribution-metadata" seems a little
awkward so we could stick with "contribution" as the module that
models the contribution an (now) contains the code to do all the
processing to read and create that model.
I think we should have the support for import/export namespace and
java as separate modules as they implement extension points
independent of the actual contribution processing.
Re. the generic code classes. It's certainly shared by lots of other
modules which currently depend on contribution. We could fluff up
something like core-contribution. Do the core-* module though only
contain runtime things? Alternatively I could be persuaded just leave
it where it is.
Simon
Re: Merging model and model-xml modules into one
Posted by ant elder <an...@gmail.com>.
On Wed, May 6, 2009 at 6:03 PM, Simon Laws <si...@googlemail.com> wrote:
> So how about
>
> contribution-metadata - I can never find this stuff
> contribution (or core-contribution or contribution-runtime) for all
> the spi/infrastructure type of stuff
> contribution-xxxx
>
> Simon
>
Continuing with these changes, to clarify what we think are -metadata
classes, spi/infrastructure, etc, it looks like we have the following
functions in the contribution module:
- model and xml processors for the sca-contribution.xml file
- generic code shared by all the model/xml modules like
BaseStAXArtifactProcessor
- runtime contribution service classes
so would it be reasonable to split the current contribution module up
like that?
Does the generic code like BaseStAXArtifactProcessor need to be in its
own contribution-xxx module or could it be somewhere shared like the
existing spi module?
...ant
Re: Merging model and model-xml modules into one
Posted by ant elder <an...@gmail.com>.
On Wed, May 6, 2009 at 6:03 PM, Simon Laws <si...@googlemail.com> wrote:
> So how about
>
> contribution-metadata - I can never find this stuff
> contribution (or core-contribution or contribution-runtime) for all
> the spi/infrastructure type of stuff
> contribution-xxxx
>
Thats starting to look much cleaner to me.
There are three contribution-xxxx modules - contribution-java,
contribution-namespace, contribution-osgi. Do we really need the -java
and -namespace ones as separate modules? Unless there are real use
cases or problems solved by keeping them separate i think they should
be merged with one of the other contribution modules.
...ant
Re: Merging model and model-xml modules into one
Posted by Simon Laws <si...@googlemail.com>.
On Wed, May 6, 2009 at 5:09 PM, Raymond Feng <en...@gmail.com> wrote:
> I don't think we use the contribution service any more in 2.x. The workspace
> modules are now in charge of contribution processing.
>
> The current tuscany-contribution module contains the model for
> Contribution/Artifact. It also defines the SPIs for contribution scanners,
> artifact processors, and model resolvers.
>
> Thanks,
> Raymond
> --------------------------------------------------
> From: "ant elder" <an...@apache.org>
> Sent: Tuesday, May 05, 2009 11:39 PM
> To: <de...@tuscany.apache.org>
> Subject: Re: Merging model and model-xml modules into one
>
>> On Thu, Apr 30, 2009 at 8:24 AM, ant elder <an...@apache.org> wrote:
>>
>>> processing. I wonder if there is still some refactoring that could be
>>> done here - it sounds like the "contribution" module includes the
>>> model code for the sca-contribution.xml and
>>> sca-contribution-generated.xml files as well as the code for the
>>> contribution service and its SPIs and extension points - perhaps the
>>> model code should be separated from the contribution service so there
>>> is module for the contribution service and another module for the
>>> sca-contribution model, and then the existing contribution-xml module
>>> gets merged into the new model module. (Which fits in nicely with a
>>> conversation from 2 years ago!
>>> http://apache.markmail.org/message/nncxz73tbozov44y)
>>>
>>> ...ant
>>>
>>
>> No replies to that so i'll assume its reasonable and add it to the
>> list of tidying up I'm doing.
>>
>> ...ant
>
>
We seem to have several things then...
contribution
contribution metadata model
contribution model
artifact model - derived from scanner
import model - derived from metadata
export model - derived from metadata
contribution scanner SPI - used to locate artifacts
stax processing base support - seems like a strange place for it
model resolver base support - again slightly odd place
contribution-xml
contribution metadata processor
then we have several...
contribution.xxxx
where xxxx seems to vary between how imports/exports are processed
(java/namespace) and how OSGi contributions as a whole are treated
(osgi).
So how about
contribution-metadata - I can never find this stuff
contribution (or core-contribution or contribution-runtime) for all
the spi/infrastructure type of stuff
contribution-xxxx
Simon
Re: Merging model and model-xml modules into one
Posted by Raymond Feng <en...@gmail.com>.
I don't think we use the contribution service any more in 2.x. The workspace
modules are now in charge of contribution processing.
The current tuscany-contribution module contains the model for
Contribution/Artifact. It also defines the SPIs for contribution scanners,
artifact processors, and model resolvers.
Thanks,
Raymond
--------------------------------------------------
From: "ant elder" <an...@apache.org>
Sent: Tuesday, May 05, 2009 11:39 PM
To: <de...@tuscany.apache.org>
Subject: Re: Merging model and model-xml modules into one
> On Thu, Apr 30, 2009 at 8:24 AM, ant elder <an...@apache.org> wrote:
>
>> processing. I wonder if there is still some refactoring that could be
>> done here - it sounds like the "contribution" module includes the
>> model code for the sca-contribution.xml and
>> sca-contribution-generated.xml files as well as the code for the
>> contribution service and its SPIs and extension points - perhaps the
>> model code should be separated from the contribution service so there
>> is module for the contribution service and another module for the
>> sca-contribution model, and then the existing contribution-xml module
>> gets merged into the new model module. (Which fits in nicely with a
>> conversation from 2 years ago!
>> http://apache.markmail.org/message/nncxz73tbozov44y)
>>
>> ...ant
>>
>
> No replies to that so i'll assume its reasonable and add it to the
> list of tidying up I'm doing.
>
> ...ant