Github Organization for eclipse-osgi-technology

Currently the OSGi's technology repo is part of the ordinary OSGi Organization. Because customn implementations we want to create are placed in this osgi organization, we kindly ask to get an own organization for individual implementations that have no spec relations (except being an implementation). We want to avoid mis-understanding for implementations under the organization osgi to treated as preferred impl compared to other implementations out in the world. For that we already have a different maven groupid.

If possible please transfer the following repository directly into this new organization: https://github.com/osgi/jakartarest-osgi/

moved from eclipsefdn/emo-team/emo#815 (moved)

If possible please transfer the following repository directly into this new organization: https://github.com/osgi/jakartarest-osgi/

Eclipse IT team... This repository is an existing Eclipse project repository, no IP review is required to transfer it.

added IT-prioritylow IT-severitylow service:GitHub team:releng labels

assigned to @heurtemattes

added statewip label

@mhoffmannp88 https://github.com/eclipse-osgi-technology has been created. Committers will soon gain access. Tell me when we can plan to move jakartarest-osgi project. After the migration, otterdog will be activated.

You get a go for the migration jakartarest-osgi.

Can you please initially setup these secrets in otterdog?

  secrets+: [
    orgs.newOrgSecret('GITLAB_API_TOKEN') {
      value: "pass:bots/technology.osgi-technology/gitlab.eclipse.org/api-token",
    },
    orgs.newOrgSecret('ORG_GPG_KEY_ID') {
      value: "pass:bots/technology.osgi-technology/gpg/key_id",
    },
    orgs.newOrgSecret('ORG_GPG_PASSPHRASE') {
      value: "pass:bots/technology.osgi-technology/gpg/passphrase",
    },
    orgs.newOrgSecret('ORG_GPG_PRIVATE_KEY') {
      value: "pass:bots/technology.osgi-technology/gpg/secret-subkeys.asc",
    },
    orgs.newOrgSecret('ORG_OSSRH_PASSWORD') {
      value: "pass:bots/technology.osgi-technology/oss.sonatype.org/gh-token-password",
    },
    orgs.newOrgSecret('ORG_OSSRH_USERNAME') {
      value: "pass:bots/technology.osgi-technology/oss.sonatype.org/gh-token-username",
    },
  ],

@mhoffmannp88 repo has been moved to the new org. Meantime, we have to review organization between osgi and osgi-technology.

Bot account for osgi has been created with osgi-technology terminology. This has a impact on OSSRH, project storage,...

And the entry bots/technology.osgi-technology/gitlab.eclipse.org doesn't exist.

Can you check first PMI organization? osgi projects should be under the umbrella of https://projects.eclipse.org/projects/technology.osgi and not https://projects.eclipse.org/projects/technology.osgi-technology

Can you check first PMI organization? osgi projects should be under the umbrella of https://projects.eclipse.org/projects/technology.osgi and not https://projects.eclipse.org/projects/technology.osgi-technology

sorry could you please explain the task again? did not get it

How does the mvn group-id relates to this?

is important that all all bundles must have the group-id org.eclipse.osgitech?

we have the osgi-test project https://github.com/osgi/osgi-test wich is also part of osgi-technology. but currently lives in the osgi organization and hast the group-id org.osgi.

but could make sense to leave this in osgi (has to be discussed)

would it be possible to init the otterdog in this organisation that we are able to structure new repos in meanwhile

sure, I need meantime to take some time to understand the OSGI PMI/Github organization.

we also can have a call with bj hargrave, he should have the best understanding of current state.

Deploying a project's artifact to Maven should not depend on the credentials of an individual. We will create a new set of credentials (a bot user) and ask the Sonatype folks to give it access. This will most likely require approval by @hargrave.

Re: org.eclipse.osgitech groupId, Sonatype won't need my approval since that is a new groupId.

Re: org.osgi groupId, if you will be requesting permission for a new Eclipse account to publish under that groupId, Sonatype may well come to me for approval which I will provide.

removes my wrong words

I think org.eclipse.osgi-technology or org.eclipse.osgi would be better groupIds to use. osgitech is a bit abbreviated.

sorry must fix my words:

org.eclipse.osgitech is not the GroupID

The project jakartarest-osgi uses org.eclipse.osgi-technology.rest

this is possible because org.eclipse.osgi-technology is registers and it seems to be allowed to add something. credentials for that are condigured in jenkins

Project: https://github.com/eclipse-osgi-technology/jakartarest-osgi Artifact: https://mvnrepository.com/artifact/org.eclipse.osgi-technology.rest

But groupId and artifactId are not synced. the artifactId uses the prefix org.eclipse.osgitech.rest

<dependency>
    <groupId>org.eclipse.osgi-technology.rest</groupId>
    <artifactId>org.eclipse.osgitech.rest.jetty</artifactId>
    <version>1.2.3</version>
</dependency>

The OSGi Technology Project uses the groupId org.eclipse.osgi-technology. Our Jenkins instance (https://ci.eclipse.org/osgi-technology/) is already configured for this groupid. We would just keep this groupid. I already switched to build with Jenins to use the new Github organization and the checkout works.

@heurtemattes

since no credentials are new and we can use the existing ones, is there something missing?

Would be nice to have the .eclipsefdn folder to create our setup and other repos.

Created https://github.com/EclipseFdn/otterdog-configs/issues/219

Sorry for the delay, I'm starting the set up of otterdog. This will have an impact on both project_id: technology.osgi and technology.osgi-technology.

For the simple reason that the github.com/osgi otterdog was configured with the project_id technology.osgi-technology.

I will update configurations like this:

• github.com/osgi : project_id: technology.osgi
• github.com/eclipse-osgi-technology : project_id: technology.osgi-technology

NOTE: some projects hosted in github.com/osgi are referenced in technology.osgi-technology https://projects.eclipse.org/projects/technology.osgi-technology/developer

• https://github.com/osgi/osgi-test
• https://github.com/osgi/slf4j-osgi
• https://github.com/osgi/osgi.enroute
• https://github.com/osgi/osgi.enroute.site
• https://github.com/osgi/jakartarest-osgi

What is the status of those projects? Should they be moved to github.com/eclipse-osgi-technology? Or removed from eclipse-osgi-technology PMI and added to technology.osgi PMI configuration?

Hi @heurtemattes,

we discussed:

• https://github.com/osgi/jakartarest-osgi nothing to do - had been migrated to technology.osgi-technology(https://github.com/eclipse-osgi-technology/jakartarest-osgi)

• https://github.com/osgi/osgi-test will stay in technology.osgi(eclipsefdn/emo-team/emo#820)

What i am pretty sure, because it are the demo projects of osgi:

• https://github.com/osgi/osgi.enroute will stay in technology.osgi

• https://github.com/osgi/osgi.enroute.site will stay in technology.osgi

With this we have to discuss:

• https://github.com/osgi/slf4j-osgi

Would be great if we can migrate this in the future to technology.osgi-technology when we open a seperate issue for that

This way nothing has to switch the repo at the moment.

Things in technology.osgi are things in the OSGi Specification Project which means they are (per the charter): specifications, implementations of specifications, or TCKs for specifications.

osgi-test, slf4j-osgi, osgi.enroute were never part of technology.osgi but always part of technology.osgi-technology and should remain so.

Things in technology.osgi are under the Eclipse Specification Development Process. This process has a more complex release process involving the specification committee. Things in technology.osgi-technology are under the more simple Eclipse Development process. This is why we originally created 2 projects for OSGi: spec things and normal open source projects.

technology.osgi must be limited to specifications and TCKs of specifications. Implementations of specifications are welcome but not required to be in technology.osgi. All other OSGi related projects which are not specifications and not TCKs of specifications, such as osgi-test, MUST NOT be in technology.osgi and MUST be in technology.osgi-technology to be under the more simple Eclipse Development Process.

Thank you @hargrave .

I will bring this to the next OSGi Streering Committee Meeting.

What we really want do avoid is that one can push with the credentials of technology.osgi-technology into the groupID org.osgi. This means that we might have to change the group-id of the Projects:

• https://github.com/osgi/osgi-test
• https://github.com/osgi/slf4j-osgi
• https://github.com/osgi/osgi.enroute
• https://github.com/osgi/osgi.enroute.site

@heurtemattes it would be great if you can continue with creating otterdog for technology.osgi-technology without changing the organisation-repos structure we currently have.

This way we re not blocked in the technology.osgi-technology project and can create other projects there.

This means that we might have to change the group-id of the Projects:

That is a huge thing since people will likely cease to see updates through dependabot as they are unaware of new groupId. Certainly for osgi-test and slf4j-osgi. I don't think anyone cares about enroute anymore and there will be probably be no further releases of enroute.

If you go this route, you will want to publish relocations under the org.osgi groupId for each artifact relocated to a new groupId.

i do not like to go this route. But i can´t see how we can give the Project-Leads (and ci) of the technology.osgi-technology project the credentials to deploy to group-id org.osgi whehre all spec and tck part live.

we cant force them from outside to not use names like service,namespace ,util,enterprice , core,resource,annotation.

I agree, that this is not nice and relocation is a must. We discussed all this in last f2f. You may want so join Streering commie meeting an 13.Nov.

otterdog has been enabled for the eclipse-osgi-technology organization. The following repo has been created: https://github.com/eclipse-osgi-technology/.eclipsefdn

You can find the current configuration at https://github.com/eclipse-osgi-technology/.eclipsefdn/blob/main/otterdog/eclipse-osgi-technology.jsonnet A dashboard ui of the configuration can also be accessed at https://eclipse-osgi-technology.github.io/.eclipsefdn/ which also provides a playground to test snippets before making a PR.

When you want to suggest changes, fork the repo, make changes and create a PR. A workflow will automatically run and show you the changes that will be applied and validate that the configuration is correctly formatted and composed.

The documentation of all supported settings can be found here: https://otterdog.readthedocs.io/en/latest/reference/resource-format/

A list of all Eclipse projects that have it also enabled can be accessed here: https://eclipsefdn.github.io/otterdog-configs/ That is often quite helpful to get ideas about others do their configurations.

Otterdog is also deployed as github app and its commands can be invoked from within PR: https://github.com/eclipse-csi/.eclipsefdn/pull/6

If you have any problems let us know.

I'll keep this ticket open until you decide what to do with other projects.

added statereview label and removed statewip label

something that we started for adoptium where also multiple projects are in one GitHub organization, is to setup a custom property for each repo so that you know to which project it belongs, see

the configuration looks something like that:

I can add something like that for osgi also.

Thank you @netomi. This Might help.

But the main issue I see is, that we would still have the problem of sharing maven credentials of group-id org.osgi to both projects.

this way the technology.osgi-technology project following the Eclipse Development process can push a artifact with a name that is owned by the by technology.osgi project that must follow the Eclipse Specification Development Process. (with stricter rules).

It this is no problem for the Eclipse Security Team, it would be great.

bests

in such a case we must not add such credentials as org secret but provision them for each individual repo that is eligible for that.

just to get it right.

you have to add this additional secrets manually, to the projects?

did you fix the issue with maven that you have to set the api-key every 3 months?

so there are 2 ways to provision secrets to repos:

• doing it organization wide and specify which repos should have access to (all or a selection list)
• doing it on a repo directly

An example of a repo secret can be seen here: https://github.com/eclipse-csi/.eclipsefdn/blob/main/otterdog/eclipse-csi.jsonnet#L97

Both methods are used, and it depends on the use-case which one makes more sense. In general org wide secrets should be avoided imho but its convenient ofc.

mentioned in issue eclipsefdn/emo-team/emo#820

@netomi

The OSGi Steering Committee, the OSGi-Specification-Project-Leads and the OSGI-Technology-Project-Leads

Decided that the OSGI-Technology-Project that lives in the wrong GitHub Organisation:

• https://github.com/osgi/osgi-test
• https://github.com/osgi/slf4j-osgi
• https://github.com/osgi/osgi.enroute
• https://github.com/osgi/osgi.enroute.site

Should be migrated to the Github Organisation https://github.com/eclipse-osgi-technology/

The OSGi Steering Committee is also fine with giving the OSGI-Technology-Project access to credentials for the Maven Group-ID: org.osgi.

let me know when the migration can be done, I will then update the configuration and provision the OSSRH related secrets.

you can start.

ftr: this is the mail from the osgi chair of wg steering committee regarding this change: https://www.eclipse.org/lists/osgi-dev/msg00160.html

ok, repos have been transferred and configuration updated.

In the osgi organization there are the following secrets:

• GPG_PRIVATE_KEY
• OSSRH_PASSWORD
• OSSRH_USERNAME

the same secrets already exist in eclipse-osgi-technology but are named with an additional ORG_ prefix. I did not copy over the ones from osgi, so you would have to rename these secrets in the workflows to keep things consistent and not duplicating stuff.

fyi: there is still this repo in the osgi org where osgi-technology has write access to:

https://github.com/osgi/jakartarest-osgi

permissions should be setup in about 2-3 h.

but when visiting: https://github.com/osgi/jakartarest-osgi you will be delegated to https://github.com/eclipse-osgi-technology/jakartarest-osgi and this is where is now should live

cant see a jakartarest-osgi in browser on https://github.com/osgi

great that I asked that, as its then a misconfiguration in the PMI, will clean it up, ty for confirming. was probably forgotten to remove when the repo was transferred.

Good catch,thanks @netomi

Repo migration was done a month ago: #5100 (comment 2833249)