JCreator is a great IDE, especially with it's flexibility and look and feel and it's got an instant load time.

Gel has obviously been made with someone who has:A. An obsurd amount of time on their handsB. A lot of team members

JCreator is a small project. Gel is a large project. Gel has only been around since 19 March 2003 but it has come very far in that time, much further than many other IDE's which can only point to 1 thing:See second paragraph.

But seriously, one of the things I value in NetBeans and Eclipse is that they are both platforms bigger than simple IDEs and that they can self-host stuff you are debugging be it a IDE extension or a Java web server like Tomcat, is awesomely useful. My only complaint against Eclipse is the lack of 'big project' state - i.e., only one user context - oh and the SWT (I'm a Swing fan).

My only complaint against Eclipse is the lack of 'big project' state - i.e., only one user context - oh and the SWT (I'm a Swing fan).

Just to pick up on that comment - what kind of "big project" state are you talking about?

Things like launch configurations can be stored in configuration files, library locations can be configured via variables and adjusted on each machine, and shared Ant scripts can be used for build tasks. What other things would you find useful? Or have I misunderstood your comment?

Just to pick up on that comment - what kind of "big project" state are you talking about?

Things like launch configurations can be stored in configuration files, library locations can be configured via variables and adjusted on each machine, and shared Ant scripts can be used for build tasks. What other things would you find useful? Or have I misunderstood your comment?

It may be I'm missing something in Eclipse. With NetBeans when I switch to a different project, all my mount points change, a different set of files are visible in the editor, even the window layout and menu bindings can change. Whereas with Eclipse I have all my 'projects' visible at once (here a project is just a directory mount) which can get quite messy when I have several complex projects on the go.

Firstly, you can just close all the projects you don't need, turning them into closed-folder icons. They don't go away, but they stay out of your way.

Secondly, you can hide them - either close them and filter out closed projects, or create a working set just containing the projects you're currently dealing with. This removes them entirely from the view, but if you're changing global workspace settings you'll be affecting them in some way.

The third and cleanest way is to use multiple workspaces - start eclipse with the "-data c:/path/to/workspace" option. This allows you to configure several different shortcuts that operate in entirely different worlds - no changes you make in one will affect the other, excepting changing the Eclipse or Java installation, or modifiying external libraries.

Depending on what you're after you can use a couple of these techniques together. My webdev and game-dev workspaces are entirely seperate, but within game-dev I'll probably only have one project open at a time, the rest I leave closed.

The third and cleanest way is to use multiple workspaces - start eclipse with the "-data c:/path/to/workspace" option. This allows you to configure several different shortcuts that operate in entirely different worlds

If anyone knows how to do this with the Mac version let me know. "Shortcuts" on the mac are just symlinks... there is no place for parameters. Since Mac apps don't have the concept of command line parameters this is awkward. The workspace folder is specified in an xml config file for the Eclipse application. There is only one such file.

I will try the working set and hide filter ideas though. Now to find how to create a working set...

The workspace folder is specified in an xml config file for the Eclipse application. There is only one such file.

fx:sound of a thousand hands hitting a thousand foreheads.

Doh! That's an interesting enough question that I'll have a look myself. The documentation at eclipse.org is frankly shameful, and the mailinglists aren't worth trawling through, but the answer must be out there somewhere!

Edit: Looks like you're out of luck. Back in 2002 it was commented that the whole "-data" concept should be fixed, but obviously nothing happened about it. The best advice I can find is to duplicate the Eclipse application bundle, so you have a different Eclipse "installation" per workspace. Which sucks.

Quote

I will try the working set and hide filter ideas though. Now to find how to create a working set...

In case you relish the chase and don't want me to spoil it, I'll post the answer in pig-Latin:

To do that with Eclipse I have to name the project differently and put them in the same workspace.. at least if I want to work efficiently with the Mac version.

If my source repository has a 'development' folder and a 'maintenance' folder with the same folder names (one for each project) underneath those, then it seems that Eclipse doesn't handle that well. It likes to have the project folder in the root of the workspace.

Now that I think about it, I guess there might be a way to force it to use a particular folder that is deeper in the workspace... I'm not sure.

Of course this is really only theoretical for me at this point. I use SourceSafe (there is a nice plugin for Eclipse) on Windows for my main work development. (I can't access SourceSafe from the Mac at all. I don't use CVS because from what I have seen it is harder to use and lacks features. I'm would try Subversion but it didn't build on my Mac last time I tried.)

In Eclipse's CVS view you should be able to drill down and select any particular folder for checkout. Also, you should be able to check any folder out into a project of any name you choose.

Nesting projects is a bit harder - I don't think it allows that, does it? Regardless, you'd probably be better off keeping the branches in seperate locations and modifying the reference to whichever you're currently using instead. But I don't know your situation/setup!

Ah, no. I mean "separate" as opposed to "nested" - check the two branches out into their own (differently named) "projects" in the same workspace. Any project that uses this code but needs to be able to switch between branches can use classpath variables, project dependencies etc to do so. I haven't tried this myself, but I have a feeling it would "work".

Unfortunately this is rather contrived and a bit of a hack, but I can't think of a cleaner way of doing it right now. Anyone?

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org