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

[Christoph Läubrich via cross-project-issues-dev]

You have two cases:

1) you don't use 'org.antlr.runtime', then don't add it to your target 
and let the planner do its work as it is only a transitive dependency


2) you use 'org.antlr.runtime', then you don't want a version range in 
your target because that would mean your build is not reproducible, you 
should have the lowest version you support (read used in a version range 
of your import depending on consumer/producer [1]) in the target


Using 0.0.0 is actually only for "unreleased" items where your build is 
part of a larger aggregator and means your build might work today and 
fail tomorrow or a branch/tag is unable to be rebuild later on because 
"something" changed.


[1] 
https://docs.osgi.org/whitepaper/semantic-versioning/060-importer-policy.html



Am 20.11.23 um 13:30 schrieb Ed Merks via cross-project-issues-dev:
Unfortunately Tycho/PDE have no mechanism to express version ranges, 
only version="0.0.0" is special, but it maps to the largest available 
version.


I don't expect orbit to produce qualifier changes any time in the 
foreseeable future.


On 20.11.2023 11:18, Edward Willink via cross-project-issues-dev wrote:


Hi

For MoDisco, I successfuly upgraded to use the latest antlr 3.2.0 
which is probably the same as all other 3.2.0's.


For the OOMPH setup I could happily refer to [3.2.0,3.3.0]

But for the Tycho platform I'm a bit worried, since I have to refer to 
precisely




Ideally someone is clever enough to explain how Tycho can use a 
version range when 0.0.0 won't do.


Otherwise are we assured that the Orbit's brand new v20230929-1400 is 
not going to be incremented every time Orbit has a change?


    Regards

        Ed Willink


On 20/11/2023 09:49, 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, 
visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

On 20/11/2023 09:49, 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 

[cross-project-issues-dev] Please raise your hands regarding P2 ant support

[Christoph Läubrich via cross-project-issues-dev]

P2 includes some ant[1] tasks but as ant is not the build tool of the 
platform anymore and is replaced by Tycho[2] there is actually no active 
development / improvements anymore.


Therefore we try to find out if they are important to anyone or if we 
can reduce the technology/dependency stack of P2 and lower the 
maintenance burden by drop these (older release will still provide them 
in their current form).


So please cast you vote and/or concerns here

  https://github.com/eclipse-equinox/p2/discussions/383


[1] https://ant.apache.org/
[2] https://github.com/eclipse-tycho/tycho
___
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] Apache Maven 3.9.2 is available on all Jenkins instances now

[Christoph Läubrich]

Hi Fred,

just wanted to note that 3.9.3 is already out so probably you want to 
deploy that as well and skip  3.9.2 ..


Am 27.06.23 um 16:59 schrieb Frederic Gurr via cross-project-issues-dev:

Hi,

Maven 3.9.2 has been deployed to all Jenkins instances:
=> /opt/tools/apache-maven/3.9.2

Please note that /opt/tools/apache-maven/latest is still pointing to 
3.9.1.and will be updated on Tuesday, July 25, if no regressions are 
reported.


Release notes for Maven 3.9.2 can be found here:
https://maven.apache.org/docs/3.9.2/release-notes.html

Version details are available at
https://wiki.eclipse.org/Jenkins#Apache_Maven

Please report any issues here:
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/3318

Regards,

Fred



___
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] Staging for SimRel 2023-06 RC1 is Complete (PLEASE READ SECTION 3rd PARTY BUNDLES)

[Christoph Läubrich]

I'd like to note that Tycho 4 contains a new option to filter so called 
"provided" items see [1]


That means, if you reference another repository in your category.xml 
(see [2] for an example), Tycho will exclude all items that are provided 
by this site, even if include all dependencies are enabled.


That way one can produce sites that contain "everything needed" but 
still not reproduce what is available in any of the referenced sites.


This feature is quite new, but I still encourage everyone to try it out 
and give feedback so this can become a good alternative from maintaining 
features just for including something in an updatesite that is 
indirectly referenced.


best
 Christoph


[1] 
https://github.com/eclipse-tycho/tycho/blob/master/RELEASE_NOTES.md#new-parameter-for-tycho-p2-repository-pluginassemble-repository
[2] 
https://github.com/eclipse-m2e/m2e-core/blob/428661981bcfe567cbed50749cae5a7c16bebef8/org.eclipse.m2e.repository/category.xml#L32-L35


Am 01.06.23 um 09:01 schrieb Ed Merks:

The staging repository content of

https://download.eclipse.org/staging/2023-06/

has been promoted to the following repository for 2023-06 RC1:

https://download.eclipse.org/releases/2023-06 /202306021000/

This is ready for consumption by EPP.

It will become visible in the composite as scheduled Friday, June 2nd, 
2023:


https://download.eclipse.org/releases/2023-06

___

STOP INCLUDING 3rd PARTY BUNDLES IN FEATURES

This is the first time in a very long time that we've reduced the number 
of duplicates:


https://download.eclipse.org/releases/2023-06/202306021000/buildInfo/archive/download.eclipse.org/releases/2023-06/202306021000/index.html

The most common reason for duplicates (though not the only one) is 
including 3rd party bundles in your features, e.g., here the platform 
requires one specific version of gson while papyrus another:


In this case, lsp4j is depending on an internal package not exported by 
the direct-from-maven version of gson.  I wonder if or why that's necessary?


There is a proposal to stop including 3rd party bundles in features:

https://github.com/eclipse/orbit/issues/8#issuecomment-1534255305

I plan to help the platform and other projects stop doing that:

https://github.com/eclipse-platform/eclipse.platform.releng/issues/230#issuecomment-1560452454

For the platform is relatively easy because they're at the bottom of the 
food chain so they can just specify to include all transitive 
requirements in their repository.  For most of us though, we cannot and 
should not replicate project content of other Eclipse projects, so we 
must take a different approach.  My suggestion here is to introduce an 
additional "dependencies" feature that's included uncategorized in the 
category.xml and to move all 3rd party bundle includes to that feature 
(and DO NOT include that feature in any other feature that the user 
installs).


You might think, "but I want to be sure that a specific tested version 
of some 3rd party dependency is used".  Dream on then because there is 
no guarantee that OSGi will actually wire your bundles to  any specific 
3rd party bundle version even if that version is available in the 
installation.  The wiring will depend only on the version ranges in your 
actual bundles, not on the versions included by the features.


Regards,
Ed

___
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 Mylyn wants to participate in SimRel 2023-06

[Christoph Läubrich]

> The m2e-generated package imports don't have version ranges, which 
appears to be what is suggested to be bad metadata; that appears to be a 
problem that cannot be solved.


I have created https://github.com/eclipse-m2e/m2e-core/issues/1367 even 
though I don't know why you think it is not solvable, please leave a 
comment there with some insights if you have further details.


Am 01.05.23 um 10:13 schrieb Ed Merks:

Let's discuss on the issue so we don't flood the group's inbox.

Then we can note there that

 1. Generated OSGi artifacts are not part of the process, and if they
are to be part of the process, then we need a process for them.
 2. The m2e-generated package imports don't have version ranges, which
appears to be what is suggested to be bad metadata; that appears to
be a problem that cannot be solved.  The generated exported package
metadata appears to be very rich though, so that's great!

On 01.05.2023 10:01, Christoph Läubrich wrote:
There already IS a central place, called maven-central, the rest is 
just a matter of bad meta-data use that is:


- require-bundle for no good reason
- no proper version ranges on imports
- no use-clauses and versions on exports


Am 01.05.23 um 09:42 schrieb Alexander Fedorov:

Hello Ed,

I am also not happy to see a black hole that appeared on the site of 
the Orbit project.


I tried my best to understand what is the right way to consume 
required 3rd party libraries and the answer was "In the end, I think 
the process is very clear.*Everyone use the latest version*." 
(https://github.com/merks/simrel-maven/issues/3#issuecomment-1497228678)

And this is exactly what was done.

Please publish the recommended process of managing 3rd party 
libraries and we will follow it.
And I also don't see how it could be achieved without introducing 
another central location instead of Orbit.


Regards,
AF

5/1/2023 10:01 AM, Ed Merks пишет:


While I'm happy to see Mylyn back, I'm not happy to see it depending 
on direct-from-maven dependencies that are generated. It also 
appears that the direct-from-maven artifacts are not being signed.  
I've opened up this to track the issues:


https://github.com/eclipse-mylyn/org.eclipse.mylyn/issues/103

Note that TM4E is also generating direct-from-maven dependencies.

As I mentioned in the above issue, I think generated dependencies is 
a new can of worms and we've not even been managing the existing 
bucket of worms.   We really don't need a 4th version of  
org.apache.lucene.core on the train,  even if it's called 
org.apache.lucene.lucene-core instead.


 I see no good solution for managing this other than managing it 
from one central location that ensures exactly one p2 artifact is 
produced per maven artifact:


https://github.com/eclipse/orbit/issues/8
https://github.com/merks/simrel-maven/issues/4


On 01.05.2023 03:29, Jonah Graham wrote:

Welcome back Mylyn!

As planning council chair I see no problem with Mylyn rejoining for 
M2, but I'll bring it up with the full Planning Council at our next 
meeting for good measure and if there is any concern I'll let you 
know. In the meantime I look forward to seeing your updated 
contribution. Please reach out if you have any questions or 
concerns with reenabling the contribution.


Well done on rebooting Mylyn.

Jonah


On Sun, Apr 30, 2023, 3:57 p.m. Alexander Fedorov 
 wrote:


    Hello,

    As Eclipse Mylyn Project Lead,  in accordance with Simultaneous
    Release
    Requirements [1], I hereby announce the intent of Eclipse Mylyn to
    participate in SimRel 2023-06
    I hope the fact of re-joining will serve as an excuse for a 
slightly

    later notification (which should have happened before M1).

    The plan is to start from contribution of 3.26.0 [2] to SimRel
    2023-06
    M2 and then to provide another service release for 2023-06 RC2 
with

    addressed feedback.
    There is a 3.26.0 RC1 build available for early testing [3], 
please

    submit your feedback to Mylyn GitHub repository [4].

    [1]
https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#How_to_announce_your_participation
    [2] 
https://projects.eclipse.org/projects/tools.mylyn/releases/3.26.0

    [3] https://download.eclipse.org/mylyn/stage/
    [4] https://github.com/eclipse-mylyn/org.eclipse.mylyn/issues

    Regards,
    AF
    ___
    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, 
visithttps://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

Re: [cross-project-issues-dev] Eclipse Mylyn wants to participate in SimRel 2023-06

[Christoph Läubrich]

There already IS a central place, called maven-central, the rest is just 
a matter of bad meta-data use that is:


- require-bundle for no good reason
- no proper version ranges on imports
- no use-clauses and versions on exports


Am 01.05.23 um 09:42 schrieb Alexander Fedorov:

Hello Ed,

I am also not happy to see a black hole that appeared on the site of the 
Orbit project.


I tried my best to understand what is the right way to consume required 
3rd party libraries and the answer was "In the end, I think the process 
is very clear.*Everyone use the latest version*." 
(https://github.com/merks/simrel-maven/issues/3#issuecomment-1497228678)

And this is exactly what was done.

Please publish the recommended process of managing 3rd party libraries 
and we will follow it.
And I also don't see how it could be achieved without introducing 
another central location instead of Orbit.


Regards,
AF

5/1/2023 10:01 AM, Ed Merks пишет:


While I'm happy to see Mylyn back, I'm not happy to see it depending 
on direct-from-maven dependencies that are generated. It also appears 
that the direct-from-maven artifacts are not being signed.  I've 
opened up this to track the issues:


https://github.com/eclipse-mylyn/org.eclipse.mylyn/issues/103

Note that TM4E is also generating direct-from-maven dependencies.

As I mentioned in the above issue, I think generated dependencies is a 
new can of worms and we've not even been managing the existing bucket 
of worms.   We really don't need a 4th version of  
org.apache.lucene.core on the train,  even if it's called 
org.apache.lucene.lucene-core instead.


 I see no good solution for managing this other than managing it from 
one central location that ensures exactly one p2 artifact is produced 
per maven artifact:


https://github.com/eclipse/orbit/issues/8
https://github.com/merks/simrel-maven/issues/4


On 01.05.2023 03:29, Jonah Graham wrote:

Welcome back Mylyn!

As planning council chair I see no problem with Mylyn rejoining for 
M2, but I'll bring it up with the full Planning Council at our next 
meeting for good measure and if there is any concern I'll let you 
know. In the meantime I look forward to seeing your updated 
contribution. Please reach out if you have any questions or concerns 
with reenabling the contribution.


Well done on rebooting Mylyn.

Jonah


On Sun, Apr 30, 2023, 3:57 p.m. Alexander Fedorov 
 wrote:


Hello,

As Eclipse Mylyn Project Lead,  in accordance with Simultaneous
Release
Requirements [1], I hereby announce the intent of Eclipse Mylyn to
participate in SimRel 2023-06
I hope the fact of re-joining will serve as an excuse for a slightly
later notification (which should have happened before M1).

The plan is to start from contribution of 3.26.0 [2] to SimRel
2023-06
M2 and then to provide another service release for 2023-06 RC2 with
addressed feedback.
There is a 3.26.0 RC1 build available for early testing [3], please
submit your feedback to Mylyn GitHub repository [4].

[1]

https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#How_to_announce_your_participation
[2] https://projects.eclipse.org/projects/tools.mylyn/releases/3.26.0
[3] https://download.eclipse.org/mylyn/stage/
[4] https://github.com/eclipse-mylyn/org.eclipse.mylyn/issues

Regards,
AF
___
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, 
visithttps://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, 
visithttps://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] Apache Maven 3.9.0 is available on all Jenkins instances

[Christoph Läubrich]

Maven 3.9.0 has know issues and 3.9.1 was already released, any reason 
not to skip 3.9.0 and head over directly to 3.9.1?


Am 06.04.23 um 14:07 schrieb Frederic Gurr via cross-project-issues-dev:

Hi,

Maven 3.9.0 has been deployed to all Jenkins instances a few days ago, 
but I forgot to send out the notification. So here it is.


Note that apache-maven-latest has also been switched to 3.9.0,
since no regressions have been reported in the last 4 weeks.

Release notes for Maven 3.9.0 can be found here:
https://maven.apache.org/docs/3.9.0/release-notes.html

Version details are available at
https://wiki.eclipse.org/Jenkins#Apache_Maven

Regards,

Fred


___
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] [epp-dev] EPP 2023-03 M3

[Christoph Läubrich]

Maven artifacts are not "wrapped" they are used as-is (unless they have 
no OSGi data but then no one would complain to use another centralized 
source). So there will always be one version of the *same* artifact.


Beside that, managing dependencies and keeping up with updates is an 
inherit task of project management, simrel on the other hand is not a 
dependency management tool!


So if one expects to always use the "latest orbit" why not one can 
assume to use the "latest central" version? It is even simpler, just 
select the dependency in the target editor and press the "Update" button 
and you will use the latest version, no need to wait for an orbit 
release, no need to change urls ...



Am 27.02.23 um 14:20 schrieb Christian Dietrich:
this is known, but it basically says: instead of using 1 orbit create 
your own orbit.

work has to be done in each project

Am 27.02.23 um 14:18 schrieb Ed Merks:

I sent this note to cross-projects in January on this topic:

https://www.eclipse.org/lists/cross-project-issues-dev/msg19562.html

On 27.02.2023 14:09, Michael Keppler wrote:

Am 27.02.2023 um 09:30 schrieb Mickael Istria:

I agree that Orbit duplicating a bundle that exists in a usable state
upstream can be the root of many other issues. As we have an example
here that this has a cost to troubleshot, and that there was probably
a cost in setting up the Orbit clone;


There is probably a simple reason: Doing the same as before. If projects
are used to consuming from Orbit since many years, they will probably
continue to do so, unless someone basically stops the process for
accepting new Orbit uploads. Quite honestly, even I had the impression
that both using Orbit and Maven directly are perfectly fine, until this
discussion started.

That being said, I also have one more concern: Orbit simplified many
projects using the same version of a library, by assuming that new
releases would all use the current Orbit update site at time of release.
If every project has a locally wrapped Maven artifact instead, won't
that lead to everyone consuming another version, depending on when that
entry in the target was last updated? Or is there something in SimRel
infrastructure that magically unifies this somehow? As said before,
multiple versions of a library are generally not a problem, unless we
later notice that some Apache Commons library had a binary incompatible
change in a service release (already happened), which is why I would
expect more real world incompatibilities at runtime.

Any solution to this version mix?

Ciao, Michael

___
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] [epp-dev] EPP 2023-03 M3

[Christoph Läubrich]

I think the problem is not OSGi or singeltons, but that lsp4e and lsp4j 
actually are closely related (whats not bad per se), so at the moment I 
think if there is a new release, both should (after upgrading) doing a 
release (some kind of micro-simrel ;-)) unless both projects agree that 
the API is stable enough to use proper version ranges and use-clauses 
and then it would also work to decouple the releases all together.


For that purpose, I have added the bnd-baseline check to m2e as an 
incubator (and until now it really works well!) that helps enforcing 
strict semantic-version rules [1].


Another important thing might be to decorate lsp4j API with 
@ProviderType and @ConsumerType (recently added to Tycho + PDE as well!) 
to help such tools to make good decisions. Also automated Bundle 
Manifest export/import might help here (I'm currently working on bring 
better support for PDE in that area).


So I can only encourage people using these techniques to build better 
bundles to reduce such hassle in the future and of course feel free to 
ask if any help is needed to apply such techniques to projects.



[1] 
https://github.com/eclipse-tycho/tycho/blob/master/RELEASE_NOTES.md#new-tycho-baseline-plugin


Am 27.02.23 um 09:30 schrieb Mickael Istria:

Hello,

While we should make efforts to minimize duplications, and thanks to Ed 
to encourage that, it's also great to acknowledge that this is not a 
primary goal of SimRel and that we should praise the people who decided 
to make Eclipse Platform rely on OSGi so such duplications of 
non-singleton libraries is actually not a problem!
So let's just take a few seconds and think about how OSGi helps us 
continuously. (I've read negative comments about OSGi lately, and find 
those very unfair so I'm trying to make people realize what kinds of 
difficult problems it does resolve, and how easy can be the solutions it 
provides).


Back to this specific case...

 > It looks like lsp4e uses quite tight version ranges for lsp4j. For 
example the latest released version org.eclipse.lsp4e 0.15 
requires-bundleorg.eclipse.lsp4j;bundle-version="[0.19.0,0.20.0)".
Since lsp4j 0.20 is directly contributed to SimRel and lsp4e requires 
lsp4j 0.19 both versions apear in the SimRel-repo.


Indeed, LSP4E uses tight ranges for LSP4J because LSP4J API is changing 
in non-backward compatible-ways (this is necessary to support changes in 
Language Server Protocol).

And indeed, latest release of LSP4E (0.21) does use LSP4J 0.19 (not latest).

On Mon, Feb 27, 2023 at 12:57 AM Hannes Wellmann > wrote:


lsp4e was already updated to lsp4j 0.20 by Mickael five days ago:
https://github.com/eclipse/lsp4e/commit/ad0c6a19481f5c729b45a3784fec94201d217085 

  So as soon as the next lsp4e release (I assume 0.22) is
contributed to SimRel only one version of lsp4j should remain.
@Mickael can you tell/estimate when this will be?


LSP4E has received many big changes in the last weeks, including some 
strong API changes, for a much better result on many aspect. However, 
those refactorings are still ongoing and the current state is a mix of 
old and new without clear deprecation, it's improper tor release at the 
moment. so LSP4E won't be ready for release in 2022-03. So LSP4J 0.19 
will have to stay.
I believe there are still 2 or 3 weeks of work at the current pace 
before we can release the new and better LSP4E.


The two different 2.10.1 versions of gson are probably due to the
fact that lsp4j uses gson 2.10.1 from Maven-Central, while somebody
else uses gson 2.10.1 from Orbit:
https://download.eclipse.org/tools/orbit/downloads/drops/I20230215045902/ 

  But what I don't understand is, why does Orbit even contain a
recent version of gson? In m2e we use gson 2.10.1 from central and
it looks like it already has proper OSGi metadata.
Therefore I don't really understand why the version from Orbit is
even used and provided?


I agree that Orbit duplicating a bundle that exists in a usable state 
upstream can be the root of many other issues. As we have an example 
here that this has a cost to troubleshot, and that there was probably a 
cost in setting up the Orbit clone; I'm also curious about what is the 
expected added-value that makes this cost profitable enough to be 
perceived as an reasonable investment?

___
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] CVS support plugin discontinuation - SimRel build changes needed

[Christoph Läubrich]

One could for example use this commit:

https://github.com/eclipse-platform/eclipse.platform.team/commit/9422ef3826cbc4745f7946514e7baed456f9f999

I can't tell whether or not it is assumed "easy" enough, but at least 
that could be a starting point, of course it would have been better to 
make this a tag/branch in that repository but the code is at least not lost.


But I think the main problem is that there are obviously no interest in 
CVS anymore and just because now someone tries to use a *recent* eclipse 
to use another unmaintained project it becomes an "issue".


But if CVS is really a business need for someone I can probably offer 
commercial-support for the cvs-plugin, just contact me... in all other 
cases and if I would have been in this situation, my first obvious 
action would be to simply download an *older* eclipse release with CVS 
support, that's why there are releases, so people can go back and still 
use old toolsets...



Am 04.01.23 um 08:53 schrieb Andrey Loskutov:

Also for the sake of entertainment: WHERE is the not supported CVS support code?
Is it available in some eclipse/github/gitlab repo?

I see it was announced to be not supported anymore in [1] and there was a bug about 
stopping building it [2] but it seems the code was just deleted (there is nothing 
about CVS in [3] anymore?), so if I understand it right no one can't *simply* grab 
the code & build against the latest platform? The Platform CVS home page [4] 
also doesn't give any hints...

[1] https://www.eclipse.org/lists/cross-project-issues-dev/msg18643.html
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=577521
[3] 
https://github.com/eclipse-platform/eclipse.platform/tree/master/team/bundles
[4] https://www.eclipse.org/eclipse/platform-cvs/

Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov



Gesendet: Dienstag, 03. Januar 2023 um 22:13 Uhr
Von: "Stephan Herrmann" 
An: cross-project-issues-dev@eclipse.org
Betreff: Re: [cross-project-issues-dev] CVS support plugin discontinuation - 
SimRel build changes needed

I don't think the major-minor discussion (interesting as it may be) is of any
relevance here, because:
* The only grace period I could find concerns API removal and that is
not controlled by number of releases but by number of years [1]
* The code change in question didn't touch any true API.

Just for the sake of entertainment:
* The broken client is not by some alien author but by the Eclipse
Project itself, so when the Eclipse Project justifies the breakage
by saying: "they should never have referred to this internal class",
this blame ("they") points to the Eclipse Project itself :)

Perhaps the following observation is more relevant:
* The "breaking" code change did not fix an existing problem [2]
(Still anybody believing in "risk-free" changes?)

just saying,
Stephan


[1]
https://github.com/eclipse-platform/.github/wiki/PMC-project-guidelines#api-removal-process

[2]
https://github.com/eclipse-platform/eclipse.platform.team/issues/29#issuecomment-1370147771

Am 03.01.23 um 15:56 schrieb Alexander Fedorov:

Hello,

Great discussion.

  > Removal in January 2022 for upcoming 4.23, 2 major releases later
  > Breakage found January 2023 on 4.26, 3 major releases later

Formally, the 4.x releases on the page
https://projects.eclipse.org/projects/eclipse are all marked as "Minor Release".
How did they become "major"? If they are "major" without incrementing "major"
segment, then who are "minor"? What about PDE API tools?

Regards,
AF

1/3/2023 5:45 PM, Andrey Loskutov пишет:

Ed,
you still can use CVS plugins with 4.25 platform.
For the rest: there is no "free beer" anymore in platform.
"Спасение утопающих - дело рук самих утопающих".
If you (or anyone else) want / need CVS (or XYZ) being supported by platform,
please consider to contribute to the CVS (XYZ) plugin maintenance.
Eclipse platform is open source project and everyone can spend time or money
to improve on some aspect of it.
But one can't expect from the platform project to support every released piece
of software "for free" forever.
Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov
*Gesendet:* Dienstag, 03. Januar 2023 um 15:32 Uhr
*Von:* "Ed Willink" 
*An:* "Cross project issues" 
*Betreff:* Re: [cross-project-issues-dev] CVS support plugin discontinuation -
SimRel build changes needed

Hi

4.21 to 4.23 is two minor releases and only six months; nothing in terms of a
transition period.

It takes a change to 6.x to be two major releases.

     Regards

         Ed Willink

On 03/01/2023 14:24, Mickael Istria wrote:

 On Tue, Jan 3, 2023 at 3:12 PM Ed Willink  wrote:

 I thought that Open Source was friendly; not a facilitator for a
 proprietary business case.

 Well, sometimes allowing contributors to make money from their work is
 actually one way to try being 

[cross-project-issues-dev] Who feels responsible for the User-Interface-Guide?

[Christoph Läubrich]

Hi everyone,

I found some issues with the User Interface Guidelines[1] what makes me 
wonder who feels responsible for the information today, it all seem a 
bit outdated. I also created a discussion [2] at the platform 
repository, so I'd like to invite everyone to join and give some insights.


best
 Christoph

[1] https://wiki.eclipse.org/User_Interface_Guidelines
[2] https://github.com/eclipse-platform/.github/discussions/80
___
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: Houston We Have a Problem

[Christoph Läubrich]

Hi Ed,

I think what you describe with Tycho adding two PGP signatures is whats 
described here [1].
If you think this could help here, please describe steps to reproduce 
there and I can take a look to provide a patch for that and probably 
even a backport if required.


[1] https://github.com/eclipse-tycho/tycho/issues/1466

Am 14.11.22 um 13:43 schrieb Ed Merks:
Recent versions of Java, including the most recent Java 17 release, now 
consider some jar-signed bundles to be unsigned. This affects all 
bundles and features signed between January 1, 2019 and April 14, 2022 
with the Eclipse certificate available at that time.


This is a *very *long list with many affected projects:

https://download.eclipse.org/oomph/archive/reports-extra/staging-2022-12/download.eclipse.org/staging/2022-12/index.html

The Platform has resigned their problematic bundles already:

https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/661

Orbit too has resigned the problematic bundles:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=581039

But the Orbit repo with the resigned bundles is *NOT *the one used by 
the Platform for their M3 contribution and is not the one you/we should 
be using for M3 which is this one:


https://download.eclipse.org/tools/orbit/downloads/drops/S20221109014815/repository

*These projects need to do new builds*:

  * *org.eclipse.acceleo*
  * *org.eclipse.bpmn2*
  * *org.eclipse.dltk*
  * *org.eclipse.ecf*
  * *org.eclipse.eef*
  * *org.eclipse.emf.edapt*
  * *org.eclipse.emf.parsley*
  * *org.eclipse.fx*
  * *org.eclipse.gmf*
  * *org.eclipse.mylyn*
  * *org.eclipse.uml2*

You should *ensure that the qualifiers of your bundles and features are 
newer than 2021-04*, so that you don't have two the "same artifacts" but 
with different signatures, which is especially important if you are 
doing baseline replacement in your build.  I can help test your 
repository if you need help.  Please reach out to me.


*Everyone **needs to ensure that they consume from the next RC1 version 
of Orbit*, otherwise we are likely to end up with massive duplicate 
Orbit bundles and that is likely to cause problems.


I hope someone from Mylyn is paying attention!

https://bugs.eclipse.org/bugs/show_bug.cgi?id=581029



Meanwhile, I'm trying to enable PGP signing of the bundles and features 
with this poor certificates to "repair" them.   But, Tycho does appear 
to detect that a signature will be ignored, provides no way to specify 
how to treat artifacts that already have a PGP signature (it actually 
produces duplicate properties in the artifacts.xml), and it appears the 
PGP signatures for features are invalid, so I'm not sure I'll be 100% 
successful in finding a workaround.  The following might be the best I 
can do on your behalf unless the PGP feature signing issue is fixed:


https://download.eclipse.org/oomph/archive/reports-extra/2022-12-gpg/download.eclipse.org/staging/2022-12-gpg/index.html

Note that in this scenario, I am *adding *the sim-bot PGP key/signature 
in addition to the key/signature already present from the project.  So 
all PGP-signed bundles will generally have two PGP signatures, and in 
this exceptional case, the bundle is jar-signed and has two PGP signatures:


https://download.eclipse.org/oomph/archive/reports-extra/2022-12-gpg/download.eclipse.org/staging/2022-12-gpg/index/bcpg_1.72.0.html

With PGP-signed features, p2 fails to validate them making them 
impossible to download/install, so in this case the cure is worse than 
the disease:


https://download.eclipse.org/oomph/archive/reports-extra/2022-12-gpg-bad/download.eclipse.org/staging/2022-12-gpg-bad/index/org.eclipse.acceleo.equinox.launcher.feature.jar_3.7.11.202102190929.html

Perhaps this issue can be fixed in the coming days...

Regards,
Ed





___
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] Jetty 1.0.11 needs java.lang.module

[Christoph Läubrich]

This is not a bug in jetty but normal behavior.

You should update your toolchain, Tycho 2.1.0 is outdated, it was 
release about two years ago...


Am 18.09.22 um 19:29 schrieb Ed Willink:

Hi

My build (https://ci.eclipse.org/ocl/job/ocl-codegen-tests/127/console) 
has started to fail with


[ERROR] Cannot resolve target definition: [ERROR] Software being 
installed: org.eclipse.sdk.feature.group 4.25.0.v20220831-1800 [ERROR] 
Missing requirement: org.eclipse.jetty.util 10.0.11 requires 
'java.package; java.lang.module 0.0.0' but it could not be found [ERROR] 
Cannot satisfy dependency: org.eclipse.help.feature.group 
2.3.1100.v20220831-1800 depends on: org.eclipse.equinox.p2.iu; 
org.eclipse.jetty.util [10.0.11,10.0.11] [ERROR] Cannot satisfy 
dependency: org.eclipse.platform.feature.group 4.25.0.v20220831-1800 
depends on: org.eclipse.equinox.p2.iu; org.eclipse.help.feature.group 
[2.3.1100.v20220831-1800,2.3.1100.v20220831-1800] [ERROR] Cannot satisfy 
dependency: org.eclipse.sdk.feature.group 4.25.0.v20220831-1800 depends 
on: org.eclipse.equinox.p2.iu; org.eclipse.platform.feature.group 
[4.25.0.v20220831-1800,4.25.0.v20220831-1800]


Java modules is something I have never got to grips with.

Is this a Jetty bug in introducing a new mandatory dependency in a 
maintenance release, or is it something where some more platform modules 
visibility magic is required?


     Regards

         Ed Willink


___
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] ACTION REQUIRED: Especially LSP4E (but also Viatra and Papyrus)

[Christoph Läubrich]

Hi Ed,

this was also complained at Tycho some times before [1], but it was 
argued it is a valid use-case and should be supported...


So my guess there was, that because of the strict requirements to gson 
P2 simply includes both because it no otherwise could resolve the 
"conflict" (that only can be resolved by taking uses into account) 
otherwise and thus refuses to use the never version of lsp4e?


[1] https://github.com/eclipse-tycho/tycho/issues/1103

Am 26.08.22 um 10:37 schrieb Ed Merks:

There are two versions of lsp4j on the train:

This leads to conflicts depending what combination of things are 
installed from the train.  Much of it boils down to too many gsons:


Attached is the log when you install everything from the train which 
looks like this:


Most of these problems boil down to conflicting wiring connections to gson.

I believe there really needs to be a new lsp4e contribution because the 
current one strictly requires the older lsp4j:


Viatra also needs to look at it's 'com.google.inject' dependency and 
Papyrus is kind of a mess of conflicts.


Please try to address these issues as soon as possible so I can monitor 
their resolution in the staging repository.


Regards,
Ed



___
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] Scout contribution disabled after m2e update

[Christoph Läubrich]

Just wanted to note that m2e usage questions are better taken place at:

https://github.com/eclipse-m2e/m2e-core/discussions

instead of the (cross-project) mailing list, this makes it easier to 
focus on the particular problem and even link to the code.


Am 08.08.22 um 15:15 schrieb Arthur van Dorp:
Thanks Aleksander! My fault was looking at latest and snapshot. I should 
have navigated to 
https://download.eclipse.org/technology/m2e/releases/2.0.1/ 



Regards,

Arthur

--



BSI Business Systems Integration AG

Täfernweg 1, CH-5405 Baden
Telefon +41 58 255 93 23
www.bsi-software.com 
_


_

*From:* cross-project-issues-dev 
 *On Behalf Of *Aleksandar 
Kurtakov

*Sent:* Monday, 8 August, 2022 14:24
*To:* Cross project issues 
*Subject:* Re: [cross-project-issues-dev] Scout contribution disabled 
after m2e update


On Mon, Aug 8, 2022 at 2:50 PM Arthur van Dorp 
> wrote:


Hi Mickael,

Thanks for the heads up. I have never updated the m2e dependency
myself before and I am a bit lost. For the Scout SDK UI plugin I
plan to update the range to

org.eclipse.m2e.core.ui;bundle-version="[2.0,2.1)" in

https://github.com/eclipse-scout/scout.sdk/blob/releases/12.0/org.eclipse.scout.sdk.s2e.ui/pom.xml



But in

https://github.com/eclipse-scout/scout.sdk/blob/releases/12.0/org.eclipse.scout.sdk/pom.xml


we reference very specific versions:

     1.18.4.20220208-0831


1.19.0.20220206-1032



1.18.1.20211011-2139


The person usually updating those is currently unavailable, so I
don’t know why that is. But looking at the m2e downloads I find the
releases at

https://download.eclipse.org/technology/m2e/releases/latest/plugins/


and the snapshots at

https://download.eclipse.org/technology/m2e/snapshots/latest/plugins/ 


Both don’t have a m2e 2.0.1 core version (only 2.0.0). Am I looking
at the wrong place?

Much like in the past - each bundle is versioned separately. Due to no 
change in m2e.core it has no version change so it stays 2.0.0 and it's 
safe to use it that way.


Thanks and kind regards,

Arthur

*From:* cross-project-issues-dev
mailto:cross-project-issues-dev-boun...@eclipse.org>> *On Behalf Of
*Mickael Istria
*Sent:* Friday, 5 August, 2022 22:56
*To:* Cross project issues mailto:cross-project-issues-dev@eclipse.org>>
*Subject:* [cross-project-issues-dev] Scout contribution disabled
after m2e update

Hi all,

I updated SimRel to use new m2e 2.0.1 release. This is a new major
version compared to previously contributed 1.20.1, so some
dependency ranges need to be updated in customers, and probably some
code as well.

Scout is currently not compatible, because of a requirement on an
older version of m2e. I had to disable it for the moment.

I recommend Scout maintainers to evaluate migration to m2e 2.0.1
ASAP to ensure both can participate simultaneously in SimRel.

Cheers,
-- 


Mickael Istria

Eclipse IDE  developer, for Red
Hat Developers 

___
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] Migration to SLF4J for SWTBot 4.0.0

[Christoph Läubrich]

About the simple logger:

you could configure test (system) properties with:

https://www.eclipse.org/tycho/sitedocs/tycho-surefire-plugin/test-mojo.html#systemProperties

or you most probably should use a fragment to the slf4jsimple logger so 
it could find the properties on the commandline.


regarding log4j, you need to add the log4j binding and log4j bundles but 
not log4joverslf4j as log4joverslf4j is only for those case you are 
using log4j but with a different binding (e.g. simple or logback) but 
there are some code that still uses log4j.


If you like to get your logs redirected to eclipse-log you can use 
slf4j-osgi


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

as it is not yet part of orbit, you can include this as a maven-location 
in your target (m2e required).


Am 31.05.22 um 23:50 schrieb Patrick Tasse:

Hi everyone,

As part of the 2022-06 release, the SWTBot project will do a major 
release of version 4.0.0. In this version, SWTBot has removed its use of 
org.apache.log4j and is instead using the org.slf4j.api facade for its 
logging. See Bug 578065 for this change.


I am trying to adapt project Trace Compass to this change and I am 
having some issues, perhaps someone can help and/or this information 
will be useful to others.


Trace Compass was using the log4j Logger for its SWTBot tests, both to 
add its own messages and to rely on SWTBot's log4j debug messages.


The first issue when switching to SWTBot 4.0.0 is that the SWTBot update 
site no longer contains org.apache.log4j. So I first tried to change our 
target files to add org.apache.log4j from the Orbit update site. I also 
had to add an Import-Package dependency to org.slf4j in our swtbot.tests 
plug-ins MANIFEST.MF, to avoid 'missing ... indirectly referenced from 
.class files' errors, due to it now being used by SWTBot classes.


While the build was now successful, there was no debug logging from the 
SWTBot components because there was no slf4j binding installed. The 
console would show:


SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation

At this point, needing a quick fix, I changed our target files to use 
the previous SWTBot release update site (3.1.0) that still uses 
org.apache.log4j, instead of using the latest snapshot (4.0.0) update site.


So, now I am trying to do a proper migration to SLF4J.

I updated our targets to use the SWTBot 4.0.0 snapshot and added 
org.slf4j.api Import-Package dependency to the swtbot.tests plug-ins 
MANIFEST.MF. I removed all use of org.apache.log4j.Logger in our test 
code and replaced it with getting a logger from the org.slf4j.LoggerFactory.


Of course there was no logging when running the tests because there was 
no binding installed.


~~~ org.slf4j.binding.simple ~~~

I first tried to add org.slf4j.binding.simple from Orbit to our targets.

In my JUnit Plug-In Test Debug Configuration I can see that 
org.slf4j.api and org.slf4j.binding.simple plug-ins are added. When I 
ran the test it did not log anything because the default log level was INFO.


So I added this line as static initializer in my test code:

System.setProperty("org.slf4j.simpleLogger.log.org.eclipse", "debug");

This works because it covers both our test code classes 
org.eclipse.tracecompass.* and the SWTBot classes org.eclipse.swtbot.*. 
But it's a bit clunky, and I wanted to configure other settings, like 
setting the log file to System.out instead of System.err.


I tried creating a simplelogger.properties file in my test plug-in, 
adding it to the Binary Build in the Build Configuration tab and adding 
it's location to the Classpath in the Runtime tab.


But when I run the test, the SimpleLoggerConfiguration code tries to 
load the properties file from:

Thread.currentThread().getContextClassLoader() (java.lang)
The current thread is PluginTestRunner.
This returns a ContextFinder (org.eclipse.osgi)
But the ContextFinder.basicFindClassLoaders() implementation returns the 
first in the list that is a Bundle class loader, and that's the one at 
index [5] which is for org.slf4j.api bundle. So it never gets to index 
[19] which is our tmf.ui.swtbot.tests bundle that has the 
simplelogger.properties resource.


So it doesn't find our test plug-in's simplelogger.properties file and I 
can't configure the logger.


I don't really understand how class loaders work so at this point I gave 
up on SimpleLogger.


~~~ org.slf4j.binding.log4j12 ~~~

I secondly tried to add org.slf4j.binding.log4j12 from Orbit to our targets.

In my JUnit Plug-In Test Debug Configuration I can see that 
org.slf4j.api and org.slf4j.binding.log4j12 plug-ins are added.


But org.slf4j.binding.log4j12 requires org.apache.log4j package and this 
is found in org.slf4j.log4j, so this plug-in also needs to be added.


And now when I run my test, the org.apache.log4j.Log4jLoggerFactory 
static initializer checks that there is no 
org.slf4j.impl.Log4jLoggerFactory loaded, and 

Re: [cross-project-issues-dev] jboss repository down

[Christoph Läubrich]

As mentioned before I can access this file:

https://repository.jboss.org/nexus/content/groups/public/javax/media/jai-core/1.1.3/jai-core-1.1.3.pom

without a problem using a regular webrowser and internet-connection.


Am 17.05.22 um 15:44 schrieb Jonah Graham:

Hi folks,

The jboss maven repository being down at the moment means I cannot build 
Orbit's 2022-06 M3 contribution.


As it turns out Apache Ant has a dependency* on a module not in maven 
central (I didn't know this was allowed) so we can't build Orbit.


*Does anyone have a contact at JBoss that they can request to help 
resolve this issue and bring this repo back online?*

*
*
Thanks,
Jonah

* See the pom: 
https://search.maven.org/artifact/org.apache.ant/ant-jai/1.10.12/jar 
 - 
but key part is quoted here:


   

   
     
       jboss
       JBoss
       https://repository.jboss.org/nexus/content/groups/public/ 


     
   

This leads to build errors when trying to build "Apache Ant 
(all-in-one)" in orbit:


[ERROR] Failed to execute goal on project org.apache.ant: Could not 
resolve dependencies for project 
org.eclipse.orbit.bundles:org.apache.ant:eclipse-bundle-recipe:1.10.12-SNAPSHOT: 
Failed to collect dependencies at org.apache.ant:ant-jai:jar:1.10.12 -> 
javax.media:jai-core:jar:1.1.3: Failed to read artifact descriptor for 
javax.media:jai-core:jar:1.1.3: Could not transfer artifact 
javax.media:jai-core:pom:1.1.3 from/to jboss 
(https://repository.jboss.org/nexus/content/groups/public/ 
): transfer 
failed for 
https://repository.jboss.org/nexus/content/groups/public/javax/media/jai-core/1.1.3/jai-core-1.1.3.pom 
, 
status: 503 Service Unavailable -> [Help 1]


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com 

___
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] org.jboss.tools.tycho-plugins:repository-utils:1.7.0 can't be resolved -> did anyone meet this problem ?

[Christoph Läubrich]

I don't know this is a real jboss issue, I can access that file without 
a problem here the error (503 Service Unavailable) more seem to indicate 
that some server on the route do not like that much traffic. Maybe some 
kind of proxy server?


Am 17.05.22 um 10:33 schrieb Stephane Bouchet:

Hi,

i've created an issue on JBoss about this.

Cheers,


Le lun. 16 mai 2022 à 22:39, Mickael Istria > a écrit :


Hello,

Why particularly do you use this Maven plugin? Couldn't you simply
get rid of it?

Cheers,
___
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




--

StéphaneBouchet

Senior Software Engineer, R

Red Hat




___
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] Two versions of ASM 9.3.0

[Christoph Läubrich]

I have checked this and think the asm manifest is incomplete see:

https://gitlab.ow2.org/asm/asm/-/issues/317975

This already creates trouble at xtext when there is asm 9.2 + asm 9.3 in 
the same framework see


https://github.com/eclipse/xtext-eclipse/issues/1842

this does not mean we have any issues in the final eclipse, but I think 
its crucial to check (and help) all dependencies we use to have as best 
osgi manifest metadata as possible, so I'd like to encourage anyone to 
verify the asm issue and maybe help the asm people to improve the 
manifest generated.


Am 20.04.22 um 18:03 schrieb Jonah Graham:
On Wed, 20 Apr 2022 at 00:43, Christoph Läubrich <mailto:lae...@laeubi-soft.de>> wrote:


I think there are two cases:

1) ASM is only included transitively (e.g. there is no feature
referencing it) and everyone uses a proper version range.
2) It is referenced directly with a fixed version

In the first case i think we don't have a problem as it either is not
part of the updatesite or p2 will chose only one version

In the second most probably two version will installed and it now
depends how good the bundle is shaped (e.g. does it use proper
use-clauses) if OSGi will sort that out at runtime.


ASM does not have any uses clauses in its manifest (maybe it doesn't 
need them) - and p2 does not use "uses" when choosing which bundles to 
install.


Manifest-Version: 1.0
Bundle-DocURL: http://asm.ow2.org <http://asm.ow2.org>
Bundle-License: BSD-3-Clause;link=https://asm.ow2.io/LICENSE.txt 
<https://asm.ow2.io/LICENSE.txt>

Bundle-ManifestVersion: 2
Bundle-Name: org.objectweb.asm
Bundle-RequiredExecutionEnvironment: J2SE-1.5
Bundle-SymbolicName: org.objectweb.asm
Bundle-Version: 9.3.0
Export-Package: org.objectweb.asm;version="9.3",org.objectweb.asm.sign
  ature;version="9.3"
Implementation-Title: ASM, a very small and fast Java bytecode manipul
  ation framework
Implementation-Version: 9.3

Jonah


To make the second case more lax, I have opened a bug [1] at Tycho to
support version range inclusion of features so one do not need to stick
to a strict version. Then it would even be possible to resolve this on
p2 level and p2 will simply choose the highest matching version to
install.

[1] https://github.com/eclipse/tycho/issues/898
<https://github.com/eclipse/tycho/issues/898>

Am 20.04.22 um 00:26 schrieb Jonah Graham:
 >
 > ~~~
 > Jonah Graham
 > Kichwa Coders
 > www.kichwacoders.com <http://www.kichwacoders.com>
<http://www.kichwacoders.com <http://www.kichwacoders.com>>
 >
 >
 > On Tue, 19 Apr 2022 at 16:28, Aleksandar Kurtakov
mailto:akurt...@redhat.com>
 > <mailto:akurt...@redhat.com <mailto:akurt...@redhat.com>>> wrote:
 >
 >
 >
 >     On Tue, Apr 19, 2022 at 11:12 PM Jonah Graham
 >     mailto:jo...@kichwacoders.com>
<mailto:jo...@kichwacoders.com <mailto:jo...@kichwacoders.com>>> wrote:
 >
 >
 >
 >         On Tue., Apr. 19, 2022, 15:49 Aleksandar Kurtakov,
 >         mailto:akurt...@redhat.com>
<mailto:akurt...@redhat.com <mailto:akurt...@redhat.com>>> wrote:
 >
 >
 >
 >             On Tue, Apr 19, 2022 at 10:39 PM Nitin Dahyabhai
 >             mailto:thatnit...@gmail.com>
<mailto:thatnit...@gmail.com <mailto:thatnit...@gmail.com>>> wrote:
 >
 >                 Unless and until there is a pressing need for a newer
 >                 version than what's in Orbit--which has a recipe that
 >                 can be updated should that need arise--couldn't the
 >                 Platform stop simply stop packaging its own?
 >
 >
 >             That's kind of what happened - [1] and [2]. At the time
 >             Platform (PDE actually) had the need and work was
initiated
 >             there was nothing in Orbit - [3].
 >
 >
 >         So now that it is orbit would a PR to consume that one
when M2
 >         orbit is ready be welcome?
 >
 >
 >
 >     What happens next time PDE/JDT needs new ASM? Same dance? This
 >     doesn't sound like a good long term plan to me.
 >
 >     My personal opinion is that it's better to stop putting things in
 >     Orbit when upstream provides OSGi bundles in Maven central
but use
 >     directly.
 >
 >
 > OK - in that case we have some specific SimRel testing to do:
 >
 > 1- Which bundles ends up SimRel - or do both end up there. I
assume that
 > it will be the Orbit one because it is more recent as far as p2 is
 > concerned (not sur

Re: [cross-project-issues-dev] Two versions of ASM 9.3.0

[Christoph Läubrich]

The use clause is more important for anyone *using* the ASM packages so 
OSGi knows how to compute a valid class space.


That P2 does not support uses is irrelevant for the runtime/OSGi.

Am 20.04.22 um 18:03 schrieb Jonah Graham:
On Wed, 20 Apr 2022 at 00:43, Christoph Läubrich <mailto:lae...@laeubi-soft.de>> wrote:


I think there are two cases:

1) ASM is only included transitively (e.g. there is no feature
referencing it) and everyone uses a proper version range.
2) It is referenced directly with a fixed version

In the first case i think we don't have a problem as it either is not
part of the updatesite or p2 will chose only one version

In the second most probably two version will installed and it now
depends how good the bundle is shaped (e.g. does it use proper
use-clauses) if OSGi will sort that out at runtime.


ASM does not have any uses clauses in its manifest (maybe it doesn't 
need them) - and p2 does not use "uses" when choosing which bundles to 
install.


Manifest-Version: 1.0
Bundle-DocURL: http://asm.ow2.org <http://asm.ow2.org>
Bundle-License: BSD-3-Clause;link=https://asm.ow2.io/LICENSE.txt 
<https://asm.ow2.io/LICENSE.txt>

Bundle-ManifestVersion: 2
Bundle-Name: org.objectweb.asm
Bundle-RequiredExecutionEnvironment: J2SE-1.5
Bundle-SymbolicName: org.objectweb.asm
Bundle-Version: 9.3.0
Export-Package: org.objectweb.asm;version="9.3",org.objectweb.asm.sign
  ature;version="9.3"
Implementation-Title: ASM, a very small and fast Java bytecode manipul
  ation framework
Implementation-Version: 9.3

Jonah


To make the second case more lax, I have opened a bug [1] at Tycho to
support version range inclusion of features so one do not need to stick
to a strict version. Then it would even be possible to resolve this on
p2 level and p2 will simply choose the highest matching version to
install.

[1] https://github.com/eclipse/tycho/issues/898
<https://github.com/eclipse/tycho/issues/898>

Am 20.04.22 um 00:26 schrieb Jonah Graham:
 >
 > ~~~
 > Jonah Graham
 > Kichwa Coders
 > www.kichwacoders.com <http://www.kichwacoders.com>
<http://www.kichwacoders.com <http://www.kichwacoders.com>>
 >
 >
 > On Tue, 19 Apr 2022 at 16:28, Aleksandar Kurtakov
mailto:akurt...@redhat.com>
 > <mailto:akurt...@redhat.com <mailto:akurt...@redhat.com>>> wrote:
 >
 >
 >
 >     On Tue, Apr 19, 2022 at 11:12 PM Jonah Graham
 >     mailto:jo...@kichwacoders.com>
<mailto:jo...@kichwacoders.com <mailto:jo...@kichwacoders.com>>> wrote:
 >
 >
 >
 >         On Tue., Apr. 19, 2022, 15:49 Aleksandar Kurtakov,
 >         mailto:akurt...@redhat.com>
<mailto:akurt...@redhat.com <mailto:akurt...@redhat.com>>> wrote:
 >
 >
 >
 >             On Tue, Apr 19, 2022 at 10:39 PM Nitin Dahyabhai
 >             mailto:thatnit...@gmail.com>
<mailto:thatnit...@gmail.com <mailto:thatnit...@gmail.com>>> wrote:
 >
 >                 Unless and until there is a pressing need for a newer
 >                 version than what's in Orbit--which has a recipe that
 >                 can be updated should that need arise--couldn't the
 >                 Platform stop simply stop packaging its own?
 >
 >
 >             That's kind of what happened - [1] and [2]. At the time
 >             Platform (PDE actually) had the need and work was
initiated
 >             there was nothing in Orbit - [3].
 >
 >
 >         So now that it is orbit would a PR to consume that one
when M2
 >         orbit is ready be welcome?
 >
 >
 >
 >     What happens next time PDE/JDT needs new ASM? Same dance? This
 >     doesn't sound like a good long term plan to me.
 >
 >     My personal opinion is that it's better to stop putting things in
 >     Orbit when upstream provides OSGi bundles in Maven central
but use
 >     directly.
 >
 >
 > OK - in that case we have some specific SimRel testing to do:
 >
 > 1- Which bundles ends up SimRel - or do both end up there. I
assume that
 > it will be the Orbit one because it is more recent as far as p2 is
 > concerned (not sure, just best guess).
 > 2- Starting from the SDK, does installing features from SimRel cause
 > both to be installed, and if so, are both resolved.
 >
 > I have added the above test to my M2 checks I will do -
 > https://git.eclipse.org/r/c/epp/org.eclipse.epp.packages/+/192830
<https://git.eclipse.org/r/c/epp/org.eclipse.epp.packages/+/192830>

Re: [cross-project-issues-dev] Two versions of ASM 9.3.0

[Christoph Läubrich]

I think there are two cases:

1) ASM is only included transitively (e.g. there is no feature 
referencing it) and everyone uses a proper version range.

2) It is referenced directly with a fixed version

In the first case i think we don't have a problem as it either is not 
part of the updatesite or p2 will chose only one version


In the second most probably two version will installed and it now 
depends how good the bundle is shaped (e.g. does it use proper 
use-clauses) if OSGi will sort that out at runtime.


To make the second case more lax, I have opened a bug [1] at Tycho to 
support version range inclusion of features so one do not need to stick 
to a strict version. Then it would even be possible to resolve this on 
p2 level and p2 will simply choose the highest matching version to install.


[1] https://github.com/eclipse/tycho/issues/898

Am 20.04.22 um 00:26 schrieb Jonah Graham:


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com 


On Tue, 19 Apr 2022 at 16:28, Aleksandar Kurtakov > wrote:




On Tue, Apr 19, 2022 at 11:12 PM Jonah Graham
mailto:jo...@kichwacoders.com>> wrote:



On Tue., Apr. 19, 2022, 15:49 Aleksandar Kurtakov,
mailto:akurt...@redhat.com>> wrote:



On Tue, Apr 19, 2022 at 10:39 PM Nitin Dahyabhai
mailto:thatnit...@gmail.com>> wrote:

Unless and until there is a pressing need for a newer
version than what's in Orbit--which has a recipe that
can be updated should that need arise--couldn't the
Platform stop simply stop packaging its own?


That's kind of what happened - [1] and [2]. At the time
Platform (PDE actually) had the need and work was initiated
there was nothing in Orbit - [3].


So now that it is orbit would a PR to consume that one when M2
orbit is ready be welcome? 




What happens next time PDE/JDT needs new ASM? Same dance? This
doesn't sound like a good long term plan to me.

My personal opinion is that it's better to stop putting things in
Orbit when upstream provides OSGi bundles in Maven central but use
directly.


OK - in that case we have some specific SimRel testing to do:

1- Which bundles ends up SimRel - or do both end up there. I assume that 
it will be the Orbit one because it is more recent as far as p2 is 
concerned (not sure, just best guess).
2- Starting from the SDK, does installing features from SimRel cause 
both to be installed, and if so, are both resolved.


I have added the above test to my M2 checks I will do - 
https://git.eclipse.org/r/c/epp/org.eclipse.epp.packages/+/192830 
 - 
and I will report back then.


Jonah



Thanks,
Jonah


[1]

https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/commit/8f79635e7217ecb24dbc209b964711e66a8f322d


[2]

https://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=16b27f6531af3cf41bc73bdfb27a581565f9dc33


[3] https://github.com/eclipse-pde/eclipse.pde.ui/issues/11


___
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

Re: [cross-project-issues-dev] TM4E planning to start using JavaSE-17 as BREE soon

[Christoph Läubrich]

Just because some bundles are J17 don't mean everyone will need J17 if 
consuming "simrel", I assume there is no one really building a product 
that contains *ever* simrel project.


So lets assume there is a never java 17 version in simrel, and you want 
to stick with java 11, then you can simply use that part from an earlier 
simrel. In the end this is not different from keeping the old java 11 
version in simrel and publish a "non simrel" java 17 release.


So from my point of view it does not makes much sense to keep older 
releases in simrel and publish newer ones of it unless you plan to 
contribute bugfix releases to the java 11 one in parallel, that's what 
releases are for that people can still use the old stuff if you moved 
ahead... otherwise one update-site could be used for a rolling release 
and eclipse could save a lot of storage-space ;-)


Am 19.04.22 um 20:34 schrieb Torbjorn SVENSSON via cross-project-issues-dev:

Hello,

Is it only me that sees problems for downstream consumers of the SimRel? I 
mean, what happens if you use the SimRel as a way to define a stable target 
platform for your product?
As long as the BREE of the plugins is not newer than version X will allow the product to 
run with JRE of that version "X".
What you are talking about here is more or less requiring anyone using SimRel 
to also move to a JRE 17. I think that's okay to do, but there should be some 
heads up for this type of change as it can cause major problem for our 
downstream consumers.

My 2 cents is that the newest BREE allowed in SimRel should be the same version 
that is said to be the required JRE version to run the Eclipse IDE (AFAIK, 
that's JRE 11 ATM).

Kind regards,
Torbjörn


ST Restricted

-Original Message-
From: cross-project-issues-dev  
On Behalf Of Christoph Läubrich
Sent: den 19 april 2022 19:16
To: cross-project-issues-dev@eclipse.org
Subject: Re: [cross-project-issues-dev] TM4E planning to start using JavaSE-17 
as BREE soon

  > I would be very keen to allow Java 17 as BREE in SimRel by a project
  > that wants it.
  > PS Where is "SimRel targets Java 11" defined? Is it just implicit
  > at the moment (because Eclipse Platform is Java 11),

I think there is at least no *technical* reason of this, as far as I
know there are still bundles targeting Java 8 (or even 6), one should
only keep in mind that if Eclipse is run with JDK11 then it would
require users to install never version if they want install such Java 17
stuff (probably that will be automated with the JustJ updatesite
included), so maybe there is nothing special to consider?



Am 19.04.22 um 16:37 schrieb Jonah Graham:

Thank you Mickael for starting this discussion.

I would be very keen to allow Java 17 as BREE in SimRel by a project
that wants it. I will endeavour to get the Planning Council to come to
an agreement on this as I think that is the group in charge of such
requirements.

PS Where is "SimRel targets Java 11" defined? Is it just implicit at the
moment (because Eclipse Platform is Java 11), or is it explicit
somewhere? The only requirement on this topic in the SimRel Release
Requirements is that bundles have a BREE[1]

[1]
https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Execution_Environment_.28tested.29
<https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Execution_Environment_.28tested.29>

Jonah


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com <http://www.kichwacoders.com>


On Tue, 19 Apr 2022 at 10:25, Mickael Istria mailto:mist...@redhat.com>> wrote:

 Hi all,

 In https://github.com/eclipse/tm4e/issues/339
 <https://github.com/eclipse/tm4e/issues/339> , active TM4E
 contributors have agreed to consider the move the JavaSE-17 as
 minimal Java version soon. The rationale is that some benefits of
 recent version of Java languages (sealed Types, switch
 expressions) are likely to really facilitate further maintenance
 and development of the parsers included in TM4E, and also to
 increase quality (new constructs leave less space for bugs, and
 often perform better). So we can expect a substantial gain for TM4E
 future in adopting Java 17 soon.

 I'm sharing this with Simultaneous Release channel as TM4E is part
 of SimRel. At the moment, SimRel targets Java 11. So when TM4E is
 released with Java 17 requirement, either SimRel allows that and the
 new release gets in; or SimRel keeps Java 11 requirement and will
 use an older version of TM4E (for which there would probably have no
 support given currently active contributors are happy moving to Java
 17).
 TM4E is used by Wild Web Developer for instance; but Wild Web
 Developer doesn't mandate 1 specific version of TM4E and we plan to
 keep TM4E backward compatible in term of behavior and API; so those
 downstream consumers should be able t

Re: [cross-project-issues-dev] TM4E planning to start using JavaSE-17 as BREE soon

[Christoph Läubrich]

> I would be very keen to allow Java 17 as BREE in SimRel by a project
> that wants it.
> PS Where is "SimRel targets Java 11" defined? Is it just implicit
> at the moment (because Eclipse Platform is Java 11),

I think there is at least no *technical* reason of this, as far as I 
know there are still bundles targeting Java 8 (or even 6), one should 
only keep in mind that if Eclipse is run with JDK11 then it would 
require users to install never version if they want install such Java 17 
stuff (probably that will be automated with the JustJ updatesite 
included), so maybe there is nothing special to consider?




Am 19.04.22 um 16:37 schrieb Jonah Graham:

Thank you Mickael for starting this discussion.

I would be very keen to allow Java 17 as BREE in SimRel by a project 
that wants it. I will endeavour to get the Planning Council to come to 
an agreement on this as I think that is the group in charge of such 
requirements.


PS Where is "SimRel targets Java 11" defined? Is it just implicit at the 
moment (because Eclipse Platform is Java 11), or is it explicit 
somewhere? The only requirement on this topic in the SimRel Release 
Requirements is that bundles have a BREE[1]


[1] 
https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Execution_Environment_.28tested.29 



Jonah


~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com 


On Tue, 19 Apr 2022 at 10:25, Mickael Istria > wrote:


Hi all,

In https://github.com/eclipse/tm4e/issues/339
 , active TM4E
contributors have agreed to consider the move the JavaSE-17 as
minimal Java version soon. The rationale is that some benefits of
recent version of Java languages (sealed Types, switch
expressions) are likely to really facilitate further maintenance
and development of the parsers included in TM4E, and also to
increase quality (new constructs leave less space for bugs, and
often perform better). So we can expect a substantial gain for TM4E
future in adopting Java 17 soon.

I'm sharing this with Simultaneous Release channel as TM4E is part
of SimRel. At the moment, SimRel targets Java 11. So when TM4E is
released with Java 17 requirement, either SimRel allows that and the
new release gets in; or SimRel keeps Java 11 requirement and will
use an older version of TM4E (for which there would probably have no
support given currently active contributors are happy moving to Java
17).
TM4E is used by Wild Web Developer for instance; but Wild Web
Developer doesn't mandate 1 specific version of TM4E and we plan to
keep TM4E backward compatible in term of behavior and API; so those
downstream consumers should be able to work with former (Java
11-able) release as well as newer (Java 17-able) release. So I don't
think that downstream consumption should be a main concern.

I would invite SimRel stakeholders to consider is whether/when to
allow Java 17-based code in SimRel.
Of course, I would advocate for "Do it right now" especially since
JustJ and thus SimRel and EPP packages ships a recent Java; but
acknowledge that this may require more discussion, hence why I'm
sharing this plan for TM4E early.

Cheers,

-- 
Mickael Istria

Eclipse IDE  developer, for Red
Hat Developers 
___
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] Sorry, entering a bug into the product JDT has been disabled.,

[Christoph Läubrich]

Just curious, if as you stated

> I do not know who / what is the underlying motivating
> force for this madness.

how do you know that, as you stated

> The plan never considered a new-GIT + new-Wiki + old-Bugzilla option.

and it was not considered?

From what I have seen on the mailingslist and elsewhere, many different 
options where discussion and there was a lot of room for the community 
to participate and give suggestions.


Am 19.04.22 um 11:54 schrieb Ed Willink:

Hi

Sorry. This is vandalism. No other word for it. "action involving 
deliberate destruction of or damage to public or private property." I 
didn't call anyone in particular a vandal since I do not know who / what 
is the underlying motivating force for this madness.


Yes I'm frustrated and seriously considering quitting Eclipse since the 
EF is pulling the rug out from facilities that I considered sacrosanct.


No I can't use gitlab since gitlab doesn't talk to me.

     Regards

         Ed

On 19/04/2022 09:25, Ed Merks wrote:


Ed,

I want to suggest *yet again *to please have this discussion on this 
issue rather than on this mailing list.


https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/678

This way all the interested parties can partake in the discussion and 
it will be recorded in one place rather than threaded through this 
mailing list.  Also, you will then see how issues work (which is 
rather cool in my opinion) and you will be able to comment in a more 
informed way about it.


I'd also strongly suggest omitting the emotional baggage from the 
discussion because when you describe something as 'vandalism' it 
implies that there are vandals about.  I'm very sure that our fine, 
overworked, Eclipse-Foundation IT staff will not appreciate that 
implication, nor suggestions that there is craziness and madness involved.


Let's please be nice with one another, even when we are frustrated...

Regards,
Ed

On 19.04.2022 10:08, Ed Willink wrote:


Hi

A plan. Yes, a plan facilitates discussion that enables craziness to 
be avoided.


So where is the Bugzilla that precedes the mad rush to issues?

Unfortunately I cannot participate on gitlab issues since gitlab 
seems unable to send notifications to me. I am excluded which may 
please many. I do not have the bandwidth to keep a Firefox tab open 
on every gitlab issue I care about and to poll them to see what has 
happened.


Re the respelling of git.eclipse.org as github. I moan but accept 
that this may be a necessary evil.


It is the loss of Bugzilla that I regard as unacceptable and a 
totally unjustified vandalism.


The plan never considered a new-GIT + new-Wiki + old-Bugzilla option.

    Regards

        Ed Willink

On 18/04/2022 12:56, Ed Merks wrote:


Ed,

The fate of Bugzilla, Gerrit, git.eclipse.org.and wiki.eclipse.org 
was announced to all committers:


https://www.eclipse.org/lists/eclipse.org-committers/msg01340.html

The announcement included a plan:

https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Gerrit/Gerrit-and-Bugzilla-deprecation-and-migration-plan

It also included a place for providing feedback:

https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/678

The platform has diligently migrated everything to Github, so that's 
a done deal and will not be undone.


Certainly there are issues with issues, e.g., you can't really move 
them between organizations, when an organization has many repos, 
it's not so clear where to open and issue, and how to search for 
issues across repos and organizations isn't clear.


Note that the Eclipse TLP has 4 organizations.

https://github.com/eclipse-equinox/
https://github.com/eclipse-jdt/
https://github.com/eclipse-pde/
https://github.com/eclipse-platform/

There are also advantages to issue, e.g., the user interface is much 
richer, allowing to create nice documentation with images and examples.


In any case, the place to  have a discussions, and to suggest 
concrete proposals to mitigate the downsides, is here rather than 
the mailing list:


https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/678


Regards,
Ed

On 18.04.2022 13:19, Ed Willink wrote:


Hi

Surely the fix is to abort this mad vandalism and so avoid the need 
to chase endless ripples?


While changing the spelling of git.eclipse.org and wiki.eclipse.org 
might be necessary and a manageable pain mitigated by redirects, 
terminating Bugzilla is madness.


Bugzilla has been providing an invaluable to service to the 
platform and JDT for over 20 years and as such is THE record of 
many design decisions. The integrity of this record should not 
lightly be discarded, particularly given that Bugzilla is not EOL. 
Ok it is not seeing much progress towards version 6, but to me that 
just demonstrates that it is adequate. Proposed replacements are 
far from adequate.


Eclipse is an aggregate of many projects and so we have long 
encouraged users to report their bug making a best guess at the 
correct product, sure in the 

Re: [cross-project-issues-dev] Sorry, entering a bug into the product JDT has been disabled.,

[Christoph Läubrich]

In general its more valuable to create a dedicated issue if there is a 
problem in an "upstream", e.g if in Tycho there is an issue with p2 one 
could simply open a ticket with p2 describing the actual problem and 
linking the tycho issue. In tycho we can then use the ticket to bump 
versions once the p2issue is done.


Am 18.04.22 um 13:56 schrieb Ed Merks:

Ed,

The fate of Bugzilla, Gerrit, git.eclipse.org.and wiki.eclipse.org was 
announced to all committers:


https://www.eclipse.org/lists/eclipse.org-committers/msg01340.html

The announcement included a plan:

https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Gerrit/Gerrit-and-Bugzilla-deprecation-and-migration-plan

It also included a place for providing feedback:

https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/678

The platform has diligently migrated everything to Github, so that's a 
done deal and will not be undone.


Certainly there are issues with issues, e.g., you can't really move them 
between organizations, when an organization has many repos, it's not so 
clear where to open and issue, and how to search for issues across repos 
and organizations isn't clear.


Note that the Eclipse TLP has 4 organizations.

https://github.com/eclipse-equinox/
https://github.com/eclipse-jdt/
https://github.com/eclipse-pde/
https://github.com/eclipse-platform/

There are also advantages to issue, e.g., the user interface is much 
richer, allowing to create nice documentation with images and examples.


In any case, the place to  have a discussions, and to suggest concrete 
proposals to mitigate the downsides, is here rather than the mailing list:


https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/678


Regards,
Ed

On 18.04.2022 13:19, Ed Willink wrote:


Hi

Surely the fix is to abort this mad vandalism and so avoid the need to 
chase endless ripples?


While changing the spelling of git.eclipse.org and wiki.eclipse.org 
might be necessary and a manageable pain mitigated by redirects, 
terminating Bugzilla is madness.


Bugzilla has been providing an invaluable to service to the platform 
and JDT for over 20 years and as such is THE record of many design 
decisions. The integrity of this record should not lightly be 
discarded, particularly given that Bugzilla is not EOL. Ok it is not 
seeing much progress towards version 6, but to me that just 
demonstrates that it is adequate. Proposed replacements are far from 
adequate.


Eclipse is an aggregate of many projects and so we have long 
encouraged users to report their bug making a best guess at the 
correct product, sure in the knowledge that it can be re-componented.


For instance https://bugs.eclipse.org/bugs/show_activity.cgi?id=578944 
was recently plausibly raised as an EMF bug, but then equally 
plausibly triaged as an OCL bug. Upon investigation this was bounced 
back again to EMF with the option to bounce further to platform. 
Bugzilla supports this very cleanly.


For instance again, last week I was forced to raise 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=579718 against PDE since 
JDT has gone. hoping that some PDE recipient would know what the new 
technology for re-componenting was. Instead a comment suggests that 
this is likely a side effect of the 16 year old 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=99622 that is still 
being worked on.


Examination of Bug 99622 shows that although JDT bugs have been moved 
to archive the active bugs have not yet been migrated and that no 
moved notifications have been sent.


It seems essential that ALL bugzillas from ALL 'platform' projects 
should be kept in the SAME search space; Bugzilla provides this. 
Replacements do not. This would seem to apply until some major 
disruption such as "e5" may justify the new team starting a new bug 
train for the new activity. Until then please keep e3 and e4 together.


For Modeling projects this is even more of an imperative. Sadly 
Eclipse and World Modeling is dying so the amount of new work in the 
next 20 years is likely to be much less than that in the last twenty. 
It is therefore crazy to split the dying embers off from their 
predecessors. If/when some magic new team of well funded enthusiasts 
comes along to pioneer EMF 3, then let them too choose the appropriate 
bug platform for the new initiative. For now please do not spend so 
much effort vandalizing out past achievements and burning our precious 
development resources.


Is there any long term Eclipse committer who actually wants this 
Bugzilla vandalism?


    Regards

        Ed Willink

On 18/04/2022 00:51, Denis Roy wrote:


We'll address the issue via the HelpDesk issue below.

Agree though, we need some redirects or links at the very least.

Denis


On 2022-04-17 12:21, Stephan Herrmann wrote:

On 17.04.22 12:46, Ed Merks wrote:

The message could be improved by redirecting here:

https://github.com/eclipse-jdt#reporting-issues

It sounds like the PMI needs attention too...


see 

Re: [cross-project-issues-dev] PlatformRel vs SimRel vs Orbit Abolishment frustration / Xtext leaving SimRel (again) ?!?

[Christoph Läubrich]

Hi Christian,

first of all I could understand that its frustrating if one feels 
actually overwhelmed by releng tasks but I think you are not alone with 
that.


So the same applies for people managing the releng tasks for orbit and 
platform and this was taken in the past and for sure it was comfortable 
for the consumers but I think we have reached a point where it becomes 
prominent that it is hard to keep up with this good-old times:


- serve CVEs impacting a lot of projects arise every day and we need to 
become faster here, there are often huge delays until they show up in 
orbit, with log4shell the update was outdated a few hours later because 
of another important CVE fixed and so on
- New Java versions are released a lot more often and many OSS projects 
don't want to take the effort to support older versions


For supporting old versions, as you have written, this is a choice of 
the project and I honestly don't understand the complains, for me there 
are two options:


1) drop the support for old versions and if no one complains be happy 
about saving you a lot of useless effort
2) if users are really addicted to old versions ask them to help with 
supporting that or pay for it so you can acquire more resources


Interestingly, for platform often there *are* complains but asking for 
someone to step up and help often results in silence... in the end it 
was not /that/ impossible to upgrade.


About the OOMPH part (as it was already mentioned twice here) I'm a bit 
confused, from what I understand OOMPH is based on eclipse so it could 
pull in whats necessary from the m2e bundles and should all be set for 
the new target location types (that what these extension points are for 
isn't it?). If anything hinders us to do so we should find a solution 
for that instead of waiting to implement just another implementation of 
the same thing.


As a last note:
As Xtext is an eclipse project you can always request Orbit of adding 
*any* dependency but be aware that this must be driven by you (e.g 
providing patches).




Am 07.04.22 um 04:54 schrieb Christian Dietrich:
Hi all, my frustration of the current state has cost me another 
sleepless night and thus i need to start this discussion again.


All of the following statements are subjective and describe my personal 
view and option and feelings.


Trigger was 
https://www.eclipse.org/lists/cross-project-issues-dev/msg19066.html but 
is just another big drop to barrel to overflow.


What is it about:

- PlatformRel: Release of the basic eclipse platform and jdt on a 
regular basis
- SimRel: All project release together with PlatformRel in versions that 
work together. This requires the projects to "paying attention" to 
ensure this holds true.
- Orbit: Central place to pull 3rd dependencies from. This avoid each 
and every project packaging their own stuff and makes it possible for 
projects with the same dependency to work together seemlessly.


Projects: Eclipse has projects with
- some budget
- a limited budget (i would categeorize Xtext with 4-6 days a month here)
- basically no buget

Projects and values:
- Some projects value support for older platform and java versions, 
others dont

- Some projects "pay attention", others dont

Xtext: what do i do for Xtext
- work with community
- fix bug
- develop some smaller features
- pay attention
   - fix broken Jenkins files cause infrastructure changes
   - test against upstream platform and jdt
   - bump versions of 3rd party dependencies
   - contribute to upstream project
   - 

What makes me frustrated:

I have the feeling that i spend 95% of my buget to accommodate for 
upstream infrastructure changes so that there is basically no time left 
for bugfixes or features. The 3 month simrel also adds time pressure to 
that "paying attention" if you take it serious.


The trigger(s):
- https://bugs.eclipse.org/bugs/show_bug.cgi?id=568936 with a cleanup 
process in orbit we have to deal with stuff disappearing from orbit. it 
is clear that this is a debt in orbit and i am ok with spending a 2/3 
month worth of budget to accomodate for it.
- https://www.eclipse.org/lists/cross-project-issues-dev/msg19066.html / 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=579574


the 2nd one is the defacto abolishment of orbit.

So if Xtext uses ASM and Platform/JDT uses ASM and they should work 
together we need to uses the same ASM.

What does this mean for Xtext

- We need to be able to support older platforms and java versions with 
newer tycho versions + the work for Jenkins file to make this possible 
(8 different builds)
- We need to find out how to use the p2 maven feature from oomph (at a 
first glance i could not find an option) or replace oomph with target 
files.
- Alternatively we can stop supporting more than 1 platform or Java 
versions.


I cannot tell how much work this will be because i am neither a tycho 
nor a Jenkinsfile nor an Oomph expert. I also have no pointers where to 
copy & paste from 

Re: [cross-project-issues-dev] Eclipse Platform to prefer use of dependencies from Maven Central rather than Orbit

[Christoph Läubrich]

Sure that's true, but will the "old crap" using maven-depdency target? I 
don't think so.


And the topic is "Eclipse Platform to prefer use of dependencies from 
Maven Central" so is it relevant that *older* platform releases don't 
support it?


In general for old code I use the old tools, that's why we do releases 
and Tycho is available at maven central back to version 0.12.0 so there 
should be a suitable tool for every ancient use-case.


Am 06.04.22 um 08:28 schrieb Ed Merks:

Christoph,

Comments below.

On 06.04.2022 06:55, Christoph Läubrich wrote:

> Might this approach be a problem for projects with very
> low Java target level?

Is this relevant given that platform already requires Java 11?


This is similar to asking if JDT's compiler stopped supporting Java 11 
is relevant?   Yes, because not everyone is building with the latest 
platform.  I have builds like this:


   https://ci.eclipse.org/emf/job/all-target-platforms/

This thing tests really old crap and uses Tycho do the builds and run 
the tests.


To generalize, of course it's relevant that a build system is able to 
respect the compiler levels and BREEs of the projects being compiled. 
The current Platform is not the center of the universe.




> would be required to use a recent version of Tycho, but that might not
> support building the old Java EE levels anymore.

New features require new version correct, but it should not be an 
issue see above, anyways I'm currently working in fixing a bug [1] for 
compiling java 8 with and tycho has a integration-test for compiling 
with an java 8 jdk so if 'old Java EE levels' not means JSE1.4 or 
something...


> Also everyone using the Target Platform Definition language *.tpd
> might be out, since that tooling cannot generate the new syntax
> I believe.

There is an open issue  [2]for that but it has not gotten much 
attention yet.


> but if you have ever managed targets with 1500 plugins you really
> don't want to go back from such a component based approach, towards
> a single file

From 2022-03 on PDE supports references of other target files [3], so 
you could either use this directly, or have one "main" target with 
maven deps, that includes another that is generated by the TPD files.



[1] https://github.com/eclipse/tycho/issues/51
[2] https://github.com/eclipse-cbi/targetplatform-dsl/issues/115
[3] https://www.eclipse.org/eclipse/news/4.23/pde.php#pde-editor-include


Am 05.04.22 um 20:46 schrieb Michael Keppler:

Might this approach be a problem for projects with very low Java target
level? From my understanding, to be able to use that mechanism they
would be required to use a recent version of Tycho, but that might not
support building the old Java EE levels anymore.

Also everyone using the Target Platform Definition language *.tpd might
be out, since that tooling cannot generate the new syntax I believe.
https://github.com/eclipse-cbi/targetplatform-dsl. Of course everyone
using TPD can just maintain .target files instead, but if you have ever
managed targets with 1500 plugins, you really don't want to go back from
such a component based approach, towards a single file, without comments
etc.

___
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] Eclipse Platform to prefer use of dependencies from Maven Central rather than Orbit

[Christoph Läubrich]

> Might this approach be a problem for projects with very
> low Java target level?

Is this relevant given that platform already requires Java 11?

> would be required to use a recent version of Tycho, but that might not
> support building the old Java EE levels anymore.

New features require new version correct, but it should not be an issue 
see above, anyways I'm currently working in fixing a bug [1] for 
compiling java 8 with and tycho has a integration-test for compiling 
with an java 8 jdk so if 'old Java EE levels' not means JSE1.4 or 
something...


> Also everyone using the Target Platform Definition language *.tpd
> might be out, since that tooling cannot generate the new syntax
> I believe.

There is an open issue  [2]for that but it has not gotten much attention 
yet.


> but if you have ever managed targets with 1500 plugins you really
> don't want to go back from such a component based approach, towards
> a single file

From 2022-03 on PDE supports references of other target files [3], so 
you could either use this directly, or have one "main" target with maven 
deps, that includes another that is generated by the TPD files.



[1] https://github.com/eclipse/tycho/issues/51
[2] https://github.com/eclipse-cbi/targetplatform-dsl/issues/115
[3] https://www.eclipse.org/eclipse/news/4.23/pde.php#pde-editor-include


Am 05.04.22 um 20:46 schrieb Michael Keppler:

Might this approach be a problem for projects with very low Java target
level? From my understanding, to be able to use that mechanism they
would be required to use a recent version of Tycho, but that might not
support building the old Java EE levels anymore.

Also everyone using the Target Platform Definition language *.tpd might
be out, since that tooling cannot generate the new syntax I believe.
https://github.com/eclipse-cbi/targetplatform-dsl. Of course everyone
using TPD can just maintain .target files instead, but if you have ever
managed targets with 1500 plugins, you really don't want to go back from
such a component based approach, towards a single file, without comments
etc.

___
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 Platform to prefer use of dependencies from Maven Central rather than Orbit

[Christoph Läubrich]

> When Maven Central is not OSGi artifact  Orbit will be preferred.

I can only encourage everyone to open a ticket for such project and help 
them to include OSGi meta-data in the first place instead of putting the 
effort else-where, as adding those does not harm the project but helps 
integration it with just a few extra lines in the manifest.


Am 05.04.22 um 13:48 schrieb Aleksandar Kurtakov:

Hey everyone,
With PGP signing support, latest Tycho work and M2E extending PDE so 
*.target files can refer/use dependencies from Maven Central directly 
will prefer to use dependencies from Maven Central when updating to new 
versions of libraries.
This would be done only when we update to a new version of libraries or 
the dependency we use is no longer available in the latest Orbit build. 
When Maven Central is not OSGi artifact  Orbit will be preferred.
 From releng POV it would simply remove the middle man (Orbit/EBR) as 
Tycho automates what was achieved via EBR as an intermediate step to be 
part of the regular build.

Extra benefits are:
* Eclipse will no longer ship modified version of upstream release (PGP 
signature is in p2 metadata and not modifying the jar as jarsigner does)
* Eclipse will not longer ship bundles with symbolic names that do not 
match upstream developers decision (as it happens with number of Orbit 
artifacts)
* Version updates could be done in chunks rather than all changes at 
once to work with latest Orbit


I strongly encourage other projects to take that path too for third 
party dependencies.



--
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

[cross-project-issues-dev] Introduction to the new mixed-reactor-build feature and improved PDE/m2e support

[Christoph Läubrich]

Finally it is now possible to have "mixed-reactor-builds" with the new 
Tycho 2.7 release and the improved support in m2eclipse 1.20. Also PDE 
will contain some enhancements in the upcoming 2022-03 release.


If you like to learn more, I have described everything in more details here:

https://xn--lubisoft-0za.gmbh/en/articles/mixed-reactor-builds-with-tycho/
___
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] Please test your builds with maven 3.8.5 / Fwd: [VOTE] Release Apache Maven version 3.8.5

[Christoph Läubrich]

I'm not sure if any of the DefaultXXX implementations could be 
considered API ... and they should actually be found by the Plexus 
container by their API interfaces.


Nerveless, you need to make ModelVersionProcessor available for 
injection to fix this issue (this is maven 3.8.x API) see 
org.apache.maven.model.interpolation.DefaultModelVersionProcessor
if you do not use the standard lookup of maven components or you use 
DefaultModelBuilderFactory



Am 07.03.22 um 14:41 schrieb Mickael Istria:

Seems like Maven 3.8.5 candidate causes major issue with Tycho
"""
Plugin org.eclipse.tycho:tycho-maven-plugin:3.0.0-SNAPSHOT or one of its 
dependencies could not be resolved: The following artifacts could not be 
resolved: org.codehaus.plexus:plexus-archiver:jar:4.2.7, 
org.codehaus.plexus:plexus-interpolation:jar:1.26, 
org.codehaus.plexus:plexus-cipher:jar:2.0, 
org.eclipse.platform:org.eclipse.osgi:jar:3.17.100, 
de.pdark:decentxml:jar:1.4, org.codehaus.plexus:plexus-utils:jar:3.4.1, 
org.codehaus.plexus:plexus-component-annotations:jar:2.1.1: 
org.codehaus.plexus:plexus-archiver:jar:4.2.7 was not found in ...

""",
causes m2e integration of LemMinX-Maven to fail, most likely because 
LemMinX-Maven fails  itself

"""
[ERROR] 
/home/jenkins/agent/workspace/LemMinX-Maven_PR-282-head/lemminx-maven/src/main/java/org/eclipse/lemminx/extensions/maven/ModelValidatorMNG7170.java:[17,8] 
constructor DefaultModelValidator in class 
org.apache.maven.model.validation.DefaultModelValidator cannot be 
applied to given types;

   required: org.apache.maven.model.interpolation.ModelVersionProcessor
   found: no arguments
   reason: actual and formal argument lists differ in length
"""

I'm investigating whether a backward compatible change can be 
implemented. If not, then it means Maven has an API breakage which 
should be a reason why we could vote -1 for this release.


___
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] Please test your builds with maven 3.8.5 / Fwd: [VOTE] Release Apache Maven version 3.8.5

[Christoph Läubrich]

Hi Christian,

I'm just curious but how do you test your code contributions if not with 
a local build? Commit & Pray?


Anyways if we think CI is a must-have here, one should open a ticket 
with eclipse infra, maybe they can make this available.


Beside that, some wget / unzip / export_env / magic would be possible...

Am 06.03.22 um 12:02 schrieb Dietrich, Christian:


Yes but having it on Jenkins would make it easy to test instead of local 
pita
Christoph Läubrich <mailto:lae...@laeubi-soft.de>> schrieb am So. 6. März 2022 um 11:17:


Hi Ed,

3.8.5 isn't released yet, so everyone has now the opportunity to test
their builds and reports regression so they are fixed before the
release
if there is a major regression.


Am 06.03.22 um 11:07 schrieb Ed Willink:
 > Hi
 >
 > 3.8.5 isn't in the pull-down list for
 >
 > https://ci.eclipse.org/ocl/job/ocl-branch-tests/configure
<https://ci.eclipse.org/ocl/job/ocl-branch-tests/configure>
 >
 >      Regards
 >
 >          Ed Willink
 >
 > On 06/03/2022 09:24, Christoph Läubrich wrote:
 >> Tycho will soon require 3.8.5 due to crucial enhancements in the
maven
 >> API.
 >>
 >> So I'd like to ask everyone to test their builds with the upcoming
 >> maven 3.8.5 what could be found here:
 >>
 >> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.5/
<https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.5/>
 >>
 >> Please report any issue to the maven dev list or the JIRA as
soon as
 >> possible.
 >>
 >>
 >>  Weitergeleitete Nachricht 
 >> Betreff: [VOTE] Release Apache Maven version 3.8.5
 >> Datum: Sat, 5 Mar 2022 17:47:12 +0100
 >> Von: Michael Osipov mailto:micha...@apache.org>>
 >> Antwort an: Maven Developers List mailto:d...@maven.apache.org>>
 >> An: Maven Developers List mailto:d...@maven.apache.org>>
 >>
 >> Hi,
 >>
 >> We solved 27 issues:
 >>

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12351105

<https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12351105>

 >>
 >>
 >> There are still hundreds of issues left in JIRA:
 >>

https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved

<https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved>

 >>
 >>
 >> Staging repo:
 >> https://repository.apache.org/content/repositories/maven-1724/
<https://repository.apache.org/content/repositories/maven-1724/>
 >>
 >> Dev dist directory:
 >> https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.5/
<https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.5/>
 >>
 >> Source release checksums:
 >> apache-maven-3.8.5-src.zip sha512:
 >>

7edb6864834a81c11cf9d22a8110abc3f5f96360bdbc4bc33ec0c98dc389dd9fc71465253a87729dbe7b8a011b2ec38afa0e011172657c3a97ef96fb6f40292b

 >>
 >> apache-maven-3.8.5-src.tar.gz sha512:
 >>

1aa1b2dcba794b7e4cbc8e2ff9baf64283fb3883ae93efff26fe259578504b60a8b68404a074f4741922e462fa696cbbe71f9d74e4e6316ed0e389d25667

 >>
 >>
 >> Binary release checksums:
 >> apache-maven-3.8.5-bin.zip sha512:
 >>

f9f838b4adaf23db0204a6cafa52bf1125bd2d649fd676843fd05e82866b596ec19c4f3de60d5e3ff17f10a63d96c141311ff9bc2bfa816eade7a5cbff2bd925

 >>
 >> apache-maven-3.8.5-bin.tar.gz sha512:
 >>

89ab8ece99292476447ef6a6800d9842bbb60787b9b8a45c103aa61d2f205a971d8c3ddfb8b03e514455b4173602bd015e82958c0b3ddc1728a57126f773c743

 >>
 >>
 >> Draft for release notes:
 >> https://github.com/apache/maven-site/pull/292
<https://github.com/apache/maven-site/pull/292>
 >>
 >>
 >> Guide to testing staged releases:
 >>
http://maven.apache.org/guides/development/guide-testing-releases.html
<http://maven.apache.org/guides/development/guide-testing-releases.html>
 >>
 >> Vote open until 2021-03-13T12:00Z
 >>
 >> [ ] +1
 >> [ ] +0
 >> [ ] -1
 >>
 >>
-
 >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
<mailto:dev-unsubscr...@maven.apache.org>
 >> For additional commands, e-mail: dev-h...@maven.apache.org
<mailto:dev-h...@maven

Re: [cross-project-issues-dev] Please test your builds with maven 3.8.5 / Fwd: [VOTE] Release Apache Maven version 3.8.5

[Christoph Läubrich]

Hi Ed,

I think you need to open a ticket at eclipse infra for this.

It would even be desirable to always have the next upcoming maven 
version available on a routine basis as the more often and as early as 
possible we all test crucial tools any impact will be discovered instantly.


Am 06.03.22 um 13:08 schrieb Ed Willink:

Hi

Ok

So let's have e.g. 3.8.5-pre-20220306 in the pull down list until 
(perhaps one week) after 3.8.5 replaces it.


     Regards

         Ed Willink

On 06/03/2022 10:17, Christoph Läubrich wrote:

Hi Ed,

3.8.5 isn't released yet, so everyone has now the opportunity to test 
their builds and reports regression so they are fixed before the 
release if there is a major regression.



Am 06.03.22 um 11:07 schrieb Ed Willink:

Hi

3.8.5 isn't in the pull-down list for

https://ci.eclipse.org/ocl/job/ocl-branch-tests/configure

 Regards

     Ed Willink

On 06/03/2022 09:24, Christoph Läubrich wrote:
Tycho will soon require 3.8.5 due to crucial enhancements in the 
maven API.


So I'd like to ask everyone to test their builds with the upcoming 
maven 3.8.5 what could be found here:


https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.5/

Please report any issue to the maven dev list or the JIRA as soon as 
possible.



 Weitergeleitete Nachricht 
Betreff: [VOTE] Release Apache Maven version 3.8.5
Datum: Sat, 5 Mar 2022 17:47:12 +0100
Von: Michael Osipov 
Antwort an: Maven Developers List 
An: Maven Developers List 

Hi,

We solved 27 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12351105 



There are still hundreds of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved 



Staging repo:
https://repository.apache.org/content/repositories/maven-1724/

Dev dist directory:
https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.5/

Source release checksums:
apache-maven-3.8.5-src.zip sha512: 
7edb6864834a81c11cf9d22a8110abc3f5f96360bdbc4bc33ec0c98dc389dd9fc71465253a87729dbe7b8a011b2ec38afa0e011172657c3a97ef96fb6f40292b 

apache-maven-3.8.5-src.tar.gz sha512: 
1aa1b2dcba794b7e4cbc8e2ff9baf64283fb3883ae93efff26fe259578504b60a8b68404a074f4741922e462fa696cbbe71f9d74e4e6316ed0e389d25667 



Binary release checksums:
apache-maven-3.8.5-bin.zip sha512: 
f9f838b4adaf23db0204a6cafa52bf1125bd2d649fd676843fd05e82866b596ec19c4f3de60d5e3ff17f10a63d96c141311ff9bc2bfa816eade7a5cbff2bd925 

apache-maven-3.8.5-bin.tar.gz sha512: 
89ab8ece99292476447ef6a6800d9842bbb60787b9b8a45c103aa61d2f205a971d8c3ddfb8b03e514455b4173602bd015e82958c0b3ddc1728a57126f773c743 



Draft for release notes:
https://github.com/apache/maven-site/pull/292


Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open until 2021-03-13T12:00Z

[ ] +1
[ ] +0
[ ] -1

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

___
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] Please test your builds with maven 3.8.5 / Fwd: [VOTE] Release Apache Maven version 3.8.5

[Christoph Läubrich]

Hi Ed,

3.8.5 isn't released yet, so everyone has now the opportunity to test 
their builds and reports regression so they are fixed before the release 
if there is a major regression.



Am 06.03.22 um 11:07 schrieb Ed Willink:

Hi

3.8.5 isn't in the pull-down list for

https://ci.eclipse.org/ocl/job/ocl-branch-tests/configure

     Regards

         Ed Willink

On 06/03/2022 09:24, Christoph Läubrich wrote:
Tycho will soon require 3.8.5 due to crucial enhancements in the maven 
API.


So I'd like to ask everyone to test their builds with the upcoming 
maven 3.8.5 what could be found here:


https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.5/

Please report any issue to the maven dev list or the JIRA as soon as 
possible.



 Weitergeleitete Nachricht 
Betreff: [VOTE] Release Apache Maven version 3.8.5
Datum: Sat, 5 Mar 2022 17:47:12 +0100
Von: Michael Osipov 
Antwort an: Maven Developers List 
An: Maven Developers List 

Hi,

We solved 27 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12351105 



There are still hundreds of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved 



Staging repo:
https://repository.apache.org/content/repositories/maven-1724/

Dev dist directory:
https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.5/

Source release checksums:
apache-maven-3.8.5-src.zip sha512: 
7edb6864834a81c11cf9d22a8110abc3f5f96360bdbc4bc33ec0c98dc389dd9fc71465253a87729dbe7b8a011b2ec38afa0e011172657c3a97ef96fb6f40292b 

apache-maven-3.8.5-src.tar.gz sha512: 
1aa1b2dcba794b7e4cbc8e2ff9baf64283fb3883ae93efff26fe259578504b60a8b68404a074f4741922e462fa696cbbe71f9d74e4e6316ed0e389d25667 



Binary release checksums:
apache-maven-3.8.5-bin.zip sha512: 
f9f838b4adaf23db0204a6cafa52bf1125bd2d649fd676843fd05e82866b596ec19c4f3de60d5e3ff17f10a63d96c141311ff9bc2bfa816eade7a5cbff2bd925 

apache-maven-3.8.5-bin.tar.gz sha512: 
89ab8ece99292476447ef6a6800d9842bbb60787b9b8a45c103aa61d2f205a971d8c3ddfb8b03e514455b4173602bd015e82958c0b3ddc1728a57126f773c743 



Draft for release notes:
https://github.com/apache/maven-site/pull/292


Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open until 2021-03-13T12:00Z

[ ] +1
[ ] +0
[ ] -1

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

___
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] Please test your builds with maven 3.8.5 / Fwd: [VOTE] Release Apache Maven version 3.8.5

[Christoph Läubrich]

Tycho will soon require 3.8.5 due to crucial enhancements in the maven API.

So I'd like to ask everyone to test their builds with the upcoming maven 
3.8.5 what could be found here:


https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.5/

Please report any issue to the maven dev list or the JIRA as soon as 
possible.



 Weitergeleitete Nachricht 
Betreff: [VOTE] Release Apache Maven version 3.8.5
Datum: Sat, 5 Mar 2022 17:47:12 +0100
Von: Michael Osipov 
Antwort an: Maven Developers List 
An: Maven Developers List 

Hi,

We solved 27 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316922=12351105

There are still hundreds of issues left in JIRA:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20MNG%20AND%20resolution%20%3D%20Unresolved

Staging repo:
https://repository.apache.org/content/repositories/maven-1724/

Dev dist directory:
https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.5/

Source release checksums:
apache-maven-3.8.5-src.zip sha512: 
7edb6864834a81c11cf9d22a8110abc3f5f96360bdbc4bc33ec0c98dc389dd9fc71465253a87729dbe7b8a011b2ec38afa0e011172657c3a97ef96fb6f40292b
apache-maven-3.8.5-src.tar.gz sha512: 
1aa1b2dcba794b7e4cbc8e2ff9baf64283fb3883ae93efff26fe259578504b60a8b68404a074f4741922e462fa696cbbe71f9d74e4e6316ed0e389d25667


Binary release checksums:
apache-maven-3.8.5-bin.zip sha512: 
f9f838b4adaf23db0204a6cafa52bf1125bd2d649fd676843fd05e82866b596ec19c4f3de60d5e3ff17f10a63d96c141311ff9bc2bfa816eade7a5cbff2bd925
apache-maven-3.8.5-bin.tar.gz sha512: 
89ab8ece99292476447ef6a6800d9842bbb60787b9b8a45c103aa61d2f205a971d8c3ddfb8b03e514455b4173602bd015e82958c0b3ddc1728a57126f773c743


Draft for release notes:
https://github.com/apache/maven-site/pull/292


Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open until 2021-03-13T12:00Z

[ ] +1
[ ] +0
[ ] -1

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

___
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] P2 site mirror for Eclipse builds

[Christoph Läubrich]

As an alternative for small updatesites (around a few megabytes), it is 
also possible to deploy the update-site as an artifact to a 
maven-repository (e.g. github packages[1] free for public repositories).


This can the be consumed using the mvn protocol in tycho + pde (with 
m2e) see [2].


This might be a better alternative than GH-pages.



[1] https://github.com/features/packages

https://docs.github.com/en/actions/publishing-packages/publishing-java-packages-with-maven
[2] 
https://github.com/eclipse/tycho/blob/master/RELEASE_NOTES.md#support-for-consuming-maven-artifacts-made-of-zipped-p2-update-sites-


Am 24.02.22 um 09:34 schrieb Lorenzo Bettini:

On 22/02/22 09:38, Mikael Barbero wrote:
I get it is frustrating that suddenly it stops working while you did 
not change anything but Git(hub) repositories are no files servers and 
should not be abused like so.


You should contact the original author and ask him to publish his p2 
repository to a proper file service. It could be github releases or 
github pages. Those are not rate limited AFAICT.


In case it might helpful, I wrote a blog post on how to publish a 
composite p2 repository on github pages:


https://www.lorenzobettini.it/2021/03/publishing-an-eclipse-p2-composite-repository-on-github-pages/ 



however, please keep in mind that there are still a few limitations on 
github pages as well 
(https://docs.github.com/en/pages/getting-started-with-github-pages/about-github-pages#guidelines-for-using-github-pages): 



"GitHub Pages sites are subject to the following usage limits:

     GitHub Pages source repositories have a recommended limit of 1GB. 
For more information, see "What is my disk quota?"


     Published GitHub Pages sites may be no larger than 1 GB.

     GitHub Pages sites have a soft bandwidth limit of 100GB per month.

     GitHub Pages sites have a soft limit of 10 builds per hour.

If your site exceeds these usage quotas, we may not be able to serve 
your site, or you may receive a polite email from GitHub Support 
suggesting strategies for reducing your site's impact on our servers, 
including putting a third-party content distribution network (CDN) in 
front of your site, making use of other GitHub features such as 
releases, or moving to a different hosting service that might better fit 
your needs.

"

cheers
 Lorenzo

--
Prof. Lorenzo Bettini, Computer Science, DISIA, Univ. Firenze
HOME: http://www.lorenzobettini.it
TDD Book: https://leanpub.com/tdd-buildautomation-ci
Xtext Book: 
https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition 


___
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] P2 site mirror for Eclipse builds

[Christoph Läubrich]

Are these "external p2 sites" actually eclipse projects? Are they 
available as well on maven? Do you require the whole site or just 
individual parts?


Am 21.02.22 um 10:12 schrieb Christian Pontesegger:

Hi,

we are facing some build issues with EASE and Tracecompass projects:
both depend on an external p2 site hosted on github. Sometimes the
external site cannot be queried, probably due to quota issues on
github?

So the question is whether eclipse provides some means of buffering, eg
through artifactory? If not: under which circomstances could we mirror
the p2 and provide it as jenkins artifacts?

thanks
Christian

___
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] Anyone with ruby skills willing to help getting maven-target support for dependabot?

[Christoph Läubrich]

Hi,

the maven-target locations are around for a while and projects are 
already starting to use them (e.g. m2e).


A good tooling addition for this feature would be if dependabot[1] could 
automatically suggest updates for such dependencies declared in a target 
file.


I have created a feature-request [2] but I'm not familiar with ruby, 
thus I'd like to ask if someone on the list is more familiar and willing 
to provide a PR for getting this feature in.


[1] 
https://github.blog/2020-06-01-keep-all-your-packages-up-to-date-with-dependabot/

[2] https://github.com/dependabot/dependabot-core/issues/4682
___
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

[Christoph Läubrich]

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] 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 



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

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

[Christoph Läubrich]

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



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

[Christoph Läubrich]

To be honest by using Require-Bundle developers have taken their choice 
and should now be punished for it instead of some one else providing 
some nice workaround supporting their laziness and/or ignorance.


This whole story greatly shows why import-package is always superior to 
require bundle if you consume API.


Anyways I'm sure there will be enough "but the show must go on" +1 so 
the only valid alternative is to do it like Ed suggested, making a 
bundle that reexports under a given name (and might in this case should 
even use Require-Bundle to simply merge the class spaces).


Am 25.01.22 um 19:00 schrieb Dirk Fauth:

Hi,

As Log4j 1.x also has a vulnerability and that project has reached the 
EOL there is no official release that could be used to fix that. It 
seems QOS has taken over and provides a fixed version:


https://reload4j.qos.ch/ 

Unfortunately this can't be used in Eclipse based products to fix the 
issue if plug-in developers used Require-Bundle instead of 
Import-Package. Reload4j doesn't specify the matching Bundle-SymbolicName.


So my question to the cross project list (as I suppose this issue could 
be faced by several projects), would it be possible to re-bundle the 
reload4j jar and change the Bundle-SymbolicName to match the old Apache 
version? This could then be provided via Orbit for example.


For sure the correct way to solve the problem would be that every 
consumer Plug-in of Log4j uses Import-Package instead of Require-Bundle. 
But the past can't be changed. And I am looking for a backwards 
compatible way that is compliant to the OSS rules.


Any idea or hint is appreciated.

Greez,
Dirk

___
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] Disabling Mylyn from SimRel + Removing related Orbit workarounds

[Christoph Läubrich]

You can also include bundles in your category.xml no need for a feature.

I just wonder if not Orbit itself should contribute its latest release 
to simrel and thus participate in sim-rel process directly.


That would mean I never need to add Orbit directly but can only depend 
on what is at the simrel-repo isn't it?



Am 14.01.22 um 10:08 schrieb Ed Merks:
I'm not sure these are entirely good ideas, though certainly sensible in 
principle.  The devil is in the details...


In the other related thread (about Passage) it was suggested to "mirror 
dependencies in project's own p2 repo" but that isn't an entirely clear 
statement.  In particular, one might take that literally and too 
broadly.  E.g., I don't want my Oomph repository to mirror *all *its 
dependencies because I don't want my repository to include dependencies 
from all these other projects that Oomph directly depends upon, other 
than Orbit things "of course," though why Orbit and not the other ones?  
So I definitely *do not *want include all "includeAllDependencies".


Without guidance on *what *should be in your own repository, *why *it 
should be in your own repository, and *how *you should ensure that it 
ends up in your own repository, we have a team of downstream people with 
open questions.


Suppose we remove Orbit from the above graph, which is the stated goal.  
All the things available in Orbit that are needed by other projects will 
then have to come from repositories of other projects.   Again, that's 
fine and good and is the goal.  But, Mylyn could change its aggrcon to 
reference the Orbit repo that resolves their requirements.  That would 
clearly not improve things.  It would mask the other problems in the 
other projects because the aggregator doesn't care from where things are 
resolved.  I guess there is a rule that no one should do that? Mylyn 
could also change their repository to reference (or compose) the Orbit 
repository, which would have the same effect, but we'd not even see that 
looking at the aggrcons themselves.  Would that be wrong or against some 
rule?


The bottom line is that I'm *sure *there are many projects that depend 
on "Orbit contributions" that are in fact contributed by other projects 
rather their own project, but we only notice this "Orbit dependency" 
issue when some project is the only one with a dependency that is 
satisfied by neither itself nor any other project.  E.g., Passage is the 
only one using log4j2.  So, for example, it's okay (apparently) if my 
repo doesn't include Orbit dependencies that are included/provided by 
the Platform, until the Platform contributes a version that doesn't 
satisfy my requirements, and then it's suddenly not okay because 
suddenly we notice.  One might even argue it's better that I rely on the 
Platform contributing my Orbit dependencies because that way I won't 
include a different version leading to the multiple versions problem and 
I'll notice when I should move to a new version...


I mention this because it will be surprising later when we must disable 
some project only to find out it's the only one contributing some 
specific "Orbit dependency" on which a number of other projects depend.


All that being said, the *what and why *should be somewhat more clear to 
the projects themselves if you ask yourself, What other repositories 
must be available in order for the user to install one more more of your 
features? Note that the answer is not at all related to SimRel, but if 
your answer is that as long as the SimRel repo is available, it's fine, 
then your answer might well be circular...


So *how* do you ensure that the necessary/important/right things are in 
your own repository?  Certainly includeAllDependencies is the big 
hammer, but do you really want users to install some snapshot of all 
your dependencies?  It seems doubtful.  The obvious approach is to 
include a "missing" plugin in a feature.xml of a feature that is in your 
p2 update site because it's mentioned in the category.xml.  But that 
might not be ideal because you might be fine with a range of versions 
and might not want to force your specific version to be installed (and 
to be contributed to SimRel, leading to duplicates).  You can also 
mention such a plugin directly in your category.xml such that a version 
is available, but that one is not necessarily the one that must/will be 
installed to make your bundles happy.  What we did in Oomph is to 
include some Orbit dependencies in a test feature that is included in 
the category.xml as uncategorized and we don't contribute the test 
feature to SimRel so our Orbit requirements will (hopefully) be 
satisfied by other projects with more restrictive version range 
requirements that those of Oomph...


Regards,
Ed

On 14.01.2022 09:50, Christoph Läubrich wrote:

If Tycho is used it is probably the easiest to enable

https://www.eclipse.org/tycho/site

Re: [cross-project-issues-dev] Disabling Mylyn from SimRel + Removing related Orbit workarounds

[Christoph Läubrich]

If Tycho is used it is probably the easiest to enable

https://www.eclipse.org/tycho/sitedocs/tycho-p2/tycho-p2-repository-plugin/assemble-repository-mojo.html#includeAllDependencies

to get the best user experience and fulfill this requirement without any 
additional actions.


Am 14.01.22 um 08:43 schrieb Alexander Fedorov:

Hi Jonah,

Since Passage was never depending from Mylyn it was surprising to see it 
disabled. As I understood, it was done because Passage does not mirror 
all the used Orbit bundles to its p2 site.
Please don't get me wrong, but the gap between notification [1] and 
action seems a bit tight to me: about 1 day without technical space to 
fix it.


Perhaps I missed something important during the past years but the rule 
to always mirror Orbit dependencies to the component p2 site was neither 
clearly articulated nor enforced previously.


To avoid future misunderstanding I've created a ticket [2] to improve 
Project Handbook regrading SimRel participation.
@Wayne, @Alexander please invest your time to polish the formulation of 
this [new?] constraint for Eclipse projects that are willing to 
participate SimRel.


Thank you,
AF

[1] https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/189570
[2] https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/issues/177

1/13/2022 11:20 PM, Jonah Graham пишет:



On Thu, 13 Jan 2022 at 08:47, Jonah Graham  wrote:

On Thu., Jan. 13, 2022, 08:18 Aleksandar Kurtakov,
 wrote:

I would dare to say that as long as the workarounds are in
simrel nothing will get fixed - it's time to face reality.

Probably correct, but I don't have the nerve to disable (or
knowledge/time to fix) Mylyn.


Hi folks,

It is time to remove the temporary workarounds. When I had a look 
today I realised that more and more projects are relying on the 
temporary workaround initially put in place for Mylyn.


Over a year ago I filed numerous bugs asking projects to fix their 
contributions, some projects were very responsive and others I have 
not heard back from.


Therefore for M2 I plan to disable all projects from SimRel that 
aren't up to date or have otherwise started relying on these 
workarounds. I will submit the following gerrits[1,2] after 2022-03 M1 
is done. Please see the gerrits for what is disabled. I attempted to 
only disable features where possible and not entire contributions.


The affected projects are (with some comments):
- Mylyn (fully disabled Bug 569078)
- Passage (only one feature, so fully disabled)
- DTP (many features, lots because Lucene 7.x is no longer provided by 
Eclipse Platform? + Bug 569181)

- WTP (Bug 568136)
- m2e-wtp (JPA related code)
- PDT (Composer feature needs org.apache.commons.exec)
- soa-bpel (depends on disabled WTP features)

[1] 
https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/189612 - 
Remove the Orbit direct contribution to SimRel workaround
[2] 
https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/189614 - 
Remove Mylyn


Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com 



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To 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 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: update to 2.16.0?

[Christoph Läubrich]

Hi Alexander,

I think no one should depend on passage providing the dependency for 
them, I just suggested this as it seems passage is the only consumer of 
that orbit bundle in simrel (as m2e is for bnd-lib).


About the trust-orbit one must really ask what that should mean. 
Actually Orbit was just a source of IP reviewed items and adding some 
OSGi meta-data in some cases.


I can't remember that any security-audit was ever done before 
including/updating something in orbit, but I probably just missed 
something. And even if, it obviously has missed the CVEs discovered now 
so one could really ask if Orbit puts that much extra trust given that 
often items are long time outdated and missing security updates/fixes.



Am 13.01.22 um 10:42 schrieb Alexander Fedorov:

Thank you, Ed

You are definitely right, the notice from my side was very late, sorry 
for not discovering this Orbit contribution problem earlier.
Since Jonah updated the orbit.aggrcon before the staging we should have 
the log4j 2.15.0 in the SimRel. The log4j 2.15.0 is not the latest one 
but has a fix for the most famous vulnerability.


Thank you, Christoph

I'll definitely try the suggested approach to weaker the dependency to 
Orbit.


However, that means that dependency form Orbit has became a toxic one, 
since the focus of attention through all the discussion is always on 
consuming component (Passage in our case) rather than on the root cause 
(Orbit). Here we can observe the transfer of responsibility for Orbit 
content to the downstream component that was unlucky enough to 
contribute the bundle from Orbit to SimRel. That is definitely something 
new, since Orbit was a trusted source of 3rd party libraries for many 
years.


Regards,
AF

1/13/2022 11:53 AM, Ed Merks пишет:

Christoph,

That's cool.   Thanks for sharing.  :-)

Regards,
Ed


On 13.01.2022 09:49, Christoph Läubrich wrote:

Hi Ed,


If that implies PGP signed content on the train


Nope, this will (res)sign the artifact with standard eclipse-jar signer.

m2e uses this approach to contribute bnd-lib to simrel what is from 
p2 but without signature, the same works for artifacts of any source



BTW, when one chooses to do this "direct from Maven" thing, can one
also choose to create the source bundle/attachment for it?
It will be super annoying in the future to have a growing bunch of
black-box libraries without associated sources...


m2e+tycho support automatic source-bundle generation of associated 
source for maven items (see for example this screenshot[1]) when 
"Include Artifact Sources" is enabled.


[1] 
https://user-images.githubusercontent.com/1331477/139412713-e0218ff7-642c-4c19-afac-55fca49ef325.png 



Am 13.01.22 um 09:42 schrieb Ed Merks:

Christoph,

If that implies PGP signed content on the train, then no, Eclipse 
Passage should not choose to do that at this time because PGP 
support is not yet ready for prime time, but we are working on that;


https://gitlab.eclipse.org/eclipse-wg/ide-wg/ide-wg.eclipse.org/-/issues/11 



BTW, when one chooses to do this "direct from Maven" thing, can one 
also choose to create the source bundle/attachment for it? It will 
be super annoying in the future to have a growing bunch of black-box 
libraries without associated sources...


Regards,
Ed

On 13.01.2022 09:37, Christoph Läubrich wrote:
Eclipse Passage might choose to consume the log4j2 directly from 
maven and simply sign the artifact to comply with simrel rules as 
done here:


https://github.com/eclipse-m2e/m2e-core/blob/master/org.eclipse.m2e.site/pom.xml#L45 



This would bypass the 
OrbitChange>OrbitRelease>PassageChange>PassageRelease>RepeatHere 
cycle...


Am 13.01.22 um 09:31 schrieb Alexander Fedorov:

Hello,

Some hours ago I've found that Orbit still contributes the log4j 
vulnerability to the SimRel


Thanks to Jonah, the situation is better, now we have updated 
Orbit with log4j 2.15.0


But shouldn't we hold a train a bit to use the latest fix from 
Orbit that provides log4j 2.17.1?


Regards,
AF

12/18/2021 4:19 PM, Andrey Loskutov пишет:

After update is before update...

log4j has now 2.17.0.
https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105


Am 15. Dezember 2021 12:03:21 MEZ schrieb Alexander Fedorov 
:

Thank you, Andrey!

Just merged 
https://git.eclipse.org/r/c/orbit/orbit-recipes/+/188862

Will be working to provide Eclipse Passage 2.2.2 service release.

Regards,
AF

12/15/2021 1:38 PM, Andrey Loskutov пишет:

+1 from me.
The hype is too big.

Re-posting your message to collect more feedback regarding:
should we replace 2.15.0 with 2.16.0 in Orbit?

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


--
Kind regards,
Andrey Loskutov

https://www.eclipse.org/user/aloskutov
Спа

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

[Christoph Läubrich]

Hi Ed,


If that implies PGP signed content on the train


Nope, this will (res)sign the artifact with standard eclipse-jar signer.

m2e uses this approach to contribute bnd-lib to simrel what is from p2 
but without signature, the same works for artifacts of any source



BTW, when one chooses to do this "direct from Maven" thing, can one
also choose to create the source bundle/attachment for it?
It will be super annoying in the future to have a growing bunch of
black-box libraries without associated sources...


m2e+tycho support automatic source-bundle generation of associated 
source for maven items (see for example this screenshot[1]) when 
"Include Artifact Sources" is enabled.


[1] 
https://user-images.githubusercontent.com/1331477/139412713-e0218ff7-642c-4c19-afac-55fca49ef325.png


Am 13.01.22 um 09:42 schrieb Ed Merks:

Christoph,

If that implies PGP signed content on the train, then no, Eclipse 
Passage should not choose to do that at this time because PGP support is 
not yet ready for prime time, but we are working on that;


https://gitlab.eclipse.org/eclipse-wg/ide-wg/ide-wg.eclipse.org/-/issues/11

BTW, when one chooses to do this "direct from Maven" thing, can one also 
choose to create the source bundle/attachment for it?  It will be super 
annoying in the future to have a growing bunch of black-box libraries 
without associated sources...


Regards,
Ed

On 13.01.2022 09:37, Christoph Läubrich wrote:
Eclipse Passage might choose to consume the log4j2 directly from maven 
and simply sign the artifact to comply with simrel rules as done here:


https://github.com/eclipse-m2e/m2e-core/blob/master/org.eclipse.m2e.site/pom.xml#L45 



This would bypass the 
OrbitChange>OrbitRelease>PassageChange>PassageRelease>RepeatHere cycle...


Am 13.01.22 um 09:31 schrieb Alexander Fedorov:

Hello,

Some hours ago I've found that Orbit still contributes the log4j 
vulnerability to the SimRel


Thanks to Jonah, the situation is better, now we have updated Orbit 
with log4j 2.15.0


But shouldn't we hold a train a bit to use the latest fix from Orbit 
that provides log4j 2.17.1?


Regards,
AF

12/18/2021 4:19 PM, Andrey Loskutov пишет:

After update is before update...

log4j has now 2.17.0.
https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105


Am 15. Dezember 2021 12:03:21 MEZ schrieb Alexander Fedorov 
:

Thank you, Andrey!

Just merged https://git.eclipse.org/r/c/orbit/orbit-recipes/+/188862
Will be working to provide Eclipse Passage 2.2.2 service release.

Regards,
AF

12/15/2021 1:38 PM, Andrey Loskutov пишет:

+1 from me.
The hype is too big.

Re-posting your message to collect more feedback regarding:
should we replace 2.15.0 with 2.16.0 in Orbit?

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


--
Kind regards,
Andrey Loskutov

https://www.eclipse.org/user/aloskutov
Спасение утопающих - дело рук самих утопающих



___
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] [orbit-dev] log4j vulnerability in Eclipse: update to 2.16.0?

[Christoph Läubrich]

Eclipse Passage might choose to consume the log4j2 directly from maven 
and simply sign the artifact to comply with simrel rules as done here:


https://github.com/eclipse-m2e/m2e-core/blob/master/org.eclipse.m2e.site/pom.xml#L45

This would bypass the 
OrbitChange>OrbitRelease>PassageChange>PassageRelease>RepeatHere cycle...


Am 13.01.22 um 09:31 schrieb Alexander Fedorov:

Hello,

Some hours ago I've found that Orbit still contributes the log4j 
vulnerability to the SimRel


Thanks to Jonah, the situation is better, now we have updated Orbit with 
log4j 2.15.0


But shouldn't we hold a train a bit to use the latest fix from Orbit 
that provides log4j 2.17.1?


Regards,
AF

12/18/2021 4:19 PM, Andrey Loskutov пишет:

After update is before update...

log4j has now 2.17.0.
https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105


Am 15. Dezember 2021 12:03:21 MEZ schrieb Alexander Fedorov 
:

Thank you, Andrey!

Just merged https://git.eclipse.org/r/c/orbit/orbit-recipes/+/188862
Will be working to provide Eclipse Passage 2.2.2 service release.

Regards,
AF

12/15/2021 1:38 PM, Andrey Loskutov пишет:

+1 from me.
The hype is too big.

Re-posting your message to collect more feedback regarding:
should we replace 2.15.0 with 2.16.0 in Orbit?

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

--
Kind regards,
Andrey Loskutov

https://www.eclipse.org/user/aloskutov
Спасение утопающих - дело рук самих утопающих



___
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?

[Christoph Läubrich]

If an attacker has the ability to install an arbitrary bundle into your 
eclipse your are out of luck anyways


(I'm sure no one would ever click "Install Anyways" correct? ;-)

Am 15.12.21 um 10:27 schrieb Alexander Fedorov:
This weaving capability looks much more promising for attacker than JNDI 
from the initial topic.


Regards,
AF

12/15/2021 12:22 PM, Christoph Läubrich пишет:
And if you still think it is a good idea to patch *classes* you can do 
so using the "Weaving Hook Service Specification" [1].


With that you can replace the content of *any* class with something 
else (patched, throwing an exception, dynamic code replacement using 
javassist...).


[1] 
http://docs.osgi.org/specification/osgi.core/7.0.0/framework.weavinghooks.html 



Am 15.12.21 um 06:33 schrieb Ed Merks:

Ed,

I too thought maybe that would be possible via a fragment, but the 
bundle's classpath contributions come before each of its fragments 
classpath contributions so the bundle would have to be designed to 
allow a fragment to contribute something that would be processed 
before its own classes:


https://wiki.eclipse.org/FAQ_Can_fragments_be_used_to_patch_a_plug-in%3F

Regards,
Ed

On 14.12.2021 21:04, Ed Willink wrote:


Hi

Rather than remove and so change the existing log4j1 Orbit content, 
might it be easier to outwit the lazy load, by ensuring the the 
platform/p2 eagerly provides a spoof implementation of the unwanted 
class?


    Regards

        Ed Willink

On 14/12/2021 12:00, Jeanne, Federico wrote:


Ed,

thank you for the detailed analysis. I guess you’re right: 
determining the real exposure of each one of the plugins and 
features when it comes to such a central component like Log4J is 
really challenging.


The good thing though is that, like you already showed, the risk 
seems to be contained into only in 1 package (org.apache.log4j.net) 
and only a bunch of plugins seem to include a (non-greedy) 
dependency to that package. I like the idea of removing that 
package from future version of “org.apache.log4j” but I have to 
admin I can’t really assess what that actually means in terms of 
effort and consequences.


Anyway, I just wanted to use the momentum to try and dig a bit 
deeper and to preemptively search for similar issues that might 
arise in the future :)


Regards,

Federico

*From:*cross-project-issues-dev 
 *On Behalf Of *Ed Merks

*Sent:* Tuesday, December 14, 2021 10:36 AM
*To:* cross-project-issues-dev@eclipse.org
*Subject:* Re: [cross-project-issues-dev] [orbit-dev] log4j 
vulnerability in Eclipse?


Jeane,

The following is not saying your suggestion is a bad idea, but 
rather to clarify the nature of what we will need to say and do...


Eliminating the use of org.apache.log4j quickly seems unpromising 
at best.


At least superficially we might as well list all projects as affected.

Just looking at the first two dependencies:

And then following the dependencies of second of those:

We see that pretty close to the entire universe of Eclipse plugins 
is downstream from these.


And then, we don't know for a fact that anyone actually creates an 
org.apache.log4j.net.SocketServer...


Looking more closely at the nature of the dependencies though, it 
appears that org.apache.commons.logging only depends on the 
org.apache.log4j package:


And then it's only an optional, non-greedy dependency:

Nothing (on the release train) depends on the org.apache.log4j.net 
package where the offending class is located:


In the end, determining whether there is an actual risk rather than 
a hypothetical risk challenging at best.  I expect that everyone 
(and I do mean literally everyone using this bundle) is just doing 
this and has zero risk:


  private static final Logger log = 
Logger.getLogger(class);


Perhaps we could create a new version of org.apache.log4j that 
removes the org.apache.log4j.net.SocketServer class (or the entire 
package), as a crude quick fix, but even that would require some 
IUs to relax/modify their bounds:


This site suggests there is a 1.2.18 version of log4j though 
elsewhere it I saw a statement that the problem would not be fixed.


https://www.whitesourcesoftware.com/vulnerability-database/CVE-2019-17571 



Accurate information is hard to come by...

Regards,
Ed

On 14.12.2021 09:42, Jeanne, Federico wrote:

    Denis,

    good idea with the page, I think it brings a nice overview of
    what has been investigated and how deep the vulnerability reached.

    I couldn’t help noticing though that some of the listed projects
    mentioned using Log4j 1.2.15. Wouldn’t it also make sense to have
    another page to address the vulnerability CVE-2019-17571 (the one
    Jonah mentioned)?

    Regards,

    Federico

    *From:*cross-project-issues-dev
    
<mailto:cross-project-issues-dev-boun...@eclipse.org> *On Behalf
    Of *Denis Roy
    *Sent:* Monday, December 13, 2021 10:46 PM
    *To:* cross-project-issues-dev@eclipse.org
    *Su

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

[Christoph Läubrich]

ite what
the actual story is), I can
certainly post a blog post on the
blogs.eclipse.org
<http://blogs.eclipse.org>domain.
From there, we could tweet about
it from the official @EclipseFdn
twitter account, and perhaps add
links to the post from the
Newcomers forum.

Does that seem acceptable?

Denis

On 2021-12-13 13:44, Jonah Graham
wrote:

Thanks everyone for working
on this - I think we have a
pretty good story now about
what the Eclipse IDE / SimRel
has done for the log4j
vulnerability.

The last thing is to say so
in a concise way - where
can/should we say so (besides
this mailing list)?

Thanks,

Jonah

~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com
<http://www.kichwacoders.com>

On Mon, 13 Dec 2021 at 12:58,
Ed Merks mailto:ed.me...@gmail.com>>
wrote:

Christoph,

I really appreciate your
creative ideas.  I think
"we, i.e., as an I"
should indeed plan long
term for the possibility
of expedient mitigation
of such problems in the
future using this type of
approach.

For the project catalogs
I've regenerated them
such than installing any
version of the RCP
package (with any
installer) will install
the latest
version of Passage which
strictly requires the
updated/fix version of
org.apache.logging.log4j.
Also any
installer-created RCP
package
installation will ask to
update itself upon
startup/restart.


https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/commit/?id=929d140afc34ecdb85b7996c63ce0b36b6723a34

<https://git.eclipse.org/c/oomph/org.eclipse.oomph.git/commit/?id=929d140afc34ecdb85b7996c63ce0b36b6723a34>

Another thought I had is
that the donation support
I've added opens a
browser page.  In this
case we could change the
URL such that a page
with information about
this CVE could be
presented...

But now it's late in the
day and I'm done for now.

Regards,
Ed

       

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

[Christoph Läubrich]

 late in the
day and I'm done for now.

Regards,
    Ed

On 13.12.2021 18:03,
Christoph Läubrich wrote:
> Hi Ed,
>
> > One problem is we
don't know all the things
that strictly require the
> > older bundle.
>
> In the end what matters
is that the bundle is no
longer available. If
> we don't uninstall them
at laes they won't
resolve anymore and people
> will go to the project
website, report an issue
and/or install an
> update :-)
>
> > 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.
>
> yep that's what I have
had in mind, I think it
would be cool to have
> one global feature "CVE
Mitigation" or something
and this
> requires/includes
individual CVE features
that ship with appropriate
> p2.inf items.
> Thus way, once added to
an IDE this will enable
us to make CVE fixes
> available tor a broad
audience and make people
more aware of them
> through the update
capabilities of eclipse
itself.
>
> >> What do you think
does this sounds reasonable?
> > It's a creative
idea.  I like it.
>
> Good to hear! As you
probably know much more
about p2.inf magic than
> me can you craft such a
feature so we can
investigate this more? As
> mentioned before this
is more an idea so I
can't shar any concrete
> code samples yet and
have no idea where this
would bes be placed (part
> of the platform cbi?
github/gitlab project
under eclipse umbrella?
> eclipse cbi maybe?)
>
>
> Am 13.12.21 um 17:48
schrieb Ed Merks:

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

[Christoph Läubrich]

> However, I would vote for one feature per CVE, given 2
> reasons:

I just don't know if it is possible to present the user with a list of 
(new) CVE features to suggest  to install them.


I think one crucial part would be that the user is actively informed 
about new problems.


Anyways for sure we can add support for that in P2 and eclipse UI but 
that would require some code changes.


That's why I try to get creative how to archive something with existing 
codebase :-)


> I would expect that there is a chance of such a feature not being
> installable on some installations due to conflicting requirements.

Well that's actually the idea here, if there is a conflict P2 will 
suggest two solutions:


- uninstall the dangerous stuff and install the CVE mitigation
- do not install the CVE mitigation and keep the current installation

at least that's the theory ;-)

Am 15.12.21 um 07:52 schrieb Michael Keppler:

Am 13.12.2021 um 18:03 schrieb Christoph Läubrich:


yep that's what I have had in mind, I think it would be cool to have
one global feature "CVE Mitigation" or something and this
requires/includes individual CVE features that ship with appropriate
p2.inf items.
Thus way, once added to an IDE this will enable us to make CVE fixes
available tor a broad audience and make people more aware of them
through the update capabilities of eclipse itself.


Sounds great. However, I would vote for one feature per CVE, given 2
reasons:

Some companies are rather reluctant to change previously certified tool
chains, and might want to include fix A, but not fix B (because they can
explain why it does not affect them).

I would expect that there is a chance of such a feature not being
installable on some installations due to conflicting requirements. The
more CVEs (and requirements) included, the higher that chance. It would
be good if such conflict would not prohibit installing the other fixes.
I might be wrong about this item.

___
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?

[Christoph Läubrich]

Hi Ed,

> One problem is we don't know all the things that strictly require the
> older bundle.

In the end what matters is that the bundle is no longer available. If we 
don't uninstall them at laes they won't resolve anymore and people will 
go to the project website, report an issue and/or install an update :-)


> 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.

yep that's what I have had in mind, I think it would be cool to have one 
global feature "CVE Mitigation" or something and this requires/includes 
individual CVE features that ship with appropriate p2.inf items.
Thus way, once added to an IDE this will enable us to make CVE fixes 
available tor a broad audience and make people more aware of them 
through the update capabilities of eclipse itself.


>> What do you think does this sounds reasonable?
> It's a creative idea.  I like it.

Good to hear! As you probably know much more about p2.inf magic than me 
can you craft such a feature so we can investigate this more? As 
mentioned before this is more an idea so I can't shar any concrete code 
samples yet and have no idea where this would bes be placed (part of the 
platform cbi? github/gitlab project under eclipse umbrella? eclipse cbi 
maybe?)



Am 13.12.21 um 17:48 schrieb Ed Merks:

Christoph,

Comments below.

On 13.12.2021 17:29, Christoph Läubrich wrote:

Hi Ed,

I wonder if it would not be possible to publish a general purpose
"CVE mitigation" Updatesite everyone could add to an existing eclipse 
install.

Of course not everyone has Passage installed, nor this specific bundle...


Such an Updatesite could contain a Unit for a given CVE (e.g. 
CVE-2021-44228 in this case) that defines a negative requirement on 
any affected version (in this case any org.apache.logging.log4j with 
version range < 2.15).
Yes that's theoretically possible.  (And in the catalog I can easily do 
this, but not all installation are installed from the catalog.)


What will happen then is that P2 will give the user the choice to 
install this mitigation unit and uninstall
P2 generally wants to install features so such a thing would need to be 
packaged up as a feature...


a) the dangerous bundle
b) any dependent and affected unit (passage in this case)

from the current IDE.
One problem is we don't know all the things that strictly require the 
older bundle.  The parts of Passage contributed to the train only have 
lower bounds, but there are Passage features that include this bundle 
with an exact range...


Once an Update is in place, passage could be installed (e.g. with a 
separate update-site) again including a fixed version of the 
problematic dependecy.


Another question is what else out there that might already be installed 
depend on logging.log4j and would also need to be updated or 
uninstalled?  That's an open ended question...
Even though such a site would currently need some kind of handcrafted 
metadata, we could enhance this so we probably once have some 
automatic import of CVE from public databases and automatic 
notification of users about new CVE affecting their IDE.


Yes, such a thing will follow some pattern so generating such a thing 
would be good...
Including such a site in a target platform of a build could 
effectively fail the build (and make 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 Passag

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

[Christoph Läubrich]

Hi Jonah,

such a site could be part of a composite repository of course.

If we want to include it by default I think the EPP need to include at 
least one additional feature or we find a common feature to extend or 
there is some P2 magic I'm currently not aware to "promote" a new 
feature via the Update.


Given the attention this CVE gets (I even see some articles in our local 
newspaper about it) it might even be sufficient to promote it on the 
eclipse download site as a manual step instead.


In either case it should then be presented to the user via the "Check 
for Updates" but currently this is just an idea I came up with, when it 
is interesting I can try to craft a proof-of-concept or one of the 
P2/Tools experts (Ed?) came up with a solution based on that idea.


At least JustJ uses negative requirements to exclude certain IUs so this 
might serve as an inspiration here as well.


Am 13.12.21 um 17:39 schrieb Jonah Graham:

Hi Christoph,

That sounds reasonable to me and an interesting solution. Could SimRel 
include it as a sub/composite repo? Would adding it to the released 
composite repos cause the Check for Updates to remove (prompt to remove) 
the problematic jars?


Is that a p2 site you can craft for this issue? My p2 knowledge isn't 
sufficient for such a task.


Jonah



~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com <http://www.kichwacoders.com>


On Mon, 13 Dec 2021 at 11:30, Christoph Läubrich <mailto:lae...@laeubi-soft.de>> wrote:


Hi Ed,

I wonder if it would not be possible to publish a general purpose
"CVE mitigation" Updatesite everyone could add to an existing eclipse
install.

Such an Updatesite could contain a Unit for a given CVE (e.g.
CVE-2021-44228 in this case) that defines a negative requirement on any
affected version (in this case any org.apache.logging.log4j with
version
range < 2.15).

What will happen then is that P2 will give the user the choice to
install this mitigation unit and uninstall

a) the dangerous bundle
b) any dependent and affected unit (passage in this case)

from the current IDE.

Once an Update is in place, passage could be installed (e.g. with a
separate update-site) again including a fixed version of the
problematic
dependecy.

Even though such a site would currently need some kind of handcrafted
metadata, we could enhance this so we probably once have some automatic
import of CVE from public databases and automatic notification of users
about new CVE affecting their IDE.

Including such a site in a target platform of a build could effectively
fail the build (and make projects automatically aware of new problems)
as they arise, also preventing one from including problematic
dependencies in the future.

What do you think does this sounds reasonable?

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
<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
 

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

[Christoph Läubrich]

Hi Ed,

I wonder if it would not be possible to publish a general purpose
"CVE mitigation" Updatesite everyone could add to an existing eclipse 
install.


Such an Updatesite could contain a Unit for a given CVE (e.g. 
CVE-2021-44228 in this case) that defines a negative requirement on any 
affected version (in this case any org.apache.logging.log4j with version 
range < 2.15).


What will happen then is that P2 will give the user the choice to 
install this mitigation unit and uninstall


a) the dangerous bundle
b) any dependent and affected unit (passage in this case)

from the current IDE.

Once an Update is in place, passage could be installed (e.g. with a 
separate update-site) again including a fixed version of the problematic 
dependecy.


Even though such a site would currently need some kind of handcrafted 
metadata, we could enhance this so we probably once have some automatic 
import of CVE from public databases and automatic notification of users 
about new CVE affecting their IDE.


Including such a site in a target platform of a build could effectively 
fail the build (and make projects automatically aware of new problems) 
as they arise, also preventing one from including problematic 
dependencies in the future.


What do you think does this sounds reasonable?

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-09 (6 releases).




12/12/2021 12:41 PM, Ed Merks пишет:


Just to avoid any confusion such as that which Ed Willink mentioned, 
the https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228 
issue is specifically about the class 
org.apache.logging.log4j.core/lookup.JndiLookup.which is not in a 
package provided by org.apache.*log4j *but rather in a package 
provided by org.apache.*logging**.log4j *as illustrated here in a CBI 
p2 aggregator repo view:


Based on the analysis tool I've been developing for better managing 
SimRel, e.g., to provide traceability and dependency analysis, it's 
definitely the case that only Passage depends on this bundle:



Specifically via bundle requirements (as opposed to package 
requirements):



Those requirements have no upper bound, only an inclusive lower 
bound, such that they will resolve and use any higher version of 
org.apache.logging.log4j.  As such, installing Passage with 
https://download.eclipse.org/tools/orbit/downloads/drops2/I20211211225428/repository 
in the available sites and enabling to use those, does install the 
newer version:



The bad news 

Re: [cross-project-issues-dev] Serious problems with the new Maven POM XML editor

[Christoph Läubrich]

Link is https://github.com/eclipse-m2e/m2e-core/issues/441

Related issues:
 https://github.com/eclipse/lemminx-maven/issues/232
 https://github.com/eclipse/lemminx-maven/issues/233

Am 10.12.21 um 15:13 schrieb Denis Roy:

Please also link the bug number here so we can also follow along.

Thanks

Denis

On 2021-12-10 04:38, Andrey Loskutov wrote:

Hi Lorenzo,

Sounds really scary.
Please create a bug for m2e, we should continue investigation on that bug ASAP.

Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov



___
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] download.eclipse.org unavailable

[Christoph Läubrich]

Thanks Ed for the detailed time-line. I also can confirm that (from the 
point of a simple comitter POV) the outage was not over at Aug 2 (maybe 
for me 'core services' are just others than from the infra-POV) but has 
last far to 4 Aug and I could continue the work on my issues.


So for me the summary "The outage was extensive, and for core services, 
lasted for approximately 18 hours. Non-core services were degraded for 
an additional 12 hours." does not feels quite right but as said before I 
can't 'proof' that, its jsut that actually I was only able to resume my 
work at Aug 4 (120hrs later!) at laest until the tycho-ci server was 
restarted ...


so for me it seems a check "are all build servers running and have 
executors" is missing from the status page.


Am 13.08.21 um 15:22 schrieb Ed Willink:

Hi

Thank you all for hitting problems quite quickly once you were engaged. 
Perhaps this 'bystander's' perspective may help to understand the need 
to communicate better.


I first became aware of the problem after receiving notification a 
little after 2:42 EDT 1-Aug that a weekly OCL rebuild had failed. 
Investigation of the log pointed a finger at the GIT repo and 
eclipsestatus.io indicated that a major outage was in progress with an 
'investigating' tweet. Clearly someone was on the case and so the 
bystander effect took over and I didn't raise any reports or emails to 
distract.


'investigating' status advanced to 'fix-in-progress' after an hour.

But then nothing for a further 5 hours, at which point we got 'it will 
take 13 hours'. On twitter someone asked when the 13 hours started; one 
might have hoped that it would be from the 'fix-in-progress' time. This 
tweet and an 'ETA?' tweet were never answered.


17 hours later we got 'most websites' back, which might be true but with 
important  services down, it was misleading. It took a further perhaps 4 
hours forhttps://download.eclipse.org/tools/orbit/downloads/latest-I 
 to return, 
and 50 hours before projects-storage.eclipse.org 
 was back and another 
couple of hours to get /shared/common/apache-ant-latest/bin/ant back.


IMHO the outage lasted until at least the restoration of 
projects-storage.eclipse.org 
 at Aug 4 8:50 and so 
one of the issues to be addressed by the postmortem must be why the 
status page still reports no incidents or outage on the whole of the 3rd 
Aug when, for committers at least, there was no useable service all day.


I must thank the team again for their hard work with a very difficult 
problem, but must also stress that the communication was very poor. So 
much so that at 3:07 EDT on 4th Aug I sent a private email to Ed Merks 
speculating that:


/The total silence from the team is now way beyond 
incompetence/discourtesy/embarrassment; there must be another reason. //


//Paranoia sets in. //

//Is some government / hostile agency intervening to prevent 
communication? //


//Are the team voluntarily maintaining silence to contain a security 
issue? /


Please ensure that whenever possible the status updates are much more 
informative.


     Regards

         Ed Willink


On 09/08/2021 21:45, Denis Roy wrote:


I very much appreciate the sympathy and the support. In the end, the 
Infra team can do better than this.  We'll lick our wounds and go back 
to the drawing board to make sure we don't repeat the same mistakes twice.


Postmortem is written, pending review with my team.



Denis




 
	Virus-free. www.avast.com 
 



<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

___
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] download.eclipse.org unavailable

[Christoph Läubrich]

> but I guess there is still a major problem with eclipse.org 
infrastructure.


It would be good to have at least some more information, the status page 
says 'A fix has been implemented and we are monitoring the results' but 
this is two days old and still we see massive outages, updatesites are 
broken, CI builds are even not running, we get bug reports about broken 
functionality, that's really annoying and frustrating.


Am 03.08.21 um 18:17 schrieb Andrey Loskutov:

See https://www.eclipsestatus.io/

Some basic website functionality seem to be restored, but mailing lists / 
message sending seem to be still broken across different services.
I received few random (I guess not all) mails from bugzilla, but I guess there 
is still a major problem with eclipse.org infrastructure.


Am 2. August 2021 14:02:03 MESZ schrieb Laurent Goubet :

Hello,

All builds we started this morning (5 hours ago CEST) have failed with
issues trying to reach download.eclipse.org in one way or another, two
examples of which are:

- |Caused by: java.io.FileNotFoundException:
https://download.eclipse.org/releases/2019-09/compositeContent.jar|
-|||java.io.FileNotFoundException: Neither
https://download.eclipse.org/tools/orbit/downloads/drops/R20190602212107/repository/compositeContent.jar
nor
https://download.eclipse.org/tools/orbit/downloads/drops/R20190602212107/repository/compositeContent.xml|

When we tried to access these repositories through a browser, we
initially got a 403 error.
|https://download.eclipse.org/releases/2019-09| now seems to partially
load (all icons are broken) but
|https://download.eclipse.org/tools/orbit/downloads/drops/R20190602212107/repository
|still gives us a 403.

Could we get any status update on the issue and upcoming fix?

Regards,



--
Kind regards,
Andrey Loskutov

https://www.eclipse.org/user/aloskutov
Спасение утопающих - дело рук самих утопающих
___
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] Mylyn

[Christoph Läubrich]

> Where we stand today is that due to the JIPP migration,
> Mylyn cannot release.

Is there a ticket describing whats the problem with JIPP migration? Even 
though there might be none actively managing the project there might be 
people/projects depending on Mylin to help out on fixing some issues to 
keep it working!


e.g. if its just a matter of migration the build to a Jenkinsfile or 
something similar I might can help out here (and others as well) to fix 
that issue.



Am 21.05.21 um 22:13 schrieb Sam Davis:

From: *Mik Kersten* mailto:m...@tasktop.com>>
Date: Fri, May 21, 2021 at 10:34 AM
Subject: Mylyn
To: >

Cc: Sam Davis mailto:sam.da...@tasktop.com>>


I wanted to give the group a heads up that there are issues with Mylyn 
that could affect the simultaneous release.


For context, Mylyn (originally Mylar) was a passion and PhD project of 
mine that has been a part of the Eclipse ecosystem for 15 years now.  It 
has lived a good and full product lifecycle, and for the past few years, 
neither I nor the other staff at Tasktop who have been contributing once 
my role transitioned have been able to put enough time into to provide 
adequate support for inclusion in the simultaneous release.  Back in 
December, Sam Davis pushed a review to pull Mylyn out of the 
Simultaneous release, but that did not happen due to dependencies, and 
there wasn’t follow up on the corresponding communication so it has not 
yet happened.


Where we stand today is that due to the JIPP migration, Mylyn cannot 
release. This puts the SimRel at risk of being blocked. Given that the 
Mylyn project lacks the resources to address this, so we would like to 
remove Mylyn from the SimRel. This will require other projects, EPP 
packages, and Oomph to remove their dependencies on Mylyn unless there 
are other parties who could contribute the resources to make this happen.


If anyone is interested in taking this on, Sam and I would be more than 
happy to pass on the reins!


Assuming that does not happen, we think that it would be in everyone's 
interest to deal with this now, before it becomes urgent. Please reply 
to this thread if your project depends on Mylyn. This includes Mylyn 
Tasks/Context/Commons/Builds/Reviews/Versions, but not Mylyn Docs/Wikitext.


And on a more personal note, I have very fond memories of being a close 
part of the Eclipse ecosystem.  It is great to see it continuing, I miss 
interacting the many people who were collaborators over the years, and 
hope everyone is doing well and that we cross paths at some conference 
or other in 2022!


Best,

Mik

--
Dr. Mik Kersten
CEO https://tasktop.com 
Author https://projecttoproduct.org 





___
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

[Christoph Läubrich]

Jetty is open-source so why not contribute something so they are 
convinced to add P2 support again?


Also of course one can ask Orbit to add those bundles...

Am 13.04.21 um 17:24 schrieb Nitin Dahyabhai:
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.


--
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


___
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

[Christoph Läubrich]

I think Alexander might give some insight if there are other 
alternatives, but if you are using recent tycho + recent eclipse you can 
simply copy the "locations" from this file:


https://git.eclipse.org/r/c/platform/eclipse.platform.releng.buildtools/+/176736/17/jetty.repository/jetty.target

into your target and have the jetty ones available.

Mickael also has written a tool to create a P2 site that mirrors Maven 
deps, so if such a thing is available it is just a matter of uploading 
it to some web-server or reference it via file:/... somewhere.



Am 13.04.21 um 08:56 schrieb Ed Merks:

Markus,

Apparently this is not trivial.  It looks like for 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=569804 the following was 
added during the move to 10.x:


https://git.eclipse.org/r/c/platform/eclipse.platform.releng.buildtools/+/176736

That provides a new project:

https://git.eclipse.org/c/platform/eclipse.platform.releng.buildtools.git/tree/jetty.repository

Apparently that helps provide the Jetty dependencies.  It seems to me 
infeasible though for all the downstream projects that also depend on 
Jetty to replicate all this infrastructure.  Surely there should just be 
a Jetty 10.x p2 repository we can all reuse...


On a related note, I've tried to get the attention of someone human 
being on https://bugs.eclipse.org/bugs/show_bug.cgi?id=572026 also 
because of a Jetty problem, but it seems no human being cares to respond.


Regards,
Ed

On 13.04.2021 08:31, Markus Knauer wrote:
I started yesterday to look into this, unfortunately it'll take some 
time...


We used to consume Jetty from their 9.x p2 repositories, but with 10.x 
this is not possible any more.


Eclipse Platform Team, how are you consuming the Jetty bundles now?
That'll help us solve it on our side in the same way.

Thanks
Markus

On Fri, 9 Apr 2021 at 18:14, Kit Lo > wrote:


During Eclipse Platform 4.20 M1 contribution, we noticed conflicts
with RAP Tools and new version of Jetty.

Requesting RAP Tools development team to take a look and re-enable
RAP Tools contribution when the problem is resolved.

Regards,
Kit Lo
Eclipse Babel Project Lead
IBM Eclipse SDK (IES) Technical Lead and Release Manager



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To 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 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] Restricting bugzilla issues creation/edition?

[Christoph Läubrich]

I don't know if it is possible in Buzilla but Github support "issue 
templates" (that is some predefined text is filled when creating a new bug).


If that also possible with Bugzilla one could simply put the info that 
Github should be used as the default text if someone tries to open a new 
report including a link to Github issues.


Am 19.03.21 um 09:42 schrieb Mickael Istria:

Hi all,

I'm brainstorming about how to have a complete the migration to GitHub 
for some projects (eg m2e, Tycho...). Currently, the main pain point 
would be the bug tracker: the backlog on Bugzilla is huge and migrating 
it to GitHub wouldn't be very relevant, but this backlog needs to remain 
accessible.
One approach would be to make the BZ tracker progressively "read-only", 
or at least to prevent from creating new issues.
For a given product, is it possible to prevent creation of new issues? 
Is it possible to block creation of issues while keeping edition access 
on existing issues? Is it possible to make the product issues 
"read-only" (no creation, no edition)?
My favorite one at the moment would be to block creation of new issues 
but still allow edition.


Thanks in advance for your insights.

--
Mickael Istria
Eclipse IDE  
developer, for Red Hat Developers 


___
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] 'latest': yeah! how about 'next'

[Christoph Läubrich]

probably "upcomming" or "integration" would better suits as a name...

Am 03.02.21 um 15:15 schrieb Wim Jongman:

Hi,

I am super happy with the creation of all the 'latest' links. This makes 
life very easy for all of us who have to maintain builds and target 
platform definitions. Thank you!! It is great.


https://download.eclipse.org/eclipse/updates/latest 

https://download.eclipse.org/releases/latest 

https://help.eclipse.org/latest/index.jsp 

https://download.eclipse.org/tools/orbit/downloads/latest-I/ 


etc..

We always also have a target platform for the upcoming release (to make 
sure that we are still fine using internal and deprecated API [1] ;)


For platform, we can use /I-Builds and this is, of course, fine but all 
repos have their specific "next" endpoint e.g. snapshot, nightly, 
ibuilds, etc..

How about creating a 'next' alias best practice?

Cheers,

Wim


[1] a donkey may not be very wise but it rarely bumps the same stone twice










___
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] Using maven artifacts directly in eclipse target platform / tycho builds

[Christoph Läubrich]

Happy new year everyone,

I'd like to introduce a new feature in m2e / Tycho that supports the 
seaming-less integration for maven artifacts (OSGi and even non OSGi 
ones) to be used both in Eclipse IDE and Tycho Maven build.


This consists of two complementary features, a m2e extension for PDE 
that allows the adding/editing of a new target location type "Maven" and 
support for this location type in Tycho itself.


I have written a more detailed description in the following article [1].

I'd like to get some feedback so let me know if something is missing or 
bugs you encountered either via mailing-list, by directly contacting me 
or simply open a bug/enhancement in the m2e bugtracker [2], also please 
let me know if you think the article itself needs some deeper 
description of a given aspect of the new feature!



best regards
 Christoph

[1] 
https://xn--lubisoft-0za.gmbh/en/articles/using-maven-artifacts-in-pde-rcp-and-tycho-builds/

[2] https://bugs.eclipse.org/bugs/enter_bug.cgi?product=m2e
___
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] Who decided to override my Java installation with JustJ?

[Christoph Läubrich]

@Gunnar, @Ed

thanks for the hints and workarounds, I just found that this example 
best reproduces the original issue described here and maybe give some 
pointers what might be wrong (or needs adjustments)?


I think whatever causing this its almost always undesirable that justj 
is pulled in without explicit user request. New releases always produce 
a lot of traffic if we higher this traffic even more by downloading 
unnecessary new java version this will frustrate user soon due to long 
download times.


And even though it can

Am 17.12.20 um 10:41 schrieb Ed Merks:

You can point at this instead:

https://download.eclipse.org/releases/2020-12/202012161000/

Or at this:

http://download.eclipse.org/eclipse/updates/4.18/R-4.18-202012021800

I.e., don't point at EPP if you don't EPP's IUs.

If the problem is caused by fake p2 a.java.javase IUs missing package 
exports that are imported/used by JDT, then I don't think anyone has 
tried to fix those (which would be hard because it would need to be a 
new IU with a different version number).



On 17.12.2020 10:13, Christoph Läubrich wrote:

Is there any progress on this?

I noticed that even when using for example [1] in a target it 
downloads the full java 15 jre (>100mb) what is taking ages (eclipse 
servers are currently serving this with 16 to 32kb/s) to resolve 
target definition now.


Even worse, if one builds for multiple targets justj is downloaded for 
each target platform (e.g. linux, mac, windows) wasting a lot of 
bandwith, disk space and time...



includeMode="planner" includeSource="true" type="InstallableUnit">

 https://download.eclipse.org/releases/2020-12/"/>
 


Am 22.10.20 um 14:44 schrieb Greg Watson:

Thanks Ed, that helped. Hopefully this will be fixed soon.

Regards,
Greg


On Oct 15, 2020, at 10:17 AM, Ed Merks  wrote:

Greg,

I don't think anyone has figured out why a JRE is automatically 
installed during update:


   https://bugs.eclipse.org/bugs/show_bug.cgi?id=567504

You can undo this effect just by removing the -vm argument (to end 
up with the default) or by changing the -vm argument to the one you 
want it to use, in your eclipse.ini.


It's liable to come back if there is an unexpected updated to the 
JRE in the future...


Regards,
Ed


On 15.10.2020 15:11, Greg Watson wrote:
My Eclipse installation recently prompted me to upgrade (something 
new), so I accepted the advice. Now I’ve discovered that an unknown 
JRE was downloaded onto my machine and is being used to run 
Eclipse. This is broken on so many levels, I don’t even know where 
to start opening bug reports.


Since when does Eclipse start installing unauthorized versions of 
the JRE onto my machine without any notification, and that 
overrides my choice of the JRE (or JDK in my case) for running 
Eclipse? Not only is there no option to change or uninstall this, 
it breaks tools that rely on the JDK (e.g. Spring Boot Live hovers.)


Does anybody else see the problem here? Someone needs to rethink 
this kind of behavior.


In the mean time, does anyone know how to undo this mess, or am I 
forced to go back to 2020-06?


Regards,
Greg

___
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] Who decided to override my Java installation with JustJ?

[Christoph Läubrich]

Is there any progress on this?

I noticed that even when using for example [1] in a target it downloads 
the full java 15 jre (>100mb) what is taking ages (eclipse servers are 
currently serving this with 16 to 32kb/s) to resolve target definition now.


Even worse, if one builds for multiple targets justj is downloaded for 
each target platform (e.g. linux, mac, windows) wasting a lot of 
bandwith, disk space and time...



includeMode="planner" includeSource="true" type="InstallableUnit">

 https://download.eclipse.org/releases/2020-12/"/>
 


Am 22.10.20 um 14:44 schrieb Greg Watson:

Thanks Ed, that helped. Hopefully this will be fixed soon.

Regards,
Greg


On Oct 15, 2020, at 10:17 AM, Ed Merks  wrote:

Greg,

I don't think anyone has figured out why a JRE is automatically installed 
during update:

   https://bugs.eclipse.org/bugs/show_bug.cgi?id=567504

You can undo this effect just by removing the -vm argument (to end up with the 
default) or by changing the -vm argument to the one you want it to use, in your 
eclipse.ini.

It's liable to come back if there is an unexpected updated to the JRE in the 
future...

Regards,
Ed


On 15.10.2020 15:11, Greg Watson wrote:

My Eclipse installation recently prompted me to upgrade (something new), so I 
accepted the advice. Now I’ve discovered that an unknown JRE was downloaded 
onto my machine and is being used to run Eclipse. This is broken on so many 
levels, I don’t even know where to start opening bug reports.

Since when does Eclipse start installing unauthorized versions of the JRE onto 
my machine without any notification, and that overrides my choice of the JRE 
(or JDK in my case) for running Eclipse? Not only is there no option to change 
or uninstall this, it breaks tools that rely on the JDK (e.g. Spring Boot Live 
hovers.)

Does anybody else see the problem here? Someone needs to rethink this kind of 
behavior.

In the mean time, does anyone know how to undo this mess, or am I forced to go 
back to 2020-06?

Regards,
Greg

___
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] Building SimRel with Tycho for 2021-03

[Christoph Läubrich]

> Fix version will fix the version of the features in category.xml
> according to p2 repos. Eg for each feature in category.xml, it would
> verify the feature for the given version is available in the p2 repos
> (target platform), and if not, it would suggest a change to make.

So it does not really fix anything in the file itself? I could then 
think about an addition to tycho that might be useful in general as well:


Currently, if tycho can't resolve it simply fails with: "can't resolve 
because missing requirement XYZ and so on"


It would be really useful (and might solve the issue for simrel also) if 
we can add some pice of code that emits if there is an alternative 
version or no version at all for the missing requirement, eclipse (or 
P2?) even computes "alternative solutions", maybe this feature can be 
reused to give the required hints.


The the simrel validation will fail with a message suggesting the right 
versions to use in category.xml



Am 11.11.20 um 09:29 schrieb Mickael Istria:



On Wed, Nov 11, 2020 at 9:00 AM Christoph Läubrich 
mailto:lae...@laeubi-soft.de>> wrote:


As I'm currently working on category.xml adding support for source
features/bundles if someone can explain what exactly this "fix
versions"
does I can investigate if it is possible to be added to tycho.


Fix version will fix the version of the features in category.xml 
according to p2 repos. Eg for each feature in category.xml, it would 
verify the feature for the given version is available in the p2 repos 
(target platform), and if not, it would suggest a change to make.
This is similar and a slight variation of 
https://github.com/jbosstools/jbosstools-maven-plugins/blob/master/tycho-plugins/target-platform-utils/src/main/java/org/jboss/tools/tycho/targets/FixVersionsMojo.java 
<https://github.com/jbosstools/jbosstools-maven-plugins/blob/master/tycho-plugins/target-platform-utils/src/main/java/org/jboss/tools/tycho/targets/FixVersionsMojo.java> 
which enables some similar feature for .target file (however it also 
replaced 0.0.0, which is not desired here); so it's technically totally 
doable.


Tycho has already a version-updater for bundles/features so one for
category.xml seems valid for me.


It's a bit different, as it's about fixing the content of the file. Not 
sure we're talking about the same thing here.


Another area I'm currently investigating is creating an update-site of
everything in the current reactor build so category.xml is generated
automatically, not sure if this is applicable/useful for simrel as well.


Nope, SimRel just takes as input the p2 repos and a category.xml to 
create a new p2 repo aggregating content. There is nothing else built in 
the same reactor.


___
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] Building SimRel with Tycho for 2021-03

[Christoph Läubrich]

> There is no such tool for Tycho/category.xml

As I'm currently working on category.xml adding support for source 
features/bundles if someone can explain what exactly this "fix versions" 
does I can investigate if it is possible to be added to tycho.


Tycho has already a version-updater for bundles/features so one for 
category.xml seems valid for me.


Another area I'm currently investigating is creating an update-site of 
everything in the current reactor build so category.xml is generated 
automatically, not sure if this is applicable/useful for simrel as well.


> pom.xml / update URLs

Maybe it would be better to collect the URLs in a target definition file 
as it is more flexible (you can choose what features/versions to 
include) and has IDE Editing support?



Am 11.11.20 um 08:48 schrieb Mickael Istria:

Hello Jonah,

Thanks for having a look, answer inline


On Tue, Nov 10, 2020 at 5:21 PM Jonah Graham > wrote:


   1. Merge conflicts - this is probably not such a big deal as the
tycho validation seems very fast (2 minutes!).


I think the case of merge conflicts are almost non-existent for SimRel: 
projects typically modify a few lines, or add a few lines, which are 
independent from others. Git or even plain diff would be able to merge 
the various change without pain.


   2. Tracking who is paying attention. Until now the rule was touch
the .aggrcon file, which then was easy to identify with git log. Is
this rule important going forward? I believe so, and if so can we
agree on a simple standard for what this looks like? e.g. The 
of the repository in the pom.xml should have the simrel version that
it was contributed for in the id?


We can indeed set up some new convention in the pom.xml file, either 
with id, or with some comment convention such as  to be replaced by  and make 
the inactive contribution tool report the url of repo for which is just 
after a "Not there yet" line.


- Updating version number ranges. The b3 aggregator has a very
useful "fix versions" action that can set all the version ranges
quickly and accurately. Is there some way to make this easier with
Tycho?


There is no such tool for Tycho/category.xml at the moment; and I think 
it's mostly a use-case that is related by some existing PDE and m2e 
(requiring a lot of work though). One alternative would be to implement 
a SimRel/Tycho specific tool; that would be more affordable. I'll 
investigate about it.


- The gerrit today only has a subset of the parts of CDT that are in
simrel.aggr/cdt.aggrcom (the only contribution I looked at closely).
AFAICT only the items that are categorized are present in
category.xml. Where do uncategorized features end up? Similar
question about uncategorized bundles. I could add them all to a new
category if needed.


That seems like a bug in the routine that turns the .aggr model to a 
category.xml/pom.xml pair. I'll fix it.


___
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] (Mirror) security

[Christoph Läubrich]

Ed is right that Java/OSGi can check signatures and put several 
restrictions based on this (e.g allow to consume/provide services and 
such), but this assumes a closed/secured runtime.


If the runtime itself can be modified you are completely out of luck (as 
one the simply can disable the check), and even if there is an unknown 
signature and eclipse warns/ask if you trust them I suspect 99% of the 
users to click the "install anyways" button ...


Am 25.09.20 um 10:10 schrieb Ed Merks:

Denis,

If one has a rogue running process that can write arbitrarily to your 
file system (or parts thereof), it could tamper *anything*, so it would 
seem that at that point you would have arbitrary security risks even 
without an Eclipse IDE.  Even Windows doesn't prevent a tampered or 
unsigned executable from running.  I don't think that Linux even has 
signed executables, given there is no signing of such things in the 
Tycho builds.


Looking at this search:

https://www.google.com/search?q=java+run+only+signed+jars

and at answers like these:

https://stackoverflow.com/questions/54011270/allow-a-jar-to-run-only-if-it-is-signed
https://stackoverflow.com/questions/34641305/is-it-possible-to-force-jvm-to-check-that-every-jar-must-be-signed

suggests that it's not really so feasible to prevent Java from running 
unsigned jars, though I expect from Thomas' answer that OSGi can do 
verification with its specialized class loader (though presumably that 
has a performance impact).


Running Java with a security manager enabled for the purpose of running 
an IDE I think makes zero sense, so generally the IDE can do anything 
and can itself be a rogue process (if and when the user installs 
arbitrary things from the marketplace).


Even if the jars are verified, I can still personally think of a number 
of ways that I could tamper data files used by the IDE that would make 
the IDE "do bad things".  I'll not outline the possible ways that I can 
think of...  :-P


I think a fundamental aspect (assumption?) of security is that the 
machine itself is secure, sufficiently so that a process that does rogue 
things never runs in the first place.  Verifying signatures and 
checksums ensures that only known content is downloaded and installed in 
order to keep the machine secure.


Regards,
Ed

On 24.09.2020 19:53, Denis Roy wrote:


So it's possible for another process to tamper with jars and have 
Eclipse run them blindly.


Do we know if that is industry practice?



On 2020-09-24 12:07 p.m., Thomas Watson wrote:
Yes, p2 verifies the signatures and content of the JARs to confirm it 
hasn't been tampered with before installing the JAR.  At runtime the 
verification of JARs is not enabled by default.  Otherwise what you 
did would have resulted in a runtime exception for the class you changed.


Tom

- Original message -
From: Wim Jongman 
Sent by: cross-project-issues-dev-boun...@eclipse.org
To: Cross project issues 
Cc:
Subject: [EXTERNAL] [cross-project-issues-dev] (Mirror) security
Date: Thu, Sep 24, 2020 10:18 AM

Hi,
This is probably a silly question but I was wondering how we
protect the content of jar files as they are being pulled from
mirrors all over the world.
Due to a recent break in the Platform class, I compiled my own
version of the Platform class where I re-added the removed
method. Then I replaced it in the plugins/o.e.c.runtime jar using
7-zip.
This solved my issue but it also made me wonder how this was
protected if some mirror-server user used the same hack to dope
our jars.
I assume this is being done by p2 when downloading the jar files
by comparing some MDA hash?
Please enlighten me.
Cheers,
Wim
___
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, 
visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

--

*Denis Roy*

*Director, IT Services | **Eclipse Foundation, Inc.*

/Eclipse Foundation/ /: The Platform 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, 
visithttps://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

Re: [cross-project-issues-dev] Infrastructure Problems?

[Christoph Läubrich]

Same here...

Am 05.09.20 um 07:21 schrieb Christian Dietrich:

for me bugzilla shows

undef error - DBD::mysql::st execute failed: Disk full 
(/ramdisk/#sql_51e6_0.MAI);


Am 05.09.20 um 07:19 schrieb Ed Merks:

Hi,

There is a problem with most of the forum feeds so I can't read forums 
on Thunderbird.  They don't validate:


https://validator.w3.org/feed/check.cgi?url=https%3A%2F%2Fwww.eclipse.org%2Fforums%2Ffeed.php%3Fmode%3Dm%26l%3D1%26basic%3D1%26frm%3D48%26n%3D500%26format%3Drss 



I opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=566695 but if I 
open that bug in a new tab, I get the error:


   You must enter a valid bug number!

   Please press *Back* and try again.

Perhaps both problems are related.

Regards,
Ed



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


--
Christian Dietrich (Diplom-Informatiker (BA))
Softwareentwickler / -Architekt
Committer and Co-Lead for Eclipse Xtext

Tel.: +49 (0) 711 / 34 21 91-0
Fax.: +49 (0) 711 / 34 21 91-29
Mobil: +49 (0) 151 / 173969 17
Mail:christian.dietr...@itemis.de
XING:https://www.xing.com/profile/Christian_Dietrich8
Web:http://www.itemis.de
Skype: christiandietrich1982
ICQ: 125801794

itemis AG
Niederlassung Süd
Industriestraße 6
70565 Stuttgart

Rechtlicher Hinweis:
Registergericht: Amtsgericht Dortmund HRB 20621 | Sitz der Gesellschaft: Lünen
Vorstand: Jens Wagener (Vorsitzender) | Wolfgang Neuhaus | Abdelghani El Kacimi
Aufsichtsrat: Prof. Dr. Burkhard Igel (Vors.) | Michael Neuhaus |  Stephan 
Grollmann


___
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] SWT based 3D plot library?

[Christoph Läubrich]

As 3D is always a little bit messy to integrate in SWT I think the only 
option would be to get jzy3d, report bugs and help to improve when 
possible the SWT integration.


As jz3d uses JOGL and JOGL is one of the frameworks that could be used 
with STW OpenGL it should be at least possible to integrate it natively.


At least for me that would the the most promising option beside waiting 
until someone fires up the perfect charting lib for me :-)


Am 21.08.20 um 15:12 schrieb Andrey Loskutov:

I "for SWT" not menas "exclusivly for SWT" like in SWTChart, you can
take a look at http://www.jzy3d.org/


Thanks,

this was on my radar, but I fear this can only be used via SWT_AWT bridge, and 
so this would be a no go for me (SWT_AWT is extremely dangerous and crashes / 
deadlocks on GTK3 as much as it only can). See 
https://github.com/jzy3d/jzy3d-api/blob/master/jzy3d-swt/src/main/java/org/jzy3d/bridge/swt/Bridge.java.

Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov
___
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] SWT based 3D plot library?

[Christoph Läubrich]

I "for SWT" not menas "exclusivly for SWT" like in SWTChart, you can 
take a look at http://www.jzy3d.org/


From the docs:
--
Relying on JOGL 2, you can easily deploy native OpenGL charts on 
Windows, Unix, MacOs and integrate into Swing, AWT, SWT or JavaFX. 
Various contributions have also made Jzy3d available for other 
languages/platforms such as Scala, Groovy, Matlab, C#.


Am 21.08.20 um 13:56 schrieb Andrey Loskutov:

Hi all,

I was asked about a possibility to render 3D plot in "SWT native" code, but to 
my surprise I couldn't find a good answer.

I'm aware about swtchart 2D charts (works just fine for 2D), but I can't 
immediately find any 3D plot library for SWT.

There are few projects in Eclipse that provide 3D charts, but it looks to me, 
they are all dead or at least inactive for a very long time.

GEF3D (https://wiki.eclipse.org/GEF3D_Installation) would be a candidate, but 
this seem to be dead (I see no changes since 2012, see 
https://git.eclipse.org/c/gef3d/org.eclipse.gef3d.git/), so I would probably 
not really recommend that.

I see ICE project (https://wiki.eclipse.org/ICE , https://github.com/eclipse/ice), but 
ICE seem to be inactive too, "only" for 3 years.
Next I also see 
https://projects.eclipse.org/proposals/eclipse-advanced-visualization-project 
proposal (code at https://github.com/eclipse/eavp), again, inactive for 3 
years??

Is there any *active* project that provides 3D plots for SWT?

Kind regards,
Andrey Loskutov

Спасение утопающих - дело рук самих утопающих

https://www.eclipse.org/user/aloskutov

___
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] feature dependency version incompatibility

[Christoph Läubrich]

You should still be able to install both features without a problem.

Am 13.06.20 um 18:45 schrieb Homer, Tony:

Thanks for responding, Christoph.

I think I got your point about sensible version ranges, but as you mentioned 
the features define strict versions.  Conflicting might be the wrong word to 
use, but the point is that some features specify javax.annotation 
1.3.5.qualifier while others specify javax.annotation 1.2.0.qualifier, so AFAIK 
these features have conflicting dependency requirements and cannot be installed 
at the same time.  I was hoping someone would tell me that I am mistaken about 
this (

Tony

On 6/12/20 , 11:06 PM, "cross-project-issues-dev-boun...@eclipse.org on behalf of 
Christoph Läubrich"  wrote:

 Was is selected in the future depends on the version available at build
 time.
 If a never version at runtime is used/allowed depends on the imports in
 the Bundle itself.

 So if proper imports and use clauses are defined it could be that all
 works fine even with different (why they are conflicting?) versions.

 In a perfect world, all bundles would use import package with the lower
 bound of the lowest working version (e.g.  1.2.0) and an upper bound of
 2.0.0 then it would be possible to upgrade up until the next major release.

 The problem is, that features does not support version ranges and thus
 will still reference the version from the build (or the one forced into
 the feature.xml).
 Am 13.06.20 um 07:56 schrieb Homer, Tony:
 > Some 2020-06 features now require javax.annotation 1.3.5 (Jersey Common
 > from Orbit and bundles that depend on it such as Linux Tools Docker)
 > while others (such as org.eclipse.e4.rcp) still require javax.annotation
 > 1.2.0.
 >
 > 
https://download.eclipse.org/tools/orbit/downloads/drops2/R20200529191137/repository/plugins/org.glassfish.jersey.core.jersey-common_2.30.1.v20200513-1859.jar
 >
 > 
http://download.eclipse.org/releases/2020-06/202006171000/features/org.eclipse.linuxtools.docker.feature_4.7.0.202006092019.jar
 >
 > 
http://download.eclipse.org/releases/2020-06/202006171000/features/org.eclipse.e4.rcp_4.16.0.v20200604-0951.jar
 >
 > Is it possible to reconcile these dependency chains without rebuilding
 > the features, so that an eclipse application can use several of these
 > conflicting features from SimRel 2020-06?  As far as I know it is not,
 > but I’d love to learn that I am wrong.
 >
 > e4.rcp does not seem to have any version restriction defined (0.0.0).
 >
 > 
https://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/features/org.eclipse.e4.rcp/feature.xml#n150
 >
 > e4.rcp is resolving javax.annotation from the updates repo at build
 > time, which provides 1.2.0.
 >
 > 
http://download.eclipse.org/eclipse/updates/4.17-I-builds/I20200612-0650/plugins/javax.annotation_1.2.0.v201602091430.jar
 >
 > What contributes these third-party dependencies to the updates repo?
 >
 > Shouldn’t third-party dependencies be resolved from Orbit instead of
 > from the updates repo?
 >
 > How do I update one of these dependencies that is being provided by the
 > updates repo, such as javax.annotation?
 >
 > In any case, it seems that it must be too late to fix this for 2020-06,
 > but these should get reconciled before 2020-09.
 >
 > I’m interested in helping with this work, but I’ll need the information
 > I asked for above and could use some direction about which project to
 > log the bug in for tracking.
 >
 > Thanks!
 >
 > Tony Homer
 >
 > P.S. Is this an appropriate discussion for cross-project-issues dev?  I
 > don’t want to spam the list so please let me know if this is off-topic
 > and how I should communicate instead.  Thanks!
 >
 >
 > ___
 > 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] feature dependency version incompatibility

[Christoph Läubrich]

Was is selected in the future depends on the version available at build 
time.
If a never version at runtime is used/allowed depends on the imports in 
the Bundle itself.


So if proper imports and use clauses are defined it could be that all 
works fine even with different (why they are conflicting?) versions.


In a perfect world, all bundles would use import package with the lower 
bound of the lowest working version (e.g.  1.2.0) and an upper bound of 
2.0.0 then it would be possible to upgrade up until the next major release.


The problem is, that features does not support version ranges and thus 
will still reference the version from the build (or the one forced into 
the feature.xml).

Am 13.06.20 um 07:56 schrieb Homer, Tony:
Some 2020-06 features now require javax.annotation 1.3.5 (Jersey Common 
from Orbit and bundles that depend on it such as Linux Tools Docker) 
while others (such as org.eclipse.e4.rcp) still require javax.annotation 
1.2.0.


https://download.eclipse.org/tools/orbit/downloads/drops2/R20200529191137/repository/plugins/org.glassfish.jersey.core.jersey-common_2.30.1.v20200513-1859.jar

http://download.eclipse.org/releases/2020-06/202006171000/features/org.eclipse.linuxtools.docker.feature_4.7.0.202006092019.jar

http://download.eclipse.org/releases/2020-06/202006171000/features/org.eclipse.e4.rcp_4.16.0.v20200604-0951.jar

Is it possible to reconcile these dependency chains without rebuilding 
the features, so that an eclipse application can use several of these 
conflicting features from SimRel 2020-06?  As far as I know it is not, 
but I’d love to learn that I am wrong.


e4.rcp does not seem to have any version restriction defined (0.0.0).

https://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/features/org.eclipse.e4.rcp/feature.xml#n150

e4.rcp is resolving javax.annotation from the updates repo at build 
time, which provides 1.2.0.


http://download.eclipse.org/eclipse/updates/4.17-I-builds/I20200612-0650/plugins/javax.annotation_1.2.0.v201602091430.jar

What contributes these third-party dependencies to the updates repo?

Shouldn’t third-party dependencies be resolved from Orbit instead of 
from the updates repo?


How do I update one of these dependencies that is being provided by the 
updates repo, such as javax.annotation?


In any case, it seems that it must be too late to fix this for 2020-06, 
but these should get reconciled before 2020-09.


I’m interested in helping with this work, but I’ll need the information 
I asked for above and could use some direction about which project to 
log the bug in for tracking.


Thanks!

Tony Homer

P.S. Is this an appropriate discussion for cross-project-issues dev?  I 
don’t want to spam the list so please let me know if this is off-topic 
and how I should communicate instead.  Thanks!



___
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] JustJ JREs and download.eclipse.org Browsing

[Christoph Läubrich]

Hi Ed,

this looks good, I'll try to check if I can use this :-)

Just a note on your goody change:

> It has the advantage that you can browse folder content even
> if there is an index.html or index.php in that folder

It is common in web development to have a dummy index file to prevent 
browsing/discovery of files in a folder, so your solution might disclose 
otherwise (intentionally) hidden content.


Am 03.06.20 um 10:33 schrieb Ed Merks:

Hi,

I wanted to make the community aware that the initial prototyping work 
for providing JREs that can be redistributed by Eclipse is now complete.


The JustJ project is well documented.  You can find the details here:

https://www.eclipse.org/justj/

If you want to cut to the chase, see this section for how to try this 
out in your product:


https://www.eclipse.org/justj/?page=documentation#products

Please keep in mind that everything located in "sandbox" is transient 
and subject to arbitrary change and removal.


I've documented the ci instance as well and have made the job 
configurations readable:


https://ci.eclipse.org/justj/

Please use either https://bugs.eclipse.org/bugs/show_bug.cgi?id=562908 
or the forum https://www.eclipse.org/forums/index.php/f/532/ to provide 
feedback or to ask questions.


___

As an extra goody, I wanted a better browser for the contents of 
https://download.eclipse.org so I implemented a PHP script specifically 
for that purpose.   I did this for JustJ's content, but the result is 
fully general so I generalized it to provide the following link from 
which to get started at the root:


https://download.eclipse.org/justj/?file=

Starting here, you can browse anything on the download.eclipse.org 
server.   It has the advantage that you can browse folder content even 
if there is an index.html or index.php in that folder.


___

I took this one step further for my own project via this link:

https://download.eclipse.org/justj/www/download.eclipse.org.php?parambuild=true

I.e., it adds action links to the browser to help manage the justj site.

I asked for https://plugins.jenkins.io/build-with-parameters/ to be 
installed via this:


https://bugs.eclipse.org/bugs/show_bug.cgi?id=562477#c20

This allows me to open a parameterized build's page with pre-configured 
parameter values.  Specifically this simple build:


https://ci.eclipse.org/justj/job/internal/job/genie.justj-ssh/configure

The delete folder action links can (and does) open a page like this:

I.e., the links can run an arbitrary script with genie's credentials.  
Of course only authenticated users with genie.justj group permissions 
can actually do this.


Regards,
Ed


___
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] Mylyn to be removed from Eclipse packages

[Christoph Läubrich]

Hi Sam,

sad to heat, I always loved Mylyn and even though I have not used it 
everyday it has worked quite well.


You mentioned that mylin is stable an mature so isn't it a good 
indication that there are not much development (bug-free and 
featurecomplete)?


So maybe it would be better to discuss how we can polish the UI to make 
it integreate more seamingly?


So what maintenance is exspected? I'm pobbably able to contribute if 
neccesary if that the only problem, as I would love to see mylin 
included as part of standard eclipse.


I think there are mayn parts in Eclipse that are sode by some and used 
never by others. for example the online-help as I haven't used that for 
over 15 years of Eclipse usage...


Am 24.04.20 um 20:54 schrieb Sam Davis:

Hi,

It has been proposed that Mylyn be removed from most Eclipse packages 
[1]. So far only the PHP and Committers packages are planning to 
continue to include Mylyn. This is a result of the lack of activity on 
the project and (real or perceived) lack of use of Mylyn.


Mylyn is a stable and mature project, but as various project committers 
have moved on, there is very little capacity left to maintain it. For 
now, Mylyn will remain in the SimRel but if this becomes a problem, I 
will remove it unless a suitable party has stepped up to take on the 
necessary maintenance.


Note that this refers to Mylyn Tasks/Context/etc. and *not* Mylyn Wikitext.

Cheers,
Sam

[1] https://www.eclipse.org/lists/epp-dev/msg05871.html

*Sam Davis **|***Senior Software Engineer & Team Lead***| *Tasktop


___
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] Infrastructure Problems

[Christoph Läubrich]

I can't anymore access the following gerrit:

https://git.eclipse.org/r/#/c/160178/

it has worked today but now I'm always getting error
"https://git.eclipse.org/r/#/c/160178/;
Am 06.04.20 um 12:01 schrieb Mikael Barbero:

It is fixed.
*
Mikaël Barbero *
*Team Lead - Release Engineering | Eclipse Foundation*
 @mikbarbero
Eclipse Foundation : The Platform for Open 
Innovation and Collaboration


Le 6 avr. 2020 à 06:57, Ed Merks > a écrit :


FYI,

I don't know if others are affected but the Oomph CI instance is not 
usable right now because of signing service failures and gateway errors:


https://bugs.eclipse.org/bugs/show_bug.cgi?id=561793

This started happening yesterday morning (Sunday).

___
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] ChemClipse intend to join in Simultaneous Release (2020-06)

[Christoph Läubrich]

Hi Everyone,

I'd like to announce the intend of the ChemClipse Project[1] to join the 
sim-rel at 2020-06 release.


Steps that where already prepared for this:

- Adding a ticket to track progress [2] of open actions to fulfill 
simrel requirements

- created a new release [3]
- request for IP-Review [4]
- I subscribed to the cross-project-issues mailing list and following 
necessary bugzilla user


please let me know of any missing information or actions and how we 
could proceed, I'll then prepare the required items so any issue could 
be resolved.


regards
Christoph


[1] https://projects.eclipse.org/projects/science.chemclipse
[2] https://github.com/eclipse/chemclipse/issues/268
[3] 
https://projects.eclipse.org/projects/science.chemclipse/releases/0.8.0-2020-06

[4] https://dev.eclipse.org/ipzilla/show_bug.cgi?id=21745
___
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