3
votes

It appears that there's no ivy:unpublish task (e.g. see here).

So, I suppose that unpublished should be performed at the filesystem level either manually or through an Ant task that deletes ~/.ivy2/local subfolers? (when the aim is to unpublish from the local ivy repo).

2

2 Answers

3
votes

I'm very surprised you accepted Mark's answer, given that AFAICT it has nothing to do with your use-case, which is about your local repository - that is, your private repository on your system. His answer is relevant to shared repositories only.

There's a use case with Ivy that I suspect is very common. A developer is temporarily working on two projects, one of which is dependent on the other. While they are doing this work, they publish SNAPSHOTs from the upstream project to their local repository, so that the downstream project "sees" their changes. When the developer is done with this task, they check in their changes into source control, and then want to "rejoin the group" and get the latest SNAPSHOT dependencies for the upstream project. At this point they want to "unpublish" the upstream project from their local repository, so that they resume consuming changes from other developers in the group.

For what little it's worth, see also this Ivy Jira issue, from 2006.

As I noted in my comment there, from a couple of weeks ago, I suspect there's some best-practice that I'm not aware of, that makes this moot. Anyone?

1
votes

No, ivy does not support an unpublish action. Similarily Maven does not support such an operation.

Not sure I understand the use-case. When one "publishes" content it would normally be a very bad idea to remove it later... Why?

  • You could unpredictably break other people's builds that depend on your version.
  • Repository caches normally assume that released artifacts never change. If there exists a possibility that they might disappear, this forces a cache to constantly "dial home" to ensure they aren't dirty.

Having said that there are arguments for an against. I'd recommend reading the following excellent blog article from sonatype: