My project is composed of n modules. One of these, let's say it is called my-first-module declares, amongst others, one dependency like:
<dependency org="com.mycompany.myproject" name="my-second-module" conf="default->default" rev="1.0-SNAPSHOT"/>
The artifacts are stored in an internal repository which is correctly working when retrieving jars.
For debug purpose i run:
ant -d | grep my-second-module
The output says:
sorting dependencies of com.mycompany.myproject#my-second-module / # of dependencies : 2
and that is correct, as the second module declares 2 external dependencies. I assume then ivy.xml for my-second-module is correctly fetched and parsed from the repository. Ivy then should know the dependencies of my-second-module
The problem is, ivy is not fetching those 2 transitive dependencies.
As you can see from the declaration I have specified I want to retrieve the default configuration, and it should be running transitive.
Impossible to diagnose anything without see how you've configured the projects.
The only advice I can offer is to generate an ivy dependency management report and take a look at the "default" configuration.
<target name="init" description="Resolve dependencies">
<ivy:resolve/>
<ivy:report todir="${build.dir}/ivy-report" graph="false"/>
..
..
</target>
Perhaps the transitive dependencies are being over-ridden by other resolved modules. For example it's possible for two modules to retrieve different revisions of the same module, in which case ivy will chose one and "evict" the other. Another possibility is a module declaring an exclusion, which would account for missing transitive dependencies.
Finally, let's be clear what you mean by "fetching".... Ivy will "resolve" dependencies, which means it will analyse each module and populate it's local cache with the various files. Ivy has a separate "retrieve" task for placing files into the local build workspace.
<ivy:retrieve pattern="${dist.dir}/WEB-INF/lib/[artifact].[ext]" conf="runtime"/>
So... This means when you run ivy, files may actually not be downloaded from the remote repository, because ivy already has them safely tucked away in it's cache. (normally located in $HOME/.ivy2/cache)
Related
I recently saw a project with quite a few sub-projects, each of them with a build.xml and an ivy.xml.
When building these sub-projects apparently all 3rd-party libraries declared as dependencies are copied to a /lib directory in each of the sub-projects. Coming from Maven this looks really strange.
Is this a limitation of Ant/Ivy not being able to build a classpath from the local ~/.ivy2/cache?
Or is it a lack of Ant/Ivy knowledge at those who created the respective xmls?
Or is there a good reason to do this exactly like this with Ant/Ivy?
Hard to comment without seeing the ANT build files, but your description would suggest that the ivy cachepath task is not being used.
Hopefully the following answers will help explain how ivy configurations (similar to Maven scopes) can be used to manage classpaths exactly like Maven:
Ivy, what is the master configuration and why is it not pulling jvyaml?
How to avoid copying dependencies with Ivy
I'm still struggling with figuring out how to integrate Apache Ivy into my somewhat complex Ant build.
If it matters, I'm using ATG Dynamo, which contributes most of the mess I'm trying to deal with.
The result of a build of a module is a "build" directory, with several subdirectories. I need to publish the entire contents of the "build" directory, along with a properties file (env/default.properties) that is not produced by the build, but one property in that file is needed when later retrieving this artifact, as it indicates the absolute path (relative to another property setting) where the contents of the "build" directory need to be installed.
The entire build will have several similarly structured modules. I'm pretty sure the target that does the "ivy:publish" can be defined in a "base" build script that all the module build scripts import.
I imagine the "ivy.xml" for each module would have a "publications" element that specifies the two (?) pieces that are being published, being the "build" directory and the "env/default.properties" file. I've never seen an example that publishes a directory, is that possible? If not, then I would guess that I'd have to specify more processing and detail in the "ivy:publish" target, such that I would first zip up the "build" directory and the "env/default.properties" file both into a zip file and publish that as the single artifact. Is this more likely?
It is quite new in Ivy, and it is not released yet, but there is a concept of "packaging" which can handle directories.
See the official documentation: http://ant.apache.org/ivy/history/trunk/concept.html#packaging
With this feature, Ivy can handle by itself the unzipping of a folder. On the publish part, you are on your own, you'll have to make a zip yourself. On the retrieve part, Ivy will unzip the folder in the cache. So you will still have to do some process to copy it at the proper place.
It has not been tested, but probably you can go even further by implementing a custom unpacking algorithm, which will do the unpacking at the proper place. You'll have to implement a class which extends org.apache.ivy.core.pack.ArchivePacking, and declare it in your ivysettings.xml, like this:
<ivysetting>
<classpath file="${ivy.settings.dir}/custom-packing.jar"/>
<typedef name="customPacking" classname="com.acme.ivy.CustomPacking" />
<customPacking />
</ivysettings>
And then in your ivy.xml, declare your artifact as packaged by your custom packaging name:
<ivy-module version="1.0">
...
<publications>
<artifact name="mydistrib" type="distrib" ext=".zip" packaging="my-custom-packaging" />
</publications>
</ivy-module>
I am working on an existing application that uses ivy to manage dependencies, and the source comes with ivy.xml and ivysettings.xml files. I am trying to add my own jar to the build. What would be the easiest way to do this?
I tried adding a dependency to ivy.xml and I am not sure how to configure the repository directories. Maybe there are easy ways to do this? Any quick and dirty way will do.
The filesystem resolver in conjunction with the chain resolver should help you, assuming that you can modify the ivysettings.xml that you just inherited.
You can store your jars locally on your machine under your Local Ivy cache or your Shared Ivy cache. I believe it's $HOME/.ivy2/local and $HOME/.ivy2/shared and its in the same format as the $HOME/.ivy2/cache directory. If you use <ivy:publish/> Ant task to push your local jars to your local repository, they'll be accessible to all of your projects.
However, I recommend biting the bullet and doing things ...what's the technical term? oh yeah... The correct way.
Go ahead and setup a project wide Ivy/Maven repository where you can fetch your local jars the same way you fetch your third party jars. This way, there is no difference between your local jars, and the third party jars you're using. No one has to think where a particular Jar is located or adjust their Ivy configuration to get one jar or another.
Download either Nexus or Artifactory. You can set these repositories up so that all the third-party jars and your local jars are available as if they're all stored in the same server. You can even add in other jar repositories that are not centrally located.
I recommend Loughran's book Ant in Action. It has an excellent chapter on using Ivy. You can also look at my ivy.dir to see how I configure Ivy, so it's easily accessible to all of our projects.
In project A's build file, there is a <path>;
In project B's build file, I want to execute a tool class in project A by <java> task.
The <java> task need to use that path in its "classpathref" property.
The <path> in project A's build file is quite complicated so that I don't want to copy it to project B's build file.
So is it possible to refer to a classpath defined in one build file from another build file?
Using the import or include ANT tasks is the way to do this.... however, these are both designed build multi-module builds. It's generally a really bad idea to couple two different projects in this manner....
I understand the motivation, classpath management is one of the most important and error-prone parts of a Java build. My recommendation is to adopt Apache ivy and let it manage your build's 3rd party dependencies.
Example:
The ivy cachepath task to create your ANT path, using dependency declarations.
<ivy:cachepath pathid="test.path">
<dependency org="org.slf4j" name="slf4j-simple" rev="1.6.4" conf="default"/>
<dependency org="junit" name="junit" rev="4.10" conf="default"/>
</ivy:cachepath>
The jars themselves can be locally stored or retrieved from the Maven Central repository
Ant allows to import a project file into another. You may check section 'Resolving files against the imported file' as this will be needed in most cases.
Are there any tools available that allow the cleanup of a ant script?
I especially need to remove unecessary jar files... The Ant script I have to clean has more than 500 entries and has grown uncrontrolled over time.
There's no automated way of cleaning up jar files. You can look at the various include statements in your Java code, but they merely mention classes to include and not the jar themselves. Even if you can determine that a particular class is served by jarA.jar, it could be that jarA.jar is dependent upon jarB.jar.
You can even start removing jar files one at a time to see what breaks your build. That can be somewhat automated, especially if you specify your classpath via fileset instead of each specific jar. However, what if you actually need a jar for runtime, and not for the build?
My suggestion is to use Ant with Ivy. Ivy gives you the same Maven jar dependency capabilities without converting your project to Maven.
Take a look at Ivy and see how it works with Ant. Then, if possible, ask your developers to determine exactly what jars they need and what versions of those jars they need. You will have to help them. You might have to go through the jars in your repository and attempt to figure out what versions of the jars are in your repository.
You don't have to worry about jars that other jars depend upon. Ivy will take care of that for you. What you simply need are the jars that your developers depend upon, and they should know because they're the ones who use the include statements in their programs to specify a particular dependency.
Once you've determined the primary jars (and revisions) you need, you can easily convert your build.xml files to take advantage of Ivy's jar dependency system. Once you've done that, you can remove all the jars from your source repository since Ant with Ivy will download the required ones from the Internet based Maven repository system.