How to discard a local dependency in a maven project? - java

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

Related

How to properly bring a java library from github to replace dependency in maven project

So I have worked with git my fair share, but only with one project at a time. I have a project (call it projectA) that currently uses maven to bring in a java library (call it libraryB) that is used in projectA as a dependency. I have made some code to do something that libraryB couldn't do before (for example, it has a database connector class and I made a version that supports security). I want to commit the relevant code up to libraryB, but I don't know the best way to go about doing so. Also, projectA just has the maven dependency of libraryB currently, so it is unmodifiable. So I want to replace the unmodifiable libraryB dependency with my github fork of libraryB, put my classes and changes into it, and then do a pull request into master of libraryB on git.
Sorry if that is at all confusing with how I worded it, but any help would be appreciated.
Thanks!
Tsolakp's answer is what you want in the long run.
If library B is discontinued or has a long release cycle(meaning you could be a long time waiting for a new release):
After you've made changes to B, mvn install (or equivalent) into your local repo.
Then change the version of B referred to in A to the version you installed.
Note that, if you push A's changes this will require everyone working on A to first install B, including CI servers.
Here is the proper way to get projectA using your changes to libraryB.
1) Make pull request of your changes to libraryB.
2) Get approved and have your changes merged into libraryB.
3) Have libraryB build and deployed to remote Maven repository with newer jar version.
4) Update your libraryB jar dependency in your pom to the newer version and do a new maven build.
All of above assume that libraryB gets deployed to the remote Maven repository that is configured in your settings.xml. If it is deployed to central Maven repository then you should automatically get the newer version.

Dependencies between github projects that compile via maven

Looking for the best option, or a solution I am unaware of:
(probably unnecessary context) I developed "project A", a 1990's RPG video game ported to Java. Currently starting on "project B", a server to co-ordinate project A to run as a MMORPG.
Project A, lives in gitHub, compiles in maven and has no dependencies on project B.
Project B, (will) live in gitHub, has dependencies on "project A", and aspires to compile in maven
I would like both to sit in separate github repositories
I would like project B's pom.xml to specify the version of 'project A' needed.
No preference if this is achieved via specifying a git branch/version or maven artifactId/version.
I would like running maven for project B to find either:
(if available) Project A's last local build of specified version.
(fallback) Projects A's latest version on gitHub
I would prefer not to host project A Jars in some url (or git repo from project A, or B), as they will become large due to graphics. Also that type of thing rubs me the wrong way.
I would like "project B" to "just work" via a 'git clone ...', followed by a 'mvn package'.
There seems to be a multitude of approaches:
via 3rd party: eg jitpack
via maven reactor / modules (with what appear to be several sub approaches)
running 'mvn install' from project A
nexus, artifactory
via git submodules
I would like both to sit in separate github repositories
that's trivial
I would like project B's pom.xml to specify the version of 'project A' needed.
you can use version to distinguish your jars
I would like running maven for project B to find either:
(if available) Project A's last local build of specified version.
(fallback) Projects A's latest version on gitHub
that's maven by design
I would prefer not to host project A Jars in some url (or git repo from project A, or B), as they will become large due to graphics. Also that type of thing rubs me the wrong way.
have you consider to separate resources from core? ie put them in separate project given that they least likely to change
now solution, in my opionion what you need is remote maven repository (by remote i mean opposite to local which will be accessable whenever you want to work on your project. personally i would recommend nexus, but i might be biased here, given that i have most experience with it.
other solution might be maven repository on github. never tried it, but it looks ok
You can
check out both projects on your computer, build project A with version x.y.z and then build B against A with that version. This works through the local Maven repository on your computer.
put both B and A into a multi-module project so that you can build everything at once. This means that both projects have to be in subdirectories of some parent directory.
Use your own Nexus/Artifactory. Then you can mvn deploy B in a version to this repository and resolve it in A through the same one. Works more or less like the local repository, but is much more convenient to use and search in.

Maven: packaging & module dependencies

I have a maven project that consists of a couple of modules. The main structure and setup is this:
/project/pom.xml: packaging=pom, lists all sub-modules, version: TRUNK-SNAPSHOT
/project/core-module/pom.xml: packaging=jar
/project/war-module/pom.xml: packaging=war, depends on core-module with ${project.version}
I use IntelliJ for development if that somehow matters.
When I now develop/run/debug the war-module and meanwhile I change code in the core-module things get out of hand. The running war-module application (running via jetty:run-exploded) uses the core-module which is "installed" in my local ~/.m2/ repository instead of the current build. It doesen't matter if I do a "rebuild project" in IntelliJ or a mvn clean before running.
My question is: do I have to mvn install each time, can I circumvent the installed packages or do I have to change packaging options?
Making a long story short, the answer is: YES, in a multi-module project you have to run mvn install every time so the dependencies of your war-module get compiled and installed in your local repository.
However, for local testing I usually recommend to make use of the IDE features to test our local changes. With IntelliJ is really easy to configure and it supports a lot of different application servers.
The reason for this is: Imagine working on a large team, using an enterprise shared repository to hold your common dependencies without the need to publish them to Maven central. If any of your colleagues has made changes to core-module, committed them and make them available through your internal shared repo then Maven will download that dependency and then use to run the Jetty plugin.
The good side of this is that you'll be testing with last version of those dependencies, the bad side of it is that the code of those dependencies is not the same as the one in your working copy.

Maven m2eclipse detect changes in dependecy in workspace and automatically install

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.

Adding custom maven project as dependency

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

Categories

Resources