We Keep Coding

How to rename packages and classes programmically?

I have a code base scattered across tens of repositories.
I want to standardize names of packages and classes, but it's too tedious to do it by hand in IDE, since I need a dictionary based renaming across repositories.
Is there a way programmatically rename classes and packages across many repositories?
A similar thing for a different language: https://metacpan.org/pod/App::EditorTools

Eclipse, and just about every other major IDE, can do this rather trivially. Load the project into the IDE (most can read the project if it is built by maven or gradle, just by saying you want to 'import an existing maven java project' or some such, possibly after installation a maven and/or gradle plugin - if it's not a project built by such tools, then just import an existing java project and tell eclipse about where the source files live).
Then, right click the package, pick refactor/rename, rename it, and eclipse (or intellij, or any other major java IDE) will rename the directory, update the package statement in every source file inside it, and will update all imports or any other reference, and will even search for strings that contain that exact name in case you're doing weird reflective shenanigans and tell you that those probably also need to be updated.
It's not quite programmatic, but this sounds like it'll be much easier and faster than actually using e.g. ecj or writing an eclipse app that will run without a user interface to apply these refactor scripts.

How to limit BuildShip (gradle eclipse) integrated functionality?

Now that I am using gradle for all of my new development, I'm running into issues with BuildShip features I really don't want.
For instance, when I hit the Run hotkey when I have a unit test open in Eclipse, I only want it to run as a JUnit test, alone. But Gradle has inserted its own hooks and option, which means extra clicking or keypresses beyond the one-stroke hotkey I have assigned to Run that I can tell it I want JUnit. (The gradle test option actually runs all tests, which takes minutes.).
Question: Is there a way to remove this hook in gradle without diving into the source code and ripping out functionality myself?
This isn't the only interference (interfering with run last is another), but it's my #1 annoyance about BuildShip.
Essentially, I want this popup to stop happening.

Indeed you cannot change the available launchers prompt but you can change the default hotkeys related to each launcher and directly use the one you prefer.
From Windows > Preferences > General > Editor > Keys you can get the list of available hot-key mappings. Filter the (long) list by typing test as show below:
As you can see you have several mappings for running JUnit tests: Gradle, JUnit runner, Maven.
The default configuration for JUnit runner is Alt+Shift+X,T, not really user friendly I would say.
I changed it to a more concise Alt+U down in the Binding option and applied the changes. Now you can run any JUnit test on its open editor windows without any prompt, simply type Alt+U and the JUnit runner will be triggered automatically for that single unit test.

This is a major usability annoyance in Eclipse+Buildship. I perform the following steps every time Buildship upgrades to get rid of that annoying popup, and also avoid the (for me, useless) Gradle test process when what I really want is for the last test to run while I am not in that particular class. Admittedly, this is invasive, but it works while keeping the "good" parts of Buildship.
Open up the plugins folder and look for the org.eclipse.buildship.ui_*.jar. (I do this on a Mac, which requires showing the contents of the Eclipse.app first.) Open the .jar file in some zip file editor which can modify files within the zip file (I use BetterZip on Mac, I think Winzip and 7Zip probably work too.) Edit the plugin.xml file.
This is for the new Photon 4.8 release of Eclipse. Remove (or comment out) the following two sections:
The <command> element with id="org.eclipse.buildship.ui.shortcut.test.run"
The <extension> element with the comment <!-- "Gradle Test" entry in the "Run as... " context menu --> above it (about 30 lines)
Save the file, which should be noticed by BetterZip/Winzip and let it update the .jar file with the changed content. Finally, eclipse needs to be restarted with the -clean switch so that it does not use a cached copy of the jar file. For example, on Mac:
cd /Applications/eclipse-jee-photon-R-macosx-cocoa-x86_64/Eclipse.app/Contents/MacOS
/.eclipse -clean
Buildship will now no longer bother you with that popup or run the Gradle test within Eclipse, because the UI entry points have been removed. Unfortunately, on the next update of Buildship you need to repeat the process again on the new jar.

Eclipse: auto execute and generate code on save

I'm using Eclipse and I wanted to create a system that automatically generates java source code every time I save the project. More precisely I want to search for some files in a directory, generate static attributes for each of them and generate some methods every time the project is updated/saved. I thought that a piece of code that could be auto-executed by Eclipse would be fine, but I don't know if it's even possible. How can I achieve this behaviour?

You can specify a program or Ant script to be run when a project needs building in the 'Builders' section of the Properties for a Project.
You can also write an Eclipse plugin 'Incremental Builder' using the 'org.eclipse.core.resources.builders' extension point. More information about this in the Eclipse help.

Eclipse has an extension point for cleanup and save actions that will be executed when you a save a file.
This requires implementing and installing a custom Eclipse plugin, so it's more intrusive than using a builder to run a script, but also more flexible, since you can use the JDT API to inspect the Java model of the given file.

I personally use :https://github.com/mystilleef/eclipse4-smartsave
Just from marketplace eclipse4-smartsave or as on page other solutions.
Plugin sometimes hangs, still it is great.

Is a CompilationParticipant bundle usable in a headless PDE build?

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.

Purpose of the "Build Automatically" option in eclipse

What is the purpose of Build Automatically option in Eclipse (Project-->Build Automatically)? Mine will always be checked. But when ever I have some java code changes I still have to do a full build. I was told that it should always be checked. I don't see any benefit in doing so. Please somebody explain.

Eclipse has a good answer on their website:
You have two modes of working: auto-build mode and manual build mode. By default, you are in auto-build mode and Eclipse takes care of compiling source files automatically. Builds occur automatically in the background every time you change files in the workspace (for example saving an editor). Auto-build is convenient because it means problems view, binaries, etc. are are up-to-date at all times. The downside is that in large workspaces auto-builds can be time-consuming if you are changing files in projects with lots of downstream dependent projects.
If auto-build is taking too long and is interfering with ongoing development, it can be turned off. Once in manual build mode, the user is in complete control over when builds occur and what gets built. Project > Build All (Ctrl+B) can be invoked at any time to trigger what auto-build was doing automatically. This allows you to build up a larger set of changes before invoking a build (Eclipse remembers which files have changed so that it does not have to do more work than required when you do ask for a build.
Note that when they say "auto-build mode" they mean if you have checked "Build Automatically", when they say "manual build mode" they mean you do not have "Build Automatically" checked.

Yes, you still have to do a build - but it's done automatically when you save (not an external build like an Ant build, but the "internal" build). If you didn't want to build on save, you'd uncheck the box. Having it build automatically makes some people nervous, I believe.

NOTE
For C/C++ users it's told (from help.eclipse.org):
By default, the Eclipse workbench is configured to build projects automatically. However, for C/C++ development you should disable this option, otherwise your entire project will be rebuilt whenever, for example, you save a change to your makefile or source files. Click Project > Build Automatically and ensure there is no checkmark beside the Build Automatically menu item.

Project - Disable Autobuild option does not always mean autobuild is off. For example "Makegood" test automation plugin will trigger autobuild when Preferences - Run/Debug - launching - (General opt) Build before launch is ON. So turn it off if manual build needed.

One thing that people didn't mention here (and it took a while for me to figure this out too) is that eclipse build (either automatic or manual) would basically follow what you have outlined in the project's "Java Build Path" source tab. So when a file is covered in that build source tab, when you change the file, it gets copied/compiled to the output folder that was specified for that directory/file.

One more difference is:
Most of the time while working on JSPs it helps me when checking "Build Automatically". It automatically picks up the changes in JSPs.
But if you make changes in your java classes/XMLs you need a manual build.
Since I'm using resin server which is run outside eclipse via command prompt, i prefer checking the option.
When i have my server setup in eclipse, i turn it off and use Publish on server.
This is the way i use and the answer is based on my experience.

If Build Automatically is checked, the IDE will automatically compile your Java code whenever you modify and save a file. This does not mean it will completely build and package your entire solution as if you were going to deploy it such as if you are working in a Web project on a WAR module. It basically really just compiles your code.