Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [wtp-dev] flexible project & server api changes - please review

“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

Back to the top