| RE: [corona-dev] ProjectContainer Definition |
|
Dennis, You wrote that from the project container
perspective among the repository elements configuration attributes are needed. Question regarding that: Should the project/generic container model
contain full specification of repositories’ configuration like it is now
done inside generic repository model:
<xs:complexType name="repository-configuration">
<xs:sequence>
<xs:element name="repository-connection-parameters" type="rep:repository-connection-parameter" maxOccurs="unbounded"/>
<xs:element name="resource-subsets" type="rep:resource-subset" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="repository-connection-parameter">
<xs:attribute name="name" type="xs:anyURI" use="required"/>
<xs:attribute name="value" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="resource-subset">
<xs:attribute name="type" type="xs:anyURI" use="required"/>
<xs:attribute name="selection-criteria" type="xs:string" use="required"/>
</xs:complexType> If this part of repository model is to be
attached to generic container model then we don’t need anymore separate repository
model – all repository information will be included inside container
model. Other approach could be adding to
container model repository configuration name – while detailed
configuration would be included only inside repository model. Let’s decide if we want/need separate
model for repositories – when most of repository data will be stored also
in container model – what do you think? Edyta From:
corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of O'Flynn, Dennis I realize that we are planning to use
EMF/SDO for persisting the container data. Consequently much of this code
can be genereated. However, we are at the point were we need to have some
interfaces defined to allow others to code against the container
framework. Is there a way to provide some isloation between the producer
(generated code) of the container model and the consumer of that model. I guess what I'm asking for is the set of interfaces for
ProectContainerFactory, IProjectContainer, IRepository etc... From:
corona-dev-bounces@xxxxxxxxxxx on behalf of Kalka, Edyta Regarding the requested API please notice
that we are going to use generated SDO model code. This results in a bit less
flexibility regarding class and method names. We can wrapped some of generated classes
(such as generated ProjectFactoryImpl) but we wont have methods like
findRepository by name in the ProjectContextContainer class generated by
EMF/SDO framework. Edyta From:
corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of O'Flynn, Dennis Edyta, I’m approaching this email thread
from a ProjectContainer perspective, which does include the generic container
framework. From the ProjectContainer perspective, I believe the following
repository elements are needed:
Where these elements are part of the
ProjectContainer or GenericContainer is up to you and Glenn. I would
assume that these elements would be needed by most all container contexts, so I
guess they would belong to the GenericContainer. If these elements
are part of a GenericContainer, we could also provide a generic UI view to
display these elements in a read-only table. The following is a code example accessing
a ProjectContainer and one of its repositories. (class names are
subject to change) IProjectContainer pc = ProjectContainerFactory.create( <name>
); IRepository repo = pc.findRepository( <name> ); String name = repo.getName(); URI uri = repo.getURI(); IRepositoryConfiguration repoConfig = repo.configuraiton();
// optional config data From:
corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of Kalka, Edyta The repository definition from
Dennis’s answer comes from generic repository schema. In generic container schema repositories
references looks as follows: <xs:element name="repositories" type="con:repositories" minOccurs="0" maxOccurs="1"/> <xs:complexType name="repository"> <xs:attribute name="uri" type="xs:anyURI" use="required"/>
<xs:attribute name="type" type="xs:anyURI" use="required"/> </xs:complexType> From this answer I understood
that repository type attribute in generic container model is unnecessary and
should be only needed in project container model – is that right ? Edyta From:
corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of O'Flynn, Dennis Edyta – Thanks for the details re:
generic container. This will be helpful. I would like to emphasis a key point
– “repositories”. The generic container allows for the
definition of repositories. Each repository has is defined as: <xs:complexType name="repository"> <xs:sequence>
<xs:element
name="repository-uri"
type="rep:repository-uri"/> <xs:element
name="repository-type"
type="xs:anyURI"/> <xs:element
name="repository-description"
type="xs:string"/> <xs:element
name="repository-configurations"
type="rep:repository-configuration"
maxOccurs="unbounded"/> <xs:element
name="relationship-resource-set"
type="rep:relationship-file"
minOccurs="0"
maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="name" type="xs:string" use="required"/> <xs:attribute name="repository-configuration" type="xs:string" use="required"/> </xs:complexType> The ProjectContainer defines the context
for the generic container. This also includes the definition of each
repository “type”. The “type” of repository will
have meaning for the ProjectContainer context. However, it may have no
meaning for other implementations of a generic container. From:
corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of Kalka, Edyta I will describe how looks generic and
project context container definition now: Schema describing generic container is as
follows: <?xml
version="1.0" encoding="UTF-8"?> <!--W3C Schema generated by
XMLSpy v2006 rel. 3 U (http://www.altova.com)--> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" xmlns:con="http://www.eclipse.org/corona/server/container" targetNamespace="http://www.eclipse.org/corona/server/container">
<xs:complexType name="context-container">
<xs:sequence>
<xs:element name="container-uri" type="xs:anyURI" minOccurs="0"/>
<xs:element name="container-path" type="con:container-path-element" maxOccurs="1" minOccurs="0"/>
<xs:element name="container-type" type="xs:anyURI" minOccurs="0"/>
<xs:element name="container-description" type="xs:string" minOccurs="0"/>
<xs:element name="repositories" type="con:repositories" minOccurs="0" maxOccurs="1"/>
<xs:element name="subcontainers" type="con:subcontainers" minOccurs="0" maxOccurs="1"/>
<xs:element name="container-properties" type="con:container-properties" minOccurs="0" maxOccurs="1"/>
<xs:element name="relationship-resource-set" type="con:relationship-resource-set" minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="relationship-resource-set">
<xs:sequence>
<xs:element name="relationship-file" type="con:relationship-file" maxOccurs="unbounded" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="relationship-file">
<xs:attribute name="type" type="xs:string" use="required"/>
<xs:attribute name="version" type="xs:string" use="required"/>
<xs:attribute name="uri" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="repositories">
<xs:sequence>
<xs:element name="repository" type="con:repository" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="repository">
<xs:attribute name="uri" type="xs:anyURI" use="required"/>
<xs:attribute name="type" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="container-properties">
<xs:sequence>
<xs:element name="container-property" type="con:container-property" maxOccurs="unbounded" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="container-property">
<xs:attribute name="name" type="xs:string" use="required"/>
<xs:attribute name="value" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="container-path-element">
<xs:sequence>
<xs:element name="container-path-element" type="xs:anyURI" maxOccurs="unbounded" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="subcontainers">
<xs:sequence>
<xs:element name="context-container" type="con:context-container" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:schema> Thus, for now generic container
context includes: -
its
identifier -
type -
path
– which is location in the containers’ tree starting from the root -
description -
list
of repositories’ references -
list
of subcontainers -
list
of container properties -
list
of RDF files containing resource relationships – this is feature provided
by Glenn and I would ask him for an example of its usage – I don’t
have enough information on this subject. Such container properties
like id, type, path is presented in form of URI. If at any point we want to use
RDF such URI approach would be useful. Form of
URI is open issue. For now I used the following: -
sample
container uri: http://www.eclipse.org/corona/server/container/sampleEclipseProject -
sample
container type: http://www.eclipse.org/corona/server/containerTypes/eclipseProject etc. -
We can
extend this with version information like http://www.eclipse.org/corona/server/container/sampleEclipseProject#00.00.01 Should
we stay with such URI form or not? Any
other comments? SDO model code generated
on the basis of such schema includes ContextContainer interface (representing
data graph root object) in a form: public interface ContextContainer {
String getContainerUri();
void setContainerUri(String value);
ContainerPathElement getContainerPath();
void setContainerPath(ContainerPathElement value);
String getContainerType();
void setContainerType(String value);
String getContainerDescription();
void setContainerDescription(String value);
Repositories getRepositories();
void setRepositories(Repositories value);
Subcontainers getSubcontainers();
void setSubcontainers(Subcontainers value);
ContainerProperties getContainerProperties();
void setContainerProperties(ContainerProperties value);
RelationshipResourceSet getRelationshipResourceSet();
void setRelationshipResourceSet(RelationshipResourceSet value); } // ContextContainer ++++++++++++++++++++++++++++++++ Project
context container is to extend generic context container. In other words it is
our sample specialization of generic container. However on the server
side during new container model registration – container manager will
expect implementation of generic ContextContainer interface. For new container model
registration container manager will need information such as id, type, path
– this container data has to be set and for this reason it is placed in
generic model. In specialized container
model like Project context container we can add any additional information
required by modules specific for given system set over corona. For now project context
container schema simply extends generic container: <?xml
version="1.0" encoding="UTF-8"?> <!--W3C Schema generated by XMLSpy
v2006 rel. 3 U (http://www.altova.com)--> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" xmlns:con="http://www.eclipse.org/corona/server/container" xmlns:pcon="http://www.eclipse.org/corona/server/container/project" targetNamespace="http://www.eclipse.org/corona/server/container/project">
<xs:import namespace="http://www.eclipse.org/corona/server/container" schemaLocation="./GenericContainer.xsd"/>
<xs:complexType name="project-context-container">
<xs:complexContent>
<xs:extension base="con:context-container">
<xs:sequence>
<!—here can be placed any additional information specific for project
container e.g.” icon“ used by client ui à
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType> </xs:schema> SDO model code generated
on the basis of such schema includes ProjectContextContainer interface
(representing data graph root object) in a form: public interface ProjectContextContainer extends ContextContainer { } // ProjectContextContainer Few questions on project context container model
definition (once asked but with no feedback): Do we want to overwrite
generic properties like container identifiers inside project container by
adding to its schema: <xs:element
name="project-container-uri"
type="pcon:project-container-uri"/> <xs:simpleType
name="project-container-uri">
<xs:restriction base="xs:anyURI">
<xs:pattern value="http://www.eclipse.org/corona/server/container/\w*"/>
</xs:restriction> </xs:simpleType> ? From one side: this would give us a method for setting some kind of
restrictions over identifier expected form. But from the other side: notice that corona container manager expects
ContextContainer instance and understands its generic properties. Such container manager has no knowledge on specific container
extensions added by any new system build over corona. In this case we would
need a mechanism for mapping specific container properties to generic container
properties – in our example it would be pointing that
project-container-uri represents container-uri from generic container schema. This could be done: if for instance some extension point would be set
for new container registration with a set of arguments allowing for mapping
required generic container properties to specific ones. The question here is if we really
need something like this? Any feedback/comment very welcome! +++++++++++++++++++++++++++++++++++ So far I described containers models. Now we have repositories models
used for defining any needed container repository such as: team member
repository (being xml repository for now), cvs repository, bugzilla repository,
relational database repository etc. Such repositories’ identifiers are
used as references inside container definitions. Current schema describing generic repository looks as follows: <?xml
version="1.0" encoding="UTF-8"?> <!--W3C Schema generated by
XMLSpy v2006 rel. 3 U (http://www.altova.com)--> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" xmlns:rep="http://www.eclipse.org/corona/server/repository" targetNamespace="http://www.eclipse.org/corona/server/repository">
<xs:complexType name="repository">
<xs:sequence>
<xs:element name="repository-uri" type="rep:repository-uri"/>
<xs:element name="repository-type" type="xs:anyURI"/>
<xs:element name="repository-description" type="xs:string"/>
<xs:element name="repository-configurations" type="rep:repository-configuration" maxOccurs="unbounded"/>
<xs:element name="relationship-resource-set" type="rep:relationship-file" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="required"/>
<xs:attribute name="repository-configuration" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="repository-uri">
<xs:choice>
<xs:element name="repository-uri-element" type="xs:anyURI"/>
<xs:element name="repository-uri-reference" type="rep:repository-uri-reference"/>
</xs:choice>
</xs:complexType>
<xs:complexType name="repository-uri-reference">
<xs:attribute name="xpath-element-ref" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="relationship-file">
<xs:attribute name="type" type="xs:string" use="required"/>
<xs:attribute name="version" type="xs:string" use="required"/>
<xs:attribute name="uri" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="repository-configuration">
<xs:sequence>
<xs:element name="repository-connection-parameters" type="rep:repository-connection-parameter" maxOccurs="unbounded"/>
<xs:element name="resource-subsets" type="rep:resource-subset" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="repository-connection-parameter">
<xs:attribute name="name" type="xs:anyURI" use="required"/>
<xs:attribute name="value" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="resource-subset">
<xs:attribute name="type" type="xs:anyURI" use="required"/>
<xs:attribute name="selection-criteria" type="xs:string" use="required"/>
</xs:complexType> </xs:schema> Properties like uri, type, description
have role similar like in case of containers. Property repository-configurations
contains connection parameters and resource data
subsets definition (if we don’t want to retrieve the whole content of
given data source e.g. we want to retrieve data only from one table of some
database). Sample definition for team member
repository of repository configurations could look like this: <repository-configuration name="members_1">
<repository-connection-parameters>
<repository-connection-parameter name="fileURI" value="file://c:/org.eclipse.corona/user/coronausers.xml" />
</repository-connection-parameters>
<resource-subsets>
<resource-subset>
<resource type="http://www.eclipse.org/corona/resourceSubsetTypes/XPathResultSet" selection-critera="teammembers/member"/>
</resource-subset>
</resource-subsets> </repository-configuration>
<repository-configuration name="members_2">
<repository-connection-parameters>
<repository-connection-parameter name="fileURI" value="file://c:/org.eclipse.corona/user/coronausers2.xml" />
</repository-connection-parameters>
<resource-subsets>
<resource-subset>
<resource type="http://www.eclipse.org/corona/resourceSubsetTypes/XPathResultSet" selection-criteria="//member" />
</resource-subset>
</resource-subsets> </repository-configuration> </repository-configurations> //We can define multiple
configurations inside one repository definition and point which one should be
currently use by setting its name to repository-configuration attribute of
repository root //element. Our specialized repository model like team
member repository etc. extends generic repository. We can add inside these models anything specific
or we could overwrite generic properties like repository-configuration e.g.: <xs:element name="team-repository-configurations" type="trep:team-repository-configuration" maxOccurs="unbounded"/> <xs:complexType name="team-repository-configuration">
<xs:sequence>
<xs:element name="team-repository-connection-parameters" type="trep:team-repository-connection-parameter" maxOccurs="unbounded"/>
<xs:element name="team-resource-subsets" type="trep:team-resource-subset" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="required"/> </xs:complexType>
<xs:complexType name="team-repository-connection-parameter">
<xs:attribute name="name" type="trep:connection-parameter-type" use="required"/>
<xs:attribute name="value" type="xs:string" use="required"/> </xs:complexType> <xs:simpleType name="connection-parameter-type">
<xs:restriction base="xs:anyURI">
<xs:enumeration value="http://www.eclipse.org/corona/server/connectionParameter/fileURI"/>
<xs:enumeration value="http://www.eclipse.org/corona/server/connectionParameter/fileLocation"/>
</xs:restriction> </xs:simpleType> <xs:complexType name="team-resource-subset">
<xs:attribute name="type" type="trep:resource-subset-type" use="required"/>
<xs:attribute name="selection-criteria" type="xs:string" use="required"/> </xs:complexType> <xs:simpleType name="resource-subset-type">
<xs:restriction base="xs:anyURI">
<xs:enumeration value="http://www.eclipse.org/corona/server/resourceSubsetTypes/XPathResultSet"/>
</xs:restriction> </xs:simpleType> But in case of overwriting generic
properties we would need similar as in case of containers mapping mechanism
between generic and specialized properties. Similarly as in case of containers –
sdo repository model code includes GenericRepository interface (in case of
generic model) and TeamRepository interface (specialized repository model)
(interfaces representing data graph root objects). ++++++++++++++++++++++++++++++++++++++ Regarding the question asked during the
conference how to access model data – check some shorten code showing
idea how to serialize, deserialize and access to container/repository data: To load sdo model we need: // register factory model protected ExtendedMetaData registerModel() {
ProjectPackageImpl.eINSTANCE.getName();
resourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap().put("xml", new ProjectFactoryImpl());
return new
BasicExtendedMetaData(resourceSet.getPackageRegistry());
} //load data
graph protected final void load(HashMap loadOptions) throws Exception {
resourceSet.getResources().clear();
dataGraph = SDOUtil.loadDataGraph(dgByteInputStream, loadOptions);
dgByteInputStream.reset();
} To access model
root object like our ContextContainer instance or ProjectContextContainer
instance: ProjectContextContainer
root = (ProjectContextContainer)dataGraph.getRootObject(); To save sdo
model: resource = ((EDataGraph)dataGraph).getDataGraphResource(); resource.save(outputStream, options); outputStream.close(); ++++++++++++++++++++++++++++++++++++++ I concentrated on the static sdo models
because: – for now I don’t see
reason for using dynamic ones - static models looks better in terms of
performation (see: http://www-128.ibm.com/developerworks/webservices/library/ws-bestjdbc2/) +++++++++++++++++++++++++++++++++++++++++++++++++ Open issues: -
is this approach for
container/repository modeling ok? -
what about URI form? -
what about overwriting generic
properties with properties from specialized models – do we need that? If
yes – what mapping mechanism to use etc.? -
what approach should be taken
for enabling interface for new container/repository model registration (e.g.
extension point usage) ? -
can you see any specific
properties for our specialized models not taken into account so far? -
The same for generic properties
– what should be added to generic models? Sorry for long description but I was
trying to explain how these issues looks now and on what issues I have no
feedback. Best regards Edyta From:
corona-dev-bounces@xxxxxxxxxxx [mailto:corona-dev-bounces@xxxxxxxxxxx] On Behalf Of O'Flynn, Dennis The following is a draft definition of a
ProjectContainer. Please reply to this email thread to update this
definition. What is a ProjectContainer? A ProjectContainer is an exemplary implementation What is in a ProjectContainer?
The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it. The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it. The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the named addressee
or an authorized designee, you may not copy or use it, or disclose it to anyone
else. If you received it in error please notify us immediately and then destroy
it. The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it. The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it. The contents of this e-mail are intended for the named addressee only.
It contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose it
to anyone else. If you received it in error please notify us immediately and
then destroy it. |