I am working on a module (let's say A, version 1) that is available in my maven global repository. I have now modified the code inside this module and bumped the version up to version 2.
Now, the code for this module has not been committed and the global repository doesn't now about this new version. However, I have built the project and version 2 is available in my local .m2 folders.
I am now working on a new module (let's say B) that depends on module A, version 2. maven is not picking up this dependency on module A. And my code is not linking to classes in module A.
Any help would be much appreciated.
EDIT: I have performed a clean install of module A, and I can see the classes in the local repository.
Best,
Pulkit
Well, if you are using an IDE, which I presume you do (you are using maven), you could try to update the project configuration and update the dependencies. Also make sure you refer to the correct versions of your modules in your pom.xml file(s) . This is all presuming you have performed a clean install of your 'A version 2', of course. Good luck!
Related
The tile pretty much says it all.
I often deal with a project which depends on libraries A and B,
where A wants to pull in C version 1.0.0 and B wants to pull in C version 1.5.6.
Maven's default behavior seems to be that mvn package succeeds, including one or the other version of C on the classpath.
I would like to specify in my pom.xml that maven should refuse to build the project until one of the two C dependencies has been excluded.
Can this be done without first writing a new plugin?
The maven enforcer plugin should be able to check that, see Dependency Convergence here
The ultimate goal is to find out a way to functional test a library.
I have a parent project A with sub modules B,C and D.
Let us assume that the module C has a dependency on module B (B being the library) and is included as a maven dependency using the <dependency> tag.
I am just curious to know when I start up the application server say Tomcat would a jar for B (along with others) be created and then C uses this jar?
I tried to monitor my directories to see whether jars were being created every time the server was started up but that doesn't seem to be the case.
If B isn't used as a jar then it would not exactly be a FT since the ultimate goal is to be able to use B as a library in other projects as well. I feel like this shouldn't be a problem since the code itself does not change but I'd like to get some insight into the same and comments if any. Thank you !
I hope I get it right, because you seem to mix building, deploying and testing
Maven will only build the current pom. It will not build dependency libraries but expect to find them in the repository.
Only if module A is a multi-module build, then B, C and D will be built when you build A.
Starting a tomcat will not trigger any build.
For a functional test you would build, package and deploy and execute your tests against the full application.
I have three projects: A, B, C
and build.xml in ant that should compile them.
C depends on B that depends on A
So far I had all dependencies were in eclipse and I had a build.xml in ant with:
<eclipse.incrementalBuild project="A" kind="incremental"/>
<eclipse.incrementalBuild project="B" kind="incremental"/>
<eclipse.incrementalBuild project="C" kind="incremental"/>
Now, I have ivy.xml files - for example:
<ivy>
<ivy module="B"/>
<dependencies>
<dependency name="A">
</dependencies>
</ivy>
Now, all works great when I publish A, B, C in this order to a repository (I use sonatype nexus repository), since the repository is also used for resolving, so the process is:
1. resolve dependencies for A - no such
2. upload currently in workspace A as jar to repository
3. resolve dependencies for B - A is resolved as dependency
4. upload currently in workspace B as jar to repository
5. resolve dependenceies for C - B and A are resolved as dependencies
6. upload currently in workspace C as jar to repository
The way I see it publishing to nexus is for delivering the product
What I need is a simple build.xml to just compile my project - and so I don't want to publish all the time new version.
Instead I am looking for I way to use ivy to
1. compile A
2. and then compile B using already compiled A
2. and then compile C using already compiled B,A
I thought about using a local repository in the file system, in which stages 1-6 are made - producing local jars to be used - however, this is a bit cumbersome since:
1. my resolve will have to contain two resolvers - the file system preceding the nexus repo - which means that on a real publish, I will have to remember to delete the local jars
2. Sounds a bit too much work for something I believe may have a simpler solution.
In essence, I want to mimic eclipse's IVY plugin that can resolve dependencies in workspace and compile projects using other projects in the workspace - but I am looking for the best, most recommended way of doing this.
Thank you
You stated:
I have three projects: A, B, C and build.xml in ant that should
compile them.
That suggests that your project is in fact one large monolithic build.
Instead you need to emulate how Maven does its work. Each module needs to have its own build file and an ivy file that lists that module's dependencies. Each module publishes its own jar artifact into a repository (local or remote) making it accessible to other modules using ivy resolve operations.
The following examples give links to the ivy documentation on multi-module builds using ivy.
ivy simple shared repository
Ivy: Using dynamic revisions
It's not easy to break up a big project, I hope this helps.
I'm in the process of learning maven (and java packaging & distribution) with a new oss project I'm making as practice. Here's my situation, all java of course:
My main project is ProjectA, maven-based in a github repository. I have also created one utility project, maven-based, in github: ProjectB. ProjectA depends on a project I have heavily modified that originally was from a google-code ant-based repository, ProjectC.
So, how do I set up the build for ProjectA such that someone can download ProjectA.jar and use it without needing to install jars for ProjectB and ProjectC, and also how do I set up the build such that someone could check out ProjectA and run only 'mvn package' for a full compile?
(Additionally, what should I do with my modified version of ProjectC? include the class files directly into ProjectA, or fork the project into something that could then be used by as a maven dependency?)
I've been reading around, links such as this SO question and this SO question, but I'm unclear how those relate to my particular circumstance. So, any help would be appreciated. Thanks!
So, how do I set up the build for ProjectA such that someone can download ProjectA.jar and use it without needing to install jars for ProjectB and ProjectC
Assuming ProjectA is a JAR, you can create an executable JAR that bundles the dependencies with the Maven Assembly Plugin (and the predefined jar-with-dependencies descriptor) or with the Maven Shade Plugin.
how do I set up the build such that someone could check out ProjectA and run only 'mvn package' for a full compile?
You have to deploy the dependencies to a repository that can be read over HTTP and to declare this repository in your pom.xml. AFAIK, git-hub doesn't offer any facility for that. But any web hosting service with FTP access (or better, scp) should do the trick. If your project is open source, another option would be to use Sonatype's OSS Repository Hosting service.
Just in case, you might want to read this blog post but you won't learn much more things.
The easiest would still be to organize the 3 projects as a multi-modules maven project and to build all modules.
Additionally, what should I do with my modified version of ProjectC?
From a modularization point of view (assuming you found a solution for the above part about repository), it would certainly make sense to have it as a separate module, especially if there is an opportunity someone can use ProjectC outside your project.
You have to publish the code from the additional dependencies. Two options:
Use the maven-shade-plugin to create a maven artifact containing all the content of the B and C jars, and publish that under your own G/A/V coordinates.
Publish copies of B and C under your own G/A/V coordinates using the maven-deploy-plugin to your forge just as you will publish your own code. Different forges have different policies; but if you abide by the licenses of B and C you should be OK.
I've got a main project where module A depends on a a .jar file created by the build for module B. While I'm in development, I'm modifying B regularly, then building B to create the library, then building A to use these changes.
Is there a way to point module A's ivy file to the jar file my module B build creates? Given I'm iterating multiple times, I don't want to check module B's jar into ivy over and over. It's also annoying to have to copy the jar into module A's build directory structure after every module B build.
Actually, for me it's worse, as I have about 4 modules in something of a dependency tree (A->B->CD). If it were just A and B I'd probably just live with it, but I'm getting sick of copying jar files around after the submodule builds and thought if there was a way to override the ivy file dependency line to look locally then that'd make life a lot simpler.
Pointing the Ivy dependency at your locally built module isn't the way to solve this. Instead when you build module B publish it to your local Ivy repository. When you resolve your dependencies for module A it will pull down module B from your local repository.
From the Ivy docs on the local repository:
The local repository is particularly
useful when you want to do something
without being disturbed by anything
else happening in the environment.
This means that whenever ivy is able
to locate a module in this repository
it will be used, no matter of what is
available in others.
For instance, if you have a module
declaring a dependency on the module
foo in revision latest.integration,
then if a revision of foo is found in
the local repository, it will be used,
even if a more recent revision is
available in other repositories.
This may be disturbing for some of
you, but imagine you have to implement
a new feature on a project, and in
order to achieve that you need to
modify two modules: you add a new
method in module foo and exploit this
new method in module bar. Then if you
publish the module foo to your local
repository, you will be sure to get it
in your bar module, even if someone
else publish a new revision of foo in
the shared repository (this revision
not having the new method you are
currently adding).
But be careful, when you have finished
your development and publish it on the
shared you will have to clean your
local repository to benefit from new
versions published in the shared
repository.
Note also that modules found in the
local repository must be complete,
i.e. they must provide both a module
descriptor and the published
artifacts.
The Using Ivy in multiple projects environment documentation has an example publish-local Ant task that you might find useful.