Skip to main content
summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorEike Stepper2011-09-20 09:47:26 +0000
committerEike Stepper2011-09-20 09:47:26 +0000
commit0c89905307ebf59a7bf3597d07e809e43187644f (patch)
treedfe63afa70a00a7d88513e4a3084348ad004b3c8
parent7867093f33b6c90a6393b0bc09b2fc3f4905df4d (diff)
downloadcdo-0c89905307ebf59a7bf3597d07e809e43187644f.tar.gz
cdo-0c89905307ebf59a7bf3597d07e809e43187644f.tar.xz
cdo-0c89905307ebf59a7bf3597d07e809e43187644f.zip
overview
-rw-r--r--plugins/org.eclipse.emf.cdo.doc/diagrams.pptxbin0 -> 54410 bytes
-rw-r--r--plugins/org.eclipse.emf.cdo.doc/html/Overview.html112
-rw-r--r--plugins/org.eclipse.emf.cdo.doc/html/application-architecture.pngbin0 -> 37720 bytes
-rw-r--r--plugins/org.eclipse.emf.cdo.doc/html/repository-architecture.pngbin0 -> 42586 bytes
-rw-r--r--plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/Overview.java124
-rw-r--r--plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/application-architecture.pngbin0 -> 37720 bytes
-rw-r--r--plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/repository-architecture.pngbin0 -> 42586 bytes
-rw-r--r--plugins/org.eclipse.emf.cdo.releng.doc/model/article.ecorediag2
-rw-r--r--plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/CategoryImpl.java14
-rw-r--r--plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/DocumentationImpl.java9
-rw-r--r--plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/StructuralElementImpl.java16
11 files changed, 251 insertions, 26 deletions
diff --git a/plugins/org.eclipse.emf.cdo.doc/diagrams.pptx b/plugins/org.eclipse.emf.cdo.doc/diagrams.pptx
new file mode 100644
index 0000000000..148db250d9
--- /dev/null
+++ b/plugins/org.eclipse.emf.cdo.doc/diagrams.pptx
Binary files differ
diff --git a/plugins/org.eclipse.emf.cdo.doc/html/Overview.html b/plugins/org.eclipse.emf.cdo.doc/html/Overview.html
index 291e2b7745..fd60c9bfe1 100644
--- a/plugins/org.eclipse.emf.cdo.doc/html/Overview.html
+++ b/plugins/org.eclipse.emf.cdo.doc/html/Overview.html
@@ -23,19 +23,109 @@ function windowTitle()
<BODY BGCOLOR="white" onload="windowTitle();">
<h1><a name="Overview.html"/>Overview</h1>
<p>
+ CDO is a pure Java <i>model repository</i> for your EMF models and meta models (refer to <a href="Overview.html#Application" title="Chapter in CDO Model Repository Documentation">application architecture</a> for details). CDO can also serve as a <i>persistence and distribution framework</i> for
+ your EMF based application systems. For the sake of this overview a model can be regarded as a graph of application
+ or business objects and a meta model as a set of classifiers that describe the structure of and the possible
+ relations between these objects.
<p>
-<table border="0">
-<tr><td><img src="../images/article.gif"/>&nbsp;&nbsp;</td><td colspan="4"><a href="" title="Article in CDO Model Repository Documentation">Overview</a></td></tr>
-<tr><td><img src="../images/category.gif"/>&nbsp;&nbsp;</td><td colspan="4"><a href="reference/index.html" title="Category in CDO Model Repository Documentation">Reference</a></td></tr>
-<tr><td/><td><img src="../images/category.gif"/>&nbsp;&nbsp;</td><td colspan="3"><a href="reference/api/index.html" title="Category in CDO Model Repository Documentation">API Reference</a></td></tr>
-<tr><td/><td><img src="../images/category.gif"/>&nbsp;&nbsp;</td><td colspan="3"><a href="reference/schema/index.html" title="Category in CDO Model Repository Documentation">Extension Point Reference</a></td></tr>
-<tr><td><img src="../images/category.gif"/>&nbsp;&nbsp;</td><td colspan="4"><a href="online/index.html" title="Category in CDO Model Repository Documentation">Online Docs</a></td></tr>
-<tr><td/><td><img src="../images/article.gif"/>&nbsp;&nbsp;</td><td colspan="3"><a href="http://www.eclipse.org/cdo" title="Article in CDO Model Repository Documentation">Homepage</a></td></tr>
-<tr><td/><td><img src="../images/article.gif"/>&nbsp;&nbsp;</td><td colspan="3"><a href="http://wiki.eclipse.org/CDO" title="Article in CDO Model Repository Documentation">Wiki</a></td></tr>
-<tr><td><img src="../images/article.gif"/>&nbsp;&nbsp;</td><td colspan="4"><a href="about.html" title="Article in CDO Model Repository Documentation">Legal</a></td></tr>
-</table>
-</p>
+<h2><a name="Functionality"/>1&nbsp;&nbsp;Functionality</h2>
+<p>
+ The main functionality of CDO can be summarized as follows:
+ <ul>
+ <li><b>Persistence</b> of your models in all kinds of database backends like major relational databases or NoSQL
+ databases. CDO keeps your application code free of vendor specific data access code and eases transitions between
+ the supported backend types.
+ <p>
+ <li><b>Multi user access</b> to your models is supported through the notion of repository sessions. The physical
+ transport of sessions is pluggable and repositories can be configured to require secure authentication of users.
+ Various authorization policies can be established programmatically.
+ <p>
+ <li><b>Transactional access</b> to your models with ACID properties is provided by optimistic and/or pessimistic
+ locking on a per object granule. Transactions support multiple savepoints that changes can be rolled back to.
+ Pessimistic locks can be acquired separately for read access, write access and the option to reserve write access
+ in the future. All kinds of locks can optionally be turned into long lasting locks that survive repository
+ restarts. Transactional modification of models in multiple repositories is provided through the notion of XA
+ transactions with a two phase commit protocol.
+ <p>
+ <li><b>Transparent temporality</b> is available through audit views, a special kind of read only transactions that
+ provide you with a consistent model object graph exactly in the state it has been at a point in the past. Depending
+ on the chosen backend type the storage of the audit data can lead to considerable increase of database sizes in
+ time. Therefore it can be configured per repository.
+ <p>
+ <li><b>Parallel evolution</b> of the object graph stored in a repository through the concept of branches similar to
+ source code management systems like Subversion or Git. Comparisons or merges between any two branch points are
+ supported through sophisticated APIs, as well as the reconstruction of committed change sets or old states of
+ single objects.
+ <p>
+ <li><b>Scalability</b>, the ability to store and access models of arbitrary size, is transparently achieved by
+ loading single objects on demand and caching them <i>softly</i> in your application. That implies that objects that
+ are no longer referenced by the application are automatically garbage collected when memory contention occurs. Lazy
+ loading is accompanied by various prefetching strategies, including the monitoring of the object graph's
+ <i>usage</i> and calculation of fetch rules that are optimal for the current usage patterns. The scalability of EMF
+ applications can be further increased by leveraging CDO constructs such as remote cross referencing or optimized
+ content adapters.
+ <p>
+ <li><b>Thread safety</b> ensures that multiple threads of your application can access and modify the object graph
+ without worrying about the synchronization details. This is possible and cheap because multiple transactions can be
+ opened from within a single session and they all share the same object data until one of them modifies the graph.
+ Possible commit conflicts can be handled in the same way as if they were conflicts between different sessions.
+ <p>
+ <li><b>Collaboration</b> on models with CDO is a snap because an application can opt in to be notified about remote
+ changes to the object graph. By default your local object graph transparently changes when it has changed remotely.
+ With configurable change subscription policies you can fine tune the characteristics of your <i>distributed shared
+ model</i> so that all users enjoy the impression to collaborate on a single instance of an object graph. The level
+ of collaboration can be further increased by plugging custom collaboration handlers into the asynchronous CDO
+ protocol.
+ <p>
+ <li><b>Data integrity</b> can be ensured by enabling optional commit checks in the repository server such as
+ referential integrity checks and containment cycle checks, as well as custom checks implemented by write access
+ handlers.
+ <p>
+ <li><b>Fault tolerance</b> on multiple levels, namely the setup of fail-over clusters of replicating repositories
+ under the control of fail-over monitors, as well as the usage of anumber of special kinds of session such as
+ fail-over or reconnecting sessions that allow applications to hold on their copy of the object graph even though
+ the physical repository connection has broken down or changed to a different fail-over participant.
+ <p>
+ <li><b>Offline work</b> with your models is supported by two different mechanisms. One way is to create a clone of
+ a complete remote repository, including all history of all branches. Such a clone is continuously synchronized with
+ its remote master and can either act as an embedded repository to make a single application tolerant against
+ network outage or it can be set up to serve multiple clients, e.g., to compensate low latency master connections
+ and speed up read access to the object graph. An entirely different and somewhat lighter approach to offline work
+ is to check out a single version of the object graph from a particular branch point of the repository into a local
+ CDO workspace. Such a workspace behaves similar to a local repository without branching or history capture, in
+ particular it supports multiple concurrent transactions on the local checkout. In addition it supports most remote
+ functionality that is known from source code management systems such as update, merge, compare, revert and check
+ in.
+ </ul>
+
+<h2><a name="Architecture"/>2&nbsp;&nbsp;Architecture</h2>
+<p>
+ The architecture of CDO comprises applications and repositories. Despite a number of embedding options applications
+ are usually deployed to client nodes and repositories to server nodes. They communicate through an application
+ level CDO protocol which can be driven through various kinds of physical transports, including fast intra JVM
+ connections.
+ <p>
+ CDO has been designed to take full advantage of the OSGi platform, if available at runtime, but can perfectly be
+ operated in standalone deployments or in various kinds of containers such as JEE web or application servers.
+ <p>
+ The following chapters give an overview about the architecures of applications and repositories, respectively.
+
+<h3><a name="Application"/>2.1&nbsp;&nbsp;Application Architecture</h3>
+<p>
+ The architecture of a CDO application is characterized by its mandatory dependency on EMF, the Eclipse Modeling
+ Framework. Most of the time an application interacts with the object graph of the model through standard EMF APIs
+ because CDO model graph objects are <a href="http://download.eclipse.org/modeling/emf/emf/javadoc/2.7.0/org/eclipse/emf/ecore/EObject.html" title="Interface in org.eclipse.emf.ecore"><code>EObjects</code></a>. While CDO's basic functionality integrates nicely
+ and transparently with EMF's extension mechansims some of the more advanced functions may require to add direct
+ dependendcies on CDO to your application code.
+ <p>
+ The following diagram illustrates the major building blocks of a CDO application:
+ <p>
+ <img src="application-architecture.png"/>.
+
+<h3><a name="Repository"/>2.2&nbsp;&nbsp;Repository Architecture</h3>
+<p>
+ <img src="repository-architecture.png"/>.
<HR>
<i>Copyright (c) 2004 - 2011 Eike Stepper (Berlin, Germany) and others.</i>
diff --git a/plugins/org.eclipse.emf.cdo.doc/html/application-architecture.png b/plugins/org.eclipse.emf.cdo.doc/html/application-architecture.png
new file mode 100644
index 0000000000..2ae8bc66f0
--- /dev/null
+++ b/plugins/org.eclipse.emf.cdo.doc/html/application-architecture.png
Binary files differ
diff --git a/plugins/org.eclipse.emf.cdo.doc/html/repository-architecture.png b/plugins/org.eclipse.emf.cdo.doc/html/repository-architecture.png
new file mode 100644
index 0000000000..c2196e4f53
--- /dev/null
+++ b/plugins/org.eclipse.emf.cdo.doc/html/repository-architecture.png
Binary files differ
diff --git a/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/Overview.java b/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/Overview.java
index baac65d114..ccc24cc286 100644
--- a/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/Overview.java
+++ b/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/Overview.java
@@ -10,14 +10,136 @@
*/
package org.eclipse.emf.cdo.doc;
+import org.eclipse.emf.ecore.EObject;
+
/**
* Overview
* <p>
- * {@toc}
+ * CDO is a pure Java <i>model repository</i> for your EMF models and meta models. CDO can also serve as a
+ * <i>persistence and distribution framework</i> for your EMF based application systems. For the sake of this overview a
+ * model can be regarded as a graph of application or business objects and a meta model as a set of classifiers that
+ * describe the structure of and the possible relations between these objects.
+ * <p>
*
* @number 0
* @default
*/
public class Overview
{
+ /**
+ * Functionality
+ * <p>
+ * The main functionality of CDO can be summarized as follows:
+ * <ul>
+ * <li><b>Persistence</b> of your models in all kinds of database backends like major relational databases or NoSQL
+ * databases. CDO keeps your application code free of vendor specific data access code and eases transitions between
+ * the supported backend types.
+ * <p>
+ * <li><b>Multi user access</b> to your models is supported through the notion of repository sessions. The physical
+ * transport of sessions is pluggable and repositories can be configured to require secure authentication of users.
+ * Various authorization policies can be established programmatically.
+ * <p>
+ * <li><b>Transactional access</b> to your models with ACID properties is provided by optimistic and/or pessimistic
+ * locking on a per object granule. Transactions support multiple savepoints that changes can be rolled back to.
+ * Pessimistic locks can be acquired separately for read access, write access and the option to reserve write access
+ * in the future. All kinds of locks can optionally be turned into long lasting locks that survive repository
+ * restarts. Transactional modification of models in multiple repositories is provided through the notion of XA
+ * transactions with a two phase commit protocol.
+ * <p>
+ * <li><b>Transparent temporality</b> is available through audit views, a special kind of read only transactions that
+ * provide you with a consistent model object graph exactly in the state it has been at a point in the past. Depending
+ * on the chosen backend type the storage of the audit data can lead to considerable increase of database sizes in
+ * time. Therefore it can be configured per repository.
+ * <p>
+ * <li><b>Parallel evolution</b> of the object graph stored in a repository through the concept of branches similar to
+ * source code management systems like Subversion or Git. Comparisons or merges between any two branch points are
+ * supported through sophisticated APIs, as well as the reconstruction of committed change sets or old states of
+ * single objects.
+ * <p>
+ * <li><b>Scalability</b>, the ability to store and access models of arbitrary size, is transparently achieved by
+ * loading single objects on demand and caching them <i>softly</i> in your application. That implies that objects that
+ * are no longer referenced by the application are automatically garbage collected when memory contention occurs. Lazy
+ * loading is accompanied by various prefetching strategies, including the monitoring of the object graph's
+ * <i>usage</i> and calculation of fetch rules that are optimal for the current usage patterns. The scalability of EMF
+ * applications can be further increased by leveraging CDO constructs such as remote cross referencing or optimized
+ * content adapters.
+ * <p>
+ * <li><b>Thread safety</b> ensures that multiple threads of your application can access and modify the object graph
+ * without worrying about the synchronization details. This is possible and cheap because multiple transactions can be
+ * opened from within a single session and they all share the same object data until one of them modifies the graph.
+ * Possible commit conflicts can be handled in the same way as if they were conflicts between different sessions.
+ * <p>
+ * <li><b>Collaboration</b> on models with CDO is a snap because an application can opt in to be notified about remote
+ * changes to the object graph. By default your local object graph transparently changes when it has changed remotely.
+ * With configurable change subscription policies you can fine tune the characteristics of your <i>distributed shared
+ * model</i> so that all users enjoy the impression to collaborate on a single instance of an object graph. The level
+ * of collaboration can be further increased by plugging custom collaboration handlers into the asynchronous CDO
+ * protocol.
+ * <p>
+ * <li><b>Data integrity</b> can be ensured by enabling optional commit checks in the repository server such as
+ * referential integrity checks and containment cycle checks, as well as custom checks implemented by write access
+ * handlers.
+ * <p>
+ * <li><b>Fault tolerance</b> on multiple levels, namely the setup of fail-over clusters of replicating repositories
+ * under the control of fail-over monitors, as well as the usage of anumber of special kinds of session such as
+ * fail-over or reconnecting sessions that allow applications to hold on their copy of the object graph even though
+ * the physical repository connection has broken down or changed to a different fail-over participant.
+ * <p>
+ * <li><b>Offline work</b> with your models is supported by two different mechanisms. One way is to create a clone of
+ * a complete remote repository, including all history of all branches. Such a clone is continuously synchronized with
+ * its remote master and can either act as an embedded repository to make a single application tolerant against
+ * network outage or it can be set up to serve multiple clients, e.g., to compensate low latency master connections
+ * and speed up read access to the object graph. An entirely different and somewhat lighter approach to offline work
+ * is to check out a single version of the object graph from a particular branch point of the repository into a local
+ * CDO workspace. Such a workspace behaves similar to a local repository without branching or history capture, in
+ * particular it supports multiple concurrent transactions on the local checkout. In addition it supports most remote
+ * functionality that is known from source code management systems such as update, merge, compare, revert and check
+ * in.
+ * </ul>
+ */
+ public class Functionality
+ {
+ }
+
+ /**
+ * Architecture
+ * <p>
+ * The architecture of CDO comprises applications and repositories. Despite a number of embedding options applications
+ * are usually deployed to client nodes and repositories to server nodes. They communicate through an application
+ * level CDO protocol which can be driven through various kinds of physical transports, including fast intra JVM
+ * connections.
+ * <p>
+ * CDO has been designed to take full advantage of the OSGi platform, if available at runtime, but can perfectly be
+ * operated in standalone deployments or in various kinds of containers such as JEE web or application servers.
+ * <p>
+ * The following chapters give an overview about the architecures of applications and repositories, respectively.
+ */
+ public class Architecture
+ {
+ /**
+ * Application Architecture
+ * <p>
+ * The architecture of a CDO application is characterized by its mandatory dependency on EMF, the Eclipse Modeling
+ * Framework. Most of the time an application interacts with the object graph of the model through standard EMF APIs
+ * because CDO model graph objects are {@link EObject EObjects}. While CDO's basic functionality integrates nicely
+ * and transparently with EMF's extension mechansims some of the more advanced functions may require to add direct
+ * dependendcies on CDO to your application code.
+ * <p>
+ * The following diagram illustrates the major building blocks of a CDO application:
+ * <p>
+ * <img src="application-architecture.png"/>.
+ */
+ public class Application
+ {
+ }
+
+ /**
+ * Repository Architecture
+ * <p>
+ * <img src="repository-architecture.png"/>.
+ */
+ public class Repository
+ {
+ }
+ }
}
diff --git a/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/application-architecture.png b/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/application-architecture.png
new file mode 100644
index 0000000000..2ae8bc66f0
--- /dev/null
+++ b/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/application-architecture.png
Binary files differ
diff --git a/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/repository-architecture.png b/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/repository-architecture.png
new file mode 100644
index 0000000000..c2196e4f53
--- /dev/null
+++ b/plugins/org.eclipse.emf.cdo.doc/src/org/eclipse/emf/cdo/doc/repository-architecture.png
Binary files differ
diff --git a/plugins/org.eclipse.emf.cdo.releng.doc/model/article.ecorediag b/plugins/org.eclipse.emf.cdo.releng.doc/model/article.ecorediag
index 1fa107ce4a..22e4cb72c8 100644
--- a/plugins/org.eclipse.emf.cdo.releng.doc/model/article.ecorediag
+++ b/plugins/org.eclipse.emf.cdo.releng.doc/model/article.ecorediag
@@ -749,7 +749,7 @@
<styles xmi:type="notation:ConnectorStyle" xmi:id="_p1VWcdxaEeCpIJpgvmzkYA" routing="Rectilinear" lineColor="4210752"/>
<styles xmi:type="notation:FontStyle" xmi:id="_p1VWctxaEeCpIJpgvmzkYA" fontName="Segoe UI"/>
<element xsi:nil="true"/>
- <bendpoints xmi:type="notation:RelativeBendpoints" xmi:id="_p1VWc9xaEeCpIJpgvmzkYA" points="[-4, -20, 182, 88]$[-4, -50, 182, 58]$[-187, -50, -1, 58]$[-187, -79, -1, 29]"/>
+ <bendpoints xmi:type="notation:RelativeBendpoints" xmi:id="_p1VWc9xaEeCpIJpgvmzkYA" points="[-1, -20, 185, 92]$[-1, -51, 185, 61]$[-187, -51, -1, 61]$[-187, -87, -1, 25]"/>
</edges>
<edges xmi:type="notation:Edge" xmi:id="_6-blYNxaEeCpIJpgvmzkYA" type="3003" source="_5fxPANxaEeCpIJpgvmzkYA" target="_yWi_ANxZEeCpIJpgvmzkYA">
<styles xmi:type="notation:ConnectorStyle" xmi:id="_6-blYdxaEeCpIJpgvmzkYA" routing="Rectilinear" lineColor="4210752"/>
diff --git a/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/CategoryImpl.java b/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/CategoryImpl.java
index ed2738df45..1d5a144d9f 100644
--- a/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/CategoryImpl.java
+++ b/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/CategoryImpl.java
@@ -81,20 +81,8 @@ public class CategoryImpl extends BodyImpl implements Category
@Override
public void generate() throws IOException
{
- File targetFolder = getOutputFile();
File sourceFolder = getDoc().position().file().getParentFile();
- for (File file : sourceFolder.listFiles())
- {
- if (file.isFile())
- {
- String name = file.getName();
- if (!name.endsWith(".java") && !name.equals("package-info.java"))
- {
- File targetFile = new File(targetFolder, name);
- ArticleUtil.copyFile(file, targetFile);
- }
- }
- }
+ copyResources(sourceFolder, getOutputFile());
super.generate();
generate(getTocTarget());
diff --git a/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/DocumentationImpl.java b/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/DocumentationImpl.java
index a16905a71a..6e3c163875 100644
--- a/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/DocumentationImpl.java
+++ b/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/DocumentationImpl.java
@@ -655,7 +655,16 @@ public class DocumentationImpl extends StructuralElementImpl implements Document
@Override
public void generate() throws IOException
{
+ EList<StructuralElement> children = getChildren();
+ if (!children.isEmpty())
+ {
+ StructuralElement child = children.get(0);
+ File sourceFolder = child.getDoc().position().file().getParentFile().getParentFile();
+ copyResources(sourceFolder, getOutputFile());
+ }
+
super.generate();
+
generateToc(false);
generateToc(true);
}
diff --git a/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/StructuralElementImpl.java b/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/StructuralElementImpl.java
index 44c5ee4f96..415f385632 100644
--- a/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/StructuralElementImpl.java
+++ b/plugins/org.eclipse.emf.cdo.releng.doc/src/org/eclipse/emf/cdo/releng/doc/article/impl/StructuralElementImpl.java
@@ -668,4 +668,20 @@ public abstract class StructuralElementImpl extends LinkTargetImpl implements St
File projectFolder = getDocumentation().getOutputFile().getParentFile();
return ArticleUtil.createLink(projectFolder, getTocTarget());
}
+
+ protected void copyResources(File sourceFolder, File targetFolder)
+ {
+ for (File file : sourceFolder.listFiles())
+ {
+ if (file.isFile())
+ {
+ String name = file.getName();
+ if (!name.endsWith(".java") && !name.equals("package-info.java"))
+ {
+ File targetFile = new File(targetFolder, name);
+ ArticleUtil.copyFile(file, targetFile);
+ }
+ }
+ }
+ }
} // StructuralElementImpl

Back to the top