[Building Sakai] Out of date Eclipse files

[Noah Botimer]

Do we have any idea what the silent majority expects? That is, every  
time I've tried to generate .project/.classpath, I've gotten  
something wildly different from what is checked in. It may be  
inertia, but it feels miserable to me to have everything up-ended in  
your IDE with no sense of why it's "better" other than saving someone  
else some maintenance headache. I specifically mean how the packages  
are broken out and how the package explorer, etc., behave.

If we see the format that gets generated as a good idea, we should do  
an educational campaign encouraging people to try it and get used to  
it before the familiar model is irrevocably removed. I've got a  
feeling that the folks who are comfortable with the different layout  
are those who were willing to experiment and adjust to it.

Thanks,
-Noah

On Aug 19, 2009, at 12:04 PM, Ray Davis wrote:

>> 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
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev- 
> unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>
>