Re: Merge 641903 from trunk to 1.7 branch?
Hello Kevin, great work. I have switched my project to use the 1.7.1beta for all builds already and it is working great. Regards, Antoine Original-Nachricht Datum: Sun, 27 Apr 2008 09:50:13 +0700 Von: Kevin Jackson [EMAIL PROTECTED] An: Ant Developers List dev@ant.apache.org Betreff: Re: Merge 641903 from trunk to 1.7 branch? Hi, The problem showed up as a symptom in Ivy but Ivy isn't the only one affected by it. I'm all in favor of merging the change regardless. The change to UnknownElement is now merged back into BRANCH_17 I will test on windows/ubuntu at some point this week - then I suppose a further vote on the new srcs before releasing a further beta Thanks, Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Merge 641903 from trunk to 1.7 branch?
Hi, The problem showed up as a symptom in Ivy but Ivy isn't the only one affected by it. I'm all in favor of merging the change regardless. The change to UnknownElement is now merged back into BRANCH_17 I will test on windows/ubuntu at some point this week - then I suppose a further vote on the new srcs before releasing a further beta Thanks, Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Merge 641903 from trunk to 1.7 branch?
Hi, Note that according to recent discussions on the subject, we will most likely drop the use of 'id' on the task used to load the settings (which will probably be 'configure' again, since I seem to be the only one who don't like using configure where we have make a lot of effort to drop the confusing 'configuration' in favour of 'settings'). Hence this bug shouldn't hurt Ivy users in Ivy 2.0 final. That doesn't prevent fixing the bug in Ant 1.7.1 final, but don't do it only for Ivy users. Sorry this is a little late - no time at the moment :( Does this mean that you would like to change anything or should I merge this change into 1.7.1 now? I'd rather merge something into 1.7.1 that fixes the problem for ant, and is going to require no further changes in the future to support Ivy Thanks, Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Merge 641903 from trunk to 1.7 branch?
On Thu, Apr 24, 2008 at 8:01 AM, Kevin Jackson [EMAIL PROTECTED] wrote: Hi, Note that according to recent discussions on the subject, we will most likely drop the use of 'id' on the task used to load the settings (which will probably be 'configure' again, since I seem to be the only one who don't like using configure where we have make a lot of effort to drop the confusing 'configuration' in favour of 'settings'). Hence this bug shouldn't hurt Ivy users in Ivy 2.0 final. That doesn't prevent fixing the bug in Ant 1.7.1 final, but don't do it only for Ivy users. Sorry this is a little late - no time at the moment :( Does this mean that you would like to change anything or should I merge this change into 1.7.1 now? I'd rather merge something into 1.7.1 that fixes the problem for ant, and is going to require no further changes in the future to support Ivy We won't need any other change in Ant for Ivy 2.0.0, and don't even need this fix to be applied. So don't do it only for Ivy. Xavier Thanks, Kev - 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/
Re: Merge 641903 from trunk to 1.7 branch?
On Thu, 24 Apr 2008, Kevin Jackson [EMAIL PROTECTED] wrote: That doesn't prevent fixing the bug in Ant 1.7.1 final, but don't do it only for Ivy users. Sorry this is a little late - no time at the moment :( Does this mean that you would like to change anything or should I merge this change into 1.7.1 now? I'd rather merge something into 1.7.1 that fixes the problem for ant, and is going to require no further changes in the future to support Ivy The problem showed up as a symptom in Ivy but Ivy isn't the only one affected by it. I'm all in favor of merging the change regardless. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Merge 641903 from trunk to 1.7 branch?
Hello Kevin, I will be happy if this change 641903 gets merged to 1.7.1 final, as my project is a heavy user of the Ant + Ivy combo. Regards, Antoine Original-Nachricht Datum: Thu, 3 Apr 2008 08:00:06 +0700 Von: Kevin Jackson [EMAIL PROTECTED] An: Ant Developers List dev@ant.apache.org Betreff: Re: Merge 641903 from trunk to 1.7 branch? Hi, Sorry I'm late with this. IMHO the bug is serious enough to be fixed in 1.7.1 final and should be merged into the branch. I'm happy to merge this into 1.7.1 and run a 3rd beta cycle (test, push tarballs, vote etc) if it's a show-stopper for many people Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Merge 641903 from trunk to 1.7 branch?
On Thu, Apr 3, 2008 at 5:54 PM, Antoine Levy-Lambert [EMAIL PROTECTED] wrote: Hello Kevin, I will be happy if this change 641903 gets merged to 1.7.1 final, as my project is a heavy user of the Ant + Ivy combo. Note that according to recent discussions on the subject, we will most likely drop the use of 'id' on the task used to load the settings (which will probably be 'configure' again, since I seem to be the only one who don't like using configure where we have make a lot of effort to drop the confusing 'configuration' in favour of 'settings'). Hence this bug shouldn't hurt Ivy users in Ivy 2.0 final. That doesn't prevent fixing the bug in Ant 1.7.1 final, but don't do it only for Ivy users. Xavier Regards, Antoine Original-Nachricht Datum: Thu, 3 Apr 2008 08:00:06 +0700 Von: Kevin Jackson [EMAIL PROTECTED] An: Ant Developers List dev@ant.apache.org Betreff: Re: Merge 641903 from trunk to 1.7 branch? Hi, Sorry I'm late with this. IMHO the bug is serious enough to be fixed in 1.7.1 final and should be merged into the branch. I'm happy to merge this into 1.7.1 and run a 3rd beta cycle (test, push tarballs, vote etc) if it's a show-stopper for many people Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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/
Re: Merge 641903 from trunk to 1.7 branch?
Hi, Sorry I'm late with this. IMHO the bug is serious enough to be fixed in 1.7.1 final and should be merged into the branch. I'm happy to merge this into 1.7.1 and run a 3rd beta cycle (test, push tarballs, vote etc) if it's a show-stopper for many people Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)
On 31/03/2008, Xavier Hanin [EMAIL PROTECTED] wrote: On Mon, Mar 31, 2008 at 3:53 PM, Gilles Scokart [EMAIL PROTECTED] wrote: For the record, I'm -0.5 to the plan of Maarten. What do you exactly mean by -0.5? Do you mean that you don't like it, but will still accept it if we don't find a better and more broadly accepted solution? Yes, it is what I mean. -- Gilles Scokart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)
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. 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.7 branch?) 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
Re: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)
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
Re: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)
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,
Re: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)
On Mon, Mar 31, 2008 at 3:53 PM, Gilles Scokart [EMAIL PROTECTED] wrote: For the record, I'm -0.5 to the plan of Maarten. What do you exactly mean by -0.5? Do you mean that you don't like it, but will still accept it if we don't find a better and more broadly accepted solution? Or that you will veto changes implied by Maarten's change? I think settings should looks like a datatype (and maybe resolve as well), I somewhat agree, and I think it's not opposed to Maarten's plan. Having settings being a datatype is not opposed to have task to load an instance of the datatype, just because datatypes are lazy loaded. 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. For newbies I'm really not sure it won't be confusing. Maybe more specifically for non english speakers. The only argument for configure IMO is BC. So I prefer setup or loadsettings, but I won't object if more people prefer configure though. Xavier 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
Re: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)
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/
Re: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)
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/
Re: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)
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. 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]
Merge 641903 from trunk to 1.7 branch?
Author: peterreilly
Date: Thu Mar 27 10:09:53 2008
New Revision: 641903
URL: http://svn.apache.org/viewvc?rev=641903view=rev
Log:
Bugzilla 44689: NPE with multiple targets and id's in task
IMHO the bug is serious enough to be fixed in 1.7.1 final and should
be merged into the branch.
--- ant/core/trunk/src/main/org/apache/tools/ant/UnknownElement.java
(original)
+++ ant/core/trunk/src/main/org/apache/tools/ant/UnknownElement.java Thu Mar
27 10:09:53 2008
@@ -288,11 +288,14 @@
((Task) realThing).execute();
}
} finally {
-// Finished executing the task, null it to allow
+// Finished executing the task
+// null it (unless it has an ID) to allow
// GC do its job
// If this UE is used again, a new realthing will be made
-realThing = null;
-getWrapper().setProxy(null);
+if (getWrapper().getId() == null) {
+realThing = null;
+getWrapper().setProxy(null);
+}
}
}
Looks pretty save to me. This means we might be having a few
tasks/types living longer than needed, but it seems to be the only way
people can use ids in their build files and run multiple targets at
the same time.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Merge 641903 from trunk to 1.7 branch?
On Fri, Mar 28, 2008 at 12:11 PM, Steve Loughran [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: Author: peterreilly Date: Thu Mar 27 10:09:53 2008 New Revision: 641903 URL: http://svn.apache.org/viewvc?rev=641903view=rev Log: Bugzilla 44689: NPE with multiple targets and id's in task IMHO the bug is serious enough to be fixed in 1.7.1 final and should be merged into the branch. +1. We could always do a quick beta 3 release with this change to see that people are happy. +1 too Xavier
Re: Merge 641903 from trunk to 1.7 branch?
+1 from me. Peter On Fri, Mar 28, 2008 at 11:18 AM, Xavier Hanin [EMAIL PROTECTED] wrote: On Fri, Mar 28, 2008 at 12:11 PM, Steve Loughran [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: Author: peterreilly Date: Thu Mar 27 10:09:53 2008 New Revision: 641903 URL: http://svn.apache.org/viewvc?rev=641903view=rev Log: Bugzilla 44689: NPE with multiple targets and id's in task IMHO the bug is serious enough to be fixed in 1.7.1 final and should be merged into the branch. +1. We could always do a quick beta 3 release with this change to see that people are happy. +1 too Xavier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Merge 641903 from trunk to 1.7 branch?
+1 for me as well (let's put a little bit more presure from the Ivy guys ;-). To come back to the impact on Ivy, I think we should put a note in our doc saying that using the settings task with an id requires 1.7.1. Or is there any workaround we could implement in ivy settings task ? Gilles On 28/03/2008, Peter Reilly [EMAIL PROTECTED] wrote: +1 from me. Peter On Fri, Mar 28, 2008 at 11:18 AM, Xavier Hanin [EMAIL PROTECTED] wrote: On Fri, Mar 28, 2008 at 12:11 PM, Steve Loughran [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: Author: peterreilly Date: Thu Mar 27 10:09:53 2008 New Revision: 641903 URL: http://svn.apache.org/viewvc?rev=641903view=rev Log: Bugzilla 44689: NPE with multiple targets and id's in task IMHO the bug is serious enough to be fixed in 1.7.1 final and should be merged into the branch. +1. We could always do a quick beta 3 release with this change to see that people are happy. +1 too Xavier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Gilles Scokart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Merge 641903 from trunk to 1.7 branch?
On Fri, Mar 28, 2008 at 1:23 PM, Gilles Scokart [EMAIL PROTECTED] wrote: +1 for me as well (let's put a little bit more presure from the Ivy guys ;-). To come back to the impact on Ivy, I think we should put a note in our doc saying that using the settings task with an id requires 1.7.1. We can put a reference to the bug, the problem occurs only when you call ant with multiple targets, each depending on the same settings, so I think people can use Ivy settings with with ant 1.7.0 without running into the problem. Or is there any workaround we could implement in ivy settings task ? I don't think so, I've already tried to find something but I haven't found. But since ant 1.7.1 will be out pretty soon, if the fix is included I don't think it's worth investigating more on Ivy side. Xavier Gilles On 28/03/2008, Peter Reilly [EMAIL PROTECTED] wrote: +1 from me. Peter On Fri, Mar 28, 2008 at 11:18 AM, Xavier Hanin [EMAIL PROTECTED] wrote: On Fri, Mar 28, 2008 at 12:11 PM, Steve Loughran [EMAIL PROTECTED] wrote: Stefan Bodewig wrote: Author: peterreilly Date: Thu Mar 27 10:09:53 2008 New Revision: 641903 URL: http://svn.apache.org/viewvc?rev=641903view=rev Log: Bugzilla 44689: NPE with multiple targets and id's in task IMHO the bug is serious enough to be fixed in 1.7.1 final and should be merged into the branch. +1. We could always do a quick beta 3 release with this change to see that people are happy. +1 too Xavier - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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/
Re: Merge 641903 from trunk to 1.7 branch?
On Fri, Mar 28, 2008 at 5:37 AM, Stefan Bodewig [EMAIL PROTECTED] wrote: Bugzilla 44689: NPE with multiple targets and id's in task IMHO the bug is serious enough to be fixed in 1.7.1 final and should be merged into the branch. +1. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Merge 641903 from trunk to 1.7 branch?
On Fri, Mar 28, 2008 at 8:00 AM, Xavier Hanin [EMAIL PROTECTED] wrote: On Fri, Mar 28, 2008 at 1:23 PM, Gilles Scokart [EMAIL PROTECTED] wrote: +1 for me as well (let's put a little bit more presure from the Ivy guys ;-). To come back to the impact on Ivy, I think we should put a note in our doc saying that using the settings task with an id requires 1.7.1. We can put a reference to the bug, the problem occurs only when you call ant with multiple targets, each depending on the same settings, so I think people can use Ivy settings with with ant 1.7.0 without running into the problem. For the record, I think it's bad Ant style to use ids in tasks. This is kept around for BC, but should be discouraged. Using ids on types OTOH is OK, and essential to types in fact. If a task should refer to part of another task's internal config, this hints to the config needing to be its own type referred to by both tasks. It's even OK for the type to be implicitly created by the first task, when it receives for example a configid=foo attribute, so that the second task can use it using configrefid=foo or a nested config refid=foo /. I'm not sure how Ivy does it exactly, but somehow I got the feel from the discussions that it's using the deprecated id'd task pattern, which is a bad pattern IMHO. Hopefully I got the wrong feeling ;-) --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)
On Fri, Mar 28, 2008 at 4:08 PM, Dominique Devienne [EMAIL PROTECTED] wrote: On Fri, Mar 28, 2008 at 8:00 AM, Xavier Hanin [EMAIL PROTECTED] wrote: On Fri, Mar 28, 2008 at 1:23 PM, Gilles Scokart [EMAIL PROTECTED] wrote: +1 for me as well (let's put a little bit more presure from the Ivy guys ;-). To come back to the impact on Ivy, I think we should put a note in our doc saying that using the settings task with an id requires 1.7.1. We can put a reference to the bug, the problem occurs only when you call ant with multiple targets, each depending on the same settings, so I think people can use Ivy settings with with ant 1.7.0 without running into the problem. For the record, I think it's bad Ant style to use ids in tasks. This is kept around for BC, but should be discouraged. Using ids on types OTOH is OK, and essential to types in fact. If a task should refer to part of another task's internal config, this hints to the config needing to be its own type referred to by both tasks. It's even OK for the type to be implicitly created by the first task, when it receives for example a configid=foo attribute, so that the second task can use it using configrefid=foo or a nested config refid=foo /. I'm not sure how Ivy does it exactly, but somehow I got the feel from the discussions that it's using the deprecated id'd task pattern, which is a bad pattern IMHO. Hopefully I got the wrong feeling ;-) I think we use that bad pattern. We've been wondering about the best form settings should take for a while. It used to be a datatype in 2.0 alpha, but we were running into trouble because a datatype has no lifecycle. Hence in a discussion Peter suggested to make it a task, using the id as we did before for the datatype but with a default value: http://markmail.org/message/52hqry734myzopts This works pretty well from a user point of view who don't really know if it's a task or datatype and don't really care. Except that we run into this bug, and this bad pattern. So, what would you suggest? Is there something we could do better while still preserving the behaviour we have now? Xavier --DD - 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/
Re: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)
On Fri, Mar 28, 2008 at 10:31 AM, Xavier Hanin [EMAIL PROTECTED] wrote: On Fri, Mar 28, 2008 at 4:08 PM, Dominique Devienne [EMAIL PROTECTED] For the record, I think it's bad Ant style to use ids in tasks. [...] I think we use that bad pattern. We've been wondering about the best form settings should take for a while. It used to be a datatype in 2.0 alpha, but we were running into trouble because a datatype has no lifecycle. Hence in a discussion Peter suggested to make it a task, using the id as we did before for the datatype but with a default value: http://markmail.org/message/52hqry734myzopts Well, reading Gilles original issue, I agree with your answer Xavier. The Ant way(tm) is to have both an id for the settings and a settingsRef in retrieve. The only reason you'd not have a settingsRef in retrieve was to be BC with the deprecated config task, and only in this case would you attempt to use a default id to lookup the settings type. If config was never executed, i.e. you're not in BC mode, lacking a settingsRef in retrieve should be an error right away, and you shouldn't even try to lookup the default id. If Ivy was designed like most Ant tasks, all 3 forms below would be equivalent: retrieve settingsRef=foo / retrieve settings ... ... /settings /retrieve retrieve settings refid=foo / /retrieve Where the nested settings is equivalent to the foo settings type not shown. The original issue of not being able to error out right away when a settings doesn't have an id is not really an issue IMHO. I'd be OK with changing Ant to allow a method to be called on types so that they can self-validate themselves (I also wished for such a method a long time ago), to enable the failure right at the point of definition of the type rather than at the point it's used (well, not used in fact, if you remove the use of a default id...). This works pretty well from a user point of view who don't really know if it's a task or datatype and don't really care. Except that we run into this bug, and this bad pattern. So, what would you suggest? Is there something we could do better while still preserving the behaviour we have now? Well, I don't quite agree here. Even though tasks and types are now much closer in the core code, they still remain different concepts, and are documented in separate sections of the manual. Types are data containers, while tasks are doers or actions or verbs. You affect the behavior of a task using inline stuff (attributes, nested elements) which can be types, sometimes defined outside the task itself and simply referenced by id, and the task shouldn't even be aware whether the types are defined locally in the task, or outside. In fact, you can even id a type defined inside a task, and reference it later by id in another task. Keeping task ids force the core Ant code to jump thru quite a few hoops, which we'd better remove in fact... (but we don't for BC...) So for new code like Ivy, an Ant sub-project even, to be using task ids is not a good thing in my opinion. So I suggest you put back settings as a type, only lookup a default id when you know you are in BC mode (i.e. config was used), and otherwise depend on normal uses and rules for ids and types, allowing inline-nested definition of settings. Ant users are used to have to id types they want to refer to in several tasks. Document it as such. Error out in retrieve when so settings are specified, either inline or by ref id. My $0.02. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)
On Fri, Mar 28, 2008 at 5:14 PM, Dominique Devienne [EMAIL PROTECTED] wrote: On Fri, Mar 28, 2008 at 10:31 AM, Xavier Hanin [EMAIL PROTECTED] wrote: On Fri, Mar 28, 2008 at 4:08 PM, Dominique Devienne [EMAIL PROTECTED] For the record, I think it's bad Ant style to use ids in tasks. [...] I think we use that bad pattern. We've been wondering about the best form settings should take for a while. It used to be a datatype in 2.0alpha, but we were running into trouble because a datatype has no lifecycle. Hence in a discussion Peter suggested to make it a task, using the id as we did before for the datatype but with a default value: http://markmail.org/message/52hqry734myzopts Well, reading Gilles original issue, I agree with your answer Xavier. The Ant way(tm) is to have both an id for the settings and a settingsRef in retrieve. The only reason you'd not have a settingsRef in retrieve was to be BC with the deprecated config task, Well, it's not fully a BC issue. We could keep the configure task for BC, and define settings however we want since it's new in 2.0. The problem is more related to Ivy design. In Ivy original design I tried to make using Ivy as easy as possible. Hence if you want to use the default settings, and have an ivy file called ivy.xml in your basedir, then using Ivy is as simple as: ivy:retrieve / I think this has been appreciated by our users from the beginning of Ivy. Behind the scene, this is roughly equivalent to: ivy:configure / ivy:resolve / ivy:retrieve / But I don't know if people would complain if we were now using the settings as any other datatype in the Ant way. But I think that actually loading the settings only when they are used is counter intuitive... maybe because I'm too biased by usage of current Ivy design for more than 3 years now. So I think this is a difficult design choice: make Ivy more compliant with the Ant way, or keep a usage as it is used by some people for years, people who haven't complained about this point yet AFAIR. It's difficult to choose, and it's probably why we have discussed this so many times so far. Xavier
Re: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)
On Fri, Mar 28, 2008 at 11:50 AM, Xavier Hanin [EMAIL PROTECTED] wrote: [...] In Ivy original design I tried to make using Ivy as easy as possible. Hence if you want to use the default settings, and have an ivy file called ivy.xml in your basedir, then using Ivy is as simple as: ivy:retrieve / I think this has been appreciated by our users from the beginning of Ivy. Behind the scene, this is roughly equivalent to: ivy:configure / ivy:resolve / ivy:retrieve / This implies the use of a singleton behind the scene, no? But I don't know if people would complain if we were now using the settings as any other datatype in the Ant way. But I think that actually loading the settings only when they are used is counter intuitive... maybe because I'm too biased by usage of current Ivy design for more than 3 years now. So I think this is a difficult design choice: make Ivy more compliant with the Ant way, or keep a usage as it is used by some people for years, people who haven't complained about this point yet AFAIR. It's difficult to choose, and it's probably why we have discussed this so many times so far. Hmmm, OK. I don't see why having a settings type internally prevents this simplified use case. Ivy tasks like retrieve with no explicit settings do then attempt to lookup the well known id for a default settings, and if not found instantiate the settings type from ivy.xml, register it using the default id with the project for other tasks to use, do their business, and that's it. You implicitly define the settings to support the old use case, but plug it into the task's addSettings method as if the user had defined it explicitly, hooking up to the new Ant-way model to pass settings to Ivy tasks. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)
On Fri, Mar 28, 2008 at 6:10 PM, Dominique Devienne [EMAIL PROTECTED] wrote: On Fri, Mar 28, 2008 at 11:50 AM, Xavier Hanin [EMAIL PROTECTED] wrote: [...] In Ivy original design I tried to make using Ivy as easy as possible. Hence if you want to use the default settings, and have an ivy file called ivy.xml in your basedir, then using Ivy is as simple as: ivy:retrieve / I think this has been appreciated by our users from the beginning of Ivy. Behind the scene, this is roughly equivalent to: ivy:configure / ivy:resolve / ivy:retrieve / This implies the use of a singleton behind the scene, no? Not really. It's just where the default value for id in configure is used. But it doesn't prevent from defining other instances with other id. But I don't know if people would complain if we were now using the settings as any other datatype in the Ant way. But I think that actually loading the settings only when they are used is counter intuitive... maybe because I'm too biased by usage of current Ivy design for more than 3 years now. So I think this is a difficult design choice: make Ivy more compliant with the Ant way, or keep a usage as it is used by some people for years, people who haven't complained about this point yet AFAIR. It's difficult to choose, and it's probably why we have discussed this so many times so far. Hmmm, OK. I don't see why having a settings type internally prevents this simplified use case. Ivy tasks like retrieve with no explicit settings do then attempt to lookup the well known id for a default settings, and if not found instantiate the settings type from ivy.xml, register it using the default id with the project for other tasks to use, do their business, and that's it. You're right. The difference between the task and datatype is mainly when the settings are loaded. And also how you can use them. You implicitly define the settings to support the old use case, Indeed. but plug it into the task's addSettings method as if the user had defined it explicitly, hooking up to the new Ant-way model to pass settings to Ivy tasks. --DD Yes, you're right. So I agree that to be really clean and follow the Ant way, settings should be a data type and we should support the three kind of uses of datatypes you referenced in your earlier e-mail. But this is kind of a big change in usage, so it's difficult to make such a change now that we are close to 2.0 final. 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/
Re: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)
On Fri, Mar 28, 2008 at 12:40 PM, Xavier Hanin [EMAIL PROTECTED] wrote: On Fri, Mar 28, 2008 at 6:10 PM, Dominique Devienne [EMAIL PROTECTED] Yes, you're right. So I agree that to be really clean and follow the Ant way, settings should be a data type and we should support the three kind of uses of datatypes you referenced in your earlier e-mail. But this is kind of a big change in usage, so it's difficult to make such a change now that we are close to 2.0 final. Sure, it's up to you and the Ivy community to decide what you want to do. The 3 uses I described are quite easy to implement, and there are tons of examples in Ant itself. Regarding nearing 2.0 final, I think it's never too late to do the right thing ;-) Especially when I'm not the one who has to do it ;-))) For 2.0 you may just want to make sure you don't have anything that would prevent you from refactoring the code in the future to support the better model we discussed. Cheers, --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)
Can't we just deprecate the id attribute on the settings task and use the settingsId attribute instead? ivy:settings settingsId=my.settings / instead of ivy:settings id=my.settings / Maarten - Original Message From: Xavier Hanin [EMAIL PROTECTED] To: Ant Developers List dev@ant.apache.org Sent: Friday, March 28, 2008 4:31:42 PM Subject: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?) On Fri, Mar 28, 2008 at 4:08 PM, Dominique Devienne [EMAIL PROTECTED] wrote: On Fri, Mar 28, 2008 at 8:00 AM, Xavier Hanin [EMAIL PROTECTED] wrote: On Fri, Mar 28, 2008 at 1:23 PM, Gilles Scokart [EMAIL PROTECTED] wrote: +1 for me as well (let's put a little bit more presure from the Ivy guys ;-). To come back to the impact on Ivy, I think we should put a note in our doc saying that using the settings task with an id requires 1.7.1. We can put a reference to the bug, the problem occurs only when you call ant with multiple targets, each depending on the same settings, so I think people can use Ivy settings with with ant 1.7.0 without running into the problem. For the record, I think it's bad Ant style to use ids in tasks. This is kept around for BC, but should be discouraged. Using ids on types OTOH is OK, and essential to types in fact. If a task should refer to part of another task's internal config, this hints to the config needing to be its own type referred to by both tasks. It's even OK for the type to be implicitly created by the first task, when it receives for example a configid=foo attribute, so that the second task can use it using configrefid=foo or a nested config refid=foo /. I'm not sure how Ivy does it exactly, but somehow I got the feel from the discussions that it's using the deprecated id'd task pattern, which is a bad pattern IMHO. Hopefully I got the wrong feeling ;-) I think we use that bad pattern. We've been wondering about the best form settings should take for a while. It used to be a datatype in 2.0 alpha, but we were running into trouble because a datatype has no lifecycle. Hence in a discussion Peter suggested to make it a task, using the id as we did before for the datatype but with a default value: http://markmail.org/message/52hqry734myzopts This works pretty well from a user point of view who don't really know if it's a task or datatype and don't really care. Except that we run into this bug, and this bad pattern. So, what would you suggest? Is there something we could do better while still preserving the behaviour we have now? Xavier --DD - 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]
Re: Ivy settings id (was Re: Merge 641903 from trunk to 1.7 branch?)
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. And that doesn't change the fact that settings should be a datatype rather than a task. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
