“I would like to stress that any
work that goes into WTP, should have something to support some out-of-the-box
WTP functionality. Designing and writing code that will only be used by
external consumers of WTP should belong with the external consumers.”
I would have to strongly disagree with
this statement. For WTP to be successful as a platform, it’s API and
infrastructure has to be flexible enough to support use cases of people
building on top of it. This is one area where we feel it’s not flexible
enough. That is not to say that we should not use it internally. I would love
to see the monolithic features, such as “webapp” be broken up into
smaller features like “servlet”, “jsp”, “html”,
etc. if we have time for that. If we don’t, we should at least lay down
the infrastructure that vendors and following releases of WTP can build on.
I totally agree that this is a major
change and are we very close to the release date. However, we feel that this is
a major outage and is not something that could be easily addressed in a
following release due to API-breaking nature of this change.
- Konstantin
From: wtp-dev-bounces@xxxxxxxxxxx
[mailto:wtp-dev-bounces@xxxxxxxxxxx] On
Behalf Of Naci Dai
Sent: Wednesday, May 11, 2005 7:18
AM
To: General discussion of
project-wide or architectural issues.
Subject: Re: [wtp-dev] flexible
project & server api changes - please review
Reading through the document, I believe these
are valid requirements and the design fits the solution. I have a minor,
and a major issue :-)
1) Features are compared to natures in projects, but belong to modules.
My concern is that we are making a decision to design something into a module
(an abstraction of web/j2ee modules), that will eventually help us build
"features" into modules that will not be supported by all
server runtimes. So far I am ok.
I would like to stress that any work that goes into WTP, should have something
to support some out-of-the-box WTP functionality. Designing, and writing
code that will only be used by external consumers of WTP should belong with the
external consumer, (i.e. a requirement for web module with pollinate feature
is for an external consumer therefore not valid, but web module with
web-service feature is etc.). What this means is we should also use these
features internally for standard functionality.
2) I feel this is a major change - I would like component owners that are
affected by this change to make the decision on accepting the change prior to
R1.0. I am against any major changes late in the process. However, I
cannot fully judge the extent of the changes to say yes or no. The
component owners should judge themselve if they can produce a quality build for
M5, and release for R1. I would like to hear from server, web, j2ee,
web-service and flexible project leads on the effects of this proposed change
and vote go or no-go. We should hold a vote.
Ted Bashor wrote:
The following document describes proposed changes to componentcore and server apis:
http://www.eclipse.org/webtools/development/proposals/Component_Feature_Proposal.html
A couple main objectives:
1) provide a nature-style api on flexible project components
2) less direct coupling of a wtp project and a particular IServerRuntime
Feedback is very welcome. I've gone ahead and opened a set of bugs to track the tasks involved in getting this into m5. These are all pending approval of the api change of course.
IFeature model, extension points - 94608
Integration with componentcore - 94609
feature selection panel - 94610
IRuntime changes - 94611
function group/feature interaction - 94613
Feature definition (large scale features) - 94614
New project wizard work (Features providing DataModels) - 94615
feature lifecycle management - 94616
Structural builder moving to publish tasks - 94617
-- Ted
_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev
--
Naci Dai,
eteration a.s.
Inonu cad. Sumer sok. Zitas D1-15
Kozyatagi, Istanbul 34742
+90 (533) 580 2393 (cell)
+90 (216) 361 5434 (phone)
+90 (216) 361 2034 (fax)
http://www.eteration.com/
mailto:nacidai@xxxxxxx
mailto:naci@xxxxxxxxxxxxx