Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mylyn-dev] Do we really need the .classpath/.project/.settings files in git?

If this is useful to you, CDT had the same problem, all the different settings files had slightly different settings. So what I did a number of years ago is added to the build some scripts that synchronize settinga between all the projects.


In that directory are a bunch of other scripts that run as part of PR validations too, with the entry being check_code_cleanliness which does things like enforcing code formatting rules, trailing whitespace, line endings, etc.

HTH 
Jonah

On Tue, Apr 11, 2023, 11:43 p.m. George Lindholm <javadev@xxxxxxxxxxxx> wrote:
Hi,
  so how are the settings maintained at the moment?

There are 1159 .settings/*.prefs files at the moment. I'm trying to
figure out how change the appropriate settings to take advantage of Java-17.

Wouldn't something like using the global workspace settings along with
peer pressure work better?

George

On 2023-04-11 08:45, Holger Voormann wrote:
> Hi,
>
> The best way is to share the .settings folder. You are doing it wrong
> by not sharing (.gitignore) the .settings folder.
>
> The .settings folder is intended to be shared. It contains project
> specific settings, which are those settings in "Project > Properties"
> where you have ticked the "Enable project specific settings" checkbox.
> If you don't share the .settings folder, you are fighting your own
> decision, as by not sharing them, they become user specific settings.
>
> These project specific settings can (but do not have to) include
> formatting settings, settings for what should be displayed as a
> warning or error, the so-called save actions, and much more. These
> things are not covered by Maven or other build systems. Where should
> these project specific settings be stored if not in the project itself?
>
> Regards,
>
> Holger
>
> Am 11.04.2023 um 15:15 schrieb rsbecker@xxxxxxxxxxxxx:
>> That’s the hard part. We export settings and import them. I wish
>> there was a better way, as in moving content out of .project and
>> .settings – I had a bug open on ECLIPSE for this in general that
>> never got fixed.
>>
>> *From:*Frank Becker (Eclipse) <eclipse@xxxxxxxxxxxxxxx>
>> *Sent:* Tuesday, April 11, 2023 1:43 AM
>> *To:* rsbecker@xxxxxxxxxxxxx; Mylyn developer discussions
>> <mylyn-dev@xxxxxxxxxxx>
>> *Subject:* Re: [mylyn-dev] Do we really need the
>> .classpath/.project/.settings files in git?
>>
>> The filteredResource is used to avoid that a project showed twice in
>> the PackageExplorer View. The filter removes the subfolder of the
>> root repository.
>>
>> If you do not use the .settings you can not set project specific code
>> style like formatting, …
>>
>> How would you manage that all contributors use the requested same
>> settings?
>>
>> Regards
>>
>> Frank
>>
>>
>>
>>     Am 09.04.2023 um 20:25 schrieb <rsbecker@xxxxxxxxxxxxx
>>     <mailto:rsbecker@xxxxxxxxxxxxx>> <rsbecker@xxxxxxxxxxxxx
>>     <mailto:rsbecker@xxxxxxxxxxxxx>>:
>>
>>     I have seen this too, when Mylyn was in use at my org. I usually
>>     keep .cproject, .gitignore, .gitmodules, and .project but not
>>     .settings. When .settings is included, we often will use git
>>     update-index --assume-unchanged .settings and .project to ignore
>>     changes after the initial project setup where we do not yet include
>>     Mylyn content.
>>
>>     Hope this helps.
>>
>>     *From:*mylyn-dev <mylyn-dev-bounces@xxxxxxxxxxx
>>     <mailto:mylyn-dev-bounces@xxxxxxxxxxx>>*On Behalf Of*George Lindholm
>>     *Sent:*Sunday, April 9, 2023 1:48 PM
>>     *To:*mylyn-dev@xxxxxxxxxxx <mailto:mylyn-dev@xxxxxxxxxxx>
>>     *Subject:*Re: [mylyn-dev] Do we really need the
>>     .classpath/.project/.settings files in git?
>>
>>     So what do I do about changes like this:
>>
>>
>>         <filteredResources>
>>
>>         <filter>
>>
>>         <id>1672000970093</id>
>>
>>         <name></name>
>>
>>         <type>10</type>
>>
>>         <matcher>
>>
>>         <id>org.eclipse.ui.ide.multiFilter</id>
>>
>> <arguments>1.0-name-matches-false-false-org.eclipse.mylyn.*</arguments>
>>
>>         </matcher>
>>
>>         </filter>
>>
>>         <filter>
>>
>>         <id>1672000970100</id>
>>
>>         <name></name>
>>
>>         <type>10</type>
>>
>>         <matcher>
>>
>>         <id>org.eclipse.ui.ide.multiFilter</id>
>>
>> <arguments>1.0-name-matches-false-false-mylyn.*</arguments>
>>
>>         </matcher>
>>
>>         </filter>
>>
>>         </filteredResources>
>>
>>     that keep appearing in the top level .project files?
>>
>>     George
>>
>>     On 2023-02-05 02:28, Gunnar Wagenknecht wrote:
>>
>>             On Feb 5, 2023, at 08:51, George
>>             Lindholm<javadev@xxxxxxxxxxxx>
>>             <mailto:javadev@xxxxxxxxxxxx>wrote:
>>
>>             My point is that those files are generated by maven when a
>>             project is imported
>>
>>         I've noticed that this can cause inconsistency among team
>>         members due to environment/system issues. Additionally,
>>         .settings such ad Eclipse code formatter and import organization
>>         are not manages by M2E AFAIK.
>>
>>         -Gunnar
>>
>>
>>         --         Gunnar Wagenknecht
>>         gunnar@xxxxxxxxxxxxxxx
>>         <mailto:gunnar@xxxxxxxxxxxxxxx>,http://guw.io/ <http://guw.io/>
>>
>>
>>
>>
>>
>>         _______________________________________________
>>
>>         mylyn-dev mailing list
>>
>>         mylyn-dev@xxxxxxxxxxx <mailto:mylyn-dev@xxxxxxxxxxx>
>>
>>         To unsubscribe from this list,
>> visithttps://www.eclipse.org/mailman/listinfo/mylyn-dev
>> <https://www.eclipse.org/mailman/listinfo/mylyn-dev>
>>
>>     _______________________________________________
>>     mylyn-dev mailing list
>>     mylyn-dev@xxxxxxxxxxx <mailto:mylyn-dev@xxxxxxxxxxx>
>>     To unsubscribe from this list, visit
>>     https://www.eclipse.org/mailman/listinfo/mylyn-dev
>>     <https://www.eclipse.org/mailman/listinfo/mylyn-dev>
>>
>>
>> _______________________________________________
>> mylyn-dev mailing list
>> mylyn-dev@xxxxxxxxxxx
>> To unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/mylyn-dev
>
> _______________________________________________
> mylyn-dev mailing list
> mylyn-dev@xxxxxxxxxxx
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/mylyn-dev

_______________________________________________
mylyn-dev mailing list
mylyn-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/mylyn-dev

Back to the top