Progress with Eclipse
I need a brave eclipse user to try out the following, and then I have some questions for others. 1) Remove all .project and .classpath files from your tree. 2) cd to 'eclipse'. 3) Pick a new pathname for an eclipse workspace (call it WORKSPACE) in the following. 4) mvn -Psetup-eclipse-workspace -Declipse.workspace.dir=WORKSPACE This much will create WORKSPACE, copy some files into it, and set some global options. 5) cd .. (to the mahout top) 6) mvn -Psetup.eclipse -Declipse.workspace=WORKSPACE Now there will be .project and .classpath files. 7) start eclipse, select WORKSPACE 8) import projects from the mahout toplevel If all goes well, you will be presented with a lot of PMD complaints. I turned on PMD as part of the show, and it seems that we have a supply of PMD non-compliance. What do people think about the PMD rules we have checked in? Do we want to conform to them?
Re: Progress with Eclipse
I checked out a clean trunk and managed to get as far as step 6 without problems. 6 failed trying to pull the collections-codegen plugin 0.4-SNAPSHOT from a repo. I'm not sure why the reactor is not picking it up. Nevertheless, I was able to get past this by running a separate mvn clean install to push the plugin to my local repo. When all is said and done, I get a bunch of errors from mahout-collections complaining about the @Overrides. Switching compliance to 1.6 of course eliminates these. The .checkstyle, .pmd and .ruleset files under each project cause svn to show changes. We should set svn:ignore on these -- or should they be checked in? Without getting too specific it strikes me that some of the stuff that PMD is complaning about should be downgraded from 'Error high' or 'Error' to some level of warning. For example it appears that all of the modules have errors of some level based on the existing (default?) settings. FWIW, here's my environment: mvn --version Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400) Java version: 1.6.0_16 Java home: /u01/opt/jdk1.6.0_16/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.28-18-server arch: i386 Family: unix On Mon, Mar 22, 2010 at 9:35 AM, Benson Margulies bimargul...@gmail.com wrote: I need a brave eclipse user to try out the following, and then I have some questions for others. 1) Remove all .project and .classpath files from your tree. 2) cd to 'eclipse'. 3) Pick a new pathname for an eclipse workspace (call it WORKSPACE) in the following. 4) mvn -Psetup-eclipse-workspace -Declipse.workspace.dir=WORKSPACE This much will create WORKSPACE, copy some files into it, and set some global options. 5) cd .. (to the mahout top) 6) mvn -Psetup.eclipse -Declipse.workspace=WORKSPACE Now there will be .project and .classpath files. 7) start eclipse, select WORKSPACE 8) import projects from the mahout toplevel If all goes well, you will be presented with a lot of PMD complaints. I turned on PMD as part of the show, and it seems that we have a supply of PMD non-compliance. What do people think about the PMD rules we have checked in? Do we want to conform to them?
Re: Progress with Eclipse
I think an initial build is needed. The files should not be checked in -- Eclipse requires one-per-project and the magic dust is pushing copies from a central location. Ignores are fine. I have blankets for those files in my personal settings so I didn't spot the issue. I don't know the parentage of the PMD file that was checked in. It might even have come from me a long time ago. I do hate warnings, so my view, personally, is that we either keep+fix or remove. Is anyone else interested in wrestling with PMD. On Mon, Mar 22, 2010 at 9:41 PM, Drew Farris drew.far...@gmail.com wrote: I checked out a clean trunk and managed to get as far as step 6 without problems. 6 failed trying to pull the collections-codegen plugin 0.4-SNAPSHOT from a repo. I'm not sure why the reactor is not picking it up. Nevertheless, I was able to get past this by running a separate mvn clean install to push the plugin to my local repo. When all is said and done, I get a bunch of errors from mahout-collections complaining about the @Overrides. Switching compliance to 1.6 of course eliminates these. The .checkstyle, .pmd and .ruleset files under each project cause svn to show changes. We should set svn:ignore on these -- or should they be checked in? Without getting too specific it strikes me that some of the stuff that PMD is complaning about should be downgraded from 'Error high' or 'Error' to some level of warning. For example it appears that all of the modules have errors of some level based on the existing (default?) settings. FWIW, here's my environment: mvn --version Apache Maven 2.2.1 (r801777; 2009-08-06 15:16:01-0400) Java version: 1.6.0_16 Java home: /u01/opt/jdk1.6.0_16/jre Default locale: en_US, platform encoding: UTF-8 OS name: linux version: 2.6.28-18-server arch: i386 Family: unix On Mon, Mar 22, 2010 at 9:35 AM, Benson Margulies bimargul...@gmail.com wrote: I need a brave eclipse user to try out the following, and then I have some questions for others. 1) Remove all .project and .classpath files from your tree. 2) cd to 'eclipse'. 3) Pick a new pathname for an eclipse workspace (call it WORKSPACE) in the following. 4) mvn -Psetup-eclipse-workspace -Declipse.workspace.dir=WORKSPACE This much will create WORKSPACE, copy some files into it, and set some global options. 5) cd .. (to the mahout top) 6) mvn -Psetup.eclipse -Declipse.workspace=WORKSPACE Now there will be .project and .classpath files. 7) start eclipse, select WORKSPACE 8) import projects from the mahout toplevel If all goes well, you will be presented with a lot of PMD complaints. I turned on PMD as part of the show, and it seems that we have a supply of PMD non-compliance. What do people think about the PMD rules we have checked in? Do we want to conform to them?
Re: Progress with Eclipse
On Mon, Mar 22, 2010 at 9:46 PM, Benson Margulies bimargul...@gmail.com wrote: The files should not be checked in -- Eclipse requires one-per-project and the magic dust is pushing copies from a central location. Ignores are fine. I have blankets for those files in my personal settings so I didn't spot the issue. svn:ignore's committed. I don't know the parentage of the PMD file that was checked in. It might even have come from me a long time ago. I do hate warnings, so my view, personally, is that we either keep+fix or remove. Yes, I don't like warnings either, but until these are fixed or removed warnings are better than errors. I don't think all of PMD's gripes are worth ignoring (e.g: method names starting with capital letters). I''ve never used PMD before, so I'm likely to be of little help revising the existing settings.
Eclipse
If you want convenience with Eclipse, here's the process: 1) run eclipse:configure-workspace to set M2_REPO in the workspace. 2) Copy several files into the workspace: checkstyle setting, PMD settings, Eclipse code format settings, Eclipse cleanup settings. 3) create and augment several Eclipse setting files to point to the files in (2). 4) run eclipse:eclipse on the individual projects. Step 3 gets a little bit sticky. Since the maven-eclipse-plugin doesn't know about checkstyle and pmd, and has very limited capabilities on prop files, it turns out that 'ant' is the tool for the job. It is possible to run this from the maven-antrun-plugin, but You have to add things to the dependencies of the antrun plugin, and, due to Maven bugs, this can cause some very frustrating problems later on when trying to use anyrun for other things. So, at my dayjob, I made an outboard shell script. Everybody at our shop is Linux, Mac, or Cygwin. That's not a reasonable assumption in these parts. Options: 1) just provide an ant XML file and tell people to run ant on it. 2) shell + .bat. Anyone object to option #1?
Re: Eclipse
Sounds fine to me. (I use IntelliJ which just sucks in the pom as if it were a project file so anything that makes life better for eclipse users is good by me) On Fri, Mar 19, 2010 at 4:20 AM, Benson Margulies bimargul...@gmail.comwrote: Options: 1) just provide an ant XML file and tell people to run ant on it. 2) shell + .bat. Anyone object to option #1?
Working With Maven in Eclipse
When I run mvn eclipse:eclipse it generates .classpath and .project files in each of the mahout module directories. The last time I did this I manually merged the .classpath library declarations from each module into the main project's .classpath and that made Eclipse happy. This was really tedious and I suspect unnecessary but I am unable to make my Eclipse+m2eclipse do anything useful with the checkout wad. Are any of you using this IDE in a more automatic way?
Re: Working With Maven in Eclipse
On Wed, Mar 17, 2010 at 3:07 PM, Jeff Eastman j...@windwardsolutions.com wrote: Are any of you using this IDE in a more automatic way? I use eclipse Galileo and m2eclipse 0.9 and the 'import maven projects' feature. I check out the mahout sources into my workspace directory, do a full build on the command-line and then fire up the import in eclipse from File Import Maven Projects. I point it at the mahout root directory. You are then given the opportunity to choose which sub-modules to import. You don't need to import them all, only the projects you are interested in working with. This sets up one eclipse project for each of the mahout sub-modules you chose. Inter-project dependencies are automatically resolved. For example, if mahout-core and mahout-math are both open the m2eclipse plugin will automatically set up a project dependency on mahout-math in mahout-core. If you close mahout-math, the plugin will automatically revert to a jar dependency for mahout-math. IIRC, if you are importing mahout-collections/mahout-math you will have to add the target/generated-sources directories to your build path manually and do a refresh on the dependent projects. Alternatively just avoid importing these (or close them) and they will be treated as a regular jar dependency. I've found this works much better than doing the checkout into eclipse directly via the m2eclipse 'check out maven projects from scm' importer. I haven't tried eclipse:eclipse on a multimodule project like Mahout. I
Re: Working With Maven in Eclipse
Drew Farris wrote: On Wed, Mar 17, 2010 at 3:07 PM, Jeff Eastman j...@windwardsolutions.com wrote: Are any of you using this IDE in a more automatic way? I use eclipse Galileo and m2eclipse 0.9 and the 'import maven projects' feature. I check out the mahout sources into my workspace directory, do a full build on the command-line and then fire up the import in eclipse from File Import Maven Projects. I point it at the mahout root directory. You are then given the opportunity to choose which sub-modules to import. You don't need to import them all, only the projects you are interested in working with. This sets up one eclipse project for each of the mahout sub-modules you chose. Inter-project dependencies are automatically resolved. For example, if mahout-core and mahout-math are both open the m2eclipse plugin will automatically set up a project dependency on mahout-math in mahout-core. If you close mahout-math, the plugin will automatically revert to a jar dependency for mahout-math. IIRC, if you are importing mahout-collections/mahout-math you will have to add the target/generated-sources directories to your build path manually and do a refresh on the dependent projects. Alternatively just avoid importing these (or close them) and they will be treated as a regular jar dependency. I've found this works much better than doing the checkout into eclipse directly via the m2eclipse 'check out maven projects from scm' importer. I haven't tried eclipse:eclipse on a multimodule project like Mahout. I Marvelous! I had checked out the project from SVN as a simple Java project before I installed m2eclipse and it was not doing anything with the poms. This worked really well and I will add it to the wiki. I knew there had to be a better way. Thanks, Jeff
Re: Eclipse IAM Help
I recommend maven 2.1.x. I can't explain the error from eclipse:eclipse, I use it constantly. On Mon, Mar 15, 2010 at 7:13 PM, Jeff Eastman j...@windwardsolutions.com wrote: After deleting my .m2 repository and rebuilding Mahout I now had an Eclipse classpath full of obsolete references to various jars. I tried mvn eclipse:eclipse but it fails claiming the plugin is missing. Then I tried installing the Eclipse IAM plugin and marking the project Use Maven dependency management. That lets me browse the .pom files and the project structure looks more obvious than before but it zapped all the source directories from my classpath. If I add them back manually I have 20k errors. Has anybody used this plugin and can help get me sorted out again? Jeff PS: I'm using Maven 2.0.10
Re: How to create eclipse project for mahout using maven ?
Thanks Ankur, but when I run eclipse:eclipse, It shows me errors as
following:
[INFO] [eclipse:eclipse]
[INFO] Using Eclipse Workspace: D:\Code\workspace
[INFO] Adding default classpath container:
org.eclipse.jdt.launching.JRE_CONTAIN
ER
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Cant canonicalize system path: {0}
Embedded error: The filename, directory name, or volume label syntax is
incorrec
t
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 18 seconds
[INFO] Finished at: Tue Mar 09 16:16:06 CST 2010
[INFO] Final Memory: 29M/52M
[INFO]
*Do you know what is this issue ?*
On Wed, Mar 3, 2010 at 7:43 PM, Ankur C. Goel gan...@yahoo-inc.com wrote:
Here is what I do
1. Checkout mahout from svn into eclipse workspace.
2. Adding maven repositories to eclipse from command line- mvn
-Declipse.workspace=path-to-eclipse-workspace eclipse:add-maven-repo.
3. From mahout top level dir run this on command line - mvn
eclipse:eclipse. This generates all the eclipse files in individual maven
modules.
4. Import each module one at a time in eclipse.
-...@nkur
On 3/3/10 4:46 PM, Jeff Zhang zjf...@gmail.com wrote:
Hi all,
I'd like to create eclipse project using maven for mahout, but I meet a
error message. How people here create eclipse project ? Can you create it
successfully ?
The following is the error message:
[INFO]
[INFO] Building Mahout Taste Webapp
[INFO]task-segment: [eclipse:eclipse]
[INFO]
[INFO] Preparing eclipse:eclipse
[INFO] [remote-resources:process {execution: default}]
[INFO] [eclipse:eclipse]
[INFO] Using Eclipse Workspace: D:\Code\workspace
[INFO] Adding default classpath container:
org.eclipse.jdt.launching.JRE_CONTAIN
ER
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Cant canonicalize system path: {0}
Embedded error: The filename, directory name, or volume label syntax is
incorrec
t
[INFO]
[INFO] For more information, run Maven with the -e switch
--
Best Regards
Jeff Zhang
--
Best Regards
Jeff Zhang
Re: Math compile errors in Eclipse
DoubleFunction is a generated file right? so I'd suspect some issue with that. Is it still configured as a source root, the generated-sources dir? I dunno but this happend to me in IntelliJ too. I assume its an artifact of reloading the pom.xml file and resetting some things. On Tue, Feb 9, 2010 at 12:06 AM, Jeff Eastman j...@windwardsolutions.com wrote: I'm getting a lot of compile errors in Eclipse after my most recent svn update today. The errors begin in the math module where DoubleFunction seems to be missing and spread outward from there. Since maven can still build it I assume the problem is mine but I cannot begin to unwind it. Can somebody offer a clue? Jeff
Re: Math compile errors in Eclipse
Ah, ok, that makes some sense. I did a clean build and the red lights all went away. Thanks Sean wrote: DoubleFunction is a generated file right? so I'd suspect some issue with that. Is it still configured as a source root, the generated-sources dir? I dunno but this happend to me in IntelliJ too. I assume its an artifact of reloading the pom.xml file and resetting some things. On Tue, Feb 9, 2010 at 12:06 AM, Jeff Eastman j...@windwardsolutions.com wrote: I'm getting a lot of compile errors in Eclipse after my most recent svn update today. The errors begin in the math module where DoubleFunction seems to be missing and spread outward from there. Since maven can still build it I assume the problem is mine but I cannot begin to unwind it. Can somebody offer a clue? Jeff
Re: Eclipse and Maven Don't Agree
2010/1/18 Jeff Eastman j...@windwardsolutions.com: Sean Owen wrote: Could be. I took an indirect stab at mitigating possible sources of this issue by increasing encapsulation in the tests -- I still believe fields should never by non-private. This may start to surface the behind-the-scenes dependencies and side effects that shouldn't be there. But the issue, if you're right, probably concerns too much static stuff. What tests are failing? I tried -X, --error and --debug options but none gave me any more resolution on the problem. Thinking this might be an initialization issue, I commented out the two assertEquals statements in ../dirichlet/TestMapReduce.testMapper() and .testReducer() and now the Maven install runs just fine. So, it looks to me like a recent change to the way random numbers are initialized introduced the problem. I don't know why nobody else is seeing this, since I have not changed either of those two tests. Have you tried to have a look at the surefire test reports in: mahout/core/target/surefire-reports ? Failure stacktraces are stored in org.apache.mahout.*.txt files. If you want to plug eclipse to the JVM running the maven surefire tests to setup breakpoints: http://maven.apache.org/plugins/maven-surefire-plugin/examples/debugging.html -- Olivier http://twitter.com/ogrisel - http://code.oliviergrisel.name
Eclipse and Maven Don't Agree
I've made some changes for MAHOUT-251 and all the tests run in Eclipse, but two of them fail when run from Maven. How can I poke mvn to give me more diagnostics?
Re: Eclipse and Maven Don't Agree
-X? Use the surefire options to allow you to attach eclipse to the test once launched from maven? That's foolproof. On Sun, Jan 17, 2010 at 7:26 PM, Jeff Eastman j...@windwardsolutions.com wrote: I've made some changes for MAHOUT-251 and all the tests run in Eclipse, but two of them fail when run from Maven. How can I poke mvn to give me more diagnostics?
Re: Eclipse and Maven Don't Agree
This sounds like it is related to running tests in a single JVM and thus related to ordering of tests. Ick. On Sun, Jan 17, 2010 at 5:23 PM, Benson Margulies bimargul...@gmail.comwrote: -X? Use the surefire options to allow you to attach eclipse to the test once launched from maven? That's foolproof. On Sun, Jan 17, 2010 at 7:26 PM, Jeff Eastman j...@windwardsolutions.com wrote: I've made some changes for MAHOUT-251 and all the tests run in Eclipse, but two of them fail when run from Maven. How can I poke mvn to give me more diagnostics? -- Ted Dunning, CTO DeepDyve
Re: Eclipse and Maven Don't Agree
Could be. I took an indirect stab at mitigating possible sources of this issue by increasing encapsulation in the tests -- I still believe fields should never by non-private. This may start to surface the behind-the-scenes dependencies and side effects that shouldn't be there. But the issue, if you're right, probably concerns too much static stuff. What tests are failing?
Re: Eclipse and Maven Don't Agree
Sean Owen wrote: Could be. I took an indirect stab at mitigating possible sources of this issue by increasing encapsulation in the tests -- I still believe fields should never by non-private. This may start to surface the behind-the-scenes dependencies and side effects that shouldn't be there. But the issue, if you're right, probably concerns too much static stuff. What tests are failing? I tried -X, --error and --debug options but none gave me any more resolution on the problem. Thinking this might be an initialization issue, I commented out the two assertEquals statements in ../dirichlet/TestMapReduce.testMapper() and .testReducer() and now the Maven install runs just fine. So, it looks to me like a recent change to the way random numbers are initialized introduced the problem. I don't know why nobody else is seeing this, since I have not changed either of those two tests. When run from Eclipse one test class at a time, the random number generator is initialized one way and the two tests pass. During the Maven run; however, it is initialized differently (or not at the start of the test) and so these two tests produce different numbers of mapper partitions (collector keys) and those two tests fail. I'm going to check in the modified tests - with no asserts - while we sort out the random number seeding or I figure out a better way to do the tests. Testing Dirichlet is darn difficult because all of the random-induced moving parts.
Re: Eclipse and checkstyle
On Saturday 19 December 2009 16:30:31 Benson Margulies wrote: Since you've got a checkstyle set that you like, can I go ahead and build the profile for setting up eclipse to use it? Sure. There should already be a checkstyle file checked in (maven module) - feel free to use that or replace by one that matches the style used for Lucene as well. Isabel -- |\ _,,,---,,_ Web: http://www.isabel-drost.de /,`.-'`'-. ;-;;,_ |,4- ) )-,_..;\ ( `'-' '---''(_/--' `-'\_) (fL) IM: xmpp://main...@spaceboyz.net signature.asc Description: This is a digitally signed message part.
eclipse codestyle.xml?
Hi All, On the wiki, http://cwiki.apache.org/MAHOUT/howtocontribute.html, The link at the bottom of the page to the eclipse codestyle.xml for Mahout's coding conventions seems to be broken. Does anyone have a codestyle.xml for eclipse available? Thanks, Drew
Re: eclipse codestyle.xml?
Hmm, weird. They must have gotten lost when the ASF upgraded MoinMoin. They are the same as Lucene's: http://wiki.apache.org/lucene-java/HowToContribute On Nov 24, 2009, at 10:11 AM, Drew Farris wrote: Hi All, On the wiki, http://cwiki.apache.org/MAHOUT/howtocontribute.html, The link at the bottom of the page to the eclipse codestyle.xml for Mahout's coding conventions seems to be broken. Does anyone have a codestyle.xml for eclipse available? Thanks, Drew
Re: eclipse codestyle.xml?
We updated the lucene ones during apache con - this should work though! On Tue, Nov 24, 2009 at 4:19 PM, Grant Ingersoll gsing...@apache.org wrote: Hmm, weird. They must have gotten lost when the ASF upgraded MoinMoin. They are the same as Lucene's: http://wiki.apache.org/lucene-java/HowToContribute On Nov 24, 2009, at 10:11 AM, Drew Farris wrote: Hi All, On the wiki, http://cwiki.apache.org/MAHOUT/howtocontribute.html, The link at the bottom of the page to the eclipse codestyle.xml for Mahout's coding conventions seems to be broken. Does anyone have a codestyle.xml for eclipse available? Thanks, Drew
Re: eclipse codestyle.xml?
Actually, the Mahout wiki links are out of date. I'll update. On Nov 24, 2009, at 10:19 AM, Grant Ingersoll wrote: Hmm, weird. They must have gotten lost when the ASF upgraded MoinMoin. They are the same as Lucene's: http://wiki.apache.org/lucene-java/HowToContribute On Nov 24, 2009, at 10:11 AM, Drew Farris wrote: Hi All, On the wiki, http://cwiki.apache.org/MAHOUT/howtocontribute.html, The link at the bottom of the page to the eclipse codestyle.xml for Mahout's coding conventions seems to be broken. Does anyone have a codestyle.xml for eclipse available? Thanks, Drew
Re: eclipse codestyle.xml?
Great -- this works now. Thanks! On Tue, Nov 24, 2009 at 10:20 AM, Grant Ingersoll gsing...@apache.org wrote: Actually, the Mahout wiki links are out of date. I'll update.
