Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Link to java sources into native fragments to compile them in fragments #1008

Merged
merged 1 commit into from
Jan 30, 2024
Merged

Link to java sources into native fragments to compile them in fragments #1008

merged 1 commit into from
Jan 30, 2024

Commits on Jan 30, 2024

  1. Link java sources into native fragments to compile them there in the IDE 

    For each native SWT fragment link the source-folders containing the java
classes used in that native fragment into said fragment's Eclipse
project. This allows to compile the java classes within the fragment
project already in the development workspace and consequently to develop
and test the code in the workspace using the same structure as the built
artifacts. If desired, the code of multiple/all fragments can be
checked-out and compiled at the same time, just by opening all desired
fragment projects.

The sources still reside within the org.eclipse.swt main/host bundle but
are not compiled there anymore in the dev-workspace. This allows to
share common code while defining it only once at a central location.
Also move the shared preferences into the 'binaries/.setting' folder and
link it as '.settings' folder in each native fragment. This allows to
share the same settings in all fragment projects, while defining them
only once, just like the code.

Previously within the IDE workspace, the SWT java-sources for a platform
have been compiled within the org.eclipse.swt project using a .classpath
file specially crafted for each supported window-system/platform.
Therefore when checking out the SWT sources in the IDE one had to rename
the '.classpath_${ws}' template for the desired platform to '.classpath'
to use it locally.
With this change this renaming is not necessary anymore.

Furthermore ignore all 'Restrictions' type API problem, since SWT does
only reference its own internal classes. Because SWT does not have
external dependencies internals of other bundles cannot be referenced.
Ignoring these kind of problems avoids the need to add filters to
suppress them.

Furthermore this change allows PDE API-Tools to remove the built-in
special handling of the org.eclipse.swt setup because now the API
baseline check within the IDE can happen simply in the fragment as it
exists in the baseline.
    @HannesWell
    HannesWell committed Jan 30, 2024
    Configuration menu
    Copy the full SHA
    9e1bbba View commit details
    Browse the repository at this point in the history