[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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