search

eclipse-kura / kura

Eclipse Kura™ is a versatile framework to supercharge your edge devices, streamlining the process of configuring your gateway, connecting sensors, and IoT devices to seamlessly collect, process, and send data to the cloud.
https://eclipse.dev/kura/
Eclipse Public License 2.0
499 stars 306 forks source link

Provide P2 repository of Kura on download.eclipse.org #715

Closed ctron closed 10 months ago

ctron commented 7 years ago

We should provide a P2 repository (zipped and unzipped) on download.eclipse.org for Kura.

This can be a manual step after the release has been performed. Of course it should involve as little manual interaction as possible.

dwoodard1 commented 7 years ago

Do we want the P2 on PackageDrone and download.eclipse.org? Is there a reason to have it in both?

ctron commented 7 years ago

No. Let's just have it on download.eclipse.org. It is the proper download location and can be used with the mirror system. The public Package Drone instance is more for use in the build process. It cannot scale like the download infrastructure.

cdealti commented 7 years ago

@ctron @dwoodard1 @MMaiero I'd like to start this discussion.

dwoodard1 commented 7 years ago

So, what is the point of having a hosted P2 repository? As I see it, there are two use cases to consider.

  1. Developer using Kura. For this user, they are likely to either use a plain Maven build or the Kura user workspace. For the former, there are a few public examples of how to do this. We do need to publish Kura artifacts to Maven Central to make this easier, but the Eclipse Nexus repo also works for now. For the latter, the P2 repo is included in the zip. Not sure how the hosted version helps here, other than making the zip file smaller.

  2. Contributor to Kura. For this user, the P2 is created in the build. So, again, why do we need a hosted P2?

I think the real question is do we want to commit fully to a Tycho/PDE environment (features, etc) or use a more traditional Maven based build. There are certainly advantages/disadvantages to both.

cdealti commented 7 years ago

@dwoodard1

For the latter, the P2 repo is included in the zip. Not sure how the hosted version helps here, other than making the zip file smaller.

It's not a valid p2 repo/site. It does not contain p2 metadata. And the user workspace is not installed through any standard Eclipse install method (Oomph installer or from the IDE Help | Install New Software"). Also does not provide any Maven/CI capability. The hosted p2 repo would allow to install the user workspace through standard Eclipse methods. @ctron has already started this work [2], [3] but it's incomplete, basically only the Kura and Kura-Camel APIs are provided.

Contributor to Kura. For this user, the P2 is created in the build. So, again, why do we need a hosted P2?

The p2 repos created building the target-platform project are only good for Tycho but are not a valid "Software Sites" for Eclipse. The Eclipse target definition source of plugins is of type "Directory". If you try to create a new target definition file from the IDE, select "Software Site" as the source of plugins and browse to the above p2 repos, Eclipse will find nothing. The above p2 repos do have p2 metadata but not enough for Eclipse (I believe it's because they do not contain categories/features but only bundles). It works for the build but again, if it was hosted, it could be used by the Kura build and by the user workspace in the same way.

[1] https://github.com/eclipse/kura/wiki/Eclipse-Kura-Developer-Experience#user-workspace [2] https://github.com/eclipse/kura/tree/develop/kura/features [3] https://github.com/eclipse/kura/tree/develop/kura/org.eclipse.kura-p2

dwoodard1 commented 7 years ago

Tried editing my comment, but didn't seem to work.

I understand the limitations of what we currently do. I think the real question is do we want to commit fully to a Tycho/PDE environment (features, etc) or use a more traditional Maven based build. There are certainly advantages/disadvantages to both.

github-actions[bot] commented 10 months ago

This issue is stale because it has been open for 60 days with no activity.

github-actions[bot] commented 10 months ago

This issue was closed because it has been inactive for 14 days since being marked as stale.