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 rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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.

Mark > > On Sat, May 8, 2010 at 1:25 PM, Randy Secrist > <randy.secrist(a)gmail.com <mailto:randy.secrist@gmail.com>> 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 > rules-dev(a)lists.jboss.org <mailto:rules-dev@lists.jboss.org> > 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 > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > ------------------------------------------------------------------------ _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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.

Mark > Jervis > > >> Mark >> >> >>> On Sat, May 8, 2010 at 1:25 PM, Randy Secrist >>> <randy.secrist@gmail.com<mailto:randy.secrist@gmail.com>> 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 >>> rules-dev@lists.jboss.org<mailto:rules-dev@lists.jboss.org> >>> 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 >>> rules-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >>> >>> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> >> > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > > > > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

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 >>>> <randy.secrist@gmail.com<mailto:randy.secrist@gmail.com>> 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 >>>> rules-dev@lists.jboss.org<mailto:rules-dev@lists.jboss.org> >>>> 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 >>>> rules-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/rules-dev >>>> >>>> >>>> >>>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> rules-dev mailing list >>> rules-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-dev >>> >>> >>> >>> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev >> >> >> >> >> > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > > _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev