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?

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.

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

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


Nick Boldt <nickboldt@xxxxxxxxx>


Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>


05/12/2009 12:15 PM


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: for end users 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 * files
would be ignored by the RT site and everything else would go to the SDK

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.



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

Nick Boldt ::
Release Engineer :: Eclipse Modeling & Dash Athena
cross-project-issues-dev mailing list

GIF image

GIF image

Back to the top