From c2ba752725b6b61a8c3a77f7600e2b4b2a180793 Mon Sep 17 00:00:00 2001 From: dsyer Date: Tue, 4 Dec 2007 18:54:55 +0000 Subject: [PATCH] Updated site (tidied and added migration guide) for m3 release. --- src/.project | 5 + src/site/apt/changelog.apt | 4 + src/site/apt/getting-started.apt | 10 + src/site/apt/migration/1.0-m2-m3.apt | 67 +++ src/site/fml/faq.fml | 629 +++++++++++++-------------- src/site/ppt/Figures.ppt | Bin 90112 -> 94720 bytes src/site/site.xml | 5 +- 7 files changed, 403 insertions(+), 317 deletions(-) create mode 100644 src/site/apt/getting-started.apt create mode 100644 src/site/apt/migration/1.0-m2-m3.apt diff --git a/src/.project b/src/.project index 44c6d4e5f..8aaaa6d5e 100644 --- a/src/.project +++ b/src/.project @@ -19,5 +19,10 @@ 1 PARENT_DIR/pom.xml + + parent + 2 + PARENT_DIR/parent + diff --git a/src/site/apt/changelog.apt b/src/site/apt/changelog.apt index 8f2bd585c..6ee9c36cb 100644 --- a/src/site/apt/changelog.apt +++ b/src/site/apt/changelog.apt @@ -1,3 +1,7 @@ Changelog: Spring Batch See the changes report generated from {{{issue-tracking.html}JIRA}}. + + There is a pre-built {{{http://opensource.atlassian.com/projects/spring/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=10090&status=5&status=6&updated:previous=-1w&sorter/field=updated&sorter/order=DESC}Resolved Recently}} query that might be useful. + + You can also browse the upcoming releases and look at the {{{http://opensource.atlassian.com/projects/spring/browse/BATCH?report=com.atlassian.jira.plugin.system.project:roadmap-panel}Road Map}} query. diff --git a/src/site/apt/getting-started.apt b/src/site/apt/getting-started.apt new file mode 100644 index 000000000..55f3fd6ff --- /dev/null +++ b/src/site/apt/getting-started.apt @@ -0,0 +1,10 @@ + ------ + Spring Batch Getting Started + ------ + Dave Syer + ------ + December 2007 + +Spring Batch Getting Started + +* Work in Progress diff --git a/src/site/apt/migration/1.0-m2-m3.apt b/src/site/apt/migration/1.0-m2-m3.apt new file mode 100644 index 000000000..0629cebb9 --- /dev/null +++ b/src/site/apt/migration/1.0-m2-m3.apt @@ -0,0 +1,67 @@ + ------ + Spring Batch Upgrade + ------ + Robert Kasanicky + ------ + December 2007 + +Updating Spring Batch from 1.0-m2 to 1.0-m3 + + This is a description of what needed to be done to migrate the samples from m2 to the new m3 release. + + [Tip:] if you use SpringIDE, make sure it tracks all your configuration files, +so that errors are immediately visible. + +* VARIOUS + + * OutputSource interface has been renamed to ItemWriter, implementations have been renamed correspondingly +(e.g. FlatFileOutputSource is now FlatFileItemWriter). ItemWriter no longer extends ResourceLifecycle +(which declares methods open() and close). Often you don't need to call these methods at all, in case +you do you should implement InitializingBean and DisposableBean interfaces and declare the bean +in step scope. + + * Sql renamed to Jdbc (e.g. SqlInputSource -> JdbcInputSource). + + * Database input sources split into driving and cursor packages (cursor makes a single query and iterates +over the result set, driving query for keys and then make a new query for each key). + + * ExceptionHandler interface has been changed to handle single throwable instead of a collection of throwables +and it has become responsible for deciding about step completion. See javadoc for more details. + + * FlatFileInputSources now include FieldSet mapping logic - you can inject a FieldSetMapper +into the input source, so you no longer need to handle this in ItemProvider. Therefore +FieldSetInputSource interface and FlatFileItemProvider have been removed. Where FlatFileItemProvider +was used you can use the InputSourceItemProvider and inject the mapper into the input source. + + * Validation has been removed from input sources and moved upwards to ValidatingItemProvider. + + * XML related classes have been moved from io.stax package under io.file + + * Fixed-length tokenizer accept ranges property instead of array of lengths, e.g. "2,3" +(see javadoc for more details and fixedLengthImportJob.xml for example usage). + + +* CONTAINER CONFIGURATION + + * Use the value of JobConfiguration name property as the bean id. + + * Simplest approach to update is to use the simple-container-definition.xml, +data-source-context.xml (plus hibernate-context.xml) and batch.properties +from M3 samples and replace the post-processor bean in your job xml file with +"\" + + * JobLauncher has been moved from execution.bootstrap to execution.launch + + * JobExecutor facade has been removed, it's properties are now injected directly +into SimpleJobLauncher intead of the facade itself. + + * DefaultStepExecutorFactory is now SimpleStepExecutorFactory located in simple subpackage +and needs a reference to jobRepository instead of value for StepExecutor name. + + * ScheduledJobIdentifier has a new jobKey property replaces jobRun and jobStream. + + * SimpleStepConfiguration has been moved one package up (from execution.step.simple to execution.step). + + * Transaction manager class is specified in batch.properties + + diff --git a/src/site/fml/faq.fml b/src/site/fml/faq.fml index db6c3cde9..a9c6df090 100644 --- a/src/site/fml/faq.fml +++ b/src/site/fml/faq.fml @@ -1,315 +1,314 @@ - - - - - - When will Batch 1.0 be out? My understanding is that the - current product can be used on projects, is that - correct? - - - We expect m3, m4, rc1 before 1.0 final, so realistically - not soon. You can track the progress and planning in - JIRA - (http://opensource.atlassian.com/projects/spring/browse/BATCH). - But it is already usable at m2 as long as there is an - understanding that upgrading might take a small amount - of effort - there are 5 or 6 projects using it, with at - least one in production. That project upgraded from m1 - to m2 (which was distinctly less trivial than m2 to m3 - is likely to be) in less than a day. We intend to keep - changes from here to 1.0 as close to internal as - possible, so the client touch points are pretty stable. - - - - - How stable are the interfaces in Spring Batch? - - -

- We are still in the milestone release phase (1.0-m3 - is in the pipeline). This means that we are still - adding functionality that we want to be part of a - 1.0 release. We do not rule out changes to package - and interface names in this phase, but that said we - think the basic domain concepts in Spring Batch are - sound enough to survive significant re-factoring. - The bulk of the application developer "touch points" - have been stable for quite some time now, and we - have several early adopter projects already using - snapshot releases. -

-

- The process from here is to collect feedback from - the community and use that to decide on what extra - features need to be added to get us to 1.0. When we - are feature complete we will move to the "release - candidate" phase, and the first release in that - phase will be 1.0-rc1. When significant issues are - resolved (if there are any) we will promote the - release through the "rc" numbers, until we have a - clean 1.0 release. -

- - - - - When will support for the more complex job execution - classes appear? Our Client has a number of - multi-threaded batch jobs. - - - Multi-threaded execution in a single VM is perfectly - possible with 1.0 - but we recommend exercising caution - in the analysis of such requirements (is it really - necessary?). Several people have tried it and we haven't - had any issues yet (except documentation requests). - - - - - There are 4 main layers of the architecture - (application, core, execution, and infrastructure), what - is the vision for how the execution layer might be used - in future? What happened to the "container" layer? - - -

- The "layers" described are nicely segregated in - terms of dependency. Each layer only depends (at - compile time) on layers below it. -

-

- We recognised that what we used to call the - container layer actually is composed of two distinct - contexts, "Core" and "Execution". So the full - catalogue of contexts is: -

    -
  • - Application - is the business logic. It is written by the - application developer - the client of Spring - Batch - and only depends on the other Core - interfaces for compilation and - configuration. -
    • -
  • - Core - is the public API of Spring Batch, including - the core batch domain of Job, Step, - configuration and Executor interfaces. -
    • -
  • - Execution - is the deployment, execution and management - concerns. Different execution environments - (e.g. in a JEE container, out of container) - are configured differently, but can execute - the same application business logic. -
    • -
  • - Infrastructure - is a set of low level tools, that are used - to implement the execution and parts of the - core layers. -
    • -
-
-

-

- The "execution" layer is fertile ground for - collaboration and contributions from the community - and from projects in the field. The central - interface is - JobExecutorFacade - with methods for starting and stopping jobs. The - vision for this is that there can be multiple - implementations of - JobExecutorFacade - providing different architectural patterns, and - delivering different levels of scalability and - robustness, without changing either the business - logic or the job configuration. The initial 1.0 - release of Spring Batch will have a single - implementation - SimpleJobExecutorFacade - (formerly known as - SimpleBatchContainer - .) -

- - - - - What is the Spring Batch philosophy on the use of - flexible strategies and default implementations? - - - There are a great many extension points in Spring Batch - for the framework developer (as opposed to the - implementor of business logic). We expect clients to - create their own more specific strategies that can be - plugged in to control things like commit intervals ( - CompletionPolicy - ), rules about how to deal with exceptions ( - ExceptionHandler - ), and many others. - - - - - How does Spring Batch differ from Quartz? Is there a - place for them both in a solution? - - -

- Spring Batch and Quartz have different goals. Spring - Batch provides functionality for processing large - volumes of data and Quartz provides functionality - for scheduling tasks. So Quartz could complement - Spring Batch, but are not excluding technologies. A - common combination would be to use Quartz as a - trigger for a Spring Batch job using a Cron - expression and the Spring Core convenience - SchedulerFactoryBean - . -

- - - - - How do I schedule a job with Spring Batch? - - -

- Use a scheduling tool. There are plenty of them out - there. Examples: Quartz, Control-M, Autosys. Quartz - doesn't have all the features of Control-M or - Autosys - it is supposed to be lightweight. If you - want something even more lightweight you can just - use the OS (cron, at, etc.). -

-

- Simple sequential dependencies can be implemented - using the job-steps model of Spring Batch. We think - this is quite common. And in fact it makes it easier - to correct a common mis-use of scehdulers - having - hundreds of jobs configured, many of which are not - independent, but only depend on one other. -

- - - - - How will Spring Batch allow project to optimize for - performance and scalability (through parallel processing - or other)? - - - We see this as one of the roles of the Execution layer. - A specific implementation (or implementations) of the - StepExecutor - can deal with the concern of breaking apart the business - logic and sharing it efficiently between parallel - processes or processors. There are a number of - technologies that could play a role here. The essence is - just a set of concurrent remote calls to distributed - agents that can handle some business processing. Since - the business processing is already typically modularised - - e.g. input an item, process it - Spring Batch can - strategise the distribution in a number of ways. One - implementation that we have had some experience with - (and have a prototype for) is a set of remote EJBs - handling the business processing. We switch off Home - caching in the container and then send a specific range - of primary keys for the inputs to each of a number of - remote calls. THe same basic strategy would work with - any of the Spring Remoting protocols (plain RMI, - HttpInvoker, JMS, Hessian etc.) with little more than a - couple of lines change in the execution layer - configuration. - - - - - What are the key concepts in the Spring Batch core - domain? - - -

- In a nutshell: A JobConfiguration with a list of - StepConfigurations is passed to an ExecutionService. - From this a Job is constructed consisting of a - series of Steps, each of which is executed by a - StepExecutor. The StepExecutor contains all the - strategies for deciding when to complete, when to - commit, when to abort and when to continue. -

-

- Many Jobs in practice consist of a single Step. Step - is very useful and best practice for breaking a Job - down into logical units, rather than having to - execute separate Jobs (potentially in separate OS - processes) which have no obvious logical connection. -

-

- Jobs can be executed once, or many times with - different logical identifiers (JobIdentifier). It is - also possible to restart a failed Job with the same - or a modified input source, and identify the - resulting JobExecution as a separate entity. In this - way the progress of a Job and its history of - successful and failed executions can easily be - tracked. The same argument applies to Steps, which - have their corresponding StepExecution entity. -

- - - - - How can messaging be used to scale batch architectures? - - - There is a good deal of practical evidence from existing - projects that a pipeline approach to batch processing is - highly beneficial, leading to resilience and high - throughput. We are often faced with mission-critical - applications where audit trails are essential, and - guaranteed processing is demanded, but where there are - extremely tight limits on performance under load, or - where high throughput gives a competitive advantage. - Matt Welsh's work shows that a Staged Event Driven - Architecture (SEDA) has enormous benefits over more - rigid processing architectures, and message-oriented - middleware (JMS, AQ, MQ, Tibco etc.) gives us a lot of - resilience out of the box. There are particular benefits - in a system where there is feedback between downstream - and upstream stages, so the number of consumers can be - adjusted to account for the amount of demand. So how - does this fit into Spring Batch? Well it's a good - example of an - StepExecutor - or (more broadly) execution runtime if the deployment is - grid- or cluster-based, or in any way involves multiple - OS processes. - - - - How can I contribute to Spring Batch? - - Use JIRA and the forum to get involved in discussions - about the product and its design. There is a process for - contributions and eventually becoming a committer. The - process is pretty standard for all Apache-licensed - projects. You make contributions through JIRA (so sign - up now); you assign the copyright of any contributions - using a standard Apache-like CLA (see the Apache one for - example - ours might be slightly different); when the - contributions reach a certain level, or you convince us - otherwise that you are going to be committed long term, - even if part time, then you can become a committer. - - - - + + + + + + When will Batch 1.0 be out? My understanding is that the + current product can be used on projects, is that + correct? + + + We expect m3, m4, rc1 before 1.0 final, so realistically + not soon. You can track the progress and planning in + JIRA + (http://opensource.atlassian.com/projects/spring/browse/BATCH). + But it is already usable at m3 as long as there is an + understanding that upgrading might take a small amount + of effort - there are 5 or 6 projects using it, with at + least one in production. That project upgraded from m1 + to m2 in less than a day. We intend to keep changes from + here to 1.0 as close to internal as possible, so the + client touch points are pretty stable. + + + + + How stable are the interfaces in Spring Batch? + + +

+ We are still in the milestone release phase (1.0-m4 + is in the pipeline). This means that we are still + adding functionality that we want to be part of a + 1.0 release. We do not rule out changes to package + and interface names in this phase, but that said we + think the basic domain concepts in Spring Batch are + sound enough to survive significant re-factoring. + The bulk of the application developer "touch points" + have been stable for quite some time now, and we + have several early adopter projects already using + snapshot releases. +

+

+ The process from here is to collect feedback from + the community and use that to decide on what extra + features need to be added to get us to 1.0. When we + are feature complete we will move to the "release + candidate" phase, and the first release in that + phase will be 1.0-rc1. We only expect one release + candidate, but if there is enough demand for new + features, or significant problems occur in rc1, then + we might need an rc2. We aim for 2 weeks elapsed + time between release candidates (and between the + last milestone and rc1). +

+ + + + + When will support for the more complex job execution + classes appear? Our Client has a number of + multi-threaded batch jobs. + + + Multi-threaded execution in a single VM is perfectly + possible with 1.0 - but we recommend exercising caution + in the analysis of such requirements (is it really + necessary?). Several people have tried it and there are + some issues with restartability (plus the usual + documentation requests), but otherwise it should work. + With a little more effort starting in m4 it should work + even better, but we aren't planning to solve the + restartability problem until after 1.0. + + + + + There are 4 main layers of the architecture + (application, core, execution, and infrastructure), what + is the vision for how the execution layer might be used + in future? What happened to the "container" layer? + + +

+ The "layers" described are nicely segregated in + terms of dependency. Each layer only depends (at + compile time) on layers below it. +

+

+ We recognised that what we used to call the + container layer actually is composed of two distinct + contexts, "Core" and "Execution". So the full + catalogue of contexts is: +

    +
  • + Application + is the business logic. It is written by the + application developer - the client of Spring + Batch - and only depends on the other Core + interfaces for compilation and + configuration. +
    • +
  • + Core + is the public API of Spring Batch, including + the core batch domain of Job, Step, + configuration and Executor interfaces. +
    • +
  • + Execution + is the deployment, execution and management + concerns. Different execution environments + (e.g. in a JEE container, out of container) + are configured differently, but can execute + the same application business logic. +
    • +
  • + Infrastructure + is a set of low level tools, that are used + to implement the execution and parts of the + core layers. +
    • +
+
+

+

+ The "execution" layer is fertile ground for + collaboration and contributions from the community + and from projects in the field. The central + interface is + JobLauncher + with methods for starting and stopping jobs. The + vision for this is that there can be multiple + implementations of + JobLauncher + providing different architectural patterns, and + delivering different levels of scalability and + robustness, without changing either the business + logic or the job configuration. +

+ + + + + What is the Spring Batch philosophy on the use of + flexible strategies and default implementations? + + + There are a great many extension points in Spring Batch + for the framework developer (as opposed to the + implementor of business logic). We expect clients to + create their own more specific strategies that can be + plugged in to control things like commit intervals ( + CompletionPolicy + ), rules about how to deal with exceptions ( + ExceptionHandler + ), and many others. + + + + + How does Spring Batch differ from Quartz? Is there a + place for them both in a solution? + + +

+ Spring Batch and Quartz have different goals. Spring + Batch provides functionality for processing large + volumes of data and Quartz provides functionality + for scheduling tasks. So Quartz could complement + Spring Batch, but are not excluding technologies. A + common combination would be to use Quartz as a + trigger for a Spring Batch job using a Cron + expression and the Spring Core convenience + SchedulerFactoryBean + . +

+ + + + + How do I schedule a job with Spring Batch? + + +

+ Use a scheduling tool. There are plenty of them out + there. Examples: Quartz, Control-M, Autosys. Quartz + doesn't have all the features of Control-M or + Autosys - it is supposed to be lightweight. If you + want something even more lightweight you can just + use the OS (cron, at, etc.). +

+

+ Simple sequential dependencies can be implemented + using the job-steps model of Spring Batch. We think + this is quite common. And in fact it makes it easier + to correct a common mis-use of scehdulers - having + hundreds of jobs configured, many of which are not + independent, but only depend on one other. +

+ + + + + How will Spring Batch allow project to optimize for + performance and scalability (through parallel processing + or other)? + + + We see this as one of the roles of the Execution layer. + A specific implementation (or implementations) of the + StepExecutor + can deal with the concern of breaking apart the business + logic and sharing it efficiently between parallel + processes or processors. There are a number of + technologies that could play a role here. The essence is + just a set of concurrent remote calls to distributed + agents that can handle some business processing. Since + the business processing is already typically modularised + - e.g. input an item, process it - Spring Batch can + strategise the distribution in a number of ways. One + implementation that we have had some experience with + (and have a prototype for) is a set of remote EJBs + handling the business processing. We switch off Home + caching in the container and then send a specific range + of primary keys for the inputs to each of a number of + remote calls. The same basic strategy would work with + any of the Spring Remoting protocols (plain RMI, + HttpInvoker, JMS, Hessian etc.) with little more than a + couple of lines change in the execution layer + configuration. + + + + + What are the key concepts in the Spring Batch core + domain? + + +

+ In a nutshell: A JobConfiguration with a list of + StepConfigurations is passed to a JobExecutor. + From this a Job is constructed consisting of a + series of Steps, each of which is executed by a + StepExecutor. The StepExecutor contains all the + strategies for deciding when to complete, when to + commit, when to abort and when to continue. +

+

+ Many Jobs in practice consist of a single Step. Step + is very useful and best practice for breaking a Job + down into logical units, rather than having to + execute separate Jobs (potentially in separate OS + processes) which have no obvious logical connection. +

+

+ Jobs can be executed once, or many times with + different logical identifiers (JobIdentifier). It is + also possible to restart a failed Job with the same + or a modified input source, and identify the + resulting JobExecution as a separate entity. In this + way the progress of a Job and its history of + successful and failed executions can easily be + tracked. The same argument applies to Steps, which + have their corresponding StepExecution entity. +

+ + + + + How can messaging be used to scale batch architectures? + + + There is a good deal of practical evidence from existing + projects that a pipeline approach to batch processing is + highly beneficial, leading to resilience and high + throughput. We are often faced with mission-critical + applications where audit trails are essential, and + guaranteed processing is demanded, but where there are + extremely tight limits on performance under load, or + where high throughput gives a competitive advantage. + Matt Welsh's work shows that a Staged Event Driven + Architecture (SEDA) has enormous benefits over more + rigid processing architectures, and message-oriented + middleware (JMS, AQ, MQ, Tibco etc.) gives us a lot of + resilience out of the box. There are particular benefits + in a system where there is feedback between downstream + and upstream stages, so the number of consumers can be + adjusted to account for the amount of demand. So how + does this fit into Spring Batch? Well it's a good + example of an + StepExecutor + or (more broadly) execution runtime if the deployment is + grid- or cluster-based, or in any way involves multiple + OS processes. + + + + How can I contribute to Spring Batch? + + Use JIRA and the forum to get involved in discussions + about the product and its design. There is a process for + contributions and eventually becoming a committer. The + process is pretty standard for all Apache-licensed + projects. You make contributions through JIRA (so sign + up now); you assign the copyright of any contributions + using a standard Apache-like CLA (see the Apache one for + example - ours might be slightly different); when the + contributions reach a certain level, or you convince us + otherwise that you are going to be committed long term, + even if part time, then you can become a committer. + + + + diff --git a/src/site/ppt/Figures.ppt b/src/site/ppt/Figures.ppt index e3c0c354e8c9b5fb493891cf536d47b4aec5c9b8..519f59798204fd66e97a6fa0590fc8a4f61d020d 100644 GIT binary patch delta 5738 zcmb6-3s_Xuy6fM2%`h_zFatOY$WuT;1{f3#jPQ{iIljOok12#CCVIR{K04-;lC%e> zkfm%jN>NJ6CvKI>7d|>_8bVq})0>d?GCYl`9Y0IC|Jr*GjCRlczB}KyX089Z{@42V zUc0nWS9(QP;e*jYOLJgERzML66uE=lC&#U?{p0O@wX?Bp>2t?%gQxP6bM z>mH}$`F?NeUV##3*H88dK`O-|;4sNfy_YE1VPm=x0&a+bh~vAve@HjAPRK+{lZ^0({Ou%}eC1150*%*HZ+t@AK>x?(onxknA zVIAFu(xdqqCWT?PEnGm}lfjv+#kPzupA3ql%}=RhX^jo+1`&PKb5cuClW}BRhG{vE z2+Q$LWMA0Bz1oeQ`kyl9IXpQw2lEZ&lfh1bwt9I3YxyyUWrsFWXPGxhAVQivBCG^x z<9_t1ZCx5W_=#S=8*TyGDx4s)HF6Hna-S1~S#!s+OHtS8j9v)9=rq|7?GS|PMz(ce zypZ9?3S&c(OjrtD#O(AVW;)iFmyF;VfpZBMTn6+a07oF!gdY)I5Bo6dcL`9$+G1^j zP{amJN~+Azv!6dSR}RsKvy@1NyY_y2gKX0R@H_+j>b(uaB4dZD){Q@OY(-`y#NW*F-C9`HeKdorWY@f-+ zbD#a|Y(i@Mcv)F+s6TZj5Ho@wC^SD-zdV|4@0ld%ir9-)p&`BLDN-xEtLKK!K{kJ? z8mcd1KbOuIyo%V0UN(As6Q)m#F1s6E9%;ZRlzL+piMOjiiVcI0;t9!uL9QC|XE>b0 zR`gB|);%O-iHCJuwZ$U_Ml}Xm@1ss@0C!BH)qvoCG@HLW zLfR;TowYi{SzQmaU@l?@N84!Yd#DmCgBhaB1fL>SlQ=SDzwUkGv)-x|-X2!?sy;Ms z!veB8M^{E03~l00`nqndm(&VixA@>ziVZnxlGuv+0@j*f7W~}qmFuQ>{ZX;ST_B!{ zi@Y8&Xo~$h6+bp_%H+9oSVjFL*7&p!7NQ!pOhdClRqI(${%S$Z`vuji1$9RM55t26 zHAPYR|1PLl-xl=NUAqD5R&|H9t-9$x)+KuJGVpN~@C1eEkXtEPcXsrMP=4&DBc06{ z$Gx!zW@Z);oohW3fcU%Y%8Z=^D^JA1E0A{<{&UlLqvbST99TvLb++C{T$*wC;NWCF z-0T$BoYjH@(^7ibX5vdOVl9%AEl{iV2e}|NOQ5%hE$VDBcnC__w7A|ha4aJ6B(rOA zyJ*Q@6pl>!a=brKb1Ek(#UW=WL;?N%iA5%Pj$?s9%eEtlcQV&)Gs{jsKvy3^lGV8s z=(&G*kZz_Npspi|nmpORFX|Y7Zjp(%y`gMD>Kz*T9nvtLtfAi)dV3pZ%pE81@4p#n z*$sqvpQ}x4LI~6rD4!Z&0$Qs>2*qT31{2XodF#Lqpfe_5*VgRS56Km1;A>ZvF2!~Y zJw&TdaX|Iv^kcC=sjo&IJ?s!ojq9RL%ZdP+6O0IM*{6SANn_GD6)pR4_`^Um1|Y;O zOCE`q9eqrJ&eGyB8rqs|0D5yGLR@}gP9wdTj{pW)o;#)o(2*7my8d`5P($%mqioGB z1sXXO@%8b2C$9{ViRkNt~Fl4CoI(_vBqwc~tOb#=`Q;sD&VsZ}D4x z7;XUwaT9Y3ih=G6RB6msxQ`klG)BkM;kaj%#<*-U`cmiMG6jRGy1NS>>FSl>D93a!0fOO7)eO%^eIh_ie<$XeTRh`pU+? zwPIO*(1l?MFI3aOj3^J5`MyBgEm4}%f(4B{eGl8YbBQ7@er%_8uIBX5olK_K;zr1Y^;n@-7QafAH#asS%*>j0R?#g>J$R1Fc*aX!^Wc$_ zc4OzO{T`WkTvqH6fRYs&^hLv00=2AEA+~E{1$%MtVmfq#MjpKH8KA2_K&YjPKc;0k z@Lgvl{108hMBPSWSD_pbOA1diOXL`>aCiWoV2jQUVd5vH^x~A0-dd^Lr7`mm;Lcl) zeL`DHI{}NFe%y}b{nANq)z5(!%xukx8d|)P^I&k^`1BraUE?Mve`c1?p2Vi||jOu|r@Io-q56_?Rmh&$D38VkL zMqp?=yZYa6QO6Ze%x7O$i>{tBTd^vgbIA3VVnGc3tqT#})*YagjoFjNEN#AW={MAU zdfE1G_t8nMC)CJt$4-8?ht9d%g^=66w_I<7^Rn=s%n}tk$hew zw_TkEV$As(ZiT$89YCDdUc;eJo~NQDFJ>zlP$8DBPqz-m_h`w44K2 zF>KONgFNcG1E_1dM&=icy}#f=HO$+jK8odlo7k=LO5Na+TW0LDe@A|;ud`#n9;Iii zxJvD){Pgdg;=3v=yKZByF7D8z*`YfdXz1Q9UirvxSQ_O=5o3*XV4`A_vo+*yJw4TQ zKT;lh4|l%Otg1?r-|E0X&AY5=UUd_yY0=esx`)Y7QjUK!}Fnq(TVVJ=TgLKskz86NeyWxfaBa8xJ z*DW_f+F*ieah}VJ)%KT$)!u*+TYb~a4^w6XTK$EV|6bDX7B~fGq!U(%rx_zMOwzAb zNJB)jKMVwDnCTB|0B@|4DG=hQ{XJ}hhwPBaF<(c(!vGR;gf}z?!U7Q9H%X&x$VTts zN@2tKBO45Iv)O|<8_KS-BU_mtuH4!n7zVr93WGTto~ExuAWkf~dO{i;0|Pl?cz1Zz z&9$Yw#uXoiT%^OSaDiME3}I4z7=~Lj?pBz#>#PXeweAM?I`^)gKBPrzY}o$dXnRtZ zaSc&D;D%ziEe1(jM&UDG)3E8K7~EzMHvaTXeAxwZUF26+^=j**Tx}2FMTTE(_uyQr zU2XZRw1{6s_|DR11D5SDREE-4@qCeLGMJ@ki9?cK$bzs zW$~??4qJ`^Uk|!ddt+C>MRBtDp;Yada=}=#ZXDh7b^?<-Gw-m&WviAfv8R=mH8E-9kF)ZZZr5 zorIj-rDqeM1U{55B|tYs9qNMzM5E+5Amahl4-QC0R9GT}d1!w$5fVJKKd`ry2+1DQ z(}`Vs_ep{wnjZ8;QHxWXQ!%AJ30{wK`zkIkWI#qk!qR#FBX?R>LQc4;ug>BOA zGF)d9cwGl@vEHz~^=HKUB?!|1)nz?J8bN2uJ-~M0w-}|0Z zbls-NWV12~ww6VE+iW3()YU&L0}Ns|nzyL_!7+QbQghtj0EF})q%97gglOBE@lJCI z>4nc(h`F-G(qWcKk3F>pk$k*5pEx9jZO80wi(QD@0bP`k#cy6mM@L-;8)@?w`rude zQf0FoJXx4_ntV;$pwawB*4K0gdB5EeO6LYO+Os82o=o=hVpm*z**86WH3&WIQB1Q! z72R|p-*P%hulHBv4A#wA;fzYvvsJzHEXO&Ew#Axt;G*dKUEZTbDQ4_ZCl|;KE+=+)ZOzk@Ton44c?X{|6`e)bj^LnTgZnFNy>OywXYRihidQ^hzVk{Bf{+%BKLRewlE#KZ#|}Dq#+O#dOhP1nz{4m2dg^0xe#v zNPf)lYAl-;@B_{K0D+n*adJsughmsrWA)8_Qq8<@tp`8;+S__i>H1{44W}=<&TlsylCu?fvX>db>rT zs=kXRB;e%Rh}2Apmmf|%4m1@4lt>v&sicdf0G(Vj#Q;*JYk*R2tSAf2HPOo6NE7Qe zBrgEyqHwdccd8!fgRr^Q^!nw81FgJ{>D|fcFPHvxjwQXw8JKv(3ZX$eWi#Idnz#-n zY!5kmmJ{k~&AP)c`2fwAQ4%H8&z=snd_a>jk6kWkpx4tBhhyctuV549`lBR>qvv3) zza4A|<}z*gyQT1PY{9&ZH2s1_8!IoEf6~%pa~Ajko#Zpsof2PW2ikE3p7i$%bWP zuG9B)=@tFW(&}--K_}wWqBp7^s@r;>9-w0iVM%Sms2%>1mB7Z>UjWj-dAy-78ROH;k3qNS>b`|)+$yB6HFOap!)Ut&iucP_zKf%_@uW#-T zQdIe4Z26Zhb|C3X)L_LClf2azq=HRWpz0GXNF}?hz>RIsNK)HpiXFK?_5#W8m_^Hu z@2sThM-=yCYZ18Qr|=d#vwyJ&=OARch%U&C$MTTqhO%2qAQ`=*ArL@7qp zv>voOvZ)t-md3{lQkq;vJ|&t zSxcLiUAtOO&lXq#`R=vFAWfR5()WJRJLZ52Z^p1St-I*%EaUvi2<6nD%RAd_@io-My8O?VH zQX8zjUB~V{tfwV*Dj>JF7s+R@fGrgdak^p=O!~bhzuD2*>TZBb#{9F%TnOi25H~GPFXyj%7 z&_|m4ppl;r2N&M#4p7^SyxloA3-0!a#j z1eP$&OsohJM1LK33qfKz$B{zB=aLXGu-6jI#Fh}V#mQkvtleQILI9r>2|oP$FbHOg z$C=4}`UrBMj&BS{^7vL939H=#b>ba(r1B2T!}~&CtNpos#gt$jzY~E|?)Jx#m;%AV z{!n4sh?$ju=BPc7?+0O;xP81i91KE!ET!F1!cew7UmOi#QgcSOs8e#cY~}SkM{#Y0 z{%}#@Tpl1eM<3%D)bOUpKr3H42xy`BssZAMcS4eF@%x83k&DjwPESnak|!bkN(gCp z1QOE|$izTG=DPqnGlY_LgD6#m6eRoZZ$LtJe817TdrBA68=ge z3_$aF$>7mlof!!>{4+Gz-C~g6NP!VRc}gny^C?4MrbodbH*y`#s{v>`J#$EfWF&$C zym@>QB#Lnt=u8sCAhdNT_;hg=nGAiqIQv5=OOl~q7i~_u5(;{lY&L-zDi%G6B}L57 zk|O164X|Q}noJ~U%(1GmTdPF>Yn7&@{8^QZDSuWaCHah@FyViV@4KNet>+W*aV1lt z)^g7_^1j>SK#dQ|#jajNsZZis7(4MD_f)ajt6ikBd#*_(g*1_w3j{qdO z;+116yY^!s5Ib^Ll5n3H^%Ee%nf{JDjz2vM^tNJDi9}v73p^ERgOFCD)KlmlnXgX} v{k=YK1gw4;?!tP0?`0?i#$TNcOEu0xynQw-(5^)eapKW&kYQ{pz%B6~rH1mr diff --git a/src/site/site.xml b/src/site/site.xml index 9668a2333..2d530dcdf 100644 --- a/src/site/site.xml +++ b/src/site/site.xml @@ -28,9 +28,10 @@ - + - + +