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

     摘要:   閱讀全文

     摘要:   閱讀全文

     摘要:   閱讀全文

     摘要:   閱讀全文

     摘要:   閱讀全文

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

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

? 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，選擇數(shù)據(jù)庫，XML Database，Configuration。更改XDB的有關(guān)設(shè)置。

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

首先感謝TerryLee，配置完P(guān)rofileScriptService后，發(fā)現(xiàn)異常

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

google后，找到了解決方法。

1.在system.web節(jié)點(diǎn)加入<anonymousIdentification enabled="true"/>

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

?

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

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

這位前輩和我想到一塊兒去了。
解決步驟：
1.在解決方案資源管理器中，打開項(xiàng)目屬性。
2.在應(yīng)用程序啟動(dòng)對(duì)象中選擇要bulid的那個(gè)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.

     摘要: 轉(zhuǎn)自小小冰 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

導(dǎo)言

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

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

?

利用 Spring IoC 配置 EHCache

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

?

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

?

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

?

<!-- ======================?? 緩存?? ======================= --> <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>

?

構(gòu)建我們的 MethodCacheInterceptor

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

?

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; ? /** ?? * 設(shè)置緩存名 ?? */ ? public void setCache(Cache cache) { ??? this.cache = cache; ? } ? /** ?? * 檢查是否提供必要參數(shù)。 ?? */ ? public void afterPropertiesSet() throws Exception { ??? Assert.notNull(cache, "A cache is required. Use setCache(Cache) to provide one."); ? } ? /** ?? * 主方法 ?? * 如果某方法可被緩存就緩存其結(jié)果 ?? * 方法結(jié)果必須是可序列化的(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 代碼說明了：

• 默認(rèn)條件下，所有方法返回結(jié)果都被緩存了（ methodNames 是 null ）
• 緩存區(qū)利用 IoC 形成
• cacheKey 的生成還包括方法參數(shù)的因素（譯注：參數(shù)的改變會(huì)影響 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 開發(fā)指南》，其中他這樣描述 EHCache 配置文件的：

?

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

     摘要: 一、緒言
JDK1.5對(duì)JAVA語言進(jìn)行了做了幾個(gè)擴(kuò)展，其中一個(gè)就是泛型。
本指南旨在介紹泛型。如果你熟悉其它語言的構(gòu)造類似的東西，特別是C++的模
板（template），你會(huì)很快發(fā)現(xiàn)它們之間的相同點(diǎn)及重要的不同點(diǎn)；如果你在其他
地方?jīng)]看到過類似的東西，那反而更好，那樣你就可以開始全新的學(xué)習(xí)，用不著去忘
掉那些（對(duì)JAVA泛型）容易產(chǎn)生誤解的東西。
泛型允許你對(duì)類型進(jìn)行抽象。最常見的例子是容器類型，比如那些在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

壓縮包文件結(jié)構(gòu)：
|-tem
?????? |-folderA
?????????????????? |-filea
????????????????? ?|-fileb
?????????????????? |-filec
?????? |-filed
解壓后文件結(jié)構(gòu)：
|-tem
?????? |-folderA
?????????????????? |-filea
????????????????? ?|-fileb
?????????????????? |-filec
?????? |-filed

摘自http://www.matrix.org.cn/resource/article/43/43661_Maven.html
版權(quán)聲明：可以任意轉(zhuǎn)載，轉(zhuǎn)載時(shí)請(qǐng)務(wù)必以超鏈接形式標(biāo)明文章原始出處和作者信息及本聲明
英文原文地址:
http://www.onjava.com/pub/a/onjava/excerpt/mavenadn_ch01/index.html
中文地址:
http://www.matrix.org.cn/resource/article/43/43661_Maven.html
關(guān)鍵詞： Maven Ant Java




編者注：

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

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

Vincent Massol是Jakarta Catus framework（框架）的創(chuàng)建者。其后他花費(fèi)4年的時(shí)間在幾個(gè)大項(xiàng)目（主要是J2EE）的架構(gòu)技術(shù)上。他現(xiàn)在是Pivolis的創(chuàng)辦人和CTO,這是 一家專注于應(yīng)用敏捷方法進(jìn)行軟件開發(fā)的公司。他現(xiàn)在居住在法國的首都City of Light（巴黎）。

Timothy M. O'Brien作為一個(gè)專業(yè)的歌手/程序員現(xiàn)正在芝加哥地區(qū)工作和生活。




讓我們開始使用Maven。在本章結(jié)束時(shí)，你應(yīng)該能夠從頭建立一個(gè)Maven的項(xiàng)目，使用Maven進(jìn)行相關(guān)管理，創(chuàng)建基于某些感興趣報(bào)告的簡單的web站點(diǎn)。

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

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

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

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


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

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

在Unix平臺(tái)，下載 tar'd.zip文件（Maven-1.0.2.tar.gz）并接壓縮tar xvzf maven-1.0.2.tar.gz到你選擇的目錄。本試驗(yàn)假設(shè)你解壓Maven到/usr/local/maven-1.0.2目錄下。你此時(shí)需要設(shè) 置兩個(gè)環(huán)境變量，MAVEN_HOME和PATH。下面的命令為這兩個(gè)變量設(shè)置適當(dāng)?shù)闹担?br />[tobrien@mavenbook tobrien]$ export MAVEN_HOME=/usr/local/maven-1.0.2
[tobrien@mavenbook tobrien]$ export PATH=${PATH}:${MAVEN_HOME}/bin
如果Maven被成功安裝到你的機(jī)器，你能夠看到與Windows系統(tǒng)同樣的輸出。恭喜！你已經(jīng)成安裝了Maven。

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

剛剛發(fā)生了什么？
你剛剛安裝了Maven1.0.2并且配置了一些環(huán)境變量。是的！一旦你對(duì)MAVEN_HOME進(jìn)行了有效的設(shè)置或是maven.bat或maven.sh已經(jīng)存在，你已經(jīng)能夠完成Developer's Notebook本次的實(shí)驗(yàn)。

關(guān)于....
??????????..Maven 2?
是 時(shí)機(jī)提及Maven 2（有時(shí)也被稱為“m2”）。Maven 2完成了對(duì)Maven 1的重寫。重寫的首要目的是要提供了強(qiáng)大的Jave構(gòu)建和包含API的項(xiàng)目，允許Maven被植入任何地方，尤其是高級(jí)別的產(chǎn)品如IDEs、質(zhì)量工具、報(bào) 告工具等這些。Maven 2構(gòu)建生命周期的概念正式話，其比Maven更易擴(kuò)展。

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

開始一個(gè)新的項(xiàng)目
創(chuàng)建新項(xiàng)目的爭論一部分在于有很大部分的工作努力被用到在“發(fā)展基礎(chǔ)設(shè)施”上—自動(dòng)構(gòu)建、單元測試、文檔、項(xiàng)目報(bào)告等。使用Maven你可以加速這個(gè)過程，生成項(xiàng)目的框架使其作為新應(yīng)用的種子。


我該如何做？
Maven 擁有一個(gè)應(yīng)用程序生成插件（Genapp）你能通過其創(chuàng)建一個(gè)新項(xiàng)目。首先創(chuàng)建一個(gè)空的目錄c:\dev\mavenbook\code\genapp\ test-application這將成為應(yīng)用程序生成后的處所。通過執(zhí)行g(shù)enapp這個(gè)目標(biāo)來運(yùn)行Genapp插件，選擇默認(rèn)的模版并且提供一些你的 新項(xiàng)目的相關(guān)信息。
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

本 插件會(huì)要求用戶一些輸入，從這個(gè)輸出內(nèi)容你可以看到你使用了默認(rèn)的（defalut）應(yīng)用程序模板，并且你提供了新項(xiàng)目的應(yīng)用程序ID、name，和包 名。默認(rèn)的（default）應(yīng)用程序模板創(chuàng)建了一個(gè)單獨(dú)的類，mdn.testapp.app，和一個(gè)靜態(tài)main函數(shù)和兩個(gè)JUnit測試。

Maven的應(yīng)用程序生成插件生成了下面的目錄和文件：

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項(xiàng)目有一個(gè)參考了項(xiàng)目對(duì)象模型（POM）的標(biāo)準(zhǔn)目錄結(jié)構(gòu), （as described shortly）。如果你有一些現(xiàn)存的類你想添加到一個(gè)項(xiàng)目，添加它們到src/java，如果你有一些單元測試將它們添加到src/test。如果這些 已有的類和單元測試依賴一些外部的苦，你將在隨后的章節(jié)看到如何添加一個(gè)附屬。xdos目錄包含了格式為XDoc的項(xiàng)目文檔。

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

project.xml是項(xiàng)目的描述符；它是一個(gè)內(nèi)容為POM的XML文件。讓我們看看這個(gè)project.xml的拷貝，其已經(jīng)定義了這個(gè)項(xiàng)目：

<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有關(guān)你項(xiàng)目的全部。build元素定位應(yīng)用程序原碼，單元測試和資源文件包的位置。name, artifactId, currentVersion, inceptionYear, description。
shortDescription標(biāo)識(shí)該項(xiàng)目并且提供了該項(xiàng)目的信息被用作完成品的名字來創(chuàng)建項(xiàng)目。

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

resources 元素被用于JAR插件拷貝資源到JAR生成物。在該元素你指定一批資源到資源庫。本例中，自src/conf的資源將被復(fù)制到classpath的根目 錄。換言之，app.properties資源將被復(fù)制到所生成的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及其插件在本項(xiàng)目中的行為。你將在看過本書之后使用該文件定制所生成web站點(diǎn)的品質(zhì)和JAR文件的內(nèi)容。

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

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


在代理服務(wù)器下使用Maven
Maven依賴于Internet連接，其通過HTTP下載相關(guān)的插件。如果你工作在公共環(huán)境，你可能需要配置Maven來與工作代理服務(wù)器系統(tǒng)。


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

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

編譯和測試一個(gè)項(xiàng)目
你擁有了一個(gè)包含一個(gè)類文件和單元測試文件的項(xiàng)目。下
面，讓我們夠見這個(gè)項(xiàng)目和運(yùn)行應(yīng)用程序類吧。

我該如果做？
通過執(zhí)行jar:jar goal來創(chuàng)建一個(gè)包含應(yīng)用程序的類的jar
文 件。JAR插件定義了一個(gè)速記目標(biāo)命名為jar其依賴之前的jar:jar goal。執(zhí)行任何一個(gè)目標(biāo)將得到相同的結(jié)果。所有的插件都定義了一條這樣的捷徑；例如，測試目標(biāo)執(zhí)行的是Test插件里的test:test goal。執(zhí)行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創(chuàng)建一個(gè)target（目標(biāo)）目錄來保存中間文件和JAR文件。在JAR首次被建立后，按照下面執(zhí)行App類。

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

如果你想重復(fù)此項(xiàng)工作，運(yùn)行maven clean來移除target目錄重新構(gòu)建。

剛剛發(fā)生了什么？
當(dāng) 你運(yùn)行jar目標(biāo)時(shí)，Maven使用JAR插件來創(chuàng)建了一個(gè)JAR生成物。首先，Maven找到一系列的目標(biāo)以便能夠創(chuàng)建這個(gè)應(yīng)用程序的JAR文件； JAR插件有一個(gè)其它目標(biāo)所依賴于目標(biāo)的jar:jar goal，反過來，它也依賴于其他的目標(biāo)。Maven找出下列需要的目標(biāo)來執(zhí)行：java:prepare-filesystem，java: compile，java:jarresources，
test:prepare-filesystem，test:test-resources，test:compile，and test:test。

Maven查看其需要執(zhí)行目標(biāo)中的Test插件來執(zhí)行單元測試，并且檢查本地Maven庫中的JUnit JAR文件。因?yàn)槟氵€沒有使用過Maven，所以它將從位于http://www.ibiblio.org/
maven/的Maven默認(rèn)庫中下載junit-3.8.1.jar。你將在本章后學(xué)習(xí)到有關(guān)Maven本地庫和Maven強(qiáng)大的相關(guān)管理能力的內(nèi)容。


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


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

如果你看了上次練習(xí)所生成的project.xml文件，你將注意到許多元素都在上次討論中被忽略。下面的XML列出了POM中頂級(jí)的元素，（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。本章的式樣將提供這些細(xì)節(jié)，但你應(yīng)該使用上面XML的摘錄來以適當(dāng)?shù)捻樞蚍胖眠@些元素到你的project.xml中。

列出有效的Goals
當(dāng)你使用Maven時(shí)，你將執(zhí)行目標(biāo)。Maven插件是一組相關(guān)的插件。例如，要為一個(gè)項(xiàng)目創(chuàng)建JAR文件，你將如下所示執(zhí)行JAR插件中的jar:jar goal。
C:\dev\mavenbook\code\genapp> maven jar:jar
冒號(hào)之前的jar分類這個(gè)目標(biāo)屬于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.

如果你需要查看每個(gè)有效的插件和目標(biāo)，輸入下面內(nèi)容：
C:\dev\mavenbook\code\genapp\test-application> maven -g | more
全部的插件可能使人有些畏懼，Maven有關(guān)于一切的插件，從生成項(xiàng)目文件到IDEs到生成WAR文件以及開始和停止應(yīng)用服務(wù)器。你將在下面的實(shí)驗(yàn)中學(xué)習(xí)到一些更有用的插件。

生成調(diào)試信息
現(xiàn) 在，你可能已經(jīng)注意到Maven執(zhí)行了許多繁重的工作。如果你使用Ant，你可能已經(jīng)開始編寫Ant的build.xml文件并且添加編譯.jar任務(wù)和 單元測試。Maven隱藏了許多復(fù)雜性，但當(dāng)調(diào)試問題時(shí)，它也能夠查看“幕后”。這個(gè)能力運(yùn)行于Maven的調(diào)試模式并且這個(gè)工具打印輸出每個(gè)構(gòu)建的細(xì)節(jié) 重要的是你可以根據(jù)需要來驗(yàn)證構(gòu)建是否正確執(zhí)行。


我該如何做？
本次實(shí)驗(yàn)，參考上一個(gè)測試應(yīng)用程序。當(dāng)你運(yùn)行maven test，你將收到如下信息：

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

在執(zhí)行java:comile或java:jar-resources目標(biāo)時(shí)到底發(fā)生了什么？執(zhí)行構(gòu)建項(xiàng)目中運(yùn)行maven -x test將顯示全部目標(biāo)的調(diào)試信息。讓我們來是一下，把注意力放在最早的第三個(gè)目標(biāo)上。運(yùn)行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的打印輸出任務(wù)可能看起來很熟悉。它是Ant的echo和javac任務(wù)的輸出。Maven常常使用Ant的進(jìn)程來執(zhí)行常用操作如：拷貝、刪除、編譯和創(chuàng)建JAR文件。

剛剛發(fā)生了什么？
這兩個(gè)目標(biāo)執(zhí)行的都是非常簡單的調(diào)試輸出。java:compile目標(biāo)簡單的掃描源目錄中java源碼中較新的相關(guān)類文件。java:jar-resources目標(biāo)尋找資源中包含的JAR文件。更復(fù)雜的如test:test將產(chǎn)生有關(guān)虛擬機(jī)和類加載器的調(diào)試信息。

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

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


我該如何做？
首先，你需要根據(jù)需要定位Maven默認(rèn)中心源碼庫中的 JAR文件。ibiblio.org在http://www.ibiblio.org/maven/提供了這些。在Web瀏覽器中加載這個(gè)URL你將看到 一系列的目錄；我們關(guān)心的是springframework的目錄，springframework下子目錄的結(jié)構(gòu)如下所示：
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三個(gè)元素。你能夠添加兩個(gè)依賴關(guān)系的完成品以替代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>

現(xiàn)在，運(yùn)行jar目標(biāo)并且看看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目標(biāo)觸發(fā)的一系列事件：
1.Maven查看POM,依據(jù)project.xml的定義，看到在springframework組中的兩個(gè)人造物的依賴關(guān)系。它將載你本地Maven的資源庫中檢查spring-core-1.1.4.jar和spring-web-1.1.4.jar。
2. 當(dāng)Maven找不到這些文件，它將到http://www.ibiblio.org/maven/springframework/jars/尋找JAR 文件。這些JAR文件會(huì)被下載并放置于你本地Maven的資源庫中。它們也被添加到你項(xiàng)目的classpath中。下次在你的項(xiàng)目查詢這些文件時(shí)， Maven將在你本地的資源庫中提供它們。


圖1-1.Maven本地和遠(yuǎn)程資源庫為test application項(xiàng)目提供的spring Jar。

剛剛發(fā)生了什么？
Maven 為你節(jié)省了相當(dāng)?shù)臅r(shí)間和不必要的麻煩。Maven到來之前，依賴關(guān)系常常被捆綁到一個(gè)項(xiàng)目的目錄或者項(xiàng)目應(yīng)該指向到添加正確的JAR到你的 classpath。使用Maven管理依賴關(guān)系顯然有著明顯的優(yōu)勢(shì)；作為初學(xué)者，如果你的項(xiàng)目依賴30個(gè)外部的JAR文件，這就不需要在你的資源庫中存 儲(chǔ)成兆的JAR文件。這意味著當(dāng)你在項(xiàng)目的外部檢查資源控制的時(shí)候更少的存儲(chǔ)空間和更快的下載時(shí)間。另外，如果你有多個(gè)項(xiàng)目依賴相同的外部依賴， Maven僅需要下載一次依賴關(guān)系，并且每個(gè)項(xiàng)目引用一個(gè)單獨(dú)的副本在你本地的資源庫中。當(dāng)依賴關(guān)系能夠從Maven資源庫遠(yuǎn)程下載的時(shí)候，沒有強(qiáng)制的原 因讓你存儲(chǔ)你項(xiàng)目的依賴關(guān)系的版本。

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


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

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

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

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

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

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

關(guān)于...
...使用id元素?

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

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

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

使用id元素工作，單獨(dú)的id標(biāo)記已經(jīng)不被贊成使用并在Maven 2中消失。當(dāng)你看到別的Maven項(xiàng)目中使用dependencies的速記符號(hào)時(shí)，請(qǐng)嘗試使用groupId和artifactId來標(biāo)識(shí)你的依賴關(guān)系。

依賴快照
如果你開發(fā)的程序依賴的依賴關(guān)系經(jīng)常改變，你可能想將依賴的每個(gè)依賴關(guān)系替代為最近構(gòu)件的硬編碼的版本。在一個(gè)項(xiàng)目依賴的依賴關(guān)系還處在beta的版本，或你正開發(fā)一系列項(xiàng)目依賴的Maven項(xiàng)目時(shí)時(shí)特別有用，這將在第3章論述。本實(shí)驗(yàn)，你將學(xué)習(xí)到如何依靠快照。


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

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

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

執(zhí)行脫機(jī)構(gòu)建
如果你需要在一個(gè)離線的情況下使用Maven，你可能需要知道如何確使Maven不檢查最新的SNAPSHOT依賴關(guān)系。本實(shí)驗(yàn)將向你展示如何用Maven執(zhí)行脫機(jī)構(gòu)建。


我該如何做？
這 個(gè)方法很簡單：僅僅使用-o命令行選項(xiàng)。例如，如果你沒有網(wǎng)絡(luò)連接，但又想執(zhí)行測試目標(biāo)，運(yùn)行Maven -o test。Maven將執(zhí)行這個(gè)test目標(biāo)而不檢查依賴關(guān)系。如果你的項(xiàng)目沒有依賴SNAPSHOT構(gòu)建，你也可以斷看你的環(huán)境來添加-o標(biāo)志。如果你 依賴SNAPSHOT構(gòu)建，你將需要使用-o標(biāo)志，Maven將在每次執(zhí)行目標(biāo)時(shí)嘗試檢查最新的SNAPSHOT。在這種情況下不使用-o標(biāo)志本項(xiàng)目將不 會(huì)構(gòu)建成功。


關(guān)于...
... 執(zhí)行離線構(gòu)建如果你不想下載任何完成品？
當(dāng)然，這將不會(huì)工作。離線構(gòu)建的工作，你必須已經(jīng)有必需的依賴關(guān)系在你本地的資源庫。項(xiàng)目最簡單的獲得Maven下載依賴
關(guān)系的方法是在每個(gè)Maven項(xiàng)目實(shí)例簡單的運(yùn)行“noop”目標(biāo)，build:start。這個(gè)目標(biāo)執(zhí)行之前任何其它的目標(biāo)并不執(zhí)行任何動(dòng)作。如果你運(yùn)行build:start，Maven將從project.xml獲得獲取任何依賴關(guān)系。


使用Maven控制臺(tái)
如 果你再三的從命令行運(yùn)行Maven，你可以通過Maven控制臺(tái)來節(jié)省時(shí)間。Maven控制臺(tái)提供一個(gè)“外殼”，在這你可以鍵入目標(biāo)的名稱來執(zhí)行 Maven。通過使用Maven可以避免每次載你想運(yùn)行一個(gè)Maven目標(biāo)時(shí)Java Virtual Machine（JVM）啟動(dòng)的等待。


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

__ __
| \/ |__ _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 >

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

剛剛發(fā)生了什么？
在Maven Console下Maven執(zhí)行java:compile目標(biāo)非常之快，不信么？當(dāng)你使用Maven Console時(shí)你所執(zhí)行的目標(biāo)是在一個(gè)現(xiàn)成的JVM下。當(dāng)你從命令行運(yùn)行Maven時(shí)，你每次運(yùn)行一個(gè)目標(biāo)都不得不等待JVM的啟動(dòng)。如果你不確信其對(duì) 性能的提升，自己試試看。在命令行下運(yùn)行java:complie 10次，再在Maven Console下同樣運(yùn)行java:compile 10次。注意時(shí)間的差別，你將發(fā)現(xiàn)JVM啟動(dòng)的時(shí)間開始增加。如果你找到你自己常用的Maven目標(biāo)，Maven Console將通過啟動(dòng)JVM一次為來節(jié)省時(shí)間。


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


我該如何做？
這個(gè)過程很簡單；僅僅執(zhí)行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創(chuàng)建兩個(gè)文件以識(shí)別Eclipse的項(xiàng)目：.project和.classpath。在Eclipse中，你就可以通過下面的步驟導(dǎo)入這個(gè)工程了：
1.啟動(dòng)Eclipse。
2.從菜單欄選擇File→Import...&#61472;
3.選擇現(xiàn)存項(xiàng)目放入Workspace并單擊Next按鈕。
4.在Import對(duì)話框選擇C:\dev\mavenbook\code\genapp\test-application目錄，并單擊Finish按鈕。

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

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

關(guān)于...
... JBuilder, JDeveloper, and IntelliJ IDEA？
所有這些IDE有著Eclipse一樣簡單的插件。為JBuilder 項(xiàng)目生成必需的文件，運(yùn)行mave jbuilder，對(duì)于JDeveloper運(yùn)行mave jdeveloper，為IntelliJ IDEA項(xiàng)目運(yùn)行mave idea。


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


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

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



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

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


圖1-4.Mevenide Repository Browser view

如果你想搜索資源庫中完成品的細(xì)節(jié)，Mevenide同樣提供了資源庫搜索功能。這將是得心應(yīng)手的因?yàn)闉榱四硞€(gè)依賴關(guān)系的細(xì)節(jié)搜索http://www.ibiblio.org/maven是非常惱人的。檢查Mevenide；它將為你節(jié)省時(shí)間。

關(guān)于...
... NetBeans和JBuilder？
Mevenide當(dāng)前的版本支持這兩個(gè)IDE的表現(xiàn)。更多詳情參見http://mevenide.codehaus.org/。
... IntelliJ？
IDEA插件維持了一些目標(biāo)如同你在Eclipse中使用的目標(biāo)。更多詳情參見位于http://maven.apache.org/reference/plugins/idea/goals.html的IDEA插件的聯(lián)機(jī)文檔。


生成Ant構(gòu)建文件
當(dāng) 你想用Apache的Ant構(gòu)建的某些時(shí)候。可能你的項(xiàng)目使用自動(dòng)化處理正依賴于Ant，又可能你有一些團(tuán)隊(duì)成員沒有完成到Maven的轉(zhuǎn)換并且他們希望 繼續(xù)使用Ant。目前為止許多IDE提供通過Ant構(gòu)建項(xiàng)目文件，你能夠使用Maven生成build.xml文件這樣你的項(xiàng)目就能夠被Apache的 Ant所構(gòu)建。


我該如何做？
運(yùn)行Ant插件。運(yùn)行maven ant將創(chuàng)建build.xml文件其包含到聚合的依賴關(guān)系的目標(biāo)，build和test你的應(yīng)用程序。看看運(yùn)行默認(rèn)的jar目標(biāo)的輸出：

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

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

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


移植一個(gè)Ant項(xiàng)目到Maven
一定數(shù)量的項(xiàng)目使用Ant作為構(gòu)建系統(tǒng)，你可能打算移植到Maven上來。


我該如何做？
從 頭開始。創(chuàng)建一個(gè)默認(rèn)的Maven模版，并且移動(dòng)你的代碼到適當(dāng)?shù)奈恢谩２灰O(shè)法使Maven適合你項(xiàng)目的目錄和構(gòu)建位置。Maven強(qiáng)過一個(gè)構(gòu)建工具； 它是一個(gè)標(biāo)準(zhǔn)方式考慮到項(xiàng)目的布局和管理。如果你試圖使Maven適應(yīng)你項(xiàng)目的想法來構(gòu)建，你將結(jié)束使用Maven。如果你的項(xiàng)目由一個(gè)復(fù)雜的 buil.xml文件組成其產(chǎn)生許多不同的交付結(jié)果，你將需要“組件化”你的項(xiàng)目請(qǐng)跟隨第3章的多項(xiàng)目描述。你可能要開始移動(dòng)你項(xiàng)目的目錄結(jié)構(gòu)轉(zhuǎn)向標(biāo)準(zhǔn)的 Maven項(xiàng)目目錄結(jié)構(gòu)。換而言之，不要試圖生搬硬套你的項(xiàng)目到Maven。
如果你對(duì)遷移到Ant感興趣，但你沒有時(shí)間停止開發(fā)，你可以使用 Maven調(diào)用你現(xiàn)存的Ant目標(biāo)。如果你這么做，你將錯(cuò)失使用Maven的大部分益處，但僅僅是可能。更多信息參見位于http: //maven.apache.org/using/migrating.html的“Migrating from Ant”。

關(guān)于...
... 靈活性和選擇？
靈 活性和選擇是個(gè)比較老的問題了。我們保證Maven將改變你構(gòu)建和維護(hù)項(xiàng)目的方式方法，重要的是應(yīng)該有意的使用Maven。Ant和Maven間的差別是 什么呢？Ant提供塊構(gòu)建的可重用任務(wù)如copy,move,delete和junit，Maven提供了可重用的任務(wù)構(gòu)建。Maven是一個(gè)“構(gòu)建容 器”，其允許你在一系列項(xiàng)目上重用任務(wù)構(gòu)建。以單元測試為例，使用Ant，你將通過在你項(xiàng)目的build.xml文件里包含下面來執(zhí)行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>

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

利用Maven的Test插件為所有項(xiàng)目定義通用邏輯其需要編譯和執(zhí)行單 元測試。單元測試插件為編譯和執(zhí)行單元測試獲得了最好的實(shí)踐，并且它為所有項(xiàng)目達(dá)成了最有效的實(shí)踐。當(dāng)你運(yùn)行maven test，Maven從POM傳遞信息到Test插件，Test插件則依賴于Java插件來執(zhí)行編譯。在Maven中沒有一處你明確的告訴構(gòu)建容器如何執(zhí) 行JUnit單元測試。如果你這么做了，在Ant中你將會(huì)面對(duì)同樣的問題。正如你不用告訴你的Servlet容器如何解壓WAR文件一樣，你不用告訴 Maven如何構(gòu)建你的項(xiàng)目。Maven是一個(gè)構(gòu)建容器。許多人最初被Maven吸引是因?yàn)樗峁┝艘蕾囮P(guān)系管理，但Maven最大的好處是它提供了標(biāo)準(zhǔn) 的開發(fā)結(jié)構(gòu)來訪問多個(gè)項(xiàng)目。依賴關(guān)系管理僅僅是標(biāo)準(zhǔn)開發(fā)結(jié)構(gòu)的一個(gè)簡單的副產(chǎn)品。

提示
Maven提供了開發(fā)結(jié)構(gòu)，統(tǒng)一了項(xiàng)目布局，在最后你可
以嘗試讓Maven照管許多構(gòu)建任務(wù)的細(xì)節(jié)。與其花費(fèi)你
重要的時(shí)間來寫構(gòu)建腳本，不如使用Maven插件來把焦
點(diǎn)放到編寫你應(yīng)用程序上來。

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

生成項(xiàng)目文檔
如果你正開發(fā)Java應(yīng)用程序或者庫，你可能想生成JavaDoc。

我該如何做？
簡單的執(zhí)行javadoc目標(biāo)，Maven將生成項(xiàng)目的文檔。下面是執(zhí)行javadoc目標(biāo)的輸出：

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.

剛剛發(fā)生了什么？
再 次，Maven作了全部繁重的工作。你想要JaveDoc，你告訴Maven生成JaveDoc，故事結(jié)束。注意你不用告訴Maven任何你項(xiàng)目的情況； 它“知道”如何做，Maven這很多這樣的事都是直截了當(dāng)?shù)模辉谀愀嬖VMaven有關(guān)你的項(xiàng)目后你就不用做什么了。Maven操作細(xì)節(jié)。



介紹Maven給你的團(tuán)隊(duì)
Maven是一個(gè)偉大的協(xié)作工具，你能夠使用它生成開發(fā)者活動(dòng)報(bào)告，項(xiàng)目捐贈(zèng)者和郵件列表。


我該如何做？
許 多項(xiàng)目有一個(gè)郵件列表其被用于討論架構(gòu)和實(shí)現(xiàn)。并且，通過透視圖，如Tomcat，Maven和Ant等項(xiàng)目，并不僅僅是一個(gè)開發(fā)者社區(qū)來共享捐贈(zèng)到同樣 的郵件列表。郵件列表不僅用于開源項(xiàng)目；許多組織開始使用同樣的協(xié)作模型用于開啟，發(fā)布開發(fā)。因?yàn)猷]件列表是協(xié)作的關(guān)鍵部分，Maven提供了在一個(gè)項(xiàng)目 的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>

有 兩種類型的團(tuán)隊(duì)成員位于Maven項(xiàng)目中：捐贈(zèng)者和開發(fā)者。這種定義可能改變你的項(xiàng)目，捐贈(zèng)者通常被認(rèn)為是開源社區(qū)中捐贈(zèng)過補(bǔ)丁或文檔者，開發(fā)者是一個(gè)項(xiàng) 目的核心成員。在ASF，提交者和捐獻(xiàn)者可以一同捐獻(xiàn)一個(gè)項(xiàng)目，但捐獻(xiàn)者既不寫資源庫代碼又不提交大的項(xiàng)目決定。下面引用了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>

剛剛發(fā)生了什么？
你告訴Maven誰在這個(gè)項(xiàng)目工作，對(duì)于今后你生成項(xiàng)目的web站點(diǎn)很有用。開發(fā)者和捐贈(zèng)者的信息在POM中以列表的通過站點(diǎn)生成插件，很多插件為資源控制生成報(bào)告。跟資源控制對(duì)話...。


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


我該如何做？
你 需要添加一個(gè)respository元素到你項(xiàng)目的project.xml文件。下面的respository元素來自于Apache Struts項(xiàng)目，并且它指向到位于有效的子版本資源庫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有關(guān)SCM只讀的位置。scm標(biāo)識(shí)該URL起始于SCM位置，svn告訴Maven該URL將是資源庫的子項(xiàng)目，并且最終的片斷定位于 項(xiàng)目的trunk。你可能也指定了developerConnection，你使用該元素在你需要分隔觀眾人群的不可寫訪問和一般人群的可寫訪問源代碼。 url元素提供了能夠被瀏覽的資源庫的URL。在Struts的案例中，他們選擇了指向資源庫到它自己，它能夠被一個(gè)正常的瀏覽器所瀏覽。Struts團(tuán) 隊(duì)也可以指向到ViewCVS實(shí)例配置指向到ASF的資源庫的子版本，它能夠在http: //cvs.apache.org/viewcvs.cgi/struts/core/trunk/?root=Apache-SVN的位置找到。

當(dāng)你在一個(gè)詳細(xì)的資源控制系統(tǒng)指定了project.xml，你也可以指向到一個(gè)詳細(xì)項(xiàng)目的不同版本和分之。下面的XML展示了簡化版的Apache Struts項(xiàng)目的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被用于幾個(gè)插件，如Announcements插件，其用于為每個(gè)版本創(chuàng)建發(fā)布紀(jì)錄。

關(guān)于...
... CVS？
如果你的項(xiàng)目使用CVS，在Jakatta Catus項(xiàng)目中你將需要添加一個(gè)如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，你就需要按照下面的語法設(shè)置你的CVS_RSH環(huán)境變量。

<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>

創(chuàng)建項(xiàng)目Web站點(diǎn)
Maven能夠創(chuàng)建項(xiàng)目web頁，包含項(xiàng)目的有關(guān)信息。


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


圖1-5.簡單的Maven項(xiàng)目站點(diǎn)。

許 多Maven站點(diǎn)有一個(gè)項(xiàng)目導(dǎo)航部分用于提供鏈接系統(tǒng)向所有的Maven項(xiàng)目。項(xiàng)目信息包含項(xiàng)目的有關(guān)信息，項(xiàng)目的郵件列表，項(xiàng)目的資源控制及問題跟蹤 （你將在第4章找到所有的這些）。通過在xdocs目錄里創(chuàng)建和修改XML標(biāo)記生成Maven web站點(diǎn)的目錄。在圖5，項(xiàng)目包含5個(gè)項(xiàng)目細(xì)節(jié)文檔：Overview,FAQ,Releases,CVS Access和Status。這些文檔因?yàn)楸话ㄔ趚docs/navigation.xml文件中所以他們被包含在左邊的導(dǎo)航欄。xdocs目錄是 Maven存放XML XDoc格式的項(xiàng)目細(xì)節(jié)文檔的地方。下面是Jaxen的navigation.xml文檔的內(nèi)容：

<?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 元素放置一個(gè)鏈接http://www.werken.com到頁面的右手邊，項(xiàng)目的logo之下，menu元素包含了用以顯示的左右邊的導(dǎo)航區(qū)域。菜單 中的一個(gè)文件是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>

一旦你生成了你的項(xiàng)目站點(diǎn)，加載target/docs/index.html到一個(gè)瀏覽器來查看你項(xiàng)目的web站點(diǎn)。

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


定制站點(diǎn)報(bào)告
站點(diǎn)生成創(chuàng)建了許多有用的報(bào)告，但依照你的風(fēng)格，你可能想取出其中的某些報(bào)告。


我該如何做？
修改project.xml中的reports元素內(nèi)容來改變Maven站點(diǎn)生成對(duì)報(bào)告的生成。下面是reports元素中的幾個(gè)有效的報(bào)告活動(dòng)：

<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 的站點(diǎn)生成中排除一個(gè)報(bào)告，僅需要移除reports元素中的report的插件元素。Maven項(xiàng)目并未指定reports元素生成一套默認(rèn)的報(bào)告： jdepend，Checkstyle，changes，changelog，developer-activity，file-activity， license，javadoc，jxr，junit，linkcheck和tacklist。當(dāng)你添加一個(gè)reports元素到你項(xiàng)目的 project.xml文件，你必須列出所有你希望獲得的報(bào)告。

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


更多全面的插件和報(bào)告列表，參見：
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