I'm working on a large project (~200 eclipse projects) which is stored on a remote subversion server. I have to do an update every day (and at least a partial update/sync before every commit). The full update takes quite some time, so I'd like to have my machine do this before I arrive at work. Is there a way to do this in eclipse (3.5 on Windows XP)? Probably an external script calling svn command line tools on the project folders and then starting eclipse could do the job, but I'd like to use the svn tool in eclipse if possible.
You're much better off having this done by an external script, but if you have to do it in Eclipse, use the Eclipse Monkey plugin, which will allow you to do scripting inside Eclipse.
Unfortunately there's not too much info available for Eclipse monkey, but here's an introduction:
http://eclipse.dzone.com/news/introduction-scripting-eclipse
It is possible with subclipse plugin:
goto Synchronize view and choose the menu (the small triangle on the top right). then press Schedule... and there you can define Synchronize automatically and choose on what time.
You have to change to JavaHL in eclipse
First install in system:
subversion-javahl
additional information:
https://github.com/subclipse/subclipse/wiki/JavaHL-on-Linux
Related
The jar was created in eclipse but does not contain source code, only class files. Essentially I am wondering if Eclipse has a built in decompile feature that I can use to restore source code to an earlier version.
If I need to use a 3rd party decompile tool what is recommended?
Going forward, I will be sure to include source files in the .jar
Thanks in advance for any advice.
I am using eclipse
Eclipse Java EE IDE for Web Developers.
Version: Luna Service Release 1 (4.4.1)
Build id: 20140925-1800
There are Java de-compiler plugins available, but keep in mind that you are not going to get your original source code back. The de-compiled source will be equivalent to what was originally compiled, but may not be easy to read, especially if the classes were compiled with symbols removed.
Here is one plugin you can try:
http://jd.benow.ca/
If the versions you want to go back to are very recent (in the last few days) you may be able to use the Eclipse local history. Right click on a file and select 'Compare With > Local History' to see what Eclipse has.
You can configure how much local history Eclipse keeps in the Preferences in General > Workspace > Local History.
I have Eclipse + PyDev installed on my laptop and desktop, both of which are dual-boot Windows Vista 64 & Ubuntu 12.04. Right now the only 'version' I have fully fleshed out pretty much the way I want it is in Windows on the laptop. What would be the best way to duplicate (and hopefully synchronize) this across both computers and both operating systems? In this case the only one using the account(s) would be myself.
A few suggestions:
If you just want to refine your Eclipse installations with some
common configuration then allow them deviating from that point, you
could copy your workspace folder to all places you want, then switch
to those workspaces from within Eclipse. You can also export your preferences from
within Eclipse using File > Export > General > Preferences, that may work as well,
or better.
If you want to share Eclipse configuration between Ubuntu and Windows, you could install NTFS-3G in Ubuntu, then make Eclipse workspace point to your Windows partition. I'm not sure if Eclipse can deal with this well though (for example JDK path).
If you want to use same configuration for all of your devices and operating systems, and considering you won't be using more than one Eclipse instance at same time:
If you have wi-fi, you could share your Eclipse workspace in Windows then map a network drive letter in the other Windows, and mount a remote network location in your Ubuntus. You could still use second suggestion above for same device.
Alternatively, you could use rsync or similar to synchronize your different workspaces, both when you start and close Eclipse. This way, you move possible performance issues with above option from when you are using Eclipse to when you are starting or closing it.
You sync on start for getting up-to-date with latest changes from other devices, and on close because you want to push the changes you have made to other workspaces as well. In Ubuntu, you could just wrap the sync commands around Eclipse call in a shell script, and in Windows you can do the same with Hidden Start, except that it can hide shell window for you.
You could use services such as Dropbox, Skydrive or Ubuntu One to store your Eclipse workspace and let their client software do the synchronization job for you.
This is what came up to my mind. Maybe Eclipse has something built-in to deal with this other than export wizard, not sure.
What exactly to share
Remember that the workspace is where all your personal configurations reside, including the list of projects you see when using Eclipse. If some of these projects are outside workspace directory you may face path conflicts, for example C:\MyProject present in your PC but missing in laptop. You could keep all your projects within workspace directory for avoiding this though. Also, if you go for the first suggestion, export wizard as said may work better.
I don't think it's a good idea to share only part of workspace, unless you know what you are doing, and I don't see much benefit from sharing whole Eclipse directory itself (which is not possible between Linux and Windows anyway). You can find out where exactly your workspace is located in File > Switch Workspace.
I came across this post and wondered if there is a way to activate only a few of all of my installed plugins depending on the workspace I currently work in.
For example - If I organized my workspaces like this
/workspaces
/java
/jee
/php
...
I don't need the Android-Plugin if I'm working on my Java EE-Projects and so on.
I also came accross this, suggesting to deactivate some capabilities for each workspace. But this not an option, as apparently no plugin is registered as capability.
Thanks, m
Edit: BTW, I am using Eclipse 3.5 Galileo
Maybe you can achieve your goal but it needs lots of "customization work" so I would not do it for myself :)
Create a "minimal" Eclipse install with plugins you use all of your workspaces.
Create one dropins folder for every workspace and put all of your "workspace-specific plugins" into that folder.
Create an Eclipse shortcut for all workspaces and use something like "-data _workspacedir_ -vmargs -Dorg.eclipse.equinox.p2.reconciler.dropins.directory=_dropindir_" in the shortcut.
Start eclipse with one of your new shortcuts.
Note that in this case you cannot switch workspace within Eclipse, you have to close the current one and start the new one using the corresponding shortcut.
UPDATE: I have found some Eclipse feature request for making this kind of setup easier if they will be implemented:
Software Update must allow to install plug-ins into extension location
Support for multiple bundle pools
You can use a different configuration folder for each Eclipse instance using the -configuration option when starting Eclipse.
On Windows, I would use a batch file (e.g. run-eclipse.cmd) which looks a bit like this (a bit different on Unix, more complex on OS X because of the app packaging):
eclipsec.exe -clean -configuration configs/%1/configuration
Execute it with your environment ID (e.g. run-eclipse.cmd java). I use eclipsec because I need the console output, but you can use the plain eclipse.exe executable. The -clean is not mandatory either.
Under my Eclipse installation folder, I will have a configs folder and under this folder I will have multiple configurations. Each config folder can have its' own plugins and folders. AFAIK, if you install plugins they will be installed in your configuration folder and not your main installation folder.
The structure you get is like this:
Eclipse Folder
plugins
features
configs
java
plugins
features
configuration
Eclipse plugins are expected to start only as needed, in a lazy manner. I'm not saying that all behave exactly that way, but if you write your own plugin, you'll see this is how the technology works, your plugin gets called only as needed.
So in Eclipse, if you configure your starting Perspective (Java for me) to have only the Views you need, the plugins that are used for other views should not be started.
To do this, take the view away and save your perspective (Windows - Save perspective as).
In addition, in Ganymede, in Windows - Preferences - General - Startup and Shutdown,
there is a list of plugins that should be started on startup, so you can edit that list.
I didn't try to see if this works per workspace though.
Although my solution won't let you install plugins per workspace but will solve the problem.
The best way i found to do this is using different eclipse copies:
Extract officialeclipse.zip to two different places and install plugins you like per eclipse.
A bit late answer but if you want to manage many workspaces shortcut the following tool is very simple and helpful : http://www.xdreamteam.ch/downloads/eclipselauncher/
I use it for sorting my projects by customers and workspaces, and it launch the right workspace with all the necessary configurations needed for each.
Hello is there a way to use svn command line from eclipse?
Within eclipse in my project browser i can righclick and then click team and than i have something like svn. Not sure which plugin it is. But it doesn't have button's to for example ignore files for uploading. That's why I want to to it command line. And my question is how to do it.
Ok so how can I use it from command line in windows xp?
The plugin you are probably using is Subclipse. It should have an "Add to svn:ignore" option. If not, try updating to the latest versions of Eclipse and Subclipse. In general subclipse should be enough and there is no need for the command line.
For Windows XP I recommend Tortoise SVN. It integrates with the Windows Explorer and offers you a graphical environment for all your needs. I would say that is much more stable than subclipse and very easy to use.
If you do want to use the command line tools, download and install svn-win32 from here. The command line tools could be helpful in merge and copy operations.
I should also point out that none of these methods interfere with each other. You can work with Tortoise SVN or the command line and subclipse won't be affected. All svn clients work by writing and reading from hidden directories called .svn. There is one such directory in every folder under source control. As long as the svn client software is of the same version, an svn client can write to these hidden folders and another one will be able to read from it. A problem could arise if one of the clients is updated to a version that uses a different protocol for writing to the .svn folders. In that case, older clients won't be able to read the information stored there. Upgrading them to the latest version will solve the problem.
Not sure what you're trying to do; sometimes it's better to describe the goal rather than the means you plan to do it.
Have you tried Subeclipse? It lets you use SVN inside Eclipse; it's great.
I'm not sure if you can use it from Eclipse, but nothing stops you from just using it. From cmd / xterm / whatever. It's not going to interfere with Eclipse in anyway, nor will it interfere with Subclipse (which I'm assuming is what you're using).
I'm using subclipse, and in generaly it works pretty well.
However, and I guess this is your problem, the Team Synchronization by default wants to add all files in my projects, not just the ones I add to version control. This is lame and frustrating, and apparently there's no way to turn it off. Screenshots for older versions, however, hints at the possibility of turning the "feature" off. Frustrating!
I'm not personally a fan of Subclipse - it slows the IDE a bit too much for my taste. Here is an alternative approach using External Tools and TortoiseSVN
Create a new External Tool
Call it SVN Commit
Set the Location to \bin\TortoiseProc.exe (mine is C:\Program Files\TortoiseSVN\bin\TortoiseProc.exe)
Set the arguments to /command:commit /path:"${selected_resource_loc}"
Open the file / directory you want committed and run the external tool.
Interchange the commit in step four for additional commands. You can also add the specific tools to favorites and have them in a dropdown on the toolbar.
Additional Arguments Here
Not intended to be too presumptuous here, but I think you should look at whether Subversive or Subclipse actually solves problem in a different way than you intended. For instance, it is very much possible to ignore files and directories from being checked in, via Subclipse.
On the other hand, if you really want to hack away via the command prompt from Eclipse, you must install the Target Management project (supported for Eclipse Europa and Ganymede). Once you have that installed, you can launch a remote shell to your local machine and then type away on the command line :).
PS: I haven't used this approach ever; Subversive satisfied all my requirements of a SVN plugin in Eclipse.
Most of the work being done at my company is Qt-based C++, and it's all checked into a Subversion repository. Until now, all work on the codebase has been done purely with nano, or perhaps Kate. Being new here, I would like to take advantage of setting up Eclipse -properly- to edit my local copy of the tree. I have the CDT "version" of Eclipse, and the Qt integration, and the Subclipse module. At this point, though, I don't know what to do. Do I "import" the projects into an Eclipse-controlled workspace? Do I edit them in place? Nothing I've tried to do gets Eclipse to recognize that the "project" is a Qt application, so that I can get the integration working.
I would create a new QT project in eclipse, then switch perspectives to subclipse and simply do a SVN checkout into the new eclipse project. You should be good to go.
OK, I've been playing around with this idea, and it has some merit. I can switch to the "SVN Project Exploring" perspective (which I hadn't noticed before), and do a checkout from the head of the sub-project I want. I get a nice SVN-linked copy of the tree in my Eclipse workspace for editing. Eclipse even "understands" the classes, and can do completion on methods and such. However, I still can't get Eclipse to understand that the project is a "QT Gui" project, such that I could view the properties, and control the linking of the various Qt libraries and the like. By extension, it also doesn't understand how to build my project, like it would be able to do if I had created an empty Qt Gui project from scratch. How do I get this part working?
I have exactly the same situation at work (with CVS instead of subversion and the rest of the team using KDevelop but that's no big deal). Just start a new Qt Gui project using the Qt - Eclipse integration features and then remove all the auto generated files. Now using the "Team" features of eclipse and choose to share your project, enter the path to the repository and you 're good to go.
Checkout the project. It will ask you some options like if you want to start with a blank project, or want to use the tree to make a new project. Choose the latter and you should be ok :). It seems to work for me with Ganymed and subversive(not sure about subclipse and i don't remember.) :)
The only way I could get this to work was to check out the project with eclipse and then copy over the .project and .cdtproject files from another Qt-project. Then do a refresh on the project. This is a horrible hack but it gets you started.
You might need to define another builder for 'make'.
Second nikolavp - Checkout, and mark the option to use the new project wizard, then select Qt project. I've done this (with ganymede) and it successfully finds everything and builds correctly.
My solution:
go to the svn-view and add the repository location for your project
check out the project some temporary location with svn or any client you like
choose 'File->Import...' and say 'Qt->Qt project'
browse to the location of the *.pro file, select and hit the OK-Button
you are in the game with an appropriate Qt-project and Subversion Access for that project
I would say the same as the last one,
but instead of the two first steps I would set up the Qt-Eclipse integration:
Qt-Eclipse integration before looking for the *.pro file.