Kelvin,

I hate to slow you down but we may need to change our scoping design and 
implementation so we have clean codegen fixes from 1143 and are not depending 
on EMF's EPackage.Registry.INSTANCE. The problem from current 1143 patch is 
that SDO runtime model are no longer registered with the 
EPackage.Registry.INSTANCE because we are trying not to use the 
EPackage.Registry.INSTANCE so 1143 patch took out the registration code in the 
FactoryBase.java. If we didn't go with the new design, we need to find a way to 
pre-register SDO runtime models with the EPackage.Registry.INSTANCE in addition 
to the builtInModelRegistry.

Let me try to describe the new design here and see whether it makes sense.

Current:
The default helper context is associated with the EPackage.Registry.INSTANCE so 
all the model packages get/put operations will be based on the registry from 
the TCCL.
The local helper context (from SDOUtil.createHelperContext()) is associated 
with the local package registry. If the model packages get/put operations 
failed, the delegation chain is builtInModelRegistry then 
EPackage.Registry.INSTANCE

* default HelperContext (EPackage.Registry.INSTANCE/TCCL based)
* local HelperContext (local package registry) --delegate--> 
builtInModelRegistry --delegate--> EPackage.Registry.INSTANCE

EMF and SDO runtime models resided in EPackage.Registry.INSTANCE

SDO type models (sdoModel.xsd, sdoJava.xsd, sdoXML.xsd, and sdoInternal.xsd) 
resided in both builtInModelRegistry and
EPackage.Registry.INSTANCE (registered in the FactoryBase.java)

User models will reside either in the EPackage.Registry or local package 
registry

New:
default HelperContext (SDOPackageRegistryImpl/TCCL based) --delegate--> 
builtInModelRegistry
local HelperContext (local package registry) --delegate--> builtInModelRegistry

EMF, SDO runtime, and SDO type models all reside in the builtInModelRegistry

User models will reside either in the SDOPackageRegistryImpl(TCCL based) or 
local package registry

This new scoping design needs to closely work with TUSCANY-1143 because the new 
codegen pattern needs to be used to generate the SDO runtime models to support 
this new design.

Let me know whether we should pursue this.  Thanks.

Fuhwei

kelvin goodson <[EMAIL PROTECTED]> wrote: This release is running later than I 
had hoped due to extra jiras being
added to the plan, and a few issues that have come up after recent fixe, so
we are a bit behind where I'd proposed we should be in terms of getting this
release out.  Please help with some of these TODOs if you can.  If you plan
to tackle anything please post here so that we don't overlap;  I'll do the
same.

these are the things that I think are "must-fix"

1143 -- the issues re test failures are being resolved   -- david's working
on this
1429 -- i've looked at this and it is fine apart from the casting to
HelperContextImpls -- i put a note on the jira,
1428 -- note appended to jira asking for code to exercise/demonstrate the
fix

other issues raised on the list

the pom has a "provided scope" dependency on stax  -- I will fix this as per
my note to tuscany-dev
use rat results to fix license header issues and post rat results
check that all recent fixes in the trunk since the branch was made have
equivalent fixes in the branch

the following have been raised by comments on RC1

NOTICE files (create separate ones for impl and bin and ensure no disclaimer
contained)
need to update release notes with descriptive para and fixed jiras
need to remove dependencies on snapshot plugins (rfeng 13/7)
should remove EPL license from src distro
add stax reference in bin distro license
add readme to bin distro samples folder
fix up runsamples scripts to be more robust/helpful and ensure that the
runsamples.sh script runs ok in a linux env
fix up bad javadoc links in samples index.html
exclude samples infrastructure classes from samples javadoc
fix link back to tuscany site from overview.html to point to the get
involved page
incorporate Haleh's suggested paragraph [1] into overview.html

and some of my own todos that I hope to get to
ensure consistency of each sample program's javadoc to point back to central
instructions for running samples
put an overview doc into the sdo lib project's javadoc
add the change summary aspects of the medical scenario sample


====================================================

[1]
b) You could remove the first sentence since it does not really make sense.
How about .. Apache Tuscany SDO Samples are provided here to help users
learn SDO.'index by SDO subproject ' lists the different samples available
to you. These samples provide a starting point for learning SDO and can be
extended and enhanced to experiment with other available SDO features.
Please help us enhance these samples by sending your feedback to Tuscany
mailing list or join us and contribute to this project .

Reply via email to