I think it will simplify things greatly from a users perspective so
I'm all for it. It will also give us a whole lot more flexibility.
We'll be able to create the server instance when the runtime is
created so that means less user input. Also we currently add the
entire runtime to every project type and if G is headed toward a
componetized model it only makes sense to define a set of components
in our "runtime" definition. It will be really cool to be able to be
able to inform the user of a server instances capabilties before they
create a project.
- sachin
On Mar 1, 2006, at 7:54 PM, Dain Sundstrom wrote:
The proposal sounds good to me, but I don't think I'm really
qualified to pass any real judgment on tooling. I would like to
know what you think of the proposal. I'd also like to know if it
adds extra constraints to the Geronimo server.
-dain
On Mar 1, 2006, at 4:34 PM, Sachin Patel wrote:
So hopefully this will make sense... :)
In the two proposal notes I sent, the discussion is around the 3
concepts in WTP, "runtimes", "servers", and "facets" and what we
can do to improve the definition, design and interaction between
the frameworks that these concepts represent. So for those not
familiar with WTP, let me start by describing these concepts from
a "users perspective".
RUNTIMES & SERVERS
----------------
So currently WTP has a notion of defining a "runtime" and defining
a "server". So for a user wanting to create a j2ee app using WTP
and deploy it to geronimo the user must perform currently two
distinct tasks. (1) Is to define a Geronimo runtime using a
wizard which asks the location of the runtime which you would
point to a geronimo installation. During project creation you
would choose this newly defined runtime and what this essentially
does is configures the project to add a JRE and a "runtime
classpath container" which contains all of the geronimo spec jars
+ other G jars. This means that this project is "targeted" to be
deployed to geronimo.
Now in order to deploy that application, the user currently has to
perform a second task, and that is to define and point to the
actual server instance. You may immediatly ask yourself, didn't I
just do that by defining the runtime?
This is currently confusing to users, as the note below
indicates. Not only are the definition of the terms confusing in
discussions as many times there are used interchangably, but from
a users perspective they need to manage in the UI both the list of
servers and runtimes and the mapping between the two. And most of
all what is confusing in the above case, both the runtime and the
server are pointing to the same thing! This usability needs to
change. So one of the proposals is for these two to be merged
togather, with all server instances being runtimes, but not vise
versa. Runtimes may or may not represent a server instance.
(Multiple server instances may have unique configuration/launching
data in distinct location but share the same runtime jars. For
example WebSphere has a concept of profiles).
So with that re-read below and hopefully the note will make more
sense.
FACETS
------
Facets are basically a unit of function that can be applied and
removed to a given WTP project. For example, if a user is wanting
to create a "Web Project" the "web facet" is selected and this
creates the project directory structure specific for a web
project, web.xml, etc.... So how do facets relate to geronimo
runtimes and servers?
Since G is headed toward a model where a user can produce a custom
server image (i.e web container only, no j2ee, etc...) each
distribution may be different. So after defining a runtime by
pointing to this installation, some facets may or not be
applicable to add on a project. So from a tooling perspective we
should be able to ask...Given this "runtime" what kind of
capabilties do I have? What kind of projects can I create?
Now the second use case is that a user may not be interested in
deploying his app yet and only concerned is developing a project
that would be supported geronimo. So they may or may not have a
local geronimo install image. So with our integration and use of
maven, we should be able to take a more appcentric approach in the
tools as well. So the user should be able to simply choose the
ejb project creation wizard, select geronimo, and we should be
able to dynamically generate the minimum runtime for that project
by pulling in the necessary jars from their local install or from
a maven repo.
I hope that helps.
- sachin
On Mar 1, 2006, at 5:35 PM, Dain Sundstrom wrote:
Sachin, can you translate this from eclipse speak to geronimo speak?
-dain
On Mar 1, 2006, at 1:23 PM, Sachin Patel wrote:
Please respond with any comments or concerns you have with this
second proposal as it will have a direct affect on G tooling.
- sachin
Begin forwarded message:
From: "Konstantin Komissarchik" <[EMAIL PROTECTED]>
Date: March 1, 2006 4:02:33 PM EST
To: "General discussion of project-wide or architectural
issues." <[email protected]>
Subject: [wtp-dev] Proposal for Merging Server Runtime and
Server Instance
Reply-To: "General discussion of project-wide or architectural
issues." <[email protected]>
Currently the server tools framework has a separate notion of
runtime and a server. Typically, the runtime is supposed to
represent the server install location, while server instance
supposed to represent an actual runnable server configuration.
The runtime then functions almost like a factory for server
instances. You can have any number (including zero) of server
instances associated with a runtime. While that separation can
be a good thing in some situations, it’s has turned out to be
in a problem in others. In particular:
The runtime is supposed to be a full description of the server,
including its capabilities (which facets are supported). While
that is true in some cases, often the actual server
configuration is necessary in order to get the complete
understanding of what’s supported. See https://bugs.eclipse.org/
bugs/show_bug.cgi?id=111545 for one example of this.
Having to create and maintain separate lists of runtimes and
servers has shown to be confusing for users. Extra steps are
necessary. The user has to know about the preferences page for
managing runtimes and the servers view for managing servers.
Often there is confusion as to which one you are talking about.
People use terms server and runtime interchangeably, etc.
Some runtimes (such as Tomcat) do not have additional server
configuration, in which case the extra step of creating a
server from a runtime is very unnecessary.
I’d like to propose that the server runtime and server instance
be merged into one. I believe we can do that without detriment
to the use cases that gave rise to the separation. We can do
that by allowing a runtime to also (optionally) be a server.
That is, all servers would be runtimes, but not all runtimes
would be servers. When creating a runtime via the new runtime
wizard, the runtime provider will have full flexibility in
determining whether the runtime that’s created is a server or
not. Some runtime providers (such as Tomcat) may always create
servers. Others, such WebLogic, may do that optionally based on
user’s input. For instance, if the user specifies just the
WebLogic install location, then the created runtime would not
be a server, but if the user also provides the domain
configuration directory, then the runtime becomes a startable
server. A project can be targeted to either one for
development, but only the latter one can be used to run/debug
the app. This approach places a lot of flexibility in the hands
of the runtime providers. It’s conceivable that some may even
allow a runtime that’s not a server to be “converted” into a
server by specifying additional information.
The users would manage the list of runtimes via a new Runtimes
workbench view. The view would be extensible, allowing the
server tools framework to plug in and mark those runtimes that
are servers with decorations and additional actions, such as
start, stop, and status monitoring. This would replace the
dedicated Servers view.
At the api level, IRuntime would be adaptable to IServer (as
applicable) and IServer would be adaptable to IRuntime
(always). The server tools would maintain the markers that
indicate which runtimes are servers and surface this via api
for use by the runtime providers. This would not be surfaced to
the end user via UI.
So how would we handle use cases that drove to the separation
of the runtime and the server?
I want to just write code. I haven’t created a server and I
don’t want to create one. I will worry about running/debugging
later. The above proposal leaves this in the hands of runtime
providers. If creating a server instance configuration is not
trivial, the new runtime wizard should let the user opt out of
that. The end result would be an un-runnable runtime that the
user can still develop against.
I don’t want to have to specify the location of my server
install every time I create a new server instance. This can
easily be handled in the runtime creation wizards by
remembering the prior selections in an editable combo box.
Thoughts?
- Konstantin
__________________________________________________________________
_____ Notice: This email message, together with any
attachments, may contain information of BEA Systems, Inc., its
subsidiaries and affiliated entities, that may be confidential,
proprietary, copyrighted and/or legally privileged, and is
intended solely for the use of the individual or entity named
in this message. If you are not the intended recipient, and
have received this message in error, please immediately return
this by email and then delete it.
_______________________________________________
wtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev
