I'm working within a large build system that uses Ant/Ivy. I try to use a predefined ant task that uses ivy:publish ant task and get this error:
impossible to publish artifacts for com.company.project1.proj1#MySupportJar;working#server1: java.io.FileNotFoundException: /path_to/ivy-repository/com.company.project1.proj1/MySupportJar/5.1.3.part/MySupportJar-5.1.3.jar (No such file or directory)
The directory in the error message exists up to the version number part (5.1.3.part).
I am new to Ivy but think I get the basics of how it works. I can not find much on the exact meaning of this error so if someone could help or point me to an explanation I think I could resolve the issue from there.
Ant target
<target name="publish-shared" depends="ivyInit, resolve"
description="Publish to the shared repository">
<ivy:publish pubrevision="5.1.3"
resolver="shared"
pubdate="${timestamp}"
forcedeliver="true"
update="true"
conf="distro, docs">
<artifacts pattern="dist/[artifact].[ext]"/>
</ivy:publish>
</target>
Ivy file snippet
<publications>
<artifact name="MySupportJar" type="jar" conf="distro" />
<artifact name="MySupportJar-source" type="source" ext="jar" conf="docs" />
</publications>
Thanks.
Thanks for all the suggestions. Turns out to be a simple solution that I was not looking for.
The problem was permissions at /path_to/ivy-repository/com.company.project1. I did not have write permission. The .part file is a temporary file written by Ivy. Ivy could not write the temporary file so when it got to reading the file it failed to find it.
I'm answering this so that it might help someone later.
Thanks.
I'm fairly new to Ant with Ivy too. What I've done is combine a local Maven repository (Artifactory), with Jenkins as a continuous integration server. When we build a jar, I also produce the Maven pom.xml with it. Then, I use the mvn deploy:file command to deploy the desired build to our Maven repository.
The developer manually deploys the jar to our Maven repository via the Promoted Build plugin to Jenkins. The developer selects the build to deploy to Maven, and then pretty much presses a button, and that build will be deployed.
I actually produce two pomswith each build. One ispom.xmland the other ispom-snapshot.xml`. We deploy the snapshot with each build, so other developers can use the latest jar instead of the officially deployed one. I've put the whole thing in github if you're interested.
The only decent Ant/Ivy documentation I've seen is Manning's Ant in Action by Steve Loughram. If it wasn't for that, I probably would have never even tried Ant with Ivy. The online Ant/Ivy documentation at Apache is just plain awful.
I've looked over what you have. I suspect it might be an issue with your ivy-settings.xml file. Somewhere, it's getting the part string as the valid location for publishing the file. Otherwise, I have no idea.
As I said, we use a Maven repository for our site repository, and then use Maven to actually deploy the jars to the repository. I simply found that much easier to do it that way than to figure out how to do this in pure Ivy. Besides, it also means that our Maven projects can also use the jars from our Ant/Ivy projects.
Related
I have a little sandbox that I use to publish not-invented-here artifacts to our artifact repository. It has a common build.xml file and a common ivysettings.xml.
I would like to be able to pass the name of the ivy.xml file so I can have exactly one, uniquely-named someartifact-ivy.xml file per artifact I intend to publish.
I tried the following:
#/bin/sh
ant publish -Divy.settings.file=ivy-external-ivysettings.xml -Divy.dep.file=someartifact-ivy.xml
Property -Divy.settings.file=ivy-external-ivysettings.xml succeeds in causing ivy to use my ivy-external-ivysettings.xml file.
However, ivy seems to ignore property -Divy.dep.file=someartifact-ivy.xml and goes looking for ivy.xml instead.
The docs suggest to me that my approach should work, as does an upvoted (currently x6) answer to a similar question.
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 trying to diagnose a failure in my ant file when it runs a Worklight task. I have a small ant file containing a simple reference to a Worklight task. This works correctly.
<target name="rawBuildApplication" >
<app-builder
applicationFolder="${applicationSource}"
environments="mobilewebapp"
nativeProjectPrefix="xxx"
outputFolder="${outputFolder}"/>
</target>
However when I invoke this ant file from a build control ant file (actually from the RTC build system) I get a failure (below), showing worklight failing to find an apache Java class. I assume there's some simple environmental difference, perhaps a classpath. It might help to figure it out if I knew where Worklight loaded the apache commons from. Right now I can't see anything in my environment in the case that works that points any apache Jar.
myAntFile.xml:146: java.lang.NoSuchMethodError: org.apache.commons.io.FileUtils.deleteQuietly(Ljava/io/File;)Z
at com.worklight.builder.util.BuilderUtils.<clinit>(BuilderUtils.java:672)
at com.worklight.builder.config.UserBuildConfiguration$Builder.<init>(UserBuildConfiguration.java:203)
at com.worklight.ant.builders.ApplicationBuilderTask.createBuildConfiguration(ApplicationBuilderTask.java:149)
at com.worklight.ant.builders.ApplicationBuilderTask.execute(ApplicationBuilderTask.java:80)
Edited: the cause is the use of -lib to add the RTC toolkit directory, exactly why this clashes and how to work around yet to be determined
Usually means you have version of the commons jar in your classpath, and its overriding the one packaged in the worklight-ant.jar. the apache commons files are inside the worklight-ant.jar file
Additional info from djna: I can confirm that when adding the Rational Team Concert (RTC) 3.0 toolkit to the ant classpath, either explicitly with -lib, or when selecting that option in the RTC Build definition some conflicting commons jars are added to the classpath. Worklight packages the classes it needs in its jar, but the -lib folder seems to take precedence.
My workaround is to replace the conflicting jars with later ones. I used these jars
commons-io-2.4.jar
commons-codec-1.8.jar
httpclient-4.2.5.jar
httpcore-4.2.4.jar
httpmime-4.2.5.jar
I guess the other alternative is to upgrade to a newer RTC, but in our environment that's not currently possible.
I'm learning Ivy (http://ant.apache.org/ivy/) and integrating it as part of our build process. It's going pretty well, but I'm stuck on something with the Ivy publish task. Specifically, I'd like to publish to the local repository with the following pattern (which includes the name of the current configuration):
${ivy.local.default.root}/[organisation]/[module]/[revision]/[type]s/[conf]/[artifact].[ext]
So I set up my custom resolver:
<filesystem name="modifiedLocalRepo">
<ivy pattern="${ivy.local.default.root}/[organisation]/[module]/[revision]/[type]s/[conf]/[artifact].[ext]" />
<artifact pattern="${ivy.local.default.root}/[organisation]/[module]/[revision]/[type]s/[conf]/[artifact].[ext]" />
</filesystem>
And configured the publish task:
<ivy:publish
settingsRef="ivy.ext.settings.custom" <!--Location of definition of modifiedLocalRepo-->
resolver="modifiedLocalRepo"
artifactspattern="bin/Debug/[module].[ext]"
pubrevision="1.1-Test"
overwrite="true"
conf="primary"
/>
And have the conf defined in the ivy.xml file:
<info organisation="Mine" module="Dependency"/>
<configurations defaultconf="primary"> <!--Don't think defaultconf should be necessary-->
<conf name="primary"/>
</configurations>
<publications>
<artifact name="Dependency" ext="dll" type="bin" conf="primary"/>
<artifact name="Dependency" ext="pdb" type="bin" conf="primary"/>
</publications>
I have the process working, ivy configured, resolved, the project building, and the artifacts published (using my custom resolver above). But the [conf] token is always resolving to "default." So the published directory has the structure:
\.ivy2\local\Mine\Dependency\1.1-Test\bins\default\
instead of the structure
\.ivy2\local\Mine\Dependency\1.1-Test\bins\primary\
I've been tinkering around with it, setting the conf value, defaultconf value, etc. everywhere they are valid but it's always "default."
I'm using ant to do the build, and have run in debug mode (-d), inspected the output and noticed nothing useful. I've looked through the output of <echoproperties\> and noticed nothing useful. I've read through the Ivy documentation and only found use of [conf] as a token in retrieve and report output.
I can attach the full xml files I'm using to do my limited test build if it would be useful.
Is the [conf] token valid/respected in the artifact pattern for an Ivy publish? If so, what am I missing? Thanks!
Update:
Was using Ivy 2.3.0-rc2 and decided to try to roll back and use Ivy 2.0.0. Same issue.
Take a look at my Ivy project in github. I set it up, so you can easily add it into an existing Ant project.
We use a Maven repository, so I have it setup to create a pom.xml, and then use mvn deploy:deploy-file to deploy it back to the Maven repository. We use Jenkins for our build, so we use Jenkins to run the mvn deploy-file to do the deployment. I guess we could use <ivy:publish>, but never really tried it.
What approach has worked well for you combining IVY + msbuild?
Our goal is to integrate IVY into the C#/C++ build process for dependency resolution and publishing. We have tried adding it to custom tasks at the beginning and end of the build and we have tried wrapping the msbuild calls with ant+ apache-ant-dotnet.
Other options might be gradle, buildr, rake.
What do you use?
Thanks
Peter
Most build technologies can use libraries found in a local directory. I'd suggest using the command-line ivy program to populate this, at the start of your build:
java -jar ivy.jar -ivy ivy.xml -settings ivysettings.xml -retrieve "lib/[conf]/[artifact].[ext]"
Your dependencies are listed in a standard ivy file called ivy.xml. The protocol, location and layout of your remote repository is described in ivysettings.xml
The advantage of this approach (as opposed to switching to Gradle, etc) is that you're not trying to replace your existing build tool. Ivy is solely concerned with managing dependencies.
My team has been using Ivy for .NET for a couple of years very successfully. I know several more that give it a vote of confidence.
Use it standalone. Wrap calls into msbuild tasks. No need to use Ant integration.