On 01/04/2011 13:46, Paul Sharples wrote:
On 01/04/2011 13:22, Ross Gardler wrote:
On 01/04/2011 13:04, Paul Sharples wrote:
On 01/04/2011 12:37, Ross Gardler wrote:
.classpath and similar files should not be in SVN. Feel free to remove
it and add it to svn:ignore
Okay, but won't that mean that when someone checks out the project, it
won't be correctly configured in eclipse by default? Surely it would be
*nicer* to have it in there for eclipse users?
No, everyone has different settings for their local systems. Eclipse
randomly re-orders things when something gets changed etc.
I agree, which is why I always manually check/diff these types of file
before/if I commit them
Local config files should never be in global repositories.
Normally i would agree, but i think .project and .classpath are special
cases. Both files are generic (don't contain any absolute paths for
example) and should work as a starting point for the first time checkout
of the code into eclipse.
Hmmm... but we have a situation now where the .classpath files are not
correct for all users.
Furthermore you state you always check the diffs before committing which
seems to indicate that there are problems.
Having to make these checks detracts from commit early and often.
I wonder if others have any thoughts on this?
I would expect that if you remove it and add it to svn:ignore in a
short amount of time when someone updates it will not delete as it
will be in svn:ignore and thus no longer SVN maintained.
However, you do make a good point, it would be annoying if it didn't
work that way. Perhaps the best thing to do is post the contents of
the file, just before you delete it to this list. People can then
easily re-create.
Does that mean that new developers would first checkout the code into
eclipse - where there would now be problems, then they would have to
search for a post somewhere containing the .classpath file?
Yes, in theory.
When you import using eclipse it does a very good job of guessing the
build path etc.
In fact I'm documenting the process of building a development VM using
Eclipse at the moment. It's been put on hold while I use my "free time"
to test the releases but I hope to have it soon.
I realise in
theory they don't need to be in svn because the user might not even use
eclipse as an IDE, but aren't we in danger of making the process of
getting the code up & running a lot harder for eclipse? I'd prefer if
possible to make the change i suggested earlier and leave it as it is.
If you are asserting that these kinds of problems are rare then I'm not
going to object.
Ross
(this is one big advantage of Maven over Ant, it's rigid structures
mean it is possible to do mvn eclipse:eclipse, I don't think Ant has
an equivalent)
Ross
Ross
On 01/04/2011 12:18, Paul Sharples (JIRA) wrote:
Eclipse .classpath file contains mac specific java settings
-----------------------------------------------------------
Key: WOOKIE-193
URL: https://issues.apache.org/jira/browse/WOOKIE-193
Project: Wookie
Issue Type: Bug
Components: Configuration
Affects Versions: 0.9.1
Environment: Windows (any), but tested against Windows 7 x64 Sp1
Reporter: Paul Sharples
Assignee: Paul Sharples
Priority: Minor
Fix For: 0.9.1
When a windows/eclipse user checks out the code from svn, eclipse
reports build errors as the .classpath refers to a specific mac
install of java
<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.launching.macosx.MacOSXType/JVM
1.6"/>
On windows when i change that to a more generic...
<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/"/>
...everything behaves properly. I dont want to break everyones setup
by commiting this change back, before I can confirm that this update
will also work on macos/eclipse.
FYI: in my Eclipse setup, under Window->Preferences->Java->Installed
JREs the default JRE points to a 1.6.0_24 instance.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira
--
[email protected]
@rgardler
