Restore org.eclipse.ecf.provider.filetransfer.httpclient5.win32

[merks]

• The org.eclipse.ecf.provider.filetransfer.httpclient5.win32 bundle was accidentally removed from
  org.eclipse.ecf.filetransfer.httpclient5.feature.

[eclipse-ecf-bot]

Can one of the admins verify this patch?

[merks]

@scottslewis

Sorry that I made a mistake in my last PR and removed the bundled that is added back by this PR.

I noticed this while trying to update to

https://download.eclipse.org/rt/ecf/3.16.3/site.p2/3.16.3.v20250702-2358

Sorry.

[scottslewis]

@merks you are human too. No problem.

However, even when merged ECF classic will be blocked from releasing next version because of this:

https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/6361#note_4428180

[merks]

The whole sonatype thing is beyond annoying. 😱 Basically shut down a nicely working system to replace it with something that's really not quite ready and doesn't really provide the same useful functionality we've all been using for years.

As described on the helpdesk issue, I did find a workaround for BIRT that's not too horrible, but I'm not sure it works for ECF's approach.

I think the following is the job doing the work:

https://ci.eclipse.org/ecf/job/ecf-github.master.publish-maven-stage-release/

But I can't really see figure out where this URL is configured for the workaround:

[merks]

@scottslewis

I'm not sure there is any reason to hold up merging the PR itself. I expect/fear the Maven publishing is going to require some changes because it's not clear that a service endpoint with the same behavior as before will ever be provided by the new "central service" host; that's beyond our direct control. Also, it's almost impossible to help directly with doing the same thing in a new way with only read permissions. Both @HannesWell and I can offer advice...

The platform is now publishing to a file: location:

https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/6f4265d78136c807704aded9204468bcd296dcac/JenkinsJobs/Releng/deployToMaven.jenkinsfile#L80

And then using the "upload API":

https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/6f4265d78136c807704aded9204468bcd296dcac/JenkinsJobs/Releng/deployToMaven.jenkinsfile#L163-L197

For EMF and BIRT I will likely just let the build produce *.zip that I will upload manually via my personal account because it's only 4 times a year, not so much manual work, and I can see the process in the website.

[scottslewis]

ECF doesn't have resources, and so before doing another release I will be waiting for the maven deploy to be worked out by other projects and/or EF personnel in a public way...that does not require me to spend hours or days restructuring and testing ECF's build. Your willingness to provide help/advice is personally appreciated, but not sufficient.

[merks]

@scottslewis

I think we are at an impasse that needs to be addressed in a constructive way.

The following comment makes it clear that unfortunately Sonatype is not providing a drop-in replacement to enable sign-and-deploy-file:

https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/6361#note_4702308

The following follow-up comment provides a link to what the EF personnel are able to provide as an alternative:

https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/6361#note_4703488

I don't expect further progress on the helpdesk issue, unless you've been lobbying Sonatype behind the scenes to provide what we need?

This begs the question, what alternatives remain for making progress?

I repeat my offer to help and would like to suggest to enable me to help directly on releng. The PR track record seems sufficient for a committer election:

https://github.com/eclipse-ecf/ecf/issues?q=is%3Aopen+is%3Apr+author%3A%40me

[scottslewis]

Please update the feature versions in manifest and pom in this pr...for this feature and other filetransfer features. I've already updated the top-level features to 3.16.4 but not the filetransfer feature versions.

[scottslewis]

@scottslewis

I think we are at an impasse that needs to be addressed in a constructive way.

The following comment makes it clear that unfortunately Sonatype is not providing a drop-in replacement to enable sign-and-deploy-file:

https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/6361#note_4702308

The following follow-up comment provides a link to what the EF personnel are able to provide as an alternative:

https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/6361#note_4703488

I don't expect further progress on the helpdesk issue, unless you've been lobbying Sonatype behind the scenes to provide what we need?

Actually I have. As expected, however, any requests from the actual dev/consumer community (as opposed to funders) is/was fully ignored...not responded to...because why should they listen to the dev community?

This begs the question, what alternatives remain for making progress?

Perhaps paid EF 'technical' personnel...or paid member companies committers, or those promised committers from all the new corporate membership (e.g. Sonatype)? This is kind of a long list now

https://www.eclipse.org/membership/explore-membership/

...modifying/replacing/updating sign-and-deploy-file functionality themselves for a project that they don't own but depend upon (i.e. actual maintenance)? I'm pretty sure the maven source code is available. Call it a 'community benefit' project....oh yeah sorry...EF doesn't have such projects any longer.

Maybe the committer representatives could appeal for additional releng resources for the infrastructure projects being slowly starved out of the community? I'm pretty sure isuch projects are a long and rapidly growing list.

I repeat my offer to help and would like to suggest to enable me to help directly on releng. The PR track record seems sufficient for a committer election:

https://github.com/eclipse-ecf/ecf/issues?q=is%3Aopen+is%3Apr+author%3A%40me

No. You or anyone are, of course, free to update pom.xml and the shell script used for maven deploy:

https://github.com/eclipse-ecf/ecf

I will aid and welcome such contributions.

BTW, I'm planning to release 3.16.4 this week. I will merge this pr prior with the requested additions.

Obviously I will not able to deploy to maven as has been project tradition.

[merks]

It looks like you've been making changes and for this build:

• https://ci.eclipse.org/ecf/job/ecf-github.master.stage-release/36/consoleFull

this part is failing:

Will deploy the following bundles with newer versions:
======================================================
  org.eclipse.ecf.ai.a2a
  org.eclipse.ecf.ai.mcp.tools

mvn --projects org.eclipse.ecf.ai.a2a deploy
Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /opt/tools/apache-maven/3.9.6
Java version: 17.0.2, vendor: Oracle Corporation, runtime: /opt/tools/java/openjdk/jdk-17/17.0.2+8
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "6.7.4-200.fc39.x86_64", arch: "amd64", family: "unix"
[INFO] Scanning for projects...
[ERROR] [ERROR] Could not find the selected project in the reactor: org.eclipse.ecf.ai.a2a @ 
[ERROR] Could not find the selected project in the reactor: org.eclipse.ecf.ai.a2a -> [Help 1]
[ERROR] 

So maybe you are close to success for an alternative that you've discovered...