date:20220419

Just curious, if as you stated

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

how do you know that, as you stated

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

and it was not considered?

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

Am 19.04.22 um 11:54 schrieb Ed Willink:

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

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

Regards

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

Ed,

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

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

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

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

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

Regards,
Ed

On 19.04.2022 10:08, Ed Willink wrote:

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

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

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

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

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

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

Regards

Ed Willink

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

Ed,

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

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

The announcement included a plan:

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

It also included a place for providing feedback:

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

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

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

Note that the Eclipse TLP has 4 organizations.

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

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

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

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

Regards,
Ed

On 18.04.2022 13:19, Ed Willink wrote:

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

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

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

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

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

2022-04-19 Thread Denis Roy

Ed,

I'm very sorry that you choose to see this as a vandalism. Change is
always difficult to manage; yet if we refusing to accept it, we risk
being left behind while our surroundings evolve around us. We've been
holding onto good-old status quo for as long as we could. We must
continue to evolve. Collectively.

I think your energies would be better invested in moving your projects
forward. We can help, the burden is not all on you, and we've stretched
the timelines as much as possible. You might be pleasantly surprised
with the end result.

Unfortunately, you've been plagued with email issues for over a decade.
Each time the EF IT team has plowed through logs and have given you
trace IDs to try to track the issue at your provider. GitLab is talking
to you. I don't feel we can do any more here.

Denis

On 2022-04-19 05:54, Ed Willink wrote:

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

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

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

Regards

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

Ed,

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

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

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

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

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

Regards,
Ed

On 19.04.2022 10:08, Ed Willink wrote:

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

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

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

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

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

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

Regards

Ed Willink

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

Ed,

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

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

The announcement included a plan:

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

It also included a place for providing feedback:

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

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

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

Note that the Eclipse TLP has 4 organizations.

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

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

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

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

Regards,
Ed

On 18.04.2022 13:19, Ed Willink wrote:

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

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

Bugzilla has been providing an invaluable to service to the
platform and JDT for over 20 years and as such is THE record of
many design decisions. The integrity of this record

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

Hi all,

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

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

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

Cheers,

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

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

Thank you Mickael for starting this discussion.

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

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

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

Jonah


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


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

> Hi all,
>
> In https://github.com/eclipse/tm4e/issues/339 , active TM4E contributors
> have agreed to consider the move the JavaSE-17 as minimal Java version
> soon. The rationale is that some benefits of recent version of Java
> languages (sealed Types, switch expressions) are likely to really
> facilitate further maintenance and development of the parsers included in
> TM4E, and also to increase quality (new constructs leave less space for
> bugs, and often perform better). So we can expect a substantial gain for
> TM4E future in adopting Java 17 soon.
>
> I'm sharing this with Simultaneous Release channel as TM4E is part of
> SimRel. At the moment, SimRel targets Java 11. So when TM4E is released
> with Java 17 requirement, either SimRel allows that and the new release
> gets in; or SimRel keeps Java 11 requirement and will use an older version
> of TM4E (for which there would probably have no support given currently
> active contributors are happy moving to Java 17).
> TM4E is used by Wild Web Developer for instance; but Wild Web Developer
> doesn't mandate 1 specific version of TM4E and we plan to keep TM4E
> backward compatible in term of behavior and API; so those downstream
> consumers should be able to work with former (Java 11-able) release as well
> as newer (Java 17-able) release. So I don't think that downstream
> consumption should be a main concern.
>
> I would invite SimRel stakeholders to consider is whether/when to allow
> Java 17-based code in SimRel.
> Of course, I would advocate for "Do it right now" especially since JustJ
> and thus SimRel and EPP packages ships a recent Java; but acknowledge that
> this may require more discussion, hence why I'm sharing this plan for TM4E
> early.
>
> Cheers,
>
> --
> Mickael Istria
> Eclipse IDE  developer, for Red Hat
> Developers 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

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

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

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

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

Thanks for that. I'll try to get an answer from the planning council soon.
It may have to wait until our May 4th meeting if we can't agree on the
mailing list.

Jonah



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

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

2022-04-19 Thread Martin Lippert

Hey!

Thanks a lot for bringing this to the wider audience, much appreciated.

I added a comment around a somewhat unpleasant consequence of an upgrade to 
JavaSE-17 as a minimal Java version:
https://github.com/eclipse/tm4e/issues/339#issuecomment-1102875590 


Which draws the attention to the tight coupling between the JRE that is used to 
run the IDE and the version of Gradle that users use in their projects (caused 
by the Buildship integration):
https://github.com/eclipse/buildship/issues/1147 


Not sure what the best approach here is (beyond fixing the coupling that 
Buildship causes)… But probably worth to draw some attention to… :-)

Cheers
Martin





> Am 19.04.2022 um 16:25 schrieb 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  developer, for Red Hat 
> Developers 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

Re: [cross-project-issues-dev] Apache Maven 3.8.5 is available on all Jenkins instances now

2022-04-19 Thread Frederic Gurr

Hi,

Since there were no regressions reported, the
/opt/tools/apache-maven/latest link is pointing to 3.8.5 now.

See also: https://wiki.eclipse.org/Jenkins#Apache_Maven

Regards,

Fred


On 18.03.22 11:35, Frederic Gurr wrote:
> Hi,
> 
> Maven 3.8.5 has been deployed to all Jenkins instances.
> 
> Note that apache-maven-latest has been set to 3.8.4 now and will stay
> for a while (at least 4 weeks) to give projects some time to check if
> there are any regressions with 3.8.5.
> 
> Release notes for Maven 3.8.5 can be found here:
> https://maven.apache.org/docs/3.8.5/release-notes.html
> 
> Version details are available at
> https://wiki.eclipse.org/Jenkins#Apache_Maven
> 
> 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

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

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 planning to start using JavaSE-17 as BREE soon

2022-04-19 Thread Torbjorn SVENSSON via cross-project-issues-dev

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

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

Am 19.04.22 um 16:37 schrieb Jonah Graham:

Thank you Mickael for starting this discussion.

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

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

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

Jonah

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

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

Hi all,

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

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

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

Cheers,

-- 
Mickael Istria

Eclipse IDE  developer, for Red
Hat Developers 
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org

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

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

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

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

Hello,

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

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

Kind regards,
Torbjörn


ST Restricted

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

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

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



Am 19.04.22 um 16:37 schrieb Jonah Graham:
> Thank you Mickael for starting this discussion.
> 
> I would be very keen to allow Java 17 as BREE in SimRel by a project 
> that wants it. I will endeavour to get the Planning Council to come to 
> an agreement on this as I think that is the group in charge of such 
> requirements.
> 
> PS Where is "SimRel targets Java 11" defined? Is it just implicit at the 
> moment (because Eclipse Platform is Java 11), or is it explicit 
> somewhere? The only requirement on this topic in the SimRel Release 
> Requirements is that bundles have a BREE[1]
> 
> [1] 
> https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Execution_Environment_.28tested.29
>  
> 
> 
> Jonah
> 
> 
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com 
> 
> 
> On Tue, 19 Apr 2022 at 10:25, Mickael Istria  > wrote:
> 
> Hi all,
> 
> In https://github.com/eclipse/tm4e/issues/339
>  , active TM4E
> contributors have agreed to consider the move the JavaSE-17 as
> minimal Java version soon. The rationale is that some benefits of
> recent version of Java languages (sealed Types, switch
> expressions) are likely to really facilitate further maintenance
> and development of the parsers included in TM4E, and also to
> increase quality (new constructs leave less space for bugs, and
> often perform better). So we can expect a substantial gain for TM4E
> future in adopting Java 17 soon.
> 
> I'm sharing this with Simultaneous Release channel as TM4E is part
> of SimRel. At the moment, SimRel targets Java 11. So when TM4E is
> released with Java 17 requirement, either SimRel allows that and the
> new release gets in; or SimRel keeps Java 11 requirement and will
> use an older version of TM4E (for which there would probably have no
> support given currently active contributors are happy moving to Java
> 17).
> TM4E is used by Wild Web Developer for instance; but Wild Web
> Developer doesn't mandate 1 specific version of TM4E and we plan to
> keep TM4E backward compatible in term of behavior and API; so those
> downstream consumers should be able to work with former (Java
> 11-able) release as well as newer (Java 17-able) release. So I don't
> think that downstream consumption should be a main concern.
> 
> I would invite SimRel stakeholders to consider is whether/when to
> allow Java 17-based code in SimRel.
> Of course, I would advocate for "Do it right now" especially since
> JustJ and thus SimRel and EPP packages ships a recent Java; but
> acknowledge that this may require more discussion, hence why I'm
> sharing this plan for TM4E early.
> 
> Cheers,
> 
> -- 
> Mickael Istria
> Eclipse IDE  developer, for Red
> Hat Developers 
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> 
> To unsubscribe from this list

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

> Is it only me that sees problems for downstream consumers of the SimRel?

I think that is key the point of this discussion. If we allow BREE > 11,
then it complicates everything.

At some point we will allow it (because at some *future* point Eclipse
Platform will require it - I have no idea when that may be, it is out of my
area).

If we don't allow BREE > 11 this means that SimRel will keep the last
BREE=Java 11 version of such bundles. For now it is just TM4E - but if
other projects also make such a move SimRel won't be keeping up with some
of the projects, which tells me this can't be a long term solution.

* although non-SimRel projects ShellWax and Corrosion are or will soon be
BREE of Java 17 too.

Jonah



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


On Tue, 19 Apr 2022 at 14:34, Torbjorn SVENSSON via
cross-project-issues-dev  wrote:

> Hello,
>
> Is it only me that sees problems for downstream consumers of the SimRel? I
> mean, what happens if you use the SimRel as a way to define a stable target
> platform for your product?
> As long as the BREE of the plugins is not newer than version X will allow
> the product to run with JRE of that version "X".
> What you are talking about here is more or less requiring anyone using
> SimRel to also move to a JRE 17. I think that's okay to do, but there
> should be some heads up for this type of change as it can cause major
> problem for our downstream consumers.
>
> My 2 cents is that the newest BREE allowed in SimRel should be the same
> version that is said to be the required JRE version to run the Eclipse IDE
> (AFAIK, that's JRE 11 ATM).
>
> Kind regards,
> Torbjörn
>
>
> ST Restricted
>
> -Original Message-
> From: cross-project-issues-dev <
> cross-project-issues-dev-boun...@eclipse.org> On Behalf Of Christoph
> Läubrich
> Sent: den 19 april 2022 19:16
> To: cross-project-issues-dev@eclipse.org
> Subject: Re: [cross-project-issues-dev] TM4E planning to start using
> JavaSE-17 as BREE soon
>
>  > I would be very keen to allow Java 17 as BREE in SimRel by a project
>  > that wants it.
>  > PS Where is "SimRel targets Java 11" defined? Is it just implicit
>  > at the moment (because Eclipse Platform is Java 11),
>
> I think there is at least no *technical* reason of this, as far as I
> know there are still bundles targeting Java 8 (or even 6), one should
> only keep in mind that if Eclipse is run with JDK11 then it would
> require users to install never version if they want install such Java 17
> stuff (probably that will be automated with the JustJ updatesite
> included), so maybe there is nothing special to consider?
>
>
>
> Am 19.04.22 um 16:37 schrieb Jonah Graham:
> > Thank you Mickael for starting this discussion.
> >
> > I would be very keen to allow Java 17 as BREE in SimRel by a project
> > that wants it. I will endeavour to get the Planning Council to come to
> > an agreement on this as I think that is the group in charge of such
> > requirements.
> >
> > PS Where is "SimRel targets Java 11" defined? Is it just implicit at the
> > moment (because Eclipse Platform is Java 11), or is it explicit
> > somewhere? The only requirement on this topic in the SimRel Release
> > Requirements is that bundles have a BREE[1]
> >
> > [1]
> >
> https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Execution_Environment_.28tested.29
> > <
> https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements#Execution_Environment_.28tested.29
> >
> >
> > Jonah
> >
> >
> > ~~~
> > Jonah Graham
> > Kichwa Coders
> > www.kichwacoders.com 
> >
> >
> > On Tue, 19 Apr 2022 at 10:25, Mickael Istria  > > wrote:
> >
> > Hi all,
> >
> > In https://github.com/eclipse/tm4e/issues/339
> >  , active TM4E
> > contributors have agreed to consider the move the JavaSE-17 as
> > minimal Java version soon. The rationale is that some benefits of
> > recent version of Java languages (sealed Types, switch
> > expressions) are likely to really facilitate further maintenance
> > and development of the parsers included in TM4E, and also to
> > increase quality (new constructs leave less space for bugs, and
> > often perform better). So we can expect a substantial gain for TM4E
> > future in adopting Java 17 soon.
> >
> > I'm sharing this with Simultaneous Release channel as TM4E is part
> > of SimRel. At the moment, SimRel targets Java 11. So when TM4E is
> > released with Java 17 requirement, either SimRel allows that and the
> > new release gets in; or SimRel keeps Java 11 requirement and will
> > use an older version of TM4E (for which there would probably have no
> > support given currently active contributors are happy moving to Java
> > 17).
> > TM4E is used by Wild Web Developer for instance; but Wild Web
> > Developer doesn't mandate 1 specific version of TM4E and we plan

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

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

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

Hi folks,

Not sure where this question goes.

At the moment Eclipse Platform consumes ASM directly from Maven, which
means the version it has in its I-builds is 9.3.0[1] - GPG signed.

Orbit also has ASM 9.3.0, made in the same way as 9.2.0 and previous
releases. This means Orbit contributes version 9.3.0.v20220409-0157[2] -
jar signed.

I am concerned this means we can end up with both versions in SimRel a bit
too easily.

What, if anything, should we do about this? Is this the expected outcome?

Jonah


[1]
https://download.eclipse.org/eclipse/updates/4.24-I-builds/I20220418-1800/plugins/org.objectweb.asm_9.3.0.jar
[2]
https://download.eclipse.org/tools/orbit/downloads/drops/I20220415103937/repository/plugins/org.objectweb.asm_9.3.0.v20220409-0157.jar



~~~
Jonah Graham
Kichwa Coders
www.kichwacoders.com
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

On Tue, 19 Apr 2022 at 15:07, Mickael Istria  wrote:

>
> 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.
>
>
I assume the "Java 18" was just a typo - EPP is shipping  withJava 17 and
will be (at least) until the next LTS Java version.

Jonah
___
cross-project-issues-dev mailing list
cross-project-issues-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

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

2022-04-19 Thread Nitin Dahyabhai

Unless and until there is a pressing need for a newer version than what's in 
Orbit--which has a recipe that can be updated should that need arise--couldn't 
the Platform stop simply stop packaging its own?
___
cross-project-issues-dev mailing list
cross-project-issues-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

2022-04-19 Thread Andrey Loskutov

A really hard to detect problem may appear if the code that used signed classes 
will get in contact with code loaded unsigned. While that this doesn't matter 
from compiler POV, and the actual code is identical, at runtime the classes and 
packages will be incompatible. I remember we had something like this in our 
code that used one ASM version from platform and another one coming from Xtext, 
at runtime both were loaded and we had verify errors where VM complained about 
incompatible class loaded or bad operand type on stack or something similar 
(asm bundles are not singletons and multiple bundle versions may coexist in one 
installation).

So ideally we shouldn't mix multiple ASM bundles in one release.

Am 19. April 2022 21:23:21 MESZ schrieb Jonah Graham :
>Hi folks,
>
>Not sure where this question goes.
>
>At the moment Eclipse Platform consumes ASM directly from Maven, which
>means the version it has in its I-builds is 9.3.0[1] - GPG signed.
>
>Orbit also has ASM 9.3.0, made in the same way as 9.2.0 and previous
>releases. This means Orbit contributes version 9.3.0.v20220409-0157[2] -
>jar signed.
>
>I am concerned this means we can end up with both versions in SimRel a bit
>too easily.
>
>What, if anything, should we do about this? Is this the expected outcome?
>
>Jonah
>
>
>[1]
>https://download.eclipse.org/eclipse/updates/4.24-I-builds/I20220418-1800/plugins/org.objectweb.asm_9.3.0.jar
>[2]
>https://download.eclipse.org/tools/orbit/downloads/drops/I20220415103937/repository/plugins/org.objectweb.asm_9.3.0.v20220409-0157.jar
>
>
>
>~~~
>Jonah Graham
>Kichwa Coders
>www.kichwacoders.com

--
Kind regards,
Andrey Loskutov

https://www.eclipse.org/user/aloskutov
Спасение утопающих - дело рук самих утопающих
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

2022-04-19 Thread Aleksandar Kurtakov

On Tue, Apr 19, 2022 at 10:39 PM Nitin Dahyabhai 
wrote:

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

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

[1]
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/commit/8f79635e7217ecb24dbc209b964711e66a8f322d
[2]
https://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=16b27f6531af3cf41bc73bdfb27a581565f9dc33
[3] https://github.com/eclipse-pde/eclipse.pde.ui/issues/11


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

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

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

On Tue., Apr. 19, 2022, 15:49 Aleksandar Kurtakov, 
wrote:

>
>
> On Tue, Apr 19, 2022 at 10:39 PM Nitin Dahyabhai 
> wrote:
>
>> Unless and until there is a pressing need for a newer version than what's
>> in Orbit--which has a recipe that can be updated should that need
>> arise--couldn't the Platform stop simply stop packaging its own?
>>
>
> That's kind of what happened - [1] and [2]. At the time Platform (PDE
> actually) had the need and work was initiated there was nothing in Orbit -
> [3].
>

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

Thanks,
Jonah


> [1]
> https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/commit/8f79635e7217ecb24dbc209b964711e66a8f322d
> [2]
> https://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=16b27f6531af3cf41bc73bdfb27a581565f9dc33
> [3] https://github.com/eclipse-pde/eclipse.pde.ui/issues/11
>
>
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>>
>
> --
> Aleksandar Kurtakov
> Red Hat Eclipse Team
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

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

2022-04-19 Thread Aleksandar Kurtakov

On Tue, Apr 19, 2022 at 11:12 PM Jonah Graham 
wrote:

>
>
> On Tue., Apr. 19, 2022, 15:49 Aleksandar Kurtakov, 
> wrote:
>
>>
>>
>> On Tue, Apr 19, 2022 at 10:39 PM Nitin Dahyabhai 
>> wrote:
>>
>>> Unless and until there is a pressing need for a newer version than
>>> what's in Orbit--which has a recipe that can be updated should that need
>>> arise--couldn't the Platform stop simply stop packaging its own?
>>>
>>
>> That's kind of what happened - [1] and [2]. At the time Platform (PDE
>> actually) had the need and work was initiated there was nothing in Orbit -
>> [3].
>>
>
> So now that it is orbit would a PR to consume that one when M2 orbit is
> ready be welcome?
>


What happens next time PDE/JDT needs new ASM? Same dance? This doesn't
sound like a good long term plan to me.
My personal opinion is that it's better to stop putting things in Orbit
when upstream provides OSGi bundles in Maven central but use directly.


> Thanks,
> Jonah
>
>
>> [1]
>> https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/commit/8f79635e7217ecb24dbc209b964711e66a8f322d
>> [2]
>> https://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=16b27f6531af3cf41bc73bdfb27a581565f9dc33
>> [3] https://github.com/eclipse-pde/eclipse.pde.ui/issues/11
>>
>>
>>> ___
>>> cross-project-issues-dev mailing list
>>> cross-project-issues-dev@eclipse.org
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>>>
>>
>> --
>> Aleksandar Kurtakov
>> Red Hat Eclipse Team
>> ___
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@eclipse.org
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>


-- 
Aleksandar Kurtakov
Red Hat Eclipse Team
___
cross-project-issues-dev mailing list
cross-project-issues-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

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


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

>
>
> On Tue, Apr 19, 2022 at 11:12 PM Jonah Graham 
> wrote:
>
>>
>>
>> On Tue., Apr. 19, 2022, 15:49 Aleksandar Kurtakov, 
>> wrote:
>>
>>>
>>>
>>> On Tue, Apr 19, 2022 at 10:39 PM Nitin Dahyabhai 
>>> wrote:
>>>
 Unless and until there is a pressing need for a newer version than
 what's in Orbit--which has a recipe that can be updated should that need
 arise--couldn't the Platform stop simply stop packaging its own?

>>>
>>> That's kind of what happened - [1] and [2]. At the time Platform (PDE
>>> actually) had the need and work was initiated there was nothing in Orbit -
>>> [3].
>>>
>>
>> So now that it is orbit would a PR to consume that one when M2 orbit is
>> ready be welcome?
>>
>
>
> What happens next time PDE/JDT needs new ASM? Same dance? This doesn't
> sound like a good long term plan to me.
>
My personal opinion is that it's better to stop putting things in Orbit
> when upstream provides OSGi bundles in Maven central but use directly.
>

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

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

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

Jonah


>
>
>> Thanks,
>> Jonah
>>
>>
>>> [1]
>>> https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/commit/8f79635e7217ecb24dbc209b964711e66a8f322d
>>> [2]
>>> https://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=16b27f6531af3cf41bc73bdfb27a581565f9dc33
>>> [3] https://github.com/eclipse-pde/eclipse.pde.ui/issues/11
>>>
>>>
 ___
 cross-project-issues-dev mailing list
 cross-project-issues-dev@eclipse.org
 To unsubscribe from this list, visit
 https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev


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

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

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

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

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

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

Hello,

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

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

Kind regards,
Torbjörn

ST Restricted

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

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

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

Am 19.04.22 um 16:37 schrieb Jonah Graham:

Thank you Mickael for starting this discussion.

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

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

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

Jonah

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

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

 Hi all,

 In https://github.com/eclipse/tm4e/issues/339
  , 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

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