Comments below.
On 10.05.2019 10:10, Vikas Chandra wrote:
>>If only the correct baseline were automatically set...
In a new workspace, for an API tooling enabled plugin, we always have
an "error" that tells the user that there is no baseline.
Quickfix takes you to the page where baseline is added. After that,
the user should understand and set the correct baseline.
Most of the the documentation is already there is Andrey's 1st email's
link ( setting correct baseline and versioning).
With the Oomph setup, the baseline is always set up automatically.
There are Oomph setups for the entire darned Eclipse SDK along with
detailed documentation:
https://wiki.eclipse.org/Eclipse_Platform_SDK_Provisioning
So when I'm asked to help fix issues in the e4 workbench model I use
exactly this approach to set up an IDE to work on the platform.ui
repository, complete with the baseline set, and it tells me properly
about problems resulting from regenerating the model. I didn't have to
read any instructions first.
But everyone else seems completely enamored with their individualized
manual approach, no doubt keeping a workspace/installation alive as long
as possible because creating a new one is so unpleasant.
>> And all the preferences too.
If you don't tinker with the preference, it remains the most optimum
one. There is an option of restore default in preference
page. ( in case you have changed preference)
If you have some good suggestion or ideas to improve and automate,
please feel free to open a bug and discuss.
Well, that's already done. But I'm told it can't be used, even though I
use it myself and it works for me. If something doesn't work, I can fix
that, but as I said, it works for me.
As an example of how easy it could be, just consider that these the only
instructions one needs to set up an EMF development environment:
https://ci.eclipse.org/emf/
Drag and drop and your done. All the necessary tools are installed,
the projects are imported, organized in working sets, the right
preferences are set for EMF development. And I've tried to make it just
as easy for *all *the platform's projects. But in the end, I can only
lead a horse to water...
Regards,
Vikas
------------------------------------------------------------------------
Eclipse PDE lead,
IBM Rational
EGL D Block - Bangalore, India
Office Phone No : +91 - 80 - 41776506
------------------------------------------------------------------------
Inactive hide details for Ed Merks ---05/09/2019 11:20:10 PM---If only
the correct baseline were automatically set... And all Ed Merks
---05/09/2019 11:20:10 PM---If only the correct baseline were
automatically set... And all the preferences too. I wonder how
From: Ed Merks <ed.me...@gmail.com>
To: platform-dev@eclipse.org
Date: 05/09/2019 11:20 PM
Subject: Re: [platform-dev] API changes in SDK
Sent by: platform-dev-boun...@eclipse.org
------------------------------------------------------------------------
If only the correct baseline were automatically set... And all the
preferences too. I wonder how we could possibly do that?
It seems pointless to me to record all these important details in an
email thread. Record them in a wiki, if you feel these are important
details that are best captured by documentation. Or perhaps consider
yet again that it might be better to record these details in a script
that is automatically applied and is used by everyone so that no one
needs to read wikis and/or email threads with excruciating, manual,
monkey-work tasks. The assertion appears to be that apparently
automation doesn't work for inexplicable (and certainly unexplained)
reasons. But for goodness sake, we are tool developers, surely we can
use tools for all this! The term Luddite comes to mind when I read a
thread like this.
On 09.05.2019 18:43, Vikas Chandra wrote:
I agree with Andrey in principle !
In short,*before submitting any gerrit patch, just keep the
default workspace settings and run API tools analysis
( clean->build all) after setting the correct baseline.*Ensure
that none of the settings has been made more lenient
(error changed to warning or ignore in project setting) in the
project.
There is always a quickfix - API tool filter which allows user
to override the API tool error based on user's
judgement/scenario. Common sense overrides everything :)
Suggestions on what can be improved in
API evolution/versioning would be good to have. However, if
version guidelines is not followed, then it can cause
confusion to the end users.
If *there is a suggestion for changing the default settings
that helps in overall API evolution*or any other suggestion,
please file a bug. ( One such bug is already filed by Dani ! )
Regards,
Vikas
------------------------------------------------------------------------
Eclipse PDE lead,
IBM
EGL D Block - Bangalore, India
------------------------------------------------------------------------
Inactive hide details for Andrey Loskutov ---05/09/2019
12:50:25 AM---Hi all, If you do *not* contribute or review
contributionAndrey Loskutov ---05/09/2019 12:50:25 AM---Hi
all, If you do *not* contribute or review contributions for
Eclipse platform
From: Andrey Loskutov _<losku...@gmx.de>_ <mailto:losku...@gmx.de>
To: _platform-dev@eclipse.org_ <mailto:platform-dev@eclipse.org>
Date: 05/09/2019 12:50 AM
Subject: [platform-dev] API changes in SDK
Sent by: _platform-dev-bounces@eclipse.org_
<mailto:platform-dev-boun...@eclipse.org>
------------------------------------------------------------------------
Hi all,
If you do *not* contribute or review contributions for Eclipse
platform
SDK, stop reading this mail NOW!
I wanted to remind you about some simple rules for Eclipse SDK
development, which are mandatory for all committers.
If the commit you want to merge contains an API change,
*before* merge
you should *always* load the patch into your IDE and run a
clean build
on related project.
Before doing so you should also make sure API tooling is properly
configured, you use right API baseline and preferences are
properly set:
Preferences -> Plug in Development -> [x] Workspace Plug-Ins
override
target platform plugins...
Preferences -> Plug in Development -> [ ] Disable API builder
(must be
unset!)
Preferences -> Plug in Development -> Target Platform is set
to "Running
Platform" and you are using a recent nightly SDK build.
Preferences -> Plug in Development -> API Baselines -> [x]
_latest_release_ (must be created manually and point to plain SDK
installation of the last official SDK release).
If after that you see API errors in the workspace, please
consider to
read the proposed solution, compare that with the information
you can
get at [1], [2] and [3] and apply appropriated fix (or "-1" on the
Gerrit patch).
There can be multiple possible API error fixes proposed by
PDE, but only
one can be the right one - unfortunately we still require the
power of
human brain to apply the *right* fix.
Please also note: human and computer make mistakes. Nobody is
perfect,
API tooling too. In doubt, ask on the list, but do not start
*decrement*
bundle versions or blindly increment them (because this always
fixes the
error, however may introduce a bigger one).
Basic rule is: during a development cycle (e.g. 4.12) we only
increment
one version segment *one time* according to the rules [1], [2]
and [3].
Only in case of human errors we have to bump the same version
segment
twice (once the wrong version is built and *published* we
can't simply
revert it so we must increase again...). We never decrement
versions if
they were already published via official SDK build.
Decision about *which* bundle version segment to change should
be always
based on [1], [2] and [3], not just on PDE "quick fix"
proposals. In
doubt - ask on the list.
Sure this is all complicated, sure this makes our life not
easier and
sure this could be improved and fully automated. But as long
as we don't
have an absolutely perfect, fully automated process we *must*
follow the
rules above.
There are also few places where you can help:
- Setup and use API tooling in your SDK workspace. Do it NOW!
- Improve API tooling by contributing to PDE. There are known
bugs and
there are known performance issues, but if nobody helps, they
will stay
forever.
- Contribute more maven checks that do *more* API checks
during Gerrit
build.
[1] _https://wiki.eclipse.org/Version_Numbering_
[2] _https://wiki.eclipse.org/Evolving_Java-based_APIs_
[3] _https://wiki.eclipse.org/Evolving_Java-based_APIs_2_
Regards,
Andrey
--
Kind regards,
Andrey Loskutov
_
__https://www.eclipse.org/user/aloskutov_
---------------------------------------------
Спасение утопающих - дело рук самих утопающих
---------------------------------------------
_______________________________________________
platform-dev mailing list_
__platform-dev@eclipse.org_ <mailto:platform-dev@eclipse.org>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit_
__https://www.eclipse.org/mailman/listinfo/platform-dev_
_______________________________________________
platform-dev mailing list
_platform-dev@eclipse.org_ <mailto:platform-dev@eclipse.org>
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
_https://www.eclipse.org/mailman/listinfo/platform-dev________________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
