Home » Language IDEs » ServerTools (WTP) » Requirements Overview Draft posted
| Requirements Overview Draft posted [message #39281] |
Tue, 17 August 2004 12:08  |
Eclipse User |
|
|
|
Originally posted by: jkrause.w4toolkit.com
A first draft document of requirements to the web tools project has been
posted on
http://www.eclipse.org/webtools/development/requirements/req uirements.html
This is work in progress, not a final document! We would like to
encourage you to give us your feedback here in the newsgroup to drive
your requirements into our development plans.
As described earlier (and in the document) we center our requirements
and use case gathering at the moment around the areas of:
Structured editing (HTML, JSP, CSS, ...)
Server Tooling (start, stop, deploy, ...)
Project layout (flexible project structure)
We will provide a further revision of the document above on August 24th
and would be glad to integrate your input.
Other areas of work on our side include:
- define a template for use cases
- provide a sample use case
- prioritize requirements
- rewrite the requirements for the flexible project layout
Regards
Jochen
WTP Requirements Group
|
|
|
| Re: Requirements Overview Draft posted [message #39343 is a reply to message #39281] |
Tue, 17 August 2004 14:28  |
| Eclipse User |
|
|
|
In requards to Project Structure. I really don't like it being
defined. That's why I've stayed away from the stuff currently
available.
Take a look at the JBossIDE deployer. With that you can define where
everything comes from. That how it uses Ant to build war/ear files.
How about doing something similar with the Webtools project.
On Tue, 17 Aug 2004 18:08:34 +0200, Jochen Krause
<jkrause@w4toolkit.com> wrote:
>A first draft document of requirements to the web tools project has been
>posted on
>
> http://www.eclipse.org/webtools/development/requirements/req uirements.html
>
>This is work in progress, not a final document! We would like to
>encourage you to give us your feedback here in the newsgroup to drive
>your requirements into our development plans.
>
>As described earlier (and in the document) we center our requirements
>and use case gathering at the moment around the areas of:
>
>Structured editing (HTML, JSP, CSS, ...)
>Server Tooling (start, stop, deploy, ...)
>Project layout (flexible project structure)
>
>We will provide a further revision of the document above on August 24th
>and would be glad to integrate your input.
>
>Other areas of work on our side include:
>- define a template for use cases
>- provide a sample use case
>- prioritize requirements
>- rewrite the requirements for the flexible project layout
>
>Regards
>
>Jochen
>WTP Requirements Group
|
|
| |
| Re: Requirements Overview Draft posted [message #39497 is a reply to message #39343] |
Wed, 18 August 2004 05:51 |
| Eclipse User |
|
|
|
Hello,
I definitly agree with this comment.
Imposing a project structure is, IMHO, a major defect that WTP should avoid.
It implies two problems:
- Most of project teams define project structure as a part of their
quality assurance processes (this can even be a part of a company-wide
quality assurance plan) according to their needs. Having to comply with
a tool's project structure needs might prevent a great number of teams
from using the WTP, as it might already be the case for most of existing
tools. Complying with tool's project structure is not always an viable
option.
- If the tool needs a specific project structure, the cost to migrate
from the old structure of a project to the structure needed by the tool
might prevent most of existing project teams to ever use the WTP. I
tried using Lomboz and WSAD with one of our projects. It is almost
impossible without heavy modification of the project's structure.
Jean
Tom wrote:
> In requards to Project Structure. I really don't like it being
> defined. That's why I've stayed away from the stuff currently
> available.
>
> Take a look at the JBossIDE deployer. With that you can define where
> everything comes from. That how it uses Ant to build war/ear files.
>
> How about doing something similar with the Webtools project.
>
> On Tue, 17 Aug 2004 18:08:34 +0200, Jochen Krause
> <jkrause@w4toolkit.com> wrote:
>
>
>>A first draft document of requirements to the web tools project has been
>>posted on
>>
>> http://www.eclipse.org/webtools/development/requirements/req uirements.html
>>
>>This is work in progress, not a final document! We would like to
>>encourage you to give us your feedback here in the newsgroup to drive
>>your requirements into our development plans.
>>
>>As described earlier (and in the document) we center our requirements
>>and use case gathering at the moment around the areas of:
>>
>>Structured editing (HTML, JSP, CSS, ...)
>>Server Tooling (start, stop, deploy, ...)
>>Project layout (flexible project structure)
>>
>>We will provide a further revision of the document above on August 24th
>>and would be glad to integrate your input.
>>
>>Other areas of work on our side include:
>>- define a template for use cases
>>- provide a sample use case
>>- prioritize requirements
>>- rewrite the requirements for the flexible project layout
>>
>>Regards
>>
>>Jochen
>>WTP Requirements Group
>
>
|
|
|
| Re: Requirements Overview Draft posted [message #39528 is a reply to message #39497] |
Wed, 18 August 2004 06:21 |
| Eclipse User |
|
|
|
Originally posted by: thomas.hallgren.frameworx.com
I agree it would be bad if WTP locked in on *one* structure. But isn't
this project about defining how different well known structures, such as
the EAR, can be mapped to arbitrary file system structures?
Instead of saying, "the java packages must go here" for an EAR, you
provide a mapping mechanism so that the code can be browsed using the
well known EAR structure (i.e. an EAR browser). Same thing of course for
WAR's and EJB's.
This will give a semantic significans to the source. It is important
that Eclipse knows in what scope the code is operating. Within an EAR,
the ClassLoaders defined for that EAR defines the scope for the code in
runtime. It would be extremely nice if that could be emulated during
development also. In the long run, code changes will perhaps trigger
redeployment of EJB's EAR's etc.
Regards,
Thomas Hallgren
Jean Couillaud wrote:
> Hello,
>
> I definitly agree with this comment.
> Imposing a project structure is, IMHO, a major defect that WTP should
> avoid.
> It implies two problems:
> - Most of project teams define project structure as a part of their
> quality assurance processes (this can even be a part of a company-wide
> quality assurance plan) according to their needs. Having to comply with
> a tool's project structure needs might prevent a great number of teams
> from using the WTP, as it might already be the case for most of existing
> tools. Complying with tool's project structure is not always an viable
> option.
> - If the tool needs a specific project structure, the cost to migrate
> from the old structure of a project to the structure needed by the tool
> might prevent most of existing project teams to ever use the WTP. I
> tried using Lomboz and WSAD with one of our projects. It is almost
> impossible without heavy modification of the project's structure.
>
> Jean
>
> Tom wrote:
>
>> In requards to Project Structure. I really don't like it being
>> defined. That's why I've stayed away from the stuff currently
>> available.
>>
>> Take a look at the JBossIDE deployer. With that you can define where
>> everything comes from. That how it uses Ant to build war/ear files.
>> How about doing something similar with the Webtools project.
>>
>> On Tue, 17 Aug 2004 18:08:34 +0200, Jochen Krause
>> <jkrause@w4toolkit.com> wrote:
>>
>>
>>> A first draft document of requirements to the web tools project has
>>> been posted on
>>>
>>> http://www.eclipse.org/webtools/development/requirements/req uirements.html
>>>
>>>
>>> This is work in progress, not a final document! We would like to
>>> encourage you to give us your feedback here in the newsgroup to drive
>>> your requirements into our development plans.
>>>
>>> As described earlier (and in the document) we center our requirements
>>> and use case gathering at the moment around the areas of:
>>>
>>> Structured editing (HTML, JSP, CSS, ...)
>>> Server Tooling (start, stop, deploy, ...)
>>> Project layout (flexible project structure)
>>>
>>> We will provide a further revision of the document above on August
>>> 24th and would be glad to integrate your input.
>>>
>>> Other areas of work on our side include:
>>> - define a template for use cases
>>> - provide a sample use case
>>> - prioritize requirements
>>> - rewrite the requirements for the flexible project layout
>>>
>>> Regards
>>>
>>> Jochen
>>> WTP Requirements Group
>>
>>
>>
|
|
| |
| Re: Requirements Overview Draft posted [message #39590 is a reply to message #39528] |
Wed, 18 August 2004 09:09 |
| Eclipse User |
|
|
|
I am sorry I was explaining what I think is a bad idea without
explaining what would be a good one.
It seems mandatory, of course, to let the WTP know what is the scope and
the meaning of the files in the project tree.
The idea of conceiving a scalable mapping mechanism (as you and tom
told) seems really interesting.
The EAR structure, seems to be almost always used at the delivery stage.
However, it is sometimes used at the very end of the building process
after some processing that could be hard to reproduce within the WTP
with an incremental builder for instance.
That said, I am a junior J2EE developer, I just wanted to express my
point, I am sure some J2EE guru already has the ultimate solution(s) ;)
Thomas Hallgren wrote:
> I agree it would be bad if WTP locked in on *one* structure. But isn't
> this project about defining how different well known structures, such as
> the EAR, can be mapped to arbitrary file system structures?
>
> Instead of saying, "the java packages must go here" for an EAR, you
> provide a mapping mechanism so that the code can be browsed using the
> well known EAR structure (i.e. an EAR browser). Same thing of course for
> WAR's and EJB's.
>
> This will give a semantic significans to the source. It is important
> that Eclipse knows in what scope the code is operating. Within an EAR,
> the ClassLoaders defined for that EAR defines the scope for the code in
> runtime. It would be extremely nice if that could be emulated during
> development also. In the long run, code changes will perhaps trigger
> redeployment of EJB's EAR's etc.
>
> Regards,
>
> Thomas Hallgren
>
> Jean Couillaud wrote:
>
>> Hello,
>>
>> I definitly agree with this comment.
>> Imposing a project structure is, IMHO, a major defect that WTP should
>> avoid.
>> It implies two problems:
>> - Most of project teams define project structure as a part of their
>> quality assurance processes (this can even be a part of a company-wide
>> quality assurance plan) according to their needs. Having to comply
>> with a tool's project structure needs might prevent a great number of
>> teams from using the WTP, as it might already be the case for most of
>> existing tools. Complying with tool's project structure is not always
>> an viable option.
>> - If the tool needs a specific project structure, the cost to migrate
>> from the old structure of a project to the structure needed by the
>> tool might prevent most of existing project teams to ever use the WTP.
>> I tried using Lomboz and WSAD with one of our projects. It is almost
>> impossible without heavy modification of the project's structure.
>>
>> Jean
>>
>> Tom wrote:
>>
>>> In requards to Project Structure. I really don't like it being
>>> defined. That's why I've stayed away from the stuff currently
>>> available.
>>>
>>> Take a look at the JBossIDE deployer. With that you can define where
>>> everything comes from. That how it uses Ant to build war/ear files.
>>> How about doing something similar with the Webtools project.
>>>
>>> On Tue, 17 Aug 2004 18:08:34 +0200, Jochen Krause
>>> <jkrause@w4toolkit.com> wrote:
>>>
>>>
>>>> A first draft document of requirements to the web tools project has
>>>> been posted on
>>>>
>>>> http://www.eclipse.org/webtools/development/requirements/req uirements.html
>>>>
>>>>
>>>> This is work in progress, not a final document! We would like to
>>>> encourage you to give us your feedback here in the newsgroup to
>>>> drive your requirements into our development plans.
>>>>
>>>> As described earlier (and in the document) we center our
>>>> requirements and use case gathering at the moment around the areas of:
>>>>
>>>> Structured editing (HTML, JSP, CSS, ...)
>>>> Server Tooling (start, stop, deploy, ...)
>>>> Project layout (flexible project structure)
>>>>
>>>> We will provide a further revision of the document above on August
>>>> 24th and would be glad to integrate your input.
>>>>
>>>> Other areas of work on our side include:
>>>> - define a template for use cases
>>>> - provide a sample use case
>>>> - prioritize requirements
>>>> - rewrite the requirements for the flexible project layout
>>>>
>>>> Regards
>>>>
>>>> Jochen
>>>> WTP Requirements Group
>>>
>>>
>>>
>>>
|
|
| | |
| Re: Requirements Overview Draft posted [message #40084 is a reply to message #39559] |
Fri, 20 August 2004 09:54 |
| Eclipse User |
|
|
|
I would like to suggest a method of separating the deployment so that each
vendor could add a plugin to allow deployment to their architecture. Thus
WSAD would provide a Websphere deployment plugin and Weblogic could provide
there own deployment plugin. One implication of this is that the WebTools
project should reduce its dependence on things like WAR files and EAR files
because these become deployment options and not project options.
The other thing this allows is for a simple webapp deployment to Tomcat vs a
complex webapp deployment to websphere. It also allows each vendor to
provide their own ways to manipulate the web.xml files.
"Dave Gabol" <davegabol@eircom.net> wrote in message
news:cfvdsj$eoj$1@eclipse.org...
>
> Hi,
>
> > This is work in progress, not a final document! We would like to
> > encourage you to give us your feedback here in the newsgroup to drive
> > your requirements into our development plans.
>
> I haven't noticed support for Servlets included anywhere, unless it's
> assumed under "deply enterprise application". I'd like to see the ability
to
> code, deploy/undeploy and (particularly) debug Servlets **easily**.
>
> I also disagree with the comments made that deploying stuff using Ant etc
> makes deployer tools unecessary. It depends on the target audience. If you
> want to attract new programmers then you need to make things easy for
them.
> Don't make the same mistake as J2EE and build in complexity or reliance on
> knowledge of other tools. It will have to be corrected later to attract
> casual or new users (like J2EE or the Sun developer tools). I know this is
a
> community of developers that are deep into J2EE etc., but don't forget we
> are doing this for everyone. I personally only have a cursory knowledge
of
> EJB technology, and I know if I only had the same level of knowledge of
> other J2EE technologies I would like a simple way to work with them.
>
> All the best,
>
> Dave.
>
>
|
|
|
Goto Forum:
Current Time: Sat May 17 01:06:53 EDT 2025
Powered by FUDForum. Page generated in 0.08838 seconds |
Home