Re: [JGIT PATCH 7/9] removing eclipse project files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Robin!

Thanks for your comments, answers inside.

Please note that all my comments are for JGit only and not for the Egit Eclipse plugin! This should be discussed separately.

LieGrue,
strub

--- On Fri, 9/25/09, Robin Rosenberg <robin.rosenberg.lists@xxxxxxxxxx> wrote:

> From: Robin Rosenberg <robin.rosenberg.lists@xxxxxxxxxx>
> Subject: Re: [JGIT PATCH 7/9] removing eclipse project files
> To: "Mark Struberg" <struberg@xxxxxxxx>
> Cc: "MatthiasSohn" <matthias.sohn@xxxxxxx>, "git@xxxxxxxxxxxxxxx" <git@xxxxxxxxxxxxxxx>, "spearce@xxxxxxxxxxx" <spearce@xxxxxxxxxxx>
> Date: Friday, September 25, 2009, 11:17 PM
> torsdag 24 september 2009 13:50:11
> skrev Mark Struberg <struberg@xxxxxxxx>:
> > Hi Matthias!
> > 
> > the answer is a clear yes and no  - a 'jein' for
> german speaking people like you ;)
> > 
> > yes: we have the same settings for the compiler as
> used before: jdk 1.5 for source and target. This is exactly
> what has been taken in the ant build which was used prior to
> maven. 
> >
> > Please note that the settings in
> org.eclipse.jdt.core.prefs never had (and must not have) any
> impact on the created jar!
> 
> Not sure what ant files you are referring to here and which
> jars. The plugins downloadable from jgit.org has been built
> using PDE build. so some of the .settings should affect the
> compiler and thus the generated jars.


Apologise, you are right, no ant files. But a shell script make_jgit.sh which calls the javac directly. So no PDE for JGit as far as I see from the sources.

> 
> > and no: currently the very file you mentioned contains
> a lot more stuff. In fact most of this are only editor
> settings, preferred formattings etc which has nothing to do
> with the build per se. Eclipse has the ability to
> import/export all those settings in a XML file which is
> version independent. We should go this way and also supply
> similar setting-files for Idea and NetBeans. But forcing
> those settings via an internal Eclipse plugin config file is
> imho bad practice.
> 
> That way is awkward and people to import the settings and
> screw them up in their workspaces. I've made the projects
> I'm involved use .settings and make different settings
> mostly a non-issue because everyone gets new
> settings automatically as they change. 

We should integrate the checkstyle plugin into our pom. This should give you almost the same functionality.

> Prior to eclipse 3.3
> sharing settings was a big problem, but It's not a big deal
> nowadays. The most annoying thing is that some settings are
> not available as project specific settings. 

As you already pointed to: we have to clearly separate between settings stored in the project itself and settings stored in the workspace. The first are by far not all settings needed, the 2nd are not checked in to git anyway. Maybe I didn't  find it yet, but is there an ability to set formatter settings for XML (e.g. Tabs vs spaces policy)? I was only able to specify this for the whole workspace and not on a per project basis. And there is a lot more which imho cannot be set for a project. So checking in the xml sounds like it is way more powerful isn't? And we would have this feature for a lot non-Eclipse users too (e.g. for Jonas who hacks the nbgit NetBeans plugin based on JGit (again: EGit is a different story!)).

> 
> We use 3.3 (well I think the last user dropped it
> recently), 3.4 and 3.5. I often have to fix up new projects
> but that is typically a one-time per eclipse project
> problem. (typically the JRE gets bound to a specific install
> location).
> 
> The .launch files is another story since they change format
> all the time.

And the profiler settings, and and and. It's sad, but the list is long :(

We can also let the eclipse settings files checked in currently if you like. But I'd be happy if we continue collecting information and then make a decision.

txs, 
strub




      
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]