[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [spaces-dev] Publishing
|
I've found the agnostic repository API. It's the Equinox p2
IArtifactRepository. An implementation that supports Eclipse Update
Sites is already in the works and creating another one to support OBR
seems fairly straight forward (I intend to help with this anyway since
it strategically in line with what we want in Buckminster). The bummer
is that the p2 artifact repository doesn't compile with Eclipse 3.3. You
must use Eclipse 3.4.
Ideas, suggestions?
- thomas
Thomas Hallgren wrote:
Henrik Lindberg wrote:
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.
Yes, this was the basis for my reasoning as well. What I'm after is a
special generic OSGi-repository publishing type provided by the spaces
project.
The user has an OSGi bundle that he wants to publish into some
repository that supports a hierarchy (groups and categories). Such a
repository can be represented both in the form of OBR's, Eclipse
Update Sites, and soon also p2 structures. But for the user when he
creates this structured OSGi repository, the underlying implementation
is irrelevant. It's not relevant until someone wants to consume it. So
I see two things here:
1. Ability to manage a structured OSGi repository. This part is
agnostic from the actual implementation.
2. Ability to select what type of consumers that the repository should
support. Might be several.
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.
Well, if we publish an OBR (or federation of OBR's) and the space
provider wants to add query capabilities on top of that as an added
service, what's there to stop them? They way I see it, we don't need
to bother much about that. Not at this point anyway. Someone is bound
to provide a servlet that does this (if it's not in existence already).
- thomas
_______________________________________________
spaces-dev mailing list
spaces-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/spaces-dev
