Hi, I've noticed we have overlapping layers of project configuration, goals (in the general, non-Maven sense of goals), and tool use between Eclipse and Maven. Probably true of any of the "new generation" of IDEs.
I began noticing this a lot today because I am restructuring and componentizing a large project as part of a SCM switch (StarTeam to ClearCase). I was generating skeleton Eclipse .project and .classpath files with Maven for each of our sub-projects (components). Regardless of using Maven to generate the Eclipse project files, there are a few things we want to do to all the Eclipse projects (which we check in and share), which are realized through Eclipse settings in .project and .classpath, e.g.: - One (or both) of the Eclipse Checkstyle plugins adds itself to your .project file as a <buildCommand> - You maintain dependencies between related Eclipse projects by exporting libraries and paths, which add <classpathentry> elements to .classpath If you have a software project corresponding to a single commercial product made up of several small components (each one a project in Eclipse for various reasons) and several small teams of developers sharing .project and .classpath files in source control for each project . . . if someone changes something in their Eclipse build path configuration for their component project, like adding a jar to their build path or a new source directory or removing one of the above, the change may need to be propagated through the network of Eclipse projects, resulting in edits to all the files, checking them in, and re-importing the projects or re-starting Eclipse. There's a whole layer of moderate, not extreme, complexity of configuration to maintain in the Eclipse project configurations! So, one lesson is that any ability to generate Eclipse project files from a project.xml is just to get you started, as advertised. The other main layer is the Maven layer; the build layer. Here there are many of the same things like jars, source and classes dirs, nicely represented by the POM, which must be configured and then maintained across all the same components. What this leads me to think is that the functionality of Maven and Maven's POM concept ought to be unified with the way IDEs do things (Eclipse first, of course). I think the POM should or could become the basis for a JSR (or something like that) on Java project and build management. Much of the same information and functionality I want from Maven I also want from my IDE. The difference is more in the outputs derived from the POM: developers want the outputs displayed in the IDE and on our desktops; management wants Web-based reports and installers/CDs. These are some of the things that we are currently using the IDE and Maven (and previously Ant) to do, either during development or during the automated build: - compile - assemble and jar - run unit tests and present results - coverage analysis (Clover) - code convention checking (Checkstyle) - source metrics (JavaNCSS) - dependency analysis (Pasta or JDepend) - generate Javadoc - deploying components In development, I do all this in Eclipse with plugins and standard Eclipse functionality. With the builds, I do it all with Maven and Ant. But I'm feeling like I'm maintaining a lot of the same information in two places! Doesn't this seem to be where things need to go somehow? Maybe one of those standard IDE JSRs is a good place to start. Are any Mavenites on any good JSRs or other standards efforts related to Maven? Thank you, Scott Stirling Framingham, MA --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
