+1 to delete those files. Then add them to svn:ignore after deleting them, please.
On Sunday 09,May,2010 11:17 PM, Jervisliu wrote: > Mark Proctor wrote: > >> On 08/05/2010 15:40, Jervisliu wrote: >> >> >>> Mark Proctor wrote: >>> >>> >>> >>>> On 08/05/2010 05:13, Michael Neale wrote: >>>> >>>> >>>> >>>>> I think the past approach was not to have them - and instead let mvn >>>>> eclipse generate them - but somehow they got checked in along the >>>>> way. At least it used to be that way. >>>>> >>>>> >>>>> >>>> Maven use to not be able to build the eclipse files in the entire >>>> trunk would not build. So from time to time we generate and commit the >>>> .project and .classpath to keep them up to date. >>>> >>>> >>>> >>>> >>> Personally I prefer not to have these .project and .classpath files >>> checked in. They are annoying. For example, I always use "mvn >>> eclipse:clean eclipse:eclipse" to generate eclipse project. When I do a >>> svn commit, these .project and .classpath files always show up as >>> modified, I have to manually exclude these files from commit list. >>> >>> Mark, the Maven eclipse project generation problem you mentioned, does >>> it still exist or has it been fixed in the newer version of maven? >>> >>> >>> >> I think it's ok now, we can probably delete the files. >> >> >> > OK, if there are no objects in next 24 hours, I will remove these > .project and .classpath files from svn. > > Jervis > >> Mark >> >> >>> Jervis >>> >>> >>> >>>> Mark >>>> >>>> >>>> >>>>> On Sat, May 8, 2010 at 1:25 PM, Randy Secrist >>>>> <[email protected]<mailto:[email protected]>> wrote: >>>>> >>>>> There are a number of references to M2_REPO in eclipse .classpath >>>>> files which are appear to no longer be used by the MVN build (for >>>>> at least the test case + install phase). I'm assuming it is >>>>> because the CI loop is fine but the eclipse stuff has not been >>>>> maintained. >>>>> >>>>> Would any committers here be interested if I patched out the >>>>> artifacts within the .classpath files which I don't think we need >>>>> anymore and sent up the diff? >>>>> >>>>> or - >>>>> >>>>> should we remove the .classpath and .project? >>>>> >>>>> or - >>>>> >>>>> should we enable the sonatype maven plugin within the .project files? >>>>> >>>>> Some examples are: >>>>> drools-decisiontables/.classpath has >>>>> - antlr >>>>> - cglib >>>>> - stringtemplate >>>>> - hamcrest-core >>>>> - hamcrest-library >>>>> - jmock-legacy >>>>> - jmock >>>>> - objenesis >>>>> >>>>> Let me know what you guys think ... >>>>> >>>>> -- Randy Secrist >>>>> GE Healthcare >>>>> >>>>> _______________________________________________ >>>>> rules-dev mailing list >>>>> [email protected]<mailto:[email protected]> >>>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Michael D Neale >>>>> home: www.michaelneale.net<http://www.michaelneale.net> >>>>> blog: michaelneale.blogspot.com<http://michaelneale.blogspot.com> >>>>> >>>>> >>>>> _______________________________________________ >>>>> rules-dev mailing list >>>>> [email protected] >>>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>>> >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> rules-dev mailing list >>>> [email protected] >>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>> >>>> >>>> >>>> >>> _______________________________________________ >>> rules-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >>> >>> >>> >>> >> >> _______________________________________________ >> rules-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> > _______________________________________________ > rules-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-dev > _______________________________________________ rules-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-dev
