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
Related
I've forked a Github project, used Eclipse to clone it locally, and imported that as a general project into Eclipse.
The accompanying .project file is an Eclipse .project file with the proper "nature" and "buildCommand" xml tags.
So it seems like a valid Eclipse project. However, I'm unable to specify a run configuration or configure the build path.
When I select the Build Path popup menu item, it says "no actions available" in grayed out text. When I select "Run/Run As" from the main menu,
it shows (none applicable). I'm wondering if the problem is that the project imported completely as source folders:
There are no packages to speak of. I created another project from scratch, and created the proper source folders and packages as needed
to match the package statements in the source code. After manually importing the source from the git repo, I can build and run that project.
If the lack of packages is indeed the problem, is there a quick way in Eclipse to convert source folders to packages?
What you did is you have probably cloned the repo in Eclipse and then Imported this project through a New Project Wizard, because in GitHub there is no existing .project (and no .classpath) files.
The "New Project Wizard" will create a set of defaults for a java project (I suspect that you selected just that), but is anaware of Maven structure, so all source folders will not be recognized and you will end up having to define them on your own. Worse, you will be unaware of any special parts of the Maven build that might be configured within pom.xml.
Because this project uses Maven for building, it would be better to use M2Eclipse while importing it. Install it using Help->Install new software.
Then there are a couple of steps required to make it use all Eclipse features.
Keep your cloned copy of the repository or clone again if you want to start from scratch. Then use File->Import feature to import a maven project into the workspace. Select Exisiting Maven Projects and point to the directory containing pom.xml file in the cloned repo. This will use Maven integration in Eclipse to generate .project and .classpath files based on pom.xml contents, so you will be able to more closely mimic Maven build in Eclipse. All source folders should be properly discovered this way. Eclipse might want to install some additional integrations for Maven features that this particular project uses. Let it, if that is the case.
Now, you will have the project operational and compiling in Eclipse, but it will not be aware that it is managed by Git... This is because M2Eclipse and Git Team provider are not integrated (at least they weren't when I last checked). In order to be able to commit to the repository in Eclipse, remove the project from workspace, but without deleting contents. Then, import from Repository view using Import Projects/Import exsisting Eclipse projects. Since necessary .project file is already generated, Eclipse will autodiscover the project and will use the right configuration prepared earlier by M2Eclipse.
In the end you will have a properly configured Maven project with Git as a team provider for it.
If this is a project meant to be built by Maven that contains a pom.xml file, install M2E before importing the project from your local cloned repository. It will handle this.
Right click at root of project select properties, in the sources tab add the folder "src/main/java" as source folder
Other way is to configure facet as java
I'm helping develop a software product using Java (Eclipse Kepler for RCP Developers is our IDE) that is made up of dozens of plug-ins. We store all of these in an SVN repo on Sourceforge.
We have just been told that due to a legal problem, one of the plugins cannot be accessed via a SVN repo.
I moved it to GitHub and then imported it into my workspace, but am now unable to get the project to build in Maven. I receive this error:
Child module /x/x/x/github.project of /x/x/x/project.build/pom.xml does not exist.
The pom.xml file of project.build contains this line
<module>../../github.project</module>
Which should still be correct.
The pom.xml of the plugin project has not been modified, so it still shares the same group ID as the other plugin and all of the parent information is correct.
Can anyone give me some advice on how to properly integrate this plug-in? Is there a way to "require" a GitHub project in SVN or a different way to ensure it's included?
Thanks.
There are quite a few questions on this topic, but there are no satisfactory answers unitl now, e.g this.
I'm using Eclipse Kepler (20130529-2219), with ME2 (1.4.0.20130601-0317) and Eclipse Git Team Provider (Java implementation of GIT 3.0.0.201306040240-rc3). So I started with great expectations after reading how great git is.
Firstly, I opened an existing project and removed all the .svn rubbish and commited it to a local git repository. Perfect - now it is time to push the files to a remote repository. After having some problems creating the known_hosts file on Windows the push was successful.
Now the problems started: I wanted to pull changes for the repository, but "... not configured for pull". OK, here it was discussed that this is a common issue, and you have to delete the project and then reimport it from a remote server to allow pulling.
Hence, I set up everything again and pulled the project. Until now I was always told that .project files should not be commit to version control, therefore I didn't include them. The "import -> import from git -> local"-menu does not recognize the files in the repo as a Java project. I can therefore only import the project as a general project or use the project wizzard and set up a new Maven project, which is stupid because all information already exists in the POM.xml. If I do a plain project import, Eclipse does not know that it is a Java or Maven project and throws tonnes of errors.
Question (skip detailed problem): Is there some less awkward way to import a Maven and Java project from a remote git repo when no .project file exists?
Easiest solution: do include the .project (as in this answer) in your git repo.
And do include also the .classpath, since you now can reference relative paths in it, instead of absolute path: see ".classpath and .project - check into version control or not?"
I found an alternative to keep .project file out of Git version control. As you said the pom.xml file should be enough for IDEs to figure out that a maven project it´s in place (and it is).
Let's say you have pushed your project into Git (without .project file) and now you want to import that project into Eclipse.
Make sure you have the Git repo added into Git perspective
Go to J2EE Perspective and double click on an empty space on Navigation View. Import -> Existing Maven Projects
Browse to your Git repo location and voila! Eclipse should catch all pom.xml files and determinate they are independent Maven projects
In my case this worked to pull multiple projects located at one same Git repo, each of them only storing pom.xml file (and no .project at all)
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 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.