Why does ivy put my locally resolved jar in a sub directory within the libs directory

Question

I am not that experienced with ivy and not sure how to solve this problem, which I probably caused myself by not understanding ivy.

so I have this in my ivysettings.xml to use a local filesystem repo

JarL.java exsists in /home/tester/JAVA/tester-libs/

my dependencies are set in ivy.xml as

which resolves the dependency but where all the other jars like commons-configuration are placed in lib/ during the build, my jar is placed in lib/JarL sub-directory.

I want JarL to be placed in lib/ like the other dependencies and have no idea what to do. I hacked these scripts together from other answers I found on the net.

Ivy is just too in-depth for me. I not want to take months out of my life to learn yet another tool. I just want easy lazy development where I concentrate on the problem at hand not the dev tools.

UPDATE:

For the moment I have had to add the following 2 lines to the packing step in build.xml to get around this problem but it is a silly fix.

UPDATE: added build.xml as per Mark's request


    Builds, tests, and runs the project Naps.

and this is the nb properties file it loads

#Thu, 02 Jul 2015 05:24:03 +0100
annotation.processing.enabled=true
annotation.processing.enabled.in.editor=false
annotation.processing.processors.list=
annotation.processing.run.all.processors=true
annotation.processing.source.output=${build.generated.sources.dir}/ap-source-output
application.splash=
application.title=Naps
application.vendor=Tester
auxiliary.org-netbeans-spi-editor-hints-projects.perProjectHintSettingsFile=nbproject/cfg_hints.xml
build.classes.dir=${build.dir}/classes
build.classes.excludes=**/*.java,**/*.form
# This directory is removed when the project is cleaned:
build.dir=build
build.generated.dir=${build.dir}/generated
build.generated.sources.dir=${build.dir}/generated-sources
# Only compile against the classpath explicitly listed here:
build.sysclasspath=ignore
build.test.classes.dir=${build.dir}/test/classes
build.test.results.dir=${build.dir}/test/results
compile.on.save=true
compile.on.save.unsupported.javafx=true
# Uncomment to specify the preferred debugger connection transport:
#debug.transport=dt_socket
debug.classpath=${run.classpath}
debug.test.classpath=${run.test.classpath}
# This directory is removed when the project is cleaned:
dist.dir=dist
dist.jar=${dist.dir}/Naps.jar
dist.javadoc.dir=${dist.dir}/javadoc
endorsed.classpath=
excludes=
includes=**
# Non-JavaFX jar file creation is deactivated in JavaFX 2.0+ projects
jar.archive.disabled=true
jar.compress=false
#
# Tester - replaced classpath with ivy
javac.classpath=${ivy.classpath}\:${javafx.classpath.extension}
# javac.classpath=\
#    ${javafx.classpath.extension}
# Space-separated list of extra javac options
javac.compilerargs=
javac.deprecation=false
javac.processorpath=${javac.classpath}
javac.source=1.8
javac.target=1.8
javac.test.classpath=${javac.classpath}\:${build.classes.dir}
javac.test.processorpath=${javac.test.classpath}
javadoc.additionalparam=
javadoc.author=false
javadoc.encoding=${source.encoding}
javadoc.noindex=false
javadoc.nonavbar=false
javadoc.notree=false
javadoc.private=false
javadoc.splitindex=true
javadoc.use=true
javadoc.version=false
javadoc.windowtitle=
javafx.application.implementation.version=1.0
javafx.binarycss=false
javafx.classpath.extension=${java.home}/lib/javaws.jar\:${java.home}/lib/deploy.jar\:${java.home}/lib/plugin.jar
javafx.deploy.adddesktopshortcut=false
javafx.deploy.addstartmenushortcut=false
javafx.deploy.allowoffline=true
# If true, application update mode is set to 'background', if false, update mode is set to 'eager'
javafx.deploy.backgroundupdate=false
javafx.deploy.disable.proxy=false
javafx.deploy.embedJNLP=true
javafx.deploy.icon=
javafx.deploy.icon.native=
javafx.deploy.includeDT=true
javafx.deploy.installpermanently=false
javafx.deploy.permissionselevated=false
javafx.deploy.splash=
# Set true to prevent creation of temporary copy of deployment artifacts before each run (disables concurrent runs)
javafx.disable.concurrent.runs=false
# Set true to enable multiple concurrent runs of the same WebStart or Run-in-Browser project
javafx.enable.concurrent.external.runs=false
# This is a JavaFX project
javafx.enabled=true
javafx.fallback.class=com.javafx.main.NoJavaFXFallback
# Main class for JavaFX
javafx.main.class=naps.Main
javafx.preloader.class=
# This project does not use Preloader
javafx.preloader.enabled=false
javafx.preloader.jar.filename=
javafx.preloader.jar.path=
javafx.preloader.project.path=
javafx.preloader.type=none
# Set true for GlassFish only. Rebases manifest classpaths of JARs in lib dir. Not usable with signed JARs.
javafx.rebase.libs=false
javafx.run.height=600
javafx.run.width=800
javafx.signing.blob=false
javafx.signing.enabled=false
javafx.signing.type=notsigned
# Pre-JavaFX 2.0 WebStart is deactivated in JavaFX 2.0+ projects
jnlp.enabled=false
# Main class for Java launcher
main.class=com.javafx.main.Main
# For improved security specify narrower Codebase manifest attribute to prevent RIAs from being repurposed
manifest.custom.codebase=*
# Specify Permissions manifest attribute to override default (choices: sandbox, all-permissions)
manifest.custom.permissions=
manifest.file=manifest.mf
meta.inf.dir=${src.dir}/META-INF
mkdist.disabled=false
native.bundling.enabled=false
platform.active=default_platform
run.classpath=${dist.jar}\:${javac.classpath}\:${build.classes.dir}
run.test.classpath=${javac.test.classpath}\:${build.test.classes.dir}
source.encoding=UTF-8
src.dir=src
test.src.dir=test

ivy.classpath=lib/commons-beanutils-1.8.3.jar\:lib/commons-codec-1.6.jar\:lib/commons-collections-3.2.1.jar\:lib/commons-configuration-1.10-javadoc.jar\:lib/commons-configuration-1.10-sources.jar\:lib/commons-configuration-1.10.jar\:lib/commons-digester-1.8.1.jar\:lib/commons-jexl-2.1.1.jar\:lib/commons-jxpath-1.3.jar\:lib/commons-lang-2.6.jar\:lib/commons-logging-1.1.1.jar\:lib/commons-vfs2-2.0.jar\:lib/log4j-1.2.8.jar\:lib/maven-scm-api-1.4.jar\:lib/maven-scm-provider-svn-commons-1.4.jar\:lib/maven-scm-provider-svnexe-1.4.jar\:lib/plexus-utils-1.5.6.jar\:lib/regexp-1.3.jar\:lib/servlet-api-2.4.jar\:lib/xml-apis-1.0.b2.jar\:lib/xml-resolver-1.2.jar

UPDATE: Here is build.xml file changed to use an ivy retrieve pattern as mentioned by Mark Hunter


    Builds, tests, and runs the project Naps.

here's ivy.xml using configurations, htough there is only so not sure why that should change anything

These changes have resulted in lib/JarL-NA.jar/JarL-NA.jar becoming lib/JarL.jar/JarL.jar, which is still in a sub-directory of lib and now prevents my simple rename step form working.

The rest of the dependencies are in lib as expected and as they were before.

Addtionally, these changes have now preventd nb from resolving commons-configuration so the source can no longer import the class.

Mark O&#39;Connor · Accepted Answer

The following project is an example of how to setup and use ivy tasks. The build file you're using looks like it was generated and follows some older usage patterns.

Hope it helps.

Example

This project has been customized to use a "local-libs" directory as a file repository. This caters for scenarios where some libs are shipped alongside the source because they're not available from an external repository like Maven Central.

├── build.xml
├── ivysettings.xml
├── ivy.xml
├── local-libs
│   └── JarL-1.0.jar
└── target
    ├── dist
    │   └── lib
    │       ├── commons-configuration-1.10.jar
    │       ├── commons-lang-2.6.jar
    │       ├── commons-logging-1.1.1.jar
    │       └── JarL-1.0.jar
    └── ivy-reports
        ├── ivy-report.css
        └── org.naps-naps-napsjar.html

After running the build two directories are created under the "target" directory:

"dist/lib": Containing the files managed by ivy. Check how the resolve task works
"ivy-reports": HTML report telling you how ivy determined the dependencies

It should be noted I also included an example of how to create a property containing a list of the classpath managed by ivy.

build.xml

Pay attention to the namespace at the top if the build file. Ivy no longer needs an explicit taskdef. Also include a target that installs ivy if it's not present on the build server. Finally note how the ivy "resolve", "report", "cachepath" and "retrieve" tasks are called:

ivy.xml

Note how local files are referenced using the special organisation "NA"

ivysettings.xml

The "modules" section tells ivy to resolve "NA" organisation artifacts using the file system resolver. The artifact pattern tells ivy how to resolve local files. Always a good idea to include a version number.

Why does ivy put my locally resolved jar in a sub directory within the libs directory

Answers (1)

Example

build.xml

ivy.xml

ivysettings.xml

Related Questions