Hi All,
I know I don't let you much time to give me feedback, but it always
possible to go back if you feel I do things in the wrong direction,
and since I have spare time for the moment, I make good progress on
Ivy refactoring.
I've "finished" the split of the Ivy class, it's now almost only a
Facade to other objects, most of them being "engines" dedicated to
each feature of Ivy.
I've also just checked in a modification on the API of the deliver
method. I took deliver as an example, but my plan is to follow the
same recipe for other methods, if feedback is positive.
What I've done is introduce a DeliverOptions class which stores most
of the parameters the deliver method was taking. Well, when I say
most, I mean all the parameters which have a default value. So now you
can easily call deliver with default values only, or setup a
DeliverOptions manually to configure the algorithm. The advantage I
see is that if we want to add a new option, we just have to add the
attribute with getter/setter, and the API of deliver does not change.
Another thing is that it improves readability, especially when you
have several boolean parameters, it's very difficult to know what
you're actually doing in your call.
For instance, compare these two calls:
Ivy 1.4:
ivy.deliver(mrid, "1.5", cache, "ivy-[revision].xml", "release", new
Date(), pdrResolver, false, true)
Ivy 1.5:
ivy.deliver(mrid, "1.5", "ivy-[revision].xml",
new DeliverOptions()
.setStatus("release")
.setPubdate(new Date())
.setCache(cacheManager)
.setPdrResolver(pdrResolver)
.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"));
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?
- Xavier
