I found an annoying issue working with m2eclipse in Eclipse.
My workspace contains 2 projects, an application A and a library B. The application A POM has B as a dependency and everything works correctly. (The project dependecy is found and used when I build the application)
But if I change some code in project B and I forgot to mvn:install it, when I build the application it uses the last built version of the library and it loses my last changes.
Is there a way to force Maven / M2Eclipse to check if the source code of the dependecy is newer than the last version built, and to install it when installing/ deploying the main application?
Or maybe my approach is wrong or is something obvious that I'm missing?
You can tell m2eclipse to use resolve dependencies from the workspace rather than through the normal mechanisms. In your project properties (NOT workspace properties), select Maven->Resolve dependencies from Workspace projects.
This will mean that when you change B and subsequently build A, the changes should be picked up automatically.
If, however, you build outside Eclipse, you'll have to do the normal mvn install to get the correct dependencies.
I don't know of a way to tell maven to build the library first, then build your project. You could put two maven commands into a script and run the script.
Alternatively, you could put both projects inside a maven parent project, and then build the parent. This causes all child project to be built too (so in your case the library, and the application).
I think you have couple of options here
If you can change the maven project set up, I would suggest you to use maven multimodule
Option two might solve your problem but still involves a manual stop when you change your dependent project B, Do this on for your dependent project in eclipse
Select Library B ==> Properties ==> Maven ==> in the input box under Goals to invoke after project clean: ==> enter : install
To deploy any change that you made to Project B in eclipse to maven local/remote repo, You have to run Clean build in eclipse, This will deploy the latest Library B to the maven repository
Also make sure your Library B version is a SnapShot during the development
If you are looking to run the latest snapshots on your local machine you should try to set things up to launch directly from Eclipse.
Apart from avoiding the problem you originally posted about, it also has other advantages.
It will save you a lot of time by not having to perform intermediate build steps.
You can start and stop servers without having to leave your IDE.
The Eclipse console has extra features that you don't get from the system console.
You don't have to modify your start scripts to attach a debugger.
Related
I have a question about the integration the eclipse and maven.
I have a project A with dependencies in project B which is itself just a container for a bunch of projects B-i.
Project B is imported in Eclipse but most of the B-i are not imported in eclipse. Sometimes, I want to work on a patch in B-n. So I import the B-n project and dependency resolving usually works well, that is, project A uses the project B-n and recompiles.
Problem happens often when I want to discard the local dependency, close the local project, and make sure that the remote B-n from our repository is used by A (let's say that the other team patched project B).
What is the good and proper "way" to do that kind of patching/ensure that A is using the remote/server version of B-n and not the previously compiled local jar ?
Removing the local project ? Removing the dependency in the local project ? Will I always have to "clean install" project A when I do such a change ?
Thanks.
If I understand you correctly, you do the following:
You have a project B-n with a version (say 1.0.0-SNAPSHOT). It is built on some kind of build server.
Then you check it out, built it locally (still with version 1.0.0-SNAPSHOT). Now you want to discard your locally built version and refer again to the 1.0.0-SNAPSHOT from the repository (correct me if you did not understand you correctly).
For that, you can purge the local repository by dependency:purge-local-repository. You can start this from Eclipse through "Run As -> Maven Build...". See also
https://maven.apache.org/plugins/maven-dependency-plugin/examples/purging-local-repository.html
For a Maven-driven project in IntelliJ 2018, when should I choose to use…
The IntelliJ 2018.1 menu item Build > Rebuild Project
The Maven panel’s clean and install Lifecycle items
Under what circumstances is either appropriate?
My situation is a Vaadin 8 application using the vaadin-archetype-application-multimodule Vaadin archetype.
The Question, Does IntelliJ Build > Rebuild Project invoke maven? has a single Answer that says the Rebuild Project does not invoke Maven at all. But no guidance is given on when to use route versus the other.
Well, if you make substancial changes within a pom.xml file (new plugins, new modules within a multi-module project), you'd better run "mvn clean install". I personally never use the "Rebuild Project" within a Maven project. usually I just "make" the project so the class files are updated, or I start a real Maven build to get new / updated dependencies.
The third important option (for me) is the "Reimport all Maven projects" option, which is quite useful if a pure Maven build runs fine, but IntelliJ still thinks that there is something wrong within your project.
When you have a multi-module Maven project and:
Start your tests and application programmatically by IntelliJ (Main.java):
You do not need to use Maven at all, no clean, no install, only Make. And Rebuild when the project gets screwed up.
Click Reimport when you change dependencies or someone deploys a new dependency snapshot to your repo.
If IntelliJ refuses to download the snapshot, then try mvn clean install.
And why would you even do all that? It is faster and more user friendly.
Start your tests and application by Maven in IntelliJ (mvn jetty:run):
You have to install your modules which are as dependencies for the module on which you start your application (mvn jetty:run), because Maven does not use your compiled output for dependencies, but takes an artifact from your remote/local repository. For this case Make/Rebuild is useless, you have to use mvn (clean) install.
If you have made changes only in a module on which you run mvn jetty:run then you do not need to use package/install, but sometimes you have to use clean or Rebuild as Maven does not remove deleted resources.
Make is good for hot-swap - for that reason, it is a good idea to import all Maven projects you develop and on which you depend into a single IntelliJ project. Initial Rebuild comes handy, because without it, Make would compile the whole project instead of only changed classes, then possibly failing hot-swap or it would just take too long.
Or you could just click Make before you run your application, but it could leave some old resources created by Maven in compiled output, Rebuild would take care of that.
You can also configure your app-server to restart/reload when it detects updated files from Make or Rebuild - certainly faster than restarting the JVM or compiling by Maven, but you might like to disable that and use only hot-swap, which is still way faster if you do small changes.
Either way you might want to take a look at Maven Helper plugin for IntelliJ, it will make things way easier in big projects.
Since I'm having performance issues while building a workspace with lots of maven-projects I wonder if it is possible to deactivate the Maven Project Builder.
If I understand that right, the Maven Project Builder does not compile anything. Instead it refreshes the project-config from the POMs. I believe this is exactly what happens if I run "Maven -> update Project". If that is true I could deaktivate the Project Builder... Does anybody know if this is right?
You need to track all your library dependencies from .m2 folder, so you can restore them easily, and check if there are some scripts in pom.xml that run on build, test, or deployment and see if you can reproduce them without Maven.
In addition you should check if there are other project in your system that depends on your project and vice versa via Maven.
I'm using eclipse with the m2eclipse plugin now I just want to resolve a - imho - easy problem: I've got two maven projects, I want to add project A as dependency to project B.
Well how do I achieve this in a manner way? If I add the project A to the build path of project B eclipse recognizes the classes but this project isn't resolved by eclipse on build time.
I got it working by installing project A to my local repo and adding this as dependency to my pom. This works but is cumbersome because I always have to install a new version of project A when something changed.
Shouldn't the plugin handle such a situation for me?
Providing that you have both maven projects open in your workbench then make sure you have the "Enable Workspace Resolution" option enabled in the Maven context menu.
Yes Eclipse handle this situations.
You can add both the Projects A and B in the same work-space.
I could help you creating a simple work-space from the scratch.
I am assuming that you have already installed the MAVEN plugin M2Eclipse for Eclipse.
Start a new Eclipse in a blank Work-space
Right click on Project Explorer --> Go to Import dialog and add a Maven Module.
Locate the POM directory and add that directory.
It will list all the projects in all the sub folders.
Add as many as Maven Based modules in a single work-space.
By doing this you dont need to install the dependencies. Any change will be reflected on the derived module.
Hope that will help you.
The way you did it is correct, because it assumes that project B will be using the dependency of project A that will be in the artifactory, so you can develop both independently.
And anyway, for the project A, if you are using maven, don't you use maven clean install for compiling and deploying? That way you are sure you always have the latest version
The other option is, in case both of the are more dependent of each other, you should consider make one of them as a module of the other, or maybe make a project C that contains both modules, but that would mean both of them are part of the same project (like an ear containing two jars), depends on the situation
Right now, I have two Eclipse projects - they both use Maven 2 for all their jar-dependency goodness.
Inside Eclipse, I have project Foo included in project Bar's build path, so that I can use Foo's classes from project Bar. This works really well in Eclipse land, but when I try:
mvn compile
inside Bar's directory, it fails because Maven doesn't know about the project-to-project relationship in Eclipse's build path.
If I were using Ant, I would just use it to do something silly like copy foo.jar into project Bar's classpath, but as far as I can tell, things are done a lot less hackishly in Maven-land.
I'm wondering if there's a standard workaround for this type of problem - it seems like it would be fairly common, and I'm just missing something basic about how Maven works.
Maybe you are referencing the other project via Eclipse configure-> build path only. This works as long as you use Eclipse to build your project.
Try running first mvn install in project Bar (in order to put Bar in your Maven repository), and then add the dependency to Foo's pom.xml.
That should work!.
Check out the m2eclipse plugin. It will automatically and dynamically update the project build path when you change the pom. There is no need for running mvn eclipse:eclipse.
The plugin will also detect if any dependency is in the same workspace and add that project to the build path.
Ideally, if you use m2eclipse, you would never change the project build path manually. You would always edit pom.xml instead, which is the proper way to do it.
As has been previously stated, Maven will not know about the Eclipse project build path. You do need to add all dependencies to the pom, and you need to make sure all dependencies are built and installed first by running mvn install.
If you want to build both projects with a single command then you might find project aggregation interesting.
I just needed to do this and I needed it to build with the external mvn clean install command. Here is the proper way to configure this in Eclipse. (With project B as a dependency of A)
Open the pom.xml for project A in Eclipse.
Go to the Dependencies tab.
Click the Add... button in the middle of the page (for the left side Dependencies box)
In the popup, there should be a box under a line with text above it saying Enter groupId, artifactId or sha1 prefix or pattern (*):. Enter the artifact ID for project B into this box.
Double click the jar you want to add as a dependency to this project
You may need to update the project after.
Right click project A in you Package explorer
Maven -> Update Project...
Then hit OK in the popup.
You might want to try an alternative approach, where you have a parent maven project and two children project. let's say:
Parent (pom.xml has references to both children projects/modules)
--> A (depends on B)
--> B
then when you run mvn eclipse:eclipse from the root of Parent, maven will generate eclipse projects for A and B, and it will have B as a required project in the classpath of A.
You can run mvn install from the root of Parent to get both projects to compile.
To complete your setup, you'll have to import both A and B into Eclipse, making sure you don't check "Copy projects into workspace".
I think the best way to handle it is to make Bar a Maven project just like Foo, and then mvn install it so it is available in your local Maven repository. The drawback is that you have to install that project every time you want Maven to see the changes you make to Bar.
Not a complete answer:
Bar's pom needs to include Foo in order to use maven to compile it.
I'm interested in this question too, but from the perspective of how to get eclipse to recognise a maven-added dependency is actually another project in the same workspace. I currently alter the build path after performing mvn eclipse:eclipse
If you reference a local project, but its version has been updated (usually increased), it could maybe only be found in your local repo and you have to update the (likely fixed) version of it in your POM(s).
We have a "common project" (used everywhere) which does not necessarily need to be versioned since we tag it via source control. so either
keeping it at a fixed version or
referencing it with the special LATEST version
are good workarounds to always be on the safe side.