Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [spaces-dev] Publishing

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



Back to the top