> 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
>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev