Xavier Hanin wrote:
ivy.deliver(mrid, "1.5", "ivy-[revision].xml",
new DeliverOptions()
.setStatus("release")
.setPubdate(new Date())
setPublicationDate() ?
.setCache(cacheManager)
.setPdrResolver(pdrResolver)
What's a pdr ?
.setValidate(false)
.setResolveDynamicRevisions(true));
The second is longer, but I think it's much cleaner too. And note that
it's long because we set all options, but if we want to use default
values for everything except the status, for example, then we can do:
ivy.deliver(mrid, "1.5", "ivy-[revision].xml",
DeliverOptions.newInstance(settings).setStatus("release"));
Why do you want to use a factory method ?
Constructor works fine too and I think you should also take more
advantage of having your object in a mostly known and relevant state for
most properties and work from there.
Also I do hate to stack several statements in one line as it is a PITA
to debug.
The problem is that it changes the API, thus requiring a lot of work
to migrate tools using Ivy 1.4 API. That's why I've added a Ivy14
class, which provide a 1.4 compatible API, so that if you don't want
to use the new API, you can simply replace your instance of Ivy by an
instance of Ivy14, and you're done!
So, what do you think? Shall I continue on this way, and do that for
all main methods of Ivy? Or go back to the 1.4 API?
Simplification and partitioning is good. :)
I don't have much time to review it until the week end though.
-- stephane
