Hi again and txs 4 your comments!
There are a few problems with dirty files:
a) one cannot automated make sure that all builds well and the build is reproducable if there are dirty files lying around. A build script cannot judge which changes doesn't affect the build in a bad way and thus may be ignored.
b) therefore the maven-release-plugin will refuse to build a release if you have something dirty or not up2date.
c) if people get used to have dirty files, they will simply refuse to merge them because they don't like to apply their local settings every time
d) there are a lot of people working with Idea, NetBeans, vi, emacs, etc. All those people would not be forced by the settings in the eclipse config files.
e) having all the rules in the underlying build system will allow us to easily enable continuous integration tools like e.g. Hudson.
ad the JVM settings: I have up to 4 different JVMs installed on my boxes: 1.4.2, 1.5.x, 1.6.x stable and 1.6.x previews
So I have to tell eclipse what exact JVM to use.
Please note that the jdk1.5++ rule is already forced in the pom.xml maven-compiler-plugin settings.
ad different plugin versions config: having only the settings for a new plugin doesn't do anything (beside crashing/breaking eclipse) if you don't have the right versions of the plugins itself installed actually ;) This is imho only enforcable in a company and not in an OSS project.
LieGrue,
strub
--- On Thu, 9/24/09, Ferry Huberts <ferry.huberts@xxxxxxxxxx> wrote:
> From: Ferry Huberts <ferry.huberts@xxxxxxxxxx>
> Subject: Re: [JGIT PATCH 7/9] removing eclipse project files
> To: "Mark Struberg" <struberg@xxxxxxxx>
> Cc: "Ferry Huberts" <ferry.huberts@xxxxxxxxxx>, git@xxxxxxxxxxxxxxx, spearce@xxxxxxxxxxx
> Date: Thursday, September 24, 2009, 9:57 AM
>
> > I work on a lot of projects and having eclipse (or any
> other IDEs) project files in the SCM is
> > almost ever causing a problem. In praxis those files
> are always dirty. There are so many settings
> > which may be different from user to user
>
> true. however, those problems can easily be avoided by the
> policy of not ever checking in those eclipse files unless
> coordinated within the project.
>
> we have many big java projects here internally and _do_
> have
> the eclipse settings in git. it makes life so much easier
> for
> everyone to start work and we have many more settings in
> there that we actually want enforced.
>
> for example: we enforce a coding standard through eclipse
> by automatically formatting the source code and organising
> imports on file save. also, we want everybody to use the
> same
> settings when cleaning up the code. we want them to use
> the
> same findbugs settings, the same settings for xxx/yyy/....
>
> > * different JVM settings
>
> if specified correctly this is actually an advantage: you
> can
> standardise your projects on a (minimum) JVM platform, like
> 1.5
>
> > * using different version of various plugins
>
> we see that as an advantage so that we can standardise the
> development setup, or at least define some sort of minimum
> setup
>
>
> > You can easily create the project files for a few IDEs
> with maven e.g.:
> > $> mvn eclipse:eclipse for
> creating the eclipse project files
> > $> mvn idea:idea
> for creating the idea project files
>
> I know, quite handy :-)
>
> Think I have more questions now than before by discussing
> it :-)
>
>
--
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