Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [tycho-user] It is safer for eclipse.org projects to remove .classpath and .project from git when using tycho ?

To me there is no hard rule which way is better and decision boils down
if particular project considers pom.xml or .project/etc the primary
workspace configuration metadata.

Many/most projects I work on depend on maven/eclipse integration
functionality provided by m2e, things like source code generation, to
give you an example. For such projects it makes sense to let m2e do its
thing and treat eclipse metadata as generated contents.

For projects that use custom builders and/or rely on specific eclipse
plugins, it certainly makes sense to use eclipse workspace metadata as
the primary and treat pom.xml as necessary evil required by tycho.

And I guess there is a bunch of "standard" projects that can go either
way and choice between pom.xml and eclipse metadata becomes a matter of
personal preferences of project developers.

I have yet to see a project that benefits from maven-eclipse-plugin,
but I am biased ;-)

--
Regards,
Igor

On 12-06-15 6:13 PM, Aaron Digulla wrote:
Am 15.06.2012 00:54, schrieb Cristiano Gavião:
Hi,

Many Eclipse project are being converted to Tycho.

But I'm seeing some resistance of some teams to remove .classpath and
.project  from source control even knowing that .classpath and .project
are generated by m2e plugin.

Could Tycho developers give me some words about this?

I hate it when teams cripple their projects in this way. These are
*Eclipse* projects. After downloading/cloning them, I should be able to
open them in my workspace without any additional work.

Also, m2e doesn't always create correct files (or it didn't in the
past). Does m2e support special builders in the .project file? So this
is dangerous, too.

And lastly, when the people doing that aren't careful about their
gitignore settings, the next developer either gets missing files or
project that are always in a modified state.

The only argument which is in favor of deleting these files is that you
shouldn't commit generated files. While this might make sense at first
glance, it can (and does) create lots of problems that are hard to track
down (the "I didn't change anything" kind).

If these were huge files, I might be game but not for something that is
so small and vital and error prone.

Regards,




Back to the top