[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cross-project-issues-dev] SDK's on Galileo?
|
Not quite sure where to jump in here so I'll pick this post since David
referred to the EclipseRT Target Platform Component category...
In the context of tooling I agree with David's points here. The primary
purpose of the train repos/categories are to ease the
adoption/consumption of Eclipse projects. In fact that is the main
purpose of the train (period). For that purpose the repo need only
contain the executable bits for the tools that people install into their
IDE. This satisfies the traditional Eclipse role as a tooling platform.
As Eclipse has evolved to have a significant runtime story, we have been
faced with the need for delivering the runtime elements to consumers
with the same ease as the tooling. Enter the p2, the PDE Target
Platform provisioning work and the EclipseRT Target Platform Components
category. In the same way that tool users would add function to their
IDE using p2 and the various tooling categories, developers looking to
consume runtime function can use the PDE target provisioning work to add
runtime "SDKs" to their target platform. For this the SDKs need to have
binary and source.
One key aspect is that the SDK features intended for the target need not
be "runtime coherent". That is, they may contain more than any one
person would reasonably want. Or less. So there may not be a
correspondence between these features and what folks would use at
runtime. The point is to make it easy and intuitive to for people ot get
the function in their target. From there they craft their products and
launch configurations and ensure that only what they need is included.
So for example, in Equinox we have taken the approach of supplying just
one feature that is all bundles, features and source produced by
Equinox. This is very easy for developers to consume.
This ease of consumption should spill over into the other repo
contents. Extenders are another group that is interesting. Figuring
out how to get them the resources they need is worthwhile. Perhaps
there is another Target Platform Components category for this stuff? We
should make it easy but not complicate the lives of the mainstream
consumers with too many choices and clutter.
Just my 2c...
Jeff
David M Williams wrote:
I may be missing the exact point of what started this thread, but I can
confirm the original primary intent of the Galileo discovery site is to
make it easy for "end users" of Eclipse to find the tools they need to use
Eclipse, not extend Eclipse. And as such all projects should provide a
"minimum install, non-SDK" feature(s).
We've tried now for two years to figure out what to do about SDK's and the
users that want to extend Eclipse, but no substantial progress yet. We'd
talked about having a separate site, or perhaps s separate category, and
have even started to try and define what an SDK is (see
http://wiki.eclipse.org/SDK_Composition) but have not made a group
decision.
I think since we (Planning Council) have not came up with an agreed-to
definition or an agreed-to common way of handling SDKs, that projects will
have to use their own best judgement. I'd say at a minimum you should
provide the minimum install end-user runtime-type features ... this is
best for those that just want to use Eclipse, say to create a web app, a
php page, a Java program, some models, etc. If Projects believe they
really have enough users that require an SDK, then I'd say it is ok to
also provide an SDK feature, but has others have pointed out, those users
should have the ability to find what they need, after installing the
minimums.
A new, late-breaking alternative might be to consider using the "EclipseRT
Target Platform Components" category for _some_ SDKs and, in some of those
cases, the corresponding "runtime" components, might not even need to be
in a category, per se, just in the repository, since, as one concrete
example, few end-users really have to install "gef" from the discovery
site ... most would just get it automatically as they installed what ever
graphical editor they wanted to use.
Hope this helps clarify the current situation, and where we need to focus
next year.
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
