[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [spaces-dev] Publishing
|
I think that when something is published, it is offered to a set of
available PublishingTypes - they signal their relevance with respect to what
is being published, and the selected publishing area.
The user can then choose from the relevant types.
My idea was that these publishing types should define the actual structure
in the publishing area to relive the SpaceProvider implementor from having
to implement a growing set of publishing types.
So, I think it is up to a PublishingType to decide if it can coexist with
some other publishing type in the same area.
But, this also opens up another question - should there be server side
support for certain types of repositories? We just found that OBR supports a
query mechanism for instance. Then the simple requirement we have stated
earlier that a publishing area is simply consumed via a URL is perhaps not
true.
- henrik
-----Original Message-----
From: spaces-dev-bounces@xxxxxxxxxxx [mailto:spaces-dev-bounces@xxxxxxxxxxx]
On Behalf Of Thomas Hallgren
Sent: fredag 11 januari 2008 00:28
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
