from:"Aleksandar Kurtakov"

On Thu, Apr 7, 2022 at 3:30 PM Christian Dietrich <
christian.dietr...@itemis.de> wrote:

> created https://github.com/eclipse/ebr/pull/53/files
>

Looks like build went past this issue but next one arise:
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
(default-compile) on project org.apache.batik.bridge: Compilation failure:
Compilation failure:
[ERROR] Source option 6 is no longer supported. Use 7 or later.
[ERROR] Target option 6 is no longer supported. Use 7 or later.
[ERROR] -> [Help 1]


>
> Am 07.04.22 um 14:11 schrieb Aleksandar Kurtakov:
>
>
>
> On Thu, Apr 7, 2022 at 3:09 PM Christian Dietrich <
> christian.dietr...@itemis.de> wrote:
>
>> i cannot even reproduce this using java18
>>
>> mvn ebr:create-recipe -DgroupId=org.antlr -DartifactId=antlr-runtime
>> -Dversion=3.5.2 -DbundleSymbolicName=org.antlr.runtime
>> -Dmaven.repo.local=.m2
>>
>
> I see it building orbit-recipes clone.
> Java version: openjdk version "18" 2022-03-22
> OpenJDK Runtime Environment 22.3 (build 18+37)
> OpenJDK 64-Bit Server VM 22.3 (build 18+37, mixed mode, sharing)
> Maven version: Apache Maven 3.8.5
> (3599d3414f046de2324203b78ddcf9b5e4388aa0)
>
>
>> Am 07.04.22 um 14:02 schrieb Aleksandar Kurtakov:
>>
>>
>>
>> On Thu, Apr 7, 2022 at 2:12 PM Joakim Erdfelt 
>> wrote:
>>
>>> Regarding your JDK 17/18 support and your aQute issue.
>>>
>>> [INFO] --- ebr-maven-plugin:1.4.0-SNAPSHOT:bundle (default-bundle) @
>>> org.antlr.runtime ---
>>> [INFO] Gathering dependencies
>>> [INFO] Configured Artifact: org.antlr:antlr-runtime:3.5.2:jar
>>> [INFO] Unpacking
>>> /home/akurtakov/.m2/repository/org/antlr/antlr-runtime/3.5.2/antlr-runtime-3.5.2.jar
>>> to
>>> /home/akurtakov/git/orbit-recipes/antlr/org.antlr.runtime_3.5.2/target/dependency-bin
>>> with includes "**/*" and excludes "META-INF/maven/**/*.*"
>>> [INFO] Merging collected dependencies
>>> [INFO] Using 'UTF-8' encoding to copy filtered resources.
>>> [INFO] Copying 118 resources
>>> [INFO] Generating OSGi MANIFEST.MF
>>> [ERROR] An internal error occurred
>>> java.util.ConcurrentModificationException
>>> at java.util.TreeMap.callMappingFunctionWithCheck (TreeMap.java:750)
>>> at java.util.TreeMap.computeIfAbsent (TreeMap.java:604)
>>> at aQute.bnd.osgi.Jar.putResource (Jar.java:288)
>>> at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:202)
>>> at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:177)
>>> at java.nio.file.Files.walkFileTree (Files.java:2811)
>>> at aQute.bnd.osgi.Jar.buildFromDirectory (Jar.java:176)
>>> at aQute.bnd.osgi.Jar. (Jar.java:119)
>>> at aQute.bnd.osgi.Jar. (Jar.java:172)
>>> at org.apache.felix.bundleplugin.BundlePlugin.getOSGiBuilder
>>> (BundlePlugin.java:604)
>>> at org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer
>>> (ManifestPlugin.java:285)
>>> at org.apache.felix.bundleplugin.ManifestPlugin.execute
>>> (ManifestPlugin.java:111)
>>> at org.eclipse.ebr.maven.BundleMojo.buildBundle (BundleMojo.java:358)
>>> at org.eclipse.ebr.maven.BundleMojo.execute (BundleMojo.java:462)
>>>
>>> This is because of an old biz.aQute.bnd lib.
>>> Eclipse Jetty hit this same issue early, during the Java-17 Early Access
>>> builds.
>>> We build all the way up to Java-19 EA now.
>>>
>>> Update your biz.aQute.bndlib to version 5.3.0
>>>
>>>   
>>> biz.aQute.bnd
>>> biz.aQute.bndlib
>>> 5.3.0
>>>   
>>>
>>> If you manage the ebr-maven-plugin, then update it there.
>>> Otherwise, if you are a simple project using the ebr-maven-plugin, the
>>> above dependency in a  should be sufficient.
>>>
>>
>> I just don't have the energy to try saving things anymore, if it's
>> important enough for many people - it will get saved! Thanks for your hints
>> though!
>>
>>
>>>
>>> Btw, we LOVE the new Tycho maven P2 repo featureset.
>>> It's eliminated a big headache on our releases.
>>> We were spending on a good day about 6+ man hours to get an old school
>>> P2 repo out per release.
>>> On a problematic release it could easily top 40 man hours per release
>>> (ugh!).
>>>
>>> Now it's brain dead simple and just works, with an occasional bump in
>>> the Tycho version being used, wh

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

On Thu, Apr 7, 2022 at 3:09 PM Christian Dietrich <
christian.dietr...@itemis.de> wrote:

> i cannot even reproduce this using java18
>
> mvn ebr:create-recipe -DgroupId=org.antlr -DartifactId=antlr-runtime
> -Dversion=3.5.2 -DbundleSymbolicName=org.antlr.runtime
> -Dmaven.repo.local=.m2
>

I see it building orbit-recipes clone.
Java version: openjdk version "18" 2022-03-22
OpenJDK Runtime Environment 22.3 (build 18+37)
OpenJDK 64-Bit Server VM 22.3 (build 18+37, mixed mode, sharing)
Maven version: Apache Maven 3.8.5 (3599d3414f046de2324203b78ddcf9b5e4388aa0)


> Am 07.04.22 um 14:02 schrieb Aleksandar Kurtakov:
>
>
>
> On Thu, Apr 7, 2022 at 2:12 PM Joakim Erdfelt 
> wrote:
>
>> Regarding your JDK 17/18 support and your aQute issue.
>>
>> [INFO] --- ebr-maven-plugin:1.4.0-SNAPSHOT:bundle (default-bundle) @
>> org.antlr.runtime ---
>> [INFO] Gathering dependencies
>> [INFO] Configured Artifact: org.antlr:antlr-runtime:3.5.2:jar
>> [INFO] Unpacking
>> /home/akurtakov/.m2/repository/org/antlr/antlr-runtime/3.5.2/antlr-runtime-3.5.2.jar
>> to
>> /home/akurtakov/git/orbit-recipes/antlr/org.antlr.runtime_3.5.2/target/dependency-bin
>> with includes "**/*" and excludes "META-INF/maven/**/*.*"
>> [INFO] Merging collected dependencies
>> [INFO] Using 'UTF-8' encoding to copy filtered resources.
>> [INFO] Copying 118 resources
>> [INFO] Generating OSGi MANIFEST.MF
>> [ERROR] An internal error occurred
>> java.util.ConcurrentModificationException
>> at java.util.TreeMap.callMappingFunctionWithCheck (TreeMap.java:750)
>> at java.util.TreeMap.computeIfAbsent (TreeMap.java:604)
>> at aQute.bnd.osgi.Jar.putResource (Jar.java:288)
>> at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:202)
>> at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:177)
>> at java.nio.file.Files.walkFileTree (Files.java:2811)
>> at aQute.bnd.osgi.Jar.buildFromDirectory (Jar.java:176)
>> at aQute.bnd.osgi.Jar. (Jar.java:119)
>> at aQute.bnd.osgi.Jar. (Jar.java:172)
>> at org.apache.felix.bundleplugin.BundlePlugin.getOSGiBuilder
>> (BundlePlugin.java:604)
>> at org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer
>> (ManifestPlugin.java:285)
>> at org.apache.felix.bundleplugin.ManifestPlugin.execute
>> (ManifestPlugin.java:111)
>> at org.eclipse.ebr.maven.BundleMojo.buildBundle (BundleMojo.java:358)
>> at org.eclipse.ebr.maven.BundleMojo.execute (BundleMojo.java:462)
>>
>> This is because of an old biz.aQute.bnd lib.
>> Eclipse Jetty hit this same issue early, during the Java-17 Early Access
>> builds.
>> We build all the way up to Java-19 EA now.
>>
>> Update your biz.aQute.bndlib to version 5.3.0
>>
>>   
>> biz.aQute.bnd
>> biz.aQute.bndlib
>> 5.3.0
>>   
>>
>> If you manage the ebr-maven-plugin, then update it there.
>> Otherwise, if you are a simple project using the ebr-maven-plugin, the
>> above dependency in a  should be sufficient.
>>
>
> I just don't have the energy to try saving things anymore, if it's
> important enough for many people - it will get saved! Thanks for your hints
> though!
>
>
>>
>> Btw, we LOVE the new Tycho maven P2 repo featureset.
>> It's eliminated a big headache on our releases.
>> We were spending on a good day about 6+ man hours to get an old school P2
>> repo out per release.
>> On a problematic release it could easily top 40 man hours per release
>> (ugh!).
>>
>> Now it's brain dead simple and just works, with an occasional bump in the
>> Tycho version being used, which is automatically reported to us via the
>> github tooling.
>>
>
> Exactly my experience and I hear/see the same comments everywhere people
> did the change. The more people showing their success stories the better to
> show the real gains.
>
>
>>
>> - Joakim
>>
>>
>> On Thu, Apr 7, 2022 at 1:46 AM Aleksandar Kurtakov 
>> wrote:
>>
>>>
>>>
>>> On Thu, Apr 7, 2022 at 9:30 AM Aleksandar Kurtakov 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Apr 7, 2022 at 8:34 AM Ed Merks  wrote:
>>>>
>>>>> Christian,
>>>>>
>>>>> I share your frustrations.  Yes, much is being done to make life
>>>>> easier
>>>>> and/or better (direct Maven consumption and Github with github issues)
>>>>> but somehow every change is also disruptive and very often time
>>>>> consuming such

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

On Thu, Apr 7, 2022 at 2:12 PM Joakim Erdfelt 
wrote:

> Regarding your JDK 17/18 support and your aQute issue.
>
> [INFO] --- ebr-maven-plugin:1.4.0-SNAPSHOT:bundle (default-bundle) @
> org.antlr.runtime ---
> [INFO] Gathering dependencies
> [INFO] Configured Artifact: org.antlr:antlr-runtime:3.5.2:jar
> [INFO] Unpacking
> /home/akurtakov/.m2/repository/org/antlr/antlr-runtime/3.5.2/antlr-runtime-3.5.2.jar
> to
> /home/akurtakov/git/orbit-recipes/antlr/org.antlr.runtime_3.5.2/target/dependency-bin
> with includes "**/*" and excludes "META-INF/maven/**/*.*"
> [INFO] Merging collected dependencies
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] Copying 118 resources
> [INFO] Generating OSGi MANIFEST.MF
> [ERROR] An internal error occurred
> java.util.ConcurrentModificationException
> at java.util.TreeMap.callMappingFunctionWithCheck (TreeMap.java:750)
> at java.util.TreeMap.computeIfAbsent (TreeMap.java:604)
> at aQute.bnd.osgi.Jar.putResource (Jar.java:288)
> at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:202)
> at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:177)
> at java.nio.file.Files.walkFileTree (Files.java:2811)
> at aQute.bnd.osgi.Jar.buildFromDirectory (Jar.java:176)
> at aQute.bnd.osgi.Jar. (Jar.java:119)
> at aQute.bnd.osgi.Jar. (Jar.java:172)
> at org.apache.felix.bundleplugin.BundlePlugin.getOSGiBuilder
> (BundlePlugin.java:604)
> at org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer
> (ManifestPlugin.java:285)
> at org.apache.felix.bundleplugin.ManifestPlugin.execute
> (ManifestPlugin.java:111)
> at org.eclipse.ebr.maven.BundleMojo.buildBundle (BundleMojo.java:358)
> at org.eclipse.ebr.maven.BundleMojo.execute (BundleMojo.java:462)
>
> This is because of an old biz.aQute.bnd lib.
> Eclipse Jetty hit this same issue early, during the Java-17 Early Access
> builds.
> We build all the way up to Java-19 EA now.
>
> Update your biz.aQute.bndlib to version 5.3.0
>
>   
> biz.aQute.bnd
> biz.aQute.bndlib
> 5.3.0
>   
>
> If you manage the ebr-maven-plugin, then update it there.
> Otherwise, if you are a simple project using the ebr-maven-plugin, the
> above dependency in a  should be sufficient.
>

I just don't have the energy to try saving things anymore, if it's
important enough for many people - it will get saved! Thanks for your hints
though!


>
> Btw, we LOVE the new Tycho maven P2 repo featureset.
> It's eliminated a big headache on our releases.
> We were spending on a good day about 6+ man hours to get an old school P2
> repo out per release.
> On a problematic release it could easily top 40 man hours per release
> (ugh!).
>
> Now it's brain dead simple and just works, with an occasional bump in the
> Tycho version being used, which is automatically reported to us via the
> github tooling.
>

Exactly my experience and I hear/see the same comments everywhere people
did the change. The more people showing their success stories the better to
show the real gains.


>
> - Joakim
>
>
> On Thu, Apr 7, 2022 at 1:46 AM Aleksandar Kurtakov 
> wrote:
>
>>
>>
>> On Thu, Apr 7, 2022 at 9:30 AM Aleksandar Kurtakov 
>> wrote:
>>
>>>
>>>
>>> On Thu, Apr 7, 2022 at 8:34 AM Ed Merks  wrote:
>>>
>>>> Christian,
>>>>
>>>> I share your frustrations.  Yes, much is being done to make life easier
>>>> and/or better (direct Maven consumption and Github with github issues)
>>>> but somehow every change is also disruptive and very often time
>>>> consuming such that you much spend time on what feels like a gigantic
>>>> no-op...
>>>>
>>>> More comments below.
>>>>
>>>> On 07.04.2022 04:54, Christian Dietrich wrote:
>>>> > Hi all, my frustration of the current state has cost me another
>>>> > sleepless night and thus i need to start this discussion again.
>>>> >
>>>> > All of the following statements are subjective and describe my
>>>> > personal view and option and feelings.
>>>> >
>>>> > Trigger was
>>>> > https://www.eclipse.org/lists/cross-project-issues-dev/msg19066.html
>>>> > but is just another big drop to barrel to overflow.
>>>> >
>>>> > What is it about:
>>>> >
>>>> > - PlatformRel: Release of the basic eclipse platform and jdt on a
>>>> > regular basis
>>>> > - SimRel: All project release together with PlatformRel in versions
>>>> > that w

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

On Thu, Apr 7, 2022 at 9:30 AM Aleksandar Kurtakov 
wrote:

>
>
> On Thu, Apr 7, 2022 at 8:34 AM Ed Merks  wrote:
>
>> Christian,
>>
>> I share your frustrations.  Yes, much is being done to make life easier
>> and/or better (direct Maven consumption and Github with github issues)
>> but somehow every change is also disruptive and very often time
>> consuming such that you much spend time on what feels like a gigantic
>> no-op...
>>
>> More comments below.
>>
>> On 07.04.2022 04:54, Christian Dietrich wrote:
>> > Hi all, my frustration of the current state has cost me another
>> > sleepless night and thus i need to start this discussion again.
>> >
>> > All of the following statements are subjective and describe my
>> > personal view and option and feelings.
>> >
>> > Trigger was
>> > https://www.eclipse.org/lists/cross-project-issues-dev/msg19066.html
>> > but is just another big drop to barrel to overflow.
>> >
>> > What is it about:
>> >
>> > - PlatformRel: Release of the basic eclipse platform and jdt on a
>> > regular basis
>> > - SimRel: All project release together with PlatformRel in versions
>> > that work together. This requires the projects to "paying attention"
>> > to ensure this holds true.
>> > - Orbit: Central place to pull 3rd dependencies from. This avoid each
>> > and every project packaging their own stuff and makes it possible for
>> > projects with the same dependency to work together seemlessly.
>> >
>> > Projects: Eclipse has projects with
>> > - some budget
>> > - a limited budget (i would categeorize Xtext with 4-6 days a month
>> here)
>> > - basically no buget
>> EMF, XSD, JustJ and Oomph have been budget free for close to 2 years.
>> >
>> > Projects and values:
>> > - Some projects value support for older platform and java versions,
>> > others dont
>> > - Some projects "pay attention", others dont
>> >
>> EMF tests against Helios.  I had been trying to keep Oomph running on
>> Juno, but that was no longer possible with all the nice though
>> disruptive p2 changes for PGP.   JustJ keeps up with new Adoptium
>> releases; I'm currently testing Java 18.
>>
>> > Xtext: what do i do for Xtext
>> > - work with community
>> > - fix bug
>> > - develop some smaller features
>> > - pay attention
>> >   - fix broken Jenkins files cause infrastructure changes
>> >   - test against upstream platform and jdt
>> >   - bump versions of 3rd party dependencies
>> >   - contribute to upstream project
>> >   - 
>> >
>> Working with the community and as a community is key.  So I'm not so
>> happy to see comments like "That's more the problem of SimRel" as if we
>> aren't all part of the same community.   I know it's not fair to expect
>> the Platform to solve world hunger, but treating world hunger as someone
>> else's problem is questionable.
>>
>> I know Xtext in particular is used in a vast downstream ecosystem and I
>> know that this consumption makes all the projects upstream from Xtext,
>> including EMF and the Platform more relevant to a broader community.  So
>> we should all be concerned about Xtext's welfare.  In addition to that,
>> somehow Xtext's downstream ecosystem needs to be leveraged to sponsor
>> these activities, and therein lies a major point of failure.
>>
>> > What makes me frustrated:
>> >
>> > I have the feeling that i spend 95% of my buget to accommodate for
>> > upstream infrastructure changes so that there is basically no time
>> > left for bugfixes or features. The 3 month simrel also adds time
>> > pressure to that "paying attention" if you take it serious.
>> Yes, welcome to my world.  It's almost impossible to find time to work
>> on new things in my own technologies.
>> >
>> > The trigger(s):
>> > - https://bugs.eclipse.org/bugs/show_bug.cgi?id=568936 with a cleanup
>> > process in orbit we have to deal with stuff disappearing from orbit.
>> > it is clear that this is a debt in orbit and i am ok with spending a
>> > 2/3 month worth of budget to accomodate for it.
>> > - https://www.eclipse.org/lists/cross-project-issues-dev/msg19066.html
>> > / https://bugs.eclipse.org/bugs/show_bug.cgi?id=579574
>> >
>> > the 2nd one is the defacto abolishment of orbit.
>> Yes, this doesn't feel like a commun

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

e
> direct Maven name.  Does PDE's decision also make the decision for JDT?
> I don't know...
>
> > What does this mean for Xtext
> >
> > - We need to be able to support older platforms and java versions with
> > newer tycho versions + the work for Jenkins file to make this possible
> > (8 different builds)
> > - We need to find out how to use the p2 maven feature from oomph (at a
> > first glance i could not find an option) or replace oomph with target
> > files.
>
> I hope someone will step forward to sponsor this feature; it looks some
> promising that this will be the case...
>
> I think the issue here is mostly that you need bundles in a p2 repo, right?
>
> > - Alternatively we can stop supporting more than 1 platform or Java
> > versions.
> >
> That would provide less value to your consumers and make new versions
> less consumable and less relevant.   I very often see very old Platform
> versions being used because with all the great changes and evolutions in
> the Platform, also come regressions and breaking changes that hinder
> adoption and potentially lead to dropping adoption altogether...
> > I cannot tell how much work this will be because i am neither a tycho
> > nor a Jenkinsfile nor an Oomph expert. I also have no pointers where
> > to copy & paste from to make my life easier with that.
> Perhaps there are some things I can do to help?
> >
> > So i dont know if i can make this possible with the budget i have
> > (even less i can imagine projects with much less budget can do)
> >
> > So what can i do:
> > - support only latest greated and pass the ball downstream
> What specifically is leading to this inability to support older versions
> in this specific case?  What can be done to mitigate that?
> > - pull Xtext out of simrel and with it all of its dependencies (that
> > would also include lsp4e for example)
> No please.
> > - stay in simrel but stop "paying attention" and if stuff works together
> >
> Would Xtext still work on the latest if you did nothing?
> > Alternatives:
> > - why no keep orbit as place for 3rd party dependencies. I dont know
> > what would need to be done to  make use of the p2 maven feature there
> > instead in the projects on their own.
>
> Perhaps a middle ground would be to build/provide an Orbit-like repo
> that pulls things from Maven and publishes them in the p2 repository.
> Apparently this is so easy to do, each project should do it itself.  But
> if it's so easy to do, "we" could also do that in a central place as a
> service to SimRel and to the broader community.  If the Platform doesn't
> want to do that, help with that, nor consume from that, that doesn't
> prevent providing the same 3rd party Maven bundles being
> provided/consumed/used by the Platform...
>

As someone who did a fair part of that work on Platform behalf, down to
maintaining Orbit bundles, even keeping Orbit and EBR releng working at
times and etc. - to me Orbit just proved to be extra step for no benefit
with very few people stepping up to share the burden so the choice had to
be made - do the work directly and skip the time consuming extra steps or
let Platform suffer (we are already far behind on many dependencies which
has the issue that we ship deps with CVEs(e.g. commons-fileupload), no
support from upstream and etc.). Now that I've seen the faster and easier
path I don't see much point in doing this extra work as once this happens I
would be left to deal with it on my own again as history has shown to me.


>
> Would that help at least partially address your current concerns?   Or
> is there something that's broken even with that approach?
>
> > Thanks and regards
> > 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
>


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

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

2022-04-06 Thread Aleksandar Kurtakov

On Wed, Apr 6, 2022 at 6:04 PM Dietrich, Christian <
christian.dietr...@itemis.de> wrote:

> do you have an estimate how much time it will cost each and every project
> to adapt to this new process :(
>

Nope, I have estimated how much time it costs to keep up with dependency
changes in Platform alone and the new process cuts it literally to 1/3 of
it. So similar benefit is to be expected for others once the initial change
is done.


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


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

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

On Tue, Apr 5, 2022 at 2:54 PM Christoph Läubrich 
wrote:

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

One such project is Lucene. I never found the time to report against it so
far. Help is always more than welcome .
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/136


>
> Am 05.04.22 um 13:48 schrieb Aleksandar Kurtakov:
> > Hey everyone,
> > With PGP signing support, latest Tycho work and M2E extending PDE so
> > *.target files can refer/use dependencies from Maven Central directly
> > will prefer to use dependencies from Maven Central when updating to new
> > versions of libraries.
> > This would be done only when we update to a new version of libraries or
> > the dependency we use is no longer available in the latest Orbit build.
> > When Maven Central is not OSGi artifact  Orbit will be preferred.
> >  From releng POV it would simply remove the middle man (Orbit/EBR) as
> > Tycho automates what was achieved via EBR as an intermediate step to be
> > part of the regular build.
> > Extra benefits are:
> > * Eclipse will no longer ship modified version of upstream release (PGP
> > signature is in p2 metadata and not modifying the jar as jarsigner does)
> > * Eclipse will not longer ship bundles with symbolic names that do not
> > match upstream developers decision (as it happens with number of Orbit
> > artifacts)
> > * Version updates could be done in chunks rather than all changes at
> > once to work with latest Orbit
> >
> > I strongly encourage other projects to take that path too for third
> > party dependencies.
> >
> >
> > --
> > Aleksandar Kurtakov
> > Red Hat Eclipse Team
> >
> > ___
> > cross-project-issues-dev mailing list
> > cross-project-issues-dev@eclipse.org
> > To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> _______
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


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

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

On Tue, Apr 5, 2022 at 2:57 PM Dirk Fauth via cross-project-issues-dev <
cross-project-issues-dev@eclipse.org> wrote:

> @Aleks
> Maybe jetty is already signed correctly? How will be the process for
> unsigned content?
>

This has been an ongoing topic for the last year or so. The core is
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/master/eclipse.platform.releng.tychoeclipsebuilder/pom.xml#L38
which defines which key to use to sign (every project has a gpg key which
is available via the Jenkins build).There is a param that defines that only
non-jarsigned content is signed with pgp as it's still preferred for our
own artifacts to be jarsigned but changing upstream artifacts should be
avoided when possible.


>
>
> Christoph Läubrich  schrieb am Di., 5. Apr. 2022,
> 13:54:
>
>>  > When Maven Central is not OSGi artifact  Orbit will be preferred.
>>
>> I can only encourage everyone to open a ticket for such project and help
>> them to include OSGi meta-data in the first place instead of putting the
>> effort else-where, as adding those does not harm the project but helps
>> integration it with just a few extra lines in the manifest.
>>
>> Am 05.04.22 um 13:48 schrieb Aleksandar Kurtakov:
>> > Hey everyone,
>> > With PGP signing support, latest Tycho work and M2E extending PDE so
>> > *.target files can refer/use dependencies from Maven Central directly
>> > will prefer to use dependencies from Maven Central when updating to new
>> > versions of libraries.
>> > This would be done only when we update to a new version of libraries or
>> > the dependency we use is no longer available in the latest Orbit build.
>> > When Maven Central is not OSGi artifact  Orbit will be preferred.
>> >  From releng POV it would simply remove the middle man (Orbit/EBR) as
>> > Tycho automates what was achieved via EBR as an intermediate step to be
>> > part of the regular build.
>> > Extra benefits are:
>> > * Eclipse will no longer ship modified version of upstream release (PGP
>> > signature is in p2 metadata and not modifying the jar as jarsigner does)
>> > * Eclipse will not longer ship bundles with symbolic names that do not
>> > match upstream developers decision (as it happens with number of Orbit
>> > artifacts)
>> > * Version updates could be done in chunks rather than all changes at
>> > once to work with latest Orbit
>> >
>> > I strongly encourage other projects to take that path too for third
>> > party dependencies.
>> >
>> >
>> > --
>> > Aleksandar Kurtakov
>> > Red Hat Eclipse Team
>> >
>> > ___
>> > cross-project-issues-dev mailing list
>> > cross-project-issues-dev@eclipse.org
>> > To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


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

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

Jetty is already used that way . See
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/issues/130
for details.

On Tue, Apr 5, 2022 at 2:48 PM Aleksandar Kurtakov 
wrote:

> Hey everyone,
> With PGP signing support, latest Tycho work and M2E extending PDE so
> *.target files can refer/use dependencies from Maven Central directly will
> prefer to use dependencies from Maven Central when updating to new versions
> of libraries.
> This would be done only when we update to a new version of libraries or
> the dependency we use is no longer available in the latest Orbit build.
> When Maven Central is not OSGi artifact  Orbit will be preferred.
> From releng POV it would simply remove the middle man (Orbit/EBR) as Tycho
> automates what was achieved via EBR as an intermediate step to be part of
> the regular build.
> Extra benefits are:
> * Eclipse will no longer ship modified version of upstream release (PGP
> signature is in p2 metadata and not modifying the jar as jarsigner does)
> * Eclipse will not longer ship bundles with symbolic names that do not
> match upstream developers decision (as it happens with number of Orbit
> artifacts)
> * Version updates could be done in chunks rather than all changes at once
> to work with latest Orbit
>
> I strongly encourage other projects to take that path too for third party
> dependencies.
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
>


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

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

Hey everyone,
With PGP signing support, latest Tycho work and M2E extending PDE so
*.target files can refer/use dependencies from Maven Central directly will
prefer to use dependencies from Maven Central when updating to new versions
of libraries.
This would be done only when we update to a new version of libraries or the
dependency we use is no longer available in the latest Orbit build. When
Maven Central is not OSGi artifact  Orbit will be preferred.
>From releng POV it would simply remove the middle man (Orbit/EBR) as Tycho
automates what was achieved via EBR as an intermediate step to be part of
the regular build.
Extra benefits are:
* Eclipse will no longer ship modified version of upstream release (PGP
signature is in p2 metadata and not modifying the jar as jarsigner does)
* Eclipse will not longer ship bundles with symbolic names that do not
match upstream developers decision (as it happens with number of Orbit
artifacts)
* Version updates could be done in chunks rather than all changes at once
to work with latest Orbit

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


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

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

On Thu, Jan 13, 2022 at 6:31 PM Alexander Fedorov <
alexander.fedo...@arsysop.ru> wrote:

> Good to know that SimRel has chances to survive. Personally I can hardly
> imagine the future of Eclipse "classic" ecosystem without common baseline
> like we have now with SimRel - things could degrade really quickly.
>
> What I want to understand is the status of recommendation from Jonah:
> "passage's p2 repo should be publishing its third party deps and it should
> be possible for consumers to install passage from passage's p2 repo without
> requiring an orbit repo be added too".
>
> * Is it the best practice to follow for every SimRel project?
> * If so, could it be a part of Project Handbook?
>
> I was preferring to use Orbit version of bundles (from the corresponding
> Orbit contribution) since otherwise we will have a lot of duplicated 3rd
> party bundles with different versions in one Eclipse Package.
>

You can still use Orbit version and mirror it on your p2 site. That's what
most projects too:
* Have latest Orbit as part of their target platform
* Mirror dependencies in project's own p2 repo

If every project does that there will be no need for Orbit contribution
directly and will give greater control over Simrel content as it will be
well known who exactly required the given version. Right now if Orbit has
newer version than what projects were built and tested against - simrel can
contain totally untested and worst case non-working dependency.


> Perhaps this is not a value anymore.
>
> Please advice.
>
> Thanks in advance,
> AF
>
>
> 1/13/2022 5:56 PM, Aleksandar Kurtakov пишет:
>
>
>
> On Thu, Jan 13, 2022 at 4:31 PM Ed Merks  wrote:
>
>> It's not entirely clear that a generous layer of critique and pessimism
>> as icing on the neglect-and-apathy cake will help the broader team be more
>> motivated to work toward a more viable solution.  Certainly I personally
>> find it hugely challenging to deal with what feels like an endless stream
>> of disruptive changes that percolate their way through my software stack.
>> My projects are like book ends on this train.  Add to that playing police
>> and being the emergency response team, complemented by disruptive
>> infrastructure changes to add to the confusion, and it feels like the
>> goodness just never ends.  I could spend some time pointlessly pointing
>> fingers at whom to blame for all these messy things.  But I always remind
>> myself that when I point fingers at others, several of my own fingers are
>> always pointing back at me.  So I try to focus on what can be done to make
>> things better and what I can do to enable those.
>>
> I couldn't agree more. I started to blame myself for many failures and
> they start to happen faster and faster as I clearly fail to keep the pace
> and the only solution I've found is to just drop things that are
> non-essential to me/my usecases/. Best way to do things better is to just
> let non-viable things fall off. My experience (unfortunately!) is that it
> almost never happens to get help on things until someone getting it for
> free for now gets the breakage due to no longer being kept up and warning
> messages seem to be just ignored.
>
>
>> Let's also look at some of the positives.  We are building a highly
>> complex system, comprising a great many moving parts, with a lot of very
>> busy people involved, to deliver some really amazing results, on time, four
>> times a year.  Surely we're doing a few things right...
>>
> And we should strive for even better results. Quite often "less is more" .
>
>
>> Cheers,
>> Ed
>> On 13.01.2022 14:51, Aleksandar Kurtakov wrote:
>>
>>
>>
>> On Thu, Jan 13, 2022 at 3:47 PM Jonah Graham 
>> wrote:
>>
>>>
>>>
>>> On Thu., Jan. 13, 2022, 08:18 Aleksandar Kurtakov, 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Jan 13, 2022 at 3:11 PM Jonah Graham 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Thu., Jan. 13, 2022, 05:49 Alexander Fedorov, <
>>>>> alexander.fedo...@arsysop.ru> wrote:
>>>>>
>>>>>> > Orbit essentially is like Maven Central
>>>>>>
>>>>>> In that case I don't understand why do we need Orbit at all. With the
>>>>>> latest announcements regarding tycho capabilities from Christoph + lack 
>>>>>> of
>>>>>> resources to support Orbit in safe form it seems to be useless.
>>>>>>
>>>>>
>>>>> You have hit the nail on t

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

On Thu, Jan 13, 2022 at 4:31 PM Ed Merks  wrote:

> It's not entirely clear that a generous layer of critique and pessimism as
> icing on the neglect-and-apathy cake will help the broader team be more
> motivated to work toward a more viable solution.  Certainly I personally
> find it hugely challenging to deal with what feels like an endless stream
> of disruptive changes that percolate their way through my software stack.
> My projects are like book ends on this train.  Add to that playing police
> and being the emergency response team, complemented by disruptive
> infrastructure changes to add to the confusion, and it feels like the
> goodness just never ends.  I could spend some time pointlessly pointing
> fingers at whom to blame for all these messy things.  But I always remind
> myself that when I point fingers at others, several of my own fingers are
> always pointing back at me.  So I try to focus on what can be done to make
> things better and what I can do to enable those.
>
I couldn't agree more. I started to blame myself for many failures and they
start to happen faster and faster as I clearly fail to keep the pace and
the only solution I've found is to just drop things that are non-essential
to me/my usecases/. Best way to do things better is to just let non-viable
things fall off. My experience (unfortunately!) is that it almost never
happens to get help on things until someone getting it for free for now
gets the breakage due to no longer being kept up and warning messages seem
to be just ignored.


> Let's also look at some of the positives.  We are building a highly
> complex system, comprising a great many moving parts, with a lot of very
> busy people involved, to deliver some really amazing results, on time, four
> times a year.  Surely we're doing a few things right...
>
And we should strive for even better results. Quite often "less is more" .


> Cheers,
> Ed
> On 13.01.2022 14:51, Aleksandar Kurtakov wrote:
>
>
>
> On Thu, Jan 13, 2022 at 3:47 PM Jonah Graham 
> wrote:
>
>>
>>
>> On Thu., Jan. 13, 2022, 08:18 Aleksandar Kurtakov, 
>> wrote:
>>
>>>
>>>
>>> On Thu, Jan 13, 2022 at 3:11 PM Jonah Graham 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu., Jan. 13, 2022, 05:49 Alexander Fedorov, <
>>>> alexander.fedo...@arsysop.ru> wrote:
>>>>
>>>>> > Orbit essentially is like Maven Central
>>>>>
>>>>> In that case I don't understand why do we need Orbit at all. With the
>>>>> latest announcements regarding tycho capabilities from Christoph + lack of
>>>>> resources to support Orbit in safe form it seems to be useless.
>>>>>
>>>>
>>>> You have hit the nail on the head! Although useless is going a little
>>>> far. Orbit does not likely have a long term future. However as there are
>>>> many projects that build from it still we need it. Also there is a problem
>>>> if multiple projects start contributing the same version of third party lib
>>>> that will hopefully be solved in the future with PGP signing.
>>>>
>>>> Orbit should not be directly contributing to simrel, but for a variety
>>>> of reasons it does (see comments in the file)
>>>>
>>>> As mentioned in the Gerrit, passage's p2 repo should be publishing its
>>>> third party deps and it should be possible for consumers to install passage
>>>> from passage's p2 repo without requiring an orbit repo be added too.
>>>>
>>>> I know for sure that numerous projects are not quite doing that (again
>>>> see comments in orbit.aggrcon) but hopefully at some point the temporary
>>>> contribution of orbit to simrel directly can be removed.
>>>>
>>>
>>> I would dare to say that as long as the workarounds are in simrel
>>> nothing will get fixed - it's time to face reality.
>>>
>>
>> Probably correct, but I don't have the nerve to disable (or
>> knowledge/time to fix) Mylyn.
>>
>
> ^^ Exactly - the amount of complains from people not paying attention and
> putting burden on others to workaround for them is what made me lost trust
> that simrel is viable approach.
>
>
>>
>>
>>>
>>>>
>>>> HTH,
>>>> Jonah
>>>>
>>>>
>>>>>
>>>>> Regards,
>>>>> AF
>>>>>
>>>>> 1/13/2022 1:29 PM, Gunnar Wagenknecht пишет:
>>>>>
>>>>>
>>>>> On Jan 13, 2022, at 10:55, Aleksandar

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

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

>
>
> On Thu., Jan. 13, 2022, 08:18 Aleksandar Kurtakov, 
> wrote:
>
>>
>>
>> On Thu, Jan 13, 2022 at 3:11 PM Jonah Graham 
>> wrote:
>>
>>>
>>>
>>> On Thu., Jan. 13, 2022, 05:49 Alexander Fedorov, <
>>> alexander.fedo...@arsysop.ru> wrote:
>>>
>>>> > Orbit essentially is like Maven Central
>>>>
>>>> In that case I don't understand why do we need Orbit at all. With the
>>>> latest announcements regarding tycho capabilities from Christoph + lack of
>>>> resources to support Orbit in safe form it seems to be useless.
>>>>
>>>
>>> You have hit the nail on the head! Although useless is going a little
>>> far. Orbit does not likely have a long term future. However as there are
>>> many projects that build from it still we need it. Also there is a problem
>>> if multiple projects start contributing the same version of third party lib
>>> that will hopefully be solved in the future with PGP signing.
>>>
>>> Orbit should not be directly contributing to simrel, but for a variety
>>> of reasons it does (see comments in the file)
>>>
>>> As mentioned in the Gerrit, passage's p2 repo should be publishing its
>>> third party deps and it should be possible for consumers to install passage
>>> from passage's p2 repo without requiring an orbit repo be added too.
>>>
>>> I know for sure that numerous projects are not quite doing that (again
>>> see comments in orbit.aggrcon) but hopefully at some point the temporary
>>> contribution of orbit to simrel directly can be removed.
>>>
>>
>> I would dare to say that as long as the workarounds are in simrel nothing
>> will get fixed - it's time to face reality.
>>
>
> Probably correct, but I don't have the nerve to disable (or knowledge/time
> to fix) Mylyn.
>

^^ Exactly - the amount of complains from people not paying attention and
putting burden on others to workaround for them is what made me lost trust
that simrel is viable approach.


>
>
>>
>>>
>>> HTH,
>>> Jonah
>>>
>>>
>>>>
>>>> Regards,
>>>> AF
>>>>
>>>> 1/13/2022 1:29 PM, Gunnar Wagenknecht пишет:
>>>>
>>>>
>>>> On Jan 13, 2022, at 10:55, Aleksandar Kurtakov 
>>>> wrote:
>>>>
>>>>
>>>> IMHO, people should actively remove content from Orbit that has CVEs.
>>>> Much like with any other project. Even without replacing it with a fixed
>>>> version. We will be better with less but trusted content than questioning
>>>> ourselves for each artifact.
>>>>
>>>>
>>>> Agreed. There is usually a clean-up/removal of unneeded stuff. But the
>>>> downloads are still available for projects consuming the repositories.
>>>>
>>>> >[...] That is definitely something
>>>>> > new, since Orbit was a trusted source of 3rd party libraries for many
>>>>>
>>>>> > years.
>>>>>
>>>>
>>>>
>>>> That's a misconception. Orbit essentially is like Maven Central.
>>>> Instead of Maven Artifacts it distributes Eclipse plug-in artifacts. Maven
>>>> Central still distributes the vulnerable Log4j version and ton of other
>>>> libraries with CVEs. Does that make it a less trustworthy source now? I
>>>> don't think so. Consumers still need to stay on top of those.
>>>>
>>>> -Gunnar
>>>>
>>>>
>>>> --
>>>> Gunnar Wagenknecht
>>>> gun...@wagenknecht.org, http://guw.io/
>>>>
>>>>
>>>>
>>>> ___
>>>> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
>>>> To unsubscribe from this list, visit 
>>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>>
>>>>
>>>> _______
>>>> cross-project-issues-dev mailing list
>>>> cross-project-issues-dev@eclipse.org
>>>> To unsubscribe from this list, visit
>>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>>
>>> ___
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@eclipse.org
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>>
>>
>> --
>> Aleksandar Kurtakov
>> Red Hat Eclipse Team
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


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

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

On Thu, Jan 13, 2022 at 3:11 PM Jonah Graham  wrote:

>
>
> On Thu., Jan. 13, 2022, 05:49 Alexander Fedorov, <
> alexander.fedo...@arsysop.ru> wrote:
>
>> > Orbit essentially is like Maven Central
>>
>> In that case I don't understand why do we need Orbit at all. With the
>> latest announcements regarding tycho capabilities from Christoph + lack of
>> resources to support Orbit in safe form it seems to be useless.
>>
>
> You have hit the nail on the head! Although useless is going a little far.
> Orbit does not likely have a long term future. However as there are many
> projects that build from it still we need it. Also there is a problem if
> multiple projects start contributing the same version of third party lib
> that will hopefully be solved in the future with PGP signing.
>
> Orbit should not be directly contributing to simrel, but for a variety of
> reasons it does (see comments in the file)
>
> As mentioned in the Gerrit, passage's p2 repo should be publishing its
> third party deps and it should be possible for consumers to install passage
> from passage's p2 repo without requiring an orbit repo be added too.
>
> I know for sure that numerous projects are not quite doing that (again see
> comments in orbit.aggrcon) but hopefully at some point the temporary
> contribution of orbit to simrel directly can be removed.
>

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


>
> HTH,
> Jonah
>
>
>>
>> Regards,
>> AF
>>
>> 1/13/2022 1:29 PM, Gunnar Wagenknecht пишет:
>>
>>
>> On Jan 13, 2022, at 10:55, Aleksandar Kurtakov 
>> wrote:
>>
>>
>> IMHO, people should actively remove content from Orbit that has CVEs.
>> Much like with any other project. Even without replacing it with a fixed
>> version. We will be better with less but trusted content than questioning
>> ourselves for each artifact.
>>
>>
>> Agreed. There is usually a clean-up/removal of unneeded stuff. But the
>> downloads are still available for projects consuming the repositories.
>>
>> >[...] That is definitely something
>>> > new, since Orbit was a trusted source of 3rd party libraries for many
>>> > years.
>>>
>>
>>
>> That's a misconception. Orbit essentially is like Maven Central. Instead
>> of Maven Artifacts it distributes Eclipse plug-in artifacts. Maven Central
>> still distributes the vulnerable Log4j version and ton of other libraries
>> with CVEs. Does that make it a less trustworthy source now? I don't think
>> so. Consumers still need to stay on top of those.
>>
>> -Gunnar
>>
>>
>> --
>> Gunnar Wagenknecht
>> gun...@wagenknecht.org, http://guw.io/
>>
>>
>>
>> ___
>> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
>> To unsubscribe from this list, visit 
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>>
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


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

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

On Thu, Jan 13, 2022 at 12:49 PM Alexander Fedorov <
alexander.fedo...@arsysop.ru> wrote:

> > Orbit essentially is like Maven Central
>
> In that case I don't understand why do we need Orbit at all. With the
> latest announcements regarding tycho capabilities from Christoph + lack of
> resources to support Orbit in safe form it seems to be useless.
>

I fully agree with you here and that's how we plan to do things for Eclipse
Platform starting from the 2022-06 release. For me Orbit is on life support
until some final bits are in place to use plain Maven Central. Note that
there are some things like Ant where Orbit does way more so it may stay in
some very reduced form for such cases.


>
> Regards,
> AF
>
> 1/13/2022 1:29 PM, Gunnar Wagenknecht пишет:
>
>
> On Jan 13, 2022, at 10:55, Aleksandar Kurtakov 
> wrote:
>
>
> IMHO, people should actively remove content from Orbit that has CVEs. Much
> like with any other project. Even without replacing it with a fixed
> version. We will be better with less but trusted content than questioning
> ourselves for each artifact.
>
>
> Agreed. There is usually a clean-up/removal of unneeded stuff. But the
> downloads are still available for projects consuming the repositories.
>
> >[...] That is definitely something
>> > new, since Orbit was a trusted source of 3rd party libraries for many
>> > years.
>>
>
>
> That's a misconception. Orbit essentially is like Maven Central. Instead
> of Maven Artifacts it distributes Eclipse plug-in artifacts. Maven Central
> still distributes the vulnerable Log4j version and ton of other libraries
> with CVEs. Does that make it a less trustworthy source now? I don't think
> so. Consumers still need to stay on top of those.
>
> -Gunnar
>
>
> --
> Gunnar Wagenknecht
> gun...@wagenknecht.org, http://guw.io/
>
>
>
> ___
> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


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

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

ight choose to consume the log4j2 directly from
> >>>>> maven and simply sign the artifact to comply with simrel rules as
> >>>>> done here:
> >>>>>
> >>>>>
> https://github.com/eclipse-m2e/m2e-core/blob/master/org.eclipse.m2e.site/pom.xml#L45
> >>>>>
> >>>>>
> >>>>> This would bypass the
> >>>>> OrbitChange>OrbitRelease>PassageChange>PassageRelease>RepeatHere
> >>>>> cycle...
> >>>>>
> >>>>> Am 13.01.22 um 09:31 schrieb Alexander Fedorov:
> >>>>>> Hello,
> >>>>>>
> >>>>>> Some hours ago I've found that Orbit still contributes the log4j
> >>>>>> vulnerability to the SimRel
> >>>>>>
> >>>>>> Thanks to Jonah, the situation is better, now we have updated
> >>>>>> Orbit with log4j 2.15.0
> >>>>>>
> >>>>>> But shouldn't we hold a train a bit to use the latest fix from
> >>>>>> Orbit that provides log4j 2.17.1?
> >>>>>>
> >>>>>> Regards,
> >>>>>> AF
> >>>>>>
> >>>>>> 12/18/2021 4:19 PM, Andrey Loskutov пишет:
> >>>>>>> After update is before update...
> >>>>>>>
> >>>>>>> log4j has now 2.17.0.
> >>>>>>> https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105
> >>>>>>>
> >>>>>>>
> >>>>>>> Am 15. Dezember 2021 12:03:21 MEZ schrieb Alexander Fedorov
> >>>>>>> :
> >>>>>>>> Thank you, Andrey!
> >>>>>>>>
> >>>>>>>> Just merged
> >>>>>>>> https://git.eclipse.org/r/c/orbit/orbit-recipes/+/188862
> >>>>>>>> Will be working to provide Eclipse Passage 2.2.2 service release.
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>> AF
> >>>>>>>>
> >>>>>>>> 12/15/2021 1:38 PM, Andrey Loskutov пишет:
> >>>>>>>>> +1 from me.
> >>>>>>>>> The hype is too big.
> >>>>>>>>>
> >>>>>>>>> Re-posting your message to collect more feedback regarding:
> >>>>>>>>> should we replace 2.15.0 with 2.16.0 in Orbit?
> >>>>>>>>>
> >>>>>>>>> ___
> >>>>>>>>> cross-project-issues-dev mailing list
> >>>>>>>>> cross-project-issues-dev@eclipse.org
> >>>>>>>>> To unsubscribe from this list,
> >>>>>>>>> visithttps://
> www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> >>>>>>>>>
> >>>>>>> --
> >>>>>>> Kind regards,
> >>>>>>> Andrey Loskutov
> >>>>>>>
> >>>>>>> https://www.eclipse.org/user/aloskutov
> >>>>>>> Спасение утопающих - дело рук самих утопающих
> >>>>>>>
> >>>>>>
> >>>>>> ___
> >>>>>> cross-project-issues-dev mailing list
> >>>>>> cross-project-issues-dev@eclipse.org
> >>>>>> To unsubscribe from this list, visit
> >>>>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> >>>>> ___
> >>>>> cross-project-issues-dev mailing list
> >>>>> cross-project-issues-dev@eclipse.org
> >>>>> To unsubscribe from this list, visit
> >>>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> >>>> ___
> >>>> cross-project-issues-dev mailing list
> >>>> cross-project-issues-dev@eclipse.org
> >>>> To unsubscribe from this list, visit
> >>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> >>> ___
> >>> cross-project-issues-dev mailing list
> >>> cross-project-issues-dev@eclipse.org
> >>> To unsubscribe from this list, visit
> >>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> >> ___
> >> cross-project-issues-dev 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
>


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

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

On Thu, Jan 13, 2022 at 11:39 AM Ed Merks  wrote:

> Yes please!  Thanks!!
>
Done. Should be fixed by
https://git.eclipse.org/c/simrel/org.eclipse.simrel.build.git/commit/?id=35787e30f5eeafc972286e6fd78d92308bf8ea44
.


> On 13.01.2022 10:38, Aleksandar Kurtakov wrote:
>
> Here is official request from Linux Tools for a respin for this one.
> Should I feel free to commit to simrel when done?
>
> On Thu, Jan 13, 2022 at 11:36 AM Ed Merks  wrote:
>
>> FYI,
>>
>> If https://bugs.eclipse.org/bugs/show_bug.cgi?id=578192 is fixed quickly
>> (in the next few hours) I will respin for that which will pick up
>> anything else that is contributed/committed between now and then.
>>
>> Regards,
>> Ed
>>
>> On 13.01.2022 09:39, Ed Merks wrote:
>> > The deadline for contributions is Wednesday evening.  I can hold off
>> > promotion if someone asks me to do that ahead of time, but once I get
>> > up on Thursday morning, I will promote what's there at that time as I
>> > have done today...
>> >
>> > I can respin if necessary, but this issue is not one that cropped up
>> > today nor last night so...
>> >
>> > Regards,
>> > Ed
>> >
>> >
>> > On 13.01.2022 09:31, Alexander Fedorov wrote:
>> >> Hello,
>> >>
>> >> Some hours ago I've found that Orbit still contributes the log4j
>> >> vulnerability to the SimRel
>> >>
>> >> Thanks to Jonah, the situation is better, now we have updated Orbit
>> >> with log4j 2.15.0
>> >>
>> >> But shouldn't we hold a train a bit to use the latest fix from Orbit
>> >> that provides log4j 2.17.1?
>> >>
>> >> Regards,
>> >> AF
>> >>
>> >> 12/18/2021 4:19 PM, Andrey Loskutov пишет:
>> >>> After update is before update...
>> >>>
>> >>> log4j has now 2.17.0.
>> >>> https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105
>> >>>
>> >>>
>> >>> Am 15. Dezember 2021 12:03:21 MEZ schrieb Alexander Fedorov
>> >>> :
>> >>>> Thank you, Andrey!
>> >>>>
>> >>>> Just merged https://git.eclipse.org/r/c/orbit/orbit-recipes/+/188862
>> >>>> Will be working to provide Eclipse Passage 2.2.2 service release.
>> >>>>
>> >>>> Regards,
>> >>>> AF
>> >>>>
>> >>>> 12/15/2021 1:38 PM, Andrey Loskutov пишет:
>> >>>>> +1 from me.
>> >>>>> The hype is too big.
>> >>>>>
>> >>>>> Re-posting your message to collect more feedback regarding:
>> >>>>> should we replace 2.15.0 with 2.16.0 in Orbit?
>> >>>>>
>> >>>>> ___
>> >>>>> cross-project-issues-dev mailing list
>> >>>>> cross-project-issues-dev@eclipse.org
>> >>>>> To unsubscribe from this list,
>> >>>>> visithttps://
>> www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>> >>>>>
>> >>> --
>> >>> Kind regards,
>> >>> Andrey Loskutov
>> >>>
>> >>> https://www.eclipse.org/user/aloskutov
>> >>> Спасение утопающих - дело рук самих утопающих
>> >>>
>> >>
>> >> ___
>> >> cross-project-issues-dev mailing list
>> >> cross-project-issues-dev@eclipse.org
>> >> To unsubscribe from this list, visit
>> >> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
>
> ___
> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


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

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

Here is official request from Linux Tools for a respin for this one. Should
I feel free to commit to simrel when done?

On Thu, Jan 13, 2022 at 11:36 AM Ed Merks  wrote:

> FYI,
>
> If https://bugs.eclipse.org/bugs/show_bug.cgi?id=578192 is fixed quickly
> (in the next few hours) I will respin for that which will pick up
> anything else that is contributed/committed between now and then.
>
> Regards,
> Ed
>
> On 13.01.2022 09:39, Ed Merks wrote:
> > The deadline for contributions is Wednesday evening.  I can hold off
> > promotion if someone asks me to do that ahead of time, but once I get
> > up on Thursday morning, I will promote what's there at that time as I
> > have done today...
> >
> > I can respin if necessary, but this issue is not one that cropped up
> > today nor last night so...
> >
> > Regards,
> > Ed
> >
> >
> > On 13.01.2022 09:31, Alexander Fedorov wrote:
> >> Hello,
> >>
> >> Some hours ago I've found that Orbit still contributes the log4j
> >> vulnerability to the SimRel
> >>
> >> Thanks to Jonah, the situation is better, now we have updated Orbit
> >> with log4j 2.15.0
> >>
> >> But shouldn't we hold a train a bit to use the latest fix from Orbit
> >> that provides log4j 2.17.1?
> >>
> >> Regards,
> >> AF
> >>
> >> 12/18/2021 4:19 PM, Andrey Loskutov пишет:
> >>> After update is before update...
> >>>
> >>> log4j has now 2.17.0.
> >>> https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45105
> >>>
> >>>
> >>> Am 15. Dezember 2021 12:03:21 MEZ schrieb Alexander Fedorov
> >>> :
> >>>> Thank you, Andrey!
> >>>>
> >>>> Just merged https://git.eclipse.org/r/c/orbit/orbit-recipes/+/188862
> >>>> Will be working to provide Eclipse Passage 2.2.2 service release.
> >>>>
> >>>> Regards,
> >>>> AF
> >>>>
> >>>> 12/15/2021 1:38 PM, Andrey Loskutov пишет:
> >>>>> +1 from me.
> >>>>> The hype is too big.
> >>>>>
> >>>>> Re-posting your message to collect more feedback regarding:
> >>>>> should we replace 2.15.0 with 2.16.0 in Orbit?
> >>>>>
> >>>>> ___
> >>>>> cross-project-issues-dev mailing list
> >>>>> cross-project-issues-dev@eclipse.org
> >>>>> To unsubscribe from this list,
> >>>>> visithttps://
> www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> >>>>>
> >>> --
> >>> Kind regards,
> >>> Andrey Loskutov
> >>>
> >>> https://www.eclipse.org/user/aloskutov
> >>> Спасение утопающих - дело рук самих утопающих
> >>>
> >>
> >> ___
> >> cross-project-issues-dev mailing list
> >> cross-project-issues-dev@eclipse.org
> >> To unsubscribe from this list, visit
> >> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


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

[cross-project-issues-dev] HttpClient 5 update in p2

2021-12-14 Thread Aleksandar Kurtakov

Hey everyone,
Eclipse IDE switched the underlying httpclient library used to httpclient
5.x via [1] for 2022-03 release. This has been long standing issue [2]
which hurt us in 2021-12 release [3]. This allows us to ship with single
version of JNA instead of both 4.x and 5.x with all consequences from that
(visible in [3] one more time).
Please test thoroughly various updates especially if you're using proxies
and even more carefully if you use Windows specific proxies as these are
the usual suspects for problems.


[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=577769
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=576256
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=577647

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

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

On Fri, Nov 19, 2021 at 11:46 AM Christian Dietrich <
christian.dietr...@itemis.de> wrote:

> i would like to see better support to maintain e.g. composite updates
> sites for that.
> but with 2 releases i think this is the death to composite updates sites
> for
> multiples releases in general as there is not much to find.
>
I don't see the relationship here. One can have a composite site with as
many versions as they want on downloads pointing to 2 versions from
downloads and rest from archive and even have that transparent thanks to
redirects (aka no change in the composite site when archiving). The
discussion here is what is on downloads (aka mirrored).


>
> Am 19.11.21 um 10:43 schrieb Aleksandar Kurtakov:
>
>
>
> On Fri, Nov 19, 2021 at 11:37 AM Aleksandar Kurtakov 
> wrote:
>
>>
>>
>> On Thu, Nov 18, 2021 at 7:43 PM Frederic Gurr <
>> 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 next week. So only the last 8 releases will stay on
>>> download.eclipse.org. I will add the task to move old releases to
>>> 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.
>>
>
> IMHO, such a check should be part of release or progress reviews and
> actions required from projects. Having smth happening regularly, being well
> defined and actionable is what we should aim for rather than the current
> "exclude" lists and generally costing time to people involved in many
> projects to just go and check if any of the dozens projects involved in is
> guilty.
>
>
>>
>>
>>>
>>> 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
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>>
>>
>> --
>> Aleksandar Kurtakov
>> Red Hat Eclipse Team
>>
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
>
> ___
> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
> Vorstand/Board: Jens Wagener (Vors./chairman), Dr. Stephan Eberle,
> Abdelghani El-Kacimi, Wolfgang Neuhaus, Franz-Josef Schuermann
> Aufsichtsrat/Supervisory Board: Michael Neuhaus (Vors./chairman), Harald
> Goertz, Eric Swehla
> Sitz der Gesellschaft/Registered Office: Am Brambusch 15-24, 44536 Lünen
> (Germany)
> Registergericht/Registry Court: Amtsgericht Dortmund | HRB 20621
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


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

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

Yet another huge part of mirror content is EPP project
https://download.eclipse.org/oomph/archive/download.eclipse/technology/epp/packages/index.html
. This one is due for some pruning too similar to simrel.

On Fri, Nov 19, 2021 at 11:43 AM Aleksandar Kurtakov 
wrote:

>
>
> On Fri, Nov 19, 2021 at 11:37 AM Aleksandar Kurtakov 
> wrote:
>
>>
>>
>> On Thu, Nov 18, 2021 at 7:43 PM Frederic Gurr <
>> 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 next week. So only the last 8 releases will stay on
>>> download.eclipse.org. I will add the task to move old releases to
>>> 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.
>>
>
> IMHO, such a check should be part of release or progress reviews and
> actions required from projects. Having smth happening regularly, being well
> defined and actionable is what we should aim for rather than the current
> "exclude" lists and generally costing time to people involved in many
> projects to just go and check if any of the dozens projects involved in is
> guilty.
>
>
>>
>>
>>>
>>> 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
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>>
>>
>> --
>> Aleksandar Kurtakov
>> Red Hat Eclipse Team
>>
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
>


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

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

On Fri, Nov 19, 2021 at 11:37 AM Aleksandar Kurtakov 
wrote:

>
>
> On Thu, Nov 18, 2021 at 7:43 PM Frederic Gurr <
> 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 next week. So only the last 8 releases will stay on
>> download.eclipse.org. I will add the task to move old releases to
>> 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.
>

IMHO, such a check should be part of release or progress reviews and
actions required from projects. Having smth happening regularly, being well
defined and actionable is what we should aim for rather than the current
"exclude" lists and generally costing time to people involved in many
projects to just go and check if any of the dozens projects involved in is
guilty.


>
>
>>
>> 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
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
>


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

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

On Thu, Nov 18, 2021 at 7:43 PM Frederic Gurr <
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 next week. So only the last 8 releases will stay on
> download.eclipse.org. I will add the task to move old releases to
> 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
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


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

[cross-project-issues-dev] Removal of "Classic Search" from Eclipse IDE

2021-10-04 Thread Aleksandar Kurtakov

Hey everyone,
"Classic Search" aka Old Search has been deprecated since Eclipse 3.0 and
provided nothing else but "migration" strategy to open a dialog for old
implementations to allow firing the "new" search from the old view.
The view will be gone [1] together with the internal classes [2] in 4.22
release. Existing deprecated API will be marked for removal and follow the
standard deprecation and removal procedure (although it's non functional
for years!).

[1] https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/186120
[2] https://git.eclipse.org/r/c/platform/eclipse.platform.text/+/186121

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

[cross-project-issues-dev] CVS support plugin discontinuation

2021-09-17 Thread Aleksandar Kurtakov

Hey everyone,
CVS is dead technology but we still lose precious releng time in making
sure versions are changed so it's updated clean from previous release,
useless bits are still built on every patch review, tests are not run and
so on. All that for nothing as we don't know whether there is any user left
and whether the plugin is even still functional.

With all that said, Eclipse TLP PMC is planning to have 4.22/2021-12
release be the last one containing CVS support . It's a standalone feature
not included in Eclipse SDK  nor in any EPP (AFAIK) thus it shouldn't
affect many people (if anyone!). Being standalone, building it separately
should be easy in case anyone is willing to preserve it.
If you're still using CVS and depend on this plugin availability please
raise your voice now and contact us on platform-...@eclipse.org to plan and
organize the split of CVS feature and you taking over release duties for it.
-- 
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

Re: [cross-project-issues-dev] SimRel: retention time for milestone and release candidate repos

2021-08-26 Thread Aleksandar Kurtakov

On Thu, Aug 26, 2021 at 3:49 PM Frederic Gurr <
frederic.g...@eclipse-foundation.org> wrote:

> Hi,
>
> Are there any good reasons to keep milestone repos, release candidate
> repos and repos that were replaced with a respin around for an extended
> time (or forever)?
>
> @Jonah: A similar question could be asked for the retention time of EPP
> milestone and release candidates _repos_.
>
> This should not concern the EPP artifacts for milestones and release
> candidates on the download website. I think there are good reasons to
> keep the EPP packages around.
>
> E.g. the 2018-09 SimRel release contains seven p2 repos (M1, M2, M3,
> RC1, RC2, and two respins). Only the final release (the last respin) is
> relevant AFAICT. This would save 10-15GB disk space per release
> depending on the number of respins.
>
> I'd propose that all repos of a release (e.g. 2021-06) are kept until
> the next final release (e.g. 2021-09) has dropped. Everything except the
> final release repo (of 2021-06) will then be removed. This would set the
> retention time to roughly three months.
>
> WDYT?
>

+1. Keeping M* and RC* builds is pointless past GA.


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

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

2021-07-23 Thread Aleksandar Kurtakov

Looks like issue is back - https://ci.eclipse.org/equinox/ is not launching
new containers.

On Thu, Jul 22, 2021 at 12:58 PM Ondrej Dockal  wrote:

> Thanks for the update,
>
> I tried and everything is working fine, now.
>
> thanks
>
> On Thu, Jul 22, 2021 at 9:09 AM Mikael Barbero via
> cross-project-issues-dev  wrote:
>
>> I've created https://www.eclipsestatus.io/incidents/yd3qyk7g0xj3 with
>> the reported issues. We will provide update. over there (and on tweeter
>> @Eclipse_Status <https://twitter.com/Eclipse_Status>)
>>
>> Thanks for your patience.
>>
>> *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 22 Jul 2021, at 08:58, Ed Merks  wrote:
>>
>> I think it's hit or miss because it works for this:
>>
>> https://ci.eclipse.org/oomph/
>>
>> But for these I get an error:
>>
>> https://ci.eclipse.org/justj/loginError
>> https://ci.eclipse.org/emf/loginError
>>
>> And this "staging" instance doesn't seem to be able to launch any jobs:
>>
>> https://ci-staging.eclipse.org/oomph/
>>
>> So I think something is wrong.
>>
>> I also saw that https://bugs.eclipse.org/bugs/show_bug.cgi?id=573903 got
>> reopened so maybe there's a more general problem with credentials and
>> accounts...
>>
>> Regards,
>> Ed
>> On 22.07.2021 08: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 Jenkins instance. Just simply throwing "Invalid
>> username or password".
>>
>> Is it something global?
>>
>> Thanks.
>>
>> Ondrej Dockal
>> RedDeer project lead
>>
>> ___
>> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
>> To unsubscribe from this list, visit 
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>>
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


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

Re: [cross-project-issues-dev] Do we need a MAX BREE? max java version?

2021-07-05 Thread Aleksandar Kurtakov

BREE is deprecated by OSGi although Eclipse doesn't show warnings about
this deprecation. If you use osgi.ee [1] capability one can easily define
min and max versions. Equinox/p2/tycho should work fine without BREE and
with osgi.ee capability used. Not sure whether all PDE features will grok
it though.

[1]
https://docs.osgi.org/specification/osgi.core/7.0.0/framework.namespaces.html#framework.namespaces.osgi.ee

On Mon, Jul 5, 2021 at 4:39 PM Jörg Kubitz  wrote:

>
> Java was planed to be backward compatible.
> But with removed APIs in newer JDKs it is not anymore.
> "Bundle-RequiredExecutionEnvironment: JavaSE-1.8"
> is not a guarantee it will still run on later java JDK versions. But we
> treat it as that.
> API removals will go on.
>
> What do you think?
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>

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

[cross-project-issues-dev] SWT and Java 11

2021-07-01 Thread Aleksandar Kurtakov

Hey everyone,
With most things in Eclipse Platform and JDT requiring Java 11 now I wonder
how moving SWT to require Java 11 would be received?
Seeing that Java 17 works on long overdue FFI enhancements (
https://openjdk.java.net/jeps/412) moving to Java 11 so we don't urge the
move to 17 at once sounds like pretty good idea to me.
P.S. Poll available at
https://twitter.com/akurtakov/status/1410577466016649223

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

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

2021-06-16 Thread Aleksandar Kurtakov

me to do that.
>
> [1]
> https://www.eclipse.org/projects/project-plan.php?planurl=http://www.eclipse.org/eclipse/development/plans/eclipse_project_plan_4_21.xml
> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=572389
>
> 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
>


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

Re: [cross-project-issues-dev] Mylyn

2021-05-23 Thread Aleksandar Kurtakov

On Sun, May 23, 2021 at 7:47 AM Jonah Graham  wrote:

> Hi folks,
>
> I am not sure, but I think there are numerous projects that depend on
> Notifications framework from Mylyn. For example LSP4E does:
>
>
> https://git.eclipse.org/r/plugins/gitiles/lsp4e/lsp4e/+/refs/heads/master/org.eclipse.lsp4e/src/org/eclipse/lsp4e/ServerMessageHandler.java
>

> Not sure what the best path forward for that is, for example how easy
> would it be to pull out of Mylyn.
>

JFace provides notification for some time and migration should be quite
straightforward see
https://wiki.eclipse.org/JFaceSnippets#Snippet081_-_Notication_API


>
> Over the last few years BIRT went temporarily into this same situation (It
> is coming back now!
> https://twitter.com/BirtEclipse/status/1367319082987622400) - so in
> SimRel this was handled by the projects that needed parts of BIRT having to
> contribute those parts themself (e.g. the MAT project does that
> https://git.eclipse.org/r/plugins/gitiles/simrel/org.eclipse.simrel.build/+/refs/heads/master/mat.aggrcon#4).
> I hope that BIRT comes back soon to SimRel as the reboot progresses.
> Likewise I hope that Mylyn can also have such a resurgence.
>
> Thanks
> Jonah
>
>
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
>
> On Fri, 21 May 2021 at 16:14, Sam Davis  wrote:
>
>> From: Mik Kersten 
>> Date: Fri, May 21, 2021 at 10:34 AM
>> Subject: Mylyn
>> To: 
>> Cc: Sam Davis 
>>
>>
>> I wanted to give the group a heads up that there are issues with Mylyn
>> that could affect the simultaneous release.
>>
>> For context, Mylyn (originally Mylar) was a passion and PhD project of
>> mine that has been a part of the Eclipse ecosystem for 15 years now.  It
>> has lived a good and full product lifecycle, and for the past few years,
>> neither I nor the other staff at Tasktop who have been contributing once my
>> role transitioned have been able to put enough time into to provide
>> adequate support for inclusion in the simultaneous release.  Back in
>> December, Sam Davis pushed a review to pull Mylyn out of the Simultaneous
>> release, but that did not happen due to dependencies, and there wasn’t
>> follow up on the corresponding communication so it has not yet happened.
>>
>> Where we stand today is that due to the JIPP migration, Mylyn cannot
>> release. This puts the SimRel at risk of being blocked. Given that the
>> Mylyn project lacks the resources to address this, so we would like to
>> remove Mylyn from the SimRel. This will require other projects, EPP
>> packages, and Oomph to remove their dependencies on Mylyn unless there are
>> other parties who could contribute the resources to make this happen.
>>
>> If anyone is interested in taking this on, Sam and I would be more than
>> happy to pass on the reins!
>>
>> Assuming that does not happen, we think that it would be in everyone's
>> interest to deal with this now, before it becomes urgent. Please reply to
>> this thread if your project depends on Mylyn. This includes Mylyn
>> Tasks/Context/Commons/Builds/Reviews/Versions, but not Mylyn Docs/Wikitext.
>>
>> And on a more personal note, I have very fond memories of being a close
>> part of the Eclipse ecosystem.  It is great to see it continuing, I miss
>> interacting the many people who were collaborators over the years, and hope
>> everyone is doing well and that we cross paths at some conference or other
>> in 2022!
>>
>> Best,
>>
>> Mik
>>
>> --
>> Dr. Mik Kersten
>> CEO https://tasktop.com
>> Author https://projecttoproduct.org
>>
>>
>>
>>
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


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

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

On Tue, Apr 13, 2021 at 7:13 PM Matthias Sohn 
wrote:

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

https://ci.eclipse.org/jetty/job/jetty-rt-bundles-9/ is the job. It
rebuilds the sources so there is no guarantee that it matches the actual
Jetty release. In order to be done proper it would have to be done like the
jetty 10 so actual jetty build artifacts are used and to prevent breakages
like it can be seen with the multiple Non 27 builds to wrap up very minimal
change exposed by this needless rebuild.
Note that the job deployment part is broken due to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=570630 and will need fixing
too.


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


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

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

On Tue, Apr 13, 2021 at 6:24 PM Nitin Dahyabhai 
wrote:

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


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


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

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

On Tue, Apr 13, 2021 at 10:17 AM Gunnar Wagenknecht 
wrote:

> Are we inventing another way to avoid adding it to Orbit?
>

To me Orbit has a strong connection with third-party (aka CQs/IP team
involved and etc.) . Also the way the Jetty repo is generated ensures that
the OSGi metadata is not touched even a character compared to what Jetty
team has deployed to Maven central. That ensures better communication with
both upstream (Jetty devs) and downstreams (Fedora devs)  as we are not
intervening in the middle.


>
> Mind everyone that Orbit is not about using/enforcing a specific
> technology. Whatever produces a p2 repo with signed content would work.
>
> -Gunnar
>
> --
> Gunnar Wagenknecht
> gun...@wagenknecht.org, http://guw.io/
>
>
> > On Apr 13, 2021, at 09:02, Christoph Läubrich 
> wrote:
> >
> > I think Alexander might give some insight if there are other
> alternatives, but if you are using recent tycho + recent eclipse you can
> simply copy the "locations" from this file:
> >
> >
> https://git.eclipse.org/r/c/platform/eclipse.platform.releng.buildtools/+/176736/17/jetty.repository/jetty.target
> >
> > into your target and have the jetty ones available.
> >
> > Mickael also has written a tool to create a P2 site that mirrors Maven
> deps, so if such a thing is available it is just a matter of uploading it
> to some web-server or reference it via file:/... somewhere.
> >
> >
> > Am 13.04.21 um 08:56 schrieb Ed Merks:
> >> Markus,
> >> Apparently this is not trivial.  It looks like for
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=569804 the following was
> added during the move to 10.x:
> >>
> https://git.eclipse.org/r/c/platform/eclipse.platform.releng.buildtools/+/176736
> >> That provides a new project:
> >>
> https://git.eclipse.org/c/platform/eclipse.platform.releng.buildtools.git/tree/jetty.repository
> >> Apparently that helps provide the Jetty dependencies.  It seems to me
> infeasible though for all the downstream projects that also depend on Jetty
> to replicate all this infrastructure.  Surely there should just be a Jetty
> 10.x p2 repository we can all reuse...
> >> On a related note, I've tried to get the attention of someone human
> being on https://bugs.eclipse.org/bugs/show_bug.cgi?id=572026 also
> because of a Jetty problem, but it seems no human being cares to respond.
> >> Regards,
> >> Ed
> >> On 13.04.2021 08:31, Markus Knauer wrote:
> >>> I started yesterday to look into this, unfortunately it'll take some
> time...
> >>>
> >>> We used to consume Jetty from their 9.x p2 repositories, but with 10.x
> this is not possible any more.
> >>>
> >>> Eclipse Platform Team, how are you consuming the Jetty bundles now?
> >>> That'll help us solve it on our side in the same way.
> >>>
> >>> Thanks
> >>> Markus
> >>>
> >>> On Fri, 9 Apr 2021 at 18:14, Kit Lo  ki...@us.ibm.com>> wrote:
> >>>
> >>>During Eclipse Platform 4.20 M1 contribution, we noticed conflicts
> >>>with RAP Tools and new version of Jetty.
> >>>
> >>>Requesting RAP Tools development team to take a look and re-enable
> >>>RAP Tools contribution when the problem is resolved.
> >>>
> >>>Regards,
> >>>Kit Lo
> >>>Eclipse Babel Project Lead
> >>>IBM Eclipse SDK (IES) Technical Lead and Release Manager
> >>>
> >>>
> >>>
> >>> ___
> >>> cross-project-issues-dev mailing list
> >>> cross-project-issues-dev@eclipse.org
> >>> To unsubscribe from this list, visithttps://
> www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> >> ___
> >> cross-project-issues-dev mailing list
> >> cross-project-issues-dev@eclipse.org
> >> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> > ___
> > cross-project-issues-dev mailing list
> > cross-project-issues-dev@eclipse.org
> > To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


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

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

On Tue, Apr 13, 2021 at 9:56 AM Ed Merks  wrote:

> Markus,
>
> Apparently this is not trivial.  It looks like for
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=569804 the following was
> added during the move to 10.x:
>
>
> https://git.eclipse.org/r/c/platform/eclipse.platform.releng.buildtools/+/176736
>
> That provides a new project:
>
>
> https://git.eclipse.org/c/platform/eclipse.platform.releng.buildtools.git/tree/jetty.repository
>
> Apparently that helps provide the Jetty dependencies.  It seems to me
> infeasible though for all the downstream projects that also depend on Jetty
> to replicate all this infrastructure.  Surely there should just be a Jetty
> 10.x p2 repository we can all reuse...
>
I gave up on such hopes thus my hopes are into relying more on Maven and
less on p2. Reasons are simple - everyone cares for maven reusable
artifacts and p2 means more work for me (always!). So to me maven is like
git - it won the battle so it's a matter of time before we adapt or shrink
even more.


> On a related note, I've tried to get the attention of someone human being
> on https://bugs.eclipse.org/bugs/show_bug.cgi?id=572026 also because of a
> Jetty problem, but it seems no human being cares to respond.
>
This is dead project for me
https://git.eclipse.org/r/c/usssdk/org.eclipse.usssdk/+/174896 - I had smth
to look at and started with the obvious first thing . At the point I was
looking at my queue and don't remembered anymore what I needed it for
simply abandon and put it in the list of things to simply ignore and remove
from my stack.
IMHO usssdk should be merged with MPC so at least some of the proliferation
is removed.


> Regards,
> Ed
>
> On 13.04.2021 08:31, Markus Knauer wrote:
>
> I started yesterday to look into this, unfortunately it'll take some
> time...
>
> We used to consume Jetty from their 9.x p2 repositories, but with 10.x
> this is not possible any more.
>
> Eclipse Platform Team, how are you consuming the Jetty bundles now?
> That'll help us solve it on our side in the same way.
>
> Thanks
> Markus
>
> On Fri, 9 Apr 2021 at 18:14, Kit Lo  wrote:
>
>> During Eclipse Platform 4.20 M1 contribution, we noticed conflicts with
>> RAP Tools and new version of Jetty.
>>
>> Requesting RAP Tools development team to take a look and re-enable RAP
>> Tools contribution when the problem is resolved.
>>
>> Regards,
>> Kit Lo
>> Eclipse Babel Project Lead
>> IBM Eclipse SDK (IES) Technical Lead and Release Manager
>>
>
>
> ___
> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> _______
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


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

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

On Tue, Apr 13, 2021 at 9:32 AM Markus Knauer 
wrote:

> I started yesterday to look into this, unfortunately it'll take some
> time...
>
> We used to consume Jetty from their 9.x p2 repositories, but with 10.x
> this is not possible any more.
>
> Eclipse Platform Team, how are you consuming the Jetty bundles now?
>

A repo containing only what's needed by Platform is fetched from maven
central, signed and deployed for our usage.
Releng sources:
https://git.eclipse.org/c/platform/eclipse.platform.releng.buildtools.git/tree/jetty.repository/
P2 URL: https://download.eclipse.org/eclipse/jetty/10.0.1/


> That'll help us solve it on our side in the same way.
>
> Thanks
> Markus
>
> On Fri, 9 Apr 2021 at 18:14, Kit Lo  wrote:
>
>> During Eclipse Platform 4.20 M1 contribution, we noticed conflicts with
>> RAP Tools and new version of Jetty.
>>
>> Requesting RAP Tools development team to take a look and re-enable RAP
>> Tools contribution when the problem is resolved.
>>
>> Regards,
>> Kit Lo
>> Eclipse Babel Project Lead
>> IBM Eclipse SDK (IES) Technical Lead and Release Manager
>>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, 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

Re: [cross-project-issues-dev] [epp-dev] Xtext Leaving Eclipse Simrel with 2021-06

2021-03-26 Thread Aleksandar Kurtakov

On Fri, Mar 26, 2021 at 11:25 AM Aleksandar Kurtakov 
wrote:

>
>
> On Fri, Mar 26, 2021 at 11:00 AM Ed Willink  wrote:
>
>> 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.
>>
> Exactly, thanks again for proving my point - Java 9 imposed one set of
> changes, Java 11 additional, Java 14 additional, Java 16 additional and
> even more expected with Java 17. With literally 3 people looking at Tycho
> issues with priority being after Eclipse Platform, WildWebDeveloper, M2E,
> Corrosion, Linux Tools and so on and on it's an achievement that Tycho is
> working on so big a number of environments/jvms.
> I want to be perfectly clear about expectations if Tycho is left with
> current manpower - latest Java and latest LTS Java. I know this has
> implications on everyone but my time is as scarce as everyone else's and
> just like everyone else I have to do what I'm paid for - release Eclipse
> platform that supports latest Java and latest LTS Java. And tycho is just a
> means to achieve that!
> I would very much welcome others joining on daily tasks so we share the
> burden and wider compatibility is preserved. I'm willing to transfer
> whatever extra power one thinks I have on any such decision and let that
> person show us (and teach me!) how to achieve better results in current
> circumstances!
>

I forgot to add that transfer of power goes hand in hand with transfer of
duties.


>
> 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>
>> <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://githu

Re: [cross-project-issues-dev] [epp-dev] Xtext Leaving Eclipse Simrel with 2021-06

2021-03-26 Thread Aleksandar Kurtakov

egistergericht/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 listcross-project-issues-...@eclipse.org
> To unsubscribe from this list, visit 
> https://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 listepp-...@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/epp-dev
>
>
>
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
>  Virus-free.
> www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=emailclient>
> <#m_7428541893459966454_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> epp-dev mailing list
> epp-...@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/epp-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

Re: [cross-project-issues-dev] Xtext Leaving Eclipse Simrel with 2021-06

2021-03-26 Thread Aleksandar Kurtakov

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


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

Re: [cross-project-issues-dev] Upcoming pack200 changes on Eclipse Platform side

2021-03-25 Thread Aleksandar Kurtakov

Example change from ShellWax to not bother with pack200 for those using
Tycho can be seen at
https://github.com/eclipse/shellwax/commit/b8b9f072493533ac385d373d5cc97e706b5f1e56

On Thu, Mar 25, 2021 at 12:18 PM Aleksandar Kurtakov 
wrote:

> Hey everyone,
> Due to pack200 being no-op since Eclipse 4.16 when run on Java 14+ (as the
> JVM removed the needed underlying tools) Eclipse TLP is planning the
> following changes:
> * 2021-09 release - no pack200 artifacts being generated and published
> * 2022-06 release - p2 APIs will ignore everything pack200 and not deal
> with pack200 at all
> * 2023-06 release - p2 pack200 specific APIs will be entirely removed
>
> It's documented in the recommendations [1] and removals[2] documentation
> for upcoming 2021-06 release.
> We strongly advise projects to stop generating and publishing pack.gz
> files even for the 2021-06 release.
>
> [1]
> https://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=9af465b47297dcb0d9ab62faa06feb675b1d45d9
> [2]
> https://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=a4627c2be04b5d0ce3951ee1fece6c316e84ddbd
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
>


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

[cross-project-issues-dev] Upcoming pack200 changes on Eclipse Platform side

2021-03-25 Thread Aleksandar Kurtakov

Hey everyone,
Due to pack200 being no-op since Eclipse 4.16 when run on Java 14+ (as the
JVM removed the needed underlying tools) Eclipse TLP is planning the
following changes:
* 2021-09 release - no pack200 artifacts being generated and published
* 2022-06 release - p2 APIs will ignore everything pack200 and not deal
with pack200 at all
* 2023-06 release - p2 pack200 specific APIs will be entirely removed

It's documented in the recommendations [1] and removals[2] documentation
for upcoming 2021-06 release.
We strongly advise projects to stop generating and publishing pack.gz files
even for the 2021-06 release.

[1]
https://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=9af465b47297dcb0d9ab62faa06feb675b1d45d9
[2]
https://git.eclipse.org/c/platform/eclipse.platform.common.git/commit/?id=a4627c2be04b5d0ce3951ee1fece6c316e84ddbd

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

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

2021-02-08 Thread Aleksandar Kurtakov

I've used another email not subscribed to this list so forwarding it.

-- Forwarded message -
From: Александър Куртаков 
Date: Mon, Feb 8, 2021 at 10:40 AM
Subject: Re: [eclipse-dev] Is anyone still using Copyright tool?
To: General development mailing list of the Eclipse project. <
eclipse-...@eclipse.org>
Cc: issues, Cross 


Let's move any discussion to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=571007 actually to not spam
everyone.

On Mon, Feb 8, 2021 at 10:38 AM Aleksandar Kurtakov 
wrote:

> So far single user. We are about to proceed with removal. It can still be
> installed from old Eclipse releases p2 sites.
> Ed, let me know if you have alternative proposal how to progress on the
> other topics or if you want to move the code to one of your repos and need
> few days for it.
>
> On Fri, Feb 5, 2021 at 6:59 PM Aleksandar Kurtakov 
> wrote:
>
>> Question is about [1] being still used by anyone. I haven't seen anyone
>> using it/running it on git repos like it has been in the past. Changing
>> copyright year in every file is not mandatory for Eclipse TLP since 2016
>> [2] and has never been mandatory for other projects AFAIK.
>> What I look for is removing this part of Eclipse Releng plugin to gain
>> the following benefits:
>> 1. Drop dependency on EGit in Eclipse Platform and thus circular build
>> dependency.
>> 2. Point 1 will allow to to build Eclipse Platform p2 repo in a way that
>> includes all transitive dependencies [3]
>> 3. Point 2 will allow to switch third-party dependencies to require
>> rather than include and thus support version ranges.
>> 4. Point 3 will allow updates of third party dependencies for security
>> reasons to be far simpler as currently it's a terrible experience [4]
>> 5. Point 3 will simplify updates of third party dependencies in Eclipse
>> Platform releng as touching features should be far less frequent event just
>> cause exact version is hardcoded in includes.  e.g. [5]
>>
>> The potential benefit is quite big so please come up with proposals
>> how/what to do and still improve our procedures.
>>
>> [1]
>> https://wiki.eclipse.org/Development_Resources/How_to_Use_Eclipse_Copyright_Tool
>> [2] https://wiki.eclipse.org/Eclipse/PMC/Minutes_2016
>> [3]
>> https://www.eclipse.org/tycho/sitedocs/tycho-p2/tycho-p2-repository-plugin/assemble-repository-mojo.html#includeAllDependencies
>> [4] https://www.eclipse.org/lists/tycho-user/msg08879.html
>> [5]
>> https://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=58e5c221bfc493e40d499f58c93a17cc14d061ac
>>
>> --
>> Alexander Kurtakov
>> Red Hat Eclipse Team
>>
>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
> ___
> eclipse-dev mailing list
> eclipse-...@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/eclipse-dev
>
___
eclipse-dev mailing list
eclipse-...@eclipse.org
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse-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

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

2021-02-08 Thread Aleksandar Kurtakov

So far single user. We are about to proceed with removal. It can still be
installed from old Eclipse releases p2 sites.
Ed, let me know if you have alternative proposal how to progress on the
other topics or if you want to move the code to one of your repos and need
few days for it.

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

> Question is about [1] being still used by anyone. I haven't seen anyone
> using it/running it on git repos like it has been in the past. Changing
> copyright year in every file is not mandatory for Eclipse TLP since 2016
> [2] and has never been mandatory for other projects AFAIK.
> What I look for is removing this part of Eclipse Releng plugin to gain the
> following benefits:
> 1. Drop dependency on EGit in Eclipse Platform and thus circular build
> dependency.
> 2. Point 1 will allow to to build Eclipse Platform p2 repo in a way that
> includes all transitive dependencies [3]
> 3. Point 2 will allow to switch third-party dependencies to require rather
> than include and thus support version ranges.
> 4. Point 3 will allow updates of third party dependencies for security
> reasons to be far simpler as currently it's a terrible experience [4]
> 5. Point 3 will simplify updates of third party dependencies in Eclipse
> Platform releng as touching features should be far less frequent event just
> cause exact version is hardcoded in includes.  e.g. [5]
>
> The potential benefit is quite big so please come up with proposals
> how/what to do and still improve our procedures.
>
> [1]
> https://wiki.eclipse.org/Development_Resources/How_to_Use_Eclipse_Copyright_Tool
> [2] https://wiki.eclipse.org/Eclipse/PMC/Minutes_2016
> [3]
> https://www.eclipse.org/tycho/sitedocs/tycho-p2/tycho-p2-repository-plugin/assemble-repository-mojo.html#includeAllDependencies
> [4] https://www.eclipse.org/lists/tycho-user/msg08879.html
> [5]
> https://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=58e5c221bfc493e40d499f58c93a17cc14d061ac
>
> --
> Alexander Kurtakov
> Red Hat Eclipse Team
>


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

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

2021-02-05 Thread Aleksandar Kurtakov

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.
What I look for is removing this part of Eclipse Releng plugin to gain the
following benefits:
1. Drop dependency on EGit in Eclipse Platform and thus circular build
dependency.
2. Point 1 will allow to to build Eclipse Platform p2 repo in a way that
includes all transitive dependencies [3]
3. Point 2 will allow to switch third-party dependencies to require rather
than include and thus support version ranges.
4. Point 3 will allow updates of third party dependencies for security
reasons to be far simpler as currently it's a terrible experience [4]
5. Point 3 will simplify updates of third party dependencies in Eclipse
Platform releng as touching features should be far less frequent event just
cause exact version is hardcoded in includes. e.g. [5]

The potential benefit is quite big so please come up with proposals
how/what to do and still improve our procedures.

[1]
https://wiki.eclipse.org/Development_Resources/How_to_Use_Eclipse_Copyright_Tool
[2] https://wiki.eclipse.org/Eclipse/PMC/Minutes_2016
[3]
https://www.eclipse.org/tycho/sitedocs/tycho-p2/tycho-p2-repository-plugin/assemble-repository-mojo.html#includeAllDependencies
[4] https://www.eclipse.org/lists/tycho-user/msg08879.html
[5]
https://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=58e5c221bfc493e40d499f58c93a17cc14d061ac

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

Re: [cross-project-issues-dev] Simultaneous Release participation and the Eclipse IDE packages

2021-01-22 Thread Aleksandar Kurtakov

On Fri, Jan 22, 2021 at 5:23 PM Wayne Beaton <
wayne.bea...@eclipse-foundation.org> wrote:

> As the recent SolarWinds hack has reminded us, security is everyone's
> concern. We owe it to the millions of developers and adopters who use our
> technologies to take all reasonable steps to ensure the validity of the
> software that we distribute.
>
> Responsibility to decide which Eclipse IDE packages are distributed as
> official "Eclipse IDE" releases (e.g., the packages listed on the Eclipse
> IDE packages download page  or
> are installable via the installer) rests with the Eclipse Foundation. That
> is, the Eclipse Foundation has (and has always had) responsibility to
> ensure that the content being distributed as official "Eclipse IDE"
> releases meets a well-defined standard.
>
> The standard is set by the participation rules of the simultaneous release
> and following the practices established for the simultaneous release, are
> in our opinion, the best means of mitigating risk.
>
> In order for a package to be listed as an official "Eclipse IDE" release,
> displayed on "package" download pages and included in the installer, these
> rules must be followed:
>
> *All features to the package must come through the simultaneous release. *That
> is, all Eclipse open source projects contributing features to projects must
> participate in the simultaneous release and follow the participation rules
> defined and maintained by the Eclipse Planning Council. By way of
> clarification, content produced by other Eclipse open source projects may
> be included, but only when that content is sponsored into the simultaneous
> release by a project that is itself participating in the process (Eclipse
> Jetty is an example of this).
>
> *All bundles must be signed using the EF's certificate. *Obvious
> exceptions will be made in cases where signing is impossible.
>

> We will be applying this standard to the next release and for every
> release thereafter.
>
> The means by which the simultaneous release participation rules are
> changed is to engage with the Eclipse Planning Council via your Eclipse
> Planning Council representative.
>

So if I understand correctly everything from above can be changed via the
Planning Council. I'm especially interested in the signing as it's becoming
harder and harder to keep up with external ecosystem due to way faster pace
and being able to use different means of signing as discussed at
https://www.eclipse.org/lists/p2-dev/msg05910.html becomes critical. But
let's keep this discussion for the next Planning Council meeting.


>
> Please let me know if you have any questions or concerns.
>
> Wayne
> --
>
> Wayne Beaton
>
> Director of Open Source Projects | Eclipse Foundation
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


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

Re: [cross-project-issues-dev] SimRel JIPP migration to new infrastructure is now complete

2021-01-14 Thread Aleksandar Kurtakov

On Fri, Jan 15, 2021 at 8:14 AM Ed Merks  wrote:

> Fred,
>
> Yes, people don't look at reports.  That's why no one noticed that bad
> licenses and unsigned content are present for 2021-03 M1; they've been
> present in staging for a while:
>
>
> https://download.eclipse.org/oomph/archive/reports/download.eclipse.org/staging/2021-03/index.html
>

In my experience with the same topic but in Platform releng the only way to
make issues not be introduced is make them break the build whenever
possible, everything else pretty much left keeping the state on the few
people that generate and look at the report.


>
> Note that I've opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=570380
> because https://git.eclipse.org/c is completely unreliable these days,
> which is why the above report has a bunch of error icons due to of random
> failures loading the icons during generation.
>
> This "gitc" problem also makes reporting on SimRel broken:
>
>   https://ci.eclipse.org/oomph/job/simrel-analyzer/
>
> And it makes it next to impossible for me to generate the product catalog
> for M1.
>
> Broken processes are frustrating and unreliable infrastructure is both
> annoying and time consuming.
> Regards,
> Ed
>
> On 14.01.2021 15:38, Frederic Gurr wrote:
>
> Hi,
>
> As you might know, the SimRel JIPP has been migrated to our new
> cluster-based infrastructure 
> (seehttps://bugs.eclipse.org/bugs/show_bug.cgi?id=568118).
>
> This has some implications on the SimRel aggregation build:
> On the old infra, the SimRel JIPP could utilize up to 16 CPUs of the
> host machine (hipp8) and had file system access (via NFS mounts) 
> todownload.eclipse.org. On the new infra, resource restrictions are in
> place and there is no direct access to download.eclipse.org (only via
> SCP/SSH).
>
> Therefore we are using a dedicated "promotion" build agent with 4vCPUs
> that provides filesystem access. Due to the CPU resource limits of the
> build agent, an aggregation build (simrel.runaggregator.pipeline) now
> takes approximately 2 hours on the new infra (vs ~1h hour on the old
> infra). One hour of this build was spent on "repo reports" alone. AFAIK
> nobody reads the repo reports on a regular basis...if ever. Hence I've
> split out the repo report generation from the aggregation build.
> I'd suggest to run the separate repo reports job
> (https://ci-staging.eclipse.org/simrel/job/simrel.reporeports.pipeline/)
> at least every day/night, but not after every aggregation build anymore.
>
> Please also note, more changes (e.g. native Tycho build) will come soon,
> but the focus is on the migration for now.
>
> If you have any questions or concerns, please let me know.
>
> Regards,
>
> Fred
>
>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


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

Re: [cross-project-issues-dev] [pde-dev] [tycho-user] Using maven artifacts directly in eclipse target platform / tycho builds

2021-01-05 Thread Aleksandar Kurtakov

On Tue, Jan 5, 2021 at 1:27 PM Ed Merks  wrote:

> I read the article, but what's not clear to me is how the
> magically-created-and-repackaged-as-a-bundle Maven artifacts are
> republished.  I assume they must end up in a p2 repo to be installable
> somewhere...  Of course in terms of Eclipse Project using this cool
> support, the question then is: how will the life cycles will work if such
> things are magically created independently by different projects on demand
> and also perhaps more significantly, how are they IP reviewed if they've
> been pulled straight from some Maven repository somewhere?
>
Dash-licenses [1] contains maven plugin so IP can be verified on every
build you produce if you want. Not easily achievable now due to [2] which
shouldn't be too hard to fix.

[1] https://github.com/eclipse/dash-licenses
[2] https://github.com/eclipse/dash-licenses/issues/45


> On 05.01.2021 08:48, Mickael Istria wrote:
>
>
> Thanks for all this very powerful and interesting work Christian! I think
> it's really a good way forward and a good opportunity to progressively
> replace Orbit by a more "build native" approach that will make adoption of
> Maven artifacts by Eclipse projects much easier and faster than the current
> process with Orbit.
>
> On Tue, Jan 5, 2021 at 7:57 AM Ed Willink  wrote:
>
>> for my (small number of) users the problem is the other way round. How to
>> make Eclipse standalone project releases easily consumable by Maven.
>>
>
> It's indeed a different problem and requires different solution. My
> current impression as I deal more and more with things like Language
> Servers and other stuff that are not purely Eclipse Platfrom artifacts but
> then gets consumed in an Eclipse IDE is that if your project also targets
> plain Java and non-Eclipse Platform deployments, then it's better to just
> make it a plain Java project (ie stop using MANIFEST-first and PDE to
> develop it; do plain Java, Maven, BND and so on); and then consume those
> artifacts in your Eclipse Platform integration using the strategies
> described by Christian in his blog post.
> Consuming Maven jars in Eclipse Platform is a much better (simpler)
> handled problem than consuming OSGi artifacts in plain Java.
> --
> Mickael Istria
> Eclipse IDE 
> developer, for Red Hat Developers 
>
> ___
> tycho-user mailing listtycho-u...@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/tycho-user
>
> ___
> pde-dev mailing list
> pde-...@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/pde-dev
>


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

Re: [cross-project-issues-dev] [cbi-dev] Building SimRel with Tycho for 2021-03

2020-11-27 Thread Aleksandar Kurtakov

On Fri, Nov 27, 2020 at 5:54 PM Jonah Graham  wrote:

>
> On Thu, 26 Nov 2020 at 14:57, Frederic Gurr <
> frederic.g...@eclipse-foundation.org> wrote:
>
>> side note: I opened the
>> category.xml file with the category.xml-editor and the opening alone
>> re-wrote/re-formated the whole file.)
>>
>
> (I think this hasn't been answered anywhere yet)
>
> This is because the category.xml support in Tycho is far beyond what is in
> PDE at the moment: https://wiki.eclipse.org/Tycho/category.xml says
> "There are extensions to the format only supported by p2 and Tycho."
>
> It may be nice if the PDE editor didn't delete what it doesn't understand
> though :-)
>

Please open a bug for these cases or add me to the bug. We have to fix that.


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


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

Re: [cross-project-issues-dev] Problems with UI tests in JIPP

2020-11-27 Thread Aleksandar Kurtakov

On Fri, Nov 27, 2020 at 12:57 PM Lorenzo Bettini 
wrote:

> That's what I see before the UI tests are executed:
>
> [INFO] Running org.eclipse.emf.parsley.tests.FormWidgetFactoryTest
> ***WARNING: GTK+ version too old (micro mismatch)
> ***WARNING: SWT requires GTK 3.20.0
> ***WARNING: Detected: 3.10.9
>
> so how can I get a newer version in JIPP?
>

Your JIPP has to be moved to JIRO as the old infrastructure doesn't allow
updates for one single project without doing it for everyone else . As it's
being decommissioned spending time to do the updates there is not worth it.
I see there is https://bugs.eclipse.org/bugs/show_bug.cgi?id=568105 so you
should be on the right track.
P.S. SWT moved to require 3.14 since 2019-12 release so this is not a new
requirement in anyway.


>
> On 27/11/20 11:53, Aleksandar Kurtakov wrote:
> > Which gtk version do you have there ?
> >
> >
> >   gtk_event_controller_set_propagation_phase  is available since gtk
> 3.14 and latest
> >   SWT requires 3.20. So please ensure you have new enough GTK.
> >
> >
> > On Fri, Nov 27, 2020 at 12:41 PM Lorenzo Bettini <
> lorenzo.bett...@gmail.com
> > <mailto:lorenzo.bett...@gmail.com>> wrote:
> >
> > Hi
> >
> > when building our project EMF Parsley on JIPP, we experience issues
> with tests that need
> > the UI (or at least, that's what I think it's happening).
> >
> > We use icewm, which we launch like that
> >
> > icewm --replace --sm-disable 2> icewm.err &
> >
> > and in the .err file, as soon as a UI test runs we see
> >
> > IceWM: using /opt/public/hipp/homes/genie.emf-parsley/.icewm for
> private configuration
> > files
> > XIO:  fatal IO error 11 (Resource temporarily unavailable) on X
> server ":323"
> >   after 6777 requests (6777 known processed) with 0 events
> remaining.
> >
> > Surefire also leaves this information in the dump file
> >
> > /opt/public/common/java/openjdk/jdk-11/bin/java: symbol lookup error:
> >
>  
> /opt/public/hipp/homes/genie.emf-parsley/.swt/lib/linux/x86_64/libswt-pi3-gtk-4940r23.so:
> > undefined symbol: gtk_event_controller_set_propagation_ph
> >
> > everything used to work a few months ago...
> >
> > any clue please?
> > thanks in advance
> > Lorenzo
> >
>
>
> --
> Prof. Lorenzo Bettini, Computer Science, DISIA, Univ. Firenze
> HOME: http://www.lorenzobettini.it
> TDD Book: https://leanpub.com/tdd-buildautomation-ci
> Xtext Book:
>
> https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


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

Re: [cross-project-issues-dev] Problems with UI tests in JIPP

2020-11-27 Thread Aleksandar Kurtakov

Which gtk version do you have there ?
gtk_event_controller_set_propagation_phase  is available since gtk 3.14 and
latest SWT requires 3.20. So please ensure you have new enough GTK.

On Fri, Nov 27, 2020 at 12:41 PM Lorenzo Bettini 
wrote:

> Hi
>
> when building our project EMF Parsley on JIPP, we experience issues with
> tests that need
> the UI (or at least, that's what I think it's happening).
>
> We use icewm, which we launch like that
>
> icewm --replace --sm-disable 2> icewm.err &
>
> and in the .err file, as soon as a UI test runs we see
>
> IceWM: using /opt/public/hipp/homes/genie.emf-parsley/.icewm for private
> configuration files
> XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server
> ":323"
>   after 6777 requests (6777 known processed) with 0 events remaining.
>
> Surefire also leaves this information in the dump file
>
> /opt/public/common/java/openjdk/jdk-11/bin/java: symbol lookup error:
>
> /opt/public/hipp/homes/genie.emf-parsley/.swt/lib/linux/x86_64/libswt-pi3-gtk-4940r23.so:
> undefined symbol: gtk_event_controller_set_propagation_ph
>
> everything used to work a few months ago...
>
> any clue please?
> thanks in advance
> Lorenzo
>
> --
> Prof. Lorenzo Bettini, Computer Science, DISIA, Univ. Firenze
> HOME: http://www.lorenzobettini.it
> TDD Book: https://leanpub.com/tdd-buildautomation-ci
> Xtext Book:
>
> https://www.packtpub.com/application-development/implementing-domain-specific-languages-xtext-and-xtend-second-edition
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>

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

Re: [cross-project-issues-dev] BIRT removal

2020-10-22 Thread Aleksandar Kurtakov

On Thu, Oct 22, 2020 at 6:49 PM Andrew Johnson 
wrote:

> > Message: 3
> > Date: Thu, 22 Oct 2020 09:07:07 -0400
> > From: Wayne Beaton 
> > To: Cross project issues 
> > Subject: Re: [cross-project-issues-dev] Is AERI still used in release
> >train
> > Message-ID:
> >
> > 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 
> wrote:
> >
> > > Hi Wayne,
> > >
> > > TL;DR
> > >
> > > AERI p2 was:
> > > https://download.eclipse.org/technology/epp/logging/milestones/ - see
> change
> > > 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
> > > 
> > >
> > > Longer version:
> > >
> > > The AERI p2 repo was being picked up from
> > > https://download.eclipse.org/technology/epp/logging/milestones/ - see
> > > 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) 
> -
> in
> > > light of Bug 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
> > >
> BIRT removal was discussed in December 2019
> https://www.eclipse.org/lists/cross-project-issues-dev/msg17217.html
> and the contribution was reduced to just the BIRT charting feature which
> solved the problems then. Is this proposal to remove that as well?
>
> Eclipse Memory Analyzer uses BIRT charts for its useful (but optional)
> chart feature.
> What options does MAT have for continuing to use BIRT charting?
>

One option is MAT to contribute the BIRT bundles it uses. Another is to
move to https://projects.eclipse.org/projects/science.swtchart .


>
> The birt.aggrcon points to
> https://download.eclipse.org/birt/update-site/oxygen-interim/
> with BIRT files dated 4.7.0.v201706222054.jar
>
> but there is also
> https://download.eclipse.org/birt/update-site/photon-interim/
> with BIRT files dated 4.8.0.v201905101549.jar
> https://download.eclipse.org/birt/update-site/2018-09-interim/
> with BIRT files dated 4.9.0.v201905231911.jar
> and full downloads, but not a p2 update site at
>
> https://download.eclipse.org/birt/downloads/build.php?build=R-R1-4.8.0-201806261756
>
> including birt-charts-4.8.0-20180626.zip
>
> though SimRel can't choose a release - that is for the project. I saw a
> couple of new committer elections to BIRT in September/October 2020 but no
> recent activity yet from them.
> https://www.eclipse.org/lists/birt-dev/threads.html#11081
>
> Andrew Johnson
>
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>

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

[cross-project-issues-dev] Simre p2 repo aggregator issues

2020-10-09 Thread Aleksandar Kurtakov

Hey everyone,
Due to having to disable one submission to simrel I tried using the editor
as described in [1] and it failed in both 2020-09 and in-development
2020-12 with :
 Cannot satisfy dependency:
From: CBI Aggregator Edit Support 1.0.100.20180129-0239
(org.eclipse.cbi.p2repo.aggregator.edit 1.0.100.20180129-0239)
To: osgi.bundle; org.eclipse.equinox.p2.metadata [2.3.0,2.4.0)
  Cannot satisfy dependency:
From: CBI Aggregator Editor 1.0.102.20180423-1709
(org.eclipse.cbi.p2repo.aggregator.editor.feature.feature.group
1.0.102.20180423-1709)
To: org.eclipse.equinox.p2.iu; org.eclipse.cbi.p2repo.aggregator.edit
[1.0.100.20180129-0239,1.0.100.20180129-0239]
  Cannot satisfy dependency:
From: Equinox p2, headless functionalities 1.6.800.v20200917-0634
(org.eclipse.equinox.p2.core.feature.feature.group 1.6.800.v20200917-0634)
To: org.eclipse.equinox.p2.iu; org.eclipse.equinox.p2.metadata
[2.5.100.v20200908-1020,2.5.100.v20200908-1020]
  Cannot satisfy dependency:
From: Equinox p2, Provisioning for IDEs. 2.4.1000.v20200917-0634
(org.eclipse.equinox.p2.user.ui.feature.group 2.4.1000.v20200917-0634)
To: org.eclipse.equinox.p2.iu;
org.eclipse.equinox.p2.core.feature.feature.group
[1.6.800.v20200917-0634,1.6.800.v20200917-0634]
  Cannot satisfy dependency:
From: Eclipse SDK 4.18.0.I20201007-1800 (org.eclipse.sdk.ide
4.18.0.I20201007-1800)
To: org.eclipse.equinox.p2.iu;
org.eclipse.equinox.p2.user.ui.feature.group
[2.4.1000.v20200917-0634,2.4.1000.v20200917-0634]

Thus I ended up editing the file as pure text file directly which is quite
and improvement from releng POV especially considering that the tool is not
installable due to too tiny dependency version ranges.
With that struggle I couldn't resist to ask myself why do we overcomplicate
things and not do what most projects contributing to simrel already do -
create their p2 repository via Tycho.
There is a bug for moving to Tycho already [2] and it's time to revive the
discussion and simplify releng processes and reduce the number of tools we
use.
The way I look at things is - if I'm struggling to have all the various
"specialized" tools needed we have while being paid to do it full time and
years of releng experience with eclipse projects we have close to zero
chances in attract new people in helping and it's time to think more
seriously about that.

[1]
https://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build#Install_the_CBI_p2Repo_Aggregator
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=500769

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

[cross-project-issues-dev] MPC disabled in Simrel to contribute Eclipse Platform 4.18 M1

2020-10-09 Thread Aleksandar Kurtakov

Hi,
In order to contribute latest Eclipse Platform to Simrel for 2020-12 M1 I
had to disable MPC due to failing to resolve [1] due to too tiny dependency
version range.
There is a fix in mpc git [2] which should fix the immediate issue but IMHO
is not the correct one long term. The recommended way should be to bump the
range to [1.0.0,2.0.0) instead.



[1]
https://ci.eclipse.org/simrel/job/simrel.runaggregator.VALIDATE.gerrit/1732/console
[2]
https://git.eclipse.org/c/mpc/org.eclipse.epp.mpc.git/commit/?id=08179882adf4898c47aedfbc69b9ee4a75775f66

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

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

2020-10-07 Thread Aleksandar Kurtakov

On Wed, Oct 7, 2020 at 2:15 PM Matthias Sohn 
wrote:

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

Have you considered (or even evaluated) usage of Java 11 HttpClient
instead?


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


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

Re: [cross-project-issues-dev] feature dependency version incompatibility

2020-06-13 Thread Aleksandar Kurtakov

On Sat, Jun 13, 2020 at 8:57 AM Homer, Tony  wrote:

> Some 2020-06 features now require javax.annotation 1.3.5 (Jersey Common
> from Orbit and bundles that depend on it such as Linux Tools Docker) while
> others (such as org.eclipse.e4.rcp) still require javax.annotation 1.2.0.
>
>
> https://download.eclipse.org/tools/orbit/downloads/drops2/R20200529191137/repository/plugins/org.glassfish.jersey.core.jersey-common_2.30.1.v20200513-1859.jar
>
>
> http://download.eclipse.org/releases/2020-06/202006171000/features/org.eclipse.linuxtools.docker.feature_4.7.0.202006092019.jar
>
>
> http://download.eclipse.org/releases/2020-06/202006171000/features/org.eclipse.e4.rcp_4.16.0.v20200604-0951.jar
>
>
>
> Is it possible to reconcile these dependency chains without rebuilding the
> features, so that an eclipse application can use several of these
> conflicting features from SimRel 2020-06?  As far as I know it is not, but
> I’d love to learn that I am wrong.
>
>
>
> e4.rcp does not seem to have any version restriction defined (0.0.0).
>
>
> https://git.eclipse.org/c/platform/eclipse.platform.ui.git/tree/features/org.eclipse.e4.rcp/feature.xml#n150
>
> e4.rcp is resolving javax.annotation from the updates repo at build time,
> which provides 1.2.0.
>
>
> http://download.eclipse.org/eclipse/updates/4.17-I-builds/I20200612-0650/plugins/javax.annotation_1.2.0.v201602091430.jar
>
> What contributes these third-party dependencies to the updates repo?
>
Eclipse Platform build using
https://git.eclipse.org/c/platform/eclipse.platform.releng.aggregator.git/tree/eclipse.platform.releng.prereqs.sdk/eclipse-sdk-prereqs.target
where versions are strictly fixed as updates are not always straightforward
when done on the lowest level in the stack.


> Shouldn’t third-party dependencies be resolved from Orbit instead of from
> the updates repo?
>
> How do I update one of these dependencies that is being provided by the
> updates repo, such as javax.annotation?
>
Unfortunately there is no other way I'm aware of other than rebuilding
eclipse platform after changing the prereqs target file.


>
>
> In any case, it seems that it must be too late to fix this for 2020-06,
> but these should get reconciled before 2020-09.
>

I'm here with you and have opened
https://bugs.eclipse.org/bugs/show_bug.cgi?id=564264 to track it down. As
the bundle is in Orbit already (thanks!) this shouldn't be an issue to be
done for 4.17 M1.


> I’m interested in helping with this work, but I’ll need the information I
> asked for above and could use some direction about which project to log the
> bug in for tracking.
>
>
>
> Thanks!
>
> Tony Homer
>
>
>
> P.S. Is this an appropriate discussion for cross-project-issues dev?  I
> don’t want to spam the list so please let me know if this is off-topic and
> how I should communicate instead.  Thanks!
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


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

Re: [cross-project-issues-dev] SWT on Gtk will require Gtk 3.20+ in 2020-06

2020-05-08 Thread Aleksandar Kurtakov

On Fri, May 8, 2020 at 4:41 PM Andrey Loskutov  wrote:

> Alex, you've said that "All non EOLed Linux distributions are already at
> Gtk 3.24".
>
> My colleague responsible for our RHEL platform just told me, RHEL 80. (and
> of course 7.4-7.x) are still on 3.22. Could you please check that?
> See also
> https://access.redhat.com/support/policy/updates/errata#Extended_Life_Cycle_Support
>

My mistake. This should have been 3.22, it was a genuine mistake on my side
checking smth - remember it wrong and use the wrong statement everywhere.
Sorry about that!
We can't move to version newer than what RHEL has as we build with the
default gtk from RHEL.


>
> Background: we are on RHEL 7.4 now and evalute transition to 8.0 (not 8.1,
> but may be). It would not make sense to jump on RHEL platform that has no
> chance to run latest Eclipse.
>
> Kind regards,
> Andrey Loskutov
>
> Спасение утопающих - дело рук самих утопающих
>
> https://www.eclipse.org/user/aloskutov
>
>
> *Gesendet:* Donnerstag, 12. März 2020 um 11:11 Uhr
> *Von:* "Aleksandar Kurtakov" 
> *An:* "issues, Cross" 
> *Betreff:* [cross-project-issues-dev] SWT on Gtk will require Gtk 3.20+
> in 2020-06
> Hey everyone,
> SWT min Gtk version is going to be bumped again this release (to require
> Gtk 3.20+). All non EOLed Linux distributions are already at Gtk 3.24.
> We plan to bump Gtk requirement to 3.24 for September release too.
> This is important step so SWT work on GTK4 can be started now and thus the
> needs of it being expressed to GTK devs on time so we don't end in the GTK3
> situation when porting SWT to it was started only after GTK 3.0 was final
> thus leading to many hacks.
>
> Work will be handled in
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=561047 .
>
> --
> Alexander Kurtakov
> Red Hat Eclipse Team
> ___ cross-project-issues-dev
> mailing list cross-project-issues-dev@eclipse.org To unsubscribe from
> this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


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

Re: [cross-project-issues-dev] GTK 3.22.30 support

2020-05-07 Thread Aleksandar Kurtakov

On Thu, May 7, 2020 at 9:22 PM Anna Kochetova 
wrote:

> We have an application based on Eclipse 4.5 which fails to start with GTK
> 3.22.30. It's not feasible to downgrade GTK, so I'm looking into upgrading
> our app to a more recent Eclipse version.
>

In that case - go directly for 4.15.

>
> On Wed, May 6, 2020 at 10:35 PM Aleksandar Kurtakov 
> wrote:
>
>>
>>
>> On Thu, May 7, 2020 at 12:32 AM Anna Kochetova <
>> anna.kochet...@tasktop.com> wrote:
>>
>>> Hello,
>>>
>>> I was wondering which Eclipse version works with GTK 3.22.30?
>>>
>>
>> All versions from the last 2 years should work. I do recommend always
>> using the latest as every next version has more fixes. Do you have
>> particular issue?
>>
>>
>>>
>>> --
>>> Best regards,
>>> Anna Kochetova
>>> __
>>>
>>> QA Engineer | Tasktop Technologies | tasktop.com
>>> ___
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@eclipse.org
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>>
>>
>> --
>> Alexander Kurtakov
>> Red Hat Eclipse Team
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>
>
> --
> Best regards,
> Anna Kochetova
> __
>
> QA Engineer | Tasktop Technologies | tasktop.com
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


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

Re: [cross-project-issues-dev] [epp-dev] EPP 2020-06 M2

2020-05-07 Thread Aleksandar Kurtakov

On Thu, May 7, 2020 at 5:11 PM Jonah Graham  wrote:

> Hi Alex,
>
> I agree with Fred on this - no respin is my preference for this please.
>

OK. I had to ask :). If the simrel build fails on such contributions it
would be perfect.


>
> Thanks
> Jonah
>
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
>
> On Thu, 7 May 2020 at 09:27, Frederic Gurr <
> frederic.g...@eclipse-foundation.org> wrote:
>
>> Hi,
>>
>> Unsigned artifacts are bad, but not a blocker, therefore I'd recommend
>> to not respin M2.
>>
>> Regards,
>>
>> Fred
>>
>> On 07.05.20 14:54, Aleksandar Kurtakov wrote:
>> >
>> >
>> > On Thu, May 7, 2020 at 1:28 PM Ed Merks > > <mailto:ed.me...@gmail.com>> wrote:
>> >
>> > Hi,
>> >
>> > The 2020-06 M2 version will have a lot of new unsigned content:
>> >
>> >
>> >
>> https://download.eclipse.org/oomph/archive/simrel/linuxtools.aggrcon/index.html
>> >   https://bugs.eclipse.org/bugs/show_bug.cgi?id=562917
>> >
>> > I should remind you that these project-specific reports are
>> > generated daily.   You may wish to monitor them, especially the day
>> > after you've changed your contribution.
>> >
>> > If Eclipse as a whole wasn't so poverty stricken, notification of
>> > such problems could be generated automatically at the point in time
>> > when the problem is first introduced.  Or better yet, it could be
>> > done as part of verifying the SimRel contribution...
>> >
>> > Linux Tools build is ongoing as we speak. Is there still time to have
>> > new submission for M2?
>> >
>> >
>> >
>> > Regards,
>> > Ed
>> >
>> >
>> > On 07.05.2020 11:46, Jonah Graham wrote:
>> >> Hi everyone,
>> >>
>> >> Our next milestone build is available for testing: EPP 2020-06 M2
>> >>
>> >> /There has been a small permissions problem and the p2 repo has
>> >> not been published yet to download.eclipse.org
>> >> <http://download.eclipse.org>. It will be published soon, but I
>> >> wanted to get this out to you as soon as possible. If you need the
>> >> p2 repo, it is available on the CI job linked below./
>> >> /
>> >> /
>> >> /I have been following the steps
>> >> on https://hackmd.io/@jonahgraham/eclipse-epp-release-process -
>> >> you can see the checkmarks as to what is done./
>> >>
>> >>
>> https://ci.eclipse.org/packaging/job/simrel.epp-tycho-build/1020/artifact/org.eclipse.epp.packages/archive/
>> >> or
>> >>
>> https://download.eclipse.org/technology/epp/downloads/release/2020-06/M2/
>> >>
>> >> with the p2 repositories at
>> >>
>> >> http://download.eclipse.org/staging/2020-06 and
>> >> http://download.eclipse.org/technology/epp/packages/2020-06/M2
>> >>
>> >> Please test and send your +1 to this mailing list. +1s are
>> >> optional as the package will be published anyway.
>> >>
>> >> Thank you for testing!
>> >>
>> >> Regards,
>> >> Jonah
>> >> ~~~
>> >> Jonah Graham
>> >> Kichwa Coders
>> >> www.kichwacoders.com <http://www.kichwacoders.com>
>> >>
>> >> ___
>> >> epp-dev mailing list
>> >> epp-...@eclipse.org <mailto:epp-...@eclipse.org>
>> >> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/epp-dev
>> > ___
>> > epp-dev mailing list
>> > epp-...@eclipse.org <mailto:epp-...@eclipse.org>
>> > To unsubscribe from this list, visit
>> > https://www.eclipse.org/mailman/listinfo/epp-dev
>> >
>> >
>> >
>> > --
>> > Alexander Kurtakov
>> > Red Hat Eclipse Team
>> >
>> > ___
>> > cross-project-issues-dev mailing list
>> > cross-project-issues-dev@eclipse.org
>> > To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>> >
>>
>> --
>> Frederic Gurr
>> Release Engineer | Eclipse Foundation Europe GmbH
>>
>> Annastr. 46, D-64673 Zwingenberg
>> Handelsregister: Darmstadt HRB 92821
>> Managing Directors: Ralph Mueller, Mike Milinkovich, Gaël Blondelle
>> ___
>> cross-project-issues-dev 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
>


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

Re: [cross-project-issues-dev] [epp-dev] EPP 2020-06 M2

2020-05-07 Thread Aleksandar Kurtakov

On Thu, May 7, 2020 at 1:28 PM Ed Merks  wrote:

> Hi,
>
> The 2020-06 M2 version will have a lot of new unsigned content:
>
>
> https://download.eclipse.org/oomph/archive/simrel/linuxtools.aggrcon/index.html
>   https://bugs.eclipse.org/bugs/show_bug.cgi?id=562917
>
> I should remind you that these project-specific reports are generated
> daily.   You may wish to monitor them, especially the day after you've
> changed your contribution.
>
> If Eclipse as a whole wasn't so poverty stricken, notification of such
> problems could be generated automatically at the point in time when the
> problem is first introduced.  Or better yet, it could be done as part of
> verifying the SimRel contribution...
>
Linux Tools build is ongoing as we speak. Is there still time to have new
submission for M2?



> Regards,
> Ed
>
>
> On 07.05.2020 11:46, Jonah Graham wrote:
>
> Hi everyone,
>
> Our next milestone build is available for testing: EPP 2020-06 M2
>
> *There has been a small permissions problem and the p2 repo has not been
> published yet to download.eclipse.org . It
> will be published soon, but I wanted to get this out to you as soon as
> possible. If you need the p2 repo, it is available on the CI job linked
> below.*
>
> *I have been following the steps
> on https://hackmd.io/@jonahgraham/eclipse-epp-release-process
>  - you can see
> the checkmarks as to what is done.*
>
>
> https://ci.eclipse.org/packaging/job/simrel.epp-tycho-build/1020/artifact/org.eclipse.epp.packages/archive/
> or
> https://download.eclipse.org/technology/epp/downloads/release/2020-06/M2/
>
> with the p2 repositories at
>
> http://download.eclipse.org/staging/2020-06 and
> http://download.eclipse.org/technology/epp/packages/2020-06/M2
>
> Please test and send your +1 to this mailing list. +1s are optional as the
> package will be published anyway.
>
> Thank you for testing!
>
> Regards,
> Jonah
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
> ___
> epp-dev mailing listepp-...@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/epp-dev
>
> ___
> epp-dev mailing list
> epp-...@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/epp-dev
>


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

Re: [cross-project-issues-dev] GTK 3.22.30 support

2020-05-06 Thread Aleksandar Kurtakov

On Thu, May 7, 2020 at 12:32 AM Anna Kochetova 
wrote:

> Hello,
>
> I was wondering which Eclipse version works with GTK 3.22.30?
>

All versions from the last 2 years should work. I do recommend always using
the latest as every next version has more fixes. Do you have particular
issue?


>
> --
> Best regards,
> Anna Kochetova
> __
>
> QA Engineer | Tasktop Technologies | tasktop.com
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


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

[cross-project-issues-dev] HEADS-UP: ICU4J scheduled for removal from Eclipse SDK after June 2022 release

2020-05-04 Thread Aleksandar Kurtakov

Hey everyone,
This is a heads up email that Eclipse PMC has agreed that ICU4J library
will be removed after June 2022 release.The need for this library usage has
reduced over time and it become a burden to keep uptodate with it and in
addition it increased significantly download/installation sizes.
For most of the classes in the library there are direct replacements
available in java.text or java.util packages. There are cases where it
provides convenience methods but replacing them hasn't been that hard in my
experience.
Every bundle referencing ICU4J is suggested to stop doing that and move to
JVM classes. In cases where this is not wanted or feasible developers
should be ready to provide ICU4J in their p2 sites and take over
maintenance cost for keeping up ICU4J uptodate in Orbit.
Respective bug is [1].

[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=562582
[2]
https://git.eclipse.org/c/platform/eclipse.platform.text.git/commit/?id=e21c925be078745b12480a94e3a40aaa0623f8ed

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

Re: [cross-project-issues-dev] No I-builds since I20200331-1800

2020-04-02 Thread Aleksandar Kurtakov

On Thu, Apr 2, 2020 at 5:27 PM Becker, Matthias  wrote:

> Hi everbody,
>
> I just noticed that on https://download.eclipse.org/eclipse/downloads/
> the newest i-build is from 31th of March.
> Is this expected?
>

Last night build failed due to mac signing service being down.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=561685
There is additional build running right now to check that mac signing is
back https://ci-staging.eclipse.org/releng/job/I-build/28/console

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

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

Re: [cross-project-issues-dev] fork of EPL code in EPL project allowed?

2020-03-27 Thread Aleksandar Kurtakov

On Fri, Mar 27, 2020 at 3:09 PM Henrik Rentz-Reichert (hrr) 
wrote:

> Aleksandar,
>
>
>
> thanks for the explanations and for looking into this! I completely
> understand your situation and didn’t want to bother the Platform team with
> personal mails. I assume (and you confirmed it) that they are busy also
> without caring about my problems.
>

Actually I am advertising exactly that. Ping bug/mailing lists/people/etc.
I have to admit that nowadays it's the most persistent that get attention
:)


>
>
> But to be able to move forward I’ve posted my question for the possibility
> of a kind of fork.
>
> I didn’t mean this is any way as a complaint about poor responsiveness of
> the Platform team.
>
> So for now we will duplicate the code (following Ed Willink’s
> suggestions). And later I would be happy to drop it again and use the
> refactored Platform code.
>
>
>
> Thanks,
>
> Henrik
>
>
>
> *Von:* cross-project-issues-dev-boun...@eclipse.org <
> cross-project-issues-dev-boun...@eclipse.org> *Im Auftrag von *Aleksandar
> Kurtakov
> *Gesendet:* Freitag, 27. März 2020 12:18
> *An:* Cross project issues 
> *Betreff:* Re: [cross-project-issues-dev] fork of EPL code in EPL project
> allowed?
>
>
>
>
>
>
>
> On Fri, Mar 27, 2020 at 12:28 PM Henrik Rentz-Reichert (hrr) <
> h...@protos.de> wrote:
>
> Hi,
>
> the Eclipse eTrice project filed a bug [1] against the Text component of
> the Platform.
> We would like to use the org.eclipse.jface.text.rules.RuleBasedScanner in
> a headless application. The RuleBasedScanner and related classes aren't
> depending on UI stuff, which is fine. However, the org.eclipse.jface.text
> bundle is depending on SWT. So we asked for a split into UI dependent and
> UI independent parts into separate bundles.
>
> Since [1] didn't receive an answer within 3 month and I also assume that
> it's not likely that this part would be split off and moved to a separate
> bundle, my question is:
> Is it allowed that the eTrice project forks the needed classes unchanged
> into its own code base? Of course this would require to place them inside a
> new bundle, e.g. org.eclipse.jface.text.rules, to avoid conflicts.
>
>
>
> I'm sorry for the late reply!
>
> We don't have the manpower to triage all the incoming bugs. Please be a
> bit more patient with us and try to actively ping on bugs, send mails to
> project links, even direct mails to people that worked on given area is
> just fine. It's not like we want  to actively ignore people (especially
> proactive people trying to help improving the codebase) it's just that
> there are so many hours in the day and when you get hundreds of emails per
> day you act on 10-20 and on the next day you start afresh, that's why
> consistency in communication is key.
>
> With all of the above said, I've replied to the bug and brought it to
> discussion so we can work on proper solution. Initial idea was easy to
> implement but would have introduced issues with JPMS and we try our APIs to
> stay stable for years.
>
>
>
>
> Thanks,
> Henrik
>
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=558350
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
>
> --
>
> Alexander Kurtakov
>
> Red Hat Eclipse Team
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


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

Re: [cross-project-issues-dev] fork of EPL code in EPL project allowed?

2020-03-27 Thread Aleksandar Kurtakov

On Fri, Mar 27, 2020 at 12:28 PM Henrik Rentz-Reichert (hrr) 
wrote:

> Hi,
>
> the Eclipse eTrice project filed a bug [1] against the Text component of
> the Platform.
> We would like to use the org.eclipse.jface.text.rules.RuleBasedScanner in
> a headless application. The RuleBasedScanner and related classes aren't
> depending on UI stuff, which is fine. However, the org.eclipse.jface.text
> bundle is depending on SWT. So we asked for a split into UI dependent and
> UI independent parts into separate bundles.
>
> Since [1] didn't receive an answer within 3 month and I also assume that
> it's not likely that this part would be split off and moved to a separate
> bundle, my question is:
> Is it allowed that the eTrice project forks the needed classes unchanged
> into its own code base? Of course this would require to place them inside a
> new bundle, e.g. org.eclipse.jface.text.rules, to avoid conflicts.
>

I'm sorry for the late reply!
We don't have the manpower to triage all the incoming bugs. Please be a bit
more patient with us and try to actively ping on bugs, send mails to
project links, even direct mails to people that worked on given area is
just fine. It's not like we want  to actively ignore people (especially
proactive people trying to help improving the codebase) it's just that
there are so many hours in the day and when you get hundreds of emails per
day you act on 10-20 and on the next day you start afresh, that's why
consistency in communication is key.
With all of the above said, I've replied to the bug and brought it to
discussion so we can work on proper solution. Initial idea was easy to
implement but would have introduced issues with JPMS and we try our APIs to
stay stable for years.

>
> Thanks,
> Henrik
>
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=558350
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>

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

[cross-project-issues-dev] SWT on Gtk will require Gtk 3.20+ in 2020-06

2020-03-12 Thread Aleksandar Kurtakov

Hey everyone,
SWT min Gtk version is going to be bumped again this release (to require
Gtk 3.20+). All non EOLed Linux distributions are already at Gtk 3.24.
We plan to bump Gtk requirement to 3.24 for September release too.
This is important step so SWT work on GTK4 can be started now and thus the
needs of it being expressed to GTK devs on time so we don't end in the GTK3
situation when porting SWT to it was started only after GTK 3.0 was final
thus leading to many hacks.

Work will be handled in https://bugs.eclipse.org/bugs/show_bug.cgi?id=561047
.

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

Re: [cross-project-issues-dev] Gerrit fails with "Failed to load p2 metadata repository"

2020-03-12 Thread Aleksandar Kurtakov

On Thu, Mar 12, 2020 at 9:23 AM Becker, Matthias  wrote:

> Today my gerrit changes fail with
>
>
>
> 08:19:07 [ERROR] Failed to resolve target definition
> /home/jenkins/agent/workspace/eclipse.platform.ui-Gerrit/.repository/org/eclipse/eclipse-sdk-prereqs/4.16.0-SNAPSHOT/eclipse-sdk-prereqs-4.16.0-SNAPSHOT.target:
> Failed to load p2 metadata repository from location
> https://download.eclipse.org/egit/updates-5.6: No repository found at
> https://download.eclipse.org/egit/updates-5.6. -> [Help 1]
>
>
>
> See
> https://ci.eclipse.org/platform/job/eclipse.platform.ui-Gerrit/21989/console
>
>
>
> What’s the issue here?
>

There is bug open for the issue
https://bugs.eclipse.org/bugs/show_bug.cgi?id=561045


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


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

Re: [cross-project-issues-dev] git.eclipse.org seems down

2020-02-18 Thread Aleksandar Kurtakov

I can't push to gerrit Can't connect to any repository: ssh://
akurta...@git.eclipse.org:29418/cdt/org.eclipse.cdt.git (Read timed out
after 30,000 ms).

On Tue, Feb 18, 2020 at 12:42 PM Mikael Barbero <
mikael.barb...@eclipse-foundation.org> wrote:

> I can't see anything bad in the gerrit logs. It may be network congestion,
> but AFAICT no equipment in the infra is under an unusual load.
>
> Is this blocking anyone at the moment?
>
> *Mikaël Barbero *
> *Team Lead - Release Engineering | Eclipse Foundation*
>  @mikbarbero
> Eclipse Foundation : The Platform for Open
> Innovation and Collaboration
>
> Le 18 févr. 2020 à 11:00, Andrey Loskutov  a écrit :
>
> Yep, I see many random timeouts today on pulling from different platform
> git repositories.
>
> Kind regards,
> Andrey Loskutov
>
> Спасение утопающих - дело рук самих утопающих
>
> https://www.eclipse.org/user/aloskutov
>
>
> *Gesendet:* Dienstag, 18. Februar 2020 um 10:58 Uhr
> *Von:* "LORENZO Vincent" 
> *An:* " (cross-project-issues-dev@eclipse.org)" <
> cross-project-issues-dev@eclipse.org>
> *Betreff:* [cross-project-issues-dev] git.eclipse.org seems down
>
> Hello everybody,
>
>   I can’t  patches on gerrit and locally I can’t make a git
> pull (Connection to git.eclipse.org closed by remote host.)
>
> The server service seems spotty.
>
>
> Does someone have the same trouble ?
>
>
>
> Regards,
>
> --
>
> Vincent LORENZO
>
> 01-69-08-17-24
>
> CEA Saclay Nano-INNOV
>
> Institut CARNOT CEA LIST
>
> Point Courrier n° 174
>
> 91 191 Gif sur Yvette CEDEX
>
> ___ cross-project-issues-dev
> mailing list cross-project-issues-dev@eclipse.org To 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



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

Re: [cross-project-issues-dev] Today is M2

2020-02-08 Thread Aleksandar Kurtakov

On Sat, Feb 8, 2020 at 11:12 AM Ed Merks  wrote:

> Wayne,
>
> Are you suggesting that SUA 2.0 is a new participation requirement?  It
> seems to me merely a very-nice-to-have.  At this point I would just be
> happy if there were no corrupted variants of SUA 1.0 and SUA 1.1:
>
>   https://bugs.eclipse.org/bugs/show_bug.cgi?id=553881
>   https://bugs.eclipse.org/bugs/show_bug.cgi?id=553883
>
> The odds that the 20 features using SUA 1.0 and the 365 features using SUA
> 1.1 will all migrate to SUA 2.0 before the 2020-03 release, without
> introducing new errors, seem beyond remote to me.
>
> All,
>
> Note that not only were the two license problems above not fixed for M2,
> the signing problems were also not fixed:
>
>   https://bugs.eclipse.org/bugs/show_bug.cgi?id=559739
>   https://bugs.eclipse.org/bugs/show_bug.cgi?id=559740
>
We should get the swtchart one fixed for M3.
https://github.com/eclipse/swtchart/commit/af344337cde6e591cfca9984ec62bc07ab45167b


> On the plus side, although the Eclipse Eierlegende Wollmilchsau remains a
> horrible beast:
>
>   https://bugs.eclipse.org/bugs/show_bug.cgi?id=483982
>
> At least it launches successfully again:
>
>   https://bugs.eclipse.org/bugs/show_bug.cgi?id=559317
>
> Of course this is only the case after waiting some minutes for the
> workspace dialog prompt, hoping my computer doesn't catch on fire in the
> process, and then waiting another minute for the IDE actually rear its ugly
> head.
>
> At this point, the Error Log is very well populated:
>
>   https://bugs.eclipse.org/bugs/attachment.cgi?id=281750=edit
>
> Most interesting is that clicking an error log entry will always create a
> new one:
>
>   org.eclipse.core.runtime.CoreException: No property tester contributes a
> property org.eclipse.tcf.te.launch.ui.model.canDelete to type class
> org.eclipse.ui.internal.views.log.LogEntry
>
> Regards,
> Ed
> On 07.02.2020 23:07, Wayne Beaton wrote:
>
> Hey folks!
>
> Today is the M2 date for the simultaneous release. I'll be assembling the
> project participation information shortly.
>
> If you are planning to contribute new bits to the 2020-03 simultaneous
> release, and have not already done so, please create a release record as
> soon as possible. It'll be much easier for everybody (especially me) if you
> can get this done before I start assembling the participation list (if the
> information is there, then it will be far more likely that I get it right
> the first time and we can avoid the back-and-forth of fixing things after
> the fact). There is help in the handbook
> .
>
> Please make sure that your content has the latest SUA and that, if your
> project is currently using the EPL-1.0, you update to the EPL-2.0. If you
> need help with this, please let me know (there's a lot of useful
> information for this on Bug 530393
> ).
>
> You need only engage in a release review if you have not done so with one
> year of your release date. If you do need to engage in a release review,
> please engage in the workflow at your earliest convenience. The IP Log
> submission deadline is February 28/2020 (M3).
>
> Note that, whether or not you engage in a release review, you are required
> to implement the IP Policy at all times. Further, it is a simultaneous
> release requirement that all third party content be consumed through
> Eclipse Orbit.
>
> The IP Policy was updated in the fall. In practical terms for simultaneous
> release participants, this means that you no longer need to create
> piggyback CQs. There's more background in a Reviewing Third Party Content
> blog post
> .
> More information regarding how our processes are being updated will be
> coming shortly.
>
> You have likely heard that the Eclipse Planning Council was removed from
> the Bylaws of the Eclipse Foundation. This does not mean that the Planning
> Council no longer exists, only that it is no longer governed directly by
> the bylaws. The Planning Council is still very much the primary authority
> with regard to oversight of the simultaneous release.
>
> Thanks,
>
> Wayne
> --
>
> Wayne Beaton
>
> Director of Open Source Projects | Eclipse Foundation, Inc.
>
> ___
> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe from 
> this list, 
> visithttps://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev



-- 
Alexander Kurtakov
Red Hat Eclipse Team

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

2020-01-30 Thread Aleksandar Kurtakov

On Thu, Jan 30, 2020 at 5:01 PM Jonah Graham  wrote:

> I am not sure what happened to EPP for M1 - but at the moment the chatter
> on the mailing list makes EPP look dead. I tried to revive getting a +1s
> for M1 and to find out / understand the process, but I was met with almost
> complete silence on the mailing list
> https://www.eclipse.org/lists/epp-dev/msg05666.html.
>
> Although this may be a case of transference - I suspect that no one said
> anything on epp-dev because they were afraid of putting their head about
> the parapet and becoming "it" for EPP project lead without having any
> understanding of what that would entail.
>
> I honestly don't know how Markus did EPP for all these years single
> handedly* without having to delegate to anyone - there is something to do
> generally on every third Thursday all year round (sometimes even more often
> like RC times). Did Markus schedule all his holidays and everything else
> about his life around the Eclipse release schedule? Personally I have had
> to delegate my +1 for the CPP package a handful of times because I am not
> able to reliably be around for each and every release. For someone like me
> to take on the EPP role would require a full rebuilding of consensus and
> delegating authority to make it sustainable.
>
> I am not even willing to engage in considering** this as I still have no
> clarity what is required every third thursday, is it just clicking a
> button, or is it hours and days of work to resolve broken packages (I know
> Markus has had to do such resolutions in the past and that is a non-trivial
> task)
>
> * I am aware that there are others who have done this too - but for the
> context of the future of the EPP I am focusing on Markus' contribution.
>
> ** I have other issues with taking this on - I am the new CDT project lead
> which is taking a lot of work to consolidate the project and try to bring
> new contributors (and future committers!) online. In addition, because of
> CDT's dependencies I am taking on more and more work on those dependency
> projects.
>
> I hope this helps explain why I can't break the chicken-and-egg problem on
> my own - perhaps I am too chicken :-)
>

After reading I have an "interesting" proposal :) . Instead of looking for
single person why don't we do it in shifts - each release one of the
package maintainers does the work. IMHO it is:
* fair
* spreads the work
* will help with automation as every package maintainer will have to do it
at one point

There is the question what if given maintainer/project doesn't want to do
it - well, solution for this is simple drop that particular EPP.


>
> Jonah
>
>
> On Thu, 30 Jan 2020 at 07:59, Ed Merks  wrote:
>
>> On 30.01.2020 11:53, Aleksandar Kurtakov wrote:
>> > Well, focus on "what" is quite important as I still haven't seen
>> > anywhere written what exactly is needed for the "who" decides to take
>> > EPP. There won't be any "who" until "what" is clearly defined.
>>
>> That is indeed a good point.  :-)
>>
>> Markus didn't announce here despite being prompted, and while I'm sure
>> he's documented what exactly he does, even I don't know exactly what
>> that is.  I don't expect it's all that onerous.  In any case, in this
>> thread you can see that he's offered to walk someone through the steps:
>>
>>https://www.eclipse.org/lists/epp-dev/msg05676.html
>>
>> I.e., Markus will clarify the "what" when there is a "who" but if there
>> cannot be a "who" without a "what" then we have a classic
>> chicken-versus-egg problem...
>>
>> Of course my natural reaction is to jump in and be the "who", but I'm
>> quite sure that this is also pandering to complacency.  That needs to
>> end because it's not sustainable.  But it would most certainly be the
>> best course of action for the greater good...
>>
>> ___
>> 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



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

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

2020-01-30 Thread Aleksandar Kurtakov

On Thu, Jan 30, 2020 at 12:38 PM Ed Merks  wrote:

> Of course there's no such thing as a bad question, but I think the
> question below is kind of the wrong question at this point in time.   At
> this point, the "we" who are doing the tasks, time consuming or trivial,
> as I've already spelled out are Fred, Markus, and Ed.   Fred will
> continue to do what's needed, so we can expect the M2 train repo leave
> the station as usual, and can expect that to continue into the future.
> So the train repo functions even in the face of complacency, so perhaps
> we ought to strike that from the discussion, until Fred (the Foundation)
> threatens to stop doing this.  But Markus will not continue do to what's
> needed, so who will make sure M2 packages arrive?  No one. This problem
> is imminent. It will not be solved because Fred or I have less work on
> other "unnecessary but time consuming tasks". Of course Ed can probably
> be counted on to do what he always does, so we can all at least hope
> that he just does his usual thing. Maybe even assume that he'll just do
> Markus' thing too because Ed is crazy.
>
> So it seems to me we cannot focus so much on the "what" as long as there
> is no "who".  I.e., I think it's misguided to assume we can squeeze a
> "who" out of thin air by changing the definition of what needs to be
> done.  M2 definitely needs to happen...
>

Well, focus on "what" is quite important as I still haven't seen anywhere
written what exactly is needed for the "who" decides to take EPP. There
won't be any "who" until "what" is clearly defined.


>
> On 30.01.2020 10:45, Aleksandar Kurtakov wrote:
> >  Until there are signs of new resources we have to ask "What is the
> > least needed time consuming task we can stop doing ?" so progress on
> > the good ideas can happen.
> ___
> 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



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

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

2020-01-30 Thread Aleksandar Kurtakov

On Thu, Jan 30, 2020 at 10:17 AM Ed Merks  wrote:

> Thank you Stephan for your balanced, concise, insightful commentary!
>
> More comments below...
>
> On 29.01.2020 23:54, Stephan Herrmann wrote:
> > Thanks, Ed, for raising these concerns.
> >
> > The thread is already at a volume which makes it hard to digest, I can
> > only hope I got the essence of what everybody is thinking.
> >
> Yes, the thread has frayed into multiple smaller threads, some of which
> stray far from the original focus.  E.g., release cadence and quality
> concerns.
> >
> > One way I could interpret the situation is: It takes a very small
> > number of qualified people to herd the train - full-time, and then the
> > immediate issue is resolved.
>
> Yes, Fredric Gurr, Ed Merks, and Markus Knauer help to ensure that the
> large volume of inputs result in the correct and appropriate outputs.
> The simrel inputs are a large sets of p2 repositories comprising an even
> larger set of installable units. Fred's work ensures that these inputs
> map to a simple p2 repository (the train repo) with a correct, coherent,
> consistent set of installable units, organized into categories.  Markus
> Knauer's work ensures that the EPP inputs (the package/product
> definitions), in combination with the train repo, map to a simple p2
> repository (the epp repo) as well as a set of canned packages
> (zip/tar/dmg).  These two simple repos are composed to give us the
> overall simrel repo.  Ed Merks ensures that the train repo in
> combination with the epp repo maps to a set of Product Versions in
> Oomph's Eclipse.org Product Catalog, and delivers a set of installers
> (*.exe/tar/dmg) that is based on the latest installable units from the
> train repo.  These installers can be used to install the same "packages"
> as are delivered as canned packages (zip/tar/dmg).
>
> Fred is funded by the Foundation, which stepped in when David Williams
> funding was cut by IBM.  Ed Merks was funded by itemis, but that has
> been cut.  Markus Knauer is funded by Eclipse Source, but his daily work
> is unrelated and so he has stepped back because essentially his work is
> unfunded.  In the past, both itemis and Eclipse Source were Strategic
> Developer Members, but each has stepped back from that long ago.  At
> this point the Foundation is not able to step in because of its own
> budget constraints and is also not willing to step in because it's a
> slippery slope to step in purely using existing budget whenever some
> part of the community fails.  Of course the failure in this case is
> cross project and broadly sweeping...
>
> > There are member companies for whom it should not be a problem to fund
> > the one appointed train master - perhaps via the foundation. I'd love
> > to see Ed's efforts to be compensated in a way which would allow him
> > to give us a long term perspective. I don't represent a member company
> > so I can't comment on whether and how this simple idea could be put to
> > action.
> >
> The proposed solution is a Working Group with membership fees as the
> funding model for this process.  Of course for that to work, some member
> companies need to get step up and that boils down to the question: why
> should I (as a member company) get involved (pay) when I can just wait
> for and hope that some other member company will pay the cost instead?
> It feels like a game of chicken played by multi-billion revenue
> companies, where the amount of money actually required is as a molecule
> of water.   I remember all too well the days when the Platform was
> funded almost exclusively by IBM: that game of chicken lasted for
> years.  Thank goodness Red Hat joined the party and thank the mighty
> techo deities for Tycho.
> >
> > I assume all of us subscribed to cross-projects have a shared interest
> > in providing to our users plenty of options of which software they
> > want to install, in various combinations, and all in the latest and
> > greatest version. Without bad surprises on their way.
>
> Yes and no.  Herein we already see a fundamental split in the
> community.  There is the "we don't care about the train repo" camp, and
> also the "we don't care about the packages" camp...
>
> > Please, those who want to do away with SimRel: tell me, what efforts
> > are incurred by SimRel that or not essential for this original goal?
> > If SimRel incurs non-essential efforts, produces accidental
> > complexity, shouldn't we just name these, so we can fix things
> > (process? automation?).
>
> In my opinion, aside from the question how exactly the p2
> repo/installable-unit inputs are managed/represented, the train repo is
> and must remain one of the primary goals and outputs of the overall
> process.  Many of us care deeply about this and some of us only care
> about this.  Producing this is Fred's role and of course it's already
> primarily automated. In fact, so automated that we have a daily staging
> train repo.  Only Fred can comment on how much overall

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

On Wed, Jan 29, 2020 at 8:06 PM Daniel Megert 
wrote:

> I'm -1 to change the release schedule. Yes, there are probably more bugs
> but there are also more features *and* bug fixes that our users get more
> frequently.
>
> One important thing that was not mentioned so far is the role of the
> Planning Council where the stakeholders (strategic members and PMCs)
> discuss and decide on the schedule. This can for sure not go to EPP unless
> the current council is part of the EPP leadership.


IMHO EPP (incl. SimRel)  shouldn't be mixed with Planning Council - it
should be governed as every other project. Planning Council should be more
of a cross project collaboration place. I would also question the need for
Strategic members and PMCs having a vote on EPP (even less being in the
leadership) unless the member in question actually does something in the
EPP project.
As much as this might sound like blasphemy we will fail to attract people
taking over some duties if there are multiple abstract bodies dictating
what/how to be done. I know that I (personally) for sure would not sign up
in such a case. Having people that actually know what/how/why is done or at
least are interested in helping some area would be more than welcome but
having people from a PMC that failed to do proper release for couple of
years or just being appointed by some company seems pointless. And my
Planning Council experience shows that such people never actually attended
even less discussed anything at the meetings and this makes me even more
convinced that giving every strategic member and PMC EPP leadership would
be totally wrong move.


>
> For me the thing we must preserve is the p2 repo and the installer.
> Package are also nice/useful but not my top priority.
>
> Dani
>
>
>
> From:Gunnar Wagenknecht 
> To:Cross project issues 
> Date:29.01.2020 15:25
> Subject:[EXTERNAL] Re: [cross-project-issues-dev] [WARNING]
> SimRel Headed Off theTracks
> Sent by:cross-project-issues-dev-boun...@eclipse.org
> --
>
>
>
> > On Jan 29, 2020, at 12:44, Sebastian Zarnekow <
> sebastian.zarne...@gmail.com> wrote:
> >
> > But in general, the current release cadence puts too much of a burden on
> the shoulders of all maintainers.
>
>
> As a project lead contributed to the train in the past and as a package
> maintainer, I truly disagree with the "too much of a burden" claim being
> raised here. Once you got all the things in place and compliant I don't
> ever recall it being a problem to put out new bits. 98% of it was automated
> anyway. It was push on Jenkins. The other 2% was bureaucracy in the portal.
>
>
> > Platform and JDT used to be rock solid with the annual releases. Now we
> see more releases but also more bugs and complains from users as far as I
> can tell. Most of the people that I'm talking too are no longer confident
> in the quality of the release. For them it's nowadays a tradeoff between
> the bugs the suffer from and know of vs the bugs they will suffer from but
> don't know yet.
>
> There is some truth here but it really isn't that bad. I'd like to raise
> two things on the positive side, though.
>
> 1. The quality is in my subjective impression on par with - if not better
> - than the six-weeks milestone releases Eclipse had previously.
> 2. I don't have to wait for a full year till I'm able to consume a fix.
>
> Yes, I do face a few bugs. Some of them are annoying. But I'd challenge if
> they are really a result of the faster release cadence *or* a result of
> funding downsizing in involved development teams.
>
>
> > > Also annual releases will resurrect a number of "service releases"
> with all the effort required,
> >
> > And with the quality gains. Exactly.
>
> You will only see quality gains *if* the projects are willing to invest
> into maintaining a service branch. I have the impression that it's easier
> for the active projects to simply fix things in main/master and don't worry
> about back porting (which can double work).
>
>
> In the past the SimRel had its clear purpose. It was a big win for the
> Foundation to be able to coordinate releases across its projects. It really
> made us look big in terms of numbers and successful (year over year at the
> same time, no delays). It came with a ton of bureaucracy. IBM thankfully
> dedicated full-time employees to creating and maintaining the SimRel.
>
> I think it was already a risky decision to continue business as usual when
> the only FTE retired. There is a staffing issue at hand. I don't get the
> proposal of going back to one release per year. What is the solution if
> SimRel rans into a staffing issue again? One release every four years? I
> think a first step is to admit that we cannot maintain the existing
> process. There simply isn't enough funding.
>
> We have to allow and ask the question - is it time to end the SimRel?
>
> FWIW, as a package maintainer I don't care if I consume things from

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

On Wed, Jan 29, 2020 at 2:57 PM Ed Merks  wrote:

> Clearly we digress here.  In any case, this bugzilla is open for
> removing invalid marketplace listings:
>
>https://bugs.eclipse.org/bugs/show_bug.cgi?id=550713
>
> Many failures are pretty clear.  The host no longer exists so clearly
> the listing is completely bogus...
>

I know the bug and I have commented on it and chased people to drop broken
listings and etc. But this is clearly not working thus we need someone from
Foundation to either step in or open the management of the marketplace to
the community so we can deliver better user experience.


>
> More comments below.
>
> On 29.01.2020 13:34, Aleksandar Kurtakov wrote:
> > So who is in charge of marketplace content?
>
> That's unclear.  It's kind of distributed as are most things. The user
> create/edits their listing, but until I implemented something to test
> it, no one tested it. There is no established process for removal.  I
> think only foundation staff can remove listings. And of course, like
> everyone else, the foundation staff is overloaded for lack of resource...
>
> > I can't believe we don't have a way to remove non-installable features
> > based on these reports. After all each release there is compatibility
> > with the latest  simrel added. Who does that? How? Can community
> > influence help with that?
> > IMHO claimed but not actually supported compatibility should be auto
> > removed from the market place entry. Entries with nothing installable
> > should be removed.
> I agree, but I'd hate for errors in my testing to cause a listing to be
> removed for bogus reasons.
> > As I would expect something like "Eclipse Foundation doesn't have
> > resources to develop that" popping up in the discussion - how can the
> > community help?  Any pointers are welcome.
> I think the report pretty much does the job, assuming no errors in the
> testing process itself.
>

We have to be 100% sure in the report - yes! But even more importantly it
has to be hooked with some automated run, notify (maintainer should be able
to point issue in reporting to stop removal or fix the listing), remove if
no action cycle and this is not existing AFAIK.


> > Wayne, I point to you with these questions as you should at least be
> > able to ask the correct person to jump in.
> ___
> 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



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

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

On Wed, Jan 29, 2020 at 1:28 PM Ed Merks  wrote:

> Comments below.
> On 29.01.2020 10:48, Mickael Istria wrote:
>
>
> It seems mostly based on the the principle/assumption that moving the
>> problem will simplify the problem or make existing problems disappear by
>> magic.
>>
> Indeed, I believe that moving the problem to a better functioning project
> according to EDP practices, and by the way getting rid of a lot of
> questionable effort, will make many projects disappear.
>
> Making project disappears will definitely help make their contributed
> problems disappears.  Also, centralization of responsibilities seems
> helpful.
>
> Currently the train repo is a prerequisite for producing the packages and
>> it composes a large set of repositories into a single aggregate at which
>> point a high level of consistency is checked and ensured. In the end,
>> ensuring that all the artifacts that comprise each package are coherent
>> (and stable) does not go away even if somehow the packages were produced by
>> directly pulling content from something other than the train repository.
>>
> With EPP, we ensure that the packages are consistent and of good enough
> quality to be released. I don't think that would change much, and EPP could
> also add some tests verifying all features can install in the same IDE.
>
> The user's often install additional things the consistency of which is
> also important it seems to me.   The train has helped a great deal with
> that. E.g., you can be sure that when you install Xtext you also install
> the corresponding EMF version...
>
>
>
>> Nothing changes with regard to ensuring consistent licenses, signed
>> content, proper inter-operation, stable repositories, and mutual
>> instability.
>>
> Right, but at least, if it's in EPP, then we're sure the projects that are
> integrated have at least 1 person (the EPP maintainer for this package)
> caring about those issues and dealing with them. While with current push
> model in SimRel, some project push outdated stuff and aren't reachable.
>
> Yes, though it's not clear that this point what subset remains based on
> the transitive closure of all EPP package dependencies.   Often there are
> surprises.  E.g., I tried to remove BIRT, but there remain charting
> dependencies so I could only reduce the subset aggregated from BIRT...
>
> In the end, I'm not even sure if you're suggesting that there needs to be
>> no aggregation at all, but simply a very large set of direct references to
>> various project repositories.  But I can assure you that loading 50
>> repositories instead of 2 when doing an install will not improve the
>> experience, and that getting n projects to maintain long-term stable sites
>> is a new problem that will also turn into yet another cat herding exercise
>> and when it fails (as all things do on occasion), the users will notice
>> immediately.
>>
> I suggest EPP builds the aggregated and categorized p2 repository,
> containing only stuff that are included in packages.
>
> We'd need to understand the transitive closure of all packages and presume
> that consistency for anything in a package is just not important to anyone,
> not even users.
>
> As such, I did quick test, resolve all EPP IUs for 2020-03 into a target
> platform, which suggests that only 10% of the IUs are in packages. It's not
> clear which cross section of projects this covers.  But it's clear looking
> at which EMF things are in the TP that only a very small subset of what EMF
> contributes to the aggregate is transitively required by the EPP
> packages.   I'd not be happy with a train aggregate that did not include
> all the things I currently contribute to the train.  One stop shopping from
> the aggregate, an aggregate that's bigger than what's transitively
> pre-installed in the union of all EPP packages, seems to me to have
> significant value...
>
> To build. EPP references different source p2 repositories, just like
> SimRel reference other repositories.
>
> So how will the exact repositories to use be managed?  I see later you
> suggest a *.target file, but it's not clear if that's a per-package
> *.target, in which case keeping it consistent across packages is important,
> or if it's shared single *.target, in which case multiple packages need to
> main the union of IUs to pull from the URLs.
>
> It feel as if you've joined the discussion years after all the reasons for
>> having a train the first place were had, and that you assume there really
>> are no good reasons because you were not part of those discussions.  So all
>> the reasons need to be reiterated, at which point you are highly inclined
>> to try to shoot each one down because they don't fit you current conclusion.
>>
> I know the reasons, and participated in integration of a project in SimRel
> 11 years ago and was very excited about SimRel and invested in it. I think
> it was interesting back then, but times have changed: many project are
> almost inactive in SimRel, SimRel

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks

On Wed, Jan 29, 2020 at 1:47 PM Ed Merks  wrote:

> Comments below.
>
> On 29.01.2020 12:08, Aleksandar Kurtakov wrote:
> >
> > Let's add that I fully stand by Mickael here and his proposal is the
> > only one we got so far with a potential to improve the situation.
> As I mentioned in my reply to Mickael, the proposal is mostly juggling
> the locations of the problems, not eliminating the underlying problems,
> though likely reducing the problems by virtue of reducing the number of
> involved projects.
>

I have never even thought that this will fix the underlying problems. But
reducing them gives some fresh air and time(!) so we can actually look at
how to actually fix them. Keeping the status quo means all of our time goes
into preserving it .
Let me give another example - we have spent months on getting api tools,
version checks, even new compile warnings fail gerrit verification jobs for
platform. This came at a cost - a number of third party dependencies
(Lucene, Felix , Batik ...) haven't been updated regularly. But now that
these checks are in line and every single patch is verified to not break
these things (that used to cost weeks per release) we are full steam ahead
on improving the situation as we are no longer paying the time price to do
it manually.
If that means we get EPP+simrel shrinked to some bare minimum so we can
automate things and whoever wants to add something adheres to more and
automated(!) checks - it's totally worth it.


> > We have to just admit that Simrel and EPP can't continue in the way
> > they are and look out for changes that will improve the situation.
> I don't agree.  I would argue that train aggregate's value is not merely
> to install EPP packages, but rather to provide one-stop shopping for a
> consistent set of features that will function cohesively.  But it's fair
> to argue, "I don't care about that so I won't invest my resource in
> that".  Nevertheless, I do see value in that, and have been investing
> resource in that.
> > From Ed's proposal:
> > * Choice 1 - let's be realistic and admit that this would not happen.
> > No one will step up and do things the way they used to be just because
> > someone is used to it being that way E.g. If I (or anyone from my
> > team) step up - we will effectively implement the proposal. Of course
> > anyone is free to jump in and keep things the way they are - I'll be
> > more than happy to be proven wrong here :)
> I would be happy to step in if I were able to continue to pay my bills
> in some way that was directly or indirectly related to the investment of
> my effort.
>

And many others but I don't see anyone offering it. That's why I call it
unrealistic until we actually see someone offering it.


> > * Choice 2 - speak to representatives. From all the
> > Planning/Architecture council meetings there used to be a lot of
> > wishful thinking over the years and pretty much no one there spent the
> > time/resources to make it happen. Read this as - we don't need talks,
> > we need actions.
> I've prompted the board the take action but without further prompting it
> is indeed just so many words and so little action.
> > * Choice 3 - do nothing . I understand this is meant to be provocative
> > and I fully support some stress over the community. We should start
> > questioning every single piece of our process and if it has resource
> > issues consider it ineffective or not needed before trying to solve
> > it. For many of the existing plugins that are part of the Simrel that
> > would be the best to do - nothing.
> Yes, I intend to make people realize that this is basically what
> everyone is doing and has been doing.
> > Well actually do single step - remove them.
> > To use DLTK project  - we did exactly that - dropped the python (Pydev
> > is better offering!), ruby (Solargraph is better offering!), shell
> > script (ShellWas is better offering), js (WildWebDeveloper is better
> > offering)  from the December release.
> > To use CDT project  - launchbar and templates repo are merged into
> > main one to reduce cycles. Terminal is getting moved to CDT so RSE can
> > finally be left to rot there. Ancient parsers are getting dropped and
> > so on.
> > I'm not even going to mention the amount of work and automation that
> > went on Platform and Tycho side .
> Yes, I'm well aware of how much work it is just contributing quality
> content to SimRel for my own projects.  I'm sure this is a huge effort
> for a great many, hence the cries for doing fewer releases. But the
> platform drives and that drives the rest of us and we have far less
> resource than does the platform!
>

Interestingly enough Platform used to be the one of

Re: [cross-project-issues-dev] [WARNING] SimRel Headed Off the Tracks