I have a maven project in Eclipse with a bunch of local project dependencies.
Building with the Maven assembly plugin or shade plugin is a pain because I first have to build and install all of the local project dependencies before I can build my main project.
Does m2e provide a way to script a sequence of arbitrary maven commands? I know I can script everything from the command line, I just don't know where m2e's instance of maven is installed, and I'd like to avoid installing a separate instance.
Have you considered creating a multi-module Maven project that "contains" the dependencies? That would allow you to build just the container and Maven automatically takes care of building the component modules. Eclipse's m2e supports multi-module builds so there wouldn't be anything special to do for Eclipse.
Related
There appears to be an Eclipse plugin for Gradle, but no Gradle plugin for Eclipse...
Simply, I'd like to add a build.gradle to my Eclipse project, write its contents (including defining its dependencies), and then run it from inside Eclipse, the same way I can run Ant scripts from inside Eclipse.
When it runs, I'd expect the plugin to pull down all dependencies and make them available to my project's classpath in Eclipse.
If no such plugin exists, then I ask: what's the best way to develop in Eclipse, but keep your builds managed by Gradle? If I decide I need a new xyz.jar as a dependency for my code, how do I add it as a dependency in such a way that both Gradle and Eclipse will recognize it (and not throw compiler errors)?
Either use the IDE project generation approach (gradle eclipse), or use the Eclipse Gradle Integration. In both cases, you'll want to apply plugin: "eclipse".
The Gradle plugin for Eclipse is part of the Spring IDE. It understands the dependencies specified in the build script and makes those available in the .classpath.
What is the difference between running a maven build on a maven project
mvn install
then importing the module in eclipse (Import > Existing Maven Projects) as a maven artifact versus running
mvn install eclipse:eclipse
and importing the maven project as a regular project (Import > Existing Projects into Workspace)?
The second option seems faster within eclipse (mvn install eclipse:eclipse) but I'm not sure why.
When you import an existing Maven project, it is done by m2e, the official Eclipse Maven plugin (when I say official I mean it is in the Eclipse incubation process). It offers more features and can be more convenient to use in my experience
When you do it by eclipse:eclipse, it is done by a Maven Eclipse mojo which creates a simple Java project. The problem is that you have to re-do this again every time you change your pom.xml. With m2e, this is usually done automatically.
I made simple maven project and I opened it with Eclipse. I have installed maven plugin for Eclipse. I'm interested in following:
How Eclipse compiles code when I hit save on my source code (does it use configuration from ant or maven or something else)?
When I run tests from JUnit plugin for Eclipse those Eclipse calls mvn test (I suppose not, but what is then happening exactly)?
Is it possible that maven does the build successfully but Eclipse is
showing errors in code?
The Maven Integration for Eclipse makes it easier to edit POM files, allows you to execute maven builds from within Eclipse and to help with dependency management. It doesn't actually compile your code (unless of course you execute a maven build from within Eclipse). The main help is with the dependency management and writing the .classpath file of your project within Eclipse.
To try and answer your questions:
Eclipse uses its standard mechanism to compile code. With a standard eclipse for java developers your project will have a Java Project nature and Eclipse will then use the Java Development Tools - JDT to compile the code. (Internally this uses an incremental builder to build the code http://help.eclipse.org/juno/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2FresAdv_builders.htm). What source files it will compile and where it will place the resultant .class files is configured in your project's Java Build Path (which I am guessing the maven plugin may well configure for you)
JUnit support is part of the Java Development Tools as well.
It is possible that maven will successfully build a project outside of Eclipse, but that the same project will show errors within Eclipse. This is usually down to classpath errors (dependencies defined in the project's POM not being added to the classpath in Eclipse). If you are using the maven plugin with eclipse this probably shouldn't happen. If you are not using the maven plugin within eclipse you can execute maven eclipse:eclipse to have maven update the Eclipse .classpath file of the project which should then fix any of these problems.
I have a project that depends on a library that is only easily available through Maven (OpenIMAJ). I have set up a Maven 3 project in NetBeans 7, and can develop my code that way. I would like to integrate the build product from this Maven project into a larger NetBeans project that does not use Maven 3. What's the smoothest way to get the JAR output from the Maven build process into my Netbeans (non-Maven) project, with the proper dependencies in the classpath?
Build & install Maven-project to local Maven repository (Or deploy to shared repository)
In non-Maven-project, express a dependency on the JAR (?) built by Maven-project just like you would for any other JAR
Is there a way for my eclipse project to inherit the build classpath from existing Ant build.xml files? It would be nice if I didn't have to keep the eclipse project and the ant build in sync!
Off-hand, I'd say no, but see here http://www.ant4eclipse.org/node/6 for an attempt at doing the opposite (keeping the Ant build path in sync with Eclipse). Maybe that's of some use?
Another option would be is for both ant and eclipse to point to a common file specifying dependencies, independent from both ant and eclipse.
You can do this with ivy (http://ant.apache.org/ivy/), which has both tasks for ant and a eclipse ide plugin. ivy also solves the third-party library dependency management problem (you create a central repository of all third-party dependencies in your company which are pulled down as needed, rather than keeping .jar files with each project).
It takes a little time to create the initial ivy repository by copying libraries from maven, but is well worth it longer-term.