On 1/31/07, Stephane Bailliez <[EMAIL PROTECTED]> wrote:
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 ?
My idea was to distinguish constructors (I defined two actually: one with no
arguments, and one with all options as parameter) from factory method which
actually process the argument to find what values should be for options (the
settings is not part of the attributes of DeliverOptions, it's only used to
give default values to the actual attributes). Another thing is that factory
methods have the advantage to be more flexible (as explained in the
excellent "Effective Java Programming" you've certainly read). But in this
case I don't see how it could really help, so if several people prefer
constructor, I'll go with it, no problem.
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.
I'm not sure to see what you mean. If I provide an IvySettings object, I can
have good default values for my attributes. Otherwise I can't, for the cache
for example. So does it mean I should avoid the empty constructor to be sure
a DeliverOptions won't ever be badly set?
Also I do hate to stack several statements in one line as it is a PITA
to debug.
You're right, but the API doesn't force you to put all on the same line :-)
I'll try to use multi line statements more often.
> 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.
It's fine, I think I'll let the API like that for the moment to wait for
review, and tomorrow I'll continue the refactoring with the IvyNode split. A
good day of headache in perspective :-)
Xavier
-- stephane
