RE: [spaces-dev] Publishing

["Henrik Lindberg" <henrik.lindberg@xxxxxxxxxxxxxx>]

The proposed structure is that a person can have access to spaces via
several spaces accounts, and for each account there can be many spaces.

A space provides publishing areas into which something can be published. 
When publishing, a PublishingType is what publishes the "content" in a
particular form (structure, meta data, etc.). It would be quite messy if a
user decides to puts potentially conflicting types of publishing in the same
publishing area (say en Eclipse update site, and an OBR repository, with a
sprinkle of some jars with manually supplied meta data).

A PublishingArea is defined as a combination of Test/Production, and
Flat/Structured - a space can supply all if wanted. The structured areas are
required to be able to publish things like "an update site" or "an OBR", but
can also hold just a bunch of zip files without any particular structure.
The flat areas can only be used for a bunch of "top level" files. 

So, when a space is implemented as a region of a remove file system, the
account would probably refer to the remote file system as a whole, and each
space is simply a location in this file system if a user where to view it
with some sort of file system browser.

When a space is implemented as some sort of "project" with associated areas,
the account would then typically be the user's account (assuming that a user
has the same identity even if participating in several projects). The
publishing areas could be wildly different; e.g. a flat space could be based
on ftp, and a structured on CVS.

I hope that helps answering the question.

Regards
- Henrik

-----Original Message-----
From: spaces-dev-bounces@xxxxxxxxxxx [mailto:spaces-dev-bounces@xxxxxxxxxxx]
On Behalf Of Thomas Hallgren
Sent: fredag 11 januari 2008 01:13
To: Developer discussions for the Spaces project
Subject: 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
>   

_______________________________________________
spaces-dev mailing list
spaces-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/spaces-dev