[Building Sakai] Out of date Eclipse files

Wed Aug 19 10:35:25 PDT 2009

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"
>>
>>
>
>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2417 bytes
Desc: not available
Url : http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20090819/fb327d14/attachment.bin 