Hi Scott, I think some duplication will inevitably exist. Different IDEs use different ways to represent the same things (and have grown accustomed to doing so) and many of those ways you simply have to live with (unless you are planning on convincing eclipse development team to switch to maven POMs instead of .classpath and .project :)). Eclipse user myself, what I think is missing is a decent maven plugin for eclipse (along the lines of ant plugin or building on top of the ant plugin) that could bring some of the maven't functionality to eclipse.
things like: 1. generating/updating project.xml from .classpath and .project would already be useful. 2. running maven's goals from eclipse runtime 3. as would the effort to keep the 2 in sync automatically, 4. an editor with outline for project.xml/project.properties would also be very handy. I have nothing against JSRs as long as they are useful (= were designed as a result of experience based on people using technology) and flexible (= it shouldn't take 1 year to change a standard). Personally, I think that it would be a lot faster to write a plugin and start making use of it (if it turns out to be useful people with a lot of free time can standardize it later). dima ----- Original Message ----- From: "Scott Stirling" <[EMAIL PROTECTED]> To: "'Maven Users List'" <[EMAIL PROTECTED]> Sent: Wednesday, June 04, 2003 12:10 PM Subject: Eclipse and Maven - layers overlapping > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
