I am trying to extend a third-party Eclipse plug-in by using a fragment project. The major reason is that the third party plug-in contains classes having the default (package) modifier and I need to extend them.
Thus, my extensions class must be located in exactly the same package. I create a fragment project containing the same package and put my class into it. Everything works fine when I am using a runtime workspace.
However, if I try to deploy my fragment (e.g., deploying it into the dropins folder of my Eclipse distribution), I am not able to execute the code. Extensions and stuff like that work fine (e.g., I use extensions for a new Run Configuration. However, if I try to instantiate this run configuration I get an error message that the third-party root plug-in was unable to load the class to display my configuration tab group.
Any experience with this kind of problems?
Sorry, but that does not work. Unless the host bundle has been crafted specially for it, you cannot override a class in the host from a fragment. The reason is that resources - including classes - are retrieved from the host before any fragment.
See org.eclipse.osgi.baseadaptor.loader.ClasspathManager for the implementation..
Actually, this is the extension code I am using:
<extension point="org.eclipse.debug.ui.launchConfigurationTabGroups">
<launchConfigurationTabGroup
class="com.android.ide.eclipse.adt.internal.launch.jouleunit.AndroidJouleUnitTabGroup"
id="com.android.ide.eclipse.adt.jouleunit.AndroidJouleUnitLaunchConfigTabGroup"
type="com.android.ide.eclipse.adt.jouleunit.launchConfigurationType">
</launchConfigurationTabGroup>
Of course, there are further extensions definig the launch configuration type etc. but this is the one leading to the class which Eclipse can not find.
Actually I found the problem now for myself. The problem was a wrong configured build properties file which excluded the Java byte code from my fragment JAR. Very itchy, as the classes were in the JAR but in a wrong subdirectory.
Related
I'm in the early stages of creating a new Eclipse plug-in in Eclipse 2019-06. I created the plug-in using the "Hello World" wizard option and created a debug configuration that successfully launches a secondary workbench for testing. I can click on my new menu option and step into my new code.
I want to use a modified version of org.eclipse.jdt.junit.wizards.NewTestCaseWizardPageOne, so I added the package to my project and edited NewTestCaseWizardPageOne. However, when I try to debug, the debugger asks for a source location. It seems to want to load the file from the local repository (.p2/pool/plugins/org.eclipse.jdt.junit_3.11.400.v20190510-0840.jar), rather than my edited version. Why is that?
There must be some kind of classpath problem, but don't versions of files in the project have precedence over those in the dependent plugins? I've looked at a number of similar questions (1, 2) and other sources, but I haven't yet found the answer. Please help.
Following Alexander Federov's suggestion, I converted my plugin into a fragment. This was fairly easy to do following the advice from this StackOverflow page. The main changes were:
Renamed plugin.xml to fragment.xml and changed the top level xml
element from plugin to fragment.
Added a Fragment-Host entry to MANIFEST.MF
The key advantage that this provided is discussed in an Eclipse Wiki
page:
... a fragment appears much the
same as a normal plug-in. A fragment can specify libraries,
extensions, and other files. When it is loaded by the platform loader,
a fragment is logically, but not physically, merged into the host
plug-in. The end result is exactly the same as if the fragment's
manifest were copied into the plug-in manifest, and all the files in
the fragment directory appear as if they were located in the plug-in's
install directory. Thus, a runtime library supplied by a fragment
appears on the classpath of its host plug-in. In fact, a Java class in
a fragment can be in the same package as a class in the host and will
even have access to package-visible methods on the host's classes.
The last part having to do with access to package-visible methods was what I needed. Thanks, Alexander!
I am setting up Selenium right now and i have to copy the Selenium files into my eclipse project. Unfortunately, every tutorial has different files which they are adding to the Eclipse project, mostly because they are using older Selenium versions.
Currently, i just added all jar. files from the "libs" folder and also the jar file called "client-combined-3.5.3-nodeps". So i hope these are all files i need.
My question is, what happens if some files are missing? Is Selenium then not usable correctly?
Selenium Java client provides us the APIs through different packages. So when we need to use the APIs we have to make the necessary imports as well.
Now, if you miss out to add certain Selenium related jars in your Project, some methods from your main() or #test Class may not get resolved due to absence of the imports. Hence your program/script will show you errors as unresolved methods and will the program will not get compiled/executed.
Hence, it's always a good idea to add all the jars in your project from the released Selenium Client SDK.
At times, there may exist certain methods which are defined in multiple packages. For example method abc() may be defined in java.util.pqr; as well as in org.openqa.selenium.xyz;. In those cases we have to make our imports wisely as per our requirement.
I'd like to know how to configure the maven-bundle-plugin (backed by bnd) to completely ignore the classes contained within an embedded jar.
Background
I'm working in a controlled environment where the environment my code is running on is defined by a single company (including all the tools). The code is java and uses OSGi to define module dependencies.
Some of the provided modules contain what look like invalid class files, I can only assume that the system will 'correct' these class files before it tries to load them into any type of JVM. In any case these class files work when deployed onto the target system.
I'm trying to create a build system based on Maven that can produce packages the system understands and have hit a problem where these invalid class files are being read by BND (via apache-felix) which causes errors.
I'd like a way to have the jars that contain these class files on the class path of the bundle but where the contained .class files aren't read/processed by bnd. I could settle for simply ignoring the errors and continuing but can't find a way to do that either without felix aborting the entire build phase.
I just found the -failok directive, don't know why I didn't find it before. Adding <_failok>true</_failok> to the instructions allows me to continue working.
See instructions-ref
I have been struggling a while now to try to reuse the RemoteService implementation from one GWT project into a new one.
Here's the big picture:
I have a working smartgwt-mobile project and we now decided we wanted a desktop version of the same project, using regular smart-gwt. The GUI of this new app will obviously be different but the server side code will be exactly the same.
I tried to just "borrow" the RemoteService interface, its async counterpart and the whole server package by either linking the package folders in the other project inside the new source structure (I am using Eclipse with GWT plugin) or by adding the borrowed code path as a filtered source folder to the build path, and while this satisfies the Eclipse dependency checker, the GWT compiler is unable to find the borrowed code suggesting I need to add "inherit" declarations in the module .gwt.xml file.
When I do this and recompile it now expects a second module .gwt.xml file in the root of the borrowed code which is not acceptable because it would affect the other project.
I have been reading up on the GWT module documentation but I fail to see how to implement such a scheme. It may actually be impossible to do what I am trying to achieve.
I would be willing, if that solves the problem, to create a third project that simply defines a GWT RemoteService module that then will be inherited by both the mobile and desktop smartgwt projects.
Does anybody have suggestions about how to tackle this issue?
I'l agree to "third project that simply defines a GWT RemoteService module that then will be inherited by both the mobile and desktop smartgwt projects"
Why because, I'm just already doing this. Yes that is Obviously an DAO project(DB layer) which has all my DB business logic methods there.
And its always better to maintain separate DAO layer to expose your data to services(ex.webservices).
So here's how I solved the issue.
The problem with linking to an existing GWT project source folders is that the GWT compiler always (at least that's what it looks like) expects to find a GWT module definition file (.gwt.xml). I have not been able to link in the source folders in such a way that the GWT compiler is happy, even though the Eclipse dependency resolver has no problem with it.
So I created a third project using the GWT Eclipse plugin. I unchecked the "Create Sample Code" option, so I ended up with an empty GWT project. I then selected 'Add' > 'New' > 'Other' > 'Google' > 'Module', entered a module name, e.g. 'myModule', a package name, e.g. 'com.myCompany.myModule' and clicked 'Finish'. The GWT New Module wizard created the package and a child package under it named 'com.myCompany.myModule.client' and I created 'com.myCompany.myModule.server' myself.
Now I copied the RemoteService and related classes (The implementation and Async version ), plus all the server side code the RemoteService code calls from the original project I wanted to borrow from and pasted it into the new project. Very soon I had all dependencies satisfied and I opened the Build Path dialog on the new Smart-GWT web app project and included the GWT RemoteService Module Project in the projects tab. Last thing to do was adding an inherit element to the .gwt.xml file:
<inherits name='com.myCompany.myModule.MyModule'/>
Voilá: That's all there is to it. If you select 'GWT Compile Project' It compiles and runs in dev mode without warnings.
I now still have to delete the shared code from the first project and inherit from the module, bat that is simply a repetition of what I already did.
In the end this was much less painful as I imagined it to be, so I recommend this approach.
I'm using Eclipse for some embedded development and recently is started to give me these errors every time I save a file or do a build. It's annoying but for the most part it doesn't seem to be causing any problems (It even still highlights warnings/errors int the source. What's going on here?
Plug-in org.eclipse.cdt.cross.arm.gnu was unable to load class
org.eclipse.cdt.managedbuilder.internal.scannerconfig.DefaultGnuWinScannerInfoCollector.
Plug-in org.eclipse.cdt.cross.arm.gnu was unable to load class
org.eclipse.cdt.managedbuilder.internal.scannerconfig.ManagedGCCScannerInfoConsoleParser
It looks like the eclipse wiki FAQ says
The most likely reason is that an exception was thrown in the static initializer for a class declared by the offending plug-in. Check the .log file to see whether that indeed happened.
The Eclipse Platform loader will not load a plug-in when exceptions are thrown during the initialization of the Java classes that make up the plug-in.
Another common reason for this error is the lack of an appropriate constructor for the class being loaded. Most classes declared in extension points must have a public zero-argument constructor. Check the extension point documentation to see what constructor is required for the classes that you declare in an extension.
If the problem only occurs when deploying a packaged plug-in (i.e., when it is not started in a runtime workbench via PDE) it is usually a good idea to check the Bundle-ClassPath attribute in the MANIFEST.MF file.
The JAR file that contains the plug-in classes must be listed in the Bundle-ClassPath. Even if the plug-in's proper classes are all listed, class loading may still fail because a .class file may contain references to other classes that cannot be resolved at runtime. In this case, the missing classes need to be identified (usually by looking at the import statements of the problematic class) and the necessary entries need to be added to the Bundle-ClassPath. If additional JAR files are required, those JARs also need to be listed in the build.properties file so that they are included when the plug-in is packaged.
(See this thread as an illustration of that last point)
So, for instance, in this thread, for another issue back in eclipse3.0 time:
The plugin.xml file specifies "org.eclipse.core.runtime.compatablity" as a required plugin. However, I am using Eclipse Version 3.0.1 and should be using "org.eclipse.core.runtime_3.0.1".
Solution:
Replace the line in the Plugin.xml
<import plugin="org.eclipse.core.runtime.compatability"/>
with
<import plugin="org.eclipse.core.runtime"/>
VonC is right -- with a fair bit of detail on what might go wrong with class loading...
In this case, your arm.cross toolchain is referencing internal classes in CDT's managedbuild which aren't accessible. This is an incompatibility between your arm toolchain and CDT. You should file a bug with them on this error, first trying a newer version.