We Keep Coding

How do I get IntelliJ to load my .rvmrc for a non-ruby based project?

I have a Grails project that depends on a couple of ruby gems being installed. All of our developers have RVM installed and thus we have an .rvmrc file in our project directory to switch to the appropriate ruby and gemset.
Is there a way to have IntelliJ automatically read the .rvmrc even though the project needs the SDK to be set to a JDK?
Note: I've looked at the IntelliJ ruby plugin and couldn't see a way to get it to load the .rvmrc but not be the only SDK.

It's not possible, please submit a detailed request with the use case.

Using Eclipse with Subversion and Maven

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.

oData4j sample eclipse project

I have downlaoded oData4J jar files from odata.org and I intend to do a sample producer, within a basic web service.
I assumed that InMemoryProducerExample.java from http://code.google.com/p/odata4j/ will do the job and most probably it is.
My problem is that I have no clue which type of project to create (Eclipse Java), how to deploy and test this example.
Does anyone have such a start up hellow world tutorial for odata step by step, or an eclipse project which use InMemoryProducerExample.java from oData. I really need a starting point and I can see one online.
Thanks.

The easiest way to run the odata4j example is to simply checkout their project, and open it in eclipse.
If you don't have mercurial installed, install it from here.
checkout the latest odata4j code using this mercurial command,
hg clone https://code.google.com/p/odata4j/
Open the project in eclipse using the maven eclipse plugin. If you are using the latest version of eclipse, this will be installed already, it not you can install it from here.
In eclipse, go import->maven->Existing maven projects
Then select the directory where mercurial checked out odata4j.
When eclipse finishes importing the projects, you can find InMemoryProducerExample, and right click on it to run it as a java program. You can run any of the other examples in the same way.

Meanwhile, forks of odata4j which continued their lives are also available on GitHub, see https://github.com/odata4j/odata4j and my own https://github.com/vorburger/odata4j/ (which I am about to transfer to https://github.com/lukinf), which included some minor fixes for opening it in Eclipse.

Standard Java Project Description Format

I'm coming from the .NET world where Visual Studio is pretty ubiquitous. VS has a .sln file which pretty exhaustively describes a project, including where to find source files, dependencies, etc.
Now I'm doing some java coding in a team. My problem is this: I'm using intellij and others are using eclipse (while others could be using some other IDE). Is there a standard project description file that can be shared among IDE's? I obviously don't want to put my intellij specific files to source control. So what I'm looking for is a standard that pretty much any self-respecting IDE would recognize which you could point it to and it would be able to interpret the project structure, how to find dependencies, the class paths, etc.

Maven should be able to do it (a project build manager and source control overlay), but alas, there is no standard project file. There are Maven plug-ins available for all the major IDEs. http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html

Note quite. But you have a "way out". You can use Maven2. It has a unified pom file which contains all:
source folders (note: maven imposes a default convention on those, but they are still configurable)
compiler level
dependencies
build steps
etc..
(Of course that would require to install the maven plugins for both IDEs)
Another option would be to force either of the IDEs and commit their proprietary descriptors.

As others have posted, Ant and Maven are pretty much the de facto project spec utilities in the Java world. Those are both generally easy to learn -- a fair learning curve, but nothing dramatic -- and are pretty powerful. You could speak to your team members or leader and see how they've dealt with it -- I'm sure it isn't a new problem.
Aside from that, a lot of development teams (in my experience, at least) try to avoid putting project files in source control. The developers are required to basically create their own projects in whatever IDE they're using. It makes getting started on a project a little more difficult for a developer coming fresh into an existing project, but it also helps the developer get a little better acquainted with the project.
At my shop (very, very small team), we use Eclipse, but we still have to manage the workspaces (similar to VS solutions, but not quite the same) ourselves. I've created some Ant scripts for use on our continuous integration server, and that won't necessarily keep problems from arising, but it helps make them more obvious when they do.

There is no such standard project description file as far as I know. But intellij is able to take an eclipse and convert to an intellij project. Also you could look at maven.

There is not one. You could switch to an build system using ANT (similar to Make) but that has pitfalls of it's own. You will get the most mileage if you and your team standardize on an IDE though ...

I think what you want here is for a developer using Eclipse to edit the project settings and have those changes reflected in IDEA for some other developer. If that's the case, then Maven is what you want. IDEA 9.x has great support for Maven, and so does Eclipse. If a developer that uses Eclipse edits the dependencies in the Maven project files (pom.xml files), then IDEA can import the files and change it's project settings.
RE: ANT vs Maven - In this respect (syncing project settings) ANT build files won't work because they are imperative (script-like) rather than declarative.

Maven should be the preferred way but most IDE's now days support some kind of ant based project which is what most of the IDES use internally. Usually called free-form projects.

I'm not a Maven fan myself. I'd recommend Ant long before Maven.
If you're using IntelliJ, I'd argue that it does have a pretty standard idiom. And since it can import any Eclipse project file, you'll be on safe turf laying things out as IntelliJ does it.
I don't check in my IntelliJ project files, but the /src, /lib, /test, /resources etc. are all fair game.
The true answer should be that your team should huddle up and come up with a standard layout that you agree on regardless of IDE. You've got to check code into SVN sometime.
Your question is interesting to me, because I'm trying to go in the other direction (Java->C#, IntelliJ->Visual Studio), and I'm having trouble doing the mapping in the other direction.
I think it's just part of learning a language and its native IDE. I find that it's best to find an experienced guide.
One problem you'll have is that the .NET universe is isotropic (all things Microsoft), where even your small corner of the Java universe is heterogeneous (IntelliJ and Eclipse and NetBeans). You're less likely to find one true answer for all of Java.

Is Developing Maven war apps in MyEclipse worth it?

My organization has made an upper level decision to move to maven as the standard build tool for Java projects. I have been tasked with helping our local teams migrate projects over to maven.
One of the core tools that is in play is the MyEclipse IDE. MyEclipse seems to have had a "fun" history with the maven team as evidenced in various places, especially when dealing with war projects. I haven't encountered problems with simple jar projects...yet.
After fighting with MyEclipse and failing to make it recognize a war project easily, the question becomes, is MyEclipse worth it for developing maven war apps?
If so, is there a way to get MyEclipse to play nicely with a war project that I've not found? Or, am I simply better off suggesting its time to use Eclipse Java EE edition with m2eclipse?

No. MyEclipse does not support projects that were created outside of it. It is by design only working with projects created using its wizards.
From the Using Maven in MyEclipse Overview
NOTE: Maven is only supported for new projects. Migration of existing
projects to Maven-enabled projects is not supported at this time, but
may be considered for a later release. Right now the MyEclipse team is
focused on providing as fluid a new-Maven-project experience as
possible

I am working as a tech lead, and we recently started moving to maven. I had a couple of issues getting maven to work with myeclipse. First, even when I "Enabled all m2eclipse features" checkbox, I still couldn't check out a project as a maven project, from subversion. That option (that you get from m2eclipse) just wasn't available.
Also, some of the preferences you get with m2eclipse are not available with maven4myeclipse.
Finally, I couldn't just uninstall the maven4eclipse plugin and install m2eclipse. That would have been an acceptable workaround.
I think Genutec tried to make Maven more accesible to newbies, but there are some problems in the impementation, and I don't see them being fixed soon. For us, that will likely delegate MyEclipse to being just a fancy jsp editor.

Mike,
Sorry to hear you are fighting MyEclipse and Maven, in the past the most common problem I've seen causing people pain in this area is when they don't have the Web Root, Java source dirs or resource dirs set correctly.
Using this webpage as reference for a standard Maven2 web project layout, you can easily create a Maven-enabled MyEclipse Web Project. The steps you would want to take are as follows:
File > New > Web Project
Give your project a name, use the Java source dir of "src/main/java" and a Web Root of "src/main/webapp", check the Java EE spec level you want, check "Add Maven support" checkbox and hit Finish (unless you want to setup the artifact/group IDs).
Now, if this is the first time using Maven4MyEclipse, a lot of initialization will take place preparing your local repository and grabbing all the Java EE resources to build your project, but after that's done you should be all set.
You can execute the Maven targets off the Right-click Run As or Debug As menu and even manage custom goal execution using the "Maven build..." shortcut -- this is all similar to m2eclipse.
If you decide you want to use m2eclipse complete, you can navigate to Window > Preferences > MyEclipse > Maven4MyEclipse and check the "Enable all m2eclipse features" checkbox.
Out of the box we only hide the bits that can make Maven confusing for first-time folks, if you enable all the m2 bits, you can do whatever you want with Maven and MyEclipse. If you keep having trouble stop by our forums and let us know and we'll help out as best we can.

Mike,
think the issue is that the project has already been created outside of MyEclipse and >worked thru maven using the command line. Importing it is not successful.
I saw this post when looking for other Maven resources so I'll chime in.
Why not import your existing project using File > Import and turn on all the m2eclipse features and continue to develop it as you did before using maven commandline tools? I've done this and it works well for legacy projects, once m2eclipse features are enabled as mentioned in Riyad's #5.
Personally, I've always thought the maven war format was a bust, but we still have some old projects that use it around. Maven's format is just a default (and a poor one), not some sort of standard. However, we currently leave those old projects "as is" (using the above technique) just because it's easy. But for new work we use the MyEclipse web projects then just enable Maven support on them. The benefit is that you get all the Maven support and it's super easy to use and manage but no more commandline (although that still works too) and all the MyEclipse tools work perfectly on them as well. It's a "best of both" approach, well, at least for us. YMMV.
Hope that helps,
Dave

Mike,
Interesting, what happens when you have developers who are not using MyEclipse?
Not an issue here; I work for a very large company that has been standardized on it for quite some time (happily, I might add as we used to be a WSAD shop -- shudder.)
Anyway, if you have some that use MyEclipse and some that don't I see two options. First, if you create MyEclipse web projects and then "Add Maven capabilities" (or whatever it's called) to them, they'll work in MyEclipse and from the Maven commandline as well. So even if you're not using MyEclipse you can still use the commandline Maven tools. Also, since the MyEclipse structure is the more standard "exploded war" layout, it should work with whatever else you use as well.
Other thing to consider is that Maven's web layout is simply a default and Maven can easily support any project structure, including the one MyEclipse uses, so you should be able to use the MyEclipse project with Maven in any tool with just a little additional config. That's likely why the Maven commandline tools still work on the MyEclipse Web projects -- the MyEclipse guys just automatically configure Maven to recognize the format.
You also could just import the externally created Maven web projects as I said in my last post. We don't like to do that because that structure is unique to Maven and just doesn't work with any tools except Maven. As a result, it basically defeats the the tool support you get automatically in MyEclipse, Eclipse Java EE, or pretty much any other tool. It's just a poor default. Exploded WAR format, that's used by MyEclipse, Eclipse Java EE, WSAD, RAD, and everyone else is simply a better solution. Especially when it still works with Maven just fine as well.
Maven was made to be flexible to project structure. We've just found by using that flexibility a little you can get Maven support and great tool support too.
Dave