I wrapped a source github for b4a with Eclipse.
I added core.jar but when I compile the project in b4a it shows this error:
trouble processing "java/com/lsjwzh/widget/materialloadingprogressbar/CircleProgressBar$OvalShadow.class": Ill-advised or mistaken usage of a core class (java.* or javax.*) when not building a core library.
This is often due to inadvertently including a core library file in your application's project, when using an IDE (such as Eclipse). If you are sure you're not intentionally defining a core class, then this is the most likely explanation of what's going on.
However, you might actually be trying to define a class in a core namespace, the source of which you may have taken, for example, from a non-Android virtual machine project. This will most assuredly not work. At a minimum, it jeopradizes the compatibility of your app with future versions of the platform.
I changed package name from
java.com.lsjwzh.widget.materialloadingprogressbar
to
com.lsjwzh.widget.materialloadingprogressbar
Why show in error -
"java/com/lsjwzh/widget/materialloadingprogressbar/CircleProgressBar$OvalShadow.class"
?
I rebuilt the project in eclipse and compile with SimpleLibraryCompiler for b4a.
I forgot use
#DependsOn
for calling Additional jar in folder libs.
Related
I have a C project that uses libc, and I need to compile it into a static library that will be added later to a different project.
My question is: what will happen if the second project (the one that will use my library) is already using a differnt version of libc? Will this fail during linkage? And if so, how can I overcome this problem?
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 have exactly the same problem as in this question: Eclipse: Using "Open Declaration" ... in a Scala project
However, I'm using the latest Scala IDE in version 3.0.2 (I have downloaded the Eclipse bundle from the site), and I would assume such basic functionality works by now, and apparently it's me who have something misconfigured.
I have created a new Scala project. Then I open some standard library class/trait/whatever, let's say scala.util.parsing.combinator.JavaTokenParsers. The source is neatly displayed, but when I try to show class hierarchy, I get the message: The resource is not on the build path of a Java project.
Also, searching for references etc. won't work.
I guess it is a matter of properly configuring the build path? Or maybe I should somehow attach Scala library sources to my project? But I can see the source, so aren't they attached already?
Here is the snapshot of my project configuration:
UPDATE:
By playing a bit with setting/resetting build path stuff, I managed to get rid of pop-up warning but the class hierarchy comes up empty and when searching for references I get only hits from my own sources, nothing from standard library.
In another workspace I also tried randomly adding and removing scala-library jars and got it work almost, but the type hierarchy comes up only with super-classes, without any sub-classes (which renders it quite useless). Searching for references works ok though.
Funny thing, I cannot make it work in my original workspace...
Gotta love Eclipse.
Your build path is not configured properly.
If you take a look under Scala Library[...] you have scala-library.jar we can only see one top-level package scala. There should be numerous other packages besides that. (Ruled Out)
I would recommend you follow these steps
Right-click project, build-path, Java-build-path, Libraries and make sure that the correct library is referenced there.
If it is the one you need, Try to remove this library and add it again, then clean and re-fresh the project. Also try this step in a fresh workspace.(something must have messed up this workspace )
Lastly. Goto the path D:\Eclipse For Scala\configuration\org.eclipse.osgi\bundles\286\1\.cp\lib and verify the sizes of the jars there. There should be 6 jars there and the size of scala-library jar should be around 6.8M. If size is smaller, consider re-downloading
Greetings,
I have a java project which I export as a jar. This java project also uses JNI.
So far, the only method I could find to use this jar in an Eclipse plugin is to wrap it in an other eclipse plugin project, and add this jar wrapper plugin to dependencies of my actual plugin.
I've wrestled with Eclipse's paths and dependency settings for days, and this method is the only one that works for me at the moment.
However, it is not very practical, since when I change my JNI based java code, I can simply create a new jar, but to connect that jar to my actual plugin, I have to re-create the jar wrapper plugin every time.
That is, I delete the jar wrapper plugin project, with everything on the disk, and re create it with the same name, pointing to the updated jar. I also have to drop the reference to this project from the actual plugin project and add again (maybe this has gotten smarter recently, but I did not test it)
This is time consuming, and I can't add this wrapper plugin project to svn either, since it is being created from scratch every time.
If I could simply update a jar wrapping eclipse plugin project by pointing at the new version of jar, that would solve my problem, and I could commit the project to svn after each update.
Is there any method you can think of which may help me run this process smoothly?
Best Regards
Seref
An Equinox-only (i.e. non-standard OSGi) method of using external libraries in an OSGi bundle without physically wrapping them is bundling by reference: you still need a wrapper plugin, but it does not contain the wrapped library itself but a reference in the bundle manifest's Bundle-Classpath header with a syntax like this:
Bundle-Classpath: external:/path/to/your/lib.jar
During development time, this is quite convenient and saves the effort of having to recreate the wrapper plugin whenever the wrapped library is updated. During deployment time, you'll either have to install the library along with the product or use a traditional wrapper plugin (one containing the actual library). You can also use the same wrapper plugin for bith use cases, but change the Bundle-Classpath from external:/stuff/lib.jar to libs/lib.jar dependent on whether you want to use the wrapped or the external library.
(Most of this comes from the book OSGi and Equinox - Creating Highly Modular Java Systems, which I don't really like, but which nevertheless contains useful stuff about Equinox (Eclipse's OSGi implementation) and the PDE build system.)
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.