So I've been hit by an Eclipse bug. \o/
Long story short, either I've got to install an old Eclipse and set up a bunch of workspaces from scratch (a laborious process that'll take half a day at least) or I can run a few specific ant commands manually. However I can't seem to find a way to extract the full command from a specific external tool configuration.
Any ideas? Or will I have to build the commands manually (a few properties, a custom ANT_HOME and alternative JRE make them a bit lengthy).
Not really the direct answer, but the best solution to my problem...
You can revert updates in Eclipse. In my case the bug was introduced by 4.7.1 and I had originally installed 4.7.0 so I simply reverted those updates and it restored the feature I relied upon (running ant in an alternative JRE).
Related
I am new in Scala, so sorry if the question is absolutely obvious.
I have an Eclipse Photon installed on my computer. Would like to edit Scala code and produce runnable jars. The tricky part is that I don't have internet access on my computer (Centos7).
I bear in mind two potential issues/questions:
Downloading the plugin manually: I know, that Scala IDE plugin for Eclipse enables running Scala code/producing jars (like https://medium.com/devilsadvocatediwakar/how-to-install-scala-plugins-in-eclipse-in-ubuntu-13e53ffe3f39). Installing it from the GUI is rather straight forward. Is it possible to download a plugin bundle manually (not from GUI), move it to target computer and finally install it?
Compiling code into jars: assume that the point 1 is done. SBT or Maven requires some dependencies (e.g. Yoda time, Spark libraries) to produce specific jars - does it cause, that all the dependencies shall be moved and installed manually also?
The answer was provided by the Luis Miguel Mejía Suárez in comments:
Yes you can. For installing a manual plugin - here you can find the
zip of the ScalaIDE - and finally, use the maven repository to search
and download the dependencies JARS... However, is this really your
personal computer? or some kind of deployment server? - Also, as an
ex-user of the ScalaIDE I would recommend you to try a different,
newer IDE. For example, I just switched the last week from Eclipse to
VSCode with metals.
I am using Eclipse Mars and I have the following problem.
After the installation of a plugin, the Adoe Flash Builder plugin, it is a plugin that is installed outside Eclipse (executing an installer and selecting the Eclipse folder) I have some problem.
The plugin installation failed (because this plugin is supported only on the 32 bit version of Eclipse). So the plugin was not completly installed.
When I start Eclipse I obtain a lot of error messages caused by this failed installation and it is impossible to me work.
So I have tried to disinstall this plugin but it doesn't give me the possibility to uninstall it (the Uninstall button is disabled).
Here the screenshot where you can see that, selecting the plugin that I want to uninstall, the Uninstall button is disabled:
Why? Can I manually delete this plugin in some way? (I have not directory related to it into my Eclipse folder). It seems that in some way Eclipse have the information of this plugin but that this is not effectively present. How can I remove it? Or is faster reinstall and configure again my environment (Eclipse + SVN plugin + project configuration)
I have tried sometimes to get rid of "messed up" eclipse configurations.
In the end, it just didn't work out. I always ended up throwing away everything.
Besides: Eclipse Neon R2a was released already; so just download that and say goodbye to Mars.
And the real answer (in my opinionated eyes): I decided at some point to enable myself to install eclipse "from scratch" as quickly as possible (for example by having automation where possible; and "checklists" to follow where manual interaction is required). Simply because "installing from scratch" helps avoiding a lot of problems over time.
And while we are talking about eclipse best practices: if your OS is Linux, consider to switch to git-svn instead of SVN. Your machine still talks SVN to the remote SVN server, but you can enjoy the full beauty of git locally. No more SVN plugins, no more hours of waiting for that SVN plugin doing refresh ... I can't tell you how much time that simply change saved for me.
Is it anyhow possible to force a running Eclipse to clean and rebuild from command line in linux or time triggered?
I have a workspace with hundreds of Maven projects that have to be cleaned an rebuild after a file change automatically. The file change is happening every night triggered by a cronjob which runs svn update followed by a mvn clean and a mvn install at the end. Eclipse itself sees those source changes and rebuilds automatically (native hooks) to keep being up to date. But because of unknown reasons it does not rebuild completely. A lot of errors and warnings remain. Those errors disappear only if I clean the whole Eclipse workspace which then results in an automatic rebuild in Eclipse. This rebuild takes a long time (> 1 hour). I don't want to spend this time every day. So I'm looking for a automatic way to force a complete clean and rebuild of my workspace of a running eclipse over night.
I can't restart eclipse over night.
One idea is to clean Eclipse from outside (but how?) to let it notice the change by itself. Eclipse might then rebuild automatically.
As far as I'm aware, there's no predefined way to trigger this from the outside. So I'm going to propose a strategy which can achieve what you need. This touches on a lot of advanced topics so I'm only going to provide some pointers to get you started, because bringing all the details will be too much for this format. It would probably make an excellent blog article tho. So here we go:
Write a plugin for your Eclipse.
This plugin hast to expose an MXBean with a Clean-and-Rebuild operation. Use the JDK tool jconsole to check the operation's accessibility.
That operation in turn executes the clean and the full rebuild commands. You can use the Eclipse Plug-in Spy to find the appropriate command contributions, and/or scour the Eclipse source code.
Then, you need to build a custom JMX client which invokes that MXBean operation from the outside. This is basically a stripped down version of jconsole's JMX capabilities and can be a simple Java command line app your cron job calls. It needs to connect to your local Eclipse instance and invoke the operation you defined earlier. In order to find the correct instance to connect to, your Eclipse plugin could write the port of the instance's MXBean server to a file your JMX client looks for at startup.
EDIT: In addition to the clean and rebuild commands, you'll want to invoke a full refresh of the workspace beforehand.
I've written a plugin that uses the org.eclipse.jdt.core.compilationParticipant extension to gather some compile information to be used elsewhere. I've tested in multiple versions of the Eclipse IDE and it works like a charm. My ultimate goal is to be able to use it in a headless production PDE build. I've added some logging to the bundle so I am aware when it starts up, when it shuts down, and when source compilation occurs. The problem is that these events never get caught in my headless build buy the participant. The headless PDE build is kicked off by starting the equinox launcher from an ant script that runs the antrunner executing the PDE build script. There are so many scopes of execution involved I'm unsure where to start looking. My first question is, is what I'm trying to do even possible? It didn't seem like the CompilationParticipant would only work in the UI, but I want to make sure before I go down the road of debugging this. Has anyone ever done this?
I tried to add a comment, but I'm too wordy so I will try to clarify here a bit. Unfortunately I can't do much to change the build system except to apply hooks like I am attempting. I did spend some time running through the ant scripts that PDE generates and see the it is calling the JDT compiler adapter which made me curious if the JDT compiler adapter could reference the compilation participant since it is running ant from the plugin and should have access to the framework, and it seemed to be the intent of the participant API to allow the hooking of the JDT compiler to do things like the implementation of the APT processor and other DSL implementations. That was my read on the intent of the participants, and assume they would be available in a headless build since the APT processor works, but since I can't find a really good tutorial I'm kind of putting things together piecemeal and I'm guessing I'm missing something, or at least I hope so..
It is true that PDE is generating ant scripts and calling the javac task, but it is also setting the build.compiler property to use the JDT compiler and therefore I would assume have access to the OSGi framework. Here is a snippet from one of the generated build files to show what I am talking about:
<compilerarg line="-log '${temp.folder}/pde.example3.jar.bin${logExtension}'" compiler="org.eclipse.jdt.core.JDTCompilerAdapter"/>
Debugging org.eclipse.jdt.internal.core.JavaModelManager reveals that the JDT compiler is in fact being used but getRegisteredParticipants is not being called for some reason, startup() is however being called, so the question it why does it not try to register participants.
After spending hours in the debugger attaching to the various VMs that spawn during my build process I was able to determine the flow through a PDE build. I don't believe that CompilationParticipants come in to play, in fact I don't even think the JavaBuilder is called. It looks like the execution path is something like the following:
Ant spawns my VM which starts the Equinox Launcher which starts up the OSGi framework and instantiates the AntRunner application, this in turn starts ant from the Elcipse Ant plugin that runs the build.xml file from the PDE plugin, the Build.xml file generates all the ant scripting used to generate the eclipse plugins which includes setting the build.compiler to the JDTCompilerAdapter which wraps the Eclipse Java Compiler ( originally based on Visual Age for Java ). The JDTCompilerAdapter does some setup and instantiates the org.eclipse.jdt.internal.compiler.batch.Main class which does the real compilation, and also instantiates the org.eclipse.jdt.internal.compiler.apt.dispatch.BatchAnnotationProcessorManager class to handle annotation processing. Nowhere in this path of execution are participants notified, and the JDTCompilerAdapter seems to be specifically designed to be able to be used outside the OSGi environment in ant. so it looks like CompilationParticipants will not give me what I need in a headless PDE build using the antrunner..
AFAIK PDE build is "just" a fancy way of generating a lot of Ant-scripts, and I belive it just uses the javac target to compile files. You can check that after the PDE build has run, by going into your source folders, find the Ant-script, and check.
If what you do is important for the build, I would recommend that you check out Buckminster. It is a build tool designed of OSGi applications. It is special in the sense, that it actually builds in an Eclipse workspace, so it uses the same builders and stuff like CompilationParticipants as you do during development, assuming you have installed the plugins in the headless build-application.
Well after tons of debugging, reading docs, and stepping though the PDE sources it seems like this can NOT be done. It seems in a headless build the execution of the JDTCompilerAdapter is designed to work outside of OSGi and does not have access to the framework it is simply called from the javac task and does NOT involve the JavaBuilder and therefore does not call any participants.
I've developed an Eclipse (3.5) plugin for my employer (a university) using Graphical Editing Framework (GEF).
Deploying the app should be as simple as pressing the "Export Wizard" link and entering an archive name and hitting "Finish" (shown in the images below).
But then I encounter the an error dialog protesting "Could not find one or more classes: "org.apache.tools.ant.launch.AntMain". Please check the Ant classpath."
But I've looked inside the Eclipse>Preferences>Ant>Runtime>ClassPath and found everything to be in order.
What's wrong? How do I set the class path so I can deploy my plugin.
UPDATE:
I'm using Mac OSX Leopard for development.
I also correct the ANT_HOME settings in preferences>Ant>Runtime>ClassPath to /Applications/eclipse/plugins/org.apache.ant_1.7.1.v20090120-1145 as others have suggested
The Export Wizard Link http://img199.imageshack.us/img199/5766/picture4ro.png
The Export Wizard http://img134.imageshack.us/img134/9534/picture5gf.png
It does not seem to be related to eclipse 3.5 (it has been reported with eclipse3.2 or 3.1.2).
In one case, it was because the build was using:
-Djava.endorsed.dirs
which happened to point on an old Ant version.
Another said its Ant->Runtime / "Ant Home" was erroneously set to the current project dir.
setting it to /usr/share/ant makes ant work properly. (But you said that "eveything was in order" there).
A third had to manually add
/usr/lib/eclipse/plugins/org.apache.ant_1.6.5/lib/ant-launcher.jar
to the Ant classpath in the preferences to make it work.
It all boils dow to an older version of Ant being somehow referenced.
I tried for far too long to solve this problem, so I resorted to the good ol` truism, "Java hates OSX" and decided to try the whole process on Vista... and BAM! worked first time, no issues.
So, the answer to my question is "Don't use OSX, use Windows or Linux".
I'm not a jerk so I posted this platform bug in Eclipse bugzilla.
VonC was indeed awesome enough to give me really good advise and point to other bugs I couldn't find.. he deserves more votes..