the guys that had deep knowledge of API tools codebase, design and etc
Just saw this. I have fixed close to 200 bugs in API tools in last 5-7
years ( *including many*
*enhancements*) . I believe I have decent knowledge of API code base
and design
I recommend putting blocker/regression tag on any issue that needs more
attention.
My priorities in API tools are to not have a regression or a general
blocker issue. Also I
try to have at least 1-2 enhancements per year ( in API tools).
If some other bug needs to be addressed, a quality patch should be
provided or a “/constructive/”
discussion should be initiated.
Thanks and Regards,
Vikas
Eclipse PDE Lead
--
*From: *pde-dev <pde-dev-bounces@xxxxxxxxxxx> on behalf of Aleksandar
Kurtakov <akurtako@xxxxxxxxxx>
*Reply to: *"Eclipse PDE general developers list." <pde-dev@xxxxxxxxxxx>
*Date: *Monday, 7 November 2022 at 1:29 PM
*To: *"Eclipse PDE general developers list." <pde-dev@xxxxxxxxxxx>
*Subject: *[EXTERNAL] Re: [pde-dev] Discontinue API Tools ( was Re: What
do API tools want here?)
On Mon, Nov 7, 2022 at 9: 52 AM Ed Merks <ed. merks@ gmail. com> wrote:
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"
ZjQcmQRYFpfptBannerStart
*This Message Is From an External Sender *
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
On Mon, Nov 7, 2022 at 9:52 AM Ed Merks <ed.merks@xxxxxxxxx
<mailto:ed.merks@xxxxxxxxx>> wrote:
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
<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
<https://bugs.eclipse.org/bugs/show_bug.cgi?id=332767>
That was almost a month ago...
Unfortunately, the guys that had deep knowledge of API tools codebase,
design and etc. haven't been working with us for years. As we are the
people with commit rights, we are the "experts" so acting according to
your best knowledge is everything we can do.
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
<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>
<mailto:laeubi@xxxxxxxxxxxxxx>
*An:* pde-dev@xxxxxxxxxxx <mailto: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> <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>
<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 <mailto: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>
<https://www.eclipse.org/mailman/listinfo/pde-dev>
<https://www.eclipse.org/mailman/listinfo/pde-dev>
_______________________________________________
pde-dev mailing list
pde-dev@xxxxxxxxxxx <mailto: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>
<https://www.eclipse.org/mailman/listinfo/pde-dev>
<https://www.eclipse.org/mailman/listinfo/pde-dev>
_______________________________________________
pde-dev mailing list
pde-dev@xxxxxxxxxxx <mailto: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 <mailto: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 <mailto: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>
--
Aleksandar Kurtakov
Red Hat Eclipse Team
_______________________________________________
pde-dev mailing list
pde-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/pde-dev