On 01/04/2011 14:05, Ross Gardler wrote:
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.
The only reason i have had to do it is because the .classpath referred
to a mac/eclipse specific variable, which when refactered should no
longer be a problem on windows or mac. Once updated it should be
generic to everybody and not need changing again. The only time the file
would be updated again in the future would be for example, if we added
another src/ folder to the project, which we would want all users to
pickup anyway. I think my first suggestion should fix the problem for
everybody.
The original non apache version of wookie had the generic entry...
<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/"/> // This should work
on macos and windows
...in .classpath but at some point it had become updated with mac
specific data to read...
<classpathentry kind="con"
path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.launching.macosx.MacOSXType/JVM
1.6"/> // does not work on windows
I'm only suggesting we put it back as it originally was.
Having to make these checks detracts from commit early and often.
I wonder if others have any thoughts on this?
Mac developers need to test it out I guess
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.
hmm. :-)
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.
If I commited this change i would expect to very rarely have a different
version of .classpath to anybody else and if it was different in svn i
would want to look at it and possibly update because someone else had
modified it purposely. (see above).
However, If your version of eclipse appends something to the end of that
classpath entry I'm talking about, then it should not be commited back
(i have a feeling that the mac version of eclipse *sometimes can* (but
not always) append that value to the end, depending on how you configure
your installed JREs/workspace).
My suggestion is to make the slight change for now in svn, and see if
there are any issues with the mac version of eclipse appending values to
the variable, perhaps then reconsider what to do. Its easy enough to
change again.
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
