Re: [cross-project-issues-dev] SDK's on Galileo?

[Anthony Hunter <anthonyh@xxxxxxxxxx>]

Since most if not all of the modeling projects involve plug-in development, you need the Eclipse source and documentation. Hence you need the SDK features for the modeling projects.

Cheers...
Anthony
--
Anthony Hunter mailto:anthonyh@xxxxxxxxxx
Software Development Manager: Eclipse Open Source Components
IBM Rational Software: Aurora / GEF / GMF / Modeling Tools
Phone: 613-270-4613


Nick Boldt ---05/12/2009 12:15:03 PM---> 1.) Projects SHOULD provide a runtime feature (no source, no developer > docs)

From:	Nick Boldt <nickboldt@xxxxxxxxx>
To:	Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date:	05/12/2009 12:15 PM
Subject:	Re: [cross-project-issues-dev] SDK's on Galileo?

---

> 1.) Projects SHOULD provide a runtime feature (no source, no developer
> docs)
> 2.) Projects MAY in addition provide an SDK

That's completely the reverse from what I was told by Rich Gronback when 
we first started contributing features to Galileo. I was generating the 
.build file with sdk + runtime features included (as we did for 
Ganymede) and was told that this year, we should include ONLY SDKs. I'm 
glad we've swung the pendulum the other way. :)

--

As to the idea of having a "runtimes only" and a "SDK-heavy" site for 
the two types of users... why not have:

http://download.eclipse.org/releases/galileo/ for end users
http://download.eclipse.org/releases/galileo-sdk/ for extenders

I'd be happy to generate two .build files for the Modeling contributions 
if it would help solve this two-community dichotomy we have every year. 
The BuckyBuilder would have to be mod'd such that all *sdk.build files 
would be ignored by the RT site and everything else would go to the SDK 
site.

Since p2 now defaults to searching a single site (or optionally, all 
sites) for performance reasons it might be nice to have a single 
SDK-heavy site so that users need not enable / add all the individual 
projects sites if they want sources/docs, but can simply select the 
preloaded URL for the SDKs and fetch from there.

Thoughts?

Nick

> Regarding the "SDK's in the RT Target Platform Category" idea, 
> my understanding is that this would work fine for source
> bundles, but the developer docs won't be visible by referencing
> a target platform.
> 
> It may be an interesting enhancement request for next year to 
> allow running a help server based on contents in the TARGET
> platform and not only the development host as it is today.
> 
> 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 David M Williams
>> Sent: Dienstag, 12. Mai 2009 09:17
>> To: Cross project issues
>> Subject: 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. 
>>
>>
>>
>> _______________________________________________
>> 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

-- 
Nick Boldt :: http://wiki.eclipse.org/User:Nickb
Release Engineer :: Eclipse Modeling & Dash Athena
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev