[Building Sakai] Out of date Eclipse files

[Ray Davis]

 > As for 2.6.x as it exists today, I suggest that David or Matt regenerate
 > the .classpath files so that they reference K1 1.0.11 as is the case in
 > the 2.6.0 branch.  That at least brings them up-to-date so while we
 > decide their fate.  If neither has time, I'll be happy to do it.

In case it saves anyone some time, here's how Aaron did that last year:

find . -name .classpath -exec svn del {} \;
find . -name .project -exec svn del {} \;
find . -type d -depth 1 -exec svn commit {} -m 
"http://bugs.sakaiproject.org/jira/browse/SAK-13484 removed existing 
eclipse files" \;

Then to rebuild and recommit:
mvn eclipse:eclipse
find . -type d -depth 1 -exec svn propset svn:ignore 
target,bin,.classpath,.project {} \;
find . -name .classpath -exec svn add {} \;
find . -name .project -exec svn add {} \;
find . -type d -depth 1 -exec svn commit {} -m 
"http://bugs.sakaiproject.org/jira/browse/SAK-13484 added back in 
generated eclipse files" \;

Oh, and my +1 vote for removing them completely still stands. :)

Best,
Ray

On 8/19/09 8:50 AM, Anthony Whyte wrote:
> I proposed back in April that we delete these files.
> 
> http://collab.sakaiproject.org/pipermail/sakai-dev/2009-April/000923.html
> 
> It met with no objections but with suggestions that at a minimum:
> 
> 1) we put documentation in place that describes the change in practice 
> and instructs developers on how to regenerate Eclipse metadata files
> 2) we update the svn config file global-ignores to exclude Eclipse 
> .classpath, .project, .settings, etc. files
> 
> I later suggested we consider doing this after 2.6.0 is released.  2.6.0 
> is released.  We should schedule a date to perform this excision in 
> trunk at a minimum and 2.6.x if no one has objections to the removal of 
> files from the maintenance branch.
> 
> As for 2.6.x as it exists today, I suggest that David or Matt regenerate 
> the .classpath files so that they reference K1 1.0.11 as is the case in 
> the 2.6.0 branch.  That at least brings them up-to-date so while we 
> decide their fate.  If neither has time, I'll be happy to do it.
> 
> Cheers,
> 
> Anthony
> 
> 
> On Aug 19, 2009, at 11:28 AM, Matthew Buckett wrote:
> 
>> On the 2.6.x branch all the .classpath files seem to point to an old
>> kernel version as the version of kernel in /master/pom.xml has been
>> incremented but the .classpath files haven't been rebuilt. I know the
>> API of the kernel shouldn't change but it means a fresh checkout and
>> import into Eclipse has 100s of errors because I don't have the
>> earlier kernel in my maven repo.
>>
>> We have our own version of the kernel (with API changes) so I need to
>> rebuild all the .classpath files to point to our local one so it
>> doesn't affect us too much, but it is a little messy for people
>> wanting to work with a clean 2.6.x
>>
>> I'd prefer that we didn't have any .project/.classpath/.settings files
>> in a standard checkout and the first thing you did after a checkout
>> was a "mvn eclipse:eclipse -DdownloadSources=true
>> -DdownloadJavadocs=true" then import into eclipse. As even if we
>> supply .project/.classpath files you still need to run maven first to
>> download the dependencies so why not have the maven invocation build
>> up to eclipse files as well.
>>
>> -- 
>>  Matthew Buckett