Author: ykryvinchanka Date: 2007-11-13 06:19:40 -0500 (Tue, 13 Nov 2007) New Revision: 4868 Added: trunk/as/docs/reference/en/modules/modules.xml trunk/as/docs/reference/en/modules/perspective.xml trunk/as/docs/reference/en/modules/runtimes_servers.xml trunk/as/docs/reference/en/modules/webtools.xml Removed: trunk/as/docs/reference/en/modules/DeployingModules.xml trunk/as/docs/reference/en/modules/JBossASPerspective.xml trunk/as/docs/reference/en/modules/RuntimesAndServers.xml trunk/as/docs/reference/en/modules/WebToolsprojects.xml Log: http://jira.jboss.com/jira/browse/RHDS-298 JBossServManRef .Xml files names changed + pictures sorted into corresponding folders and named as "chapter_name_?" Deleted: trunk/as/docs/reference/en/modules/DeployingModules.xml =================================================================== --- trunk/as/docs/reference/en/modules/DeployingModules.xml 2007-11-13 09:54:09 UTC (rev 4867) +++ trunk/as/docs/reference/en/modules/DeployingModules.xml 2007-11-13 11:19:40 UTC (rev 4868) @@ -1,77 +0,0 @@ -<?xml version="1.0" encoding="ISO-8859-1"?> -<chapter id="deploy"> - <title>Deploying Modules (out of date!)</title> - - <para> - Deploying to a server is mostly painless. - There are several ways to do it provided by Webtools, - and some additional methods provided by RHDS. </para> - <section><title>WTP Projects</title> - <section><title>Run On Server</title> - <para> - The first WTP method is to right-click on a webtools project, - such as a dynamic web project, ejb project, or ear project. - and then selecting <emphasis> Run As &gt; Run on server</emphasis>. - The resulting dialog allows you to select which supporting - server the project can be published to. </para> - <para> - For the JBoss AS Server Adapters, publishing using this method - will force a default, best-guess, packaging configuration - for your project. This best-guess does <emphasis>not</emphasis> - publish incrementally, but instead repackages your entire - project into a .war, .jar, or .ear as appropriate, and - then coppies that file into the proper deploy directory. - For quicker smarter deployment, you will need to create - archives using the <emphasis>Project Archives</emphasis> - view and customize packaging yourself.</para> - </section> - <section><title>Add / Remove Projects</title> - <para> - Another method is in either the Servers View, or the JBoss - Servers View, to right click on a server and select - the <emphasis>Add or Remove Projects</emphasis> menu item. - This will bring up a dialog allowing you to either publish - projects / modules to a server, or remove them from the server.</para> - - <para> - If the selected module is a webtools project, - it will be published as in the <emphasis>Run on Server</emphasis> - option, with a best-guess full package. If, however, the selected - element is an archive from the <emphasis>Project Archives View</emphasis>, - it will be published according to the rules of that module type, which - are explained below.</para> - </section> - <section><title>JBoss Servers View, Publish</title> - <para> - In the JBoss Server's View, in the bottom section, is a - category called <emphasis>Modules</emphasis> which should - display all currently-published modules on the server. - By right-clicking on the desired module and selecting - <emphasis>Publish</emphasis>, it will force a full - rebuild of the entire module. </para> - </section> - <section><title>Project Archives View</title> - <para>In the Project Archives View, you can - right-click on any declared archive and select the - <emphasis>Publish To Server</emphasis> element, as described in - the last chapter. </para> - <para> - The ONLY WAY to ensure an <emphasis>Incremental Build</emphasis>, - such as changes to one jsp, html, or .class file, is to - enable the builder for that project. This is done by either changing - the global preferences for the Archives View, or in enabling - project-specific preferences and ensuring the builder is on.</para> - </section> - <!-- - <figure id="viewMain"> <title>JBoss Servers View: Main Section</title> - <mediaobject> - <alt>JBoss Servers View Main Section</alt> - <imageobject> - <imagedata - fileref="..\..\..\..\reference\en\images\asPerspective\viewMain.jpg"/> - </imageobject> - </mediaobject> - </figure> - --> - </section> - </chapter> Deleted: trunk/as/docs/reference/en/modules/JBossASPerspective.xml =================================================================== --- trunk/as/docs/reference/en/modules/JBossASPerspective.xml 2007-11-13 09:54:09 UTC (rev 4867) +++ trunk/as/docs/reference/en/modules/JBossASPerspective.xml 2007-11-13 11:19:40 UTC (rev 4868) @@ -1,251 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<chapter id="JBossASPerspective" xreflabel="JBossASPerspective"> - <?dbhtml filename="JBossASPerspective.html"?> - <chapterinfo> - <keywordset> - <keyword>Red Hat Developer Studio</keyword> - <keyword>Eclipse</keyword> - <keyword>Deploy</keyword> - <keyword>Deployment</keyword> - <keyword>JBoss</keyword> - </keywordset> - </chapterinfo> - <title>JBoss AS Perspective</title> - - <para>The <property>JBoss AS</property> Perspective is similar to the Java perspective, but it contains a few additional views. Two of the additional views are standard views, specifically the <property>Console </property> view and the <property>Properties</property> view. - The other two views that are added are the <property>Project archives</property> view and the <property>JBoss Servers View</property>.</para> - - <section id="JBossServersView"> - <?dbhtml filename="JBossServerView.html"?> - <title>The JBoss Servers View</title> - <para>This chapter will focus on the the JBoss Server's View. The JBoss Servers View is based on the Webtool's view, Servers View. The top half of the JBoss Servers View essentially embeds the original Servers View directly into it, making slight changes to the context menu. - A second half was added to provide additional information about the server selected in the top half. In the image provided, categories in the second half include which modules are currently deployed.</para> - - <figure> - <title>The JBoss Servers View</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/JBossASPerspective/jbossserverview.png"/> - </imageobject> - </mediaobject> - </figure> - - - <para>In order to access the view's preferences, you should access <emphasis><property>Window &gt; Preferences &gt; JBoss Tools &gt; JBoss Servers &gt; View</property></emphasis>. - This preference page allows you to select which view extensions you want on or off, the order they appear - in the view, as well as any other extension-specific preferences that may be available.</para> - <figure> - <title>View Preferences</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/JBossASPerspective/Enableprefer.png"/> - </imageobject> - </mediaobject> - </figure> - <para>Extender is meant to provide additional functionality relevent to the server selected in the top half of the view. If a standard server element is selected from above, some - of the extensions may still provide the additional information. Others may not. - - So, let's look at the currently available extensions to the JBoss Server's View.</para> - <figure> - <title>View Extensions</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/JBossASPerspective/JBVExtensions.png"/> - </imageobject> - </mediaobject> - </figure> - <para>The <property>Modules</property> section shows what modules are currently deployed to the server, and allows you to remove them - from the server, or force a full republish upon them. It only shows which modules have been deployed through Eclipse, - not any and all modules that happen to be in the deploy directory.</para> - <figure> - <title>Modules Action</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/JBossASPerspective/JBVModulesactions.png"/> - </imageobject> - </mediaobject> - </figure> - <para>The <property>Event Log</property> will show relevent information to your server's startup, shutdown, and publish processes. This allows - you to keep an eye on what's going on (such as automatic incremental deployment if you have it enabled). - The only action available is to clear the event log. However if the properties view is opened, you can receive further - information on each event log item (when available).</para> - <figure> - <title>Event Log Actions</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/JBossASPerspective/JBVEventlogactions.png"/> - </imageobject> - </mediaobject> - </figure> - <figure> - <title>Stopping the Server</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/JBossASPerspective/JBVServerisstopped.png"/> - </imageobject> - </mediaobject> - </figure> - <para>The <property>XML Configuration</property> category allows you to quickly browse to descriptor files in your server's deploy directory and - check or change the values. Its use requires the Properties view. Basically, XML Configuration are XML XPaths where a xpath is a path used to access - some specific part of an xml document.</para> - <figure> - <title>XML Configuration and Properties View</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/JBossASPerspective/JBVxmlconfigandprop.png"/> - </imageobject> - </mediaobject> - </figure> - <para>The view itself contains only a list of categories. By right-clicking on <emphasis><property>XML Configuration</property></emphasis>, you can create a new category. - Ports are provided by default and is filled with many of the most commonly used ports in the JBoss Server.</para> - <figure> - <title>Adding New Category</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/JBossASPerspective/JBSVaddingcategory.png"/> - </imageobject> - </mediaobject> - </figure> - <para>By right-clicking on <emphasis><property>Ports</property></emphasis>, you can create a new XPaths.</para> - <figure> - <title>Adding New XPath</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/JBossASPerspective/JBSVAddxpath.png"/> - </imageobject> - </mediaobject> - </figure> - <para>After that, the dialog shown below will appear.</para> - <figure> - <title>Adding New XPath</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/JBossASPerspective/JBSVAddinganxpath.png"/> - </imageobject> - </mediaobject> - </figure> - <para>As you type, the fields autocomplete to help you locate exactly what xpath you're looking for. The goal here is to - get an end result where the xpath matches up with an easily changed property. With that in mind, if the property - you want to change is the text of an element, then the final field Attribute Name - should be left blank and your xpath should end with port. - If, on the other hand, your desired field is the port attribute of &lt;fieldName port="35"&gt;, then your xpath will end - with fieldName and your Attribute Name will be "port". - When finished, you can click <emphasis><property>Preview</property></emphasis> to see how many matches you have for that particular xpath, as shown below.</para> - <figure> - <title>XPath Preview</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/JBossASPerspective/JBSVxpathpreview.png"/> - </imageobject> - </mediaobject> - </figure> - </section> - <section id="Project_archivesView"> - <title>Project archives View</title> - <para>Every application, whether plain old Java, J2EE, or some other language altogether, needs to be packaged in some way. In Java-related projects, - many people use ANT. Red Hat Developer Studio comes with our own archives tool with a bit easier and less-verbose XML and a handy user interface.</para> - <para>The Project Archives plugin consists primarily of a view to set up each packaging configuration. Each project can enable or disable its builder, or depend on the global setting.</para> - <para>The packaging configuration for each project is stored in that project's root folder, and is in a file named <property>.packages</property>, which has a fairly simple XML - structure. Modifying the file by hand is neither required nor reccommended, and using the UI is the official way of modifying your packaging structure.</para> - <para>Aside from the builder, the other preferences for the plugin are mostly cosmetic, allowing you to show full or truncated paths, show the project at the - root, etc. None of these have any effect on the functionality of the packaging plugin.</para> - - <section id="Creating an archive"> - <title>Creating an Archive</title> - <para>When creating a new archive, you have some different options at your disposal. If the project has no <property>.packages</property> file, your - options will be presented to you all at once for you to choose from (as above). Otherwise you will right-click inside the view and select <emphasis><property>New Archive</property></emphasis> - to see your archive type options.</para> - <figure> - <title>Create an Archive</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/JBossASPerspective/archives1.png"/> - </imageobject> - </mediaobject> - </figure> - <para>JAR is the standard archive type, and does very little configuration, leaving most of the work up to you. You can customize the name, add folders, - filesets, and inner jars to it.</para> - <para>The other types, for the most part, simply start off with a default setting, usually the jar with some specific children based on an expected - structure of the project. For example, if the project is a dynamic web project, and you create a WAR archive, the archive will be created with a few filesets relevant to the known structure of the project.</para> - - <para>Because the first page of all new archive wizards are the same, and it is also the only page in the New Jar Wizard, that page is shown below.</para> - <figure> - <title>New JAR Wizard</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/JBossASPerspective/archives2.png"/> - </imageobject> - </mediaobject> - </figure> - - <para>The page is pretty simple. All it asks is for the name of your new archive, a destination, which we'll get to in a moment, and whether the archive - is exploded or packaged up.</para> - <para>The destination of an archive can be anywhere on the filesystem, anywhere in the workspace, inside some other archive, or inside a folder - declared inside an archive. You can browse to workspace or filesystem destinations by clicking on their respective buttons. To select a destination - inside some other archive, you'll need to press the <property>Workspace...</property> button. At the bottom of the list, you'll see archives that have been declared in the - workspace.</para> - <section id="CreatingaFolder"> - <title>Creating a Folder</title> - <para>Creating a folder is much easier. You simply right-click on an archive or folder you want your new folder to be a child under. The only piece of - required information is naming the file.</para> - </section> - <section id="CreatingaFileSet"> - <title>Creating a FileSet</title> - <para>To create a new fileset, you click on an available target location such as an archive, a nested archive, or a folder within an archive, and select - New Fileset. The New Fileset Wizard requires a destination (where the files will go), and a root directory (or where the files are coming from). - The source can be anywhere in the workspace or from the filesystem at large.</para> - <para>Below that, the fileset requires only an includes pattern and an excludes pattern. As you type in either of these fields, the preview viewer should - update itself with which files are matched.</para> - </section> - </section> - <section id="View Actions"> - <title>View Actions</title> - <figure> - <title>Context Menu on the Item</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/JBossASPerspective/archives3.png"/> - </imageobject> - </mediaobject> - </figure> - <para>The context menu on the items in the view is extendable, but there are several that come standard. The first is the <property>Build Archive</property> action, enabled - only on top-level archives, which initiates a full build on that archive. Editing and deleting nodes are also standard actions, with deletion not needing - an explanation. The edit action brings up the wizard associated with that particular node type and allows the details to be changed. The final action - contribution here is the ability to publish to a declared server.</para> - </section> - <section id="PublishToServer"> - <title>Publish to Server</title> - <figure> - <title>Context Menu on the Item</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/JBossASPerspective/archives4.png"/> - </imageobject> - </mediaobject> - </figure> - <para>The dialog above appears after selecting <property>Publish To Server</property>. To simply publish once, you just select the server(s) that you want, and finish. - If you want the Publish to Server action on that particular Archive to always publish to that set of servers, then check the appropriate checkbox. - And finally, to enable automatic publishing upon build events, check the last checkbox.</para> - <para>The automatic publishing feature is nice if, for example, your package's destination (where it is built) is a temporary folder and you want the - archive published to several servers. If you only really want your archive published to one server, it might be easier to have the archive's destination - folder be the deploy folder of the server.</para> - </section> - - </section> - - <section id="Deploy to Server"> - <?dbhtml filename="DeployToServer.html"?> - <title>Deploy to Server</title> - <para>In the context menu of files there is a <property>Deploy To Server</property> option that allows a single file deployment. To deploy these non-WTP files/projects right click on the file (-ds.xml, .ear, .jar etc.) and select <emphasis><property>Deploy To server</property></emphasis> and it will be automatically deployed.</para> - <figure> - <title>Deploy to Sever</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/JBossASPerspective/deploytoserver.png"/> - </imageobject> - </mediaobject> - </figure> - <para>The deployed files are listed side-by-side with other modules that are deployed to the server.</para> - -</section> -</chapter> Deleted: trunk/as/docs/reference/en/modules/RuntimesAndServers.xml =================================================================== --- trunk/as/docs/reference/en/modules/RuntimesAndServers.xml 2007-11-13 09:54:09 UTC (rev 4867) +++ trunk/as/docs/reference/en/modules/RuntimesAndServers.xml 2007-11-13 11:19:40 UTC (rev 4868) @@ -1,126 +0,0 @@ -<?xml version="1.0" encoding="UTF-8"?> -<chapter id="RuntimesAndServers" xreflabel="RuntimesAndServers"> - <?dbhtml filename="RuntimesAndServers.html"?> - <chapterinfo> - <keywordset> - <keyword>Red Hat Developer Studio</keyword> - <keyword>Eclipse</keyword> - <keyword>Deploy</keyword> - <keyword>Deployment</keyword> - <keyword>JBoss</keyword> - </keywordset> - </chapterinfo> - <title>Runtimes and Servers in the JBoss AS plugin</title> - - <para>The JBoss AS plugin makes use of Webtools. This includes starting and stopping servers in run or debug mode. It also includes - targeting webtools projects, such as dynamic web projects, to certain server runtimes in order to ensure that the proper jars - from a specific server are added to the project's classpath properly.</para> - <para>In order to get started creating, running, and debugging J2EE applications, we must start with creating our <property>runtime</property> and - <property>server</property> instances.</para> - - <section> - <title>Webtools Runtimes</title> - <para>In RHDS, Server Runtimes have one main purpose: to point to a server installation somewhere on disk. - In our case, this will be a JBoss installation, and it can than be used for two primary purposes. - First, it provides classpath additions to webtools projects that require them. Second, for JBoss server at least, it provides information necessary - for the starting and stopping of the server, such as which jars to run and which configuration to use. </para> - - - <section><title>Installing a new Runtime</title> - <para>You can install runtimes into eclipse from the <emphasis><property>Window &gt; Preferences... </property></emphasis> - menu, and then selecting <emphasis><property>Server &gt; Installed Runtimes</property></emphasis> from the categories available.</para> - <figure> - <title>Installed Runtimes</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/serverRuntimes/installedRuntimes.png"/> - </imageobject> - </mediaobject> - </figure> - <para>From this preference page you can see what runtimes are declared, and what type they are. In the image shown above, there are two declared - runtimes, including a JBoss 4.2 instance.</para> - <para>To create a JBoss runtime, we begin by clicking the <emphasis><property>Add</property></emphasis> button. This will open another dialog that allows us to choose what type - of runtime we want to create. Most of the runtime options are provided by webtools, but those provided by RHDS are the ones we will focus on.</para> - <figure> - <title>Adding a Runtime</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/serverRuntimes/newRuntime.png"/> - </imageobject> - </mediaobject> - </figure> - <para>As seen above, there appear to be two JBoss categories. The first is contributed by webtools, and is a generic adapter that is not upkept very well. - For this reason, RHDS provides updated and supported adapters of our own. There is one for each of JBoss 3.2, 4.0, amd 4.2. You'll also note a deploy-only - runtime type. This type provides no classpath for webtools projects. It is used solely by it's server type for the purpose of setting up a deploy directory - for users who don't wish to make use of starting, stopping, or debugging their projects inside eclipse.</para> - <figure> - <title>Adding a JBoss 4.2 Runtime</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/serverRuntimes/new4.0Runtime.png"/> - </imageobject> - </mediaobject> - </figure> - <para>As shown above, all you need to do to create the runtime is to name it, browse to it's install directory, - select a Java Runtime Environment, and select which configuration you want. As you browse to a valid installation folder, the list of configurations will - update allowing you to select the configuration of your choice.</para> - <para>Once the runtime is created, the configuration is an unchanging property - of that runtime. This is because many of the jars necessary to provide for classpaths, such as the ejb3 jar locations or the servlet jar locations, - are located in deploy directories of each configurations (depending on which version of JBoss is being used). Because of this, to compile against - a different configuration's jars, you will need to create a new runtime from that configuration.</para> - <para>Also, because of the open-source nature of JBoss, it is likely that a user may want to - modify and repackage some of the configuration-specific jboss jars and create their own configuration using those modified jars. Rather than forcing the user to copy his - entire JBoss installation, this structure allows them to create only a new configuration instead.</para> - <para>As a result of having each runtime represent a specific configuration rather than the server installation as a whole, it is very likely you'll create several different runtimes - to test each of your configurations. It becomes important to ensure your runtimes, and later your servers, are given descriptive names that help you remember which is which. - It will do no good to try to remember if "JBoss-runtime 5" is the 4.0 install with ejb3? Or the 4.2 install's custom configuration you decided to create.</para> - <para>After pressing finish, you'll see that your new runtime has been added to the list and can now be targeted by webtools type projects or servers, both of which we'll get to later.</para> - </section> - - <section><title>Deleting a Runtime</title> - <para></para> - </section> - - </section> - - <section> - <title>Webtools Servers</title> - <para>Webtools servers are eclipse-representations of a backing server installation. They are used to start or stop servers, deploy to servers, or debug code that will run on the server. They keep track of what modules (jars, wars, etc) - you deploy to the server and also allow you to undeploy those modules. </para> - <para>Servers can be started or stopped with different command-line arguments. They are often backed by a runtime object representing that server's location.</para> - <section> - <title>Creating a New Server</title> - <para>There are many ways to get to the new server wizard. One way is to use the old standard <emphasis><property>File -&gt; New -&gt; Other... </property></emphasis>wizard, - and type in <emphasis><property>Server</property></emphasis>. This should show the screen below, which does not look that different from the initial screen when creating a new runtime. </para> - <figure> - <title>Adding a JBoss Server</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/serverRuntimes/newServer.png"/> - </imageobject> - </mediaobject> - </figure> - <para>Because the server object is what keeps track of things like command line arguments when starting or stopping, and runtimes keep track of the location of the installation, - each server instance must be backed by an appropriate runtime. </para> - <para>Because there may be many runtimes of each type declared, the wizard allows you to select which runtime you want your server to be backed by. The combo box below the view lets you - select which declared runtime to use. For example, if there were already multiple JBoss 4.2 runtimes declared, the combo box would list all of the 4.2 runtimes available. </para> - <para>If none of the runtimes declared are one you want to use, for example if you declared a default and a minimal runtime before but now want your server - to be backed by the ALL configuration, then you can click on the <emphasis><property>Installed Runtimes... </property></emphasis> button to bring up the preference page - shown at the beginning of this chapter. </para> - <figure> - <title>Installed Server Runtime Environments</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/serverRuntimes/installedRuntimeEnv.png"/> - </imageobject> - </mediaobject> - </figure> - <para>If the server you want to create doesn't have any installed runtime yet, the combo box and button will disappear, and the next page in the wizard will force you to create - the associated runtime first. </para> - <para>Either way, after targeting your server to a runtime, the final screen in this wizard is largely confirmational, giving the user a chance to verify - that he's selected the appropriate runtime. It also allows the user to name the server appropriately. </para> - </section> - - </section> - - </chapter> Deleted: trunk/as/docs/reference/en/modules/WebToolsprojects.xml =================================================================== --- trunk/as/docs/reference/en/modules/WebToolsprojects.xml 2007-11-13 09:54:09 UTC (rev 4867) +++ trunk/as/docs/reference/en/modules/WebToolsprojects.xml 2007-11-13 11:19:40 UTC (rev 4868) @@ -1,79 +0,0 @@ -<?xml version="1.0" encoding="ISO-8859-1"?> -<chapter id="webtoolsProjects"> - <title>Webtools Projects</title> - <section><title>Description</title> - <para> - Webtools provides what are called "faceted" projects. - Their most popular such projects are their J2EE projects, - such as their <property>Dynamic Web Project</property>, their EJB Project, - or their EAR project. </para> - <para> - The idea behind faceted projects is that each project - can accept units of functionality, or facets, which can be - added or removed by the user. Some examples of these facets - are adding a webdoclet facet to a web project, or an - ejbdoclet to an EJB Project. </para> - <para> - Most often, these "facets" either add to the project's classpath, - enable a builder, or watch the project in some other fashion. </para> - <para> - WTP projects have undergone some criticism as being - <emphasis>over-engineered</emphasis> or too restrictive in their - design. WTP projects are set up in a tree-relationship to each other, - where one project can be a child of another. For example, an EAR - project may have a Web Project child, an EJB project child, - or other types. </para> - <para> - The benefit of this is that the structure of your projects is - then known, and packaging it up *should* be trivial. However, - if your project is non-standard, or you feel too confined by - such rigid structural requirements, you can still choose to - package your project using the Archives plugin</para> - - </section> - - - <section><title>Faceted Project Wizards</title> - <para>To create a new <property>Dynamic Web Project</property> select <emphasis><property>File &gt; New &gt; Other...</property></emphasis> then <emphasis><property>Web &gt; Dynamic Web Project</property></emphasis></para> - <figure> - <title>New Dynamic Web Project</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/projects/newDynWeb.png"/> - </imageobject> - </mediaobject> - </figure> - <para>Click <emphasis><property>Next</property></emphasis> and you will see Dynamic Web Project page</para> - <figure> - <title>Faceted Project Wizard: First Page</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/projects/wizard1.png"/> - </imageobject> - </mediaobject> - </figure> - <para> - The first page of most WTP projects allows you to target a specific runtime, - representing a server's library location. It will also provide you the ability to - add this project to an EAR project, and select a pre-selected default set of facets, - called a configuration, rather than manually select each facet you might want.</para> - <para> - Selecting the runtime, again, allows the project to install the proper - classpaths to the project so it knows what code to compile against.</para> - <figure> - <title>Faceted Project Wizard: Second Page</title> - <mediaobject> - <imageobject> - <imagedata fileref="images/projects/wizard2.png"/> - </imageobject> - </mediaobject> - </figure> - <para> - The second page of the wizard allows you to enable or disable specific facets, as - described above. Some facets may require others, and some may conflict with others, - but on the whole this page allows you to add any number of facets that don't conflict - with each other. </para> - <para> - Further pages are specific to either the project type, or the facets selected.</para> - </section> -</chapter> Added: trunk/as/docs/reference/en/modules/modules.xml =================================================================== --- trunk/as/docs/reference/en/modules/modules.xml (rev 0) +++ trunk/as/docs/reference/en/modules/modules.xml 2007-11-13 11:19:40 UTC (rev 4868) @@ -0,0 +1,77 @@ +<?xml version="1.0" encoding="ISO-8859-1"?> +<chapter id="modules"> + <title>Deploying Modules (out of date!)</title> + + <para> + Deploying to a server is mostly painless. + There are several ways to do it provided by Webtools, + and some additional methods provided by RHDS. </para> + <section><title>WTP Projects</title> + <section><title>Run On Server</title> + <para> + The first WTP method is to right-click on a webtools project, + such as a dynamic web project, ejb project, or ear project. + and then selecting <emphasis>run on server...</emphasis>. + The resulting dialog allows you to select which supporting + server the project can be published to. </para> + <para> + For the JBoss AS Server Adapters, publishing using this method + will force a default, best-guess, packaging configuration + for your project. This best-guess does <emphasis>not</emphasis> + publish incrementally, but instead repackages your entire + project into a .war, .jar, or .ear as appropriate, and + then coppies that file into the proper deploy directory. + For quicker smarter deployment, you will need to create + archives using the <emphasis>Project Archives</emphasis> + view and customize packaging yourself.</para> + </section> + <section><title>Add / Remove Projects</title> + <para> + Another method is in either the Servers View, or the JBoss + Servers View, to right click on a server and select + the <emphasis>Add or Remove Projects</emphasis> menu item. + This will bring up a dialog allowing you to either publish + projects / modules to a server, or remove them from the server.</para> + + <para> + If the selected module is a webtools project, + it will be published as in the <emphasis>Run on Server</emphasis> + option, with a best-guess full package. If, however, the selected + element is an archive from the <emphasis>Project Archives View</emphasis>, + it will be published according to the rules of that module type, which + are explained below.</para> + </section> + <section><title>JBoss Servers View, Publish</title> + <para> + In the JBoss Server's View, in the bottom section, is a + category called <emphasis>Modules</emphasis> which should + display all currently-published modules on the server. + By right-clicking on the desired module and selecting + <emphasis>Publish</emphasis>, it will force a full + rebuild of the entire module. </para> + </section> + <section><title>Project Archives View</title> + <para>In the Project Archives View, you can + right-click on any declared archive and select the + <emphasis>Publish To Server</emphasis> element, as described in + the last chapter. </para> + <para> + The ONLY WAY to ensure an <emphasis>Incremental Build</emphasis>, + such as changes to one jsp, html, or .class file, is to + enable the builder for that project. This is done by either changing + the global preferences for the Archives View, or in enabling + project-specific preferences and ensuring the builder is on.</para> + </section> + <!-- + <figure id="viewMain"> <title>JBoss Servers View: Main Section</title> + <mediaobject> + <alt>JBoss Servers View Main Section</alt> + <imageobject> + <imagedata + fileref="..\..\..\..\reference\en\images\asPerspective\viewMain.jpg"/> + </imageobject> + </mediaobject> + </figure> + --> + </section> + </chapter> Added: trunk/as/docs/reference/en/modules/perspective.xml =================================================================== --- trunk/as/docs/reference/en/modules/perspective.xml (rev 0) +++ trunk/as/docs/reference/en/modules/perspective.xml 2007-11-13 11:19:40 UTC (rev 4868) @@ -0,0 +1,251 @@ +<?xml version="1.0" encoding="UTF-8"?> +<chapter id="perspective" xreflabel="perspective"> + <?dbhtml filename="perspective.html"?> + <chapterinfo> + <keywordset> + <keyword>Red Hat Developer Studio</keyword> + <keyword>Eclipse</keyword> + <keyword>Deploy</keyword> + <keyword>Deployment</keyword> + <keyword>JBoss</keyword> + </keywordset> + </chapterinfo> + <title>JBoss AS Perspective</title> + + <para>The <property>JBoss AS</property> Perspective is similar to the Java perspective, but it contains a few additional views. Two of the additional views are standard views, specifically the <property>Console </property> view and the <property>Properties</property> view. + The other two views that are added are the <property>Project archives</property> view and the <property>JBoss Servers View</property>.</para> + + <section id="JBossServersView"> + <?dbhtml filename="JBossServerView.html"?> + <title>The JBoss Servers View</title> + <para>This chapter will focus on the the JBoss Server's View. The JBoss Servers View is based on the Webtool's view, Servers View. The top half of the JBoss Servers View essentially embeds the original Servers View directly into it, making slight changes to the context menu. + A second half was added to provide additional information about the server selected in the top half. In the image provided, categories in the second half include which modules are currently deployed.</para> + + <figure> + <title>The JBoss Servers View</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/perspective/perspective_1.png"/> + </imageobject> + </mediaobject> + </figure> + + + <para>In order to access the view's preferences, you should access <emphasis><property>Window &gt; Preferences &gt; JBoss Tools &gt; JBoss Servers &gt; View</property></emphasis>. + This preference page allows you to select which view extensions you want on or off, the order they appear + in the view, as well as any other extension-specific preferences that may be available.</para> + <figure> + <title>View Preferences</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/perspective/perspective_2.png"/> + </imageobject> + </mediaobject> + </figure> + <para>Extender is meant to provide additional functionality relevent to the server selected in the top half of the view. If a standard server element is selected from above, some + of the extensions may still provide the additional information. Others may not. + + So, let's look at the currently available extensions to the JBoss Server's View.</para> + <figure> + <title>View Extensions</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/perspective/perspective_3.png"/> + </imageobject> + </mediaobject> + </figure> + <para>The <property>Modules</property> section shows what modules are currently deployed to the server, and allows you to remove them + from the server, or force a full republish upon them. It only shows which modules have been deployed through Eclipse, + not any and all modules that happen to be in the deploy directory.</para> + <figure> + <title>Modules Action</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/perspective/perspective_4.png"/> + </imageobject> + </mediaobject> + </figure> + <para>The <property>Event Log</property> will show relevent information to your server's startup, shutdown, and publish processes. This allows + you to keep an eye on what's going on (such as automatic incremental deployment if you have it enabled). + The only action available is to clear the event log. However if the properties view is opened, you can receive further + information on each event log item (when available).</para> + <figure> + <title>Event Log Actions</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/perspective/perspective_5.png"/> + </imageobject> + </mediaobject> + </figure> + <figure> + <title>Stopping the Server</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/perspective/perspective_6.png"/> + </imageobject> + </mediaobject> + </figure> + <para>The <property>XML Configuration</property> category allows you to quickly browse to descriptor files in your server's deploy directory and + check or change the values. Its use requires the Properties view. Basically, XML Configuration are XML XPaths where a xpath is a path used to access + some specific part of an xml document.</para> + <figure> + <title>XML Configuration and Properties View</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/perspective/perspective_7.png"/> + </imageobject> + </mediaobject> + </figure> + <para>The view itself contains only a list of categories. By right-clicking on <emphasis><property>XML Configuration</property></emphasis>, you can create a new category. + Ports are provided by default and is filled with many of the most commonly used ports in the JBoss Server.</para> + <figure> + <title>Adding New Category</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/perspective/perspective_8.png"/> + </imageobject> + </mediaobject> + </figure> + <para>By right-clicking on <emphasis><property>Ports</property></emphasis>, you can create a new XPaths.</para> + <figure> + <title>Adding New XPath</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/perspective/perspective_9.png"/> + </imageobject> + </mediaobject> + </figure> + <para>After that, the dialog shown below will appear.</para> + <figure> + <title>Adding New XPath</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/perspective/perspective_10.png"/> + </imageobject> + </mediaobject> + </figure> + <para>As you type, the fields autocomplete to help you locate exactly what xpath you're looking for. The goal here is to + get an end result where the xpath matches up with an easily changed property. With that in mind, if the property + you want to change is the text of an element, then the final field Attribute Name + should be left blank and your xpath should end with port. + If, on the other hand, your desired field is the port attribute of &lt;fieldName port="35"&gt;, then your xpath will end + with fieldName and your Attribute Name will be "port". + When finished, you can click <emphasis><property>Preview</property></emphasis> to see how many matches you have for that particular xpath, as shown below.</para> + <figure> + <title>XPath Preview</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/perspective/perspective_11.png"/> + </imageobject> + </mediaobject> + </figure> + </section> + <section id="Project_archivesView"> + <title>Project archives View</title> + <para>Every application, whether plain old Java, J2EE, or some other language altogether, needs to be packaged in some way. In Java-related projects, + many people use ANT. Red Hat Developer Studio comes with our own archives tool with a bit easier and less-verbose XML and a handy user interface.</para> + <para>The Project Archives plugin consists primarily of a view to set up each packaging configuration. Each project can enable or disable its builder, or depend on the global setting.</para> + <para>The packaging configuration for each project is stored in that project's root folder, and is in a file named <property>.packages</property>, which has a fairly simple XML + structure. Modifying the file by hand is neither required nor reccommended, and using the UI is the official way of modifying your packaging structure.</para> + <para>Aside from the builder, the other preferences for the plugin are mostly cosmetic, allowing you to show full or truncated paths, show the project at the + root, etc. None of these have any effect on the functionality of the packaging plugin.</para> + + <section id="Creating an archive"> + <title>Creating an Archive</title> + <para>When creating a new archive, you have some different options at your disposal. If the project has no <property>.packages</property> file, your + options will be presented to you all at once for you to choose from (as above). Otherwise you will right-click inside the view and select <emphasis><property>New Archive</property></emphasis> + to see your archive type options.</para> + <figure> + <title>Create an Archive</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/perspective/perspective_12.png"/> + </imageobject> + </mediaobject> + </figure> + <para>JAR is the standard archive type, and does very little configuration, leaving most of the work up to you. You can customize the name, add folders, + filesets, and inner jars to it.</para> + <para>The other types, for the most part, simply start off with a default setting, usually the jar with some specific children based on an expected + structure of the project. For example, if the project is a dynamic web project, and you create a WAR archive, the archive will be created with a few filesets relevant to the known structure of the project.</para> + + <para>Because the first page of all new archive wizards are the same, and it is also the only page in the New Jar Wizard, that page is shown below.</para> + <figure> + <title>New JAR Wizard</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/perspective/perspective_13.png"/> + </imageobject> + </mediaobject> + </figure> + + <para>The page is pretty simple. All it asks is for the name of your new archive, a destination, which we'll get to in a moment, and whether the archive + is exploded or packaged up.</para> + <para>The destination of an archive can be anywhere on the filesystem, anywhere in the workspace, inside some other archive, or inside a folder + declared inside an archive. You can browse to workspace or filesystem destinations by clicking on their respective buttons. To select a destination + inside some other archive, you'll need to press the <property>Workspace...</property> button. At the bottom of the list, you'll see archives that have been declared in the + workspace.</para> + <section id="CreatingaFolder"> + <title>Creating a Folder</title> + <para>Creating a folder is much easier. You simply right-click on an archive or folder you want your new folder to be a child under. The only piece of + required information is naming the file.</para> + </section> + <section id="CreatingaFileSet"> + <title>Creating a FileSet</title> + <para>To create a new fileset, you click on an available target location such as an archive, a nested archive, or a folder within an archive, and select + New Fileset. The New Fileset Wizard requires a destination (where the files will go), and a root directory (or where the files are coming from). + The source can be anywhere in the workspace or from the filesystem at large.</para> + <para>Below that, the fileset requires only an includes pattern and an excludes pattern. As you type in either of these fields, the preview viewer should + update itself with which files are matched.</para> + </section> + </section> + <section id="View Actions"> + <title>View Actions</title> + <figure> + <title>Context Menu on the Item</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/perspective/perspective_14.png"/> + </imageobject> + </mediaobject> + </figure> + <para>The context menu on the items in the view is extendable, but there are several that come standard. The first is the <property>Build Archive</property> action, enabled + only on top-level archives, which initiates a full build on that archive. Editing and deleting nodes are also standard actions, with deletion not needing + an explanation. The edit action brings up the wizard associated with that particular node type and allows the details to be changed. The final action + contribution here is the ability to publish to a declared server.</para> + </section> + <section id="PublishToServer"> + <title>Publish to Server</title> + <figure> + <title>Context Menu on the Item</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/perspective/perspective_15.png"/> + </imageobject> + </mediaobject> + </figure> + <para>The dialog above appears after selecting <property>Publish To Server</property>. To simply publish once, you just select the server(s) that you want, and finish. + If you want the Publish to Server action on that particular Archive to always publish to that set of servers, then check the appropriate checkbox. + And finally, to enable automatic publishing upon build events, check the last checkbox.</para> + <para>The automatic publishing feature is nice if, for example, your package's destination (where it is built) is a temporary folder and you want the + archive published to several servers. If you only really want your archive published to one server, it might be easier to have the archive's destination + folder be the deploy folder of the server.</para> + </section> + + </section> + + <section id="Deploy to Server"> + <?dbhtml filename="DeployToServer.html"?> + <title>Deploy to Server</title> + <para>In the context menu of files there is a <property>Deploy To Server</property> option that allows a single file deployment. To deploy these non-WTP files/projects right click on the file (-ds.xml, .ear, .jar etc.) and select <emphasis><property>Deploy To server</property></emphasis> and it will be automatically deployed.</para> + <figure> + <title>Deploy to Sever</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/perspective/perspective_16.png"/> + </imageobject> + </mediaobject> + </figure> + <para>The deployed files are listed side-by-side with other modules that are deployed to the server.</para> + +</section> +</chapter> Added: trunk/as/docs/reference/en/modules/runtimes_servers.xml =================================================================== --- trunk/as/docs/reference/en/modules/runtimes_servers.xml (rev 0) +++ trunk/as/docs/reference/en/modules/runtimes_servers.xml 2007-11-13 11:19:40 UTC (rev 4868) @@ -0,0 +1,126 @@ +<?xml version="1.0" encoding="UTF-8"?> +<chapter id="runtimes_servers" xreflabel="runtimes_servers"> + <?dbhtml filename="runtimes_servers.html"?> + <chapterinfo> + <keywordset> + <keyword>Red Hat Developer Studio</keyword> + <keyword>Eclipse</keyword> + <keyword>Deploy</keyword> + <keyword>Deployment</keyword> + <keyword>JBoss</keyword> + </keywordset> + </chapterinfo> + <title>Runtimes and Servers in the JBoss AS plugin</title> + + <para>The JBoss AS plugin makes use of Webtools. This includes starting and stopping servers in run or debug mode. It also includes + targeting webtools projects, such as dynamic web projects, to certain server runtimes in order to ensure that the proper jars + from a specific server are added to the project's classpath properly.</para> + <para>In order to get started creating, running, and debugging J2EE applications, we must start with creating our <property>runtime</property> and + <property>server</property> instances.</para> + + <section> + <title>Webtools Runtimes</title> + <para>In RHDS, Server Runtimes have one main purpose: to point to a server installation somewhere on disk. + In our case, this will be a JBoss installation, and it can than be used for two primary purposes. + First, it provides classpath additions to webtools projects that require them. Second, for JBoss server at least, it provides information necessary + for the starting and stopping of the server, such as which jars to run and which configuration to use. </para> + + + <section><title>Installing a new Runtime</title> + <para>You can install runtimes into eclipse from the <emphasis><property>Window &gt; Preferences... </property></emphasis> + menu, and then selecting <emphasis><property>Server &gt; Installed Runtimes</property></emphasis> from the categories available.</para> + <figure> + <title>Installed Runtimes</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/runtimes_servers/runtimes_servers_1.png"/> + </imageobject> + </mediaobject> + </figure> + <para>From this preference page you can see what runtimes are declared, and what type they are. In the image shown above, there are two declared + runtimes, including a JBoss 4.2 instance.</para> + <para>To create a JBoss runtime, we begin by clicking the <emphasis><property>Add</property></emphasis> button. This will open another dialog that allows us to choose what type + of runtime we want to create. Most of the runtime options are provided by webtools, but those provided by RHDS are the ones we will focus on.</para> + <figure> + <title>Adding a Runtime</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/runtimes_servers/runtimes_servers_2.png"/> + </imageobject> + </mediaobject> + </figure> + <para>As seen above, there appear to be two JBoss categories. The first is contributed by webtools, and is a generic adapter that is not upkept very well. + For this reason, RHDS provides updated and supported adapters of our own. There is one for each of JBoss 3.2, 4.0, amd 4.2. You'll also note a deploy-only + runtime type. This type provides no classpath for webtools projects. It is used solely by it's server type for the purpose of setting up a deploy directory + for users who don't wish to make use of starting, stopping, or debugging their projects inside eclipse.</para> + <figure> + <title>Adding a JBoss 4.2 Runtime</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/runtimes_servers/runtimes_servers_3.png"/> + </imageobject> + </mediaobject> + </figure> + <para>As shown above, all you need to do to create the runtime is to name it, browse to it's install directory, + select a Java Runtime Environment, and select which configuration you want. As you browse to a valid installation folder, the list of configurations will + update allowing you to select the configuration of your choice.</para> + <para>Once the runtime is created, the configuration is an unchanging property + of that runtime. This is because many of the jars necessary to provide for classpaths, such as the ejb3 jar locations or the servlet jar locations, + are located in deploy directories of each configurations (depending on which version of JBoss is being used). Because of this, to compile against + a different configuration's jars, you will need to create a new runtime from that configuration.</para> + <para>Also, because of the open-source nature of JBoss, it is likely that a user may want to + modify and repackage some of the configuration-specific jboss jars and create their own configuration using those modified jars. Rather than forcing the user to copy his + entire JBoss installation, this structure allows them to create only a new configuration instead.</para> + <para>As a result of having each runtime represent a specific configuration rather than the server installation as a whole, it is very likely you'll create several different runtimes + to test each of your configurations. It becomes important to ensure your runtimes, and later your servers, are given descriptive names that help you remember which is which. + It will do no good to try to remember if "JBoss-runtime 5" is the 4.0 install with ejb3? Or the 4.2 install's custom configuration you decided to create.</para> + <para>After pressing finish, you'll see that your new runtime has been added to the list and can now be targeted by webtools type projects or servers, both of which we'll get to later.</para> + </section> + + <section><title>Deleting a Runtime</title> + <para></para> + </section> + + </section> + + <section> + <title>Webtools Servers</title> + <para>Webtools servers are eclipse-representations of a backing server installation. They are used to start or stop servers, deploy to servers, or debug code that will run on the server. They keep track of what modules (jars, wars, etc) + you deploy to the server and also allow you to undeploy those modules. </para> + <para>Servers can be started or stopped with different command-line arguments. They are often backed by a runtime object representing that server's location.</para> + <section> + <title>Creating a New Server</title> + <para>There are many ways to get to the new server wizard. One way is to use the old standard <emphasis><property>File -&gt; New -&gt; Other... </property></emphasis>wizard, + and type in <emphasis><property>Server</property></emphasis>. This should show the screen below, which does not look that different from the initial screen when creating a new runtime. </para> + <figure> + <title>Adding a JBoss Server</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/runtimes_servers/runtimes_servers_4.png"/> + </imageobject> + </mediaobject> + </figure> + <para>Because the server object is what keeps track of things like command line arguments when starting or stopping, and runtimes keep track of the location of the installation, + each server instance must be backed by an appropriate runtime. </para> + <para>Because there may be many runtimes of each type declared, the wizard allows you to select which runtime you want your server to be backed by. The combo box below the view lets you + select which declared runtime to use. For example, if there were already multiple JBoss 4.2 runtimes declared, the combo box would list all of the 4.2 runtimes available. </para> + <para>If none of the runtimes declared are one you want to use, for example if you declared a default and a minimal runtime before but now want your server + to be backed by the ALL configuration, then you can click on the <emphasis><property>Installed Runtimes... </property></emphasis> button to bring up the preference page + shown at the beginning of this chapter. </para> + <figure> + <title>Installed Server Runtime Environments</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/runtimes_servers/runtimes_servers_5.png"/> + </imageobject> + </mediaobject> + </figure> + <para>If the server you want to create doesn't have any installed runtime yet, the combo box and button will disappear, and the next page in the wizard will force you to create + the associated runtime first. </para> + <para>Either way, after targeting your server to a runtime, the final screen in this wizard is largely confirmational, giving the user a chance to verify + that he's selected the appropriate runtime. It also allows the user to name the server appropriately. </para> + </section> + + </section> + + </chapter> Added: trunk/as/docs/reference/en/modules/webtools.xml =================================================================== --- trunk/as/docs/reference/en/modules/webtools.xml (rev 0) +++ trunk/as/docs/reference/en/modules/webtools.xml 2007-11-13 11:19:40 UTC (rev 4868) @@ -0,0 +1,79 @@ +<?xml version="1.0" encoding="ISO-8859-1"?> +<chapter id="webtools"> + <title>Webtools Projects</title> + <section><title>Description</title> + <para> + Webtools provides what are called "faceted" projects. + Their most popular such projects are their J2EE projects, + such as their <property>Dynamic Web Project</property>, their EJB Project, + or their EAR project. </para> + <para> + The idea behind faceted projects is that each project + can accept units of functionality, or facets, which can be + added or removed by the user. Some examples of these facets + are adding a webdoclet facet to a web project, or an + ejbdoclet to an EJB Project. </para> + <para> + Most often, these "facets" either add to the project's classpath, + enable a builder, or watch the project in some other fashion. </para> + <para> + WTP projects have undergone some criticism as being + <emphasis>over-engineered</emphasis> or too restrictive in their + design. WTP projects are set up in a tree-relationship to each other, + where one project can be a child of another. For example, an EAR + project may have a Web Project child, an EJB project child, + or other types. </para> + <para> + The benefit of this is that the structure of your projects is + then known, and packaging it up *should* be trivial. However, + if your project is non-standard, or you feel too confined by + such rigid structural requirements, you can still choose to + package your project using the Archives plugin</para> + + </section> + + + <section><title>Faceted Project Wizards</title> + <para>To create a new <property>Dynamic Web Project</property> select <emphasis><property>File &gt; New &gt; Other...</property></emphasis> then <emphasis><property>Web &gt; Dynamic Web Project</property></emphasis></para> + <figure> + <title>New Dynamic Web Project</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/webtools/webtools_1.png"/> + </imageobject> + </mediaobject> + </figure> + <para>Click <emphasis><property>Next</property></emphasis> and you will see Dynamic Web Project page</para> + <figure> + <title>Faceted Project Wizard: First Page</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/webtools/webtools_2.png"/> + </imageobject> + </mediaobject> + </figure> + <para> + The first page of most WTP projects allows you to target a specific runtime, + representing a server's library location. It will also provide you the ability to + add this project to an EAR project, and select a pre-selected default set of facets, + called a configuration, rather than manually select each facet you might want.</para> + <para> + Selecting the runtime, again, allows the project to install the proper + classpaths to the project so it knows what code to compile against.</para> + <figure> + <title>Faceted Project Wizard: Second Page</title> + <mediaobject> + <imageobject> + <imagedata fileref="images/webtools/webtools_3.png"/> + </imageobject> + </mediaobject> + </figure> + <para> + The second page of the wizard allows you to enable or disable specific facets, as + described above. Some facets may require others, and some may conflict with others, + but on the whole this page allows you to add any number of facets that don't conflict + with each other. </para> + <para> + Further pages are specific to either the project type, or the facets selected.</para> + </section> +</chapter>