diff --git a/README.markdown b/README.markdown new file mode 100644 index 0000000..012db26 --- /dev/null +++ b/README.markdown @@ -0,0 +1,295 @@ +# The smallest plugin system ever + +V0.8 - Oliver Gierke, SpringSource - a division of VMware + +© 2008-2012 The original authors + +## Revision History + +* 04.11.2008 Oliver Gierke Initial draft +* 05.11.2008 Oliver Gierke Added metadata module documentation +* 24.01.2009 Oliver Gierke Added remark to inner bean usage +* 23.03.2009 Oliver Gierke Added section on plugin ordering +* 21.02.2012 Oliver Gierke Move project to SpringSource + +## Preface + +### Introduction + +Building extensible architectures nowadays is a core principle to create maintainable applications. This is why fully fledged plugin environments like *OSGi* are so poular these days. Unfortunately the introduction of *OSGi* introduces a lot of complexity to projects. + +Spring Plugin provides a more pragmatic approach to plugin development by providing the core flexibility of having plugin implementations extending a core system's functionality but of course not delivering core OSGi features like dynamic class loading or runtime installation and deployment of plugins. Although Spring Plugin thus is not nearly as powerful as OSGi, it servers poor man's requirements to build a modular +extensible application. + +### Context + +- You want to build an extensible architecture minimizing overhead as much as possible +- You cannot use OSGi as fully fledged plugin architecture for whatever reasons +- You want to express extensibility by providing dedicated plugin interfaces +- You want to extend the core system by simply providing an implementation of the plugin interface bundled in a JAR file and available in the classpath +- (You use Spring in your application) + +The last point actually is not essential although Spring Plugin gains a +lot of momentum in collaborative use with Spring. + +### Technologies + +#### Spring + +Spring is the defacto standard application framework for Java applications. Its consistent programming model, easy configuration and wide support for all kinds of third party libraries makes it the first class citizen of application frameworks. Spring Plugin tightly integrates into Spring's component model and extends the core container +with some custom functionality. + +## Core + +### Introduction + +Host system provides a plugin interface providers have to implement. +Core system is build to hold a container of instances of this interface +and works with them. + +**Example 1.1. Basic example of plugin interface and host** + +~~~~java +/** + * Interface contract for the providers to be implemented. + */ +public interface MyPluginInterface { + public void bar(); +} + + +/** + * A host application class working with instances of the plugin + * interface. + */ +public class HostImpl implements Host { + + private final List plugins; + + public HostImpl(List plugins) { + Assert.notNull(plugins); + this.plugins = plugins; + } + + /** + * Some business method actually working with the given plugins. + */ + public void someBusinessMethod() { + for (MyPluginInterface plugin : plugins) { + plugin.bar(); + } + } +} +~~~~ + +This is the way you would typically construct a host component in general. Leveraging dependency injection via setters allows flexible usage in a variety of environments. Thus you could easily provide a factory class that is able to lookup `MyPluginInterface` +implementations from the classpath, instantiate them and inject them into `HostImpl`. + +Using Spring as component container you could configure something like this: + +**Example 1.2. Configuring HostImpl with Spring** + +~~~~xml + + + + + + + +~~~~ + +This is pretty much well known to Spring developers and let's us face the wall that this is rather static. Everytime you want to add a new plugin implementation instance you have to modify configuration of the core. Let's see how we can get this dance a little more. + +### Collecting Spring beans dynamically + +With the `BeanListBeanFactory` Spring Plugin provides a Spring container extension, that allows to lookup beans of a given type in the current `ApplicationContext` and register them as list under a given name. Take a look at the configuration now: + +**Example 1.3. Host and plugin configuration with Spring Plugin +support** + +~~~~xml + + + + + + + + + + + + + +~~~~ + +~~~~xml + + +~~~~ + +You can see that we include a wildcarded configurationfile that allows plugin projects to easily contribute plugin implementations by declaring them as beans in configuration files matching the wildcarded path. If you use Spring 2.5 component scanning you don't have to use the import trick at all as Spring would detect the implementation automatically as long as it is annotated with `@Component`, `@Service` a.s.o. + +The `BeanListBeanFactory` in turn allows registering a map of lists to be created, where the maps entry key is the id under which the list will be registered and the entry's value is the type to be looked up. + +> #### Note +> +> The design of the `BeanListBeanFactory` might seem a little confusing at first +> (especially to set a map on a property named lists). This is due to the posibility to +> register more than one list to be looked up. We think about dropping this +> functionality for the sake of simplicity in future versions. + +### A whole lotta XML - namespace to help! + +Actually this already serves a lot of requirements we listed in [Section “Context”](#context). Nevertheless the amount of XML to be written is quite large. Furthermore it's rather not intuitive to configure a bean id as key, and a type as value. We can heavily shrink the XML required to a single line by providing a Spring namespace boiling configuration down to this: + +**Example 1.4. Host configuration using the plugin namespace** + +~~~~xml + + + + + + + + + + +~~~~ + +Assuming you have added the namespace XSD into Eclipse and installed Spring IDE, you should get code completion on filling the class attribute. + +### Using inner beans + +The listing above features an indirection for the `plugin` bean definition. Defining the plugin list as top level bean can have advantages: you easily could place all plugin lists in a dedicated configuration file, presenting all application extension points in one single place. Nevertheless you also might choose to define the list directly in the property declaration: + +**Example 1.5. Using inner bean definition** + +~~~~xml + + + + + + + +~~~~ + +This way you have a more compact configuration, paying the prica of tangling all extention points though possibly various config files. + +#### Plugin beans + +Using plain interfaces and `BeanListBeanFactory` offers an easy way to dynamically lookup beans in Spring environments. Nevertheless, very often you face the situation that you want to have dedicated access to a subset of all plugins, choose plugins by a given criteria or use a decent default plugin or the like. Thus we need a basic infrastructure interface for plugin interfaces to extend and a more sophisticated plugin container. + +#### Plugin + +Hera's central infrastructure interfacte is `Plugin`, where `S` defines the delimiter type you want to let implementations decide on, whether they shall be invoked or not. Thus the plugin implementation have to implement `supports(S delimiter)` to come to the decision. Consider the following example: + +**Example 1.6. Usage of Plugin interface** + +~~~~java +public enum ProductType { + SOFTWARE, HARDWARE; +} + +public interface ProductProcessor extends Plugin { + public void process(Product product); +} +~~~~ + +This design would allow plugin providers to implement `supports(ProductType productType)` to decide which product types they want to process and provide actual processing logic in `process(Product product)`. + +#### PluginRegistry + +Using a `List` as plugin container as well as the `Plugin` interface you can now select plugins supporting the given delimiter. To not reimplement the lookup logic for common +cases Spring Plugin provides a `PluginRegistry, S>` interface that provides sophisticated methods to access certain plugins: + +**Example 1.7. Usage of the PluginRegistry** + +~~~~java +PluginRegistry registry = SimplePluginRegistry.create(); +// Add plugin instances +registry.add(new FooImplementation()); +// Returns the first plugin supporting SOFTWARE +registry.getPluginFor(ProductType.SOFTWARE); +// Returns the first plugin supporting SOFTWARE, or DefaultPlugin if none found +registry.getPluginFor(ProductType.SOFTWARE, new DefaultPlugin()); +// Returns all plugins supporting HARDWARE, throwing the given exception if none found +registry.getPluginsFor(ProductType.HARDWARE, new MyException("Damn!"); +~~~~ + +#### Configuration and namespace + +Similar to the `BeanListBeanFactory` described in [Collecting Spring beans +dynamically](#core.beans-dynamically) Spring Plugin provides a `PluginRegistryBeanFactory` to automatically lookup beans of a dedicated type to be aggregated in a `PluginRegistry`. Note that the type has to be assignable to `Plugin` to let the registry work as expected. + +Furthermore there is also an element in the namespace to shrink down configuration XML: + +**Example 1.8. Using the XML namespace to configure a registry** + +~~~~xml + +~~~~ + +### Ordering plugins + +Declaring plugin beans sometimes it is necessary to preserve a certain order of plugins. Suppose you have a plugin host that already defines one plugin that shall always be executed after all plugins declared by extensions. Actually the Spring container typically returnes beans in the order they were declared, so that you could import you wildcarded config files right before declaring the default plugin. Unfortunately +the order of the beans is not contracted to be preserved for the Spring container. Thus we need a different solution. + +Spring provides two ways to order beans. First, you can implement `Ordered` interface and implement `getOrder` to place a plugin at a certain point in the list. Secondly you can user the `@Order` annotation. For more information on ordering capabilities of Spring see the [section on this topic in the Spring reference documentation](http://static.springsource.org/spring/docs/3.1.x/javadoc-api/org/springframework/core/Ordered.html). + +Using the Spring Plugin namespace you will get a `PluginRegistry` instance that is capable of preserving the order defined by the mentioned means. Using Spring Plugin +programatically use `OrderAwarePluginRegistry`. + +## Metadata + +For plugin architectures it is essential to capture metadata information about plugin instances. A very core set of metadata (name, version) also serves as identifier of a plugin and thus can be used. The Spring Plugin metadata module provides support to capture metadata. + +### Core concepts + +The metadata module actually builds around two core interfaces, `PluginMetadata` and `MetadataProvider`: + +**Example 2.1. Core concepts** + +~~~~java +public interface PluginMetadata { + String getName(); + String getVersion(); +} + +public interface MetadataProvider { + PluginMetadata getMetadata(); +} +~~~~ + +The `PluginMetadata` interface captures the required properties to define an identifyable plugin. This means, that implementations should ensure uniqueness through these two properties. With `SimplePluginMetadata` Spring Plugin provides a Java bean style class to capture metadata. Of course applications can and should provide extended metadata information according to their needs. The very narrow interface is only targeted at integrating the metadata concept with the `PluginRegistry` (see [the section called “PluginRegistry”](#core.plugin-registry)) without bothering developers with too much information required. + +The `MetadataProvider` interface is to be used in application plugin interfaces to indicate that they can provide metadata. To ease plugin implementation we provide +`AbstractMetadataBasedPlugin` that uses the internal metadata to implement `supports(..)` method of `Plugin`. Extending this base class plugins with metadata as selection criteria can easily be build. This way you could store the metadata in user specific configuration files and use this to select a distinct plugin specific to a given user. + +## Glossary + + +### O + +OSGi + + * Open Services Gateway Initiative - a fully fledged plugin runtime + environment on top of the Java VM - + [http://en.wikipedia.org/wiki/OSGi](http://en.wikipedia.org/wiki/OSGi). + +### X + +XML + + * eXtensible Markup Language + +XSD + + * Xml Schema Definition \ No newline at end of file diff --git a/core/src/docbkx/core.xml b/core/src/docbkx/core.xml deleted file mode 100644 index 44054a2..0000000 --- a/core/src/docbkx/core.xml +++ /dev/null @@ -1,317 +0,0 @@ - - - - Core - -
- Introduction - - Host system provides a plugin interface providers have to implement. - Core system is build to hold a container of instances of this interface - and works with them. - - - Basic example of plugin interface and host - - /** - * Interface contract for the providers to be implemented. - */ -public interface MyPluginInterface { - - public void bar(); -} - - -/** - * A host application class working with instances of the plugin - * interface. - */ -public class HostImpl implements Host { - - private List<MyPluginInterface> plugins; - - /** - * Setter to inject the plugins - */ - public void setPlugins(List<MyPluginInterface> plugins) { - this.plugins = plugins; - } - - /** - * Some business method actually working with the given plugins. - */ - public void someBusinessMethod() { - - for (MyPluginInterface plugin : plugins) { - plugin.bar(); - } - } -} - - - This is the way you would typically construct a host component in - general. Leveraging dependency injection via setters allows flexible usage - in a variety of environments. Thus you could easily provide a factory - class that is able to lookup - MyPluginInterface implementations from the - classpath, instantiate them and inject them into HostImpl. - - Using Spring as component container you could configure something - like this: - - - Configuring HostImpl with Spring - - <bean id="host" class="com.acme.HostImpl"> - <property name="plugins"> - <list> - <bean class="MyPluginImplementation" /> - </list> - </property> -</bean> - - - This is pretty much well known to Spring developers and let's us - face the wall that this is rather static. Everytime you want to add a new - plugin implementation instance you have to modify configuration of the - core. Let's see how we can get this dance a little more. -
- -
- Collecting Spring beans dynamically - - With the BeanListBeanFactory - Spring Plugin provides a Spring container - extension, that allows to lookup beans of a given type in the current - ApplicationContext and register them as - list under a given name. Take a look at the configuration now: - - - Host and plugin configuration with Spring Plugin support - - <import resource="classpath*:com/acme/**/plugins.xml" /> - -<bean id="host" class="com.acme.HostImpl"> - <property name="plugins" ref="plugins" /> -</bean> - -<bean class="org.springframework.plugin.support.BeanListBeanFactory"> - <property name="lists"> - <map> - <entry key="plugins" value="org.acme.MyPluginInterface" /> - </map> - </property> -</bean> - - <!-- In a file called plugins.xml in the plugin project --> -<bean class="MyPluginimplementation" /> - - - You can see that we include a wildcarded configurationfile that - allows plugin projects to easily contribute plugin implementations by - declaring them as beans in configuration files matching the wildcarded - path. If you use Spring 2.5 component scanning you don't have to use the - import trick at all as Spring would detect the implementation - automatically as long as it is annotated with @Component, - @Service a.s.o. - - The BeanListBeanFactory in turn allows - registering a map of lists to be created, where the maps entry key is the - id under which the list will be registered and the entry's value is the - type to be looked up. - - - The design of the BeanListBeanFactory might - seem a little confusing at first (especially to set a map on a property - named lists). This is due to the posibility to register more than one - list to be looked up. We think about dropping this functionality for the - sake of simplicity in future versions. - - - - A whole lotta XML - namespace to help! - - Actually this already serves a lot of requirements we listed in - . Nevertheless the amount of XML to be - written is quite large. Furthermore it's rather not intuitive to - configure a bean id as key, and a type as value. We can heavily shrink - the XML required to a single line by providing a Spring namespace - boiling configuration down to this: - - - Host configuration using the plugin namespace - - <beans xmlns="http://www.springframework.org/schema/beans" - xmlns:plugin="http://www.springframework.org/schema/plugin" - xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" - xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd - http://www.springframework.org/schema/plugin http://www.springframework.org/schema/plugin/spring-plugin.xsd"> - - <import resource="classpath*:com/acme/**/plugins.xml" /> - - <bean id="host" class="com.acme.HostImpl"> - <property name="plugins" ref="plugins" /> - </bean> - - <plugin:list id="plugins" class="org.acme.MyPluginInterface" /> -</beans> - - - Suggested you have added the namespace XSD into Eclipse and - installed Spring IDE, you should get code completion on filling the - class attribute. - - - - Using inner beans - - The listing above features an indirection for the - plugin bean definition. Defining the plugin list as top - level bean can have advantages: you easily could place all plugin lists - in a dedicated configuration file, presenting all application extension - points in one single place. Nevertheless you also might choose to define - the list directly in the property declaration: - - - Using internal bean definition - - <import resource="classpath*:com/acme/**/plugins.xml" /> - -<bean id="host" class="com.acme.HostImpl"> - <property name="plugins"> - <plugin:list class="org.acme.MyPluginInterface" /> - </property> -</bean> - - - This way you have a more compact configuration, paying the prica - of tangling all extention points though possibly various config - files. - -
- -
- Plugin beans - - Using plain interfaces and - BeanListBeanFactory offers an easy way to - dynamically lookup beans in Spring environments. Nevertheless, very often - you face the situation that you want to have dedicated access to a subset - of all plugins, choose plugins by a given criteria or use a decent default - plugin or the like. Thus we need a basic infrastructure interface for - plugin interfaces to extend and a more sophisticated plugin - container. - - - Plugin - - Hera's central infrastructure interfacte is - Plugin<S>, where S defines the - delimiter type you want to let implementations decide on, whether they - shall be invoked or not. Thus the plugin implementation have to - implement supports(S delimiter) to come to the - decision. Consider the following example: - - - Usage of Plugin interface - - public enum ProductType { - - SOFTWARE, HARDWARE; -} - -public interface ProductProcessor extends Plugin<ProductType> { - - public void process(Product product); -} - - - This design would allow plugin providers to implement - supports(ProductType productType) to decide - which product types they want to process and provide actual processing - logic in process(Product product). - - - - PluginRegistry - - Using a List as plugin container as - well as the Plugin interface you can now - select plugins supporting the given delimiter. To not reimplement the - lookup logic for common cases Spring Plugin provides a - PluginRegistry<T extends Plugin<S>, - S> interface that provides sophisticated methods to - access certain plugins: - - - Usage of the PluginRegistry - - PluginRegistry<ProductProcessor, ProductType> registry = - SimplePluginRegistry.create(); - -// Add plugin instances -registry.add(new FooImplementation()); - -// Returns the first plugin supporting SOFTWARE -registry.getPluginFor(ProductType.SOFTWARE); - -// Returns the first plugin supporting SOFTWARE, -// or DefaultPlugin if none found -registry.getPluginFor(ProductType.SOFTWARE, new DefaultPlugin()); - -// Returns all plugins supporting HARDWARE, -// throwing the given exception if none found -registry.getPluginsFor(ProductType.HARDWARE, new MyException("Damn!"); - - - - - Configuration and namespace - - Similar to the BeanListBeanFactory - described in Spring Plugin - provides a PluginRegistryBeanFactory to - automatically lookup beans of a dedicated type to be aggregated in a - PluginRegistry. Note that the type has to be - assignable to Plugin to let the registry - work as expected. - - Furthermore there is also an element in the namespace to shrink - down configuration XML: - - - Using the XML namespace to configure a registry - - <plugin:registry id="plugins" class="com.acme.MyPluginInterface" /> - - - - - Ordering plugins - - Declaring plugin beans sometimes it is necessary to preserve a - certain order of plugins. Suppose you have a plugin host that already - defines one plugin that shall always be executed after all plugins - declared by extensions. Actually the Spring container typically returnes - beans in the order they were declared, so that you could import you - wildcarded config files right before declaring the default plugin. - Unfortunately the order of the beans is not contracted to be preserved - for the Spring container. Thus we need a different solution. - - Spring provides two ways to order beans. First, you can implement - Ordered interface and implement - getOrder to place a plugin at a certain point - in the list. Secondly you can user the @Order - annotation. For more information on ordering capabilities of Spring see - the section on this topic in the Spring reference - documentation. - - Using the Spring Plugin namespace you will get a - PluginRegistry instance that is capable - of preserving the order defined by the mentioned means. Using Spring - Plugin programatically use - OrderAwarePluginRegistry. - -
- diff --git a/metadata/src/docbkx/metadata.xml b/metadata/src/docbkx/metadata.xml deleted file mode 100644 index efa1194..0000000 --- a/metadata/src/docbkx/metadata.xml +++ /dev/null @@ -1,57 +0,0 @@ - - - - Metadata - - For plugin architectures it is essential to capture metadata - information about plugin instances. A very core set of metadata (name, - version) also serves as identifier of a plugin and thus can be used. The - Spring Plugin metadata module provides support to capture metadata. - -
- Core concepts - - The metadata module actually builds around two core interfaces, - PluginMetadata and - MetadataProvider: - - - Core concepts - - public interface PluginMetadata { - - String getName(); - - String getVersion(); -} - - -public interface MetadataProvider { - - PluginMetadata getMetadata(); -} - - - The PluginMetadata interface captures - the required properties to define an identifyable plugin. This means, that - implementations should ensure uniqueness through these two properties. - With SimplePluginMetadata Spring Plugin provides a - Java bean style class to capture metadata. Of course applications can and - should provide extended metadata information according to their needs. The - very narrow interface is only targeted at integrating the metadata concept - with the PluginRegistry (see ) without bothering developers with too - much information required. - - The MetadataProvider interface is to - be used in application plugin interfaces to indicate that they can provide - metadata. To ease plugin implementation we provide - AbstractMetadataBasedPlugin that uses the internal - metadata to implement supports(..) method of - Plugin. Extending this base class plugins - with metadata as selection criteria can easily be build. This way you - could store the metadata in user specific configuration files and use this - to select a distinct plugin specific to a given user. -
- diff --git a/pom.xml b/pom.xml index 5dd162f..f88b1e9 100644 --- a/pom.xml +++ b/pom.xml @@ -109,72 +109,6 @@ - - - com.agilejava.docbkx - docbkx-maven-plugin - 2.0.8 - - - - generate-html - generate-pdf - - pre-site - - - false - - - - net.sf.offo - fop-hyph - 1.2 - runtime - - - - org.docbook - docbook-xml - 4.4 - runtime - - - - index.xml - true - ${project.basedir}/src/docbkx/resources/xsl/fopdf.xsl - css/html.css - false - ${project.basedir}/src/docbkx/resources/xsl/html.xsl - 1 - 1 - - - version - ${project.version} - - - - - - - - - - - - - - - - - - - - - - com.springsource.bundlor com.springsource.bundlor.maven diff --git a/src/docbkx/index.xml b/src/docbkx/index.xml deleted file mode 100644 index c59c211..0000000 --- a/src/docbkx/index.xml +++ /dev/null @@ -1,215 +0,0 @@ - - - - - Spring Plugin - - The smallest plugin system ever - - - - Oliver - - Gierke - - - Senior Member Technical Staff - - SpringSource, a division of VMware - - - ogierke (at) vmware.com - - - - V0.8 - - 23.09.2009 - - - 2008-2012 - - The original authors - - - - - 04.11.2008 - - - Oliver - - Gierke - - - Initial draft - - - - 05.11.2008 - - - Oliver - - Gierke - - - Added metadata module documentation - - - - 24.01.2009 - - - Oliver - - Gierke - - - Added remark to inner bean usage - - - - 23.03.2009 - - - Oliver - - Gierke - - - Added section on plugin ordering - - - - 21.02.2012 - - - Oliver - - Gierke - - - Move project to SpringSource - - - - - - Preface - -
- Introduction - - Building extensible architectures nowadays is a core principle to - create maintainable applications. This is why fully fledged plugin - environments like OSGi are so - poular these days. Unfortunately the introduction of - OSGi introduces a lot of - complexity to projects. - - Spring Plugin provides a more pragmatic approach to plugin - development by providing the core flexibility of having plugin - implementations extending a core system's functionality but of course - not delivering core OSGi features like dynamic class - loading or runtime installation and deployment of plugins. Although - Spring Plugin thus is not nearly as powerful as OSGi, - it servers poor man's requirements to build a modular extensible - application. -
- -
- Context - - - - You want to build an extensible architecture minimizing - overhead as much as possible - - - - You cannot use OSGi as fully fledged plugin architecture for - whatever reasons - - - - You want to express extensibility by providing dedicated - plugin interfaces - - - - You want to extend the core system by simply providing an - implementation of the plugin interface bundled in a JAR file and - available in the classpath. - - - - (You use Spring in your application) - - - - The last point actually is not essential although Spring Plugin - gains a lot of momentum in collaborative use with Spring. -
- -
- Technologies - - - Spring - - Spring is the defacto standard application framework for Java - applications. Its consistent programming model, easy configuration and - wide support for all kinds of third party libraries makes it the first - class citizen of application frameworks. Spring Plugin tightly - integrates into Spring's component model and extends the core - container with some custom functionality. - -
- - - - - - - - - - - - - O - - - OSGi - - - Open Services Gateway Initiative - a fully fledged plugin - runtime environment on top of the Java VM - http://en.wikipedia.org/wiki/OSGi. - - - - - - X - - - XML - - - eXtensible Markup Language - - - - - XSD - - - Xml Schema Definition - - - - - diff --git a/src/docbkx/resources/css/highlight.css b/src/docbkx/resources/css/highlight.css deleted file mode 100644 index ffefef7..0000000 --- a/src/docbkx/resources/css/highlight.css +++ /dev/null @@ -1,35 +0,0 @@ -/* - code highlight CSS resemblign the Eclipse IDE default color schema - @author Costin Leau -*/ - -.hl-keyword { - color: #7F0055; - font-weight: bold; -} - -.hl-comment { - color: #3F5F5F; - font-style: italic; -} - -.hl-multiline-comment { - color: #3F5FBF; - font-style: italic; -} - -.hl-tag { - color: #3F7F7F; -} - -.hl-attribute { - color: #7F007F; -} - -.hl-value { - color: #2A00FF; -} - -.hl-string { - color: #2A00FF; -} \ No newline at end of file diff --git a/src/docbkx/resources/css/html.css b/src/docbkx/resources/css/html.css deleted file mode 100644 index dd2ab69..0000000 --- a/src/docbkx/resources/css/html.css +++ /dev/null @@ -1,305 +0,0 @@ -@IMPORT url("highlight.css"); - -body { - text-align: justify; - margin-right: 2em; - margin-left: 2em; -} - -a, -a[accesskey^="h"], -a[accesskey^="n"], -a[accesskey^="u"], -a[accesskey^="p"] { - font-family: Verdana, Arial, helvetica, sans-serif; - font-size: 12px; - color: #003399; -} - -a:active { - color: #003399; -} - -a:visited { - color: #888888; -} - -p { - font-family: Verdana, Arial, sans-serif; -} - -dt { - font-family: Verdana, Arial, sans-serif; - font-size: 12px; -} - -p, dl, dt, dd, blockquote { - color: #000000; - margin-bottom: 3px; - margin-top: 3px; - padding-top: 0; -} - -ol, ul, p { - margin-top: 6px; - margin-bottom: 6px; -} - -p, blockquote { - font-size: 90%; -} - -p.releaseinfo { - font-size: 100%; - font-weight: bold; - font-family: Verdana, Arial, helvetica, sans-serif; - padding-top: 10px; -} - -p.pubdate { - font-size: 120%; - font-weight: bold; - font-family: Verdana, Arial, helvetica, sans-serif; -} - -td { - font-size: 80%; -} - -td, th, span { - color: #000000; -} - -td[width^="40%"] { - font-family: Verdana, Arial, helvetica, sans-serif; - font-size: 12px; - color: #003399; -} - -table[summary^="Navigation header"] tbody tr th[colspan^="3"] { - font-family: Verdana, Arial, helvetica, sans-serif; -} - -blockquote { - margin-right: 0; -} - -h1, h2, h3, h4, h6 { - color: #000000; - font-weight: 500; - margin-top: 0; - padding-top: 14px; - font-family: Verdana, Arial, helvetica, sans-serif; - margin-bottom: 0; -} - -h2.title { - font-weight: 800; - margin-bottom: 8px; -} - -h2.subtitle { - font-weight: 800; - margin-bottom: 20px; -} - -.firstname, .surname { - font-size: 12px; - font-family: Verdana, Arial, helvetica, sans-serif; -} - -table { - border-collapse: collapse; - border-spacing: 0; - border: 1px black; - empty-cells: hide; - margin: 10px 0 30px 50px; - width: 90%; -} - -div.table { - margin: 30px 0 10px 0; - border: 1px dashed gray; - padding: 10px; -} - -div .table-contents table { - border: 1px solid black; -} - -div.table > p.title { - padding-left: 10px; -} - -table[summary^="Navigation footer"] { - border-collapse: collapse; - border-spacing: 0; - border: 1px black; - empty-cells: hide; - margin: 0px; - width: 100%; -} - -table[summary^="Note"], -table[summary^="Warning"], -table[summary^="Tip"] { - border-collapse: collapse; - border-spacing: 0; - border: 1px black; - empty-cells: hide; - margin: 10px 0px 10px -20px; - width: 100%; -} - -td { - padding: 4pt; - font-family: Verdana, Arial, helvetica, sans-serif; -} - -div.warning TD { - text-align: justify; -} - -h1 { - font-size: 150%; -} - -h2 { - font-size: 110%; -} - -h3 { - font-size: 100%; font-weight: bold; -} - -h4 { - font-size: 90%; font-weight: bold; -} - -h5 { - font-size: 90%; font-style: italic; -} - -h6 { - font-size: 100%; font-style: italic; -} - -tt { - font-size: 110%; - font-family: "Courier New", Courier, monospace; - color: #000000; -} - -.navheader, .navfooter { - border: none; -} - -div.navfooter table { - border-style: dashed; - border-color: gray; - border-width: 1px 1px 1px 1px; - background-color: #cde48d; -} - -pre { - font-size: 110%; - padding: 5px; - border-style: solid; - border-width: 1px; - border-color: #CCCCCC; - background-color: #f3f5e9; -} - -ul, ol, li { - list-style: disc; -} - -hr { - width: 100%; - height: 1px; - background-color: #CCCCCC; - border-width: 0; - padding: 0; -} - -.variablelist { - padding-top: 10px; - padding-bottom: 10px; - margin: 0; -} - -.term { - font-weight:bold; -} - -.mediaobject { - padding-top: 30px; - padding-bottom: 30px; -} - -.legalnotice { - font-family: Verdana, Arial, helvetica, sans-serif; - font-size: 12px; - font-style: italic; -} - -.sidebar { - float: right; - margin: 10px 0 10px 30px; - padding: 10px 20px 20px 20px; - width: 33%; - border: 1px solid black; - background-color: #F4F4F4; - font-size: 14px; -} - -.property { - font-family: "Courier New", Courier, monospace; -} - -a code { - font-family: Verdana, Arial, monospace; - font-size: 12px; -} - -td code { - font-size: 110%; -} - -div.note * td, -div.tip * td, -div.warning * td, -div.calloutlist * td { - text-align: justify; - font-size: 100%; -} - -.programlisting { - clear: both; -} - -.programlisting .interfacename, -.programlisting .literal, -.programlisting .classname { - font-size: 95%; -} - -.title .interfacename, -.title .literal, -.title .classname { - font-size: 130%; -} - -/* everything in a is displayed in a coloured, comment-like font */ -.programlisting * .lineannotation, -.programlisting * .lineannotation * { - color: green; -} - -.question * p { - font-size: 100%; -} - -.answer * p { - font-size: 100%; -} \ No newline at end of file diff --git a/src/docbkx/resources/images/admons/blank.png b/src/docbkx/resources/images/admons/blank.png deleted file mode 100644 index 764bf4f..0000000 Binary files a/src/docbkx/resources/images/admons/blank.png and /dev/null differ diff --git a/src/docbkx/resources/images/admons/caution.gif b/src/docbkx/resources/images/admons/caution.gif deleted file mode 100644 index d9f5e5b..0000000 Binary files a/src/docbkx/resources/images/admons/caution.gif and /dev/null differ diff --git a/src/docbkx/resources/images/admons/caution.png b/src/docbkx/resources/images/admons/caution.png deleted file mode 100644 index 5b7809c..0000000 Binary files a/src/docbkx/resources/images/admons/caution.png and /dev/null differ diff --git a/src/docbkx/resources/images/admons/caution.tif b/src/docbkx/resources/images/admons/caution.tif deleted file mode 100644 index 4a28294..0000000 Binary files a/src/docbkx/resources/images/admons/caution.tif and /dev/null differ diff --git a/src/docbkx/resources/images/admons/draft.png b/src/docbkx/resources/images/admons/draft.png deleted file mode 100644 index 0084708..0000000 Binary files a/src/docbkx/resources/images/admons/draft.png and /dev/null differ diff --git a/src/docbkx/resources/images/admons/home.gif b/src/docbkx/resources/images/admons/home.gif deleted file mode 100644 index 6784f5b..0000000 Binary files a/src/docbkx/resources/images/admons/home.gif and /dev/null differ diff --git a/src/docbkx/resources/images/admons/home.png b/src/docbkx/resources/images/admons/home.png deleted file mode 100644 index cbb711d..0000000 Binary files a/src/docbkx/resources/images/admons/home.png and /dev/null differ diff --git a/src/docbkx/resources/images/admons/important.gif b/src/docbkx/resources/images/admons/important.gif deleted file mode 100644 index 6795d9a..0000000 Binary files a/src/docbkx/resources/images/admons/important.gif and /dev/null differ diff --git a/src/docbkx/resources/images/admons/important.png b/src/docbkx/resources/images/admons/important.png deleted file mode 100644 index ad57f6f..0000000 Binary files a/src/docbkx/resources/images/admons/important.png and /dev/null differ diff --git a/src/docbkx/resources/images/admons/important.tif b/src/docbkx/resources/images/admons/important.tif deleted file mode 100644 index 184de63..0000000 Binary files a/src/docbkx/resources/images/admons/important.tif and /dev/null differ diff --git a/src/docbkx/resources/images/admons/next.gif b/src/docbkx/resources/images/admons/next.gif deleted file mode 100644 index aa1516e..0000000 Binary files a/src/docbkx/resources/images/admons/next.gif and /dev/null differ diff --git a/src/docbkx/resources/images/admons/next.png b/src/docbkx/resources/images/admons/next.png deleted file mode 100644 index 45835bf..0000000 Binary files a/src/docbkx/resources/images/admons/next.png and /dev/null differ diff --git a/src/docbkx/resources/images/admons/note.gif b/src/docbkx/resources/images/admons/note.gif deleted file mode 100644 index f329d35..0000000 Binary files a/src/docbkx/resources/images/admons/note.gif and /dev/null differ diff --git a/src/docbkx/resources/images/admons/note.png b/src/docbkx/resources/images/admons/note.png deleted file mode 100644 index ad57f6f..0000000 Binary files a/src/docbkx/resources/images/admons/note.png and /dev/null differ diff --git a/src/docbkx/resources/images/admons/note.tif b/src/docbkx/resources/images/admons/note.tif deleted file mode 100644 index 08644d6..0000000 Binary files a/src/docbkx/resources/images/admons/note.tif and /dev/null differ diff --git a/src/docbkx/resources/images/admons/prev.gif b/src/docbkx/resources/images/admons/prev.gif deleted file mode 100644 index 64ca8f3..0000000 Binary files a/src/docbkx/resources/images/admons/prev.gif and /dev/null differ diff --git a/src/docbkx/resources/images/admons/prev.png b/src/docbkx/resources/images/admons/prev.png deleted file mode 100644 index cf24654..0000000 Binary files a/src/docbkx/resources/images/admons/prev.png and /dev/null differ diff --git a/src/docbkx/resources/images/admons/tip.gif b/src/docbkx/resources/images/admons/tip.gif deleted file mode 100644 index 823f2b4..0000000 Binary files a/src/docbkx/resources/images/admons/tip.gif and /dev/null differ diff --git a/src/docbkx/resources/images/admons/tip.png b/src/docbkx/resources/images/admons/tip.png deleted file mode 100644 index ad57f6f..0000000 Binary files a/src/docbkx/resources/images/admons/tip.png and /dev/null differ diff --git a/src/docbkx/resources/images/admons/tip.tif b/src/docbkx/resources/images/admons/tip.tif deleted file mode 100644 index 4a3d8c7..0000000 Binary files a/src/docbkx/resources/images/admons/tip.tif and /dev/null differ diff --git a/src/docbkx/resources/images/admons/toc-blank.png b/src/docbkx/resources/images/admons/toc-blank.png deleted file mode 100644 index 6ffad17..0000000 Binary files a/src/docbkx/resources/images/admons/toc-blank.png and /dev/null differ diff --git a/src/docbkx/resources/images/admons/toc-minus.png b/src/docbkx/resources/images/admons/toc-minus.png deleted file mode 100644 index abbb020..0000000 Binary files a/src/docbkx/resources/images/admons/toc-minus.png and /dev/null differ diff --git a/src/docbkx/resources/images/admons/toc-plus.png b/src/docbkx/resources/images/admons/toc-plus.png deleted file mode 100644 index 941312c..0000000 Binary files a/src/docbkx/resources/images/admons/toc-plus.png and /dev/null differ diff --git a/src/docbkx/resources/images/admons/up.gif b/src/docbkx/resources/images/admons/up.gif deleted file mode 100644 index aabc2d0..0000000 Binary files a/src/docbkx/resources/images/admons/up.gif and /dev/null differ diff --git a/src/docbkx/resources/images/admons/up.png b/src/docbkx/resources/images/admons/up.png deleted file mode 100644 index 07634de..0000000 Binary files a/src/docbkx/resources/images/admons/up.png and /dev/null differ diff --git a/src/docbkx/resources/images/admons/warning.gif b/src/docbkx/resources/images/admons/warning.gif deleted file mode 100644 index c6acdec..0000000 Binary files a/src/docbkx/resources/images/admons/warning.gif and /dev/null differ diff --git a/src/docbkx/resources/images/admons/warning.png b/src/docbkx/resources/images/admons/warning.png deleted file mode 100644 index ef3e10f..0000000 Binary files a/src/docbkx/resources/images/admons/warning.png and /dev/null differ diff --git a/src/docbkx/resources/images/admons/warning.tif b/src/docbkx/resources/images/admons/warning.tif deleted file mode 100644 index 7b6611e..0000000 Binary files a/src/docbkx/resources/images/admons/warning.tif and /dev/null differ diff --git a/src/docbkx/resources/images/callouts/1.png b/src/docbkx/resources/images/callouts/1.png deleted file mode 100644 index 7d47343..0000000 Binary files a/src/docbkx/resources/images/callouts/1.png and /dev/null differ diff --git a/src/docbkx/resources/images/callouts/10.png b/src/docbkx/resources/images/callouts/10.png deleted file mode 100644 index 997bbc8..0000000 Binary files a/src/docbkx/resources/images/callouts/10.png and /dev/null differ diff --git a/src/docbkx/resources/images/callouts/11.png b/src/docbkx/resources/images/callouts/11.png deleted file mode 100644 index ce47dac..0000000 Binary files a/src/docbkx/resources/images/callouts/11.png and /dev/null differ diff --git a/src/docbkx/resources/images/callouts/12.png b/src/docbkx/resources/images/callouts/12.png deleted file mode 100644 index 31daf4e..0000000 Binary files a/src/docbkx/resources/images/callouts/12.png and /dev/null differ diff --git a/src/docbkx/resources/images/callouts/13.png b/src/docbkx/resources/images/callouts/13.png deleted file mode 100644 index 14021a8..0000000 Binary files a/src/docbkx/resources/images/callouts/13.png and /dev/null differ diff --git a/src/docbkx/resources/images/callouts/14.png b/src/docbkx/resources/images/callouts/14.png deleted file mode 100644 index 64014b7..0000000 Binary files a/src/docbkx/resources/images/callouts/14.png and /dev/null differ diff --git a/src/docbkx/resources/images/callouts/15.png b/src/docbkx/resources/images/callouts/15.png deleted file mode 100644 index 0d65765..0000000 Binary files a/src/docbkx/resources/images/callouts/15.png and /dev/null differ diff --git a/src/docbkx/resources/images/callouts/2.png b/src/docbkx/resources/images/callouts/2.png deleted file mode 100644 index 5d09341..0000000 Binary files a/src/docbkx/resources/images/callouts/2.png and /dev/null differ diff --git a/src/docbkx/resources/images/callouts/3.png b/src/docbkx/resources/images/callouts/3.png deleted file mode 100644 index ef7b700..0000000 Binary files a/src/docbkx/resources/images/callouts/3.png and /dev/null differ diff --git a/src/docbkx/resources/images/callouts/4.png b/src/docbkx/resources/images/callouts/4.png deleted file mode 100644 index adb8364..0000000 Binary files a/src/docbkx/resources/images/callouts/4.png and /dev/null differ diff --git a/src/docbkx/resources/images/callouts/5.png b/src/docbkx/resources/images/callouts/5.png deleted file mode 100644 index 4d7eb46..0000000 Binary files a/src/docbkx/resources/images/callouts/5.png and /dev/null differ diff --git a/src/docbkx/resources/images/callouts/6.png b/src/docbkx/resources/images/callouts/6.png deleted file mode 100644 index 0ba694a..0000000 Binary files a/src/docbkx/resources/images/callouts/6.png and /dev/null differ diff --git a/src/docbkx/resources/images/callouts/7.png b/src/docbkx/resources/images/callouts/7.png deleted file mode 100644 index 472e96f..0000000 Binary files a/src/docbkx/resources/images/callouts/7.png and /dev/null differ diff --git a/src/docbkx/resources/images/callouts/8.png b/src/docbkx/resources/images/callouts/8.png deleted file mode 100644 index 5e60973..0000000 Binary files a/src/docbkx/resources/images/callouts/8.png and /dev/null differ diff --git a/src/docbkx/resources/images/callouts/9.png b/src/docbkx/resources/images/callouts/9.png deleted file mode 100644 index a0676d2..0000000 Binary files a/src/docbkx/resources/images/callouts/9.png and /dev/null differ diff --git a/src/docbkx/resources/images/logo.png b/src/docbkx/resources/images/logo.png deleted file mode 100644 index a9f6d95..0000000 Binary files a/src/docbkx/resources/images/logo.png and /dev/null differ diff --git a/src/docbkx/resources/images/xdev-spring_logo.jpg b/src/docbkx/resources/images/xdev-spring_logo.jpg deleted file mode 100644 index 622962e..0000000 Binary files a/src/docbkx/resources/images/xdev-spring_logo.jpg and /dev/null differ diff --git a/src/docbkx/resources/xsl/fopdf.xsl b/src/docbkx/resources/xsl/fopdf.xsl deleted file mode 100644 index 0a90bfb..0000000 --- a/src/docbkx/resources/xsl/fopdf.xsl +++ /dev/null @@ -1,449 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - , - - - - - - - - - Copyright © 2011 - - - - - - - - - - - - - - - - - - - - - - - - - - - - -5em - -5em - - - - - - - - - - - Spring Data Document () - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 0 - - 1 - 1 - 0 - - - - - - book toc - - - - 2 - - - - - - - - - - 0 - 0 - 0 - - - 5mm - 10mm - 10mm - - 15mm - 10mm - 0mm - - 18mm - 18mm - - - 0pc - - - - - justify - false - - - 11 - 8 - - - 1.4 - - - - - - - 0.8em - - - - - - 17.4cm - - - - 4pt - 4pt - 4pt - 4pt - - - - 0.1pt - 0.1pt - - - - - 1 - - - - - - - - left - bold - - - pt - - - - - - - - - - - - - - - 0.8em - 0.8em - 0.8em - - - pt - - 0.1em - 0.1em - 0.1em - - - 0.6em - 0.6em - 0.6em - - - pt - - 0.1em - 0.1em - 0.1em - - - 0.4em - 0.4em - 0.4em - - - pt - - 0.1em - 0.1em - 0.1em - - - - - bold - - - pt - - false - 0.4em - 0.6em - 0.8em - - - - - - - - - pt - - - - - 1em - 1em - 1em - #444444 - solid - 0.1pt - 0.5em - 0.5em - 0.5em - 0.5em - 0.5em - 0.5em - - - - 1 - - #F0F0F0 - - - - - - 0 - 1 - - - 90 - - - - - '1' - src/docbkx/resources/images/admons/ - - - - - - figure after - example before - equation before - table before - procedure before - - - - 1 - - - - 0.8em - 0.8em - 0.8em - 0.1em - 0.1em - 0.1em - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/src/docbkx/resources/xsl/highlight-fo.xsl b/src/docbkx/resources/xsl/highlight-fo.xsl deleted file mode 100644 index 09d8089..0000000 --- a/src/docbkx/resources/xsl/highlight-fo.xsl +++ /dev/null @@ -1,44 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \ No newline at end of file diff --git a/src/docbkx/resources/xsl/highlight.xsl b/src/docbkx/resources/xsl/highlight.xsl deleted file mode 100644 index c63c476..0000000 --- a/src/docbkx/resources/xsl/highlight.xsl +++ /dev/null @@ -1,42 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - \ No newline at end of file diff --git a/src/docbkx/resources/xsl/html.xsl b/src/docbkx/resources/xsl/html.xsl deleted file mode 100644 index d3250c7..0000000 --- a/src/docbkx/resources/xsl/html.xsl +++ /dev/null @@ -1,107 +0,0 @@ - - - - - - - - - - - 0 - 0 - 1 - - - - - - book toc - - - - 3 - - - - - 1 - - - - - - - 1 - - - 90 - - - - - 1 - images/admons/ - - - - figure after - example before - equation before - table before - procedure before - - - - , - - - - - - - - -
-

Authors

-

- -

- - - - -
- - - - - - -
- - - - diff --git a/src/docbkx/resources/xsl/html_chunk.xsl b/src/docbkx/resources/xsl/html_chunk.xsl deleted file mode 100644 index 29b35d2..0000000 --- a/src/docbkx/resources/xsl/html_chunk.xsl +++ /dev/null @@ -1,221 +0,0 @@ - - - - - - - - - - '5' - '1' - 0 - 0 - 1 - - - - book toc - qandaset toc - - - 3 - - - 1 - - - - - 1 - 90 - - - - - 1 - images/admons/ - - - - figure after - example before - equation before - table before - procedure before - - - - , - - - - () - - - - - -
-

Authors

-

- -

- - - - - - - - - 1 - - - - - - - - - - -
- -
- - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - -   - - - - - - - - - - - - - - -  |  - - -   - - - - - - - - -toc - - - - - - - - -   - - - - - - - - - - - - -
- - - -   - - - Sponsored by SpringSource - - - -   - - - -
- -
- - -