|
+1 for using Oomph setups.
If there wasn't an Oomph setup available for the Platform
projects, I would probably not even started working on the
platform project at all.
Having used Oomph in multiple projects, I can tell it makes
bootstrapping your environment something you do over your coffee
break. No need for long complex procedures, and consistency
between the setups of all developers.
Op 5/10/2019 om 11:26 AM schreef Ed
Merks:
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
_______________________________________________
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
|
