I'm working on a plugin which editor augments on the existing JDT (Java) editor
using aspects.
Now, Eclipse text editors that derive from AbstractTextEditor are
organized in clear components, following an MVC architecture. Those
components are then accessed through precise paths,
e.g. reconciliation. You can find one example of a custom reconciler and
the assumptions it can (and does) use on the behavior of the editor
here.
I'd like to write headless unit tests against those assumptions, that
would check that my weaving through aspects has not broken anything along
the way. For example, in the case of reconciliation, I would like to
open an editor, input some incorrect content (with respect to some
reconciliation strategy), wait for a while, and check that Problems are
indeed reported.
Note that which problems are reported, or how they would be signaled to
the user in a UI component doesn't concern me : I want
to test that my swapping a SourceViewer for a custom one through aspects
doesn't break editor logic, not my specific reconciliation strategy.
(In fact, I'd
probably mock it for that test. Moreover, the UI testing, being
presumably not runnable in a headless fashion, is beyond the scope of my
question.)
It seems this should be easy to do if the appropriate structures
existed. Do they ? Is there any test framework or mocks in sync with Eclipse's
architectural assumptions that would let me do what I have in mind ? Those would have to reproduce workflow behavior of the existing Eclipse editor. Surely this would be among Eclipse's own unit tests, right ? ... though
I can't seem to find anything of the sort. Any ideas ?
I have asked that same question on the eclipse core platform mailing-list, and got a great answer from Dani Megert giving me pointers to Eclipse's own test framework. The Junit plugin tests are released for download as part of the extended SDK, and browsing the git source lets you see there are already tests against the model or interacting with some of the Editor components.
Related
I would like to write JUnit test for my Eclipse RCP while I continue developing the code. When starting the application the different plugins initialize variables of various plugins/classes (mostly within their start methods) which are needed for the correct functionality.
If this initialization doesn't happen, it is impossible to test code because it depends on those values.
How do I solve this issue without creating a lot of dummy values?
What is the general approach to testing Eclipse RCPs?
You're facing a common problem: Too many dependencies. You need to cut them.
With Eclipse 3, this is going to be somewhat hard. Try to split the code into things that depend on the Eclipse platform running and everything else. Eclipse often uses interfaces, so you can test many things using mocks.
With e4, things got more simple since many services will be injected, making mocking and testing even easier.
But the goal must always be to have as much code as possible that doesn't depend on SWT or the platform. Create your own interfaces if you have to. The runtime imlementations just wrap Eclipse code. For tests, you can use mocks to simulate the Eclipse runtime.
You can run tests using JUnit plugintest, that will start up the plugin framework and will allow for testing of plugins. But this usually only solves some of the issues. The best suggestion is as Aaron suggests to separate functionality as much as possible to the point where all your actual code are just plain old java objects that you can test normally. All dependencies to Eclipse are in different classes and are kept as thin as possible so that they dont require testing.
This can be difficult to achieve, so mocking may be required. Another trick I've resorted to at times is to use Java reflection to change values of private fields, see this question
I have an exported Eclipse Java Project in my server and I want to be able to compile the project and use ASTParser with JDT.
I'm able to compile the project using BatchCompiler, however it runs on console and gives me PrintWriters instead of an array of problems and errors. Also I want to be able to use proposals in Eclipse and BatchCompiler didn't built for this purpose.
Therefore I tried to use ASTParser, it can be used with either char[] or ICompilationUnit. CompletionProposalCollector and org.eclipse.jdt.internal.compiler.Compiler.Compiler needs ICompilationUnit so I have to create an ICompilationUnit which only can be created by an IJavaProject (https://dl.dropboxusercontent.com/u/10773282/2012/eclipse_workspace.pdf) in order to be able to use these features.
It seems the only way to create IJavaProject is to use ResourcesPlugin.getWorkspace(), however it returns java.lang.IllegalStateException: Workspace is closed. on my computer and it seems the reason is that the program that I coded is not an Eclipse plug-in.
Is there any way to create IJavaProject without Eclipse environment?
From the comments, it looks like you are trying to do more than just parsing, you actually want to get some form of content assist.
I'm afraid that you're asking for too much. There is no simple way to get the power and flexibility of JDT outside of a running Eclipse instance (believe me, I've tried). There's no simple way, but if you are brave and strong willed, you can one of try following:
Run a headless Eclipse on your server that works on top of an actual workspace. This would be the easiest to implement, but would be the most resource intensive and least flexible way of doing things.
Use the jdt core jar, and create alternate implementations of the IResource hierarchy, and the parts of JFace that are used by the the parser and the CompletionEngine. This would likely be the most feature-rich way to go, but also the most brittle. I can't guarantee that this would work as you may need to create some very complex stubs for internal Eclipse non-API classes.
Avoid the CompletionEngine and the ASTParser entirely and just use the batch compiler. You would then need to provide an alternate implementation of org.eclipse.jdt.internal.compiler.env.INameEnvironment. This implementation would be able to find types, files, and compilation units in your actual project structure. You'd need to reimplement support for content assist, but this would most likely work reasonably well.
I am actually fairly interested in doing something like this (but I lack the time to do it). If you are seriously considering creating a headless JDT that can run on a server, feel free to ask for more information. I am quite familiar with JDT internals.
I've had a similar problem. Here is how to use ASTParser without Eclipse (it just needs the core JDT JAR on the classpath): http://blog.pdark.de/2010/11/05/using-eclipse-to-parse-java-code/
In the Eclipse manifest editor, there exist check boxes for enabling/disabling plug-in activation and singleton behavior, as shown below:
[ ] Activate this plug-in when one of its classes is loaded
[ ] This plug-in is a singleton
Questions:
When would the activation check box NOT be checked?
If wrapping a third-party library, should this plug-in "usually" be configured as a singleton?
I'm searching for information or some examples that would demonstrate when activation of the plugin would not be desired (i.e., intentional non-activation). The singleton behavior is clearer (in my opinion) to see when it would be appropriate (e.g., a logger).
Much thanks!
Michael
When you both don't a) need to do anything special when the plug-in starts and stops; b) don't have any extensions in plugin.xml which are only picked up on activation. However, those are circumstances where you can not activate. Since it's easy enough to forget about turning automatic activation on when they change, I'd still check the option even in this case. I don't know of any situation where you'd actively want to turn automatic activation off.
No, usually not. Only when two instances of this plug-in would interfere with each other. As you suggest, a logger (both would try to write to same files), a printing library, a graphics toolkit, etc.
Background
I'm a developer of the Vrapper project.
Vrapper contains of 2 major parts
Vim-emulation library (vrapper.core)
Eclipse part that makes a good use of it
We want vrapper.core to be Eclipse-unaware, so it's reusable
outside of the Eclipse. Currently, we can "vrap" all sorts of Eclipse
text editors and our little mock text editor that we use for unit testing.
vrapper.core implements all sorts of Vim commands, modes, etc.
Those all communicate with Platform - an interface that abstracts out
underlying stuff (text editor, clipboards, settings system, etc.).
When mode is created for an editor it asks platform if there are extra
commands that are approperiate for underlying editor, currently edited file type, etc.
EclipsePlatform provides those commands using Eclipse extension points mechanism.
So, let's consider the following projects (there are more):
vrapper.core - Eclipse-independent code for Vrapper
vrapper.eclipse - Eclipse plug-in that depends on vrapper.core
surround.core - Eclipse-independent code that emulates surround.vim (Vim plug-in)
surround.eclipse - Eclipse fragment for vrapper.eclipse
that makes it provide commands form surround.core.
There are two ways we can deal with those:
One plug-in to rule them all
This is how it should look like from Eclipse's perspective.
There is one plug-in that contains code from vrapper.eclipse and vrapper.core,
and one fragment that contains code from surround.core and surround.eclipse.
Many plug-ins
There are 3 plug-ins
two OSGified libraries vrapper.core, surround.core
vrapper.eclipse
surround.eclipse fragment depends on vrapper.core in this case
Problems
Many plug-ins solution have some issues with lazy class loading that I don't understand.
It's beacause when instances of modes from vrapper.core are created they need
classes from surround.core to be created (via vrapper.eclipse -> surround.eclipse).
This works if you run stuff from Eclipse and select all plug-ins from run configuration,
but if one deploys features & plugins and run eclipse normally an exception is thrown
because classes from surround.core cannot be found.
It's something in the spirit of surround.core asking for extra commands from
dependent plug-ins creates implicit circular dependencies.
What I mean by implicit dependencies is that no core class depends on eclipse-specific classes in compile time.
Modes (like vim normal mode) are core classes. They contain commands. There are some commands specific for particular Eclipse editors (like run this JDT-specific refactoring). Those commands implement core interfaces, but their code (obviously) lives in eclipse-specific projects. When mode is created it asks underlying platform for some extra commands - those extra commands are implemented in eclipse plug-ins. This is when lazy class loading in eclipse make everything blow up in runtime - classes for extra commands are referenced by extension points, but they are not yet loaded. Boom, exception.
I tried to work this around by using "one plug-in to rule them all" approach.
Having just one plug-in seems to be much better solution to me, but I couldn't make it work cleanly.
Only thing that succeeded for me was quite an ugly hack.
All .core projects had an Ant task that created .jar file with their classes
and dropped it into corresponding *.eclipse project
*.eclipse projects included that jars and had them enlisted in MANIFEST files.
The problem with this ugly hack approach (besides of it being ugly hack) is
that development becomes quite painful. Eclipse code navigation, code coverage
and few other things in Eclipse stops working.
Summary
We have eclipse independent library + eclipse specific stuff architecture,
but we really need all of this to live in one plug-in (because there are some dependencies in both directions).
How do I make code from few projects live into one plug-in/fragment?
It turned out that adding Eclipse-BuddyPolicy: dependent to MANIFEST.MF files, reexporting some dependencies and turning one fragment into plugin (so there is plug-in dependency for BuddyPolicy to track) was the right solution.
Problem solved :-)
From reading this it sounds as if the actual problem is the fact that there are dependencies in both directions. Can't you refactor your projects to make only the Eclipse-spcific proejcts depend on the core projects, and not the other way around?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
Wether you call it Addons, Plugins or extra peices of code that is connected with the original software later, it really doesn't matter. I would love to understand how they work, there has to be a simple explanation of how to design a Plugin System. Unfortunately, I never understood it, and there remains a lot of open question in my mind. For example, how does the program find a plugin? how does it interface with it? when is it preferable for a software to have Plugin System?
Thanks for all helpful answers. It seems I asked too open question, fortunately I got keywords to look for. I liked David answer though I am not a Java guy, but his talk made sense to me :)
Plug-ins work by conforming to well-known interfaces that the main application expects to work with.
There are several ways in which a plug-in architecture actually works, but in general, these are the steps:
Plug-ins are designed to match an interface that the application expects. For example, a simple application might require that plug-ins implement a IPlugin interface.
Plug-ins are loaded by the application, usually when the app is starting up
Plug-ins are often provided access to much of the data that the application manages. For example, Firefox plug-ins can access the current web page, and Eclipse plug-ins can access the open files.
Here are two ways (out of several) in which an application can find plug-ins:
The plug-ins are known to exist in a particular folder, and the application knows to load plug-ins from that folder
Each plug-in runs as a service, and the services are designed to work together (this is how an OSGi-based application works)
When plug-ins are found, they are loaded by the application (sometimes the job of a Class Loader).
A software architect might design a plug-in architecture when they expect that either the software provider or the user community will implement new features that were not originally part of the system. Two great examples are Eclipse and Firefox; other applications include Adobe Photoshop (for artistic techniques and graphical tools) and Winamp (for visualizations).
Create an interface that all plugins of a particular type will implement
Write the code that will 'consume' the plugin against the interface only.
Have a dynamic way to load a DLL containing the plugin type that implements your interface (for instance, have a configurable folder location to test whether any DLLs in that folder contain any types that implement your interface, and dynamically load any that do. In .NET this might use Assembly.LoadFile())
If you want to have a look at some source code, Paint.NET is free and open source, and has a plugin architecture.
A program typically has to be designed to look for a plug-in, and the plug-in has to have a standard access point to accept control from the main program. Every application or website does it a little differently.
The simplest type of plug-in is accessed something like this:
if (a plug-in exists/is configured)
call predefined plug-in code
In this case, the main program is coded to only handle a specific set of plug-ins (many php-based wordpress templates are like this). A slightly more advanced plug-in
perform application specific logic
if any plug-in exists that exposes the run_after_app_specific_logic function
call plug-in code
This second case can handle ridiculously complex plug-ins ... the plug-in would just need to implement more functions called by the master program.
Eclipse in an example of a application-framework which is entirely plugin-based, meaning that all functionality is implemented as plugins. There is a thin layer at the bottom for startup/shutdown and plugin-management, but everything else is implemented as plugins on top of that. This results in a framework which can be used for just about everything. More info about Eclipse plugin architecture can be found here: http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html.
It's very language dependent.
In an interpreted language it simply involves calling a file that follows a pattern.
In C it's pretty hard to do without help. In C+windows a "DLL" can be a plug-in and are often used that way.
In an OO language with reflection, you might create an object that implements an interface and load it reflectively. After it's loaded, you can ignore the fact that it was a plug-in because it's treated as any other object in your code.
.net has a plugin architecture (is it COM?) Well anyway COM can be used as (is?) a plugin system.
Your question is probably too open-ended because of all the possibilities. There is no single answer.
I've never written a plugin system. But this is how I imagine it in my head:
Your program has a subdirectory for plugins (e.g. "C:\Program Files\My Program Name\plugins").
You create plugins as DLL files and place them in the plugins folder.
These DLLs would export functions with predefined names.
When you run your program, it looks through all the DLLs in your plugins folder. In each one it would look for an exported function with a certain name (e.g. "Load") and call that function. The plugin could then do any setup that it needed to do.
The program would then call an exported function on the plugin with a name like "GetPluginName". The plugin would return it's name and the program could then use that name when it displays a list of plugins to the user.
When it comes time to invoke the plugin, the program would call another exported function (maybe "Activate") and probably pass the plugin a pointer to the data that the plugin is going to work on. The program would then do its work on the data.
The plugin might also export another function that the program would call to show a setup dialog where you could change the plugin options.
A plugin system can be implemented in many ways, but the common way for a lot of C/C++ applications is a DLL-based plugin SDK.
The DLL will expose various automated function calls which may allow the plugin to "set itself up" in the running application such as adding menu items, new functionality or extra options for systems (like 3D rendering implementations).
More ofthen there's no need for any special discovery - the plugin mechanizm is generally dumb: Here's a code signature I understand, and here's a call(s) I can make. I have no clue how the thing I'm calling will do the job, but I expect result to be in certain format. And that is pretty much a contract. Now - the plugin will implement the contract and make itself available. In Java, for example "make available" simply means that implementing classes are loaded into memory. JDBC driver for a particular database would be a good example.