Is there any way to discover programatically (but not in PDE code) which eclipse projects are opened?
I was hoping that would exist a .metadata anywhere telling me that, but couldn't find any non binary data.
The closer I got was something like:
"$WORKSPACE.metadata/.plugins/org.eclipse.core.resources/.projects/%s/org.eclipse.jdt.core/state.dat" where %s refers to the project name
I think m2eclipse uses that guy for some kind of control, because on a m2project this file gets removed as soon as the projects build.
Also, i found some information on .metadata/.plugins/org.eclipse.ui.workbench/workingsets.xml but none of them give me the full info I was hoping to find.
Does anyone knows how to solve it?
I was trying on eclipse 3.7.
On eclipse 4.3 , at least, its possible to parse $WORKSPACE/.metadata/.plugins/org.eclipse.ui.workbench/workingsets.xml and look up whether the desired project has a factoryID="org.eclipse.jdt.ui.PersistableJavaElementFactory", meaning it is opened.
I Didn't try this on 4.2 tough, maybe it works there as well.
To do it "programmatically", you call the APIs from the org.eclipse.core.resources plug-in. Otherwise, you are doing it wrong.
Related
I'm developing an Eclipse Plug-in.
I need to programmatically get both filepath and filename of the selected/active file in the eclipse editor.
Also need to programmatically add an existing file (located outside the project) to the project and then open it on the editor.
I'm a totally beginner with Eclipse, so complete solution would be appreciated.
You question is quite general, but this should clear things up a bit:
Eclipse Plugin Development Tutorial
About adding a file to the project, you have to read the documentation and find where eclipse handles projects. I think that if you have a reference to the project it should be easy.
Hope it helps =)
Your editor is most likely inheriting from IEditorPart, so you should be able to call getEditorInput(), which then may or may not turn out to be a FileEditorInput, for example. From there, you can get at the underlying details of the file.
For your second problem, you can use IProject.create() and then e.g. do an IFile.createLink() and use a local filesystem path, or copy the file using IFile.appendContents().
Have you tried the solution proposed in http://www.eclipse.org/forums/index.php/mv/msg/97927/300308/#msg_300308?
I've already followed the directions # Using preprocessor directives in BlackBerry JDE plugin for eclipse? for making sure the blackberry plugin preprocessing hook is (theoretically) enabled.
I'm using Eclipse 3.5.1 with Blackberry Plugin 1.1 with BB SDKs 4.7.0 and 4.6.0.
I have my preprocessor defines set (and I've tried in both the Project's Blackberry Properties as well as the Workspace Blackberry Build settings), and checked their capitalization and spelling carefully too.
I'm fairly confident the actual code to say "this stuff should be preprocessed" is good, because including/excluding preprocessed code seems to work fine on command line builds:
//#preprocess --- at beginning of file
and then code blocks like this throughout:
//#ifndef jde_4_7
/*
//#endif
//#ifdef jde_4_7
import net.rim.device.api.ui.TouchEvent;
//#endif
//#ifndef jde_4_7
*/
//#endif
So what I can't figure out what else could be wrong that would cause Eclipse to not compile in my preprocessed code unless I remove the comments that are supposed to prevent the touch code from building into a build for blackberries that don't support touch.
At one point it used to work (and no I haven't updated Eclipse), but sometime in the last couple of weeks it seemed to just stop working. And I'm getting kind of tired of the error-prone process of searching for ifdefs and manually commenting/uncommenting touch code and looking for a better solution while I do testing and initial development requiring testing both touch and non-touch functionality.
Any other ideas on what could be wrong or how to fix it?
I managed to get this working by adding this in the eclipse ini file
osgi.framework.extensions=net.rim.ejde.preprocessing.hook
you would probably already have osgi.framework.extensions. Just add net.rim.ejde.preprocessing.hook to it.
Yeah, I've had the same experience with this. Seems like they've dropped support for it with their new plug-in. Sometimes it feels like those guys can't get anything right. If you want preprocessing I'm afraid you'll have to use Eclipse 3.4 and the old plug-in (1.0.67). You can go here and fetch a bundled eclipse 3.4 with the said plug-in and any other component pack you may need.
I am using Eclipse 3.5 for several different Java/JSP projects. All of our project code is stored in Subversion. I use the Subclipse plugin to update / commit code. This works great for all projects except one. There is one project where almost every time I do a SVN update, the entire project becomes riddled with Java compile errors. Most of the errors are complaints that it can't find other class files within the same project. To resolve this, I have to go to Project > Clean and manually clean out the project, which takes a little while to run. Everything compiles just fine after this, but it is a bit of a pain to have to manually clean the project every time I do a SVN update. And this only happens for this one single project.
Anyone experience something like this? I am not even sure where to look to figure out why the project needs to constantly be manually cleaned. Is it possible that someone else is checking in a file that breaks my project build in Eclipse? If so, what file(s) should I look for?
First, excuse me if I say something obvious, but you didn't give any details of your project configuration, nor described your previous attempts at solving this issue. So, maybe you've already tried everything I'm going to suggest... ;-)
Off the top of my mind, I'd check whether someone else is committing compiled classes, instead of sources only.
Other than that, it depends on your configuration: I'm assuming that you've got the "Build automatically" flag checked, that you're building through Eclipse only (and not, for example, through Ant, letting maybe the Ant build put its output somewhere in your classpath), and that you're not versioning jars nor your .classpath file.
I suggest (if you're not doing so) to perform your SVN updates going through the Synchronize view (Team -> Synchronize with Repository), in order to see at a glance what kind of incoming changes you've got, to better distinguish cases when your project gets messed up from cases when it doesn't.
Some one already explained that, may be someone else also committing the compiled classes , and the class paths are getting conflicts. Fist know this info from your collegues and proceed. I didn't come across this situation. sorry.
How are you storing the project on SVN? Are you storing the entire Eclipse project or just source code, structure, etc? If you're not storing the entire project I'd suggest doing that as it makes it easier to work with (unless you've got somebody using a different IDE). Without some more information it makes it hard to diagnose, but it certainly sounds like somebody is committing compiled class paths. You should check the SVN history to confirm.
I'm trying to use Google Protocol Buffers in my project and I'd like to have some tooling support from Eclipse. In particular, I want Eclipse to call protoc every time I make changes to the .proto files and then rebuild all code that depends on the generated code.
I tried to set up a Custom Builder but it keeps bugging me with errors I don't understand, most often it complains that the .proto file is not on the path given by --proto-path, which it should be by all I can tell. Also, because I use ${build_files}, Eclipse passes all changed files to the compiler (instead of those that I have configured to trigger the build).
NetBeans seems to have a protobuf-Plugin, but I can't find one for Eclipse. Is there one?
Theres a protoclipse plugin on googlecode, which is in the initial stages:
http://code.google.com/p/protoclipse/
Not sure if there is a builder, but I did find a plugin for syntax highlighting for protocol buffers.
You can define an external builder on the plugin that invokes an ant task. It is an ugly kludge, but until there is a better solution this may serve your purposes.
In practice, syntax highlighting turned out to not be that important, I hardly edit these files, and they tend to be very small. Maven and the m2eclipse plugin handle the building side of things great.
I recommend using Google's "Protocol Buffers Development Tools". It is a plugin for Eclipse that features automagic regeneration and error checking, among other things. It's available here: http://code.google.com/p/protobuf-dt/ .
While this question is close to other Eclipse plugin for working with protobuf, answers here are different.
Well, yes, if you use maven/gradle to invoke protoc (Protobuf compiler), than you may need no Eclipse plugin at all.
Colorizing editor helps for long file or with many comments. Know there are 2 editor plugins for Eclipse.
Simple usecase: assemble an Eclipse product using simple scripts, just dumping bundles into the plugins dir.
This used to work with 3.3 - with 3.5 it's broken: my application doesn't start as the app plugin is not found.
Question: what's the easiest way to fix that? This seems to be the only pain in the whole upgrade process for me.
Attempts:
I guess this is a no-no for P2: it maintains the bundles.info file instead, which is probably very smart.. a bit too smart for me.
Some ideas I had:
can I just skip P2 altogether and get back to plain old, simple -dirty- discovery mechanism?
can I set up plugins dir as a 'watched directory'
looks like I need to use the p2.reconciler for that.. oh wait, it's deprecated already :-( bug 251561.. (thanks VonC for the pointer)
can this old setting in the config.ini still work? (which is now replaced with the 'simpleconfigurator') osgi.bundles=org.eclipse.equinox.common#2:start, org.eclipse.update.configurator#3:start, org.eclipse.core.runtime#start
should I call the (p2) director?
"please pick my plugins up" :)
I'd avoid the dropin folder for this - that's more for the
end-users.
I'd avoid messing with the bundles.info if possible.
I don't care about all those smart features in my product yet- actually the users don't use the built-in update mechanism at all.
So I'd like to KISS (ie: just to start up), and add more advanced support when needed.
I've asked this on Eclipse forums, but no answer yet, so would really be grateful for some enlightenment.
Also, feel free to correct me on the assumptions - I've just read the P2 docs, which seem confusing at times.
Thanks!
Answer: actually option 3 above seems to work after all - thanks Francis for confirming this! (it didn't work originally, but that was probably caused by some missing deps).
My only issue with that now is, some Eclipse bundles actually require simpleconfigurator. So I wonder if swapping it out will cause problems down the line.
You can alter your configuration/config.ini file to not use the org.eclipse.equinox.simpleconfigurator (which does the p2-based configuration) and instead use the org.eclipse.update.configurator which is the old-school way of just configuring whatever is in the plugins directory. This should give you what you want.
Even if it does not fully answer what you are after, you can specify in an eclipse.ini (like the one I describe here):
-Dorg.eclipse.equinox.p2.reconciler.dropins.directory=C:/jv/eclipse/mydropins
That does specify to p2 to monitor any directory of your choosing to detect plugins in it.
Another source of idea could be this article: Composing and updating custom Eclipse distros
It's not hard to create a feature based product that includes these things, and do a product build to end up with something like this:
Note: the concept of reconciliation is detailed in the eclipse Wiki.
For certain installations of Eclipse, there will exist the notion of a shared installation -- this may be in the case of a Linux system where a base set of software is installed via packages (perhaps RPMs), or may be in a Maya deployment where shared profiles are defined in a central server.
In both cases, it is necessary to perform reconciliation between the shared profile and the user's current instantiation of the profile including any modifications they may have made.
Part of this mechanism is the Dropins Reconciler setting. Although, as bug 251561 illustrates, it is not advised to put too many plugins in there.
Maybe this will help you (shot in the dark)? I found this when upgrading my Eclipse installation to Galileo and trying to keep my Flex Plugin install.