To date I have done all my management of SVN via TortoiseSVN. I would like to learn a bit more about how to use Eclipse/Subclipse. The main thing I am trying to figure out is the update. The issue is this that I need to update more then what is in the Eclipse project. Here is what things look like in Subversion:
trunk
Clients
EclipseProjects
Project1
Project2
Project3
Project4
Project5
Project6
Project7
JDK
SQLScripts
The issue is that while the Eclipse workspace only contains a few of the Projects# directories, to run the application one must drop to the command line and run it and the application uses ALL the projects. I also want to be updated the other folders that are at the same level as EclipseProject: Clients, JDK, SQLScripts.
Currently with TortoiseSVN, I simply go to the trunk and do an update. How can I do that within Eclipse when the trunk is not part of the workspace?
Subclipse can only operate on what is loaded into your Eclipse workspace. You have a few options here, not in particular order:
Checkout each project separately using Subclipse. Each project will be its own SVN working copy.
Checkout "trunk" using Subclipse. Just create an Eclipse "simple project" for this checkout. The individual Eclipse projects can then be Imported into your workspace. So projects will show up twice. Once as themselves, and once as a folder beneath the trunk project. If you want to update them all at once, you can take the Update on the trunk project. But you can still take actions on individual projects too.
Same as #2, but do the checkout of trunk using TortoiseSVN. And use TortoiseSVN when you update everything. You will need to do Team > Refresh to let Subclipse know you did something in TortoiseSVN. I would still use Subclipse and import those projects into SVN. Even if you do all your commit and update actions using TortoiseSVN, there are advantage inside Eclipse to having Subclipse installed and TortoiseSVN and Subclipse can both use the same working copy fine as long as they share the same SVN version.
I use all 3 of these approaches in different scenarios.
It's actually quite simple. All you'll have to do is check out the repository using Eclipse check out tool.
In Eclipse, open Window > Show View > Other..., select SVN Repositories. Click New Repository Location, enter your SVN url, username and password. Once the repository added, do Checkout and voilà.
A little advice based on my experience : do not check out the whole trunk! Because then you will have one big folder trunk in the Project Explorer and it's frustrating open three folders trunk > EclipseProjects > ProjectXYZ everytime to actually get to your project. It's also not very visually pleasant and ordered. What I recommend is checkout the ProjectX folders, Clients, JDK and SQL Scripts folders separately. You'll have a nice flat hierarchy like this :
Clients
Project1
Project2
Project3
Project4
Project5
Project6
Project7
JDK
SQLScripts
Remember that using this technique, anything outside the scope of these folders (e.g. trunk/EclipseProjects/log.txt) won't be taken into account. If you have anything like that, you can always put it in the separate subfolder of trunk and treat it the same way as others.
Related
I want to use TortoiseSVN together with Eclipse.
For now I just want to try it out.
So I use a local folder as repository.
I have installed TortoiseSVN 1.7.13.
I created a folder called 'REPOSITORY' and chose 'Create repository here' from
the context menu.
As other websites told, I installed Subclipse 1.8.22 in Eclipse.
I use the SVNKit1.7.9 as client or connector (Whatever it is called).
I had already some projects in eclipse's workspace.
From the context menu I chose 'Team->Share Project'.
That is what other websites told to do.
It did show the normal commit dialog and so on.
The projects are marked as commited but the folder 'REPOSITORY'
is still small in size.
It seems, that the projects where not copied or moved to the repository.
At work we have a server based SVN. I just want to have something like that at home.
Did I miss something?
Isn't it the purpose of the SVN repository to hold a copy of the projects?
So the commited projects should be inside the REPOSITORY, right?
Greetings
Mike
Apparently, you have to manually import the project in Eclipse into the repository created with TortoiseSVN before actually committing to it.
This other page might help you. It gives a very detailed walkthrough of how to set up exactly the kind of local system you want. In essence:
In Eclipse, delete the project but not its contents (Delete project contents on disk unchecked). This will leave the project's folder under your workspace location untouched.
Outside Eclipse, import the project folder into the repository previously created with TortoiseSVN (Right click on folder > TortoiseSVN > Import and select the URL of the repository). Once imported, you may wish to delete the project folder.
Back in Eclipse, checkout the project from TortoiseSVN's repository (e.g. Right click on Package Explorer > Import.. > SVN > Projects from SVN).
Hope that helps.
If your project's folder structure and package structure are the same, you can use Eclipse Subversive. It's just a plugin for eclipse and provides all features of TortoiseSVN
I have two eclipse project. The second one depends on the first one. When I try to rename a java class of the first project (using the rename function on the java file on the project explorer) it correctly do the refactor of that project but it doesn't changes anything on the project that depends on it.
Is there a way in eclipse to tell the renaming function to act even on the projects that are linked to the refactored one? Thanks for help.
My Eclipse version is Juno.
Update:
Forgot to mention that the projects are linked to an SVN repository. Maybe it could be relevant.
Update 2:
I add more details after mliebelt request of clarification.
My Eclipse version is Juno, Eclipse Java EE IDE for Web Developers, build id: 20120614-1722.
I've installed some plugins: subclipse, JRebel, m2e, Eclipse Web Tool Platform.
The second project is linked to the first one as a project dependency in eclipse. I have added the first project in the project tab of Java Build Path. Everything seems to work fine, even the renaming function.
Then, I tried to put the two project in two different SVN repositories. I created two repositories on the SVN server and I installed on my machine the client tortoiseSVN and the eclipse plugin subclipse. Since I didn't succeeded in importing the projects on the server directly from eclipse, I copied the projects' folders in a different location and I removed the projects from eclipse. I used tortoiseSVN to import the projects, each one on a repository with the same name of the project, and than I imported the project back to eclipse. To do that I used the eclipse "import existent project into workspace" function with the "copy project into workspace" option selected. Everything seems to work but not the renaming function.
It does work (for me), so here is what I have done to reproduce the behavior. I hope that this helps to find the error.
Create two projects, and make the second dependent on the first.
Create some source code, so that you can refactor it. Ensure that a class in Test2 is dependent on a class in Test.
Select from the context menu of the method you want to rename. Enter there a new name for the method, only then is the Preview option available. Ensure that Update references is checked.
Press the button Preview to see which classes will be changed by the refactoring.
As you can see, it works for me. Please check what is different in your context:
Define dependency different
Use different refactoring (which possibly contains a bug)
... ?
I then added the two projects to a (local) repository (I use the plugin Subversive, it that matters), and have retried the refactoring, and it works the same way. What is that "it does not work if the projects are in SVN"? The projects have to be in Eclipse, refactoring cannot be done on the Subversion repository directly.
I have made another attempt to reproduce the error, but could not. Here is what has worked for me (no screenshots included):
Installed Java EE from Eclipse (version Indigo)
Installed Subclipse 1.8 from the Eclipse Marketplace.
Defined the 2 projects as before.
Added the projects to the different Subversion repositories by using Team > Share Project...> SVN > select the repository location > Finish
I have then deleted the 2 projects, and instantiated them inside the workspace by doing the following steps:
Go to the SVN Repository Exploring perspective.
Open in the view SVN Repositories your repository locations, and select for each project from the menu Checkout....
The projects will be reinstantiated insided the workspace, and the dependency between the 2 is not lost.
After that, I am able to rename a method as I have shown above.
The problem in my workflow, described in Update2, was that, when I imported back the projects to eclipse, I used "import existent project into workspace" function.
I had to use SVN Checkout Projects from SVN instead, choosing the repositories I previously created.
I use Eclipse to edit Java, and use Git for my VCS. Should I have my local repository in my workspace, or outside it, and copy the files every time I want to commit? I know I can do it every way, but I'm new to Git, and wondering which way is better.
The best practice at the moment is to create your git repositories outside of your workspace. The most common form of repository contains a couple of projects in some logical structure, and the workspace likes projects in a flat structure. See the EGit User Guide/Considerations when creating Repos for more details.
When importing the projects into the workspace via standard import or EGit, Eclipse is happy to point to the other location on disk.
I just have the local repository in the workspace. I'm not sure why you'd want to keep the two separate - why create extra work for yourself?
Code, commit; code, commit... (where "code" includes tests of course)
Inside it. Creating an external one that you have to remember to copy files to, etc. starts to defeat some of the reasons to use a VCS like GIT :)
You can also always create and 'checkout' branches if you want to get some code separate for now. Then both the branch code and the base code are both in VCS and you'll always be able to mange them for merges, etc.
If you are used to subversion you may have this thoughts first. But working with Git means to have the complete repository as your own workspace.
You should configure Eclipse to use git and add to your .gitignore file the project folder if you do not want to have it in the repository.
As development workflow I can recommend the method Vincent Driessen bloged about: http://nvie.com/posts/a-successful-git-branching-model/
You have to remember that Git is just a single .git directory in your project. So you could just have one project folder that you work off of in your Eclipse workspace. If you are using Eclipse I recommend the EGit plugin.
Inside it; especially if all of your work is in Eclipse. Managing the repo outside of Eclispe is going to make it much more likely to add files you don't want in your repo (ex war/WEB-INF/classes). Also, managing from Eclipse means it will naturally be easier for other developers to sync your repo and setup their environment in Eclipse.
I suppose a good exception to this rule would be if you were maintaining a dev-environment folder of some sort (ex, jdk used/eclipse install used/jars for 3rd party libraries to add to build path/etc). So I guess the best general rule to follow would be if you're using Eclipse to change the files, you should also be using Eclipse to manage the file in your git repo.
Also, use EGit if you aren't already (I think others have mentioned this).
i was on a 2-day training introducing as to Java EE. We used there Java EE, Spring Framework, Maven, Springsource Tool Suite (Eclipse), Tomcat.
I took the Eclipse workspace we created there and run it on my work PC. I had, if i remember correctly, only to configure Tomcat properly, and it worked on my PC.
Now i want to save the created Eclipse workspace containing 5 "sub"-projects in subversion so that my work colleagues can checkout this to them and run it on their computers.
How to do this correctly? I found somewhere a svn:ignore rule:
.classpath
.project
.settings
target
Using tortoiseSVN i added to the folder with the workspace this ignore rule, but the found out that the underlying folders target were'nt deleted so i deleted them manually and "added to ignore list". But after that the project in spring source tool suite does not see the mevan dependencies (i think so) because the imports are broken. STS underlines org. in the imports and says it can not resolve this.
How do i correctly version control such a project?
In my project we are using Maven and Eclipse (Helios, currently) and the Maven plugins for Eclipse:
Maven Integration for Eclipse
Maven Integration for WTP
We only have the pom.xml file and the src/ directory tree in our version control system. We make sure not to add the eclipse files there. Then when a new developer starts in the project they do Import -> Maven -> Existing Maven Projects. The Maven plugins for Eclipse then set up perfect build paths, settings and so on.
This way it is also very easy to re-import your projects into Eclipse as needed.
So, my tip is to leave the Eclipse files out of SVN and make sure you can setup the project correctly automatically simply by importing a Maven project.
If I understand your problem the right way, you need to configure Eclipse in order to be able to launch tomcat from it. The key, here, is not maven anymore, but Eclipse, I think. As you've made modifications in your workspace that can't be put in your maven configuration file (the pom.xml), you become "Eclipse dependant".
The key here is that, as you're Eclipse dependant, you need the Eclipse configuration files to work. Consequently, I'm afraid you need to add back .classpath, .project, .settings to your versioning tool... It's not generic, because you force people who work on your project to use Eclipse. But if everybody in your team do so, it shouldn't be a problem.
As I don't use Eclipse anymore, I don't know if versioning theses files can lead to problems. However, I hope this answer will help you to configure your project back...
EDIT : to be more accurate... and maybe give a better answer.
When using a version control system, the main goal is often (always ?) to give all the keys to use the sources, and develop from them. Consequently, you need to put in your VCS your sources, and all the configurations needed to use them efficiently.
In your specific case, the key is that you've become Eclipse dependant through its Springsource Tool Suite plugin. Consequently, it becomes essential to add the configuration files for this tool, because they can't work without them, and if they can't work, you can't work.
I can tell you my way of subversioning maven eclipse projects. First, when you create the project structure you have to commit the .setting, .classpath, .project files into the subversion repository. If you can't do this the other colleagues will can not use the project structure after checkout. After you commit the project structure, the best way is not to commit these files except only when you change something important eclipse or build path settings, because the others will have conflicts due to the system dependent informations. Never commit the maven target directory. Sorry for my english. Hope it helps.
I have a eclipse workspace which constitutes of 15 different java projects . To configure the eclipse workspace , every time I need to add the java projects manually and add the dependency and refrences in the java build path.
Adding all the projects and resolving dependency every time becomes a manual and redundant task. I explored on the .classpath inside the every projects which stores the dependency and refrences information.
I would like to automate this redundant process.
Have any one tried doing that , any inputs will be helpful.
I don't need to add same project more than once , but often need to create a new eclipse workspace with new code changes and delivery (I can't take some of the changes in the current work space).In simple terms for e.g if some one need to create eclipse workspace again and again , or multiple people need to create the same workspace for their work . How can we reduce that manual effort?
I am still a little unsure about your motivations but I am going to assume that by new code changes and delivery you mean a different revision/branch of the same code base. For this purpose and for many other reasons, if you are not using source control like SVN or Git, look into it. These tools are priceless and also free.
Eclipse
I don't think this is technically part of your question but I wanted to add it for completeness. If you're implementing the techniques below, it is also handy to have a 'fully loaded eclipse'. I keep a 'fully loaded eclipse' on a network drive somewhere with some plugins pre-loaded so that new additions to the team don't have to download/install the plugins. It's not hard to do since eclipse doesn't need to be 'installed'. You can just copy the eclipse folder to where you want it and run it. Personally I like to include plugins for source control, code style, code coverage and metrics but you should include anything that you use consistently in your project.
The Workspace
To copy an existing workspace (not including any projects, I'll get to that later) all you have to do is copy the .metadata folder from an existing workspace folder to an empty folder that will be your new workspace folder. When you start up eclipse simply choose the new workspace folder and you will have all the same preferences as you had in the other workspace.
I have used this technique before so that when people join a project they can take a copy of a 'clean workspace' I keep on a network drive somewhere that helps them get up and running quickly. Preferably, this 'clean workspace' should not have any preferences that are only personal preferences like having the perspectives setup just the way you like it but should only have preferences like Ant global properties, compiler compliance level, pre-made commonly-used external tool and run configurations etc.
Projects
For the projects themselves, I would recommend checking them into source control including the eclipse .project and .classpath files. The SVN plugin (subclipse) makes it very easy to do this. Then when someone joins your project, all they have to do is check them out as projects in their new 'clean workspace' which is also very easy to do. Since the project you're checking-out already has the .project and .classpath files, all of the dependencies are already setup! Just make sure that all the jars and any other dependencies are checked-in with the projects.
Workspace Setup Procedure
Take a copy of the 'fully loaded eclipse'.
Take a copy of the 'clean workspace'.
Check out the projects into that workspace.
That's it! Your new recruit should be ready to go!
Multiple Code Branches
Now, if I was right to assume that by new code changes and delivery you mean a different branch of the same code base, creating a workspace for a different branch as easy as following the same steps but checking out the required revision or branch instead of the latest version from the trunk. If you don't quite understand what I mean by that, read up on source control.
Cudos
Good on you for taking the time to do this, I have been in projects where it can literally take a day to get setup...
Maybe little late, but stuck into the same problem and found a tool in eclipse marketplace that helps to manage setting up and launching eclipse all time for different branches, new developers or other reasons.
The tool is called yatta.
With this, one can create profiles which can be based on their current running eclipse with all the tools, plugins, workspace, CSM repos and what not.
This profiles can be exported to yatta profile hub which can be public or private and later shared with different developers and can be imported and launched.
You don't say whether you're using a build tool other than Eclipse, but if not you should.
Eclipse is able to parse Ant files to discover the source directories and libraries. And Maven and Gradle can both generate Eclipse project files for you to import.
As a longer-term benefit, using a build tool means that you can easily build and deploy your projects without any need for Eclipse. And it will be easier for new team members to work on the projects, as they won't need to figure out all the dependencies.
If you don't already have people with expertise, I would recommend Maven. It's easy to set up a basic Java build script, and its dependency management features are IMO better than the alternatives. It will, however, force you into its way of doing things, particularly wrt source tree layout.
You should really look into build tools like Maven, Ant, .... Those can generate needed classpath variables for you automatically and can do many more things as well
If you're checking out the projects from CVS / SVN in Eclipse, then it's possible to create a Team Project Set. This is essentially an XML file that will contain a list of projects and their source repository path
It can be exported via File | Export | Team | Team Project Set, and imported into another workspace via File | Import | Team | Team Project Set
There's more information on this feature at this link on Javalobby
Using vagrant it is quite easy to automate setting up an entire desktop development environment.
See the answer I provided to a similar question here, which has links to scripts that automate checking out maven projects, creating an eclipse workspace and importing the projects.