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 (JIRA)" <de...@tuscany.apache.org> on 2011/05/23 12:38:47 UTC

[jira] [Resolved] (TUSCANY-3443) Devise a away to track and spi changes we make in 2.x

     [ https://issues.apache.org/jira/browse/TUSCANY-3443?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Simon Laws resolved TUSCANY-3443.
---------------------------------

    Resolution: Fixed

We now haw the itest/spi test

> Devise a away to track and spi changes we make in 2.x
> -----------------------------------------------------
>
>                 Key: TUSCANY-3443
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-3443
>             Project: Tuscany
>          Issue Type: Improvement
>          Components: SCA Java Runtime
>    Affects Versions: Java-SCA-2.x
>         Environment: All
>            Reporter: Simon Laws
>
> From this thread (http://www.mail-archive.com/dev%40tuscany.apache.org/msg11292.html) it would be good to have a clearer idea of what SPI we define and how it is changing as we move toward our 2.0 release. Here are some ideas...
> Identify with a greater degree of fidelity which interfaces/classes we actually consider to be part of the SPI
>    Which interfaces/classes will be implemented/extended as part of building extensions, e.g. the binding or implementation model
>    Which interfaces/classes will be called as part of building extensions, e.g. endpoints/endpointreferences
>   We have two lists now on the 2.x docs page and I would like to review and aggregate if possible
> Have Java doc for all of the files above
> Identify when these change from revision to revision
>   Create versions tests
>   Keep a manual list of the APIs the feature pack use and take it upon ourselves to take note and report when we change things on the list OR
>   Have an itest which looks at each file and compares them against a known hash of the previous good version of the file
> When something has changed identify what has actually changed
>   Look for differences in the Java doc (needs to be Java doc there to do this of course)
>   manual description
> Keep a current status of what has changed
>   manual in the first instance. On the status page?

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira