Hi guys,
I'm top posting now because of the so many overlapping comments below makes it
difficult to pinpoint where to hook into this discussion.
First of all, I too encountered the incorrect (MacOSX) JRE_CONTAINER mismatch on
Linux, so can someone fix this issue ASAP?
But concerning checking in these Eclipse specific config files, I've always been
in favor of *not* doing so.
Too often this break others environment configurations and/or trigger svn
changes whenever I make manual Eclipse configuration changes affecting these
files. Which I most likely wouldn't want to commit anyway (custom builders, etc).
As I'm completely unfamiliar with Ivy/IvyDE, other than blindly installing that
plugin in Eclipse, I don't know if it is possible to dynamically (or manually)
derive/generate appropriate Eclipse configuration files, similar to what is
custom with Maven based project using either the maven-eclipse-plugin or (*much*
better) the m2eclipse plugin?
I would hope and assume this to be possible, or otherwise maybe it is possible
to use/provide a custom script to execute on the command-line for this purpose?
I found http://code.google.com/p/ivy-eclipse/ but that happens to be GPL3 based,
maybe there are alternatives?
Another but related issue with the current *single* eclipse project/classpath
setup is that it is also used for the parser and connector (java) sub projects,
while these might not (and should not) need everything from the main classpath.
Or conversely, if those sub projects need additional/other dependencies you
would currently need to expose that on this single eclipse project classpath.
In both situations there is the danger of a "polluted" classpath which easily
might lead to incorrect or undesired usage/references.
I'm not sure how Ivy/IvyDE handles such things, but this is one area I like very
much from Maven: clean classpath separation between modules. And with the
m2eclipse plugin this is auto-magically handled and resolved.
Just my 2 cents.
Regards,
Ate
On 04/01/2011 04:01 PM, Paul Sharples wrote:
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
