[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [spaces-dev] Publishing
|
For people curious about the OBR (and since you're likely to find the
predecessor at Sourceforge if you google for it), here is good link:
http://www2.osgi.org/download/rfc-0112_BundleRepository.pdf
- thomas
Thomas Hallgren wrote:
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
