[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.newcomer] Re: layout of an eclipse workspace and eclipse "special files"
On 07/02/2009 05:41 PM, Eric Rizzo wrote: 
Wow, so many questions, so little time...
See my comments in-line below.


I thanked you with my previous reply and I did mean it. Still do.
But I've thought a little bit about the answers and I think they
indicate some continued problems with my understanding.



Mike Carifio wrote: 
I'll couch this question with linux pathnames, but the question is
platform independent. Suppose I've installed eclipse 3.5 in
/opt/eclipse/eclipse-3.5 (which eclipse defines correctly with the
ECLIPSE_HOME classpath variable).

If I install plugins, they seem to "land" in
~/.eclipse/org.eclipse.platform_3.5.0_695685997/plugins. What if I
want the plugins shared by several users? If I install plugins
as root, do they land in (say) $ECLIPSE_HOME/eclipse/plugins?


I'm not a Linux user so can't help much here. But I do know there are
some resources that talk specifically about multi-user installations.
Ah, here it is:
http://help.eclipse.org/stable/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/multi_user_installs.html


This blog post offers some alternative ideas, too:
http://divby0.blogspot.com/2007/08/howto-install-eclipse-for-multi-user.html


<more below>

What is the file layout of my workspace ~/workspace? In particular,
.metadata contains all sorts of stuff, for example .metadata/.log
and .metadata/.plugins, which is configuration for each plugin on
a per workspace basis (?). Each workspace seems to have a .metadata
subfolder, therefore these settings aren't shared across workspaces.
For example, if I name a new perspective 'MyPerspective' in ~/workspace
and then switch to ~/workspace-other, 'MyPerspective' is unavailable.
This means I have to know the "scope" of various settings? Or did I just
put it "in the wrong place"?


You are correct that (most) Preferences are workspace-specific. It is
possible to export/import preferences to move them between workspaces,
via the File menu.

<more below>


Project folders seem to have two "opaque" files: .classpath and
.project. Also a .settings folder. Are the layouts and contents of
these files documented?

I understand that these files are "internal" to eclipse and can change
without notice, but they are sometimes checked into source code control.
Is there a better way to "share" project settings across developers?


The .classpath and .project files really must accompany the project in
source control - they define the structure of the project and would be a
hassle to re-create.
The files under .settings are the intended mechanism for sharing project
settings amongst a team; they are intended to be checked-in. Is there a
particular reason why you have a hesitation to do that?

My hesitation stems from the fact that I don't understand yet what they actually do and whether I would be polluting someone else's workspace with my settings. So let's continue with the questions.

It looks like .settings is a folder with java property files as contents. For example I have 'org.eclipse.jdt.core.prefs' with a long list of pairs, e.g. 'org.eclipse.jdt.core.compiler.source=1.5'. So if I check this file into scm, does that mean that when someone else opens this project, they'll get this setting? If they change it inadvertently
via the eclipse project properties page, and then commit the project, isn't it possible they'll overwrite this? Isn't this forcing every user
to have pretty sophisticated knowledge about how eclipse works to make sure this doesn't happen?





<more below>

Finally, if I look at the 'Configuration' tab of 'Eclipse Installation
Details', I see all kinds of attributes and values. Some appear to be
Java properties, e.g. org.osgi.framework.os.version=2.6.29.5-191.
What do these values mean?


You'd have to ask about specific ones, as there are just too many for
anyone to know/explain purposes of all of them. Chances are most of them
are not useful to the average user; in 7 years as an Eclipse user (many
of those at the "guru" level"), I think I've only ever had to muck with
any of them maybe once.

<more below>


Although at first glance this isn't a newcomer question, in some sense
it is. It seems to me that $ECLIPSE_HOME, the workspace and the project
folder form a search path for various settings, but I'm not sure if
that's really right. For example, I've added a new keyboard short cut.
Is that a workspace setting? A project setting? I don't yet understand
the scope of settings.


(Almost) Anything defined in the Preferences dialog is scoped at the
workspace level. Many of those can be overridden on a per-project basis,
using the the Project Properties dialog. Such things are (usually)
stored in the .settings directory of the project. And usually checked in
to source control, as I've said.
The only thing that is scoped above the workspace level (ie,
per-installation) is what is in eclipse.ini and the set of installed
features/plug-ins.

Keyboard shortcuts are a workspace setting, and can be exported/imported
either as part of the entire Preferences set or separately.

<more below>


Also confusing to me is how one developer captures configuration and
setting information for another developer to use. For example, eclipse
builds project automatically behind the scenes, but doesn't that
depend on .classpath, etc? Am I forced to export an ant script or
worst yet
handcraft it and put it under source code control? Once you do that,
haven't you now broken the abstraction that eclipse provides? I think
I recently read a thread about sharing the .metadata folder with other
developers. The consensus was that this was a bad idea. What's the right
idea?


Check in the .project, .classpath, and .settings files. It's simple and
the mechamism that has been provided to do what you're asking. I don't
understand any hesitation to do so...

See my comment above regarding settings. So I've looked inside .classpath. How does this xml get translated into a Java classpath?
What do the entries mean? What are the various kinds (src, lib, con, output)? How did this list get generated? What eclipse UI entries actually modify which lines? This feels like Russian roulette.



As you surmise, DON'T check in the .metadata directory; workspaces are
definitely not intended to be shared and attempting to do so WILL cause
problems and headaches.

Hope this helps,
Eric

These questions reoccur. Someone just posted the "settings question" today. Personally, I think that indicates a problem. If certain parts of
the eclipse project "metadata" are to be exported and shared, then they
need to be documented and explained. Otherwise, I can have my project
corrupted "from outside" with an scm update and I can do the same to
my workmates. This just doesn't make much sense to me (yet), so I continue to clarify my understanding.