[Building Sakai] Out of date Eclipse files

Jim Eng jimeng at umich.edu
Wed Aug 19 13:12:17 PDT 2009 

+1 for Noah's request/suggestion that this not be done in a way that  
results in jarring changes in organization of projects in eclipse.



On Aug 19, 2009, at 1:35 PM, Anthony Whyte wrote:

> Overseeing the 2.6.0 release branch, I generated Eclipse meta data  
> files diligently every time we generated a new kernel release (a not  
> insignificant set of releases).  I did not find the task overly  
> onerous nor did I find the output generated after running mvn  
> eclipse:clean eclipse:eclipse different from what I expected.  I  
> Jira'd the task and David Horwitz, the 2.6.x branch manager (or  
> myself if he was unavailable) refreshed the 2.6.x branch (not  
> counting 1.0.11)--again not an onerous task, but one which is not  
> recommended as a best practice.  Eclipse meta data files contain  
> data that is largely relevant to local workspaces and as such, in  
> the opinion of many, should not be managed in source control.
>
> Speculating on what the silent majority expects is to me a  
> problematic exercise.  One could assert the adoption of best  
> practices is what the silent majority desires.  One could equally  
> assert that like Garth Algar (Wayne's World) the silent majority  
> fears change and we should just keep doing what we are doing.
>
> For me, the sakai-dev mailing lists exists to elicit opinion,  
> comment, suggestions, advice and criticism on matters such as these  
> and silence, whatever the motive, is defined by our Apache-inspired  
> "lazy consensus" model as assent.
>
> Cheers,
>
> Anth
>
>
>
>
>
>
> On Aug 19, 2009, at 12:59 PM, Noah Botimer wrote:
>
>> 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"
>>>
>>>
>>
>>
>>
>
> _______________________________________________
> 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"

More information about the sakai-dev mailing list