for someone it may seems a little weird but still I want to know if it's possible or not. We have a lot of projects which coded on eclipse so far and some of us wants to jump into intellij idea world.
Can we be able to run the projects via eclipse and intellij together at the same time? I mean for instance I'll be using intellij idea while another friend of mine will be using eclipse instead of intellij idea on the same projects, is it possible?
If it's possible, would it create any problem for version control systems such as subversion?
Subversion will have no problem at all, but I recommend you in that case that you rely your java build configuration (sources, compiler level, dependencies, etc.) on maven or gradle instead of doing it twice, once for every IDE you are using. Then both maven or gradle should be able to generate IDE-specific configuration files for each environment and you would work in the same conditions.
Actually I like the idea of working with a managed and automated build process, so if anyone is brave and bold enough to use vim... they can use it without problems, and still build their app.
Can we be able to run the projects via eclipse and intellij together at the same time?
Yes, because these IDE store their project data and configuration in different files, so they don't step on each other:
Eclipse stores its files in .project, .classpath, .settings
IntelliJ stores its files in .idea, *.iml
If it's possible, would it create any problem for version control systems such as subversion?
Not at all.
Btw I do this too sometimes: I have projects where members use different IDE: IntelliJ, Android Studio, Eclipse, with no problems.
Related
I'm working on a rather big RCP application, where only 2 / 100 projects are written and maintained by me. I do have dependencies on other projects and these projects might depend on another project as well.
Since Eclipse takes a lot of time to start up and loading (might even crashing sometimes if not ready) I was wondering if Eclipse Neon could determinate the projects I don't need so I could wipe them out of the workspace to fasten up the loading.
If it is helpful: We use gradle to build the project.
It's hard to know exactly how your projects relate to one another but I'm guessing you could use gradle's new composite build support (added in v3.1) to have some projects as source dependencies and others as binary dependencies.
You could then wipe out everything that's not part of the composite build from your eclipse workspace. You might even make use of this snippet to see what source folders are in your eclipse workspace... perhaps you could write a gradle task to do the wiping?
I'm assuming you are using buildship?
I am trying to use Eclipse, Subversion and Maven for my projects and everyone is telling me never to check in the following files:
target/
.classpath
.project
.settings
But if I dont check them in and some other project checkouts the project from within Eclipse, Eclipse does not know what type of project it is.. Are we doing something wroung?
How do you work?
Eclipse has a plug-in for Maven; I believe it is called m2eclipse. After having it installed you can select Import from Maven project and select the pom.xml which will import your project to eclipse even if .project and .settings are not present. So there is no need for you to commit them to svn. This comes with the advantage of IDE neutrality; other members of your team may use Intellij IDEA or NetBeans without any concern.
Also Maven has a plug-in for eclipse; you can go where pom.xml is located, open a terminal and type mvn eclipse:eclipse and it will automatically generate .project and .settings.. However the first option is more recommended.
I had the same issue with eclipse, maven and git, so maybe it is helpful for you:
Try to setup your repo in svn and check it out, but don't import it.
You have to import the project over File -> Import -> Existing Maven Project into your workspace.
The last step is to share the project. Rightclick -> Team -> Share -> SVN -> and set the existing one as repo.
That's the way I handle this in Eclipse. Hope it's clear enough?
Btw you should not check in these file, because classpath and so on could be different on other machines.
I check in .classpath and .project but not very often. You do have to make sure that everyone who is working on the project has versions of eclipse that are close enough (including the particular plugins and eclipse features included). Sometimes you can get by with very different versions of eclipse if you make sure almost nobody checks those files in and everybody just mostly compares and manually updates those files from the version control when they are updated.
If you don't check them in, everybody has to create an empty project and then load the source files (and all the version control files or folders) into the project. If you are careful you can copy in those two files and then fool with the options settings to make them match.
Note that Maven helps a lot with this as it takes care of most of the content of the .classpath file.
The main reason not to check in those files are that the IDE's will very likely make changes to those files to suit your local dev environment. Which will probably cause conflicts and thus "broken" projects if everybody is committing their versions all the time.
That said, eclipse should have decent maven integration via the m2eclipse plugin (which I believe might be baked in by default these days).
Part of the idea behind Maven is exactly this - reproducible builds cross platform, cross IDE etc etc - so IDE specific files like that should not be required to build the project.
Importing the project with the m2eclipse plugin should sort things out nicely.
If you mean the other members check out the project and it doesn't work for them, they can check out the maven project separately without using eclipse and then import it into eclipse as an existing maven project using the m2eclipse plugin. This works cleanly without any problems (for me at least).
if everyone in your team is using Eclipse and it is agreed that the project will never use anything else, you may as weel check those files in. but it will make things kind of irritating if someone uses IntelliJ, Netbeans of other tooling or has his Eclipse very customized.
It depends.
Maven documentation explicitly says something like "Do not check in .project/.classpath/.settings/ because they can be regenerated from pom.xml". The later part of the sentence ("they can be regenerated") is not true, so the first part of the sentence (the advice) may or may not be OK, depending on the circunstances. Not every bit of the Eclipse configuration can be regenerated from the pom.xml, so my opinion is that the decission is based on a tradeoff between how much gain you get from it and being tied to the particular IDE.
So it depends.
For "community projects", where usually each developer will use different IDEs and different versions of the IDE, I would recommend not to check in those files. Otherwise, it would be a pain for developers not using your IDE and your version of the IDE.
For large "corporate project", IDE and IDE version are not free to be choosen by the developer but firmly dictated by the project management. So are dictated things such as compiler(1), code formatting, validating rules, warnings-and-errors configuration, custom in-house plugins configuration and many others. Many of those things cannot be set in pom.xml (nor should they because Maven is not and IDE, but a building tool). So in this case I would recomend to check in those files and blame the developer who complies, because he is trying not to follow the dictates.
(Notice that in this case I intentionally used words such as "dictate" and "blame" because the project management of a corporate project has not only the right but also de duty to "dictate" and "blame")
In the opposite side, for one-person projects, you do not have to worry about your colleages, so go check them in.
But the key is that you have to know your circunstances and the consecuences and decide yourself.
(1) No, "maven.compiler.source" is not the compiler to be used.
For a Java project (with the team of 5-10 developers) should I store my IDE project files (e.g. Eclipse or IntelliJ Idea) in version control system (currently I store only build scripts)? What's the best practice?
PS Do you aware of any tools to automatically generate project files for common Java IDEs according to some descriptor?
You might want to take a look at the answers to this question: Which eclipse files belong under Version Control. As to the second part, maven has plugins for IntelliJ and Eclipse at least.
If you care about the project file at all, then you should check it into a VCS. Really, you might not care. But if you do, VCS it...
Our team (6-8 developers) originally checked in project files, and soon found that they can cause problems when it comes to paths and build path, etc. Usually not, but when an issue did arise it could take time to ferret it out. Then we stopped doing that, and it has worked much better. We now put definitions in the VCS ignore files to make sure they don't get in. However, in our case we work with Maven, so the practice has been create an eclipse workspace and then import the Maven projects from the source. So recreating project environment is quick and predictable. From my experience, checking in can cause minor headaches.
There are different opinions. Once I was told that I shouldn't put project files in VCS, but then project files ware added to repository (not accidentally).
Many open source projects have project file in VCS. I think it could be good practice if one particular IDE is proffered in other case developers should probably take care on project files by themselves.
Maven can generate project files (at last for eclipse)
OK my problem is quite simple
Im about to start working with a team of programmers, and we are using a svn repository to store our code, thy files are set up as Eclipse Project as the rest of my team all like eclipse.
However I am die hard netbeans man, I have tried eclipse Iv given it some time but we do not gel as they say.
So my question is there a combination of plugins /hacks that i can use to access a Eclipse Project from an SVN repository inside Netbeans , without corrupting the eclipse project or causing problems for the rest of my team (I would rather suffer eclipse than do this to them)
Many thanks ^_^
In NetBeans 6.8 under File > Import Project there is both Eclipse Project and Resynchronize Eclipse Projects. I'm guessing this can be used to work together with people using Eclipse.
UPDATE: How the eclipse import function works.
As NA pointed out, there is a way to import your Eclipse projects into Netbeans. However, arguably, you shouldn't be checking in IDE-specific files into your repository unless you can guarantee everybody is using the same IDE. Otherwise, I would recommend only checking in the source code, resources, and additional libraries and keep the specific files on ignore and have each individual setup their own environment.
Another alternative, is to check in the IDE-specific files in a different folder in the repository so that an individual can grab them if they need them.
What is the best way to allow a team of programmers to use Netbeans, Eclipse and IntelliJ on the same project, thus eliminating the "which IDE is better" question.
Which files should or should not be checked into source code control?
I think the best way is to make the build process independent of IDE. This means that your project should not rely on any IDE-specific files to build, but rather use an external build system, like Apache Maven, Apache Ant, or even make or custom scripts. Maven is supported by most popular Java IDEs, either directly or via plug-ins.
If you don't want to use an external build systems, you should at least make the project as easy to set up as possible (i.e. by having standard folders for shared libraries and other dependencies). When I have working on teams with multiple IDEs in the past, I spent by far the most time on resolving dependencies as the prerequisites for building the project changed over time. In the worst case you may even end up with developers not bothering to get the latest version from the version control repository, since they think setting up the new project is such a hassle.
If your project has many library dependencies, I think its a good idea to make these available in binary form in the version control repository. That way people don't have to resolve all the dependencies of the dependencies and so on just to build a single project. This does however require that you have someone responsible for keeping the "official" binaries up-to-date whenever they change. (This is pretty much the same philosophy used by the Maven repository, but the principles can be applied manually even when not using Maven.)
Well, that's a pretty self-answering question.
The files to not check into source control are files that have to do with the IDEs themselves.
Leave it to the developers to generate these files.
If you use Maven, it can generate the files such as Eclipse's .project and .classpath for you. Eclipse in general is very easy to use with a basic file structure (with the new Java Project option).
I think Maven has Netbeans support as well, not sure about IntelliJ though.
Maven's site is maven.apache.org.
For each IDE that has more than one developer, check-in all the supporting files. Why re-invent the wheel at every desk.
I have done this with many different IDEs, and I have yet to see a filename conflict.
In fact, even when only a single developer uses a particular IDE, it is to his/her advantage to version the supporting files, for the same reason that you version the other files in your development environment: history, diffing, comments, etc.
For Eclipse, that would be .classpath and .project files.
My team uses Maven, and developers are discouraged from checking in Eclipse-specific files. Because they can be generated from Maven, these files are redundant.
Also, checking project-specific files seems like it would save time, but it usually winds up being a pain because of variations in different developers' workstations, resulting in wasted time resolving conflicts in the IDE-specific files. The only way to get around that is to force everyone to set up their environment the same way, which goes against the IDE-agnostic approach.
There are many considerations when using multiple toolsets within the same project team. For example, my team has Java developers using IntelliJ and most of the front end (JSP/CSS/HTML) developers using eclipse. We are in the process of migrating the Eclipse users to IntelliJ because of some IntelliJ plugins that we have developed that provide extended support for our environment. We're not going to develop the plugins for multiple platforms, so we are standardizing on IntelliJ across the board.
In terms of specific files, I can speak to IntelliJ. We have checked in our .ipr files and our .iml files. Do not check in .iws files. If you also have Eclipse users, configure your IntelliJ project to read/store dependency information in the .classpath file and commit that to your VCS.
We intentionally support multiple IDEs from the same SVN repository. Our thinking was that we want to ensure that, if a new person joined the team or someone had to start working on a new machine, we wanted them to be able to checkout the codebase, import it to the IDE and immediately have a work-able configuration.
What that means on the developer end is that they should not commit their changes to the IDE files. Everything else (e.g., src, test, lib and so forth) becomes the set that we normally update and commit every day.
The side benefit is that we have completely eliminated the IDE wars here: Netbeans and Eclipse people live in perfect harmony (looking askance at the IntelliJ people, but hey... ;-).
For more comments and answers on this topic see this question (How do you handle different Java IDEs and svn?)
We rename our IDE files for checkin with an extra extension .deletethis or similar. When a new person checks out the project, they simply strip off the extra extension and are good to go. This way we avoid source control conflicts with the project files as people tweak their environments. And you don't have to worry about educating new developers to not check in those files.
Typically, I would consider this a bad idea. I'm not sure what kind of environment this is (perhaps open source?), but it would really suck to support multiple IDEs. One thing I would recomend if this is unavoidable, would be to standardize your builds in ant scripts. If you have a large set of dependencies, this may be the easiest way to get a predictable build across all platforms.
If one of the IDEs happens to be RAD (based on eclipse), there is an entire folder called .settings that you would not want to include in the SCM.