Congrats for finding the root case, I would have never though about
something like hat would be the cause!
For sure we should improve our tools (and I already did some trivial
enhancements), the most problematic here (and on other issues as well)
is that there seem not many people actually can give some guidance and
the code is not very self explaining (to me) why what happens... and
then contributing to it becomes really a nightmare if you do not even
understand why the error happens and (until now) no one even has a clue.
And as you noticed, the problem is not that one is not willing to
contribute but there is literally no response for months, so one can
really get the impression the code base is dead/unmaintained state...
Do what you can according to your best knowledge. This is a problem in almost every project I ever worked on, the sooner we accept that if no one replies the committer should act in what he believes is in the best interest of the project the sooner we will see positive changes.
Not every functionality deserves to live but also not being dropped without effort to change it. A change touching more things than necessary or not being optimal is just fine if there is no one else stepping up to do it better.
With the previous said - don't wait for answers indefinitely, they will most likely not come. Just do what you can, have time for and you want to do.
Am 07.11.22 um 08:52 schrieb Ed Merks:
> It seems to me that we often tell people who complain about a problem
> that a PR would be most welcome. In this case where we have a problem
> with a shoe and "we" are the shoemaker of that shoe, that suggestion
> seems even more appropriate. We are PDE...
>
> In any case, you opened
> https://github.com/eclipse-pde/eclipse.pde/issues/378 and the issue was
> determined to be a surprising and nasty corner case of our own
> manufacture. So I think we can now safely call off the demolition crew.
>
> -----------------
>
> It is frustrating that there is little in the way of responsiveness when
> asking questions. For example I *know *there is a bug in
> org.eclipse.pde.api.tools.internal.builder.Reference.getParameterList(),
> and I have a fix for it (I think). But I don't know what exactly that
> method is supposed to do, so I asked in the bug where that method was
> introduced:
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=332767
>
> That was almost a month ago...
>
>
> On 06.11.2022 07:09, Christoph Läubrich wrote:
>> > I understand and agree that the current situation is unpleasant or
>> > better annoying.
>>
>> 611 failing test anyone? ;-)
>>
>> That's just another example, we have random failures, none seem to
>> know why or what can be done even though we have tried some things but
>> it still occurs.
>>
>> > In case it would require more time/effort to adjust the existing code
>> > base to the new tooling (e.g. remove all required-bundles) it could be
>> > simpler to fix the PDE API-tools instead.
>>
>> For sure it depends on the tooling, and I won't recommend to just
>> migrate everything, but it seems code debt for API tools is increasing
>> and actually no one "simply fix it" even simple(?) ones like [1] just
>> hanging around.
>>
>> So it is better to decide if there is a future for API tools or if we
>> better look *now* for alternatives and let user know there is most
>> likely no more support for them (similar for pde-build that seems
>> unmaintained for a long time as well!).
>>
>>
>>
>> [1] https://github.com/eclipse-pde/eclipse.pde/issues/124
>>
>>
>>
>> Am 05.11.22 um 22:19 schrieb Hannes Wellmann:
>>> I understand and agree that the current situation is unpleasant or
>>> better annoying.
>>> Nevertheless we need some form of API tooling and I don't know if
>>> other techniques and tools can deal better with the PDE specialties
>>> like re-exported Required-Bundles (which is likely causing your issues)?
>>> What would be the alternatives in this case?
>>> In case it would require more time/effort to adjust the existing code
>>> base to the new tooling (e.g. remove all required-bundles) it could
>>> be simpler to fix the PDE API-tools instead.
>>> Using Re-export in general is bad and I fully agree/support improving
>>> PDE's Import-Package support in general but since probably many rely
>>> on re-exported require-bundle that it will take some time and
>>> discussion to get rid of that and will probably not work until there
>>> is a equivalent convenient solution available (like automatically
>>> calculated Import-Packages)
>>> But my blind guess is that other tools (probably from BND?) would
>>> also have their difficulties with that.
>>> > as even the build-setup is horrible complex and hard to perform
>>> including calling helper mojos and ant scripts.
>>> Since we are working on a API-tools plugin at Tycho, that problem
>>> should no longer exists in the not to distance future (I hope to have
>>> time to continue my work on that soon).
>>> Furthermore I had the intention to improve PDE's API tools in the
>>> future with regard to detecting necessary version bumps in Features
>>> and Plugins already in the IDE.
>>> That being said, if there is a 'drop-in' replacement for PDE's API
>>> tools I would not object to use that instead.
>>> But I would not assume that such immediate drop-in exists, but please
>>> correct me if I'm wrong.
>>> Nevertheless, if a suitable library exists we could consider to use
>>> that in the core of PDE's API tools and add reasonable PDE
>>> specialties on top of that.
>>> Greetings,
>>> Hannes
>>> *Gesendet:* Samstag, 05. November 2022 um 15:31 Uhr
>>> *Von:* "Christoph Läubrich" <laeubi@xxxxxxxxxxxxxx>
>>> *An:* pde-dev@xxxxxxxxxxx
>>> *Betreff:* [pde-dev] Discontinue API Tools ( was Re: What do API
>>> tools want here?)
>>> So now three month later, still no one know why API tools complains, or
>>> even what the error message means. Ed has done some analysis and even
>>> found that all quick fixes are broken here and even adding code in mini
>>> steps do not help any further.
>>>
>>> For me the question is if there is no support, no maintenance or
>>> development available if it is time to discontinue API tools, as even
>>> the build-setup is horrible complex and hard to perform including
>>> calling helper mojos and ant scripts.
>>>
>>> SO if PDE itself can't master its own API tools I think its time to face
>>> the truth and recommend to stop using it and migrate to other
>>> techniques.
>>>
>>> Am 06.08.22 um 08:16 schrieb Christoph Läubrich:
>>> > Hi PDE-Devs,
>>> >
>>> > I have a strange error from the API tools and no clue what it want
>>> here,
>>> > the error is:
>>> >
>>> > The type
>>> org.eclipse.pde.ui.launcher.AbstractPDELaunchConfiguration has
>>> > been removed from org.eclipse.pde.ui_3.14.0
>>> >
>>> > see build [1]
>>> > and PR [2]
>>> >
>>> > Any hint would be welcome ... I think it would be the best to
>>> directly
>>> > add any comments to the PR.
>>> >
>>> >
>>> > [1]
>>> https://ci.eclipse.org/pde/job/eclipse.pde.ui/job/PR-214/6/consoleFull <https://ci.eclipse.org/pde/job/eclipse.pde.ui/job/PR-214/6/consoleFull>
>>> > [2] https://github.com/eclipse-pde/eclipse.pde/pull/214
>>> <https://github.com/eclipse-pde/eclipse.pde/pull/214>
>>> > _______________________________________________
>>> > pde-dev mailing list
>>> > pde-dev@xxxxxxxxxxx
>>> > To unsubscribe from this list, visit
>>> > https://www.eclipse.org/mailman/listinfo/pde-dev
>>> <https://www.eclipse.org/mailman/listinfo/pde-dev>
>>> _______________________________________________
>>> pde-dev mailing list
>>> pde-dev@xxxxxxxxxxx
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/pde-dev
>>> <https://www.eclipse.org/mailman/listinfo/pde-dev>
>>>
>>> _______________________________________________
>>> pde-dev mailing list
>>> pde-dev@xxxxxxxxxxx
>>> To unsubscribe from this list, visit
>>> https://www.eclipse.org/mailman/listinfo/pde-dev
>> _______________________________________________
>> pde-dev mailing list
>> pde-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/pde-dev
>
> _______________________________________________
> pde-dev mailing list
> pde-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/pde-dev
_______________________________________________
pde-dev mailing list
pde-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/pde-dev
