Jukka Zitting (JIRA) wrote:
[
http://issues.apache.org/jira/browse/GRFT-91?page=comments#action_12422584
]
Jukka Zitting commented on GRFT-91:
-----------------------------------
"maven eclipse" doesnt work for multiprojects.
"maven -Dgoal=eclipse multiproject:goal" should do that. I can also
make a more explicit "maven allEclipse" goal for that if you like.
Sure, I'd be interested to see that.
We really prefer having one Eclipse project for all subprojects though.
The problem with the precreated Eclipse project files is that if you
make inherently local modification (like set the project dependency
mentioned above, enable the Eclipse Checkstyle plugin, etc.), you'll
need to change normal svn usage patterns. When run in the project
folder, "svn status" will report the Eclipse files as modified, "svn
diff > latest-changes.patch" will include the local Eclipse changes,
"svn commit" will break things for others, etc. Even Eclipse will
flag the project as modified even if you've made no other changes to
it.
The only real issue I've had with checking in the .classpath file is
that we have to edit both the project.xml and .classpath (via the
Eclipse UI) when adding or removing a dependency. Once your project is
initially setup, this is a small price to pay, but if it could be
automated *correctly*, Im +1 for that.
We always use relative paths (Classpath Variables) to the local maven
repository, so this does impose an additional step for the user to once
setup the maven repository root for all maven-based projects. Contrary
to your statements above, I never see the .classpath file modified
unless I actually modify it via the Eclipse user interface.
