Home » Language IDEs » ServerTools (WTP) » Doing something about it.
| Doing something about it. [message #8099] |
Fri, 05 September 2003 06:50  |
Eclipse User |
|
|
|
Originally posted by: bf.digitalstrider.com
To finally get started on this list (im really annoyed so far) i made up
this document which should reflect the
current state the thoughts which popped up (at least if i wasnt carried away
while writting it).
If you find mistakes i havent found, correct them yourselfs, since i don't
care too much. Also i'm currently
learning J2EE! Which means, i may accidently not see evident things, but i
guess youre nice guys and
forgive me my shortcomings.
I tried to format the document on a monospaced font. i guess it will look
awful when using another font, so
tell me if i should repost it in rtf-email format or read below for other
possibilities.
I really hope you people out there appreciate the doc and that we might
eventually get started since i hate projects
which had a good initial idea behind them and are not moving an inch due to
some silly question (forgive me, whoever
is going to read this from the future PMC or whoever else is offended ;)
See you around.
Dan
--------------------------------------------------------
--------------------------------------------------------
Web Tools Project
Initial Draft
version 0.0.1
[Changes]
- All new.
************
Introduction
************
Purpose of the Document
-----------------------
The purposes of this document are at the moment several. The first and
foremost is: we have good ideas and wether
bureaucracy nor economic strategies of some providers of J2EE development
tools will hinder us. Second is that that
the good ideas are not forgotten or ignored (at least so long as not another
corruption of the newsarchives occurs)
but they lie bare and no development is done on them since everyone thinks
himself better of at supporting other
projects or enjoying spare time. So then, lets do something about it.
If someone feels that this document should be restructured, orthographically
or stylistically improved or otherwise
altered, feel free to do so.
Also are the structuring of the next steps or whatever else mentioned in
this document simply the harvest of the
newsgroup on Webtools Project and some imagination from myself (and
hopefully soon others). It shall simply provide
a common playground for us all until there is finally a PMC or we have taken
the scepter ourselfs.
Current State
-------------
As mentioned above most of us subscribed on the newslist (missing those who
already unsigned due to lack of
activity) are waiting for some bureaucratic schemes to be laid out by a
yet-to-be-formed PMC. Until the PMC is
formed and there is some real action, we should use this document or similar
utilities to gather ideas, concepts,
thoughts and whatever else crosses our minds concerning the webtools
project. The PMC can hopefully use whatever we
are thinking up, and it gives us a starting point for discussion.
Next Steps
----------
Thought about it-> (Robert Varga): "... Therefore the first to do is to
provide a base infrastructure that can hold
together all stuff to be developed later. You need to be able to manage
deployment units, deployment methods and
deployment destinations. That is the very first thing to do." (See other
thoughts at Deployment Unit Section).
Other ideas are to develop the components (sorry for the outworn word)
independent of each other so that the
deployment unit is not necessary (you dont want always to build a complete
web tools project for using a JSP-Editor)
and then the deployment Unit is the glue of all these things.
Also should this document be approved by the members on the list (more the
form than the actual content). We could
the clean out the ifs and shoulds and everything else which separates it
from a 'official' document.
Conventions
-----------
This document was initially written in openoffice and can be saved either as
msword filetype (for the MS-People out
there) or as open-office filetype. Tell me what you think about it, since
the first version will be posted as plain
text email (i dont like newsgroups which use attachments). Somebody
mentioned a free cvs-repositery until things get
rolling on eclipse.org. perhaps this is the way to go. Or we can stick to
the plaintext version in emails.
Below the title is a versionnumber and a changes section. Every change which
occurs while adding/improving/updating
the document should be mentioned there (except changes on orthography or
style). The changes will go in after more
or less thorough discussion (except perhaps the initial text on a new
section) and so i guess changes wont be done
all too often, but with the revision number, somebody can sort out the
differences between two files with the same
version and merge em (hmm, someones shouting CVS from between my ears).
Also if possible center youre posts around one issue at hand (which will
more or less correspond to the chapters
inside this doc) since we will be able to draw some conclusions and move
them here.
******************
Stuff that matters
******************
Sorry, had no idea what to call this bunch which follows.
The nice listing below was posted by Igor Khlystov.
General purpose tools
---------------------
I guess, all of us agree with me, that all editors should have syntax
highlighting, syntax checking (where
applicable) and tooltips assist. So these things have not to be mentioned
for each editor.
CSS editor
''''''''''
XML editor
''''''''''
Should probably, the first to develop, as it seems would be a base to other
flavors.
HTML/XHTML editor
'''''''''''''''''
XSL editor ( debugger?)
'''''''''''''''''''''''
JSP editor
''''''''''
The JSP Editor has to be independent of a webtools project. It is usable on
non-webtools .jsp files but will
integrate with its environment if the edited JSP is inside a webtools
project.
The JSP Editor should be able to solve references and provide links for tags
like <%@ include and <jsp:forward.
A Key feature of the editor will be the possibility to debug web
applications. So there will also be a JSP debugging
environment.
Also Key requirement/feature should be the early support of frameworks
(first of all, struts i guess). This is a
marketing idea as well; Emerson Cargnin writes: "Could it support struts
from the start ?? I think this could be a
way to call a lot of others developers, since there's no tool good enough
(and OS) at the market."
EJB
---
wizards
'''''''
builders
''''''''
specific views
''''''''''''''
Platform adapters
-----------------
Provides launch, debug mode, "in place" and standard deployment,
configurations , general and platform specific
builders etc.
Apache HTTP
'''''''''''
Jetty
'''''
Tomcat
''''''
Resin
'''''
JRun
''''
WebLogic
''''''''
WebSphere
'''''''''
JBoss
'''''
OpenEJB
'''''''
Frameworks tools
----------------
A set of tools to design and develop application within specific frameworks.
JavaFaces
'''''''''
Struts
''''''
Eclipse web model
'''''''''''''''''
A Web nature should be added to the project.
Deployment Unit
'''''''''''''''
A deployment unit is the set of files that are deployed together. This is
you have to be able to designate the
future place of single files and project subtrees inside a deployment unit.
When you have this, you know what is
necessary to be deployed together.
This is followed by the deployment methods:
- you can make export procedures for deployment units to either jar/war/ear
or exploded directory format.
- you can make deployment procedures of jar/war/ear or exploded
directory-structures into application servers.
- you may want to integrate parts of the previous two together to directly
deploy from source to the server. This is
followed by managing deployment destinations to not to enter data necessary
to the deployment every time you are
deploying something. A deployment destination can be a Server instance, or a
Domain in a cluster.
|
|
|
| Re: Doing something about it. [message #8133 is a reply to message #8099] |
Fri, 05 September 2003 12:23  |
| Eclipse User |
|
|
|
Originally posted by: robert.varga.fathomtechnology.com
I think you should rather put it up on a website somewhere with more
formatting available.
Or, I don't know, whether the wiki pages are world-writable or not...
Regards,
Robert Varga
"Daniel Mueller" <bf@digitalstrider.com> wrote in message
news:bj9bm1$q1i$1@eclipse.org...
> To finally get started on this list (im really annoyed so far) i made up
> this document which should reflect the
> current state the thoughts which popped up (at least if i wasnt carried
away
> while writting it).
> If you find mistakes i havent found, correct them yourselfs, since i don't
> care too much. Also i'm currently
> learning J2EE! Which means, i may accidently not see evident things, but i
> guess youre nice guys and
> forgive me my shortcomings.
>
> I tried to format the document on a monospaced font. i guess it will look
> awful when using another font, so
> tell me if i should repost it in rtf-email format or read below for other
> possibilities.
>
> I really hope you people out there appreciate the doc and that we might
> eventually get started since i hate projects
> which had a good initial idea behind them and are not moving an inch due
to
> some silly question (forgive me, whoever
> is going to read this from the future PMC or whoever else is offended ;)
>
> See you around.
>
> Dan
>
> --------------------------------------------------------
> --------------------------------------------------------
>
>
> Web Tools Project
>
> Initial Draft
>
> version 0.0.1
>
> [Changes]
>
> - All new.
>
>
>
>
>
>
>
>
> ************
> Introduction
> ************
>
> Purpose of the Document
> -----------------------
>
> The purposes of this document are at the moment several. The first and
> foremost is: we have good ideas and wether
> bureaucracy nor economic strategies of some providers of J2EE development
> tools will hinder us. Second is that that
> the good ideas are not forgotten or ignored (at least so long as not
another
> corruption of the newsarchives occurs)
> but they lie bare and no development is done on them since everyone thinks
> himself better of at supporting other
> projects or enjoying spare time. So then, lets do something about it.
>
> If someone feels that this document should be restructured,
orthographically
> or stylistically improved or otherwise
> altered, feel free to do so.
>
> Also are the structuring of the next steps or whatever else mentioned in
> this document simply the harvest of the
> newsgroup on Webtools Project and some imagination from myself (and
> hopefully soon others). It shall simply provide
> a common playground for us all until there is finally a PMC or we have
taken
> the scepter ourselfs.
>
> Current State
> -------------
>
> As mentioned above most of us subscribed on the newslist (missing those
who
> already unsigned due to lack of
> activity) are waiting for some bureaucratic schemes to be laid out by a
> yet-to-be-formed PMC. Until the PMC is
> formed and there is some real action, we should use this document or
similar
> utilities to gather ideas, concepts,
> thoughts and whatever else crosses our minds concerning the webtools
> project. The PMC can hopefully use whatever we
> are thinking up, and it gives us a starting point for discussion.
>
> Next Steps
> ----------
>
> Thought about it-> (Robert Varga): "... Therefore the first to do is to
> provide a base infrastructure that can hold
> together all stuff to be developed later. You need to be able to manage
> deployment units, deployment methods and
> deployment destinations. That is the very first thing to do." (See other
> thoughts at Deployment Unit Section).
> Other ideas are to develop the components (sorry for the outworn word)
> independent of each other so that the
> deployment unit is not necessary (you dont want always to build a complete
> web tools project for using a JSP-Editor)
> and then the deployment Unit is the glue of all these things.
> Also should this document be approved by the members on the list (more the
> form than the actual content). We could
> the clean out the ifs and shoulds and everything else which separates it
> from a 'official' document.
>
> Conventions
> -----------
> This document was initially written in openoffice and can be saved either
as
> msword filetype (for the MS-People out
> there) or as open-office filetype. Tell me what you think about it, since
> the first version will be posted as plain
> text email (i dont like newsgroups which use attachments). Somebody
> mentioned a free cvs-repositery until things get
> rolling on eclipse.org. perhaps this is the way to go. Or we can stick to
> the plaintext version in emails.
>
> Below the title is a versionnumber and a changes section. Every change
which
> occurs while adding/improving/updating
> the document should be mentioned there (except changes on orthography or
> style). The changes will go in after more
> or less thorough discussion (except perhaps the initial text on a new
> section) and so i guess changes wont be done
> all too often, but with the revision number, somebody can sort out the
> differences between two files with the same
> version and merge em (hmm, someones shouting CVS from between my ears).
>
> Also if possible center youre posts around one issue at hand (which will
> more or less correspond to the chapters
> inside this doc) since we will be able to draw some conclusions and move
> them here.
>
>
> ******************
> Stuff that matters
> ******************
>
> Sorry, had no idea what to call this bunch which follows.
> The nice listing below was posted by Igor Khlystov.
>
>
> General purpose tools
> ---------------------
> I guess, all of us agree with me, that all editors should have syntax
> highlighting, syntax checking (where
> applicable) and tooltips assist. So these things have not to be mentioned
> for each editor.
>
> CSS editor
> ''''''''''
>
> XML editor
> ''''''''''
>
> Should probably, the first to develop, as it seems would be a base to
other
> flavors.
>
>
> HTML/XHTML editor
> '''''''''''''''''
>
> XSL editor ( debugger?)
> '''''''''''''''''''''''
>
> JSP editor
> ''''''''''
>
> The JSP Editor has to be independent of a webtools project. It is usable
on
> non-webtools .jsp files but will
> integrate with its environment if the edited JSP is inside a webtools
> project.
> The JSP Editor should be able to solve references and provide links for
tags
> like <%@ include and <jsp:forward.
> A Key feature of the editor will be the possibility to debug web
> applications. So there will also be a JSP debugging
> environment.
>
> Also Key requirement/feature should be the early support of frameworks
> (first of all, struts i guess). This is a
> marketing idea as well; Emerson Cargnin writes: "Could it support struts
> from the start ?? I think this could be a
> way to call a lot of others developers, since there's no tool good enough
> (and OS) at the market."
>
>
> EJB
> ---
>
> wizards
> '''''''
>
> builders
> ''''''''
>
> specific views
> ''''''''''''''
>
>
> Platform adapters
> -----------------
> Provides launch, debug mode, "in place" and standard deployment,
> configurations , general and platform specific
> builders etc.
>
> Apache HTTP
> '''''''''''
>
> Jetty
> '''''
>
> Tomcat
> ''''''
>
> Resin
> '''''
>
> JRun
> ''''
>
> WebLogic
> ''''''''
>
> WebSphere
> '''''''''
>
> JBoss
> '''''
>
> OpenEJB
> '''''''
>
>
> Frameworks tools
> ----------------
> A set of tools to design and develop application within specific
frameworks.
>
> JavaFaces
> '''''''''
> Struts
> ''''''
> Eclipse web model
> '''''''''''''''''
> A Web nature should be added to the project.
>
>
> Deployment Unit
> '''''''''''''''
> A deployment unit is the set of files that are deployed together. This is
> you have to be able to designate the
> future place of single files and project subtrees inside a deployment
unit.
> When you have this, you know what is
> necessary to be deployed together.
> This is followed by the deployment methods:
>
> - you can make export procedures for deployment units to either
jar/war/ear
> or exploded directory format.
>
> - you can make deployment procedures of jar/war/ear or exploded
> directory-structures into application servers.
>
> - you may want to integrate parts of the previous two together to directly
> deploy from source to the server. This is
> followed by managing deployment destinations to not to enter data
necessary
> to the deployment every time you are
> deploying something. A deployment destination can be a Server instance, or
a
> Domain in a cluster.
>
>
>
|
|
|
| Re: Doing something about it. [message #8527 is a reply to message #8099] |
Fri, 19 September 2003 15:17 |
| Eclipse User |
|
|
|
Originally posted by: mark_lybarger.nospam.yahoo.com
Just a few thoughts since there seems to be some actual interest in moving
this project along. Like a lot of folks, I'd really like to see it take
off. (any funding from IBM available?? probably wishfull thinking ;) ).
As with any project or development effort, there needs to be a mission
statement or statement of work. A project overview of sorts. What is
this project and what is it going to accomplish at a high level.
There should also be a project team charter. Who are the team members and
what are the roles/responsiblities on the project (business analyst,
project lead, technical architect, etc). it's the buraucratic bs that
needs to get out of the way first before the grunt labor can continue.
Next comes a requirements document from a business analyst type person.
While that's being drafted, a high level design document will show the
peices to be developed and how they interoperate together.
Following that, there s/b a detailed technical spec and a detailed
business requirements document. Perhaps by this stage, it's been decided
what will be included in an initial release, and what will be included
later. (core + limited functionality at first, with more functionality
being rapidly added later).
All this time the PM does whatever a PM does. set milestones, helps review
stuff, gathers and deploys verious resources.
Now that there's a detailed technical spec for release 1, it's time to
start building stuff. pull stuff from other projects, coding, assembling
stuff, etc.
Daniel Mueller wrote:
> To finally get started on this list (im really annoyed so far) i made up
> this document which should reflect the
> current state the thoughts which popped up (at least if i wasnt carried away
> while writting it).
> If you find mistakes i havent found, correct them yourselfs, since i don't
> care too much. Also i'm currently
> learning J2EE! Which means, i may accidently not see evident things, but i
> guess youre nice guys and
> forgive me my shortcomings.
> I tried to format the document on a monospaced font. i guess it will look
> awful when using another font, so
> tell me if i should repost it in rtf-email format or read below for other
> possibilities.
> I really hope you people out there appreciate the doc and that we might
> eventually get started since i hate projects
> which had a good initial idea behind them and are not moving an inch due to
> some silly question (forgive me, whoever
> is going to read this from the future PMC or whoever else is offended ;)
> See you around.
> Dan
> --------------------------------------------------------
> --------------------------------------------------------
> Web Tools Project
> Initial Draft
> version 0.0.1
> [Changes]
> - All new.
> ************
> Introduction
> ************
> Purpose of the Document
> -----------------------
> The purposes of this document are at the moment several. The first and
> foremost is: we have good ideas and wether
> bureaucracy nor economic strategies of some providers of J2EE development
> tools will hinder us. Second is that that
> the good ideas are not forgotten or ignored (at least so long as not another
> corruption of the newsarchives occurs)
> but they lie bare and no development is done on them since everyone thinks
> himself better of at supporting other
> projects or enjoying spare time. So then, lets do something about it.
> If someone feels that this document should be restructured, orthographically
> or stylistically improved or otherwise
> altered, feel free to do so.
> Also are the structuring of the next steps or whatever else mentioned in
> this document simply the harvest of the
> newsgroup on Webtools Project and some imagination from myself (and
> hopefully soon others). It shall simply provide
> a common playground for us all until there is finally a PMC or we have taken
> the scepter ourselfs.
> Current State
> -------------
> As mentioned above most of us subscribed on the newslist (missing those who
> already unsigned due to lack of
> activity) are waiting for some bureaucratic schemes to be laid out by a
> yet-to-be-formed PMC. Until the PMC is
> formed and there is some real action, we should use this document or similar
> utilities to gather ideas, concepts,
> thoughts and whatever else crosses our minds concerning the webtools
> project. The PMC can hopefully use whatever we
> are thinking up, and it gives us a starting point for discussion.
> Next Steps
> ----------
> Thought about it-> (Robert Varga): "... Therefore the first to do is to
> provide a base infrastructure that can hold
> together all stuff to be developed later. You need to be able to manage
> deployment units, deployment methods and
> deployment destinations. That is the very first thing to do." (See other
> thoughts at Deployment Unit Section).
> Other ideas are to develop the components (sorry for the outworn word)
> independent of each other so that the
> deployment unit is not necessary (you dont want always to build a complete
> web tools project for using a JSP-Editor)
> and then the deployment Unit is the glue of all these things.
> Also should this document be approved by the members on the list (more the
> form than the actual content). We could
> the clean out the ifs and shoulds and everything else which separates it
> from a 'official' document.
> Conventions
> -----------
> This document was initially written in openoffice and can be saved either as
> msword filetype (for the MS-People out
> there) or as open-office filetype. Tell me what you think about it, since
> the first version will be posted as plain
> text email (i dont like newsgroups which use attachments). Somebody
> mentioned a free cvs-repositery until things get
> rolling on eclipse.org. perhaps this is the way to go. Or we can stick to
> the plaintext version in emails.
> Below the title is a versionnumber and a changes section. Every change which
> occurs while adding/improving/updating
> the document should be mentioned there (except changes on orthography or
> style). The changes will go in after more
> or less thorough discussion (except perhaps the initial text on a new
> section) and so i guess changes wont be done
> all too often, but with the revision number, somebody can sort out the
> differences between two files with the same
> version and merge em (hmm, someones shouting CVS from between my ears).
> Also if possible center youre posts around one issue at hand (which will
> more or less correspond to the chapters
> inside this doc) since we will be able to draw some conclusions and move
> them here.
> ******************
> Stuff that matters
> ******************
> Sorry, had no idea what to call this bunch which follows.
> The nice listing below was posted by Igor Khlystov.
> General purpose tools
> ---------------------
> I guess, all of us agree with me, that all editors should have syntax
> highlighting, syntax checking (where
> applicable) and tooltips assist. So these things have not to be mentioned
> for each editor.
> CSS editor
> ''''''''''
> XML editor
> ''''''''''
> Should probably, the first to develop, as it seems would be a base to other
> flavors.
> HTML/XHTML editor
> '''''''''''''''''
> XSL editor ( debugger?)
> '''''''''''''''''''''''
> JSP editor
> ''''''''''
> The JSP Editor has to be independent of a webtools project. It is usable on
> non-webtools .jsp files but will
> integrate with its environment if the edited JSP is inside a webtools
> project.
> The JSP Editor should be able to solve references and provide links for tags
> like <%@ include and <jsp:forward.
> A Key feature of the editor will be the possibility to debug web
> applications. So there will also be a JSP debugging
> environment.
> Also Key requirement/feature should be the early support of frameworks
> (first of all, struts i guess). This is a
> marketing idea as well; Emerson Cargnin writes: "Could it support struts
> from the start ?? I think this could be a
> way to call a lot of others developers, since there's no tool good enough
> (and OS) at the market."
> EJB
> ---
> wizards
> '''''''
> builders
> ''''''''
> specific views
> ''''''''''''''
> Platform adapters
> -----------------
> Provides launch, debug mode, "in place" and standard deployment,
> configurations , general and platform specific
> builders etc.
> Apache HTTP
> '''''''''''
> Jetty
> '''''
> Tomcat
> ''''''
> Resin
> '''''
> JRun
> ''''
> WebLogic
> ''''''''
> WebSphere
> '''''''''
> JBoss
> '''''
> OpenEJB
> '''''''
> Frameworks tools
> ----------------
> A set of tools to design and develop application within specific frameworks.
> JavaFaces
> '''''''''
> Struts
> ''''''
> Eclipse web model
> '''''''''''''''''
> A Web nature should be added to the project.
> Deployment Unit
> '''''''''''''''
> A deployment unit is the set of files that are deployed together. This is
> you have to be able to designate the
> future place of single files and project subtrees inside a deployment unit.
> When you have this, you know what is
> necessary to be deployed together.
> This is followed by the deployment methods:
> - you can make export procedures for deployment units to either jar/war/ear
> or exploded directory format.
> - you can make deployment procedures of jar/war/ear or exploded
> directory-structures into application servers.
> - you may want to integrate parts of the previous two together to directly
> deploy from source to the server. This is
> followed by managing deployment destinations to not to enter data necessary
> to the deployment every time you are
> deploying something. A deployment destination can be a Server instance, or a
> Domain in a cluster.
|
|
|
Goto Forum:
Current Time: Sun Sep 01 02:02:50 GMT 2024
Powered by FUDForum. Page generated in 0.03205 seconds |
] 
Search
Help
Register
Login
Home
