I'm working on an open-source cross-platform C++ project that supports Make and Xcode builds. I'd like to add an Eclipse project as well, but there seems to be no double-clickable way to import a project into Eclipse. Consequently, my "project" consists of fact that I have .project and .cproject files checked into the repository.
torc/
trunk/
eclipse/
??
sandbox/
.project
.cproject
...
src/
.project
.cproject
...
xcode/
torc.xcodeproj/
...
...
Suppose somebody downloads the code but doesn't use Xcode. They can build the code with Make, but many people will probably want to peruse the code structure and sources, and Eclipse would provide a great way to do that.
Unfortunately, the user may not be familiar with Eclipse or how to import projects, and I'd like to make things easier for them, not harder. I was hoping to provide something double-clickable or draggable that would get them started with minimal grief. Can anybody suggest a good way to do this? Or is there an alternate approach that would feel natural to current or prospective Eclipse users?
I am aware of this approach, using org.eclipse.cdt.managedbuilder.core.headlessbuild, but that seems to work primarily with never versions of Eclipse and CDT.
I have an answer, but it's not very pretty.
You could create a workspace directory for your project in your repository and check it in with the project already added to the workspace. Then, you could create a script which launches Eclipse and tells it to use the workspace directory in the repository. (For example, eclipse -data ./eclipse/workspace.) You should make sure the workspace has been cleaned first because a workspace that has been built can contain quite a lot of extra metadata.
That said, this is not a great solution. Experienced Eclipse users will probably not want to use your workspace because preferences are stored in the workspace, and besides, if they see a .project and .classpath file, they're already going to know how to import it into their own workspace. People unfamiliar with Eclipse are likely not to have Eclipse installed at all.
Related
I want to import a maven project from GitHub into intellij which in of itself I know how to do however, the project this time was created initially also as an eclipse project and I want to be able to work on it in idea while my team members work on it in eclipse without causing conflicts due to differing project file structures. How can this be done?
When checking it out in Intellij it does ask me if I want to create a project from it and select yes but next, it asks whether to create the project from the existing sources vs from external model. From the external model option it allows me to pick eclipse or maven but not both. Do I just create from existing sources? Which is my best option to do this without screwing it up for the others when I commit and push my changes?
I understand that the easy answer might be: "just use eclipse" however, I think the answer on how to properly do this could be useful later. Not only me but also for others who want to work with the IDE they are most familiar and productive with and not mess with the workflow.
Any help would be appreciated
When importing an Eclipse project into IntelliJ, you have the option to:
Create module files near .classpath files
Keep project and module files in
The idea is to keep your *.iml file concurrently with your Eclipse .project/.classpath (and you can keep them in sync).
That way, you can open the project in both IDE.
All!
In our project team, people use either IntelliJ or Eclipse IDE depending on what they are comfortable with. Eacf of the IDEs have their own settings files. For instance, IntelliJ uses .idea and .iml and Eclipse uses .project, .settings, .classpath! While some other stack overflow thread says it's not needed to check in any of these files from either IDEs if you are using Maven, I'm unsure why that's the case. None of the threads say why using Maven does not warrant (some of) the settings, .project, .classpath be checked in?
Can someone help me understand 2 things
1) Why don't we need these files to be checked in when using Maven?
2) If we must check in (Assuming Maven is not used), how do we ensure that either IDEs work okay when checking out from source control and what to check in to ensure cross compatibility.
Thanks!
1) These files are not needed because bothe IDEs can import maven projects using the pom.xml file. So the pom.xml file is your single source of project description for both IDEs.
https://projects.eclipse.org/projects/technology.m2e
https://www.jetbrains.com/help/idea/maven-support.html#maven_import_project_start
2) You see it right, it's hard to ensure cross-compatibility if you use only the native project files of the IDEs. Among many other things that's why it's encouraged to separate the build chain (Maven, Gradle, etc.) from the IDE. Also continuous integration systems can be configured more easily if a unified build tool is used so it's kind of a best practice to use one and keep it independent from the IDE.
In case you don't want to switch to maven now, check in the Eclipse .project and .classpath files, Intellij is able to understand them.
I have a netbeans project that is under mercurial. What I would like to do is to strip down everything that makes this project netbeans project to only to leave code in there so that I can easily import it in say eclipse.
Is there some automated way to do this or do I have to remove manually this?
What approach would you recommend.
Cheers
You only have to add the nbproject folder to ignore (= don't check in). All NetBean-settings are placed in this folder. Dont check in the build and dist folder as well, because these contain the compiled code (but they are ignored per default).
The best way to do "IDE neutral projects" is to use Maven !
In NetBeans when the project is Maven-based (as opposed to Ant-based) you'll see that all those NetBeans-specific files that you normally see in nbproject folder are just not there. The nbproject folder doesn't even exist. The reason is that for a Maven-based project NetBeans essentially uses the pom.xml as the definition of the project and that's a good thing because the POM is portable and directly understood by other IDEs.
Even for a Maven-based project NetBeans will still store some IDE-specific stuff in a file called nb-configuration.xml but you can include all of the contents of this file as properties inside the pom.xml. These properties will then be ignored by other IDEs when they load the POM. This way you can pretty much avoid altogether to check any IDE-specific files into the VCS. Also it is worth mentioning that the stuff in nb-configuration.xml is never needed for someone else (using NetBeans or another IDE) to be able to build your project. Another way to put it is that it contains non-essential data. The POM - by virtue - is always guaranteed to be a complete description of how to build the project.
Contrary if your NetBeans project is Ant-based then at least in my experience you cannot avoid checking NetBeans specific files into the VCS ... because otherwise even those using NetBeans won't be able to correctly open your project.
However even with Maven there's one area where you'll be forced to have NetBeans-specific files in the VCS and that is if you use the Matisse GUI builder in NetBeans. The Matisse GUI builder produces some proprietary files with .form extension and you really need to have those in your VCS. But this is the only example I can come up with where NetBeans-specific files will need to go into the VCS assuming your project is Maven-based.
If the project indeed is Maven-based and you still feel that there are NetBeans-specific files that you need to have in the VCS then let us know exactly which files you're thinking of. Then we can take it from there. :-)
Should I put .classpath, .project files and .settings files on SCM when working with Maven project with m2eclipse plugin? Theoretically every developer can grab the sources and import maven projects.
Due to your experience is it better to do this that way or to put Eclipse files to SCM too? Some developers are using InteliJ so I don't want the projects to be Eclipse specific. It seems that the .project file may change according to the set of installed plugins, e.g. change buildCommand from org.eclipse.jdt.core.javabuilder to org.eclipse.wst.common.project.facet.core.builder etc.
Please share your knowledge and experience.
In my experience, you should not include .classpath, .project or .settings. All the information needed to re-import the project is in the pom file, so long as you use "import existing maven projects".
If you put all those local ones, you are likely to end up having SCM changes for irrelevant things, such as different order of entries, local modifications someone made to their project preferences, etc...
As per my experience , it is safe to check-in .project file as it defines the nature and other properties which is useful for developers who will be creating new workspace. Many times, custom facets needs to be added via Eclipse and you may want to share it with other members of your team provided all others use the same IDE for example RAD.
They won't have to go through the pain of again setting and changing project nature, so it might help. Even we had to share our .settings folder in most cases because ppl were facing issues with workspace setup. So all depends on the need and it might help.
One situation in which it is very convenient to have Eclipse project files under version control is when you have Java code automatically generated by plugins. Eclipse removes missing source directories from its configuration before code generators run.
UPDATE
With recent Eclipse releases (I'd say since Juno, certainly since Mars) this is no longer the case.
Over the years the m2e plugin was greatly improved and nowadays there is really no need to store project settings in your SCM, as these settings are properly recreated from the project POM. This has the added benefit of allowing the use of different Eclipse releases with the same project.
What Eclipse specific files should I add to the VCS (Subversion, GIT, etc...) when sharing an Eclipse project?
What I have here:
.autotools
.cproject
.project
.settings/
Just stumbled upon this and had the same problem some time ago, so I will try to share my experience.
First it depends on who are the other users of the VCS or better what programs they will use. If they do not use Eclipse these files will only pollute their projects.
If they do use Eclipse the files might be of use to them, but in my latest project I did not include them for the following reasons:
Everyone had another system which meant other paths for the includes and so on. Concluding from this I surveyed the contents of these files to see if they should be used:
.cproject: The includes are listed here, so you will have different files in the list on each platform. -> leave out
.project: Found some environment dependent paths here too. Maybe it also has a problem when there are different plugins installed. -> leave out
.settings: It might make sense sometimes to share the settings but usually it is each developers own decision. -> leave out
.autotools: I did not use this, so I cannot say anything about it.
Summary
It seems best to leave those files out of the repository.
For Eclipse this introduces the problem of creating a new project when importing from the VCS. In this case you should give advice on how to configure the project to set it up correctly.
When you put the project files into the VCS those who do not use Eclipse will probably have less problems than those who do, because the files are simply ignored at their site while the Eclipse users will have to reconfigure them for their system.
Maybe there is some better way to share those projects but I did not find one yet.