text: . introduces some basic concepts, explains how to install Virgo Web Server and the associated Eclipse™ tools, and examines a sample web application in detail, including how the application is built and tested.
  It is intended for Spring application programmers and assumes little or no understanding of OSGi™ or Virgo Web Server.
  Questions about Web Server and SpringSource Tool Suite (or this Guide) may be posted to the Web Server Community Forums ().
  Vir. Web. Web Server turns off damping of a service proxy while the proxy’s application context is being closed.
  (Spring DM has been contributed to Eclipse as the Gemini Blueprint project.)
  Web. This Guide makes no further reference to plans. See Section A.2, “Documentation” for a link to more Virgo documentation.
  PAR files (or individual bundles) are deployed into Web Server by dropping them into a “pickup” directory or using the Administration Console web application provided with Web Server. During deployment, the bundles in the PAR file are installed into OSGi, resolved together, and then started together.
  Before developing an application with Web Server, it is essential to install Web Server, an Integrated Development Environment (IDE), and a build system integrated with Eclipse. The IDE used here is the Eclipse-based SpringSource Tool Suite (STS), and the build system used here is Apache Maven.
  STS is supplied as a fully configured Eclipse IDE, with Virgo Web Server and Maven plugins built-in.
  Before proceeding, ensure that a Java™ Standard Edition Development Kit (JDK)
  for Java 6 or later is installed and that the
  JAVA_HOME environment variable
  is set to the root directory of the JDK.
  (A Java Runtime Environment (JRE) alone is not sufficient,
  a development kit is necessary to use the facilities in STS.)
  To verify this, issue the command
  "%JAVA_HOME%"\bin\java -version from
  a command prompt on Windows (or
  $JAVA_HOME/bin/java -version from a terminal window on UNIX)
  and ensure that the command completes successfully and reports
  a Java version
  1.6.x (denoting Java
  not handle long pathnames correctly.
  Although the steps are similar, the details of installing the Virgo Web Server depend on the operating system.
  Obtain Web Server from the download site (). This guide is consistent with version 2.1.0.RELEASE of Web Server.
  Unzip the download of Web Server to the root directory of
  a drive (this will avoid possible problems with long pathnames).
  Set an environment variable
  %VWS_HOME% to refer to the unzipped folder…
  prompt> cd C:\ prompt> "%JAVA_HOME%"\bin\jar xf \path\to\virgo-web-server-2.1.0.RELEASE.zip prompt> set VWS_HOME=C:\virgo-web-server-2.1.0.RELEASE
  To verify the installation, issue the command:
  "%VWS_HOME%"\bin\startup.bat.
  Unzip the download of Web Server to a suitable location on the file system, such
  as the home directory. (If the download was automatically unzipped by the operating
  system, simply move the unzipped directory to the chosen location.)
  Set an environment variable
  $VWS_HOME to refer to the unzipped folder…
  prompt$ mkdir /path/to/home/springsource prompt$ cd /path/to/home/springsource prompt$ unzip /path/to/virgo-web-server-2.1.0.RELEASE.zip prompt$ export VWS_HOME=/path/to/home/springsource/virgo-web-server-2.1.0.RELEASE
  To verify the installation, use a terminal window to issue the command:
  $VWS_HOME/bin/startup.sh.
  The SpringSource Tool Suite (STS) is a development environment based on Eclipse that is already configured with the plugins needed to work with Web Server and OSGi. Although the steps are similar, the details of installing STS depend on the operating system.
  Go to the STS download site () and download the variant appropriate to the operating system being used. This guide is consistent with STS version 2.5.0.RELEASE. Previous versions may not work properly with the latest revision of GreenPages, currently 2.3.0.RELEASE.
  It is possible to use vanilla Eclipse, and add the SpringSource Tools to it. Please refer to the installation instructions in the Virgo Programmer Guide.
  Unzip the download of STS to the root directory of a drive (this will avoid possible problems with long pathnames).
  prompt> cd C:\ prompt> "%JAVA_HOME%"\bin\jar xf \full…path…to\springsource-tool-suite-2.5.0.RELEASE-e3.6.1-win32.zip
  To verify the installation, run the
  eclipse.exe (or
  sts.exe) executable in the unzipped directory
  and check that STS displays a welcome panel.
  The first time there may be a short delay due to the initial set-up of indexes.
  Unpack the download of STS to a suitable location on the file system, such
  as
  /opt or, if root access is not available, the home directory.
  (If the download was automatically unpacked by the operating
  system, simply move the unpacked directory to the chosen location.)
  To verify the installation, run the STS executable (
  STS.app on Mac OS X)
  in the unpacked directory and check that STS displays a welcome panel.
  The first time there may be a short delay due to the initial set-up of indexes. 2.2 Web Web instructions for building the complete GreenPages application and running it in Web Server as well as running tests and executing it from the SpringSource Tool Suite. In addition, the application is examined in development stages from SpringSource Tool Suite, stepping through the development process and comparing this to the solution.-2.3.0.RELEASE.zip prompt> set GREENPAGES_HOME=c:\springsource\samples\greenpages-2.3.0.RELEASE
  To extract the files on Unix systems:
  prompt$ mkdir -p /opt/springsource/samples prompt$ cd /opt/springsource/samples prompt$ unzip /path/to/greenpages-2.3.0.RELEASE.zip prompt$ export GREENPAGES_HOME=/opt/springsource/samples/greenpages-2 in the next section).
  The
  start directory contains an initial skeleton of the GreenPages application which can be used to generate the full application.
  The examination steps refer to this skeleton by way of illustration.
  To follow the examination steps read Chapter 4, The Web Module after installing the full application in the following section.
  GreenPages uses Apache Maven as its primary build system. Each module and SpringSource repositories. Subsequent runs will not need to do this.
  Verify that the
  greenpages-2 Web Server, these dependencies can be loaded into memory as needed, but first they must be made available to Web Server.
  The Maven build included with GreenPages uses the
  dependency:copy-dependencies plugin to gather
  all the artifacts that GreenPages depends on that are not supplied by the Web Server runtime. These dependencies
  can then be installed into the Web Server repository. Dependencies are gathered automatically during the
  package phase. These dependencies can be found in
  $GREENPAGES_HOME/solution/greenpages/target/par-provided. To install dependencies
  simply copy all the
  *.jar files from this directory into
  $VWS_HOME/repository/usr.
  Installing dependencies on Windows:
  prompt> cd %GREENPAGES_HOME%\solution\greenpages prompt> copy target\par-provided\* %VWS_HOME%\repository\usr
  Installing Dependencies on UNIX:
  prompt$ cd $GREENPAGES_HOME/solution/greenpages prompt$ cp target/par-provided/* $VWS_HOME/repository/usr
  Notice that Web Web Server when copying these files.
  The next time Web Server is started the
  -clean option will cause Web Server to re-scan the repository directories in any case.
  It is always safe to start Web Web Server and start it:
  Copy the GreenPages PAR to the
  $VWS_HOME/pickup directory. On Unix:
  prompt$ cd $VWS_HOME prompt$ cp $GREENPAGES_HOME/solution/greenpages/target/greenpages-solution-2.3.0.RELEASE.par pickup/
  On Windows:
  prompt> cd %VWS_HOME% prompt> copy %GREENPAGES_HOME%\solution\greenpages\target\greenpages-solution-2.3.0.RELEASE.par pickup\
  Start Web Server with the
  -clean option. On Unix:
  prompt$ $VWS_HOME/bin/startup.sh -clean
  On Windows:
  prompt> "%VWS_HOME%"\bin\startup.bat -clean
  Verify that GreenPages starts correctly by checking in the Web Server output for the log message:
  <DE0005I> Started par 'greenpages' version '2 Web Web Server are associated with a Virgo Web Server runtime environment in Eclipse. This is to allow launching and testing from within Eclipse, and also to allow classpath construction in Eclipse to mirror the dynamic classpath in the Web Server runtime.
  Compilation errors in the previous step will be resolved here.
  To configure a Web Server runtime environment:
  Open→ → .
  In the Show View dialog choose → to make the servers view visible:
  Right-click in the Servers (which may not be empty) view and select → .
  In the New Server dialog, choose → and click Next.
  Click
  $VWS like this:
  It is safe to ignore these.
  When STS starts the Web Server it uses a ‘warm start’ by default.
  It is useful to set the
  -clean option so that every server start is a clean one.
  This is done by an option on the Web Server Overview window, which is obtained by opening the Web Server entry in the Servers window in STS.
  (Double-click, or right-click and choose Open.)
  The check box is labelled ‘Start server with -clean option’.
  Close the window before proceeding.
  Now that GreenPages is successfully imported into Eclipse, run the project directly from within the IDE.
  If the GreenPages PAR file was copied to the
  pickup directory, be sure it is now removed so that it does not conflict with the deployment of the Eclipse project. On Unix:
  prompt$ cd $VWS_HOME/pickup prompt$ rm greenpages-solution-2.3.0.RELEASE.par
  On Windows:
  prompt> cd %VWS_HOME%\pickup prompt> del greenpages-solution-2.3.0.RELEASE.par
  Also, to prevent conflicts with the server configured in Eclipse, stop a currently-running Web Server by typing
  Control-C in the console window.
  To run GreenPages from within Eclipse:
  Right click on the Web Server instance in the Servers view and select the menu item.
  Add greenpages-solution (which is the containing project or PAR) to the server and finish.
  To start Web Server from within Eclipse right-click on the Web Server node in the Servers window and choose Servers view should now show the server and the added project:. The
  Verify that GreenPages is started correctly by checking for
  <DE0005I> Started par 'greenpages' version '2.3.0.RELEASE'. in the Console window.
  (If errors are shown implying that GreenPages failed to be installed, this may be because some dependencies were not copied to Web Server, as described in section the section called “Installing dependencies into Web Server”. Check this.)
  Once installed and started GreenPages is again available from a web browser at the address.
  In common with most Enterprise Java applications GreenPages uses a web-based interface for user interactions. The following steps show how the controller for the application is constructed, using a service from the OSGi Service Registry.
  It is assumed that the instructions in Chapter 2, Installation have been followed already and that the GreenPages zip file has been downloaded and unzipped as described in Chapter 3, Installing and exploring GreenPages.
  Before beginning, configure the development environment to work with the application. In the case of GreenPages this means Maven and Eclipse.
  The following sections are most easily followed in the Java (or Spring) perspective (not, for example, the Java EE perspective). If not already in an appropriate perspective, switch in SpringSource Tool Suite using themenu:
  In this step create a reference to the Web Server instance that the GreenPages application integrates with (the instance may already be created if the GreenPages solution has been run from STS).
  In STS open Add… to create a new Web Server runtime environment. In the dialog that opens, select the Virgo Web Server (runtime) v2.1 and check the box to Create a new local server. When complete, press Next.→ → . Select
  In the next dialog, set the Virgo Web Server installation directory field to the
  value of
  $VWS_HOME and
  check that the JRE: option is set to Java 1.6 or later.
  This may not be the workbench default.
  When complete, press Finish.
  After returning to the Preferences window, press OK to return to Eclipse. The Servers view has opened and now shows an instance of Virgo Web Server in it.
  There is also a Servers project, in which the server is listed.
  The code should be edited to look like this:
   Web.
  During development time, it can be helpful to run an application inside of the deployment container. In the case
  of GreenPages, this means deploying the
  greenpages.web bundle to the Virgo Web Server.
  The Web Server can be used while working in Eclipse.
  In this step the
  greenpages.web bundle is deployed and the Web Server instance is started.
  Drag the
  greenpages.web project from the Package Explorer and drop it
  on the Web Server instance in the Servers view.
  Because
  greenpages.web is a web bundle the server will start automatically, and
  a browser window may open.
  Expand the Web Server instance and the bundle
  greenpages.web will be listed as a child.
  If deployment is successful the console will contain the message:
  <DE0005I> Started bundle 'greenpages.web' version '2.3.0'
  Leave the server instance running and go to the next step.
  The Web Server has special knowledge of web application bundles. In this step web bundle metadata is added to the bundle and a web browser is used to navigate to it.
  Open a web browser and navigate to. If the link is not currently served by any bundle in the Web Server there may be an error displayed:
  or else there is a blank page displayed. No pages are served.
  To fix this issue the
  greenpages.web bundle must be declared to be a web bundle and a
  context path defined.
  Open the
  template.mf file (at the top level under the
  greenpages.web project)
  and add (and save) the following entry (using the template.mf pane of the editor):
  Web-ContextPath: greenpages
  Be careful not to insert any blank lines or trailing spaces in this file.
  Once added, right-click on the
  greenpages.web project and select
  → .
  This will use a tool called Bundlor (included in STS) to update the OSGi metadata in the
  MANIFEST.MF file. Once Bundlor has finished running, open the
  META-INF/MANIFEST.MF file in the
  src/main/webapp folder.
  It should look something like the following:
  Manifest-Version: 1.0 Bundle-Name: GreenPages Web Import-Library: org.springframework.spring;version="[3.0, 3.1)" Import-Bundle: com.springsource.org.apache.taglibs.standard;version="[ 1.1.2,1.3)" Web-ContextPath: greenpages,org.springframework.stereotype,org.springframewo rk.web.bind.annotation,org.springframework.web.context,org.springfram ework.web.servlet Bundle-ManifestVersion: 2 Bundle-SymbolicName: greenpages.web Tool: Bundlor 1.0.0.RELEASE Bundle-Version: 2.3.0
  although the order of the entries may be different.
  The server (if it is still running) will track these changes and automatically refresh
  (or restart) the
  greenpages.web bundle as required.
  Observe the context path for the web bundle being announced
  (it should now be
  '/greenpages'
  whereas previously it would have been a default context path
  derived from the bundle name:
  '/greenpages.web').
  By default, Bundlor generates
  Import-Package entries with no version range specified.
  In the absence of a version range, the OSGi default (which denotes any version) is used.
  While this is very flexible it is generally a good idea to restrict an import by specifying a narrower range.
  This can be achieved by providing Bundlor with some additional information in the manifest template,
  as in the next step.
  Add (and save) the following entry to the
  template.mf file:
  Import-Template: org.springframework.*;version="[3.0.0, 3.1.0)"
  (Again, be careful not to leave trailing spaces on lines or insert blank lines in this file, except that there must be one trailing space after the colon to indicate that the header continues on the next line.)
  Re-run the MANIFEST.MF generation as described earlier.
  In the
  MANIFEST.MF file the
  Import-Package entry
  should now have version ranges on each of the
  springframework packages:;version="[3.0.0, 3.1.0)",org.springframework.ste reotype;version="[3.0.0, 3.1.0)",org.springframework.web.bind.annotat ion;version="[3.0.0, 3.1.0)",org.springframework.web.context;version= "[3.0.0, 3.1.0)",org.springframework.web.servlet;version="[3.0.0, 3.1 .0)"
  Behind the scenes the Web Server Tools have refreshed the deployed bundle as changes were made. Once again navigate to. This page now displays an entry field.
  Put any characters into the entry field and press Submit. This should display a “404” error page with the description:
  description The requested resource () is not available.
  This is because there is no search page (
  search.htm) to process this request yet.
  The next section will address this.
  At the end of the previous step, the Web Server instance was started
  and the
  greenpages.web bundle deployed.
  This bundle shows a static home page but a search value causes an error.
  The error appears because the URL for that search is not serviced by the controller.
  The application logic behind the search request is not in the
  greenpages.web project but
  in another project called
  greenpages.app.
  This section creates the
  greenpages.app project
  and then combines the two projects into a PAR so as to deploy them together as a single unit.
  While executing these instructions it is not necessary to remove bundles from the Web Server instance,
  nor to stop the instance.
  As changes are made the bundle will be refreshed (or redeployed) and the server instance
  may report errors if the changes are incomplete.
  These may safely be ignored.
  Alternatively, the
  greenpages.web bundle can be removed from the Web Server instance,
  or the server can be stopped while these changes are made.
  All of the bundles in the GreenPages sample are Maven projects which refer to a ‘parent’ project. To allow STS to accommodate references to the parent, import this project first.
  In the same way that the starting
  greenpages.web project was imported
  (see Section 4.3, “The controller”)
  import the
  $GREENPAGES_HOME/start/parent project.
  In this step, the
  greenpages.app project is imported which contains the business
  interfaces (and stub implementations of these interfaces).
  In the same way that the starting
  greenpages.web project was imported
  (see Section 4.3, “The controller”) Web.
  Change the Application Name to
  Greenpages PAR and the Version to
  2.3.0, then
  ensure that the Target Runtime
  is set to Virgo Web Server (Runtime) v2.1 and press Next.
  In the next dialog, select the
  greenpages.app and
  greenpages.web
  bundles so that they are contained in the PAR and press Finish.
  The project
  greenpages.web still shows, except for the one space after the colon,-SymbolicName: greenpages Tool: Bundlor 1.0.0.RELEASE Export-Package: greenpages;version="2.3.0" Bundle-Version: 2.3.0
  Go to the next step.
  Now that the
  greenpages.app bundle exports the package that the
  Directory and
  Listing interfaces reside in,
  the
  greenpages.web bundle must import it.
  In this step the Maven
  pom.xml file is updated to depend on the
  greenpages.app bundle and import the
  package.
  Open the
  pom.xml file in the
  greenpages.web project.
  (Edit the source directly by using the
  pom.xml tab in the editor.).;="[2.3, 2.4)"
  Be careful to include the “
  .*” in the package pattern.
  Once Bundlor has finished, go to the next step.
  Currently the Web Server instance has a single web module bundle deployed. In this step, the
  greenpages.web bundle is undeployed and
  greenpages PAR is deployed.
  Right-click on the Web Server in the Servers view, and select
  Add and Remove….)}.
  Web.
  The web bundle will not completely start.
  This is because there is no provider of a
  greenpages.Directory in
  the Service Registry. The next step will address this.
  The error is re-issued as the Web Web Server instance from the
  Servers view. If the GreenPages PAR was not
  removed before, it will be automatically deployed, otherwise deploy it as before. There should be no errors reported.
  When GreenPages is deployed successfully, open a web browser and navigate to. On
  the home page type
  wilkinson into the search field and press Submit.
  Unlike the previous attempt, this should return a list (of size 1) of search results. From here, select
  view to get the “detailed” listing.
  This uses a stub implementation of the
  Directory interface which only knows about “Andy Wilkinson”.
  The web interface is complete enough. Go to the next chapter to see the middle tier implementation.
  GreenPages’ middle-tier provides implementations of the
  Directory and
  Listing
  interfaces that can be used by the Web bundle. (and, mutatis mutandis on Windows).
  Click Next.
  In this page of the wizard, many of the Bundle Properties are already populated. The
  Bundle-SymbolicName is the name of the project. The
  Bundle-Name is
  derived from the
  Bundle-SymbolicName. The
  Bundle-Version is
  set, and there is no
  Bundle-Description.
  Change the
  Bundle-Name to “
  GreenPages DataSource” to more accurately
  describe the bundle’s purpose. An option to ‘Enable Bundle Classpath Container’ is already selected. It should
  be de-selected, as a Maven Classpath container will be configured later.
  Ensure that the Target Runtime
  is set to Virgo Web Server (Runtime) v2.1.
  Click Finish.
  The
  greenpages.db project appears in the Package Explorer view..
  (If the error
  Cannot find artifact for parent POM occurs check that the version is correct.
  It may differ from the one given here.) any:
  (It is useful to check that the Maven project just configured has the correct Java System library associated with it and that
  the
  MANIFEST.MF file that we have just moved is correctly generated when necessary.
  To ensure this, disable the dependency management (enabled in the previous section) and then re-enable it, saving the changes in between.
  This step may also change the Java system libraries associated with the build (right-click on the
  greenpages.db project, under Properties, Java build path and Libraries).
  If the Java system libraries look incorrect, simply remove them in the Libraries window and reset them.) is now resolved as Commons DBCP is available on the classpath.
  Now that the
  DataSource bean is available, it can be published into the OSGi service registry.
  Right-click the
  spring folder and select
  → again.
  This time specify
  a name of
  osgi-context.xml, click Next, and add the
  osgi
  namespace declaration
  (ensure that the resultant schema location string contains the URL
  as
  will result in an obscure deployment failure due to an invalid 'cacheTarget' property)..
  These imports may not be resolved.
  The
  greenpages.db project needs to be associated with a Web Server instance which has the
  Commons DBCP bundle in its repository to resolve them.
  In any event the next step adds the
  greenpages.db
  project to the GreenPages PAR and will result in it inheriting the PAR project’s targetted runtime
  configuration.
  Double-click the
  MANIFEST.MF file in the
  greenpages project in the
  Package Explorer view.
  Switch to the
  Dependencies tab and click Add….
  greenpages.db and click OK.
  Save the updated file. something like:
  Error creating bean with name 'dataSource' defined in URL [bundleentry://68.fwk504117357/META-INF/spring/ module-context.xml]: Invocation of init method failed; nested exception is org.apache.commons.dbcp.SQLNestedException: Cannot load JDBC driver class 'org.h2.Driver'
  though the numbers might be different.)
  There are a few cases where Bundlor will not identify a dependency on a class and, at the moment, this is one of them, although this is an area of Bundlor that is being improved all the time. Thankfully, it.
  (One possible cause of failure here is the username and password on the
  dataSource
  bean defined in
  module-context.xml. Check that these are exactly correct.)
  In this section the JPA module in GreenPages is created, building upon an existing skeleton. JPA and its metadata are configured, and a JPA-based Directory service implementation is published which is then consumed by the application’s Web bundle. retrieve also in the
  META-INF folder
  alongside.
  Open
  osgi-context.xml in the
  META-INF/spring folder of the
  greenpages.jpa project and add the following:
  <!-- import the DataSource from OSGi --> .
  (Some warnings concerning the
  dataSource bean will now disappear.) OSGi="[3.0,3.1)", org.springframework.transaction.aspectj;version="[3.0,3.1)" may.
  (A possible action if this fails is to Update (Maven) Dependencies on the project right-click menu in the Maven sub-menu.)
  Open Equinox console or the web-based admin console to examine the services being used
  by
  greenpages.web.
  The service which is being used by the Web bundle can be changed at runtime without having to restart the
  application or the Web Server. This can be achieved by changing
  greenpages.app so that it no longer
  publishes its
  Directory implementation. As a result of this
  Directory
  service no longer being available, the Web bundle_2.3.0]': …
  which indicates that there is some package (
  org.springframework.dao.annotation) which is not
  available to the “
  BundleClassLoader” for bundle
  greenpages-1-greenpages.jpa_2 so that the
  MANIFEST.MF
  is kept up to date as the project is changed.="[3.0,3.1)", greenpages;version="[2.0,2.1)", javax.persistence;version="[1.0.0,1.0.0]"
  If there is already an
  Import-Template header in the template, extend it to include the
  above package version range specifications.
  This header tells Bundlor that all imports of
  org.springframework packages
  should be in the range
  3.0 inclusive to
  3.1
  exclusive, that an import of the
  greenpages package should be in the
  range
  2.0 inclusive to Web Server.
  In our application integration testing means testing an application or portion of an application with other code. This kind of testing does look a bit different when developing for Web Server. In most cases Web.
  Before proceeding, stop any Web Server instance that was previously running., an
  “in-process” database is instantiated and populated with data for testing..
  If the test fails, check that the H2 database server is still running in the background.
  Proceed to the next step.
  Earlier a single bundle was integration tested by providing a test implementation of its
  DataSource dependency.
  When integration testing it is often a good idea to
  test the entire application outside of the container.
  In this step a test case for the
  entire GreenPages application is created,.
  The test should pass. If it doesn't, try the usual Eclipse dance steps of opening and closing the project and doing a clean rebuild to clear the problem. warnings like the following-2.3.0.RELEASE="[1.2.2.osgi, 1.2.2.osgi]"
  and, if further warnings are issued, in the
  template.mf file of other bundles (for example,
  greenpages.jpa).</artifactId> <name>GreenPages PAR</name> <packaging>par</packaging> <dependencies> </dependencies> <build> <plugins> </plugins> </build> </project>
  ensuring that the version numbers are consistent
  (for example,
  2.3.0.RELEASE might be
  2.3.0
  depending on which version of
  greenpages being developed).
  This skeleton defines a basic configuration with a parent POM. Notice that the
  packaging
  type is
  par. After this file is created contributed a Maven plugin to SpringSource (see Section A.2, “Documentation”)
  that builds a PAR file from a list of dependencies. In this step the Maven
  par plugin is added
  to properly build a PAR artifact type.
  In the
  <build><plugins>…</plugins></build> section, add a plugin declaration for the
  par plugin.
  <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-par-plugin</artifactId> <version>1.0.0.RELEASE</version> <configuration> <applicationSymbolicName>greenpages</applicationSymbolicName> <applicationDescription>GreenPages</applicationDescription> <> <type>war</type> </dependency>
  Now, run the following command.
  mvn clean package
  This command will now complete successfully and build a PAR into
  target/:
  [INFO] Scanning for projects... [INFO] ------------------------------------------------------------------------ [INFO] Building GreenPages PAR [INFO] task-segment: [clean, package] [INFO] ------------------------------------------------------------------------ [INFO] [clean:clean {execution: default-clean}] [INFO] [resources:resources {execution: default-resources}] [INFO] [par:par {execution: default-par}] [INFO] Assembling Artifacts for PAR '…/start/greenpages/target/greenpages-2.3.0.RELEASE.par' [INFO] Added 'greenpages.app.jar' [INFO] Added 'greenpages.jpa.jar' [INFO] Added 'greenpages.db.jar' [INFO] Added 'greenpages.web.war' [INFO] [com.springsource.bundlor.:transform {execution: bundlor}] [INFO] Ignored project with non-bundle packaging: [par] [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESSFUL [INFO] ------------------------------------------------------------------------
  Proceed to the next step.
  Maven now successfully builds the PAR for the application, however the dependencies,org.apache.log4j</excludeGroupIds> </configuration> </execution> </executions> </plugin>
  A dependency on Freemarker needs to be added to the other dependencies. This is required to ensure the Web bundle has the correct set of dependencies as well as the other bundles. Normally they would simply be resolved transitively from the bundle projects but the ‘war’ project does not pass on its dependencies; it expects them to be contained in its ‘lib’ directory. For this reason its dependencies must be given explicitly.
  <!-- Required for the web bundle as dependencies are not propagated up from war build types --> <dependency> <groupId>org.freemarker</groupId> <artifactId>com.springsource.freemarker</artifactId> <scope>provided</scope> </dependency>
  The next step is to stop the Web bundle including its dependencies in a lib directory as they will be provided
  by the runtime enviroment. Add the following build section to the
  greenpages.web POM file.
  <build> <plugins> <plugin> <artifactId>maven-war-plugin</artifactId> <version>2.1-beta-1</version> <configuration> <packagingExcludes>WEB-INF/lib/**</packagingExcludes> </configuration> </plugin> </plugins> </build>
  Run the following command.
  mvn clean package
  When the command has completed, it will have copied all of the PAR’s dependencies into the
  target/par-provided directory.
  The output from Maven should include lines like these
  [INFO] [par:par] [INFO] Assembling Artifacts for PAR '/Users/chrisfrost/Repos/GIT/greenpages/solution/ greenpages/target/greenpages-solution-2.3.0.RELEASE.par' [INFO] Added 'greenpages.app-solution.jar' [INFO] Added 'greenpages.jpa-solution.jar' [INFO] Added 'greenpages.db-solution.jar' [INFO] Added 'greenpages.web-solution.war'
  If the dependencies are produced, proceed to the next step.
  Although the application is built, and dependencies produced for separate deployment, the tests are not run as part of that build.
  Add (or replace) the following plug-in entry in the
  pom.xml file in the
  parent
  directory under
  start:
  /org/springframework/org.springframework.instrument/3.0.0.M3/org.springframework.instrument-3.0.0.M3.jar</argLine> </configuration> </plugin>
  where the location of the user Maven repository is hard-coded.
  Now run
  mvn clean install from the
  start directory.
  Observe that the tests we constructed before are now run.
  Maven can now build both the PAR application and the collection of dependencies required for the application. In this step the PAR and dependencies are copied to the Web Server and the PAR is started.
  Change directory to
  start/greenpages.
  Copy the JARs in the
  target/par-provided directory into the
  $VWS_HOME/repository/usr/ directory.
  Copy the PAR (
  greenpages-2.3.0.RELEASE.par) in the
  target/ directory
  into the
  $VWS_HOME/pickup directory.
  Start the Web Server and look for a message similar to:
  <DE0005I> Started par 'greenpages' version '2.3.0.RELEASE'.
  in the console output.
  Once deployment of the GreenPages application has completed, navigate to.
  The GreenPages application has been built from the command line, with a complete dependency set generated for independent deployment.
  The automated build and test procedure is to run
  mvn clean install from the
  base directory, generating the component bundles, and then to run
  mvn clean package from
  the
  greenpages directory to generate the PAR and produce all its dependencies.
  Virgo () — homepage for Virgo. Web Server Documentation () – cover page for all Virgo documentation.
  Spring DM Reference Guide ().
  Spring Framework 3.0 documentation ().
  FreeMarker documentation ().
  Eclipse IDE documentation ().
  EclipseLink documentation wiki ().
  Maven PAR plugin ().