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.
Related
I have a working maven project on eclipse which I made using the archetype for Jakarta EE with an ear packaging using windfly 21. (org.windfly.archetype - wildfly-jakartaee-ear-archetype).
After i got a working webpage, i decided to share it on git, using the eclipse GUI. (Right click on project -> Team -> Share).
This moves the project onto another folder, as it says that having git repositories inside eclipse default workspace folder is not recommended.
The problem is that after sharing it, even before I commit or push, it stops working. It stops recognizing packages and I'm unable to make it "run on server".
This is an image of how it looks after I share it on git. I cannot execute "p1parte1" or "p1parte1-ear" anymore (neither any of the other projects/modules), and the other projects below dont have the java classes inside.
I literally have no idea how to fix this, i've spent like 3 hours searching online and trying things.
I solved this by manually fully copying the project that was not shared in the eclipse workspace folder to the git folder.
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.
I'm moving over from eclipse to Intellij, and I hit a snag on setting up my project
I have 4 projects on github that, in eclipse, all live in one workspace. They are API, Server, Client, and Basic Plugin, and they each have a Maven pom.
What I want to do is set up Intellij's project structure similar to Eclipse's workspace, where all 4 of those projects are side by side in the explorer, but it's not letting me import more than one maven project as a module (I import the first fine, but the rest silently fail), and importing directly from github creates a whole new project for each repository, which is not ideal.
I tried to import a in my eclipse workspace, but it all broke (Object and Math were not found), and all the java environment setting were wrong.
Any ideas? I'm fairly new with Intellij and I really like it, but I don't want to switch over from eclipse if I can't get my workflow right.
First of all, Intellij IDEA uses different naming than Eclipse, you can learn the details here: http://www.jetbrains.com/idea/documentation/migration_faq.html. In short, Eclipse's Workspace is called Project in IDEA, and Eclipse's Project is Module in IDEA. In your case, you want to have multiple Maven-based modules in one Project. You can do it by creating a Project with one Module and then adding the rest of Modules (File->Add Module->Import Module from external model->Maven etc.).
As for the multiple Git repositories, you can configure that using this help page: http://www.jetbrains.com/idea/webhelp/git-branches-in-multirooted-projects.html
In your case, have a look at the 'Asynchronous branch control' section). It's really straightforward, I have just done it myself for the first time by following these instructions.
Good luck.
UPDATE: The above link now gives 404, so here are the most up-to-date ones that may be of help:
https://www.jetbrains.com/help/idea/2017.1/git-branches-in-multirooted-projects.html
https://www.jetbrains.com/help/idea/using-git-integration.html
IntelliJ opens one project at time, but this project can have multiple modules ( say, maven reactor ). So modules are kind of [related] workspace projects in eclipse. You also can open several independent projects in different windows.
In case you have working maven reactor build, you can just open topmost pom as project and everything will be set up. ( treat maven reactor as your workspace )
I have imported project with Maven. But Subclipse didn't recognize that project already in SVN (I don't see pictogram barrel). For team in context menu I see 2 options:
Apply path
Share project
Which one I must select? In SVN repository there is already project made by other persons.
And I also made checkout by Tortoise. So I need only to recognize SVN local repository by STS.
Sharing the project should make it detect that .svn directories already exist, and should propose you to keep these files and use the information they contain to establish the SVN configuration of the project.
svn is a versionmanagement system. if you got old code and someone released a newer version you can apply a patch. you can share your project on cvs svn and git. like github or google project.
you need to go to new svn repoository and select the one of your project. then you can checkout project as new project. maven is for dependencies, not for code manipulation
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.