From 6cb4dc4f237ea2669917769fea2cb84e937ebc1a Mon Sep 17 00:00:00 2001
From: rkv <rkv@opencascade.com>
Date: Tue, 30 Oct 2012 07:20:28 +0000
Subject: [PATCH] Unused files are removed.

---
 Workspace/Siman/src/simer.properties |  12 --
 Workspace/Siman/src/som.xml          | 245 ---------------------------
 2 files changed, 257 deletions(-)
 delete mode 100644 Workspace/Siman/src/simer.properties
 delete mode 100644 Workspace/Siman/src/som.xml

diff --git a/Workspace/Siman/src/simer.properties b/Workspace/Siman/src/simer.properties
deleted file mode 100644
index 8f8e78a..0000000
--- a/Workspace/Siman/src/simer.properties
+++ /dev/null
@@ -1,12 +0,0 @@
-schema.version     = D-0.3
-
-wapp.version       = D-0.5
-wapp.root          = D:/users/rkv/SIMAN/SIMAN_SRC/Workspace/Siman/WebContent/
-wapp.login         = conf/login.conf
-wapp.configuration = conf/som.xml
-wapp.customization = conf/my.xml
-wapp.website       = http://www.salome-platform.org
-wapp.onlinehelp    = http://docs.salome-platform.org/salome_6_3_1/gui/GUI_index.html
-wapp.context       = repository
-
-locale.supported   = fr,en
\ No newline at end of file
diff --git a/Workspace/Siman/src/som.xml b/Workspace/Siman/src/som.xml
deleted file mode 100644
index 62f68b7..0000000
--- a/Workspace/Siman/src/som.xml
+++ /dev/null
@@ -1,245 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-
-<project-structure>
-
-
-<!-- 1. Database physical location
-     The database includes an SQL base containing the studies and the document metadata, a Lucene index used for searching studies and
-     knowledges, a file vault including all actual data and a directory where files uploaded and downloaded by users are temporarily saved.
-     All these information are located in sub-directories of a common root directory defined below.
-     This directory must be visible from the server application (Tomcat).
-     -->
-    <database>
-        <repository disk="D:/users/rkv/SALOME_SIMER/rep" />
-    </database>
-
-
-<!-- 2. Formats
-     -->
-    <formats>
-
-<!-- 2.1 Project elements identification scheme
-     Studies, Knowledges and Documents are identified by unique user references. The structure of these references is customizable.
-     You customize references through patterns.
-     A reference's pattern is a character string including format directives. These format directives allow you to insert
-     some information into the reference. The following directives are available:
-     - %yy or %yyyy for inserting the entity creation year on 2 or 4 digits
-     - %0000 for inserting a unique index, the number of digits being defined by the number of 0
-     The above index is unique in the scope of cycle defined by the first format directive (year). In other words, this index
-     restarts every new year. As such, for making references unique on this application server, both format directives (cycle
-     and index) must be present in the pattern.
-     Other characters are simply inserted as is in generated references. They can be used for extending the reference uniqueness
-     beyond application servers, by adding a prefix specific to a given server (for example, a company department name).
-     Given that these references may be used as directory or file names of the repository vault, the pattern must not include
-     illicit characters such as '/', '?', '<', '>' etc.
-     -->
-        <references  study="DER%yy%0000"/>
-
-<!-- 2.2 Physical files naming scheme
-     The physical data files stored into the repository vault can be named as follows:
-     - By the user-defined title of corresponding documents ("title" name attribute below)
-     - Encoded by a built-in scheme ("encoded" name attribute)
-     - As is, that is, by keeping the name of the imported file ("asis" name attribute - not yet supported)
-     Remarks:
-     - When using the title scheme, as file names may include accent characters, client browsers must be configured for
-       NOT encoding URLs as UTF-8.
-     - Whatever is the naming scheme used, in order to avoid name clashes, file names are anyway suffixed by an index
-       unique in the scope of the owner study.
-     -->
-        <files name="encoded"/>
-
-<!-- 2.3 Document versions format
-     Defines the format in which version numbers are presented to users.
-     A version number includes a major, a minor and a branch number, when exist.
-     -->
-        <versions pattern="%M.%m[-%s]"/>
-    </formats>
-
-
-<!-- 3. Study step types
-     The user activities involved in studies are defined by study step types. The tag below simply lists all possible steps
-     applicable in a workflow.
-     Step types are defined by type names used in the API for accessing to study activities.
-     The document data produced during these activities are saved into the repository vault. They can be structured in
-     sub-directories of each study root directory. As such, the definition of study step types includes the path of the
-     corresponding sub-directory.
-     The list below does not define the order of steps - this order is specified by the workflow. The steps are listed in
-     an order defining the internal index of steps. These index are used for localizing the activity names and corresponding
-     folder names.
-     
-     Remark:
-     - "scenario" is a reserved type name.
-     -->
-    <steps>
-        <article type="specification"  path="1.Study"/>
-        <article type="design"         path="1.Study"/>
-        <article type="modeling"       path="2.Geometry"/>
-        <article type="meshing"        path="3.Mesh"/>
-        <article type="preprocessing"  path="4.Load"/>
-        <article type="solving"        path="5.Result"/>
-        <article type="postprocessing" path="6.Analysis"/>
-        <article type="capitalization" path="7.Knowledge"/>
-        <article type="reporting"      path="1.Study"/>
-    </steps>
-
-
-<!-- 4. Document types
-     All documents under the control of the Study Manager are typed. The tag below simply lists all possible document types
-     involved in a workflow.
-     Document types are defined by type names used in the API for manipulating document types. These type names are also used
-     for localizing document types.
-     The documents have dependencies in accordance to their type. As such, the definition of each document type include the
-     potential dependencies of corresponding documents.
-     
-     Warning: Articles must be ordered in a way that dependent document types (uses attribute values) must previously be defined.
-     Example: "requirements" type must be defined before "specification" because "specification" uses "requirements".
-     Remarks:
-     - The dependencies are transitive (if document A depends on document B, itself depending on C, A implicitly depends on C).
-     - "knowledge" is a reserved word qualifying Knowledge Elements. So, it must not be used as a document type name.
-     - "default" and "built-in" are also reserved words used for defining validation cycles.
-     - In this version, the "uses" attribute is limited to 1 document type only.
-     -->
-    <documents>
-        <article type="requirements"/>
-        <article type="specification" uses="requirements"/>
-        <article type="design"        uses="specification"/>
-        <article type="geometry"      uses="design"/>
-        <article type="model"         uses="geometry"/>
-        <article type="loads"         uses="model"/>
-        <article type="script"        uses="loads"/>
-        <article type="log"           uses="script"/>
-        <article type="results"       uses="script"/>
-        <article type="report"        uses="results"/>
-        <article type="memorandum"/>
-        <article type="minutes"/>
-    </documents>
-
-
-<!-- 5. Simulation Context types
-     As documents, the simulation contexts are typed. The tag below simply lists the simulation context types available initially,
-     after the installation of the product. These types can then be extended on the fly by end-users when assigning simulation
-     contexts to studies.
-     Simulation context types are defined by type names used in the API for manipulating simulation contexts. These type names
-     are also used for localizing simulation contexts types.
-     
-     Warning: The Simulation Context type "product" is mandatory as it is used when creating a study.
-     -->
-    <contexts>
-
-    <!-- General information -->
-        <article type="customer"/>
-        <article type="product"/>
-        <article type="phase"/>            <!-- Phase of the product                                 -->
-        <article type="need"/>             <!-- Customer needs                                       -->
-        <article type="purpose"/>          <!-- Objective of the study                               -->
-        <article type="physic"/>           <!-- Structure analysis, Thermal-hydraulics, Neutronic... -->
-
-    <!-- Geometry characteristics               Examples:                 -->
-        <article type="object"/>           <!-- Car, Plane, Equipment...  -->
-        <article type="part"/>             <!-- Crankcase, Outer layer... -->
-        <artivle type="geometry"/>         <!-- Surface, Volume           -->
-
-    <!-- Model characteristics                  Examples:            -->
-        <article type="model"/>            <!-- CSG, FEM...          -->
-        <article type="element"/>          <!-- Bar, Surface, Volume -->
-        <article type="shape"/>            <!-- (Surface) Triangle, Quadrangle... (Volume) Tetrahedron, Hexahedron... -->
-        <article type="order"/>            <!-- First-order, Second-order... -->
-
-    <!-- Analysis type                          Examples:          -->
-        <article type="analysis"/>         <!-- Static, Dynamic... -->
-
-    <!-- Software tools used -->
-        <article type="platform"/>
-        <article type="module"/>
-        <article type="component"/>
-    </contexts>
-
-
-<!-- 6. Knowledge Elements types
-     As documents and simulation contexts, the knowledges are typed. The tag below lists these knowledge types.
-     Knowledge types are simply defined by type names used in the API for manipulating knowledge types. These type names
-     are also used for localizing knowledge types.
-     
-     Warning: The Knowledge Elements type "usecase" is reserved for internal use.
-     -->
-    <knowledges>
-        <article type="bestpractice"/>
-        <article type="limitation"/>
-        <article type="inconsistency"/>
-        <article type="metrics"/>
-        <article type="improvement"/>
-    </knowledges>
-
-
-<!-- 7. User activities
-
-     Remarks:
-     - Step names must naturally be unique.
-     - Simulation Contexts must be attached to one classification step only.
-     - Result document types must be results of one step only and be part of contents of the corresponding step.
-     -->
-    <activities>
-        <step name="specification">
-            <classification context="customer,product,phase,need,purpose,physic"/>
-            <flow contents="requirements,specification,minutes" result="specification"/>
-            <storage path="1.Study"/>
-        </step>
-      <scenario>
-        <step name="design">
-            <flow contents="design,memorandum,minutes" result="design"/>
-            <storage path="1.Study"/>
-        </step>
-        <step name="modeling">
-            <classification context="object,part,geometry"/>
-            <flow contents="geometry,memorandum,minutes" result="geometry"/>
-            <storage path="2.Geometry"/>
-   	    </step>
-        <step name="meshing">
-            <classification context="model,element,shape,order"/>
-            <flow contents="model,memorandum,minutes" result="model"/>
-            <storage path="3.Mesh"/>
-        </step>
-        <step name="preprocessing">
-            <classification context="analysis"/>
-            <flow contents="loads,script,minutes" result="loads"/>
-            <storage path="4.Analysis"/>
-        </step>
-        <step name="solving">
-            <classification context="platform,module,component"/>
-            <flow contents="log,results,minutes" result="results"/>
-            <storage path="5.Result"/>
-        </step>
-        <step name="postprocessing">
-            <flow contents="memorandum,minutes"/>
-            <storage path="6.Report"/>
-        </step>
-        <step name="capitalization">
-            <flow contents="knowledge"/>
-            <storage path="6.Report"/>
-        </step>
-      </scenario>
-        <step name="reporting">
-            <flow contents="report,minutes" result="report"/>
-            <storage path="1.Study"/>
-        </step>
-    </activities>
-
-
-<!-- 8. Document validation cycles
-     Validation cycles define the actors involved in the validation steps of documents. These steps can be
-     "review", "approval" and "acceptance".
-     Remarks:
-     - Each validation cycle is defined by a tag corresponding to the type of an activity result document.
-     - The actors of validation steps can be
-       "manager", referring the responsible of study,
-       "Nx1", referring the manager of the department (see User definition for more information),
-       "Nx2", referring the boss of the department manager,
-       "customer" (most likely involved in the acceptance step).
-     -->
-    <validations>
-        <specification  review="Nx1"  approval="Nx2"/>
-        <report         review="Nx1"  approval="Nx2"/>
-        <default        review="manager"            />
-    </validations>
-
-</project-structure>
\ No newline at end of file
-- 
2.39.2