[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [wtp-jst-dev] Flexible Project api decisions for R0.7


Chuck,

Thx. There has been a lot of discussion on the design lately and I've just requested feedback from the newsgroup. We should the code as is for WTP 0.7 and give this a high priority for resolution in WTP 1.0 M8.

Arthur Ryman,
Rational Desktop Tools Development

phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@xxxxxxx
intranet: http://labweb.torolab.ibm.com/DRY6/



Chuck Bridgham <cbridgha@xxxxxxxxxx>
Sent by: wtp-jst-dev-bounces@xxxxxxxxxxx

06/30/2005 03:22 PM

Please respond to
J2EE Standard Tools developer discussions

To
J2EE Standard Tools developer discussions <wtp-jst-dev@xxxxxxxxxxx>
cc
Subject
[wtp-jst-dev] Flexible Project api decisions for R0.7






Hello all,


I would like to share our current status, and where we are leaning in regards to the provisional api in R0.7


Since we have learned that the platform is now considering support for flexible projects in R3.2, there are concerns that we are providing api functionality that may go beyond what the platform will provide.

I have been in touch with Kevin Haaland, and we will start working with the platform team in the next couple weeks, with R3.1 now history.


>From what I understand, the api that allows source mappings (IVirtualResource), is most likely to be adopted, or changed by the platform team.  Currently we expose minimal end user tooling that allows

configuration of this mapping.  But, this doesn't preclude someone from using the flexible api to create advanced project folder mappings that include aggregation and composition of multiple source folders.

We are proposing that in M6,  we remove the ability to have more than one source location mapped to a runtime location.  This conservative approach will help us migrate current users to the 3.2 platform solution when ready.


The Component level api, that allows multiple J2EE modules to reside within a single project, is more probable to remain in WTP.  We will continue to support this scheme on a non-default basis, as it was one of the
key initial requirments.  Moving forward though, we do need to also ask the platform and jdt team what the possibilities are of nested projects, or some other way to support multiple classpaths per project.


Obviously, we don't want to change api that is in use during M6, as we need to stabilize the release, not introduce more churn, but we feel the "multiple mapping" api is not being used, and should not effect current users.


I welcome any feedback here


Thanks - Chuck


Rational J2EE Tooling Team Lead
IBM Software Lab - Research Triangle Park, NC
Email:  cbridgha@xxxxxxxxxx
Phone: 919-254-1848 (T/L: 444)
_______________________________________________
wtp-jst-dev mailing list
wtp-jst-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-jst-dev