Skip to main content

[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...

Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member

> -----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 
> > 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
> >
> >   
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx

Back to the top