Has anybody made DDT (D Development Tools) to work on Eclipse Juno? When I try to install DDT it complains about wrong version of the DLTK.
Update: Since DDT verion 0.8 Eclipse Kepler and DLTK 5.0 is supported by default.
It is possible, but you need to install an old dltk version until DDT author ports it to new one.
Relevant comments: http://code.google.com/a/eclipselabs.org/p/ddt/wiki/Installation
Quoting Bruno:
The http://download.eclipse.org/releases/indigo update site contains DLTK 3.0,
so the installation should still work as described above. There might be a problem if
Eclipse update actually finds DLTK 3.0 but also finds 4.0 and is trying to install 4.0 if
some other plugin requires version 4.0. Make sure Eclipse is not trying to get updated
to 4.0 .
Related
I had Dart 2.1 v, then i update with
brew upgrade dart
After that i can check dart version:
brew info dart
Everything its fine, now is 2.7 v. But when i want to create a new project on IntelliJ IDEA still with 2.1v, i know i need to change, but on preference options "languages & Frameworks" Dart is not there.
You don't have to/can not change the Dart version for new projects in IntelliJ settings. Just be sure to use the correct Dart SDK path (e.g. the SDK that you have updated to 2.7) when creating a new project.
In pubspec.yaml you can see that the Dart version is >= 2.0.0 && < 3.0.0, so the project always uses the Dart version of the specified SDK. Thus your projects will always use the latest version of Dart 2.x. All minor updates within version 2.x are backward compatible, so there is no problem to always use the latest version.
I was setting up a new laptop and downloaded Eclipse: Version: 2019-12 (4.14.0) but when I tried to add the LDT plugins, it fails because it cannot satisfy dependency (see below.)
The prior version of eclipse I had on my last laptop was 2018-12 (4.10.)
Does anyone have a list of what or know which the last/latest version of Eclipse which works with the (1.4.2?) LDT plugin is?
[[EDIT]] => Verified that Lua Development Tools still installs if I reinstall 2018-12 Eclipse. So it is a compatability thing as I asked. Since no one yet has the answer, I will install one after another Eclipse version to determine last that works and update this entry. VERIFIED: 2019-09 is the latest that works with LDT plugin.
(pointed repo to "stable" (although tried even nightly after that)
Error message:
Cannot complete the install because one or more required items could not be found.
Software being installed: Lua Development Tools SDK 1.4.2.201804031433 (org.eclipse.ldt.source.feature.group 1.4.2.201804031433)
Missing requirement: Lua Development Tools Core 1.3.0.201804031433 (org.eclipse.ldt 1.3.0.201804031433) requires 'osgi.bundle; org.eclipse.dltk.core [5.5.0,6.0.0)' but it could not be found
Cannot satisfy dependency:
From: Lua Development Tools - Core Feature 1.4.2.201804031433 (org.eclipse.ldt.core.feature.group 1.4.2.201804031433)
To: org.eclipse.equinox.p2.iu; org.eclipse.ldt [1.3.0.201804031433,1.3.0.201804031433]
Cannot satisfy dependency:
From: Lua Development Tools 1.4.2.201804031433 (org.eclipse.ldt.feature.group 1.4.2.201804031433)
To: org.eclipse.equinox.p2.iu; org.eclipse.ldt.core.feature.group [1.4.2.201804031433,1.4.2.201804031433]
Cannot satisfy dependency:
From: Lua Development Tools SDK 1.4.2.201804031433 (org.eclipse.ldt.source.feature.group 1.4.2.201804031433)
To: org.eclipse.equinox.p2.iu; org.eclipse.ldt.feature.group [1.4.2.201804031433,1.4.2.201804031433]
The key error here is
requires 'osgi.bundle; org.eclipse.dltk.core [5.5.0,6.0.0)'
which is saying that a version of the 'org.eclipse.dltk.core' plug-in (bundle in OSGi terminology) with a version of at least 5.5.0 and less than 6.0.0 is required.
The Eclipse 2019-12 release has version 6.0 of this plug-in so it does not match the criteria and the install fails.
I installed earlier versions of Eclipse IDE (Java) and it appears the version right before the one I was trying (2019-12) is the last that will accept installing the LDT plug-in successfully: Eclipse (Java) 2019-09
Hopefully it is a bug that gets fixed in either LDT or Eclipse 2019-12.
There is a workaround that I found here: https://www.eclipse.org/forums/index.php/t/1101907/
The solution is basically to provide the missing resource from a download since it doesn't seem to be available from repositories any more:
Download the runtime for DLTK 5.7.1 as a zip: http://www.eclipse.org/downloads/download.php?file=/technology/dltk/downloads/drops/R5.7/R-5.7.1-201703020501/dltk-core-R-5.7.1-201703020501.zip
In Eclipse, navigate to menu > Help > Install new software...
Click Manage... to go to Available Software Sites dialog
Click Add... use a good name like "LDTK zip", click the "Archive" button and browse to that zip, downloaded from before.
Then when I tried again the install happened correctly and my initial tests indicate that LDT is working as expected.
Xtext 2.0 was released with Eclipse Indigo (3.7).
Xtext 2.3 was released with Eclipse Juno (3.8/4.2).
I have developed a plugin with Xtext 2.3. I tried to install it on 3.7 but it installs Xtext 2.0.1 as a dependency, and then the editor does not seem to work. If I use Xtext 2.3 does it mean my clients have to use Juno or later, or is there another solution?
Xtext 2.3 can be installed over Indigo as well using the update site http://download.eclipse.org/modeling/tmf/xtext/updates/composite/releases/ Simply add it in the Add new software dialog, and then you can install it.
On the other hand, if you want your code to work with Xtext 2.0, then you have to modify (and test) your code with Xtext 2.0 as well, at the minimum you have to update the dependencies in manifest.mf files, and also might need to regenerate the editor with Xtext 2.0, and possibly modify some of your manually written code.
I am developing an Eclipse Plugin and want most of the features to be compatible with Eclipse 3.4.
Until now that was no problem because we could just use eclipse 3.4 in the build process, so compiler errors would be found easily.
Now we have a new feature that requires eclipse 3.5 and we cannot use 3.4 for the build any longer but have to use 3.5 at least. The problem now is that we dont know if the old features are still compatible with eclipse 3.4. (at least not by automatic build)
Is there any smart solution to this problem? Make sure some of the plugin features are compatible with eclipse 3.4 and some with 3.5? Preferably a solution that can be automated and added to the build process.
Build your 3.5 plugins with a 3.4 target. Then you'll see which problems ouccurs :).
After you have identified your bundles which are using new features only avialable in 3.5 set in your MANIFEST.MF the version number of the dependeny to the used version in 3.5, so that resolving the dependencies of your bundles in a 3.4 target will fail.
In general I would recommend that you should setup your target you're building against in your IDE, to get notified about possible problems while you're writing the code, not when building your plugins.
To make a bundle plugin runnable in a 3.4 and in 3.5 with the new features there will be no easy solution, the probably easiest way is to split the bundle and isolate the 3.5 features in a new bundle, so that your plugins can also be run in a 3.4 environment.
In addition to toms' answer, I would recommend that you run your test suite during a headless build against a 3.5 eclipse as well as a 3.4 eclipse.
The way that we do this in our own shop is this, with 4 automated build jobs:
Build the product against a 3.5 target eclipse
Run the tests on the 3.5 target
Build the product against a 3.4 target eclipse
Run the tests on the 3.4 target
If the 3.5 target fails, then we don't build a 3.4 target. (Of course, in our case, we are doing 3.6 and 3.5 (and starting to introduce 3.7)).
Is there a way to build an Eclipse Update Site so that Eclipse 3.3 will install one version of my plug-in while Eclipse 3.4 will install another version? The feature spec allows for "optional included features" but I can't see how to make them conditional on the version of the target.
Background: I've become responsible for an Eclipse extension that has half a dozen plug-ins which depend on a "support" plug-in, and the support plug-in needs to be one version for Eclipse 3.3 and a different version for Eclipse 3.4/3.5. I currently have two separate features, "extension for 3.3" and "extension for 3.4+" but I'd like to not bother my users with this detail.