|
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
------------------------------------------------------------------------
 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.merks@xxxxxxxxx>
To: platform-dev@xxxxxxxxxxx
Date: 05/09/2019
11:20 PM
Subject: Re:
[platform-dev] API changes in SDK
Sent by: platform-dev-bounces@xxxxxxxxxxx
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
------------------------------------------------------------------------
Andrey Loskutov ---05/09/2019 12:50:25
AM---Hi all, If you do *not* contribute or review
contributions for Eclipse platform
From: Andrey Loskutov <loskutov@xxxxxx>
To: platform-dev@xxxxxxxxxxx
Date: 05/09/2019 12:50 AM
Subject: [platform-dev] API changes
in SDK
Sent by: platform-dev-bounces@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
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@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
|
