Move org.eclipse.swt.tools to platform?

[laeubi]

Currently we have some org.eclipse.swt.tools bundles (and a feature) in the SWT repo.

These depend on the RCP platform and therefore create a cyclic dependency to the platform repo (e.g. requires an i-builds repository). Also these are not really useful in a standalone SWT application therefore.

As platform already always uses latest SWT and we have a combinde/build/release it seems more suitable to have these things in the platfrom repo (like JFace) to decouple SWT more, and make it more independent.

The only dependency to platform will then be the target (for JSVG) and the parent pom, both things are "lightweight" and can be replaced easily with something in SWT directly if required.

[mickaelistria]

In general more *tools would make more sense in PDE IMO, because the target audience are plugin developers.

[HannesWell]

IIRC the SWT tools are specific to SWT development itself (aren't they?) and not relevant for other Eclipse Plug-in developers.
Therefore I would suggest to move them to https://github.com/eclipse-platform/eclipse.platform.releng.buildtools, where we already have tools for our own use.

Nevertheless I also see some advantages in having the SWT tools in the SWT repository as it simplifies keeping them in sync.

[mickaelistria]

OK, if SWT tools are only existing to maintain SWT...

Nevertheless I also see some advantages in having the SWT tools in the SWT repository as it simplifies keeping them in sync.

Then I agree with that and I believe that keeping things easy for maintainers is more important than trying to break build cycles that are not so annoying in practice.

[akurtakov]

There are 2 different kind of tools that shouldn't be treated the same way if we want to do the "right thing" (tm):

• https://github.com/eclipse-platform/eclipse.platform.swt/tree/master/bundles/org.eclipse.swt.tools.spies could (and probably should be ) moved to PDE as these are (at least used to be ) generally usable tools (leak/spy).
• https://github.com/eclipse-platform/eclipse.platform.swt/tree/master/bundles/org.eclipse.swt.tools is a JNI generator code that makes no sense to go into PDE as it has many things SWT hardcoded there (incl. paths IIRC). Back in the days people thought it's quite cool way and even extracted it in standalone reusable tool (https://github.com/fusesource/hawtjni) but with JNA, JNR and lately Java FFM it makes no sense and doing any work on it (other than removing no longer useful parts) is kind of time lost. Moving it to releng.buildtools doesn't make sense as it's not releng tool (not used at maven or I-build build time at all) but a tool which produces C code that's checked in git and used only during SWT natives bindings development . I believe it can stay where it is and be reduced till removed entirely.

[HeikoKlare]

https://github.com/eclipse-platform/eclipse.platform.swt/tree/master/bundles/org.eclipse.swt.tools is a JNI generator code that makes no sense to go into PDE as it has many things SWT hardcoded there (incl. paths IIRC).

This is correct. The state of the tooling has to (or should be) consistent with the structure of the native implementations at a commit level, so they should not be separated (in particular when considering that the tools should eventually be removed anyway).
There is just a current example that requires the synchronous change of tools and native implementation: https://github.com/eclipse-platform/eclipse.platform.swt/pull/2054/files#diff-d6145677438eb54419076d939462d8a0c8eee449f6ca28e351980888ba3fb79d

[laeubi]

So can we agree to at least move org.eclipse.swt.tools.spies to PDE then like we already did with the e4 spies (+the feature)?

Also I wonder if we need to build/deploy/release the JNI generator at all it seems more like a tool used inside the IDE (where it does not matter it depends on platform)

[HeikoKlare]

Also I wonder if we need to build/deploy/release the JNI generator at all it seems more like a tool used inside the IDE (where it does not matter it depends on platform)

Isn't that already the reason why it needs to be deployed? In my understanding, it needs to be installed in your IDE (it adds a specific project builder). Otherwise you would have to always start a runtime Eclipse to modify native-related code in SWT with the according tooling for auto-generating the JNI code.

[akurtakov]

So can we agree to at least move org.eclipse.swt.tools.spies to PDE then like we already did with the e4 spies (+the feature)?

That's fine by me.

Also I wonder if we need to build/deploy/release the JNI generator at all it seems more like a tool used inside the IDE (where it does not matter it depends on platform)

To me it doesn't matter whether I install JNI generator from I-builds repo or from some other repo that's built and auto deployed from swt master build via some profile (or some other means). Going that path shouldn't be a problem IMHO.

[laeubi]

To me it doesn't matter whether I install JNI generator from I-builds repo or from some other repo that's built and auto deployed from swt master build via some profile (or some other means). Going that path shouldn't be a problem IMHO.

I more think that simply import the project should be enough (@merks correct me if I'm wrong and its actually fetched from the ibuilds) or elsewhere.

[akurtakov]

Import the project is not enough as swt.tools has to be installed in the working IDE as plugin for the builder that generates the native files to actually work.