Add a standard osgi repository that includes all equinox bundles #294
Conversation
|
Of course there is no harm do to produce alternative representations. I wonder though who would be the consumers of this? Also, where specifically will this be made available? I'm not sure I understand the SimRel comment either; SimRel (the CBI aggregator) consumes from p2 repositories, as do Equinox applications in general... Maven repositories are quite standard too, and the Equinox bundles are available daily from the follow Maven repository, so they're readily and quickly available: https://repo.eclipse.org/content/repositories/eclipse-snapshots/org/eclipse/platform/ I'm not sure if this is considered a light-weight source... |
I was about to respond similarly. I think it would be better to publish to a maven repository for projects that want to consume the very latest I-Builds in a "standard" way other than the I-Build p2 repository. |
|
@merks Funny enough each time I suggest using maven directly I get "but this requires m2e" or "people are used to http" and there are even people converting maven-p2-repositories to http ones ;-P But guess what, this additional creates a maven deployable artifact that can be consumed from maven and then allows to consume everything from maven, so deploy it to e.g download.eclipse.org would just be a lower barrier point and unless the maven deploy is all setup and to allow to attract some consumers. Nerveless to work efficiently one need some kind of meta-data-repository to consume first, as maven has the drawback that it can only access known artifact coordinates so there is no way to know what artifact on central exports the package |
|
Funny enough, even when artifacts are published to a Maven repository daily, tested that all Maven dependencies resolve, there are still people who look for yet another way to accomplish that same goal. Probably we digress, but is it documented somewhere how this thing converts package imports into Maven dependencies or how it maps onto Maven group/artifact IDs? Is that compatible with what Equinox is currently publishing to Maven? But then I wonder, is Maven even relevant to this new goal? I see the zip file contains a similar/analogous representation to p2. Is this the OBR standard? |
There is a difference between something published on a graceful basis by a larger authority once a day (what would happen if another project broke the build?) on behalf of project versus the project having the power of publishing (and releasing!) its artifacts whenever needed / decided even on every build. So this is not really the same goals.
This has nothing to do with maven so there is no documentation about that, it simply collects all bundles of a build not more or less.
Equinox is not publishing anything to maven directly but if it would it would be compatible because the
Maven is used to build and can be used to deploy it but in general it is not related to the topic per se that's why I mention a "traditional" Http deployment (without any maven reference then) as a first step.
It is https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.repository.html and my long-term goal is to establish this format as a comparable alternative to the vendor specific P2 format, so there will be usable as updatesite, target location in PDE/Tycho/P2 UI ... |
laeubi
force-pushed
the
add_osgi_repository_build
branch
from
845428f
to
a9a8f86
Compare
|
I now have modified the Jenkinsfile to also collect the (http deployable) repository (repository-deploy.zip): https://ci.eclipse.org/equinox/job/equinox/job/PR-294/2/artifact/repository/target/ |
It's not entirely clear why "we" need an alternative, especially for something that impacts so many downstream technologies... |
Because P2 already lacks support for more advanced OSGi techniques and because of its "closed model" is not able to adapt to this and other tools like to use standard documented techniques that are portable. Beside this I don't claimed "we" need it but there are people that like to use modern and flexible techniques even if "we" lacking more and more behind and there was the same discussion long time ago when I first added support for maven-targets and today even "we" use them so it is not completely hopeless anyways ;-) |
laeubi
force-pushed
the
add_osgi_repository_build
branch
from
a9a8f86
to
9a2a2d7
Compare
|
Support for PDE was added here: |
|
Tycho support is here: |
Currently one has to wait until the next release or use the ibuilds composite p2 repository but there is currently no way to fetch latest equinox bundles in a more lightweight way. This uses the new tycho-repositry-plugin to build a standard OSGi repository that could be deployed e.g. as part of the mater verification build.
laeubi
force-pushed
the
add_osgi_repository_build
branch
from
9a2a2d7
to
9575aec
Compare
Currently one has to wait until the next release or use the ibuilds composite p2 repository but there is currently no way to fetch latest equinox bundles in a more lightweight way.
This uses the new tycho-repositry-plugin to build a standard OSGi repository that could be deployed e.g. as part of the mater verification build.
WDYT @akurtakov @tjwatson? The idea would be that we can deploy a standard osgi repository with each master build and possibly even have an automated release build to publish equinox bundles independent from regular release cycles, at best such repository would then even be used as contribution to simrel some time....
But first goal would be to supply something standardized to the outside world without much effort.