ant-ivy-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From zharvey <>
Subject Re: ivy:publish build error
Date Thu, 15 Sep 2011 14:56:38 GMT


I have a number of sub-questions spawning from your last (and very helpful!)
response; but only one of them concerns me immediately. I'll address the
others later.

I guess it makes sense that you can't write to a HTTP url. However, HTTP
does have the PUT method. And now that I've cleaned up my XML scripts (from
the examples & input you provided) I am now getting a completely different
error; one that jives with your statements in the last response:

IOException: PUT operation to URL failed with
status code 405: Method Not Allowed.

According to W3C, HTTP 405s get thrown for a number of reasons, one of which
is "attempting to write to a read-only resource."

So this has me thinking: I'm using the URL (default) resolver to try and
publish my artifact, and Ivy is smart enough to translate that into an HTTP
PUT operation.

It turns out that the Apache httpd server (which is what I'm using for
"") can be configured, albeit hackaliciously, to in fact accept
PUT commands.

My question to you and the Old Nabble community at large is this: which of
the following siutations (if any) are the case here:
(a) Ivy intrinsicly prohibits URL resolver to publish (write) artifacts,
regardless of web server settings at the URL; or
(b) There's no way get both the module descriptor and the artifact bundled
up inside the same ivy:publish execute since HTTP PUT only accepts 1 item;
(c) It, theoretically, would be possible to script my Apache server to
accept the PUT from Ivy and write these files to my ivyrepo. (Yes, I am
aware of the security concerns that will arise from this, and would have to
take measure into my own hands on that account).

Or, is there some other angle I'm not seeing? Based on the IOException I'm
reading in my console, it sounds like option (c) might be feasible. But you
seem to be very well-versed with Ivy, and from reading your last response,
it sounds like (a) or (b) could be the case.

I just don't want to launch down some crazy avenue and spend a 1/2 day
reconfigging my web server only to find out that (c) was never a possibility
in the first place.

I appreciate everything you've helped me with so far and am interested in
hearing what the community thinks.

Kirby Files wrote:
> zharvey wrote on 09/15/2011 09:29 AM:
>> Hi Kirby,
>> Thanks for getting back to me so quickly.
>> Here's my settings file (ivy-settings.xml):
>> ===============================
>> <ivysettings>
>> 	<properties file=""/>
>>      <settings defaultResolver="defResolver"/>
>>      <latest-strategies>
>>      	<latest-lexico/>
>>      </latest-strategies>
>>      <resolvers>
>>          <chain name="defResolver" returnFirst="true">
>>           	<url name="jarServer">
>> 				<ivy
>> pattern="[organisation]/[module]-[revision]-ivy.xml"/>
>> 				<artifact
>> pattern="[organisation]/[artifact]-[revision].[ext]"/>
>>           	</url>
>>          </chain>
>>      </resolvers>
> You only have url resolvers defined here. You cannot really publish to 
> those. You need to publish to a resolver you can write to: filesystem, 
> sftp, webdav via common-vfs, etc.
>>      <modules>
>>      	<module organisation="myOrg" name="*" resolver="defResolver"/>
>>      </modules>
> If you have a defaultResolver defined, as you do above, you don't need 
> to do explicit module mapping to a resolver.
>>      <publications defaultconf="publish">
>> 		<artifact name="MyModule" />
>> 	</publications>
> You're going to publish your artifacts to a configuration named 
> publish, so any modules depending on MyModule will need to have a 
> confMapping of compile->publish. Is that what you want? I typically 
> publish artifacts to configurations based upon how they will be used 
> by the consuming project. So jars needed for running an app will be in 
> the "runtime" configuration, while jars only needed for building will 
> be published to the "compile" configuration, etc. I also defined 
> javadocs and sources configurations.
>> 	<!-- Ivy "publish" task; publish the distribution to SVN for downstream
>> projects -->
>> 	<target name="publish">
>> 		<ivy:publish organisation="myOrg" module="MyModule"
>> resolver="defResolver"
>> revision="1.0">
>> 			<artifacts pattern="dist/[artifact]-[revision].[ext]"/>
>> 		</ivy:publish>
>> 	</target>
>> </project>
> So there's your problem. The publish target needs to depend on the 
> resolve target, which needs to depend on the settings target.
> The settings task should only ever be run once during an ant build, so 
> I guard against executing twice (say resolve->settings and 
> deliver->settings are both executed in the same build):
>      <target name="ivysettings" unless="ivysettings.completed">
>          <property name="ivysettings.completed" value="true" />
>          <ivy:settings id="ivy.instance"
>                        url="${ivy.settings.url}"
>          />
>      </target>
> You'll also want to publish to a resolver to which you can write. I 
> generally would not add the artifacts child element (use publications 
> in ivy.xml instead); use artifactspattern to define where to find the 
> jars specified in <publications>. Unless you have multiple modules per 
> buildfile, I wouldn't use the org or module attributes, either. You 
> should probably specify a pubrevision and status.
> Here's an example from one of my projects:
>      <target name="publish_only"
>              depends="resolve"
>              description="--&gt; publish this project in the prod ivy 
> repository">
>          <property name="revision" value="${version}" />
>          <ivy:publish 
> artifactspattern="${dist.dir}/[type]s/[artifact]-[revision].[ext]"
>                       resolver="masrep_sftp"
>                       pubrevision="${revision}"
>                       status="release"
>                       overwrite="false"
>                       update="true" />
>          <echo message="project ${} released with 
> version ${revision}" />
>      </target>
> Also,
> Thanks,
> ---
> Kirby Files
> Software Architect
> Masergy Communications

View this message in context:
Sent from the ivy-user mailing list archive at

View raw message