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

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
> 


Back to the top