[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cross-project-issues-dev] SDK's on Galileo?
|
Hi Jeff,
given that target platform components need to be consumed by
a different wizard than updating Eclipse itself, has anyone
ever thought about putting those RT Target Platform stuff into
a separate Repository?
And have that target platform repository auto-populated in
the PDE Targe Platform provisioning wizard, but not in the
p2 update wizard.
While I do understand the role of source bundles in the
target platform category, I still don't quite understand
what we're going to do with the developer docs (*.doc.isv
bundles) since my understanding is that those need to live
in the host Eclipse...
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
> -----Original Message-----
> From: cross-project-issues-dev-bounces@xxxxxxxxxxx
> [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Jeff McAffer
> Sent: Mittwoch, 13. Mai 2009 05:18
> To: Cross project issues
> Subject: 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
> >
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>