Apache Ant & Ivy: wrong dependencies generated - ant

I'm writing a Java library for my project: I use Ivy for the dependencies management and the publishing of the JAR to my local repository.
When I update ivy.xml (i.e. to add a new external library), everything is OK: all artifacts are retrieved and used.
However, when I publish my library, the ivy-module xml generated by Ivy contains missing/wrong references (often to previous versions of the external libraries).
This is the target I have in my build.xml:
<target name="publish" depends="jar" description="Publish this project in the ivy repository">
<property name="revision" value="${version}" />
<ivy:publish artifactspattern="${jar.dir}/[artifact].[ext]" resolver="projects" pubrevision="${revision}" status="release" update="true" overwrite="true" />
<echo message="project ${ant.project.name} released with version ${revision}" />
</target>
And this is my ivy.xml:
<ivy-module version="2.0">
<info organisation="xyz" module="zyx"/>
<configurations defaultconfmapping="*->*,!javadoc,!sources" />
<dependencies>
<dependency org="ch.qos.logback" name="logback-classic" rev="0.9.28" />
<dependency org="commons-lang" name="commons-lang" rev="2.5"/>
<dependency org="commons-io" name="commons-io" rev="2.0"/>
<dependency org="org.simpleframework" name="simple-xml" rev="2.4.1">
<exclude module="stax"/>
<exclude module="stax-api"/>
</dependency>
<dependency name="AlmaUtils" rev="1.3.10"/>
<!-- Reflections -->
<dependency org="org.reflections" name="reflections" rev="0.9.5-RC2">
<exclude module="logback-classic"/>
</dependency>
<!-- Bouncycastle cryptography -->
<dependency org="org.bouncycastle" name="bcprov-ext-jdk16" rev="1.45"/>
<dependency org="jdom" name="jdom" rev="1.1">
<exclude module="xerces"/>
<exclude module="xalan"/>
</dependency>
<!-- Scripting -->
<dependency name="js-engine" rev="1.0"/>
<dependency org="rhino" name="js" rev="1.7R2"/>
<!-- JGA -->
<dependency name="jga" rev="0.8.1"/>
</dependencies>

Perhaps you should add the following target into your build.
<target name="clean-all" depends="clean" description="Purge ivy cache">
<ivy:cleancache/>
</target>
This will wipe the slate clean and ensure that your build is completely clean.
Ivy is basically an optimized downloader, however, sometimes it can make incorrect caching decisions when you upgrade the version of a complex tree of dependencies. Maven builds are also affected by this problem when the local repository is very large.

Related

Ant Ivy conf specific retrieve is failing on my published jar

Building with Ant Ivy, I'm trying to separate my jars into one configuration for 3rd party jars and another configuration for the jars I build and publish. ProjectA uses 3rd party jars and builds a jar that ProjectB depends on, but when I use Ant Ivy confs I can't get ProjectB to retrieve the ProjectA jar.
When I execute the ant script for ProjectB, it builds ProjectA fine. The ProjectA build publishes a jar to the local repository. ProjectB retrieves the necessary jars from the public repository with no problem, but when it tries to retrieve the ProjectA jar, it says UNRESOLVED DEPENDENCY: testproject#ProjectA;2.0.0: configuration not found in testproject#ProjectA;2.0.0: 'localjars'. It was required from testproject#ProjectB;2.0.0 localjars
If I remove all references to the 2nd configuration, localjars, and just use default for everything, it works fine. I really need to sort my jars into the different confs though.
I've successfully used a revision value passed from the ant script in place of "2.0.0" below and referenced with ${revision}, but the conf error is the same.
ProjectA ivy.xml (with a subset of dependencies for brevity):
<ivy-module version="2.0">
<info organisation="testproject" module="ProjectA" revision="2.0.0" status="release" publication="20160524124555"/>
<configurations>
<conf name="default" transitive="false" visibility="public"/>
<conf name="localjars" extends="default" visibility="public"/>
</configurations>
<publications>
<artifact name="projectA-jar-2.0.0" type="jar" conf="localjars" ext="jar"/>
</publications>
<dependencies>
<dependency org="commons-beanutils" name="commons-beanutils" rev="1.7.0" conf="default->master"/>
<dependency org="commons-collections" name="commons-collections" rev="3.1" conf="default->master"/>
</dependencies>
</ivy-module>
ProjectA build.xml publish target:
<target name="publish" depends="package"
description="--> compile test and publish this project in the local ivy repository">
<ivy:publish artifactspattern="${DEPLOY_DIR_LIB}/[artifact].[ext]"
resolver="local" pubrevision="2.0.0" status="release"
srcivypattern="${ivy.dep.file}" forcedeliver="true" overwrite="true" conf="localjars,default"/>
<echo message="project ${ant.project.name} released with version 2.0.0" />
</target>
ProjectB ivy.xml:
<ivy-module version="2.0">
<info organisation="testproject" module="ProjectB" revision="2.0.0" status="release" publication="20160524103113"/>
<configurations>
<conf name="default"/>
<conf name="localjars" extends="default"/>
</configurations>
<publications>
<artifact name="projectB-2.0.0" conf="localjars" type="jar" ext="jar"/>
</publications>
<dependencies>
<dependency org="testproject" name="ProjectA" rev="${revision}" transitive="true" conf="localjars->localjars; default->default"/>
</dependencies>
ProjectB Ant resolve target:
<target name="resolve" description="--> retrieve dependencies with ivy">
<ivy:retrieve pattern="${DEPLOY_DIR_LIB}/[artifact]-2.0.0.[ext]" revision="2.0.0" conf="localjars" />
</target>
Any idea what's wrong? Thanks!
Patrick
Not entirely certain why your configuration is not working. One thing I'd advise is not to disable transitive dependencies. You'll note I have a different approach in creating the "default" configuration in the working example below.
Example
Each project has its own local build and ivy file. Collaboration is via jars published to the "local" repository.
├── build.xml
├── ProjectA
│   ├── build.xml
│   ├── ivy.xml
│   └── src
│   └── Hello.txt
└── ProjectB
├── build.xml
├── ivy.xml
└── src
└── Hello.txt
build.xml
Master build file that builds all modules in the correct order, using the buildlist task.
Additionally I normally include an extra target for installing ivy.
<project name="main" default="publish" xmlns:ivy="antlib:org.apache.ivy.ant">
<available classname="org.apache.ivy.Main" property="ivy.installed"/>
<target name="install-ivy" unless="ivy.installed">
<mkdir dir="${user.home}/.ant/lib"/>
<get dest="${user.home}/.ant/lib/ivy.jar" src="http://search.maven.org/remotecontent?filepath=org/apache/ivy/ivy/2.4.0/ivy-2.4.0.jar"/>
<fail message="Ivy has been installed. Run the build again"/>
</target>
<target name="publish" depends="install-ivy">
<ivy:buildlist reference="build-path">
<fileset dir="." includes="*/build.xml"/>
</ivy:buildlist>
<subant target="publish" buildpathref="build-path"/>
</target>
<target name="clean">
<subant target="clean">
<fileset dir="." includes="*/build.xml"/>
</subant>
</target>
<target name="clean-all" depends="clean">
<ivy:cleancache/>
</target>
</project>
ProjectA/ivy.xml
The "master" configuration contains only artifacts. This naming convention mirrors the scopes used by Maven.
Note also how the "default" configuration extends both "master" and "runtime". This enables clients to pull down everything they will need.
<ivy-module version="2.0">
<info organisation="com.myspotontheweb" module="ProjectA"/>
<configurations>
<conf name="default" description="Master artifact and runtime dependencies" extends="master,runtime"/>
<conf name="master" description="Artifact published by this module"/>
<conf name="compile" description="Required to compile application"/>
<conf name="runtime" description="Additional run-time dependencies" extends="compile"/>
<conf name="test" description="Required for test only" extends="runtime"/>
</configurations>
<publications>
<artifact name="ProjectA" type="jar" ext="jar" conf="master"/>
</publications>
<dependencies>
<!-- compile dependencies -->
<dependency org="org.slf4j" name="slf4j-api" rev="1.7.5" conf="compile->default"/>
<!-- runtime dependencies -->
<dependency org="org.slf4j" name="slf4j-log4j12" rev="1.7.5" conf="runtime->default"/>
<!-- test dependencies -->
<dependency org="junit" name="junit" rev="4.11" conf="test->default"/>
</dependencies>
</ivy-module>
ProjectB/ivy.xml
Note how ProjectA is the only dependency and it maps the remote "default" configuration to the local "compile" configuration.
Another subtle issue is the use of the "latest.integration" dynamic revision. This means we don't need to hardcode the revision of ProjectA.
<ivy-module version="2.0">
<info organisation="com.myspotontheweb" module="ProjectB"/>
<configurations>
<conf name="default" description="Master artifact and runtime dependencies" extends="master,runtime"/>
<conf name="master" description="Artifact published by this module"/>
<conf name="compile" description="Required to compile application"/>
<conf name="runtime" description="Additional run-time dependencies" extends="compile"/>
<conf name="test" description="Required for test only" extends="runtime"/>
</configurations>
<publications>
<artifact name="ProjectB" type="jar" ext="jar" conf="master"/>
</publications>
<dependencies>
<dependency org="com.myspotontheweb" name="ProjectA" rev="latest.integration" conf="compile->default"/>
</dependencies>
</ivy-module>
ProjectA/build.xml
The revision to be published is set as a property, which can be overridden if necessary.
Note also how ivy configurations can be used to control classpaths within the build, using the cachepath task
<project name="ProjectA" default="build" xmlns:ivy="antlib:org.apache.ivy.ant">
<property name="build.dir" location="build"/>
<property name="pub.version" value="1.0"/>
<property name="pub.resolver" value="local"/>
<target name="resolve">
<ivy:resolve/>
<ivy:cachepath pathid="compile.path" conf="compile"/>
<ivy:cachepath pathid="test.path" conf="test"/>
</target>
<target name="build" depends="resolve">
<mkdir dir="${build.dir}"/>
<jar destfile="${build.dir}/${ant.project.name}.jar" basedir="src"/>
</target>
<target name="publish" depends="build">
<ivy:publish pubrevision="${pub.version}" resolver="${pub.resolver}" overwrite="true">
<artifacts pattern="${build.dir}/[artifact].[ext]"/>
</ivy:publish>
</target>
<target name="clean">
<delete dir="${build.dir}"/>
</target>
</project>
ProjectB/build.xml
Identical to the other project just having a different name attribute.
<project name="ProjectB" default="build" ....

Check for packages latest version in Ivy

We use Ivy for dependency management. In order to guarantee stability and traceability, we fix version numbers for all dependencies in our ivy files, plus we use transitive=false to avoid dependency trees to grow uncontrolled. The second has only the disadvantage that it may require a few tests to complete the ivy file.
Since we fix version numbers, we don't get updated about the existence of a later version of a package. What we don't want is to get the freshest version of a dependency at build time. What we want is to periodically check for available updates and later decide whether and which packages to update.
As an example, here are our Spring dependencies as of 01/14/2016
<dependency org="org.springframework" name="spring-core" rev="4.2.4.RELEASE" transitive="false" conf="runtime->*"/>
<dependency org="org.springframework" name="spring-aop" rev="4.2.4.RELEASE" transitive="false" conf="runtime->*"/>
<dependency org="org.springframework" name="spring-beans" rev="4.2.4.RELEASE" transitive="false" conf="runtime->*"/>
<dependency org="org.springframework" name="spring-context" rev="4.2.4.RELEASE" transitive="false" conf="runtime->*"/>
<dependency org="org.springframework" name="spring-context-support" rev="4.2.4.RELEASE" transitive="false" conf="runtime->*"/>
<dependency org="org.springframework" name="spring-expression" rev="4.2.4.RELEASE" transitive="false" conf="runtime->*"/>
<dependency org="org.springframework" name="spring-jdbc" rev="4.2.4.RELEASE" transitive="false" conf="runtime->*"/>
<dependency org="org.springframework" name="spring-orm" rev="4.2.4.RELEASE" transitive="false" conf="runtime->*"/>
<dependency org="org.springframework" name="spring-tx" rev="4.2.4.RELEASE" transitive="false" conf="runtime->*"/>
<dependency org="org.springframework" name="spring-web" rev="4.2.4.RELEASE" transitive="false" conf="runtime->*"/>
<dependency org="org.springframework" name="spring-webmvc" rev="4.2.4.RELEASE" transitive="false" conf="runtime->*"/>
<dependency org="org.springframework" name="spring-test" rev="4.2.4.RELEASE" transitive="false" conf="test->*"/>
<dependency org="org.springframework.plugin" name="spring-plugin-core" rev="1.2.0.RELEASE" transitive="false" conf="runtime->*"/>
<dependency org="org.springframework.plugin" name="spring-plugin-metadata" rev="1.2.0.RELEASE" transitive="false" conf="runtime->*"/>
<dependency org="org.springframework.batch" name="spring-batch-core" rev="3.0.6.RELEASE" transitive="false" conf="runtime->*"/>
<dependency org="org.springframework.batch" name="spring-batch-infrastructure" rev="3.0.6.RELEASE" transitive="false" conf="runtime->*"/>
But we have a lot more. So I am asking if there is a smarter way to check for possible updates for all packages (we now have 101 packages).
Ant's ivy:report won't show the availability of a later version. Manually checking 101 packages on Maven is boring.
We also have a local Artifactory installation, I'm saying that if it could prove useful for purpose.
Any idea? What I would like to see is a report with current and latest version numbers of packages in an Ivy file
I just found an ivy task checkdepsupdate designed to solve your problem:
<target name="resolve" description="Use ivy to resolve classpaths">
<ivy:resolve/>
<ivy:checkdepsupdate showTransitive="false" revisionToCheck="latest.release"/>
</target>
Taking the ivy file in my example below it prints the following report detailing, the latest releases for my 3rd party dependencies.
[ivy:checkdepsupdate] Dependencies updates available :
[ivy:checkdepsupdate] org.slf4j#slf4j-api 1.7.5 -> 1.7.13
[ivy:checkdepsupdate] org.slf4j#slf4j-log4j12 1.7.5 -> 1.7.13
[ivy:checkdepsupdate] junit#junit 4.11 -> 4.12
I think this might be what you are looking for.
Miscellaneous
At the risk of stating the obvious, by setting transitive=false you take upon yourself the job of managing the entire tree of dependencies. For simple projects that's fine but you're now discovering the downsides of this approach. Projects like Spring have deliberately split their deliverables into multiple jars to increase flexibility. It allows you to only download what you need and avoid the inclusion of one incredibly large monolithic spring jar.
I would recommend a couple of things to improve your ivy experience
Embrace ivy's management of transitive dependencies
Use dynamic revisions
Publish to a repository, in order to create a release record
Transitive dependencies and classpath management
In my ivy file I will generally only include the module that contains the class I'm using, letting ivy take care of the other dependencies. I also use ivy configurations to group dependencies by function. My end goal is to use configurations to populate a java classpath, so some of my dependencies are required at compile time, others at run-time, finally testing frequently requires jars that would never be shipped with the release.
Example ivy file:
<ivy-module version="2.0">
<info organisation="com.myspotontheweb" module="demo"/>
<configurations>
<conf name="compile" description="Required to compile application"/>
<conf name="runtime" description="Additional run-time dependencies" extends="compile"/>
<conf name="test" description="Required for test only" extends="runtime"/>
</configurations>
<dependencies>
<!-- compile dependencies -->
<dependency org="org.slf4j" name="slf4j-api" rev="1.7.5" conf="compile->default"/>
<!-- runtime dependencies -->
<dependency org="org.slf4j" name="slf4j-log4j12" rev="1.7.5" conf="runtime->default"/>
<!-- test dependencies -->
<dependency org="junit" name="junit" rev="4.11" conf="test->default"/>
</dependencies>
</ivy-module>
The SLFJ project is an excellent example of how one would use a standard programming API, but at runtime decide on a particular implementation based on the jars included on the classpath. In the above example I tell my build to use the log4j implementation jar at runtime, which will in turn pull down a compatible version of log4j and everything it depends on.
Finally, note how each configuration extends the other? This means that the test configuration will include the jars in both the compile and runtime configurations. Exactly what I'd need when running a unit test using junit.
This is my standard resolve task in ANT:
<target name="resolve" depends="install-ivy" description="Use ivy to resolve classpaths">
<ivy:resolve/>
<ivy:report todir='${build.dir}/ivy-reports' graph='false' xml='false'/>
<ivy:cachepath pathid="compile.path" conf="compile"/>
<ivy:cachepath pathid="test.path" conf="test"/>
</target>
The compile and test classpaths are now auto-populated and ready for use as references:
<target name="compile" depends="resolve" description="Compile code">
<mkdir dir="${build.dir}/classes"/>
<javac srcdir="${src.dir}" destdir="${build.dir}/classes" includeantruntime="false" debug="true" classpathref="compile.path"/>
</target>
<target name="test" depends="compile" description="Run unit tests">
<mkdir dir="${build.dir}/test-reports"/>
<junit printsummary="yes" haltonfailure="yes">
<classpath>
<path refid="test.path"/>
<pathelement path="${build.dir}/classes"/>
</classpath>
..
..
</junit>
</target>
And the resolve task has created a record of each classpath maintained by the build.
Dynamic revisions
When you publish to an ivy repository you can specify the release type. This allows ivy to automatically determine the latest published version of a particular release type. By default two types of release are supported:
integration
release
The former corresponds to the Maven concept of Snapshot releases. Built binaries under the control of another team within your organisation, but not ready for release yet. The latter is of course for binaries that are fully approved and released, ideal for 3rd party dependencies.
The following is an example showing the theorical use of the two dynamic revisions:
<dependencies>
<!-- compile dependencies -->
<dependency org="myorg" name="teamA" rev="latest.integration" conf="compile->default"/>
<dependency org="myorg" name="teamB" rev="latest.integration" conf="compile->default"/>
<dependency org="myorg" name="teamC" rev="latest.integration" conf="compile->default"/>
<dependency org="org.slf4j" name="slf4j-api" rev="latest.release" conf="compile->default"/>
<!-- runtime dependencies -->
<dependency org="org.slf4j" name="slf4j-log4j12" rev="latest.release" conf="runtime->default"/>
<!-- test dependencies -->
<dependency org="junit" name="junit" rev="latest.release" conf="test->default"/>
</dependencies>
So this would achieve your desire. Your build would automatically register new dependencies from 3rd party projects.
Publish to a repository, in order to create a release record
Time does not stand still nor does a project's dependency tree. Due to the high number of direct dependencies a modern Java program may have it can become very confusing to resolve the dependencies.
But.... How does one reproduce an older build? We might tag our source code, but how does one keep track of the dependencies at that point in time.
I decide to publish each release into a Maven repository:
how to publish 3rdparty artifacts with ivy and nexus
Here's a snippet
<target name="prepare" description="Generate POM">
<!-- Optional: Intermediate file containing resolved version numbers -->
<ivy:deliver deliverpattern="${build.dir}/ivy.xml" pubrevision="${publish.revision}" status="release"/>
<!-- Generate the Maven POM -->
<ivy:makepom ivyfile="${build.dir}/ivy.xml" pomfile="${build.dir}/donaldduck.pom"/>
</target>
<target name="publish" depends="init,prepare" description="Upload to Nexus">
<ivy:publish resolver="nexus-deploy" pubrevision="${publish.revision}" overwrite="true" publishivy="false" >
<artifacts pattern="${build.dir}/[artifact](-[classifier]).[ext]"/>
</ivy:publish>
</target>
Since I'm using Nexus I need to generate a Maven POM file for my module. Notice the use of the tasks deliver and makepom? The first will create a temp ivy file containing the resolved version numbers of each of my dependencies. This means the resultant POM file in Maven contains the real versions I used to build my code.
You could expand upon this idea and additionally publish the following alongside your released binary:
Javadocs jar
Source code jar
Ivy reports jar
Junit reports jar
etc
In my opinion the release repository should be the unchanging record for your release and important compliment to the source code repository. Indeed in a large corporate organisation, this kind of file based release record could outlive your source code repository technology (Clearcase -> Subversion -> Git -> ??).

Arquillian Weld-EE test setup with ant+ivy

I set up a project following the getting started guide. I have to use ivy. These are my dependencies:
<dependencies>
<dependency org="org.jboss.spec" name="jboss-javaee-all-6.0" rev="3.0.1.Final" conf="build->default" />
<dependency org="org.jboss.arquillian.junit" name="arquillian-junit-container" rev="1.0.3.Final" conf="test->default(*)" transitive="true"/>
<dependency org="org.jboss.arquillian.junit" name="arquillian-junit-core" rev="1.0.3.Final" conf="test->default(*)" transitive="true"/>
<dependency org="org.jboss.weld.arquillian.container" name="arquillian-weld-ee-embedded-1.1" rev="1.1.2.Final" conf="test->default(*)" />
<dependency org="org.jboss.weld" name="weld-core" rev="1.1.10.Final" conf="test->default(*)" />
<dependency org="org.slf4j" name="slf4j-log4j12" rev="1.6.4" conf="test->default(*)" />
</dependencies>
Problem: Although I map to "*", the deps are not resolved transitive. Do I have to add every single jar by hand, just because I am stuck with ivy? or am I missing something?
Clarification:
I use the mapping "myconf->default()" transitive="true".
I read this as follows: "take the default conf of the dependency and map it to "myconf". (): if the dependeny does not provide "default", use every conf it provides. and all this should be done transitive, meaning every sub-dependency will also be mapped.
But what I get is: just the jars specified, and a lot of CNFE when I run the test.
I read about arquillian-container poms that are referenced in maven projects and I am beginning to fear that there is no working "out of the box" dependency mapping mechanism for ivy and arquillian. I am happy Iif anyone can confirm this or provide a working (best: tested) dependency configuration that I can use. Thank you very much!
I'd recommend that your ivy file always declare a set of configurations. Configurations are the logical groupings of jars within your build.
The following example creates a configuration for the 3 classpaths used in a typical java build:
compile
runtime
test
(Note also the "extends" keyword)
<ivy-module version="2.0">
<info organisation="com.myspotontheweb" module="demo"/>
<configurations>
<conf name="compile" description="Required to compile application"/>
<conf name="runtime" description="Additional run-time dependencies" extends="compile"/>
<conf name="test" description="Required for test only" extends="runtime"/>
</configurations>
<dependencies>
<!-- compile dependencies -->
<dependency org="org.jboss.spec" name="jboss-javaee-all-6.0" rev="3.0.1.Final" conf="compile->default" />
<!-- test dependencies -->
<dependency org="org.jboss.arquillian.junit" name="arquillian-junit-container" rev="1.0.3.Final" conf="test->default"/>
<dependency org="org.jboss.arquillian.junit" name="arquillian-junit-core" rev="1.0.3.Final" conf="test->default"/>
<dependency org="org.jboss.weld.arquillian.container" name="arquillian-weld-ee-embedded-1.1" rev="1.1.2.Final" conf="test->default" />
<dependency org="org.jboss.weld" name="weld-core" rev="1.1.10.Final" conf="test->default" />
<dependency org="org.slf4j" name="slf4j-log4j12" rev="1.6.4" conf="test->default" />
</dependencies>
</ivy-module>
The configuration mappings will then map the local configuration to the remote one, as follows:
conf="compile->default"
The remote "default" configuration is normally all you need and will include the remote module's compilation dependencies. For a more detailed explanation of how Maven modules are translated I suggest reading the following answer:
How are maven scopes mapped to ivy configurations by ivy
Finally, your build file can use these configurations to create populated ANT classpaths:
<target name="init" description="Use ivy to resolve classpaths">
<ivy:resolve/>
<ivy:report todir='build/ivy' graph='false' xml='false'/>
<ivy:cachepath pathid="compile.path" conf="compile"/>
<ivy:cachepath pathid="runtime.path" conf="runtime"/>
<ivy:cachepath pathid="test.path" conf="test"/>
</target>
The "report" task is especially useful to document the versions of each jar on the classpath.

Apache ivy. JbossAS, dependencies and some basic questions on ivy

I'm totally new in ivy, so don't blame for for rather elementary questions.
I'm working on project that depends on some libraries of jbossAS 4.0.3.
To tell exactly - there are jboss-4.0.3-scheduler, jboss-4.0.3-jboss-system, jboss-4.0.3-jboss, jboss-4.0.3-jbossall-client. So i have a logical question - how can I point ivy to find them on public repository? Or that's the wrong direction of leveraging ivy in this situation?
And another simple question - for example, in the past this project depended on castor-0.9.7, axis-1.3 and log4j - after ivy dependency resolution - I had a lot of other jars like activation-1.1.jar, axis-saaj-1.3.jar, mail-1.4.jar and so on. So it was only 3 jars in dependencies in the past - now I have 10. Do i really need them?
And what is the way to know for sure what do i need of this additional jars?? (after all the project was working with old config - 3 jars).
And what if I have some artifact(dependee project). Other project depends on it, but i don't want transitive dependencies to be resolved. That's only a question of interest ))
This is how i am pulling dependencies now (from local repo), and what i want - to pull them from public repo (if it is possible) :
<ivy-module version="2.2">
<info organisation="org.btl" module="BtlAppServer" revision="1.7"/>
<configurations defaultconfmapping="default">
<conf name="compile" visibility="private"/>
<conf name="test" extends="compile" visibility="private"/>
<conf name="master" />
<conf name="runtime" extends="compile" />
<conf name="default" extends="master,runtime"/>
</configurations>
<publications>
<artifact conf="master"/>
</publications>
<dependencies>
<dependencies>
<dependency org="jboss" name="jboss" rev="4.0.3" conf="*->default" />
<dependency org="jboss" name="jbossall-client" rev="4.0.3"
conf="*->default"/>
<dependency org="jboss" name="jboss-system" rev="4.0.3" conf="*->default"/>
<dependency org="jboss" name="scheduler-plugin" rev="4.0.3"
conf="*->default"/>
<dependency org="org.btl" name="BtlCommon" rev="latest.integration" />
</dependencies>
</ivy-module>
setttings file for this stuff :
<ivysettings>
<settings defaultResolver="myChain"/>
<include url="${ivy.default.settings.dir}/ivysettings-public.xml"/>
<include url="${ivy.default.settings.dir}/ivysettings-shared.xml"/>
<include url="${ivy.default.settings.dir}/ivysettings-local.xml"/>
<include url="${ivy.default.settings.dir}/ivysettings-main-chain.xml"/>
<include url="${ivy.default.settings.dir}/ivysettings-default-chain.xml"/>
<resolvers>
<chain name="myChain" returnFirst="true">
<resolver ref="local"/>
<!-- JBoss -->
<ibiblio name="jboss-nexus" m2compatible="true"
root="https://repository.jboss.org/nexus/content/groups/developer/"
pattern="[organisation]/[module]/[revision]/[artifact]-[revision](-
[classifier]).[ext]"/>
<ibiblio name="ibiblio" m2compatible="true" />
</chain>
</resolvers>
<modules>
<module organisation='org.btl' resolver='local' />
</modules>
</ivysettings>
File ivy.xml for the second question :
<ivy-module version="2.2">
<info organisation="org.btl" module="BtlCommon" revision="1.7"/>
<configurations defaultconfmapping="default">
<conf name="compile" visibility="private"/>
<conf name="test" extends="compile" visibility="private"/>
<conf name="master" />
<conf name="runtime" extends="compile" />
<conf name="default" extends="master,runtime"/>
</configurations>
<publications>
<!--get the artifact from our module name-->
<artifact conf="master"/>
</publications>
<dependencies>
<dependency org="axis" name="axis" rev="1.3" conf="*->default" />
<dependency org="castor" name="castor" rev="0.9.7" conf="*->default" />
<dependency org="log4j" name="log4j" rev="1.2.15" conf="*->default" >
<exclude org="com.sun.jdmk"/>
<exclude org="com.sun.jmx"/>
<exclude org="javax.jms"/>
</dependency>
</dependencies>
</ivy-module>
Don't know if that can help someway )
The extra jars are produced by transitive dependencies. These may not be needed to compile your project but needed at runtime.
If they are actually needed depends on the dependency itself and your usage of the library. Mail.jar(Java Mail API) for example is only needed if you need to send Mails.
I think it will be quite complicated to really make sure, that you won't need the extra libraries (in the future?). If you are sure now, that you program runs without them, you can just set the transitive attribute to the dependency. And they will not be downloaded.
<dependency org="axis" name="axis" rev="1.3" conf="*->default" transitive="false"/>
I found the Jboss dependencies in the java.net repository for revision="4.2.2.GA". Seems the best option. But I couldn't find the scheduler.
ivysettings.xml
<ibiblio name="jboss-java.net" m2compatible="true"
root="http://download.java.net/maven/2/"/>

Harsh Jarring with ivy

Does someone happens to know if there is a way to retrieve the contents of jar libs into one single jar - so that it would be
jar 1 :
org
smth
new.class
jar 2 :
org
smth
also.class
jar 3 :
org
another
otheralso.class
that single jar:
org
another
one.class
smth
two class
result jar :
org
another
one.class
otheralso.class
smth
two class
also.class
new.class
with ivy and ant ) i have a cachepath or cachefileset )
Need to combine ivy with the groovy plug-in.
build.xml
<target name="resolve">
<ivy:resolve/>
<ivy:cachepath pathid="build.path" conf="build"/>
<ivy:cachefileset setid="jarfiles" conf="jars"/>
</target>
<target name="combine-jars" depends="resolve">
<taskdef name="groovy" classname="org.codehaus.groovy.ant.Groovy" classpathref="build.path"/>
<!--
Iterate thru each file expanding content into a temp directory
used to create a new jar
-->
<groovy>
project.references.jarfiles.each {
ant.unzip(src: it, dest:"build/tmp")
}
ant.jar(destfile:"build/newjar.jar", basedir:"build/tmp")
</groovy>
</target>
ivy.xml
Use ivy configurations to separate downloads into build dependencies and a collection
of files to be later combined within the build.
<ivy-module version="2.0">
<info organisation="org.myspotontheweb" module="demo"/>
<configurations>
<conf name="build" description="ANT tasks"/>
<conf name="jars" description="Files to be combined"/>
</configurations>
<dependencies>
<!-- build dependencies -->
<dependency org="org.codehaus.groovy" name="groovy-all" rev="1.8.2" conf="build->default"/>
<!-- jars dependencies -->
<dependency org="log4j" name="log4j" rev="1.2.16" conf="jars->default"/>
<dependency org="commons-lang" name="commons-lang" rev="2.6" conf="jars->default"/>
..
..
</dependencies>
</ivy-module>
I actully came to this decision
<target name="project.archive" depends="project.make, ivy-runtimecahe">
<mkdir dir="${project.build}\temp" />
<copy todir="${project.build}\temp">
<archives>
<zips >
<restrict >
<path refid="classpath.Runtime" />
<name name="*.jar" />
</restrict>
</zips>
</archives>
</copy>
<jar jarfile="${project.build}\${project.archive.name}-${project.version}.jar"
manifest="${basedir}\${project.maifest}">
<fileset dir="${project.build}\temp" includes="**\*.class" />
<fileset dir="${project.classes}" includes="**\*.class" />
<fileset dir="Btlserver" includes="**\*.xml" />
</jar>
then we delete temp - and voila.
Besides, may be you can suggest smth about multiple projects layout in eclipse with ivyDE and ant?? I asked this question, but no one has even posted any suggestions. Sad (

Resources