1.ApplicationWorkbenchAdvisor
?? configurer.setSaveAndRestore(false);
?? 當設為false時，project rebuild才能有效；否則，將不作改變。

     摘要:   閱讀全文

     摘要:   閱讀全文

     摘要:   閱讀全文

     摘要:   閱讀全文

     摘要:   閱讀全文

Oracle 9i開始，創建數據庫時默認包含了XDB特性。一旦啟動了數據庫和Listener，Oracle XDB的http服務就占用8080端口，剛好和JBoss、Tomcat等默認端口沖突。除了修改Tomcat等外，還可以修改XDB的配置。
Oracle XDB的端口設置不在配置文件中，而是在數據庫里。修改XDB的http和ftp服務端口的方法有3種：

1.使用sys登錄Oracle，利用dbms_xdb修改端口設置

? SQL> -- Change the HTTP/WEBDAV port from 8080 to 8081
? SQL> call dbms_xdb.cfg_update(updateXML(
??? 2??????? dbms_xdb.cfg_get()
??? 3????? , '/xdbconfig/sysconfig/protocolconfig/httpconfig/http-port/text()'
??? 4????? , 8081))
??? 5? /

? Call completed.

? SQL> -- Change the FTP port from 2100 to 2111
? SQL> call dbms_xdb.cfg_update(updateXML(
??? 2???????? dbms_xdb.cfg_get()
??? 3?????? , '/xdbconfig/sysconfig/protocolconfig/ftpconfig/ftp-port/text()'
??? 4?????? , 2111))
??? 5? /

? Call completed.

? SQL> COMMIT;

? Commit complete.

? SQL> EXEC dbms_xdb.cfg_refresh;

? PL/SQL procedure successfully completed.

2.使用OEM console，選擇數據庫，XML Database，Configuration。更改XDB的有關設置。

3.去掉數據庫的初始化參數：? dispatchers='(PROTOCOL=TCP) (SERVICE=XDB)'，將會禁止XDB的http和ftp服務。

首先感謝TerryLee，配置完ProfileScriptService后，發現異常

The server method 'SetProfile' failed with the following error:property cannot be set for anonymous users.System.Configuration.Provider.ProviderException。

google后，找到了解決方法。

1.在system.web節點加入<anonymousIdentification enabled="true"/>

2.<add name="FloatingLabelLocation" />改為<add name="FloatingLabelLocation" allowAnonymous="true" />

?

??????? 工作需要，學習C#，真是被Visual Studio2003搞郁悶了，懷念Eclipse,Idea的日子。為了盡快上手，去博庫書城，買了本書《Beginning C# Objects From Concepts to Code》中文版。碰到了一個項目包含多個main無法build的問題，google了一把，才找到一前輩寫的文章。

http://davidavraamides.net/blog/2005/08/30/multiple-main/

這位前輩和我想到一塊兒去了。
解決步驟：
1.在解決方案資源管理器中，打開項目屬性。
2.在應用程序啟動對象中選擇要bulid的那個main。

FortMinor, LinkinPark, song

By Craig Walls and Ryan Breidenbach
Giving and taking

The question you should be asking at this point is whether or not a knight should be responsible for obtaining a quest. Or, should a knight be given a quest to embark upon?

Consider the following change to KnightOfTheRoundTable:

public class KnightOfTheRoundTable implements Knight {
   private Quest quest;
   ...

   public KnightOfTheRoundTable(String name) {
      ...
   }

   public HolyGrail embarkOnQuest() throws QuestException {
      ...
      return quest.embark();
   }

   public void setQuest(Quest quest) {
      this.quest = quest;
   }
}

Notice the difference? Compare figure 1.3 with figure 1.2 to see the difference in how a knight obtains its quest. Now the knight is given a quest instead of retrieving one itself. KnightOfTheRoundTable is no longer responsible for retrieving its own quests. And because it only knows about a quest through the Quest interface, you could give a knight any implementation of Quest you want. In a production system, maybe you would give it a HolyGrailQuest, but in a test case you would give it a mock implementation of Quest.

In a nutshell, that is what inversion of control is all about: the responsibility of coordinating collaboration between dependent objects is transferred away from the objects themselves. And that's where lightweight container frameworks, such as Spring, come into play.

Assigning a quest to a knight

Now that you've written your KnightOfTheRoundTable class to be given any arbitrary Quest object, how can you specify which Quest it should be given?

Figure 1.3 A knight is given a quest through its setQuest() method.

The act of creating associations between application components is referred to as wiring. In Spring, there are many ways to wire components together, but the most common approach is via XML. Listing 1.8 shows a simple Spring configuration file, knight.xml, that gives a quest (specifically, a HolyGrailQuest) to a KnightOfTheRoundTable.

Listing 1.8 Wiring a quest to a knight in knight.xml

Click here for a larger image.

This is just a simple approach to wiring beans. Don't worry too much about the details of it right now. In chapter 2 we'll explain more about what is going on here, as well as show you even more ways you can wire your beans in Spring.

Now that we've declared the relationship between a knight and a quest, we need to load up the XML file and kick off the application.

Seeing it work

In a Spring application, a BeanFactory loads the bean definitions and wires the beans together. Because the beans in the knight example are declared in an XML file, an XmlBeanFactory is the appropriate factory for this example. The main() method in listing 1.9 uses an XmlBeanFactory to load knight.xml and to get a reference to the "knight" object.

Listing 1.9 Running the knight example

Click here for a larger image.

Once the application has a reference to the KnightOfTheRoundTable object, it simply calls the embarkOnQuest() method to kick off the knight's adventure. Notice that this class knows nothing about the quest the knight will take. Again, the only thing that knows which type of quest will be given to the knight is the knight.xml file.

It's been a lot of fun sending knights on quests using inversion of control, but now let's see how you can use IoC in your real-world enterprise applications.⁴

1.4.3 IoC in enterprise applications

Suppose that you've been tasked with writing an online shopping application. Included in the application is an OrderServiceBean, implemented as a stateless session bean. Now you want to have a class that creates an Order object from user input (likely an HTML form) and call the createOrder() method on your OrderServiceBean, as shown in listing 1.10.

Listing 1.10 Creating an order using EJB

Click here for a larger image.

Notice that it took five lines of code just to get your OrderService object. Now imagine having to do this everywhere you need an OrderService object. Now imagine you have ten other EJBs in your application. That is a lot of code! But duplicating this code everywhere would be ridiculous, so a ServiceLocator is typically used instead. A ServiceLocator acts as a central point for obtaining and caching EJBHome references:

private OrderService getOrderService() {
   OrderServiceHome home =
      ServiceLocator.locate(OrderServiceHome);
   OrderService orderService = home.create();
}

While this removes the need to duplicate the lookup code everywhere in the application, one problem still remains: we always have to explicitly look up our services in our code.

Now let's see how this would be implemented in Spring:

private OrderService orderService;

public void doRequest(HttpServletRequest request) {
   Order order = createOrder(request);
   orderService.createOrder(order);
}

public void setOrderService(OrderService orderService) {
   this.orderService = orderService;
}

No lookup code! The reference to OrderService is given to our class by the Spring container through the setOrderService() method. With Spring, we never have to trouble ourselves with fetching our dependencies. Instead, our code can focus on the task at hand.

But inversion of control is only one of the techniques that Spring offers to JavaBeans. There's another side to Spring that makes it a viable framework for enterprise development. Let's take a quick look at Spring's support for aspect-oriented programming.

End Notes

1 In this book, Spring was originally called "interface21."

2 The container actually performs other activities involving the life cycle of the bean. But for illustrative purposes, these two lines are sufficient.

3 Although we agree that "dependency injection" is a more accurate name than "inversion of control," we're likely to use both terms interchangeably in this book.

4 This assumes that your real-world applications do not involve knights and quests. In the event that your current project does involve knights and quests, you may disregard the next section.

More to Come
The rest of this sample chapter will appear on our Web site starting April 27th.

About the Authors

Craig Walls is a software developer with over 10 years' experience and co-author of XDoclet in Action. He has sucessfully implemented a number of Spring applications. Craig lives in Denton, Texas.

An avid supporter of open source Java technologies, Ryan Breidenbach has been developing Java web applications for the past five years. He lives in Coppell, Texas.

About the Book

Spring in Action by Craig Walls and Ryan Breidenbach

Published February 2005, Softbound, 472 pages
Published by Manning Publications Co.
ISBN 1932394354
Retail price: $44.95
Ebook price: $22.50. To purchase the ebook go to http://www.manning.com/walls2.
This material is from Chapter 1 of the book.

By Craig Walls and Ryan Breidenbach

The BeanFactory class used here is the Spring container. After loading the hello.xml file into the container, the main() method calls the getBean() method on the BeanFactory to retrieve a reference to the greeting service. With this reference in hand, it finally calls the sayGreeting() method. When we run the Hello application, it prints (not surprisingly)

Buenos Dias!

This is about as simple a Spring-enabled application as we can come up with. But it does illustrate the basics of configuring and using a class in Spring. Unfortunately, it is perhaps too simple because it only illustrates how to configure a bean by injecting a String value into a property. The real power of Spring lies in how beans can be injected into other beans using IoC.

1.4 Understanding inversion of control

Inversion of control is at the heart of the Spring framework. It may sound a bit intimidating, conjuring up notions of a complex programming technique or design pattern. But as it turns out, IoC is not nearly as complex as it sounds. In fact, by applying IoC in your projects, you'll find that your code will become significantly simpler, easier to understand, and easier to test.

But what does "inversion of control" mean?

1.4.1 Injecting dependencies

In an article written in early 2004, Martin Fowler asked what aspect of control is being inverted. He concluded that it is the acquisition of dependent objects that is being inverted. Based on that revelation, he coined a better name for inversion of control: dependency injection.³

Any nontrivial application (pretty much anything more complex than HelloWorld.java) is made up of two or more classes that collaborate with each other to perform some business logic. Traditionally, each object is responsible for obtaining its own references to the objects it collaborates with (its dependencies). As you'll see, this can lead to highly coupled and hard-to-test code.

Applying IoC, objects are given their dependencies at creation time by some external entity that coordinates each object in the system. That is, dependencies are injected into objects. So, IoC means an inversion of responsibility with regard to how an object obtains references to collaborating objects.

1.4.2 IoC in action

If you're like us, then you're probably anxious to see how this works in code. We aim to please, so without further delay...

Suppose that your company's crack marketing team culled together the results of their expert market analysis and research and determined that what your customers need is a knight. That is, they need a Java class that represents a knight. After probing them for requirements, you learn that what they specifically want is for you to implement a class that represents an Arthurian knight of the Round Table that embarks on brave and noble quests to find the Holy Grail.

This is an odd request, but you've become accustomed to the strange notions and whims of the marketing team. So, without hesitation, you fire up your favorite IDE and bang out the class in listing 1.5.

Listing 1.5 KnightOfTheRoundTable.java

In listing 1.5 the knight is given a name as a parameter of its constructor. Its constructor sets the knight's quest by instantiating a HolyGrailQuest. The implementation of HolyGrailQuest is fairly trivial, as shown in listing 1.6.

Listing 1.6 HolyGrailQuest.java

package com.springinaction.chapter01.knight;
public class HolyGrailQuest {
   public HolyGrailQuest() {}

   public HolyGrail embark() throws GrailNotFoundException {
      HolyGrail grail = null;
      // Look for grail
      ...
      return grail;
   }
}

Satisfied with your work, you proudly check the code into version control. You want to show it to the marketing team, but deep down something doesn't feel right. You almost dismiss it as the burrito you had for lunch when you realize the problem: you haven't written any unit tests.

Knightly testing

Unit testing is an important part of development. It not only ensures that each individual unit functions as expected, but it also serves to document each unit in the most accurate way possible. Seeking to rectify your failure to write unit tests, you put together the test case (listing 1.7) for your knight class.

Listing 1.7 Testing the KnightOfTheRoundTable

package com.springinaction.chapter01.knight;

import junit.framework.TestCase;

public class KnightOfTheRoundTableTest extends TestCase {

   public void testEmbarkOnQuest() {
      KnightOfTheRoundTable knight =
         new KnightOfTheRoundTable("Bedivere");

      try {
         HolyGrail grail = knight.embarkOnQuest();

         assertNotNull(grail);

         assertTrue(grail.isHoly());
      } catch (GrailNotFoundException e) {
         fail();
      }
   }
}

After writing this test case, you set out to write a test case for HolyGrailQuest. But before you even get started, you realize that the KnightOfTheRoundTableTest test case indirectly tests HolyGrailQuest. You also wonder if you are testing all contingencies. What would happen if HolyGrailQuest's embark() method returned null? Or what if it were to throw a GrailNotFoundException?

Who's calling who?

The main problem so far with KnightOfTheRoundTable is with how it obtains a HolyGrailQuest. Whether it is instantiating a new HolyGrail instance or obtaining one via JNDI, each knight is responsible for getting its own quest (as shown in figure 1.2). Therefore, there is no way to test the knight class in isolation. As it stands, every time you test KnightOfTheRoundTable, you will also indirectly test HolyGrailQuest.

Figure 1.2 A knight is responsible for getting its own quest, through instantiation or some other means.

What's more, you have no way of telling HolyGrailQuest to behave differently (e.g., return null or throw a GrailNotFoundException) for different tests. What would help is if you could create a mock implementation of HolyGrailQuest that lets you decide how it behaves. But even if you were to create a mock implementation, KnightOfTheRoundTable still retrieves its own HolyGrailQuest, meaning you would have to make a change to KnightOfTheRoundTable to retrieve the mock quest for testing purposes (and then change it back for production).

Decoupling with interfaces

The problem, in a word, is coupling. At this point, KnightOfTheRoundTable is statically coupled to HolyGrailQuest. They're handcuffed together in such a way that you can't have a KnightOfTheRoundTable without also having a HolyGrailQuest.

Coupling is a two-headed beast. On one hand, tightly coupled code is difficult to test, difficult to reuse, difficult to understand, and typically exhibits "whack-a-mole" bugs (i.e., fixing one bug results in the creation of one or more new bugs). On the other hand, completely uncoupled code doesn't do anything. In order to do anything useful, classes need to know about each other somehow. Coupling is necessary, but it should be managed very carefully.

A common technique used to reduce coupling is to hide implementation details behind interfaces so that the actual implementation class can be swapped out without impacting the client class. For example, suppose you were to create a Quest interface:

package com.springinaction.chapter01.knight;

public interface Quest {
   public abstract Object embark() throws QuestException;
}

Then, you change HolyGrailQuest to implement this interface. Also, notice that embark now returns an Object and throws a QuestException.

package com.springinaction.chapter01.knight;

public class HolyGrailQuest implements Quest {
   public HolyGrailQuest() {}

   public Object embark() throws QuestException {
      // Do whatever it means to embark on a quest
      return new HolyGrail();
   }
}

Also, the following method must also change in KnightOfTheRoundTable to be compatible with these Quest types:

private Quest quest;
...
public Object embarkOnQuest() throws QuestException {
   return quest.embark();
}

Likewise, you could also have KnightOfTheRoundTable implement the following Knight interface:

public interface Knight {
   public Object embarkOnQuest() throws QuestException;
}

Hiding your class's implementation behind interfaces is certainly a step in the right direction. But where many developers fall short is in how they retrieve a Quest instance. For example, consider this possible change to KnightOfTheRoundTable:

public class KnightOfTheRoundTable implements Knight {

   private Quest quest;
   ...

   public KnightOfTheRoundTable(String name) {
      quest = new HolyGrailQuest();
   ...
   }

   public Object embarkOnQuest() throws QuestException {
      return quest.embark();
   }
}

Here the KnightOfTheRoundTable class embarks on a quest through the Quest interface. But, the knight still retrieves a specific type of Quest (here a HolyGrailQuest). This isn't much better than before. A KnightOfTheRoundTable is stuck going only on quests for the Holy Grail and no other types of quest.

By Craig Walls and Ryan Breidenbach
Application context module

The core module's BeanFactory makes Spring a container, but the context module is what makes it a framework. This module extends the concept of BeanFactory, adding support for internationalization (I18N) messages, application life cycle events, and validation.

In addition, this module supplies many enterprise services such as e-mail, JNDI access, EJB integration, remoting, and scheduling. Also included is support for integration with templating frameworks such as Velocity and FreeMarker.

Spring's AOP module

Spring provides rich support for aspect-oriented programming in its AOP module. This module serves as the basis for developing your own aspects for your Spring-enabled application.

To ensure interoperability between Spring and other AOP frameworks, much of Spring's AOP support is based on the API defined by the AOP Alliance. The AOP Alliance is an open-source project whose goal is to promote adoption of AOP and interoperability among different AOP implementations by defining a common set of interfaces and components. You can find out more about the AOP Alliance by visiting their website at http://aopalliance.sourceforge.net.

The Spring AOP module also introduces metadata programming to Spring. Using Spring's metadata support, you are able to add annotations to your source code that instruct Spring on where and how to apply aspects.

JDBC abstraction and the DAO module

Working with JDBC often results in a lot of boilerplate code that gets a connection, creates a statement, processes a result set, and then closes the connection. Spring's JDBC and Data Access Objects (DAO) module abstracts away the boilerplate code so that you can keep your database code clean and simple, and prevents problems that result from a failure to close database resources. This module also builds a layer of meaningful exceptions on top of the error messages given by several database servers. No more trying to decipher cryptic and proprietary SQL error messages!

In addition, this module uses Spring's AOP module to provide transaction management services for objects in a Spring application.

Object/relational mapping integration module

For those who prefer using an object/relational mapping (ORM) tool over straight JDBC, Spring provides the ORM module. Spring doesn't attempt to implement its own ORM solution, but does provide hooks into several popular ORM frameworks, including Hibernate, JDO, and iBATIS SQL Maps. Spring's transaction management supports each of these ORM frameworks as well as JDBC.

Spring's web module

The web context module builds on the application context module, providing a context that is appropriate for web-based applications. In addition, this module contains support for several web-oriented tasks such as transparently handling multipart requests for file uploads and programmatic binding of request parameters to your business objects. It also cotains integration support with Jakarta Struts.

The Spring MVC framework

Spring comes with a full-featured Model/View/Controller (MVC) framework for building web applications. Although Spring can easily be integrated with other MVC frameworks, such as Struts, Spring's MVC framework uses IoC to provide for a clean separation of controller logic from business objects. It also allows you to declaratively bind request parameters to your business objects, What's more, Spring's MVC framework can take advantage of any of Spring's other services, such as I18N messaging and validation.

Now that you know what Spring is all about, let's jump right into writing Spring applications, starting with the simplest possible example that we could come up with.

1.3 Spring jump start

In the grand tradition of programming books, we'll start by showing you how Spring works with the proverbial "Hello World" example. Unlike the original Hello World program, however, our example will be modified a bit to demonstrate the basics of Spring.

Note: To find out how to download Spring and plug it into your project's build routine, refer to appendix A.

Spring-enabled applications are like any Java application. They are made up of several classes, each performing a specific purpose within the application. What makes Spring-enabled applications different, however, is how these classes are configured and introduced to each other. Typically, a Spring application has an XML file that describes how to configure the classes, known as the Spring configuration file.

The first class that our Springified Hello World example needs is a service class whose purpose is to print the infamous greeting. Listing 1.1 shows GreetingService.java, an interface that defines the contract for our service class.

Listing 1.1 The GreetingService interface separates the service's implementation from its interface.

package com.springinaction.chapter01.hello;

public interface GreetingService {
   public void sayGreeting();
}

GreetingServiceImpl.java (listing 1.2) implements the GreetingService interface. Although it's not necessary to hide the implementation behind an interface, it's highly recommended as a way to separate the implementation from its contract.

Listing 1.2 GreetingServiceImpl.java: Responsible for printing the greeting

package com.springinaction.chapter01.hello;

public class GreetingServiceImpl implements GreetingService {
   private String greeting;

   public GreetingServiceImpl() {}

   public GreetingServiceImpl(String greeting) {
      this.greeting = greeting;
   }

   public void sayGreeting() {
      System.out.println(greeting);
   }

   public void setGreeting(String greeting) {
      this.greeting = greeting;
   }
}

The GreetingServiceImpl class has a single property: the greeting property. This property is simply a String that holds the text that is the message that will be printed when the sayGreeting() method is called. You may have noticed that the greeting can be set in two different ways: by the constructor or by the property's setter method.

What's not apparent just yet is who will make the call to either the constructor or the setGreeting() method to set the property. As it turns out, we're going to let the Spring container set the greeting property. The Spring configuration file (hello.xml) in listing 1.3 tells the container how to configure the greeting service.

Listing 1.3 Configuring Hello World in Spring

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN"
   "http://www.springframework.org/dtd/spring-beans.dtd">

<beans>
   <bean id="greetingService"
         class="com.springinaction.chapter01.hello.GreetingServiceImpl">
      <property name="greeting">
         <value>Buenos Dias!</value>
      </property>
   </bean>
</beans>

The XML file in listing 1.3 declares an instance of a GreetingServiceImpl in the Spring container and configures its greeting property with a value of "Buenos Dias!" Let's dig into the details of this XML file a bit to understand how it works.

At the root of this simple XML file is the <beans> element, which is the root element of any Spring configuration file. The <bean> element is used to tell the Spring container about a class and how it should be configured. Here, the id attribute is used to name the bean greetingService and the class attribute specifies the bean's fully qualified class name.

Within the <bean> element, the <property> element is used to set a property, in this case the greeting property. By using <property>, we're telling the Spring container to call setGreeting() when setting the property.

The value of the greeting is defined within the <value> element. Here we've given the example a Spanish flair by choosing "Buenos Dias" instead of the traditional "Hello World."

The following snippet of code illustrates roughly what the container does when instantiating the greeting service based on the XML definition in listing 1.3:²

GreetingServiceImpl greetingService = new GreetingServiceImpl();
greetingService.setGreeting("Buenos Dias!");

Similarly, we may choose to have Spring set the greeting property through GreetingServiceImpl's single argument constructor. For example:

<bean id="greetingService"
      class="com.springinaction.chapter01.hello.GreetingServiceImpl">
   <constructor-arg>
      <value>Buenos Dias!</value>
   </constructor-arg>
</bean>

The following code illustrates how the container will instantiate the greeting service when using the <constructor-arg> element:

GreetingServiceImpl greetingService =
   new GreetingServiceImpl("Buenos Dias");

The last piece of the puzzle is the class that loads the Spring container and uses it to retrieve the greeting service. Listing 1.4 shows this class.

Listing 1.4 The Hello World main class

package com.springinaction.chapter01.hello;

import java.io.FileInputStream;
import org.springframework.beans.factory.BeanFactory;
import org.springframework.beans.factory.xml.XmlBeanFactory;

public class HelloApp {
   public static void main(String[] args) throws Exception {
      BeanFactory factory =
         new XmlBeanFactory(new FileInputStream("hello.xml"));

      GreetingService greetingService =
         (GreetingService) factory.getBean("greetingService");

      greetingService.sayGreeting();
   }
}

By Craig Walls and Ryan Breidenbach

It all started with a bean.

In 1996 the Java programming language was still a young, exciting, up-and-coming platform. Many developers flocked to the language because they had seen how to create rich and dynamic web applications using applets. But they soon learned that there was more to this strange new language than animated juggling cartoon characters. Unlike any language before it, Java made it possible to write complex applications made up of discrete parts. They came for the applets, but they stayed for the components.

It was in December of that year that Sun Microsystems published the Java-Beans 1.00-A specification. JavaBeans defined a software component model for Java. This specification defined a set of coding policies that enabled simple Java objects to be reusable and easily composed into more complex applications. Although JavaBeans were intended as a general-purpose means of defining reusable application components, they have been primarily used as a model for building user interface widgets. They seemed too simple to be capable of any "real" work. Enterprise developers wanted more.

Sophisticated applications often require services such as transaction support, security, and distributed computing—services not directly provided by the Java-Beans specification. Therefore, in March 1998, Sun published the 1.0 version of the Enterprise JavaBeans (EJB) specification. This specification extended the notion of Java components to the server side, providing the much-needed enterprise services, but failed to continue the simplicity of the original JavaBeans specification. In fact, except in name, EJB bears very little resemblance to the original JavaBeans specification.

Despite the fact that many successful applications have been built based on EJB, EJB never really achieved its intended purpose: to simplify enterprise application development. Every version of the EJB specification contains the following statement: "Enterprise JavaBeans will make it easy to write applications." It is true that EJB's declarative programming model simplifies many infrastructural aspects of development, such as transactions and security. But EJBs are complicated in a different way by mandating deployment descriptors and plumbing code (home and remote/local interfaces). Over time many developers became disenchanted with EJB. As a result, its popularity has started to wane in recent years, leaving many developers looking for an easier way.

Now Java component development is coming full circle. New programming techniques, including aspect-oriented programming (AOP) and inversion of control (IoC), are giving JavaBeans much of the power of EJB. These techniques furnish JavaBeans with a declarative programming model reminiscent of EJB, but without all of EJB's complexity. No longer must you resort to writing an unwieldy EJB component when a simple JavaBean will suffice.

And that's where Spring steps into the picture.

1.1 Why Spring?

If you are reading this book, you probably want to know why Spring would be good for you. After all, the Java landscape is full of frameworks. What makes Spring any different? To put it simply, Spring makes developing enterprise applications easier. We don't expect that to convince you at face value, so first let's take a look at life without Spring.

1.1.1 A day in the life of a J2EE developer

Alex is a Java developer who has just started on his first enterprise application. Like many Java 2 Enterprise Edition (J2EE) applications, it is a web application that serves many users and accesses an enterprise database. In this case, it is a customer management application that will be used by other employees at his company.

Eager to get to work, Alex fires up his favorite integrated development environment (IDE) and starts to crank out his first component, the CustomerManager component. In the EJB world, to develop this component Alex actually has to write several classes—the home interface, the local interface, and the bean itself. In addition, he has to create a deployment descriptor for this bean.

Seeing that creating each of these files for every bean seems like a lot of effort, Alex incorporates XDoclet into his project. XDoclet is a code generation tool that can generate all of the necessary EJB files from a single source file. Although this adds another step to Alex's development cycle, his coding life is now much simpler.

With XDoclet now handling a lot of the grunt work for him, Alex turns his attention to his real problem—what exactly should the CustomerManager component do? He jumps in with its first method, getPreferredCustomer(). There are several business rules that define exactly what a preferred customer is, and Alex dutifully codes them into his CustomerManager bean.

Wanting to confirm that his logic is correct, Alex now wants to write some tests to validate his code. But then it occurs to him: the code he is testing will be running within the EJB container. Therefore, his tests need to execute within the container as well. To easily accomplish this, he concocts a servlet that will be responsible for executing these tests. Since all J2EE containers support servlets, this will allow him to execute his tests in the same container as his EJB. Problem solved!

So Alex fires up his J2EE container and runs his tests. His tests fail. Alex sees his coding error, fixes it, and runs the tests again. His tests fail again. He sees another error and fixes it. He fires up the container and runs the tests again. As Alex is going through this cycle, he notices something. The fact that he has to start the J2EE container for each batch of testing really slows down his development cycle. The development cycle should go code, test, code, test. This pattern has now been replaced with code, wait, test, code, wait, test, code, wait, get increasingly frustrated...

While waiting for the container to start during another test run, Alex thinks, "Why am I using EJB in the first place?" The answer, of course, is because of the services it provides. But Alex isn't using entity beans, so he is not using persistence services. Alex is also not using the remoting or security services. In fact, the only EJB service Alex is going to use is transaction management. This leads Alex to another question: "Is there an easier way?"

1.1.2 Spring's pledge

The above story was a dramatization based on the current state of J2EE—specifically EJB. In its current state, EJB is complicated. It isn't complicated just to be complicated. It is complicated because EJBs were created to solve complicated things, such as distributed objects and remote transactions.

Unfortunately, a good number of enterprise projects do not have this level of complexity but still take on EJB's burden of multiple Java files and deployment descriptors and heavyweight containers. With EJB, application complexity is high, regardless of the complexity of the problem being solved—even simple applications are unduly complex. With Spring, the complexity of your application is proportional to the complexity of the problem being solved.

However, Spring recognizes that EJB does offer developers valuable services. So Spring strives to deliver these same services while simplifying the programming model. In doing so, it adopts a simple philosophy: J2EE should be easy to use. In keeping with this philosophy, Spring was designed with the following beliefs:

• Good design is more important than the underlying technology.
• JavaBeans loosely coupled through interfaces is a good model.
• Code should be easy to test.

Okay. So how does Spring help you apply this philosophy to your applications?.

Good design is more important than the underlying technology

As a developer, you should always be seeking the best design for your application, regardless of the implementation you choose. Sometimes the complexity of EJB is warranted because of the requirements of the application. Often, this is not the case. Many applications require few, if any, of the services provided by EJB yet are still implemented using this technology for technology's sake. If an application does not require distribution or declarative transaction support, it is unlikely that EJB is the best technology candidate. Yet many Java developers feel compelled to use EJB for every Java enterprise application.

The idea behind Spring is that you can keep your code as simple as it needs to be. If what you want are some plain-vanilla Java objects to perform some services supported by transparent transactions, you've got it. And you don't need an EJB container, and you don't have to implement special interfaces. You just have to write your code.

JavaBeans loosely coupled through interfaces is a good model

If you are relying on EJBs to provide your application services, your components do not just depend on the EJB business interface. They are also responsible for retrieving these EJB objects from a directory, which entails a Java Naming and Directory Interface (JNDI) lookup and communicating with the bean's EJBHome interface. This is not creating a decoupled application. This is tightly coupling your application to a specific implementation, namely EJB.

With Spring, your beans depend on collaborators through interfaces. Since there are no implementation-specific dependencies, Spring applications are very decoupled, testable, and easier to maintain. And because the Spring container is responsible for resolving the dependencies, the active service lookup that is involved in EJB is now out of the picture and the cost of programming to interfaces is minimized. All you need to do is create classes that communicate with each other through interfaces, and Spring takes care of the rest.

Code should be easy to test

Testing J2EE applications can be difficult. If you are testing EJBs within a container, you have to start up a container to execute even the most trivial of test cases. Since starting and stopping a container is expensive, developers may be tempted to skip testing all of their components. Avoiding tests because of the rigidness of a framework is not a good excuse.

Because you develop Spring applications with JavaBeans, testing is cheap. There is no J2EE container to be started since you will be testing a POJO. And. since Spring makes coding to interfaces easy, your objects will be loosely coupled, making testing even easier. A thorough battery of tests should be present in all of your applications; Spring will help you accomplish this.

1.2 What is Spring?

Spring is an open-source framework, created by Rod Johnson and described in his book Expert One-on-One: J2EE Design and Development.¹ It was created to address the complexity of enterprise application development. Spring makes it possible to use plain-vanilla JavaBeans to achieve things that were previously only possible with EJBs. However, Spring's usefulness isn't limited to server-side development. Any Java application can benefit from Spring in terms of simplicity, testability, and loose coupling.

Note: To avoid ambiguity, we'll use the term "EJB" when referring to Enterprise JavaBeans. When referring to the original JavaBean, we'll call it "JavaBean," or "bean" for short. Some other terms we may throw around are "POJO" (which stands for "plain old Java object") or "POJI" (which means "plain old Java interface").

Put simply, Spring is a lightweight inversion of control and aspect-oriented container framework. Okay, that's not so simple a description. But it does summarize what Spring does. To make more sense of Spring, let's break this description down:

• Lightweight—Spring is lightweight in terms of both size and overhead. The entire Spring framework can be distributed in a single JAR file that weighs in at just over 1 MB. And the processing overhead required by Spring is negligible. What's more, Spring is nonintrusive: objects in a Spring-enabled application typically have no dependencies on Spring-specific classes.
• Inversion of control—Spring promotes loose coupling through a technique known as inversion of control (IoC). When IoC is applied, objects are passively given their dependencies instead of creating or looking for dependent objects for themselves. You can think of IoC as JNDI in reverse—instead of an object looking up dependencies from a container, the container gives the dependencies to the object at instantiation without waiting to be asked.
• Aspect-oriented—Spring comes with rich support for aspect-oriented programming that enables cohesive development by separating application business logic from system services (such as auditing and transaction management). Application objects do what they're supposed to do—perform business logic—and nothing more. They are not responsible for (or even aware of) other system concerns, such as logging or transactional support.
• Container—Spring is a container in the sense that it contains and manages the life cycle and configuration of application objects. You can configure how your each of your beans should be created—either create one single instance of your bean or produce a new instance every time one is needed based on a configurable prototype—and how they should be associated with each other. Spring should not, however, be confused with traditionally heavyweight EJB containers, which are often large and cumbersome to work with.
• Framework—Spring makes it possible to configure and compose complex applications from simpler components. In Spring, application objects are composed declaratively, typically in an XML file. Spring also provides much infrastructure functionality (transaction management, persistence framework integration, etc.), leaving the development of application logic to you.

All of these attributes of Spring enable you to write code that is cleaner, more manageable, and easier to test. They also set the stage for a variety of subframeworks within the greater Spring framework.

1.2.1 Spring modules

The Spring framework is made up of seven well-defined modules (figure 1.1). When taken as a whole, these modules give you everything you need to develop enterprise-ready applications. But you do not have to base your application fully on the Spring framework. You are free to pick and choose the modules that suit your application and ignore the rest.

As you can see, all of Spring's modules are built on top of the core container. The container defines how beans are created, configured, and managed—more of the nuts-and-bolts of Spring. You will implicitly use these classes when you configure your application. But as a developer, you will most likely be interested in the other modules that leverage the services provided by the container. These modules will provide the frameworks with which you will build your application's services, such as AOP and persistence.

Figure 1.1 The Spring framework is composed of several well-defined modules.

The core container

Spring's core container provides the fundamental functionality of the Spring framework. In this module you'll find Spring's BeanFactory, the heart of any Spring-based application. A BeanFactory is an implementation of the factory pattern that applies IoC to separate your application's configuration and dependency specifications from the actual application code.

We discuss the core module (the center of any Spring application) throughout our book, Spring in Action from Manning Publications, starting in chapter 2, when we cover bean wiring using IoC.

     摘要: 轉自小小冰 http://blog.csdn.net/kellerdu/archive/2004/11/08/172247.aspx----------------------------------------------------------------------- ------- ------- ------- -- 示例：在...  閱讀全文

1.ChinaTex
http://www.chinatex.org
2.Ctex
http://www.ctex.org
3.hooklee's TeX Page: ChinaTeX Project
http://www.hooklee.com/tex.html

?

原文地址：
http://opensource.atlassian.com/confluence/spring/display/DISC/Caching+the+result+of+methods+using+Spring+and+EHCache

導言

從 Spring 1.1.1 開始， EHCache 就作為一種通用緩存解決方案集成進 Spring 。

我將示范攔截器的例子，它能把方法返回的結果緩存起來。

?

利用 Spring IoC 配置 EHCache

在 Spring 里配置 EHCache 很簡單。你只需一個 ehcache.xml 文件，該文件用于配置 EHCache ：

?

<ehcache> ??? <!—設置緩存文件 .data 的創建路徑。 ???????? 如果該路徑是 Java 系統參數，當前虛擬機會重新賦值。 ???????? 下面的參數這樣解釋： ???????? user.home – 用戶主目錄 ???????? user.dir????? – 用戶當前工作目錄 ???????? java.io.tmpdir – 默認臨時文件路徑 --> ??? <diskStore path="java.io.tmpdir"/> ??? <!—缺省緩存配置。CacheManager 會把這些配置應用到程序中。 ??????? 下列屬性是 defaultCache 必須的： ??????? maxInMemory?????????? - 設定內存中創建對象的最大值。 ??????? eternal??????????????????????? - 設置元素（譯注：內存中對象）是否永久駐留。如果是，將忽略超 ??????????????????????????????????????????????時限制且元素永不消亡。 ??????? timeToIdleSeconds? - 設置某個元素消亡前的停頓時間。 ????????????????????????????????????????????? 也就是在一個元素消亡之前，兩次訪問時間的最大時間間隔值。 ????????????????????????????????????????????? 這只能在元素不是永久駐留時有效（譯注：如果對象永恒不滅，則 ????????????????????????????????????????????? 設置該屬性也無用）。 ????????????????????????????????????????????? 如果該值是 0 就意味著元素可以停頓無窮長的時間。 ??????? timeToLiveSeconds?- 為元素設置消亡前的生存時間。 ?????????????????????????????????????????????? 也就是一個元素從構建到消亡的最大時間間隔值。 ?????????????????????????????????????????????? 這只能在元素不是永久駐留時有效。 ??????? overflowToDisk??????? - 設置當內存中緩存達到 maxInMemory 限制時元素是否可寫到磁盤 ???????????????????????????????????????????????上。 ??????? --> ??? <cache name="org.taha.cache.METHOD_CACHE" ??????? maxElementsInMemory="300" ??????? eternal="false" ??????? timeToIdleSeconds="500" ??????? timeToLiveSeconds="500" ??????? overflowToDisk="true" ??????? /> </ehcache>

?

攔截器將使用 ”org.taha.cache.METHOD_CACHE” 區域緩存方法返回結果。下面利用 Spring IoC 讓 bean 來訪問這一區域。

?

<!-- ======================?? 緩存?? ======================= --> <bean id="cacheManager" class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean"> ? <property name="configLocation"> ??? <value>classpath:ehcache.xml</value> ? </property> </bean> <bean id="methodCache" class="org.springframework.cache.ehcache.EhCacheFactoryBean"> ? <property name="cacheManager"> ??? <ref local="cacheManager"/> ? </property> ? <property name="cacheName"> ??? <value>org.taha.cache.METHOD_CACHE</value> ? </property> </bean>

?

構建我們的 MethodCacheInterceptor

該攔截器實現 org.aopalliance.intercept.MethodInterceptor 接口。一旦 運行起來 (kicks-in) ，它首先檢查被攔截方法是否被配置為可緩存的。這將可選擇性的配置想要緩存的 bean 方法。只要調用的方法配置為可緩存，攔截器將為該方法生成 cache key 并檢查該方法返回的結果是否已緩存。如果已緩存，就返回緩存的結果，否則再次調用被攔截方法，并緩存結果供下次調用。

?

org.taha.interceptor.MethodCacheInterceptor

?

/* ?* Copyright 2002-2004 the original author or authors. ?* ?* Licensed under the Apache License, Version 2.0 (the "License"); ?* you may not use this file except in compliance with the License. ?* You may obtain a copy of the License at ?* ?*????? http://www.apache.org/licenses/LICENSE-2.0 ?* ?* Unless required by applicable law or agreed to in writing, software ?* distributed under the License is distributed on an "AS IS" BASIS, ?* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. ?* See the License for the specific language governing permissions and ?* limitations under the License. ?*/ package org.taha.interceptor; import java.io.Serializable; import org.aopalliance.intercept.MethodInterceptor; import org.aopalliance.intercept.MethodInvocation; import org.apache.commons.logging.LogFactory; import org.apache.commons.logging.Log; import org.springframework.beans.factory.InitializingBean; import org.springframework.util.Assert; import net.sf.ehcache.Cache; import net.sf.ehcache.Element; /** ?* @author <a href=" mailto:irbouh@gmail.com">Omar Irbouh</a> ?* @since 2004.10.07 ?*/ public class MethodCacheInterceptor implements MethodInterceptor, InitializingBean { ? private static final Log logger = LogFactory.getLog(MethodCacheInterceptor.class); ? private Cache cache; ? /** ?? * 設置緩存名 ?? */ ? public void setCache(Cache cache) { ??? this.cache = cache; ? } ? /** ?? * 檢查是否提供必要參數。 ?? */ ? public void afterPropertiesSet() throws Exception { ??? Assert.notNull(cache, "A cache is required. Use setCache(Cache) to provide one."); ? } ? /** ?? * 主方法 ?? * 如果某方法可被緩存就緩存其結果 ?? * 方法結果必須是可序列化的(serializable) ?? */ ? public Object invoke(MethodInvocation invocation) throws Throwable { ??? String targetName? = invocation.getThis().getClass().getName(); ??? String methodName? = invocation.getMethod().getName(); ??? Object[] arguments = invocation.getArguments(); ??? Object result; ??? logger.debug("looking for method result in cache"); ??? String cacheKey = getCacheKey(targetName, methodName, arguments); ??? Element element = cache.get(cacheKey); ??? if (element == null) { ????? //call target/sub-interceptor ????? logger.debug("calling intercepted method"); ????? result = invocation.proceed(); ????? //cache method result ????? logger.debug("caching result"); ????? element = new Element(cacheKey, (Serializable) result); ????? cache.put(element); ??? } ??? return element.getValue(); ? } ? /** ?? * creates cache key: targetName.methodName.argument0.argument1... ?? */ ? private String getCacheKey(String targetName, ???????????????????????????? String methodName, ???????????????????????????? Object[] arguments) { ??? StringBuffer sb = new StringBuffer(); ??? sb.append(targetName) ????? .append(".").append(methodName); ??? if ((arguments != null) && (arguments.length != 0)) { ????? for (int i=0; i<arguments.length; i++) { ??????? sb.append(".") ????????? .append(arguments[i]); ????? } ??? } ??? return sb.toString(); ? } }

?

MethodCacheInterceptor 代碼說明了：

• 默認條件下，所有方法返回結果都被緩存了（ methodNames 是 null ）
• 緩存區利用 IoC 形成
• cacheKey 的生成還包括方法參數的因素（譯注：參數的改變會影響 cacheKey ）

使用 MethodCacheInterceptor

下面摘錄了怎樣配置 MethodCacheInterceptor ：

?

<bean id="methodCacheInterceptor" class="org.taha.interceptor.MethodCacheInterceptor"> ? <property name="cache"> ??? <ref local="methodCache" /> ? </property> </bean> <bean id="methodCachePointCut" class="org.springframework.aop.support.RegexpMethodPointcutAdvisor"> ? <property name="advice"> ??? <ref local="methodCacheInterceptor"/> ? </property> ? <property name="patterns"> ??? <list> ????? <value>.*methodOne</value> ????? <value>.*methodTwo</value> ??? </list> ? </property> </bean> <bean id="myBean" class="org.springframework.aop.framework.ProxyFactoryBean"> ? <property name="target"> ?? <bean class="org.taha.beans.MyBean"/> ? </property> ? <property name="interceptorNames"> ??? <list> ????? <value>methodCachePointCut</value> ??? </list> ? </property> </bean>

?

?

譯注

夏昕所著《 Hibernate 開發指南》，其中他這樣描述 EHCache 配置文件的：

?

<ehcache> ??? <diskStore path="java.io.tmpdir"/> ??? <defaultCache ??????? maxElementsInMemory="10000" //Cache中最大允許保存的數據數量 ??????? eternal="false"????????????????????? ?//Cache中數據是否為常量 ??????? timeToIdleSeconds="120"???? //緩存數據鈍化時間 ??????? timeToLiveSeconds="120"???? //緩存數據的生存時間 ??????? overflowToDisk="true"?????? //內存不足時，是否啟用磁盤緩存 ??? /> </ehcache>

     摘要: 一、緒言
JDK1.5對JAVA語言進行了做了幾個擴展，其中一個就是泛型。
本指南旨在介紹泛型。如果你熟悉其它語言的構造類似的東西，特別是C++的模
板（template），你會很快發現它們之間的相同點及重要的不同點；如果你在其他
地方沒看到過類似的東西，那反而更好，那樣你就可以開始全新的學習，用不著去忘
掉那些（對JAVA泛型）容易產生誤解的東西。
泛型允許你對類型進行抽象。最常見的例子是容器類型，比如那些在Collection
層次下的類型。
  閱讀全文

Flash objects appear through overlay.

http://www.sitepoint.com/forums/printthread.php?t=158317

solution:<param name="wmode" value="opaque">

文章來自:http://www.yd631.com/blog/article.asp?id=226

壓縮包文件結構：
|-tem
?????? |-folderA
?????????????????? |-filea
????????????????? ?|-fileb
?????????????????? |-filec
?????? |-filed
解壓后文件結構：
|-tem
?????? |-folderA
?????????????????? |-filea
????????????????? ?|-fileb
?????????????????? |-filec
?????? |-filed

摘自http://www.matrix.org.cn/resource/article/43/43661_Maven.html
版權聲明：可以任意轉載，轉載時請務必以超鏈接形式標明文章原始出處和作者信息及本聲明
英文原文地址:
http://www.onjava.com/pub/a/onjava/excerpt/mavenadn_ch01/index.html
中文地址:
http://www.matrix.org.cn/resource/article/43/43661_Maven.html
關鍵詞： Maven Ant Java




編者注：

如 果你已經有十次輸入同樣的Ant targets來編譯你的代碼、jar或者war、生成javadocs，你一定會自問，是否有有一個重復性更少卻能同樣完成該工作的方法。Maven便 提供了這樣一種選擇，將你的注意力從作業層轉移到項目管理層。Maven項目已經能夠知道如何構建和捆綁代碼，運行測試，生成文檔并宿主項目網頁。

O'Reilly's 的新書Maven:A Developer's Notebook幫你提升你的項目、使其盡快的運行起來，同時也提供了對Maven插件及其團隊協作等高級特性的深度考察。在“Maven Jump-Start” (656K PDF)的示范章節中，作者Vincent Massol和Timothy M.O'Brien向你展示了如何安裝Maven，如何開始你初次的構建，研究如何使其與IDEs集成極其資源管等特性。

Vincent Massol是Jakarta Catus framework（框架）的創建者。其后他花費4年的時間在幾個大項目（主要是J2EE）的架構技術上。他現在是Pivolis的創辦人和CTO,這是 一家專注于應用敏捷方法進行軟件開發的公司。他現在居住在法國的首都City of Light（巴黎）。

Timothy M. O'Brien作為一個專業的歌手/程序員現正在芝加哥地區工作和生活。




讓我們開始使用Maven。在本章結束時，你應該能夠從頭建立一個Maven的項目，使用Maven進行相關管理，創建基于某些感興趣報告的簡單的web站點。

安裝Maven
開 始本書以前，你有一些必備的安裝工作。本書中的例子用Java1.4.2編寫，Maven能夠兼容Java1.4.2和Java1.5.0。本書中所寫 Maven的最新版本是在編寫本書時發布的—Maven 1.0.2。除JDK和Maven1.0.2之外，你還需要連接到Internet，Maven將通過公網站點下載相關其需要的。那么，前進，安裝 Maven吧。

我該如何做？
從Apache Software Foundation(ASF)下載Maven。進入http://maven.apache.org/從左側的導航菜單中的Getting Maven菜單選擇下載。它將帶你進入一個讓你選擇Windows 安裝包、zip文件、tar'd.bzip文件或者tar'd.gzip文件。下載適合你平臺的分類。

我該如何做？
從Apache Software Foundation(ASF)下載Maven。進入http://maven.apache.org/從左側的導航菜單中的Getting Maven菜單選擇下載。它將帶你進入一個讓你選擇Windows 安裝包、zip文件、tar'd.bzip文件或者tar'd.gzip文件。下載適合你平臺的分類。

提示
某些Developer's Notebook中涉及的插件未與Maven1.0.2
綁定。請參考第6章并且附錄A有安裝Maven所需插件的全部
列表以及詳細說明。


在Microsoft Windows平臺，下載Windows安裝包（maven-1.0.2.exe），跟隨自動安裝過程中的提示。在使用Maven Windows 安裝器進行安裝后，你應該定義一個用戶環境變量，MAVEN_HOME，指向你本地的Maven安裝。你此時需要進入控制面版→系統→高級選擇環境變量按 鈕，添加%MAVEN_HOME%\bin到你的PATH環境變量。進入命令提示行運行cmd.exe，如果Maven安裝成功，你將能夠看到命令行有下 面的輸出：
C:\dev\mavenbook\code>maven -v
__??__
|??\/??|__ _Apache__ ___
| |\/| / _` \ V / -_) ' \??~ intelligent projects ~
|_|??|_\__,_|\_/\___|_||_|??v. 1.0.2

如 果你愿意安裝Maven到一個除了C:\Program Files\Apache Software Foundation\Maven 1.0.2的目錄，你也可以下載Maven1.0.2.zip文件，解壓縮到任何目錄。設置MAVEN_HOME指 向到Maven解壓縮的目錄，并且添加%MAVEN_HOME%\Bin到你的PATH環境變量。

在Unix平臺，下載 tar'd.zip文件（Maven-1.0.2.tar.gz）并接壓縮tar xvzf maven-1.0.2.tar.gz到你選擇的目錄。本試驗假設你解壓Maven到/usr/local/maven-1.0.2目錄下。你此時需要設 置兩個環境變量，MAVEN_HOME和PATH。下面的命令為這兩個變量設置適當的值：
[tobrien@mavenbook tobrien]$ export MAVEN_HOME=/usr/local/maven-1.0.2
[tobrien@mavenbook tobrien]$ export PATH=${PATH}:${MAVEN_HOME}/bin
如果Maven被成功安裝到你的機器，你能夠看到與Windows系統同樣的輸出。恭喜！你已經成安裝了Maven。

提示
有些人喜歡保存本地應用程序在Unix下的/opt目錄或
Windows下的c:\apps。你可以根據個人喜好安裝Maven。

剛剛發生了什么？
你剛剛安裝了Maven1.0.2并且配置了一些環境變量。是的！一旦你對MAVEN_HOME進行了有效的設置或是maven.bat或maven.sh已經存在，你已經能夠完成Developer's Notebook本次的實驗。

關于....
??????????..Maven 2?
是 時機提及Maven 2（有時也被稱為“m2”）。Maven 2完成了對Maven 1的重寫。重寫的首要目的是要提供了強大的Jave構建和包含API的項目，允許Maven被植入任何地方，尤其是高級別的產品如IDEs、質量工具、報 告工具等這些。Maven 2構建生命周期的概念正式話，其比Maven更易擴展。

Maven 1和Maven 2有許多共同點，但它們還有幾個主要的不同之處。在書中的各個部分我們盡可能提示你所希望了解的那些不同之處。更多關于Maven 2的信息，請轉到http://maven.apache.org/下載Maven 2的體驗版本，并加入Maven用戶或開發者郵件列表。如果你聽過Continuous Integration，你可能也想看一看命名為Continuum的Maven子項目，地址在http: //maven.apache.org/continuum。

開始一個新的項目
創建新項目的爭論一部分在于有很大部分的工作努力被用到在“發展基礎設施”上—自動構建、單元測試、文檔、項目報告等。使用Maven你可以加速這個過程，生成項目的框架使其作為新應用的種子。


我該如何做？
Maven 擁有一個應用程序生成插件（Genapp）你能通過其創建一個新項目。首先創建一個空的目錄c:\dev\mavenbook\code\genapp\ test-application這將成為應用程序生成后的處所。通過執行genapp這個目標來運行Genapp插件，選擇默認的模版并且提供一些你的 新項目的相關信息。
C:\dev\mavenbook\code\genapp\test-application>maven genapp

__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.2
Attempting to download commons-jelly-tags-interaction-20030211.143817.jar.
4K downloaded
Enter a project template to use: [default]
[Enter]
Please specify an id for your application: [app]
test-application
Please specify a name for your application: [Example Application]
Test Application
Please specify the package for your application: [example.app]
mdn.testapp
build:start:
genapp:
[copy] Copying 1 file to C:\dev\mavenbook\code\genapp\test-application\
src\java\mdn\testapp
[copy] Copying 3 files to C:\dev\mavenbook\code\genapp\test-application\
src\test\mdn\testapp
[copy] Copying 1 file to C:\dev\mavenbook\code\genapp\test-application\
[copy] Copying 2 files to C:\dev\mavenbook\code\genapp\test-application\
BUILD SUCCESSFUL

本 插件會要求用戶一些輸入，從這個輸出內容你可以看到你使用了默認的（defalut）應用程序模板，并且你提供了新項目的應用程序ID、name，和包 名。默認的（default）應用程序模板創建了一個單獨的類，mdn.testapp.app，和一個靜態main函數和兩個JUnit測試。

Maven的應用程序生成插件生成了下面的目錄和文件：

test-application/
project.properties
project.xml
src/
conf/
app.properties
java/mdn/testapp/
App.java
test/mdn/testapp/
AbstractTestCase.java
AppTest.java
NaughtyTest.java

所 有Maven項目有一個參考了項目對象模型（POM）的標準目錄結構, （as described shortly）。如果你有一些現存的類你想添加到一個項目，添加它們到src/java，如果你有一些單元測試將它們添加到src/test。如果這些 已有的類和單元測試依賴一些外部的苦，你將在隨后的章節看到如何添加一個附屬。xdos目錄包含了格式為XDoc的項目文檔。

提示
請注意Maven1.0.2裝載的Genapp插件版本創建了非標準
的布局。在Maven項目中src/java和src/test不再出現
在固有的源代碼和單元測試位置。取而代之的是你可
以使用src/main/java和src/test/java。為了改變這些，
修改你項目的xml文件，改變src/java的引用為src/main-
/java，src/test的引用為src/test/java。更多的信息，
請參見“Maven Conventions”,地址在
http://maven.apache.org/-reference/conventions.html。

project.xml是項目的描述符；它是一個內容為POM的XML文件。讓我們看看這個project.xml的拷貝，其已經定義了這個項目：

<project>
<pomVersion>3</pomVersion>
<artifactId>test-application</artifactId>
<name>Test Application</name>
<currentVersion>1.0</currentVersion>
<organization>
<name>Your Organization</name>
<url>http://www.someorganization.biz/</url>
<logo>http://www.someorganization.biz/logo.gif|jpg|...</logo>
</organization>
<inceptionYear>2005</inceptionYear>
<package>mdn.testapp</package>
<logo>http://yourproject/logo.jpg|gif|...</logo>
<description>
An example project
</description>
<shortDescription>
How to use maven in different situations
</shortDescription>
<!-- Many Elements Omitted (see generated POM) -->
<dependencies/>
<build>
<sourceDirectory>src/java</sourceDirectory>
<unitTestSourceDirectory>src/test</unitTestSourceDirectory>
<unitTest>
<includes>
<include>**/*Test.java</include>
</includes>
<excludes>
<exclude>**/NaughtyTest.java</exclude>
</excludes>
</unitTest>
<resources>
<resource>
<directory>src/conf</directory>
<includes>
<include>*.properties</include>
</includes>
</resource>
</resources>
</build>
</project>

該文件告訴Maven有關你項目的全部。build元素定位應用程序原碼，單元測試和資源文件包的位置。name, artifactId, currentVersion, inceptionYear, description。
shortDescription標識該項目并且提供了該項目的信息被用作完成品的名字來創建項目。

提示
如果你工作在已有的Maven項目，你應該看到id元素在
artifactId的位置。該id元素已經不被贊成使用，
你可以用artifactId替代。

resources 元素被用于JAR插件拷貝資源到JAR生成物。在該元素你指定一批資源到資源庫。本例中，自src/conf的資源將被復制到classpath的根目 錄。換言之，app.properties資源將被復制到所生成的JAR生成物的根目錄。如果你想所有位于src/conf的*.properties資 源和*.xml資源在mdn.testapp包中生成的JAR有效，你可以按照以下來指定targetPath：

<resource>
<directory>src/conf</directory>
<targetPath>mdn/testapp</targetPath>
<includes>
<include>*.properties</include>
<include>*.xml</include>
</includes>
</resource>

project.properties讓你能夠定制Maven及其插件在本項目中的行為。你將在看過本書之后使用該文件定制所生成web站點的品質和JAR文件的內容。

提示
關于在沒有Genapp插件來生成新Maven項目的快速入
門指導，參見BrettPorter的“The Ten Minute Test”，
地址在http://maven.apache.org/start/ten-minute-
test.html。

關于...
... Maven在有關協作項目中跟蹤信息的能力？
為簡化本例，我們從project.xml文件中去掉了一些初期顯示的描
述項目郵件列表、知識庫、開發者和web站點的元素。第4、5章深
入更多有關使用Maven發布web站點和在現有源碼庫中工作的細節。


在代理服務器下使用Maven
Maven依賴于Internet連接，其通過HTTP下載相關的插件。如果你工作在公共環境，你可能需要配置Maven來與工作代理服務器系統。


我該如何做？
你 可能需要設置你項目中project.properties文件的一些屬性。project.properties文件允許你通過設置命名的屬性來定制 Maven的行為。配置代理服務器，放置下面的project.properties到與你項目中project.xml文件同樣的位置：
maven.proxy.host = proxy.company.com
maven.proxy.port = 80
并且，如果你需要連接到一個代理服務器必須有NTLM的授
權，設置以下屬性：
maven.proxy.ntlm.username = tobrien
maven.proxy.ntlm.password = myp@ssw0rd

提示
在第二章，你將學到user-specific屬性將被定義在
~/build.properties或%USERPROFILE%\build.properties 文件。現在，如果你需要完成本試驗，在 project.properties里定義這些屬性。

編譯和測試一個項目
你擁有了一個包含一個類文件和單元測試文件的項目。下
面，讓我們夠見這個項目和運行應用程序類吧。

我該如果做？
通過執行jar:jar goal來創建一個包含應用程序的類的jar
文 件。JAR插件定義了一個速記目標命名為jar其依賴之前的jar:jar goal。執行任何一個目標將得到相同的結果。所有的插件都定義了一條這樣的捷徑；例如，測試目標執行的是Test插件里的test:test goal。執行jar goal和maven jar：

C:\dev\mavenbook\code\genapp\test-application>maven jar
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.2
Attempting to download junit-3.8.1.jar.
118K downloaded
build:start:
java:prepare-filesystem:
[mkdir] Created dir: C:\dev\mavenbook\code\genapp\test-application\
target\classes
java:compile:
[echo] Compiling to C:\dev\mavenbook\code\genapp\test-application/
target/classes
[echo]
[javac] Compiling 1 source file to C:\dev\mavenbook\code\genapp\testapplication\
target\classes
java:jar-resources:
Copying 1 file to C:\dev\mavenbook\code\genapp\test-application\target\
classes
test:prepare-filesystem:
Compiling and Testing a Project 9
[mkdir] Created dir: C:\dev\mavenbook\code\genapp\test-application\
target\test-classes
[mkdir] Created dir: C:\dev\mavenbook\code\genapp\test-application\
target\test-reports
test:test-resources:
test:compile:
[javac] Compiling 3 source files to C:\dev\mavenbook\code\genapp\testapplication\
target\test-classes
test:test:
[junit] Running mdn.testapp.AppTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.078 sec
jar:jar:
[jar] Building jar: C:\dev\mavenbook\code\genapp\test-application\
target\test-application-1.0.jar
BUILD SUCCESSFUL
Total time: 9 seconds

Maven創建一個target（目標）目錄來保存中間文件和JAR文件。在JAR首次被建立后，按照下面執行App類。

C:\dev\mavenbook\code\genapp\test-application> java ^
More? target\test-application-1.0.jar mdn.testapp.App
Hello World!

如果你想重復此項工作，運行maven clean來移除target目錄重新構建。

剛剛發生了什么？
當 你運行jar目標時，Maven使用JAR插件來創建了一個JAR生成物。首先，Maven找到一系列的目標以便能夠創建這個應用程序的JAR文件； JAR插件有一個其它目標所依賴于目標的jar:jar goal，反過來，它也依賴于其他的目標。Maven找出下列需要的目標來執行：java:prepare-filesystem，java: compile，java:jarresources，
test:prepare-filesystem，test:test-resources，test:compile，and test:test。

Maven查看其需要執行目標中的Test插件來執行單元測試，并且檢查本地Maven庫中的JUnit JAR文件。因為你還沒有使用過Maven，所以它將從位于http://www.ibiblio.org/
maven/的Maven默認庫中下載junit-3.8.1.jar。你將在本章后學習到有關Maven本地庫和Maven強大的相關管理能力的內容。


與項目對象模型一同工作
Project Object Model（POM）是Maven的重要部分，你將與其一同工作貫穿本書。


我該如何做？
POM 同樣涉及到項目的描述。project.xml描述了項目的源代碼、開發者、源控制，許可和標示信息譬如項目名稱和發起組織。Maven打破了過去傳統的 構建系統；取而代之的是為每個構建提供了外在說明，Maven使用聲名的方法管理構建。換句話說，你不用過多的告訴Maven做什么，Maven知道去查 找基于project.xml中的內容。另一方面，Ant以命令方式進行項目構建；你最終要告訴Ant編譯這個文件，建立這個目錄，綁定這些文件到WAR 等等。Maven維護一個插件的分類來與標準的POM—一個結構聲明、標示和內容工作。

如果你看了上次練習所生成的project.xml文件，你將注意到許多元素都在上次討論中被忽略。下面的XML列出了POM中頂級的元素，（in the order in which they are expected:
）：

<project>
<extend/>
<pomVersion/>
<id/>
<name/>
<groupId/>
<currentVersion/>
<organization/>
<inceptionYear/>
<package/>
<logo/>
<gumpRepositoryId/>
<description/>
<shortDescription/>
<url/>
<issueTrackingUrl/>
<siteAddress/>
<siteDirectory/>
<distributionSite/>
<distributionDirectory/>
<repository/>
<versions/>
<branches/>
<mailingLists/>
<developers/>
<contributors/>
<licenses/>
<dependencies/>
<build/>
<reports/>
<properties/>
</project>

本 章探究更多以上XML列出的元素，包括contributors，developers，dependencies，reports和 repository。本章的式樣將提供這些細節，但你應該使用上面XML的摘錄來以適當的順序放置這些元素到你的project.xml中。

列出有效的Goals
當你使用Maven時，你將執行目標。Maven插件是一組相關的插件。例如，要為一個項目創建JAR文件，你將如下所示執行JAR插件中的jar:jar goal。
C:\dev\mavenbook\code\genapp> maven jar:jar
冒號之前的jar分類這個目標屬于JAR插件。查看全部的JAR插件列表，鍵入以下命令：
C:\dev\mavenbook\code\genapp> maven -P jar
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.2
Goals in jar
============
[jar] Create the deliverable jar file.
deploy ......................... Deploy a jar to the remote repository
deploy-snapshot ................ Deploy a snapshot jar to the remote
repository
install ........................ Install the jar in the local repository
install-snapshot ............... Install a snapshot jar in the local
repository
jar ............................ Create the deliverable jar file.
snapshot ....................... Create a snapshot jar, ie '
id-YYYYMMDD.hhmmss.jar'
Plugin for creating JAR files. Requires Maven 1.0 RC2.

如果你需要查看每個有效的插件和目標，輸入下面內容：
C:\dev\mavenbook\code\genapp\test-application> maven -g | more
全部的插件可能使人有些畏懼，Maven有關于一切的插件，從生成項目文件到IDEs到生成WAR文件以及開始和停止應用服務器。你將在下面的實驗中學習到一些更有用的插件。

生成調試信息
現 在，你可能已經注意到Maven執行了許多繁重的工作。如果你使用Ant，你可能已經開始編寫Ant的build.xml文件并且添加編譯.jar任務和 單元測試。Maven隱藏了許多復雜性，但當調試問題時，它也能夠查看“幕后”。這個能力運行于Maven的調試模式并且這個工具打印輸出每個構建的細節 重要的是你可以根據需要來驗證構建是否正確執行。


我該如何做？
本次實驗，參考上一個測試應用程序。當你運行maven test，你將收到如下信息：

java:compile:
[echo] Compiling to 
C:\dev\mavenbook\code\genapp\test-application/
target/classes
[echo]
java:jar-resources:
[...]

在執行java:comile或java:jar-resources目標時到底發生了什么？執行構建項目中運行maven -x test將顯示全部目標的調試信息。讓我們來是一下，把注意力放在最早的第三個目標上。運行maven -x test生成下面的輸出：

[...]
java:compile:
[echo] Compiling to C:\dev\mavenbook\code\genapp\test-application/
target/classes
[javac] [DEBUG] fileset: Setup scanner in dir
C:\dev\mavenbook\code\genapp\test-application\src\java with
patternSet{ includes: [ ] excludes: [**/package.html] }
[javac] [VERBOSE] mdn\testapp\App.java omitted as mdn/testapp/App.class
is up to date.
java:jar-resources:
[DEBUG] FileSet: Setup scanner in dir
C:\dev\mavenbook\code\genapp\test-application\src\conf with
patternSet{ includes: [*.properties] excludes: [ ] }
[VERBOSE] app.properties omitted as app.properties is up to date.
[...]

java:compile的打印輸出任務可能看起來很熟悉。它是Ant的echo和javac任務的輸出。Maven常常使用Ant的進程來執行常用操作如：拷貝、刪除、編譯和創建JAR文件。

剛剛發生了什么？
這兩個目標執行的都是非常簡單的調試輸出。java:compile目標簡單的掃描源目錄中java源碼中較新的相關類文件。java:jar-resources目標尋找資源中包含的JAR文件。更復雜的如test:test將產生有關虛擬機和類加載器的調試信息。

當Maven有問題或某個目標拋出異常，Maven將簡單打印較少的錯誤信息來告訴你有錯誤發生。如果你需要等多信息，并且看到堆棧跟蹤，添加-e標志到命令行。與-e標志一起，Maven將打印完整的堆棧信息當其遇到錯誤時。

添加依賴關系
你 有了一個擁有單個類文件并且已經成功編譯執行的項目。下面，你將添加一個依賴關系到項目描述器并且開始使用Maven管理項目依賴關系。本次實驗的目的 是，假設你需要工作在Spring框架中。添加Spring框架-spring-core-1.1.4.jar和spring-web- 1.1.4.jar的依賴關系。


我該如何做？
首先，你需要根據需要定位Maven默認中心源碼庫中的 JAR文件。ibiblio.org在http://www.ibiblio.org/maven/提供了這些。在Web瀏覽器中加載這個URL你將看到 一系列的目錄；我們關心的是springframework的目錄，springframework下子目錄的結構如下所示：
http://www.ibiblio.org/maven
/springframework
/jars
spring-core-1.1.4.jar
spring-dao-1.1.4.jar
spring-web-1.1.4.jar

依照人造物，你使用dependency—groupId, artifactId和version三個元素。你能夠添加兩個依賴關系的完成品以替代test-application/project.xml中的dependencies元素如下所示：

<dependencies>
<dependency>
<groupId>springframework</groupId>
<artifactId>spring-core</artifactId>
<version>1.1.4</version>
</dependency>
<dependency>
<groupId>springframework</groupId>
<artifactId>spring-web</artifactId>
<version>1.1.4</version>
</dependency>
</dependencies>

現在，運行jar目標并且看看Maven的輸出吧；它將包含下面如下這些。

Attempting to download spring-core-1.1.4.jar.
266K downloaded
Attempting to download spring-web-1.1.4.jar.
111K downloaded

圖1-1顯示了jar目標觸發的一系列事件：
1.Maven查看POM,依據project.xml的定義，看到在springframework組中的兩個人造物的依賴關系。它將載你本地Maven的資源庫中檢查spring-core-1.1.4.jar和spring-web-1.1.4.jar。
2. 當Maven找不到這些文件，它將到http://www.ibiblio.org/maven/springframework/jars/尋找JAR 文件。這些JAR文件會被下載并放置于你本地Maven的資源庫中。它們也被添加到你項目的classpath中。下次在你的項目查詢這些文件時， Maven將在你本地的資源庫中提供它們。


圖1-1.Maven本地和遠程資源庫為test application項目提供的spring Jar。

剛剛發生了什么？
Maven 為你節省了相當的時間和不必要的麻煩。Maven到來之前，依賴關系常常被捆綁到一個項目的目錄或者項目應該指向到添加正確的JAR到你的 classpath。使用Maven管理依賴關系顯然有著明顯的優勢；作為初學者，如果你的項目依賴30個外部的JAR文件，這就不需要在你的資源庫中存 儲成兆的JAR文件。這意味著當你在項目的外部檢查資源控制的時候更少的存儲空間和更快的下載時間。另外，如果你有多個項目依賴相同的外部依賴， Maven僅需要下載一次依賴關系，并且每個項目引用一個單獨的副本在你本地的資源庫中。當依賴關系能夠從Maven資源庫遠程下載的時候，沒有強制的原 因讓你存儲你項目的依賴關系的版本。

當Maven下載依賴關系，其在你本地的機器上從遠程的Maven資源庫拷貝一個文件到你本地的Maven資源庫。Maven如何定位依賴關系的？它使用project.xml中dependency元素的信息，如圖1-2所示。


圖1-2.POM和Maven資源庫的映射。

指 定的groupId告訴Maven查看特定的目錄-springframework。指定type告訴Maven查找特定的子目錄如jar和war（注意 s是Maven附加到type元素上的）；本例中，type是被忽略的，JAR類型是默認類型。當你指定了artifactId，你正告訴Maven哪個 文件將從jar目錄下載。頂級目錄表現為組標示符，JAR文件名的第一部分表現為artifact標示符，文件名最后的部分，包括擴展名表現為 version標示符。Maven使用下面的公式來決定一個來自于資源庫中的依賴關系。[REPO_ROOT]參考你遠程的資源庫：

[REPO_ROOT]/<groupId>/<type>s/<artifactId>-<currentVersion>.<type>

提示
Maven2.0的說明中，資源庫可能開始于類似Java包的
結構。作為springframework的替代，groupId被提議
的結構為org.springframework。另外，每個版本將有
一個分隔目錄用以增加Maven資源庫的效率。更多有關
改變的提交建議，參見http://docs.codehaus.org/display/
MAVEN/Repository+Layout+-+Final。

一 個本地的資源庫來處理依賴關系。在Unix機器上，你的Maven資源庫能在~/.maven/repository目錄找到，在Windows機器上， 你的Maven的資源庫在你的%USERPROFILE%目錄。如果你看一看本地Maven的資源庫，你將會注意到它正包含一個 springframework的目錄。%USERPROFILE%\.maven\repository\springframework\jars目 錄包含spring-core依賴關系的兩個：spring-core-1.1.4.jar文件和spring-core-1.1.4.jar.md5文 件,其包含MD5文件用于驗證sprint-core JAR文件的完整性。Maven 1當前并沒有使用MD5來驗證完成品的完整性，但在將來的版本可能會用其來驗證完成品的完整性。

提示
在Windows機器上，%USERPROFILE%通常決定于C:\D-
ocuments and Settings\vmassol這種目錄。%USERPR-
OFILE%被用在Unix的主目錄。（%USERPROFILE% is
used in the spirit of the abbreviation for a Unix home directory。）

關于...
...使用id元素?

如果你工作在現存的Maven項目，你可能有依賴關系使用id元素。下面的dependencies元素示范了使用單獨id元素來附加Jakarta Commons Math的1.0版本：

<dependencies>
<dependency>
<id>commons-math</id>
<version>1.0</version>
</dependency>
</dependencies>

單獨使用id元素工作僅在groupId和artifactId匹配時，如果你瀏覽Maven資源庫，你將看到下面的目錄結構：
/commons-math
/jars
commons-math-1.0.jar
commons-math-1.1.jar

使用id元素工作，單獨的id標記已經不被贊成使用并在Maven 2中消失。當你看到別的Maven項目中使用dependencies的速記符號時，請嘗試使用groupId和artifactId來標識你的依賴關系。

依賴快照
如果你開發的程序依賴的依賴關系經常改變，你可能想將依賴的每個依賴關系替代為最近構件的硬編碼的版本。在一個項目依賴的依賴關系還處在beta的版本，或你正開發一系列項目依賴的Maven項目時時特別有用，這將在第3章論述。本實驗，你將學習到如何依靠快照。


我該如何做？
在 你的依賴關系塊兒中指定一個明確的版本，使用SNAPSHOT關鍵字作為版本名稱的一部分。每次你執行Maven目標時，Maven將從遠程資源庫中檢查 較新的依賴關系。如果遠程資源庫的版本較新Maven將下載其到本地資源庫。例如：下面的依賴關系將一直下載spring的新版JAR文件。

<dependency>
<groupId>springframework</groupId>
<artifactId>spring</artifactId>
<version>1.2-SNAPSHOT</version>
</dependency>

剛剛發生了什么？
當 你使用SNAPSHOT依賴關系，你正告訴Maven使用遠程資源庫的最新版本。在你使用多項目插件或者當你依賴的一個完成品尚處于開發階段這將得心應 手。在你工作的團隊僅有較少的開發者組成時，最好也常這么做。你將使用SNAPSHOT依賴關系當你的項目依賴一個最近的開發或者非正式版本的特別組件。 SNAPSHOT依賴關系應該在開發階段被保留，并且，概括說，你不用改發布一個依賴于SNAPSHOT依賴關系的項目。

執行脫機構建
如果你需要在一個離線的情況下使用Maven，你可能需要知道如何確使Maven不檢查最新的SNAPSHOT依賴關系。本實驗將向你展示如何用Maven執行脫機構建。


我該如何做？
這 個方法很簡單：僅僅使用-o命令行選項。例如，如果你沒有網絡連接，但又想執行測試目標，運行Maven -o test。Maven將執行這個test目標而不檢查依賴關系。如果你的項目沒有依賴SNAPSHOT構建，你也可以斷看你的環境來添加-o標志。如果你 依賴SNAPSHOT構建，你將需要使用-o標志，Maven將在每次執行目標時嘗試檢查最新的SNAPSHOT。在這種情況下不使用-o標志本項目將不 會構建成功。


關于...
... 執行離線構建如果你不想下載任何完成品？
當然，這將不會工作。離線構建的工作，你必須已經有必需的依賴關系在你本地的資源庫。項目最簡單的獲得Maven下載依賴
關系的方法是在每個Maven項目實例簡單的運行“noop”目標，build:start。這個目標執行之前任何其它的目標并不執行任何動作。如果你運行build:start，Maven將從project.xml獲得獲取任何依賴關系。


使用Maven控制臺
如 果你再三的從命令行運行Maven，你可以通過Maven控制臺來節省時間。Maven控制臺提供一個“外殼”，在這你可以鍵入目標的名稱來執行 Maven。通過使用Maven可以避免每次載你想運行一個Maven目標時Java Virtual Machine（JVM）啟動的等待。


我該如何做？
Maven Console是一個插件，你可以通過鍵入maven console在命令提示符。這將產生下面的輸出：

__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.2
The following commands are available:
list - list all available goals
help - this message
<goalname> - attain a goal
quit - quits the console
test-application 1.0 >

目 前，你可以在命令行執行任何你能執行的目標。開始是一下；鍵入 java:compile。Maven將執行 java:compile目標并返回提示符其它的目標。在一個序列中運行兩個目標，你可以在提示符處輸入它們，通過“空格”-例如， clean test。眾所周知作為“goal chaining”這是你想通過Maven獲得指定一系列目標的方法。退出Maven Console，鍵入quit，查看有效目標列表，鍵入list。

剛剛發生了什么？
在Maven Console下Maven執行java:compile目標非常之快，不信么？當你使用Maven Console時你所執行的目標是在一個現成的JVM下。當你從命令行運行Maven時，你每次運行一個目標都不得不等待JVM的啟動。如果你不確信其對 性能的提升，自己試試看。在命令行下運行java:complie 10次，再在Maven Console下同樣運行java:compile 10次。注意時間的差別，你將發現JVM啟動的時間開始增加。如果你找到你自己常用的Maven目標，Maven Console將通過啟動JVM一次為來節省時間。


生成Eclipse項目
我打賭你一定想在IDE下工作。Maven通過插件來與Eclipse,InelliJ,IDEA,JBuilder,JDeveloper以及Emacs集成。Maven很好的與全部這些工作集成，本實驗關注其在Eclipse上的集成，一個開源的IDE。


我該如何做？
這個過程很簡單；僅僅執行eclipse插件：

C:\dev\mavenbook\code\genapp\test-application> maven eclipse
build:start:
eclipse:generate-project:
[echo] Creating C:\dev\mavenbook\code\genapp\test-application/.project ...
eclipse:generate-classpath:
[echo] Creating C:\dev\mavenbook\code\genapp\test-application/.classpath ...
[echo] Contains JUnit tests
[echo] Setting compile of src/test to target/test-classes
Plugin 'cactus-maven' in project 'Test Application' is not available
[echo] Setting default output directory to target/classes
eclipse:
[echo] Now refresh your project in Eclipse (right click on the project
and select "Refresh")
BUILD SUCCESSFUL
Total time: 2 seconds

Maven創建兩個文件以識別Eclipse的項目：.project和.classpath。在Eclipse中，你就可以通過下面的步驟導入這個工程了：
1.啟動Eclipse。
2.從菜單欄選擇File→Import...&#61472;
3.選擇現存項目放入Workspace并單擊Next按鈕。
4.在Import對話框選擇C:\dev\mavenbook\code\genapp\test-application目錄，并單擊Finish按鈕。

你稍候將執行更多步來指向Eclipse到本地Maven資源庫。Eclipse使用一個名叫MAVEN_REPO來指向到本地Maven資源庫。你能通過在命令行執行下面的操作設置MAVEN_REPO來使用Maven:
maven -Dmaven.eclipse.workspace=c:\eclipse\workspace eclipse:add-maven-repo
執行這個目標可以設置位于目錄c:\eclipse\workspace的全局變量MAVEN_REPO。
作為選擇，你可以按照這些步驟手工配置該變量：
1.從菜單欄中選擇Window→打開Eclipse Preferences選擇preferences。
2.在樹型菜單左手邊的Preferences對話框，選擇Java→Build Path→Classpath變量。
3.單擊New按鈕來創建一個新的變量；這可以帶入到新變量對話框。
4.輸入MAVEN_REPR到Name域。
5.單擊Folder按鈕選擇你本地的Maven資源庫。
6.單擊OK并重新構建你的項目。

你可能需要配置MAVEN_REPO僅一次；該變量是全局的它可以與全部Eclipse項目共享。

關于...
... JBuilder, JDeveloper, and IntelliJ IDEA？
所有這些IDE有著Eclipse一樣簡單的插件。為JBuilder 項目生成必需的文件，運行mave jbuilder，對于JDeveloper運行mave jdeveloper，為IntelliJ IDEA項目運行mave idea。


使用Maven的Eclipse插件
是的，這是一個你可以使用的高品質的Maven插件。它提供了許多有趣的特性，如編輯project.xml文件的能力，支持Maven自定義，Maven資源庫瀏覽等其他功能。


我該如何做？
Mevenide (http://mevenide.codehaus.org/mevenide-ui-eclipse/update/index.html) 是一個Eclipse插件其允許你使用Maven在Eclipse中工作。你能夠按照如下指導從Eclipse更新站點上下載它：
1.啟動Eclipse。
2.從菜單中選擇Help→Software Updates→Find and Install。
3.在Install/Update和更新的對話框中，選擇“Search for new feature to install,”并單擊下一步。
4.在Install對話框中，單擊New Remote Site。
5. 在New Update Site對話框中，鍵入Mevenide在Name域，其位置在Eclipse Updates站點的URL區域。Mavenid在Eclipse Update站點中的位置是http: //mevenide.codehaus.org/release/eclipse/update/site.xml。
6.當單詞Mevenide出現在Install對話框中，選擇兩個子目標，Maven和Mevenide并單擊Next。
7.直到Maven和Mevenide被下載和安裝，重起Eclipse。

首 先你會注意到Mevenide標注所有project.xml文件為綠色圖標。在Project Object Model編輯器中打開project.xml，右擊任何project.xml文件并選擇Open With...→Project Object Model編輯器。該編輯器如下圖1-3所顯示。



Mevenide 在Eclipse中提供了一系列tab讓你編輯不同的project.xml片斷。如果你學到了很多的project.xml語法，就知道 Mevenide的Project Object Model編輯器提供了GUI接口來維護這個XML文件。如果你仍然希望直接編輯這個XML，你能夠選擇最右邊的Source tab。
除POM 編輯器之外，Mevenide也為你提供了Eclipse以外執行Maven目標的方法。要在Eclipse中執行一個Maven目標，選擇 Run→External Tools…→External Tools…你就能夠創建一個Maven的配置并從全部有效的目標中選擇你希望執行的目標。當目標在Eclipse中被執行，通過Console視圖有效 得顯示它的輸出。

Mevenide提供的另一個有趣的功能是Repository Browser。這個工具允許你檢查許多遠程資源庫的內容。打開Repository Browser，選擇Window→Show View…→Other…，此時在Maven目錄的結果對話框中選擇Repository Browser。Repository Browser簡單的以樹型顯示了資源庫中的全部依賴關系（dependency），如圖1-4所示，其顯示了HTTPClient和abbot group的依賴關系。


圖1-4.Mevenide Repository Browser view

如果你想搜索資源庫中完成品的細節，Mevenide同樣提供了資源庫搜索功能。這將是得心應手的因為為了某個依賴關系的細節搜索http://www.ibiblio.org/maven是非常惱人的。檢查Mevenide；它將為你節省時間。

關于...
... NetBeans和JBuilder？
Mevenide當前的版本支持這兩個IDE的表現。更多詳情參見http://mevenide.codehaus.org/。
... IntelliJ？
IDEA插件維持了一些目標如同你在Eclipse中使用的目標。更多詳情參見位于http://maven.apache.org/reference/plugins/idea/goals.html的IDEA插件的聯機文檔。


生成Ant構建文件
當 你想用Apache的Ant構建的某些時候。可能你的項目使用自動化處理正依賴于Ant，又可能你有一些團隊成員沒有完成到Maven的轉換并且他們希望 繼續使用Ant。目前為止許多IDE提供通過Ant構建項目文件，你能夠使用Maven生成build.xml文件這樣你的項目就能夠被Apache的 Ant所構建。


我該如何做？
運行Ant插件。運行maven ant將創建build.xml文件其包含到聚合的依賴關系的目標，build和test你的應用程序。看看運行默認的jar目標的輸出：

C:\dev\mavenbook\code\genapp\test-application>ant
Buildfile: build.xml
init:
[mkdir] Created dir: C:\dev\mavenbook\code\genapp\target\lib
get-deps:
[get] Getting: http://www.ibiblio.org/maven/springframework/jars/
spring-core-1.1.4.jar
[get] Getting: http://www.ibiblio.org/maven/springframework/jars/
spring-web-1.1.4.jar
compile:
[copy] Copying 1 file to C:\dev\mavenbook\code\genapp\target\classes
junit-present:
[echo] = = = = = = ============ WARNING = = = == = = = = = = = = = = = = = = = = = = =
[echo] Junit isn't present in your ${ANT_HOME}/lib directory. Tests not
executed.
[echo] = = ==============================================
compile-tests:
internal-test:
test:
jar:
[jar] Building jar: C:\dev\mavenbook\code\genapp\test-application\
target\test-application-1.0.jar
BUILD SUCCESSFUL
Total time: 2 seconds

你 可能注意到這里存在一個問題，這是個說明性的問題。Apache Ant沒有自動管理依賴關系用于可選的Ant任務。如果你向運行JUnit單元測試，你就需要從本地Maven資源庫拷貝junit-3.8.1.jar 到${ANT_HOME}/lib下。這個構建文件包含了一個get-deps的目標其從位于http://www.ibiblio.org/maven 的遠程Maven資源庫為所有的項目依賴關系執行Ant獲得任務到gran。

關于...
... 試圖離開Ant?Maven是Ant的替代者么？
是 或不是。Ant并不“差”，并且多數工具仍然同Ant工作。沒有理由不提供與Apache Ant的交互，一旦你學到更多關于第2章的Jelly，你將發現Ant工作在Maven里應用的更廣泛。許多項目使用持續集成的系統如其期望的Ant構建 文件。運行maven ant provides很容易找到繼續支持這些工具。


移植一個Ant項目到Maven
一定數量的項目使用Ant作為構建系統，你可能打算移植到Maven上來。


我該如何做？
從 頭開始。創建一個默認的Maven模版，并且移動你的代碼到適當的位置。不要設法使Maven適合你項目的目錄和構建位置。Maven強過一個構建工具； 它是一個標準方式考慮到項目的布局和管理。如果你試圖使Maven適應你項目的想法來構建，你將結束使用Maven。如果你的項目由一個復雜的 buil.xml文件組成其產生許多不同的交付結果，你將需要“組件化”你的項目請跟隨第3章的多項目描述。你可能要開始移動你項目的目錄結構轉向標準的 Maven項目目錄結構。換而言之，不要試圖生搬硬套你的項目到Maven。
如果你對遷移到Ant感興趣，但你沒有時間停止開發，你可以使用 Maven調用你現存的Ant目標。如果你這么做，你將錯失使用Maven的大部分益處，但僅僅是可能。更多信息參見位于http: //maven.apache.org/using/migrating.html的“Migrating from Ant”。

關于...
... 靈活性和選擇？
靈 活性和選擇是個比較老的問題了。我們保證Maven將改變你構建和維護項目的方式方法，重要的是應該有意的使用Maven。Ant和Maven間的差別是 什么呢？Ant提供塊構建的可重用任務如copy,move,delete和junit，Maven提供了可重用的任務構建。Maven是一個“構建容 器”，其允許你在一系列項目上重用任務構建。以單元測試為例，使用Ant，你將通過在你項目的build.xml文件里包含下面來執行JUnit測試。

<junit printsummary="yes" haltonfailure="yes">
<classpath>
<pathelement location="${build.tests}"/>
<pathelement path="${java.class.path}"/>
</classpath>
<formatter type="plain"/>
<test name="my.test.TestCase" haltonfailure="no" outfile="result">
<formatter type="xml"/>
</test>
<batchtest fork="yes" todir="${reports.tests}">
<fileset dir="${src.tests}">
<include name="**/*Test*.java"/>
<exclude name="**/AllTests.java"/>
</fileset>
</batchtest>
</junit>

該 片斷省略的不同路經和變量的定義如build.tests和java.class.path，同時也省略的Ant目標的定義。另外一些單元測試類，你也需 要定義一個標以目標在源文件和單元測試中，并且一個目標對應創建一個目錄。每個項目需要定義同樣的邏輯以執行單元測試。最后，大多數的Ant項目使用了相 似的目錄結構，并且構建邏輯重用是通過拷貝和粘貼到build.xml文件。時間推移，項目將變的更復雜和用戶化，目錄標準增加并且每個項目趨于不同的編 譯、測試方法和包；久而久之，build.xml變成項目中的一部分了。你定制的Ant構建文件越大，越多的(entropy creeps)會進入到你的構建工作。Ant作為一個構建工具的能力要少于其作為語言提供構特性的API。1.6的Ant，含有了Ant庫和宏。在完成全 局可重用的表現上與Maven相比Ant還有一段很長的路要走。

利用Maven的Test插件為所有項目定義通用邏輯其需要編譯和執行單 元測試。單元測試插件為編譯和執行單元測試獲得了最好的實踐，并且它為所有項目達成了最有效的實踐。當你運行maven test，Maven從POM傳遞信息到Test插件，Test插件則依賴于Java插件來執行編譯。在Maven中沒有一處你明確的告訴構建容器如何執 行JUnit單元測試。如果你這么做了，在Ant中你將會面對同樣的問題。正如你不用告訴你的Servlet容器如何解壓WAR文件一樣，你不用告訴 Maven如何構建你的項目。Maven是一個構建容器。許多人最初被Maven吸引是因為它提供了依賴關系管理，但Maven最大的好處是它提供了標準 的開發結構來訪問多個項目。依賴關系管理僅僅是標準開發結構的一個簡單的副產品。

提示
Maven提供了開發結構，統一了項目布局，在最后你可
以嘗試讓Maven照管許多構建任務的細節。與其花費你
重要的時間來寫構建腳本，不如使用Maven插件來把焦
點放到編寫你應用程序上來。

下 面的章節將向你展示如何調整和定制Maven，但你需要確定你并不要求Maven成為另一個Ant。很有可能你有一個巨大的重建于Ant的 build.xml文件充滿了Jelly腳本（見第2章）并且的Maven項目和一個大的maven.xml文件。但如果這么做你則失去了所有Maven 的指向。如果你發想自己包含了很多構建相關的邏輯在你的Maven構建，你需要慎重考慮使用Maven。高定制化的Maven構建是矛盾的；你的 Maven項目應該對現存插件起到杠桿作用。例如，如果你的項目需要編譯Jave源文件，創建JAR文件，使用Jave插件和JAR插件。如果你忽略重用 Maven插件使用Maven的Ant集成則是重復制造輪子，你最好不要使用Maven。不要濫用Maven；合理使用Maven，省省你的火氣。

生成項目文檔
如果你正開發Java應用程序或者庫，你可能想生成JavaDoc。

我該如何做？
簡單的執行javadoc目標，Maven將生成項目的文檔。下面是執行javadoc目標的輸出：

C:\dev\mavenbook\code\genapp\test-application>maven javadoc
__ __
| \/ |__ _Apache__ ___
| |\/| / _` \ V / -_) ' \ ~ intelligent projects ~
|_| |_\__,_|\_/\___|_||_| v. 1.0.2
build:start:
xdoc:init:
maven-javadoc-plugin:report:
[mkdir] Created dir: C:\dev\mavenbook\code\genapp\test-application\
target\javadoc\src
[javadoc] Generating Javadoc
[javadoc] Javadoc execution
[javadoc] Loading source files for package mdn.testapp...
[javadoc] Constructing Javadoc information...
[javadoc] Standard Doclet version 1.5.0_01
[javadoc] Building tree for all the packages and classes...
[javadoc] Generating C:\dev\mavenbook\code\genapp\test-application\
target\docs\apidocs\constant-values.html...
[javadoc] Copying file C:\Documents and Settings\tobrien\.maven\cache\
maven-javadoc-plugin-1.7\plugin-resources\stylesheet.css to file C:\dev\
mavenbook\code\genapp\test-application\target\docs\apidocs\stylesheet.css...
[javadoc] Building index for all the packages and classes...
[javadoc] Building index for all classes...
[delete] Deleting directory C:\dev\mavenbook\code\genapp\testapplication\
target\javadoc\src
BUILD SUCCESSFUL
Total time: 7 seconds
Once this goal has been executed, JavaDoc is available in testapplication/
target/javadoc/src.

剛剛發生了什么？
再 次，Maven作了全部繁重的工作。你想要JaveDoc，你告訴Maven生成JaveDoc，故事結束。注意你不用告訴Maven任何你項目的情況； 它“知道”如何做，Maven這很多這樣的事都是直截了當的；在你告訴Maven有關你的項目后你就不用做什么了。Maven操作細節。



介紹Maven給你的團隊
Maven是一個偉大的協作工具，你能夠使用它生成開發者活動報告，項目捐贈者和郵件列表。


我該如何做？
許 多項目有一個郵件列表其被用于討論架構和實現。并且，通過透視圖，如Tomcat，Maven和Ant等項目，并不僅僅是一個開發者社區來共享捐贈到同樣 的郵件列表。郵件列表不僅用于開源項目；許多組織開始使用同樣的協作模型用于開啟，發布開發。因為郵件列表是協作的關鍵部分，Maven提供了在一個項目 的project.xml中指定郵件列表的途徑。下面引用project.xml添加郵件列表的元素：

<mailingLists>
<mailingList>
<name>Maven User List</name>
<subscribe>users-subscribe@maven.apache.org</subscribe>
<unsubscribe>users-unsubscribe@maven.apache.org</unsubscribe>
<archive>http://marc.theaimsgroup.com/?l=turbine-maven-user</archive>
</mailingList>
<mailingList>
<name>Maven Developer List</name>
<subscribe>dev-subscribe@maven.apache.org</subscribe>
<unsubscribe>dev-unsubscribe@maven.apache.org</unsubscribe>
<archive>http://marc.theaimsgroup.com/?l=turbine-maven-dev</archive>
</mailingList>
</mailingLists>

有 兩種類型的團隊成員位于Maven項目中：捐贈者和開發者。這種定義可能改變你的項目，捐贈者通常被認為是開源社區中捐贈過補丁或文檔者，開發者是一個項 目的核心成員。在ASF，提交者和捐獻者可以一同捐獻一個項目，但捐獻者既不寫資源庫代碼又不提交大的項目決定。下面引用了project.xml添加 contributor和developer元素到project.xml文件：

<developers>
<developer>
<name>Vincent Massol</name>
<id>vmassol</id>
<email>vmassol@apache.org</email>
<organization>Apache Software Foundation</organization>
<roles>
<role>Author</role>
<role>Developer</role>
</roles>
<url>http://www.massol.net</url>
<timezone>+1</timezone>
</developer>
</developers>
<contributors>
<contributor>
<name>Tim OBrien</name>
<email>tobrien@apache.org</email>
<organization>Apache Software Foundation</organization>
<roles>
<role>Author</role>
<role>Developer</role>
</roles>
<url>http://www.oreillynet.com/pub/au/1738</url>
<timezone>-6</timezone>
</contributor>
</contributors>

剛剛發生了什么？
你告訴Maven誰在這個項目工作，對于今后你生成項目的web站點很有用。開發者和捐贈者的信息在POM中以列表的通過站點生成插件，很多插件為資源控制生成報告。跟資源控制對話...。


向Maven到資源控制
你 使用資源控制么？把它告訴給Maven，在本書的下面你將能夠生成一些有興趣的描述報告。一旦你關聯了源代碼資源庫到你的項目，你將能夠是用Maven的 Source Control Management(SCM)插件，其提供了許多目標（goal）用于從諸如CVS和其子版本的版本控制系統更新和發布。


我該如何做？
你 需要添加一個respository元素到你項目的project.xml文件。下面的respository元素來自于Apache Struts項目，并且它指向到位于有效的子版本資源庫http: //svn.apache.org/repos/asf/struts/core/trunk：

<repository>
<connection>
scm:svn:http://svn.apache.org/repos/asf/struts/core/trunk
</connection>
<developerConnection>
scm:svn:https://svn.apache.org/repos/asf/struts/core/trunk
</developerConnection>
<url>http://svn.apache.org/repos/asf/struts/core/trunk</url>
</repository>

connection 元素告訴Maven有關SCM只讀的位置。scm標識該URL起始于SCM位置，svn告訴Maven該URL將是資源庫的子項目，并且最終的片斷定位于 項目的trunk。你可能也指定了developerConnection，你使用該元素在你需要分隔觀眾人群的不可寫訪問和一般人群的可寫訪問源代碼。 url元素提供了能夠被瀏覽的資源庫的URL。在Struts的案例中，他們選擇了指向資源庫到它自己，它能夠被一個正常的瀏覽器所瀏覽。Struts團 隊也可以指向到ViewCVS實例配置指向到ASF的資源庫的子版本，它能夠在http: //cvs.apache.org/viewcvs.cgi/struts/core/trunk/?root=Apache-SVN的位置找到。

當你在一個詳細的資源控制系統指定了project.xml，你也可以指向到一個詳細項目的不同版本和分之。下面的XML展示了簡化版的Apache Struts項目的version和branche元素。

<versions>
<version>
<id>1.2.0</id>
<name>1.2.0</name>
<tag>STRUTS_1_2_0</tag>
</version>
<version>
<id>1.2.6</id>
<name>1.2.6</name>
<tag>STRUTS_1_2_6</tag>
</version>
</versions>
<branches>
<branch>
<tag>STRUTS_1_1_BRANCH</tag>
</branch>
<branch>
<tag>STRUTS_1_2_BRANCH</tag>
</branch>
</branches>

Version被用于幾個插件，如Announcements插件，其用于為每個版本創建發布紀錄。

關于...
... CVS？
如果你的項目使用CVS，在Jakatta Catus項目中你將需要添加一個如repository元素的資源庫元素如下所示：

<repository>
<connection>
scm:cvs:pserver:anoncvs@cvs.apache.org:/home/cvspublic:jakarta-cactus
</connection>
<url>http://cvs.apache.org/viewcvs.cgi/jakarta-cactus/</url>
</repository>

在使用CVS paserver如果你暴露你的資源庫上面的引用是合適的。如果你在SSH之上訪問CVS，你就需要按照下面的語法設置你的CVS_RSH環境變量。

<repository>
<connection>
scm:cvs:pserver:anoncvs@cvs.apache.org:/home/cvspublic:jakarta-cactus
</connection>
<url>http://cvs.apache.org/viewcvs.cgi/jakarta-cactus/</url>
<developerConnection>
scm:cvs:ext:tobrien@somehost:/home/cvs/repository:modulename
</developerConnection>
</repository>

創建項目Web站點
Maven能夠創建項目web頁，包含項目的有關信息。


我該如何做？
創建一個Maven項目web站點，使用Site插件運行下面的Maven目標：
C:\dev\mavenbook\code\genapp\test-application> maven site
運 行Site插件將在test-application/target/docs/index.html目錄創建默認的項目站點。如果你加載這個HTML， 你將發現這個站點與眾不同的Maven感觀。圖1-5展示了一個輕量的定制web站點，包含定制的組織logo和項目logo。作為替換向你展示了人工的 web站點，你能夠看出這個站點的項目當前正使用Maven的構建系統-Jaxen。


圖1-5.簡單的Maven項目站點。

許 多Maven站點有一個項目導航部分用于提供鏈接系統向所有的Maven項目。項目信息包含項目的有關信息，項目的郵件列表，項目的資源控制及問題跟蹤 （你將在第4章找到所有的這些）。通過在xdocs目錄里創建和修改XML標記生成Maven web站點的目錄。在圖5，項目包含5個項目細節文檔：Overview,FAQ,Releases,CVS Access和Status。這些文檔因為被包括在xdocs/navigation.xml文件中所以他們被包含在左邊的導航欄。xdocs目錄是 Maven存放XML XDoc格式的項目細節文檔的地方。下面是Jaxen的navigation.xml文檔的內容：

<?xml version="1.0" encoding="ISO-8859-1"?>
<project name="jaxen" repository="jaxen" >
<title>jaxen: universal java xpath engine</title>
<body>
<links>
<item name="The Werken Company" />
</links>
<menu name="jaxen">
<item name="Overview" href="/index.html"/>
<item name="FAQ" href="/faq.html"/>
<item name="Releases" href="/releases.html"/>
<item name="CVS Access" href="/cvs-usage.html"/>
<item name="Status" href="/status.html"/>
</menu>
</body>
</project>

link 元素放置一個鏈接http://www.werken.com到頁面的右手邊，項目的logo之下，menu元素包含了用以顯示的左右邊的導航區域。菜單 中的一個文件是xdocs/index.xml。下面是Jaxen的xdocs/index.xml文件的簡短目錄：

<?xml version="1.0"?>
<document url="http://jaxen.org/index.xml">
<properties>
<author email="bob@eng.werken.com">bob mcwhirter</author>
<title>jaxen</title>
</properties>
<body>
<section name="News">
<p>
Added the slidedeck from my
<a href="/pdf/intro-slides.pdf">SD-West presentation</a>.
</p>
<p>
Check out these
<a >Performance
Benchmarks</a> comparing dom4j and Jaxen against Xerces and Xalan.
</p>
</section>
[...]
</document>

一旦你生成了你的項目站點，加載target/docs/index.html到一個瀏覽器來查看你項目的web站點。

關于...
... 這些文件的語法？
你 能在Maven XDoc插件的FAQ（http://maven.apache.org/reference/plugins/xdoc/faq.html）找到 navigation.xml文件的更多相關語法和格式信息。并且你也能在Maven XDoc Plug-in page（http://maven.apache.org/reference/plugins/xdoc/index.html）上找到更多有關 individual pages格式的信息。這個插件也面也包含更多定制站點生成插件的輸出和行為的說明。
看第4章有關多樣化報告的更深的分析，這樣你句能夠把項目活動和結構搞清楚了。


定制站點報告
站點生成創建了許多有用的報告，但依照你的風格，你可能想取出其中的某些報告。


我該如何做？
修改project.xml中的reports元素內容來改變Maven站點生成對報告的生成。下面是reports元素中的幾個有效的報告活動：

<reports>
<report>maven-changelog-plugin</report>
<report>maven-changes-plugin</report>
<report>maven-checkstyle-plugin</report>
<report>maven-clover-plugin</report>
<report>maven-cruisecontrol-plugin</report>
<report>maven-developer-activity-plugin</report>
<report>maven-faq-plugin</report>
<report>maven-file-activity-plugin</report>
<report>maven-license-plugin</report>
<report>maven-linkcheck-plugin</report>
Customizing Site Reports 37
<report>maven-javadoc-plugin</report>
<report>maven-jdepend-plugin</report>
<report>maven-jira-plugin</report>
<report>maven-junit-report-plugin</report>
<report>maven-jxr-plugin</report>
<report>maven-pmd-plugin</report>
<report>maven-simian-plugin</report>
<report>maven-tasklist-plugin</report>
</reports>

從Maven 的站點生成中排除一個報告，僅需要移除reports元素中的report的插件元素。Maven項目并未指定reports元素生成一套默認的報告： jdepend，Checkstyle，changes，changelog，developer-activity，file-activity， license，javadoc，jxr，junit，linkcheck和tacklist。當你添加一個reports元素到你項目的 project.xml文件，你必須列出所有你希望獲得的報告。

剛剛發生了什么？
reports元素列出了所有這些多樣的reports，但你可能想了解報告提供的全部這些。表1-1提供了報告的一些摘要描述。


更多全面的插件和報告列表，參見：
Maven插件: http://maven.apache.org/reference/plugins/index.html
Maven插件沙箱: http://maven.apache.org/plugins-sandbox/index.html
Maven 在SourceForge上的插件: http://maven-plugins.sourceforge.net/
第三方Maven插件: http://maven.apache.org/reference/3rdparty.html

add <class-loader delegate="true"/> to web.xml