(no commit message)
[utils] / src / site / xdoc / index.xml
1 <?xml version="1.0"?>
2 <document xmlns="http://maven.apache.org/XDOC/2.0"
3   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
4   xsi:schemaLocation="http://maven.apache.org/XDOC/2.0 http://maven.apache.org/xsd/xdoc-2.0.xsd">
5
6   <properties>
7     <title>overview</title>
8     <author email="erik@brakkee.org">Erik Brakkee</author>
9   </properties>
10   <body>
11     <section name="Introduction">
12       <p> The utilities library consists of software to support development of Java and in
13         particular Java EE applications. I started this in 2005 when I realized that it would be
14         very nice to have a support library readily available instead of having to cut and paste
15         from old code. </p>
16       <p> There are many purposes for this documentation: </p>
17       <ul>
18         <li>To allow others to use this library.</li>
19         <li>To allow myself to use the library(!). This is because I have written a lot of stuff in
20           the past and need to make sure I have good enough documentation describing what I have
21           made and how to use it. </li>
22         <li>To document the current state of development. In particular, some parts may be
23           deprecated because of other developments).</li>
24         <li>To allow extension of the library.</li>
25       </ul>
26       <p> See the links on the left side for information about various components of the utilities
27         library. </p>
28
29     </section>
30     <section name="Philosopy">
31       <p> Some parts in the utilities library may seem familiar to users of other popular frameworks
32         such as <a href="http://www.springframework.org">Spring</a> and <a
33           href="http://code.google.com/p/google-guice/">Guice</a>. This is not always a coincidence.
34         It is my view that there many good IOC
35         frameworks but that it is not a good idea to tie into any one of them 
36         specifically. Also, the support that one actually needs to develop applications and in
37         particular enterprise applications efficiently only requires a few basic support utilities
38         and typically not a big framework. Therefore, you will find a couple of small 
39         utilities that may be familiar in the functionality they offer to what is found 
40         in other frameworks. </p>
41       <p>Apart from this, there are many other interesting developments going on: </p>
42       <ul>
43         <li><em>Java EE 6 dependency injection:</em> Java EE 6 provides a powerful dependency
44           injection framework called <a href="http://jcp.org/en/jsr/summary?id=299">Contexts and
45             Dependency Injection (CDI)</a>, that contains a lot of experience from proven frameworks
46           such as Spring and Guice. In particular, I think CDI can be viewed as a standardization of
47           Guice (although some people might disagree). This, in effect, should make anyone think
48           twice before depending heavily on a 3rd party IOC framework instead of using CDI. </li>
49         <li><em>Lightweight component technologies:</em> Integration of lightweight component
50           technologies such as <a href="http://www.osgi.org">OSGI</a> and Java EE is under way which
51           will also shift the balance. In effect, the enterprise spec for OSGI was released March
52           23rd 2010 and Glassfish V3 is already partly using it. </li>
53       </ul>
54       <p> In particular, I believe that Java EE 6 with new powerful concepts such as singleton
55         beans, lifecycle management, Contexts and Dependency Injection, used in combination with Enterprise OSGI will
56         provide the most powerful way to develop applications in the future. In this. I am making
57         only an exception for web frameworks to which I think JSF is not a good solution. I would
58         use <a href="http://wicket.apache.org">Wicket</a> anyday if it were up to me. </p>
59
60     </section>
61   </body>
62 </document>