[cross-project-issues-dev] Eclipse BPEL Designer pulling out of simrel

2022-01-14 Thread Ralph Soika 

Hello,

we plan to pull out the Eclipse BPEL Designer 
 from the simrel. We 
think this project plays no longer a relevant role and was not 
maintained for years now.


If someone is using the project or knowing projects depending on the 
Eclipse BPMN Designer please let me know. The project will not be 
deleted and the latest version can still be downloaded form: 
https://download.eclipse.org/bpel/updates/2020-06/1.1.3/


Best regards
Ralph

--

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

*Imixs* is an open source company, read more: www.imixs.org 

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

2022-01-14 Thread Jonah Graham 
I have heard from a number of projects, both on this list and elsewhere
that they are making the updates. I have not submitted these changes today
and propose that I do them at the beginning of the 2022-06 release cycle
(mid-March). At that time I will recheck to make sure I am not disabling
anything that gets fixed in the meantime.

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


On Thu, 13 Jan 2022 at 15:20, Jonah Graham  wrote:

>
>
> On Thu, 13 Jan 2022 at 08:47, Jonah Graham  wrote:
>
>> On Thu., Jan. 13, 2022, 08:18 Aleksandar Kurtakov, 
>> wrote:
>>
>>> I would dare to say that as long as the workarounds are in simrel
>>> nothing will get fixed - it's time to face reality.
>>>
>> Probably correct, but I don't have the nerve to disable (or
>> knowledge/time to fix) Mylyn.
>>
>
> Hi folks,
>
> It is time to remove the temporary workarounds. When I had a look today I
> realised that more and more projects are relying on the temporary
> workaround initially put in place for Mylyn.
>
> Over a year ago I filed numerous bugs asking projects to fix their
> contributions, some projects were very responsive and others I have not
> heard back from.
>
> Therefore for M2 I plan to disable all projects from SimRel that aren't up
> to date or have otherwise started relying on these workarounds. I will
> submit the following gerrits[1,2] after 2022-03 M1 is done. Please see the
> gerrits for what is disabled. I attempted to only disable features where
> possible and not entire contributions.
>
> The affected projects are (with some comments):
> - Mylyn (fully disabled Bug 569078)
> - Passage (only one feature, so fully disabled)
> - DTP (many features, lots because Lucene 7.x is no longer provided by
> Eclipse Platform? + Bug 569181)
> - WTP (Bug 568136)
> - m2e-wtp (JPA related code)
> - PDT (Composer feature needs org.apache.commons.exec)
> - soa-bpel (depends on disabled WTP features)
>
> [1] https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/189612
> - Remove the Orbit direct contribution to SimRel workaround
> [2] https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/189614
> - Remove Mylyn
>
> Jonah
>
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
>>
>>>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] Critical projects?

2022-01-14 Thread Scott Lewis 

Hi Simrel folks,

As the lead of long-time participant project (ECF), I've personally 
experienced (as well as watched in horror) the problem of diminishing 
maintenance resources that now seems endemic to simrel projects and to 
the simrel itself.


I heard that yesterday there was a meeting at the White House about 
fears of the 'next log4j' [1].


Today I read this story [2] about Google and IBM suggesting a 'critical 
projects list' as a step toward (reportedly) a better model (read $) for 
ongoing maintenance of 'critical projects'.


My first thought:   Where is Eclipse, EF, simrel and supporting projects 
wrt this/these efforts?  Of course everyone thinks of their own project 
as 'essential' :), but more broadly I would be much more comfortable if 
the choices wrt 'criticality' and what is/is not 'infrastructure' were 
made based upon a clear representation of consumer needs.   It seems 
from the zdnet reporting (which may not be accurate of course) that 
mostly corporate and commercial concerns wrt open source maintenance are 
currently being identified.


I just wanted to raise this among the projects participating in the 
simrel.   I'm not sure how any of this is going to be approached, but am 
hoping that the simrel project leads and teams can find a way to 
participate in these efforts, as I think there is a huge amount of 
knowledge and experience here about open source maintenance via 
transparency, successful, scalable, community collaboration.


Scott

[1] 
https://www.zdnet.com/article/after-log4j-white-house-worries-about-the-next-big-open-source-flaw/


[2] 
https://www.zdnet.com/article/log4j-after-white-house-meeting-google-calls-for-list-of-critical-open-source-projects/


___
cross-project-issues-dev 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] SimRel 2022-03 M1 is Available

2022-01-14 Thread Ed Merks 

Hi,

The 2021-12 M3 update repository is available from:

 http://download.eclipse.org/releases/2021-12/

The EPP Packages are available here:

  https://www.eclipse.org/downloads/packages/release/2022-03/m1

There seem to be wrong links to the 2021-12 installer though. Installers 
for 2022-03 are available here (and please use the download link icons 
because those use mirrors):


https://download.eclipse.org/justj/?file=oomph/epp/2022-03/M1

Thanks Alex for fixing the Linux Tools signing problem so quickly and 
the other Alex for getting the latest and greatest log4j2 in place.


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

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

2022-01-14 Thread Jonah Graham 
Hi Alexander,

Sorry that you got caught in the crossfire on this change - the
realization that Passage was depending (unintentionally) on a workaround I
put in last year for Mylyn made me revisit to see if the cost of fixing
Mylyn this way was having unintended consequences. After a year instead of
the problem getting better, the problem has become worse.

I appreciate all the analysis done in this thread. One thing to note is
this is not a project handbook issue, but simply a release train
participation issue. While I am sure Wayne/EMO will facilitate where
necessary the rules of engagement are documented in the wiki (out of date)
https://wiki.eclipse.org/SimRel/Overview and guided by the Planning
Council.  As for the Orbit rule - for 15 years (how old is SimRel?) Orbit
did not participate directly. Orbit is not a "normal" project, and the
closest reference to the rule I mention is in the FAQ[1] which says "This
is analogous to the use of "third party" bundles from Orbit, where the
original authors clearly do not "participate" in the release".

PS - It is not 1 day to resolve the issue, but 20 days until M2 and 54 days
notification until RC2. If the consensus is that it is too tight, it may be
best to introduce this kind of change at the beginning of a release cycle,
which means I hold off merging until late March.

[1] https://wiki.eclipse.org/SimRel/Simultaneous_Release_Policy_FAQ

Jonah



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


On Fri, 14 Jan 2022 at 02:43, Alexander Fedorov <
alexander.fedo...@arsysop.ru> wrote:

> Hi Jonah,
>
> Since Passage was never depending from Mylyn it was surprising to see it
> disabled. As I understood, it was done because Passage does not mirror all
> the used Orbit bundles to its p2 site.
> Please don't get me wrong, but the gap between notification [1] and action
> seems a bit tight to me: about 1 day without technical space to fix it.
>
> Perhaps I missed something important during the past years but the rule to
> always mirror Orbit dependencies to the component p2 site was neither
> clearly articulated nor enforced previously.
>
> To avoid future misunderstanding I've created a ticket [2] to improve
> Project Handbook regrading SimRel participation.
> @Wayne, @Alexander please invest your time to polish the formulation of
> this [new?] constraint for Eclipse projects that are willing to participate
> SimRel.
>
> Thank you,
> AF
>
> [1] https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/189570
> [2] https://gitlab.eclipse.org/eclipsefdn/emo-team/emo/-/issues/177
>
> 1/13/2022 11:20 PM, Jonah Graham пишет:
>
>
>
> On Thu, 13 Jan 2022 at 08:47, Jonah Graham  wrote:
>
>> On Thu., Jan. 13, 2022, 08:18 Aleksandar Kurtakov, 
>> wrote:
>>
>>> I would dare to say that as long as the workarounds are in simrel
>>> nothing will get fixed - it's time to face reality.
>>>
>> Probably correct, but I don't have the nerve to disable (or
>> knowledge/time to fix) Mylyn.
>>
>
> Hi folks,
>
> It is time to remove the temporary workarounds. When I had a look today I
> realised that more and more projects are relying on the temporary
> workaround initially put in place for Mylyn.
>
> Over a year ago I filed numerous bugs asking projects to fix their
> contributions, some projects were very responsive and others I have not
> heard back from.
>
> Therefore for M2 I plan to disable all projects from SimRel that aren't up
> to date or have otherwise started relying on these workarounds. I will
> submit the following gerrits[1,2] after 2022-03 M1 is done. Please see the
> gerrits for what is disabled. I attempted to only disable features where
> possible and not entire contributions.
>
> The affected projects are (with some comments):
> - Mylyn (fully disabled Bug 569078)
> - Passage (only one feature, so fully disabled)
> - DTP (many features, lots because Lucene 7.x is no longer provided by
> Eclipse Platform? + Bug 569181)
> - WTP (Bug 568136)
> - m2e-wtp (JPA related code)
> - PDT (Composer feature needs org.apache.commons.exec)
> - soa-bpel (depends on disabled WTP features)
>
> [1] https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/189612
> - Remove the Orbit direct contribution to SimRel workaround
> [2] https://git.eclipse.org/r/c/simrel/org.eclipse.simrel.build/+/189614
> - Remove Mylyn
>
> Jonah
>
> ~~~
> Jonah Graham
> Kichwa Coders
> www.kichwacoders.com
>
>>
>>>
> ___
> cross-project-issues-dev mailing listcross-project-issues-...@eclipse.org
> To unsubscribe from this list, visit 
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list

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

2022-01-14 Thread Ed Merks 

Mickael,

You quote out of context where "Tycho being used" is in reference to the 
build of a project's p2 site not with reference to how the aggregation 
itself is implemented.


I think it would be awfully nice if there were less finger pointing and 
less pessimism shared quite so freely.   Of course we all feel that we 
personally have the most well-informed, well-balanced point of view 
while those of others are all too often somehow ill-considered and 
unbalanced.  That's just human nature, but a little bit of reflection 
tells us that perhaps it's because we are only looking at the shiny side 
of the coin and that we ought to seriously look at the other side too 
rather than lay the coin flat and draw attention only to the 
upward-facing shiny side.


I don't even think this particular coin to which you draw attention is 
actually relevant to whether Orbit's repository is included in an 
aggregation or not (the topic of this thread), because this is not an 
issue of how the aggregation is implemented nor is the issue somehow 
resolved or eliminated by implementing aggregation differently...


On 14.01.2022 10:23, Mickael Istria wrote:



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

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

2022-01-14 Thread 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] Disabling Mylyn from SimRel + Removing related Orbit workarounds

2022-01-14 Thread Christoph Läubrich 

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

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


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



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


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


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


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


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


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


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


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


Regards,
Ed

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

If Tycho is used it is probably the easiest to enable

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

2022-01-14 Thread Christoph Läubrich 

If Tycho is used it is probably the easiest to enable

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

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


Am 14.01.22 um 08:43 schrieb Alexander Fedorov:

Hi Jonah,

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


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


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


Thank you,
AF

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

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



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

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

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

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


Hi folks,

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


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


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


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

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

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


Jonah

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



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



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

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