Hello everyone,
I'm a few months old to Ivy now and now have a bunch of projects which
work well when it comes to dependency management, publishing etc... One
of the things that I've been struggling a bit is lack of "first class"
support for "changing" revisions (a.k.a SNAPSHOTS).
For example, consider my module:
<ivy-module version="2.0">
<info organisation="org.myapp" module="my-ivy-experiements"
revision="0.1.0-SNAPSHOT"/>
<publications>
<artifact name="foo-bar" type="jar" ext="zip"/>
</publications>
....
<dependency org="org.thirdparty" name="some-util"
rev="2.0.0-SNAPSHOT" changing="true"/>
....
Ivy allows me to mark dependencies as "changing" and that works out well
for snapshot dependencies. However, I haven't yet found a way to mark my
module itself as changing (notice the version of my module is
0.1.0-SNAPSHOT) so that when the ivy publish is triggered:
<target name="publish" description="Deploy the binaries to the snapshots">
<ivy:publish resolver="local" publishivy="true" forcedeliver="true"
overwrite="true">
<artifacts pattern="${dist.dir}/[artifact].[ext]"/>
</ivy:publish>
</target>
I would expect the publish cleans up existing folders and artifacts for
that version of the module being published, from the target location,
and recreates the artifacts and folders afresh, for changing modules
such as this one.
With the current behaviour where publish just leaves behind existing
artifacts, I've run into problems related to reproducibility of the
builds. For example, consider 0.1.0-SNAPSHOT of my module published
xyz.jar in the first build. I then go ahead and change my ivy module to
publish a abc.jar instead of xyz.jar for the same 0.1.0-SNAPSHOT version
and retrigger the publish. The 0.1.0-SNAPSHOT directory in my ivy cache
ends up containing both xyz.jar and abc.jar, instead of just the
abc.jar. This ended up causing problems because the build kept passing
on my instance (which had the stale jar in cache). Then, when it was
built on someone else's system where the cache was built afresh, it
failed because a certain part of the build, which I had forgotten to
update, was referring to the old xyz.jar which is no longer being published.
Is there any way to ensure that SNAPSHOT (a.k.a changing) modules can be
marked as such, so that the publish and other related tasks can treat
them as something that needs to be recreated every time afresh?
Something like:
<ivy-module version="2.0">
<!-- A module level attribute which is used consistently across
tasks to identity changing revisions in this module -->
<info organisation="org.myapp" module="my-ivy-experiements"
revision="0.1.0-SNAPSHOT" changingPattern=".*SNAPSHOT"/>
....
<!-- No explicit need to specify this as changing="true" since the
module level changingPattern takes care of this -->
<dependency org="org.thirdparty" name="some-util"
rev="2.0.0-SNAPSHOT"/>
....
Notice that I've set a module level changingPattern which could then be
used for both the dependencies as well as the module itself to identity
changing revisions.
I could have gone by proposing a changing=true attribute on the info
element, but then whenever I want to release this module and change it's
revision to 0.1.0, I don't want to remember to edit the changing
attribute for this revision to false before triggering this release.
Is something like this possible? If not, would this be something that
could be proposed for upcoming releases?
-Jaikiran
