I want my application shaped changed by modifying org.eclipse.ui.workbench plugin.
but the problem is even though I import it with source , it is not operated.
How do I solve this out?
It looks like importing a plugin from source leaves the *.properties files behind. They are required, however; and must be copied manually in order for the plugin to be functional.
Don't do that :-)
Two reasons:
(1) as soon as you switch to a newer version of Eclipse, your code won't work. You have to merge all the changes that had gone into workbench plugin
(2) By modifying the code and not submitting the changes back, you are violating EPL. (I'm not a lawyer, so check with a real lawyer for more details)
Related
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.
In order to modify an eclipse plugin, what are the steps to find its editable code ?
I read and debug source provided with eclipse distribution but to try a fix in org.eclipse.jdt.internal.corext.codemanipulation behavior I need to make it editable.
Well, the source repository is available at eclipse.org, the plugin compiled with the source should be available from the standard eclipse update site.
I'm guessing you are considering changing the source, recompiling and using your plugin instead of the standard one? There is a different way to change functionality, its with fragments. For example, look at a question I asked earlier, follow the links in my text and Andrews answer for more information.
The problem: we have dozens of Maven sub-projects (managed by m2eclipse) in our 3-level POM tree and people keep adding and removing some of them on a bi-weekly basis. The problem is further complicated by a fact that not all newly added projects result in compile-time error when they are missing. The could end up not being dropped into OSGi container since people forget to import them properly and Eclipse for some reason doesn't know about their existence automatically.
Currently, people have to watch some mailing list and whenever there is such an event, they have to go and either manually invoke import wizard for the very root POM and add missing projects or manually remove some of the not needed ones. Moving/renaming is a combination of removing/adding.
That all is very error prone and we would like to automate/simplify the process somehow.
Ideally, we would like to have the following workflow:
1) sync
2) fire Eclipse
3) Some hook to trigger which would analyze developer's workspace against latest POM tree (the very root POM is fixed and known)
4) There should be some button somewhere which would be:
- green, if everything is all-right
- red, if not
Clicking it should automatically remove not needed projects (and update Eclipse internals) and add the new ones (some sort of invoking import wizard in a silent mode).
Is it possible with the existing functionality? Or would we have to somehow extend m2e? Any other solutions???
Any help would be very appreciated!
P.S.
We're aware that this type of problem we have is probably due to badly designed project structure. However, it's not easy to get that fixed while running on tight release cycles. So, we need an interim solution.
This smells to me that you're fixing a wrong problem. I doubt something like this would be supported out-of-the-box in m2e - unless one day it becomes best practice to put each type in it's own module. After some time project modules should stabilize, and reflect architecture which can change but not frequently (major versions only). If it changes too frequently then not enough thought has been put into design decisions. Consider splitting projects into multiple sub-projects which one can checkout/clone and work independently on.
When syncing changes just check if there were modules added/deleted - and if so, after sync just logically remove and then import back existing maven projects.
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.
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.