I think I was just hung up on the same problem, but I want to clarify to make sure. When you say that eclipse:eclipse requires you to install before generating the .project and .classpath files, you mean before generating the *correct* .project and .classpath files, right? That's what's been driving me crazy - I run mvn eclipse:clean eclipse:eclipse on the root pom of a multi-module project for which artifacts do already exist in the local repository and suddenly all of the project references between modules are gone, and every dependency is resolved using the local repository. If I run mvn eclipse:clean install eclipse:eclipse, the project references are fixed.

Are we talking about the same thing, then? Either way, this behavior is not intuitive to me.

-Matt

On Mar 29, 2006, at 8:12 PM, Gordon Henriksen wrote:

Hi everyone,

Bit of a problem. There's a workaround, but the workaround is precisely the problem. Here goes…

mvn eclipse:eclipse requires that I install my local projects before it will generate the .project and .classpath files for Eclipse. This makes total sense for external dependencies; the .classpath needs to reference an .jar file somewhere, so putting them in ~/.m2/repository makes a lot of sense. Fine and dandy. But for a project like such:

    my-root-project/ { packaging: pom }
       my-lib/ { packaging: jar }
       my-webapp/ { packaging: war, dependencies: { my-lib } }

When I run mvn eclipse:eclipse, the Eclipse .classpath file references the adjacent my-lib project, not my-lib that resides in the ~/.m2/repository. Therefore, the install doesn't seem as if it should be necessary for the local projects. Yet the Eclipse plugin insists upon it. Further, it is damaging to our workflow, since we have to make sure our code compiles before we can add a dependency to pom.xml and successfully push those to Eclipse. Besides that, forcing the install of a project before we can even get our IDE set up seems very backwards; by definition, the projects in question are under development, so publishing them to even the per-user repository is premature.

In fact, since I prefer not to have the possibility of out-of- sync .classpath and .project files, I've prohibited checking these files in. So our checkout directions look like this:

    mkdir my-enterprise
    cd my-enterprise
    svn co svn+ssh://my.host/my-enterprise/trunk .
    mvn install  # <-- !!!!
    mvn eclipse:eclipse

Is there a reason this is the case? Or should I file an RFE and look into making a patch?

Other Eclipse+Maven users:
Should I allow checkin of .classpath and .project, even at the risk of them falling out of sync with pom.xml? Does it sound like I'm missing the zen of making these tools cooperate?

— G


---------------------------------------------------------------------
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]

Reply via email to