Re: [cross-project-issues-dev] getting feature licenses right

[Ed Willink via cross-project-issues-dev]

Hi

Yes Ed M's example is much simper and you never have to worry about 
updating again.


  license-feature="org.eclipse.license"
  license-feature-version="0.0.0"

BUT you automatically track every EF license upgrade, so if you need to 
review such upgrades you need to reference your own audited copy.


    Regards

        Ed Willink

On 28/11/2023 15:19, Ed Merks via cross-project-issues-dev wrote:
It's better to use the common license feature (not how Oomph or EMF 
are doing it with their own license feature) which is more historical...


I recently improved the README for this:

https://github.com/eclipse-cbi/epl-license-feature

So it's better to look at a simple example like this one:

https://github.com/eclipse-orbit/orbit-legacy/tree/main/features/org.eclipse.orbit.legacy-feature 




On 28.11.2023 15:29, Christian Pontesegger via 
cross-project-issues-dev wrote:

Hi,

I would like to get my license links right in my feature definitions an
wonder how that works for other projects.

Eg Oomph:
https://github.com/eclipse-oomph/oomph/blob/master/features/org.eclipse.oomph.all-feature/feature.xml 


uses %licenseURL and %license

which I expected to be defined in
https://github.com/eclipse-oomph/oomph/blob/master/features/org.eclipse.oomph.all-feature/feature.properties 


but they are not. Also a license.html file is missing in the repo which
I remember was needed (at least some time ago)

Are these files patched by tycho somehow? If yes, how does this work?

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 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] Papyrus won't be participating in 2023-09 train

[Ed Willink via cross-project-issues-dev]

Hi Pauline

Provided your N-builds demonstrate that your tests still pass on the 
latest Eclipse, you can just emulate the latest SimRel commit:


    [modisco,ocl,qvtd,qvto] Touch for 2023-09

The commit provides a trivial change for each *.aggrcon to prevent the 
stale-project-detector activating after M2.


    Regards

        Ed Willink

On 01/08/2023 16:26, Jonah Graham via cross-project-issues-dev wrote:

Hi Pauline,

If you don't mind me asking, why disable Papyrus for a single release? 
Can you ship the same version for 2023-09 as you did for 2023-06? Is 
there something about Papyrus 6.5.0 that no longer works with the rest 
2023-09?


Jonah
~~~
Jonah Graham (he/him)
Kichwa Coders
www.kichwacoders.com <http://www.kichwacoders.com>


On Tue, 1 Aug 2023 at 05:23, DEVILLE Pauline via 
cross-project-issues-dev  wrote:


Hello everyone,

We would like to inform you that Papyrus won't be participating in
the next 2023-09 release train, we will be returning for the next
2023-12 train.

Best regards,

Pauline

___
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, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] A future without source features?

[Ed Willink]

Hi

Is this serious or have I totally misunderstood?

The ability to step through code with the debugger is one of the more 
important features of the Eclipse IDE.


If there are no source features, Eclipse IMHO ceases to be an IDE.

The current Tycho support makes source features very easy so why change?

Requiring an Internet connection to fetch from an external repository is 
not helpful, particularly when flying or when the Internet is flaky. I 
typically install from the platform SDK and project SDK ZIPs that for 
most projects have everything that I need. Please do not break a very 
traditional use case.


    Regards

        Ed Willink

On 16/01/2023 21:02, Mickael Istria wrote:

Hi all,

I'd like to raise to general awareness a technical proposal for 
Platform and others, that I believe is worth progressively going 
mainstream as it's a noticeable simplification to multiple processes, 
and that is very likely to be achievable in a short timeframe.

Basically, the idea is to get rid of source features.
Indeed, source features are not so important artifacts per se, what 
really matters is making source bundles available at build-time (to 
include them in p2 repositories or products) and at dev-time (to make 
them available in the IDE).
But nowadays, none of those do require source features: Tycho now has 
a cool "includeAllSources" flag on the tycho-p2-repository-plugin 
https://tycho.eclipseprojects.io/doc/latest/tycho-p2/tycho-p2-repository-plugin/assemble-repository-mojo.html#includeAllSources 
that allows to (drumroll) include all sources available from the 
reactor or the target-platform for each bundle of the resulting p2 
repository; and PDE already has capability to find locally available 
source bundles in the .target or the installation path and will soon 
have ability to resolve more source bundles from target-platform on 
demand: https://github.com/eclipse-pde/eclipse.pde/pull/425. Moreover, 
the m2e intergration with PDE makes that source bundles also become 
available locally when the artifact originates from a Maven repository.
All that make that instead of managing source feature artifact, we 
have workflows to make source features available to the user basically 
with just 1 flag at build time. On Platform, this would allow to avoid 
lots of "touch" commits when an external version of a dependency 
changes; we can stop listing transitive deps in feature.xml (p2 
resolves them) but still have their source bundles in p2 repo (Tycho 
adds them).


Of course, things are rarely perfect on 1st shot; but the more people 
try to make it perfect, the more it is likely to become so. To get 
there, anyone interested please consider trying those new capabilities 
and report issues. In the best case, you may be able to get rid of 
source features and some build customization; in the worst case you'll 
report issue.


Cheers,
--
Mickael Istria
Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red 
Hat Developers <https://developers.redhat.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

Re: [cross-project-issues-dev] CVS support plugin discontinuation - SimRel build changes needed

[Ed Willink]

Hi

Indeed, but I think that some of us would like to know how +0.1.0 rather 
than +1.0.0 became a major release with the result that Eclipse policies 
that some of us have endeavoured to observe are just being torn to 
shreds by the platform.


    Regards

        Ed Willink

On 04/01/2023 09:42, Ed Merks wrote:


Ed,

I think you are barking up a tree that is no longer occupied by a cat.

It's fine to make cross-project aware of the issue, but I think 
everything meaningful to be said on the topic has now been said, with 
Stephan Hermann's summary being particularly savvy...


If you think more needs to be said *and *you think that what you say 
will actually sway the very people who you think should take some form 
of action (which I feel makes you overly optimistic), it would be 
best, to do so on the issue that you've already opened where 
anyone/everyone interested in further discussions can participate too:


https://github.com/eclipse-platform/eclipse.platform.team/issues/29

My sense is that this decision was made long ago and that no one is 
obligated to make an older version of CVS continue to work in current 
or future releases.


Regards,
Ed

On 04.01.2023 09:48, Ed Willink wrote:

Hi

On 03/01/2023 21:13, Stephan Herrmann wrote:

* The code change in question didn't touch any true API.

IMHO, UX is also API, albeit spelling changes / menu rationalization 
/ form prettifying are acceptable and sometimes desirable. The 
fundamental user capability to check out a CVS project is API.


Presumably it was possible to write a program that re-used team CVS 
support to check out a CVS project. The API used by this hypothetical 
program is now broken. If such a program was only possible using 
internal classes, then those classes constitute what I call 
artificially internal functionality; internal classes that, in the 
absence of a suitable Facade, users have no alternative but to use 
for reasonable purposes.


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

Re: [cross-project-issues-dev] CVS support plugin discontinuation - SimRel build changes needed

[Ed Willink]

Hi

On 03/01/2023 21:13, Stephan Herrmann wrote:

* The code change in question didn't touch any true API.

IMHO, UX is also API, albeit spelling changes / menu rationalization / 
form prettifying are acceptable and sometimes desirable. The fundamental 
user capability to check out a CVS project is API.


Presumably it was possible to write a program that re-used team CVS 
support to check out a CVS project. The API used by this hypothetical 
program is now broken. If such a program was only possible using 
internal classes, then those classes constitute what I call artificially 
internal functionality; internal classes that, in the absence of a 
suitable Facade, users have no alternative but to use for reasonable 
purposes.


    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

Re: [cross-project-issues-dev] CVS support plugin discontinuation - SimRel build changes needed

[Ed Willink]

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

But indeed, if one wants to do that work for free, that's even friendlier.

My understanding of the disciplined deprecation was that two major
releases were required after an announcement, but since e6 is
impossibly
distant the platform has taken to breakage in minor versions.
Nonetheless I would expect two releases on the yearly cadence so
breakage within 18 months seems very wrong and to merit a
regression fix.


Deprecation announced in September 2021 (4.21)
Removal in January 2022 for upcoming 4.23, 2 major releases later
Breakage found January 2023 on 4.26, 3 major releases later

The cadence is described at https://projects.eclipse.org/projects/eclipse

Ultimately, there is a clear law of software development: unmaintained 
software that no-one builds or updates against newer version of its 
dependencies will die; only software that someone maintains actively 
survives. It's not a matter of process here, but a matter of interest 
in maintaining it. If some money can be found to boost interest from 
someone in maintaining here, then we all win.___
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

[Ed Willink]

Hi

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


The CVS deprecation was announced in September 2021. It announced 
removal of the ongoing distribution, not refactoring and breakage.


My understanding of the disciplined deprecation was that two major 
releases were required after an announcement, but since e6 is impossibly 
distant the platform has taken to breakage in minor versions. 
Nonetheless I would expect two releases on the yearly cadence so 
breakage within 18 months seems very wrong and to merit a regression fix.


    Regards

        Ed Willink

On 03/01/2023 10:46, Mickael Istria wrote:

Hello,

The older version of CVS support seem to not be working any more with 
newer Platform: 
https://github.com/eclipse-platform/eclipse.platform.team/issues/29#issuecomment-1369456296 
. While there is clearly no intention for Platform to revive CVS 
support or anything of that form. the broken or unavailable CVS 
support seems to be something that is a problem for a few people on 
StackOverflow. It may be a good business opportunity for some 
freelancers to try to get in touch with people who seem to need CVS 
support and turn those CVS users as customers who could fund a forked 
and up-to-date version of former support; or to get in touch with them 
and sell some CVS->Git migration.

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

___
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] Build failures with https://download.eclipse.org/eclipse/updates/4.27-I-builds/I20221130-1800

[Ed Willink]

Hi Ed

Thanks. That was the clue I needed.

It would appear that the 1.72.0 version of org.bouncycastle.bcpg in the 
latest Orbit has a signing challenge that fails for Eclipse 4.27's 
I-build if Tycho < 2.7.1. Since this was not a problem with Eclipse 4.26 
for which


[INFO] Fetching bcpg_1.72.0.jar 
fromhttps://download.eclipse.org/eclipse/updates/4.26-I-builds/I20221123-0600/plugins/
  (393.64kB)

was successful, I'm puzzled as to quite what has actually changed.

Anyway, changing to Tycho >= 2.7.1 is now mandatory.

Changing to Tycho 3.0.0 and so Java 17 is not yet necessary.

Changing to Maven 3.8.5 is not yet necessary.



Eliminating the deprecated tycho-source-feature-plugin is obviously a 
good idea, but your simple cut and paste gives a problem for me with a 
duplicate tycho-source-plugin. For me the additional bold lines are 
appropriate since I'm already using the plugin-source goal.


  
    org.eclipse.tycho
    tycho-source-plugin
    ${tycho-version}
    
  
false
  
    
    
  
    plugin-source
    
  plugin-source
    
  
*  **
**    feature-source**
**    **
**  feature-source**
**    **
**  **
*    
  

(attempting to just specify one execution with two goals gives an 
obscure org.eclipse.equinox.p2.iu not found.)


I cannot find documentation to explain the suppressed 
addMavenDescriptor. I wonder if it is unfriendly to non-Eclipse users.


    Regards

        Ed Willink

On 12/12/2022 07:53, Ed Merks wrote:


Ed,

If you move to Tycho 3.0 and beyond, you need to read the release 
notes, and this in particular:


https://github.com/eclipse-tycho/tycho/blob/master/RELEASE_NOTES.md#removal-of-tycho-source-featuresource-feature

So you need to replace this:

  
    org.eclipse.tycho.extras
tycho-source-feature-plugin
    
  
    generate-source-feature
    
  source-feature
    
  
    
  

with this

  
    org.eclipse.tycho
    tycho-source-plugin
    
  
    package
    feature-source
    
  feature-source
    
  
    
  

That replacement is already available in versions of Tycho < 3.0.0

As for bcpg,  that sounds related to this issue:

https://github.com/eclipse-equinox/p2/issues/203

I would expect using Tycho 2.7.5 (with newer version of p2) should 
eliminate the bcpg problem.  I think tycho 2.7.5 still contains the 
deprecated org.eclipse.tycho.extras:tycho-source-feature-plugin, but 
you may as well fix that because eventually you will have to fix that.



On 12.12.2022 07:48, Ed Willink wrote:


Hi

Once again my forced weekly builds against latest fail.

https://ci.eclipse.org/qvt-oml/job/qvto-master/487/

[ERROR] An error occurred while transferring artifact canonical: 
osgi.bundle,bcpg,1.72.0 from repository 
https://download.eclipse.org/eclipse/updates/4.27-I-builds/I20221130-1800: 
[ERROR] Result of processing steps.: [ERROR] Public key not found for 
700e4f39bc05364b. [ERROR] Internal error: 
org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException: 
Could not mirror artifact osgi.bundle,bcpg,1.72.0 into the local 
Maven repository.See log output for details. -> [Help 1] org.apache.maven.InternalErrorException: Internal error: org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException: Could not mirror artifact osgi.bundle,bcpg,1.72.0 into the local Maven repository.See log output for details.


A similar build locally fails more reasonably on a missing com.ibm.icu.

bcpg is indeed missing. Is there a typo for com.bouncycastle.bcpg?

--

Last successful build used:

Java 11, Maven 3.6.3, Tycho 2.6.0, Platform 4.26

--

Upgrading to Java 19 fails with JavaSE-19 not supported.

Upgrading to Java 17 makes no difference.

Upgrading to Maven 3.8.6 makes no difference.

Upgrading to Tycho 2.7.0 or 2.7.5 or 3.0.0: 
https://ci.eclipse.org/qvt-oml/job/qvto-branch-tests/128/

  gives many

[WARNING] The POM for 
org.eclipse.tycho.extras:tycho-source-feature-plugin:jar:3.0.0 is 
missing, no dependency information available


then

[ERROR] Cannot resolve project dependencies: [ERROR] Software being 
installed: org.eclipse.qvto.releng.build-site 
raw:3.10.8.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):3.10.8-SNAPSHOT 
[ERROR] Missing requirement: org.eclipse.qvto.releng.build-site 
raw:3.10.8.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):3.10.8-SNAPSHOT 
requires 'org.eclipse.equinox.p2.iu; 
org.eclipse.m2m.qvt.oml.tools.source.feature.group 0.0.0' but it 
could not be found


suggesting something bad with the platform.

What is the correct set of tools to build the latest platform build?

    Regards

      

[cross-project-issues-dev] Build failures with https://download.eclipse.org/eclipse/updates/4.27-I-builds/I20221130-1800

[Ed Willink]

Hi

Once again my forced weekly builds against latest fail.

https://ci.eclipse.org/qvt-oml/job/qvto-master/487/

[ERROR] An error occurred while transferring artifact canonical: 
osgi.bundle,bcpg,1.72.0 from repository 
https://download.eclipse.org/eclipse/updates/4.27-I-builds/I20221130-1800: 
[ERROR] Result of processing steps.: [ERROR] Public key not found for 
700e4f39bc05364b. [ERROR] Internal error: 
org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException: 
Could not mirror artifact osgi.bundle,bcpg,1.72.0 into the local Maven 
repository.See log output for details. -> [Help 1] org.apache.maven.InternalErrorException: Internal error: org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException: Could not mirror artifact osgi.bundle,bcpg,1.72.0 into the local Maven repository.See log output for details.


A similar build locally fails more reasonably on a missing com.ibm.icu.

bcpg is indeed missing. Is there a typo for com.bouncycastle.bcpg?

--

Last successful build used:

Java 11, Maven 3.6.3, Tycho 2.6.0, Platform 4.26

--

Upgrading to Java 19 fails with JavaSE-19 not supported.

Upgrading to Java 17 makes no difference.

Upgrading to Maven 3.8.6 makes no difference.

Upgrading to Tycho 2.7.0 or 2.7.5 or 3.0.0: 
https://ci.eclipse.org/qvt-oml/job/qvto-branch-tests/128/

  gives many

[WARNING] The POM for 
org.eclipse.tycho.extras:tycho-source-feature-plugin:jar:3.0.0 is 
missing, no dependency information available


then

[ERROR] Cannot resolve project dependencies: [ERROR] Software being 
installed: org.eclipse.qvto.releng.build-site 
raw:3.10.8.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):3.10.8-SNAPSHOT 
[ERROR] Missing requirement: org.eclipse.qvto.releng.build-site 
raw:3.10.8.'SNAPSHOT'/format(n[.n=0;[.n=0;[-S]]]):3.10.8-SNAPSHOT 
requires 'org.eclipse.equinox.p2.iu; 
org.eclipse.m2m.qvt.oml.tools.source.feature.group 0.0.0' but it could 
not be found


suggesting something bad with the platform.

What is the correct set of tools to build the latest platform build?

    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

Re: [cross-project-issues-dev] Jetty 1.0.11 needs java.lang.module

[Ed Willink]

Hi

Thanks. Yes a more recent Tycho fixed it.

Sorry for the slow acknowledgement. Initially changing Tycho provoked 
some magic failures that mysteriously went away.


Echoing a similar problem on the winsigner improvement thread...

Is it possible for the platform to define a stable compatible e.g. 
eclipse-tycho-version to allow in pom.xml


${eclipse-tycho-version}
${tycho-version}

so that 'lazy' developers do not have to keep diagnosing breakages?

    Regards

        Ed Willink

On 18/09/2022 18:38, Christoph Läubrich wrote:

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

___
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-winsigner Improvement

[Ed Willink]

Hi

The new SHA signatures may explain why at least Tycho 2.4.0 is needed to 
build against the latest platform I-build. Java 11 is still ok.


Use of a lesser Tycho version gives the partial log and partial trace below.

Is it possible for the platform to define a stable compatible e.g. 
eclipse-tycho-version to allow in pom.xml


${eclipse-tycho-version}
${tycho-version}

so that 'lazy' developers do not have to keep diagnosing breakages?

    Regards

        Ed Willink

[INFO] Fetching org.eclipse.core.resources_3.18.100.v20221004-0631.jar 
fromhttps://download.eclipse.org/eclipse/updates/4.26-I-builds/I20221007-1800/plugins/
  (892.3kB)
[ERROR] An error occurred while transferring artifact canonical: 
osgi.bundle,org.eclipse.core.resources,3.18.100.v20221004-0631 from 
repository 
https://download.eclipse.org/eclipse/updates/4.26-I-builds/I20221007-1800: 
[ERROR] Problems downloading artifact: 
osgi.bundle,org.eclipse.core.resources,3.18.100.v20221004-0631.: [ERROR] 
Error reading signed content:/tmp/signatureFile7309577143305142161.jar 
[ERROR] Internal error: 
org.eclipse.tycho.repository.local.MirroringArtifactProvider$MirroringFailedException: 
Could not mirror artifact 
osgi.bundle,org.eclipse.core.resources,3.18.100.v20221004-0631 into the 
local Maven repository.See log output for details. An error occurred 
while processing the signatures for the file: 
/tmp/signatureFile7309577143305142161.jar: No algorithm found for 
1.2.840.113549.1.1.12 -> [Help 1]


...

Caused by: java.security.NoSuchAlgorithmException: No algorithm found for 
1.2.840.113549.1.1.12
at org.eclipse.osgi.internal.signedcontent.PKCS7Processor.findEncryption 
(PKCS7Processor.java:95)
at 
org.eclipse.osgi.internal.signedcontent.PKCS7Processor.processSignerInfos 
(PKCS7Processor.java:364)
at org.eclipse.osgi.internal.signedcontent.PKCS7Processor. 
(PKCS7Processor.java:172)
at 
org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.processSigner 
(SignatureBlockProcessor.java:109)
at org.eclipse.osgi.internal.signedcontent.SignatureBlockProcessor.process 
(SignatureBlockProcessor.java:76)
at 
org.eclipse.osgi.internal.signedcontent.SignedBundleFile.initializeSignedContent
 (SignedBundleFile.java:56)
at 
org.eclipse.osgi.internal.signedcontent.SignedBundleHook.getSignedContent 
(SignedBundleHook.java:223)
at 
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.verifyContent
 (SignatureVerifier.java:84)
at 
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.verify 
(SignatureVerifier.java:66)
at 
org.eclipse.equinox.internal.p2.artifact.repository.SignatureVerifier.close 
(SignatureVerifier.java:115)
at 
org.eclipse.equinox.internal.provisional.p2.artifact.repository.processing.ProcessingStep.close
 (ProcessingStep.java:92)
at 
org.eclipse.equinox.internal.p2.artifact.processors.checksum.MessageDigestProcessingStep.close
 (MessageDigestProcessingStep.java:58)
at 
org.eclipse.equinox.internal.provisional.p2.artifact.repository.processing.ProcessingStep.close
 (ProcessingStep.java:92)
at 
org.eclipse.equinox.internal.p2.artifact.processors.checksum.MessageDigestProcessingStep.close
 (MessageDigestProcessingStep.java:58)
at 
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.reportStatus
 (SimpleArtifactRepository.java:1250)
at 
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.downloadArtifact
 (SimpleArtifactRepository.java:645)
at 
org.eclipse.equinox.internal.p2.artifact.repository.simple.SimpleArtifactRepository.getArtifact
 (SimpleArtifactRepository.java:776)
___
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] Jetty 1.0.11 needs java.lang.module

[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

Re: [cross-project-issues-dev] Current Simrel repo inconsistent?

[Ed Willink]

Hi

Unless you can transitively eliminate all traditional Orbit 
dependencies, the simple solution is to add


    location="https://download.eclipse.org/tools/orbit/downloads/drops/R20220302172233/repository"/>


as an additional Orbit location, so that you can access traditional 
Orbit contents from the last Orbit build to include them.


It would of course be much better if there was a symbolic "legacy" link 
analogous to "latest". Even better would be to continue to provide the 
widely used legacy Orbit content in Orbit without forcing us all to 
debug and change builds for no obviously good reason.


    Regards

        Ed Willink

On 06/08/2022 07:13, Christian Dietrich wrote:
created 
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/444 



Am 06.08.22 um 08:09 schrieb Andrey Loskutov:
*21:33:56*   [ERROR]   Software being installed: 
org.eclipse.rcp.feature.group 4.25.0.v20220728-1800
*21:33:56*   [ERROR]   Missing requirement: org.apache.xmlgraphics 
2.6.0.v20210409-0748 requires 'java.package; org.apache.commons.io 
1.3.1' but it could not be found
*21:33:56*   [ERROR]   Cannot satisfy dependency: 
org.apache.batik.css 1.14.0.v20210324-0332 depends on: java.package; 
org.apache.xmlgraphics.java2d.color 2.2.0
*21:33:56*   [ERROR]   Cannot satisfy dependency: 
org.eclipse.e4.rcp.feature.group 4.25.0.v20220727-1405 depends on: 
org.eclipse.equinox.p2.iu; org.apache.batik.css 
[1.14.0.v20210324-0332,1.14.0.v20210324-0332]
*21:33:56*   [ERROR]   Cannot satisfy dependency: 
org.eclipse.rcp.feature.group 4.25.0.v20220728-1800 depends on: 
org.eclipse.equinox.p2.iu; org.eclipse.e4.rcp.feature.group 
[4.25.0.v20220727-1405,4.25.0.v20220727-1405]




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [cross-project-issues-dev] Solved: Gmail thinks Gitlab is Spam

[Ed Willink]

Hi

Correction. Raising 
https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1404 
demonstrated that the provocative tail problem occurs on GitLab as well 
as GitHub.


Raising issue 1404 demonstrated that GitLab is blacklisted for me at 
GMail. GitHub is only a phishing hazard.


Regards

Ed Willink

On 13/06/2022 08:18, Ed Willink wrote:

Hi

https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1404 raised.

On further investigation this is a Phishing rather than Spam problem. 
It appears that the 'provocative tail' is outside the traditional text 
protected by the mail signature and so the links within the tail cause 
an inadequate Gmail phishing detector to fail. The same tail embedded 
as regular message text a test Bugzilla notification is checked 
without trouble by Gmail.


@Wayne: Yes, this is perhaps just a GitHub redirected to Gmail problem.

(Testing teeing my redirection to two emails revealed that there are 
some legitimate senders (e.g. the nextdoor.co.uk local social media 
site) that Gmail seems to blacklist without providing any Spam clues; 
not a good email supplier.)


Regards

Ed Willink

On 09/06/2022 20:41, Wayne Beaton wrote:


Surely the EF should ensure that EF messages do not contain what
is clearly partial SPAM?


I looked through about a dozen messages sent from various eclipse.org 
<http://eclipse.org> lists and found this in none of them (but did 
find it in several examples of messages sent from GitHub). The one 
example that you've presented is from GitHub.


If you have specific examples that come from eclipse.org 
<http://eclipse.org>, please cite them in an issue and start a 
conversation about sorting this out with the IT team.


Wayne

On Thu, Jun 9, 2022 at 3:26 PM Ed Willink  wrote:

Hi

Yes, the tails may be a red herring. It was just that the 'Spam'
messages I rescued were from Eclipse and they all had this tail,
which
despite the comment in

https://developers.google.com/gmail/markup/actions/declaring-actions

are not ignored by the Thunderbird email client. Surely the EF
should
ensure that EF messages do not contain what is clearly partial SPAM?
Bugzilla was fine.

It appears that contrary to the 0.05% false positive rate claimed
for
the Gmail Spam filter, it was actually more like 50% for me
affecting
many senders. Truly abysmal. Any in a folder that requires a
couple of
scrolling actions to reveal.

 Regards

         Ed Willink

On 09/06/2022 11:36, Arthur van Dorp wrote:
> Hi Ed
>
> Not sure those "tails" are to blame. They are actually meant
for mail clients and Gmail supports those:
>
>
https://developers.google.com/gmail/markup/actions/declaring-actions
>
> Regards
> Arthur
>
> -Original Message-
    > From: cross-project-issues-dev
 On Behalf Of Ed
Willink
> Sent: Thursday, 9 June, 2022 12:20
> To: Cross project issues 
> Subject: [cross-project-issues-dev] Solved: Gmail thinks Gitlab
is Spam
>
> Hi
>
> I have been complaining recently about lost emails,
particularly all those from gitlab, github and some from
cross-project-dev.
>
> Problem solved. The lost emails have a tail that looks like:
>
> [ { "@context": "http://schema.org;, "@type": "EmailMessage",
> "potentialAction": { "@type": "ViewAction", "target":
>

"https://github.com/eclipse-m2e/m2e-core/pull/735#issuecomment-1150841883","url":
>
"https://github.com/eclipse-m2e/m2e-core/pull/735#issuecomment-1150841883;,
> "name": "View Pull Request" }, "description": "View this Pull
Request on GitHub", "publisher": { "@type": "Organization",
"name": "GitHub",
> "url":

"https://smex-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fgithub.com=54465e77-e305-480a-8537-dee40869dc31=2553b7ee1b402f6c614d840b79175d8e10d66fea-f28b8dabd5154be63373caed4ac034dbbd4db939

<https://smex-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fgithub.com=54465e77-e305-480a-8537-dee40869dc31=2553b7ee1b402f6c614d840b79175d8e10d66fea-f28b8dabd5154be63373caed4ac034dbbd4db939>"
} } ]
>
> The latest 'improved' Gmail spam filter is 'clever' enough to
regard the tail gibberish as a Spam indicator, and so Thunderbird
failed to download the messages for me.
>
> Unfortunately if you log on to Gmail, the Spam folder is not
visible unless you scroll the folder list, so I was deceived into
thinking there was no recoverable personal Spam just lost global
Spam.
>
> Once I

Re: [cross-project-issues-dev] Solved: Gmail thinks Gitlab is Spam

[Ed Willink]

Hi

https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1404 raised.

On further investigation this is a Phishing rather than Spam problem. It 
appears that the 'provocative tail' is outside the traditional text 
protected by the mail signature and so the links within the tail cause 
an inadequate Gmail phishing detector to fail. The same tail embedded as 
regular message text a test Bugzilla notification is checked without 
trouble by Gmail.


@Wayne: Yes, this is perhaps just a GitHub redirected to Gmail problem.

(Testing teeing my redirection to two emails revealed that there are 
some legitimate senders (e.g. the nextdoor.co.uk local social media 
site) that Gmail seems to blacklist without providing any Spam clues; 
not a good email supplier.)


Regards

Ed Willink

On 09/06/2022 20:41, Wayne Beaton wrote:


Surely the EF should ensure that EF messages do not contain what
is clearly partial SPAM?


I looked through about a dozen messages sent from various eclipse.org 
<http://eclipse.org> lists and found this in none of them (but did 
find it in several examples of messages sent from GitHub). The one 
example that you've presented is from GitHub.


If you have specific examples that come from eclipse.org 
<http://eclipse.org>, please cite them in an issue and start a 
conversation about sorting this out with the IT team.


Wayne

On Thu, Jun 9, 2022 at 3:26 PM Ed Willink  wrote:

Hi

Yes, the tails may be a red herring. It was just that the 'Spam'
messages I rescued were from Eclipse and they all had this tail,
which
despite the comment in

https://developers.google.com/gmail/markup/actions/declaring-actions

are not ignored by the Thunderbird email client. Surely the EF should
ensure that EF messages do not contain what is clearly partial SPAM?
Bugzilla was fine.

It appears that contrary to the 0.05% false positive rate claimed for
the Gmail Spam filter, it was actually more like 50% for me affecting
many senders. Truly abysmal. Any in a folder that requires a
couple of
scrolling actions to reveal.

 Regards

         Ed Willink

On 09/06/2022 11:36, Arthur van Dorp wrote:
> Hi Ed
>
> Not sure those "tails" are to blame. They are actually meant for
mail clients and Gmail supports those:
>
> https://developers.google.com/gmail/markup/actions/declaring-actions
>
> Regards
> Arthur
>
> -Original Message-
    > From: cross-project-issues-dev
 On Behalf Of Ed Willink
> Sent: Thursday, 9 June, 2022 12:20
> To: Cross project issues 
> Subject: [cross-project-issues-dev] Solved: Gmail thinks Gitlab
is Spam
>
> Hi
>
> I have been complaining recently about lost emails, particularly
all those from gitlab, github and some from cross-project-dev.
>
> Problem solved. The lost emails have a tail that looks like:
>
> [ { "@context": "http://schema.org;, "@type": "EmailMessage",
> "potentialAction": { "@type": "ViewAction", "target":
>

"https://github.com/eclipse-m2e/m2e-core/pull/735#issuecomment-1150841883","url":
>
"https://github.com/eclipse-m2e/m2e-core/pull/735#issuecomment-1150841883;,
> "name": "View Pull Request" }, "description": "View this Pull
Request on GitHub", "publisher": { "@type": "Organization",
"name": "GitHub",
> "url":

"https://smex-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fgithub.com=54465e77-e305-480a-8537-dee40869dc31=2553b7ee1b402f6c614d840b79175d8e10d66fea-f28b8dabd5154be63373caed4ac034dbbd4db939

<https://smex-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fgithub.com=54465e77-e305-480a-8537-dee40869dc31=2553b7ee1b402f6c614d840b79175d8e10d66fea-f28b8dabd5154be63373caed4ac034dbbd4db939>"
} } ]
>
> The latest 'improved' Gmail spam filter is 'clever' enough to
regard the tail gibberish as a Spam indicator, and so Thunderbird
failed to download the messages for me.
>
> Unfortunately if you log on to Gmail, the Spam folder is not
visible unless you scroll the folder list, so I was deceived into
thinking there was no recoverable personal Spam just lost global Spam.
>
> Once I scrolled and opened the Spam folder, Eureka, there are
all the lost emails (well 30 days worth). After marking a few as
not-Spam, the filter was trained and 180 lost emails were
available to Thunderbird.
>
> Bottom line. If you use Gmail, review your Spam folder because
recent Eclipse communications have a junk 

Re: [cross-project-issues-dev] Multiple version of org.eclipse.sdk.feature.group in the 2022-06 simrel

[Ed Willink]

Hi

This is something that has always puzzled me.

If reverting to an old installation then that old installation must have 
existed and so must have had all the requisite plugins in place. These 
do not appear to be deleted when upgrading so surely reverting should 
not need to access any repo at all. Everything that is needed is in 
place in the installation tree; just needs the configuration to pick the 
correct plugins. Reverting should therefore be much faster and much more 
reliable. Further copies of everything are probably also available in 
OOMPH's p2 repo or in the user's manual ZIPs and their origin could be 
cached in the configuration.


Perhaps as a security check there could be a checksum of each plugin to 
diagnose when an upgrade overwrites a plugin.


Regards

        Ed Willink

On 11/06/2022 15:45, Michael Keppler wrote:
As Ed wrote, reverting was the only way to fix your IDE, when a 
milestone was broken. And for reverting you need the old update site. 
I've done that multiple times.
However, since oomph this is probably not needed anymore, since we are 
now used to just doing the installation again. With that in mind, it 
might be possible to get rid of composite milestone update sites.


___
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


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [cross-project-issues-dev] Solved: Gmail thinks Gitlab is Spam

[Ed Willink]

Hi

Yes, the tails may be a red herring. It was just that the 'Spam' 
messages I rescued were from Eclipse and they all had this tail, which 
despite the comment in


https://developers.google.com/gmail/markup/actions/declaring-actions

are not ignored by the Thunderbird email client. Surely the EF should 
ensure that EF messages do not contain what is clearly partial SPAM? 
Bugzilla was fine.


It appears that contrary to the 0.05% false positive rate claimed for 
the Gmail Spam filter, it was actually more like 50% for me affecting 
many senders. Truly abysmal. Any in a folder that requires a couple of 
scrolling actions to reveal.


    Regards

        Ed Willink

On 09/06/2022 11:36, Arthur van Dorp wrote:

Hi Ed

Not sure those "tails" are to blame. They are actually meant for mail clients 
and Gmail supports those:

https://developers.google.com/gmail/markup/actions/declaring-actions

Regards
Arthur

-Original Message-
From: cross-project-issues-dev  
On Behalf Of Ed Willink
Sent: Thursday, 9 June, 2022 12:20
To: Cross project issues 
Subject: [cross-project-issues-dev] Solved: Gmail thinks Gitlab is Spam

Hi

I have been complaining recently about lost emails, particularly all those from 
gitlab, github and some from cross-project-dev.

Problem solved. The lost emails have a tail that looks like:

[ { "@context": "http://schema.org;, "@type": "EmailMessage",
"potentialAction": { "@type": "ViewAction", "target":
"https://github.com/eclipse-m2e/m2e-core/pull/735#issuecomment-1150841883","url":
"https://github.com/eclipse-m2e/m2e-core/pull/735#issuecomment-1150841883;,
"name": "View Pull Request" }, "description": "View this Pull Request on GitHub", "publisher": { "@type": 
"Organization", "name": "GitHub",
"url": 
"https://smex-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fgithub.com=54465e77-e305-480a-8537-dee40869dc31=2553b7ee1b402f6c614d840b79175d8e10d66fea-f28b8dabd5154be63373caed4ac034dbbd4db939;
 } } ]

The latest 'improved' Gmail spam filter is 'clever' enough to regard the tail 
gibberish as a Spam indicator, and so Thunderbird failed to download the 
messages for me.

Unfortunately if you log on to Gmail, the Spam folder is not visible unless you 
scroll the folder list, so I was deceived into thinking there was no 
recoverable personal Spam just lost global Spam.

Once I scrolled and opened the Spam folder, Eureka, there are all the lost 
emails (well 30 days worth). After marking a few as not-Spam, the filter was 
trained and 180 lost emails were available to Thunderbird.

Bottom line. If you use Gmail, review your Spam folder because recent Eclipse 
communications have a junk tail that predisposes them to be treated as Spam.

Surely Eclipse should not be sending messages with such a provocative junk tail?

      Regards

          Ed Willink


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

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


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

[cross-project-issues-dev] Solved: Gmail thinks Gitlab is Spam

[Ed Willink]

Hi

I have been complaining recently about lost emails, particularly all 
those from gitlab, github and some from cross-project-dev.


Problem solved. The lost emails have a tail that looks like:

[ { "@context": "http://schema.org;, "@type": "EmailMessage", 
"potentialAction": { "@type": "ViewAction", "target": 
"https://github.com/eclipse-m2e/m2e-core/pull/735#issuecomment-1150841883","url": 
"https://github.com/eclipse-m2e/m2e-core/pull/735#issuecomment-1150841883;, 
"name": "View Pull Request" }, "description": "View this Pull Request on 
GitHub", "publisher": { "@type": "Organization", "name": "GitHub", 
"url": "https://github.com; } } ]


The latest 'improved' Gmail spam filter is 'clever' enough to regard the 
tail gibberish as a Spam indicator, and so Thunderbird failed to 
download the messages for me.


Unfortunately if you log on to Gmail, the Spam folder is not visible 
unless you scroll the folder list, so I was deceived into thinking there 
was no recoverable personal Spam just lost global Spam.


Once I scrolled and opened the Spam folder, Eureka, there are all the 
lost emails (well 30 days worth). After marking a few as not-Spam, the 
filter was trained and 180 lost emails were available to Thunderbird.


Bottom line. If you use Gmail, review your Spam folder because recent 
Eclipse communications have a junk tail that predisposes them to be 
treated as Spam.


Surely Eclipse should not be sending messages with such a provocative 
junk tail?


    Regards

        Ed Willink


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

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

[Ed Willink]

Hi Christian

IIRC when we moved to the three monthly cadence, some projects made 
clear from the outset that they would skip at least one of the 
milestones. On this occasion the platform has skipped M2 as originally 
planned. The M2 EPPs are therefore out but with M1 platform/JDT content.


    Regards

        Ed Willink

On 06/05/2022 06:46, Christian Dietrich wrote:

i mean the milestone 2 jonah is talking about


Am 06.05.22 um 07:44 schrieb Andrey Loskutov:

m2? Do you mean p2? p2 is in the SDK, m2 not.

Am 6. Mai 2022 07:37:49 MESZ schrieb Christian Dietrich 
:

i dont see m2 there

Am 06.05.22 um 07:37 schrieb Andrey Loskutov:
Still here, since ever: 
https://download.eclipse.org/eclipse/downloads/


Am 6. Mai 2022 07:35:23 MESZ schrieb Christian Dietrich 
:

where can one find "eclipse sdk" downloads nowadays?
google does not seem to help

Am 06.05.22 um 02:08 schrieb Jonah Graham:
On Tue, 19 Apr 2022 at 18:26, Jonah Graham 
 wrote:



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


In 4.24 SDK there is the Maven version of asm and asm.tree.
In 2022-06 M2 p2 repo there is Maven version of asm.tree (from 
platform p2 repo) and Orbit version of asm (from Xtext's p2 repo)


  2- Starting from the SDK, does installing features from SimRel
  cause both to be installed, and if so, are both resolved.


Starting with M2 SDK, installing Xtext SDK from 2022-06 M2 simrel 
causes asm.tree from Orbit to be installed:


osgi> ss org.objectweb.asm
"Framework is launched."


id State       Bundle
283 RESOLVED    org.objectweb.asm.tree_9.3.0
374 RESOLVED    org.objectweb.asm_9.3.0.v20220409-0157
Both versions of asm are in my plugins directory after installing 
xtext:


$ ll eclipse/plugins/*asm*
-rw-r--r-- 1 jonah jonah 122176 Apr 28 19:00 
eclipse/plugins/org.objectweb.asm_9.3.0.jar
-rw-rw-r-- 1 jonah jonah 136049 May  5 19:57 
eclipse/plugins/org.objectweb.asm_9.3.0.v20220409-0157.jar
-rw-r--r-- 1 jonah jonah  52669 Apr 28 19:00 
eclipse/plugins/org.objectweb.asm.tree_9.3.0.jar


So is that OK?

___
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



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




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

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

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

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

[Ed Willink]

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

        

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

[Ed Willink]

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 https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/1186

Anybody with a bookmark on bugs.eclipse.org or even 
https://bugs.eclipse.org/bugs/enter_bug.cgi will simply learn that 
JDT is no longer accepting bug reports. End of story. I thought open 
source development is all about communication. Never too old to learn 
better. I'm glad I no longer feel responsible for any of this, 
otherwise I'd have trouble avoiding any bad words ...


Stephan




On 17.04.2022 12:43, Ed Willink wrote:

Hi

The PMI form for JDT at

https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JDT

is no longer able to report a bug. It reports "Sorry, entering a 
bug into the product JDT has been disabled.,,Please press Back and 
try again."


Does this mean that JDT is now perfect and will never have any bugs 
ever again?


    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

--

*Denis Roy*

*Director, IT Services | **Eclipse Foundation*

/Eclipse Foundation/ <http://www.eclipse.org/>/: The Community for 
Open Innovation and Collaboration/


Twitter: @droy_eclipse


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


--
This email has been ch

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

[Ed Willink]

Hi

The PMI form for JDT at

https://bugs.eclipse.org/bugs/enter_bug.cgi?product=JDT

is no longer able to report a bug. It reports "Sorry, entering a bug 
into the product JDT has been disabled.,,Please press Back and try again."


Does this mean that JDT is now perfect and will never have any bugs ever 
again?


    Regards

        Ed Willink


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [cross-project-issues-dev] Declaring Orbit Build: S20220403232146 (2022-06 M1)

[Ed Willink]

Hi

https://bugs.eclipse.org/bugs/show_bug.cgi?id=579584 raised to 
re-instate antlr 3.2.0


https://bugs.eclipse.org/bugs/show_bug.cgi?id=579583 raised to 
re-instate lpg.runtime.java


Regards

Ed Willink

On 04/04/2022 16:35, Christian Dietrich wrote:


ok, i found some some orphans
guice 5 (on 2022-06) needs javax.inject
and org.aopalliance which are both no longer part of 2022-06
i wonder if there is tooling to find more of these inconsistencies

i removed our usage of commons.lang
and updated junit to 4.13.2

gson was broken data in local maven repo

Am 04.04.22 um 16:33 schrieb Jonah Graham:

Hi Christian / Ed / Ed / other Orbit consumers,

> @Jonah does this mean i deed to use 10 repos to get the sum of my 
orbit deps?


No, it means if you rely on the old CVS defined orbit bundles you now 
need to make that reference explicit in your target file (i.e to 
R20201118194144 + S20220403232146 for M1) as the Orbit project is not 
maintaining the old CVS defined bundles anymore.


Using the CVS defined orbit is a risk for the project (and up to the 
project to decide how much of a risk that is). We no longer have the 
sources or build machine of the CVS defined bundles and have for the 
last few years been patching the repo*. Because we don't have a way 
to build those old bundles everytime a modification needed to be made 
it was a lot of manual crafting of p2 repos and modifying metadata.


Here is a concrete example. Orbit's upcoming releases do not want to 
recommend org.apache.log4j 1.2.15 anymore (due to CVEs). That bundle 
version is not in S20220403232146, but its replacement is (1.2.19) 
and no one wants to make another derivative of R20201118194144 that 
has it excluded.


As for specific dependencies identified in this thread:

>org.antlr.runtime/3.2.0.v201101311130
That version is available in R20201118194144 and newer versions 
(3.5.2, and numerous 4.x versions) will be in the recommended 2022-06 
release.


>JUnit 4.12
Also in R20201118194144 and newer versions (4.13.2 and 5.x) will be 
in the recommended 2022-06 release.


> com.google.gson 2.8.9
This is in the 2022-06 M1, so not sure what the issue is here.

> javax.inject
Available in R20201118194144. As of now no one has added 
jakarta.inject (the new name for this bundle) to Orbit's git as an 
EBR. The whole javax -> jakarta transition has lots of its own 
problems that so far are being handled piecemeal (and is part of why 
Mylyn stopped working and has been removed from SimRel).


> commons.lang
Available in R20201118194144. As of now no one has added it to 
Orbit's git as an EBR.


> should we create a bugzilla?
There is one - https://bugs.eclipse.org/bugs/show_bug.cgi?id=568936

I hope that clarifies things. Please ask follow-ups.
Jonah


* 
https://download.eclipse.org/tools/orbit/downloads/drops/R20160520211859/ 
was the last recommended build from CVS, 
https://download.eclipse.org/tools/orbit/downloads/drops/R20201118194144/ 
is the many times patched version of that.





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


On Mon, 4 Apr 2022 at 01:03, Christian Dietrich 
 wrote:


@Jonah does this mean i deed to use 10 repos to get the sum of my
orbit deps?

i am getting

Error: Failed to resolve target definition

/home/runner/work/xtext-reference-projects/xtext-reference-projects/integrationtests/org.eclipse.xtext.integrationtests.target/org.eclipse.xtext.integrationtests.target.target:
Could not find "org.antlr.runtime/3.2.0.v201101311130" in the
repositories of the current location

is that intentional?

Am 04.04.22 um 01:57 schrieb Jonah Graham:

Hello folks,

I am distributing this wider than normal because of the larger
impact of this change. See details below in the quoted emails.

Following the build process on the wiki[0] I'm declaring
S20220403232146 [1,2] as our contribution for SimRel 2022-06 M1 [3].

*Reminder: *As of 2022-06 this is no longer a composite repo.
The final CVS defined bundles are available
in R20201118194144[4]. If you need these old bundles I highly
recommend you add recipes to orbit[5] or change to other options
like the new Maven in PDE option[6]. We don't really have a way
to rebuild these old bundles therefore having your project
depend on them is a risk in your project.

The following changes are new for 2022-06 M1 since  2022-03 R
(sorry for the noisy commits on build scripts - these changes
used to be hidden in configuration changes on Jenkins, but I
migrated all the build scripts to git):

4322974 Bug 569078: GMF Runtime have fixed their SimRel
contribution (fixup)
fe394e5 Merge "Bug 569078: GMF Runtime have fixed their SimRel
contribution"
467effd Bug 568936: Automatically set name/description of build
0ea4906 Bug 568936: Fix typos/syntax error in build scripts
43f6ea5 Bug 569078

Re: [cross-project-issues-dev] Declaring Orbit Build: S20220403232146 (2022-06 M1)

[Ed Willink]

Hi

Because of incompatibilities org.antlr.runtime/3.2.0.v201101311130 is 
the version that a number of tools, probably at least Xtext, ATL, 
Epsilon have 'standarized' on. Is a Bugzilla required to retain it?


I'm not clear why lpg.runtime.java is missing. Is a Bugzilla required to 
rectify an oversight? Are there other contributions that have suffered 
the same erroneous excclusion?


    Regards

        Ed Willink

On 04/04/2022 06:03, Christian Dietrich wrote:


@Jonah does this mean i deed to use 10 repos to get the sum of my 
orbit deps?


i am getting

Error: Failed to resolve target definition 
/home/runner/work/xtext-reference-projects/xtext-reference-projects/integrationtests/org.eclipse.xtext.integrationtests.target/org.eclipse.xtext.integrationtests.target.target: 
Could not find "org.antlr.runtime/3.2.0.v201101311130" in the 
repositories of the current location


is that intentional?

Am 04.04.22 um 01:57 schrieb Jonah Graham:

Hello folks,

I am distributing this wider than normal because of the larger 
impact of this change. See details below in the quoted emails.


Following the build process on the wiki[0] I'm declaring 
S20220403232146 [1,2] as our contribution for SimRel 2022-06 M1 [3].


*Reminder: *As of 2022-06 this is no longer a composite repo. The 
final CVS defined bundles are available in R20201118194144[4]. If you 
need these old bundles I highly recommend you add recipes to orbit[5] 
or change to other options like the new Maven in PDE option[6]. We 
don't really have a way to rebuild these old bundles therefore 
having your project depend on them is a risk in your project.


The following changes are new for 2022-06 M1 since  2022-03 R (sorry 
for the noisy commits on build scripts - these changes used to be 
hidden in configuration changes on Jenkins, but I migrated all the 
build scripts to git):


4322974 Bug 569078: GMF Runtime have fixed their SimRel contribution 
(fixup)
fe394e5 Merge "Bug 569078: GMF Runtime have fixed their SimRel 
contribution"

467effd Bug 568936: Automatically set name/description of build
0ea4906 Bug 568936: Fix typos/syntax error in build scripts
43f6ea5 Bug 569078: GMF Runtime have fixed their SimRel contribution
05613db Bug 568936: Add description to main build process
6fe3fb2 Bug 568936: Add description to main build process
*76a5833 Bug 568936: Add org.apache.xml.resolver recipe *<-- 
highlighted because this is the /only/ bundle change for 2022-06 M1 
vs 2022-03 R

e638e8e Bug 568936: Remove CVS bundles from mirroring and output
bccd811 Bug 568936: Fix name of Jenkinsfile
7569a3d Bug 568936: Fix typos/syntax error in build scripts
09458b8 Bug 568936: The timestamp should be ms since 1970
c3e0f5e Bug 568936: Fix typos/syntax error in build scripts
9502f26 Bug 568936: Composite handling + always promote build
119c3f1 Bug 568936: Fix typos/syntax error in build scripts
74eb7d7 Bug 568936: Fix typos/syntax error in build scripts
556e608 Bug 568936: Fix typos/syntax error in build scripts
1fb1ece Bug 568936: Fix typos/syntax error in build scripts
19fce78 Bug 568936: Fix typos/syntax error in build scripts
ed3f604 Bug 568936: Remove CVS sourced bundles from Orbit
e355dbf Bug 568936: Move Jenkinsfile and used scripts into source control
105e5c4 Bug 569078: Make a limited version of bundles from Orbit for 
SimRel (fixup)
b544c64 Bug 569078: Make a limited version of bundles from Orbit for 
SimRel

37f3210 Build against Eclipse 4.23
8d3e517 Update reference repository to 2022-03 R release

As for the comparing repos - Roland has provided me details which I 
added to the Wiki[0] - but it is non trivial for me to run at the 
moment. Please let me know if you are able to help out by providing 
that info.


[0] 
https://wiki.eclipse.org/Orbit/Promotion,_Release,_and_Retention_Policies#Milestone_Release_Process
[1] 
https://download.eclipse.org/tools/orbit/downloads/drops/S20220403232146/repository/ <-- 
this release

[2] https://download.eclipse.org/tools/orbit/downloads/2022-06/
[3] https://wiki.eclipse.org/Category:SimRel-2022-06
[4] 
https://download.eclipse.org/tools/orbit/downloads/drops/R20201118194144/ 
<-- old CVS repo!

[5] https://wiki.eclipse.org/Orbit/Adding_Bundles_To_Orbit_In_5_Minutes
[6] I'm not sure what the best link for this is - but Eclipse 
Platform does it here 
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/7aa6ff4ba08601f8e5152a95d29b248e490f5fe8/eclipse.platform.releng.prereqs.sdk/eclipse-sdk-prereqs.target#L239


Thanks,
Jonah

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


On Tue, 22 Feb 2022 at 22:32, Jonah Graham  
wrote:


Hello folks,

Starting with 2022-06 M1 the Orbit repo will no longer be a
composite repo combining the old CVS build with the latest git
based build.

The 2022-03 recommended build will be the last to contain these
old CVS bundles.

Please comment on the bug if this causes 

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

[Ed Willink]

Hi

At present I do not know how I can readily test a pre-Maven either 
locally or remotely. (The "Invoke top level target" does not offer the 
ability to invoke Maven from a script or to have a pre-script, so I 
guess to use your scriptlet, a variant job would have to be created 
reverting to the old script driven approach.)


My suggestion was absolutely not to add 3.8.5, but:

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


Hardly a one-shot. I have at least four jobs that I could try it on. And 
since we seem to be getting some bad feedback, re-runs might well be 
necessary to debug.


Bottom line: developer has something that needs testing. As a user, I am 
prepared to take easy actions to help. I am not going to spend time 
learning new technology. Please be helpful to the developer by helping 
the user. An alternate pull-down is easy and probably achieves the 
intended change first time - takes a minute - half an hour later I can 
inspect the result. Hacking jobs and scripts is not easy, almost 
certainly some debugging to do, probably the start of a bad day.


    Regards

        Ed Willink

On 07/03/2022 12:38, Mikael Barbero wrote:
Given that 3.8.5 is not released yet, I'm not keen on adding it to 
Foundation's Jenkins.


Also, as I guess it would be for a one shot test, it's just as easy 
for projects to test their build locally.


If you *really* want to test in your Jenkins pipeline, maven's .tar.gz 
can always be downloaded as part of your job and unarchived somewhere 
in your workspace:


$ curl -sSJOLf 
https://dist.apache.org/repos/dist/dev/maven/maven-3/3.8.5/binaries/apache-maven-3.8.5-bin.tar.gz

$ tar zxf apache-maven-3.8.5-bin.tar.gz
$ export PATH="$(pwd)/apache-maven-3.8.5/bin:${PATH}"
$ mvn -v
Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)
...

which not much more than changing your pipeline to select a different 
version of the "maven" jenkins tooling.




*Mikaël Barbero *
*Manager — Release Engineering and Technology | Eclipse Foundation*
 @mikbarbero
Eclipse Foundation <http://www.eclipse.org/>: The Platform for Open 
Innovation and Collaboration


On 6 Mar 2022, at 11:04, Dietrich, Christian 
 wrote:


Can this be provided on Jenkins ?

Christoph Läubrich  schrieb am So. 6. März 
2022 um 10:24:


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

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

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

[Ed Willink]

Hi

Ah!. There is a Maven Runtime pull-down in the m2e arbitrated launch 
configuration. But it only offers 3.8.4 so the pita is how to persuade 
the launch config to see alternative Mavens. It has a Configure button 
but this doesn't seem to help with non-standard locations.


    Regards

        Ed Willink

On 07/03/2022 08:43, Ed Willink wrote:

Hi

To me it's all fairly magic. But I assume that somehow something gets 
fetched from Maven Central since there is no ZIP to install as for 
normal Eclipse add-ons and so no sources to help with debugging.


I cannot see anything in my pom.xml that controls it, so I suspect 
what ever happens is built-in to m2e and then checked by:


  
    org.apache.maven.plugins
    maven-enforcer-plugin
    ${maven-enforcer-version}
    
  
    enforce-versions
    
  enforce
    
    
  
    
  3.6.3
    
    
  
    
  
    
  

    Regards

        Ed Willink


On 07/03/2022 08:09, Christoph Läubrich wrote:

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 



   

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

[Ed Willink]

Hi

To me it's all fairly magic. But I assume that somehow something gets 
fetched from Maven Central since there is no ZIP to install as for 
normal Eclipse add-ons and so no sources to help with debugging.


I cannot see anything in my pom.xml that controls it, so I suspect what 
ever happens is built-in to m2e and then checked by:


  
    org.apache.maven.plugins
    maven-enforcer-plugin
    ${maven-enforcer-version}
    
  
    enforce-versions
    
  enforce
    
    
  
    
  3.6.3
    
    
  
    
  
    
  

    Regards

        Ed Willink


On 07/03/2022 08:09, Christoph Läubrich wrote:

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

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

[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


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

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

[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


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

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

[Ed Willink]

Hi

Thanks. The explanation reassures me.

    Regards

        Ed Willink

On 24/02/2022 15:18, Jonah Graham wrote:


On Thu, 24 Feb 2022 at 03:55, Ed Willink  wrote:

Hi

Ouch!. It seems like these are manually maintained and so subject
to human fallibility.

Not "Ouch!" but by design. Please see my reply to Martin's original 
question.


If "latest" is to be useful, it must be automatic.


The latest is automated - covered as part of the releng steps[1] that 
I reference in my Orbit announcements[2]


[1] 
https://wiki.eclipse.org/Orbit/Promotion,_Release,_and_Retention_Policies#Milestone_Release_Process

[2] https://www.eclipse.org/lists/orbit-dev/msg05550.html

It makes sense to reference multiple repos, as in my cut and paste
from my S-build that referenced both latest-S and latest-R Orbit,
since latest-S is usually the most recent except just after a
release when latest-R may be later (unless a gratuitous S-build
immediately followed the R-build).

However multiple explicit references seems crazy especially when
they are so stale.

Please see my email about removal of CVS built bundles from the p2. If 
you still refer to these old Orbit bundles you will need to keep a 
reference to an older Orbit repo in your target platform, or update 
your dependencies.


HTH,
Jonah

    Regards

            Ed Willink

On 24/02/2022 08:27, Martin Lippert wrote:

Hey!

Quick question:
why do those update sites refer to the latest S or R builds AS
WELL AS a specific release repo from 2020 ?

The content of the latest-S looks like:




Any idea why the R20201118194144 repo is included here?

Cheers
Martin




Am 24.02.2022 um 06:47 schrieb Ed Willink :

Hi

For those needing to update: Orbit now has:

    https://download.eclipse.org/tools/orbit/downloads/latest-S;
<https://download.eclipse.org/tools/orbit/downloads/latest-S>/>
    https://download.eclipse.org/tools/orbit/downloads/latest-R;
<https://download.eclipse.org/tools/orbit/downloads/latest-R>/>

so there is no need to update ever again. Just rebuild.

        Regards

        Ed Willink

On 24/02/2022 02:13, Jonah Graham wrote:

Hi folks,

I have now checked and the EPP packages that have
org.apache.log4j now have the 1.2.19 reload4j version.

Some progress has already been made on the bugs, so with a bit
more work we can have the whole simrel free of the 1.2.15
version of log4j.

However, individual projects need to update to the newest Orbit
version and rebuild. Numerous projects still have the 1.2.15
version in their p2 repos.

Thanks,
Jonah

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


On Wed, 23 Feb 2022 at 12:22, Jonah Graham
 wrote:

Hi folks,

The SimRel release will include the reload4j version of the
bundle. Most p2 install resolutions will pull in the
reload4j version.

However it also includes the 1.2.15 version because of some
hard dependencies on the 1.2.15 version (Bug 578940
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=578940> Bug
578941 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=578941>)

When I do the EPP build I will verify/report whether any of
the packages contain the 1.2.15 version.

Jonah


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


On Wed, 16 Feb 2022 at 03:04, Dirk Fauth via
cross-project-issues-dev
 wrote:

Just as an information for people that did not get the
current status via other channels.

The re-bundled version of reload4j is available in the
latest stable build of Eclipse Orbit.

Logpresso has added handling for the re-bundled variant
and will not detect the vulnerability in its latest
version.

Christian Dietrich 
schrieb am Di., 8. Feb. 2022, 17:18:

yes i tried to use the pomDependencies consider
features
https://git.eclipse.org/r/c/orbit/orbit-recipes/+/190576

https://ci.eclipse.org/orbit/job/gerrit-orbit-recipes/1782/artifact/releng/repository-all/target/repository/
but i get signing warning and also naming
conventions etc
are completely "bogus"

Am 08.02.22 um 17:16 schrieb Ed Merks:


Christian,

I *assume *it is not jar signed but rather only
has an external PGP signature.

Regards,...
Ed

On 08.02.2022 16:48, Christian Dietrich wrote:


is the orginal signing not enhou

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

[Ed Willink]

Hi

Ouch!. It seems like these are manually maintained and so subject to 
human fallibility.


If "latest" is to be useful, it must be automatic.

It makes sense to reference multiple repos, as in my cut and paste from 
my S-build that referenced both latest-S and latest-R Orbit, since 
latest-S is usually the most recent except just after a release when 
latest-R may be later (unless a gratuitous S-build immediately followed 
the R-build).


However multiple explicit references seems crazy especially when they 
are so stale.


    Regards

        Ed Willink

On 24/02/2022 08:27, Martin Lippert wrote:

Hey!

Quick question:
why do those update sites refer to the latest S or R builds AS WELL AS 
a specific release repo from 2020 ?


The content of the latest-S looks like:




Any idea why the R20201118194144 repo is included here?

Cheers
Martin




Am 24.02.2022 um 06:47 schrieb Ed Willink :

Hi

For those needing to update: Orbit now has:

    location="https://download.eclipse.org/tools/orbit/downloads/latest-S"/>
    location="https://download.eclipse.org/tools/orbit/downloads/latest-R"/>


so there is no need to update ever again. Just rebuild.

    Regards

        Ed Willink

On 24/02/2022 02:13, Jonah Graham wrote:

Hi folks,

I have now checked and the EPP packages that have org.apache.log4j 
now have the 1.2.19 reload4j version.


Some progress has already been made on the bugs, so with a bit more 
work we can have the whole simrel free of the 1.2.15 version of log4j.


However, individual projects need to update to the newest Orbit 
version and rebuild. Numerous projects still have the 1.2.15 version 
in their p2 repos.


Thanks,
Jonah

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


On Wed, 23 Feb 2022 at 12:22, Jonah Graham  
wrote:


Hi folks,

The SimRel release will include the reload4j version of the
bundle. Most p2 install resolutions will pull in the reload4j
version.

However it also includes the 1.2.15 version because of some hard
dependencies on the 1.2.15 version (Bug 578940
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=578940> Bug
578941 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=578941>)

When I do the EPP build I will verify/report whether any of the
packages contain the 1.2.15 version.

Jonah


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


On Wed, 16 Feb 2022 at 03:04, Dirk Fauth via
cross-project-issues-dev 
wrote:

Just as an information for people that did not get the
current status via other channels.

The re-bundled version of reload4j is available in the
latest stable build of Eclipse Orbit.

Logpresso has added handling for the re-bundled variant and
will not detect the vulnerability in its latest version.

Christian Dietrich  schrieb am
Di., 8. Feb. 2022, 17:18:

yes i tried to use the pomDependencies consider features
https://git.eclipse.org/r/c/orbit/orbit-recipes/+/190576

https://ci.eclipse.org/orbit/job/gerrit-orbit-recipes/1782/artifact/releng/repository-all/target/repository/
but i get signing warning and also naming conventions etc
are completely "bogus"

Am 08.02.22 um 17:16 schrieb Ed Merks:


Christian,

I *assume *it is not jar signed but rather only has an
external PGP signature.

Regards,...
Ed

On 08.02.2022 16:48, Christian Dietrich wrote:


is the orginal signing not enhough?
and what about about.html and other eclipse rule foo.

Am 08.02.22 um 16:32 schrieb Matthias Sohn:

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

On Tue, Feb 8, 2022 at 4:04 PM Dirk Fauth via
cross-project-issues-dev
 wrote:

Well, from my point of view the usage of reload4j
is the only backwards compatible solution.
Unfortunately not for every case, e.g. too strict
version ranges. The solution forward is of course
the usage of a log wrapper to decouple
development from deployment.

Anyhow I don't know how to add a bundle jar
signed and unchanged to Orbit. I am only aware of
the re-bundling via EBR. Doing that will cause a
change in the jar structure that causes for
example logpresso to identify a CVE,

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

[Ed Willink]

Hi

For those needing to update: Orbit now has:

    location="https://download.eclipse.org/tools/orbit/downloads/latest-S"/>
    location="https://download.eclipse.org/tools/orbit/downloads/latest-R"/>


so there is no need to update ever again. Just rebuild.

    Regards

        Ed Willink

On 24/02/2022 02:13, Jonah Graham wrote:

Hi folks,

I have now checked and the EPP packages that have org.apache.log4j now 
have the 1.2.19 reload4j version.


Some progress has already been made on the bugs, so with a bit more 
work we can have the whole simrel free of the 1.2.15 version of log4j.


However, individual projects need to update to the newest Orbit 
version and rebuild. Numerous projects still have the 1.2.15 version 
in their p2 repos.


Thanks,
Jonah

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


On Wed, 23 Feb 2022 at 12:22, Jonah Graham  wrote:

Hi folks,

The SimRel release will include the reload4j version of the
bundle. Most p2 install resolutions will pull in the reload4j
version.

However it also includes the 1.2.15 version because of some hard
dependencies on the 1.2.15 version (Bug 578940
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=578940> Bug 578941
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=578941>)

When I do the EPP build I will verify/report whether any of the
packages contain the 1.2.15 version.

Jonah


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


On Wed, 16 Feb 2022 at 03:04, Dirk Fauth via
cross-project-issues-dev  wrote:

Just as an information for people that did not get the current
status via other channels.

The re-bundled version of reload4j is available in the latest
stable build of Eclipse Orbit.

Logpresso has added handling for the re-bundled variant and
will not detect the vulnerability in its latest version.

Christian Dietrich  schrieb am
Di., 8. Feb. 2022, 17:18:

yes i tried to use the pomDependencies consider features
https://git.eclipse.org/r/c/orbit/orbit-recipes/+/190576

https://ci.eclipse.org/orbit/job/gerrit-orbit-recipes/1782/artifact/releng/repository-all/target/repository/
but i get signing warning and also naming conventions etc
are completely "bogus"

Am 08.02.22 um 17:16 schrieb Ed Merks:


Christian,

I *assume *it is not jar signed but rather only has an
external PGP signature.

Regards,...
Ed

On 08.02.2022 16:48, Christian Dietrich wrote:


is the orginal signing not enhough?
and what about about.html and other eclipse rule foo.

Am 08.02.22 um 16:32 schrieb Matthias Sohn:

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

On Tue, Feb 8, 2022 at 4:04 PM Dirk Fauth via
cross-project-issues-dev
 wrote:

Well, from my point of view the usage of reload4j
is the only backwards compatible solution.
Unfortunately not for every case, e.g. too strict
version ranges. The solution forward is of course
the usage of a log wrapper to decouple development
from deployment.

Anyhow I don't know how to add a bundle jar signed
and unchanged to Orbit. I am only aware of the
re-bundling via EBR. Doing that will cause a change
in the jar structure that causes for example
logpresso to identify a CVE, although it is fixed.
Which is actually only an issue in the detection.
But that was one of the reasons why I contacted the
reload4j project to change the base to avoid the
re-bundling.

Anyone who knows how to only sign and publish to
Orbit without re-bundling?

Ed Merks  schrieb am Di., 8.
Feb. 2022, 15:54:

Dirk,

Thanks.  That's really great!  It would be
great for this release cycle if it were jar
signed and available from Orbit so that we
could ship it with 2022-03...

There are people who are concerned:


https://www.eclipse.org/forums/index.php/mv/msg/1109656/1849775/#msg_1849775

Though I'm not sure if they would consider the
 

[cross-project-issues-dev] +0.0.1 rather than +0.1.0 for OCL, QVTd for 2022-03

[Ed Willink]

Hi

The current work on static operations (and properties) to support custom 
OCL libraries is not sufficiently mature for 2022-03. OCL (and QVTd) 
will therefore release 6.17.1 and 0.28.1 for 2022-03 rather than 6.18.0, 
0.29.0.


For M3, the 6.17.0 and 0.28.0 releases are re-contributed.

For RC1, 6.17.1 and 0.28.1 will appear with just minor bug fixes.

This change should not affect anyone, apart from Wayne's stats, since 
hopefully nobody has a tight version lower bound.


@Wayne: PMI pages already updated.

    Regards

        Ed Willink


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

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

[Ed Willink]

Hi

On 26/01/2022 07:48, Christoph Läubrich wrote:
Why not using SLF4J in all places and let the user choose the 
implementation with their favorite CVEs?


Use of SLF4J has been suggested before and so I tried to be a good 
Eclipse citizen. My failed attempts are described in:


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

If SLF4J is to be used, can someone please ensure that the platform is 
fit for purpose and that there is a good tutorial on how to do really 
boring logging.


Regards

Ed Willink


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

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

[Ed Willink]

On 14/01/2022 09:08, Ed Merks wrote:
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...


A similar situation exists for OCL and QVTo.

OCL should use the same version of Guava as 'everyone else' so OCL 
relies on the Xtext to provide it without imposing any version bounds. 
Known relevant Guava incompatibilities are accommodated by replacing 
incompatible functionality with local implementations.


Similarly ASM is re-used from the platform but with a lower bound to 
exclude a known API incompatibility. The upper bound was removed after 
ASM took to throwing new versions for each new Java version.


However for LPG, which few other projects use, OCL redistributes LPG. 
QVTo consumes the same version as OCL.


The imported version may be random, in so far as OCL / QVTo have no idea 
which version is in use, but it's consistent and users should see the 
version that was tested. Testing of the latest OCL distribution on 
Oxygen and later platforms provides some opportunity for detecting 
incompatible dependencies.


Over the years, it was my impression that the need to redistribute LPG 
was precisely because Orbit was not (transitively) available when 
performing an Install New Software... from SimRel.


It would therefore seem that the longstanding and desirable practice of 
excluding Orbit has been undermined by who/whatever is providing it. If 
nothing else, providing it costs users unnecessary download time on a 
large index and may provide many opportunities for ambiguous 
better/slower P2 install solutions.


Please, let's revert to our longstanding practice that Orbit is not 
transitively available in SimRel.


    Regards

        Ed Willink




--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] CVS support plugin discontinuation - SimRel build changes needed

[Ed Willink]

Hi Jonah

You haven't explained why Modisco or Parsley were disabled or why there 
was no discussion prior to such a widespread unnecessary disabling.


Yes the disabling has eventually been reverted, but unfortunately there 
was an 8 hour delay between the Gerrit that reverted and the actual 
merge. IMHO until the merge occurs, there was no reversion.


Regards

Ed Willink


On 08/01/2022 15:33, Jonah Graham wrote:

Hi Eike,

Actually CDO does depend on Mylyn, and therefore (until 2021-12) on CVS:

EMF CDO depends on EMF Compare's contribution:
org.eclipse.emf.cdo.compare -> org.eclipse.emf.compare

EMF Compare depends on EGit's contribution:
org.eclipse.emf.compare.egit ->  org.eclipse.jgit

EGit depends on Mylyn's contribution:
org.eclipse.mylyn.github.feature.feature.group 
-> org.eclipse.mylyn_feature.feature.group
(Note that despite the name 
org.eclipse.mylyn.github.feature.feature.group  is contributed by EGit 
to simrel)


The difference is the granularity of the dependencies. For 
SimRel dependencies are normally handled at the contribution level. At 
the feature/bundle level there may indeed be no dependencies from CDO 
-> Mylyn/CVS, but with many contributions being interdependent on each 
other, and Mylyn historically cutting across so many projects, 
something that disabled Mylyn causes many things to be easily disabled.


Of course this problem is hindered by Mylyn being under-resourced at 
the moment.


I hope that helps,
Jonah


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


On Sat, 8 Jan 2022 at 10:01, Eike Stepper  wrote:

Thanks for your explanation. But, for the record, CDO does not
dpened, neither directly nor transitively on anything from Mylyn
or from CVS.

Cheers
/Eike


http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Am 08.01.2022 um 15:35 schrieb Kit Lo:


Eike / Ed W. / Lorenzo / Team,

Let me clarify. While contributing Eclipse Project M1 to SimRel
2022-03 M1, SimRel Aggregator Validation found many dependency
issues "directly" or "indirectly" related to the removal of CVS
in Eclipse Project. Mylyn was the first offender. After disabling
Mylyn, all the other downstream projects also needed to be
disabled because they were "directly" or "indirectly" affected by
the removal of CVS and/or Mylyn.

Thanks to Jonah's analysis, most/all of the downstream projects
were affected by Mylyn. Once Mylyn fixed their CVS dependency,
Jonah was able to enable most/all the other downstream projects.

Sorry for the inconvenience and the alarm caused by the change!

Regards,
Kit Lo
Eclipse Babel Project Lead
IBM Eclipse SDK (IES) Technical Lead and Release Manager

Inactive hide details for "Lorenzo Bettini" ---01/08/2022
05:56:28 AM---Same for EMF Parsley: how did you find the CVS
dependen"Lorenzo Bettini" ---01/08/2022 05:56:28 AM---Same for
EMF Parsley: how did you find the CVS dependency? Il Sab 8 Gen
2022, 07:16 Ed Willink 
<mailto:lorenzo.bett...@gmail.com>
To: "Cross project issues" 
<mailto:cross-project-issues-dev@eclipse.org>
Date: 01/08/2022 05:56 AM
Subject: Re: [cross-project-issues-dev] CVS support plugin
discontinuation - SimRel build changes needed
Sent by: "cross-project-issues-dev"

<mailto:cross-project-issues-dev-boun...@eclipse.org>

--------



Same for EMF Parsley: how did you find the CVS dependency?

Il Sab 8 Gen 2022, 07:16 Ed Willink <_ed.willink@gmail.com_
<mailto:ed.will...@gmail.com>> ha scritto:

Hi

Ditto for Modisco. My OOMPH generated Modisco installation is
totally free of even transitive dependencies on CVS so there
must be a fault in your dependency analysis.
Surely such a dramatic disabling should have been
investigated on the Gerrit / a prvate branch and then
    discussed? Why was it merged to master? Why has it not yet
been reverted?

 Regards

    Ed Willink

On 08/01/2022 05:25, Eike Stepper wrote:

@Jonah Thanks for re-enabling CDO!

@Kit How did you establish that CDO depends (possibly
transitively) on CVS? The bundle manifests of CDO do not
contain anything to that extent, and in my target
platform for CDO there are no CVS bundles.

Cheers
/Eike

_
__http://www.esc-net.de_ <http://www.esc-net.de>_
__http://thegordian.blogspot.com_
<http://thegordian.blogspot.com>_
__http://twitter.com/eikestepper_
<http://twitter.com/eikestepper>


   

Re: [cross-project-issues-dev] CVS support plugin discontinuation - SimRel build changes needed

[Ed Willink]

Hi

Ditto for Modisco. My OOMPH generated Modisco installation is totally 
free of even transitive dependencies on CVS so there must be a fault in 
your dependency analysis.


Surely such a dramatic disabling should have been investigated on the 
Gerrit / a prvate branch and then discussed? Why was it merged to 
master? Why has it not yet been reverted?


 Regards

    Ed Willink

On 08/01/2022 05:25, Eike Stepper wrote:

@Jonah Thanks for re-enabling CDO!

@Kit How did you establish that CDO depends (possibly transitively) on 
CVS? The bundle manifests of CDO do not contain anything to that 
extent, and in my target platform for CDO there are no CVS bundles.


Cheers
/Eike


http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Am 07.01.2022 um 23:21 schrieb Jonah Graham:

Hi folks,

I have reenabled all the projects as the failures were due to 
transitive dependencies on Mylyn. For Mylyn I have disabled the CVS 
related/dependent features only. AFAICT (validation passes, 
waiting for full build) this should be the full solution so none of 
the other projects need to do anything this time.


See https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/189399

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


On Fri, 7 Jan 2022 at 17:11, Jonah Graham  wrote:

Thanks Kit!

It looks like we have quite a few dependencies to resolve here
:-) CDT doesn't directly depend on CVS, perhaps there is a
transient dependency that does though.

Does anyone know which of these directly depend on CVS? I am
trying to figure it out now and hope to make a new contribution
soon if possible with a smaller set of disabled projects
by removing individual features.

PS Thank you for making such a large change in M1 - it gives all
the downstream consumers more time to actually understand the
implication of the earlier announced changes.

Jonah

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


On Fri, 7 Jan 2022 at 16:54, Kit Lo  wrote:

As announced in
https://www.eclipse.org/lists/cross-project-issues-dev/msg18643.html
<https://www.eclipse.org/lists/cross-project-issues-dev/msg18643.html> 
Eclipse
Platform project has stopped building CVS. While contributing
to SimRel 2022-03 M1 we found some projects are dependent on
CVS causing SimRel build to fail. To make SimRel work we
ended up disabling multiple projects. Please re-enable them
once the support for CVS has been disabled. Here is the list
of projects that were disabled:

- cdt
- dltk
- egit
- embedcdt
- emf-cdo
- emf-compare
- emf-parsley
- linuxtools
- m2m-atl
- modisco
- mylyn
- oomph
- pdt
- ptp
- tcf
- tracecompass

Thank you!

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


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Ed Willink]

Hi

Maybe the CVE is also misleading or the discussion here is very wrong. 
The current Orbit repo contains


org.apache.log4j 1.2.15 is clearly not log4j2. It has been in use 
unchanged in every Eclipse distribution for at least the last ten years.


The analysis on this thread has been about org.apache.logging.log4j 
which could be a log4j2. It is unused in core and many Eclipse 
configurations.


Please be precise.

Regards

Ed Willink

On 13/12/2021 19:33, Denis Roy wrote:


The CVE shows: Apache Log4j2

I would assume that is correct.


On 2021-12-13 14:31, Ed Willink wrote:


Hi

Please start by correctly referencing the vulnerability.

It is with org.apache.logging.log4j,

There is no issue with org.apache.log4j so continually referring to 
this as a log4j vulnerability is very misleading.


AFAICT no Eclipse installation of mine has ever included 
org.apache.logging.log4j.


Regards

Ed Willink

On 13/12/2021 19:15, Denis Roy wrote:


How about I start:


title: *Eclipse and log4j vulnerability **(CVE-2021-442280)*

Here is the status of the various Eclipse Foundation projects, with 
regards to CVE-2021-442280:



- Eclipse IDE 2021-12: *not vulnerable*

- Eclipse Jetty (version): status

- Eclipse GlassFish (version): status

- Eclipse jGit (version): status


We would likely need to get the input from other projects, to 
"self-certify".  I can do this by reaching out to 
eclipse.org-committers if anyone agrees.


At this point, most of Europe is logged out for the day, and time is 
ticking away fast for this sort of action.



Denis





On 2021-12-13 14:00, Jonah Graham wrote:

Hi Denis,

Yes - that seems best. I can help with the actual story - as can 
others on this list (I hope :-).


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


On Mon, 13 Dec 2021 at 13:58, Denis Roy 
 wrote:


Good question.

If we agree on a story (ie, if someone can help me write 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  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

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

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.
 

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

[Ed Willink]

Hi

Please start by correctly referencing the vulnerability.

It is with org.apache.logging.log4j,

There is no issue with org.apache.log4j so continually referring to this 
as a log4j vulnerability is very misleading.


AFAICT no Eclipse installation of mine has ever included 
org.apache.logging.log4j.


Regards

Ed Willink

On 13/12/2021 19:15, Denis Roy wrote:


How about I start:


title: *Eclipse and log4j vulnerability **(CVE-2021-442280)*

Here is the status of the various Eclipse Foundation projects, with 
regards to CVE-2021-442280:



- Eclipse IDE 2021-12: *not vulnerable*

- Eclipse Jetty (version): status

- Eclipse GlassFish (version): status

- Eclipse jGit (version): status


We would likely need to get the input from other projects, to 
"self-certify".  I can do this by reaching out to 
eclipse.org-committers if anyone agrees.


At this point, most of Europe is logged out for the day, and time is 
ticking away fast for this sort of action.



Denis





On 2021-12-13 14:00, Jonah Graham wrote:

Hi Denis,

Yes - that seems best. I can help with the actual story - as can 
others on this list (I hope :-).


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


On Mon, 13 Dec 2021 at 13:58, Denis Roy 
 wrote:


Good question.

If we agree on a story (ie, if someone can help me write 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  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

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

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

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

[Ed Willink]

Hi

The title of this thread is confusing.

It appears that there is a concern with org.apache.logging.log4j.

To me log4J is org.apache.log4j that has been in use by numerous Eclipse 
projects unchanged for over 10 years.


e.g. org.eclipse.quinox.p2.ui, org.eclipse.gef, 
org.eclipse.emf.common.ui, org.eclipse.pde.ui, org.eclipse.ui


AFAICT this thread requires no action in regard to org.apache.log4j.

    Regards

        Ed Willink

On 10/12/2021 18:46, Denis Roy wrote:


Hi Folks,

As you may be aware, an important vulnerability has been discovered in 
log4j


If I recall, log4j is used in Eclipse components.  Does anyone have a 
feel for our current state? Is 2021-12 affected?


https://arstechnica.com/information-technology/2021/12/minecraft-and-other-apps-face-serious-threat-from-new-code-execution-bug/


Denis



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


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Retention time for SimRel releases

[Ed Willink]

Hi

When we were on a yearly cadence, the last two releases was two years 
which was kind of reasonable.


Now 2 years means 8 releases in order to accommodate the many users who 
don't change frequently. 2 releases is far too few.


    Regards

        Ed Willink

On 19/11/2021 10:01, Frederic Gurr wrote:

Hi,

Since SimRel (and EPP) release bits are accessed a lot more (and usually
for a longer period of time) than other files, I think it makes sense to
keep more releases (e.g. the last 8) on download.eclipse.org and the
mirrors.

@Denis: can you confirm my assumption with any numbers? or are the
download numbers for releases older than the last two also insignificant
for SimRel and EPP releases?

Regards,

Fred

On 19.11.21 10:37, Aleksandar Kurtakov wrote:


On Thu, Nov 18, 2021 at 7:43 PM Frederic Gurr
mailto:frederic.g...@eclipse-foundation.org>> wrote:

 Hi,

 On https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/78
 ("Download.e.o size too big for mirrors"), Aleksandar Kurtakov pointed
 out, that a big chunk of disk space is taken by the content of the
 https://download.eclipse.org/releases folder.

 It currently contains all SimRel releases from "Europa" to 2021-12
 taking up ~100GB. As a first step the mirrors exclude list has been
 modified so all releases up to "Mars" are not mirrored.

 I'm planning to move all releases from "Europa" to 2019-12 to
 archive.eclipse.org <http://archive.eclipse.org> next week. So only
 the last 8 releases will stay on
 download.eclipse.org <http://download.eclipse.org>. I will add the
 task to move old releases to
 archive.eclipse.org <http://archive.eclipse.org> to the release
 check list
 https://wiki.eclipse.org/SimRel/Release_Checklist.

 Please let me know if you have any questions or concerns.


In https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/78 it's
written "download.e.o must only contain the last 2 releases. Older
releases must be moved to archives". IMHO it would be good if this is
either enforced that way for everything(!) or changed to some other
number (for which there is agreement it makes sense) and again enforced.
  



 Regards,

 Fred

 --
 Frederic Gurr
 Release Engineer | Eclipse Foundation Europe GmbH

 Berliner Allee 47, D-64295 Darmstadt
 Handelsregister: Darmstadt HRB 92821
 Managing Directors: Gaël Blondelle, Mike Milinkovich
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 <mailto: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



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

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

[Ed Willink]

Hi

IIRC after many similar occurrences in the past, it was pointed out that 
+3 is not a not-before-date. If a project makes a major version change 
then it can and almost certainly should provide a preliminary 
contribution with updated versions well before +0, at perhaps -2 or even 
-14.


    Regards

        Ed Willink

On 07/10/2021 07:57, Ed Merks wrote:


Hi,

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


Note that EGit/JGit has very few things on which it depends but quite 
a few things depend on it:


In retrospect, it also seems kind of pointless to put upper bounds on 
the EGit/JGit dependencies.  E.g., CDT isn't broken because it only 
has no upper limit...  EMF compare has mostly removed the upper limits 
as well, at least from the bundles...


I've made the necessary changes in Oomph, including changing Oomph's 
build to use https://download.eclipse.org/egit/updates-stable-nightly 
such that the builds will fail earlier the next time APIs actually break:


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

I've re-enabled Oomph's SimRel contribution.

Please respin the SimRel repo to include the contribution and please 
revert the removal changes from EPP packages and respin those as well.


Sorry for the inconvenience.

Regards,
Ed


On 06.10.2021 23:57, Jonah Graham wrote:

Thanks Mathias.

(cc epp-dev)

Note that if these projects don't contribute new versions in the next 
couple of hours I'll disable those features in EPP.


I'm not too concerned about emf being disabled for M1, not sure 
effect of oomph though. Does that mean no installer for M1?


Hopefully someone will weigh in on that.

Thanks,
Jonah




On Wed., Oct. 6, 2021, 17:14 Matthias Sohn,  
wrote:


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

- org.eclipse.emf.compare.egit requires org.eclipse.jgit
[4.9.0,6.0.0) which is not available anymore
since we bumped jgitand egit to 6.0.0 for 2021-12.
- org.eclipse.oomph.setup.sdk requires jgit/egit [5.12.0,5.13.0)

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

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

22:51:10 [0]Missing requirement: Git integration for Eclipse
- Core 5.12.0.202106070339-r (org.eclipse.egit.core
5.12.0.202106070339-r) requires 'java.package;
org.eclipse.jgit.annotations [5.12.0,5.13.0)' but it could
not be found
22:51:10
22:51:10 JavaPackage(org.eclipse.jgit.annotations
[5.12.0,5.13.0)) is required by:
22:51:10 ValidationSet(main)
22:51:10 Contribution(Oomph)
22:51:10

MappedRepository(https://download.eclipse.org/oomph/drops/milestone/S20211006-051210-1.23.0-M1)
22:51:10 Feature(org.eclipse.oomph.setup.sdk.feature.group)
22:51:10
InstallableUnit(org.eclipse.oomph.setup.git.feature.group
1.20.0.v20210924-1427)
22:51:10 InstallableUnit(org.eclipse.oomph.setup.git
1.20.0.v20210924-1427)
22:51:10 InstallableUnit(org.eclipse.egit.core
5.12.0.202106070339-r)

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

Hi Matthias,

IMHO you should disable emf compare with an announcement
to this list that you did so.

Hopefully that isn't a can of worms - the worms being if
EMF Compare has dependencies.

Jonah


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


On Wed, 6 Oct 2021 at 16:37, Matthias Sohn
 wrote:

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

22:27:06 [0]Missing requirement: EMF Compare EGit
Support 1.2.4.202107200824
(org.eclipse.emf.compare.egit 1.2.4.202107200824)
requires 'osgi.bundle; org.eclipse.jgit
[4.9.0,6.0.0)' but it could not be found
22:27:06
22:27:06 Bundle(org.eclipse.jgit [4.9.0,6.0.0)) is
required by:
22:27:06   ValidationSet(main)
22:27:06     Contribution(EMF Compare)
22:27:06      

MappedRepository(https://download.eclipse.org/modeling/emf/compare/updates/milestones/3.3/S202107200824)
22:27:06
Feature(org.eclipse.emf.compare.egit.feature

Re: [cross-project-issues-dev] download.eclipse.org unavailable

[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 
<https://download.eclipse.org/tools/orbit/downloads/latest-I> to return, 
and 50 hours before projects-storage.eclipse.org 
<mailto:genie.modi...@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 
<mailto:genie.modi...@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





--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] git rollback?

[Ed Willink]

Hi Mikael

At least two projects are reporting what appears to be a GIT roll back 
to a backup state.


The time of the outage is therefore less interesting than the time of 
the backup state that determines what is, at least currently, lost.


    Regards

        Ed Willink

On 04/08/2021 13:11, Mikael Barbero wrote:
The last weekend's outage was on our primary backend storage (where 
repos hosted at git.eclipse.org <http://git.eclipse.org> are stored). 
The outage started at 9:20pm/9:30pm EDT on July 31st.


Since then, live replicas have been rsync'd back. What you see is 
apparent data loss. I don't have any information whether this is due 
to how the storage has been restored. I cannot tell you if we have 
more up-to-date data that could be restored for your git repo.


Hopefully, the date/time of the outage given above should help you 
gather the required clues to bring back a working git repo.



*Mikaël Barbero *
*Manager — Release Engineering and Technology | Eclipse Foundation*
 @mikbarbero
Eclipse Foundation <http://www.eclipse.org/>: The Platform for Open 
Innovation and Collaboration


On 4 Aug 2021, at 10:23, Andrey Loskutov <mailto:losku...@gmx.de>> wrote:


For SDK work coordination I've created
https://bugs.eclipse.org/bugs/show_bug.cgi?id=575230 
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=575230>

Kind regards,
Andrey Loskutov

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

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

*Gesendet:* Mittwoch, 04. August 2021 um 10:06 Uhr
*Von:* "Stephan Herrmann" <mailto:stephan.herrm...@berlin.de>>
*An:* cross-project-issues-dev@eclipse.org 
<mailto:cross-project-issues-dev@eclipse.org>

*Betreff:* Re: [cross-project-issues-dev] git rollback?

I think affected teams should now safe guard all clones on individual 
machines, and wait until the IT team signals that systems are back to 
stable, really.


At that time we may need to re-push lost commits from our local 
clones. Perhaps even some lost tags are available from local clones.


For that task of re-pushing, teams may need to coordinate, which 
commits in which order need to be re-played. A good indicator is the 
"Tested-by" line in commit messages, which signals a commit that has 
once gone through the gerrit exercise and thus should be seen as part 
of the "official" history. A bugzilla query for recently resolved 
bugs would be helpful - if bugzilla queries are reliable again.


For now, waiting and not pushing anything seems to be the best 
strategy, right?


Stephan

On 04.08.21 08:38, Ed Willink wrote:

Hi Sravan

In the absence of any clues from the IT team can you please
identify the time to which GIT / downloads have been rolled back
so that we can all be aware of what is, at least currently, lost
at the EF.

    Regards

        Ed Willink

On 04/08/2021 06:36, Sravan K Lakkimsetti wrote:

Platform I-build from July 31(last successful build for
platform) has gone missing
https://download.eclipse.org/eclipse/downloads/drops4/I20210731-1800/
<https://download.eclipse.org/eclipse/downloads/drops4/I20210731-1800/> 
also
related git tags gone missing from the repository.

Thanks and Regards,
Sravan

Sravan Kumar Lakkimsetti
IBM India Pvt Ltd,
Embassy Golf Links Business Park, C Block,
Off Indiranagar-Kormangla Inner Ring Road,
Bangalore - 560071, India

        "Ed Willink" ---04-08-2021 10:00:35---Hi
Same for OCL.

From: "Ed Willink" 
To: cross-project-issues-dev@eclipse.org
Date: 04-08-2021 10:00
Subject: [EXTERNAL] Re: [cross-project-issues-dev] git rollback?
Sent by: "cross-project-issues-dev"






Hi

Same for OCL.

I pushed a branch commit that successfully refreshed
everything on the branch with the result that the IT team now
need to resolve a merge of the rolled back copy, the
    incremental backed up history and the post 'no-outage' changes.

    Regards

        Ed Willink

On 04/08/2021 02:34, Jonah Graham wrote:


  * On Tue, 3 Aug 2021 at 18:25, Stephan Herrmann
<_stephan.herrmann@berlin.de_
<mailto:stephan.herrm...@berlin.de>> wrote:
  o Has the jdt.core git been rolled back?

I don't know - it certainly looks like it. AFAIK the git
URL links you posted are mirrors of the gerrit repos. The
gerrit repos are the primary IIUC. In gerrit the
referenced review is still active -
_https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/183569_
<https://git.eclipse.org/r/c/jdt/e

Re: [cross-project-issues-dev] Cancel M2 this week

[Ed Willink]

Hi

With the new cadence, for many projects, M2 is the main/only milestone 
so skipping it seems unwise.


I suggest a one week delay provided the infrastructure is back by Saturday.

    Regards

        Ed Willink

On 04/08/2021 12:54, Jonah Graham wrote:

Hi folks,

(cross posted to cross-project-issues, planning-council, epp)

I propose we officially abandon an M2 release this week due to the 
ongoing infra issue. As of now, no project except Eclipse SDK[1] has 
been able to make an M2 contribution, the official deadline is the end 
of day today, so unlikely all or most of the 70 simrel projects will 
be able to respond even if we do get infra back soon. Additionally, 
the simrel CI instance is also in a non functioning state[2].


Once things are running smoothly again (infra wise) we can decide 
whether to do a late M2 release, or just wait until M3. My current 
opinion is to abandon M2 and wait until M3.


Planning council reps, please do weigh in if you are not also on 
vacation/holiday this week.


Thanks
Jonah

[1] Eclipse SDK projects contributed their M2 parts before the infra 
issue last Friday.
[2] One of the VMs that simrel CI uses (promotion-vm) is offline 
https://ci.eclipse.org/simrel/computer/promotion-vm/ 
<https://ci.eclipse.org/simrel/computer/promotion-vm/>




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


On Wed, 4 Aug 2021 at 03:54, Ed Merks <mailto:ed.me...@gmail.com>> wrote:


Christoph ,

I  can only speculate about what's going on but speculation will
get us nowhere.  Suffice to say that I am deeply and fundamentally
concerned both by the state of our infrastructure and even more so
by the complete silence from the Foundation.

I have tried to reach out yesterday to gain more information, and
to suggest that information be posted to the community, but so far
without success...

It would appear to me that we will *not *be able to get m2
completed today because I'm not sure any of us can do a build and
promote the results right now. Certainly I cannot, at this point,
do any of my usual activities for m2, no new version of Oomph, no
new installers, no product catalog updates...

Regards,
Ed

On 04.08.2021 08:52, Christoph Läubrich wrote:

> but I guess there is still a major problem with eclipse.org
<http://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/ <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
<http://eclipse.org> infrastructure.


Am 2. August 2021 14:02:03 MESZ schrieb Laurent Goubet
 <mailto:laurent.gou...@obeo.fr>:

Hello,

All builds we started this morning (5 hours ago CEST) have
failed with
issues trying to reach download.eclipse.org
<http://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|
<https://download.eclipse.org/releases/2019-09/compositeContent.jar%7C>

-|||java.io.FileNotFoundException: Neither

https://download.eclipse.org/tools/orbit/downloads/drops/R20190602212107/repository/compositeContent.jar

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

<https://download.eclipse.org/tools/orbit/downloads/drops/R20190602212107/repository/compositeContent.xml%7C>


When we tried to access these repositories through a browser, we
initially got a 403 error.
|https://download.eclipse.org/releases/2019-09|
<https://download.eclipse.org/releases/2019-09%7C> now seems to
partially
load (all icons are broken) but

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

<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

Re: [cross-project-issues-dev] git rollback?

[Ed Willink]

Hi Sravan

In the absence of any clues from the IT team can you please identify the 
time to which GIT / downloads have been rolled back so that we can all 
be aware of what is, at least currently, lost at the EF.


    Regards

        Ed Willink

On 04/08/2021 06:36, Sravan K Lakkimsetti wrote:


Platform I-build from July 31(last successful build for platform) has 
gone missing 
https://download.eclipse.org/eclipse/downloads/drops4/I20210731-1800/ 
<https://download.eclipse.org/eclipse/downloads/drops4/I20210731-1800/> also 
related git tags gone missing from the repository.


Thanks and Regards,
Sravan

Sravan Kumar Lakkimsetti
IBM India Pvt Ltd,
Embassy Golf Links Business Park, C Block,
Off Indiranagar-Kormangla Inner Ring Road,
Bangalore - 560071, India

Inactive hide details for "Ed Willink" ---04-08-2021 10:00:35---Hi 
Same for OCL."Ed Willink" ---04-08-2021 10:00:35---Hi Same for OCL.


From: "Ed Willink" 
To: cross-project-issues-dev@eclipse.org
Date: 04-08-2021 10:00
Subject: [EXTERNAL] Re: [cross-project-issues-dev] git rollback?
Sent by: "cross-project-issues-dev" 







Hi

Same for OCL.

I pushed a branch commit that successfully refreshed everything on the 
branch with the result that the IT team now need to resolve a merge of 
the rolled back copy, the incremental backed up history and the post 
'no-outage' changes.


    Regards

        Ed Willink

On 04/08/2021 02:34, Jonah Graham wrote:


On Tue, 3 Aug 2021 at 18:25, Stephan Herrmann
<_stephan.herrmann@berlin.de_ <mailto:stephan.herrm...@berlin.de>>
wrote:
Has the jdt.core git been rolled back? 
I don't know - it certainly looks like it. AFAIK the git URL links

you posted are mirrors of the gerrit repos. The gerrit repos are
the primary IIUC. In gerrit the referenced review is still active
- _https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/183569_
<https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/183569> - so
it looks like gerrit took a step backwards, rather than just git
by itself. For the latter commit, the gerrit entry is "broken"
_https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/183573_
<https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/183573>
Locally pulling doesn't provide anything newer than 2021-07-26. 
Same for me.


Is this an effect of the recent incident? 
Probably, but I don't know. @Webmaster will have to comment.


Any other project seeing similar effects? 
Yes. CDT has at least one gerrit from July 31st that has lost a

patchset and associated comments. I have them in my email, but
they are missing from gerrit:

_https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/183568_
<https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/183568>

The metadata in the email is below, and there is no such comment
in the gerrit:

Gerrit-Project: cdt/org.eclipse.cdt
Gerrit-Branch: master
Gerrit-Change-Id: I96589e86bee561aa200a4a4487549305765d6409
Gerrit-Change-Number: 183568
Gerrit-PatchSet: 4
Gerrit-Owner: Mat Booth <_mat.booth@gmail.com_
<mailto:mat.bo...@gmail.com>>
Gerrit-Reviewer: CDT Bot <_cdt-bot@eclipse.org_
<mailto:cdt-...@eclipse.org>>
Gerrit-Comment-Date: Sat, 31 Jul 2021 20:04:45 +

You can also see evidence of the mismatch in CDT's build jobs.

_https://ci.eclipse.org/cdt/job/cdt-verify-test-cdt-ui-only-pipeline/3450/_
<https://ci.eclipse.org/cdt/job/cdt-verify-test-cdt-ui-only-pipeline/3450/> 
and
_https://ci.eclipse.org/cdt/job/cdt-verify-test-cdt-ui-only-pipeline/3451/_
<https://ci.eclipse.org/cdt/job/cdt-verify-test-cdt-ui-only-pipeline/3451/> 
both
built PS4, but 3450 built the now lost patchset, so the sha1 for
the same ref is different:

image.png


HTH,
Jonah


Stephan
___
cross-project-issues-dev mailing list_
__cross-project-issues-dev@eclipse.org_
<mailto:cross-project-issues-dev@eclipse.org>
To unsubscribe from this list, visit
_https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev_
<https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev>

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



Virus-free. _www.avast.com_

<https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>

Re: [cross-project-issues-dev] git rollback?

[Ed Willink]

Hi

Same for OCL.

I pushed a branch commit that successfully refreshed everything on the 
branch with the result that the IT team now need to resolve a merge of 
the rolled back copy, the incremental backed up history and the post 
'no-outage' changes.


    Regards

        Ed Willink

On 04/08/2021 02:34, Jonah Graham wrote:


On Tue, 3 Aug 2021 at 18:25, Stephan Herrmann 
mailto:stephan.herrm...@berlin.de>> wrote:


Has the jdt.core git been rolled back?


I don't know - it certainly looks like it. AFAIK the git URL links you 
posted are mirrors of the gerrit repos. The gerrit repos are the 
primary IIUC. In gerrit the referenced review is still active - 
https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/183569 
<https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/183569> - so it 
looks like gerrit took a step backwards, rather than just git by 
itself. For the latter commit, the gerrit entry is "broken" 
https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/183573 
<https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/183573>


Locally pulling doesn't provide anything newer than 2021-07-26.


Same for me.


Is this an effect of the recent incident?


Probably, but I don't know. @Webmaster will have to comment.


Any other project seeing similar effects?


Yes. CDT has at least one gerrit from July 31st that has lost a 
patchset and associated comments. I have them in my email, but they 
are missing from gerrit:


https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/183568 
<https://git.eclipse.org/r/c/cdt/org.eclipse.cdt/+/183568>


The metadata in the email is below, and there is no such comment in 
the gerrit:


Gerrit-Project: cdt/org.eclipse.cdt
Gerrit-Branch: master
Gerrit-Change-Id: I96589e86bee561aa200a4a4487549305765d6409
Gerrit-Change-Number: 183568
Gerrit-PatchSet: 4
Gerrit-Owner: Mat Booth mailto:mat.bo...@gmail.com>>
Gerrit-Reviewer: CDT Bot <mailto:cdt-...@eclipse.org>>

Gerrit-Comment-Date: Sat, 31 Jul 2021 20:04:45 +

You can also see evidence of the mismatch in CDT's build jobs.

https://ci.eclipse.org/cdt/job/cdt-verify-test-cdt-ui-only-pipeline/3450/ 
<https://ci.eclipse.org/cdt/job/cdt-verify-test-cdt-ui-only-pipeline/3450/> 
and 
https://ci.eclipse.org/cdt/job/cdt-verify-test-cdt-ui-only-pipeline/3451/ 
<https://ci.eclipse.org/cdt/job/cdt-verify-test-cdt-ui-only-pipeline/3451/> 
both built PS4, but 3450 built the now lost patchset, so the sha1 for 
the same ref is different:


image.png


HTH,
Jonah


Stephan
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
<mailto:cross-project-issues-dev@eclipse.org>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
<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



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Can not browse newly created issues in Bugzilla

[Ed Willink]

Hi

Yes. The recent outage has created many backlogs that are slowly clearing.

For a while the Bugzilla search indexc denied the existence of recent 
Bugzillas; you had to know the number to read it.


There currently appears to be a 12 hour backlog on Bugzilla 
notifications, CI build reports, mailing list postings.


(Your posting dated 2-Aug-2021 10:35 reached me half an hour ago. 11:30 
UK time.)


August cross-project-dev postings do not yet appear in 
https://www.eclipse.org/lists/cross-project-issues-dev/index.html


    Regards

        Ed Willink

On 02/08/2021 10:35, Ralph Soika wrote:


Hi,

I have a strange problem with the bug list in bugzilla. I have just 
created a new issue :


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

which is assigned to the project "BPMN2Modeller" and the component "Core"

If I try to browse the issue list the issue is not shown.

https://bugs.eclipse.org/bugs/buglist.cgi?component=Core_id=20859367=BPMN2Modeler=---

Did anybody know this kind of issue?


Best regards

Ralph



--

*Imixs Software Solutions GmbH*
*Web:* www.imixs.com <http://www.imixs.com> *Phone:* +49 (0)89-452136 16
*Timezone:* Europe/Berlin - CET/CEST
*Office:* Agnes-Pockels-Bogen 1, 80992 München
Registergericht: Amtsgericht Muenchen, HRB 136045
Geschaeftsführer: Gaby Heinle u. Ralph Soika

*Imixs* is an open source company, read more: www.imixs.org 
<http://www.imixs.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



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] OCL, QVTd late

[Ed Willink]

Hi

The OCL M2 contribution is already late and likely to be much later 
since the OCL GIT repo remains stale and the 
projects-storage.eclipse.org genie seems to hang on disk accesses 
preventing any promotion.


I'm unclear whether it is premature to report this, but 
https://www.eclipsestatus.io/ suggests that everything is fixed and only 
needs monitoring. However in 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=575158 , I outline a 
succession of problems that were observable after the current outage 
'ended'. Many of these problems have gone away no doubt as further 
synching has progressed.


Is it possible that we can have a clear statement of where we are and 
when we expect to be back to normal?


Why does synching take so long? I would expect synching to take less 
than a second. Given the stale nature of the OCL GIT repo, it appears 
that synching means restore from backup, so we need to know what has 
been lost and how much of the loss is temporary and how much is permanent.


I am sure that the IT team are working very hard on a difficult problem 
and do not need interruptions.


However announcing that the outage is over when it isn't is unhelpful to 
everyone. We all pile in to catch up and hit problems and so create more 
work for the busy team.


    Regards

        Ed Willink


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [cross-project-issues-dev] Cannot login into ci.eclipse.org

[Ed Willink]

Hi

Me Too.

    Regards

        Ed Willink

On 22/07/2021 07:51, Ondrej Dockal wrote:

Hey everybody,

Do you happen to share the same issue as I do? I cannot log into 
ci.eclipse.org/myProject <http://ci.eclipse.org/myProject> Jenkins 
instance. Just simply throwing "Invalid username or password".


Is it something global?

Thanks.

Ondrej Dockal
RedDeer project lead

___
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



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Signed down

[Ed Willink]

Hi

The signer is down

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

    Regards

        Ed Willink


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [cross-project-issues-dev] Move JDT to Java 11

[Ed Willink]

On 16/06/2021 14:35, Christian Dietrich wrote:

as org.eclipse.equinox.common already requires java 11 and this is a
(transitive) dependency of jdt,
i assume jdt already effectively needs java 11 with the current release


It appears that the move to Java 11 has already happened (by mistake).

Movement of UI plugins to Java 11 was inconvenient but only affected the 
IDE so it was at least consistent.


Now in 2021-06, org.eclipse.core.resources has moved to Java 11 making 
standalone Java 8 usage of Eclipse much much harder than it was.


    Regards

        Ed Willink


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [cross-project-issues-dev] Bugzilla notifications flaky

[Ed Willink]

Hi

Issue retracted. Sorry for the noise. (Unless someone else has missing 
notifications too...)


    Regards

        Ed Willink


On 09/06/2021 15:23, Denis Roy wrote:


As mentioned in my response to your direct email to me, I've traced 
emails and they are received by your mail server. I've provided the 
tracking numbers for the Message IDs on your side (queued as number), 
but I've never heard back:


C32B420C8B55: to=, relay=mail.*.uk[78.*.3]:25, delay=5.7, 
delays=0.04/0/5.3/0.31, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued 
as 43029802C0)



I understand this is frustrating, but there's unfortunately nothing we 
can do, no matter which component of our infra you claim is flaky.



Denis



On 2021-06-09 10:16 a.m., Ed Willink wrote:

Hi

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

Bugzilla notifications seem to be down again, consequently many 
important Bug correspondences are getting lost just as RC2 comes to a 
difficult climax.


    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



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Bugzilla notifications flaky

[Ed Willink]

Hi

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

Bugzilla notifications seem to be down again, consequently many 
important Bug correspondences are getting lost just as RC2 comes to a 
difficult climax.


    Regards

        Ed Willink


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [cross-project-issues-dev] Signed content

[Ed Willink]

Hi

The QVTd build has just failed [1] with:

java.lang.SecurityException: class "org.eclipse.core.runtime.RegistryFactory"'s 
signer information does not match signer information of other classes in the same package

This has happened a few times before [2], [4].

The problem was always that a split package had only been partially 
rebuilt and so was inconsistently signed.


The specific bad build was fixed, but the stretch bug [3] of 
guaranteeing a rebuild of the split package ensemble remains outstanding.


This looks like the same problem again, but may be the new don't sign 
policy has rippled, so I'll defer raising another Bugzilla pending 
discussion here.


Regards

Ed Willink

[1] https://ci.eclipse.org/qvtd/job/qvtd-master/377/display/redirect
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=267150
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=466991
[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=531640
On 02/05/2021 09:10, Ed Merks wrote:


Hi,

I am assume from observation that the platform team has decided to 
change its signing policy to not physically sign some jars anymore:


https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/eclipse/updates/4.20-I-builds/index.html

This of course propagates to SimRel:

https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2021-06/index.html

I don't recall a Planning Council policy decision to drop/change the 
need for signed jars.  I don't know the full impact this has on the 
installer nor on consumers.   The installer at least appears to 
happily install such things and the IDE presents such things to the 
user as if they are signed:


Slowly I get the feeling that SimRel is a no longer process where we 
all work together as a team.  Rather it feels as if the platform team 
can and does unilaterally make decisions for everyone else.


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



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] emf.XSD2Java ant task errors with recent 4.20 builds

[Ed Willink]

Hi

Since nobody else has answered...

The Ant tasks are painful to maintain and remain as relics of a bygone 
age. Today I always use MWE2 + Java rather than Ant. For my own 
projects, each time Ant tests are troublesome, e.g. when migrating to 
Tycho, I consider removing the support, but that's not very honest wrt 
deprecation policy so they stay. I suspect that Ed Merks has a similar 
lack of enthusiasm for maintaining the EMF Ant tasks for a tiny number 
of users. I recommend that you recode.


That said, EMF and Ant are pretty stable whereas the platform and Java 
are not, so since your breakage occurs with a new platform, I can only 
suggest searching for the breaking commit and investigating.


    Regards

        Ed Willink

On 23/04/2021 12:02, Andrey Loskutov wrote:

Hi,

could anyone point me to recent changes in EMF / Ant / platform that could 
cause emf.XSD2Java ant tasks to fail?

Last Friday's platform was OK, yesterday's nightly build is broken for me.

Ant task looks like:
 
   
   
 

Similar errors are reported for emf.Ecore2Java tasks too, by specifying the "taskname" 
attribute I can workaround them - but the same "fix" doesn't work for emf.XSD2Java.
If you have any ideas how to "fix" emf.XSD2Java, also welcome.

Problem: failed to create task or type emf.XSD2Java
Cause: The name is undefined.
Action: Check the spelling.
Action: Check that any custom tasks/types have been declared.
Action: Check that any / declarations have taken place.

at 
org.apache.tools.ant.UnknownElement.getNotFoundException(UnknownElement.java:497)
at 
org.apache.tools.ant.UnknownElement.makeObject(UnknownElement.java:429)
at 
org.apache.tools.ant.UnknownElement.maybeConfigure(UnknownElement.java:165)
at org.apache.tools.ant.Task.perform(Task.java:349)
at org.apache.tools.ant.Target.execute(Target.java:449)
at org.apache.tools.ant.Target.performTasks(Target.java:470)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1401)
at 
org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:36)
at 
org.eclipse.ant.internal.core.ant.EclipseSingleCheckExecutor.executeTargets(EclipseSingleCheckExecutor.java:32)
at org.apache.tools.ant.Project.executeTargets(Project.java:1264)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:437)
... 49 more

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


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [cross-project-issues-dev] SWT win32 Broken in Latest 4.20 IBuild?

[Ed Willink]

Hi

I don't understand. Many (?all)  projects have discovered that the 
increased EF integrity makes it really hard to promote from the Jenkins 
build area to the public downloads area. Consequently my builds, when 
successful, trigger a separate promotion job. Nothing gets promoted till 
the build succeeds. Surely the platform should keep candidates in the 
Jenkins workspace or some private project space until such time as the 
analysis has confirmed that they are fit for public consumption? Users 
who really want an unstable build can download from the private 
workspace. Promoting then analysing then marking as unstable seems like 
a recipe for confused users.


"often they'll see a good build" !!! Surely must be always? You haven't 
explained how Tycho magically took the oldest of three (all stable) and 
so happened to allow the OCL build to succeed.


You haven't explained how a not-unstable build has over 7000 fails.

You haven't explained why any not-unstable builds has any fails at all.

    Regards

        Ed Willink

On 16/04/2021 08:41, Sravan K Lakkimsetti wrote:


Hi Ed,

Here is the process we follow,

There are two steps in promotion.

 1. Promote build to downloads pages. To serve users who want to download.
 2. Add to I-builds composite repository

When we find problems with build we mark a build as unstable. This 
removes offending build from I-builds composite repository. This 
enables end users to use a good build for upgrade process. These 
broken builds stay for a week on the download page and after they are 
automatically removed. This process is there for developers to analyse 
problems.


Due to this process whenever downstream projects point to I-builds 
composite most often they’ll see a good build. We also mark a build 
unstable if we find any problems during the build process itself.


Because of above mentioned process Tycho will not pull a bad build in 
maximum cases.


Hope this explanation helps

Thanks

Sravan

*From:*Ed Willink 
*Sent:* 16 April 2021 12:36
*To:* cross-project-issues-dev@eclipse.org
*Subject:* [EXTERNAL] Re: [cross-project-issues-dev] SWT win32 Broken 
in Latest 4.20 IBuild?


Hi

There is something much stranger gong on.

I ran an early OCL build that would have run on Sunday. It has SWT 
usage but the build runs fine, because it used


https://download.eclipse.org/eclipse/updates/4.20-I-builds/I20210413-1400  
<https://download.eclipse.org/eclipse/updates/4.20-I-builds/I20210413-1400/plugins/>

although that is the earliest of the 3 listed in the 
compositeArtifacts.jar. If it had used the more recent then the 
problem might have shown up.


?? Why did Tycho fail to pull in the broken build ??

http://download.eclipse.org/eclipse/downloads/drops4/I20210413-1400/ 
<http://download.eclipse.org/eclipse/downloads/drops4/I20210413-1400/> 
has 63 test fails which is rather disturbing.


http://download.eclipse.org/eclipse/downloads/drops4/I20210415-0010/ 
<http://download.eclipse.org/eclipse/downloads/drops4/I20210415-0010/>, 
which is not marked as unstable, has 7057 fails.


Surely such a high number of fails should be a private matter to be 
resolved by the platform committers with no more trouble to the 
community as a whole than perhaps a polite message to 
cross-project-dev announcing the lack of build promotions while a 
problem is investigated.


Why does http://download.eclipse.org/eclipse/downloads/ 
<http://download.eclipse.org/eclipse/downloads/> show unstable builds? 
Surely these too should not have been promoted to waste disc space / 
confuse the community?


Why do any builds have any fails at all? Surely a test that fails is a 
test that fails? In my code, if a test is proving problematic then I 
raise a Bugzilla and comment out the test until a solution is found.


    Regards

        Ed Willink

On 16/04/2021 07:45, Niraj Modi wrote:

Hi All,

We learned that Windows Signing service is down/broken:
http://build.eclipse.org:31338/winsign.php
<http://build.eclipse.org:31338/winsign.php>

Raised a blocker below bug with Eclipse foundation:

*Bug 572896*
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=572896> - Windows
Signing service is down or link broken

Regards,

Niraj Modi

- Original message -
From: Sravan K Lakkimsetti/India/IBM
To: "Cross project issues"

<mailto:cross-project-issues-dev@eclipse.org>, Niraj
Modi/India/IBM@IBM
Cc:
Subject: RE: [EXTERNAL] [cross-project-issues-dev] SWT win32
Broken in Latest 4.20 IBuild?
Date: Fri, Apr 16, 2021 11:46 AM

Found the faulty commit

https://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/commit/?id=a26b79c959e884b3a3a96ce2e2cbf0b6ef9e6d23

<https://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/commit/?id=a26b79c959e884b3a3a96ce2e2cbf0b6ef9e6d23>

Re: [cross-project-issues-dev] SWT win32 Broken in Latest 4.20 IBuild?

[Ed Willink]

Hi

There is something much stranger gong on.

I ran an early OCL build that would have run on Sunday. It has SWT usage 
but the build runs fine, because it used


https://download.eclipse.org/eclipse/updates/4.20-I-builds/I20210413-1400  
<https://download.eclipse.org/eclipse/updates/4.20-I-builds/I20210413-1400/plugins/>

although that is the earliest of the 3 listed in the 
compositeArtifacts.jar. If it had used the more recent then the problem 
might have shown up.


?? Why did Tycho fail to pull in the broken build ??

http://download.eclipse.org/eclipse/downloads/drops4/I20210413-1400/ has 
63 test fails which is rather disturbing.


http://download.eclipse.org/eclipse/downloads/drops4/I20210415-0010/, 
which is not marked as unstable, has 7057 fails.


Surely such a high number of fails should be a private matter to be 
resolved by the platform committers with no more trouble to the 
community as a whole than perhaps a polite message to cross-project-dev 
announcing the lack of build promotions while a problem is investigated.


Why does http://download.eclipse.org/eclipse/downloads/ show unstable 
builds? Surely these too should not have been promoted to waste disc 
space / confuse the community?


Why do any builds have any fails at all? Surely a test that fails is a 
test that fails? In my code, if a test is proving problematic then I 
raise a Bugzilla and comment out the test until a solution is found.


    Regards

        Ed Willink



On 16/04/2021 07:45, Niraj Modi wrote:

Hi All,
We learned that Windows Signing service is down/broken:
http://build.eclipse.org:31338/winsign.php 
<http://build.eclipse.org:31338/winsign.php>

Raised a blocker below bug with Eclipse foundation:
*Bug 572896* <https://bugs.eclipse.org/bugs/show_bug.cgi?id=572896> - 
Windows Signing service is down or link broken

Regards,
Niraj Modi

- Original message -
From: Sravan K Lakkimsetti/India/IBM
To: "Cross project issues" ,
Niraj Modi/India/IBM@IBM
Cc:
Subject: RE: [EXTERNAL] [cross-project-issues-dev] SWT win32
Broken in Latest 4.20 IBuild?
Date: Fri, Apr 16, 2021 11:46 AM

Found the faulty commit

https://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/commit/?id=a26b79c959e884b3a3a96ce2e2cbf0b6ef9e6d23

<https://git.eclipse.org/c/platform/eclipse.platform.swt.binaries.git/commit/?id=a26b79c959e884b3a3a96ce2e2cbf0b6ef9e6d23>

Need to investigate why this happened.

@Niraj Modi
Can you please help?

Thanks
Sravan

-Original Message-
From: Ed Merks 
Sent: 16 April 2021 11:18
To: Cross project issues 
Subject: [EXTERNAL] [cross-project-issues-dev] SWT win32 Broken in
Latest 4.20 IBuild?

Hi,

I updated my target platform from
http://download.eclipse.org/eclipse/updates/4.20-I-builds
<http://download.eclipse.org/eclipse/updates/4.20-I-builds> and
after that I could not run any SWT applications anymore:

java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:


D:\Users\merks\oomph-1.21\ws\.metadata\.plugins\org.eclipse.pde.core\IDE\org.eclipse.osgi\480\0\.cp\swt-win32-4944r16.dll:
%1 is not a valid Win32 application
     no swt-win32 in java.library.path: [C:\Program
Files\Java\jdk-11.0.9\bin,]
 D:\Users\merks\.swt\lib\win32\x86_64\swt-win32-4944r16.dll: %1 is
not a valid Win32 application
     Can't load library:
D:\Users\merks\.swt\lib\win32\x86_64\swt-win32.dll
 D:\Users\merks\.swt\lib\win32\x86_64\swt-win32-4944r16.dll: %1 is
not a valid Win32 application

Using http://download.eclipse.org/releases/2021-06/202104161000
<http://download.eclipse.org/releases/2021-06/202104161000>
instead works fine, so it seems to be something that's happened
between M1 and today.

Has anyone else noticed this?  For those who "eat our own dog
food", such a problem could cripple your IDE if you update the IDE
itself...

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



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] ci.eclipse.org speed

[Ed Willink]

Hi

In the last couple of weeks OCL compatibility tests seem to be taking 25 
to 50% longer, sometimes failing to complete within a once-generous timeout.


Is this a known phenomenon or do I need to search deep for a 
Java/platform/EMF/OCL performance regression [1]?


    Regards

        Ed Willink

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



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [cross-project-issues-dev] [epp-dev] Xtext Leaving Eclipse Simrel with 2021-06

[Ed Willink]

Hi

ASM, Guice and Guava can be accommodated by losing the upper version 
bound; they appear to have good compatibility for at least my trivial 
usages. The explicit upper bound is honest in that it indicates 
not-tested, but a blocker for anyone who wants to try and test it.


The real killers for project relengs are the platform's gratuitous 
removal of IPlatformRunnable, movement to Java 11 BREE coupled with 
Tycho evolution. Equally troublesome are the almost six monthly 
breakages of the EF IT infrastructure as service is 'improved'.


    Regards

        Ed Willink


On 26/03/2021 07:24, Christian Dietrich wrote:


yes we can keep it unless some new ASM, Guice, Guava, Junit5 or 
another "paying attention" topic forces us to act and build milestones 
and releases with the 3 weeks pressure.


Am 26.03.21 um 08:20 schrieb Ed Merks:

All,

I've been tempted for quite some time to make a similar announcement, 
only for EMF.   I don't believe I will have the resource to get EMF's 
build working on the new infrastructure, and most certainly I am 
highly unlikely to do so without some evidence that the cost and 
effort involved will *not *be born only by me personally (and by the 
helpful-but-overburdened Foundation Staff):


https://bugs.eclipse.org/bugs/show_bug.cgi?id=558735#c1

I *strongly *recommend to the IDE Working Group that action be taken 
without further delay.



Christian,

One thing that I would ask, and strongly suggest for Xtext, is simply 
to leave your current contribution(s) to SimRel as is for 
contribution to 2021-06 such that the IDE Working Group has time to 
take action.   There is no absolute requirement that you must provide 
a new release, right?  Certainly one would hope that it's reasonable 
to assume that the Platform, and your other dependencies, will remain 
fully compatible with your most recently release, right?


Physically removing the most recent Xtext release from the 2021-06 
train is a bit of a bombshell that affects a great many other 
projects.  Once we drop this bomb, we may as well throw in the towel...


Regards,
Ed


On 25.03.2021 13:28, Dietrich, Christian wrote:

Hi all,

i want to inform you that we at itemis will no longer drive the 
participation of Xtext in the Eclipse simultaneous release beginning 
with the upcoming 2021-06 release 
https://blogs.itemis.com/en/xtext-is-leaving-the-eclipse-simultaneous-release 
<https://blogs.itemis.com/en/xtext-is-leaving-the-eclipse-simultaneous-release>. 



As there are currently no other parties with the capacity to take 
over the work this will result in Xtext leaving the Simrel. This 
will also affect other projects in the Simrel that consume Xtext 
like OCL, Xcore, Parsley and parts of GEF as well as the DSL Package 
in EPP. (and maybe others)


Please feel free to join the discussion at 
https://github.com/eclipse/xtext/issues/1961 
<https://github.com/eclipse/xtext/issues/1961>


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, Stephan Grollmann
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, 
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 (Vors.), Dr. Stephan Eberle, Abdelghani El Kacimi,
Wolfgang Neuhaus, Franz-Josef Schuermann
Aufsichtsrat: Michael Neuhaus (Vors.), Harald Goertz, Stephan Grollmann

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, Stephan Grollmann
Sitz der Gesellschaft/Registered Office: Am Brambusch 15-24, 44536 
Lünen (Germany)

Registergericht/Registry Court: Amtsgericht Dortmund | HRB 20621

___
epp-dev mailing li

Re: [cross-project-issues-dev] Gotchas Building Against Eclipse 4.20

[Ed Willink]

Hi

You may also find https://bugs.eclipse.org/bugs/show_bug.cgi?id=569379 
relevant if you move on from an old Tycho to avoid IPlatformRunnable.


It would appear that something in the auto-POM logic ignores the 
MANIFEST.MF BREE and instead picks one from an explicit pom.xml BREE so 
avoid vintage BREEs in test plugins.


Inconsistent org.eclipse.jdt.core.prefs between plugins can also be a 
problem. Maybe OOMPH can avoid this.


If you  use JDT's @NonNull annotations it is essential that you set 
deriveReleaseCompilerArgumentFromTargetLevel false.


    Regards

        Ed Willink


On 19/03/2021 08:33, Wim Jongman wrote:

Thanks, Ed! I was just starting to convert some builds to 4.20.

On Fri, Mar 19, 2021 at 9:17 AM Ed Merks <mailto:ed.me...@gmail.com>> wrote:



BREE 1.6  and when I moved them to BREE 1.8, that magically
avoided the
Tycho compile errors.  Probably others won't have such a problem, but
maybe good to keep in mind.


Maybe: https://bugs.eclipse.org/bugs/show_bug.cgi?id=561363 
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=561363>


___
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



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Broken signer

[Ed Willink]

Hi

The signer has failed. https://bugs.eclipse.org/bugs/show_bug.cgi?id=571754

    Regards

        Ed Willink


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

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

[Ed Willink]

HI

I use the copyright tool for MoDisco, OCL, QVTd, QVTo

    Regards

        Ed Willink

On 05/02/2021 17:07, Matthias Sohn wrote:
On Fri, Feb 5, 2021 at 6:00 PM Aleksandar Kurtakov 
mailto:akurt...@redhat.com>> wrote:


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


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

What I look for is removing this part of Eclipse Releng plugin to
gain the following benefits:
1. Drop dependency on EGit in Eclipse Platform and thus circular
build dependency.
2. Point 1 will allow to to build Eclipse Platform p2 repo in a
way that includes all transitive dependencies [3]
3. Point 2 will allow to switch third-party dependencies to
require rather than include and thus support version ranges.
4. Point 3 will allow updates of third party dependencies for
security reasons to be far simpler as currently it's a terrible
experience [4]
5. Point 3 will simplify updates of third party dependencies in
Eclipse Platform releng as touching features should be far less
frequent event just cause exact version is hardcoded in includes. 
e.g. [5]

The potential benefit is quite big so please come up with
proposals how/what to do and still improve our procedures.

[1]

https://wiki.eclipse.org/Development_Resources/How_to_Use_Eclipse_Copyright_Tool

<https://wiki.eclipse.org/Development_Resources/How_to_Use_Eclipse_Copyright_Tool>
[2] https://wiki.eclipse.org/Eclipse/PMC/Minutes_2016
<https://wiki.eclipse.org/Eclipse/PMC/Minutes_2016>
[3]

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

<https://www.eclipse.org/tycho/sitedocs/tycho-p2/tycho-p2-repository-plugin/assemble-repository-mojo.html#includeAllDependencies>
[4] https://www.eclipse.org/lists/tycho-user/msg08879.html
<https://www.eclipse.org/lists/tycho-user/msg08879.html>
[5]

https://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=58e5c221bfc493e40d499f58c93a17cc14d061ac

<https://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=58e5c221bfc493e40d499f58c93a17cc14d061ac>

-- 
Alexander Kurtakov

Red Hat Eclipse Team
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
<mailto:cross-project-issues-dev@eclipse.org>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
<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



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Using maven artifacts directly in eclipse target platform / tycho builds

[Ed Willink]

Hi

Improving the Maven compatibility is certainly a good idea, but for my 
(small number of) users the problem is the other way round. How to make 
Eclipse standalone project releases easily consumable by Maven.


https://www.eclipse.org/forums/index.php/mv/msg/1097672/1826580/#msg_1826580 
is an attempt by a user to contribute.


https://bugs.eclipse.org/bugs/show_bug.cgi?id=562307 is my fruitless 
attempts to actually publish via https://repo.eclipse.org 
<https://repo.eclipse.org/content/repositories/qvtd> although I gather 
that is now going out of fashion.


As a naive traditional Eclipse releng I have successfully struggled to 
keep the P2 builds going. I see P2-to-Maven as a generic capability that 
the EF (or some skilled contributor) should solve on behalf of the 
community. As with downloads, when everyone does their own thing, it 
takes a lot of effort to produce an inconsistent mess.


    Regards

        Ed Willink

On 04/01/2021 19:10, Christoph Läubrich wrote:

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



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Problem with SimRel Validation Builds

[Ed Willink]

Hi

Thanks. I eventually found it after discovering that other contributions 
were progressing.


Just a bit strange for the Validate job to move while the Pipeline job 
didn't.


    Regards

        Ed

On 09/12/2020 09:00, Frederic Gurr wrote:

Hi,

Your Gerrit review was built and merged by the Validate job on the new
SimRel Jiro instance
(https://ci-staging.eclipse.org/simrel/job/simrel.runaggregator.VALIDATE.gerrit/).
So there was no delay and no issue.

To avoid further confusion, I've re-enabled the validate job on the old
JIPP. Until further notice, please disregard
https://ci-staging.eclipse.org/simrel.

Regards,

Fred

On 09.12.20 07:06, Ed Willink wrote:

Hi

The normal
https://ci.eclipse.org/simrel/job/simrel.runaggregator.VALIDATE.gerrit/shows
as disabled since Dec 4th so that just about all RC2 contributions are
blocked. This doesn't seem like waiting till RC2 is done before an infra
change.

How are RC2 contributions supposed top be made?

     Regards

         Ed Willink

On 08/12/2020 09:00, Frederic Gurr wrote:

Hi Jonah,

Thanks for the heads-up and sorry for the noise. The staging repo is
complete, but there was a permissions issue, that made the directories
not readable.

I will make sure that simrel.runaggregator.pipeline runs from the old
instance until RC2 is done.

The migration bug is:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=568118

Regards,

Fred

On 08.12.20 02:50, Jonah Graham wrote:

Hi Fred,

The staging repo is broken. The root files are there, but the
subdirectories (e.g. plugins) are empty. Is the staging-ci version
conflicting with the main ci one? There hasn't been a successful main ci
build since RC2 period started.

A few other things on this subject:

- the ci-staging is triggering EPP builds. I don't think that should
happen until the migration is done.
- the ci-staging seems to be stuck re-running the build despite no
changes. The last few builds all have the same trigger and pair of git
repos.
- the normal ci build seems to be failing in the post build steps only
- is there a bugzilla or similar to subscribe to on the simrel jiro
migration?

Thanks
Jonah



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


On Mon, 7 Dec 2020 at 05:11, Frederic Gurr
mailto:frederic.g...@eclipse-foundation.org>> wrote:

  Hi,

  Sravan is correct. I should have disabled the
  simrel.runaggregator.VALIDATE.gerrit job (which I did on Sunday
after
  the error reports).

  Sorry for the noise.

  Regards,

  Fred

  On 06.12.20 08:30, Sravan K Lakkimsetti wrote:
  > Looks like Fred is migrating Simrel project to JIRO. Please
ignore
  > ci-staging path. This patch did not put a -1 on the gerrit patch
  for me
  > yesterday.
  >
  >
  >
  > Thanks
  >
  > Sravan
  >
  >
  >
  > *From:*Ed Merks mailto:ed.me...@gmail.com>>
  > *Sent:* 06 December 2020 11:13
  > *To:* Cross project issues mailto:cross-project-issues-dev@eclipse.org>>
  > *Subject:* [EXTERNAL] [cross-project-issues-dev] Problem with
SimRel
  > Validation Builds
  >
  >
  >
  > Hi,
  >
  > SimRel validation builds like this are failing:
  >
  >
 
https://ci-staging.eclipse.org/simrel/job/simrel.runaggregator.VALIDATE.gerrit/1904/console


  >
  > I think this is the problem:
  >
  > *06:24:12* No JDK named ‘jdk11-latest’ found
  >
  > Then it uses Java 8:
  >
  > *06:24:24* Java version: 1.8.0_262, vendor: Eclipse OpenJ9,
  runtime: /opt/java/openjdk/jre
  >
  > But Java 8 doesn't work:
  >
  > *06:24:40* Caused by: java.lang.UnsupportedClassVersionError:
  JVMCFRE003 bad major version;
  class=org/eclipse/tycho/extras/eclipserun/EclipseRunMojo, offset=6
  >
  > How did JDK 11 disappear and how do we get it back?
  >
  > I opened the following:
  >
  > https://bugs.eclipse.org/bugs/show_bug.cgi?id=569506
  >
  > Regards,
  > Ed
  >
  >
  >
  >
  >
  > ___
  > cross-project-issues-dev mailing list
  > cross-project-issues-dev@eclipse.org
  <mailto:cross-project-issues-dev@eclipse.org>
  > To unsubscribe from this list, visit
  https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
  >

  --
  Frederic Gurr
  Release Engineer | Eclipse Foundation Europe GmbH

  Annastr. 46, D-64673 Zwingenberg
  Handelsregister: Darmstadt HRB 92821
  Managing Directors: Gaël Blondelle, Mike Milinkovich
  ___
  cross-project-issues-dev mailing list
  cross

Re: [cross-project-issues-dev] Problem with SimRel Validation Builds

[Ed Willink]

Hi

The normal 
https://ci.eclipse.org/simrel/job/simrel.runaggregator.VALIDATE.gerrit/shows 
as disabled since Dec 4th so that just about all RC2 contributions are 
blocked. This doesn't seem like waiting till RC2 is done before an infra 
change.


How are RC2 contributions supposed top be made?

    Regards

        Ed Willink

On 08/12/2020 09:00, Frederic Gurr wrote:

Hi Jonah,

Thanks for the heads-up and sorry for the noise. The staging repo is
complete, but there was a permissions issue, that made the directories
not readable.

I will make sure that simrel.runaggregator.pipeline runs from the old
instance until RC2 is done.

The migration bug is:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=568118

Regards,

Fred

On 08.12.20 02:50, Jonah Graham wrote:

Hi Fred,

The staging repo is broken. The root files are there, but the
subdirectories (e.g. plugins) are empty. Is the staging-ci version
conflicting with the main ci one? There hasn't been a successful main ci
build since RC2 period started.

A few other things on this subject:

- the ci-staging is triggering EPP builds. I don't think that should
happen until the migration is done.
- the ci-staging seems to be stuck re-running the build despite no
changes. The last few builds all have the same trigger and pair of git
repos.
- the normal ci build seems to be failing in the post build steps only
- is there a bugzilla or similar to subscribe to on the simrel jiro
migration?

Thanks
Jonah



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


On Mon, 7 Dec 2020 at 05:11, Frederic Gurr
mailto:frederic.g...@eclipse-foundation.org>> wrote:

 Hi,

 Sravan is correct. I should have disabled the
 simrel.runaggregator.VALIDATE.gerrit job (which I did on Sunday after
 the error reports).

 Sorry for the noise.

 Regards,

 Fred

 On 06.12.20 08:30, Sravan K Lakkimsetti wrote:
 > Looks like Fred is migrating Simrel project to JIRO. Please ignore
 > ci-staging path. This patch did not put a -1 on the gerrit patch
 for me
 > yesterday.
 >
 >
 >
 > Thanks
 >
 > Sravan
 >
 >
 >
 > *From:*Ed Merks mailto:ed.me...@gmail.com>>
 > *Sent:* 06 December 2020 11:13
 > *To:* Cross project issues mailto:cross-project-issues-dev@eclipse.org>>
 > *Subject:* [EXTERNAL] [cross-project-issues-dev] Problem with SimRel
 > Validation Builds
 >
 >
 >
 > Hi,
 >
 > SimRel validation builds like this are failing:
 >
 >
 
https://ci-staging.eclipse.org/simrel/job/simrel.runaggregator.VALIDATE.gerrit/1904/console
 >
 > I think this is the problem:
 >
 > *06:24:12* No JDK named ‘jdk11-latest’ found
 >
 > Then it uses Java 8:
 >
 > *06:24:24* Java version: 1.8.0_262, vendor: Eclipse OpenJ9,
 runtime: /opt/java/openjdk/jre
 >
 > But Java 8 doesn't work:
 >
 > *06:24:40* Caused by: java.lang.UnsupportedClassVersionError:
 JVMCFRE003 bad major version;
 class=org/eclipse/tycho/extras/eclipserun/EclipseRunMojo, offset=6
 >
 > How did JDK 11 disappear and how do we get it back?
 >
 > I opened the following:
 >
 > https://bugs.eclipse.org/bugs/show_bug.cgi?id=569506
 >
 > Regards,
 > Ed
 >
 >
 >
 >
 >
 > ___
 > cross-project-issues-dev mailing list
 > cross-project-issues-dev@eclipse.org
 <mailto:cross-project-issues-dev@eclipse.org>
 > To unsubscribe from this list, visit
 https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
 >

 --
 Frederic Gurr
 Release Engineer | Eclipse Foundation Europe GmbH

 Annastr. 46, D-64673 Zwingenberg
 Handelsregister: Darmstadt HRB 92821
 Managing Directors: Gaël Blondelle, Mike Milinkovich
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 <mailto: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



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [cross-project-issues-dev] javax.xml.bind not found

[Ed Willink]

Hi

https://download.eclipse.org/tools/orbit/downloads/drops/R20201130205003/ 
is the source of many things that come in useful.


Many of them are redistributed by Eclipse projects so that users are 
unaware that they actually come from Orbit.


It may be that you are not using some project that you used to, or that 
some project no longer redistributes. IIRC Mylyn has been restructuring.


    Regards

        Ed Willink

On 01/12/2020 08:05, Ralph Soika wrote:


Hi,

I have a problem with one of my plugins which is using the 
javax.xml.bind packages to marshal and unmarshal xml classes. The 
javax.xml.bind is missing in Eclipse 2020-09. So I see exceptions like 
this one during runtime:


org.eclipse.e4.core.di.InjectionException: 
java.lang.NoClassDefFoundError: javax/xml/bind/JAXBContext


Also I am not able to do a maven build from Eclipse 2020-09. The 
strange thing is that the same plugin still works in Eclipse 2020-06 - 
and I can build it from that platform. I fear that I had missed 
something important and also I guess my Maven tycho plugins are outdated.


Can someone point me to a example how a Eclipse Plugin with Tycho 
should look like. Or better can some point me to a eclipse plugin 
project of the current release train using javax.xml.bind, so that I 
can take the correct configuration from there?


Thanks for any hints and help

===
Ralph

--

*Imixs Software Solutions GmbH*
*Web:* www.imixs.com <http://www.imixs.com> *Phone:* +49 (0)89-452136 16
*Office:* Agnes-Pockels-Bogen 1, 80992 München
Registergericht: Amtsgericht Muenchen, HRB 136045
Geschaeftsführer: Gaby Heinle u. Ralph Soika

*Imixs* is an open source company, read more: www.imixs.org 
<http://www.imixs.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



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] BIRT removal

[Ed Willink]

Hi

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

raised for MoDisco to re-use BIRT chart via MAT.

    Regards

        Ed Willink

On 22/10/2020 16:54, Wayne Beaton wrote:
We have the same sort of arrangement with Eclipse Jetty. The 
simultaneous release includes Jetty and it's included in the packages 
(to support the help system), but it's not a participant in the 
release and is not listed as an installable feature.


Your project can pull in the required bits of Eclipse BIRT, but will 
then be responsible for them.


I am getting some faint hope vibes that the BIRT team might re-engage, 
but those are fleeting.


Wayne

On Thu, Oct 22, 2020 at 11:49 AM Andrew Johnson 
mailto:andrew_john...@uk.ibm.com>> wrote:


> Message: 3
> Date: Thu, 22 Oct 2020 09:07:07 -0400
> From: Wayne Beaton mailto:wayne.bea...@eclipse-foundation.org>>
> To: Cross project issues mailto:cross-project-issues-dev@eclipse.org>>
> Subject: Re: [cross-project-issues-dev] Is AERI still used in
release
>    train
> Message-ID:
>   
mailto:g...@mail.gmail.com>>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks for this, Jonah.
>
> That logging/milestones directory probably needs to be removed,
but I'll
> leave that to your discretion.
>
> The BIRT aggrcon needs to be removed. BIRT dropped out, so their
aggrcon
> should be deleted, please.
>
...
>
> Wayne
>
> On Wed, Oct 21, 2020 at 9:40 PM Jonah Graham
mailto:jo...@kichwacoders.com>>
wrote:
>
> > Hi Wayne,
> >
> > TL;DR
> >
> > AERI p2 was:
> >
https://download.eclipse.org/technology/epp/logging/milestones/
<https://download.eclipse.org/technology/epp/logging/milestones/>
- see
change
> > 170952
> >
<https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/170952
<https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/170952>>
> >
> > There are 6 or so other aggrcons that need attention, details
below,
but 4
> > of them can be deleted if I can get a +1 on  change 171096
> >
<https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/171096
<https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/171096>>
> >
> > Longer version:
> >
> > The AERI p2 repo was being picked up from
> >
https://download.eclipse.org/technology/epp/logging/milestones/
<https://download.eclipse.org/technology/epp/logging/milestones/>
- see
> >
https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/170952
<https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/170952>

for
> > the change that removed it from SimRel.
> >
> > There are a few other aggrcon files that are perhaps a little
dated.
> >
> > enabled aggrcon files with no edits in 2020:
> > - actf - project has a few commits in 2020, just no more recent
release or
> > contribution to simrel
> > - birt - there is long history here that I am not revisiting[1]
> > - usssdk[2] - project has a few commits in 2020, just no more
recent
> > contribution to simrel
> >

...

> >
> > [1] ...but the current birt p2 repo contributes a bunch of old
orbit
> > content to simrel that cause problems like Bug 499207 (Obsolete
> > certificates)
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=499207
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=499207>> -
in
> > light of Bug 553288 <
https://bugs.eclipse.org/bugs/show_bug.cgi?id=553288
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=553288>>
> > which may make even more of the certificates out of date we
may need
to
> > revisit this again before 2020-12 release. The birt p2 repo is
practically
> > a simrel of its own, it includes lots or orbit, eclipse platform,
> > datatools, and lots of other stuff. Generally this is not a
problem,
but
> > the orbit project publishes bundles with the same fully qualified
version
> > that differs only in signature. So there are multiple bundles out
there
> > which are not binary equal but have the same version.
> >
...
> >
> > HTH,
> > Jonah
> >
> > ~~~
> > Jonah Graham
> > Kichwa Coders
> > www.kichwacoders.com <http://www.kichwacoders.com>
> >
BIRT removal was discussed in December 2019
http

Re: [cross-project-issues-dev] Windowbuilder is broken in the release train

[Ed Willink]

Hi

It would be nice to avoid WindowBuilder going the same way as VE the 
Visual Editor.


IIRC I managed to resurrect a VE build to make it useable for a couple 
of extra years, by which time WindowBuilder came to the rescue. That 
seems so long ago (2008) that I can find no sign of my rescue with 
Google; probably because VE has been erased (archived).


If you can identify the API breakage we can maybe persuade the platform 
to revert.


    Regards

        Ed Willink


On 19/09/2020 14:59, Wim Jongman wrote:

Hi,

I see that all our wb features are in the release train, which can be 
confusing. Should I make a top-level feature just for the RT depending 
on the current RT features? If so can the features then be 
individually updated?


Thanks,

Wim

image.png





On Sat, Sep 19, 2020 at 10:06 AM Wim Jongman <mailto:wim.jong...@gmail.com>> wrote:


Thanks, Ed. It was worth a try.

On Sat, Sep 19, 2020 at 9:00 AM Ed Merks mailto:ed.me...@gmail.com>> wrote:

Wim,

I suppose one alternative is to respin the train repo, but
that's a big undertaking, especially trying to get it to have
consistently the same contents as what it current has, other
than the updated Window Builder.

Another alternative might be to compose your release
repository into the train composite.   But you have categories
in your update site and those would likely become visible.  So
probably not a good idea either.

I suspect there is no good/feasible solution at this late
point.  :-(

Regards,
Ed

On 18.09.2020 19:47, Wim Jongman wrote:

Hi,

Due to an API break, the version of windowbuilder in the
release train is not working anymore.

Can this be fixed in some way?

I have a release that works.

Best regards,

Wim

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

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
<mailto:cross-project-issues-dev@eclipse.org>
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
<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



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] OCL, QVTd, QVTo failures

[Ed Willink]

Hi

The OCL, QVTd and QVTo weekly forced nightly re-builds have all failed 
today with a class loading problem that at first glance looks like 
another gratuitous Java-8-no-longer-supported bug. Probably the same as 
the reverted breakage two weeks ago from 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=56 (oddly MoDisco's 
build did not fail).


I'm afraid that I do not have the time or energy to track down these 
problems at present. MoDisco, OCL, QVTd and QVTo will therefore revert 
to the (maintained) 2020-06 release for 2020-09. Once I have caught up 
with the Xtext deprecations, I may be in a position to progress again.


Hopefully the platform will institute some testing to ensure that Java 
>8 is only necessary in the dark corner where it is actually necessary, 
and ideally ensure that in that corner a compatibility functionality 
invokes a legacy workaround.


    Regards

        Ed Willink


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [cross-project-issues-dev] Upgrading the Eclipse SDK target environment for the *September* Eclipse release...

[Ed Willink]

Hi

This has now happened and it causes a problem. See [1]

Boring Java 8 builds now fail in non-UI contexts.

My understanding of the original report was that I would have difficulty 
starting the Eclipse UI without Java 11 and I commented that better user 
help was desirable.


I am therefore disappointed to discover that applications using the 
non-UI org.eclipse.search fail since the UI is not separated into a 
separate bundle.


As I commented on [2]

/Seems like moving the whole platform to Java 11 just for Jetty is like 
amputating a whole leg just because a toe is gangrenous./


Since Java 8 is significantly faster [3], the platform needs to ensure 
that its beyond Java 8 issues are isolated, e.g an old Jetty if Java 8, 
a new Jetty if Java 11.


Regards

Ed Willink

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=56
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=565368
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=565563

On 20/03/2020 18:34, Mike Wilson wrote:

Hello cross project people,
The Eclipse Project PMC has approved a change to the target 
environments for the 2020-09 Eclipse release of the Eclipse Project 
(that is, our 4.17 release) to be based on Java 11. This will allow us 
to include Jetty 10, when it is available as indicated here:

https://www.eclipse.org/lists/jetty-dev/msg03214.html
Given that this change has the potential to impact downstream 
projects, we are asking for feedback now: please let us know if you 
believe this will cause problems for your project.
Note that we are not asking teams to update the BREE for their 
components, and it is fine for components to support earlier versions 
of Java. This note is just identifying the version of Java that we 
will use to validate the September release, and thus will be the 
supported version for the Eclipse SDK.

thanks,
the Eclipse Project 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



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [eclipse-pmc] Upgrading the Eclipse SDK target environment for the *September* Eclipse release...

[Ed Willink]

Hi

I thought I had raised a Bugzilla on this but cannot find it.

IMHO the eclipse.exe launcher should diagnose the suitability of the 
user's platform for Eclipse and provide helpful diagnostics rather than 
a Java bang dialog. This should all be done before Java is started. 
Wrong Java version is an obvious check. Historically, the Microsoft Java 
was a regular user hazard.


    Regards

        Ed Willink

On 23/03/2020 15:25, Daniel Megert wrote:

HI Matthias

> letting things (like Help) fail seems not very nice from the user’s 
point of view. I would vote for requiring Java 11 at the start.

I agree.

I'm not a p2 expert, so,, no, I can't answer your question to an end, 
but I assume that it won't warn and just fail on restart.


Dani



From: "Becker, Matthias" 
To: "eclipse-...@eclipse.org" , Cross project 
issues 

Date: 23.03.2020 13:59
Subject: [EXTERNAL] Re: [cross-project-issues-dev] [eclipse-pmc] 
Upgrading the Eclipse SDK target environment for the *September* 
Eclipse release...

Sent by: cross-project-issues-dev-boun...@eclipse.org



Hi Dani,

letting things (like Help) fail seems not very nice from the user’s 
point of view. I would vote for requiring Java 11 at the start.


@Dani: Do you also have answers to my other questions?


Regards,

Matthias

*From: * on behalf of Daniel Megert 
*

Reply to: *"eclipse-...@eclipse.org" *
Date: *Monday, 23. March 2020 at 13:33*
To: *Cross project issues *
Cc: *"cross-project-issues-dev-boun...@eclipse.org" 
, 
"eclipse-...@eclipse.org" *
Subject: *Re: [eclipse-pmc] [cross-project-issues-dev] Upgrading the 
Eclipse SDK target environment for the *September* Eclipse release...


It depends. We (the platform) can require/hardcode Java 11 when you 
start the SDK or we do not enforce this but let things like Help/Jetty 
fail. Our position is that users need Java 11 for 2020-09.


Dani



From: "Becker, Matthias" 
To: "eclipse-...@eclipse.org" , 
"cross-project-issues-dev@eclipse.org" 


Date: 23.03.2020 10:57
Subject: [EXTERNAL] Re: [cross-project-issues-dev] [eclipse-pmc] 
Upgrading the Eclipse SDK target environment for the *September* 
Eclipse release...

Sent by: cross-project-issues-dev-boun...@eclipse.org



Hi everybody,

do I understand this correctly that the 2020-09 release needs at least 
a Java 11 VM to run? Will it no longer run on a Java 8 VM?


Will platform raise the Bundle-Execution Environment?

If release 2020-09 will only run on Java11 and newer: How does 
platform's "Check for Updates" handle this? What happens if a user has 
an existing installation running on Java 8 (and this is the user's one 
and only Java VM)? Does P2 tell the user that the new bundles to be 
installed require Java 11 but that the current installation does not 
supply this?


Regards,

Matthias

*From: * on behalf of Mike Wilson 
*

Reply to: *"eclipse-...@eclipse.org" *
Date: *Friday, 20. March 2020 at 19:35*
To: *"cross-project-issues-dev@eclipse.org" 
*

Cc: *"eclipse-...@eclipse.org" *
Subject: *[eclipse-pmc] Upgrading the Eclipse SDK target environment 
for the *September* Eclipse release...


Hello cross project people,

The Eclipse Project PMC has approved a change to the target 
environments for the 2020-09 Eclipse release of the Eclipse Project 
(that is, our 4.17 release) to be based on Java 11. This will allow us 
to include Jetty 10, when it is available as indicated here:


_https://www.eclipse.org/lists/jetty-dev/msg03214.html_

Given that this change has the potential to impact downstream 
projects, we are asking for feedback now: please let us know if you 
believe this will cause problems for your project.


Note that we are not asking teams to update the BREE for their 
components, and it is fine for components to support earlier versions 
of Java. This note is just identifying the version of Java that we 
will use to validate the September release, and thus will be the 
supported version for the Eclipse SDK.


thanks,

the Eclipse Project 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




___
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



--
This email has been checked for viruses by Avast a

Re: [cross-project-issues-dev] Getting 502 Bad Gateway/504 Gateway Time-out accessing ci.eclipse.org

[Ed Willink]

Hi

My JIPPs are ok but I cannot log  in to the MarketPlace. (The Login 
'button' goes away and comes back on the same page without logging in.)


    Regards

        Ed Willink

On 23/03/2020 07:06, Ed Merks wrote:

FYI,

I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=561350 
because since yesterday I am unable to access my Jenkins instances.  
Perhaps your instances are also affected...


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


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Ed Willink]

Hi

On 29/01/2020 13:22, Ed Merks wrote:


Yet even this is non-trivial work that must be done by someone.

We seem to be so concerned with the details that we are completely 
ignoring the bigger picture.


The EF provides many services to us that we could not survive without. 
(No doubt we may have suggestions for doing them even better, but at 
least they mostly get done.) Thank you very much.


AFAIAA the EF employees are paid, presumably from Friends of Eclipse and 
other begging bowls.


It appears that many very important communal activities are not 
EF-funded and so unreasonably dependent on the enthusiasm and 
time-generosity of a few individuals. Again thank you, but this is where 
the sustainability problem lies.


All project-neutral activities such as SimRel, MarketPlace admin, AERI 
admin, ... must be EF-funded; perhaps not generously funded but at least 
reasonably so.


We need to ensure that the big users of Eclipse really contribute.

I gather that Huawei makes use of QVTo, perhaps to manage product lines, 
but certainly QVTo and I expect Eclipse gets nothing in return


Once we have sustainable funding for project-neutral, we can perhaps 
move on to funding widely useful activities such as OOMPH, EMF and some 
legacy projects.


    Regards

        Ed Willink


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

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

[Ed Willink]

Hi

I share Ed and Christian's concerns, and as I wrote earlier the original 
purpose of SimRel was to provide a coherent synchronized release across 
all active projects. The quarterly SimRel has totally undermined that 
because many projects cannot support the faster cadence. Personally, it 
means that I just chuck out my auto-tested builds without manual 
verification. Diligent checks that I used to perform annually have gone 
out the window. I used to use perhaps every other 6 weekly milestone for 
my personal development resulting in many regression bugs getting fixed 
pre-release. Now the regressions get detected after release; it is all 
much much too fast. The final platform RC is done almost before some 
projects have started on their first RC. The only things that can get 
fixed are panics and just look at the number of RC3 respin discussions 
we now have to have because of the unreasonable speed; in the past RC3 
and RC4 were available.


Let's go back to annual SimRels that provide a coherent best endeavours 
release that users can be confident of enhancing by taking on board 
service releases. No longer a brand new different selection of novel 
bugs every quarter.


If projects want to do quarterly intermediate releases, fine, they are 
intermediate releases. Until such time as the high speed community steps 
up and commits the resources to support it, why does the rest of Eclipse 
have to suffer?


The timing of the annual release should be aligned to offer a useable 
rather than experimental latest-Java experience.


(When I advocate annual SimRels, that does not mean I endorse EPPs. 
Personally I only use the base Eclipse SDK ZIP, project ZIPs where 
available and the SimRel P2 as a last resort. I can easily live without 
EPPs, but a synchronized SimRel P2 is critical.)


(As a modelling developer I might be expected to use the Modeling EPP, 
but sadly I find that although ridiculously bloated, it lacks important 
projects and includes one project that I find detrimental to my UX.)


    Regards

        Ed Willink

On 29/01/2020 08:21, Dietrich, Christian wrote:

Hi all,

I personally share Ed's concerns about the direction the Eclipse
SimRel is thrifting. Maintaining 4 Releases a Year in a quite involved
project like Xtext with many dependencies was a lot of work. Also the
move to the new Cloud based Jenkins infrastructure ate a lot of
resources at the Xtext team last year. Resources that we won't have
this year. Thus is see this a burden for many smaller and less
resourced projects. I am not sure if a pull approach would solve this
problem as there still needs to be common ground for projects that
need to depend on each other. No EMF would mean no Platform, Xtext,
OCL etc.

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

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

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

[Ed Willink]

Hi

Indeed, and java.util.logging and logback.

My attempts to use SLF4J in OCL have foundered. Migrating the plugins 
was easy, although RSI-inducing. Test harnesses which represent an 
'overall application' must continue to use their log4j proprietary 
tweaks, but making this work enters a hotchpotch world of fragments and 
smart class loaders. Eventually I gave up; too time consuming for purely 
cosmetic value. It is far from clear which of the three rival LOG4J for 
SLF4J in Orbit is the right one. After major failures with Apache 
conflicts, I settled on the fragment, whose fragment-host readme-bundles 
suggests an out of date predecessor to Require-Capability that doesn't 
seem to work for all the class loaders. AFAICT SLF4J and/or P2 fragment 
declarations are not yet ready for prime time. I never even got as far 
as struggling to make the migrated tests work on Tycho.


Wrt Xtext, there will almost certainly be some new magic to ensure that 
an Xtext application has a fallback Log4j logger rather than the default 
NOP logger.


Regards

Ed Willink

On 25/01/2020 14:23, Aleksandar Kurtakov wrote:



On Sat, Jan 25, 2020 at 10:56 AM Ed Willink <mailto:e...@willink.me.uk>> wrote:


Hi

I've started to action this for OCL;
https://bugs.eclipse.org/bugs/show_bug.cgi?id=559532

and hit a silly problem; who redistributes SLF4J?

If it's standard, surely the platform should redistribute so that
a copy
can be found in e.g. eclipse-SDK-4.14-win32-x86_64.zip ?


Platform doesn't use slf4j nor log4j thus it makes no sense to 
redistribute them. I should add to the mix that there is the OSGi 
LogService which might be the proper API to use in OSGi projects as it 
will not add yet another dependency. I'm not an expert in the area so 
I would appreciate some more guidance in case what I said is not correct.



There is no SLF4J there. There is no log4j either. Where does
log4j come
form? It turns out that EGit redistributes both log4j and SLF4J. Very
helpful, but surely not right?

What is the preferred policy for redistribution of SLF4J? Does every
project need to redistribute it itself to avoid piggy-backing on
EGit or
mandating that users manually add Orbit to their Install sites?

Regards

Ed Willink

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
<mailto: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



--
Alexander Kurtakov
Red Hat Eclipse Team

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

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

[Ed Willink]

Hi

I've started to action this for OCL; 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=559532


and hit a silly problem; who redistributes SLF4J?

If it's standard, surely the platform should redistribute so that a copy 
can be found in e.g. eclipse-SDK-4.14-win32-x86_64.zip ?


There is no SLF4J there. There is no log4j either. Where does log4j come 
form? It turns out that EGit redistributes both log4j and SLF4J. Very 
helpful, but surely not right?


What is the preferred policy for redistribution of SLF4J? Does every 
project need to redistribute it itself to avoid piggy-backing on EGit or 
mandating that users manually add Orbit to their Install sites?


Regards

Ed Willink

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

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

[Ed Willink]

Hi Christian

After reading some of the SLF4J documentation, it appears that SLF4J is 
not a replacement for Log4J rather it is a Facade that hides Log4j or 
whatever other conformant logger an application configures.


At the source code level it appears to be just necessary to change

    Logger log = Logger.getLog(MyClass.class);

to

    Logger log = LoggerFactory.getLog(MyClass.class);

(using the slf4j rather than log4j imports)

and change the Import-Package from log4j to slf4j.

Thereafter it would appear that so long as some part of the application 
explicitly uses log4j, slf4j will be forced to delegate to log4j 
regardless. Once everything uses slf4j, slf4j has a freedom to choose.


It therefore appears that ordinary application plugins can change now.

My only uncertainty is the magic configuration, for which I have only 
cracked the Tycho fragment initialization for Xtext application tests in 
the last few weeks. A new magic may be required, but the SLF4J 
documentation rather implies that these problems may have been 
considered; a bit of reflection seems to have a poke around to determine 
whether to use log4j. It might just work. Only real way to tell is to 
build an Xtext application with no log4j dependencies and see what happens.


    Regards

        Ed Willink

On 24/01/2020 08:06, Christian Dietrich wrote:


Hi,

we (Xtext) currently have no capacity to do

- the bureaucracy
- analyze impacts on logging customization points in Xtext
- analyze who else uses what logging and how that change would affect 
them and indirectly us


Regards
Christian

Am 23.01.20 um 15:05 schrieb Ed Willink:


Hi

If there is a conflict hazard then it already exists. Examining one 
of my workspaces...


Good (SLF4J) - jgit, m2e
Bad (LOG4J) - mwe, ocl, qvtd, xtend, xtext

This is complete news to me. I continue to use log4j since it avoids 
changing code styles that have been unchanged for many many years. 
Other projects probably just copy prevailing practice.


I presume changing is rather easy, and of no consequence to the 
exported API, since the use of log4j is by import package.


However without a commitment to change by Xtext, I would be reluctant 
to change any Xtext-based project.


    Regards

        Ed Willink

On 23/01/2020 13:09, Hickman, Steve (AdvTech) wrote:


Log4j 1.x reached end of life in 2015. The documentation for it now 
appears to have gone offline. There are some Eclipse projects (call 
them L1 projects) that currently use Log4j 1.x directly rather than 
SLF4J. That means that any projects that depend on L1 projects 
cannot use Log4J 2.x without risking dependency collisions from 
attempting to load multiple versions of Log4J.


SLF4J was created precisely to eliminate dependencies on specific 
logging implementations.


It is important that libraries like those that plug into Eclipse not 
unintentionally force a specific logging implementation on their 
users. Those library developers have no way of knowing – and 
probably no way of satisfying – all the requirements of their 
various sets of users.


Given that, it seems that Eclipse should make SLF4J the ‘official’ 
logging API for all Eclipse libraries.


*Steve Hickman*

Software Architect

*Honeywell* | Aerospace

Office: 480-236-8367

steve.hick...@honeywell.com <mailto:steve.hick...@honeywell.com>

https://in.honeywell.com/sites/aero/ENG/advance-tech/crew-intf/Pages/crewhome.aspx


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


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


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

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

[Ed Willink]

Hi

If there is a conflict hazard then it already exists. Examining one of 
my workspaces...


Good (SLF4J) - jgit, m2e
Bad (LOG4J) - mwe, ocl, qvtd, xtend, xtext

This is complete news to me. I continue to use log4j since it avoids 
changing code styles that have been unchanged for many many years. Other 
projects probably just copy prevailing practice.


I presume changing is rather easy, and of no consequence to the exported 
API, since the use of log4j is by import package.


However without a commitment to change by Xtext, I would be reluctant to 
change any Xtext-based project.


    Regards

        Ed Willink

On 23/01/2020 13:09, Hickman, Steve (AdvTech) wrote:


Log4j 1.x reached end of life in 2015. The documentation for it now 
appears to have gone offline. There are some Eclipse projects (call 
them L1 projects) that currently use Log4j 1.x directly rather than 
SLF4J. That means that any projects that depend on L1 projects cannot 
use Log4J 2.x without risking dependency collisions from attempting to 
load multiple versions of Log4J.


SLF4J was created precisely to eliminate dependencies on specific 
logging implementations.


It is important that libraries like those that plug into Eclipse not 
unintentionally force a specific logging implementation on their 
users. Those library developers have no way of knowing – and probably 
no way of satisfying – all the requirements of their various sets of 
users.


Given that, it seems that Eclipse should make SLF4J the ‘official’ 
logging API for all Eclipse libraries.


*Steve Hickman*

Software Architect

*Honeywell* | Aerospace

Office: 480-236-8367

steve.hick...@honeywell.com <mailto:steve.hick...@honeywell.com>

https://in.honeywell.com/sites/aero/ENG/advance-tech/crew-intf/Pages/crewhome.aspx


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

Re: [cross-project-issues-dev] repo.eclipse.org maintenance on January 19th

[Ed Willink]

Hi

The 'old' ci.eclipse.org seems to have gone down.

While trying to investigate weird failures that started yesterday [1], I 
now get catastrophic start up [2].


    Regards

        Ed Willink

[1] 
https://ci.eclipse.org/ocl/job/ocl-compatibility-2019-03/org.eclipse.ocl$org.eclipse.ocl.compatibility.tests/45/


[2] 
https://ci.eclipse.org/ocl/job/ocl-compatibility-2019-03/org.eclipse.ocl$org.eclipse.ocl.compatibility.tests/48/


On 20/01/2020 09:25, Mikael Barbero wrote:
As note on the associated ticket, and unrelated to the 
repo.eclipse.org <http://repo.eclipse.org> maintenance, we've been 
having a failing proxy node in our reverse proxy pool for the last 2 
days. This node has not been automatically removed from the pool for 
some reasons. As such, 1/3 of the requests directed to the cluster 
were timing out. It was mostly affecting Jenkins instances on the new 
infra and help.eclipse.org <http://help.eclipse.org>.


Everything should be back on track. We're now working on preventing 
such proxy node failure from impacting projects as much as it did this 
week end.


Thanks for your patience.
*
Mikaël Barbero *
*Team Lead - Release Engineering | Eclipse Foundation*
 @mikbarbero
Eclipse Foundation <http://www.eclipse.org/>: The Platform for Open 
Innovation and Collaboration


Le 19 janv. 2020 à 16:52, Mikael Barbero 
<mailto:mikael.barb...@eclipse-foundation.org>> a écrit :


Internal DNS are note yet updated, so builds on Jenkins are still 
seeing 503 while https://repo.eclipse.org 
<https://repo.eclipse.org/> is up and running.


Will keep you posted once everything is back to normal.

Le 19 janv. 2020 à 16:22, Mikael Barbero 
<mailto:mikael.barb...@eclipse-foundation.org>> a écrit :


Note that DNS had to be changed, so depending on the caching level 
of your setup, you may have to wait until the change is fully 
propagated.


Le 19 janv. 2020 à 16:15, Mikael Barbero 
<mailto:mikael.barb...@eclipse-foundation.org>> a écrit :


Maintenance is over.

Thanks for your patience.
*
Mikaël Barbero *
*Team Lead - Release Engineering | Eclipse Foundation*
 @mikbarbero
Eclipse Foundation <http://www.eclipse.org/>: The Platform for Open 
Innovation and Collaboration


Le 14 janv. 2020 à 15:37, Mikael Barbero 
<mailto:mikael.barb...@eclipse-foundation.org>> a écrit :


Hi,

We will do some maintenance of the Nexus instance servicing 
repo.eclipse.org <http://repo.eclipse.org/>. The maintenance is 
scheduled for Jan 19. @ 12 noon CET following our maintenance 
window for Tier II services 
(https://wiki.eclipse.org/IT_SLA#Maintenance).


The repositories will set to readonly (no deploy will work) for 
about 3 hours and the service will be unavailable for about 15 min.


See https://bugs.eclipse.org/bugs/show_bug.cgi?id=551775 for details.

Thanks for your understanding.

*
Mikaël Barbero *
*Team Lead - Release Engineering | Eclipse Foundation*
 @mikbarbero
Eclipse Foundation <http://www.eclipse.org/>: The Platform for 
Open Innovation and Collaboration











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

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

[Ed Willink]

HI Lars

You seem to have missed the distinction.

The original bug was the philosophy change, initially endorsed, 
subsequently rejected as a bad regression.


The follow on bug was an ergonomic issue that violated even the changed 
philosophy. After reporting I back-pedalled on reproducibility. I 
suspect that the actual problem might well be idiot user; disabling 
auto-build or just not waiting long enough for all the time wasting 
background activities such as Bug 544272 to complete before the editor 
can refresh its markers usefully.


    Regards

        Ed Willink

On 17/12/2019 17:07, Lars Vogel wrote:

 From Ed Willink,


Sadly some like https://bugs.eclipse.org/bugs/show_bug.cgi?id=545211 have to 
wait 9 months until the platform team 'duplicates'.

Ed, if you open twice the same bug as you did with
https://bugs.eclipse.org/bugs/show_bug.cgi?id=544977 and
https://bugs.eclipse.org/bugs/show_bug.cgi?id=545211 it would be great
if you can mark one of them yourself as dup instead of complaining
about the time the platform team needs to find this.

On Fri, Dec 13, 2019 at 2:12 PM Ed Willink  wrote:

Hi

Yes. It would be great and in the past I did that re-installing for many 6/8 
weekly milestones. But with three weekly milestones, not all of which have a 
coherent set of contributions and four releases a year I just do not have time. 
In the past four RCs provided an opportunity for test. Now the platform is 
pretty much done before RC1 is declared complete. It's unacceptably fast and 
now you see the consequences. I just have to keep my fingers crossed 
interactively. API-wise, all my projects have a forced weekly rebuild that 
catches out quite a few regressions. Sadly some like 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=545211 have to wait 9 months 
until the platform team 'duplicates'.

 Regards

 Ed Willink

On 13/12/2019 10:23, Daniel Megert wrote:

It would be great if everyone could at least test or even better, run on the 
latest milestone/RC. Platform got a stop ship bug for 4.13 and one for 4.14 
reported after RC2. The 4.13 bug was introduced in M3 and the 4.14 bug in M1. 
So, there would have been enough room to find the bugs earlier.

Of course the Platform team does exactly that but everyone has its own patterns 
how to work and hence, unfortunately did not detect those bugs.

Thanks to everyone who helps with testing!
Dani

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

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




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

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

[Ed Willink]

Hi

Yes. It would be great and in the past I did that re-installing for many 
6/8 weekly milestones. But with three weekly milestones, not all of 
which have a coherent set of contributions and four releases a year I 
just do not have time. In the past four RCs provided an opportunity for 
test. Now the platform is pretty much done before RC1 is declared 
complete. It's unacceptably fast and now you see the consequences. I 
just have to keep my fingers crossed interactively. API-wise, all my 
projects have a forced weekly rebuild that catches out quite a few 
regressions. Sadly some like 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=545211 have to wait 9 
months until the platform team 'duplicates'.


    Regards

        Ed Willink

On 13/12/2019 10:23, Daniel Megert wrote:
It would be great if everyone could at least test or even better, run 
on the latest milestone/RC. Platform got a stop ship bug for 4.13 and 
one for 4.14 reported after RC2. The 4.13 bug was introduced in M3 and 
the 4.14 bug in M1. So, there would have been enough room to find the 
bugs earlier.


Of course the Platform team does exactly that but everyone has its own 
patterns how to work and hence, unfortunately did not detect those bugs.


Thanks to everyone who helps with testing!
Dani

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

Re: [cross-project-issues-dev] Can we please stop using composite repos?

[Ed Willink]

Hi

Ah! That corresponds to what I observe and am always puzzled by. Given 
that the previous installations are fully available in the 
features/plugins folders, why is it necessary for a reversion to do any 
remote access at all? At best it wastes time, at worst it fails.


    Regards

        Ed Willink

On 10/12/2019 15:18, Camille Letavernier wrote:

Hi Jonah,

IIRC (from a few years ago :) ), one of the reasons to keep multiple 
versions in the Simrel Composite was to support rollback. If you 
updated e.g. from M1 to M2 and noticed that something's broken, you 
can revert to M1 automatically (Via Installed Software -> Installation 
History). However, this feature only works if M1 is still available at 
the same location, i.e. in the composite update site you used to 
update to M2 (Or to initially install M1).


That was even more useful when we had yearly releases, because users 
could be affected by SR1 regressions and want to rollback to the "SR0" 
release (M1 and M2 only affect Eclipse developers and early adopters, 
so it's typically less of an issue).


Regards,
Camille

On Tue, Dec 10, 2019 at 3:39 PM Jonah Graham <mailto:jo...@kichwacoders.com>> wrote:


Thanks Ed and Mikael for responding.

I will change to use the staging repo to build & release my EPP
product - I hadn't liked it in the past because it was a moving
target as people updated the simrel contents.

However, I was only referring to multiple children providing just
different versions of the same content - not composites with
different content. There are specific failures when there are
multiple children with the same content - yet none of the answers
or the FAQ answer the question of the use case of having a single
repo with multiple versions available. However, I don't understand
this line from the FAQ: "and once we remove it, it will invalidate
that target". How does changing the composite to point from M1 to
M2 do that?

Anyway, this seems to be one of the things that are the way they
are - I hope to understand but I am not sure I will.

Jonah





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


On Tue, 10 Dec 2019 at 03:40, Mikael Barbero
mailto:mikael.barb...@eclipse-foundation.org>> wrote:



Can the composite only include the current/latest version,
or can someone educate me as to the value of having multiple
versions?


It's a really good question.  It just seems to be a "habit"
to compose multiple children, usually with some restriction
on the number of children, e.g., the most recent n children. 
But personally, just to make everything faster for the client
and less overhead for thedownload.eclipse.org
<http://download.eclipse.org/>server, I would prefer to use a
repo with a single child with the most recent version.

So what prompted everyone to have this habit?


AFAIK, it comes from the simrel process of "making visible"
the repository to the world (after the quiet / mirroring
time). See code comment in

https://git.eclipse.org/c/simrel/org.eclipse.simrel.tools.git/tree/promoteUtils/makeVisible.sh#n25

See also this FAQ entry

https://wiki.eclipse.org/SimRel/Simultaneous_Release_Cycle_FAQ#Why_do_we_use_composites_anyway.2C_if_there_are_potential_problems_with_them.3F

Cheers,

*Mikaël Barbero *
*Team Lead - Release Engineering | Eclipse Foundation*
 (+33) 642 028 039 |  @mikbarbero
Eclipse Foundation <http://www.eclipse.org/>: The Platform for
Open Innovation and Collaboration

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

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
<mailto: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



--
Camille Letavernier
Senior Software Architect EclipseSource France
Email: cletavern...@eclipsesource.com 
<mailto:cletavern...@eclipsesource.com>

Web: http://eclipsesource.com/paris
Phone: +33 1 85 41 09 21
EclipseSource France SAS 7 rue de la Croix Martre 91120 Palaiseau
General Manager: Remi Schnekenburger
Registered Office: 7 rue de la Croix Martre, 91120 Palaiseau, France
Commercial Register 824 97

Re: [cross-project-issues-dev] 2019-12: The Eclipse Eierlegende Wollmilchsau

[Ed Willink]

Hi Mickael

I think you forget why SimRel started and so overlook its major utility.

Pre-SimRel, it was hard to know what version of what worked with what 
requiring users of multiple tools to maintain distinct Eclipses for 
distinct application domains.


Post-SimRel there is a pretty good chance that everything that comes 
from the one SimRel is compatible.


Personally, I don't use the EPPs, I download the ZIPs for those projects 
that provide them and install piecemeal using SimRel as a 'library' of 
bits that I failed/cannot get from ZIP. As such SimRel is almost just an 
Orbit variant, but it usually avoids needing to add Orbit to the 
available sites. And Orbit gives no guarantee of coherence, which SimRel 
does.


I only use the MarketPlace as a last resort or as an occasional quick 
check on OCL utility that has somehow got into the MarketPlace as well 
as SimRel.


    Regards

        Ed Willink


On 10/12/2019 09:05, Mickael Istria wrote:

Hi Ed,

Thanks for bringing this.
I was actually waiting for the best opportunity to start discussing a 
very related topic, but from a maintenance POV not a user one, and I 
think this is a good one:

*What is the value and quality of SimRel? Is it worth it's cost?*

As you're highlighting, the actual SimRel doesn't result in good 
"common" toolset. Installing whole SimRel leads to a failing or 
non-usable IDE. So is this non-functional thing worth it?
EPP packages behave fine, they're tested and delivered to the target 
audience in a good enough shape. Marketplace is now the main and best 
entry-point for many features and fits much better into typical user 
workflows


Does SimRel bring anything really good beyond EPP packages? Anything 
good enough to be worth the maintenance effort?
Is it an interesting exercise to expect all Eclipse Platform plugins 
in the Eclipse Foundation to work properly together as the same 
application? Who is actually likely to invest in making their specific 
plugins fit better with all other Eclipse plugins if the typical 
audience doesn't care?


My opinion on this is that SimRel is nowadays a giant hard to maintain 
inconsistent effort, and that EPP and Marketplace have superseded it 
and made it not so profitable anymore.
I would suggest that we just abandon SimRel in favor of EPP building 
packages and a p2 repository containing all the dependencies for these 
packages; and other plugins should just target Marketplace as entry 
point, until they reach a good enough quality and value to get into 
some EPP package.


Cheers,

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

Re: [cross-project-issues-dev] 2019-12: The Eclipse Eierlegende Wollmilchsau

[Ed Willink]

Hi Ed

On 10/12/2019 08:56, Arthur van Dorp wrote:
Or is it just the interactions such that no single bundle is actually 
to blame?  Or did I install something that should not be installed in 
an IDE?


Kind of Yes. My strong prejudice is that earlyStartup is a major 
facility that some projects misuse as an easy way to avoid designing an 
appropriately lazy application specific startup. IMHO earlyStartup 
allows many 'ordinary' things to happen before the platform is ready. 
Since EMF can be used by many early registrations, EMF is very likely to 
feature in the startup fight. I would back a move to require all usage 
of org.eclipse.ui.startup to need signing off by the PMC and the 
platform team.


(Oops, the usage of org.eclipse.ui.startup by a user contribution to 
QVTo never got written out.)


    Regards

        Ed Willink

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

Re: [cross-project-issues-dev] LSP4E: A Problem Waiting to Happen?

[Ed Willink]

Hi

Yes I think I saw something similar a few weeks ago, when I needed to do 
a feature-affecting change for MoDisco.


But mostly I never use the aggregator tooling since it breaks EMF [1]

Once a tool has bitten you a few times, you remember to avoid it like 
the plague.


Usually my changes are for repo-name/feature range only and so are much 
better done with a text editor.


    Regards

        Ed Willink

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

On 08/12/2019 12:17, Stephan Herrmann wrote:

thanks for nagging :)

While we are at it, is anybody using validation from the aggregation 
editor??

Reason for asking: whenever I try that, it aborts with this message:

Unable to load repository 
https://archive.eclipse.org/webtools/downloads/drops/R3.2/C3.2.0/I-C3.2.0-20100614204142/repository
Unable to load repository 
p2:https://archive.eclipse.org/webtools/downloads/drops/R3.2/C3.2.0/I-C3.2.0-20100614204142/repository/
Build failed! Exception was org.eclipse.core.runtime.CoreException: 
Unable to load repository 
p2:https://archive.eclipse.org/webtools/downloads/drops/R3.2/C3.2.0/I-C3.2.0-20100614204142/repository/ 




yes, my browser can see that repository. Is p2 not ready to read from 
archive.e.o? Is the repo broken by any terms?


anybody else seeing this?
Stephan

On 08.12.19 10:23, Ed Merks wrote:

Hi,

It's me the nagger again. I know many of you are editing your 
*.aggrcon manually.  This is mildly annoying.  When I edit using the 
editor and save my changes, all the files being edited manually change.


I can and do revert all these, but it's annoying.

Unfortunately this approach also makes it easy (and likely) to 
overlook problems in the consistency of the overall simrel.aggr 
resource.


In addition, the recommended process for contributing is to point 
your contribution at a specific update site:


https://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build#The_best_format_and_process_for_contributing_to_Sim._Release 



When you don't do this, your contribution will potentially change 
dynamically, which might be convenient for you, but it is problematic 
from an overall consistency point of view.  It's also less than idea 
if your specific site updates its content dynamically...


Why do I harp about this?  I'm quite sure that lsp4e intends to 
contribute the 0.13.0 release for 2019-12:


https://projects.eclipse.org/projects/technology.lsp4e/releases/0.13.0

But look closely at what the editor tells us:


While the "dynamically changing" repo (I can only assume that this is 
the case) does contain version 1.30.0, this is *not *what's 
contributed to the the 2019-12 release train.  Somewhere (and I have 
no clue from where) the 0.12.0 version is found and that's what's on 
the train:


https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/releases/2019-12/http___download.eclipse.org_releases_2019-12_201912061000/org.eclipse.lsp4e_0.12.0.201909270706.html 



I'm quite sure this is not the intent so I've opened this Bugzilla:

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

Regards,
Ed


___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or 
unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or 
unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

Re: [cross-project-issues-dev] Restrict BIRT's Contribution...

[Ed Willink]

HI

On 07/12/2019 09:39, Ed Merks wrote:


Therefore surely all BIRT features should be removed from all SimRel 
categories?


I took the approach of minimizing the impact, leaving this charting 
feature in the category.  I think that's least disruptive at this point.


The BIRT chart feature would still be there for those who explore the 
uncategorized view and of course for transitive install by consuming 
projects such as MoDisco.


No BIRT feature would be there to fool users into believing there is a 
BIRT tool.


For MoDisco it appears that total loss of BIRT would just require an 
optional feature to be removed. Since that feature enables BIRT charts 
to be modelized and BIRT is missing, retaining the feature presumably 
only supports rescue of legacy BIRT charts.


    Regards

        Ed

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

Re: [cross-project-issues-dev] Restrict BIRT's Contribution...

[Ed Willink]

HI Ed

Yes the BIRT chart feature is all that MoDisco uses.

Looking at the residual aggrcon ...

"oxygen" is really vintage
"interim" is really smelly

It seems that BIRT has died and we are raking over its ashes.

Therefore surely all BIRT features should be removed from all SimRel 
categories?


Perhaps somewhere central analogous to Orbit is a better location for a 
frozen library until BIRT is resuscitated.


    Regards

        Ed


On 07/12/2019 08:10, Ed Merks wrote:


Aleksandar,

Thanks again for the constructive suggestion.  I experimented with 
reducing BIRT's contribution to just the chart feature:


https://git.eclipse.org/r/154052

That build passes and that also solves the "who will do this problem". :-P

In addition, I fixed all the broken links in simrel.aggr. Many people 
are editing textually; removing a feature from your *.aggrcon breaks 
the links from the custom categories to those features, or shifts them 
to a different feature.  It's hard ensure one doesn't introduce errors 
when there are errors to begin with.  :-(


Note that I'm not 100% sure if this change to BIRT's contribution also 
avoids all the unsigned content, but I believe it does.  I.e., 
installing this feature in an IDE does not appear to install the two 
unsigned bundles older Orbit bundles.


Of course I'm not so comfortable changing someone else's *.aggrcon, so 
if there is someone from the BIRT team paying attention, please speak up.


Failing that, what do we, the active participants, think of this 
approach/change?


Regards,
Ed


On 06.12.2019 20:51, Aleksandar Kurtakov wrote:
Yes the feature is still there 
https://github.com/eclipse/birt/blob/master/features/org.eclipse.birt.chart.feature/feature.xml 
. If that's enough for MAT it should work.


On Fri, Dec 6, 2019 at 9:47 PM Aleksandar Kurtakov 
mailto:akurt...@redhat.com>> wrote:




On Fri, Dec 6, 2019 at 9:03 PM Andrew Johnson
mailto:andrew_john...@uk.ibm.com>> wrote:

Date: Fri, 6 Dec 2019 18:38:24 +0100
From: Ed Merks
To: cross-project-issues-dev@eclipse.org

Subject:

Fred,

We're definitely on the path to greatness again.? Many teams
have taken
action so the RC1 report is much improved:


https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/releases/2019-12/http___download.eclipse.org_releases_2019-12_201912061000.html

Special thanks to the Eclipse Collections team who I know
invested
significant time.

There are unfortunately some hold-outs that continue to
reflect poorly
on our group's results:

These outstanding bugs are open for each of the bad license
problems
because it appears that these contributors are not reading
cross-projects:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=553879
https://bugs.eclipse.org/bugs/show_bug.cgi?id=553523
https://bugs.eclipse.org/bugs/show_bug.cgi?id=553880
https://bugs.eclipse.org/bugs/show_bug.cgi?id=553881
https://bugs.eclipse.org/bugs/show_bug.cgi?id=553882
https://bugs.eclipse.org/bugs/show_bug.cgi?id=553883

*Please pay attention t4me, uml2, m2e, m2e-wtp, mylyn docs,
and xwt teams.*

Also, given that the Reporting package has been removed I would
recommend removing BIRT itself from SimRel.?? This content is
more than
two years old with bad licenses and with the only remaining
unsigned
content. ? I don't hold out hope that there will be a new
build so I've
*not *opened a Bugzilla. *
*
*
*
*Does BIRT removal affect anyone?*

Regards,
Ed

Yes, Eclipse Memory Analyzer uses BIRT for graphing of memory
usage. We would not have any pie charts if BIRT was removed,
both dynamic charts in the overview pane and HTML charts in
reports. The pie charts shown on our home page
https://www.eclipse.org/mat/and here
https://www.eclipse.org/mat/about/overview.pngand here

https://help.eclipse.org/2019-09/topic/org.eclipse.mat.ui.help/tasks/listbiggestobjects.htmlis
generated by BIRT.

Fortunately the graphing is in a separate feature, so it
would not break the rest of the tool, but it is useful for
us. We only have a small team and don't have the time or
expertise to use a new graphing package. If it has to be
removed then we need plenty of notice, and ideally some help
in writing code to use a replacement. Please keep BIRT. 



Is it a possibility BIRT contribution to be shrinked to charting
feature only? IIRC chart was separate feature in birt . We moved
to swtchart from BIRT chart in Linux Tools and never looked back.



Thanks,

Andrew Johnson
Committer, Eclipse Memory 

Re: [cross-project-issues-dev] SimRel 2019-12 Release Candidate 1 (RC1) is available. ACTION REQUIRED FOR t4me, uml2, m2e, m2e-wtp, mylyn docs, and xwt. QUESTION: Should we remove BIRT?

[Ed Willink]

Hi

On 06/12/2019 17:38, Ed Merks wrote:

*Does BIRT removal affect anyone?*

Regards,
Ed


Yes. MoDisco has a model discovery from a BIRT chart.

    Regards

        Ed

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

Re: [cross-project-issues-dev] Project Repository Reports

[Ed Willink]

Hi

Shouldn't they just be moved to archive where archive composites give 
access to the archives in just the same way as the normal composite for 
normal contents, but avoiding the need to inflict the loading of vintage 
material on normal users?


    Regards

        Ed Willink

On 05/12/2019 10:27, Lars Vogel wrote:

Hi Eike,

thanks a bunch for that.

What is the process to delete obsolete p2 repos? AFAICS repos from
https://download.eclipse.org/oomph/archive/p2-index/eclipse.e4.html
can be removed.

Best regards, Lars

On Thu, Dec 5, 2019 at 8:52 AM Eike Stepper  wrote:

Hi Committers,

Every once in a while during my work I notice broken p2 repositories, 
especially composites,  somewhere on
download.eclipse.org. Sometimes p2 refuses to load the composites altogether, 
sometimes it loads them only partially,
which often makes it even harder to detect the nature of the problem.

I have created a Jenkins job that finds and analyzes all p2 repos on the 
downloads server once per day. The job creates
per-project reports and an overview page. The reports focus on the parent/child 
relationships between the ~18,000
existing repos and highlight broken links. During the internal test phase of 
the report generator some projects could
already fix many of their broken repos, so that we're now down to 188 broken 
repos in total (down from ~550).

Please have a look at the overview page and find the report for your project:

https://download.eclipse.org/oomph/archive/p2-index/

I hope that the reports are helpful for you and that they help to eliminate all 
broken repos at some point. Your
feedback is most welcome ;-)

Cheers
/Eike


http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



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




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

Re: [cross-project-issues-dev] Project Repository Reports

[Ed Willink]

Hi Eike

Great stuff.

You might care to generate warnings for not-latest repos that are more 
than 5 years old on download.eclipse.org rather than archive.eclipse.org.


    Regards

        Ed

On 05/12/2019 07:51, Eike Stepper wrote:

Hi Committers,

Every once in a while during my work I notice broken p2 repositories, 
especially composites,  somewhere on download.eclipse.org. Sometimes 
p2 refuses to load the composites altogether, sometimes it loads them 
only partially, which often makes it even harder to detect the nature 
of the problem.


I have created a Jenkins job that finds and analyzes all p2 repos on 
the downloads server once per day. The job creates per-project reports 
and an overview page. The reports focus on the parent/child 
relationships between the ~18,000 existing repos and highlight broken 
links. During the internal test phase of the report generator some 
projects could already fix many of their broken repos, so that we're 
now down to 188 broken repos in total (down from ~550).


Please have a look at the overview page and find the report for your 
project:


https://download.eclipse.org/oomph/archive/p2-index/

I hope that the reports are helpful for you and that they help to 
eliminate all broken repos at some point. Your feedback is most 
welcome ;-)


Cheers
/Eike


http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or 
unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

Re: [cross-project-issues-dev] Project Repository Reports

[Ed Willink]

Hi

I use a 'shell' job[1]  to execute a command such as

ssh genie.qvt-...@projects-storage.eclipse.org cd 
/home/data/httpd/download.eclipse.org/mmt/qvto/updates/releases ; ant -f 
/shared/modeling/tools/promotion/manage-composite.xml remove 
-Dchild.repository=3.4.1


Unfortunately turnaround on such commands is tediously slow because of 
the one minute wait for an executor.


    Regards

        Ed Willink

[1] https://ci.eclipse.org/qvt-oml/job/shell/

On 05/12/2019 08:12, Arthur van Dorp wrote:

Hi Eike,

Thank you for the report. Is there an easy way (let's say per Jenkins job) to 
regenerate compositeArtifacts.jar and compositeContent.jar? The errors I've 
looked at were all missing old releases which were either archived away without 
updating the indexes or not correctly deployed (some nightly deployments).

Thanks and regards,
Arthur

-Original Message-
From: cross-project-issues-dev-boun...@eclipse.org 
 On Behalf Of Eike Stepper
Sent: Thursday, 5 December, 2019 08:52
To: cross-project-issues-dev@eclipse.org
Subject: [cross-project-issues-dev] Project Repository Reports

Hi Committers,

Every once in a while during my work I notice broken p2 repositories, 
especially composites,  somewhere on download.eclipse.org. Sometimes p2 refuses 
to load the composites altogether, sometimes it loads them only partially, 
which often makes it even harder to detect the nature of the problem.

I have created a Jenkins job that finds and analyzes all p2 repos on the 
downloads server once per day. The job creates per-project reports and an 
overview page. The reports focus on the parent/child relationships between the 
~18,000 existing repos and highlight broken links. During the internal test 
phase of the report generator some projects could already fix many of their 
broken repos, so that we're now down to 188 broken repos in total (down from 
~550).

Please have a look at the overview page and find the report for your project:

https://download.eclipse.org/oomph/archive/p2-index/

I hope that the reports are helpful for you and that they help to eliminate all 
broken repos at some point. Your feedback is most welcome ;-)

Cheers
/Eike


http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



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

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

Re: [cross-project-issues-dev] Do You Constantly Need to Login?

[Ed Willink]

HI Ed

Yes/No but certainly not often/constantly. I would say that for me it is 
twice as often as I might expect as a consequence of running a 'cleaner' 
or Firefox crashing. Do you have an overenthusiastic automated 
'cleaner'? What is often for me is the need to keep logging in to 
Jenkins, which is perhaps because the cookie is per-connection-id (?? 
dynamic IP address) rather than per remote user.


(I raised a Bugzilla about the loss of context via the login page years 
ago.)


    Regards

        Ed

On 04/12/2019 05:09, Ed Merks wrote:
I don't know if it's just me, or because of some Firefox issue, or 
because of some changes to the Eclipse infrastructure, but I find that 
I often/constantly need to login when I navigate to a Bugzilla, 
navigate to a Forum, or navigate to a CI instance.


Particularly with the Forum, it shows me needing to login, but when I 
do that it navigates me to this page:


  https://www.eclipse.org/forums/index.php/re/

And then I have to go back and refresh the Forum page that I was on 
before.  It's rather annoying!


Bugzilla seems to remember my login a little longer, but it too often 
requires a new login as well...


Is anyone else encountering such problems?

Regards,
Ed

___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or 
unsubscribe from this list, visit

https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

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

[Ed Willink]

Hi

Thanks, you must have fixed it. Everything started working again a few 
minutes after your message.


    Regards

        Ed Willink

On 25/11/2019 09:29, Frederic Gurr wrote:

Hi,

I can access the *.eclipse.org services just fine at the moment (from
Germany).
I will keep an eye on it and alert the Ottawa folks if necessary.


Regards,

Fred

On 25.11.19 09:50, Wim Jongman wrote:

I'm in the Amsterdam area and all services seem down.

On Mon, Nov 25, 2019 at 9:35 AM Matthias Sohn mailto:matthias.s...@gmail.com>> wrote:

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

 Hello,

 download.eclipse.org <http://download.eclipse.org> is not responding
 attempt to submit the problem to bugzilla also failed


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

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


 It blocks the release activities, please help.

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

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


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


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

[cross-project-issues-dev] Modisco request to rejoin SimRel

[Ed Willink]

Hi

It's after M2, but is it too late for Modisco to rejoin SimRel for 2019-12?

There will be a minor version jump for features from 1.2.0 to 1.5.0 to 
reflect the significant packaging changes as a consequence of folding in 
parts of EMF Facet and revitalizing the build. Plugin versions will 
progress as normal.


    Regards

        Ed Willink



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

Re: [cross-project-issues-dev] Eclipse Platform bundles usage of new language constructs and your plugins

[Ed Willink]

Hi

"move your bundle to newer BREE (highest BREE of deps)"

Seems like a good candidate for a MANIFEST.MF warning.

    Regards

        Ed Willink

On 17/10/2019 14:14, Aleksandar Kurtakov wrote:
Eclipse Platform starts using more and more new Java constructs (up to 
Java 8 for now) like try-with-resources, foreach and etc.
Bundles have their minimal versions bumped whenever BREE has been 
bumped so one can have clear indicator of this change.
This new features bring dependency on new classes like AutoClosable ( 
Java 1.7) , Iterable (Java 1.5) and probably others.
If your bundles have BREE lower than the Platform bundle they depend 
on and you have JVM of that level configured in Eclipse errors like 
"The type java.lang.Iterable cannot be resolved. It is indirectly 
referenced from required .class files" could be shown.
This is source level only issue if you try to build your old bundle 
against latest platform. People just using their prebuilt bundles 
won't face anything like this.

Possible fixes for this issue are:
* move your bundle to newer BREE (highest BREE of deps)
* build against proper target platform containing the oldest versions 
of your deps you support


I don't believe many people will face such issues but let's get this 
out for the sake of having it written somewhere.


--
Alexander Kurtakov
Red Hat Eclipse Team

___
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



--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] OI2JIRO migration - reminder - hipp4

[Ed Willink]

HI

Some mistake surely?

"Only one(!)"

Both QVTd and QVTo are marked as RESOLVED FIXED.

    Regards

        Ed Willink

On 24/09/2019 16:39, Frederic Gurr wrote:

Hi,

Unfortunately, there has been almost no progress on the migration of
JIPPs on hipp4: Only one(!) project acknowledged the migration in the
last month and a half. So we need to give this a gentle push:

*** Please note: if we don't hear back from projects before Monday,
October 21st, 2019, we will assume silent agreement that the migration
was successful. We will then start to archive the JIPP on the old infra. ***


Regards,

Fred

On 08.08.19 13:41, Frederic Gurr wrote:

Hi,

This is a gentle reminder to all projects whose JIPPs reside on hipp4 to
check and acknowledge that the migration from the old infra to the new
cluster based infra (codename Jiro) was successful.

This concerns the following projects:
* Ajdt
* Apogy
* App4mc
* Chess
* Diffmerge
* Dirigible
* Egerrit
* Epsilon
* ESF
* Glassfish-tools
* Henshin
* Jubula
* Keti
* Mdht
* Openk-platform
* Qvt-oml
* Qvtd
* Vorto

You can find the corresponding Bugzilla issues in the list here:
https://bugs.eclipse.org/bugs/showdependencytree.cgi?id=544221_resolved=1

Some of the projects are already actively involved, but the majority of
projects has not responded at all. A lot of people are still on summer
leave, so we know that things move slower around this time of the year.

Once you're back, we appreciate your assistance in finishing this
migration effort in a timely manner.


Regards,

Fred




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [cross-project-issues-dev] ACTION REQUIRED: SimRel Participants Please Fix Your SimRel Contribution's Problems

[Ed Willink]

Hi

On 24/09/2019 06:38, Ed Merks wrote:

For example Eclipse Collections has this specific report:

https://download.eclipse.org/oomph/archive/simrel/collections.aggrcon/index.html 




Thanks Ed. An easy to consume report. Great job.
Note that the license problem, i.e.,  all the various corrupted 
versions of SUA 2.0, is easy to fix, e.g., I fixed it like this for 
the Platform:


https://git.eclipse.org/r/#/c/149636/1/eclipse.platform.releng.prereqs.sdk/eclipse-sdk-prereqs.target 



If you don't really care what version of the license you use, there is a 
simpler solution; re-use the CBI master license. Version 0.0.0 will 
redirect to the latest.


Each feature.xml:




   
  [Documentation] Copyright text will be taken from the shared 
license feature

   

Each *.target:

  includeMode="planner" includeSource="true" type="InstallableUnit">

    
    location="https://download.eclipse.org/cbi/updates/license"/>

  

If you have your own license feature, just delete it.

Regards

Ed Willink


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [cross-project-issues-dev] SimRel 2019-09 Repository Quality

[Ed Willink]

Hi Ed

A nice step forward...

I was looking at the standard reports a couple of days ago and thinking, 
wow, how 1970's; no colour or hyperlinks. Your reports are in principle 
much better. (However perhaps your hyperlinks got line wrapped. I don't 
see the valid groups or circles that your refer to. I see four 
hyperlinks but only two distinct displays.)


But in both cases the emphasis is to catalog what is present rather than 
to target the offenders. I find it very time consuming to check whether 
my plugin patterns are in a good or bad section of the many reports.


Suggest that the reports are turned inside out so that there is a top 
level red/amber/green hyperlink for e.g. org.eclipse.xxx that takes me 
to the red (really bad) / amber (slightly bad) / green (ok) sub-reports 
of org.eclipse.xxx.


It may then be possible to encourage the org.eclipse.xxx releng to take 
action.


Regards

    Ed Willink


On 02/09/2019 09:43, Ed Merks wrote:


Mickael,

Comments below.

On 02.09.2019 10:30, Mickael Istria wrote:

Hi Ed,

Some similar (yet different) reports already exist in 
https://download.eclipse.org/releases/2019-09/201907191000/buildInfo/reporeports 
and some of the issues you mention have already been reported for ages.


Indeed, I am aware of those reports.  The presentation just makes  it 
difficult to get a real overview and it is not highly navigable.




---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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