RE: [wtp-dev] flexible project & server api changes - please review

["Ted Bashor" <tbashor@xxxxxxx>]

Agree that we need buy in from component/module owners.  And that WTP should include implementations of our api as appropriate.

 

Regarding risk to 1.0, which John also mentioned, I want to echo what Konstantin said, and stress that for 1.0 we could (and probably would) ship with only course grained features which map pretty directly to the existing "component types" and "server types".  Hopefully, the bulk of the work for module, builder, and server implementation owners would just be reorganizing existing code.  Into an api framework that we believe is more flexible and extensible.  (And familiar too, since it basically mimics the role of Nature in a platform project.)

 

A reason we want to push for this in 1.0 despite the late date (assuming we can convince people it's the right way to go), is so that we don't get stuck having to support the current api/model in future WTP releases.

 

-Ted

-----Original Message-----
From: wtp-dev-bounces@xxxxxxxxxxx [mailto:wtp-dev-bounces@xxxxxxxxxxx]On Behalf Of Naci Dai
Sent: Wednesday, May 11, 2005 9:22 AM
To: General discussion of project-wide or architectural issues.
Subject: Re: [wtp-dev] flexible project & server api changes - please review

I do not understand what you disagree with clearly, maybe you can help me understand your issues a little better:

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.

My position is we need to use what we produce in wtp (as some would say, eat our own dog food).  Otherwise, we risk producing abstract concepts that does not have any direct clients in wtp. Unfortunately, third party code that does not get contributed back to wtp cannot be used to validate and test these concepts actively. If we produce APIs for abstract concepts (at least if they do not have their concrete implementations in WTP), it will be hard for the committers to test its validity and suitability.  I do not believe you disagree with any of this.

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.

There are two issues here:. The change request and design is based on a solid need, the question is when and how. We need to hear from the component owners and understand if this will cause major milestone/release date shifts.  I am not in favor of a slip in dates. If we can do them without affecting the dates I am all for it. If they will, we need to review what gets declared API, so that these changes can be incorporated without effecting the consumers of the code after R1.0.  This may also be a good opportunity to have the new teams help in actively contributing to the code with these changes.  If we are going to need time, and this is very critical to have in R1 as API, we need to take it to the PMC and decide if we will reconsider the dates.

Without hearing the assessment of the component owners this will remain a speculation so lets give them a chance.

- 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

_______________________________________________
wtp-dev mailing list
wtp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-dev