I want to be able to add a task of my own to the ArtifactHandler, without inheriting everything that comes with AbstractArchiveTask. The problem with AbstractArchiveTask is that it’s a CopyTask with a deep hierarchy. The list of Notation Parsers used for PublishArtifact’s only supports Files and AbstactArchiveTask. I can fulfill all the requirements needed for PublishArchive pretty simply, though I probably have to implement the builtBy in AbstractPublishArtifact, but that class is internal (odd that I can reference builtBy when defining an artifact, yet it’s internal).
It just seems that DefaultPublishArtifactFactory could do a little more than assume Files and AbstractArchiveTask.
I’d suggest staying away from ArtifactHandler as a long term strategy. Our new publication stuff will eventually supersede a lot of things in this area.
Instead, I’d suggest coming up with your own DSL that just directly adds PublishArtifact objects to the configruation’s ‘publications’ set. You could aim to make this DSL general enough so that it can be backed by the new publication mechanism once it supports the functionality you need.
Given that we want to deprecate all of this stuff eventually, I’m reluctant to make improvements unless we absolutely need to. Eventually, PublishArtifact will no longer be relevant. Furthermore, we want to move away from Ivy’s concept of a configuration for publishing.