Build Path > Add Library > JUnit unable to add JUnit3 or JUnit4 components.
I see such message in the .log
!MESSAGE No property tester contributes a property projectPersistentProperty org.eclipse.team.core.repository to type class org.eclipse.core.internal.resources.Project
Eclipse Galileo installed by root user on Linux.
It works well for root and for other users except this JUnit issue.
Why it lost Junit?
(I've checked file permissions twice - all readable!)
This seems to be related to bug 239715, triggered by TypeExtensionManager.java, and due to some kind of plugins combination.
Could you check if your org.eclipse.core.expressions/.options file has the line
org.eclipse.core.expressions/debug/TypeExtensionManager=false
This should be enough to make that error message disappear.
That file is <eclipse-SDK-3.5-win32>\eclipse\plugins\org.eclipse.core.expressions_3.4.100.v20090429-1800.jar, and I just checked, it does contains the right option value (with latest Galileo) (are you using an older Galileo RC or Milestone release?).
Ah, I was getting this problem this morning. A search showed that it was possibly related to JGit/Egit. After updating the EGit plugin from 0.5 to 0.6, the errors have not returned.
You can make a variable junit or smtg similar to your customized one, add the junit folder to this varible, and give extension of it as junit4.8.1.jar.
I tried this and it works, but you have to delete any plugins of junit of version4 if present from plugins folder.
Related
I am getting an error like -
Cannot contact RemoteTestNG Client.Make sure you do not have older versions of testing.jar on your classpath.
Reason:Timeout while trying to contact RemoteTestNG.
I tried various solutions already present in stack overflow:
Check "Use project testng" option
Add latest testing.jar in classpath.
Check for duplicate testng jars in classpath.
Delete old testNG testsets ,clean workspace and restart workspace
But all the above solutions did not work for me and I ended up getting the same error again.
Please help me out here.
the latest release of testng eclipse 6.9.11 should fix this issue, please let me know (or fire an issue here https://github.com/cbeust/testng-eclipse/issues)
Noted: since this version, option "Use Project TestNG jar" was removed, to always respect the Project's TestNG lib.
Introduction
I have spend a lot of time to fix this bug
In our application we have a lot of generated code by cxf and jaxb which produces tons of warnings. We use the maven-build-helper plugin to add this code to our projects automatically.
By adding this enhancement, eclipse JDT enabled the possibility to set the javac -nowarn flag for specific source folders. Unluckily, by updating the maven project the flag gets lost. There are a few threads on SO where users got bugged by bug.
What I have tried so far
So i came up with a clever solution, javac has a nowarn flag. I set it to my maven-compiler-plugin and specified the directory. My maven build was fine, but my eclipse build wasn't. My research told me, that eclipse jdt does only use the maven-compiler-plugin source and target version. So my next step was to try to configure the EclipseCompiler, but this is not possible, because there is no possibility to add custom compiler Arguments in eclipse JDT.
Next Step. Inside of the .classpath file, eclipse JDT adds an ignore_optional_problems attribute for each ignored path. By updating the maven project inside of eclipse, this entry gets lost. So i started to write a maven "ignore-source-folder" plugin which should add the missing attribute. To run the plugin each time eclipse starts a build, i also created a m2e connector to refresh the .classpath file and everything should be fine.
By testing my plugin with my connector i realized, it works, but only 70% of the repetitions.
What happened?
Every time eclipse m2e/Jdt starts a new build, all classpath entries will be removed and populated again. When my maven plugin gets triggered by eclipse, a race condition starts.
So I started to analyze the code of jdt and m2e jdt. The ignore_optional_problems flag gets only once set manually inside of the patch which was provided to JDT and isn't stored somewhere else. By triggering a new build via m2e-jdt this information gets lost.
How to fix this problem
To fix this problem, some element has to be added or extended in jdt which contains all ignored folders. If a new build gets triggered and the classpath file gets newly generated by m2e-jdt this element should be checked for ignored paths. ClasspathEntryDescriptor seems to be a good place for it.
My problem
I checked out jdt and m2e jdt, but i have tons of errors inside of my IDE and i have no idea how to start. And even if I fix the code, I have no idea how to build and test it. I think my effort will be to high and we talk about 20 or 30 simple lines of code.
I am afraid if I add my results to the filed bug at eclipse, no one will care about it.
So, is there any developer able and willing to help me for this tiny job?
You need to "fix" the M2E's JDT project configurator. Probably somewhere in the m2e-core project. So, your change should obtain some kind of configuration flag from the project pom and create corresponding classpath entries for JDT.
i am using eclipse 3.5 to create a simple plugin bearing an extension point. i built it using headless pde build via ant. the plugin functions properly. i then proceeded to test its extension point by placing my plugin jar into eclipse_home/dropins with intention of eventually creating an extension. but after i start eclipse, i get the following error in its log:
!ENTRY org.eclipse.equinox.p2.core 4 0 2012-03-22 01:00:45.270
!MESSAGE Provisioning exception
!STACK 1
org.eclipse.equinox.internal.provisional.p2.core.ProvisionException: No repository found at file:/C:/eclipse35/dropins/MyPlugin/.
at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.fail(AbstractRepositoryManager.java:380)
at org.eclipse.equinox.internal.p2.repository.helpers.AbstractRepositoryManager.loadRepository(AbstractRepositoryManager.java:641)
at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:92)
at org.eclipse.equinox.internal.p2.metadata.repository.MetadataRepositoryManager.loadRepository(MetadataRepositoryManager.java:88)
at org.eclipse.equinox.internal.p2.reconciler.dropins.Activator.loadMetadataRepository(Activator.java:90)
at org.eclipse.equinox.internal.p2.reconciler.dropins.DropinsRepositoryListener.getMetadataRepository(DropinsRepositoryListener.java:184)
at org.eclipse.equinox.internal.p2.reconciler.dropins.DropinsRepositoryListener.addRepository(DropinsRepositoryListener.java:79)
at org.eclipse.equinox.internal.p2.reconciler.dropins.DropinsRepositoryListener.added(DropinsRepositoryListener.java:57)
at org.eclipse.equinox.internal.provisional.p2.directorywatcher.DirectoryWatcher.processFile(DirectoryWatcher.java:200)
at org.eclipse.equinox.internal.provisional.p2.directorywatcher.DirectoryWatcher.scanDirectories(DirectoryWatcher.java:161)
at org.eclipse.equinox.internal.provisional.p2.directorywatcher.DirectoryWatcher.poll(DirectoryWatcher.java:108)
at org.eclipse.equinox.internal.p2.reconciler.dropins.Activator.watchDropins(Activator.java:491)
at org.eclipse.equinox.internal.p2.reconciler.dropins.Activator.start(Activator.java:167)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:782)
at java.security.AccessController.doPrivileged(Native Method)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:773)
at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:754)
at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:352)
at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:370)
at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1068)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:557)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:464)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:248)
at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:445)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:220)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:330)
i have tried both just placing the plugin jar directly in the dropins directory, as well as using the following directory structure: eclipse_home/dropins/MyPlugin/plugins/myplugin.jar. both approaches work just fine with 3rd party plugins, but not with mine. please let me know what i am doing wrong. thank you!
It seems like two problems. The "no repository found" error message looks like this problem. And then there is the issue with your plugin not starting.
First you should check if the plugin is found.
Then you should check if the plugin is resolved, i.e if all requirements are fulfilled.
If you have the plugin development version of Eclipse, then you can open the plugin registry view. See if your plugin is in the list, if so, then the atleast it has been found. Then right click on it, enable advanced operations, and after that choose diagnose. Some requirement has probably not been fulfilled.
If you dont have the Plugin version of Eclipse, you can use the osgi console. Go to console view, and choose OSGI console in the view menu.
Run command ss to list all plugins, and diag 123 where the number is the id of your plugin to diagnose it.
Also, see a previous answer to a similar question
Edit: Oh, and I have been having some serious problems getting plugins placed in the dropins catalog to work at times... You could try to copy it to the eclipse/plugins catalog directly.
I am working on an RCP project based on eclipse. It has been working fine but recently I thought I'd upgrade it to use a new eclipse version (3.2 -> 3.5).
After a bit of trouble, it was running on the new platform. Then I did something. Don't know what. The end result is that I'm now getting a classpath error when one of my plugins (A) tries to access a class in one of the dependent plugins (B) (also one of mine).
As far as I can see, Plugin A has Plugin B in its' dependency list and the compiler shows no errors. To test, I created a new Plugin C with one class and accessed the class from Plugin A. That works fine.
Does anyone have any hints for troubleshooting such issues? A checklist of settings to check? I've been struggling with this for hours and getting nowhere! Particularly frustrating as it was working until I changed something!
Thanks
Update
I should also say that the project is quite old and uses the plugin.xml and not the manifest. Could this be a problem? Is there a way to upgrade?
Some ideas:
Clean-and-build every project (maybe after a restart of Eclipse)
Check, whether the required packages are also exported
Check the Error log, maybe there is some unloadable plug-in, etc.
Check the Run configuration, whether every required plug-in is present there
If the problem does not happen in a Runtime workbench, but in an Exported RCP app, then check whether you compile the project with the same settings during export than in Eclipse
I hope, something helps about these.
You can try the following in your run configuration:
In the Main tab check Clear (workspace) under Workspace Data
In the Configuration tab check clear the configuration area before launching under Configuration Area
This helps me every time I encounter some strange ClassNotFound errors.
If I understand you correctly you have no compiler errors but when you run you get class not found exceptions? You could try PDE Tools > Update Classpath from the project's context menu to see if you declared any dependencies outside of the MANIFEST.MF file, which would result in compiling code that fails at runtime.
I developed for RCP quite a long ago, but if I'm not wrong, since 3.4 or 3.5 you have to declare in the plugin configration which packages/classes are exported for dependent plugins and which are not.
This is unlike the old convention of using 'internal' in the package to mark non-exported packages.
Since you have plugin.xml from very old version of eclipse, it might be the problem, as exported resources from one plugin to another were not enforced in Eclipse RCP 3.2.
One more complement, hope it helps.
Open plugin.xml, check "build" tab, see how "binary build" are configured. It affects which files will compiled and exported.
See binary build here : http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Fguide%2Ftools%2Feditors%2Fmanifest_editor%2Fbuild.htm
I have added all common targets like (init, clean, getivy, etc) in ./common/common.xml and added:
<import file="${basedir}/common/common.xml"/>
in build.xml.
When I build the project, its working fine. But, When I open build.xml in Eclipse IDE, I see some "Red" marks underneath targets which have a dependency targets that are defined in common.xml. And when I do mouse over those Red marked targets, I see a message saying that:
Target init does not exist in this project.
To clarify, the common folder is added through svn:externals. Does this need extra configurations in Eclipse?
I have Eclipse Indigo Service Release 1 Build id: 20110916-0149 with ant 1.8.2 and the described problem with import seems to be fixed as Steve already mentioned. But the problem still exists for include and no answer seems to solve it for me. I searched the bugtracker shortly but don't have the time to be sure and test in the latest eclipse version and post a bug in the bugtracker.
Edit:
I had the problem with import again after refactoring the folder structure in the project and moving the buildfile. Although I started "Validate" on the project, the validation cached the old location and did'nt realize the move. I had to close the editor and the warning disappeared.
If your build.xml, and the common directory are at the same directory level then just try
<import file="common/common.xml" />
This works for me fine.
Use the include path ${basedir}/common/common.xml because . is probably the directory in which Eclipse is installed.
I found a post online here where someone found a workaround. You just need to make the file import not the first line in the ant build file. If you put it after a property declaration for instance the error goes away. This worked fine for me and eclipse is happy now.
The specific problem we had seemed to be because we
were importing common build.xml files into our project-specific build files, but the import was having problems when it is the first line in our
project-specific build file.
However, if I put a property task before the import, it seems to work fine. I am guessing this much force some initialization that wasn't occurring with only the <import>. I have no idea why this same issue doesn't happen in either command line with Ant 1.8, or with Eclipse using Ant 1.7.