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?

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. 





Back to the top