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.
Related
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 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!
I am upgrading a project from Ant to Gradle. The project uses a aqapi13.jar(this is oracle aq jar. This is needed as the project reads from an oracle-queue and writes to an activemq queue.)
The ant project contains the jar aqapi13.jar in the libs folder. But iam trying to get this dependency from a repository instead of having it in the libs folder.
However, iam not able to find a repository which contains this jar. All the repositories that I have seen contain aqapi13-9i.jar, but not aqapi13.jar.
Anyone knows the difference between aqapi13.jar and aqapi13-9i.jar and how to get the needed aqapi13.jar from a repository.
Advance Thanks
Some dependencies are never found in public repositories because of the license they have.
One way to use this dependencies is to create your own repository (e.g. artifactory, nexus, archiva). Then you are free to put in every artifact you want (as long as you do not publish the repository). This repository can also serve as a mirror for maven.
Another way could be to mark this dependency as system scope.
I am new to Hibernate 3 and I don't understand the difference between
1) *http://sourceforge.net/projects/hibernate/files/hibernate3/
and
2) *https://repository.jboss.org/nexus/content/groups/public/
when it comes to compiling Hibernate tutorial files.
I am following Hibernate tutorial from *http://docs.jboss.org/hibernate/core/3.6/quickstart/en-US/html_single/
As I understand there is no setup.exe for Hibernate 3. I assume that instead of having setup.exe I need to set classpaths to get my Hibernate 3 installed.
I have downloaded release of Hibernate from the list at *http://sourceforge.net/projects/hibernate/files/hibernate3/. It's more than 140 MB. After having unzipped this 140 MB file I didn't set any classpaths. I downloaded tutorial code from *http://docs.jboss.org/hibernate/core/3.6/quickstart/en-US/html_single/files/hibernate-tutorials.zip, unzipped it and edited pom.xml in this way that this tutorial would use two repositories like
1) *http://repo1.maven.org/maven2/
and
2) *https://repository.jboss.org/nexus/content/groups/public/
Then I typed mvn compile and build was succesful!
How is it possible that this build was succesful? I didn't set any classpaths which means that Hibernate 3 (that 140 MB file) was not included in my project's classpath. Moreover I don't understand what means to include in my project's classpath? Does it mean that under Windows XP I should set environment variables like:
1) path/to/hibernate3.jar
2) path/to/lib/required/
3) path/to/lib/jpa/
When I added these three paths to environment variables it didn't change anything - mvn compile worked the same way as before. Did I set this classpath in the wrong way?
In my point of view it seems to me that it is not necessary to download Hibernate 3 (140 MB) at all and all the files that were necessary to build this hibernate application (tutorial file) successfully were downloaded from repositories.
What do I misunderstand?
Thanks in advance!
You need to read up on how Maven works. There is an excellent free PDF called Better Builds with Maven that will explain it all in some detail, however here is a quick overview to help you along.
Maven is a build system
So it manages how to build your project. This comes from the configuration details you put in the pom.xml. You defined dependencies and Maven knows how to find them as a result either you configuring those locations, or Maven relying on it's own default locations. (This is where the http://repo1.maven.org/maven2/ is coming from).
Maven builds in defined phases, with each phase relying on the one before it. In order these are (simplified for easy presentation):
Clean - wipe out any previous compilation work (usually in "target") and start afresh
Copy resources - copy everything under src/main/resources to target/classes
Compile - compile everything under src/main/java to target/classes
Test - run the tests under src/test/java (using src/test/resources if required)
Package - build the target artifact (JAR, WAR, EAR etc)
Install - put the artifact into the local repository (to share with other local projects)
Deploy - put the artifact into the team repository (to share with everyone else)
From the above, it should be clear that specifying Hibernate3 as a dependency in your Maven pom.xml will instruct Maven to go off and look in your local repository for the necessary JAR files that make up Hibernate. If it can't find them there it'll look in the team repository (if mentioned in your .m2/settings.xml file). If not there then it'll download them from Maven central (http://repo1.maven.org/maven2/).
Maven uses the concept of transitive dependencies meaning that your project depends on Hibernate, but Hibernate depends on CGLIB which in turn depends on, say, ANTLR or something. You don't have to think about that, Maven takes care of bringing in all the relevant JARs you need to make your project work.
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.