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

[Mickael Istria via cross-project-issues-dev]

Hi Wayne, all,

LSP4E will contribute 0.26.1 (unless we have to create another release)
https://projects.eclipse.org/projects/technology.lsp4e/releases/0.26.1
Wild Web Developer will contribute 1.3.5
https://projects.eclipse.org/projects/tools.wildwebdeveloper/releases/1.3.5

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

Re: [cross-project-issues-dev] [eclipse-ide-wg] Eclipse Java IDE 2023-03 video

[Mickael Istria]

Thanks Holger for this excellent video!
As a reminder, if anyone is interested in managing the @EclipseJavaIDE
twitter account to eg. post this video on the day of the release; please
get in touch and I'll share the credentials. As mentioned earlier, I'm not
going to do it this time as I'm progressively trying to quit twitter.
Cheers,
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [epp-dev] EPP 2023-03 M3

[Mickael Istria]

Hello,

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

Back to this specific case...

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

Indeed, LSP4E uses tight ranges for LSP4J because LSP4J API is changing in
non-backward compatible-ways (this is necessary to support changes in
Language Server Protocol).
And indeed, latest release of LSP4E (0.21) does use LSP4J 0.19 (not latest).

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

> lsp4e was already updated to lsp4j 0.20 by Mickael five days ago:
>
> https://github.com/eclipse/lsp4e/commit/ad0c6a19481f5c729b45a3784fec94201d217085
>  So as soon as the next lsp4e release (I assume 0.22) is contributed to
> SimRel only one version of lsp4j should remain.
> @Mickael can you tell/estimate when this will be?
>

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

The two different 2.10.1 versions of gson are probably due to the fact that
> lsp4j uses gson 2.10.1 from Maven-Central, while somebody else uses gson
> 2.10.1 from Orbit:
> https://download.eclipse.org/tools/orbit/downloads/drops/I20230215045902/
>  But what I don't understand is, why does Orbit even contain a recent
> version of gson? In m2e we use gson 2.10.1 from central and it looks like
> it already has proper OSGi metadata.
> Therefore I don't really understand why the version from Orbit is even
> used and provided?
>

I agree that Orbit duplicating a bundle that exists in a usable state
upstream can be the root of many other issues. As we have an example here
that this has a cost to troubleshot, and that there was probably a cost in
setting up the Orbit clone; I'm also curious about what is the expected
added-value that makes this cost profitable enough to be perceived as an
reasonable investment?
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Builds failing

[Mickael Istria]

Reproduced in
https://ci.eclipse.org/releng/job/Builds/job/I-build-4.27/96/console . Have
you already open a ticket to EF infra support?
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

On Thu, Jan 19, 2023 at 4:20 PM Ed Willink  wrote:

> Is this serious or have I totally misunderstood?
>

Both.
___
cross-project-issues-dev 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] A future without source features?

[Mickael Istria]

Hi all,

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

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

Cheers,
-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat
Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

On Wed, Jan 4, 2023 at 8:53 AM Andrey Loskutov  wrote:

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

https://github.com/eclipse-platform/eclipse.platform.team/issues/8 and
https://github.com/eclipse-platform/eclipse.platform.team/commit/7592b18cbbb95c47723044805933c3d4298306fb
are where the removal of CVS plugins took place. Anyone interested can
fetch the parent commit
https://github.com/eclipse-platform/eclipse.platform.team/commit/160248690da26615c80fc2e7342e4109f232452e
and get the org.eclipse.team.cvs* folders to fork from.

> IMHO, UX is also API

Well, I don't think it's a matter of opinion here, but a matter of
definition. When Eclipse Project says "API" in its retention policy, it
clearly doesn't say "UX".

> Presumably it was possible to write a program that re-used team CVS
support to check out a CVS project.

That's why the removal was announced way ahead of the actual removal, so
that people who presumably cared enough could tell and ask for another
process or some delay if necessary. But no-one did.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

Well, if there is a consensus that Platform should fully and stricly
implement semantic versioning, even for internal classes; we'll end up with
Platform bumping its major version every 3 months. I hope you -and everyone
else- is ready to be very careful at defining the version ranges in your
MANIFEST.MF files; or your plugins will die even sooner!
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

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

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

Well, sometimes allowing contributors to make money from their work is
actually one way to try being friendly.
But indeed, if one wants to do that work for free, that's even friendlier.

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


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

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

Ultimately, there is a clear law of software development: unmaintained
software that no-one builds or updates against newer version of its
dependencies will die; only software that someone maintains actively
survives. It's not a matter of process here, but a matter of interest in
maintaining it. If some money can be found to boost interest from someone
in maintaining here, then we all win.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

Hello,

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

Re: [cross-project-issues-dev] running UI tests in JIRO

[Mickael Istria]

Hi,
Note that if you're running on a pod based on a recent Fedora version which
has Gnome >= 40, you should be able to leverage
https://www.phoronix.com/news/GNOME-40-Headless-Virtual and replace Xvnc &
metacicty with `mutter --headless`. If this is of high enough interest to
be able to leverage latest things on CI, it could be worth you try
contributing a pod template with such recent fedora:
https://github.com/eclipse-cbi/jiro-agents
Cheers
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Where is M2E - POM Editor (Legacy) using WebTools SourceEditing UI?

[Mickael Istria]

On Fri, Sep 16, 2022 at 12:03 PM Lorenzo Bettini 
wrote:

> has it been abandoned for good?


Yes.
But if you're willing to revive it, please consider joining the m2e-dev
mailing-list to state your intent and submitting PRs to restore it.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [ide-dev] Eclipse Java IDE 2022-09 video

[Mickael Istria]

Thank you very much Holger, that a great resource!
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] m2e(-wtp) requesting a SimRel respin

[Mickael Istria]

Thank you very much, and sorry again!

On Thursday, September 8, 2022, Ed Merks  wrote:
> The respin is complete at this location and is ready for consumption by
EPP:
>
> https://download.eclipse.org/releases/2022-09/202209141001/
>
> On 08.09.2022 18:58, Ed Merks wrote:
>
> I've started the respin now.  ETA, hopefully an hour.
>
> On 08.09.2022 17:49, Jonah Graham wrote:
>
> It is fine by me as EPP hasn't even finished the RC2 work - but this
needs planning council approval at this point.
> @Eclipse Planning Council private list can you please weigh in on this.
Particularly Ed who would have to do the work of respinning the SimRel
repo. My vote is +1.
> Thanks,
> Jonah
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
>
> On Thu, 8 Sept 2022 at 11:44, Mickael Istria  wrote:
>>
>> Sorry, again some troubles from m2e & m2e-wtp.
>> There is a critical bug of m2e-wtp that was fixed a few days ago:
https://github.com/eclipse-m2e/m2e-wtp/issues/15 . I've published a 1.5.2
release of m2e-wtp a few minutes ago, and we would like to have this
release included in SimRel 2022-09, basically requiring a respin.
>> The proposed change to SimRel is
https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/195683 ; the
change in m2e-wtp is https://github.com/eclipse-m2e/m2e-wtp/pull/16 .
>> What do you think?
>> --
>> Mickael Istria
>> Eclipse IDE developer, for Red Hat Developers
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
> ___
> eclipse.org-planning-council mailing list
> eclipse.org-planning-coun...@eclipse.org
> To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse.org-planning-council
>

-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat
Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] m2e(-wtp) requesting a SimRel respin

[Mickael Istria]

Sorry, again some troubles from m2e & m2e-wtp.
There is a critical bug of m2e-wtp that was fixed a few days ago:
https://github.com/eclipse-m2e/m2e-wtp/issues/15 . I've published a 1.5.2
release of m2e-wtp a few minutes ago, and we would like to have this
release included in SimRel 2022-09, basically requiring a respin.
The proposed change to SimRel is
https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/195683 ; the
change in m2e-wtp is https://github.com/eclipse-m2e/m2e-wtp/pull/16 .

What do you think?
-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat
Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

Hi Wayne,

m2e has to publish an important bugfix release. So it now contributes 2.0.3
to SimRel:
https://projects.eclipse.org/projects/technology.m2e/releases/2.0.3

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

Re: [cross-project-issues-dev] ACTION REQUIRED: Especially LSP4E (but also Viatra and Papyrus)

[Mickael Istria]

This should now be fixed with
https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/195380
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] ACTION REQUIRED: Especially LSP4E (but also Viatra and Papyrus)

[Mickael Istria]

On Fri, Aug 26, 2022 at 11:02 AM Christian Dietrich <
christian.dietr...@itemis.de> wrote:

> This is long fixed in lsp4e but I don’t know why no new milestone was
> contributed
>

There are no real reasons against it, it just has to be important enough
for someone to report it and for someone (maybe else) to take care of
fixing it.
LSP4E has ongoing change I'd like to see completed before releasing, but
they can wait. I'm going to release TM4E 0.20.7 now.
___
cross-project-issues-dev 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] Scout contribution disabled after m2e update

[Mickael Istria]

Hi all,

I updated SimRel to use new m2e 2.0.1 release. This is a new major version
compared to previously contributed 1.20.1, so some dependency ranges need
to be updated in customers, and probably some code as well.
Scout is currently not compatible, because of a requirement on an older
version of m2e. I had to disable it for the moment.
I recommend Scout maintainers to evaluate migration to m2e 2.0.1 ASAP to
ensure both can participate simultaneously in SimRel.

Cheers,
-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat
Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Action Required: 3rd party bundles changed in Platform

[Mickael Istria]

On Thu, Jul 28, 2022 at 9:32 PM Martin Lippert  wrote:

> Execution default-target-platform of goal
> org.eclipse.tycho:target-platform-configuration:2.7.3:target-platform
> failed: The Maven artifact to be added to the target platform is not stored
> at the required location on disk: required
> "/XXX/.m2/repository/org/junit/jupiter/junit-jupiter-params/5.8.1/junit-jupiter-params-5.8.1.jar"
> but was
> "/XXX/.m2/repository/org/junit/jupiter/junit-jupiter-params/5.8.2/junit-jupiter-params-5.8.2.jar"
>

It depends on you target platform and other things.
I think this should be reported to Tycho, ideally with a minimal
reproducer, and using latest 2.7.4 release) or even better 3.0.0-SNAPSHOT.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] How to name tests for bugs after GitHub move

[Mickael Istria]

On Thu, Jul 28, 2022 at 6:41 PM S A 
wrote:

> Hi all,
>

Hi,

are there guidelines on how to name tests for specific bugs/issues, now
> that the Eclipse code base has mostly moved to GitHub?
>

There is no particular guidelines for test method names. It's up to the
contributor to name the tests as they prefer. If there are concerns,
they're discussed during the reviews; but usually the name of test methods
is not something that is argued.

How do I name tests similarly, referring to GitHub issues?
>

You can name them `TestGitHubIssue1234" or similar.

I specifically want to name the test after the bug, I don't want to
> "invent" a name that tries to summarize the bug in 3-4 words (the JavaDoc
> comment explains the bug).
>

It's also up to you and the reviewers; but usually the other way round is
more productive: test method describe roughly the case and the Javadoc
points to the ticket with details. That allows to more easily understand
what the test is about when it fails without requiring to navigate to the
bug; if tests name and assertions are good enough, the failure is pretty
explicit.

Also what about adding links to GItHub issues in the JacaDoc comment of the
> test? I assume that is OK (though will the links continue to work if/after
> repositories get "merged")?
>

Yes, links are welcome. Merging repositories doesn't make that we delete
the previous ones, they're usually just made read-only, so content is still
accessible.
But in case they're removed, it's a good argument for my suggestion above
that good naming and description in code is more sustainable that relying
in references to external resources. In the end, code is the real
substance, every tool or workflow around is just "decoration" that come and
go according to trends that are usually beyond our control.

HTH
___
cross-project-issues-dev 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] Action Required: 3rd party bundles changed in Platform

[Mickael Istria]

Hi all,

As Eclipse SDK is moving to use "official" upstream libraries from Maven
Central instead of Orbit's ones, some bundles are now using a different
Bundle-SymbolicName so you cannot use Platform p2 repo anymore to get those.
This may cause dependency issues in your project, if you have relied on
3rd-party artifacts being provided in the Eclipse Platform p2 repo.
Remediation is documented at
https://github.com/eclipse-platform/eclipse.platform.common/blob/master/bundles/org.eclipse.platform.doc.isv/porting/4.25/incompatibilities.html
.

Cheers,

-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat
Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] PGP Signing on ci.eclipse.org

[Mickael Istria]

Hi,

I think this should be covered by the info in this document:
https://docs.google.com/document/d/1MnDBvOUwKvKacB-QKnH_PzK88dUlHkjs-D-DWEKmvkY/edit#heading=h.tir6oo3i3el8

HTH
___
cross-project-issues-dev 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 Java IDE 2022-06 video

[Mickael Istria]

Again an excellent one, 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

Re: [cross-project-issues-dev] 2022-06 Participation Page

[Mickael Istria]

On Wednesday, June 8, 2022, Wayne Beaton <
wayne.bea...@eclipse-foundation.org> wrote:
> Is it time for Eclipse LSP4e, Eclipse LSP4j, Eclipse TM4E and Eclipse
Wild Web Developer to graduate?


Yes, but at the moment (and maybe always), some higher priority things are
in my backlog and make those "bureaucracy" tasks are delayed. So anyone who
wants graduation to happen, please state your interest in taking care of
it, that would help a lot!

-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat
Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

Hi,

You may want to report an issue to
https://issues.redhat.com/projects/NEXUS/summary .
HTH
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

Hello,

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

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

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

[Mickael Istria]

Hi,

Do both version end in SimRel? I think the version constraint in Platform
are lax enough to let it use Orbit's version; so SimRel may actually
resolve it to only 1 version. If not and if this can help, we can consider
relaxing constraints in Platform to enable that.

HTH
___
cross-project-issues-dev 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] TM4E planning to start using JavaSE-17 as BREE soon

[Mickael Istria]

On Tue, Apr 19, 2022 at 8:35 PM Torbjorn SVENSSON via
cross-project-issues-dev  wrote:

> Hello,
>

Hi,


> What you are talking about here is more or less requiring anyone using
> SimRel to also move to a JRE 17.


Not directly (SimRel can still use older versions of TM4E), but yes, I
guess it can become the beginning of a trend for many projects and
ultimately SimRel moving to JRE 17.
Downstream projects/products that have different requirements from what
SimRel decides to provide will have to deal with them on their hand, eg
composing versions in their .target.


> I think that's okay to do, but there should be some heads up for this type
> of change as it can cause major problem for our downstream consumers.
>

This is kind of a 1st heads up ;)

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


Eclipse IDE can currently run with JRE 11, but the vast majority of users
now do get JustJ from EPP packages; and that is currently Java 18.

But overall, it is still totally acceptable for some projects to stick to
older Java while some other move to newer.
___
cross-project-issues-dev 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] TM4E planning to start using JavaSE-17 as BREE soon

[Mickael Istria]

Thanks a lot Martin, it's indeed an annoyance.

Is specifying a (older) Gradle version on project a common practice? How
does it work in CLI if one uses a newer Gradle install to run some build
that defines an older Gradle version?
What are the chances that this bug gets fixed soon enough? (I'm going to
ask on the bug as well and link to the discussion).
___
cross-project-issues-dev 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] [tm4e-dev] TM4E planning to start using JavaSE-17 as BREE soon

[Mickael Istria]

On Tue, Apr 19, 2022 at 4:38 PM Jonah Graham  wrote:

> PS Where is "SimRel targets Java 11" defined? Is it just implicit at the
> moment (because Eclipse Platform is Java 11), or is it explicit somewhere?
>

Good question. It's more something that seems to me as an ad-hoc rule; but
maybe I'm just over-interpreting. Anyway, the goal is more to raise
awareness, we won't change the SimRel contribution to require JavaSE-17
immediately. It's just to clarify that support for older versions of TM4E
that use JavaSE-11 as BREE is likely to disappear soon and project that
depend on it may find it interesting for their own planning.
Also, if we can have an agreement to have JavaSE-17 requirement in SimRel
2022-06, we'll for sure welcome it and do the move & release ASAP so it
gets included in SimRel early May; but if not, we may delay a bit the
release. Overall, for TM4E, the sooner we can release with JavaSE-17
requirement, the better; but we're not in despair and can arrange things a
bit to better fit other constraints.
___
cross-project-issues-dev 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] TM4E planning to start using JavaSE-17 as BREE soon

[Mickael Istria]

Hi all,

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

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

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

Cheers,

-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat
Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [ide-dev] Eclipse Java IDE 2022-03 video

[Mickael Istria]

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

Re: [cross-project-issues-dev] Eclipse IDE 2022-03 participation

[Mickael Istria]

Hi,

Wild Web Developer 0.13.3 is part of SimRel (for a relatively long time
already, so no extra things like respins to worry about). Can the 2022-03
metadata please be changed accordingly?

Thanks in advance
___
cross-project-issues-dev 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] Introduction to the new mixed-reactor-build feature and improved PDE/m2e support

[Mickael Istria]

Hi Christoph,

Thanks for sharing. Ability to mix felix, bnd and Tycho in a Maven builds
can really make many things much easier!
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

LemMinX-Maven was fixed to be compatible with Maven 3.8.3 to 3.8.5, m2e was
tested as working fine with this patch.
The only remaining thing to verify is Tycho.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

Seems like Maven 3.8.5 candidate causes major issue with Tycho
"""
Plugin org.eclipse.tycho:tycho-maven-plugin:3.0.0-SNAPSHOT or one of its
dependencies could not be resolved: The following artifacts could not be
resolved: org.codehaus.plexus:plexus-archiver:jar:4.2.7,
org.codehaus.plexus:plexus-interpolation:jar:1.26,
org.codehaus.plexus:plexus-cipher:jar:2.0,
org.eclipse.platform:org.eclipse.osgi:jar:3.17.100,
de.pdark:decentxml:jar:1.4, org.codehaus.plexus:plexus-utils:jar:3.4.1,
org.codehaus.plexus:plexus-component-annotations:jar:2.1.1:
org.codehaus.plexus:plexus-archiver:jar:4.2.7 was not found in ...
""",
causes m2e integration of LemMinX-Maven to fail, most likely because
LemMinX-Maven fails  itself
"""
[ERROR]
/home/jenkins/agent/workspace/LemMinX-Maven_PR-282-head/lemminx-maven/src/main/java/org/eclipse/lemminx/extensions/maven/ModelValidatorMNG7170.java:[17,8]
constructor DefaultModelValidator in class
org.apache.maven.model.validation.DefaultModelValidator cannot be applied
to given types;
  required: org.apache.maven.model.interpolation.ModelVersionProcessor
  found: no arguments
  reason: actual and formal argument lists differ in length
"""

I'm investigating whether a backward compatible change can be implemented.
If not, then it means Maven has an API breakage which should be a reason
why we could vote -1 for this release.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

Hi Christoph,

Thanks for the notification. Some important PR/jobs to look at for Eclipse
ecosystem to provide a minimal validation of upcoming Maven releases are
* m2e: https://github.com/eclipse-m2e/m2e-core/pull/602
* Tycho: https://ci.eclipse.org/tycho/job/tycho-build-with-maven-snapshots/

Issues on those jobs should be investigated. If those can be properly fixed
on project side and then build/tests pass, then we can vote +1 for this
Maven release; if some new bugs are shown and analysis indicates they are
really Maven bugs, then projects should vote -1 for this Maven release.
Regressions with Maven are quite frequent, so it's safer to assume that
there is probably a bug by default ;)
___
cross-project-issues-dev 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 Blogging

[Mickael Istria]

On Thu, Feb 17, 2022 at 3:49 PM Wim Jongman  wrote:

> Dude, lighten up. You talk about the EF webmasters and the infra like they
> are about to die.
>

I was 1 year in the board of EF as committer representative. It was
moreover a bad year (they happen) with bad consequences for some EF
services and employees. I've learned there that always asking EF for more
is not really in the best interest of the community and that the community
always expecting more is not a realistic long-term solution. Whatever the
community can do well without involving Foundation staff or resources is
actually helping both EF to keep focused on its main goals and services,
and also helping community into evolving its solutions freely as needed
without intermediary discussion/governance.
___
cross-project-issues-dev 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 Blogging

[Mickael Istria]

On Thu, Feb 17, 2022 at 12:15 PM Wim Jongman  wrote:

> Having our own blogging server would make sure that useful blogs are
> archived forever, and it is organized and searchable from one place.
>

Define "our" ;)
The issue with asking Foundation for more services is that -with limited
manpower- it reduces the quality of services on existing services. So if
the blog platform introduce a reduction of quality about the CI or GitHub
integration, adding a few more hours of delays for each answer, then it's
definitely not something profitable to the community. If the blog platform
has very low SLA, so low that its issues are never prioritized and it's
always failing, then it means it will be itself of bad quality, often
failing, never evolving, and will become a dead service very soon.
Also, many people will still fairly prefer to publish to their own blog, to
boost their company or personal branding in the ecosystem, allowing them
more opportunities. So I don't think many people will want to sue such a
common platform.
Realistically, I don't think this is in the best interest of the community
to ask it from EF.

If you want to write blog posts without subscribing to a service, maybe get
in touch with vogella, I believe they can sometimes host some
Eclipse-related blog articles.

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

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

[Mickael Istria]

On Sunday, January 16, 2022, Lorenzo Bettini 
wrote:
> So the limitations (not failing because of missing dependencies) of Tycho
mirror are real (I seem to understand they come from the eclipse mirror
application on which it's built).

Yes.

-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat
Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

On Saturday, January 15, 2022, Lorenzo Bettini 
wrote:
> Mickael, IIRC your proposal was based on Tycho mirror goal

Nope, except for exceptions. See
https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/170553/14/pom.xml

-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat
Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

On Fri, Jan 14, 2022 at 9:50 AM Christoph Läubrich 
wrote:

> If Tycho is used
>

I tried for a long time to migrate SimRel from p2 aggregator (which is a
technology very few are capable of using, much fewer are capable of
maintaining, and much even fewer -if any- is willing to maintain) to Tycho
and provided a full migration path and even a fully output of this
migration path that was building a repo that was equivalent to SimRel.
There were some quirks and attention got focused on those quirks without
anyone really trying to be constructive on helping to fix them, and some
vocal consumers were afraid of this change being a burden for for them as
they're not willing to change at all (
https://www.astroarch.com/tvp_strategy/no-thanks-busy-pay-back-technical-debt-40188/
); in the end, I gave up because of more energy spent by anti-change camp
than I wanted to spend on this migration.
Let's hope that will change some day; but I personally can't be that
optimistic any more.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

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

> I guess I'm trying to determine if there are any versions of Eclipse,
> Jetty, jGit, etc that are vulnerable.
>

Eclipse Platform, and its transitive deps (including some parts of Jetty),
do not require nor ship log4j.
EGit does include log4j 1.2.15 as optional requirement; so it seems safe.
Wild Web Developer, and its transitive deps (including LSP4E, LSP4J, some
parts of EGit...), do not require nor ship log4j.
m2e, and its transitive deps, do not require not ship log4j
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [eclipse-ide-wg] Eclipse Java IDE 2021-12 video

[Mickael Istria]

As usual, it's a great resource. Thanks!
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Fwd: [eclipse-ide-wg] Paper on Impact of Eclipse SimRel Cadence on Bug Fixing

[Mickael Istria]

-- Forwarded message -
From: Mike Milinkovich 
Date: Thu, Dec 2, 2021 at 9:31 PM
Subject: [eclipse-ide-wg] Paper on Impact of Eclipse SimRel Cadence on Bug
Fixing
To: Discussions on Eclipse IDE Working Group 


All,

I thought some here might be interested in this paper: On the impact of
release policies on bug handling activity: A case study of Eclipse
<https://hal.inria.fr/hal-03035765>

*Abstract *: Large software projects follow a continuous development
process with regular releases during which bugs are handled. In recent
years, many software projects shifted to rapid releases that reduce
time-to-market and claim a faster delivery of fixed issues, but also have a
shorter period to address bugs. To better understand the impact of rapid
releases on bug handling activity, we empirically analyse successive
releases of the Eclipse Core projects, focusing on the bug handling rates
and durations as well as the feature freeze period. We study the impact of
Eclipse's transition from a yearly to quarterly release cycle. We confirm
our findings through feedback received from five Eclipse Core maintainers.
Among others, our results reveal that Eclipse's bug handling process is
becoming more stable over time, with a decreasing number of reported bugs
before releases, an increasing bug fixing rate and an increasingly balanced
bug handling workload before and after releases. The transition to a
quarterly release cycle continued to improve bug handling. In addition,
more effort is spent on bug fixing during the feature freeze period, while
the bug handling rates do not differ between both periods.

-- 

*Mike Milinkovich*

*Executive Director | **Eclipse Foundation AISBL*

Twitter:@mmilinkov


--
[image: Avast logo] <https://www.avast.com/antivirus>

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

<#m_-3615560805540916629_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
eclipse-ide-wg mailing list
eclipse-ide...@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://www.eclipse.org/mailman/listinfo/eclipse-ide-wg


-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat
Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

Hi,

TM4E contributes 0.4.3 (released and added to SimRel earlier today).
LSP4E will most likely contribute a 0.20.1 and m2e a 1.19.0. Both are
supposed to get released next week.

Cheers,

-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat
Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Connection reset when accessing the JBoss Public Nexus

[Mickael Istria]

Hi,

What can be done?
>

Stop depending on repositories which don't have SLAs that fits your project
;)
I sincerely recommend you consider stopping usage of the
org.jboss.tools.tycho-plugins stuff, they're very old, not so well
maintained and the most interesting ones have been workarounds for features
that are now better incorporated directly in the download.eclipse.org infra
(eg browsing repositories, note about how to install), or in Tycho (eg
repository-reference).

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

Re: [cross-project-issues-dev] The Eclipse IDE 2021-09 release is available now!

[Mickael Istria]

Thanks all!

Here are the known social media resources/discussions you may want to
share/upvote/discuss:
Tweet: https://twitter.com/EclipseJavaIDE/status/1438152934278238211
Reddit:
* https://www.reddit.com/r/java/comments/por5ko/eclipse_421_available/
* https://www.reddit.com/r/java/comments/por47h/eclipse_202109421_released/
*
https://www.reddit.com/r/programming/comments/por4oe/eclipse_202109421_released/
Youtube: https://www.youtube.com/watch?v=_OkIpz__Fyk

Please share other secial media resources you may know about this release.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [eclipse-ide-wg] Eclipse 2021-09 video

[Mickael Istria]

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

Re: [cross-project-issues-dev] Eclipse IDE 2021-09 Simultaneous Release Participation

[Mickael Istria]

M2e contributes 1.18.1 to SimRel:
https://projects.eclipse.org/projects/technology.m2e/releases/1.18.1

Thanks Holger and Jonah for noticing and fixing this contribution, together
with Wild Web Developer.

-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/eclipseide> developer, for Red Hat
Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, 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?

[Mickael Istria]

On Mon, Jul 5, 2021 at 3:39 PM Jörg Kubitz  "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.


Actually, neither BREE or osgi.ee requirement do guarantee anything about
EE APIs, they mostly only guarantee execution of execution level and .class
version support. Import-Package should be used to build guarantees about
APIs, but here as well, the package grain may be too coarse and cases of
just 1 method removal remain hard to capture.
Setting a max version requires a lot of effort to go to newer versions (all
MANIFEST.MF need to be modified!), we should avoid it and just keep
optimistic, otherwise each release of Java would be even more expansive to
adopt.
___
cross-project-issues-dev 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] The Eclipse IDE 2021-06 release is available now!

[Mickael Istria]

Thanks all!
Tweeted https://twitter.com/EclipseJavaIDE/status/1405165811803856899
___
cross-project-issues-dev 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] [ide-dev] Eclipse 2021-06 video

[Mickael Istria]

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

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

[Mickael Istria]

On Thursday, June 3, 2021, Matthias Sohn  wrote:
> you can create a patch in Gerrit from a web browser, see
https://git.eclipse.org/r/Documentation/user-inline-edit.html


Thanks for the tip!

-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

On Thu, Jun 3, 2021 at 7:01 PM Jonah Graham  wrote:

> Can we respin 2021-06 RC1 to include m2e 1.18.0? If so, that would be my
> vote. Based on your message about laptop this seems unlikely?
>

I just published m2e 1.18.0 release from current master. It's available at
https://download.eclipse.org/technology/m2e/releases/1.18.0/ . I won't be
able to take care of updating the m2e.aggrcon file soon as I don't have Git
nearby and I'm not aware of a way to contribute a patch via Gerrit from a
web browser. So it would be great if you could take care of updating this
m2e.aggrcon file, submitting the patch to validate it, merge and so on.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

Hi all,

As mentioned in another thread, m2e has an important bug with Platform 4.20
and SLF4J 2.0, causing build output to not appear in the console. This
issue is fixed in m2e and we can try releasing m2e 1.18.0 for SimRel
2021-06.
However there are a lot of other changes in m2e 1.18.0 compared to m2e
1.17.2 which is currently in SimRel (
https://github.com/eclipse-m2e/m2e-core/compare/1.17.2...master ); so this
is not necessarily a trivial change and can be risky. But m2e has an
extensive test suite which IMO makes it relatively safe to adopt m2e.
So 2 solutions:
* Either we keep m2e 1.17.2 in 2021-06 with the bug and just tell people
who face it to update to m2e 1.18.0, or
* we rush a m2e 1.18.0 in 2021-06, which can be a source of quirks in the
release process (especially since my work laptop just died so I'm not going
to be very efficient at it)

Cheers,

-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Restricting bugzilla issues creation/edition?

[Mickael Istria]

@Denis and Infra team: can such restrictions be setup on Eclipse Bugzilla
instance? If so, I guess it's only a matter of opening a bug when project
is ready to migrate, isn't it?

On Fri, Mar 19, 2021 at 9:42 AM Mickael Istria  wrote:

> [...]
> One approach would be to make the BZ tracker progressively "read-only", or
> at least to prevent from creating new issues.
> For a given product, is it possible to prevent creation of new issues? Is
> it possible to block creation of issues while keeping edition access on
> existing issues? Is it possible to make the product issues "read-only" (no
> creation, no edition)? All that without removing the product backlog.
> My favorite one at the moment would be to block creation of new issues but
> still allow 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

Re: [cross-project-issues-dev] Restricting bugzilla issues creation/edition?

[Mickael Istria]

On Fri, Mar 19, 2021 at 10:28 AM Rolf Theunissen 
wrote:

> RTFM:
> https://bugzilla.readthedocs.io/en/5.0/administering/categorization.html#basic-product-group-restriction
> Based on group permissions it is controlled who can enter, edit, read,
> etc., on a product granularity,  So it should be possible to disable
> create, while remain edit rights.
> (Sorry to be blund, but manuals do have value although engineers tend to
> just ignore them)
>

OK, so it's technically possible for Bugzilla in general. As I'm not a
Bugzilla admin, I'm more curious about whether it's something EMO
Infrastructure team can set up on bugs.eclipse.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] Restricting bugzilla issues creation/edition?

[Mickael Istria]

Hi all,

I'm brainstorming about how to have a complete the migration to GitHub for
some projects (eg m2e, Tycho...). Currently, the main pain point would be
the bug tracker: the backlog on Bugzilla is huge and migrating it to GitHub
wouldn't be very relevant, but this backlog needs to remain accessible.
One approach would be to make the BZ tracker progressively "read-only", or
at least to prevent from creating new issues.
For a given product, is it possible to prevent creation of new issues? Is
it possible to block creation of issues while keeping edition access on
existing issues? Is it possible to make the product issues "read-only" (no
creation, no edition)?
My favorite one at the moment would be to block creation of new issues but
still allow edition.

Thanks in advance for your insights.

-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] The Eclipse IDE 2021-03 release is available now!

[Mickael Istria]

And some (longer) discussion on hackernews:
https://news.ycombinator.com/item?id=26494952
___
cross-project-issues-dev 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] The Eclipse IDE 2021-03 release is available now!

[Mickael Istria]

Here is a tweet:
https://twitter.com/EclipseJavaIDE/status/1372196630200455170 and some
Reddit discussions:
*
https://www.reddit.com/r/java/comments/lxlxiw/many_new_java_cleanups_in_eclipse_202103419/
*
https://www.reddit.com/r/programming/comments/m72kpa/eclipse_ide_202103_is_released/
*
https://www.reddit.com/r/java/comments/m72jcn/eclipse_ide_202103_is_released/

On Wed, Mar 17, 2021 at 3:00 PM Frederic Gurr <
frederic.g...@eclipse-foundation.org> wrote:

> The main repository is at
>
> => http://download.eclipse.org/releases/2021-03/
>
> (http://download.eclipse.org/releases/latest also points to it)
>
> The EPP (all-in-one) packages are available at
>
> => https://www.eclipse.org/downloads/eclipse-packages/
>
> The landing page can be found here:
>
> => https://www.eclipse.org/eclipseide/2021-03/
>
> Thanks to all users, bug reporters, contributors, committers, releng
> engineers and everyone else involved with making this release possible!
>
> Enjoy the spring and stay healthy!
>
> 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
>


-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] [ide-dev] Eclipse 2021-03 video

[Mickael Istria]

Thanks Holger!
___
cross-project-issues-dev 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] The "new user -> ECA -> signed-off by" workflow is broken

[Mickael Istria]

On Thu, Mar 4, 2021 at 2:52 PM Wim Jongman  wrote:

> We lose 99% of our casual contributors.
>

That's a huge exaggeration ;) But thanks for bringing attention on this
important topic!

I agree the "Signed-Off-By" is becoming a point of friction and making the
contribution barrier higher than for many other projects.
I went through https://www.eclipse.org/projects/dev_process/ for a
reference about Signed-Off-By and couldn't see anything on that matter. So
it seems to me Signed-Off-By is not an actual requirement of the EDP. So we
should seek for less intrusive way to get contributors agreeing with ECA
and automating this check, for example doing the exact same things as is
currently done, but with the committer email address directly.
I've added Architecture Council as CC to handle that discussion as it may
relate to the implementation of the EDP.

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

Re: [cross-project-issues-dev] winning configuration for compare-version-with-baselines

[Mickael Istria]

Hi,

Please bring this question to tycho-u...@eclipse.org mailing-list

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

[cross-project-issues-dev] 1-liner "Clone to Eclipse" badge for GitHub repositories

[Mickael Istria]

Hi all,

If you have a project under some GitHub repository, you can easily add a
"Clone to GitHub" badge that will start the Eclipse IDE and show the Git
clone dialog after a few dummy clicks (necessary for security purpose).
See https://github.com/mickaelistria/redirctToEclipseIDECloneCommand for
the 1-liner to add to your README files.

As a reminder, this is purely usage of the protocol handlers capabiltiies
of Eclipse Platform (
https://help.eclipse.org/2020-12/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Freference%2Fref-linkhandlersprefs.htm
). You can easily add your own protocol handlers for your integrations; the
gain on usability is huge as this allow more straightforward workflows.
The only tweak with GitHub is that it doesn't allow other links than http://
and https:// so a redirection service is necessary.

Cheers,
-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse IDE 2021-03 Simultaneous Release Participation

[Mickael Istria]

Hi Wayne,

I created new (empty at the moment) release entries for projects that will
have a new release to include in SimRel 2021-03 between now and March 17th.
At the moment, I did set the date to March 17th, but some of them will
probably be released sooner. I'll adapt the entries accordingly.
* https://projects.eclipse.org/projects/technology.lsp4e/releases/0.18.0
*
https://projects.eclipse.org/projects/tools.wildwebdeveloper/releases/0.11.5
* https://projects.eclipse.org/projects/technology.m2e/releases/1.17.2

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

Re: [cross-project-issues-dev] [epp-dev] Does SimRel need to include EPP site (circular dependency)?

[Mickael Istria]

>
> Firstly because in these corona times, it seems involvement is lower than
> normal.  And secondly because when ship a next release we want people to be
> able to update to it, so the question of whether EPP's sites will be found
> by existing 2020-12 installations is relevant.  These installations point
> at https://download.eclipse.org/releases/latest which should therefore
> continue to compose the EPP updates.
>
> So again, I can only recommend caution and consideration before we
> redesign the whole system on whims and assumptions.
>

Thanks, you're right, it's not something we can change from 1 release to
the other.
So a 1st iteration is to add the EPP latest site to EPP packages, and
release with them; and later, we can then consider removing the composite
reference from SimRel to EPP.
___
cross-project-issues-dev 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] Does SimRel need to include EPP site (circular dependency)?

[Mickael Istria]

> I thought Jonah was solving this problem and already has a "fix" for it?

I think he's solving 1 instance of this problem, but not the whole class.
And the fix has some drawbacks (eg more p2 repositories necessary to
install certain packages).

On Thu, Feb 4, 2021 at 1:58 PM Ed Merks  wrote:

> The whole community currently uses things like
> https://download.eclipse.org/releases/latest/ for one stop shopping for
> updates.   Surely changing that is not a good solution to an
> internal/interim releng issue.
>

The repo would still be present in EPP, it's just that this wouldn't
contain the EPP artifacts anymore which would be in a separate repository
(eg https://download.eclipse.org/technology/epp/packages/latest/ ) enabled
in EPP by default. So Check for Updates from EPP packages would still work
and EPP could more easily include non-SimRel-repo artifacts like JustJ.
___
cross-project-issues-dev 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] Does SimRel need to include EPP site (circular dependency)?

[Mickael Istria]

Hi all,

There are some changes going on on the EPP side to deal with some troubles
of viisble sites or not.

The fundamental issue is that EPP is downstream of SimRel, and it adds some
extra content that are not in SimRel site (JustJ specifically). EPP
publishes a site that we want to work for product updates and installer;
while the EPP site is then composited into SimRel, so the extra content
from EPP -that may not be desirable for SimRel- now become visible to
SimRel while not really desirable for consumers of SimRel (eg RCP product
developers).

My proposal to make all that simple would be to simply remove the EPP site
as a composite of SimRel; and instead add in the EPP packages and installer
a direct reference to the EPP site additionally to SimRel.
With that, we get a more proper separation and I don't think we'd lose
anything in term of usability.

So the big question is: would it hurt if we stop SimRel referencing EPP
site?

Cheers


-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

This also prevents from shipping the PDE/Maven integration by default in
packages because it contains BND artifact (unmodified from Maven) that is
not signed with the Eclipse certificate.
___
cross-project-issues-dev 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

[Mickael Istria]

[cross-posted to epp-dev mailing-list]
Hi,

That means that the "Eclipse IDE for Rust developers" package should not
appear on the https://www.eclipse.org/downloads/packages/ page. To be
honest, it's not a big deal, I'll adjust links from Corrosion README so
they point to the internal EPP download area. So if you wish to proceed
with removal now, feel free.

The parts about signing are more a reminder of current rules, so no impact
here. However as Alexander mentioned, I think it's worth exploring
alternative approaches to signing if we want to innovate faster. The whole
world, including the majority of active Eclipse Foundation projects, except
Eclipse SimRel participant, manage to go round without jarsigner. If we
want SimRel to remain in touch with this world, able to consume new APIs
and so on more easily, in the continuation of all efforts done to improve
3rd-party approval from IP perspective, we need to find a more efficient
way to deal with external artifacts that are unsigned. Orbit doesn't go
fast enough anymore...

On Fri, Jan 22, 2021 at 4: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 <https://www.eclipse.org/downloads/packages/> 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.
>
> 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
>


-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, 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

[Mickael Istria]

On Fri, Jan 15, 2021 at 11:57 AM Frederic Gurr <
frederic.g...@eclipse-foundation.org> wrote:

> On 15.01.21 07:22, Aleksandar Kurtakov wrote:
> > 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.
>
> I will put something in place that breaks the build when jars are
> unsigned. We should be able to expand this rather quickly to other
> issues as well


IIRC, the CBI repo analyzer, that got somehow abandoned in favor of Oomph
analyzer, were able to fail the build for some class of errors
https://wiki.eclipse.org/CBI/p2repoAnalyzers/Repo_Reports#With_Maven
___
cross-project-issues-dev 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

[Mickael Istria]

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

> how are they IP reviewed if they've been pulled straight from some Maven
> repository somewhere?
>

Just like adding any 3rd-party jar to the dependencies, projects will still
have to verify *themselves* (ie not by delegating work to Orbit) that what
they intend to ship is conform to IP requirements (eg check with the
dash-license tool and/or open CQs).
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

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 <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] The Eclipse IDE 2020-12 release is available now!

[Mickael Istria]

Thanks all! Here is a tweet about it:
https://twitter.com/EclipseJavaIDE/status/1339255844316327939
Some Reddit posts:
https://www.reddit.com/r/java/comments/keaniu/eclipse_2020124180_released/
and
https://www.reddit.com/r/programming/comments/keant6/eclipse_2020124180_released/
___
cross-project-issues-dev 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] [ide-dev] Eclipse 2020-12 video

[Mickael Istria]

Thanks for this video Holger, great as usual!
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Problem with SimRel Validation Builds

[Mickael Istria]

Hi,

Can't we restore the previous CI, disable staging, and get back to this
work when there is less risk associated with it? After SimRel release seem
like a safer, easier and less stressful time to deal with that migration.


On Tuesday, December 8, 2020, Jonah Graham  wrote:
> Hi Fred,
> The staging repo is broken. The root files are there, but the
subdirectories (e.g. plugins) are empty. Is the staging-ci version
conflicting with the main ci one? There hasn't been a successful main ci
build since RC2 period started.
> A few other things on this subject:
> - the ci-staging is triggering EPP builds. I don't think that should
happen until the migration is done.
> - the ci-staging seems to be stuck re-running the build despite no
changes. The last few builds all have the same trigger and pair of git
repos.
> - the normal ci build seems to be failing in the post build steps only
> - is there a bugzilla or similar to subscribe to on the simrel jiro
migration?
> Thanks
> Jonah
>
>
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
>
> On Mon, 7 Dec 2020 at 05:11, Frederic Gurr <
frederic.g...@eclipse-foundation.org> wrote:
>>
>> Hi,
>>
>> Sravan is correct. I should have disabled the
>> simrel.runaggregator.VALIDATE.gerrit job (which I did on Sunday after
>> the error reports).
>>
>> Sorry for the noise.
>>
>> Regards,
>>
>> Fred
>>
>> On 06.12.20 08:30, Sravan K Lakkimsetti wrote:
>> > Looks like Fred is migrating Simrel project to JIRO. Please ignore
>> > ci-staging path. This patch did not put a -1 on the gerrit patch for me
>> > yesterday.
>> >
>> >
>> >
>> > Thanks
>> >
>> > Sravan
>> >
>> >
>> >
>> > *From:*Ed Merks 
>> > *Sent:* 06 December 2020 11:13
>> > *To:* Cross project issues 
>> > *Subject:* [EXTERNAL] [cross-project-issues-dev] Problem with SimRel
>> > Validation Builds
>> >
>> >
>> >
>> > Hi,
>> >
>> > SimRel validation builds like this are failing:
>> >
>> >
https://ci-staging.eclipse.org/simrel/job/simrel.runaggregator.VALIDATE.gerrit/1904/console
>> >
>> > I think this is the problem:
>> >
>> > *06:24:12* No JDK named ‘jdk11-latest’ found
>> >
>> > Then it uses Java 8:
>> >
>> > *06:24:24* Java version: 1.8.0_262, vendor: Eclipse OpenJ9, runtime:
/opt/java/openjdk/jre
>> >
>> > But Java 8 doesn't work:
>> >
>> > *06:24:40* Caused by: java.lang.UnsupportedClassVersionError:
JVMCFRE003 bad major version;
class=org/eclipse/tycho/extras/eclipserun/EclipseRunMojo, offset=6
>> >
>> > How did JDK 11 disappear and how do we get it back?
>> >
>> > I opened the following:
>> >
>> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=569506
>> >
>> > Regards,
>> > Ed
>> >
>> >
>> >
>> >
>> >
>> > ___
>> > cross-project-issues-dev mailing list
>> > cross-project-issues-dev@eclipse.org
>> > To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>> >
>>
>> --
>> Frederic Gurr
>> Release Engineer | Eclipse Foundation Europe GmbH
>>
>> Annastr. 46, D-64673 Zwingenberg
>> Handelsregister: Darmstadt HRB 92821
>> Managing Directors: Gaël Blondelle, Mike Milinkovich
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>

-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, 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

[Mickael Istria]

Hi all,

I've updated
https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/170553 so it
looks more like a "final" change (although it's based on an older commit,
so the files would need to be updated/regenerated before we can consider
merging). It covers most concerns I've read here, and I've put in
CONTRIBUTING.md some more information about how this is to be used by
contributing projects + some additional gap analysis notes.

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

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

[Mickael Istria]

On Fri, Nov 27, 2020 at 10:47 AM Eike Stepper  wrote:

> Would our current *.aggrcon files be migrated to the new format for us?


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

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

[Mickael Istria]

Hi,
Wild Web Developer will attempt to release a 0.11.4 for SimRel 2020-12:
https://projects.eclipse.org/projects/tools.wildwebdeveloper/releases/0.11.4
m2e will attempt to release a 1.17.0 for SimRel 2020-12:
https://projects.eclipse.org/projects/technology.m2e/releases/1.17.0
Cheers,
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

On Fri, Nov 27, 2020 at 9:54 AM Ed Merks  wrote:

> There is a big size difference between the *.jar versus the *.xml.xz,
> especially for the content.jar/content.xml.xz:
> https://download.eclipse.org/justj/?file=releases/2020-12/202011271000
> We'd not want to lose that I think, because this has a significant impact
> on the server traffic...
>
OK, I'll investigate that. I'm confident we can easily have .xz back in a
way or another.

> Because of that separation, goodness knows if what think I contribute will
> really come from my repo and not some other repo. [...] E.g., when I
> contribute Oomph, I *do not *contribute the http client bundles (as an
> example).  I do it that way so that I don't contribute conflicting or older
> versions of those things.
>
If I'm not mistaken, current aggregator has never guaranteed anything about
provenance and does some dependency resolution against *all* repos already.
I'll work on an example to prove me wrong or false and report the results
and example. That will either strengthen or invalidate this argument.

> But what stops the Tycho resolution mechanism from grabbing potentially
> older the ones from the Oomph repository anyway?  Nothing I think...
>
Nothing indeed, unless some other requirements enforces a specific version
of the artifact in its dependency chain. But as mentioned, I believe it's
the same for current aggregator already. More details to come next week.

> I also wonder too if the two different implementations (resolution
> algorithms) use to build the repositories really do actually produce the
> same repositories?
>
 They're both relying on p2 director so there shouldn't be a too big
difference; but we'll diff the output.

> The Planning Council ought to speak out and the simrel participant
> opinions (if any one has one!), ought to be considered too.
>
I agree. However, I think there are still technical questions that need an
answer before we require Planning Council to voice an opinion.
___
cross-project-issues-dev 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

[Mickael Istria]

Thanks for having a look Fred.

On Thu, Nov 26, 2020 at 8:58 PM Frederic Gurr <
frederic.g...@eclipse-foundation.org> wrote:

> * is there a good reason why the pom.xml has been moved to a module
> instead of keeping it in the root pom.xml/directory?
>

No, I just wanted to keep all files in the repo without removing anything;
but it's not necessary. The pom.xml/category.xm can totally be in the root
folder.

* can you give some insight what "remove-xz"


remove-xz removes the .xz files from the p2 repo because we manually edit
the p2 repo with remove-uncategorized and this manual edition seems to fail
at updating the .xz files (but works for .xml and .jar files).


> and "add-aliens" do or why they are necessary?
>

The units part of "add-aliens" are the ones that are not in the main
validationSet of SimRel. Those units can basically not be installed
together with SimRel, they'd make the dependency resolution fail. To me,
they'd better be out of SimRel and instead the RAP tools should take care
of providing a proper target-platform skeleton to work with, referencing
the necessary repos. However they're here at the moment; so the add-aliens
adds them to the repo using a way that doesn't check compatibility with
other units, so that it doesn't fail.

* how did you create the category.xml file? (side note: I opened the
> category.xml file with the category.xml-editor and the opening alone
> re-wrote/re-formated the whole file.)
>

Using the action in CBI aggregator to generate Tycho build from .aggr file.

* According to the comment, the list of repositories in the pom.xml file
> was generated with the CBI aggregator tool. Was that only necessary for
> the initial list?


Yes.


> What would a new project need to add and where? Only
> add bundle/feature to the category.xml and add the repository to the
> pom.xml?
>

Exactly.

* is there still a way to only validate changes like the "validate" profile?
>

Yes, this is new in Tycho and is what triggered that thread. `mvn validate`
does that.

If we want to switch to Tycho for the 2020-03 release, we will need to
> put some documentation in place for existing and new users what needs to
> be changed and done.


Sure. I'll add comments to the pom.xml for your previous questions and a
CONTRIBUTING.md to explain how to add/modify content; and will create a new
patch set that removes the aggr stuff and put the Tycho-based aggregator at
the root. But not before Tuesday.

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

[cross-project-issues-dev] How can I receive daily digest of all new Bugzilla tickets for project?

[Mickael Istria]

Hi,

I'd like to configure Bugzilla in a way that for some projects, I receive
every day a list of the new bugs that were open to them.
I went through Bugzilla settings and didn't find anything obvious. Did I
miss anything? Is that already doable or something impossible with Bugzilla?

Thanks in advance

-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

On Tue, Nov 10, 2020 at 5:21 PM Jonah Graham  wrote:

> - The gerrit today only has a subset of the parts of CDT that are in
> simrel.aggr/cdt.aggrcom (the only contribution I looked at closely). AFAICT
> only the items that are categorized are present in category.xml. Where do
> uncategorized features end up? Similar question about uncategorized
> bundles. I could add them all to a new category if needed.
>

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

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

[Mickael Istria]

On Wed, Nov 11, 2020 at 10:06 AM Christoph Läubrich 
wrote:

> So it does not really fix anything in the file itself?


It's better if it modifies the file directly IMO.


> Currently, if tycho can't resolve it simply fails with: "can't resolve
> because missing requirement XYZ and so on"
> It would be really useful (and might solve the issue for simrel also) if
> we can add some pice of code that emits if there is an alternative
> version or no version at all for the missing requirement, eclipse (or
> P2?) even computes "alternative solutions", maybe this feature can be
> reused to give the required hints.


p2 already has such features to compute remediations; but it's long to
process and requires some user decision. IMO it does not fit well in what
we expect as a build tool.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

On Wed, Nov 11, 2020 at 9:00 AM Christoph Läubrich 
wrote:

> As I'm currently working on category.xml adding support for source
> features/bundles if someone can explain what exactly this "fix versions"
> does I can investigate if it is possible to be added to tycho.
>

Fix version will fix the version of the features in category.xml according
to p2 repos. Eg for each feature in category.xml, it would verify the
feature for the given version is available in the p2 repos (target
platform), and if not, it would suggest a change to make.
This is similar and a slight variation of
https://github.com/jbosstools/jbosstools-maven-plugins/blob/master/tycho-plugins/target-platform-utils/src/main/java/org/jboss/tools/tycho/targets/FixVersionsMojo.java
which enables some similar feature for .target file (however it also
replaced 0.0.0, which is not desired here); so it's technically totally
doable.

Tycho has already a version-updater for bundles/features so one for
> category.xml seems valid for me.
>

It's a bit different, as it's about fixing the content of the file. Not
sure we're talking about the same thing here.

Another area I'm currently investigating is creating an update-site of
> everything in the current reactor build so category.xml is generated
> automatically, not sure if this is applicable/useful for simrel as well.
>

Nope, SimRel just takes as input the p2 repos and a category.xml to create
a new p2 repo aggregating content. There is nothing else built in the same
reactor.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

Hello Jonah,

Thanks for having a look, answer inline


On Tue, Nov 10, 2020 at 5:21 PM Jonah Graham 
wrote:

>   1. Merge conflicts - this is probably not such a big deal as the tycho
> validation seems very fast (2 minutes!).
>

I think the case of merge conflicts are almost non-existent for SimRel:
projects typically modify a few lines, or add a few lines, which are
independent from others. Git or even plain diff would be able to merge the
various change without pain.


>   2. Tracking who is paying attention. Until now the rule was touch the
> .aggrcon file, which then was easy to identify with git log. Is this rule
> important going forward? I believe so, and if so can we agree on a simple
> standard for what this looks like? e.g. The  of the repository in the
> pom.xml should have the simrel version that it was contributed for in the
> id?
>

We can indeed set up some new convention in the pom.xml file, either with
id, or with some comment convention such as  to be replaced by  and make the inactive contribution tool report the url of
repo for which is just after a "Not there yet" line.


> - Updating version number ranges. The b3 aggregator has a very useful "fix
> versions" action that can set all the version ranges quickly and
> accurately. Is there some way to make this easier with Tycho?
>

There is no such tool for Tycho/category.xml at the moment; and I think
it's mostly a use-case that is related by some existing PDE and m2e
(requiring a lot of work though). One alternative would be to implement a
SimRel/Tycho specific tool; that would be more affordable. I'll investigate
about it.


> - The gerrit today only has a subset of the parts of CDT that are in
> simrel.aggr/cdt.aggrcom (the only contribution I looked at closely). AFAICT
> only the items that are categorized are present in category.xml. Where do
> uncategorized features end up? Similar question about uncategorized
> bundles. I could add them all to a new category if needed.
>

That seems like a bug in the routine that turns the .aggr model to a
category.xml/pom.xml pair. I'll fix it.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

Hi all,

With a recent patch, Tycho has achieved a major milestone that allows it to
be a viable replacement to build SimRel repo in place of the very specific
CBI aggregator. Specifically, Tycho now can validate a build plan without
downloading all artifacts, so it can allow the Gerrit patch/CI feedback
short feedback loop.

The principle and benefits of this change consists in getting rid of CBI
aggregator specific files, models, builders... which no-one beyond a few
privileged (?) ones know how to deal with. By moving it to more mainstream
and better known Maven+Tycho+category.xml stack, we allow more people to
participate in the maintenance of the SimRel aggregation; and we also get
rid of one brick to maintain (CBI aggregator) in favor of a well maintained
and active one (Tycho). This will overall result in some resources saving
and SimRel entry-barrier being much lowered.
Of course, there are some features of CBI aggregator that don't have
equivalent in Tycho, and the other way round; sending emails for example
wouldn't be available anymore. But times have changed since the
introduction of CBI aggregator (called b3 back then): CI rose, Code Review
rose, all this DevOps things basically matured and has brought solutions
for the use-case that were directly supported by b3. Not so objectively, I
don't know of any feature of CBI aggregator for SimRel build that we would
really miss when moving to Tycho. I don't the replacement this will either
increase difficulty of contributing to SimRel or to maintain it.

This Gerrit patch shows it in action
https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/170553 . You
see it adds 1 category.xml file with the content of SimRel, and the list of
p2 repositories in the pom.xml.

I think all that stack is mature enough, and the value/savings in changing
to Tycho is compelling enough to consider this migration for 2021-03.

Cheers,
-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

On Fri, Oct 9, 2020 at 9:12 AM Aleksandar Kurtakov 
wrote:

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


Thanks Alex for bringing the motivation, I've invested the day in
refreshing all those efforts on
https://bugs.eclipse.org/bugs/show_bug.cgi?id=500769 /
https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/170553 to
move SimRel to Tycho, and resubmitted a change for CBI aggregator to allow
generating an equivalent-ish Tycho build (pom.xml+category.xml) which was
used to SimRel
https://git.eclipse.org/r/c/cbi/org.eclipse.cbi.p2repo.aggregator/+/81540 .
I'm waiting for completion of local build and will report some feedback on
the related bugs or Gerrit.
___
cross-project-issues-dev 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] Opportunity to promote Eclipse IDE commiters sponsoring via @EclipseJavaIDE

[Mickael Istria]

Hi all,

Here is a last reminder,

On Wednesday, September 16, 2020, Mickael Istria  wrote:
> Hi fellow Committers!
> [Note: this is a 2nd iteration, for the 2020-09 to 2020-12 period]
>
> If you're seeking sponsorship via a service such as GitHub Sponsors or
Patreon, and would like your page to be promoted on the @EclipseJavaIDE
twitter account, we may be able to help. If you are interested and fulfill
the following criteria:
>
> You are currently an active committer on an Eclipse project that’s
included in an EPP package, or is part of the essential tool chain to
produce an EPP package.
> You have a sponsoring page clearly identifying the Eclipse projects that
you support.
>
> Then please contact us before end of June with the following details:
>
> Your full name.
> The link to your sponsoring page.
> The names of the projects on which you’re actively participating as a
committer, including links to that demonstrate your recent (less than 3
months old) commit or review activities.
>
> We will tweet about the sponsoring opportunity via @EclipseJavaIDE and
schedule the tweets to be published once per week starting from early
October, i.e., ~2 weeks after the 2020-09 release, by alphabetical order
base on the first name, with a maximum of 8 tweets for this 2nd campaign.
To avoid collision with communications about the 2020-09 and 2020-12
releases, we will leave ~2 weeks before and ~2 weeks after the release
without promoting sponsorship.
> Should we receive too many requests, we will prioritize the ones working
on projects that are part of “Eclipse IDE for Java Developers” or “Eclipse
IDE for Enterprise Java developers” as these best match the interests of
the target audience.
> If this receives enough interest (3 committers at least), we will iterate
and adapt for a 3rd campaign after 2020-12 based on the results of this 2nd
campaign.
>
> Cheers,
>
> --
> Mickael Istria
> Eclipse IDE developer, for Red Hat Developers
>
> --
> Mickael Istria
> Eclipse IDE developer, for Red Hat Developers

-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Opportunity to promote Eclipse IDE commiters sponsoring via @EclipseJavaIDE

[Mickael Istria]

Hi fellow Committers!

[Note: this is a 2nd iteration, for the 2020-09 to 2020-12 period]

If you're seeking sponsorship via a service such as GitHub Sponsors or
Patreon, and would like your page to be promoted on the @EclipseJavaIDE
twitter account, we may be able to help. If you are interested and fulfill
the following criteria:

   1. You are currently an active committer on an Eclipse project that’s
   included in an EPP package, or is part of the essential tool chain to
   produce an EPP package.
   2. You have a sponsoring page clearly identifying the Eclipse projects
   that you support.

Then please contact us before end of June with the following details:

   1. Your full name.
   2. The link to your sponsoring page.
   3. The names of the projects on which you’re actively participating as a
   committer, including links to that demonstrate your recent (less than 3
   months old) commit or review activities.

We will tweet about the sponsoring opportunity via @EclipseJavaIDE and
schedule the tweets to be published once per week starting from early
October, i.e., ~2 weeks after the 2020-09 release, by alphabetical order
base on the first name, with a maximum of 8 tweets for this 2nd campaign.
To avoid collision with communications about the 2020-09 and 2020-12
releases, we will leave ~2 weeks before and ~2 weeks after the release
without promoting sponsorship.
Should we receive too many requests, we will prioritize the ones working on
projects that are part of “Eclipse IDE for Java Developers” or “Eclipse IDE
for Enterprise Java developers” as these best match the interests of the
target audience.
If this receives enough interest (3 committers at least), we will iterate
and adapt for a 3rd campaign after 2020-12 based on the results of this 2nd
campaign.

Cheers,

-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>

>

-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Eclipse 2020-09 video

[Mickael Istria]

Awesome, thanks Holger!
___
cross-project-issues-dev 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] Corrosion dropping from SimRel

[Mickael Istria]

On Tue, Sep 1, 2020 at 7:53 PM Wayne Beaton <
wayne.bea...@eclipse-foundation.org> wrote:

> Independent of this, according to my records, Eclipse Corrosion is overdue
> for a Release Review. Please initiate one immediately.
>

I've created
https://projects.eclipse.org/projects/tools.corrosion/releases/0.4.3
Cheers,
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

On Mon, Aug 31, 2020 at 1:38 PM Mickael Istria  wrote:

> m2e *might* be 1.16.2 but that depends on a change upstream non-SimRel
> project (LemMinX) that not certain for 2020-09.
>

I confirm m2e will be 1.16.2, as important fix has been made available
upstream
https://projects.eclipse.org/projects/technology.m2e/releases/1.16.2
-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] Corrosion dropping from SimRel

[Mickael Istria]

On Tue, Sep 1, 2020 at 7:53 PM Wayne Beaton <
wayne.bea...@eclipse-foundation.org> wrote:

> Somebody will correct me if I'm wrong, but AFAIK it a requirement for
> inclusion in an EPP package is participation in the simultaneous release.
> [...]
> Per EPP/How to create a package
> :
>
> Packages must only contain code from Eclipse projects from the
>> Simultaneous Release
>
>
SimRel is not a requirement for EPP any more, this was clarified with
Planning Council earlier this year.
The documentation needs to be updated, we'll look at it soon.


> The simultaneous release participation requirements are an important part
> of the quality controls around the packages.
>

That's arguable and you recently mentioned in another that you don't like
discussions that argue about the value of SimRel ;)

Independent of this, according to my records, Eclipse Corrosion is overdue
> for a Release Review. Please initiate one immediately.
>

I'll take care of it soon. In the worst case, it's totally fine if we ship
the previous 0.4.2 version of Corrosion in the upcoming SimRel. But a 0.4.3
would indeed be better.
___
cross-project-issues-dev 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] JDK on JIPP Instance

[Mickael Istria]

On Mon, Aug 31, 2020 at 4:08 PM Frederic Gurr <
frederic.g...@eclipse-foundation.org> wrote:

> To clarify: in https://bugs.eclipse.org/bugs/show_bug.cgi?id=565263 you
> requested the move to JIRO since LSP4E requires newer versions of
> webkitgtk which we can't support in our old environment.
>
> Supporting newer JDK version is a different matter and can be done
> easily on the old infra since it does not require an OS upgrade.


Ah OK, you're right; I faced so many deps related churns lately that I lost
the causality chain of all that.
Sorry for blaming you; and in the end, I'm relatively happy using JIRO now.
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

[Mickael Istria]

On Thu, Aug 27, 2020 at 8:51 PM Wayne Beaton <
wayne.bea...@eclipse-foundation.org> wrote:

> *AFAICT, the corrosion.aggrcon file still exists and is not disabled.* Also,
> since CFT has dropped out, its aggrcon file should also be removed (not
> just disabled). Can somebody take care of that, please?
>

Thanks for the reminder Wayne, I forgot to merge
https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/168044 . I'm
on it right now, too bad I missed M3!
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] SWT based 3D plot library?

[Mickael Istria]

SWT Snippet195 contains an example of how to use LWJGL to draw on some SWT
Canvas. That's more than 3D plotting so it may be overkill for the desired
case though.
HTH
___
cross-project-issues-dev 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] Corrosion dropping from SimRel

[Mickael Istria]

Hi all,

Corrosion is leaving SimRel. I'll make the actual change in a few minutes.
Corrosion remains an active project, with decent maintenance (more would be
better and the project is open to new contributors ;) ), and will still be
included in the "Eclipse IDE for Rust developers" EPP package.
The reason behind that change is that SimRel was identified by its
contributors in mailing-list discussions as a non-profitable extra-step for
Corrosion, whose main target for downstream consumption are EPP packages.

Cheers,
-- 
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev