We Keep Coding

Sonarqube - how to enable license-checker for Kotlin projects?

I'm setting up a Sonarqube Developer Edition server and am trying to use the license-checker plugin I got from:
https://github.com/porscheinformatik/sonarqube-licensecheck
The plugin's jar is deployed to the correct directory and I have created a new Sonar way (license) Java profile that inherits the profile Sonar way (Built-in). In the new profile, I added the "License is not allowed" and "Dependency has unknown license" rules the plugin requires to work. I tested with a Java project and it works flawlessly.
I tried the same approach for the Kotlin profile Sonar way (license) I created and that inherits the Sonar way (Built-in) profile. But these rules are not available to Kotlin and, thus, the License check plugin does not run when I attempt to analyze a Kotlin project.
This seems to be a Java-specific plugin, but I might be mistaken. Is there a way to get this working I am not realizing?

Long story short, the plugin does not support my scenario.
Long story, my question was not clear enough and I failed to put some information as I was learning about this build myself. The project is in Kotlin and uses gradle to handle dependencies. The plugin only supports maven and NPM builds. So, for my to achieve the desired result, I would need to extend the plugin to handle the build.gradle.kts file. This task is a very big question mark in itself, so I will be looking at another alternative for the time being.

Launching an Eclipse 3.x RCP Application using bndtools

I have spent the past few days trying to find a solution to my problem. I am trying to launch an Eclipse RCP using the 3.x compatibility layer using the bndtools launcher via a bndrun file.
I am aware of the solution which involves placing bndtools.runtime.eclipse.applauncher in the list of run bundles in order to get an E4 application to start and that there are ways to migrate an E3.x application to E4. We would like to maintain programmatic control over the Rich Client Platform for the time being so migrating to an XMI file for laying out the Workbench is not ideal at this time.
I created a plug-in project which builds using bndtools. To my knowledge I have included all of the necessary bundles to run the application and have followed several examples (as an aside, most of the OSGI examples I found were console-based).
Because I wasn't seeing the RCP load up (we have an RCP plug-in which extends the IApplication interface and our project structure is still Activator based) I was initially at a loss as to why this wasn't working but adding -osgi-console= to the run properties did provide some additional information:
Using -runfw: org.eclipse.osgi
The final lines are the following:
# framework=org.eclipse.osgi.launch.Equinox#59fa1d9b
# registered launcher with arguments for syncing
# will wait for a registered Runnable
Additionally, the plug-in I am using to test with is marked as STRTD and the bundle that is using it is also marked as STRTD whereas most other bundles are marked as ACTIV, which I assume is also part of the problem. I have tried to force bundles to start by including a line to start several bundles (following other examples) but have run into issues where the console will error stating could not load or find main class for org.eclipse.core.runtime when trying to include that in the list of activated bundles.
Googling (and even Binging) have not appeared to produce a solution which explains how to set up an Eclipse 3.x application to run using a bndrun file. What am I missing? Most recently I tried the following properties:
-runproperties: \
osgi.os=win32,\
osgi.clean=true,\
osgi.console=,\
eclipse.product=org.eclipse.sdk.ide,\
osgi.arch=x86_64,\
osgi.ws=win32,\
equinox.use.ds=true,\
eclipse.application=org.eclipse.ui.ide.workbench
I assume that if the actual test bundle I am using would actually activate that I should also be able to find the application ID set in the plugin.xml file and to use that instead. Trying to activate that plug-in also results in a could not find main class error even though I specify a Bundle-Activator in the bnd file. That Activator does not appear to be started since I have it set to print to the console and nothing is printed. I assume that since the bundle is in the STRTD state that it did not start.
Any help with this would be appreciated.
Edit:
As an update, adding org.apache.felix.gogo.runtime and org.apache.felix.gogo.shell did result in my test plug-in's activator getting started. Curiously the plug-in it is dependent on, though, moved from STRTD to RSLVD.
Other discussion has indicated that we might have to manually start an Eclipse instance using EclipseStarter?

The following Github repo contains using an example with bndtools and Eclipse 3.8. It uses an adapted bndtools.runtime.eclipse.applauncher inside /cnf/eclipse_common_3.8/bndtools.runtime.eclipse.applaunch-0‌​.1.0.jar see the 3.8 bnd launch config also include here example.aspectj/example.aspectj.bnd.app/run/launch_org.eclip‌​se.osgi_3.8.x.bndrun‌​. This was (beside the Aspect stuff demoed in the repo) the smallest set of bundles to startup an Eclipse app successfully with bnd.

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.

Register Bundles in the PluginRegistry?

I'm trying to load OSGi Bundles from an arbitrary folder at runtime in order to use them in my Eclipse RCP Application. The following steps I have done so far to achieve that objective:
Create a new Plugin
Acquire the BundleContext from the Plugin Activator
Install a Bundle via the install() method of the BundleContext
Start the acquired Bundle via the start() method
After these steps the Bundle is in status ACTIVE and can be retrieved via any BundleContext. My problem is that the bundle cannot be retrieved via PluginRegistry.getAllModels(). Apparently the PluginRegistry is not listing to changes in the BundleContext. I need find a way to register my Bundle in the PluginRegistry. This is important because the PluginRegistry is used by already existing software parts, e.g. the Manifest Editor.
The PluginRegistry has no method to register Bundles. Is there a way to add them to the registry?

The PluginRegistry class is a development time class supporting the PDE. Does this mean that your RCP application includes the PDE and is used (in part) for plugin development? If this is true, then you will need to work out now PDE works (which is something I don't know much about). I recommend having a look at the classes in the org.eclipse.pde.runtime plugin (not the internal classes). You should be able to work out with the debugger and looking at the code how to add a plugin to the PDE runtime. If you have further questions about that, use the PDE newsgroup at the Eclipse site.
If your RCP application does not include plugin development, then there is no need to work with the PluginRegistry at runtime, so I'm confused by your question. Perhaps you could elaborate more?

During the development of Acceleo, we stumble upon this problem too as we need to let the user deploy Eclipse plugins, located in its workspace, in the running Eclipse instance (we also need to uninstall those plugins after that). Since Acceleo is open source, you can have a look at our source code on github.
I won't detail everything here but you should find what you are looking for around the line 880 and after around the line 752. The file linked is our utility class for manipulation of Eclipse plugins in the workspace and Eclipse bundles in the running instance so you can find there pretty much anything needed to handle your problem.
Small warning, when we are deploying on the fly an Eclipse plugin located in the workspace, we deactivate its plugin.xml. Since most of the Eclipse tools are just looking at the plugin which are contributing to their extension point at a given moment and since they are not listening dynamically to the installation / uninstallation of Eclipse plugins contributing to their extension point (which can be done like this) they may keep references to contribution from plugins that we will uninstall later which can create problem. This behavior is explained in detail line 775 in the first linked file.
Regards,
Stephane Begaudeau

Autocompletion in Eclipse for Roo project

I've got a Roo project where I've made a couple of entities, and when I load up the project in Eclipse it loads up fine, but if I i.e. make an instance MyEntity entity and then write entity. I don't get any of my properties (i.e. getMyField) in the autocompletion list. If I write entity.getMyField() it compiles fine, that is taken care of by the aspects. How do I enable autocompletion for functions generated by the aspects?
Cheers
Nik

Which "type" of eclipse are you using? Do you have AJDT intstalled within your eclipse? If so there is still an option to disable weaving of JDT. The note below (taken from the Roo documentation) should help you to turn on JDT weaving (Window -> Preferences > JDT Weaving.
When using AJDT you may be prompted
whether to enable weaving of the JDT.
You should select to enable weaving so
as to ensure the Java Editor in
Eclipse (or STS) gives the best
AspectJ-based experience. You can also
verify this setting is active by
loading Eclipse (or STS) and selecting
Window > Preferences > JDT Weaving.
By the way have you considered trying the Spring Source Tool Suite? There you find all the plugins (AJDT support...) already installed. And it fits very well for Roo as it offers Roo functionality from within eclipse.

I have experienced the same problem as niklassaers: Roo AspectJ methods not showing in eclipse autocompletion while compiling fine. I'm using the latest version of STS, with AJDT installed by default, and verified that JDT Weaving is active, but the problem persists.
On the other hand, I've found out that executing Maven > Update project... (Alt-F5) makes the ROO AJ methods visible to auto completion.
This solution might be related on how I structured my project (I have two eclipse Maven projects in my workspace, myproject.data containing roo classes with aj methods, and myproject.services acting as a client for those classes); besides, I have to repeat Alt-F5 every time I open my workspace, but this seems to work.
I'd like to understand better the reasons of this code completion problem, and maybe find some way to solve the problem permanently, without having to update maven projects every time. Could it be related to interactions between the AJDT plugin and m2eclipse Maven plugin?