For the record, I'm -0.5 to the plan of Maarten. I think settings should looks like a datatype (and maybe resolve as well), but I don't find any good aproach to do it. The changes would be too big. So I don't see a better plan than the one presented by Maarten.
If someone has a better plan, please talk. Concerning the name, I would preffer to stick to configure if we don't move to a datatype. I don't think that configuring ivy using a settings file will be confused with the dependency configurations. Gilles On 31/03/2008, Xavier Hanin <[EMAIL PROTECTED]> wrote: > On Mon, Mar 31, 2008 at 1:36 PM, Maarten Coene <[EMAIL PROTECTED]> > wrote: > > > > I don't think the tasks should be stateless, I think it's fine the way it > > is now. > > There are other examples of tasks that must be executed one ofther the > > other, like: > > setProxy -> must be executed before outgoing http connections are made if > > you have a proxy > > the Clover tasks -> the setup task must be executed first > > junitreport -> is sharing state with the junit tasks through xml files, a > > bit the same as the postresolve task can share state with the resolve task > > by parsing the XML resolve report. > > > > If we keep ivy:settings to be a task, we should do 2 things: > > - rename the "id" attribute to something else > > - rename "ivy:settings" to something else to make it more clear what it > > does to avoid confusion. But I think Gilles has a point here about the > > ivy:configure task. I don't see a difference between the "ivy:settings" > task > > and the "ivy:configure" task, except the ability to specify a settings id. > > > > So, I think we should do the following: > > 1. undeprecate the "ivy:configure" task and add a settingsId attribute to > > it (and the other settings attributes that aren't present on ivy:configure) > > 2. undefine the "ivy:settings" task (just remove it from the antlib.xml) > > 3. refactor the IvyAntSettingsTask (or whatever it's name is) to be a real > > datatype, which will be created internally by ivy:configure and used in all > > the other Ivy tasks. But don't make this datatype available for usage in > the > > ant scripts yet. This way, it will be easy to support the use-case of > > lazy-loading the Ivy settings once we think it's usefull to support it. > > > I mostly agree with this plan. The only thing I'm still wondering about is > if naming the task "configure" is a good idea. We have renamed configuration > files to settings files everywhere to avoid the confusion. Calling the task > configure may reintroduce some confusion. So I'd prefer another name, like > loadsettings or setup. > > > Xavier > > > > > > > > > Maarten > > > > > > ----- Original Message ---- > > From: Xavier Hanin <[EMAIL PROTECTED]> > > To: Ant Developers List <dev@ant.apache.org> > > Sent: Sunday, March 30, 2008 5:52:39 PM > > Subject: Re: Ivy settings id (was Re: Merge 641903 from trunk to > 1.7branch?) > > > > On Sat, Mar 29, 2008 at 7:23 PM, Gilles Scokart <[EMAIL PROTECTED]> > > wrote: > > > > > I'm -1 to rename ivy:settings into ivy:loadsettings. If you realy > > > want something like that, then it would be better to go back to the > > > ivy:configure (and I would be -0.5). > > > > > > The reason I think ivy:settings should be a data-type (or look like a > > > data type) is because every ant task are "standalone". I don't know > > > any example of 2 tasks that should be executed one after the other, > > > while it is usual to have an ant task depending on a pre-declared > > > datatype. > > > > First, if we really want to have all Ivy tasks stateless, we should change > > resolve too. The problem is exactly the same between resolve and any post > > resolve task as it is between settings and any other task. > > Second, I see an example of tasks somewhat depending on one another: > > taskdef > > and any task declared by the taskdef. > > So I think loading settings with a task is consistent with resolving > > dependencies with a task, and I think it's the only way we have to > > actually > > load the settings when the user wants. If datatype were not lazily > > initialized I think I'd be in favour of using a datatype. But with the > > current facts I'm not. > > > > Xavier > > > > > > > > > > An other way to say that is that every tasks are "stateless". The > > > only exceptions is the properties task, which for me look like a data > > > declaration. > > > > > > > > > > That's why Ant is a declarative langage, and not a procedural langage. > > > I consider ivy:configure "command" as a procedural command and not a > > > declarative one. > > > > > > Now, I agree that the declarative aproach leas to some issues. One of > > > them is that the datatype are curently always processed lazily (the > > > first time they are used) and thus the errors are also reported > > > lazily, which make the debuging more complex. > > > > > > Anyway, even if I like the suggestion of Dominique (the user that > > > don't want to put a settingsRef should use ivy:configure in BC mode), > > > it has a drawback. If the user forget to put its settingsRef, he will > > > not receive any error message, the code will run with the default > > > settings, even if an other settings is defined. This lead to problem > > > difficult to debug. > > > > > > Gilles > > > > > > > > > On 29/03/2008, Xavier Hanin <[EMAIL PROTECTED]> wrote: > > > > On Fri, Mar 28, 2008 at 11:50 PM, Dominique Devienne < > > > [EMAIL PROTECTED]> > > > > wrote: > > > > > > > > > > > > > On Fri, Mar 28, 2008 at 5:40 PM, Maarten Coene < > > > [EMAIL PROTECTED]> > > > > > wrote: > > > > > > Can't we just deprecate the "id" attribute on the settings task > > and > > > use > > > > > the settingsId attribute instead? > > > > > > > > > > id is handled by Ant itself, in the core. I don't think you can > > > deprecate > > > > > it. > > > > > > > > > > > > I think we would deprecate the usage we do of id, not really the > > > attribute > > > > itself. And I don't think we even really need to deprecate it, the > > > usage of > > > > id like it is used today has been introduced in 2.0 alphas and betas, > > > so > > > > with no guarantee that it won't change. > > > > > > > > > > > > > > > > > > And that doesn't change the fact that <settings> should be a > > datatype > > > > > rather than a task. --DD > > > > > > > > > > > > I'm still not sure if settings "should" be a datatype. Maybe the name > > > makes > > > > thinks it should be a datatype. If we call it loadsettings instead, I > > > think > > > > it still make sense to make it a task. Exactly as resolve is a task, > > > and > > > > allow with resolveId to set the id of the resolve report it generates > > > and is > > > > later used by other tasks like retrieve. Making resolve a datatype > > > would > > > > really not make any sense IMO, since what people expect when calling > > is > > > > actually to resolve dependencies. We can consider it's the same thing > > > with > > > > settings/loadsettings. It's kind of similar to the property task when > > > you > > > > use the file attribute: it loads a property file and sets a set of > > > > properties. It has a side effect for other tasks, but it's still a > > > task, not > > > > a datatype. > > > > > > > > So maybe renaming settings in loadsettings and renaming id in > > > settingsId > > > > would be a pretty good solution for 2.0: it give us the opportunity > > to > > > later > > > > add a settings datatype, which loadsettings is only responsible for > > > loading. > > > > And we don't have the 'id' bad usage anymore. > > > > > > > > WDYT? > > > > > > > > > > > > Xavier > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Xavier Hanin - Independent Java Consultant > > > > http://xhab.blogspot.com/ > > > > http://ant.apache.org/ivy/ > > > > http://www.xoocode.org/ > > > > > > > > > > > > > -- > > > Gilles Scokart > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Xavier Hanin - Independent Java Consultant > > http://xhab.blogspot.com/ > > http://ant.apache.org/ivy/ > > http://www.xoocode.org/ > > > > > > > > > > > > > > > ____________________________________________________________________________________ > > Like movies? Here's a limited-time offer: Blockbuster Total Access for one > > month at no cost. > > http://tc.deals.yahoo.com/tc/blockbuster/text4.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > -- > > Xavier Hanin - Independent Java Consultant > http://xhab.blogspot.com/ > http://ant.apache.org/ivy/ > http://www.xoocode.org/ > -- Gilles Scokart --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
