[wtp-jst-dev] Flexible Project api decisions for R0.7

[Chuck Bridgham <cbridgha@xxxxxxxxxx>]

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)