Re: [cross-project-issues-dev] Eclipse IDE 2024-06 Project Participation Page

[Matthias Sohn via cross-project-issues-dev]

On Thu, May 23, 2024 at 10:42 PM Wayne Beaton via cross-project-issues-dev <
cross-project-issues-dev@eclipse.org> wrote:

> I have applied all of the updates. There's an anomaly in the system
> related to the recent upgrade of the PMI that required a little more
> mechanical work than usual to apply these updates, so there is some chance
> that I may have messed something up. If you notice something, let me know.
>

You missed to update JGit which will ship 6.10.0 not 6.9.0

AFAICT (based on what I'm seeing in the simrel.build Git repository), this
> release marks the return of the Eclipse Papyrus project to the simultaneous
> release. Welcome back.
>
> Please let me know if there are any other issues.
>
> If you require a review, please reach out to the EMO.
>
> Wayne
>
> On Wed, 22 May 2024 at 17:56, Wayne Beaton <
> wayne.bea...@eclipse-foundation.org> wrote:
>
>> Greetings folks!
>>
>> I've assembled the release information for participating projects here
>> .
>>
>> Note that the list of projects reflects our long time practice of only
>> including projects whose teams are actively participating in the
>> simultaneous release. If you look hard enough, you'll notice that projects
>> that have been "sponsored in" by participating projects are absent from the
>> list. This is per the requirements. I expect that these requirements will
>> change in some future release.
>>
>> A lot of the releases are quite old, and based on the activity in the
>> simrel.build 
>> repository,  at least a few projects need to create some release records,
>> and some may need to engage in a progress review (I've done my usual thing
>> of making by best guess based on the release records in the system).
>>
>> If your project is contributing a different release than what you see
>> here, please ensure that you've created a release record
>> , and
>> let me know. If your project has not engaged in a progress (or release)
>> review  in
>> more than one year, please engage with the EMO ASAP to schedule a review.
>>
>> Be sure to set the New and Noteworthy URL in your release record: it is
>> through this relationship that we build the aggregate N
>>
>> Please make sure that you've made your best effort to engage in the IP
>> Due Diligence Process for all third party content before you engage with
>> the EMO for review. Bear in mind that you should be engaging in the IP
>> Due Diligence Process
>>  on an
>> ongoing basis and that all releases (regardless of whether or not they
>> correspond with a progress or release review) must only contain content
>> that has been vetted through the due diligence process. With the Eclipse
>> Dash License Tool  and the
>> ability to use it to automatically create review requests, it should be 
>> *easier
>> than ever* before to engage (the README has extensive information on how
>> to engage, and does include some pointers for using it with Eclipse Tycho
>> -based builds).
>> Connect with the EMO if you need assistance.
>>
>> Here are some things that I've observed:
>>
>> Eclipse Client Platform has been removed.
>>
>> The aggrcon files for the following projects are disabled; if any of
>> these projects are dropping from the release, please let me know:
>>
>>- Eclipse Xpand
>>- Eclipse BPMN2 Modeler Project
>>- Eclipse RCPTT
>>
>> Let me know what I've missed.
>>
>> Thanks,
>>
>> Wayne
>> --
>>
>> Wayne Beaton
>>
>> Director of Open Source Projects | Eclipse Foundation
>>
>>
>> My working day may not be your working day! Please don’t feel obliged to
>> read or reply to this e-mail outside of your normal working hours.
>>
>
>
> --
>
> Wayne Beaton
>
> Director of Open Source Projects | Eclipse Foundation
>
>
> My working day may not be your working day! Please don’t feel obliged to
> read or reply to this e-mail outside of your normal working hours.
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse IDE 2024-06 Project Participation Page

[Matthias Sohn via cross-project-issues-dev]

On Wed, May 22, 2024 at 11:56 PM Wayne Beaton via cross-project-issues-dev <
cross-project-issues-dev@eclipse.org> wrote:

> Greetings folks!
>
> I've assembled the release information for participating projects here
> .
>

JGit and EGit will contribute 6.10.0 to 2024-06


> Note that the list of projects reflects our long time practice of only
> including projects whose teams are actively participating in the
> simultaneous release. If you look hard enough, you'll notice that projects
> that have been "sponsored in" by participating projects are absent from the
> list. This is per the requirements. I expect that these requirements will
> change in some future release.
>
> A lot of the releases are quite old, and based on the activity in the
> simrel.build 
> repository,  at least a few projects need to create some release records,
> and some may need to engage in a progress review (I've done my usual thing
> of making by best guess based on the release records in the system).
>
> If your project is contributing a different release than what you see
> here, please ensure that you've created a release record
> , and
> let me know. If your project has not engaged in a progress (or release)
> review  in
> more than one year, please engage with the EMO ASAP to schedule a review.
>
> Be sure to set the New and Noteworthy URL in your release record: it is
> through this relationship that we build the aggregate N
>
> Please make sure that you've made your best effort to engage in the IP Due
> Diligence Process for all third party content before you engage with the
> EMO for review. Bear in mind that you should be engaging in the IP Due
> Diligence Process
>  on an ongoing
> basis and that all releases (regardless of whether or not they correspond
> with a progress or release review) must only contain content that has been
> vetted through the due diligence process. With the Eclipse Dash License
> Tool  and the ability to use it
> to automatically create review requests, it should be *easier than ever*
> before to engage (the README has extensive information on how to engage,
> and does include some pointers for using it with Eclipse Tycho
> -based builds).
> Connect with the EMO if you need assistance.
>
> Here are some things that I've observed:
>
> Eclipse Client Platform has been removed.
>
> The aggrcon files for the following projects are disabled; if any of these
> projects are dropping from the release, please let me know:
>
>- Eclipse Xpand
>- Eclipse BPMN2 Modeler Project
>- Eclipse RCPTT
>
> Let me know what I've missed.
>
> Thanks,
>
> Wayne
> --
>
> Wayne Beaton
>
> Director of Open Source Projects | Eclipse Foundation
>
>
> My working day may not be your working day! Please don’t feel obliged to
> read or reply to this e-mail outside of your normal working hours.
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] How to remove contents from https://repo.eclipse.org/#welcome ?

[Matthias Sohn via cross-project-issues-dev]

On Fri, Mar 22, 2024 at 3:54 PM LORENZO Vincent via
cross-project-issues-dev  wrote:

> Hello everybody,
>
> I would like to know if there is a way to remove contents pushed on
> https://repo.eclipse.org/#welcome.
>

Don't know.
You can file a ticket at the helpdesk to get help from the Eclipse IT team.
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues

-Matthias


>
>
> Thank you for your help.
>
> --
>
> Vincent Lorenzo
>
>
>
>
>
>
>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Fwd: EGit M3 contributing late

[Matthias Sohn via cross-project-issues-dev]

I had sent this email to the wrong list.

-- Forwarded message -
From: Matthias Sohn 
Date: Wed, Feb 21, 2024 at 10:24 PM
Subject: EGit M3 contributing late
To: Orbit Developer discussion 


I will need some more time to get the M3 contribution for EGit built.
First I had issues with ClearlyDefined rate limits and now the lucene
feature which was still available yesterday when I updated EGit to use it
has a new version. So I have to update the version EGit uses once more.

yesterday I updated to
org.eclipse.orbit.maven.lucene.feature.group
[4.31.0.v20240130-0800,4.31.0.v20240130-0800]
now it is
org.eclipse.orbit.maven.lucene.feature.jar
 [4.31.0.v20240221-0830,4.31.0.v20240221-0830]

-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] ACTION REQUIRED: Acceleo, Sirius, EMF Compare, CDO, GEF 5, RCPTT

[Matthias Sohn via cross-project-issues-dev]

It looks like antlr 4.7 contians a proper OSGi MANIFEST.MF
https://repo1.maven.org/maven2/org/antlr/antlr4-runtime/4.7.2/

Hence I think it should be possible to add this as a Maven dependency to
your target platform similar
to how we started doing that in JGit in this change:
https://eclipse.gerrithub.io/c/eclipse-jgit/jgit/+/201348

-Matthias

On Mon, Nov 20, 2023 at 10:49 AM Laurent Goubet via
cross-project-issues-dev  wrote:

> Hello Ed,
>
> You've raised issues for the Guava versions, but I expect you're trying to
> get rid of all duplicates.
>
> From what I'm seeing, you've removed the 4.7 version of antlr from the
> latest orbit build -
> https://download.eclipse.org/tools/orbit/simrel/orbit-aggregation/2023-12/
> which only contains antlr 4.13. This version is not used by anyone
> according to
> https://download.eclipse.org/staging/2023-12/buildInfo/archive/download.eclipse.org/staging/2023-12/
> . Moving from one version of antlr to the next is not a trivial task, so I
> (and probably the other users of antlr 4.7), would like to avoid that.
>
> You mention that "The 4.x versions are available as OSGi bundles" (
> https://github.com/eclipse-orbit/orbit-simrel/commit/85f7256abe6b90f023de4bfabb09f1416f100a67).
> What does that mean?
>
> Now, what I'm planning to do for Acceleo is to retrieve antlr from the
> older orbit (2023-09), so there will remain older versions of that
> dependency in 2023-12 RC1.
>
> With how orbit looks now, what is the expectation for dependencies such as
> antlr which are not easily updateable? How do we re-add older versions if
> we need them?
>
> Regards,
> Laurent
> Le 17/11/2023 à 11:46, Ed Merks via cross-project-issues-dev a écrit :
>
> I now have a first hit list.  Old guava versions will be eliminated:
>
> https://github.com/eclipse-simrel/simrel.build/issues/80
>
> If you do not eliminate all dependencies on older versions of guava via an
> updated contribution, then I reserve the option, and am likely to excise
> the option, to disable your contribution, without further notification.
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> --
>
> *Laurent Goubet*
> Consultant
> +33 2 51 13 51 42
>
> 
>
> 7 Boulevard Ampère - Carquefou - France
> *obeo.fr*  | *twitter*
>  | *linkedin*
> 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] classpath errors caused by dash license-tool-plugin ?

[Matthias Sohn]

It seems commit
https://github.com/eclipse/dash-licenses/commit/338c666ba87aecf8d34cfee5b02ee3209b78e091

of the license-tool-plugin causes classpath errors in JGit builds.

See https://github.com/eclipse/dash-licenses/issues/232

-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Access to org.eclipse.simrel.build

[Matthias Sohn]

Fetching using https from
https://git.eclipse.org/r/a/simrel/org.eclipse.simrel.build
works for me


On Wed, Apr 26, 2023 at 11:07 AM Dietrich, Christian <
christian.dietr...@itemis.de> wrote:

> created https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/3053
>
> Vorstand/Board: Jens Wagener (Vors./chairman), Dr. Stephan Eberle,
> Wolfgang Neuhaus, Franz-Josef Schuermann
> Aufsichtsrat/Supervisory Board: Michael Neuhaus (Vors./chairman), Harald
> Goertz, Eric Swehla
> Sitz der Gesellschaft/Registered Office: Am Brambusch 15-24, 44536 Lünen
> (Germany)
> Registergericht/Registry Court: Amtsgericht Dortmund | HRB 20621
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] JGit/EGit contribution to M3 late

[Matthias Sohn]

That would be great, please respin to include our contribution.
I should start contributions earlier, I always run late and then don't spot
which mistakes I did due being tired ;-)

-Matthias

On Thu, Feb 23, 2023 at 11:00 AM Ed Merks  wrote:

> Matthias,
>
> I can respin  without too much effort if you wish.   Jonah won't start the
> EPP builds for a few hours I think, so there is a short runway.  Of course
> RC1 is next week...
>
> Please let me know ASAP if you wish for a respin!
>
> Regards,
> Ed
>
> On 23.02.2023 10:51, Matthias Sohn wrote:
>
> Found the problem and submitted the contribution in simrel repo.
> Apparently too late to reach M3.
>
> On Thu, Feb 23, 2023 at 1:24 AM Matthias Sohn 
> wrote:
>
>> I give up, something is wrong with the egit-stable build and I need some
>> sleep now.
>>
>> On Wed, Feb 22, 2023 at 10:15 PM Matthias Sohn 
>> wrote:
>>
>>> The JGit/EGit contribution for M3 will be late.
>>> I hope I can finish it within the next one or two hours.
>>>
>>
> ___
> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] JGit/EGit contribution to M3 late

[Matthias Sohn]

Found the problem and submitted the contribution in simrel repo.
Apparently too late to reach M3.

On Thu, Feb 23, 2023 at 1:24 AM Matthias Sohn 
wrote:

> I give up, something is wrong with the egit-stable build and I need some
> sleep now.
>
> On Wed, Feb 22, 2023 at 10:15 PM Matthias Sohn 
> wrote:
>
>> The JGit/EGit contribution for M3 will be late.
>> I hope I can finish it within the next one or two hours.
>>
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] JGit/EGit contribution to M3 late

[Matthias Sohn]

I give up, something is wrong with the egit-stable build and I need some
sleep now.

On Wed, Feb 22, 2023 at 10:15 PM Matthias Sohn 
wrote:

> The JGit/EGit contribution for M3 will be late.
> I hope I can finish it within the next one or two hours.
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] JGit/EGit contribution to M3 late

[Matthias Sohn]

The JGit/EGit contribution for M3 will be late.
I hope I can finish it within the next one or two hours.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Should SimRel include updated JustJ

[Matthias Sohn]

On Thu, Sep 22, 2022 at 8:17 AM Ed Merks  wrote:

> Jeff,
>
> Given the regular release schedule of Adoptium/Temurin versions, often
> fixing security-related issues, baking a particular version into each
> release train repository, fixed to the particular version available at that
> time, doesn't seem like the best solution to this problem.  Note too that
> it's highly unlikely the user was just updating 2022-06 but rather from
> something much older that was previously updated to 2022-06 because 2022-06
> shipped with JustJ 17.0.x.
>
> Having an update site that is automatically added by EPP to each package
> and points to the desired current version would seem like a better
> solution.  I vaguely recall having such discussions but obviously we didn't
> conclude that...
>
> There is also a question of which version should a JustJ update site
> specify?  We could use this one:
>
> https://download.eclipse.org/justj/jres/
>
> But that includes the 18.x release and soon the 19.x release.   We
> probably don't want people updating to those.
>
> We could also compose this one:
>
> https://download.eclipse.org/justj/jres/17/updates/release/latest
>
> and update to some future LTS version eventually.
>
> Or maybe we should just compose the above into this site which I believe
> is already automatically added to all EPP packages:
>
> https://download.eclipse.org/releases/latest
>
> That would seem the simplest approach and would address the issue for
> existing installations already...
>
+1, this looks like the best approach

> Regards,
> Ed
>
> On 21.09.2022 23:45, Jeff Johnston wrote:
>
> A user recently opened an issue against JDT UI because they were trying to
> update their 2022-06 Eclipse IDE for Java Developers and it fails because
> the current JustJ they had: 15.0.1 is not sufficient to update components
> which now require Java 17.
>
> While they can manually add the needed JustJ updates site would it not
> make sense to make a JustJ update available automatically for such
> end-users at least in the case where Eclipse increases minimum JVM
> requirements?
>
> -- Jeff J.
>
> ___
> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] 2022-09 Participation

[Matthias Sohn]

JGit and EGit will ship 6.3.0. I will create release records when I am back
from vacation on Sunday.

On Wed 31. Aug 2022 at 05:27, Wayne Beaton <
wayne.bea...@eclipse-foundation.org> wrote:

> Greetings folks!
>
> I've assembled my first pass at the Eclipse IDE 2022-09 participation page
> .
>
> Please have a look to ensure that I've captured the release version of
> your project correctly. If you're contributing a new release, please be
> sure to create the release record.
>
> You may notice that Maven Integration for Web Tools Platform is dropped
> from the project list. That project was terminated and its resources were
> merged into Maven Integration.
>
> Some anomalies that I've noticed:
>
>- The Eclipse Platform release record has not been created yet;
>- Eclipse ACTF's aggrcon is disabled;
>- Eclipse PDT's aggrcon is disabled; and
>- Eclipse DLTK's aggrcon is disabled.
>
> Can a committer from Eclipse Platform please create the release record?
>
> Regarding the disabled contributions... Can a representative from the
> corresponding project committers please let us know if you are engaged
> working on getting these contributions back into an enabled state?
>
> If your project is contributing a new major or minor release to 2022-09
> and you haven't engaged in a release or progress review in the year leading
> up to your release date, please engage with the EMO ASAP.
>
> Remember that, regardless of whether or not a review is required, any
> intellectual property included in any release must be fully vetted. If you
> have not already done so, I recommend that you check out the Eclipse Dash
> License Tool to identify any gaps in the vetting of your third-party
> dependencies; look especially at the Automatic IP Team Review Requests
> 
> feature.
>
> Thanks,
>
> Wayne
> --
>
> Wayne Beaton
>
> Director of Open Source Projects | Eclipse Foundation
>
>
> My working day may not be your working day! Please don’t feel obliged to
> read or reply to this e-mail outside of your normal working hours.
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse BPMN2 - Jenkins Build failed permanently

[Matthias Sohn]

On Fri, May 27, 2022 at 11:01 PM Ralph Soika  wrote:

> Hello Ed,
>
> the build process is not working much better using the correct git repo ;-)
>
> But still I run into another problem regarding the signing plugin
>
> The profile configuration in the pom.xml looks like this:
>
>
> 
> sign
> 
> 
> 
> org.eclipse.tycho.extras
> tycho-pack200a-plugin
> ${tycho-extras-version}
> 
> 
> pack200-normalize
> 
> normalize
> 
> 
> 
> 
>
> 
> org.eclipse.cbi.maven.plugins
> eclipse-jarsigner-plugin
> 1.1.3
> 
> 
> sign
> verify
> 
> sign
> 
> 
> 
> 
>
> 
> org.eclipse.tycho.extras
> tycho-pack200b-plugin
> ${tycho-extras-version}
> 
> 
> pack200-pack
> 
> pack
> 
> 
> 
> 
> 
> 
> 
>
>
> I am using tycho-version 1.3.0
>
> The error message is:
>
>
> *
> 22:52:36* [INFO] *--- tycho-pack200b-plugin:1.3.0:pack (pack200-pack) @ 
> org.eclipse.bpmn2.modeler.help ---
> **22:52:36* [INFO] Pack200 packing jar 
> /home/jenkins/agent/workspace/bpmn2-modeler.nightly/plugins/org.eclipse.bpmn2.modeler.help/target/org.eclipse.bpmn2.modeler.help-1.5.4-SNAPSHOT.jar*22:52:36*
>  [INFO] *22:52:36* [INFO] *--- eclipse-jarsigner-plugin:1.1.3:sign (sign) @ 
> org.eclipse.bpmn2.modeler.help ---
> **22:52:37* [INFO] Signing jar: 
> /home/jenkins/agent/workspace/bpmn2-modeler.nightly/plugins/org.eclipse.bpmn2.modeler.help/target/org.eclipse.bpmn2.modeler.help-1.5.4-SNAPSHOT.jar*22:52:38*
>  May 27, 2022 8:52:38 PM org.apache.http.impl.execchain.RetryExec 
> execute*22:52:38* INFO: I/O exception (java.net.NoRouteToHostException) 
> caught when processing request to {}->http://build.eclipse.org:31338: No 
> route to host (Host unreachable)*22:52:38* May 27, 2022 8:52:38 PM 
> org.apache.http.impl.execchain.RetryExec execute*22:52:38* INFO: Retrying 
> request to {}->http://build.eclipse.org:31338*22:52:41* May 27, 2022 8:52:41 
> PM org.apache.http.impl.execchain.RetryExec execute
> .
>
>
> To be honest I do not know from where the hostname '
> build.eclipse.org:31338' came from and why the Jenkins did not know this
>
> Upgrading the tycho plugin to 2.7.2 as you mentioned before seems not to
> solve the problem. Can it be the version of the eclipse-jarsigner-plugin
> 1.1.3?
>

We use the latest release 1.3.2 of the eclipse-jarsigner-plugin

>
> Regards
>
> Ralph
>
>
>
>
>
>
> On 27.05.22 21:22, Ed Merks wrote:
>
> Ralph,
>
> Your build uses
>
> -Pplatform-2022-06
>
>
> But you have no such profile.  The last profile in the root pom is this
> one for platform-2020-09:
>
> https://git.eclipse.org/c/bpmn2/org.eclipse.bpmn2.git/tree/pom.xml#n187
>
> This is why no eclipse-site property is defined and why the unexpanded
> ${eclipse-site} is used as a URL causing the failure message
>
> Regards,
> Ed
>
>
> On 27.05.2022 20:31, Ralph Soika wrote:
>
> Hello,
>
> thanks for your response. Could it be that using the protocol HTTP instead
> of HTTPS is causing such an issue?
>
> I have now updated the pom and started a new build. Let's see what is
> happening
>
>
> Best regards
>
> Ralph
>
>
> On 27.05.22 19:45, Ed Merks wrote:
>
> Ralph,
>
> Probably it's bad to use Java 8.
>
> *15:46:30* Java version: 1.8.0_202, vendor: Oracle Corporation, runtime: 
> /opt/tools/java/oracle/jdk-8/1.8.0_202/jre
>
>
> I think you'll need to switch to Java 11.  I'm also not sure which version
> of Tycho you are using...  I think it's
>
> 1.7.0
>
> But probably something like 2.7.1 or 2.7.2 would be better.
>
> I don't see where the system property for this is being set.
>
> ${eclipse-site}
>
> I see stuff like this:
>
>   
>   
>   platform-2020-09
>   
>   
>   platform-version-name
>   2020-09
>   
>   
>  

Re: [cross-project-issues-dev] JGit/EGit contribution for M3 might arrive late, https://ci.eclipse.org/egit/ stuck ?

[Matthias Sohn]

The JGit/EGit contribution was submitted and the aggregation build is
running
https://ci.eclipse.org/simrel/job/simrel.runaggregator.pipeline/2047/console

On Wed, May 25, 2022 at 10:14 PM Matthias Sohn 
wrote:

> Now it's moving :-)
> looks like you found another node
>
> On Wed, May 25, 2022 at 10:12 PM Denis Roy <
> denis@eclipse-foundation.org> wrote:
>
>> Surely there is another CentOS 7 node that can be used.  I'll ask around.
>>
>>
>> On 2022-05-25 16:05, Matthias Sohn wrote:
>>
>> The egit milestone build for 2022-06 M3 is stuck with this message
>>
>> *21:46:38*  Still waiting to schedule task*21:46:38*  ‘centos-7-1dlsv 
>> <https://ci.eclipse.org/egit/computer/centos-7-1dlsv/>’ is offline
>>
>>  looks like a Jenkins node is offline.
>>
>>  This may cause the JGit/EGit contribution for M3 arrive late.
>>
>>  -Matthias
>>
>>
>> ___
>> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
>> To unsubscribe from this list, visit 
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>> --
>>
>> *Denis Roy*
>>
>> *Director, IT Services | **Eclipse Foundation*
>>
>> *Eclipse Foundation* <http://www.eclipse.org/>*: The Community for Open
>> Innovation and Collaboration*
>>
>> Twitter: @droy_eclipse
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] JGit/EGit contribution for M3 might arrive late, https://ci.eclipse.org/egit/ stuck ?

[Matthias Sohn]

Now it's moving :-)
looks like you found another node

On Wed, May 25, 2022 at 10:12 PM Denis Roy 
wrote:

> Surely there is another CentOS 7 node that can be used.  I'll ask around.
>
>
> On 2022-05-25 16:05, Matthias Sohn wrote:
>
> The egit milestone build for 2022-06 M3 is stuck with this message
>
> *21:46:38*  Still waiting to schedule task*21:46:38*  ‘centos-7-1dlsv 
> <https://ci.eclipse.org/egit/computer/centos-7-1dlsv/>’ is offline
>
>  looks like a Jenkins node is offline.
>
>  This may cause the JGit/EGit contribution for M3 arrive late.
>
>  -Matthias
>
>
> ___
> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> --
>
> *Denis Roy*
>
> *Director, IT Services | **Eclipse Foundation*
>
> *Eclipse Foundation* <http://www.eclipse.org/>*: The Community for Open
> Innovation and Collaboration*
>
> Twitter: @droy_eclipse
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] JGit/EGit contribution for M3 might arrive late, https://ci.eclipse.org/egit/ stuck ?

[Matthias Sohn]

The egit milestone build for 2022-06 M3 is stuck with this message

*21:46:38*  Still waiting to schedule task*21:46:38*  ‘centos-7-1dlsv
’ is offline


looks like a Jenkins node is offline.


This may cause the JGit/EGit contribution for M3 arrive late.


-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] org.jboss.tools.tycho-plugins:repository-utils:1.7.0 can't be resolved -> did anyone meet this problem ?

[Matthias Sohn]

On Mon, May 16, 2022 at 6:12 PM LORENZO Vincent 
wrote:

> Hi,
>
> Since the 12th of May, we have Papyrus jobs in failure due
> to org.jboss.tools.tycho-plugins:repository-utils which is unailable.
>
> Neither the git contents, neither the job configuration changed these last
> days, so I suppose the problem comes from an external changes but I don’t
> have idea for a solution.
>
>
>
> Please, did anyone already met this error and find a solution ?
>
>
>
> The job in error :
> https://ci.eclipse.org/papyrus/view/Master/job/Papyrus-Master/
>
> The error :
>
> [ERROR] Plugin org.jboss.tools.tycho-plugins:repository-utils:1.7.0 or one of 
> its dependencies could not be resolved: Failed to read artifact descriptor 
> for org.jboss.tools.tycho-plugins:repository-utils:jar:1.7.0: 
> org.jboss.tools.tycho-plugins:repository-utils:pom:1.7.0 failed to transfer 
> from https://repository.jboss.org/ during a previous attempt. This failure 
> was cached in the local repository and resolution is not reattempted until 
> the update interval of org.jboss.tools.tycho-plugins has elapsed or updates 
> are forced. Original error: Could not transfer artifact 
> org.jboss.tools.tycho-plugins:repository-utils:pom:1.7.0 from/to 
> org.jboss.tools.tycho-plugins (https://repository.jboss.org/): transfer 
> failed for 
> https://repository.jboss.org/org/jboss/tools/tycho-plugins/repository-utils/1.7.0/repository-utils-1.7.0.pom,
>  status: 503 Service Unavailable -> [Help 1]
>
> We had similar issues with the EGit build last year and therefore stopped
using org.jboss.tools.tycho-plugins:repository-utils.
If you use this plugin to link associated p2 repos you can replace
that by s
in category.xml, available since tycho 2.4.0:
https://git.eclipse.org/r/c/egit/egit/+/186129

-Matthias


> Thank you for your help.
>
>
>
> Best Regards,
>
> --
>
> Vincent LORENZO
>
> 01-69-08-17-24
>
> CEA Saclay Nano-INNOV
>
> Institut CARNOT CEA LIST
>
> Point Courrier n° 174
>
> 91 191 Gif sur Yvette CEDEX
>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] JGit/EGit contribution for 2022-03 RC1 will be late

[Matthias Sohn]

I submitted the JGit/EGit contribution for 2022-03 RC1, the build is
running now.

On Wed, Mar 2, 2022 at 10:36 PM Matthias Sohn 
wrote:

> Our contribution to RC1 will come late. Might need another hour.
>
> -Matthias
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] JGit/EGit contribution for 2022-03 RC1 will be late

[Matthias Sohn]

Our contribution to RC1 will come late. Might need another hour.

-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Log4j 1.x vulnerability

[Matthias Sohn]

I went ahead and pushed the naive addition of reload4j 1.2.19 disguised as
bundle org.apache.log4j to Orbit
https://git.eclipse.org/r/c/orbit/orbit-recipes/+/190574
feel free to change this if someone finds out how to use EBR to only sign
the upstream artefact.

-Matthias

On Tue, Feb 8, 2022 at 4:04 PM Dirk Fauth via cross-project-issues-dev <
cross-project-issues-dev@eclipse.org> wrote:

> Well, from my point of view the usage of reload4j is the only backwards
> compatible solution. Unfortunately not for every case, e.g. too strict
> version ranges. The solution forward is of course the usage of a log
> wrapper to decouple development from deployment.
>
> Anyhow I don't know how to add a bundle jar signed and unchanged to Orbit.
> I am only aware of the re-bundling via EBR. Doing that will cause a change
> in the jar structure that causes for example logpresso to identify a CVE,
> although it is fixed. Which is actually only an issue in the detection. But
> that was one of the reasons why I contacted the reload4j project to change
> the base to avoid the re-bundling.
>
> Anyone who knows how to only sign and publish to Orbit without
> re-bundling?
>
> Ed Merks  schrieb am Di., 8. Feb. 2022, 15:54:
>
>> Dirk,
>>
>> Thanks.  That's really great!  It would be great for this release cycle
>> if it were jar signed and available from Orbit so that we could ship it
>> with 2022-03...
>>
>> There are people who are concerned:
>>
>>
>> https://www.eclipse.org/forums/index.php/mv/msg/1109656/1849775/#msg_1849775
>>
>> Though I'm not sure if they would consider the problem being fixed in
>> 1.2.19 a fact and even if its a fact if it would be a fact that matters...
>>
>> Regards,
>> Ed
>>
>> On 08.02.2022 15:48, Dirk Fauth via cross-project-issues-dev wrote:
>>
>> Hi,
>>
>> I got in contact with the reload4j team. They changed the
>> Bundle-SymbolicName to org.apache.log4j and fixed several OSGi meta data
>> related issues in the meanwhile. Today they published 1.2.19 which should
>> work as a drop-in replacement in Eclipse based applications where
>> Require-Bundle was used. My local tests worked so far.
>>
>> That said, re-bundling for Orbit should not be necessary as reload4j
>> could directly be consumed via Maven Central.
>>
>> Just wanted to keep you updated.
>>
>> Greez,
>> Dirk
>>
>> Ed Willink  schrieb am Mi., 26. Jan. 2022, 13:47:
>>
>>> Hi
>>>
>>> On 26/01/2022 07:48, Christoph Läubrich wrote:
>>> > Why not using SLF4J in all places and let the user choose the
>>> > implementation with their favorite CVEs?
>>>
>>> Use of SLF4J has been suggested before and so I tried to be a good
>>> Eclipse citizen. My failed attempts are described in:
>>>
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=559532
>>>
>>> If SLF4J is to be used, can someone please ensure that the platform is
>>> fit for purpose and that there is a good tutorial on how to do really
>>> boring logging.
>>>
>>> Regards
>>>
>>> Ed Willink
>>>
>>>
>>> --
>>> This email has been checked for viruses by Avast antivirus software.
>>> https://www.avast.com/antivirus
>>>
>>> ___
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@eclipse.org
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>>
>> ___
>> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
>> To unsubscribe from this list, visit 
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Log4j 1.x vulnerability

[Matthias Sohn]

On Wed, Jan 26, 2022 at 8:48 AM Christoph Läubrich 
wrote:

> I think redirecting logging messages to the eclipse log would better be
> done like SLF4j-osgi [1]
>
> What I really wonder is: Have these project really a hard
> requirement/demand on using especially Log4J(1/2)?
>
> Why not using SLF4J in all places and let the user choose the
> implementation with their favorite CVEs?
>
> It could even be a simrel rules that logging is only done through SLF4J
> we can include the slf4joverX in the platform and SLF4j-osgi as the
> default implementation so everything goes to the eclipse /osgi log.
>

+1
if we go for this solution we need to ensure that the issue with modified
MDC initialization in reload4j
which is mentioned in
https://gerrit-review.googlesource.com/c/gerrit/+/328620
is also addressed in slf4j-osgi


> [1] https://github.com/osgi/slf4j-osgi
>
> Am 26.01.22 um 06:56 schrieb Dietrich, Christian:
> > we at Xtext have already a issue to track it on our side
> > https://github.com/eclipse/xtext/issues/2028
> > 
> >
> > unfortunately Xtext in the current release has require bundle (if i
> > catched them all they should be gone in 2.26.0.M3) but the bigger
> > problem is this one here
> >
> https://github.com/eclipse/xtext-eclipse/blob/ffa3cf77753ebc29687768731a5d45416d2b50f1/org.eclipse.xtext.logging/META-INF/MANIFEST.MF#L5
> > <
> https://github.com/eclipse/xtext-eclipse/blob/ffa3cf77753ebc29687768731a5d45416d2b50f1/org.eclipse.xtext.logging/META-INF/MANIFEST.MF#L5
> >
> >
> > i guess also some downsteam components in simrel would have to pick up a
> > new Xtext release.
> > i am not sure how much time i can spent to "pay attention" in feb and
> > what the webmaster team will break
> > so that i am not sure if it is a good idea to add the new Xtext release
> > to simrel
> >
> > kind regards
> > Christian
> >
> > Vorstand/Board: Jens Wagener (Vors./chairman), Dr. Stephan Eberle,
> > Abdelghani El-Kacimi, Wolfgang Neuhaus, Franz-Josef Schuermann
> > Aufsichtsrat/Supervisory Board: Michael Neuhaus (Vors./chairman), Harald
> > Goertz, Eric Swehla
> > Sitz der Gesellschaft/Registered Office: Am Brambusch 15-24, 44536 Lünen
> > (Germany)
> > Registergericht/Registry Court: Amtsgericht Dortmund | HRB 20621
> >
> > ___
> > cross-project-issues-dev mailing list
> > cross-project-issues-dev@eclipse.org
> > To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Log4j 1.x vulnerability

[Matthias Sohn]

Gerrit recently moved from log4j 1.2 to reload4j [1].
Note that to make this work with slf4j you have to update slf4j to 1.7.33
and add org.slf4j:slf4j-reload4j instead of org.slf4j:slf4j-log4j12 [2] at
runtime.

[1] https://gerrit-review.googlesource.com/c/gerrit/+/328081
[2] https://gerrit-review.googlesource.com/c/gerrit/+/328620

On Wed, Jan 26, 2022 at 8:33 AM Christoph Läubrich 
wrote:

> Creating a fragment tightly couples it to its implementation and thus
> have to scope with its life-time and internal implementation state.
>
> You have two choices:
>
> - make two fragments
> - switch to never dependency and don't care about the old
>
> Am 26.01.22 um 08:30 schrieb Dirk Fauth via cross-project-issues-dev:
> > @Christian
> > Good to hear that you are moving to Import-Package! The fragment in the
> > current configuration can actually not be simply fixed with a drop-in
> > replacement as your version bounds are too strict. With that
> > configuration it won't be ever possible to exchange to a newer bugfix
> > version. I would suggest that you at least change this to [1.2.15,1.3)
> >
> > @Christopher
> > I am fighting the Require-Bundle vs Import-Package discussion for years.
> > There are unfortunately a few use cases in the Eclipse Platform that
> > blocks the clean usage because of split package issues. Still I agree to
> > your statement in general, especially with regards to logging
> > dependencies which is because of SLF4J one of the best examples.
> > But even with Import-Package the fragment issue (e.g. To provide a
> > bundled logging configuration or custom log writer) would fail.
> >
> > Should we have a look at creating a re-bundled reload4j?
> >
> > Dietrich, Christian  > > schrieb am Mi., 26. Jan. 2022,
> 06:56:
> >
> > we at Xtext have already a issue to track it on our side
> > https://github.com/eclipse/xtext/issues/2028
> > 
> >
> > unfortunately Xtext in the current release has require bundle (if i
> > catched them all they should be gone in 2.26.0.M3) but the bigger
> > problem is this one here
> >
> https://github.com/eclipse/xtext-eclipse/blob/ffa3cf77753ebc29687768731a5d45416d2b50f1/org.eclipse.xtext.logging/META-INF/MANIFEST.MF#L5
> > <
> https://github.com/eclipse/xtext-eclipse/blob/ffa3cf77753ebc29687768731a5d45416d2b50f1/org.eclipse.xtext.logging/META-INF/MANIFEST.MF#L5
> >
> >
> > i guess also some downsteam components in simrel would have to pick
> > up a new Xtext release.
> > i am not sure how much time i can spent to "pay attention" in feb
> > and what the webmaster team will break
> > so that i am not sure if it is a good idea to add the new Xtext
> > release to simrel
> >
> > kind regards
> > Christian
> >
> > Vorstand/Board: Jens Wagener (Vors./chairman), Dr. Stephan Eberle,
> > Abdelghani El-Kacimi, Wolfgang Neuhaus, Franz-Josef Schuermann
> > Aufsichtsrat/Supervisory Board: Michael Neuhaus (Vors./chairman),
> > Harald Goertz, Eric Swehla
> > Sitz der Gesellschaft/Registered Office: Am Brambusch 15-24, 44536
> > Lünen (Germany)
> > Registergericht/Registry Court: Amtsgericht Dortmund | HRB 20621
> > ___
> > cross-project-issues-dev mailing list
> > cross-project-issues-dev@eclipse.org
> > 
> > To unsubscribe from this list, visit
> > https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> > 
> >
> >
> > ___
> > cross-project-issues-dev mailing list
> > cross-project-issues-dev@eclipse.org
> > To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] reload4j 1.2.18 fixing pressing issues of log4j 1.2.17

[Matthias Sohn]

The reload4j project [1] is a fork of Apache log4j version 1.2.17 with
the goal of fixing pressing issues. It is intended as a drop-in
replacement for log4j version 1.2.17.

The reload4j project aims to fix the most urgent issues in log4j 1.2.17
which hasn't seen a new release since 2012. Note that on 2022-01-06 the
Apache Logging PMC formally voted to reaffirm the EOL (End of Life)
status of log4j 1.x. Despite best efforts it was therefore impossible to
revive the log4j 1.x project within the Apache Software Foundation.

The first release 1.2.18 of reload4j was released yesterday.

Most notably version 1.2.18 contains the following changes
- remove unused method JNDIUtil.getInitialContext()
- fix CVE-2019-17571 [2]
- fix CVE-2021-4104 [3]

This new version might help all those projects which still depend on log4j
1.x.

[1] https://reload4j.qos.ch/
[2] https://github.com/advisories/GHSA-2qrg-x229-3v8q
[3] https://github.com/advisories/GHSA-fp5r-v3w9-4333

-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [orbit-dev] log4j vulnerability in Eclipse?

[Matthias Sohn]

On Sat, Dec 11, 2021 at 8:36 PM Matthias Sohn 
wrote:

> On Sat, Dec 11, 2021 at 11:35 AM Gunnar Wagenknecht <
> gun...@wagenknecht.org> wrote:
>
>> Alexander,
>>
>> On Dec 11, 2021, at 10:16, Alexander Fedorov <
>> alexander.fedo...@arsysop.ru> wrote:
>> It would be great to learn vulnerability clean-up process with Eclipse
>> Orbit team to then apply it to Eclipse Passage.
>>
>>
>>
>> There is no Orbit team. Orbit is driven by project committers
>> using/needing libraries in Orbit.
>> I encourage the Eclipse Passage project to submit a Gerrit review for a
>> newer version.
>>
>
> considering the buzz around this vulnerability I went ahead and pushed an
> update to log4j 2.15 for orbit
> https://git.eclipse.org/r/c/orbit/orbit-recipes/+/188768
> note that the required clearlydefined score isn't reached yet, if this
> doesn't change soon
> maybe someone can contribute the missing information to clearlydefined or
> we file CQs to get the license approval for the new version
>

since the log4j project published another release 2.16.0 adding more fixes
for CVE-2021-44228
I pushed another update for Orbit:
https://git.eclipse.org/r/c/orbit/orbit-recipes/+/188862
and contributed curations to the corresponding clearlydefined entries


>
>
>> You can also try a new way as described by Mickael here:
>> https://www.eclipse.org/lists/orbit-dev/msg05509.html
>>
>> -Gunnar
>> ___
>> orbit-dev mailing list
>> orbit-...@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/orbit-dev
>>
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [orbit-dev] log4j vulnerability in Eclipse?

[Matthias Sohn]

ke projects automatically aware of
>>> >>> new problems) as they arise, also preventing one from including
>>> >>> problematic dependencies in the future.
>>> >> In the end it at the simplest, it could just be a feature with p2.inf
>>> >> with negative requirements for bundles that have been determined to
>>> >> be unsafe.
>>> >>> What do you think does this sounds reasonable?
>>> >> It's a creative idea.  I like it.
>>> >>> Am 12.12.21 um 14:07 schrieb Ed Merks:
>>> >>>> Alexander,
>>> >>>>
>>> >>>> Will you set the lower bound to force the fixed version and to
>>> >>>> disallow the older version?
>>> >>>>
>>> >>>> If only the installer and its product catalogs were involved, I
>>> >>>> could fix the problem easily by adding an update site and forcing
>>> >>>> the version range to install the fixed version.  I wouldn't even
>>> >>>> need a new version of Passage to force/fix that...
>>> >>>>
>>> >>>> But we're also talking about the release train repository, which
>>> >>>> would need a respin.  Unfortunately there are updates in the SimRel
>>> >>>> repo after the 2021-12 tag:
>>> >>>>
>>> >>>> Some of those will be needed because the
>>> >>>> https://download.eclipse.org/eclipse/updates/4.22-I-builds
>>> >>>> repository is gone.  Hopefully other projects contributed stable
>>> >>>> repositories with unchanging released content rather than pointing
>>> >>>> at "moving target" that has changed its content since the release.
>>> >>>>
>>> >>>> If we decide we need to do a respin and we accomplish that, then
>>> >>>> EPP needs to respin as well.   This will be something the Planning
>>> >>>> Council will need to discuss and to decide which actions to take.
>>> >>>>
>>> >>>> Only you know how Passage uses the logging facility to know if
>>> >>>> there is in actual fact a risk.  I.e., is Passage actually logging
>>> >>>> information obtained from an internet connection and is that
>>> >>>> actually enabled/activated in the RCP/RAP package itself? I.e.,
>>> >>>> does what Jens Lideström outlined apply?  (Thanks Jens!)  If not,
>>> >>>> then perhaps we're unduly alarmed.  I could see nothing that
>>> >>>> appears to be related to Passage in an IDE into which I installed
>>> >>>> Passage, i.e., no preferences, no wizards, no views, nothing
>>> >>>> obvious.   Is it perhaps the case that the security problems would
>>> >>>> only manifest themselves in applications where Passage is deployed
>>> >>>> at runtime for licensing control of that application?
>>> >>>>
>>> >>>> Please try to outline the risk factors of Passage's development
>>> >>>> tools being installed in a IDE application to help inform the
>>> >>>> Planning Council in making a decision.
>>> >>>>
>>> >>>> P.S., Passage in the only component on the 2021-12 train that is
>>> >>>> affected; I cannot comment on all Eclipse-distributed content in
>>> >>>> general...
>>> >>>>
>>> >>>> Regards,
>>> >>>> Ed
>>> >>>>
>>> >>>> On 12.12.2021 11:04, Alexander Fedorov wrote:
>>> >>>>> Passage Team is working to provide Eclipse Passage 2.2.1 that will
>>> >>>>> consume fixed logger from
>>> >>>>>
>>> https://download.eclipse.org/tools/orbit/downloads/drops2/I20211211225428/repository
>>> >>>>>
>>> >>>>>
>>> >>>>> Ed, how could we then provide an update for released SimRel
>>> 2021-12?
>>> >>>>>
>>> >>>>> Regards,
>>> >>>>> AF
>>> >>>>>
>>> >>>>> P.S. I'm really surprised to have the only component affected
>>> >>>>> after having org.apache.*logging**.log4j 2.8.2 *published in
>>> >>>>> Eclipse Orbit starting from 2020

Re: [cross-project-issues-dev] log4j vulnerability in Eclipse?

[Matthias Sohn]

On Fri, Dec 10, 2021 at 8:11 PM Denis Roy 
wrote:

> I guess I'm trying to determine if there are any versions of Eclipse,
> Jetty, jGit, etc that are vulnerable.
>
JGit logs using slf4j API and org.eclipse.jgit.pgm bundles the old log4j
1.2.15 which is not affected by this vulnerability.
Though we should move away from log4j 1.x since it's EOL.

> For instance, we use Gerrit 3.2.7, which may contain a vulnerability.
>
Gerrit uses log4j 1.2.17 which is not affected by this vulnerability, see
https://bugs.chromium.org/p/gerrit/issues/detail?id=15414

-Matthias


> Denis
>
>
>
>
>
> On 2021-12-10 14:02, Matthew Khouzam via cross-project-issues-dev wrote:
>
> https://nvd.nist.gov/vuln/detail/CVE-2021-44228
> 
> NVD - CVE-2021-44228 
> Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages,
> and parameters do not protect against attacker controlled LDAP and other
> JNDI related endpoints. An attacker who can control log messages or log
> message parameters can execute arbitrary code loaded from LDAP servers when
> ...
> nvd.nist.gov
> It's for log4j2 between 2.0.0 and 2.14.1
> --
> *From:* cross-project-issues-dev
> 
>  on behalf of Denis Roy
>  
> *Sent:* Friday, December 10, 2021 1:46 PM
> *To:* Cross project issues 
> 
> *Subject:* [cross-project-issues-dev] log4j vulnerability in Eclipse?
>
>
> Hi Folks,
>
> As you may be aware, an important vulnerability has been discovered in
> log4j
>
> If I recall, log4j is used in Eclipse components.  Does anyone have a feel
> for our current state?  Is 2021-12 affected?
>
>
> https://arstechnica.com/information-technology/2021/12/minecraft-and-other-apps-face-serious-threat-from-new-code-execution-bug/
> 
>
>
> Denis
>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [orbit-dev] log4j vulnerability in Eclipse?

[Matthias Sohn]

On Sat, Dec 11, 2021 at 11:35 AM Gunnar Wagenknecht 
wrote:

> Alexander,
>
> On Dec 11, 2021, at 10:16, Alexander Fedorov 
> wrote:
> It would be great to learn vulnerability clean-up process with Eclipse
> Orbit team to then apply it to Eclipse Passage.
>
>
>
> There is no Orbit team. Orbit is driven by project committers
> using/needing libraries in Orbit.
> I encourage the Eclipse Passage project to submit a Gerrit review for a
> newer version.
>

considering the buzz around this vulnerability I went ahead and pushed an
update to log4j 2.15 for orbit
https://git.eclipse.org/r/c/orbit/orbit-recipes/+/188768
note that the required clearlydefined score isn't reached yet, if this
doesn't change soon
maybe someone can contribute the missing information to clearlydefined or
we file CQs to get the license approval for the new version


> You can also try a new way as described by Mickael here:
> https://www.eclipse.org/lists/orbit-dev/msg05509.html
>
> -Gunnar
> ___
> orbit-dev mailing list
> orbit-...@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/orbit-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [jetty-dev] archived jetty 9.4.x releases moved to another relative path

[Matthias Sohn]

On Sat, Nov 20, 2021 at 3:13 AM Joakim Erdfelt  wrote:

> On Fri, Nov 19, 2021 at 5:20 PM Matthias Sohn 
> wrote:
>
>> On Fri, Nov 19, 2021 at 11:42 PM Joakim Erdfelt 
>> wrote:
>>
>>> archive.eclipse.org is an automated feature that the webmaster at
>>> eclipse.org manages and maintains.
>>>
>>> Frankly, I'm surprised that the p2 bundles are even present on
>>> archive.eclipse.org, as no actively maintained project in Eclipse uses
>>> the Jetty 9.x bundles.
>>>
>>
>> JGit is an actively maintained Eclipse project and uses 9.4.x (9.4.44 on
>> master) update to Jetty 10 is in progress.
>> Since we also maintain older JGit versions it's a hassle if the path of
>> archived Jetty versions changes since
>> then auto-redirect from download.eclipse.org to archive.eclipse.org
>> doesn't work and we have to fix the target platform
>> of all the affected older JGit releases.
>>
>
Maybe someone on the cross projects list knows why the 9.4.x jetty p2 repos
were archived to the wrong path and can fix that ?


> How does JGit use Jetty?
> I'm genuinely curious, as I've used jgit in many projects and haven't
> noticed Jetty before.
>

JGit uses jetty for tests, e.g. to test the git servlet implementing the
http support used by jgit based git servers


> Starting with Jetty 10, the P2 repositories are entirely maintained within
>>> Maven Central using the Tycho P2 featureset to use a maven repository vs a
>>> bundle server.
>>>
>>
>> Can you provide some pointers how we can use these p2 repositories
>> on Maven Central?
>>
>
> Not sure, nobody on the Eclipse Jetty project uses OSGi or P2 themselves.
> The P2 repositories for Jetty that you find at Eclipse are maintained by
> other Eclipse projects that need them.
>
> Perhaps the issue and subsequent PR might give you pointers?
>
> https://github.com/eclipse/jetty.project/issues/6403
> https://github.com/eclipse/jetty.projec/pull/6404
>

I found a 10.0.6 p2 repository here
https://download.eclipse.org/eclipse/jetty/10.0.6/

-Matthias


- Joakim
> ___
> jetty-dev mailing list
> jetty-...@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/jetty-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] 2021-12 project participation

[Matthias Sohn]

EGit will ship 6.0.0 not 6.0 I fixed the release record accordingly

On Thu, Nov 18, 2021 at 6:12 AM Wayne Beaton <
wayne.bea...@eclipse-foundation.org> wrote:

> Greetings Simultaneous Release Participants!
>
> It's that time of the quarter again.
>
> Please have a look at the participation page
> . If I have something
> wrong, please let me know.
>
> I've made my usual best guesses at what version of each project's software
> will be included in the 2021-12 simultaneous release. Based on what I see
> in the simrel repository, though, I think that a few of you need to create
> release records for your contributions.
>
> If your project is pushing a new version and I have the wrong version
> selected, please ensure that you have created a release record with the
> correct version number and date. If that's in place, then please respond to
> this thread with the correct version information (or just send me a
> separate note).
>
> If your project is contributing a major or minor release and has not
> engaged in a progress or release review within one year of the release
> date, then please engage the EMO ASAP to schedule a review.
>
> Note that even if you do not need to engage in a progress or release
> review, *you are responsible for ensuring that the intellectual property
> due diligence process has been completed for all of the contents of your
> release*. If you have open CQs for content that will be included in the
> release, please reach out to emo-reco...@eclipse.org to request that they
> expedite processing.
>
> If you haven't yet, consider trying the Eclipse Dash License Tool
>  to review the license state of
> your project's third party content.
>
> Remember that you do not need to submit your IP Log for review if you are
> not engaging in a progress or release review. If you are uncertain about
> the status of your project's intellectual property, you can submit the IP
> Log with a comment requesting that the EMO review your project for
> conformance (when you submit an IP Log for review, the EMO will assume that
> you're initiating a release review unless you indicate otherwise).
>
> I've noticed a few things...
>
> Several Eclipse Mylyn features are disabled. Is this a problem? What is
> the status of this? It feels a little late to be asking this question, but
> will Eclipse Mylyn be updated in time to be included in the release?
>
> Eclipse EGF dropped out starting with the 2021-09 release. Can/should
> somebody remove the aggrcon file?
>
> Eclipse XWT and Eclipse Papyrus have been reactivated in the repository.
> In June
> ,
> these projects "decided to opt out of the train for this release". To the
> best of my knowledge, opting out completely (that is, not contributing even
> old bits) of a release is unprecedented, so I'm not sure what (if anything)
> special needs to be done here. AFAICT, nobody from the Planning Council
> expressed any concerns in response to the declaration from the project
> teams, so I've added them back in. Please let me know if this is a problem.
> AFAICT there is no release record for Eclipse XWT that corresponds to this
> release.
>
> There are some very old components in the simultaneous release. The
> Eclipse Data Tools features are, AFAICT, more than three years old. Eclipse
> ACTF is more than four years old. Are these features being tested? Is there
> anybody on this list representing the interests of these projects?
>
> Thanks for your attention.
>
> Wayne
> --
>
> Wayne Beaton
>
> Director of Open Source Projects | Eclipse Foundation
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] JGit/EGit contribution to M1 will be late

[Matthias Sohn]

On Thu, Oct 7, 2021 at 12:01 PM Laurent Goubet 
wrote:

> > Please respin the SimRel repo to include the contribution and please
> revert the removal changes from EPP packages and respin those as well.
>
> I've now updated and re-enabled the EMF Compare contribution to cope with
> the EGit breaks. Please take this into account as well for the respin.
>
> > In retrospect, it also seems kind of pointless to put upper bounds on
> the EGit/JGit dependencies.  E.g., CDT isn't broken because it only has no
> upper limit...  EMF compare has mostly removed the upper limits as well, at
> least from the bundles...
>
> EGit broke its APIs twice in the last few releases. "no upper limit"
> wouldn't have broken the simrel, but the final repository itself would have
> either been broken (NoSuchMethodException from any user of EMF Compare) or
> there would have been two versions of EGit, depending on how the wiring
> would have gone.
>
> What was
> Activator.getDefault().getRepositoryCache().lookupRepository(gitDir);
> Became
> RepositoryCache.getInstance().lookupRepository(gitDir);
> between 5.10 and 5.11
>
org.eclipse.egit.core is not exposed as public API, looks like some of the
API in this package should be made public if you depend on it

> This once again changed to
> RepositoryCache.INSTANCE.lookupRepository(gitDir);
> between 5.13 and 6.0.
>
Removing the upper limit is not an answer here.
>
> Laurent
> On 07/10/2021 08:57, Ed Merks wrote:
>
> Hi,
>
> To prevent such problems in the future, I strongly suggest that EGit/JGit
> should be at +2 or better yet at +1 but definitely not +3.  This will also
> help with the scenario of making contributions so late on the final day.
>
> Note that EGit/JGit has very few things on which it depends but quite a
> few things depend on it:
>
> In retrospect, it also seems kind of pointless to put upper bounds on the
> EGit/JGit dependencies.  E.g., CDT isn't broken because it only has no
> upper limit...  EMF compare has mostly removed the upper limits as well, at
> least from the bundles...
>
> I've made the necessary changes in Oomph, including changing Oomph's build
> to use https://download.eclipse.org/egit/updates-stable-nightly such that
> the builds will fail earlier the next time APIs actually break:
>
>   https://bugs.eclipse.org/bugs/show_bug.cgi?id=576491
>
> I've re-enabled Oomph's SimRel contribution.
>
> Please respin the SimRel repo to include the contribution and please
> revert the removal changes from EPP packages and respin those as well.
>
> Sorry for the inconvenience.
>
> Regards,
> Ed
>
>
> On 06.10.2021 23:57, Jonah Graham wrote:
>
> Thanks Mathias.
>
> (cc epp-dev)
>
> Note that if these projects don't contribute new versions in the next
> couple of hours I'll disable those features in EPP.
>
> I'm not too concerned about emf being disabled for M1, not sure effect of
> oomph though. Does that mean no installer for M1?
>
> Hopefully someone will weigh in on that.
>
> Thanks,
> Jonah
>
>
>
>
> On Wed., Oct. 6, 2021, 17:14 Matthias Sohn, 
> wrote:
>
>> I had to disable the following features to contribute jgit/egit
>> 6.0.0.202110060947-m1.
>> The build is running now.
>>
>> - org.eclipse.emf.compare.egit requires org.eclipse.jgit [4.9.0,6.0.0)
>> which is not available anymore
>> since we bumped jgit and egit to 6.0.0 for 2021-12.
>> - org.eclipse.oomph.setup.sdk requires jgit/egit [5.12.0,5.13.0)
>>
>> On Wed, Oct 6, 2021 at 10:56 PM Matthias Sohn 
>> wrote:
>>
>>> I disabled the feature org.eclipse.emf.compare.egit.feature.group to
>>> workaround this issue
>>> and hit the next problem in oomph requiring jgit/egit [5.12.0,5.13.0) which
>>> again isn't compatible with
>>> 6.0.0.202110060947-m1 which I am trying to contribute.
>>>
>>> 22:51:10 [0]Missing requirement: Git integration for Eclipse - Core
>>> 5.12.0.202106070339-r (org.eclipse.egit.core 5.12.0.202106070339-r)
>>> requires 'java.package; org.eclipse.jgit.annotations [5.12.0,5.13.0)'
>>> but it could not be found
>>> 22:51:10
>>> 22:51:10 JavaPackage(org.eclipse.jgit.annotations [5.12.0,5.13.0)) is
>>> required by:
>>> 22:51:10 ValidationSet(main)
>>> 22:51:10 Contribution(Oomph)
>>> 22:51:10 MappedRepository(
>>> https://download.eclipse.org/oomph/drops/milestone/S20211006-051210-1.23.0-M1
>>> )
>>> 22:51:10 Feature(org.eclipse.oomph.setup.sdk.feature.group)
>>> 22:51:10 InstallableUnit(org.eclipse.oomph.setup.git.feature.group
>>> 1.20.0.v20210924-1427)
>>> 2

Re: [cross-project-issues-dev] JGit/EGit contribution to M1 will be late

[Matthias Sohn]

On Thu, Oct 7, 2021 at 8:58 AM Ed Merks  wrote:

> Hi,
>
> To prevent such problems in the future, I strongly suggest that EGit/JGit
> should be at +2 or better yet at +1 but definitely not +3.  This will also
> help with the scenario of making contributions so late on the final day.
>
I agree we should contribute earlier at +1 and will do that in the future

> Note that EGit/JGit has very few things on which it depends but quite a
> few things depend on it:
>
> In retrospect, it also seems kind of pointless to put upper bounds on the
> EGit/JGit dependencies.  E.g., CDT isn't broken because it only has no
> upper limit...  EMF compare has mostly removed the upper limits as well, at
> least from the bundles...
>
> I've made the necessary changes in Oomph, including changing Oomph's build
> to use https://download.eclipse.org/egit/updates-stable-nightly such that
> the builds will fail earlier the next time APIs actually break:
>
>   https://bugs.eclipse.org/bugs/show_bug.cgi?id=576491
>
> I've re-enabled Oomph's SimRel contribution.
>
> Please respin the SimRel repo to include the contribution and please
> revert the removal changes from EPP packages and respin those as well.
>
> Sorry for the inconvenience.
>
> Regards,
> Ed
>
>
> On 06.10.2021 23:57, Jonah Graham wrote:
>
> Thanks Mathias.
>
> (cc epp-dev)
>
> Note that if these projects don't contribute new versions in the next
> couple of hours I'll disable those features in EPP.
>
> I'm not too concerned about emf being disabled for M1, not sure effect of
> oomph though. Does that mean no installer for M1?
>
> Hopefully someone will weigh in on that.
>
> Thanks,
> Jonah
>
>
>
>
> On Wed., Oct. 6, 2021, 17:14 Matthias Sohn, 
> wrote:
>
>> I had to disable the following features to contribute jgit/egit
>> 6.0.0.202110060947-m1.
>> The build is running now.
>>
>> - org.eclipse.emf.compare.egit requires org.eclipse.jgit [4.9.0,6.0.0)
>> which is not available anymore
>> since we bumped jgit and egit to 6.0.0 for 2021-12.
>> - org.eclipse.oomph.setup.sdk requires jgit/egit [5.12.0,5.13.0)
>>
>> On Wed, Oct 6, 2021 at 10:56 PM Matthias Sohn 
>> wrote:
>>
>>> I disabled the feature org.eclipse.emf.compare.egit.feature.group to
>>> workaround this issue
>>> and hit the next problem in oomph requiring jgit/egit [5.12.0,5.13.0) which
>>> again isn't compatible with
>>> 6.0.0.202110060947-m1 which I am trying to contribute.
>>>
>>> 22:51:10 [0]Missing requirement: Git integration for Eclipse - Core
>>> 5.12.0.202106070339-r (org.eclipse.egit.core 5.12.0.202106070339-r)
>>> requires 'java.package; org.eclipse.jgit.annotations [5.12.0,5.13.0)'
>>> but it could not be found
>>> 22:51:10
>>> 22:51:10 JavaPackage(org.eclipse.jgit.annotations [5.12.0,5.13.0)) is
>>> required by:
>>> 22:51:10 ValidationSet(main)
>>> 22:51:10 Contribution(Oomph)
>>> 22:51:10 MappedRepository(
>>> https://download.eclipse.org/oomph/drops/milestone/S20211006-051210-1.23.0-M1
>>> )
>>> 22:51:10 Feature(org.eclipse.oomph.setup.sdk.feature.group)
>>> 22:51:10 InstallableUnit(org.eclipse.oomph.setup.git.feature.group
>>> 1.20.0.v20210924-1427)
>>> 22:51:10 InstallableUnit(org.eclipse.oomph.setup.git
>>> 1.20.0.v20210924-1427)
>>> 22:51:10 InstallableUnit(org.eclipse.egit.core 5.12.0.202106070339-r)
>>>
>>> On Wed, Oct 6, 2021 at 10:47 PM Jonah Graham 
>>> wrote:
>>>
>>>> Hi Matthias,
>>>>
>>>> IMHO you should disable emf compare with an announcement to this list
>>>> that you did so.
>>>>
>>>> Hopefully that isn't a can of worms - the worms being if EMF Compare
>>>> has dependencies.
>>>>
>>>> Jonah
>>>>
>>>>
>>>> ~~~
>>>> Jonah Graham
>>>> Kichwa Coders
>>>> www.kichwacoders.com
>>>>
>>>>
>>>> On Wed, 6 Oct 2021 at 16:37, Matthias Sohn 
>>>> wrote:
>>>>
>>>>> I pushed our contribution [1] though the simrel validation build fails
>>>>> [2] with the error
>>>>>
>>>>> 22:27:06 [0]Missing requirement: EMF Compare EGit Support
>>>>> 1.2.4.202107200824 (org.eclipse.emf.compare.egit 1.2.4.202107200824)
>>>>> requires 'osgi.bundle; org.eclipse.jgit [4.9.0,6.0.0)' but it could not be
>>>>> found
>>>>> 22:27:06
>>>>> 22:27:06 Bundle(org.eclipse

Re: [cross-project-issues-dev] JGit/EGit contribution to M1 will be late

[Matthias Sohn]

I had to disable the following features to contribute jgit/egit
6.0.0.202110060947-m1.
The build is running now.

- org.eclipse.emf.compare.egit requires org.eclipse.jgit [4.9.0,6.0.0)
which is not available anymore
since we bumped jgit and egit to 6.0.0 for 2021-12.

- org.eclipse.oomph.setup.sdk requires jgit/egit [5.12.0,5.13.0)

On Wed, Oct 6, 2021 at 10:56 PM Matthias Sohn 
wrote:

> I disabled the feature org.eclipse.emf.compare.egit.feature.group to
> workaround this issue
> and hit the next problem in oomph requiring jgit/egit [5.12.0,5.13.0) which
> again isn't compatible with
> 6.0.0.202110060947-m1 which I am trying to contribute.
>
> 22:51:10 [0]Missing requirement: Git integration for Eclipse - Core
> 5.12.0.202106070339-r (org.eclipse.egit.core 5.12.0.202106070339-r)
> requires 'java.package; org.eclipse.jgit.annotations [5.12.0,5.13.0)' but
> it could not be found
> 22:51:10
> 22:51:10 JavaPackage(org.eclipse.jgit.annotations [5.12.0,5.13.0)) is
> required by:
> 22:51:10 ValidationSet(main)
> 22:51:10 Contribution(Oomph)
> 22:51:10 MappedRepository(
> https://download.eclipse.org/oomph/drops/milestone/S20211006-051210-1.23.0-M1
> )
> 22:51:10 Feature(org.eclipse.oomph.setup.sdk.feature.group)
> 22:51:10 InstallableUnit(org.eclipse.oomph.setup.git.feature.group
> 1.20.0.v20210924-1427)
> 22:51:10 InstallableUnit(org.eclipse.oomph.setup.git 1.20.0.v20210924-1427)
> 22:51:10 InstallableUnit(org.eclipse.egit.core 5.12.0.202106070339-r)
>
> On Wed, Oct 6, 2021 at 10:47 PM Jonah Graham 
> wrote:
>
>> Hi Matthias,
>>
>> IMHO you should disable emf compare with an announcement to this list
>> that you did so.
>>
>> Hopefully that isn't a can of worms - the worms being if EMF Compare has
>> dependencies.
>>
>> Jonah
>>
>>
>> ~~~
>> Jonah Graham
>> Kichwa Coders
>> www.kichwacoders.com
>>
>>
>> On Wed, 6 Oct 2021 at 16:37, Matthias Sohn 
>> wrote:
>>
>>> I pushed our contribution [1] though the simrel validation build fails
>>> [2] with the error
>>>
>>> 22:27:06 [0]Missing requirement: EMF Compare EGit Support
>>> 1.2.4.202107200824 (org.eclipse.emf.compare.egit 1.2.4.202107200824)
>>> requires 'osgi.bundle; org.eclipse.jgit [4.9.0,6.0.0)' but it could not be
>>> found
>>> 22:27:06
>>> 22:27:06 Bundle(org.eclipse.jgit [4.9.0,6.0.0)) is required by:
>>> 22:27:06   ValidationSet(main)
>>> 22:27:06 Contribution(EMF Compare)
>>> 22:27:06   MappedRepository(
>>> https://download.eclipse.org/modeling/emf/compare/updates/milestones/3.3/S202107200824
>>> )
>>> 22:27:06 Feature(org.eclipse.emf.compare.egit.feature.group)
>>> 22:27:06   InstallableUnit(org.eclipse.emf.compare.egit
>>> 1.2.4.202107200824)
>>>
>>> because  org.eclipse.emf.compare.egit requires org.eclipse.jgit
>>> [4.9.0,6.0.0).
>>> This can't work since JGit/EGit bumped their version to 6.0 (our M1
>>> contribution is 6.0.0.202110060947-m1)
>>> as announced earlier on this list [3].
>>>
>>> org.eclipse.emf.compare.egit needs to bump the upper boundary of the
>>> jgit/egit version they require to allow 6.0.x.
>>> How can I get our contribution in ?
>>> Disable the emf.compare contribution until they fixed this version range
>>> ?
>>>
>>> [1] https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/186244
>>> [2]
>>> https://ci.eclipse.org/simrel/job/simrel.runaggregator.VALIDATE.gerrit/2436/console
>>> [3] https://www.eclipse.org/lists/cross-project-issues-dev/msg18654.html
>>>
>>> -Matthias
>>>
>>> On Wed, Oct 6, 2021 at 9:50 PM Matthias Sohn 
>>> wrote:
>>>
>>>> The JGit/EGit contribution to M1 will be late, I need a bit more time
>>>> to finish the build.
>>>>
>>>> -Matthias
>>>>
>>> ___
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@eclipse.org
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] JGit/EGit contribution to M1 will be late

[Matthias Sohn]

I disabled the feature org.eclipse.emf.compare.egit.feature.group to
workaround this issue
and hit the next problem in oomph requiring jgit/egit [5.12.0,5.13.0) which
again isn't compatible with
6.0.0.202110060947-m1 which I am trying to contribute.

22:51:10 [0]Missing requirement: Git integration for Eclipse - Core
5.12.0.202106070339-r (org.eclipse.egit.core 5.12.0.202106070339-r)
requires 'java.package; org.eclipse.jgit.annotations [5.12.0,5.13.0)' but
it could not be found
22:51:10
22:51:10 JavaPackage(org.eclipse.jgit.annotations [5.12.0,5.13.0)) is
required by:
22:51:10 ValidationSet(main)
22:51:10 Contribution(Oomph)
22:51:10 MappedRepository(
https://download.eclipse.org/oomph/drops/milestone/S20211006-051210-1.23.0-M1
)
22:51:10 Feature(org.eclipse.oomph.setup.sdk.feature.group)
22:51:10 InstallableUnit(org.eclipse.oomph.setup.git.feature.group
1.20.0.v20210924-1427)
22:51:10 InstallableUnit(org.eclipse.oomph.setup.git 1.20.0.v20210924-1427)
22:51:10 InstallableUnit(org.eclipse.egit.core 5.12.0.202106070339-r)

On Wed, Oct 6, 2021 at 10:47 PM Jonah Graham  wrote:

> Hi Matthias,
>
> IMHO you should disable emf compare with an announcement to this list that
> you did so.
>
> Hopefully that isn't a can of worms - the worms being if EMF Compare has
> dependencies.
>
> Jonah
>
>
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
>
> On Wed, 6 Oct 2021 at 16:37, Matthias Sohn 
> wrote:
>
>> I pushed our contribution [1] though the simrel validation build fails
>> [2] with the error
>>
>> 22:27:06 [0]Missing requirement: EMF Compare EGit Support
>> 1.2.4.202107200824 (org.eclipse.emf.compare.egit 1.2.4.202107200824)
>> requires 'osgi.bundle; org.eclipse.jgit [4.9.0,6.0.0)' but it could not be
>> found
>> 22:27:06
>> 22:27:06 Bundle(org.eclipse.jgit [4.9.0,6.0.0)) is required by:
>> 22:27:06   ValidationSet(main)
>> 22:27:06 Contribution(EMF Compare)
>> 22:27:06   MappedRepository(
>> https://download.eclipse.org/modeling/emf/compare/updates/milestones/3.3/S202107200824
>> )
>> 22:27:06 Feature(org.eclipse.emf.compare.egit.feature.group)
>> 22:27:06   InstallableUnit(org.eclipse.emf.compare.egit
>> 1.2.4.202107200824)
>>
>> because  org.eclipse.emf.compare.egit requires org.eclipse.jgit
>> [4.9.0,6.0.0).
>> This can't work since JGit/EGit bumped their version to 6.0 (our M1
>> contribution is 6.0.0.202110060947-m1)
>> as announced earlier on this list [3].
>>
>> org.eclipse.emf.compare.egit needs to bump the upper boundary of the
>> jgit/egit version they require to allow 6.0.x.
>> How can I get our contribution in ?
>> Disable the emf.compare contribution until they fixed this version range ?
>>
>> [1] https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/186244
>> [2]
>> https://ci.eclipse.org/simrel/job/simrel.runaggregator.VALIDATE.gerrit/2436/console
>> [3] https://www.eclipse.org/lists/cross-project-issues-dev/msg18654.html
>>
>> -Matthias
>>
>> On Wed, Oct 6, 2021 at 9:50 PM Matthias Sohn 
>> wrote:
>>
>>> The JGit/EGit contribution to M1 will be late, I need a bit more time to
>>> finish the build.
>>>
>>> -Matthias
>>>
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] JGit/EGit contribution to M1 will be late

[Matthias Sohn]

I pushed our contribution [1] though the simrel validation build fails [2]
with the error

22:27:06 [0]Missing requirement: EMF Compare EGit Support
1.2.4.202107200824 (org.eclipse.emf.compare.egit 1.2.4.202107200824)
requires 'osgi.bundle; org.eclipse.jgit [4.9.0,6.0.0)' but it could not be
found
22:27:06
22:27:06 Bundle(org.eclipse.jgit [4.9.0,6.0.0)) is required by:
22:27:06   ValidationSet(main)
22:27:06 Contribution(EMF Compare)
22:27:06   MappedRepository(
https://download.eclipse.org/modeling/emf/compare/updates/milestones/3.3/S202107200824
)
22:27:06 Feature(org.eclipse.emf.compare.egit.feature.group)
22:27:06   InstallableUnit(org.eclipse.emf.compare.egit
1.2.4.202107200824)

because  org.eclipse.emf.compare.egit requires org.eclipse.jgit
[4.9.0,6.0.0).
This can't work since JGit/EGit bumped their version to 6.0 (our M1
contribution is 6.0.0.202110060947-m1)
as announced earlier on this list [3].

org.eclipse.emf.compare.egit needs to bump the upper boundary of the
jgit/egit version they require to allow 6.0.x.
How can I get our contribution in ?
Disable the emf.compare contribution until they fixed this version range ?

[1] https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/186244
[2]
https://ci.eclipse.org/simrel/job/simrel.runaggregator.VALIDATE.gerrit/2436/console
[3] https://www.eclipse.org/lists/cross-project-issues-dev/msg18654.html

-Matthias

On Wed, Oct 6, 2021 at 9:50 PM Matthias Sohn 
wrote:

> The JGit/EGit contribution to M1 will be late, I need a bit more time to
> finish the build.
>
> -Matthias
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] JGit/EGit contribution to M1 will be late

[Matthias Sohn]

The JGit/EGit contribution to M1 will be late, I need a bit more time to
finish the build.

-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] JGit and EGit 6.0 switch BREE to Java 11 for 2021-12

[Matthias Sohn]

This is a heads up that JGit and EGit are switching their minimum BREE to
Java 11 for their 6.0 release which we plan to ship with Eclipse
simultaneous release 2021-12.

see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=569917
https://bugs.eclipse.org/bugs/show_bug.cgi?id=576238

-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Emergency Outage - OKD cluster

[Matthias Sohn]

pushing to Gerrit still fails [1], seems to be caused by this incident

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=574424

-Matthias

On Thu, Jun 24, 2021 at 12:45 AM Matthew Ward <
matt.w...@eclipse-foundation.org> wrote:

> Hello Everyone,
>
>   We are experiencing an outage in our OKD cluster due to failed network
> change.  Currently the webmaster team is working to restore service, but we
> may need to restart the cluster.
>
> -Matt.
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] m2e 1.18.0 and SimRel 2021-06

[Matthias Sohn]

On Thu, Jun 3, 2021 at 7:11 PM Mickael Istria  wrote:

>
>
> On Thu, Jun 3, 2021 at 7:01 PM Jonah Graham 
> wrote:
>
>> Can we respin 2021-06 RC1 to include m2e 1.18.0? If so, that would be my
>> vote. Based on your message about laptop this seems unlikely?
>>
>
> I just published m2e 1.18.0 release from current master. It's available at
> https://download.eclipse.org/technology/m2e/releases/1.18.0/ . I won't be
> able to take care of updating the m2e.aggrcon file soon as I don't have Git
> nearby and I'm not aware of a way to contribute a patch via Gerrit from a
> web browser.
>

you can create a patch in Gerrit from a web browser, see
https://git.eclipse.org/r/Documentation/user-inline-edit.html


> So it would be great if you could take care of updating this m2e.aggrcon
> file, submitting the patch to validate it, merge and so on.
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] JGit/EGit late for RC1

[Matthias Sohn]

the simrel build including our contribution finished, we are good to go

On Thu, Jun 3, 2021 at 4:43 PM Matthias Sohn 
wrote:

> I submitted the submission to simrel
> https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/181256
> and the simrel build is running, see my last email
>
> thanks
> -Matthias
>
> On Thu, Jun 3, 2021 at 4:39 PM Frederic Gurr <
> frederic.g...@eclipse-foundation.org> wrote:
>
>> Hi Matthias,
>> Is something still blocking the submission to SimRel? I'm waiting for
>> this change before promoting the staging repo to releases.
>>
>> Regards,
>> Fred
>>
>> On Thu, 3 Jun 2021, 14:12 Jonah Graham,  wrote:
>>
>>> Hi Matthias,
>>>
>>> jgit/egit look close now - the most recent change verified successfully,
>>> it just needs a rebase?
>>> https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/181256/
>>>
>>> Thanks
>>> Jonah
>>> ~~~
>>> Jonah Graham
>>> Kichwa Coders
>>> www.kichwacoders.com
>>>
>>>
>>> On Wed, 2 Jun 2021 at 16:48, Matthias Sohn 
>>> wrote:
>>>
>>>> our contribution to RC1 will be late.
>>>>
>>>> I had RC1 contribution ready yesterday [1], but today it turned out we
>>>> need another fix [2]
>>>> and Jenkins is very slow [3].
>>>>
>>>> [1]
>>>> https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/181256
>>>> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=573922
>>>> [3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=571952#c66
>>>>
>>>> -Matthias
>>>> ___
>>>> cross-project-issues-dev mailing list
>>>> cross-project-issues-dev@eclipse.org
>>>> To unsubscribe from this list, visit
>>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>>
>>> ___
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@eclipse.org
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] JGit/EGit late for RC1

[Matthias Sohn]

I submitted the submission to simrel
https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/181256
and the simrel build is running, see my last email

thanks
-Matthias

On Thu, Jun 3, 2021 at 4:39 PM Frederic Gurr <
frederic.g...@eclipse-foundation.org> wrote:

> Hi Matthias,
> Is something still blocking the submission to SimRel? I'm waiting for this
> change before promoting the staging repo to releases.
>
> Regards,
> Fred
>
> On Thu, 3 Jun 2021, 14:12 Jonah Graham,  wrote:
>
>> Hi Matthias,
>>
>> jgit/egit look close now - the most recent change verified successfully,
>> it just needs a rebase?
>> https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/181256/
>>
>> Thanks
>> Jonah
>> ~~~
>> Jonah Graham
>> Kichwa Coders
>> www.kichwacoders.com
>>
>>
>> On Wed, 2 Jun 2021 at 16:48, Matthias Sohn 
>> wrote:
>>
>>> our contribution to RC1 will be late.
>>>
>>> I had RC1 contribution ready yesterday [1], but today it turned out we
>>> need another fix [2]
>>> and Jenkins is very slow [3].
>>>
>>> [1] https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/181256
>>> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=573922
>>> [3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=571952#c66
>>>
>>> -Matthias
>>> ___
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@eclipse.org
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] JGit/EGit late for RC1

[Matthias Sohn]

I submitted the change and the build is now running
https://ci.eclipse.org/simrel/job/simrel.runaggregator.pipeline/1579/console

On Thu, Jun 3, 2021 at 4:36 PM Matthias Sohn 
wrote:

> We had to skip running the tests to finish the release builds due to the
> Jenkins slowness.
> I now rebased our contribution and will submit it as soon as the
> verification build succeeded.
>
> -Matthias
>
> On Thu, Jun 3, 2021 at 2:12 PM Jonah Graham 
> wrote:
>
>> Hi Matthias,
>>
>> jgit/egit look close now - the most recent change verified successfully,
>> it just needs a rebase?
>> https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/181256/
>>
>> Thanks
>> Jonah
>> ~~~
>> Jonah Graham
>> Kichwa Coders
>> www.kichwacoders.com
>>
>>
>> On Wed, 2 Jun 2021 at 16:48, Matthias Sohn 
>> wrote:
>>
>>> our contribution to RC1 will be late.
>>>
>>> I had RC1 contribution ready yesterday [1], but today it turned out we
>>> need another fix [2]
>>> and Jenkins is very slow [3].
>>>
>>> [1] https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/181256
>>> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=573922
>>> [3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=571952#c66
>>>
>>> -Matthias
>>> ___
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@eclipse.org
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] JGit/EGit late for RC1

[Matthias Sohn]

We had to skip running the tests to finish the release builds due to the
Jenkins slowness.
I now rebased our contribution and will submit it as soon as the
verification build succeeded.

-Matthias

On Thu, Jun 3, 2021 at 2:12 PM Jonah Graham  wrote:

> Hi Matthias,
>
> jgit/egit look close now - the most recent change verified successfully,
> it just needs a rebase?
> https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/181256/
>
> Thanks
> Jonah
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
>
> On Wed, 2 Jun 2021 at 16:48, Matthias Sohn 
> wrote:
>
>> our contribution to RC1 will be late.
>>
>> I had RC1 contribution ready yesterday [1], but today it turned out we
>> need another fix [2]
>> and Jenkins is very slow [3].
>>
>> [1] https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/181256
>> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=573922
>> [3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=571952#c66
>>
>> -Matthias
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] JGit/EGit late for RC1

[Matthias Sohn]

our contribution to RC1 will be late.

I had RC1 contribution ready yesterday [1], but today it turned out we need
another fix [2]
and Jenkins is very slow [3].

[1] https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/181256
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=573922
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=571952#c66

-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] JGit/EGit contribution for M3 again late

[Matthias Sohn]

On Thu, May 27, 2021 at 2:03 AM Denis Roy 
wrote:

> Hi Matthias,
>
> Build times from March = 6 minutes to May = 23 minutes, we are working on
> identifying the cause. I apologize for that.
>
> One build has an error 400 from repo.eclipse.org, which we could look
> into. But most of your failed builds have this message:
>
>
> *18:40:02*  22:40:02 [ERROR] Cannot resolve project dependencies:*18:40:02*  
> 22:40:02 [ERROR]   Software being installed: org.eclipse.egit.github.core 
> 5.11.0.202103091610-r*18:40:02*  22:40:02 [ERROR]   Missing requirement: 
> org.eclipse.egit.github.core 5.11.0.202103091610-r requires 'java.package; 
> org.eclipse.jgit.annotations [5.11.0,5.12.0)' but it could not be found
>
> Which part of CI is responsible for that?
>
The EGit M3 build picked up the M2 build of JGit instead of the M3 build.
Looks like this was my fault by pushing the JGit v5.12.0.202105261145-m3
too late.
The EGit build looks for the closest tagged JGit version matching the same
major.minor version [1].
If the JGit v5.12.0.202105261145-m3 wasn't pushed when I started the
EGit v5.12.0.202105261145-m3 build
it would select the v5.12.0.202105051250-m2 JGit version.

Meanwhile I ran that build again (which couldn't finish since release
artefacts can't be redeployed on Nexus) and it picked up
the correct M3 build of JGit. Hence I think me pushing the JGit tag too
late was causing this.
Yesterday I ran all the validation builds for M3 locally to shorten the
time to get the milestone tagged on the CI.

> Would be great if you could identify the root cause of the slowdown of our
CI builds.
JGit build times are now 1h or more. They used to be in the range of
20-35min [2].
EGit build times increased from around 25min to around 1 hour [3].

Did we maybe loose the resource packs [4] we had for the JGit and EGit
builds ?

thanks
-Matthias

[1]
https://git.eclipse.org/r/plugins/gitiles/egit/egit-pipelines/+/refs/heads/master/src/org/eclipse/egit/jenkins/Lib.groovy#59
[2]
https://ci.eclipse.org/jgit/job/stable/job/jgit.gerrit-pipeline/buildTimeTrend
[3] https://ci.eclipse.org/egit/job/egit.gerrit/buildTimeTrend
[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=548126


> Denis
>
>
> On 2021-05-26 5:27 p.m., Matthias Sohn wrote:
>
> I am giving up for M3, with such an unreliable CI it's close to impossible
> to get a version out of the door :-(
> Will prepare the final release soon to have time to repeat this trial and
> error with the shaky CI a couple of times.
>
> On Wed, May 26, 2021 at 10:57 PM Matthias Sohn 
> wrote:
>
>> we are suffering from
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=571952
>> hence our contribution will be a little late again
>>
>> -Matthias
>>
>
> ___
> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> --
>
> *Denis Roy*
>
> *Director, IT Services | **Eclipse Foundation*
>
> *Eclipse Foundation* <http://www.eclipse.org/>*: The Community for Open
> Innovation and Collaboration*
>
> Twitter: @droy_eclipse
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] JGit/EGit contribution for M3 again late

[Matthias Sohn]

I am giving up for M3, with such an unreliable CI it's close to impossible
to get a version out of the door :-(
Will prepare the final release soon to have time to repeat this trial and
error with the shaky CI a couple of times.

On Wed, May 26, 2021 at 10:57 PM Matthias Sohn 
wrote:

> we are suffering from
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=571952
> hence our contribution will be a little late again
>
> -Matthias
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] JGit/EGit contribution for M3 again late

[Matthias Sohn]

we are suffering from
https://bugs.eclipse.org/bugs/show_bug.cgi?id=571952
hence our contribution will be a little late again

-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] 2021-06 Participating Projects List

[Matthias Sohn]

Please update JGit and EGit to 5.12.0, I created the release records and
scheduled release reviews
since the last one was around this time last year.

https://projects.eclipse.org/projects/technology.jgit/releases/5.12.0
https://projects.eclipse.org/projects/technology.egit/releases/5.12.0

-Matthias

On Tue, May 18, 2021 at 5:04 PM Jeff Johnston  wrote:

> Hi Wayne,
>
> Please update Linux Tools to 8.3.0.  I have created a release record.
>
> Thanks,
>
> -- Jeff J.
>
> On Tue, May 18, 2021 at 10:48 AM Wayne Beaton <
> wayne.bea...@eclipse-foundation.org> wrote:
>
>> Greetings Folks. It's that time again!
>>
>> I've created a participation page for the 2021-06 Release
>> . On it, I've listed the
>> participating projects along with the version that the project is
>> contributing to the simultaneous release. Please have a look and let me
>> know if anything needs to be updated.
>>
>> Note that you'll need to create a release record for the release you're
>> contributing if you have not already done so (please do so before asking me
>> to update your project's participation listing).
>>
>> Note also that if you have not done so in the last year and you're
>> contributing a new major or minor release, you'll need to engage in a release
>> review .
>>
>> Intellectual property must be properly accounted for and tracked at all
>> times. The project team must engage in the Eclipse IP Due Diligence
>> Process  on an ongoing
>> basis. The IP Log review and approval that occurs at the time of either a
>> release review or progress review should be regarded as a means of
>> confirming that intellectual property is being properly managed and not as
>> a trigger to engage in a last minute clean up.
>>
>> Let me know if you have any questions,
>>
>> Wayne
>> --
>>
>> Wayne Beaton
>>
>> Director of Open Source Projects | Eclipse Foundation
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] JGit/EGit will be late for 2021-06 M2

[Matthias Sohn]

On Wed, May 5, 2021 at 10:47 PM Matthias Sohn 
wrote:

> I had some issues with running the builds hence JGit/EGit will be late for
> M2.
>

our contribution is submitted, build is running
https://ci.eclipse.org/simrel/job/simrel.runaggregator.pipeline/1534/
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] JGit/EGit will be late for 2021-06 M2

[Matthias Sohn]

I had some issues with running the builds hence JGit/EGit will be late for
M2.

-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] RAP Tools disabled because of conflicts with Eclipse Platform 4.20 M1 contribution

[Matthias Sohn]

On Tue, Apr 13, 2021 at 6:21 PM Aleksandar Kurtakov 
wrote:

>
>
> On Tue, Apr 13, 2021 at 7:13 PM Matthias Sohn 
> wrote:
>
>> On Tue, Apr 13, 2021 at 5:42 PM Aleksandar Kurtakov 
>> wrote:
>>
>>>
>>>
>>> On Tue, Apr 13, 2021 at 6:24 PM Nitin Dahyabhai 
>>> wrote:
>>>
>>>> Unfortunately the problem Ed brought up where downstream projects would
>>>> have to reproduce what the Platform does for its Jetty problems is already
>>>> here. WTP needs more Jetty bundles than the Platform provides, and if the
>>>> Platform is using 10.0.1, it would be foolish for me to ship using anything
>>>> else, even 10.0.2.
>>>>
>>>> I don't know who was taking care of
>>>> https://download.eclipse.org/jetty/updates/jetty-bundles-9.x/, but
>>>> there needs to be something similar for 10.x, and likely 11.x, to serve as
>>>> a canonical p2 repository for all of it. Pulling jars directly from Maven
>>>> seems well suited to products, RCP apps, and configurations that aren't
>>>> expected to be built upon, but for the Platform to use this approach only
>>>> complicates matters. The Platform is an unavoidable middleman in this case.
>>>>
>>> It was about time for everyone to realize that "The Platform is an
>>> unavoidable middleman in this case." - thanks for stating it that clearly.
>>> We have mostly abandoned our CDT/Linux Tools plugins so we can keep the
>>> Platform running but it's time for others to jump in.
>>> I was the one doing it lately and it was a full rebuild breaking quite
>>> often which I couldn't afford time to redo for 10.x esp with team
>>> shrinking, no one replied to request for help on platform releng and
>>> gaining additional responsibilities. I would welcome anyone stepping up and
>>> doing things in a more general and reusable way - unless/until that happens
>>> I see no other way to keep things but to take the shortest path. There are
>>> simply that many hours in the day and what I or someone else wants doesn't
>>> change the speed of the clock.
>>>
>>
>> if you can point me at how this was done previously with jetty 9.x I may
>> try to care for this.
>> In JGit we are still depending on jetty 9.x since we still want to
>> support Java 8 and we were piggy-backing
>> on the jetty 9.x p2 repos maintained by the platform.
>> I was already wondering where to get a p2 repo for the latest 9.x jetty
>> releases, while platform moved on to jetty 10.7
>>
>
> https://ci.eclipse.org/jetty/job/jetty-rt-bundles-9/ is the job. It
> rebuilds the sources so there is no guarantee that it matches the actual
> Jetty release. In order to be done proper it would have to be done like the
> jetty 10 so actual jetty build artifacts are used and to prevent breakages
> like it can be seen with the multiple Non 27 builds to wrap up very minimal
> change exposed by this needless rebuild.
> Note that the job deployment part is broken due to
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=570630 and will need fixing
> too.
>

who can provide me permissions to access the configuration of this job ?


>
>
>>
>> I am not listening on the platform releng list, that's why I didn't see
>> your request for help.
>>
>>
>>>
>>>> --
>>>> Regards,
>>>> Nitin Dahyabhai
>>>> Eclipse WTP PMC
>>>> ___
>>>> cross-project-issues-dev mailing list
>>>> cross-project-issues-dev@eclipse.org
>>>> To unsubscribe from this list, visit
>>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>>
>>>
>>>
>>> --
>>> Aleksandar Kurtakov
>>> Red Hat Eclipse Team
>>> ___
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@eclipse.org
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] RAP Tools disabled because of conflicts with Eclipse Platform 4.20 M1 contribution

[Matthias Sohn]

On Tue, Apr 13, 2021 at 5:42 PM Aleksandar Kurtakov 
wrote:

>
>
> On Tue, Apr 13, 2021 at 6:24 PM Nitin Dahyabhai 
> wrote:
>
>> Unfortunately the problem Ed brought up where downstream projects would
>> have to reproduce what the Platform does for its Jetty problems is already
>> here. WTP needs more Jetty bundles than the Platform provides, and if the
>> Platform is using 10.0.1, it would be foolish for me to ship using anything
>> else, even 10.0.2.
>>
>> I don't know who was taking care of
>> https://download.eclipse.org/jetty/updates/jetty-bundles-9.x/, but there
>> needs to be something similar for 10.x, and likely 11.x, to serve as a
>> canonical p2 repository for all of it. Pulling jars directly from Maven
>> seems well suited to products, RCP apps, and configurations that aren't
>> expected to be built upon, but for the Platform to use this approach only
>> complicates matters. The Platform is an unavoidable middleman in this case.
>>
> It was about time for everyone to realize that "The Platform is an
> unavoidable middleman in this case." - thanks for stating it that clearly.
> We have mostly abandoned our CDT/Linux Tools plugins so we can keep the
> Platform running but it's time for others to jump in.
> I was the one doing it lately and it was a full rebuild breaking quite
> often which I couldn't afford time to redo for 10.x esp with team
> shrinking, no one replied to request for help on platform releng and
> gaining additional responsibilities. I would welcome anyone stepping up and
> doing things in a more general and reusable way - unless/until that happens
> I see no other way to keep things but to take the shortest path. There are
> simply that many hours in the day and what I or someone else wants doesn't
> change the speed of the clock.
>

if you can point me at how this was done previously with jetty 9.x I may
try to care for this.
In JGit we are still depending on jetty 9.x since we still want to support
Java 8 and we were piggy-backing
on the jetty 9.x p2 repos maintained by the platform.
I was already wondering where to get a p2 repo for the latest 9.x jetty
releases, while platform moved on to jetty 10.

I am not listening on the platform releng list, that's why I didn't see
your request for help.


>
>> --
>> Regards,
>> Nitin Dahyabhai
>> Eclipse WTP PMC
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Is anyone still using Copyright tool?

[Matthias Sohn]

On Fri, Feb 5, 2021 at 6:00 PM Aleksandar Kurtakov 
wrote:

> Question is about [1] being still used by anyone. I haven't seen anyone
> using it/running it on git repos like it has been in the past. Changing
> copyright year in every file is not mandatory for Eclipse TLP since 2016
> [2] and has never been mandatory for other projects AFAIK.
>

we don't use the copyright tool in JGit and EGit


> What I look for is removing this part of Eclipse Releng plugin to gain the
> following benefits:
> 1. Drop dependency on EGit in Eclipse Platform and thus circular build
> dependency.
> 2. Point 1 will allow to to build Eclipse Platform p2 repo in a way that
> includes all transitive dependencies [3]
> 3. Point 2 will allow to switch third-party dependencies to require rather
> than include and thus support version ranges.
> 4. Point 3 will allow updates of third party dependencies for security
> reasons to be far simpler as currently it's a terrible experience [4]
> 5. Point 3 will simplify updates of third party dependencies in Eclipse
> Platform releng as touching features should be far less frequent event just
> cause exact version is hardcoded in includes.  e.g. [5]
>
> The potential benefit is quite big so please come up with proposals
> how/what to do and still improve our procedures.
>
> [1]
> https://wiki.eclipse.org/Development_Resources/How_to_Use_Eclipse_Copyright_Tool
> [2] https://wiki.eclipse.org/Eclipse/PMC/Minutes_2016
> [3]
> https://www.eclipse.org/tycho/sitedocs/tycho-p2/tycho-p2-repository-plugin/assemble-repository-mojo.html#includeAllDependencies
> [4] https://www.eclipse.org/lists/tycho-user/msg08879.html
> [5]
> https://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=58e5c221bfc493e40d499f58c93a17cc14d061ac
>
> --
> Alexander Kurtakov
> Red Hat Eclipse Team
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Why can' I contribute CDO M2?

[Matthias Sohn]

On Wed, Feb 3, 2021 at 4:08 PM Eike Stepper  wrote:

> Hi All,
>
> I just tried to push my bits but I'm getting this message without further
> explanation:
>
> Repository ssh://
> estep...@git.eclipse.org:29418/simrel/org.eclipse.simrel.build
>
> commit f7d8573: An error happened while checking commit
> Processing changes: refs: 1
> Processing changes: refs: 1, done
>

Hard to say what caused this without access to the server logs.
Did you try again ?
Try via https protocol ? For that use the http password you can generate
here
https://git.eclipse.org/r/settings/#HTTPCredentials

Can someone help me, please?!
>
> Cheers
> /Eike
>
> 
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] RFC - moving JGit baseline to Java 11 ?

[Matthias Sohn]

We are considering bumping the minimum Java version for JGit to Java SE 11.
Let us know if you support this proposal or if this would cause problems
for you on bug 569917 
.

-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [egit-dev] [mylyn-dev] Mylyn participation in 2020-12

[Matthias Sohn]

On Sun, Dec 13, 2020 at 7:18 PM Jonah Graham  wrote:

>
>
> On Sun., Dec. 13, 2020, 13:14 Matthias Sohn, 
> wrote:
>
>> On Sun, Dec 13, 2020 at 5:27 AM Jonah Graham 
>> wrote:
>>
>>> On Wed, 9 Dec 2020 at 21:10, Matthias Sohn 
>>> wrote:
>>>
>>>> On Thu, Dec 10, 2020 at 2:55 AM Jonah Graham 
>>>> wrote:
>>>>
>>>>> * The way I get the error message you have is to start with 2020-09
>>>>> committers, add download.eclipse.org/staging/2020-12 as an available
>>>>> software site, check for updates and install all updates. On restart I get
>>>>> the error you report. However in this case, you get a mismash of upgrades
>>>>> and critically you are still running 2020-09 EPP and product. For example
>>>>> you get the new PDE, but the old JDT and platform. If you try the same
>>>>> steps, but disable all sites except the added staging repo, the upgrade
>>>>> will fail with no remedy available error message.
>>>>>
>>>>
>>>> yep, I tried the same steps
>>>>
>>>
>>> Matthias, I used the steps with the URLs for RC2 and everything looks
>>> fine. See https://www.eclipse.org/lists/epp-dev/msg06118.html for the
>>> p2 urls.
>>>
>>
>> Upgrading a 2020-09 package from the 2020-12 staging repository still
>> yields broken mylyn task view.
>> Upgrading it from 2020-12 staging repository and epp repository yields a
>> working mylyn task view.
>> Don't know what will be in the release repository compared to these two
>> tests.
>>
>
> The release repo is a composite repo of the two.
>

then we seem good to go

thanks
-Matthias


> Thanks,
> Jonah
>
>
>> -Matthias
>>
>>
>>> Are you satisfied this is sufficiently resolved for 2020-12?
>>>
>>> Thanks,
>>> Jonah
>>> ___
>>> mylyn-dev mailing list
>>> mylyn-...@eclipse.org
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/mylyn-dev
>>>
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
> ___
> egit-dev mailing list
> egit-...@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/egit-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [mylyn-dev] Mylyn participation in 2020-12

[Matthias Sohn]

On Sun, Dec 13, 2020 at 5:27 AM Jonah Graham  wrote:

> On Wed, 9 Dec 2020 at 21:10, Matthias Sohn 
> wrote:
>
>> On Thu, Dec 10, 2020 at 2:55 AM Jonah Graham 
>> wrote:
>>
>>> * The way I get the error message you have is to start with 2020-09
>>> committers, add download.eclipse.org/staging/2020-12 as an available
>>> software site, check for updates and install all updates. On restart I get
>>> the error you report. However in this case, you get a mismash of upgrades
>>> and critically you are still running 2020-09 EPP and product. For example
>>> you get the new PDE, but the old JDT and platform. If you try the same
>>> steps, but disable all sites except the added staging repo, the upgrade
>>> will fail with no remedy available error message.
>>>
>>
>> yep, I tried the same steps
>>
>
> Matthias, I used the steps with the URLs for RC2 and everything looks
> fine. See https://www.eclipse.org/lists/epp-dev/msg06118.html for the p2
> urls.
>

Upgrading a 2020-09 package from the 2020-12 staging repository still
yields broken mylyn task view.
Upgrading it from 2020-12 staging repository and epp repository yields a
working mylyn task view.
Don't know what will be in the release repository compared to these two
tests.

-Matthias


> Are you satisfied this is sufficiently resolved for 2020-12?
>
> Thanks,
> Jonah
> ___
> mylyn-dev mailing list
> mylyn-...@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/mylyn-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Mylyn participation in 2020-12

[Matthias Sohn]

On Thu, Dec 10, 2020 at 2:55 AM Jonah Graham  wrote:

> Hi Matthias / other parties following along,
>
> I think there are two things going on here. In M3 I removed a very small
> part of Mylyn[1], as far as I understood, just the SDK for a part of Mylyn,
> nothing functional. The error message you reported is not caused by that,
> but instead caused by the problem of p2 not taking into consideration
> "uses" directives when doing the upgrade. The error message you get is just
> a more visible problem than was there since 2020-06. In 2020-06 and 2020-09
> at some points within use of Mylyn a user would get failed operation with
> "java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext" or similar in
> their error log. So in 2020-12 the error has simply been surfaced to happen
> at startup time rather than delayed at runtime.
>
> This error message being visible to everyone doing an upgrade is bad. I
> don't know your exact steps, but got them like this*.
>
> I thought I had mitigated this all properly[2] (i.e. worked around the
> Mylyn bitrotting problem in EPP) by forcing install of the required JAXB
> bundles so that the p2 resolution limitation did not affect the install.
>
> The mitigation done in [2] was supposed to be temporary, i.e until Mylyn
> provided a proper fix! As Mylyn didn't by RC1, I made a slight modification
> to the workaround to make it uninstallable[3]. However, that seems to have
> had the unintended side-effect of causing the upgrade flow to no longer
> upgrade that feature and instead on upgrade that feature is removed from
> the install.
>
> Therefore I will simply revert it [4] and we should be good to go. I have
> tested this locally and will retest tomorrow from the actual build.
>
> There will still be ways to create a bad install, but it should be
> generally harder for users to hit this.
>
> Post-mortem note - this wasn't detected probably because no one tested
> doing an upgrade until you did. I have added an upgrade check to my sanity
> check of releasing.md[5]. Hopefully some of the package maintainers can
> conduct upgrade tests too.
>
>
> * The way I get the error message you have is to start with 2020-09
> committers, add download.eclipse.org/staging/2020-12 as an available
> software site, check for updates and install all updates. On restart I get
> the error you report. However in this case, you get a mismash of upgrades
> and critically you are still running 2020-09 EPP and product. For example
> you get the new PDE, but the old JDT and platform. If you try the same
> steps, but disable all sites except the added staging repo, the upgrade
> will fail with no remedy available error message.
>

yep, I tried the same steps


> As that left me in a different bad state which I don't really consider
> valid I did a check for updates with the following two repos, which are
> pretty close to what the final release repo composite will contain:
> - https://download.eclipse.org/staging/2020-12/
> -
> https://ci.eclipse.org/packaging/job/simrel.epp-tycho-build/lastSuccessfulBuild/artifact/org.eclipse.epp.packages/archive/repository/
> This means that everything upgrades correctly, except the epp.common
> feature as mentioned above. It should work once a build containing [4] is
> built in the next few hours.
>
> [1] https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/172836
> [2] https://www.eclipse.org/lists/epp-dev/msg06089.html
> [3] https://git.eclipse.org/r/c/epp/org.eclipse.epp.packages/+/173324
> [4] https://git.eclipse.org/r/c/epp/org.eclipse.epp.packages/+/173636
> [5]
> https://git.eclipse.org/r/c/epp/org.eclipse.epp.packages/+/173637/1/RELEASING.md
>
> I trust that this will fully resolve the issue until either Mylyn is fixed
> or removed from SimRel. I am very reluctant to remove Mylyn because for the
> people who do like it they really love it and for them it is a big
> differentiator. We need to have a separate discussion about how to save
> Mylyn at some point.
>
> Please let me know your thoughts.
>
> Jonah
>
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
>
> On Wed, 9 Dec 2020 at 16:55, Matthias Sohn 
> wrote:
>
>> On Wed, Dec 9, 2020 at 10:24 AM Matthias Sohn 
>> wrote:
>>
>>> Currently still some parts of Mylyn's contribution to the simrel 2020-12
>>> are disabled [1].
>>> Will this be fixed soon before RC2 ends ?
>>>
>>> I contributed the JGit/EGit 5.10 release to simrel last night assuming
>>> Mylyn would fix
>>> these disabled parts of its contribution.
>>>
>>> If Mylyn is not able to fix this I have to respin EGit today in order to
>>> remove

Re: [cross-project-issues-dev] Mylyn participation in 2020-12

[Matthias Sohn]

On Wed, Dec 9, 2020 at 10:24 AM Matthias Sohn 
wrote:

> Currently still some parts of Mylyn's contribution to the simrel 2020-12
> are disabled [1].
> Will this be fixed soon before RC2 ends ?
>
> I contributed the JGit/EGit 5.10 release to simrel last night assuming
> Mylyn would fix
> these disabled parts of its contribution.
>
> If Mylyn is not able to fix this I have to respin EGit today in order to
> remove the EGit Mylyn
> integration which depends on org.eclipse.mylyn.commons.sdk.feature.group
> which is
> currently disabled in simrel.
>

I got no reaction from Mylyn, neither here nor on [1].
Looks like they silently left the simultaneous release :-(

I am running out of time to respin EGit today to remove the mylyn related
EGit plugins (mylyn and github integrations),
could do that tomorrow.

I tried upgrading a 2020-09 Committer package with the 5.10 JGit/EGit build
using the 2020-12 staging repo.
Upgrade works but afterwards Mylyn views don't load properly complaining
about the missing disabled features
and logging the errors [2]. Manual workaround is to first uninstall the
EGit mylyn integration in 2020-09
and then install EGit and JGit 5.10 without the EGit mylyn integration.

I could remove the mylyn and github integrations from simrel immediately
but then upgrade from 2020-09
would probably fail since in 2020-09 these plugins might be installed. So
they would have to be uninstalled manually.
For proper upgrade from older releases we would need to uninstall these
plugins during the upgrade using p2.inf
surgery. This requires implementing this in EGit and respinning the EGit
release which I could tackle tomorrow.

What do you think ?

-Matthias


> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=564699
>

[2] org.osgi.framework.BundleException: Could not resolve module:
org.eclipse.mylyn.github.ui [535]
  Unresolved requirement: Require-Bundle: org.eclipse.mylyn.tasks.ui;
bundle-version="[3.20.0,4.0.0)"
-> Bundle-SymbolicName: org.eclipse.mylyn.tasks.ui;
bundle-version="3.25.2.v20200814-0512"; singleton:="true"
   org.eclipse.mylyn.tasks.ui [331]
 Unresolved requirement: Require-Bundle:
org.eclipse.mylyn.commons.notifications.feed; bundle-version="1.0.0"
   -> Bundle-SymbolicName:
org.eclipse.mylyn.commons.notifications.feed;
bundle-version="1.17.2.v20200813-0821"; singleton:="true"
  org.eclipse.mylyn.commons.notifications.feed [299]
No resolution report for the bundle.  Bundle was not
resolved because of a uses constraint violation.
  org.apache.felix.resolver.reason.ReasonException: Uses constraint
violation. Unable to resolve resource
org.eclipse.mylyn.commons.notifications.feed [osgi.identity;
type="osgi.bundle"; version:Version="1.17.2.v20200813-0821";
osgi.identity="org.eclipse.mylyn.commons.notifications.feed";
singleton:="true"] because it is exposed to package 'javax.xml.bind' from
resources javax.xml.bind [osgi.identity; type="osgi.bundle";
version:Version="2.2.0.v201105210648"; osgi.identity="javax.xml.bind"] and
jakarta.xml.bind [osgi.identity; osgi.identity="jakarta.xml.bind";
type="osgi.bundle"; version:Version="2.3.3.v20201118-1818"] via two
dependency chains.

Chain 1:
  org.eclipse.mylyn.commons.notifications.feed [osgi.identity;
type="osgi.bundle"; version:Version="1.17.2.v20200813-0821";
osgi.identity="org.eclipse.mylyn.commons.notifications.feed";
singleton:="true"]
require: (&(osgi.wiring.bundle=javax.xml.bind)(bundle-version>=2.2.0))
 |
provide: osgi.wiring.bundle: javax.xml.bind
  javax.xml.bind [osgi.identity; type="osgi.bundle";
version:Version="2.2.0.v201105210648"; osgi.identity="javax.xml.bind"]

Chain 2:
  org.eclipse.mylyn.commons.notifications.feed [osgi.identity;
type="osgi.bundle"; version:Version="1.17.2.v20200813-0821";
osgi.identity="org.eclipse.mylyn.commons.notifications.feed";
singleton:="true"]
require: (&(osgi.wiring.bundle=com.sun.xml.bind)(bundle-version>=2.2.0))
 |
provide: osgi.wiring.bundle;
bundle-version:Version="2.3.3.v20201118-1818";
osgi.wiring.bundle="com.sun.xml.bind"
  com.sun.xml.bind [osgi.identity; osgi.identity="com.sun.xml.bind";
type="osgi.bundle"; version:Version="2.3.3.v20201118-1818"]
import:
(&(osgi.wiring.package=javax.xml.bind)(&(version>=2.3.3)(!(version>=2.3.4
 |
export: osgi.wiring.package: javax.xml.bind
  jakarta.xml.bind [osgi.identity; osgi.identity="jakarta.xml.bind";
type="osgi.bundle"; version:Version="2.3.3.v20201118-1818"]
at org.eclipse.osgi.container.Module.start(Modul

[cross-project-issues-dev] Mylyn participation in 2020-12

[Matthias Sohn]

Currently still some parts of Mylyn's contribution to the simrel 2020-12
are disabled [1].
Will this be fixed soon before RC2 ends ?

I contributed the JGit/EGit 5.10 release to simrel last night assuming
Mylyn would fix
these disabled parts of its contribution.

If Mylyn is not able to fix this I have to respin EGit today in order to
remove the EGit Mylyn
integration which depends on org.eclipse.mylyn.commons.sdk.feature.group
which is
currently disabled in simrel.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=564699

-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] 2020-12 Release

[Matthias Sohn]

JGit and EGit will release 5.10.0 for 2020-12. I created the missing
release records.
Details are still to be done.

-Matthias

On Thu, Nov 26, 2020 at 9:45 PM Wayne Beaton <
wayne.bea...@eclipse-foundation.org> wrote:

> Greetings folks.
>
> Thanks for all of your hard work in assembling your contributions to the
> simultaneous release.
>
> I've created the master record ("release page") for the 2020-12
> simultaneous release .
> Please have a look at the page and let me know what I've gotten wrong.
>
> I've started comparing it to the build aggrcon files and have noticed that
> a few projects appear to be contributing new releases but have not yet
> created release records. Please make sure that you've created the
> release record
>  before
> asking me to update the release page.
>
> Selecting the right release record has required some guesswork on my part.
> I did notice that some of the release records have dates that are later
> than the simultaneous release date. Please make the value in the release
> date field for your release record is no later than December 16/2020.
>
> There were a few records dated 2020-12-18 that (at least according to the
> aggrcon files) I believe that I have correctly guessed are participating in
> the release; there was at least one release dated much later in December
> that I wasn't sure about and instead opted to pick the previous release as
> the participating one.
>
> If your project's release date is more than one year later than the date
> of your project's last successful release review, then you must engage in a
> release review. The EMO will automatically start tracking your release
> review when you submit your IP Log for review. Note that you only need to
> submit your IP Log for review or request PMC approval for your release if
> you are engaging in a release review.
>
> Even if your project does not require a release review, you must still
> take care to ensure that all of the intellectual property included in your
> release has been property vetted by the IP due diligence process. If you
> require assistance, please contact the IP Team.
>
> Note that the IP Team consults the future release records as input into
> their prioritization. Please create your release records as early as
> possible (even if you have to shift the date later) to ensure that we have
> as much information as possible to assist with prioritization and improve
> our odds of getting the intellectual property that you care about cleared
> well in advance of your planned release date.
>
> Wayne
> --
>
> Wayne Beaton
>
> Director of Open Source Projects | Eclipse Foundation, Inc.
>
> Join us at our virtual event: EclipseCon 2020
>  - October 20-22
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Platform: Enable usage of operating system root certificates / trust store in default SSLContext?

[Matthias Sohn]

On Thu, Oct 15, 2020 at 9:38 AM Ed Merks  wrote:

> Sebastian,
>
> This issue sounds related to the following Bugzilla, which has kind of
> morphed into "update to latest release installs JustJ JRE":
>
>   https://bugs.eclipse.org/bugs/show_bug.cgi?id=567504
>
> But in any case, the user noticed because they were expecting their
> /etc/ssl/certs/java/cacerts to be used, but the embedded JRE uses its own
> cacerts and no others.
>
> I've seen the problem you describe at customer sites as well, where it
> caused problems with p2 access to update sites that went through the
> corporate firewall so folks had to add root certificates to their JDK
> installation.
>
> So this does sound very useful, though I don't understand the full details
> and implications...
>
> Regards,
> Ed
> On 07.10.2020 15:45, Ratz, Sebastian wrote:
>
> Hello,
>
>
>
> A JVM brings its own set of root CA certificates as the root of trust
> (lib/security/cacerts).
>
>
>
> This also means that Eclipse relies on that trust store for every HTTPS
> call, e.g. the update mechanism (Eclipse update sites use HTTPS since not
> too long, so this was not that big of a problem before).
>
>
>
>
>
> However – especially in many corporate environments – TLS injection
> proxies are deployed that hook into TLS connections and re-sign traffic
> using a new certificate.
>
> Usually this certificate is also deployed into the operating system trust
> store, such that browser and other functionality is not impacted.
>
> However, since Eclipse relies on the JVM trust store, Eclipse is left out
> of the loop here.
>
>
>
> This then leads to typical problems such as
>
> sun.security.validator.ValidatorException … PKIX path building failed:
> sun.security.provider.SunCertPathBuilderException: unable to find valid
> certification path to requested target
>
>
>
>
>
> In order to work around that issue we have implemented an
> javax.net.ssl.SSLContext with custom X509KeyManager and X509TrustManager
> that additionally load the operating system trust/key store (Windows-ROOT
> and Windows-MY on Windows, and KeychainStore on macOs). We use this for
> HTTPS calls that we make from within our own plugins.
>
>
>
> But since we do not modify the JVM-wide default
> (javax.net.ssl.SSLContext.setDefault(SSLContext)) in order to avoid
> influencing any potential 3rd-party plugins, we still have to deal with
> customer problems where e.g. the update mechanism is affected.
>
>
>
>
>
> *Is there interest in the platform to have this functionality in the core
> platform?*
>
>
>
> We could then contribute our implementation and Eclipse Platform could
> then use SSLContext.setDefault() to modify the default very early-on during
> startup, optionally with a preference to enable/disable this behavior.
>
>
>
>
>
> An initial list that would be affected by (would benefit from) this:
>
>- Update mechanism
>- EGit
>
> +1 for EGit


>
>-
>- …
>
>
>
> Since the embedded browser has always used the OS trust store, a
> discrepancy between that and HTTPS calls made from within Eclipse would
> also be resolved.
>
>
>
>
>
> Best regards,
>
> Sebastian Ratz
>
> ___
> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] updating httpcomponents to 5.0.2 for JGit/EGit

[Matthias Sohn]

On Wed, Oct 7, 2020 at 10:18 PM Matthias Sohn 
wrote:

> On Wed, Oct 7, 2020 at 1:21 PM Aleksandar Kurtakov 
> wrote:
>
>>
>>
>> On Wed, Oct 7, 2020 at 2:15 PM Matthias Sohn 
>> wrote:
>>
>>> This is a heads up regarding usage of Apache httpcomponents.
>>> We are considering to update httpcomponents (httpcore and httpclient) to
>>> 5.0.2 for JGit/EGit.
>>> See [1] and the changes adding these new versions to Orbit [2].
>>> I still need to add conscrypt to Orbit which is an optional dependency
>>> for the
>>> http 2.0 implementation in httpcore5-h2.
>>>
>>> Let us know if there are any concerns regarding this plan.
>>>
>>
>> Have you considered (or even evaluated) usage of Java 11 HttpClient
>> instead?
>>
>
> JGit today's default uses HttpURLConnection in the core org.eclipse.jgit
> bundle. Optionally
> apache httpclient 4.5.10 can be used instead via the
> org.eclipse.jgit.http.apache bundle.
>
> I am looking at updating the latter to apache httpclient 5.0.2.
> According to the migration guide API changes
> compared to 4.5.10 aren't huge.
>
> We may consider to replace the default implementation using
> HttpURLConnection in org.eclipse.jgit
> with the new Java 11 http client. This would require to update the
> execution environment for JGit from Java 8 to 11.
>

In EGit the user can also choose between the Java built-in http client
(currently HttpURLConnection)
and Apache httpclient.


>
>
>>
>>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=567654
>>> [2]  https://git.eclipse.org/r/c/orbit/orbit-recipes/+/170406/1
>>> https://git.eclipse.org/r/c/orbit/orbit-recipes/+/170407/1
>>> https://git.eclipse.org/r/c/orbit/orbit-recipes/+/170408/1
>>>
>>> -Matthias
>>> ___
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@eclipse.org
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>>
>>
>> --
>> Alexander Kurtakov
>> Red Hat Eclipse Team
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] updating httpcomponents to 5.0.2 for JGit/EGit

[Matthias Sohn]

On Wed, Oct 7, 2020 at 1:21 PM Aleksandar Kurtakov 
wrote:

>
>
> On Wed, Oct 7, 2020 at 2:15 PM Matthias Sohn 
> wrote:
>
>> This is a heads up regarding usage of Apache httpcomponents.
>> We are considering to update httpcomponents (httpcore and httpclient) to
>> 5.0.2 for JGit/EGit.
>> See [1] and the changes adding these new versions to Orbit [2].
>> I still need to add conscrypt to Orbit which is an optional dependency
>> for the
>> http 2.0 implementation in httpcore5-h2.
>>
>> Let us know if there are any concerns regarding this plan.
>>
>
> Have you considered (or even evaluated) usage of Java 11 HttpClient
> instead?
>

JGit today's default uses HttpURLConnection in the core org.eclipse.jgit
bundle. Optionally
apache httpclient 4.5.10 can be used instead via the
org.eclipse.jgit.http.apache bundle.

I am looking at updating the latter to apache httpclient 5.0.2.
According to the migration guide API changes
compared to 4.5.10 aren't huge.

We may consider to replace the default implementation using
HttpURLConnection in org.eclipse.jgit
with the new Java 11 http client. This would require to update the
execution environment for JGit from Java 8 to 11.


>
>> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=567654
>> [2]  https://git.eclipse.org/r/c/orbit/orbit-recipes/+/170406/1
>> https://git.eclipse.org/r/c/orbit/orbit-recipes/+/170407/1
>> https://git.eclipse.org/r/c/orbit/orbit-recipes/+/170408/1
>>
>> -Matthias
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>
>
> --
> Alexander Kurtakov
> Red Hat Eclipse Team
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] updating httpcomponents to 5.0.2 for JGit/EGit

[Matthias Sohn]

This is a heads up regarding usage of Apache httpcomponents.
We are considering to update httpcomponents (httpcore and httpclient) to
5.0.2 for JGit/EGit.
See [1] and the changes adding these new versions to Orbit [2].
I still need to add conscrypt to Orbit which is an optional dependency for
the
http 2.0 implementation in httpcore5-h2.

Let us know if there are any concerns regarding this plan.

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=567654
[2]  https://git.eclipse.org/r/c/orbit/orbit-recipes/+/170406/1
https://git.eclipse.org/r/c/orbit/orbit-recipes/+/170407/1
https://git.eclipse.org/r/c/orbit/orbit-recipes/+/170408/1

-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Updated Eclipse licenses ?

[Matthias Sohn]

On Tue, Sep 1, 2020 at 10:52 PM Ralph Soika  wrote:

> Hi,
>
> in our projects (soa-bpmn, soa-bepl, mdt-bpmn2) the eclipse license text
> seems to be outdated (it is still from the year 2011).
>
> Can someone please point me to a page or another eclipse project, where I
> can see the correct Eclipse license text, so that I can copy the text into
> my features.properties and license.html artifacts. Especially the text for
> the feature.properties has a curious formatting. So I am looking for a
> features.properties file where I can copy this formatting to avoid breaking
> the text formatting at some line where I should not do so.
>
> we use the eclipse license feature [1] e.g. here in the egit feature [2].
The version of the license feature is defined in the target platform we use
[3].
In feature.properties we use [4]. If there is a new version of the license
we
update the version of the license feature we include in the target platform.

[1]
https://git.eclipse.org/r/plugins/gitiles/cbi/org.eclipse.license/+/refs/heads/master
[2]
https://git.eclipse.org/r/plugins/gitiles/egit/egit/+/refs/heads/master/org.eclipse.egit-feature/feature.xml#8
[3]
https://git.eclipse.org/r/plugins/gitiles/egit/egit/+/refs/heads/master/org.eclipse.egit.target/egit-4.16-staging.target#25
[4]
https://git.eclipse.org/r/plugins/gitiles/egit/egit/+/refs/heads/master/org.eclipse.egit-feature/feature.properties#22


-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Simultaneous Release Page 2020-09

[Matthias Sohn]

On Thu, Aug 27, 2020 at 10:45 PM Ralph Soika  wrote:

> Hi Wayne,
>
> the versions for the soa-bpel.aggrecon and the mdt-bpmn2.aggrecon are not
> as I expected them.
>
> I have submitted my changes to gerrit under the following commit address:
> https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/167721
>
> The new versions for these parts are:
>
> *mdt-bpmn2.aggrecon from 1.5.0 -> 1.5.1*
>   "https://download.eclipse.org/modeling/mdt/bpmn2/updates/2020-09/1.5.1;
> >
>  versionRange="1.5.1">
>href="simrel.aggr#//@customCategories[identifier='SOA%20Development']"/>
> 
>   
>
>
> *soa-bpel.aggrecon from 1.1.2 -> 1.1.3*
>"https://download.eclipse.org/bpel/updates/2020-09/1.1.3;
> >
>  versionRange="1.1.3">
>href="simrel.aggr#//@customCategories[identifier='SOA%20Development']"/>
> 
>  versionRange="1.1.3">
>href="simrel.aggr#//@customCategories[identifier='SOA%20Development']"/>
> 
>  name="org.eclipse.bpel.apache.ode.runtime.feature.feature.group"
> versionRange="1.1.3">
>href="simrel.aggr#//@customCategories[identifier='SOA%20Development']"/>
> 
>   
>
>
> It looks like this changes have not made it into the simrel.
>
> You know I am new in this role and I wonder what I have done wrong? I
> submitted my changes to gerrit at the 2020-08-14 23:25:10 . As my commits
> looked fine I expected this changes will be merged. But now I see there are
> merge conflicts. I am pretty sure that I have pulled the
> org.eclipse.simrel.build project imidiately before I pushed my changes to
> gerrit.
>
> Can you help me with this issue?
>
After pushing your change for review (push origin HEAD:refs/for/master)
wait for the validation build to finish.
If it succeeded either review your change yourself, vote +2 on Code Review
if it is ok and submit it
or ask another simrel committer to review.

AFAIK changes must be submitted latest on Wednesday of the respective
milestone or RC latest until 5pm EST.
SInce there are dependencies between projects the deadlines are staggered
from +0 (submit until Friday before milestone date,
e.g. Eclipse platform),  +1 (submit on Monday), +2 (submit until Tuesday)
and +3 (submit until Wednesday), see
https://wiki.eclipse.org/SimRel/Simultaneous_Release_Cycle_FAQ#How_to_decide_if_offset_is_.2BN_category
If you are late speak up on this mailing list.

Find the schedule for the 2020-09 release here
https://wiki.eclipse.org/Category:SimRel-2020-09
the recommended way to contribute updates via Gerrit review is described in
https://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build#Contribute_via_a_Gerrit_review_.28recommended.29
the simultaneous release FAQ is here
https://wiki.eclipse.org/SimRel/Simultaneous_Release_Cycle_FAQ

-Matthias

> Best regards
>
> Ralph
>
>
>
> On 27.08.20 20:50, Wayne Beaton wrote:
>
> I've created the tracking page for 2020-09
> . Please have a look to
> ensure that I've correctly recorded your project's participation correctly.
>
> In particular, please make sure that I have the version right. If I've
> made a mistake... please first make sure that you've created a release
> record for the right version and then let me know to update the tracking
> page to point to that version.
>
> If you are contributing a new major or minor release and have not engaged
> in a release review since September 16/2019, then you need to submit your
> IP Log and connect with EMO ASAP to initiate the release review process.
> Note that you only need to submit your IP Log for review if you are
> required to engage in a release review. There's more information in the
> handbook .
>
> Based on messages on this list, both Eclipse Corrosion, Eclipse EMFStore,
> and Eclipse Tools for Cloud Foundry (CFT) have dropped out, so they've been
> removed from the list.
>
> *AFAICT, the corrosion.aggrcon file still exists and is not disabled.* Also,
> since CFT has dropped out, its aggrcon file should also be removed (not
> just disabled). Can somebody take care of that, please?
>
> Thanks for all your efforts.
>
> Wayne
> --
>
> Wayne Beaton
>
> Director of Open Source Projects | Eclipse Foundation, Inc.
>
> Join us at our virtual event: EclipseCon 2020
>  - October 20-22
>
> ___
> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> --
>
> *Imixs Software Solutions GmbH*
> *Web:* www.imixs.com *Phone:* +49 (0)89-452136 16
> *Office:* Agnes-Pockels-Bogen 1, 80992 München
> Registergericht: Amtsgericht Muenchen, HRB 136045
> Geschaeftsführer: Gaby Heinle u. Ralph Soika
>
> *Imixs* is an 

Re: [cross-project-issues-dev] Commits Fail to Find ECA

[Matthias Sohn]

On Sat, Aug 22, 2020 at 10:04 AM Ed Merks  wrote:

> I have this failure trying to commit:
>
> Repository ssh://eme...@git.eclipse.org:29418/emf/org.eclipse.emf
>
> commit fb27b26: An Eclipse Contributor Agreement is required.
> Processing changes: refs: 1
> Processing changes: refs: 1, done
> commit fb27b26: --
> commit fb27b26: Reviewing commit: fb27b260
> commit fb27b26: Authored by: Ed Merks 
> commit fb27b26:
> ERROR: commit fb27b26: The author does not have a current Eclipse
> Contributor Agreement (ECA) on file.
> If there are multiple commits, please ensure that each author has a ECA.
> commit fb27b26:
> commit fb27b26: Please see http://wiki.eclipse.org/ECA
>
> So perhaps the bugzilla problem is more widespread and ECAs are not
> found in general.
>

checking your ECA via the ECA validation in the portal also fails.
For myself the ECA validation succeeds.


>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] 2020-06 Release

[Matthias Sohn]

JGit will like EGit also ship 5.8 with 2020-06, I added the missing release
entry
https://projects.eclipse.org/projects/technology.jgit/releases/5.8.0

-Matthias

On Wed, May 20, 2020 at 5:59 PM Wayne Beaton <
wayne.bea...@eclipse-foundation.org> wrote:

> Hey folks!
>
> I've created the record for the 2020-06 Simultaneous Release
> . As usual, I've used the
> information that I have available to make my best guess at which version
> you're releasing. If I've got something wrong, please first make sure that
> you've created a release record with the right date and then let me know to
> update the corresponding entry on the release page.
>
> I noticed that several of the contributions are more than one year old
> (some of them significantly more). I don't believe that it's necessarily
> wrong to contribute stable content, but would like to make sure that
> somebody is periodically testing configurations that include these
> contributions to mitigate the risk that we ship broken content.
>
> Eclipse Tools for Cloud Foundry (2018)
> Eclipse BIRT (2017)
> Eclipse Mylyn (2018)
> Eclipse WindowBuilder (early 2019)
> Eclipse Xpand (2016)
> Eclipse Remote Systems Explorer (2018)
> Eclipse EMFStore (2017)
> Eclipse BPMN2 Model (2018)
> Eclipse BPEL Designer (2018)
> Eclipse ACTF (2017)
>
> Wayne
>
>
>
>
>
> --
>
> Wayne Beaton
>
> Director of Open Source Projects | Eclipse Foundation, Inc.
>
> Join us at our virtual event: EclipseCon 2020
>  - October 20-22
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] contribution statistics

[Matthias Sohn]

Hi,

I am looking for contribution statistics to Eclipse projects. I am aware of
the "Who's involved" tab
in the project portal (e.g. [1]) but this only provides a 3 month summary
per project. This is also
available on top level project level [2]. Though I am looking for overall
statistics across all Eclipse
projects and a breakdown.

I remember there was a page providing such data but I can't find it anymore.

[1] https://projects.eclipse.org/projects/technology.jgit/who
[2] https://projects.eclipse.org/projects/technology/who

-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] JGit/EGit contribution will be late

[Matthias Sohn]

JGit/EGit contribution is merged, build is running, another build is
pending to pickup the swtbot contribution
which was merged after the JGit/EGit contribution.

On Wed, May 6, 2020 at 9:52 PM Matthias Sohn 
wrote:

> I need a bit more time for the JGit/EGit contribution to M2.
> Fighting with Jenkins build pods crashing without an apparent reason.
>
> -Matthias
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] JGit/EGit contribution will be late

[Matthias Sohn]

I need a bit more time for the JGit/EGit contribution to M2.
Fighting with Jenkins build pods crashing without an apparent reason.

-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] org.apache.commons.codec

[Matthias Sohn]

I updated the JGit/EGit contribution
https://git.eclipse.org/r/#/c/158269/
and this now comes with the latest versions of commons codec (1.13.0) and
Apache httpclient (4.5.10) and httpcore (4.4.12)
https://repo.eclipse.org/content/unzip/releases.unzip/org/eclipse/egit/org.eclipse.egit.repository/5.7.0.202002241735-m3/org.eclipse.egit.repository-5.7.0.202002241735-m3.zip-unzip/plugins/

On Mon, Feb 24, 2020 at 6:39 PM Matthias Sohn 
wrote:

> I need to update the JGit/EGit contribution to the release train
> repository, will do this asap
>
> On Mon, Feb 24, 2020 at 4:32 PM Andrey Loskutov  wrote:
>
>> Matthias just pushed an update of JGit dependencies that AFAIK would also
>> use latest Orbit, see https://git.eclipse.org/r/158190
>>
>> Kind regards,
>> Andrey Loskutov
>>
>> Спасение утопающих - дело рук самих утопающих
>>
>> https://www.eclipse.org/user/aloskutov
>>
>>
>> *Gesendet:* Montag, 24. Februar 2020 um 15:43 Uhr
>> *Von:* "Jonah Graham" 
>> *An:* "Cross project issues" 
>> *Betreff:* [cross-project-issues-dev] org.apache.commons.codec
>> Hi folks,
>>
>> I am trying to resolve a dependency problem - there are multiple versions
>> of the following in
>> https://download.eclipse.org/staging/2020-03/plugins/
>>
>> org.apache.httpcomponents.httpclient has 4.5.2, 4.5.6 and 4.5.10*
>> org.apache.commons.codec has versions 1.9.0, 1.10.0 and 1.13.0*
>>
>> Of those only the * ones are in current orbit.
>>
>> What is the way to resolve this? At the moment, AFAICT for example,
>> egit's simrel contribution requires jgit
>> (org.eclipse.jgit.http.apache.feature.group) which requires
>> o.a.h.httpclient 4.5.6 which requires o.a.c.codec 1.10.
>>
>> This is causing me problems for CDT as when I tried to upgrade our
>> target platform to Eclipse Platform's M3 contribution, I can no longer
>> resolve egit because current orbit does not have the org.apache
>> dependencies that egit/jgit needs.
>>
>> This is not a new problem, 2019-12 had 2 versions of each of the above
>> libraries, now we are at three of them.
>>
>> Any suggestions?
>>
>> Thanks
>> Jonah
>>
>> ~~~
>> Jonah Graham
>> Kichwa Coders
>> www.kichwacoders.com
>> ___ cross-project-issues-dev
>> mailing list cross-project-issues-dev@eclipse.org To change your
>> delivery options, retrieve your password, or unsubscribe from this list,
>> visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] org.apache.commons.codec

[Matthias Sohn]

I need to update the JGit/EGit contribution to the release train
repository, will do this asap

On Mon, Feb 24, 2020 at 4:32 PM Andrey Loskutov  wrote:

> Matthias just pushed an update of JGit dependencies that AFAIK would also
> use latest Orbit, see https://git.eclipse.org/r/158190
>
> Kind regards,
> Andrey Loskutov
>
> Спасение утопающих - дело рук самих утопающих
>
> https://www.eclipse.org/user/aloskutov
>
>
> *Gesendet:* Montag, 24. Februar 2020 um 15:43 Uhr
> *Von:* "Jonah Graham" 
> *An:* "Cross project issues" 
> *Betreff:* [cross-project-issues-dev] org.apache.commons.codec
> Hi folks,
>
> I am trying to resolve a dependency problem - there are multiple versions
> of the following in  https://download.eclipse.org/staging/2020-03/plugins/
>
> org.apache.httpcomponents.httpclient has 4.5.2, 4.5.6 and 4.5.10*
> org.apache.commons.codec has versions 1.9.0, 1.10.0 and 1.13.0*
>
> Of those only the * ones are in current orbit.
>
> What is the way to resolve this? At the moment, AFAICT for example, egit's
> simrel contribution requires jgit
> (org.eclipse.jgit.http.apache.feature.group) which requires
> o.a.h.httpclient 4.5.6 which requires o.a.c.codec 1.10.
>
> This is causing me problems for CDT as when I tried to upgrade our
> target platform to Eclipse Platform's M3 contribution, I can no longer
> resolve egit because current orbit does not have the org.apache
> dependencies that egit/jgit needs.
>
> This is not a new problem, 2019-12 had 2 versions of each of the above
> libraries, now we are at three of them.
>
> Any suggestions?
>
> Thanks
> Jonah
>
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
> ___ cross-project-issues-dev
> mailing list cross-project-issues-dev@eclipse.org To change your delivery
> options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Issues with git/gerrit and sometimes bugzilla

[Matthias Sohn]

On Mon, Feb 10, 2020 at 4:37 PM Mikael Barbero <
mikael.barb...@eclipse-foundation.org> wrote:

> Some of you are still unable to log into services like git/gerrit,
> bugzilla or jenkins.
>
> Webmasters are currently looking into it and will keep you posted as soon
> as it's fixed.
>

please also look at
https://bugs.eclipse.org/bugs/show_bug.cgi?id=559980
it seems cloning via git daemon is also broken


> Thanks for your patience.
>
> *Mikaël Barbero *
> *Team Lead - Release Engineering | Eclipse Foundation*
>  @mikbarbero
> Eclipse Foundation : The Platform for Open
> Innovation and Collaboration
>
> Le 7 févr. 2020 à 20:42, Matthew Ward 
> a écrit :
>
> One of our backend storage nodes fell over which has impacted service
> availability.  We've cut over to our standby and are restarting services as
> required to bring everything back up.
>
> -Matt.
>
> On Fri, Feb 7, 2020 at 2:03 PM Thomas Watson  wrote:
>
>> I've been getting 502 errors access the eclipse servers, bug
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=559928 opened.
>>
>>
>> Tom
>>
>>
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Can SLF4J be made the official logging API for Eclipse projects?

[Matthias Sohn]

Roland told me that for adding new content to Orbit (which is most often
required for new versions of already approved third party libraries)
we should still file CQs until the new process and tools are sorted out.

On Fri, Jan 24, 2020 at 5:25 PM Wayne Beaton <
wayne.bea...@eclipse-foundation.org> wrote:

> I'm working on some updates to the handbook and we're rolling out some
> (relatively minor) updates to the "Create a CQ" functionality on the PMI.
> My apologies to all that this is taking longer than I'd hoped.
>
> The short version is that you don't need any tools to not create a CQ.
>
> In this particular case, we know that the libraries in question have been
> approved by the IP due diligence process, so just don't create any new CQs.
> The challenging bit is how we make it easier for committers to know that
> they don't need to create a CQ; I'm working on a solution to that problem
> that I've committed to rolling out this quarter (at least part of which
> will be contributed to Eclipse Dash, so you all can help maintain it). I
> need you to be patient for a little while longer for this.
>
> The slightly longer version is that I've spent a lot of effort to get our
> existing IP data into a state where we can do more in an automated manner.
> Over the years we've collected a lot of data, but--as you likely already
> know--it's not been collected in a form that makes it consistently
> queryable. I've got that (mostly) sorted out. We're also starting to
> leverage license data from Clearly Defined, a project which crowd sources
> license data from open source projects. My expectation is that we will
> still need to create CQs for third party content, we'll just have to create
> a lot fewer of them. Those that we do create will follow the same process
> that we do today. Again, I owe a longer explanation.
>
> Regarding IP Logs, I've been experimenting using build tools to fill in
> the gaps. This works pretty well for Maven-, Gradle- and NPM-based builds,
> where you can build an accurate dependency list right out of the tool
> (e.g., "mvn dependency:list"). FWIW, the tools that I referred to have
> evolved from scripts that I've been using for a few months to map the
> results from that dependency list to license and CQ information. I'll start
> attaching the output from the scripts to IP Log CQs as a stop gap.
>
> HTH,
>
> Wayne
>
> On Fri, Jan 24, 2020 at 11:02 AM Christian Dietrich <
> christian.dietr...@itemis.de> wrote:
>
>> but where is then new tooling for that ?
>>
>> the portal still creates cqs
>> Am 24.01.20 um 16:58 schrieb Wayne Beaton:
>>
>> - the bureaucracy
>>
>>
>> I assume that you mean IP due diligence. There should be no Eclipse
>> Foundation bureaucracy required. All of the libraries in question have
>> already been approved, so the project team can just start using them.
>>
>> Following the Eclipse Foundation's Board of Directors approval of our new
>> IP Policy in October, Piggyback CQs are no longer required. I owe the
>> community a much longer discussion about all of the changes. There is some
>> discussion on by 
>> blog
>>  
>> 
>> .
>>
>> You will still have to submit your IP Log for review, but only the next
>> time that you actually have to do a release review. Note that changes made
>> to the EDP in December 2018 make it so that you can do releases for an
>> entire year following a successful release review (i.e., we no longer
>> require a review for every single release).
>>
>> I hope that this knocks at least one thing off of the list (I understand
>> that the other things on the list are harder
>>
>> HTH,
>>
>> Wayne
>>
>> On Fri, Jan 24, 2020 at 3:07 AM Christian Dietrich 
>>  wrote:
>>
>>
>> Hi,
>>
>> we (Xtext) currently have no capacity to do
>>
>> - the bureaucracy
>> - analyze impacts on logging customization points in Xtext
>> - analyze who else uses what logging and how that change would affect them
>> and indirectly us
>>
>> Regards
>> Christian
>> Am 23.01.20 um 15:05 schrieb Ed Willink:
>>
>> Hi
>>
>> If there is a conflict hazard then it already exists. Examining one of my
>> workspaces...
>>
>> Good (SLF4J) - jgit, m2e
>> Bad (LOG4J) - mwe, ocl, qvtd, xtend, xtext
>>
>> This is complete news to me. I continue to use log4j since it avoids
>> changing code styles that have been unchanged for many many years. Other
>> projects probably just copy prevailing practice.
>>
>> I presume changing is rather easy, and of no consequence to the exported
>> API, since the use of log4j is by import package.
>>
>> However without a commitment to change by Xtext, I would be reluctant to
>> change any Xtext-based project.
>>
>> Regards
>>
>> Ed Willink
>> On 23/01/2020 13:09, Hickman, Steve (AdvTech) wrote:
>>
>> Log4j 1.x reached end of life in 2015. The documentation for it now
>> appears to have gone 

[cross-project-issues-dev] removing assertj 1.7.1

[Matthias Sohn]

I added the latest version 3.14 of assertj to Orbit [1] and pushed a change
to remove the old version 1.7.1 [2]. Please consider to update to the new
version and vote on the change for removing the old version. In general we
could remove it on the master branch since if you really
still need the old version you can consume it from existing R-builds of
Orbit.

The following projects have an approved CQ for 1.7.1:
- eclipse.platform [3]
- tools.linuxtools [4]
- tools.windowbuilder [5]
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=559225
[2] https://git.eclipse.org/r/#/c/156220/
[3] https://dev.eclipse.org/ipzilla/show_bug.cgi?id=9715
[4] https://dev.eclipse.org/ipzilla/show_bug.cgi?id=10279
[5] https://dev.eclipse.org/ipzilla/show_bug.cgi?id=15010
-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] proposed Orbit update: switch from com.spotify.docker.client to org.mandas.docker.client

[Matthias Sohn]

On Tue, Jan 21, 2020 at 11:12 PM Homer, Tony  wrote:

> Over on orbit-dev, Roland Grunberg suggested that I notify this list about
> this proposed change due to the potential impact on other projects.
>
> Please refer to https://bugs.eclipse.org/bugs/show_bug.cgi?id=558284 for
> detailed background info.
>
> In a nutshell, com.spotify.docker.client (currently available via Orbit)
> is no longer maintained and has dependencies with CVEs.  A Java docker
> client is needed by linux-tools docker tooling (and at least one downstream
> project which is maintained by my team).  org.mandas.docker.client is a
> fork of Spotify Docker Client which is being actively maintained with
> special consideration for CVE mitigation.  It preserves the existing
> interface but changes the package name from com.spotify to org.mandas, so
> projects using it as a dependency will need to make some updates (but they
> should be mostly straightforward).  The dependency set is almost entirely
> updated and in some cases changed in order to eliminate problematic or
> unmaintained dependencies.  The proposal is to replace
> com.spotify.docker.client with org.mandas.docker.client in Orbit. This will
> require a large number of updates in Orbit (many of the updates should be
> made anyway due to CVEs in the versions which are currently availabl
>  e in Orbit).  The proposed list of changes follows.
>
> Update to org.slf4j.api 1.7.29, remove 1.7.2 and 1.7.10
>
> Update jackson to 2.10.1, remove 2.9.9/2.9.93 (this set of changes will
> include com.fasterxml.jackson.core.jackson-annotations,
> com.fasterxml.jackson.core.jackson-core,
> com.fasterxml.jackson.core.jackson-databind,
> com.fasterxml.jackson.datatype.jackson-datatype-guava,
> com.fasterxml.jackson.jaxrs.jackson-jaxrs-base,
> com.fasterxml.jackson.jaxrs.jackson-jaxrs-json-provider)
>
> Update to jersey 2.29.1, remove 2.22.1 (this set of changes will include
> org.glassfish.jersey.apache.connector,
> org.glassfish.jersey.bundles.repackaged.jersey-guava,
> org.glassfish.jersey.containers.servlet,
> org.glassfish.jersey.containers.servlet.core,
> org.glassfish.jersey.core.jersey-client,
> org.glassfish.jersey.core.jersey-common,
> org.glassfish.jersey.core.jersey-server,
> org.glassfish.jersey.ext.entityfiltering,
> org.glassfish.jersey.media.jersey-media-json-jackson)
>
> Update to javax.activation 1.1.1, remove 1.1.0
>
> Update to org.apache.commons.compress 1.19, remove 1.6.0, 1.15.0, 1.18.0
>

I already updated apache commons compress to 1.19.0
https://bugs.eclipse.org/bugs/show_bug.cgi?id=558859
it's available in I-builds
https://download.eclipse.org/tools/orbit/downloads/drops/I20200120214610/

Update to com.github.jnr.unixsocket 0.24.0, remove 0.18.0
>
> Update to org.mockito.core 3.2.0, remove 2.23.0
>
> Update to ch.qos.logback.* 1.2.3, remove 1.0.7, 1.1.2 (this set of changes
> will include ch.qos.logback.classic, ch.qos.logback.core,
> ch.qos.logback.slf4j)
>
> Add org.immutables.value 2.8.2
>
> Add com.google.google-auth-library-oauth2-http 0.18.0
>
> Add com.google.jimfs  1.1
>
> Add joda-time 2.10.5
>
> Add org.awaitility 4.0.1
>
> Add com.squareup.okhttp3.mockwebserver 4.2.2
>
> Add com.spotify.hamcrest-jackson 1.1.5
>
> Add com.spotify.hamcrest-pojo 1.1.5
>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [eclipse.org-committers] Use Milestones/RCs To Test and Run

[Matthias Sohn]

I can't find the RC2 packages, are they already available ?
Can't find them here
https://www.eclipse.org/downloads/packages/release/2019-12/rc2

-Matthias

On Fri, Dec 13, 2019 at 4:11 PM Daniel Megert 
wrote:

> The Platform cannot envision all the ways it is used. We do what we can to
> test. So, as long as you test your stuff against all the milestones and
> then don't file bugs after RC2 - fine.
>
> Dani
>
>
>
> From:Greg Watson 
> To:Daniel Megert 
> Cc:Eclipse Cross Project Issues <
> cross-project-issues-dev@eclipse.org>, eclipse.org-committ...@eclipse.org
> Date:13.12.2019 15:11
> Subject:[EXTERNAL] Re: [cross-project-issues-dev]
> [eclipse.org-committers] UseMilestones/RCs To Test and Run
> Sent by:cross-project-issues-dev-boun...@eclipse.org
> --
>
>
>
> Projects have enough on their plates testing their own code, let alone
> testing the platform. This seems to be a deficiency in the regression
> testing of the platform, and should be handled by the platform team IMHO.
>
> Greg
>
> On Dec 13, 2019, at 5:23 AM, Daniel Megert <*daniel_meg...@ch.ibm.com*
> > wrote:
>
> It would be great if everyone could at least test or even better, run on
> the latest milestone/RC. Platform got a stop ship bug for 4.13 and one for
> 4.14 reported after RC2. The 4.13 bug was introduced in M3 and the 4.14 bug
> in M1. So, there would have been enough room to find the bugs earlier.
>
> Of course the Platform team does exactly that but everyone has its own
> patterns how to work and hence, unfortunately did not detect those bugs.
>
> Thanks to everyone who helps with testing!
> Dani
> ___
> *eclipse.org* -committers mailing list
> *eclipse.org-committ...@eclipse.org* 
> https://www.eclipse.org/mailman/listinfo/eclipse.org-committers
>
> IMPORTANT: Membership in this list is generated by processes internal to
> the Eclipse Foundation.  To be permanently removed from this list, you must
> contact e...@eclipse.org to request removal.
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] New Gerrit users cannot login

[Matthias Sohn]

File a bug ?

On Thu, Dec 5, 2019 at 11:26 AM Lars Vogel  wrote:

> Still failing for our new potential contributors.
>
> On Wed, Dec 4, 2019 at 3:43 PM Lars Vogel  wrote:
> >
> > Hi,
> >
> > FYI new Gerrit users receive an error message if they try to login
> > after registration. See screenshot below. I sent an email to webmaster
> > about this.
> >
> > Best regards, Lars
> >
> >
> > --
> > Eclipse Platform project co-lead
> > CEO vogella GmbH
> >
> > Haindaalwisch 17a, 22395 Hamburg
> > Amtsgericht Hamburg: HRB 127058
> > Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
> > USt-IdNr.: DE284122352
> > Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web:
> http://www.vogella.com
>
>
>
> --
> Eclipse Platform project co-lead
> CEO vogella GmbH
>
> Haindaalwisch 17a, 22395 Hamburg
> Amtsgericht Hamburg: HRB 127058
> Geschäftsführer: Lars Vogel, Jennifer Nerlich de Vogel
> USt-IdNr.: DE284122352
> Fax (040) 5247 6322, Email: lars.vo...@vogella.com, Web:
> http://www.vogella.com
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] download.eclipse.org is not responding

[Matthias Sohn]

On Mon, Nov 25, 2019 at 8:50 AM Alexander Fedorov <
alexander.fedo...@arsysop.ru> wrote:

> Hello,
>
> download.eclipse.org is not responding
> attempt to submit the problem to bugzilla also failed
>

try using https protocol, I can reach at least the EGit update site
https://download.eclipse.org/egit/updates/

https://status.eclipse.org/
shows there seem to be some issues with some services


> It blocks the release activities, please help.
>
> Thanks in advance,
> AF
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] many services down ?

[Matthias Sohn]

I can't reach Gerrit and the Eclipse Status monitor
https://status.eclipse.org/ says that the following services are down:

   - Website
   - Git/Gerrit
   - Wiki
   - Bugzilla
   - JIPP/CI Site
   - Download

-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] End of an Era: shell access.

[Matthias Sohn]

I tried to update the content of /home/data/httpd/
download.eclipse.org/egit/github/updates from
/home/data/httpd/download.eclipse.org/egit/github/updates-5.4
which I missed when publishing 5.4.

though it seems rm -rf silently doesn't work anymore, despite being
advertised by help:

r$ help
This shell is restricted to the following commands:
ls , cp , mv , mkdir , curl , rsync , scp , rm , quit/exit and help

r$ ls /home/data/httpd/download.eclipse.org/egit/github/updates
artifacts.jar  content.jar  features  p2.index
artifacts.xml.xz  content.xml.xz
 github-updatesite-5.3.0.201903130848-r.zip  plugins

this should remove the old content:
r$ rm -rf /home/data/httpd/download.eclipse.org/egit/github/updates/*

but it seems this doesn't work:
r$ ls /home/data/httpd/download.eclipse.org/egit/github/updates
artifacts.jar  content.jar  features  p2.index
artifacts.xml.xz  content.xml.xz
 github-updatesite-5.3.0.201903130848-r.zip  plugins

-Matthias

On Thu, Aug 29, 2019 at 3:21 PM Matthew Ward <
matt.w...@eclipse-foundation.org> wrote:

> Eike,
>
>   There is a built in 'help' function which will display the available
> commands.
>
> Ed,
>
>   I left cron jobs alone with the idea that people would ask for them to
> be removed once they had been moved elsewhere.  Please file a bug and I'll
> get the job cleaned up.
>
> -Matt,
>
> On Thu, Aug 29, 2019 at 2:52 AM Eike Stepper  wrote:
>
>> Am 27.08.2019 um 16:44 schrieb Matthew Ward:
>> > Hi Ed,
>> >
>> >   The restricted shell was originally created with the goal of
>> providing committers a way to interact with the
>> > downloads/archive filesystems for releng activities, and version
>> control systems without providing a general purpose
>> > shell.  So naturally the command set available leans in that
>> direction(mv,cp,mkdir,git etc).
>> Finding out what the restricted shell actually allows you to do is quite
>> annoying, as it just kicks you out on forbidden
>> commands. Is there an alternative way of discovering/indicating
>> forbiddenness?
>>
>> Cheers
>> /Eike
>>
>> 
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>> >
>> > We are certainly willing to discuss adding extra commands either
>> temporarily or permanently, but I want to make it
>> > clear that the goal is not to reproduce bash.
>> >
>> > -Matt.
>> >
>> >
>> >
>> >
>> > On Mon, Aug 26, 2019 at 9:58 AM Ed Merks > ed.me...@gmail.com>> wrote:
>> >
>> > What will we be able to do in restricted shell?  Using vi is a very
>> basic activity.  I suppose there must be some
>> > good reason why that's restricted?  Earlier I was under the
>> impression that such simple things would continue to
>> > work, but now I have to wonder.  But then it was mentioned that
>> things we discover needed could become unrestricted...
>> >
>> >
>> > On 26.08.2019 15:35, Matthew Ward wrote:
>> >> Hi David,
>> >>
>> >>   Thanks for the questions.
>> >>
>> >> Users with the restricted shell will have the same home
>> directories that they do currently, which will remain the
>> >> place for authorized keys.   You won't be able to
>> edit(vi/emacs/ed) files directly within the restricted shell,
>> >> so you will need to upload them via scp/rsync.  If you want a more
>> 'interactive' type of access I'd suggest
>> >> looking into using libfuse, and specifically the sshfs file system.
>> >>
>> >> The restricted shell allows rsync, so there should be zero
>> impact.  If you'd like to test in advance, drop me a
>> >> line and I'll set you up.
>> >>
>> >> -Matt.
>> >>
>> >> On Sat, Aug 24, 2019 at 3:23 PM David Williams <
>> david_willi...@acm.org > wrote:
>> >>
>> >> On 8/23/19 14:24, Matthew Ward wrote:
>> >>> Hi Everyone,
>> >>>
>> >>>   I just wanted to follow up with a reminder that on August
>> 28th we will be moving committers that have an
>> >>> actual shell on Eclipse.org to our restricted shell.
>> >>>
>> >>> I'd like to thank both Donat and Etienne on the Buildship
>> RelEng team who volunteered to test this change,
>> >>> and helped me confirm that this change should be minimally
>> disruptive.
>> >>>
>> >>> If you have any questions, please let me know.
>> >>>
>> >>> -Matt.
>> >>>
>> >>
>> >> Thanks for the reminder.
>> >>
>> >> Will those of use that still want to use 'scp' and similar
>> still have a 'home directory' (on "build"?) and is
>> >> that still the place for .ssh/authorized_keys2? Or, does all
>> that change with "restricted shell"?
>> >>
>> >> If a change, can you point me to instructions on how to set
>> that up? I would assume some form of "ssh-copy-id
>> >> hostname" but thought best not to assume and ask explicitly.
>> >>
>> >> In case you are wondering, the use case, for using scp and
>> similar is to download a number of builds to my
>> >>  

Re: [cross-project-issues-dev] 2019-09 Simultaneous Release

[Matthias Sohn]

I miss JGit on this list, it's bundled with EGit in the egit.aggrcon file
[1].
The release record is here [2].

[1]
https://git.eclipse.org/r/plugins/gitiles/simrel/org.eclipse.simrel.build/+/refs/heads/master/egit.aggrcon
[2] https://projects.eclipse.org/projects/technology.jgit/releases/5.5.0

-Matthias

On Thu, Aug 8, 2019 at 10:18 PM Wayne Beaton <
wayne.bea...@eclipse-foundation.org> wrote:

> I have updated the participation page
>  with the information that
> I have available. Let me know if I've got anything wrong.
>
> Per the Simultaneous Release participation rules
> ,
> every participating project needs to signal their continued participation
> by making a change (any change) to the project's aggrcon file. If your
> contribution will be a new release of your content, you must also create a
> release record. The date on the release record should be the date of the
> release (2019-09-18); when I add your project to the list, I pick the
> release record with a date on or before the date of the Simultaneous
> Release.
>
> Note that changes made the Eclipse Development Process require a release
> review (and IP Log review) only if the release is major or minor and your
> project has not done a release review in the past year. As always, service
> releases do not require a review. Do note, however, that you are still
> required to have all of your intellectual property fully vetted and cleared
> by the IP Team before it can be included in any release (regardless of
> whether or not you engage in a review).
>
> I'll check again and update the participation list accordingly next week.
> The opt-in deadline is M2, so after tomorrow... you're late.
>
> Thanks for your attention.
>
> Wayne
>
>
>
> On Thu, Aug 8, 2019 at 3:00 PM Wayne Beaton <
> wayne.bea...@eclipse-foundation.org> wrote:
>
>> Don't panic yet. I start to build this list in earnest around the M2 mark.
>>
>> I'll make sure that Eclipse Web Tools makes the list.
>>
>> Wayne
>>
>> On Thu, Aug 8, 2019 at 2:50 PM Nitin Dahyabhai  wrote:
>>
>>> Is there cause for concern at how brief the list at
>>> https://projects.eclipse.org/releases/2019-09 (and that WTP isn't
>>> there,
>>> although I'm pretty sure we should be)? Or just a bug?
>>>
>>> Regards,
>>> Nitin Dahyabhai
>>> WTP PMC Lead
>>> nit...@us.ibm.com
>>>
>>>
>>> ___
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@eclipse.org
>>> To change your delivery options, retrieve your password, or unsubscribe
>>> from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>>
>>
>> --
>>
>> Wayne Beaton
>>
>> Director of Open Source Projects | Eclipse Foundation, Inc.
>>
>
>
> --
>
> Wayne Beaton
>
> Director of Open Source Projects | Eclipse Foundation, Inc.
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [orbit-dev] Orbit Bundle Removals For 2019-09 M1

[Matthias Sohn]

On Wed, Jun 26, 2019 at 8:44 PM Roland Grunberg  wrote:

> Hi,
>
> The following bundles are either in the process of being removed, or
> planned as such for the Orbit 2019-09 release. Ideally we'll have them
> done for M1 so that there's plenty of time to adapt to the changes.
>
> If there's any opposition to any of the removals, let me know. I
> believe there was some to older Lucene but this should be resolved.
>
> - BouncyCastle 1.59.0, 1.60.0
>   - 1.61.0 exists
>   - https://git.eclipse.org/r/143086 & https://git.eclipse.org/r/143087


these 2 changes removing BouncyCastle 1.59 and 1.60 are merged now

>
>
> - Lucene 5.2.1, 6.1.0, 7.1.0 http://eclip.se/539752
>   - 7.5.0 and 8.1.0 exist as replacement
>   - 3.5.0 will remain since I believe Recommenders still requires it
> and the index that uses it is unlikely to be updated anytime soon
>
> - com.google.guava 15.0.0, 18.0.0
>   - 21.0.0 and 27.0.0 exist
>
> - org.tukaani.xz 1.3.0, 1.5.0, 1.6.0
>   - 1.8.0 exists
>
> - Felix 0.10.0 https://eclip.se/547314
>   - 1.x version exists
>
> Cheers,
> --
> Roland Grunberg
>
> ___
> orbit-dev mailing list
> orbit-...@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/orbit-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Fetching from Gerrit fails

[Matthias Sohn]

Gerrit seems to feel unhappy and git fetch fails both via https and ssh
protocol.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=548302

-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] EGit/JGit late

[Matthias Sohn]

On Wed, Jun 12, 2019 at 10:14 PM Matthias Sohn 
wrote:

> Hi,
>
> we are facing issues with the EGit build, meanwhile we could fix an issue
> on our side. But now the signing service is unavailable hence our
> contribution for RC2 will come late.
>
> I filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=548204 to track
> this problem.
>

I now succeeded to finish the release build and updated our simrel
contribution to JGit and EGit 5.4.0.
The build is running:
https://ci.eclipse.org/simrel/job/simrel.runaggregator.pipeline/536/console

-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] EGit/JGit late

[Matthias Sohn]

Hi,

we are facing issues with the EGit build, meanwhile we could fix an issue
on our side. But now the signing service is unavailable hence our
contribution for RC2 will come late.

I filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=548204 to track this
problem.

-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] hipp 3 down ?

[Matthias Sohn]

On Tue, Jun 11, 2019 at 9:52 AM Matthias Sohn 
wrote:

> I can't reach the JGit Jenkins [1] running on hipp3 and the infra monitor
> [2] says it is offline.
> Can you please bring it back online ?
>
> [1] https://ci.eclipse.org/jgit/
> [2] https://accounts.eclipse.org/committertools/infra-status
>

I filed https://bugs.eclipse.org/bugs/show_bug.cgi?id=548131 to track this
problem


> thanks
> -Matthias
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] hipp 3 down ?

[Matthias Sohn]

I can't reach the JGit Jenkins [1] running on hipp3 and the infra monitor
[2] says it is offline.
Can you please bring it back online ?

[1] https://ci.eclipse.org/jgit/
[2] https://accounts.eclipse.org/committertools/infra-status

thanks
-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Is jsch finally dead?

[Matthias Sohn]

JGit has implemented alternative SSH client support (kudos to Thomas Wolf)
in its
bundle org.eclipse.jgit.ssh.apache which uses the following 3rd party
bundles:

org.apache.sshd.osgi 2.2.0.v20190425-2127 is an upstream artifact that
combines sshd-common and sshd-core so it can be deployed in OSGi
environments
org.apache.sshd.sftp 2.2.0.v20190425-2127 to support SFTP protocol
net.i2p.crypto.eddsa 0.3.0.v20181102-1323 to support ed25519 keys

Since 5.3.0 EGit uses Apache Mina sshd as the default ssh client.

Open enhancement requests regarding usage of Apache Mina sshd in JGit and
EGit:
https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=REOPENED=Technology_id=18764270=EGit=JGit_format=advanced_desc=mina%20sshd_desc_type=allwordssubstr

-Matthias

On Sat, Jun 8, 2019 at 12:12 PM Ed Merks  wrote:

> The EGit folks have started using Apache MINA and now has an option in
> Team -> Git for SSH client to choose between Jsch and Apache MINA sshd.  I
> thought that it uses org.apache.mina.core which is available from Orbit,
> e.g.,
>
> http://download.eclipse.org/tools/orbit/downloads/latest-R
>
> But I'm not really sure now.  I can see they have
> org.eclipse.jgit.ssh.apache which depends on packages org.apache.sshd.*
> which come from a bundle called org.apache.sshd.core which has 'Apache MINA
> SSHD Core' as the name so it seems that's what's being used.
> On 08.06.2019 11:05, Stefanos Kalantzis wrote:
>
> Sorry about sending a new email, but I don't have the existing thread, and
> can't find the Message-ID anywhere. If someone still has it please reply to
> the old thread :)
>
> The last message from December 2018 implied that there will be a new
> project as replacement of jsch.
>
> Does anyone have further information on this? Was this attempt ever
> started?
>
> Thanks,
> -sK
>
> ___
> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, 
> visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Orbit To Release An RC2 Build

[Matthias Sohn]

On Sun, Jun 2, 2019 at 5:48 PM Roland Grunberg  wrote:

> On Sunday, June 2, 2019, Matthias Sohn  wrote:
>>
>>
>> I agree this looks inconsistent. No clue why this happened, comparing the
>> sources against 1.60
>> didn't reveal the reason why the build decided for JavaSE 9. I pushed a
>> fix for review
>> https://git.eclipse.org/r/#/c/143182/
>>
>
>  I haven't looked too deeply yet but my guess is that the metadata
> generation detects a module-info file and treats this as requiring Java 9
> at a minimum. The affected property can be manually set as needed though.
>
> Given that the scope is limited, we can do an RC2a. I would just make sure
> to test to confirm it works as you expect.
>

Meanwhile I found that the build failure of
https://git.eclipse.org/r/#/c/143168/ updating EGit to use this version of
bouncycastle
is caused by this issue.

The I-Build
https://download.eclipse.org/tools/orbit/downloads/drops/I20190602181010/
which contains the fix https://git.eclipse.org/r/#/c/143182/ fixes this
issue.

Also Alexander confirmed in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=547570 that this fix now
enables Eclipse Passage
to update to bouncycastle 1.61 which didn't work with the earlier R-build.

-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Orbit To Release An RC2 Build

[Matthias Sohn]

On Sun, Jun 2, 2019 at 11:58 AM Alexander Fedorov <
alexander.fedo...@arsysop.ru> wrote:

> Hello Matthias,
>
> Now the "org.bouncycastle.bcpg" declares
> Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=9))"
> while its BREE is :
> Bundle-RequiredExecutionEnvironment: J2SE-1.5
>
> It looks like an issue as we still have a Java8+ as the latest
> installation requirement.
>

I agree this looks inconsistent. No clue why this happened, comparing the
sources against 1.60
didn't reveal the reason why the build decided for JavaSE 9. I pushed a fix
for review
https://git.eclipse.org/r/#/c/143182/

-Matthias


> Regards,
> AF
>
> 01.06.2019 18:00, Matthias Sohn пишет:
>
> It's here
> https://download.eclipse.org/tools/orbit/downloads/drops/R20190531194818/
> see https://www.eclipse.org/lists/orbit-dev/msg05083.html
>
> -Matthias
>
> On Sat, Jun 1, 2019 at 12:31 PM Daniel Megert 
> wrote:
>
>> Hi
>>
>> Any other change to be expected? When will the final URL/release be
>> available?
>>
>> Thanks,
>> Dani
>>
>>
>>
>> From:Roland Grunberg 
>> To:orbit-dev 
>> Cc:"issues, Cross" 
>> Date:31.05.2019 19:27
>> Subject:[EXTERNAL] [cross-project-issues-dev] Orbit To Release
>> An RC2 Build
>> Sent by:cross-project-issues-dev-boun...@eclipse.org
>> --
>>
>>
>>
>> Hey everyone,
>>
>> While we released our RC1 contribution a few days ago, and generally
>> this ends up being our final release, we expect to have an RC2
>> contribution.
>>
>> A newer version of BouncyCastle (bcprov, bcpkix, bcpg) 1.61 will be
>> introduced [1]. None of the older versions of BouncyCastle will be
>> removed from 2019-06, but will likely happen for 2019-09.
>>
>> Cheers,
>> --
>> Roland Grunberg
>>
>> [1] https://git.eclipse.org/r/143085/
>>
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>>
>>
>>
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
> ___
> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, 
> visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Orbit To Release An RC2 Build

[Matthias Sohn]

It's here
https://download.eclipse.org/tools/orbit/downloads/drops/R20190531194818/
see https://www.eclipse.org/lists/orbit-dev/msg05083.html

-Matthias

On Sat, Jun 1, 2019 at 12:31 PM Daniel Megert 
wrote:

> Hi
>
> Any other change to be expected? When will the final URL/release be
> available?
>
> Thanks,
> Dani
>
>
>
> From:Roland Grunberg 
> To:orbit-dev 
> Cc:"issues, Cross" 
> Date:31.05.2019 19:27
> Subject:[EXTERNAL] [cross-project-issues-dev] Orbit To Release An
> RC2 Build
> Sent by:cross-project-issues-dev-boun...@eclipse.org
> --
>
>
>
> Hey everyone,
>
> While we released our RC1 contribution a few days ago, and generally
> this ends up being our final release, we expect to have an RC2
> contribution.
>
> A newer version of BouncyCastle (bcprov, bcpkix, bcpg) 1.61 will be
> introduced [1]. None of the older versions of BouncyCastle will be
> removed from 2019-06, but will likely happen for 2019-09.
>
> Cheers,
> --
> Roland Grunberg
>
> [1] https://git.eclipse.org/r/143085/
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Slow git https access via https://git.eclipse.org/r/?

[Matthias Sohn]

On Mon, May 27, 2019 at 10:02 AM Matthias Sohn 
wrote:

> On Mon, May 27, 2019 at 9:45 AM Andrey Loskutov  wrote:
>
>> Hi,
>>
>> I'm only one who has a problem to pull from git.eclipse.org via https?
>>
>> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=547671
>
>
> I can't fetch from Gerrit anymore since yesterday and filed bug
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=547666
> to track this
>

fetching from Gerrit via ssh seems to work
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Slow git https access via https://git.eclipse.org/r/?

[Matthias Sohn]

On Mon, May 27, 2019 at 9:45 AM Andrey Loskutov  wrote:

> Hi,
>
> I'm only one who has a problem to pull from git.eclipse.org via https?
>
> See https://bugs.eclipse.org/bugs/show_bug.cgi?id=547671


I can't fetch from Gerrit anymore since yesterday and filed bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=547666
to track this

-Matthias
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Staging for SimRel 2019-03 Release Candidate (RC1) is complete

[Matthias Sohn]

validation succeeded hence I submitted the change and kicked the build job
https://ci.eclipse.org/simrel/job/simrel.runaggregator.pipeline/357/console

On Thu, Mar 7, 2019 at 8:16 PM Matthias Sohn 
wrote:

>
>
> On Thu, Mar 7, 2019 at 7:26 PM Frederic Gurr <
> frederic.g...@eclipse-foundation.org> wrote:
>
>> Thanks for the insight Carsten!
>>
>> The actual change in commit 2f53a00 was that on line 32 in egit.aggrcon
>> the attribute 'enabled="false"' was removed, which activated the
>> repository.
>>
>> @Matthias: Can you either disable the repository or change the
>> mirrorArtifacts attribute as Carsten suggested?
>>
>
> done here:
> https://git.eclipse.org/r/#/c/138296/
>
> thanks for the help
>
> Regards,
>>
>> Fred
>>
>> On 07.03.19 18:56, Carsten Reckord wrote:
>> > Looking at egit.aggrcon, I would guess that it is caused by this:
>> >
>> >   http://download.eclipse.org/egit/github/staging/v5.3.0.201903061415-rc1;
>> description="EGit GitHub Updates" mirrorArtifacts="false">
>> >
>> > The mirrorArtifacts="false" will cause the EGit GitHub artifacts not to
>> be included in the repo, instead triggering the composite. And I guess the
>> local file: url mapping of the aggregator then causes the broken child url.
>> >
>> > Cheers,
>> >
>> > Carsten Reckord
>> > Lead Software Architect & co-founder
>> >
>>
>> --
>> Frederic Gurr
>> Release Engineer | Eclipse Foundation Europe GmbH
>>
>> Annastr. 46, D-64673 Zwingenberg
>> Handelsregister: Darmstadt HRB 92821
>> Managing Directors: Ralph Mueller, Mike Milinkovich, Chris Laroque
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Staging for SimRel 2019-03 Release Candidate (RC1) is complete

[Matthias Sohn]

On Thu, Mar 7, 2019 at 7:26 PM Frederic Gurr <
frederic.g...@eclipse-foundation.org> wrote:

> Thanks for the insight Carsten!
>
> The actual change in commit 2f53a00 was that on line 32 in egit.aggrcon
> the attribute 'enabled="false"' was removed, which activated the
> repository.
>
> @Matthias: Can you either disable the repository or change the
> mirrorArtifacts attribute as Carsten suggested?
>

done here:
https://git.eclipse.org/r/#/c/138296/

thanks for the help

Regards,
>
> Fred
>
> On 07.03.19 18:56, Carsten Reckord wrote:
> > Looking at egit.aggrcon, I would guess that it is caused by this:
> >
> >   http://download.eclipse.org/egit/github/staging/v5.3.0.201903061415-rc1;
> description="EGit GitHub Updates" mirrorArtifacts="false">
> >
> > The mirrorArtifacts="false" will cause the EGit GitHub artifacts not to
> be included in the repo, instead triggering the composite. And I guess the
> local file: url mapping of the aggregator then causes the broken child url.
> >
> > Cheers,
> >
> > Carsten Reckord
> > Lead Software Architect & co-founder
> >
>
> --
> Frederic Gurr
> Release Engineer | Eclipse Foundation Europe GmbH
>
> Annastr. 46, D-64673 Zwingenberg
> Handelsregister: Darmstadt HRB 92821
> Managing Directors: Ralph Mueller, Mike Milinkovich, Chris Laroque
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Staging for SimRel 2019-03 Release Candidate (RC1) is complete

[Matthias Sohn]

/home/data/httpd/download.eclipse.org/staging/2019-03/aggregate has no
content.jar

msohn@build:/home/data/httpd/download.eclipse.org/staging/2019-03> ls
aggregate/
artifacts.jar  binary  features  plugins

could this cause the problem ?

On Thu, Mar 7, 2019 at 6:25 PM Matthias Sohn 
wrote:

> something is wrong with the content of the staging repository.
>
> I installed Eclipse committer package 2019-03 M3 and could install
> JGit/EGit 5.3.0 RC1 from
> the original p2 repositories
> https://download.eclipse.org/egit/staging/v5.3.0.201903061415-rc1
> https://download.eclipse.org/egit/github/staging/v5.3.0.201903061415-rc1
>
> but trying to update the same 2019-03 M3 installation from
> http://download.eclipse.org/staging/2019-03/
>
> fails with the error
>
> An error occurred while collecting items to be installed
>
> session context was:(profile=epp.package.committers,
> phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=,
> action=).
>
> No repository found containing:
> osgi.bundle,org.bouncycastle.bcpg,1.60.0.v20181210-2057
>
> No repository found containing:
> osgi.bundle,org.bouncycastle.bcpkix,1.60.0.v20181210-2057
>
> No repository found containing:
> osgi.bundle,org.bouncycastle.bcprov,1.60.0.v20181210-2057
>
> No repository found containing:
> osgi.bundle,org.eclipse.cvs,1.4.900.v20190301-0040
>
> No repository found containing:
> osgi.bundle,org.eclipse.egit,5.3.0.201903061415-rc1
>
> No repository found containing:
> osgi.bundle,org.eclipse.egit.core,5.3.0.201903061415-rc1
>
> No repository found containing:
> osgi.bundle,org.eclipse.egit.doc,5.3.0.201903061415-rc1
>
> No repository found containing:
> osgi.bundle,org.eclipse.egit.gitflow,5.3.0.201903061415-rc1
>
> No repository found containing:
> osgi.bundle,org.eclipse.egit.gitflow.ui,5.3.0.201903061415-rc1
>
> No repository found containing:
> osgi.bundle,org.eclipse.egit.mylyn.ui,5.3.0.201903061415-rc1
>
> No repository found containing:
> osgi.bundle,org.eclipse.egit.ui,5.3.0.201903061415-rc1
>
> No repository found containing:
> osgi.bundle,org.eclipse.epp.mpc.ui,1.7.5.v20190301-1516
>
> No repository found containing:
> osgi.bundle,org.eclipse.jdt,3.17.0.v20190301-0040
>
> No repository found containing:
> osgi.bundle,org.eclipse.jdt.apt.core,3.6.300.v20190228-0624
>
> No repository found containing:
> osgi.bundle,org.eclipse.jdt.apt.core.source,3.6.300.v20190228-0624
>
> No repository found containing:
> osgi.bundle,org.eclipse.jdt.core,3.17.0.v20190227-1706
>
> No repository found containing:
> osgi.bundle,org.eclipse.jdt.core.source,3.17.0.v20190227-1706
>
> No repository found containing:
> osgi.bundle,org.eclipse.jdt.debug.ui,3.10.200.v20190226-0733
>
> No repository found containing:
> osgi.bundle,org.eclipse.jdt.debug.ui.source,3.10.200.v20190226-0733
>
> No repository found containing:
> osgi.bundle,org.eclipse.jdt.doc.isv,3.14.300.v20190301-0538
>
> No repository found containing:
> osgi.bundle,org.eclipse.jdt.doc.user,3.15.200.v20190227-0848
>
> No repository found containing:
> osgi.bundle,org.eclipse.jdt.launching,3.13.0.v20190222-0937
>
> No repository found containing:
> osgi.bundle,org.eclipse.jdt.launching.source,3.13.0.v20190222-0937
>
> No repository found containing:
> osgi.bundle,org.eclipse.jdt.ui,3.17.0.v20190228-1358
>
> No repository found containing:
> osgi.bundle,org.eclipse.jdt.ui.source,3.17.0.v20190228-1358
>
> No repository found containing:
> osgi.bundle,org.eclipse.jgit,5.3.0.201903061415-rc1
>
> No repository found containing:
> osgi.bundle,org.eclipse.jgit.archive,5.3.0.201903061415-rc1
>
> No repository found containing:
> osgi.bundle,org.eclipse.jgit.http.apache,5.3.0.201903061415-rc1
>
> No repository found containing:
> osgi.bundle,org.eclipse.jgit.ssh.apache,5.3.0.201903061415-rc1
>
> No repository found containing:
> osgi.bundle,org.eclipse.pde,3.13.500.v20190301-0040
>
> No repository found containing:
> osgi.bundle,org.eclipse.pde.doc.user,3.14.300.v20190301-0538
>
> No repository found containing:
> osgi.bundle,org.eclipse.pde.ui,3.10.600.v20190222-1655
>
> No repository found containing:
> osgi.bundle,org.eclipse.pde.ui.source,3.10.600.v20190222-1655
>
> No repository found containing:
> org.eclipse.update.feature,org.eclipse.cvs,1.4.800.v20190301-0040
>
> No repository found containing:
> org.eclipse.update.feature,org.eclipse.egit,5.3.0.201903061415-rc1
>
> No repository found containing:
> org.eclipse.update.feature,org.eclipse.egit.gitflow.feature,5.3.0.201903061415-rc1
>
> No repository found containing:
> org.eclipse.update.feature,org.eclipse.egit.mylyn,5.3.0.2019030614

Re: [cross-project-issues-dev] Staging for SimRel 2019-03 Release Candidate (RC1) is complete

[Matthias Sohn]

something is wrong with the content of the staging repository.

I installed Eclipse committer package 2019-03 M3 and could install
JGit/EGit 5.3.0 RC1 from
the original p2 repositories
https://download.eclipse.org/egit/staging/v5.3.0.201903061415-rc1
https://download.eclipse.org/egit/github/staging/v5.3.0.201903061415-rc1

but trying to update the same 2019-03 M3 installation from
http://download.eclipse.org/staging/2019-03/

fails with the error

An error occurred while collecting items to be installed

session context was:(profile=epp.package.committers,
phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=,
action=).

No repository found containing:
osgi.bundle,org.bouncycastle.bcpg,1.60.0.v20181210-2057

No repository found containing:
osgi.bundle,org.bouncycastle.bcpkix,1.60.0.v20181210-2057

No repository found containing:
osgi.bundle,org.bouncycastle.bcprov,1.60.0.v20181210-2057

No repository found containing:
osgi.bundle,org.eclipse.cvs,1.4.900.v20190301-0040

No repository found containing:
osgi.bundle,org.eclipse.egit,5.3.0.201903061415-rc1

No repository found containing:
osgi.bundle,org.eclipse.egit.core,5.3.0.201903061415-rc1

No repository found containing:
osgi.bundle,org.eclipse.egit.doc,5.3.0.201903061415-rc1

No repository found containing:
osgi.bundle,org.eclipse.egit.gitflow,5.3.0.201903061415-rc1

No repository found containing:
osgi.bundle,org.eclipse.egit.gitflow.ui,5.3.0.201903061415-rc1

No repository found containing:
osgi.bundle,org.eclipse.egit.mylyn.ui,5.3.0.201903061415-rc1

No repository found containing:
osgi.bundle,org.eclipse.egit.ui,5.3.0.201903061415-rc1

No repository found containing:
osgi.bundle,org.eclipse.epp.mpc.ui,1.7.5.v20190301-1516

No repository found containing:
osgi.bundle,org.eclipse.jdt,3.17.0.v20190301-0040

No repository found containing:
osgi.bundle,org.eclipse.jdt.apt.core,3.6.300.v20190228-0624

No repository found containing:
osgi.bundle,org.eclipse.jdt.apt.core.source,3.6.300.v20190228-0624

No repository found containing:
osgi.bundle,org.eclipse.jdt.core,3.17.0.v20190227-1706

No repository found containing:
osgi.bundle,org.eclipse.jdt.core.source,3.17.0.v20190227-1706

No repository found containing:
osgi.bundle,org.eclipse.jdt.debug.ui,3.10.200.v20190226-0733

No repository found containing:
osgi.bundle,org.eclipse.jdt.debug.ui.source,3.10.200.v20190226-0733

No repository found containing:
osgi.bundle,org.eclipse.jdt.doc.isv,3.14.300.v20190301-0538

No repository found containing:
osgi.bundle,org.eclipse.jdt.doc.user,3.15.200.v20190227-0848

No repository found containing:
osgi.bundle,org.eclipse.jdt.launching,3.13.0.v20190222-0937

No repository found containing:
osgi.bundle,org.eclipse.jdt.launching.source,3.13.0.v20190222-0937

No repository found containing:
osgi.bundle,org.eclipse.jdt.ui,3.17.0.v20190228-1358

No repository found containing:
osgi.bundle,org.eclipse.jdt.ui.source,3.17.0.v20190228-1358

No repository found containing:
osgi.bundle,org.eclipse.jgit,5.3.0.201903061415-rc1

No repository found containing:
osgi.bundle,org.eclipse.jgit.archive,5.3.0.201903061415-rc1

No repository found containing:
osgi.bundle,org.eclipse.jgit.http.apache,5.3.0.201903061415-rc1

No repository found containing:
osgi.bundle,org.eclipse.jgit.ssh.apache,5.3.0.201903061415-rc1

No repository found containing:
osgi.bundle,org.eclipse.pde,3.13.500.v20190301-0040

No repository found containing:
osgi.bundle,org.eclipse.pde.doc.user,3.14.300.v20190301-0538

No repository found containing:
osgi.bundle,org.eclipse.pde.ui,3.10.600.v20190222-1655

No repository found containing:
osgi.bundle,org.eclipse.pde.ui.source,3.10.600.v20190222-1655

No repository found containing:
org.eclipse.update.feature,org.eclipse.cvs,1.4.800.v20190301-0040

No repository found containing:
org.eclipse.update.feature,org.eclipse.egit,5.3.0.201903061415-rc1

No repository found containing:
org.eclipse.update.feature,org.eclipse.egit.gitflow.feature,5.3.0.201903061415-rc1

No repository found containing:
org.eclipse.update.feature,org.eclipse.egit.mylyn,5.3.0.201903061415-rc1

No repository found containing:
org.eclipse.update.feature,org.eclipse.epp.mpc,1.7.5.v20190301-1516

No repository found containing:
org.eclipse.update.feature,org.eclipse.jdt,3.17.0.v20190301-0040

No repository found containing:
org.eclipse.update.feature,org.eclipse.jdt.source,3.17.0.v20190301-0040

No repository found containing:
org.eclipse.update.feature,org.eclipse.jgit,5.3.0.201903061415-rc1

No repository found containing:
org.eclipse.update.feature,org.eclipse.jgit.http.apache,5.3.0.201903061415-rc1

No repository found containing:
org.eclipse.update.feature,org.eclipse.jgit.ssh.apache,5.3.0.201903061415-rc1

No repository found containing:
org.eclipse.update.feature,org.eclipse.pde,3.13.400.v20190301-0538

No repository found containing:
org.eclipse.update.feature,org.eclipse.pde.source,3.13.400.v20190301-0538

On Thu, Mar 7, 2019 at 5:47 PM Matthias Sohn 
wrote:

> it just upda