Home » Language IDEs » ServerTools (WTP) » Requirements and use cases for web tools
| Requirements and use cases for web tools [message #37211] |
Thu, 05 August 2004 18:20  |
Eclipse User |
|
|
|
Originally posted by: jkrause.w4toolkit.com
Hi,
as a member of the project team I am working on a first draft defining
requirements and use cases for this project.
We would welcome your input, the first themes that we are defining
requirements for are:
- project structure
- JSP editor (editors for structured languages more general)
- server tooling
It would be interesting to see your personal priorities for the
requirements / use cases you send.
Please keep in mind that the web tools project is about creating an
extensible platform and exemplary tools, not only the latter ...
Thank you for your input
Jochen
|
|
| | |
| Re: Requirements and use cases for web tools [message #37317 is a reply to message #37211] |
Thu, 05 August 2004 23:04  |
| Eclipse User |
|
|
|
[project structure]
I like TheElementsOfAntStyle. like this:
build Temporarily used as a staging area for classes and more.
dist Distribution directory.
docs Documentation files stored in their presentation format.
etc Sample files.
lib Project dependencies, typically third party .jar files.
src Root directory of Java source code, package directory structure
below.
src/xdocs Documentation in XML format, to be transformed into
presentation format during the build process.
src/META-INF Metadata for the JAR file.
web Root directory of web content (.html, .jpg, .JSP).
web/WEB-INF Web deployment information, such as web.xml.
But, project structure should be flexible. multiple sourcepath, the name of
web content directory, document files directory, etc.
I prefer to divide source path to three parts: src/java for java source,
src/conf for resources, src/test for test classes
And I want most features like jsp editor, debugging and xml editor to work
independently of eclipse project settings(.project file). Current ibm
contribution code modify existing project, that's not good. Like MyEclipse
plugin, it'll be better that developer can easily add or remove features to
project. And it should be able to build project without eclipse. When
deploying project to real servers in our system, I first checkout project
from cvs repository and build it directly. I don't want to upload project
built in eclipse for some reasons.So, I need any project to be built without
eclipse. Build tool like make, Ant, Maven will be useful. I prefer Maven to
Ant. I Think Ant is bad for describing project structure, it just define
what to do and less powerful than even make.
Server tool is not esential. Most WAS servers provide convenient tool to
deploy, start, stop. And by just using eclipse run setting, that tools can
be used. Priority of this job should be lower.
JSP editor in MyEclipse plugin is very good. I don't think jsp preview is
useful. Highlighting corrently and content assist will be enough. JSP
debugging is needed.
"Jochen Krause" <jkrause@w4toolkit.com> wrote in message
news:ceubnj$age$1@eclipse.org...
> Hi,
>
> as a member of the project team I am working on a first draft defining
> requirements and use cases for this project.
>
> We would welcome your input, the first themes that we are defining
> requirements for are:
>
> - project structure
> - JSP editor (editors for structured languages more general)
> - server tooling
>
> It would be interesting to see your personal priorities for the
> requirements / use cases you send.
>
> Please keep in mind that the web tools project is about creating an
> extensible platform and exemplary tools, not only the latter ...
>
> Thank you for your input
>
> Jochen
|
|
|
| Re: Requirements and use cases for web tools [message #37352 is a reply to message #37211] |
Thu, 05 August 2004 23:20 |
| Eclipse User |
|
|
|
Using your list, I think the first priority should be the structured
language editors. HTML, XML, and JSP are the top three in importance.
Next server tooling. Anything you can do with the old Sysdeo plug-in, you
want the first version of Web Tools to be able to do, only better.
You didn't mention this one but I think that UI scalability needs some love
early on. It feels like the size of context sensitive menus in the Package
explorer doubled in size after I installed the IBM contribution, even when
I'm just doing desktop Java apps. Many of the plug-ins instantiate
themselves at startup time too. WTP should be there when you need it but out
of the way when you don't.
Another requirement I would offer up is that I believe WTP should track 3.1
development, require it, and take advantage of every new feature there as
soon as possible. And in fact, you want to drive new features down *into*
the 3.1 platform at every opportunity. Case in point: the Internet prefernce
page - that should just replace the setting in Install/Update because they
interfere with each other. Another example would be the new content type
framework. Maybe that nice web browser window too, so everybody can stop
reinventing it.
Every project is tempted to work with the previous stable release for as
long as possible, and I totally understand the desire for that from the
project developer's point of view. You want stability, you've got release
deadlines, yada yada. But consider that any WTP early adopters and testers
are more than likely going to be 3.1 early adopters and testers too. For
example I was extremely frustrated that CDT didn't work with the 3.0
milestones for the longest time (remember the typing backwards problem?),
and even now I don't consider it to be fully 3.0 "native". It took a long
time to get "show in" support in there, and it took a long time to get the
new annotation support in, etc.. Please bite the bullet and tie yourself to
the 3.1 schedule and software, eventually you'll be glad you did.
--
Ed Burnette, co-author, Eclipse in Action
www.manning.com/gallardo
www.eclipsepowered.org
"Jochen Krause" <jkrause@w4toolkit.com> wrote in message
news:ceubnj$age$1@eclipse.org...
> We would welcome your input, the first themes that we are defining
> requirements for are:
>
> - project structure
> - JSP editor (editors for structured languages more general)
> - server tooling
|
|
| |
| Re: Requirements and use cases for web tools [message #37420 is a reply to message #37211] |
Fri, 06 August 2004 08:39 |
| Eclipse User |
|
|
|
Originally posted by: jrduncans.stephenduncanjr.com
Project Structure
Must be flexible. We have our structure, and we don't want to change.
That said, our structure isn't that unusual:
Project
src
packages
site
meta-inf
web-inf
supt
css
imgs
inc
js
JSP Editor
Must use JDT preferences for syntax highlighting (All of it! Right now
IBM contribution doesn't do method names). Needs to handle file
includes of other JSP files. We have headers that do most of our import
statements that are shared, sometimes multiple includes, as well as some
useBean statements. This frequently isn't handled well by current JSP
editors, and files are marked with errors even though there are no real
problems. Content assist for Java scriptlets should be at the same
level as the JDT. Handy tools for HTML, CSS, and Javascript are nice
bonuses. Basic syntax highlighting is a necessity though.
As far underlying platform, the ability for future additions of other
language support
Server Tooling
Don't really have a strong interest in this at the moment. Generally
we're fine with using ANT to push our files to our development Tomcat
server for testing, and using the Tomcat provided tools for the
redeploying when necessary, etc. I don't really have a need for Eclipse
support for servers.
-Stephen Duncan Jr
|
|
|
| Re: Requirements and use cases for web tools [message #37489 is a reply to message #37420] |
Fri, 06 August 2004 11:39 |
| Eclipse User |
|
|
|
I like suggest a few things.
Flexible projects structures. I think we've already seen three or more
suggested project structures. I know I have yet another, I'm so do others.
Ed has some very good ideas, so I'll add them to my list. I agree that
we should focus on 3.1 support.
Please coordinate with the pollinate team. We want make sure niether
group is duplicating work.
I'd like see a database perspective. I still feel that this is a project
in and of itself. We should really think about turning it into
subproject or spawning it off. There is no reason to lock this into web
tools project.
Please keep in mind that most developers here are pretty advanced. You
can see this from some of the comments such as, skip server stuff it
trivial. Server support might trivial be to this group, but trust me it
isn't for most people. I also saw request for hibernate, spring and
maven support. I say no to all this ideas! Those communities should
build on top of Eclipse WTP. Most developers wouldn't have a clue
hibernate or the Spring Framework. If we did support them, remember not
everyone is drinking the hibernate, spring or whatever kool-aid. I sure
that some would say why hibernate, why not JDO, ORM, or... you get the
idea. There is already HUGH work here, we don't need to go searching for
more.
This brings up my next thought. Less is more. As I said, this is huge
project. We should look as triming this thing into something more
managable in terms of usablity, resources requirements, size and even
features.
|
|
| | |
| Re: Requirements and use cases for web tools [message #37682 is a reply to message #37489] |
Mon, 09 August 2004 14:00 |
| Eclipse User |
|
|
|
Jeff Duska wrote:
> I like suggest a few things.
> Flexible projects structures. I think we've already seen three or more
> suggested project structures. I know I have yet another, I'm so do others.
Agreed - The more examples the better, this will help us come up with a
"wish-list" of possible structures.
> I'd like see a database perspective. I still feel that this is a project
> in and of itself. We should really think about turning it into
> subproject or spawning it off. There is no reason to lock this into web
> tools project.
I know the IBM contribution didn't contribute any "perspectives", as the
content is still being worked out. Various views and toolbars are
included (Project Navigator). That do contain RDB content.
> Please keep in mind that most developers here are pretty advanced. You
> can see this from some of the comments such as, skip server stuff it
> trivial. Server support might trivial be to this group, but trust me it
> isn't for most people. I also saw request for hibernate, spring and
> maven support. I say no to all this ideas! Those communities should
> build on top of Eclipse WTP. Most developers wouldn't have a clue
> hibernate or the Spring Framework. If we did support them, remember not
> everyone is drinking the hibernate, spring or whatever kool-aid. I sure
> that some would say why hibernate, why not JDO, ORM, or... you get the
> idea. There is already HUGH work here, we don't need to go searching for
> more.
I agree that we need to keep focused on the initial scope of the project,
but I like to hear the advantages/requirements from other tools/frameworks
such as mapping tools from hibernate, and object persistence from Spring -
Especially with EJB 3.0 on the horizon. Maven/Ant build structures are
usually static/fixed structures, and understanding these requirements up
front will help WTP work will various setups.
Thanks - Chuck
|
|
| | | |
| Re: Requirements and use cases for web tools [message #49170 is a reply to message #37386] |
Thu, 14 October 2004 18:06 |
| Eclipse User |
|
|
|
Tomasz Pik wrote:
> Jochen Krause wrote:
>
>> Hi,
>>
>> as a member of the project team I am working on a first draft defining
>> requirements and use cases for this project.
>>
>> We would welcome your input, the first themes that we are defining
>> requirements for are:
>>
>> - project structure
>
>
> I like Maven approach.
> So for war file:
> * project1/src/java/package/goes/Here.java
> * project1/src/webapp/index.html
> * project1/src/webapp/WEB-INF/web.xml
>
> For ejb jar file:
> * project2/src/java/package/goes/Here.java
> * project2/src/ejb/META-INF/ejb-jar.xml
>
> For J2EE ear packages:
> * project3/src/application/META-INF/application.xml
>
> Note, that ear module is separate from war/ejbjar modules.
> It just assembles war/ejbjars created in separate modules.
>
> I think that following maven convention will make an eclipse/maven
> a perfect pair - eclipse for developement and maven for things
> like remote deployment, nightly builds and so on.
>
> Regards,
> Tomek Pik
+1
* Janne Kario
|
|
|
Goto Forum:
Current Time: Sun May 11 14:41:27 EDT 2025
Powered by FUDForum. Page generated in 0.08453 seconds |
Home