[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [spaces-dev] Publishing
|
Sorry, bad wording when I said "space equal to one repository". What I
meant was, do a space contain a most one repository or can it have
several? There are some simplifications that can be made if it cannot
hold more then one (naming the repo is not necessary and there's no need
of a list for the user to choose from).
Of course a space should be able to contain other things.
- thomas
Mitch Sonies wrote:
Are you implying that Spaces only hold Eclipse plug-ins, features, etc? As
opposed to anything a developer developed with Eclipse and wants to share
somewhere? My understanding was that there was no such limitation. Maybe
I'm missing something?
||mitch
|-----Original Message-----
|From: spaces-dev-bounces@xxxxxxxxxxx [mailto:spaces-dev-
|bounces@xxxxxxxxxxx] On Behalf Of Thomas Hallgren
|Sent: Thursday, January 10, 2008 6:28 PM
|To: Developer discussions for the Spaces project
|Subject: [spaces-dev] Publishing
|
|I've done some more thinking around publishing and how it is supposed to
|work. In order to make things simple, I think we need to maintain a
|repository. A repository in this case being an Eclipse Update Site or an
|OBR.
|
|One of the goals for Spaces is to simplify. We don't want to force the
|full complexity of plugins, features, and update sites (or OBR's for
|that matter) onto the user. He has a plugin that he wants to make
|available. Click, click. It shouldn't be more complicated than that.
|Ideally, the user right-clicks on a plug-in project, and he clicks
|"Publish", clicks OK in the wizard that pops up, and that's it. The
|default values in the wizard should be such that the plug-in is
|published and readily available.
|
|Some things to consider in order to make it that simple are:
|* Is a space equal to one repository or can it have multiple
|repositories?
|* Do we want to expose Eclipse features at all? If we do, how does that
|relate to OBR?
|* Can one abstract repository be viewed in different concrete ways
|(Eclipse Update Site, OBR, p2, maven) or are they different
|repositories?
|
|Personally, I think it would be ideal if we decide that we use an
|abstraction of a repository for publishing. Depending on settings, the
|actual artifacts created will vary. If the user wants an Eclipse update
|site, that's what it's going to be. If the user wants both that and an
|OBR, fine. Then we create both. This should be transparent to the user.
|He should be able to add or remove repository types whenever he chooses
|to.
|
|For milestone one, I think we should aim for the Eclipse Update site and
|then do OBR or p2 if time permits. The important thing is that we have
|an abstraction in place so that we can extend it.
|
|Some additional thoughts about features:
|* Is a feature in fact an OBR in its own right and the repository a
|federation of OBR's?
|* Do we want a general grouping concept implemented? A feature groups
|other features to any depth. It also groups plug-ins. An update site has
|categories and a feature can belong to multiple categories.
|
|Where do we draw the line between simplicity and functionality?
|
|What do you think?
|
|- thomas
|
|
|_______________________________________________
|spaces-dev mailing list
|spaces-dev@xxxxxxxxxxx
|https://dev.eclipse.org/mailman/listinfo/spaces-dev
_______________________________________________
spaces-dev mailing list
spaces-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/spaces-dev
