[m2e-wtp-dev] m2e wtp setting files and SCM repository changes

[Frank Gasdorf]

Hello everybody,

we are using git as SCM and the following .setting files are committed
initially:



*.settings/org.eclipse.wst.common.component.settings/org.eclipse.wst.common.project.facet.core.xml*
since we have workspace resolution for mvn modules activated we have the
following scenario which drives us a bit crazy:
* the first file gets updated every time a Developer imports a project that
is referenced in pom.xml
* git always mark this file as changed
* some Developers just add, commit, and push these changes, while others
know that the change are workspace specific and are not valid for others
* some changes in pom.xml file (e.g. contextName) are relevant and settings
file content updated by m2e correclty (maven --> update project...


I'd like to get an impression how others handle this to avoid always "git
checkout --" for .settings files before committing relevant changes to the
project such as java files, etc

I tried to use "--assume-unchanged" option in gitbut IMHO its not really an
option because if others clone a repositorythey have to configure it again.
On the other hand it can be hard to get updates from others in.

In addition, the wst files are required to have a proper Eclipse project
setup. Is it an option to generate these (Maven --> Uptate project ...)
before or during "Import Maven project into Workspace".

Looking forward to hear best practices from others

In regards
- Frank

[Fred Bricon]

these files are automatically generated on maven project import, or project
update.
The only reason to keep them in your SCM is if you have customized them and
automatic import gives you a different result.

I'm curious to know what kind of diff you see between imports. Also, what
version of m2e-wtp are you using?

Post by Frank Gasdorf
Hello everybody,
we are using git as SCM and the following .setting files are committed
*.settings/org.eclipse.wst.common.component.settings/org.eclipse.wst.common.project.facet.core.xml*
since we have workspace resolution for mvn modules activated we have the
* the first file gets updated every time a Developer imports a project
that is referenced in pom.xml
* git always mark this file as changed
* some Developers just add, commit, and push these changes, while others
know that the change are workspace specific and are not valid for others
* some changes in pom.xml file (e.g. contextName) are relevant and
settings file content updated by m2e correclty (maven --> update project...
I'd like to get an impression how others handle this to avoid always "git
checkout --" for .settings files before committing relevant changes to the
project such as java files, etc
I tried to use "--assume-unchanged" option in gitbut IMHO its not really
an option because if others clone a repositorythey have to configure it
again. On the other hand it can be hard to get updates from others in.
In addition, the wst files are required to have a proper Eclipse project
setup. Is it an option to generate these (Maven --> Uptate project ...)
before or during "Import Maven project into Workspace".
Looking forward to hear best practices from others
In regards
- Frank
_______________________________________________
m2e-wtp-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/m2e-wtp-dev

[Frank Gasdorf]

Within Eclipse Kepler we are using
org.eclipse.m2e.feature_1.4.0.20130601-0317

Going to try a fresh import again, maybe its because or the older version
we use ...

- Frank

Post by Fred Bricon
these files are automatically generated on maven project import, or
project update.
The only reason to keep them in your SCM is if you have customized them
and automatic import gives you a different result.
I'm curious to know what kind of diff you see between imports. Also, what
version of m2e-wtp are you using?

Post by Frank Gasdorf
Hello everybody,
we are using git as SCM and the following .setting files are committed
*.settings/org.eclipse.wst.common.component.settings/org.eclipse.wst.common.project.facet.core.xml*
since we have workspace resolution for mvn modules activated we have the
* the first file gets updated every time a Developer imports a project
that is referenced in pom.xml
* git always mark this file as changed
* some Developers just add, commit, and push these changes, while others
know that the change are workspace specific and are not valid for others
* some changes in pom.xml file (e.g. contextName) are relevant and
settings file content updated by m2e correclty (maven --> update project...
I'd like to get an impression how others handle this to avoid always "git
checkout --" for .settings files before committing relevant changes to the
project such as java files, etc
I tried to use "--assume-unchanged" option in gitbut IMHO its not really
an option because if others clone a repositorythey have to configure it
again. On the other hand it can be hard to get updates from others in.
In addition, the wst files are required to have a proper Eclipse project
setup. Is it an option to generate these (Maven --> Uptate project ...)
before or during "Import Maven project into Workspace".
Looking forward to hear best practices from others
In regards
- Frank
_______________________________________________
m2e-wtp-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/m2e-wtp-dev

--
"Have you tried turning it off and on again" - The IT Crowd
And if that fails, then http://goo.gl/tnBgH5

[Frank Gasdorf]

I'm confused a bit. What's the recommend setup for a Maven-Multi-Module
project, that has the following packaging types:
eclipse-plugin
eclipse-repository
eclipse-feature
war
jar

To be much more specific: Is it recommend to checkin .project file or let
m2e create, if the developer imports existing maven projects?

My current situation:
* If the file exists, m2e seems to verify, if the m2e nature and builders
are configured, if not, they're added
* If the .project file doesn't exists, its created with
jdt.core.javabuilder but WITHOUT pde-Buildes --> therfore cannot compile
sucessfully, because of missing plugin-dependency resolition
<buildCommand>
<name>org.eclipse.pde.ManifestBuilder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>org.eclipse.pde.SchemaBuilder</name>
<arguments>
</arguments>
</buildCommand>
* for feature modules I would expect to get a .project file generated that
has the following buildSpec' and natures
<buildSpec>
<buildCommand>
<name>org.eclipse.pde.FeatureBuilder</name>
<arguments>
</arguments>
</buildCommand>
</buildSpec>
<natures>
<nature>org.eclipse.pde.FeatureNature</nature>
</natures>

but got this:
<buildSpec>
<buildCommand>
<name>org.eclipse.jdt.core.javabuilder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>org.eclipse.m2e.core.maven2Builder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>org.springframework.ide.eclipse.core.springbuilder</name>
<arguments>
</arguments>
</buildCommand>
</buildSpec>
<natures>
<nature>org.springframework.ide.eclipse.core.springnature</nature>
<nature>org.eclipse.jdt.core.javanature</nature>
<nature>org.eclipse.m2e.core.maven2Nature</nature>
</natures>

In Addition, I expected to get Findbugs and Checkstyle builders configured,
because both are configured in maven root pom module. Eclipse plugins are
installed in MARS Eclispe IDE successfully and can be configured manually,
what I would like to avoid ;)

Last but not least : Whats your recommondation for Setups such as
checkstyle, jdt tasks, findbugs, formatter, save and clean up actions? We
are started to setup IDE with Oomph but it seems that global configurations
are overriden by project specific configurations generated by m2e.


Your help is much apreciated!

- Frank

Post by Frank Gasdorf
Within Eclipse Kepler we are using
org.eclipse.m2e.feature_1.4.0.20130601-0317
Going to try a fresh import again, maybe its because or the older version
we use ...
- Frank

Post by Fred Bricon
these files are automatically generated on maven project import, or
project update.
The only reason to keep them in your SCM is if you have customized them
and automatic import gives you a different result.
I'm curious to know what kind of diff you see between imports. Also, what
version of m2e-wtp are you using?
On Wed, Sep 9, 2015 at 8:32 AM, Frank Gasdorf <

Post by Frank Gasdorf
Hello everybody,
we are using git as SCM and the following .setting files are committed
*.settings/org.eclipse.wst.common.component.settings/org.eclipse.wst.common.project.facet.core.xml*
since we have workspace resolution for mvn modules activated we have the
* the first file gets updated every time a Developer imports a project
that is referenced in pom.xml
* git always mark this file as changed
* some Developers just add, commit, and push these changes, while others
know that the change are workspace specific and are not valid for others
* some changes in pom.xml file (e.g. contextName) are relevant and
settings file content updated by m2e correclty (maven --> update project...
I'd like to get an impression how others handle this to avoid always
"git checkout --" for .settings files before committing relevant changes to
the project such as java files, etc
I tried to use "--assume-unchanged" option in gitbut IMHO its not
really an option because if others clone a repositorythey have to configure
it again. On the other hand it can be hard to get updates from others i
n.
In addition, the wst files are required to have a proper Eclipse project
setup. Is it an option to generate these (Maven --> Uptate project ...)
before or during "Import Maven project into Workspace".
Looking forward to hear best practices from others
In regards
- Frank
_______________________________________________
m2e-wtp-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/m2e-wtp-dev

--
"Have you tried turning it off and on again" - The IT Crowd
And if that fails, then http://goo.gl/tnBgH5