This commit was manufactured by cvs2svn to create tag 'R1_5_1'.
diff --git a/development/.project b/development/.project
deleted file mode 100644
index 63e31a4..0000000
--- a/development/.project
+++ /dev/null
@@ -1,11 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<projectDescription>
- <name>jst server development</name>
- <comment></comment>
- <projects>
- </projects>
- <buildSpec>
- </buildSpec>
- <natures>
- </natures>
-</projectDescription>
diff --git a/development/PluginOverview.html b/development/PluginOverview.html
deleted file mode 100644
index 8404e94..0000000
--- a/development/PluginOverview.html
+++ /dev/null
@@ -1,47 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
-
- <TITLE>Eclipse JST server component plugins</TITLE>
- <META NAME="GENERATOR" CONTENT="OpenOffice.org 1.1.3 (Win32)">
- <META NAME="CREATED" CONTENT="20041111;21470709">
- <META NAME="CHANGED" CONTENT="16010101;0">
-</HEAD>
-<BODY>
-<P ><BR><BR>
-</P>
-<H1 ALIGN=CENTER>Eclipse JST server component plugins</H1>
-<H2>JST Server Plugins</H2>
-<P><BR>JSR Server consists of the following plugins</P>
-<UL>
- <LI><P STYLE="margin-bottom: 0cm">Plugin for j2ee
- runtime support</P>
- <LI><P STYLE="margin-bottom: 0cm">generic server that
- adds the ability to define new servers with a definition file</P>
- <LI><P STYLE="margin-bottom: 0cm">Apache Tomcat server
- tools</P>
-</UL>
-<HR>
-<H2 >Plugin Descriptions</H2>
-<H4>org.eclipse.jst.server.core</H4>
-<P>This plugin provides the core of the j2ee support.</P>
-<H4>org.eclipse.jst.server.ui</H4>
-<P>Provides the UI components for the j2ee support.</P>
-<H4>org.eclipse.jst.server.generic.core</H4>
-<P>The core of the generic server tool. Ýncludes
-the implemetation of server tooling and the mechanisms for server
-type definiton files.</P>
-<H4>org.eclipse.jst.server.generic.ui</H4>
-<P>The UI components for the generic server tooling.
-</P>
-<H4>org.eclipse.jst.server.generic.modules</H4>
-<P>Provides the j2ee standard module definitions used by
-the generic server plugin. This is subject to change when the
-flexible project work is completed.</P>
-<H4>org.eclipse.jst.server.tomcat.core</H4>
-<P>Apache Tomcat server tooling .</P>
-<H4>org.eclipse.jst.server.tomcat.ui</H4>
-<P>UI components for the Apache Tomcat Server tools.</P>
-<HR>
-</BODY>
-</HTML>
\ No newline at end of file
diff --git a/development/ServerDevelopmentPlan.html b/development/ServerDevelopmentPlan.html
deleted file mode 100644
index 82a9890..0000000
--- a/development/ServerDevelopmentPlan.html
+++ /dev/null
@@ -1,93 +0,0 @@
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
-<HTML>
-<HEAD>
- <TITLE>JST Server Development plan</TITLE>
-</HEAD>
-<BODY >
-<H1 align="center">JST Server Component Development Plan</H1>
-<H2 >Component lead: Naci Dai</H2>
-<H2 ><BR><BR>
-</H2>
-<P>The main goal for M2 is flexible project/module
-structure.
-</P>
-
-<P>Generic server plugin will become more generic. Provide extension points to easilly add new server type
-definitions.
-</P>
-
-<TABLE WIDTH=817 BORDER=1 CELLPADDING=2 CELLSPACING=3>
- <COL WIDTH=374>
- <COL WIDTH=56>
- <COL WIDTH=160>
- <COL WIDTH=137>
- <COL WIDTH=50>
- <TR>
- <TD WIDTH=374>
- <P><B>Task</B></P>
- </TD>
- <TD WIDTH=56>
- <P><B>Priority</B></P>
- </TD>
- <TD WIDTH=160>
- <P><B>Responsible <BR>Person or Team</B></P>
- </TD>
- <TD WIDTH=137>
- <P><B>Planned timeframe</B></P>
- </TD>
- <TD WIDTH=50>
- <P><B>Status</B></P>
- </TD>
- </TR>
- <TR>
- <TD WIDTH=374>
- <P>Seperate server and runtime in generic plugin</P>
- </TD>
- <TD WIDTH=56>
- <P>1</P>
- </TD>
- <TD WIDTH=160>
- <P>Gorkem Ercan</P>
- </TD>
- <TD WIDTH=137>
- <P>11/5 to 11/30 </P>
- </TD>
- <TD WIDTH=50> </TD>
- </TR>
- <TR>
-
- </TR>
- <TR>
- <TD WIDTH=374>
- <P>Create extension poin for adding new generic server definitions
- </P>
- </TD>
- <TD WIDTH=56>
- <P>2
- </P>
- </TD>
- <TD WIDTH=160>
- <P>Gorkem Ercan
- </P>
- </TD>
- <TD WIDTH=137>
- <P>11/16 to 12/10 </P>
- </TD>
-
- <TD WIDTH=50> </TD>
- </TR>
- <TD WIDTH=374>
- <P>Create and use a XSD for server definitions</P>
- </TD>
- <TD WIDTH=56 >
- <P>2</P>
- </TD>
- <TD WIDTH=160>
- <P>Gorkem Ercan, Naci Dai</P>
- </TD>
- <TD WIDTH=137>M3</TD>
- <TD WIDTH=50> </TD>
-</TABLE>
-</P>
-</BODY>
-</HTML>
diff --git a/development/description.txt b/development/description.txt
deleted file mode 100644
index be807de..0000000
--- a/development/description.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-This directory is used to hold various files useful to
-core developers (committers and contributors) to server tools
-component.
-
-Note, when checking 'development' out of repository to
-workspace, you may want to use "check out as" and
-name your workspace project 'jst server development',
-in case you have several 'development' folders checked out.
-
-Files in this directory should not be linked/published
-directly for web access (there's some issues with mirror
-updates I've heard) or included directly in builds.
-
-However, this directory can be used for initial or
-working copies of such documents which are then copied
-or published to appropriate locations once ready for
-such distribution.
\ No newline at end of file
diff --git a/development/meetingnotes/20041014.txt b/development/meetingnotes/20041014.txt
deleted file mode 100644
index f4cbe4f..0000000
--- a/development/meetingnotes/20041014.txt
+++ /dev/null
@@ -1,162 +0,0 @@
-jst server development meeting notes
-
-This file, while dated 20041014 actually covers a number of meeting
-over the last several weeks.
-
-
-20040819 Meeting notes
-
- Task: (?) someone should try doing "local build" following
- Naci's instructions, make sure it works ok, and give feedback
- on directions
-
- Task: (Gorkem) add unit tests (even if just a few simple onces
- that show class can be instantiated (and therefore plugin
- loaded).
-
- Task: (?) need to incorporate Elipse base "performance unit
- tests framework" to have regular performance data
-
-20040916 Meeting notes
-
- Jim des Rivieres presented "how to make platform quality code
- 101". (that can have a long life, etc).
- his presentation under miscdocuments directory, WTP Server Core APIs.ppt.
-
- He emphasized difference between API and SPI ... which is not
- well deliniated in current code.
-
-
- Later, referred to these web references.
- Some other API-related resources:
-
-
- http://www.eclipse.org/articles/Article-API%20use/eclipse-api-usage-rules.html
-
- http://eclipse.org/eclipse/development/java-api-evolution.html
-
- http://dev.eclipse.org/naming.html
-
-
-20040923
-
- Jim continued his presentation.
- For server core apis, it would seem more "SPI" would be
- extension points (and their required interfaces).
-
- When asked about what type of documentation is good examples
- of what we should produce, Jim mentioned two levels.
-
- First, they type of overview, such as that which exists in the
- Eclipse platforms Developers Guide
-
- Second, java doc: especially recommended core.resources and
- relationship to team.
- also mentioned jdt.core as good example of java doc.
-
- Task: (?) "developers guide" writeup for server provider and
- server clients
-
-
-
-
- Jim asked about JSR's 88 and 77. Its' believed 77 is already
- in JSK 1.4?
- No one knew enough to know implications (if they were things
- we should re-use, or things we had to be compliant with).
- Naci aggreed to study JSR 77 more
-
- Task: (Naci) JSR 77 -- what its it, what's implications for
- us?
-
- Task: (?) JSR 88 -- what is it and what's implications for us?
-
- Task?: (?) JMX was mentioned too (but I didn't get what was
- said).
-
- Naci mentioned something about difference between 'deploy' and
- 'publish' though I didn't get what it was (here in my notes),
- Probably because I was rememering how this has been confusing
- in the past with customers who think we provide a formal
- deployment
- system (managing version dependancies, groups of uesrs, etc.)
- for large IT shops.
-
-20040924
-
- Short meeting, We had connection trouble, so Naci and Gorkem
- could not present as planned.
-
- Marshall Culpepper from jboss.org joined call (on Dallas
- Time).
- Task (Marshall Culpepper) provide a JBoss adapter similar to
- how we have provided tomcat adapters.
-
- Tim mentioned lots of conversations with Darin Wright on
- improving launch support, so, for example, can have other
- launch preferences,
- a launched page history,
- I opened feature request
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=75762 to "hold"
- this area of work, though
- we will need to be more specific with what we want/need.
-
-
-20041007
-
-
- short meeting, Naci and Gorkem couldn't join.
-
- It was announced, though, that Arthur is having a face-face
- meeting in Toronto with Tim De Boer, Jim des Rivieres, and
- others from Toronto, in order to make faster progress in
- designs and making "platform quality apis".
-
-
-20041014
-
- Gorkem and Naci gave some demo's of "Lomboz-like" generic
- server support.
- they had 3 .server files for jboss, jonas, and something else
- I don't recall.
-
- The immediate feedback in the meeting was
-
- 1) why couldn't the XML files be "moved" to the
- extension point model and be part of a plugin?
- 2) even if that was undesirable for some cases/needs,
- there needs to be an "import" function that reads
- the file from one place on disk (or internet!?) and
- places them in metadirectory?, instead of user having
- to
- manually copying a file to the right place.
-
-
- Arthur wondered if this framework was generic enough to be
- used for a data base server (apache derby) to "publish" stored
- procedure calls.
- Naci responded that currently there was actually some J2EE
- specific stuff in there now, but in general could be made
- more generic.
-
- Naci had some UML diagrams he started to present before we ran
- out of time.
- [Naci perhaps you could please put those in miscdocuments,
- so we can read/study before next meeting].
-
- It quickly became apparent that we could not talk about
- 'server tools' design too much further, without addressing
- the 'flexible project' design, so everyone wanted to start
- focusing on that in weeks to come.
-
- After the call, in chat with Jim we decided before we jump
- right into project support, that we come up with and agree on
- some use-cases that have been implicit in this discussions. That
- way we can assign priorities to implementing/testing the use
- cases. This is critical so that we maintain focus and maintain the
- right scope of the design and the API. We discussed how it
- would be desireable to have the use-cases ironed out before the 10/25
- "focused design meeting".
-
- Task: (david) create initial rough draft of use cases
-
diff --git a/development/meetingnotes/20041021.txt b/development/meetingnotes/20041021.txt
deleted file mode 100644
index 1b69c38..0000000
--- a/development/meetingnotes/20041021.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-20041021 Agenda
-
- Assess where we are in design process and progress.
-
- Team agreed to flush out some use cases to help focus design,
- and help "limit" Release 1 API to only the most important, known paths.
-
- Jim expressed concern about having two API's, one for "known J2EE servers" and
- one for "unknown servers" (if I'm capturing it correctly) ... and how
- we do not want two API's. (then its not really an API, too difficult to maintain,
- and evolve).
-
- Discuss task to create explicit use cases
- Jim and Tim will create/add some while meeting in Toronto, and
- Jim will discuss next meeting (Tim will be not be able to make next meeting).
-
- Naci and Chuck will create some for project layout and discuss
- next week.
-
- How to capture the "intersection" of servers tools and projects is still
- unclear (to me).
-
- The role of ant tasks?
- Are they a positive thing?
- Or an admission we simple don't know what to do?
- (so instead of writing java code, users can write ant scripts?)
-
- team clarified:
- partially is to handle fact that while war's and ear's are "spec'd" where
- they go on a server is not.
- Also, many users have pre-existing build scripts they want to continue to use.
-
- Some of generic server support is providing launch parameters
- Naci acknowledge some of what's there now,
- could be moved to "properties files"/preference pages
-
- Project layout -- only briefly discussed -- Naci and Chuck to clarify next week.
- Eclipse native layout
- maps to J2EE runtime spec
- runs in place via file system
-
- Maven project layout.
-
- Native layout with linked contents
- maps to J2EE runtime spec (via links)
- runs in place (after following links?)
- Can we infer/derive links, given some constaints
- or user hints?
-
- User layout with user specified contents/relationships
- What do *we* do, then? (what's value add?)
-
\ No newline at end of file
diff --git a/development/meetingnotes/20041028.txt b/development/meetingnotes/20041028.txt
deleted file mode 100644
index 815b84c..0000000
--- a/development/meetingnotes/20041028.txt
+++ /dev/null
@@ -1,52 +0,0 @@
-20041028 Agenda
-
- Jim/Arthur to report on Server API meeting in Toronto
- (since Tim out)
- Naci/Chuck to report/present flexible project layout
-
-
- Jim:
-
- good meeting, appreciates complexity of the domain
- (much of the complexity hard to capture in use cases).
-
- overall, not a lot of simplification possible.
-
- * with the one exception of factoring out "project"
- related things, and probably replacing with a
- "module factory", where the project layout specific
- code could go. (the project specific stuff is mostly
- relevant during "publish" aspects and "project has changed"
- aspects).
-
- Once projects "removed" ... the "server core" and "module core"
- should be fairly separate pieces.
-
- This Needs a "concept document" describing domain.
- * [task] Jim will produce a draft of the document, while
- ideas are fresh in his mind.
-
- * Remaining (continuing) issue: They did not work on separation
- of WST part and JST part.
-
- Naci (and Chuck):
-
- Naci presented the use-case/design document he has in development directory,
- projectlayout-nmd.ppt.
-
- Chuck will put his response to this document in development directory
- as well. (The gist of which is a certain role out of what's feasible
- when, and some mention of successes in prototyping complex layouts using
- linked folders/resources. (I got the impression that for main flexible
- projects, there may be no need for improved Eclipse base support, but
- need to confirm that with Chuch/Naci as this work progresses.
-
- It was agreed a "concepts" document is needed here too, but
- was decided to wait until we see Jim's draft of server part,
- to decide how best to proceed.
-
-
- Agenda for next week:
-
- Jim will discuss/present servers/modules concepts document.
-
\ No newline at end of file
diff --git a/development/meetingnotes/20041104.txt b/development/meetingnotes/20041104.txt
deleted file mode 100644
index a906afd..0000000
--- a/development/meetingnotes/20041104.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-20041104 Agenda
-
- Attendees:
-
- Discuss Jim and Tim's concept documents (work in progress)
- see
- modules_and_servers.html, and
- web_tools_server_api_concepts.html
- (both in /jst/components/server/development/miscdocuments/ )
-
- Process for rolling out API changes.
-
- Next Steps?
-
-
\ No newline at end of file
diff --git a/development/meetingnotes/20041118.txt b/development/meetingnotes/20041118.txt
deleted file mode 100644
index 62df1aa..0000000
--- a/development/meetingnotes/20041118.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-20041118 Server/Module review meeting notes
-
-Attendees: David, Tim, Chuck, Jeem, and ?Jim?, from SAP
-
-Chuck: flexible project: will revise document by next week.
-
-Tim: working in sep. stream for API improvements.
- will be at at least some merge point for 12/2, so
- shortly after the integration build, he will merge
- back to head, so clients can update/change in time for
- 12/10 milestone cut-off date.
-
-Jeem: mentioned that is/when we use intenal APIs, and have
-opened feature request on base, we should add him on CC.
-
-Next Meeting:
- 12/2
- Agenda:
- Tim will discuss/describe new API's and design
- Chuck will discuss and describe latest
- flexible project design document.
-
-
diff --git a/development/miscdocuments/FlexibleProjectConcepts.htm b/development/miscdocuments/FlexibleProjectConcepts.htm
deleted file mode 100644
index 31fb715..0000000
--- a/development/miscdocuments/FlexibleProjectConcepts.htm
+++ /dev/null
@@ -1,958 +0,0 @@
-<html xmlns:v="urn:schemas-microsoft-com:vml"
-xmlns:o="urn:schemas-microsoft-com:office:office"
-xmlns:w="urn:schemas-microsoft-com:office:word"
-xmlns:st1="urn:schemas-microsoft-com:office:smarttags"
-xmlns="http://www.w3.org/TR/REC-html40">
-
-<head>
-<meta http-equiv=Content-Type content="text/html; charset=windows-1252">
-<meta name=ProgId content=Word.Document>
-<meta name=Generator content="Microsoft Word 10">
-<meta name=Originator content="Microsoft Word 10">
-<link rel=File-List href="FlexibleProjectConcepts_files/filelist.xml">
-<link rel=Edit-Time-Data href="FlexibleProjectConcepts_files/editdata.mso">
-<!--[if !mso]>
-<style>
-v\:* {behavior:url(#default#VML);}
-o\:* {behavior:url(#default#VML);}
-w\:* {behavior:url(#default#VML);}
-.shape {behavior:url(#default#VML);}
-</style>
-<![endif]-->
-<title>Problems that are obviously us:</title>
-<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
- name="place"/>
-<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
- name="City"/>
-<!--[if gte mso 9]><xml>
- <o:DocumentProperties>
- <o:Author>Michael D. Elder</o:Author>
- <o:LastAuthor>cbridgha</o:LastAuthor>
- <o:Revision>2</o:Revision>
- <o:TotalTime>6</o:TotalTime>
- <o:LastPrinted>2004-11-11T16:27:00Z</o:LastPrinted>
- <o:Created>2004-11-11T18:05:00Z</o:Created>
- <o:LastSaved>2004-11-11T18:05:00Z</o:LastSaved>
- <o:Pages>1</o:Pages>
- <o:Words>1502</o:Words>
- <o:Characters>8562</o:Characters>
- <o:Company>IBM</o:Company>
- <o:Lines>71</o:Lines>
- <o:Paragraphs>20</o:Paragraphs>
- <o:CharactersWithSpaces>10044</o:CharactersWithSpaces>
- <o:Version>10.4219</o:Version>
- </o:DocumentProperties>
-</xml><![endif]--><!--[if gte mso 9]><xml>
- <w:WordDocument>
- <w:Compatibility>
- <w:BreakWrappedTables/>
- <w:SnapToGridInCell/>
- <w:WrapTextWithPunct/>
- <w:UseAsianBreakRules/>
- </w:Compatibility>
- <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
- </w:WordDocument>
-</xml><![endif]--><!--[if !mso]><object
- classid="clsid:38481807-CA0E-42D2-BF39-B33AF135CC4D" id=ieooui></object>
-<style>
-st1\:*{behavior:url(#ieooui) }
-</style>
-<![endif]-->
-<style>
-<!--
- /* Font Definitions */
- @font-face
- {font-family:Wingdings;
- panose-1:5 0 0 0 0 0 0 0 0 0;
- mso-font-charset:2;
- mso-generic-font-family:auto;
- mso-font-pitch:variable;
- mso-font-signature:0 268435456 0 0 -2147483648 0;}
-@font-face
- {font-family:Tahoma;
- panose-1:2 11 6 4 3 5 4 4 2 4;
- mso-font-charset:0;
- mso-generic-font-family:swiss;
- mso-font-pitch:variable;
- mso-font-signature:1627421319 -2147483648 8 0 66047 0;}
- /* Style Definitions */
- p.MsoNormal, li.MsoNormal, div.MsoNormal
- {mso-style-parent:"";
- margin:0in;
- margin-bottom:.0001pt;
- mso-pagination:widow-orphan;
- font-size:12.0pt;
- font-family:"Times New Roman";
- mso-fareast-font-family:"Times New Roman";}
-h3
- {mso-margin-top-alt:auto;
- margin-right:0in;
- mso-margin-bottom-alt:auto;
- margin-left:0in;
- mso-pagination:widow-orphan;
- mso-outline-level:3;
- font-size:13.5pt;
- font-family:"Times New Roman";}
-a:link, span.MsoHyperlink
- {color:blue;
- text-decoration:underline;
- text-underline:single;}
-a:visited, span.MsoHyperlinkFollowed
- {color:purple;
- text-decoration:underline;
- text-underline:single;}
-@page Section1
- {size:8.5in 11.0in;
- margin:1.0in 1.25in 1.0in 1.25in;
- mso-header-margin:.5in;
- mso-footer-margin:.5in;
- mso-paper-source:0;}
-div.Section1
- {page:Section1;}
- /* List Definitions */
- @list l0
- {mso-list-id:132529151;
- mso-list-type:hybrid;
- mso-list-template-ids:1093442910 67698709 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
-@list l0:level1
- {mso-level-number-format:alpha-upper;
- mso-level-tab-stop:.5in;
- mso-level-number-position:left;
- text-indent:-.25in;}
-@list l0:level2
- {mso-level-number-format:alpha-lower;
- mso-level-tab-stop:1.0in;
- mso-level-number-position:left;
- text-indent:-.25in;}
-@list l0:level3
- {mso-level-number-format:roman-lower;
- mso-level-tab-stop:1.5in;
- mso-level-number-position:right;
- text-indent:-9.0pt;}
-@list l1
- {mso-list-id:288974159;
- mso-list-type:hybrid;
- mso-list-template-ids:1046108864 1111785440 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
-@list l1:level1
- {mso-level-start-at:0;
- mso-level-number-format:bullet;
- mso-level-text:-;
- mso-level-tab-stop:.75in;
- mso-level-number-position:left;
- margin-left:.75in;
- text-indent:-.25in;
- font-family:"Times New Roman";
- mso-fareast-font-family:"Times New Roman";}
-@list l2
- {mso-list-id:391659255;
- mso-list-type:hybrid;
- mso-list-template-ids:-1881621166 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
-@list l2:level1
- {mso-level-number-format:bullet;
- mso-level-text:\F0B7;
- mso-level-tab-stop:.5in;
- mso-level-number-position:left;
- text-indent:-.25in;
- font-family:Symbol;}
-@list l3
- {mso-list-id:859508517;
- mso-list-type:hybrid;
- mso-list-template-ids:2094045304 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
-@list l3:level1
- {mso-level-number-format:bullet;
- mso-level-text:\F0B7;
- mso-level-tab-stop:1.5in;
- mso-level-number-position:left;
- margin-left:1.5in;
- text-indent:-.25in;
- font-family:Symbol;}
-@list l4
- {mso-list-id:1006594864;
- mso-list-type:hybrid;
- mso-list-template-ids:-794890384 668081380 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
-@list l4:level1
- {mso-level-start-at:0;
- mso-level-number-format:bullet;
- mso-level-text:\F06E;
- mso-level-tab-stop:.75in;
- mso-level-number-position:left;
- margin-left:.75in;
- text-indent:-.25in;
- font-family:Wingdings;
- mso-fareast-font-family:"Times New Roman";
- mso-bidi-font-family:"Times New Roman";}
-@list l4:level2
- {mso-level-number-format:bullet;
- mso-level-text:o;
- mso-level-tab-stop:1.25in;
- mso-level-number-position:left;
- margin-left:1.25in;
- text-indent:-.25in;
- font-family:"Courier New";}
-@list l5
- {mso-list-id:1402829190;
- mso-list-type:hybrid;
- mso-list-template-ids:-1531251734 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
-@list l5:level1
- {mso-level-number-format:bullet;
- mso-level-text:\F0B7;
- mso-level-tab-stop:1.0in;
- mso-level-number-position:left;
- margin-left:1.0in;
- text-indent:-.25in;
- font-family:Symbol;}
-@list l6
- {mso-list-id:1457291202;
- mso-list-type:hybrid;
- mso-list-template-ids:-265669448 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
-@list l6:level1
- {mso-level-number-format:bullet;
- mso-level-text:\F0B7;
- mso-level-tab-stop:1.5in;
- mso-level-number-position:left;
- margin-left:1.5in;
- text-indent:-.25in;
- font-family:Symbol;}
-@list l7
- {mso-list-id:1838376975;
- mso-list-type:hybrid;
- mso-list-template-ids:-1460776930 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
-@list l7:level1
- {mso-level-number-format:bullet;
- mso-level-text:\F0B7;
- mso-level-tab-stop:1.0in;
- mso-level-number-position:left;
- margin-left:1.0in;
- text-indent:-.25in;
- font-family:Symbol;}
-ol
- {margin-bottom:0in;}
-ul
- {margin-bottom:0in;}
--->
-</style>
-<!--[if gte mso 10]>
-<style>
- /* Style Definitions */
- table.MsoNormalTable
- {mso-style-name:"Table Normal";
- mso-tstyle-rowband-size:0;
- mso-tstyle-colband-size:0;
- mso-style-noshow:yes;
- mso-style-parent:"";
- mso-padding-alt:0in 5.4pt 0in 5.4pt;
- mso-para-margin:0in;
- mso-para-margin-bottom:.0001pt;
- mso-pagination:widow-orphan;
- font-size:10.0pt;
- font-family:"Times New Roman";}
-table.MsoTableGrid
- {mso-style-name:"Table Grid";
- mso-tstyle-rowband-size:0;
- mso-tstyle-colband-size:0;
- border:solid windowtext 1.0pt;
- mso-border-alt:solid windowtext .5pt;
- mso-padding-alt:0in 5.4pt 0in 5.4pt;
- mso-border-insideh:.5pt solid windowtext;
- mso-border-insidev:.5pt solid windowtext;
- mso-para-margin:0in;
- mso-para-margin-bottom:.0001pt;
- mso-pagination:widow-orphan;
- font-size:10.0pt;
- font-family:"Times New Roman";}
-</style>
-<![endif]--><!--[if gte mso 9]><xml>
- <o:shapedefaults v:ext="edit" spidmax="2050"/>
-</xml><![endif]--><!--[if gte mso 9]><xml>
- <o:shapelayout v:ext="edit">
- <o:idmap v:ext="edit" data="1"/>
- </o:shapelayout></xml><![endif]-->
-</head>
-
-<body lang=EN-US link=blue vlink=purple style='tab-interval:.5in'>
-
-<div class=Section1>
-
-<p class=MsoNormal>The J2EE Flexible Project Concepts Documentation</p>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-<p class=MsoNormal>The goal of this document is to share some initial ideas
-that will help shape the Eclipse Web Tools (WTP) J2EE project application model
-and its implementation. We initially planned to pursue this effort as a formal
-requirements gathering and documentation process. But once we began analyzing
-the problem space it was clear that there is no common J2EE project model used
-within the J2EE development community. Stated another way, all current J2EE
-project models are ad hoc. At most, the J2EE application deployment model,
-defined in the J2EE specification, is the only common reference structure and
-it only specifies to the runtime archive form of valid J2EE applications. With
-that as our starting point, we concluded that rather than attempt to draft a
-conventional requirements document, it would be more beneficial to initiate a
-discussion of ideas among the key WTP participants that can serve as the
-catalyst for a J2EE application project requirements and subsequent
-architecture and implementation.</p>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-<p class=MsoNormal>The contents of this document are representative of the
-future direction. However, some of this functionality described is
-representative of our current state.</p>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-<p class=MsoNormal><span lang=TR style='mso-ansi-language:TR'>There are several
-use cases described in the Use Case Scenario Powerpoint Slides. Where relevant,
-the relationship of the concepts described in this document and the scenario
-slides are highlighted.</span><o:p></o:p></p>
-
-<p class=MsoNormal style='margin-left:.25in'><o:p> </o:p></p>
-
-<p class=MsoNormal><span lang=TR style='mso-ansi-language:TR'>A <b
-style='mso-bidi-font-weight:normal'>project</b> is a type of resource which
-groups resources into buildable, reusable units</span> - Java <span lang=TR
-style='mso-ansi-language:TR'>project resource</span>s are defined<span lang=TR
-style='mso-ansi-language:TR'> in terms of Java<span style='mso-spacerun:yes'>
-</span>elements such as package fragments, types, methods and fields.<o:p></o:p></span></p>
-
-<p class=MsoNormal><span lang=TR style='mso-ansi-language:TR'><o:p> </o:p></span></p>
-
-<p class=MsoNormal><span lang=TR style='mso-ansi-language:TR'>The scenario
-slides highlight the following types of use cases:<o:p></o:p></span></p>
-
-<p class=MsoNormal><span lang=TR style='mso-ansi-language:TR'><o:p> </o:p></span></p>
-
-<ul style='margin-top:0in' type=disc>
- <li class=MsoNormal style='mso-list:l2 level1 lfo8;tab-stops:list .5in'><span
- lang=TR style='mso-ansi-language:TR'>Simple Project (contains one module
- and one Deploy Scheme)<o:p></o:p></span></li>
- <li class=MsoNormal style='mso-list:l2 level1 lfo8;tab-stops:list .5in'><span
- lang=TR style='mso-ansi-language:TR'>Simple Container Project (contains one
- or more modules, possibly multiple Deploy Schemes)<o:p></o:p></span></li>
- <li class=MsoNormal style='mso-list:l2 level1 lfo8;tab-stops:list .5in'><span
- lang=TR style='mso-ansi-language:TR'>Application Project (application and
- modules contained in the same<span style='mso-spacerun:yes'>
- </span>Simple Container project)<o:p></o:p></span></li>
- <li class=MsoNormal style='mso-list:l2 level1 lfo8;tab-stops:list .5in'><span
- lang=TR style='mso-ansi-language:TR'>Application Project Variation (application
- in one Simple Container Project modules may be in other Simple Container
- projects)<o:p></o:p></span></li>
- <li class=MsoNormal style='mso-list:l2 level1 lfo8;tab-stops:list .5in'><span
- lang=TR style='mso-ansi-language:TR'>Composed Modules (stay tuned (bum bum
- bum))<o:p></o:p></span></li>
-</ul>
-
-<p class=MsoNormal><span lang=TR style='mso-ansi-language:TR'><o:p> </o:p></span></p>
-
-<p class=MsoNormal><span lang=TR style='mso-ansi-language:TR'>The J2EE module
-definitions build on the use case concepts. As discussed in the use cases, a
-module is a collection of files in a project. However, for the remainder of
-this document, the term abstract module will refer to an intangible concept (to
-be defined more explicitly later on). The abstract module concept represents
-the abstraction of a physical module in terms that can be understood
-programmatically. The specifics of how these projects<span
-style='mso-spacerun:yes'> </span>are constructed is not important to the
-discussion of modules.<o:p></o:p></span></p>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-<p class=MsoNormal>A <b style='mso-bidi-font-weight:normal'>resource</b> is a
-abstraction which contains model elements. A <b style='mso-bidi-font-weight:
-normal'>resource set </b>is a collection of related persistent resources. The
-resource set manages the collection of resources and produces notifications for
-changes to that collection. A <b style='mso-bidi-font-weight:normal'>project resource
-set </b>is a resource set defined at the project level, meaning the project
-resource set manages the collection of resources for that project. There is
-only one project resource set per project, ensuring each resource is only
-loaded once within the workspace. Each resource contained in the project
-resource set has a <b style='mso-bidi-font-weight:normal'>relative URI, </b>which<b
-style='mso-bidi-font-weight:normal'> </b>is a partial URI with respect to or
-relative to the project. A <b style='mso-bidi-font-weight:normal'>WTP project
-resource set </b>is defined in terms of module resources, which contain
-abstract module models (defined later).</p>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-<p class=MsoNormal>A <b style='mso-bidi-font-weight:normal'>URI converter</b>
-may be configured on a resource set to normalize relative URIs for comparison
-and to monitor access to the backing store.<span style='mso-spacerun:yes'>
-</span>The resource set will use this converter to produce an input or output
-stream for a URI, during serialization or deserialization of a resource, and
-during a load to check for a resource URI match to one of its known resources.</p>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-<p class=MsoNormal>An <b style='mso-bidi-font-weight:normal'>abstract module</b>
-is a logical, abstracted, first-class model of a deployable artifact. The
-initial assumption will be that abstract modules must be contained within one
-project and thus use one project resource set.<span style='mso-spacerun:yes'>
-</span>However, a project and the associated project resource set may contain
-more than one abstract module.</p>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-<p class=MsoNormal style='line-height:12.0pt;tab-stops:.5in 1.0in 1.5in 2.0in 2.5in 3.0in;
-mso-layout-grid-align:none;text-autospace:none'><span lang=TR style='color:
-black;mso-ansi-language:TR'>A <b style='mso-bidi-font-weight:normal'>J2EE a</b></span><b
-style='mso-bidi-font-weight:normal'><span lang=TR style='mso-ansi-language:
-TR'>bstract m<span style='color:black'>odule </span></span></b><span lang=TR
-style='color:black;mso-ansi-language:TR'>is a collection of one or more
-components, organized by a standard layout, targeted for the same container
-upon deployment</span><span style='color:black'>, and which can be archived
-conforming to the J2EE specification. Modules always contain a set of files,
-but all J2EE modules also contain specialized files called <b style='mso-bidi-font-weight:
-normal'>deployment descriptors</b>. Deployment descriptors describe the
-contents of deployment units and configure components and applications to their
-environment. They also externalize the relationships between components, so those
-relationships can be managed without writing or changing program code. There
-are five core types of J2EE deployment descriptors, each of which corresponds
-to a type of J2EE deployment unit: <o:p></o:p></span></p>
-
-<p class=MsoNormal style='line-height:12.0pt;tab-stops:.5in 1.0in 1.5in 2.0in 2.5in 3.0in;
-mso-layout-grid-align:none;text-autospace:none'><span style='color:black'><o:p> </o:p></span></p>
-
-<p class=MsoNormal style='margin-left:1.0in;text-indent:-.25in;line-height:
-12.0pt;mso-list:l3 level1 lfo7;tab-stops:list 1.0in left 2.0in 2.5in 3.0in;
-mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]><span
-style='font-family:Symbol;mso-fareast-font-family:Symbol;mso-bidi-font-family:
-Symbol;color:black'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'>
-</span></span></span><![endif]><span style='color:black'>Application<o:p></o:p></span></p>
-
-<p class=MsoNormal style='margin-left:1.0in;text-indent:-.25in;line-height:
-12.0pt;mso-list:l3 level1 lfo7;tab-stops:list 1.0in left 2.0in 2.5in 3.0in;
-mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]><span
-style='font-family:Symbol;mso-fareast-font-family:Symbol;mso-bidi-font-family:
-Symbol;color:black'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'>
-</span></span></span><![endif]><span style='color:black'>Application Client <o:p></o:p></span></p>
-
-<p class=MsoNormal style='margin-left:1.0in;text-indent:-.25in;line-height:
-12.0pt;mso-list:l3 level1 lfo7;tab-stops:list 1.0in left 2.0in 2.5in 3.0in;
-mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]><span
-style='font-family:Symbol;mso-fareast-font-family:Symbol;mso-bidi-font-family:
-Symbol;color:black'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'>
-</span></span></span><![endif]><span style='color:black'>EJB <o:p></o:p></span></p>
-
-<p class=MsoNormal style='margin-left:1.0in;text-indent:-.25in;line-height:
-12.0pt;mso-list:l3 level1 lfo7;tab-stops:list 1.0in left 2.0in 2.5in 3.0in;
-mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]><span
-style='font-family:Symbol;mso-fareast-font-family:Symbol;mso-bidi-font-family:
-Symbol;color:black'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'>
-</span></span></span><![endif]><span style='color:black'>Web <o:p></o:p></span></p>
-
-<p class=MsoNormal style='margin-left:1.0in;text-indent:-.25in;line-height:
-12.0pt;mso-list:l3 level1 lfo7;tab-stops:list 1.0in left 2.0in 2.5in 3.0in;
-mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]><span
-style='font-family:Symbol;mso-fareast-font-family:Symbol;mso-bidi-font-family:
-Symbol;color:black'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'>
-</span></span></span><![endif]><span style='color:black'>Resource Adapter for
-Java Connector<o:p></o:p></span></p>
-
-<p class=MsoNormal style='line-height:12.0pt;tab-stops:.5in 1.0in 2.0in 2.5in 3.0in;
-mso-layout-grid-align:none;text-autospace:none'><span style='color:black'><o:p> </o:p></span></p>
-
-<p class=MsoNormal style='line-height:12.0pt;tab-stops:.5in 1.0in 1.5in 2.0in 2.5in 3.0in;
-mso-layout-grid-align:none;text-autospace:none'><span style='color:black'>Vendor-specific
-deployment descriptors may be defined for different </span><st1:City><st1:place><span
- style='color:black'>Enterprise</span></st1:place></st1:City><span
-style='color:black'> application containers to provide additional information. <o:p></o:p></span></p>
-
-<p class=MsoNormal style='line-height:12.0pt;tab-stops:.5in 1.0in 1.5in 2.0in 2.5in 3.0in;
-mso-layout-grid-align:none;text-autospace:none'><span style='color:black'><o:p> </o:p></span></p>
-
-<p class=MsoNormal style='line-height:12.0pt;tab-stops:.5in 1.0in 1.5in 2.0in 2.5in 3.0in;
-mso-layout-grid-align:none;text-autospace:none'><span style='color:black'>Each
-deployment descriptor describes a set of contained objects which are
-represented through <b style='mso-bidi-font-weight:normal'>module models</b></span>.<span
-style='mso-spacerun:yes'> </span>The root abstract module model object for the
-deployment descriptor is the associated J2EE abstract module type object.</p>
-
-<p class=MsoNormal style='line-height:12.0pt;tab-stops:.5in 1.0in 1.5in 2.0in 2.5in 3.0in;
-mso-layout-grid-align:none;text-autospace:none'><o:p> </o:p></p>
-
-<p class=MsoNormal style='margin-left:1.0in;text-indent:-.25in;line-height:
-12.0pt;mso-list:l6 level1 lfo6;tab-stops:.5in 1.0in list 1.5in left 2.0in 2.5in 3.0in;
-mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]><span
-style='font-family:Symbol;mso-fareast-font-family:Symbol;mso-bidi-font-family:
-Symbol;color:black'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'>
-</span></span></span><![endif]><span style='color:black'>The <b
-style='mso-bidi-font-weight:normal'>Application</b> is the root object for an EAR
-module.<o:p></o:p></span></p>
-
-<p class=MsoNormal style='margin-left:1.0in;text-indent:-.25in;line-height:
-12.0pt;mso-list:l6 level1 lfo6;tab-stops:.5in 1.0in list 1.5in left 2.0in 2.5in 3.0in;
-mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]><span
-style='font-family:Symbol;mso-fareast-font-family:Symbol;mso-bidi-font-family:
-Symbol;color:black'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'>
-</span></span></span><![endif]><span style='color:black'>The <b
-style='mso-bidi-font-weight:normal'>EJBJar</b> is the root object for an EJB
-module.<o:p></o:p></span></p>
-
-<p class=MsoNormal style='margin-left:1.0in;text-indent:-.25in;line-height:
-12.0pt;mso-list:l6 level1 lfo6;tab-stops:.5in 1.0in list 1.5in left 2.0in 2.5in 3.0in;
-mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]><span
-style='font-family:Symbol;mso-fareast-font-family:Symbol;mso-bidi-font-family:
-Symbol;color:black'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'>
-</span></span></span><![endif]><span style='color:black'>The <b
-style='mso-bidi-font-weight:normal'>WebApp</b> is the root object for a Web
-module.<o:p></o:p></span></p>
-
-<p class=MsoNormal style='margin-left:1.0in;text-indent:-.25in;line-height:
-12.0pt;mso-list:l6 level1 lfo6;tab-stops:.5in 1.0in list 1.5in left 2.0in 2.5in 3.0in;
-mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]><span
-style='font-family:Symbol;mso-fareast-font-family:Symbol;mso-bidi-font-family:
-Symbol;color:black'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'>
-</span></span></span><![endif]><span style='color:black'>The <b
-style='mso-bidi-font-weight:normal'>ApplicationClient</b> is the root object
-for an Application Client module.<o:p></o:p></span></p>
-
-<p class=MsoNormal style='margin-left:1.0in;text-indent:-.25in;line-height:
-12.0pt;mso-list:l6 level1 lfo6;tab-stops:.5in 1.0in list 1.5in left 2.0in 2.5in 3.0in;
-mso-layout-grid-align:none;text-autospace:none'><![if !supportLists]><span
-style='font-family:Symbol;mso-fareast-font-family:Symbol;mso-bidi-font-family:
-Symbol;color:black'><span style='mso-list:Ignore'>·<span style='font:7.0pt "Times New Roman"'>
-</span></span></span><![endif]><span style='color:black'>The <b
-style='mso-bidi-font-weight:normal'>Connector</b> is the root object for a JCA
-Connector module.<o:p></o:p></span></p>
-
-<p class=MsoNormal style='line-height:12.0pt;tab-stops:.5in 1.0in 2.0in 2.5in 3.0in;
-mso-layout-grid-align:none;text-autospace:none'><span style='color:black'><span
-style='mso-spacerun:yes'> </span></span></p>
-
-<p class=MsoNormal>Before proceeding, it should be noted that there are two
-distinct metamodels in the tooling environment. First, J2EE abstract models
-allow framework clients to understand the J2EE-specific deployment descriptors
-and their third-party extensions. The tooling frameworks are built primarily to
-modify and update these models. There is also a separate model for
-understanding how modules and their contained resources can be constructed for
-deploying to server environments, which is referred to as <b style='mso-bidi-font-weight:
-normal'>ModuleCore</b>. </p>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-<p class=MsoNormal><b style='mso-bidi-font-weight:normal'>ModuleCore</b> can be
-used to acquire, create, and destroy <b style='mso-bidi-font-weight:normal'>abstract
-module contexts</b>. An <b style='mso-bidi-font-weight:normal'>abstract module
-context</b> is<b style='mso-bidi-font-weight:normal'> </b>used to manage
-multiple abstract modules per project. In the first implementation, an abstract
-module context will not span multiple projects. Each abstract module context identifies
-a unique custom defined abstract module using a module handle (see Server
-Tooling), server target type (see Server Tooling), an edit model (to be
-discussed later). </p>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-<table class=MsoTableGrid border=1 cellspacing=0 cellpadding=0
- style='border-collapse:collapse;border:none;mso-border-alt:solid windowtext .5pt;
- mso-yfti-tbllook:480;mso-padding-alt:0in 5.4pt 0in 5.4pt;mso-border-insideh:
- .5pt solid windowtext;mso-border-insidev:.5pt solid windowtext'>
- <tr style='mso-yfti-irow:0'>
- <td width=590 valign=top style='width:6.15in;border:solid windowtext 1.0pt;
- mso-border-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
- <p class=MsoNormal><!--[if mso & !supportInlineShapes & supportFields]><span
- style='mso-element:field-begin;mso-field-lock:yes'></span><span
- style='mso-spacerun:yes'> </span>SHAPE<span style='mso-spacerun:yes'>
- </span>\* MERGEFORMAT <span style='mso-element:field-separator'></span><![endif]--><!--[if gte vml 1]><v:group
- id="_x0000_s1067" editas="canvas" style='width:6in;height:198pt;
- mso-position-horizontal-relative:char;mso-position-vertical-relative:line'
- coordorigin="3960,10104" coordsize="7200,3394">
- <o:lock v:ext="edit" aspectratio="t"/>
- <v:shapetype id="_x0000_t75" coordsize="21600,21600" o:spt="75"
- o:preferrelative="t" path="m@4@5l@4@11@9@11@9@5xe" filled="f" stroked="f">
- <v:stroke joinstyle="miter"/>
- <v:formulas>
- <v:f eqn="if lineDrawn pixelLineWidth 0"/>
- <v:f eqn="sum @0 1 0"/>
- <v:f eqn="sum 0 0 @1"/>
- <v:f eqn="prod @2 1 2"/>
- <v:f eqn="prod @3 21600 pixelWidth"/>
- <v:f eqn="prod @3 21600 pixelHeight"/>
- <v:f eqn="sum @0 0 1"/>
- <v:f eqn="prod @6 1 2"/>
- <v:f eqn="prod @7 21600 pixelWidth"/>
- <v:f eqn="sum @8 21600 0"/>
- <v:f eqn="prod @7 21600 pixelHeight"/>
- <v:f eqn="sum @10 21600 0"/>
- </v:formulas>
- <v:path o:extrusionok="f" gradientshapeok="t" o:connecttype="rect"/>
- <o:lock v:ext="edit" aspectratio="t"/>
- </v:shapetype><v:shape id="_x0000_s1068" type="#_x0000_t75" style='position:absolute;
- left:3960;top:10104;width:7200;height:3394' o:preferrelative="f">
- <v:fill o:detectmouseclick="t"/>
- <v:path o:extrusionok="t" o:connecttype="none"/>
- <o:lock v:ext="edit" text="t"/>
- </v:shape><v:rect id="_x0000_s1069" style='position:absolute;left:4410;
- top:10258;width:6300;height:3086'>
- <v:textbox style='mso-next-textbox:#_x0000_s1069'>
- <![if !mso]>
- <table cellpadding=0 cellspacing=0 width="100%">
- <tr>
- <td><![endif]>
- <div>
- <p class=MsoNormal>ModuleCore</p>
- </div>
- <![if !mso]></td>
- </tr>
- </table>
- <![endif]></v:textbox>
- </v:rect><v:rect id="_x0000_s1070" style='position:absolute;left:4560;top:10721;
- width:2850;height:1080'>
- <v:textbox style='mso-next-textbox:#_x0000_s1070'>
- <![if !mso]>
- <table cellpadding=0 cellspacing=0 width="100%">
- <tr>
- <td><![endif]>
- <div>
- <p class=MsoNormal>ModuleContext</p>
- </div>
- <![if !mso]></td>
- </tr>
- </table>
- <![endif]></v:textbox>
- </v:rect><v:rect id="_x0000_s1071" style='position:absolute;left:7560;top:10721;
- width:2850;height:1080'>
- <v:textbox style='mso-next-textbox:#_x0000_s1071'>
- <![if !mso]>
- <table cellpadding=0 cellspacing=0 width="100%">
- <tr>
- <td><![endif]>
- <div>
- <p class=MsoNormal>ModuleContext</p>
- </div>
- <![if !mso]></td>
- </tr>
- </table>
- <![endif]></v:textbox>
- </v:rect><v:rect id="_x0000_s1072" style='position:absolute;left:4560;top:11955;
- width:2850;height:1080'>
- <v:textbox style='mso-next-textbox:#_x0000_s1072'>
- <![if !mso]>
- <table cellpadding=0 cellspacing=0 width="100%">
- <tr>
- <td><![endif]>
- <div>
- <p class=MsoNormal>ModuleContext</p>
- </div>
- <![if !mso]></td>
- </tr>
- </table>
- <![endif]></v:textbox>
- </v:rect><v:rect id="_x0000_s1073" style='position:absolute;left:7560;top:11955;
- width:2850;height:1080'>
- <v:textbox style='mso-next-textbox:#_x0000_s1073'>
- <![if !mso]>
- <table cellpadding=0 cellspacing=0 width="100%">
- <tr>
- <td><![endif]>
- <div>
- <p class=MsoNormal>ModuleContext</p>
- </div>
- <![if !mso]></td>
- </tr>
- </table>
- <![endif]></v:textbox>
- </v:rect><v:rect id="_x0000_s1074" style='position:absolute;left:4710;top:11029;
- width:1050;height:618'>
- <v:textbox style='mso-next-textbox:#_x0000_s1074'>
- <![if !mso]>
- <table cellpadding=0 cellspacing=0 width="100%">
- <tr>
- <td><![endif]>
- <div>
- <p class=MsoNormal>AbstractModule</p>
- </div>
- <![if !mso]></td>
- </tr>
- </table>
- <![endif]></v:textbox>
- </v:rect><v:rect id="_x0000_s1076" style='position:absolute;left:7710;top:11030;
- width:1050;height:617'>
- <v:textbox style='mso-next-textbox:#_x0000_s1076'>
- <![if !mso]>
- <table cellpadding=0 cellspacing=0 width="100%">
- <tr>
- <td><![endif]>
- <div>
- <p class=MsoNormal>Abstract<span style='mso-spacerun:yes'> </span>Module</p>
- </div>
- <![if !mso]></td>
- </tr>
- </table>
- <![endif]></v:textbox>
- </v:rect><v:rect id="_x0000_s1077" style='position:absolute;left:8910;top:11029;
- width:1050;height:618'>
- <v:textbox style='mso-next-textbox:#_x0000_s1077'>
- <![if !mso]>
- <table cellpadding=0 cellspacing=0 width="100%">
- <tr>
- <td><![endif]>
- <div>
- <p class=MsoNormal>Abstract<span style='mso-spacerun:yes'> </span>Module</p>
- </div>
- <![if !mso]></td>
- </tr>
- </table>
- <![endif]></v:textbox>
- </v:rect><v:rect id="_x0000_s1078" style='position:absolute;left:7710;top:12264;
- width:1050;height:617'>
- <v:textbox style='mso-next-textbox:#_x0000_s1078'>
- <![if !mso]>
- <table cellpadding=0 cellspacing=0 width="100%">
- <tr>
- <td><![endif]>
- <div>
- <p class=MsoNormal>Abstract Module</p>
- </div>
- <![if !mso]></td>
- </tr>
- </table>
- <![endif]></v:textbox>
- </v:rect><v:rect id="_x0000_s1079" style='position:absolute;left:8910;top:12264;
- width:1050;height:617'>
- <v:textbox style='mso-next-textbox:#_x0000_s1079'>
- <![if !mso]>
- <table cellpadding=0 cellspacing=0 width="100%">
- <tr>
- <td><![endif]>
- <div>
- <p class=MsoNormal>Abstract<span style='mso-spacerun:yes'> </span>Module</p>
- </div>
- <![if !mso]></td>
- </tr>
- </table>
- <![endif]></v:textbox>
- </v:rect><v:rect id="_x0000_s1080" style='position:absolute;left:4710;top:12264;
- width:1050;height:617'>
- <v:textbox style='mso-next-textbox:#_x0000_s1080'>
- <![if !mso]>
- <table cellpadding=0 cellspacing=0 width="100%">
- <tr>
- <td><![endif]>
- <div>
- <p class=MsoNormal>Abstract Module</p>
- </div>
- <![if !mso]></td>
- </tr>
- </table>
- <![endif]></v:textbox>
- </v:rect><v:rect id="_x0000_s1081" style='position:absolute;left:5910;top:12264;
- width:1050;height:617'>
- <v:textbox style='mso-next-textbox:#_x0000_s1081'>
- <![if !mso]>
- <table cellpadding=0 cellspacing=0 width="100%">
- <tr>
- <td><![endif]>
- <div>
- <p class=MsoNormal>Abstract Module</p>
- </div>
- <![if !mso]></td>
- </tr>
- </table>
- <![endif]></v:textbox>
- </v:rect><v:rect id="_x0000_s1156" style='position:absolute;left:5910;top:11030;
- width:1050;height:618'>
- <v:textbox style='mso-next-textbox:#_x0000_s1156'>
- <![if !mso]>
- <table cellpadding=0 cellspacing=0 width="100%">
- <tr>
- <td><![endif]>
- <div>
- <p class=MsoNormal>AbstractModule</p>
- </div>
- <![if !mso]></td>
- </tr>
- </table>
- <![endif]></v:textbox>
- </v:rect><w:wrap type="none"/>
- <w:anchorlock/>
- </v:group><![endif]--><![if !vml]><img width=576 height=264
- src="FlexibleProjectConcepts_files/image001.gif" v:shapes="_x0000_s1067 _x0000_s1068 _x0000_s1069 _x0000_s1070 _x0000_s1071 _x0000_s1072 _x0000_s1073 _x0000_s1074 _x0000_s1076 _x0000_s1077 _x0000_s1078 _x0000_s1079 _x0000_s1080 _x0000_s1081 _x0000_s1156"><![endif]><!--[if mso & !supportInlineShapes & supportFields]><v:shape
- id="_x0000_i1025" type="#_x0000_t75" style='width:6in;height:198pt'>
- <v:imagedata croptop="-65520f" cropbottom="65520f"/>
- </v:shape><span style='mso-element:field-end'></span><![endif]--></p>
- </td>
- </tr>
- <tr style='mso-yfti-irow:1;mso-yfti-lastrow:yes'>
- <td width=590 valign=top style='width:6.15in;border:solid windowtext 1.0pt;
- border-top:none;mso-border-top-alt:solid windowtext .5pt;mso-border-alt:solid windowtext .5pt;
- padding:0in 5.4pt 0in 5.4pt'>
- <p class=MsoNormal>Figure 1: Overview of ModuleCore, ModuleContext, and Abstract
- Module relationships.</p>
- </td>
- </tr>
-</table>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-<p class=MsoNormal>Meanwhile, <b style='mso-bidi-font-weight:normal'>edit
-models</b> provide a shared, reference counted, read/write controlled amalgamation
-of a related set of resources. Primarily, resources and Java working copies are
-wrapped by an Edit Model in order to represent a coherent and consistent view
-for clients. Managing these resources as a group, allows changes to be
-committed or rolled back as a consistent unit of work. </p>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-<p class=MsoNormal>Typically, specialized types of edit models have
-aforementioned knowledge of their expected or required resources for a given
-type of abstracted module. Not surprisingly, clients may wish to add
-capabilities and additional known resources to existing edit model. The edit
-model will attempt to load these resources so that they may be managed with the
-existing, known resources. <o:p></o:p></p>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-<p class=MsoNormal>Edit models are created via an extension which defines the <b
-style='mso-bidi-font-weight:normal'>edit model factory</b>. The lifecycle of
-how edit models are created and destroyed will be covered in the API Concepts
-document.</p>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-<p class=MsoNormal>Typically, J2EE components are built on a regular schedule
-(e.g. daily) and packaged as Enterprise Archives (EARs). Collaboration between
-teams and individual members is facilitated by these build artifacts which are
-used to back current development. These are referred to as <b style='mso-bidi-font-weight:
-normal'>target EARs</b>. Developers set up their development environments so
-the components they are actively working on are loaded directly from a source
-repository and the other components are loaded from the Target EARs.</p>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-<p class=MsoNormal>The use of target EARs is analogous to self-hosting in
-Eclipse. The idea is to only have abstract modules that are currently being
-developed in the workspace. All other dependencies will be loaded from a target
-EAR. Changing target EARs would simply be a matter of adjusting some abstract module
-property (just like PDE).<span style='mso-spacerun:yes'> </span>Loading
-projects from the repository, or deleting them from the workspace would change
-where they were loaded from as well (also like PDE).<o:p></o:p></p>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-<p class=MsoNormal>Rather than using target EARs, EAR files may be extracted to
-a structure which represents its contained abstract modules.<span
-style='mso-spacerun:yes'> </span>The remaining non-module jar archives are
-called <b style='mso-bidi-font-weight:normal'>utility jars</b>. Utility jars
-are regular jars which the various abstract modules can depend on.<span
-style='mso-spacerun:yes'> </span>Utility jars may exist as jar files within
-the EAR abstract module which is useful when a developer is not currently
-working on the contents of the utility jar. <span
-style='mso-spacerun:yes'> </span>All abstract module archives must (utility
-jars have the option) be handled in separate abstract modules.<b
-style='mso-bidi-font-weight:normal'><o:p></o:p></b></p>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-<p class=MsoNormal>An <b style='mso-bidi-font-weight:normal'>extracted</b> <b
-style='mso-bidi-font-weight:normal'>module</b> or <b style='mso-bidi-font-weight:
-normal'>utility jar module</b> is simply a module containing the extracted
-contents of the archive.<span style='mso-spacerun:yes'> </span>The benefit of
-using extracted modules is all the artifacts can be modified.<span
-style='mso-spacerun:yes'> </span>This would be useful if a developer did not
-have access to the source repository.<span style='mso-spacerun:yes'>
-</span>Typically, however, instead of using extracted modules, a developer
-would connect to a source repository. Jars within WARs can be extracted as modules
-within Eclipse projects (like utility jar modules) or can remain in the WAR in
-binary form. </p>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-<p class=MsoNormal>Document Concepts</p>
-
-<table class=MsoTableGrid border=1 cellspacing=0 cellpadding=0
- style='border-collapse:collapse;border:none;mso-border-alt:solid windowtext .5pt;
- mso-yfti-tbllook:480;mso-padding-alt:0in 5.4pt 0in 5.4pt;mso-border-insideh:
- .5pt solid windowtext;mso-border-insidev:.5pt solid windowtext'>
- <tr style='mso-yfti-irow:0'>
- <td width=295 valign=top style='width:221.4pt;border:solid windowtext 1.0pt;
- mso-border-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
- <p class=MsoNormal>Chuck<span style='mso-spacerun:yes'> </span>Bridgham</p>
- </td>
- <td width=295 valign=top style='width:221.4pt;border:solid windowtext 1.0pt;
- border-left:none;mso-border-left-alt:solid windowtext .5pt;mso-border-alt:
- solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
- <p class=MsoNormal><a href="mailto:cbridgha@us.ibm.com">cbridgha@us.ibm.com</a><o:p></o:p></p>
- </td>
- </tr>
- <tr style='mso-yfti-irow:1'>
- <td width=295 valign=top style='width:221.4pt;border:solid windowtext 1.0pt;
- border-top:none;mso-border-top-alt:solid windowtext .5pt;mso-border-alt:solid windowtext .5pt;
- padding:0in 5.4pt 0in 5.4pt'>
- <p class=MsoNormal>Jialin C. Chen </p>
- </td>
- <td width=295 valign=top style='width:221.4pt;border-top:none;border-left:
- none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt;
- mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid windowtext .5pt;
- mso-border-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
- <p class=MsoNormal><a href="mailto:jialin@us.ibm.com">jialin@us.ibm.com</a></p>
- </td>
- </tr>
- <tr style='mso-yfti-irow:2'>
- <td width=295 valign=top style='width:221.4pt;border:solid windowtext 1.0pt;
- border-top:none;mso-border-top-alt:solid windowtext .5pt;mso-border-alt:solid windowtext .5pt;
- padding:0in 5.4pt 0in 5.4pt'>
- <p class=MsoNormal>Michael D. Elder</p>
- </td>
- <td width=295 valign=top style='width:221.4pt;border-top:none;border-left:
- none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt;
- mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid windowtext .5pt;
- mso-border-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
- <p class=MsoNormal><a href="mailto:mdelder@us.ibm.com">mdelder@us.ibm.com</a></p>
- </td>
- </tr>
- <tr style='mso-yfti-irow:3'>
- <td width=295 valign=top style='width:221.4pt;border:solid windowtext 1.0pt;
- border-top:none;mso-border-top-alt:solid windowtext .5pt;mso-border-alt:solid windowtext .5pt;
- padding:0in 5.4pt 0in 5.4pt'>
- <p class=MsoNormal>Derek Holt</p>
- </td>
- <td width=295 valign=top style='width:221.4pt;border-top:none;border-left:
- none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt;
- mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid windowtext .5pt;
- mso-border-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
- <p class=MsoNormal><a href="mailto:dfholt@us.ibm.com">dfholt@us.ibm.com</a></p>
- </td>
- </tr>
- <tr style='mso-yfti-irow:4'>
- <td width=295 valign=top style='width:221.4pt;border:solid windowtext 1.0pt;
- border-top:none;mso-border-top-alt:solid windowtext .5pt;mso-border-alt:solid windowtext .5pt;
- padding:0in 5.4pt 0in 5.4pt'>
- <p class=MsoNormal>John Lanuti</p>
- </td>
- <td width=295 valign=top style='width:221.4pt;border-top:none;border-left:
- none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt;
- mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid windowtext .5pt;
- mso-border-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
- <p class=MsoNormal><a href="mailto:jlanuti@us.ibm.com">jlanuti@us.ibm.com</a></p>
- </td>
- </tr>
- <tr style='mso-yfti-irow:5;mso-yfti-lastrow:yes'>
- <td width=295 valign=top style='width:221.4pt;border:solid windowtext 1.0pt;
- border-top:none;mso-border-top-alt:solid windowtext .5pt;mso-border-alt:solid windowtext .5pt;
- padding:0in 5.4pt 0in 5.4pt'>
- <p class=MsoNormal>Jason Sholl</p>
- </td>
- <td width=295 valign=top style='width:221.4pt;border-top:none;border-left:
- none;border-bottom:solid windowtext 1.0pt;border-right:solid windowtext 1.0pt;
- mso-border-top-alt:solid windowtext .5pt;mso-border-left-alt:solid windowtext .5pt;
- mso-border-alt:solid windowtext .5pt;padding:0in 5.4pt 0in 5.4pt'>
- <p class=MsoNormal><a href="mailto:jsholl@us.ibm.com">jsholl@us.ibm.com</a></p>
- </td>
- </tr>
-</table>
-
-<p class=MsoNormal><o:p> </o:p></p>
-
-</div>
-
-</body>
-
-</html>
diff --git a/development/miscdocuments/FlexibleProjectConcepts_files/filelist.xml b/development/miscdocuments/FlexibleProjectConcepts_files/filelist.xml
deleted file mode 100644
index 8cc6128..0000000
--- a/development/miscdocuments/FlexibleProjectConcepts_files/filelist.xml
+++ /dev/null
@@ -1,5 +0,0 @@
-<xml xmlns:o="urn:schemas-microsoft-com:office:office">
- <o:MainFile HRef="../FlexibleProjectConcepts.htm"/>
- <o:File HRef="image001.gif"/>
- <o:File HRef="filelist.xml"/>
-</xml>
\ No newline at end of file
diff --git a/development/miscdocuments/FlexibleProjectConcepts_files/image001.gif b/development/miscdocuments/FlexibleProjectConcepts_files/image001.gif
deleted file mode 100644
index f2962db..0000000
--- a/development/miscdocuments/FlexibleProjectConcepts_files/image001.gif
+++ /dev/null
Binary files differ
diff --git a/development/miscdocuments/Server Tools API Branch.html b/development/miscdocuments/Server Tools API Branch.html
deleted file mode 100644
index 4d8a3bc..0000000
--- a/development/miscdocuments/Server Tools API Branch.html
+++ /dev/null
@@ -1,166 +0,0 @@
-<html>
-
-<head>
-<meta http-equiv="Content-Language" content="en-us">
-<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
-<link rel="stylesheet" href="http://www.eclipse.org/default_style.css" type="text/css">
-<title>Server Tools API Branch</title>
-</head>
-
-<body>
-
-<body alink="#ff0000" bgcolor="#ffffff" link="#0000ee" text="#000000" vlink="#551a8b">
-
-<table border="0" cellpadding="2" cellspacing="5" width="100%">
- <tbody><tr>
- <TD WIDTH=60%>
- <P ALIGN=LEFT><B><FONT SIZE=6><FONT FACE="Verdana, Arial, Helvetica, sans-serif">Server Tools API Branch</FONT></FONT></B><BR>
- <FONT SIZE=1><FONT FACE="Arial, Helvetica, sans-serif"><FONT COLOR="#8080ff">Information on the Server Tools API Branch</FONT></FONT></FONT>
- </P>
- </TD>
- <td rowspan="2" width="19%"><img src="http://www.eclipse.org/images/Idea.jpg" border="0" height="86" width="120"></td>
- </tr>
-</tbody></table>
-
-<table border="0" cellpadding="2" cellspacing="5" width="100%">
- <tbody><tr>
- <td colspan="2" align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">Changes</font></b></td>
- </tr></tbody>
-</table>
-
-This document contains information on the Server Tools API changes that have gone
-into the Server Tools API Branch for M2.
-
-<p/>
-
-<table border=1>
-<tr>
- <th>Change</th>
- <th>Reason</th>
- <th>Old Code</th>
- <th>New Code</th>
-</tr>
-<tr>
- <td>All java.util.Lists returned from methods have been changed to arrays of the corresponding
- content type.</td>
- <td>Stronger typed return values are safer, and returning a copy of the list (instead of the list
- itself) blocks against clients modifying internal data structures.</td>
- <td>List list = ServerCore.getRuntimeTypes();</td>
- <td>IRuntimeType[] rt = ServerCore.getRuntimeTypes();</td>
-</tr>
-<tr>
- <td>IResourceManager has been removed. Most of it's methods have been moved to the ServerCore
- class, with the remaining ones in ServerUtil.</td>
- <td>There was no client benefit of the resource manager, and it was misnamed.</td>
- <td>ServerCore.getResourceManager().getServers();</td>
- <td>ServerCore.getServers();</td>
-</tr>
-<tr>
- <td>All extension point interfaces have been changed to abstract classes, and the "I" removed
- from the name.</td>
- <td>Allows for future support and maintenance without breaking existing interfaces.</td>
- <td></td>
- <td></td>
-</tr>
-<tr>
- <td>Several interfaces were moved from the .core.model package to .core.</td>
- <td>The .core.model package was meant for SPIs, not API. All API classes & interfaces will
- be moved or remain in .core so that API users do not need to use the .core.model package.</td>
- <td>import org.eclipse.wst.server.code.model.IModule;</td>
- <td>import org.eclipse.wst.server.code.IModule;</td>
-</tr>
-<tr>
- <td>IServerResourceListener renamed to IServerLifecycleListener. Several methods moved out to
- new IRuntimeListener and IServerConfigurationListener interfaces.</td>
- <td>"Resource" had to be removed from the name, and the interface contained methods for
- runtimes and server configurations as well. They are split up so that API users do not
- need to listen for all types of changes from a single interface.</td>
- <td>ServerCore.getResourceManager().addServerResourceListener(myListener);</td>
- <td>ServerCore.addRuntimeLifecycleListener(myListener);</td>
-</tr>
-<tr>
- <td>Publishing interfaces completely rewritten & .core.resources package removed.</td>
- <td>The publishing interface was outdated and written before the Eclipse team support,
- ANT, or other recent publishing methods had been developed. The new API allows for
- better support and for each server type to use it's own publishing mechanism.</td>
- <td></td>
- <td></td>
-</tr>
-<tr>
- <td>IRuntimeDelegate and IRuntimeWorkingCopyDelegate merged into a single RuntimeDelegate.
- IServerDelegate and IServerWorkingCopyDelegate reworked into
- ServerDelegate and ServerBehaviourDelegate.</td>
- <td>Making clients provide two separate classes for the delegates was excessive,
- unnecessary, and ended up with too many SPI classes. Only a single delegate class is
- now required for these extension points.</td>
- <td></td>
- <td></td>
-</tr>
-<tr>
- <td>IRuntime.getDelegate(), IRuntime.getWorkingCopyDelegate() changed into IRuntime extending
- IAdaptable. Similar for IServer and other delegates</td>
- <td>IAdaptable is a common Eclipse mechanism, and allows for other extension as well. Clients
- should still remember that calling this method may involve plugin loading, so it should
- not be used in popup menus, etc.</td>
- <td>ITomcatRuntime tr = (ITomcatRuntime) runtime.getDelegate();</td>
- <td>ITomcatRuntime tr = (ITomcatRuntime) runtime.getAdapter(ITomcatRuntime.class);</td>
-</tr>
-<tr>
- <td>IModuleType and IModuleKind interfaces merged.</td>
- <td>IModuleKind was created late in the previous release cycle and couldn't be merged at the
- time it was created.</td>
- <td></td>
- <td></td>
-</tr>
-<tr>
- <td>IServerTask changed and IModuleTask removed.</td>
- <td>The existing interfaces had an ITask directly returned as a delegate, and only allowed a
- single task per extension point. The new IServerTask allows the delegate to return multiple
- tasks from a single extension point, and it is not itself a task.</td>
- <td></td>
- <td></td>
-</tr>
-<tr>
- <td>IServerConfiguration, IServerConfiguration, etc. removed</td>
- <td>The server config was a relic and did not need to be a first class resource. ServerDelegates
- are now directly responsible for maintaining the configuration.</td>
- <td></td>
- <td>see Tomcat implementation</td>
-</tr>
-<tr>
- <td>Various minor cleanup - methods renamed, parameters changed, etc.</td>
- <td>Cleanup and future maintenance.</td>
- <td></td>
- <td></td>
-</tr>
-<tr>
- <td>IModuleObjectAdapter -> IModuleArtifactAdapter, IModuleObject -> IModuleArtifact</td>
- <td>Object was too generic and didn't have any real meaning. Artifact represents what the
- IModuleObject really represents - resources within a module</td>
- <td></td>
- <td></td>
-</tr>
-<tr>
- <td>getServerType(String id) -> findServerType(String id)</td>
- <td>Lookup methods on ServerCore and ServerUtil renamed to be more accurate.</td>
- <td>IServerType st = getServerType("com.x")</td>
- <td>IServerType st = findServerType("com.x")</td>
-</tr>
-<tr>
- <td>Lots of methods & interfaces moved to internal packages</td>
- <td>Need to trim down the exposed API to only what is required for ongoing maintenance. If
- there is anything in an internal package that you were previously using, or plan to use
- in the future, please contact me and we'll work out an API solution</td>
- <td></td>
- <td></td>
-</tr>
-<tr>
- <td></td>
- <td></td>
- <td></td>
- <td></td>
-</tr>
-</table>
-
-</body>
-</html>
\ No newline at end of file
diff --git a/development/miscdocuments/Server Tools API Changes.html b/development/miscdocuments/Server Tools API Changes.html
deleted file mode 100644
index db1c8e3..0000000
--- a/development/miscdocuments/Server Tools API Changes.html
+++ /dev/null
@@ -1,263 +0,0 @@
-<html>
-
-<head>
-<meta http-equiv="Content-Language" content="en-us">
-<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
-<link rel="stylesheet" href="http://www.eclipse.org/default_style.css" type="text/css">
-<title>Server Tools API Changes</title>
-<style>
-td { font-family: arial, helvetica, geneva; font-size: 9pt; vertical-align: top; }
-td.code { font-family: "Courier New", Courier, mono; font-size: 7.75pt}
-</style>
-</head>
-
-<body alink="#ff0000" bgcolor="#ffffff" link="#0000ee" text="#000000" vlink="#551a8b">
-
-<table border="0" cellpadding="2" cellspacing="5" width="100%">
- <tbody><tr>
- <TD WIDTH=60%>
- <P ALIGN=LEFT><B><FONT SIZE=6><FONT FACE="Verdana, Arial, Helvetica, sans-serif">Server Tools API Changes</FONT></FONT></B><BR>
- <FONT SIZE=1><FONT FACE="Arial, Helvetica, sans-serif"><FONT COLOR="#8080ff">Information on Server Tools API Changes</FONT></FONT></FONT>
- </P>
- </TD>
- <td rowspan="2" width="19%"><img src="http://www.eclipse.org/images/Idea.jpg" border="0" height="86" width="120"></td>
- </tr>
-</tbody></table>
-
-
-<table border="0" cellpadding="2" cellspacing="5" width="100%">
- <tbody><tr>
- <td colspan="2" align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">M1 Changes</font></b></td>
- </tr></tbody>
-</table>
-
-This document contains information on the Server Tools API changes that have gone
-into M1.
-
-<p/>
-
-<table border=1 cellspacing="0">
-<tr>
- <th>Change</th>
- <th>Reason</th>
- <th>Old Code</th>
- <th>New Code</th>
-</tr>
-<tr>
- <td>Package renames:<br/>
- com.ibm.wtp.server.core -> org.eclipse.wst.server.core<br/>
- com.ibm.wtp.server.ui -> org.eclipse.wst.server.ui<br/>
- com.ibm.wtp.server.util -> org.eclipse.wst.server.util<br/>
- com.ibm.wtp.server.java.core -> org.eclipse.jst.server.core<br/>
- com.ibm.wtp.server.java.ui -> org.eclipse.jst.server.ui<br/>
- com.ibm.wtp.server.tomcat.core -> org.eclipse.jst.server.tomcat.core<br/>
- com.ibm.wtp.server.tomcat.ui -> org.eclipse.jst.server.tomcat.ui<br/>
- com.ibm.wtp.monitor.core -> org.eclipse.wst.monitor.core<br/>
- com.ibm.wtp.monitor.ui -> org.eclipse.wst.monitor.ui<br/>
- com.ibm.wtp.webbrowser -> org.eclipse.wst.webbrowser</td>
- <td>Renaming for open source</td>
- <td></td>
- <td></td>
-</tr>
-<tr>
- <td></td>
- <td></td>
- <td></td>
- <td></td>
-</tr>
-</table>
-
-
-<table border="0" cellpadding="2" cellspacing="5" width="100%">
- <tbody><tr>
- <td colspan="2" align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">M2 Changes</font></b></td>
- </tr></tbody>
-</table>
-
-This document contains information on the Server Tools API changes that have gone into M2.
-
-<p/>
-
-<table border=1 cellspacing="0">
-<tr>
- <th>Change</th>
- <th>Reason</th>
- <th>Old Code</th>
- <th>New Code</th>
-</tr>
-<tr>
- <td>All java.util.Lists returned from methods have been changed to arrays of the corresponding
- content type.</td>
- <td>Stronger typed return values are safer, and returning a copy of the list (instead of the list
- itself) blocks against clients modifying internal data structures.</td>
- <td class="code">List list = ServerCore.getRuntimeTypes();</td>
- <td class="code">IRuntimeType[] rt = ServerCore.getRuntimeTypes();</td>
-</tr>
-<tr>
- <td>IResourceManager has been removed. Most of it's methods have been moved to the ServerCore
- class, with the remaining ones in ServerUtil.</td>
- <td>There was no client benefit of the resource manager, and it was misnamed.</td>
- <td class="code">ServerCore.getResourceManager().getServers();</td>
- <td class="code">ServerCore.getServers();</td>
-</tr>
-<tr>
- <td>All extension point interfaces have been changed to abstract classes, and the "I" removed
- from the name.</td>
- <td>Allows for future support and maintenance without breaking existing interfaces.</td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-<tr>
- <td>Several interfaces were moved from the .core.model package to .core.</td>
- <td>The .core.model package was meant for SPIs, not API. All API classes & interfaces will
- be moved or remain in .core so that API users do not need to use the .core.model package.</td>
- <td class="code">import org.eclipse.wst.server.code.model.IModule;</td>
- <td class="code">import org.eclipse.wst.server.code.IModule;</td>
-</tr>
-<tr>
- <td>IServerResourceListener renamed to IServerLifecycleListener. Several methods moved out to
- new IRuntimeListener and IServerConfigurationListener interfaces.</td>
- <td>"Resource" had to be removed from the name, and the interface contained methods for
- runtimes and server configurations as well. They are split up so that API users do not
- need to listen for all types of changes from a single interface.</td>
- <td class="code">ServerCore.getResourceManager().addServerResourceListener(myListener);</td>
- <td class="code">ServerCore.addRuntimeLifecycleListener(myListener);</td>
-</tr>
-<tr>
- <td>Publishing interfaces completely rewritten & .core.resources package removed.</td>
- <td>The publishing interface was outdated and written before the Eclipse team support,
- ANT, or other recent publishing methods had been developed. The new API allows for
- better support and for each server type to use it's own publishing mechanism.</td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-<tr>
- <td>IRuntimeDelegate and IRuntimeWorkingCopyDelegate merged into a single RuntimeDelegate.
- IServerDelegate and IServerWorkingCopyDelegate reworked into
- ServerDelegate and ServerBehaviourDelegate.</td>
- <td>Making clients provide two separate classes for the delegates was excessive,
- unnecessary, and ended up with too many SPI classes. Only a single delegate class is
- now required for these extension points.</td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-<tr>
- <td>IRuntime.getDelegate(), IRuntime.getWorkingCopyDelegate() changed into IRuntime extending
- IAdaptable. Similar for IServer and other delegates</td>
- <td>IAdaptable is a common Eclipse mechanism, and allows for other extension as well. Clients
- should still remember that calling this method may involve plugin loading, so it should
- not be used in popup menus, etc.</td>
- <td class="code">ITomcatRuntime tr = (ITomcatRuntime) runtime.getDelegate();</td>
- <td class="code">ITomcatRuntime tr = (ITomcatRuntime) runtime.getAdapter(ITomcatRuntime.class);</td>
-</tr>
-<tr>
- <td>IModuleType and IModuleKind interfaces merged.</td>
- <td>IModuleKind was created late in the previous release cycle and couldn't be merged at the
- time it was created.</td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-<tr>
- <td>IServerTask changed and IModuleTask removed.</td>
- <td>The existing interfaces had an ITask directly returned as a delegate, and only allowed a
- single task per extension point. The new IServerTask allows the delegate to return multiple
- tasks from a single extension point, and it is not itself a task.</td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-<tr>
- <td>IServerConfiguration, IServerConfiguration, etc. removed</td>
- <td>The server config was a relic and did not need to be a first class resource. ServerDelegates
- are now directly responsible for maintaining the configuration.</td>
- <td class="code"></td>
- <td class="code">see Tomcat implementation</td>
-</tr>
-<tr>
- <td>Various minor cleanup - methods renamed, parameters changed, etc.</td>
- <td>Cleanup and future maintenance.</td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-<tr>
- <td>IModuleObjectAdapter -> IModuleArtifactAdapter, IModuleObject -> IModuleArtifact</td>
- <td>Object was too generic and didn't have any real meaning. Artifact represents what the
- IModuleObject really represents - resources within a module</td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-<tr>
- <td>getServerType(String id) -> findServerType(String id)</td>
- <td>Lookup methods on ServerCore and ServerUtil renamed to be more accurate to what
- they do.</td>
- <td class="code">IServerType st = getServerType("com.x")</td>
- <td class="code">IServerType st = findServerType("com.x")</td>
-</tr>
-<tr>
- <td>Lots of methods & interfaces moved to internal packages</td>
- <td>Need to trim down the exposed API to only what is required for ongoing maintenance. If
- there is anything in an internal package that you were previously using, or plan to use
- in the future, please contact me and we'll work out an API solution</td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-<tr>
- <td>Publishing changes - several interfaces and the org.eclipse.wst.server.core.resource
- package removed</td>
- <td>The old publishing mechanism did not allow flexibility in publishing options (e.g.
- ANT, Eclipse team support, or some other mechanism) and used an outdated publishing
- manager framework.</td>
- <td class="code"></td>
- <td class="code">ServerDelegate.publishStart(); // Called to tell the server that publishing is starting.
- Can be used to connect to a remote server, etc.<br/>
- ServerDelegate.publishStart(); // Called once to allow the server to publish any "global"
- resources or a server config<br/>
- ServerDelegate.publishStart(); // Called for each module to give the server a chance
- to publish using any method it wants<br/>
- ServerDelegate.publishFinish(); // Called to disconnect from the server or cleanup</td>
-</tr>
-<tr>
- <td>IMonitorableServer merged with IServer</td>
- <td>No need for </td>
- <td class="code">IServerDelegate delegate = server.getDelegate()<br/>
- if (delegate instanceof IMonitorableServer) {<br/>
- IMonitorableServer ms = (IMonitorableServer) delegate;<br/>
- List ports = ms.getServerPorts();<br/>
- }</td>
- <td class="code">IServerPort[] ports = server.getServerPorts();</td>
-</tr>
-<tr>
- <td>Working copy changes</td>
- <td>Previously, references were kept to every working copy, and clients had to save() or
- release() them in finally blocks or else the reference would be dangling (and possibly
- blocking other changes) forever. This code was unsafe and caused problems if a client
- tried to use a working copy after it had been saved or released.
- Now, clients can create a working copy at any time, and references are not kept. On
- save, a client can specify whether the working copy changes should be forced, or not
- (in which case the save will fail if someone else has made changes to the object in
- the meantime). If the changes do not need to be saved, clients can just drop the
- reference to the working copy at any time. As before, working copies should not be
- used for long periods of time since it increases the chances that another client has
- made changes</td>
- <td class="code">IServerWorkingCopy wc = IServer.getWorkingCopy();<br/>
- // do something with wc<br/>
- wc.save(); or wc.release();</td>
- <td class="code">IServerWorkingCopy wc = IServer.createWorkingCopy();<br/>
- // do something with wc<br/>
- wc.save(); or lose reference</td>
-</tr>
-<tr>
- <td>Change IServer.isRestartNeeded() to match other methods</td>
- <td></td>
- <td class="code">IServer.isRestartNeeded();</td>
- <td class="code">IServer.getServerRestartState();</td>
-</tr>
-<tr>
- <td></td>
- <td></td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-</table>
-
-</body>
-</html>
\ No newline at end of file
diff --git a/development/miscdocuments/Server Tools Package Renames.properties b/development/miscdocuments/Server Tools Package Renames.properties
deleted file mode 100644
index 8fb5668..0000000
--- a/development/miscdocuments/Server Tools Package Renames.properties
+++ /dev/null
@@ -1,10 +0,0 @@
-com.ibm.wtp.server.core=org.eclipse.wst.server.core
-com.ibm.wtp.server.ui=org.eclipse.wst.server.ui
-com.ibm.wtp.server.util=org.eclipse.wst.server.util
-com.ibm.wtp.server.java.core=org.eclipse.jst.server.core
-com.ibm.wtp.server.java.ui=org.eclipse.jst.server.ui
-com.ibm.wtp.server.tomcat.core=org.eclipse.jst.server.tomcat.core
-com.ibm.wtp.server.tomcat.ui=org.eclipse.jst.server.tomcat.ui
-com.ibm.wtp.monitor.core=org.eclipse.wst.monitor.core
-com.ibm.wtp.monitor.ui=org.eclipse.wst.monitor.ui
-com.ibm.wtp.webbrowser=org.eclipse.wst.webbrowser
\ No newline at end of file
diff --git a/development/miscdocuments/ServerToolsUseCases.html b/development/miscdocuments/ServerToolsUseCases.html
deleted file mode 100644
index 4b81287..0000000
--- a/development/miscdocuments/ServerToolsUseCases.html
+++ /dev/null
@@ -1,325 +0,0 @@
-<!DOCTYPE html PUBLIC "-//w3c//dtd html 4.0 transitional//en">
-<html><head>
-<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
-
-<link rel="stylesheet" href="http://www.eclipse.org/default_style.css" type="text/css">
-</head>
-
-
-
-<body alink="#ff0000" bgcolor="#ffffff" link="#0000ee" text="#000000" vlink="#551a8b">
-
-<table border="0" cellpadding="2" cellspacing="5" width="100%">
-
- <tbody><tr>
-
- <TD WIDTH=60%>
- <P ALIGN=LEFT><B><FONT SIZE=6><FONT FACE="Verdana, Arial, Helvetica, sans-serif">Server Tools Use Cases</FONT></FONT></B><BR><FONT SIZE=1><FONT FACE="Arial, Helvetica, sans-serif"><FONT COLOR="#8080ff">the
- Server Tools Use Cases</FONT></FONT></FONT>
- </P>
- </TD>
-
-
-</td>
-
-<!-- <td width="19%" rowspan="2"><img src="images/Idea.jpg" height=86 width=120></td> -->
-
- <td rowspan="2" width="19%"><img src="http://www.eclipse.org/images/Idea.jpg" border="0" height="86" width="120"></td>
-
- </tr>
-
-
-</tbody></table>
-
-<table border="0" cellpadding="2" cellspacing="5" width="100%">
-
- <tbody><tr>
-
- <td colspan="2" align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">Principles</font></b></td>
-
- </tr>
-<tr>
-<td>
-<p>The purpose of this document is to list explicit use cases for the server tools component. These uses cases can be used to both help guide design (to make sure minimal API is sufficient to support these listed, and only these listed, use cases) and to help guide testing (both unit tests, and milestone/release testing).</p>
- <P><B>Principle:</B> We'll consider starting point naive end users who
- know nothing of servers, and they don't care, just want one installed
- installed so they can focus on their web development. We'll consider
- three levels: 1) User does near nothing, 2) user doesn't do much, but
- may have to provide some configuration values and/or import
- configuration values. 3) User has to provide many configuration
- values, and in the worst cases, actually write ant scripts.</P>
- <p><b>Principle:</b> In addition to "end user" use cases,
-we'll specify "client code" uses-case that may
-simply be specifying details of function needed for end-user use cases, but
-will always have a unit test associated with it. Also, we'll specify "service provider"
-use cases which can be used to define SPI's. </p>
-</td>
-</tr>
-<tr>
- <td colspan="2" align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">End User Use Cases</font></b></td>
- </tr>
- <tr>
- <td>
- <table width="95%" border="1" cellpadding="1" cellspacing="1">
- <tbody>
- <tr>
- <th style="width: 108px">Name</th>
- <th style="width: 60px">Priority</th>
- <th style="width: 360px">Description</th>
- </tr>
- <tr>
- <td>Install a Server</td>
- <td>2</td>
- <td>From an update site, user can install a
- server (using Eclipse standard update manager functions).</td>
- </tr>
- <tr>
- <td>Configure a Jakarta-tomcat</td>
- <td>1</td>
- <td>Given a Jakarta-tomcat server (V5) installed
- on local file system, user can "install" a server to WTP by
- selecting from a list of available server adapters, selecting the one
- for Jakarta-tomcat server, and specifying location of server's
- install directory.
- <table border="1">
- <tbody>
- <tr>
- <td>Variant 1</td>
- <td style="width: 277px">JBoss Server instead</td>
- </tr>
- </tbody>
- </table>
- </td>
- </tr>
-
- <tr>
- <td>Export ANT build scripts for modules</td>
- <td>1</td>
- <td>User exports ANT build script that compiles and packages a module in for use outside the Eclipse, possibly for automated builds. </td>
- </tr>
- <tr>
- <td>Drag a module/artifact to a server to publish it</td>
- <td>3</td>
- <td>Users drags a module or a artifact in it into a server, which would mean the same action as "Run on Server" .</td>
- </tr>
-
- <tr>
- <td>run on J2EE server</td>
- <td>1</td>
- <td>user can select a JSP and "run on
- server", meaning it will be displayed in Eclipse web browser.
- <table border="1">
- <tbody>
- <tr>
- <td style="width: 66px">Variant 1</td>
- <td style="width: 348px">If no more than one installed, the user
- will not get list to select from</td>
- </tr>
- </tbody>
- </table>
- <table border="1">
- <tbody>
- <tr>
- <td style="width: 69px">Variant 2</td>
- <td style="width: 345px">If none installed, the user will be given
- a chance to select and install one (see Install a Server)</td>
- </tr>
- </tbody>
- </table>
- <table border="1">
- <tbody>
- <tr>
- <td style="width: 65px">Variant 3</td>
- <td style="width: 349px">If more than one installed, user given
- the list</td>
- </tr>
- </tbody>
- </table>
- </td>
- </tr>
- <TR>
- <TD>run on HTTP server</TD>
- <TD></TD>
- <TD>User can select an HTML file, and "run on server". This use case can be performed with WST only. (This use case has not gotten a lot of discussion, but support for "static projects" is mentioned in WTP/WST vision statement, and is a good case to make sure the architecture and design is correct). </TD>
- </TR>
-
- <tr>
- <td>Adapt to existing project/module layout<i>(I am not sure, this is may be a use case for project layout)</i></td>
- <td>1</td>
- <td>User describes the current project layout even if it is not a known layout of any kind. </td>
- </tr>
-
- <tr>
- <td>Add runtime</td>
- <td>1</td>
- <td>Add a new server runtime environment that exists on the user's machine. (Pick runtime from list. Enter name, location. Enter runtime specific information.)</td>
- </tr>
-
- <tr>
- <td>Edit or remove runtime</td>
- <td>1</td>
- <td>Modify runtime attributes or remove.</td>
- </tr>
-
- <tr>
- <td>Target project</td>
- <td>1</td>
- <td>Target a project to a specific runtime. This is optional and a project may only be targetted to one runtime at a time. (Some project types do
- not need a target, some projects do need a target)</td>
- </tr>
-
- <tr>
- <td>Add server</td>
- <td>1</td>
- <td>Add (install) a new server. Enter name & hostname, pick a server type from a list, and enter server specific information. (Some server types may only support local, not remote. Some local servers may require a runtime.)</td>
- </tr>
-
- <tr>
- <td>Edit or remove server</td>
- <td>1</td>
- <td>Modify server attributes or remove.</td>
- </tr>
-
- <tr>
- <td>Start/Stop/Restart</td>
- <td>1</td>
- <td>Each server type may support some/all/none of these state changes. Each server type has an initial state (may be unknown), and must keep the state in sync once it is loaded.
- Some of the state changes (start/stop) are not available unless the server is in the correct state. Console/Debug view, etc. should be sync'ed up or used as it makes sense
- for the server type. Starting may be done in the regular Eclipse launch modes, e.g. Run, Debug, Profile, ... depending on what the server supports. Launch Configurations are
- created and used as applicable.</td>
- </tr>
-
- <tr>
- <td>Add project</td>
- <td>1</td>
- <td>Add a module to a server. User is presented with a list of modules that are available to be added to the server, as well as a list of modules from the workspace that are
- already on the server. In some cases, the server may present additional modules in the second list that are not from the workspace/user. User can move modules around and
- when they are done, the module is configured on (and possibly published to) the server.</td>
- </tr>
-
- <tr>
- <td>Remove project</td>
- <td>1</td>
- <td>Same as above</td>
- </tr>
-
- <tr>
- <td>Publish/Sync</td>
- <td>1</td>
- <td>One way publish of all modules to a particular server. Syncs the module content - could be a delta or a full refresh depending on the implementation.</td>
- </tr>
-
- <tr>
- <td>Restart module</td>
- <td>1</td>
- <td>Optional based on server type support. Restart/refresh/remove cache for a particular module on the server to allow the newly published content to be served.</td>
- </tr>
-
- <tr>
- <td>Change notification</td>
- <td>1</td>
- <td>User makes a change to a module (e.g. edit a file). User should be notified of the impact to any running servers and what they need to do to get the change
- propogated to the server. (e.g. nothing, republish, restart module, restart server) </td>
- </tr>
-
- <tr>
- <td>Auto update</td>
- <td>2</td>
- <td>Automatically or via a single click, do the above use case to keep server in sync at all times.</td>
- </tr>
-
- <tr>
- <td>Run/Debug/Profile on Server</td>
- <td>1</td>
- <td>From any artifact (UI selection, editor input, etc.), determine which module it belongs to, prompt to choose or create a server if necessary, publish/sync the module on the server, and display an
- appropriate client to access (run) that artifact on the server.</td>
- </tr>
-
-<!-- <tr>
- <td></td>
- <td>1</td>
- <td></td>
- </tr>-->
-
- </tbody>
-</table>
-</td></tr>
-
-<tr>
- <td colspan="2" align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">API Use Cases</font></b></td>
- </tr>
-
-
-<tr><td>
- <table width="95%" border="1" cellpadding="1" cellspacing="1">
- <tbody>
- <tr>
- <th style="width: 108px">Name</th>
- <th style="width: 60px">Priority</th>
- <th style="width: 360px">Description</th>
- </tr>
-
- <tr>
- <td>Create module type(s)</td>
- <td>1</td>
- <td>Define a new type of module (interface and id) so that other SPI providers can provide instances of these module or servers that support them.</td>
- </tr>
-
- <tr>
- <td>Provide module factory</td>
- <td>1</td>
- <td>Define a new module factory for creating/discovering the modules of an existing type. (.modules file?)</td>
- </tr>
-
- <tr>
- <td>Define runtime type</td>
- <td>1</td>
- <td>Define a new runtime type, along with the module types that it supports. Define what it means to target a project to this runtime.</td>
- </tr>
-
- <tr>
- <td>Define server type</td>
- <td>1</td>
- <td>Define a new server type, along with the module types this it supports. Provide implementations for add/remove modules, publishing, start/stop, etc.</td>
- </tr>
-
- <tr>
- <td>get list of server adapters</td>
- <td>1</td>
- <td>programmatically get list of known
- Jakarta-tomcat servers adapters and their associated information
- (name, version, whether installed or not, etc)</td>
- </tr>
- <tr>
- <td>get list of installed servers</td>
- <td>1</td>
- <td>programmatically get list of installed
- servers and their associated information (name, etc)</td>
- </tr>
- <tr>
- <td>import/export server configuration</td>
- <td>2</td>
- <td>Can import or export server configuration
- files, such as to give to another member of team. This file may best
- be in XML format.</td>
- </tr>
- <tr>
- <td>Server Providers can provide discoverable adapter</td>
- <td>1 - SPI</td>
- <td>The information needed to be listed as potential server adapter can be found completely in plugin.xml (not Java code, which would require activation of plugin). </td>
- </tr>
-
- <tr>
- <td>Provide classloader behavior</td>
- <td>1</td>
- <td>A client, a jsp/ejb compiler for example, learns the classloader behavior to mimic the server runtime environment</td>
- </tr>
-
- </tbody>
-</table>
- </td>
-</tr>
-</tbody></table>
-
-
-</body></html>
\ No newline at end of file
diff --git "a/development/miscdocuments/WTP Flex project discussion\050Chuck\051.doc" "b/development/miscdocuments/WTP Flex project discussion\050Chuck\051.doc"
deleted file mode 100644
index 29e8610..0000000
--- "a/development/miscdocuments/WTP Flex project discussion\050Chuck\051.doc"
+++ /dev/null
Binary files differ
diff --git a/development/miscdocuments/WTP Server Core APIs.ppt b/development/miscdocuments/WTP Server Core APIs.ppt
deleted file mode 100644
index 6b1279a..0000000
--- a/development/miscdocuments/WTP Server Core APIs.ppt
+++ /dev/null
Binary files differ
diff --git a/development/miscdocuments/modules_and_servers.html b/development/miscdocuments/modules_and_servers.html
deleted file mode 100644
index d42b563..0000000
--- a/development/miscdocuments/modules_and_servers.html
+++ /dev/null
@@ -1,325 +0,0 @@
-<!-- saved from url=(0022)http://internet.e-mail -->
-<html>
-
-<head>
-<meta http-equiv="Content-Language" content="en-us">
-<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
-<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
-<meta name="ProgId" content="FrontPage.Editor.Document">
-<title>Modules and Servers</title>
-</head>
-
-<body>
-
-<h1>WTP Server Tools API<br>
-Modules and Servers</h1>
-<p>Last modified Nov. 3, 2004</p>
-<p>These design notes grew out of discussions between Jim des Rivieres and Tim
-Deboer the week of Oct. 25-27. The question is how to think of the
-"modules" as they appear in the Server Core API, and how best to allow
-for flexible modules layouts in the workspace.</p>
-<h2>Who owns the notion of module?</h2>
-<p>A module consists of some content - typically some files in the workspace.
-Each different module type will have its own rules for the structure and meaning
-of its content. For example, a simple web module might consist of a simple tree
-of HTML files. When the module is published to a server, these files will be
-copied to the real server.</p>
-<p>However, it's funny to think of the module as something that exists solely
-for the purpose of being published. A module in the workspace should be viewed
-as something rich and multi-faceted. Most of the interesting aspects of a module
-will be left up to the parties that actually defines real modules. It's like the
-difference between the notions of employee and person. An employee is a limited
-notion suitable for the limited purposes of describing an organization or a
-payroll; a person is a more general notion.</p>
-<p>As discussed in the JST content, there needs to flexibility on how J2EE
-modules get laid out in the workspace. The complexities include:</p>
-<ol>
- <li>Single or multiple modules per workspace project.</li>
- <li>Files, like Java source code, that are ordinarily considered part of that
- module's content, but not for the purposes of publishing to the server.</li>
- <li>Modules with files residing in JAR archives rather than directly in the
- file system.</li>
- <li>J2EE parent-child relationships between modules that may or may not be
- represented with directory containment.</li>
-</ol>
-<p>Given the high degree of variability (and current uncertainty) on the module
-side, one effective strategy is to separate module-related concerns as much as
-possible from the server-related concerns, and to place only minimal
-requirements what the module side needs to be like.</p>
-<p>In other words, the Server Core API should only attempt to capture a limited
-notion of module-as-something-to-publish. (IPublishableModule would be a more
-suggestive name than the current IModule.)</p>
-<h2>What does a server need to know about a module?</h2>
-<p>Here are the high-level API operations that involve both modules and servers:</p>
-<ul>
- <li>Associating a module with a server
- <ul>
- <li>Add a module to a server.</li>
- <li>Remove a module from a server.</li>
- <li>Obtain a list of modules associated with a server.</li>
- </ul>
- </li>
- <li>Publishing a module to a server
- <ul>
- <li>A server publishes the content of one of its modules to the real
- server.</li>
- </ul>
- </li>
- <li>Monitoring sync of module contents
- <ul>
- <li>A server determines whether the content of one of its modules is in
- sync.</li>
- <li>A server registers interest in being notified of future changes to the
- contents of one of its modules.</li>
- </ul>
- </li>
-</ul>
-<p>The first group of operations for managing associations between modules and
-servers could, in principle, be done using module ids alone; the actual modules
-content (or even the module's existence) need not enter into it; the
-implementation of these operations can be entirely generic. In practice, there
-are additional validation checks that would be server-type-specific. The add
-operations is necessarily initiated by a client in possession of both a module
-and a server.</p>
-<p>The second group of operations for actual publishing a module's content
-requires discovering and accessing that content. Several things to observe:</p>
-<ul>
- <li>The code that publishes a module is server-type-specific and can be
- specialized for each particular module type that the server supports. E.g.,
- Tomcat-specific code for publishing an EJB module; JBoss-specific code for
- publishing an EJB module.</li>
- <li>The module's content can be presented to servers in a module-type-specific
- way. E.g., a a simple static web module can look like a "virtual"
- tree of HTML files; a database module could present its content as something
- suitable for databases. (The current approach uses a tree of files for
- everything.)</li>
- <li>The module-type-specific scheme could also include inter-module
- relationships where appropriate. E.g., parent-child relationships for J2EE
- module types.</li>
- <li>The module-type-specific scheme for presenting module content to servers
- can build in support for various alternatives. For example, EJB module
- content could be presented variously as a deployment descriptor plus
- "virtual" files with standard names; or as a "virtual"
- EAR file; or as a java.io.File path to an EAR file; or as a java.io.File
- directory containing an unzipped EAR.</li>
- <li>The modules contents are revealed to the server only for a limited-time
- interaction. This means that the objects are short-lived. There is no
- requirement for events to report changes to content <i>during</i> a publish
- operation.</li>
- <li>For modules that really are based on files in the workspace, the module
- contents that get presented for publication need not betray that fact.</li>
-</ul>
-<p>The third group of operations, for monitoring sync of module contents, are
-very much like the second.</p>
-<ul>
- <li>The module-type-specific scheme for presenting module content to servers
- could include a timestamp. If the server maintains an internal record of
- what is on the real server along with the timestamp, the server can
- determine whether the module contents need to be republished.</li>
- <li>For module-type-specific schemes involving files, each file could carry
- timestamp information. For some server types, this would allow just the
- subset of changed files to be recopied to the server in some cases.</li>
- <li>When the files of a module are stored in the workspace (or somewhere else
- that can be tightly monitored), it is also practical to report change events
- affecting a module to interested servers, instead of having the servers poll
- for such changes.</li>
-</ul>
-<p>Here's an API sketch (it differs in a number of way from what is currently
-released):</p>
-<ul>
- <li>Extension point for defining a new module type.
- <ul>
- <li>Define module type id, module type name.</li>
- <li>Provide interface for accessing publishable content.</li>
- </ul>
- </li>
- <li>Extension point for defining a new server type.
- <ul>
- <li>Define server type id, server type name.</li>
- <li>Give list of supported module types.</li>
- <li>Provide mechanism for publishing supported module types to real
- server. (Server-type-specific and module-type-specific, but ignorant of
- how and where module's content is actually stored.) </li>
- <li>Provide mechanism for launching and talking to real server.</li>
- </ul>
- </li>
- <li>Extension point for defining a new module factory.
- <ul>
- <li>Supply module factory id, module factory name.</li>
- <li>Give list of module types that this factory is capable of creating.</li>
- <li>Provide mechanism for creating/discovering module instances, and for
- tracking its module instances.</li>
- <li>Provide mechanism for providing publishable module content for its
- module instances. (Server-type-independent, module-type-specific, and
- cognizant of how and where a module's publishable content is actually
- stored.)</li>
- <li>Provide mechanism, where feasible, for notifying a server of changes
- affecting publishable module content for its module instances.</li>
- </ul>
- </li>
- <li>Module handle represent a unique module instance.
- <ul>
- <li>Module has a unique module id.</li>
- <li>Module has a module type (represented by a module type id - module
- types might not exist)</li>
- <li>Module has a module factory (represented by a module factory id
- - module factory might not exist). This is the module factory
- responsible for module instance.</li>
- <li>Module is just a handle (passive key). Module might not exist.</li>
- <li>Used in server API for adding/removing a module to/from a server; for
- obtaining a list of modules associated with a server; for obtaining a
- list of modules associated with a module factory.</li>
- <li>Interface is client API; clients do not implement.</li>
- <li>Implementation is internal.</li>
- <li>
- <pre>public interface IModuleHandle {
- public String getId();
- public String getModuleTypeId();
- public String getModuleFactoryId();
- }
-[somewhere on SPI where it is available to servers and module factories]
- public IModuleHandle createModuleHandle(String moduleId, String moduleTypeId, String moduleFactoryId);</pre>
- </li>
- </ul>
- </li>
- <li>Publishable module used by server for limited-purpose of publishing a
- module's contents.
- <ul>
- <li>"Marker" interface - no methods.</li>
- <li>Each module type defines its own specialized public subinterface for
- obtaining the module's content.</li>
- <li>Subinterface is API for parties supplying module factories and server
- delegates (both SPI side)</li>
- <li>Subinterface can spec whatever contract works for making the module's
- publishable content available to any type of server that wishes to
- support that module type.</li>
- <li>Module-type-specific subinterface is used by server delegate for
- publishing purposes.</li>
- <li>Module-type-specific subinterface is implemented differently by each
- module factory that can create instances of the module type.</li>
- <li>These object only needs to be useful for the limited duration of
- publishing (or resyncing).</li>
- <li>The method should not be available to other parties.</li>
- </ul>
- </li>
- <ul>
- <li>
- <pre>[somewhere available to server delegate (only)]
- public IPublishableModule resolveForPublish(IModuleHandle moduleHandle);
-public interface IPublishableModule {}</pre>
- </li>
- </ul>
- <li>Module factories are things that create and modules.
- <ul>
- <li>Client API provides global list of module factories.</li>
- <li>Each module factory can support any number of different module types.</li>
- <li>Each module factory is responsible for creating and managing a global,
- persistent, list of its module instances. (It would be even better if a
- factory could keep .)</li>
- <li>Module factory client API.</li>
- </ul>
- <ul>
- <li>
- <pre>ServerCore
- public IModuleFactory[] getModuleFactories();
-public interface IModuleFactory {
- public String getId();
- public supportsModuleType(IModuleType moduleType);
- public IModuleHandle[] getModules();
- public IModuleHandle createModule(String moduleId, String moduleTypeId, Object data);
- public void deleteModule(IModuleHandle);
- public void addModuleFactoryListener(IModuleFactoryListener);
- public void removeModuleFactoryListener(IModuleFactoryListener);
-}</pre>
- </li>
- </ul>
- <ul>
- <li>Module factory SPI.</li>
- </ul>
- </li>
- <ul>
- <li>
- <pre>public abstract class AbstractModuleFactoryDelegate {
- public AbstractModuleFactoryDelegate(IModuleFactory factory) {...}
- public final IModuleFactory getFactory() {...}
- public abstract IModuleHandle[] getModules();
- public abstract IModuleHandle createModule(String moduleId, String moduleTypeId, Object data);
- public abstract deleteModule(IModuleHandle);
- public abstract IPublishableModule resolveForPublish(IModuleHandle moduleHandle);
-}</pre>
- </li>
- </ul>
- <li>Example
- <ul>
- <li>Declaration of module type: simple static web</li>
- <li>Include module-type-specific subinterface for publishing module
- expressed as a tree of files with timestamps.</li>
- <li>
- <pre>public interface IWebModule extends IPublishableModule {
- public interface IModuleResource {
- public String getName();
- public IPath getModuleRelativePath();
- }
- public interface IModuleFile extends IModuleResource {
- public long getTimeStamp();
- public InputStream getContents();
- }
- public interface IModuleFolder extends IModuleResource {
- public IModuleResource[] members();
- }
- public IModuleResource[] members();
-}</pre>
- </li>
- <li>IWebModule is used in servers that support simple static web modules
- <ul>
- <li>Example server type: simple web server</li>
- <li>Server delegate uses resolveForPublish(moduleHandle) to get an
- IPublishableModule</li>
- <li>Downcasts IPublishableModule to IWebModule</li>
- <li>Calls methods on IWebModule to discover files comprising content.</li>
- </ul>
- </li>
- <li>IWebModule is implemented by module factories that support simple
- static web modules
- <ul>
- <li>Example module factory 1: static web modules kept in workspace
- folders
- <ul>
- <li>Publishable content lives in workspace</li>
- <li>Each module has a root folder.</li>
- <li>Files and folders under root folder are isomorphic to
- IWebModule layout.
- <ul>
- <li>All files and folders under root folder are publishable.</li>
- <li>File and folder names are as published.</li>
- <li>File contents and timestamps are as published.</li>
- </ul>
- </li>
- <li>"data" object passed to IModuleFactory.createModule
- is IContainer for module's root folder.</li>
- <li>Factory maintains global list of modules in private plug-in
- state.</li>
- </ul>
- </li>
- <li>Example module factory 2: static web modules kept in zip file
- <ul>
- <li>Publishable content lives in zip files outside workspace</li>
- <li>Each module has a single zip file.</li>
- <li>"data" object passed to IModuleFactory.createModule
- is java.io.File (or IPath) for module's zip file.</li>
- <li>Files and folders within zip file are isomorphic to IWebModule
- layout.</li>
- <li>Factory maintains global list of its modules in private
- plug-in state.</li>
- </ul>
- </li>
- </ul>
- </li>
- </ul>
- </li>
-</ul>
-<p> </p>
-
-</body>
-
-</html>
diff --git a/development/miscdocuments/projectlayout-nmd.ppt b/development/miscdocuments/projectlayout-nmd.ppt
deleted file mode 100644
index 47a28f2..0000000
--- a/development/miscdocuments/projectlayout-nmd.ppt
+++ /dev/null
Binary files differ
diff --git a/development/miscdocuments/server/Server Tools API Changes.html b/development/miscdocuments/server/Server Tools API Changes.html
deleted file mode 100644
index 6f44d8e..0000000
--- a/development/miscdocuments/server/Server Tools API Changes.html
+++ /dev/null
@@ -1,352 +0,0 @@
-<html>
-
-<head>
-<meta http-equiv="Content-Language" content="en-us">
-<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
-<link rel="stylesheet" href="http://www.eclipse.org/default_style.css" type="text/css">
-<title>Server Tools API Changes</title>
-<style>
-td { font-family: arial, helvetica, geneva; font-size: 9pt; vertical-align: top; }
-td.code { font-family: "Courier New", Courier, mono; font-size: 7.75pt}
-</style>
-</head>
-
-<body alink="#ff0000" bgcolor="#ffffff" link="#0000ee" text="#000000" vlink="#551a8b">
-
-<table border="0" cellpadding="2" cellspacing="5" width="100%">
- <tbody><tr>
- <TD WIDTH=60%>
- <P ALIGN=LEFT><B><FONT SIZE=6><FONT FACE="Verdana, Arial, Helvetica, sans-serif">Server Tools API Changes</FONT></FONT></B><BR>
- <FONT SIZE=1><FONT FACE="Arial, Helvetica, sans-serif"><FONT COLOR="#8080ff">Information on Server Tools API Changes</FONT></FONT></FONT>
- </P>
- </TD>
- <td rowspan="2" width="19%"><img src="http://www.eclipse.org/images/Idea.jpg" border="0" height="86" width="120"></td>
- </tr>
-</tbody></table>
-
-
-<table border="0" cellpadding="2" cellspacing="5" width="100%">
- <tbody><tr>
- <td colspan="2" align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">M1 Changes</font></b></td>
- </tr></tbody>
-</table>
-
-Here are the Server Tools API changes that went into M1.
-
-<p/>
-
-<table border=1 cellspacing="0">
-<tr>
- <th>Change</th>
- <th>Reason</th>
- <th>Old Code</th>
- <th>New Code</th>
-</tr>
-<tr>
- <td>Package renames:<br/>
- com.ibm.wtp.server.core -> org.eclipse.wst.server.core<br/>
- com.ibm.wtp.server.ui -> org.eclipse.wst.server.ui<br/>
- com.ibm.wtp.server.util -> org.eclipse.wst.server.util<br/>
- com.ibm.wtp.server.java.core -> org.eclipse.jst.server.core<br/>
- com.ibm.wtp.server.java.ui -> org.eclipse.jst.server.ui<br/>
- com.ibm.wtp.server.tomcat.core -> org.eclipse.jst.server.tomcat.core<br/>
- com.ibm.wtp.server.tomcat.ui -> org.eclipse.jst.server.tomcat.ui<br/>
- com.ibm.wtp.monitor.core -> org.eclipse.wst.monitor.core<br/>
- com.ibm.wtp.monitor.ui -> org.eclipse.wst.monitor.ui<br/>
- com.ibm.wtp.webbrowser -> org.eclipse.wst.webbrowser</td>
- <td>Renaming for open source</td>
- <td></td>
- <td></td>
-</tr>
-<tr>
- <td></td>
- <td></td>
- <td></td>
- <td></td>
-</tr>
-</table>
-
-
-
-
-<table border="0" cellpadding="2" cellspacing="5" width="100%">
- <tbody><tr>
- <td colspan="2" align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">M2 Changes</font></b></td>
- </tr></tbody>
-</table>
-
-Here are the Server Tools API changes that went into M2.
-
-<p/>
-
-<table border=1 cellspacing="0">
-<tr>
- <th>Change</th>
- <th>Reason</th>
- <th>Old Code</th>
- <th>New Code</th>
-</tr>
-<tr>
- <td>All java.util.Lists returned from methods have been changed to arrays of the corresponding
- content type.</td>
- <td>Stronger typed return values are safer, and returning a copy of the list (instead of the list
- itself) blocks against clients modifying internal data structures.</td>
- <td class="code">List list = ServerCore.getRuntimeTypes();</td>
- <td class="code">IRuntimeType[] rt = ServerCore.getRuntimeTypes();</td>
-</tr>
-<tr>
- <td>IResourceManager has been removed. Most of it's methods have been moved to the ServerCore
- class, with the remaining ones in ServerUtil.</td>
- <td>There was no client benefit of the resource manager, and it was misnamed.</td>
- <td class="code">ServerCore.getResourceManager().getServers();</td>
- <td class="code">ServerCore.getServers();</td>
-</tr>
-<tr>
- <td>All extension point interfaces have been changed to abstract classes, and the "I" removed
- from the name.</td>
- <td>Allows for future support and maintenance without breaking existing interfaces.</td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-<tr>
- <td>Several interfaces were moved from the .core.model package to .core.</td>
- <td>The .core.model package was meant for SPIs, not API. All API classes & interfaces will
- be moved or remain in .core so that API users do not need to use the .core.model package.</td>
- <td class="code">import org.eclipse.wst.server.code.model.IModule;</td>
- <td class="code">import org.eclipse.wst.server.code.IModule;</td>
-</tr>
-<tr>
- <td>IServerResourceListener renamed to IServerLifecycleListener. Several methods moved out to
- new IRuntimeListener and IServerConfigurationListener interfaces.</td>
- <td>"Resource" had to be removed from the name, and the interface contained methods for
- runtimes and server configurations as well. They are split up so that API users do not
- need to listen for all types of changes from a single interface.</td>
- <td class="code">ServerCore.getResourceManager().addServerResourceListener(myListener);</td>
- <td class="code">ServerCore.addRuntimeLifecycleListener(myListener);</td>
-</tr>
-<tr>
- <td>Publishing interfaces completely rewritten & .core.resources package removed.</td>
- <td>The publishing interface was outdated and written before the Eclipse team support,
- ANT, or other recent publishing methods had been developed. The new API allows for
- better support and for each server type to use it's own publishing mechanism.</td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-<tr>
- <td>IRuntimeDelegate and IRuntimeWorkingCopyDelegate merged into a single RuntimeDelegate.
- IServerDelegate and IServerWorkingCopyDelegate reworked into
- ServerDelegate and ServerBehaviourDelegate.</td>
- <td>Making clients provide two separate classes for the delegates was excessive,
- unnecessary, and ended up with too many SPI classes. Only a single delegate class is
- now required for these extension points.</td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-<tr>
- <td>IRuntime.getDelegate(), IRuntime.getWorkingCopyDelegate() changed into IRuntime extending
- IAdaptable. Similar for IServer and other delegates</td>
- <td>IAdaptable is a common Eclipse mechanism, and allows for other extension as well. Clients
- should still remember that calling this method may involve plugin loading, so it should
- not be used in popup menus, etc.</td>
- <td class="code">ITomcatRuntime tr = (ITomcatRuntime) runtime.getDelegate();</td>
- <td class="code">ITomcatRuntime tr = (ITomcatRuntime) runtime.getAdapter(ITomcatRuntime.class);</td>
-</tr>
-<tr>
- <td>IModuleType and IModuleKind interfaces merged.</td>
- <td>IModuleKind was created late in the previous release cycle and couldn't be merged at the
- time it was created.</td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-<tr>
- <td>IServerTask changed and IModuleTask removed.</td>
- <td>The existing interfaces had an ITask directly returned as a delegate, and only allowed a
- single task per extension point. The new IServerTask allows the delegate to return multiple
- tasks from a single extension point, and it is not itself a task.</td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-<tr>
- <td>IServerConfiguration, IServerConfiguration, etc. removed</td>
- <td>The server config was a relic and did not need to be a first class resource. ServerDelegates
- are now directly responsible for maintaining the configuration.</td>
- <td class="code"></td>
- <td class="code">see Tomcat implementation</td>
-</tr>
-<tr>
- <td>Various minor cleanup - methods renamed, parameters changed, etc.</td>
- <td>Cleanup and future maintenance.</td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-<tr>
- <td>IModuleObjectAdapter -> IModuleArtifactAdapter, IModuleObject -> IModuleArtifact</td>
- <td>Object was too generic and didn't have any real meaning. Artifact represents what the
- IModuleObject really represents - resources within a module</td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-<tr>
- <td>getServerType(String id) -> findServerType(String id)</td>
- <td>Lookup methods on ServerCore and ServerUtil renamed to be more accurate to what
- they do.</td>
- <td class="code">IServerType st = getServerType("com.x")</td>
- <td class="code">IServerType st = findServerType("com.x")</td>
-</tr>
-<tr>
- <td>Lots of methods & interfaces moved to internal packages</td>
- <td>Need to trim down the exposed API to only what is required for ongoing maintenance. If
- there is anything in an internal package that you were previously using, or plan to use
- in the future, please contact me and we'll work out an API solution</td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-<tr>
- <td>Publishing changes - several interfaces and the org.eclipse.wst.server.core.resource
- package removed</td>
- <td>The old publishing mechanism did not allow flexibility in publishing options (e.g.
- ANT, Eclipse team support, or some other mechanism) and used an outdated publishing
- manager framework.</td>
- <td class="code"></td>
- <td class="code">ServerDelegate.publishStart(); // Called to tell the server that publishing is starting.
- Can be used to connect to a remote server, etc.<br/>
- ServerDelegate.publishStart(); // Called once to allow the server to publish any "global"
- resources or a server config<br/>
- ServerDelegate.publishStart(); // Called for each module to give the server a chance
- to publish using any method it wants<br/>
- ServerDelegate.publishFinish(); // Called to disconnect from the server or cleanup</td>
-</tr>
-<tr>
- <td>IMonitorableServer merged with IServer</td>
- <td>No need for additional interface</td>
- <td class="code">IServerDelegate delegate = server.getDelegate()<br/>
- if (delegate instanceof IMonitorableServer) {<br/>
- IMonitorableServer ms = (IMonitorableServer) delegate;<br/>
- List ports = ms.getServerPorts();<br/>
- }</td>
- <td class="code">IServerPort[] ports = server.getServerPorts();</td>
-</tr>
-<tr>
- <td>Working copy changes</td>
- <td>Previously, references were kept to every working copy, and clients had to save() or
- release() them in finally blocks or else the reference would be dangling (and possibly
- blocking other changes) forever. This code was unsafe and caused problems if a client
- tried to use a working copy after it had been saved or released.
- Now, clients can create a working copy at any time, and references are not kept. On
- save, a client can specify whether the working copy changes should be forced, or not
- (in which case the save will fail if someone else has made changes to the object in
- the meantime). If the changes do not need to be saved, clients can just drop the
- reference to the working copy at any time. As before, working copies should not be
- used for long periods of time since it increases the chances that another client has
- made changes</td>
- <td class="code">IServerWorkingCopy wc = IServer.getWorkingCopy();<br/>
- // do something with wc<br/>
- wc.save(); or wc.release();</td>
- <td class="code">IServerWorkingCopy wc = IServer.createWorkingCopy();<br/>
- // do something with wc<br/>
- wc.save(); or lose reference</td>
-</tr>
-<tr>
- <td>Change IServer.isRestartNeeded() to match other methods</td>
- <td></td>
- <td class="code">IServer.isRestartNeeded();</td>
- <td class="code">IServer.getServerRestartState();</td>
-</tr>
-<tr>
- <td></td>
- <td></td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-</table>
-
-
-
-<table border="0" cellpadding="2" cellspacing="5" width="100%">
- <tbody><tr>
- <td colspan="2" align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">M3 Changes</font></b></td>
- </tr></tbody>
-</table>
-
-Here are the Server Tools API changes that went into M3.
-
-<p/>
-
-<table border=1 cellspacing="0">
-<tr>
- <th>Change</th>
- <th>Reason</th>
- <th>Old Code</th>
- <th>New Code</th>
-</tr>
-<tr>
- <td>Remove serverAction extension point</td>
- <td>Duplicate function exists in Eclipse v3.0</td>
- <td class="code"><extension point="org.eclipse.wst.server.ui.serverActions"><br/>
- <serverAction id="org.eclipse.wst.server.ui.projects"<br/>
- typeIds="org.eclipse.jst.*"<br/>
- label="%actionModifyModules"<br/>
- category="control"<br/>
- icon="icons/ctool16/wiz_modify_modules.gif"<br/>
- order="50"<br/>
- class="org.eclipse.wst.server.ui.internal.actions.AddRemoveModulesAction"/><br/>
-</extension></td>
- <td class="code"><extension point="org.eclipse.ui.popupMenus"><br/>
- <objectContribution<br/>
- id="org.eclipse.wst.server.ui.popupMenu"<br/>
- objectClass="org.eclipse.wst.server.core.IServer"<br/>
- adaptable="true"><br/>
- <filter name="typeIds" value="org.eclipse.jst.*"/><br/>
- <action<br/>
- id="org.eclipse.wst.server.ui.action.modifyModules"<br/>
- label="%actionModifyModules"<br/>
- icon="icons/ctool16/wiz_modify_modules.gif"<br/>
- class="org.eclipse.wst.server.ui.internal.actions.ModifyModulesAction"><br/>
- </action><br/>
- </objectContribution><br/>
-</extension></td>
-</tr>
-<tr>
- <td>Remove objectClass attribute from moduleArtifactAdapter extension point and switch to expressions</td>
- <td>Removal of IModuleArtifactAdapter class</td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-<tr>
- <td>IElement and IElementWorkingCopy removed</td>
- <td>There was no point having common code between IRuntime and IServer, since they didn't really have
- any common structure. Existing methods moved to correct location in IRuntime, IServer, and their working copies.</td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-<tr>
- <td>IModuleEvent and IModuleFactoryEvent changed to ModuleEvent and ModuleFactoryEvent</td>
- <td>Event classes are not typically interfaces, and there was no reason to abstract these two classes.</td>
- <td class="code">IModuleEvent<br/>IModuleFactoryEvent</td>
- <td class="code">ModuleEvent<br/>ModuleFactoryEvent</td>
-</tr>
-<tr>
- <td>IServerPreferences removed</td>
- <td>IServerPreferences was not required as API and was not being used by external plugins. To clean up API,
- it is being removed from the first API version.</td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-<tr>
- <td>ServerBehaviourDelegate.setLaunchDefaults() renamed</td>
- <td>ServerBehaviourDelegate.setLaunchDefaults() was renamed to ServerBehaviourDelegate.setupLaunchConfiguration().
- It is now called on every launch instead of just the first time. This allows servers to update the launch
- configuration before it is executed.</td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-<tr>
- <td></td>
- <td></td>
- <td class="code"></td>
- <td class="code"></td>
-</tr>
-</table>
-
-</body>
-</html>
\ No newline at end of file
diff --git a/development/miscdocuments/server/Server Tools Package Renames.properties b/development/miscdocuments/server/Server Tools Package Renames.properties
deleted file mode 100644
index 8fb5668..0000000
--- a/development/miscdocuments/server/Server Tools Package Renames.properties
+++ /dev/null
@@ -1,10 +0,0 @@
-com.ibm.wtp.server.core=org.eclipse.wst.server.core
-com.ibm.wtp.server.ui=org.eclipse.wst.server.ui
-com.ibm.wtp.server.util=org.eclipse.wst.server.util
-com.ibm.wtp.server.java.core=org.eclipse.jst.server.core
-com.ibm.wtp.server.java.ui=org.eclipse.jst.server.ui
-com.ibm.wtp.server.tomcat.core=org.eclipse.jst.server.tomcat.core
-com.ibm.wtp.server.tomcat.ui=org.eclipse.jst.server.tomcat.ui
-com.ibm.wtp.monitor.core=org.eclipse.wst.monitor.core
-com.ibm.wtp.monitor.ui=org.eclipse.wst.monitor.ui
-com.ibm.wtp.webbrowser=org.eclipse.wst.webbrowser
\ No newline at end of file
diff --git a/development/miscdocuments/server/ServerToolsUseCases.html b/development/miscdocuments/server/ServerToolsUseCases.html
deleted file mode 100644
index 4b81287..0000000
--- a/development/miscdocuments/server/ServerToolsUseCases.html
+++ /dev/null
@@ -1,325 +0,0 @@
-<!DOCTYPE html PUBLIC "-//w3c//dtd html 4.0 transitional//en">
-<html><head>
-<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
-
-<link rel="stylesheet" href="http://www.eclipse.org/default_style.css" type="text/css">
-</head>
-
-
-
-<body alink="#ff0000" bgcolor="#ffffff" link="#0000ee" text="#000000" vlink="#551a8b">
-
-<table border="0" cellpadding="2" cellspacing="5" width="100%">
-
- <tbody><tr>
-
- <TD WIDTH=60%>
- <P ALIGN=LEFT><B><FONT SIZE=6><FONT FACE="Verdana, Arial, Helvetica, sans-serif">Server Tools Use Cases</FONT></FONT></B><BR><FONT SIZE=1><FONT FACE="Arial, Helvetica, sans-serif"><FONT COLOR="#8080ff">the
- Server Tools Use Cases</FONT></FONT></FONT>
- </P>
- </TD>
-
-
-</td>
-
-<!-- <td width="19%" rowspan="2"><img src="images/Idea.jpg" height=86 width=120></td> -->
-
- <td rowspan="2" width="19%"><img src="http://www.eclipse.org/images/Idea.jpg" border="0" height="86" width="120"></td>
-
- </tr>
-
-
-</tbody></table>
-
-<table border="0" cellpadding="2" cellspacing="5" width="100%">
-
- <tbody><tr>
-
- <td colspan="2" align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">Principles</font></b></td>
-
- </tr>
-<tr>
-<td>
-<p>The purpose of this document is to list explicit use cases for the server tools component. These uses cases can be used to both help guide design (to make sure minimal API is sufficient to support these listed, and only these listed, use cases) and to help guide testing (both unit tests, and milestone/release testing).</p>
- <P><B>Principle:</B> We'll consider starting point naive end users who
- know nothing of servers, and they don't care, just want one installed
- installed so they can focus on their web development. We'll consider
- three levels: 1) User does near nothing, 2) user doesn't do much, but
- may have to provide some configuration values and/or import
- configuration values. 3) User has to provide many configuration
- values, and in the worst cases, actually write ant scripts.</P>
- <p><b>Principle:</b> In addition to "end user" use cases,
-we'll specify "client code" uses-case that may
-simply be specifying details of function needed for end-user use cases, but
-will always have a unit test associated with it. Also, we'll specify "service provider"
-use cases which can be used to define SPI's. </p>
-</td>
-</tr>
-<tr>
- <td colspan="2" align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">End User Use Cases</font></b></td>
- </tr>
- <tr>
- <td>
- <table width="95%" border="1" cellpadding="1" cellspacing="1">
- <tbody>
- <tr>
- <th style="width: 108px">Name</th>
- <th style="width: 60px">Priority</th>
- <th style="width: 360px">Description</th>
- </tr>
- <tr>
- <td>Install a Server</td>
- <td>2</td>
- <td>From an update site, user can install a
- server (using Eclipse standard update manager functions).</td>
- </tr>
- <tr>
- <td>Configure a Jakarta-tomcat</td>
- <td>1</td>
- <td>Given a Jakarta-tomcat server (V5) installed
- on local file system, user can "install" a server to WTP by
- selecting from a list of available server adapters, selecting the one
- for Jakarta-tomcat server, and specifying location of server's
- install directory.
- <table border="1">
- <tbody>
- <tr>
- <td>Variant 1</td>
- <td style="width: 277px">JBoss Server instead</td>
- </tr>
- </tbody>
- </table>
- </td>
- </tr>
-
- <tr>
- <td>Export ANT build scripts for modules</td>
- <td>1</td>
- <td>User exports ANT build script that compiles and packages a module in for use outside the Eclipse, possibly for automated builds. </td>
- </tr>
- <tr>
- <td>Drag a module/artifact to a server to publish it</td>
- <td>3</td>
- <td>Users drags a module or a artifact in it into a server, which would mean the same action as "Run on Server" .</td>
- </tr>
-
- <tr>
- <td>run on J2EE server</td>
- <td>1</td>
- <td>user can select a JSP and "run on
- server", meaning it will be displayed in Eclipse web browser.
- <table border="1">
- <tbody>
- <tr>
- <td style="width: 66px">Variant 1</td>
- <td style="width: 348px">If no more than one installed, the user
- will not get list to select from</td>
- </tr>
- </tbody>
- </table>
- <table border="1">
- <tbody>
- <tr>
- <td style="width: 69px">Variant 2</td>
- <td style="width: 345px">If none installed, the user will be given
- a chance to select and install one (see Install a Server)</td>
- </tr>
- </tbody>
- </table>
- <table border="1">
- <tbody>
- <tr>
- <td style="width: 65px">Variant 3</td>
- <td style="width: 349px">If more than one installed, user given
- the list</td>
- </tr>
- </tbody>
- </table>
- </td>
- </tr>
- <TR>
- <TD>run on HTTP server</TD>
- <TD></TD>
- <TD>User can select an HTML file, and "run on server". This use case can be performed with WST only. (This use case has not gotten a lot of discussion, but support for "static projects" is mentioned in WTP/WST vision statement, and is a good case to make sure the architecture and design is correct). </TD>
- </TR>
-
- <tr>
- <td>Adapt to existing project/module layout<i>(I am not sure, this is may be a use case for project layout)</i></td>
- <td>1</td>
- <td>User describes the current project layout even if it is not a known layout of any kind. </td>
- </tr>
-
- <tr>
- <td>Add runtime</td>
- <td>1</td>
- <td>Add a new server runtime environment that exists on the user's machine. (Pick runtime from list. Enter name, location. Enter runtime specific information.)</td>
- </tr>
-
- <tr>
- <td>Edit or remove runtime</td>
- <td>1</td>
- <td>Modify runtime attributes or remove.</td>
- </tr>
-
- <tr>
- <td>Target project</td>
- <td>1</td>
- <td>Target a project to a specific runtime. This is optional and a project may only be targetted to one runtime at a time. (Some project types do
- not need a target, some projects do need a target)</td>
- </tr>
-
- <tr>
- <td>Add server</td>
- <td>1</td>
- <td>Add (install) a new server. Enter name & hostname, pick a server type from a list, and enter server specific information. (Some server types may only support local, not remote. Some local servers may require a runtime.)</td>
- </tr>
-
- <tr>
- <td>Edit or remove server</td>
- <td>1</td>
- <td>Modify server attributes or remove.</td>
- </tr>
-
- <tr>
- <td>Start/Stop/Restart</td>
- <td>1</td>
- <td>Each server type may support some/all/none of these state changes. Each server type has an initial state (may be unknown), and must keep the state in sync once it is loaded.
- Some of the state changes (start/stop) are not available unless the server is in the correct state. Console/Debug view, etc. should be sync'ed up or used as it makes sense
- for the server type. Starting may be done in the regular Eclipse launch modes, e.g. Run, Debug, Profile, ... depending on what the server supports. Launch Configurations are
- created and used as applicable.</td>
- </tr>
-
- <tr>
- <td>Add project</td>
- <td>1</td>
- <td>Add a module to a server. User is presented with a list of modules that are available to be added to the server, as well as a list of modules from the workspace that are
- already on the server. In some cases, the server may present additional modules in the second list that are not from the workspace/user. User can move modules around and
- when they are done, the module is configured on (and possibly published to) the server.</td>
- </tr>
-
- <tr>
- <td>Remove project</td>
- <td>1</td>
- <td>Same as above</td>
- </tr>
-
- <tr>
- <td>Publish/Sync</td>
- <td>1</td>
- <td>One way publish of all modules to a particular server. Syncs the module content - could be a delta or a full refresh depending on the implementation.</td>
- </tr>
-
- <tr>
- <td>Restart module</td>
- <td>1</td>
- <td>Optional based on server type support. Restart/refresh/remove cache for a particular module on the server to allow the newly published content to be served.</td>
- </tr>
-
- <tr>
- <td>Change notification</td>
- <td>1</td>
- <td>User makes a change to a module (e.g. edit a file). User should be notified of the impact to any running servers and what they need to do to get the change
- propogated to the server. (e.g. nothing, republish, restart module, restart server) </td>
- </tr>
-
- <tr>
- <td>Auto update</td>
- <td>2</td>
- <td>Automatically or via a single click, do the above use case to keep server in sync at all times.</td>
- </tr>
-
- <tr>
- <td>Run/Debug/Profile on Server</td>
- <td>1</td>
- <td>From any artifact (UI selection, editor input, etc.), determine which module it belongs to, prompt to choose or create a server if necessary, publish/sync the module on the server, and display an
- appropriate client to access (run) that artifact on the server.</td>
- </tr>
-
-<!-- <tr>
- <td></td>
- <td>1</td>
- <td></td>
- </tr>-->
-
- </tbody>
-</table>
-</td></tr>
-
-<tr>
- <td colspan="2" align="left" bgcolor="#0080c0" valign="top"><b><font color="#ffffff" face="Arial,Helvetica">API Use Cases</font></b></td>
- </tr>
-
-
-<tr><td>
- <table width="95%" border="1" cellpadding="1" cellspacing="1">
- <tbody>
- <tr>
- <th style="width: 108px">Name</th>
- <th style="width: 60px">Priority</th>
- <th style="width: 360px">Description</th>
- </tr>
-
- <tr>
- <td>Create module type(s)</td>
- <td>1</td>
- <td>Define a new type of module (interface and id) so that other SPI providers can provide instances of these module or servers that support them.</td>
- </tr>
-
- <tr>
- <td>Provide module factory</td>
- <td>1</td>
- <td>Define a new module factory for creating/discovering the modules of an existing type. (.modules file?)</td>
- </tr>
-
- <tr>
- <td>Define runtime type</td>
- <td>1</td>
- <td>Define a new runtime type, along with the module types that it supports. Define what it means to target a project to this runtime.</td>
- </tr>
-
- <tr>
- <td>Define server type</td>
- <td>1</td>
- <td>Define a new server type, along with the module types this it supports. Provide implementations for add/remove modules, publishing, start/stop, etc.</td>
- </tr>
-
- <tr>
- <td>get list of server adapters</td>
- <td>1</td>
- <td>programmatically get list of known
- Jakarta-tomcat servers adapters and their associated information
- (name, version, whether installed or not, etc)</td>
- </tr>
- <tr>
- <td>get list of installed servers</td>
- <td>1</td>
- <td>programmatically get list of installed
- servers and their associated information (name, etc)</td>
- </tr>
- <tr>
- <td>import/export server configuration</td>
- <td>2</td>
- <td>Can import or export server configuration
- files, such as to give to another member of team. This file may best
- be in XML format.</td>
- </tr>
- <tr>
- <td>Server Providers can provide discoverable adapter</td>
- <td>1 - SPI</td>
- <td>The information needed to be listed as potential server adapter can be found completely in plugin.xml (not Java code, which would require activation of plugin). </td>
- </tr>
-
- <tr>
- <td>Provide classloader behavior</td>
- <td>1</td>
- <td>A client, a jsp/ejb compiler for example, learns the classloader behavior to mimic the server runtime environment</td>
- </tr>
-
- </tbody>
-</table>
- </td>
-</tr>
-</tbody></table>
-
-
-</body></html>
\ No newline at end of file
diff --git a/development/miscdocuments/server/WTP Server Core APIs.ppt b/development/miscdocuments/server/WTP Server Core APIs.ppt
deleted file mode 100644
index bd46f3c..0000000
--- a/development/miscdocuments/server/WTP Server Core APIs.ppt
+++ /dev/null
Binary files differ
diff --git a/development/miscdocuments/server/web_tools_server_api_concepts.html b/development/miscdocuments/server/web_tools_server_api_concepts.html
deleted file mode 100644
index 8b4b23f..0000000
--- a/development/miscdocuments/server/web_tools_server_api_concepts.html
+++ /dev/null
@@ -1,260 +0,0 @@
-<html>
-
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
-<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
-<meta name="ProgId" content="FrontPage.Editor.Document">
-<title>API Concepts and Roles</title>
-</head>
-
-<body>
-
-<h1>WTP Server Tools<br>
-API Concepts and Roles</h1>
-<p>Last modified Nov. 2, 2004</p>
-<p>[<i>This document is a work in progress. The document is an attempt to
-capture the key concepts required for understanding and working with the WTP
-Server Core API. Note that the concepts may differ subtly from what is currently
-found in the currently released <a href="http://dev.eclipse.org/viewcvs/index.cgi/wst/components/server/plugins/org.eclipse.wst.server.core/?cvsroot=WebTools_Project">org.eclipse.wst.server.core
-plug-in</a>. Once this document is finalized, our intent is to bring the code
-and specs into line with this document.]</i></p>
-<p>The key concepts for understanding the API (and SPI) are servers and modules.
-The notions of server runtimes and server configurations play an important, but
-secondary role.</p>
-<p>Not surprisingly, the notion of <b>server</b> is central in the web tools
-server infrastructure. In this context we are to understand that the server is a
-web server of some ilk (a more exact definition is not required for our
-purposes). From a tool-centric point of view, a server is something that the
-developer is writing "content" for. (In a sense, the server exists,
-but lacks useful content. The development task is to provide that content.) The
-content can include anything from simple, static HTML web pages to complex,
-highly dynamic web applications. In the course of writing and debugging this
-content, they will want to test their content on a web server, to see how it
-gets served up. For this they will need to launch a server process running on
-some host machine (often the local host on which the Eclipse IDE is running), or
-attach to a server that's already running. And we must arrange that the newly
-developed content sitting in the developer's workspace ends up in a location and
-format that a running server can use for its serving purposes.</p>
-<p>(The server objects in the API are in fact intermediary "proxy"
-objects that mediate between the tools running in Eclipse and the real server. A
-server proxy object has a somewhat independent life from that of a real server.
-In cases where the server process must be launched, the proxy object exists in
-advance of the server process, and lives past the termination of the server
-process. The same server proxy may be serially reused to relaunch server
-processes. In cases where we are connecting to a server process running on a
-remote host, the server process may well outlive the proxy.)</p>
-<p>Servers have a <b>server runtime</b>. The server runtime corresponds to the
-installed code base for the server. The main role played by the server runtime
-is in identifying code libraries to compile or build against. In the case of
-local servers, the server runtime may play a secondary role of being used to
-launch the server for testing. Having the server runtimes identified as an
-entity separate from the server itself facilitates sharing server runtimes
-between several servers.</p>
-<p>Servers have an optional <b>server configuration</b>. The server
-configuration is information used to configure a running server. Simple types of
-servers might not require any configuration, whereas full-featured web server
-have an extensive set of parameters for adjusting the server's behavior. Even
-though server configuration information usually takes the form of one or more
-files, configuration information is treated separately from actual content.
-Actual web content can be deployed on different servers without change, whereas
-server configuration information is usually highly dependent on the particulars
-of the server. Having the server configuration identified as an entity separate
-from the server itself facilitates switching an existing server between
-configurations, and sharing server configurations between several servers (e.g.,
-a local test server and a remote server running on another host).</p>
-<p>The web content that is developed for a web server comes in <b>modules</b>. A
-module usually consists of a tree of files; a static HTML web is one simple
-example. Different types of modules consist of possibly constrained arrangements
-files of certain file types. The files making up a module under development
-reside in the Eclipse workspace. In order for a server to use access the content
-within a module, the module in the workspace must be <b>published </b>to the
-server (we use the term <i>publish</i> rather than <i>deploy</i> which is
-overused in J2EE). The module is the unit of content that is published to a
-server. In the case of J2EE servers, the notion of module aligns with the J2EE
-notion of a module (a server concept). But that needn't be the case; some
-types of servers, such as a simple HTTP server, don't have a notion of module.
-Either way, publishing a module to the server entails whatever it takes to get
-the publishable content from the workspace to the server in a form that the
-server can access it. Different types of server runtimes are capable of support
-various module types.</p>
-<p>At any given time, the developer may be working with any number of servers.
-Each server has a server configuration and a set of modules. From the complete
-set of modules in the workspace, any particular server may see only a subset,
-although it is also common for all servers to see all available modules. After
-the developer makes changes to the modules in the workspace and now wants to
-test their modification, they republish the modules to the server. Depending on
-the type of server, republishing a module may entail stopping and restarting the
-server.</p>
-<p>Some types of modules can have other modules as children. The standard
-example of this is a J2EE Enterprise Application (EA) module, whose children are
-simple J2EE modules like Enterprise Java Beans and Web Applications. The
-parent-child relationship is weak: two parent modules can share the same child
-module, and the same child can be parented by several modules (on the same or on
-different servers). The file trees for modules are normally mutually disjoint.
-Module containment is not reflected by any sort of directory nesting. Parent and
-child modules map to non-overlapping file trees.</p>
-<p>Modules reside in the workspace. The typical arrangement is that each module
-has its own project, termed a <b>module project</b>. The module content usually
-corresponds to a particular folder within a project rather than the root of the
-project; this allows the project to contain other files (e.g., .project, .classpath,
-source code) that are not considered part of the module content proper. Each
-different type of module has its own rules for how the content files within it
-are laid out. For instance, a J2EE web module has the same structure as an
-unzipped WAR file. (Note that the module structure rules are largely implicit
-and not reflected directly in the APIs.) It is possible for a project to
-contains more than one module (although this arrangement is less common, and not
-as well supported).</p>
-<p>During development, projects containing modules can be <b>targeted</b> to a
-particular server runtime. Targeting allows the IDE to set up various
-development time properties of the project (such as the backbone of the Java
-build path) appropriately. The most common scenario is where the project is
-targeted to the server runtime for the server to which the module is being
-published. However, it is also possible to target one server runtime (e.g., a
-generic J2EE 1.3 server runtime) while publishing to a server with a different
-server runtime (e.g., a Tomcat v5.0 server). Targeting a project to a particular
-server runtime typically establishes the Java build classpath of the project to
-include the libraries containing the Java APIs for that server runtime (e.g.,
-the appropriate J2EE class libraries). The Java build classpath also needs to
-reflect inter-module dependencies; for J2EE module types, the appropriate
-entries are typically derived from the module's manifest.</p>
-<p>A <b>server project</b> is a project used to hold serialized server (server
-runtime, server configuration) instances. The project is tagged with a special
-Eclipse server nature. The main reason behind server projects was as an
-efficient means of making these serialized files visible in the resource
-navigator and monitoring changes to them.</p>
-<p>The main goals of the Server Core client APIs are to allow clients to create,
-configure, and launch instances of particular server types. Due to differences
-in the behavior (and APIs) of different server types, a client must generally be
-knowledgeable of rules for a particular server type. Clients that have no
-knowledge of any specific server type are limited to doing things like starting,
-stopping, and relaunching existing servers. In other words, the clients APIs are
-generally server-type-specific, rather than sever-type-generic.</p>
-<p>The web tools server architecture allows for an open-ended set of server
-types, server runtime types, server configuration types, and module types. New
-types are declared via extension points in the Server Core plug-in (org.eclipse.wtp.server.core).
-Server types are declared by the serverTypes extension point; server runtime
-types, by runtimeTypes; server configuration types, by serverConfigurationTypes;
-and module types, by moduleKinds. (Additional extension points are discussed
-below.) Associated with these extension points are code APIs designed for use by
-clients contributing to the Server Core extension points; these are more
-correctly called SPIs (service provider interfaces) to distinguish them from the
-code designed to be used by other clients (which we refer to here as client
-APIs).</p>
-<p>Many of the extension points provide for a dynamic code component in addition
-to the static information supplied in the extension declaration. These are
-termed <i>delegates</i>. For instance, all communication with the running server
-is handled by a <b>server delegate</b> contributed via the server type extension
-point. Clients generally deal directly with a layer of objects exposed by the
-API expressly for client use. In the case of server, clients deal with an
-IServer. IServer has a fixed, hidden implementation (the internal class Server),
-which hangs on to a lazily-created server delegate of type IServerDelegate. The
-IServerDelegate implementation is a server-type-specific object. The more
-interesting IServer methods (e.g., getServerState()) are handled by the
-delegate. There are also getDelegate() methods that bridge API to SPI, allowing
-clients to call methods on the delegate directly. Service providers may also
-choose to expose their delegate implementation as API. This allows, for example,
-the provider of a server type to offer additional API that is
-server-type-specific.</p>
-<p>A <b>module factory</b> is responsible for creating modules. There can be any
-number of registered module factories, declared via the
-org.eclipse.wtp.server.core.moduleFactory extension point. A module factory may
-create one or more types of modules (also declared in the extension point). The
-module factory API does not prescribe a way to create modules; it does, however,
-provide methods for retrieving extant modules that it was responsible for
-creating (IModuleFactoryDelegate.getModules() and
-IModuleFactoryDelegate.getModule(String memento)).</p>
-<p>A <b>publish manager</b> is responsible for deciding whether a file resource
-will be published or not (note: publishing includes file deletions as well as
-file creations and modifications). Publish managers are declared via the
-org.eclipse.wtp.server.core.publish extension point.
-ServerCore.getPublishManagers() returns list of know publish managers. There are
-two build-in headless publish managers. The Full Publish Manager is dumb, and
-publishes all of the module's resource from workspace to server. The Smart
-Publish Manager only publishes module resources that have been created, changed,
-or deleted in the workspace, or ones that have been changed (somehow) on the
-server. A publish operation initiated by IServer.publish(IProgressMonitor
-monitor) uses the system-wide default publish manager, which defaults to the
-Smart Publish Manager. (There's also a Visual Publish Manager that lets the user
-pick and choose which files to publish.)</p>
-<p>A <b>publisher</b> (IPublisher) is an object that actually publishes the file
-of a particular module to a particular server. Each server type implements its
-own publishers. On a particular occasion, the IServerDelegate.getPublisher(List
-parents, IModule module) returns the publisher to use to publish the files of
-the given module. IPublisher.publish(IModuleResource[] resource,
-IProgressMonitor monitor) and IPublisher.delete(IRemoteResource[] resource,
-IProgressMonitor monitor) do the heavy lifting.</p>
-<p>The client API exposes:</p>
-<ul>
- <li>Server runtime types as IRuntimeType. ServerCore.getRuntimeTypes() returns
- all known server runtime types.</li>
- <li>Server types as IServerType. ServerCore.getServerTypes() returns all known
- server types. </li>
- <li>Server configuration types as IServerConfigurationType.
- ServerCore.getServerConfigurationTypes() returns all known server
- configuration types.</li>
- <li>Module types as IModuleKind. ServerCore.getModuleKinds() returns all known
- module kinds.</li>
-</ul>
-<p>The type-level relationships are:</p>
-<ul>
- <li>a server type has a server runtime type; this is the type of server
- runtime required to run the server; exposed as IServerType.getRuntimeType()</li>
- <li>a server type has an optional server configuration type; this is the type
- of server configuration required to configure the server; exposed as
- IServerType.getServerConfigurationType()</li>
- <li>a server runtime type supports 0 or more module types; exposed as
- IRuntimeType.getModuleTypes()</li>
-</ul>
-<p>The API exposes server runtime instances as IRuntime.
-ServerCore.getResourceManager().getRuntimes() returns all known server runtime
-instances. Server runtime instances are created (only) from server runtime types
-by IRuntimeType.createRuntime(String id), which returns an IRuntimeWorkingCopy.
-Any number of aspects of the server runtime instance (including location in the
-file system) can be established or adjusted from their defaults. When editing is
-complete, IRuntimeWorkingCopy.save(IProgressMonitor monitor) creates, registers,
-returns a server runtime instance (IRuntime) capturing the desired settings (the
-working copy is disposed of).</p>
-<p>The API exposes server configuration instances as IServerConfiguration.
-ServerCore.getResourceManager().getServerConfigurations() returns all known
-server configuration instances. Server configuration instances are created
-(only) from server types by
-IServerConfigurationType.createServerConfiguration(String id, IFile file,
-IProgressMonitor monitor) or IServerConfigurationType.importFromPath(String id,
-IFile file, IPath path, IProgressMonitor monitor) or
-IServerConfigurationType.importFromRuntime(String id, IFile file, IRuntime
-runtime, IProgressMonitor monitor). The file parameter is used to control where
-the server configuration instance is serialized. All 3 return an
-IServerConfigurationWorkingCopy. (There are no aspects of the server
-configuration instance to adjust.)
-IServerConfigurationWorkingCopy.save(IProgressMonitor monitor) creates,
-registers, returns a server configuration instance (IServerConfiguration)
-capturing the desired settings (the working copy is disposed of). </p>
-<p>The API exposes server instances as IServer.
-ServerCore.getResourceManager().getServers() returns all known server instances.
-Server instances are created (only) from server types by
-IServerType.createServer(String id, IFile file, IRuntime runtime,
-IProgressMonitor monitor) or IServerType.createServer(String id, IFile file,
-IRuntime runtime, IProgressMonitor monitor). The file parameter is used to
-control where the server instance is serialized. Both return an
-IServerWorkingCopy. Any number of aspects of the server instance (host name,
-server runtime, server configuration, modules, ...) can be established or
-adjusted from their defaults. When editing is complete,
-IServerWorkingCopy.save(IProgressMonitor monitor) creates, registers, returns a
-server instance (IServer) capturing the desired settings (the working copy is
-disposed of). </p>
-<p>The instance-level relationship between servers and server runtimes and
-server configurations is exposed at the API: for a given server,
-IServer.getRuntime() returns the server runtime (IRuntime),
-IServer.getServerConfiguration() returns the server configuration (IServerConfiguration).</p>
-<p>IServer.start(String mode, IProgressMonitor monitor), stop(), and
-restart(String mode) are used to start, stop, and restart a server, respectively
-(there are also synchronous methods for starting and stopping). The predicates
-IServer.canStart(String mode), canRestart(String mode), and canStop() indicate
-whether the server is receptive to being controlled. IServer.getServerState()
-can be used to query the overall state of the server (one of starting, started,
-stopping, stopped, or unknown), and IServer.getModuleState(IModule module) can
-be used to query the state of any of its modules.</p>
-
-</body>
-
-</html>
diff --git a/development/miscdocuments/web_tools_server_api_concepts.html b/development/miscdocuments/web_tools_server_api_concepts.html
deleted file mode 100644
index 8b4b23f..0000000
--- a/development/miscdocuments/web_tools_server_api_concepts.html
+++ /dev/null
@@ -1,260 +0,0 @@
-<html>
-
-<head>
-<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
-<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
-<meta name="ProgId" content="FrontPage.Editor.Document">
-<title>API Concepts and Roles</title>
-</head>
-
-<body>
-
-<h1>WTP Server Tools<br>
-API Concepts and Roles</h1>
-<p>Last modified Nov. 2, 2004</p>
-<p>[<i>This document is a work in progress. The document is an attempt to
-capture the key concepts required for understanding and working with the WTP
-Server Core API. Note that the concepts may differ subtly from what is currently
-found in the currently released <a href="http://dev.eclipse.org/viewcvs/index.cgi/wst/components/server/plugins/org.eclipse.wst.server.core/?cvsroot=WebTools_Project">org.eclipse.wst.server.core
-plug-in</a>. Once this document is finalized, our intent is to bring the code
-and specs into line with this document.]</i></p>
-<p>The key concepts for understanding the API (and SPI) are servers and modules.
-The notions of server runtimes and server configurations play an important, but
-secondary role.</p>
-<p>Not surprisingly, the notion of <b>server</b> is central in the web tools
-server infrastructure. In this context we are to understand that the server is a
-web server of some ilk (a more exact definition is not required for our
-purposes). From a tool-centric point of view, a server is something that the
-developer is writing "content" for. (In a sense, the server exists,
-but lacks useful content. The development task is to provide that content.) The
-content can include anything from simple, static HTML web pages to complex,
-highly dynamic web applications. In the course of writing and debugging this
-content, they will want to test their content on a web server, to see how it
-gets served up. For this they will need to launch a server process running on
-some host machine (often the local host on which the Eclipse IDE is running), or
-attach to a server that's already running. And we must arrange that the newly
-developed content sitting in the developer's workspace ends up in a location and
-format that a running server can use for its serving purposes.</p>
-<p>(The server objects in the API are in fact intermediary "proxy"
-objects that mediate between the tools running in Eclipse and the real server. A
-server proxy object has a somewhat independent life from that of a real server.
-In cases where the server process must be launched, the proxy object exists in
-advance of the server process, and lives past the termination of the server
-process. The same server proxy may be serially reused to relaunch server
-processes. In cases where we are connecting to a server process running on a
-remote host, the server process may well outlive the proxy.)</p>
-<p>Servers have a <b>server runtime</b>. The server runtime corresponds to the
-installed code base for the server. The main role played by the server runtime
-is in identifying code libraries to compile or build against. In the case of
-local servers, the server runtime may play a secondary role of being used to
-launch the server for testing. Having the server runtimes identified as an
-entity separate from the server itself facilitates sharing server runtimes
-between several servers.</p>
-<p>Servers have an optional <b>server configuration</b>. The server
-configuration is information used to configure a running server. Simple types of
-servers might not require any configuration, whereas full-featured web server
-have an extensive set of parameters for adjusting the server's behavior. Even
-though server configuration information usually takes the form of one or more
-files, configuration information is treated separately from actual content.
-Actual web content can be deployed on different servers without change, whereas
-server configuration information is usually highly dependent on the particulars
-of the server. Having the server configuration identified as an entity separate
-from the server itself facilitates switching an existing server between
-configurations, and sharing server configurations between several servers (e.g.,
-a local test server and a remote server running on another host).</p>
-<p>The web content that is developed for a web server comes in <b>modules</b>. A
-module usually consists of a tree of files; a static HTML web is one simple
-example. Different types of modules consist of possibly constrained arrangements
-files of certain file types. The files making up a module under development
-reside in the Eclipse workspace. In order for a server to use access the content
-within a module, the module in the workspace must be <b>published </b>to the
-server (we use the term <i>publish</i> rather than <i>deploy</i> which is
-overused in J2EE). The module is the unit of content that is published to a
-server. In the case of J2EE servers, the notion of module aligns with the J2EE
-notion of a module (a server concept). But that needn't be the case; some
-types of servers, such as a simple HTTP server, don't have a notion of module.
-Either way, publishing a module to the server entails whatever it takes to get
-the publishable content from the workspace to the server in a form that the
-server can access it. Different types of server runtimes are capable of support
-various module types.</p>
-<p>At any given time, the developer may be working with any number of servers.
-Each server has a server configuration and a set of modules. From the complete
-set of modules in the workspace, any particular server may see only a subset,
-although it is also common for all servers to see all available modules. After
-the developer makes changes to the modules in the workspace and now wants to
-test their modification, they republish the modules to the server. Depending on
-the type of server, republishing a module may entail stopping and restarting the
-server.</p>
-<p>Some types of modules can have other modules as children. The standard
-example of this is a J2EE Enterprise Application (EA) module, whose children are
-simple J2EE modules like Enterprise Java Beans and Web Applications. The
-parent-child relationship is weak: two parent modules can share the same child
-module, and the same child can be parented by several modules (on the same or on
-different servers). The file trees for modules are normally mutually disjoint.
-Module containment is not reflected by any sort of directory nesting. Parent and
-child modules map to non-overlapping file trees.</p>
-<p>Modules reside in the workspace. The typical arrangement is that each module
-has its own project, termed a <b>module project</b>. The module content usually
-corresponds to a particular folder within a project rather than the root of the
-project; this allows the project to contain other files (e.g., .project, .classpath,
-source code) that are not considered part of the module content proper. Each
-different type of module has its own rules for how the content files within it
-are laid out. For instance, a J2EE web module has the same structure as an
-unzipped WAR file. (Note that the module structure rules are largely implicit
-and not reflected directly in the APIs.) It is possible for a project to
-contains more than one module (although this arrangement is less common, and not
-as well supported).</p>
-<p>During development, projects containing modules can be <b>targeted</b> to a
-particular server runtime. Targeting allows the IDE to set up various
-development time properties of the project (such as the backbone of the Java
-build path) appropriately. The most common scenario is where the project is
-targeted to the server runtime for the server to which the module is being
-published. However, it is also possible to target one server runtime (e.g., a
-generic J2EE 1.3 server runtime) while publishing to a server with a different
-server runtime (e.g., a Tomcat v5.0 server). Targeting a project to a particular
-server runtime typically establishes the Java build classpath of the project to
-include the libraries containing the Java APIs for that server runtime (e.g.,
-the appropriate J2EE class libraries). The Java build classpath also needs to
-reflect inter-module dependencies; for J2EE module types, the appropriate
-entries are typically derived from the module's manifest.</p>
-<p>A <b>server project</b> is a project used to hold serialized server (server
-runtime, server configuration) instances. The project is tagged with a special
-Eclipse server nature. The main reason behind server projects was as an
-efficient means of making these serialized files visible in the resource
-navigator and monitoring changes to them.</p>
-<p>The main goals of the Server Core client APIs are to allow clients to create,
-configure, and launch instances of particular server types. Due to differences
-in the behavior (and APIs) of different server types, a client must generally be
-knowledgeable of rules for a particular server type. Clients that have no
-knowledge of any specific server type are limited to doing things like starting,
-stopping, and relaunching existing servers. In other words, the clients APIs are
-generally server-type-specific, rather than sever-type-generic.</p>
-<p>The web tools server architecture allows for an open-ended set of server
-types, server runtime types, server configuration types, and module types. New
-types are declared via extension points in the Server Core plug-in (org.eclipse.wtp.server.core).
-Server types are declared by the serverTypes extension point; server runtime
-types, by runtimeTypes; server configuration types, by serverConfigurationTypes;
-and module types, by moduleKinds. (Additional extension points are discussed
-below.) Associated with these extension points are code APIs designed for use by
-clients contributing to the Server Core extension points; these are more
-correctly called SPIs (service provider interfaces) to distinguish them from the
-code designed to be used by other clients (which we refer to here as client
-APIs).</p>
-<p>Many of the extension points provide for a dynamic code component in addition
-to the static information supplied in the extension declaration. These are
-termed <i>delegates</i>. For instance, all communication with the running server
-is handled by a <b>server delegate</b> contributed via the server type extension
-point. Clients generally deal directly with a layer of objects exposed by the
-API expressly for client use. In the case of server, clients deal with an
-IServer. IServer has a fixed, hidden implementation (the internal class Server),
-which hangs on to a lazily-created server delegate of type IServerDelegate. The
-IServerDelegate implementation is a server-type-specific object. The more
-interesting IServer methods (e.g., getServerState()) are handled by the
-delegate. There are also getDelegate() methods that bridge API to SPI, allowing
-clients to call methods on the delegate directly. Service providers may also
-choose to expose their delegate implementation as API. This allows, for example,
-the provider of a server type to offer additional API that is
-server-type-specific.</p>
-<p>A <b>module factory</b> is responsible for creating modules. There can be any
-number of registered module factories, declared via the
-org.eclipse.wtp.server.core.moduleFactory extension point. A module factory may
-create one or more types of modules (also declared in the extension point). The
-module factory API does not prescribe a way to create modules; it does, however,
-provide methods for retrieving extant modules that it was responsible for
-creating (IModuleFactoryDelegate.getModules() and
-IModuleFactoryDelegate.getModule(String memento)).</p>
-<p>A <b>publish manager</b> is responsible for deciding whether a file resource
-will be published or not (note: publishing includes file deletions as well as
-file creations and modifications). Publish managers are declared via the
-org.eclipse.wtp.server.core.publish extension point.
-ServerCore.getPublishManagers() returns list of know publish managers. There are
-two build-in headless publish managers. The Full Publish Manager is dumb, and
-publishes all of the module's resource from workspace to server. The Smart
-Publish Manager only publishes module resources that have been created, changed,
-or deleted in the workspace, or ones that have been changed (somehow) on the
-server. A publish operation initiated by IServer.publish(IProgressMonitor
-monitor) uses the system-wide default publish manager, which defaults to the
-Smart Publish Manager. (There's also a Visual Publish Manager that lets the user
-pick and choose which files to publish.)</p>
-<p>A <b>publisher</b> (IPublisher) is an object that actually publishes the file
-of a particular module to a particular server. Each server type implements its
-own publishers. On a particular occasion, the IServerDelegate.getPublisher(List
-parents, IModule module) returns the publisher to use to publish the files of
-the given module. IPublisher.publish(IModuleResource[] resource,
-IProgressMonitor monitor) and IPublisher.delete(IRemoteResource[] resource,
-IProgressMonitor monitor) do the heavy lifting.</p>
-<p>The client API exposes:</p>
-<ul>
- <li>Server runtime types as IRuntimeType. ServerCore.getRuntimeTypes() returns
- all known server runtime types.</li>
- <li>Server types as IServerType. ServerCore.getServerTypes() returns all known
- server types. </li>
- <li>Server configuration types as IServerConfigurationType.
- ServerCore.getServerConfigurationTypes() returns all known server
- configuration types.</li>
- <li>Module types as IModuleKind. ServerCore.getModuleKinds() returns all known
- module kinds.</li>
-</ul>
-<p>The type-level relationships are:</p>
-<ul>
- <li>a server type has a server runtime type; this is the type of server
- runtime required to run the server; exposed as IServerType.getRuntimeType()</li>
- <li>a server type has an optional server configuration type; this is the type
- of server configuration required to configure the server; exposed as
- IServerType.getServerConfigurationType()</li>
- <li>a server runtime type supports 0 or more module types; exposed as
- IRuntimeType.getModuleTypes()</li>
-</ul>
-<p>The API exposes server runtime instances as IRuntime.
-ServerCore.getResourceManager().getRuntimes() returns all known server runtime
-instances. Server runtime instances are created (only) from server runtime types
-by IRuntimeType.createRuntime(String id), which returns an IRuntimeWorkingCopy.
-Any number of aspects of the server runtime instance (including location in the
-file system) can be established or adjusted from their defaults. When editing is
-complete, IRuntimeWorkingCopy.save(IProgressMonitor monitor) creates, registers,
-returns a server runtime instance (IRuntime) capturing the desired settings (the
-working copy is disposed of).</p>
-<p>The API exposes server configuration instances as IServerConfiguration.
-ServerCore.getResourceManager().getServerConfigurations() returns all known
-server configuration instances. Server configuration instances are created
-(only) from server types by
-IServerConfigurationType.createServerConfiguration(String id, IFile file,
-IProgressMonitor monitor) or IServerConfigurationType.importFromPath(String id,
-IFile file, IPath path, IProgressMonitor monitor) or
-IServerConfigurationType.importFromRuntime(String id, IFile file, IRuntime
-runtime, IProgressMonitor monitor). The file parameter is used to control where
-the server configuration instance is serialized. All 3 return an
-IServerConfigurationWorkingCopy. (There are no aspects of the server
-configuration instance to adjust.)
-IServerConfigurationWorkingCopy.save(IProgressMonitor monitor) creates,
-registers, returns a server configuration instance (IServerConfiguration)
-capturing the desired settings (the working copy is disposed of). </p>
-<p>The API exposes server instances as IServer.
-ServerCore.getResourceManager().getServers() returns all known server instances.
-Server instances are created (only) from server types by
-IServerType.createServer(String id, IFile file, IRuntime runtime,
-IProgressMonitor monitor) or IServerType.createServer(String id, IFile file,
-IRuntime runtime, IProgressMonitor monitor). The file parameter is used to
-control where the server instance is serialized. Both return an
-IServerWorkingCopy. Any number of aspects of the server instance (host name,
-server runtime, server configuration, modules, ...) can be established or
-adjusted from their defaults. When editing is complete,
-IServerWorkingCopy.save(IProgressMonitor monitor) creates, registers, returns a
-server instance (IServer) capturing the desired settings (the working copy is
-disposed of). </p>
-<p>The instance-level relationship between servers and server runtimes and
-server configurations is exposed at the API: for a given server,
-IServer.getRuntime() returns the server runtime (IRuntime),
-IServer.getServerConfiguration() returns the server configuration (IServerConfiguration).</p>
-<p>IServer.start(String mode, IProgressMonitor monitor), stop(), and
-restart(String mode) are used to start, stop, and restart a server, respectively
-(there are also synchronous methods for starting and stopping). The predicates
-IServer.canStart(String mode), canRestart(String mode), and canStop() indicate
-whether the server is receptive to being controlled. IServer.getServerState()
-can be used to query the overall state of the server (one of starting, started,
-stopping, stopped, or unknown), and IServer.getModuleState(IModule module) can
-be used to query the state of any of its modules.</p>
-
-</body>
-
-</html>
