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 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 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 > >
Re: Fixing some naming inconsistencies in Ivy
I like the enumeration syntax, like descriptor="required | otpional", it's much more readable and it will probably allow us to have less attributes on some of the tasks. Maarten - Original Message From: Xavier Hanin <[EMAIL PROTECTED]> To: Ant Developers List Sent: Saturday, March 29, 2008 10:09:23 AM Subject: Re: Fixing some naming inconsistencies in Ivy Just pinging about this e-mail, I've had no answer so far, I think I can't make the choice alone, and we need to deal with that question before 2.0final to close IVY-297. So, anyone has an opinion about this: On Fri, Feb 29, 2008 at 12:31 PM, Xavier Hanin <[EMAIL PROTECTED]> wrote: > Hi, > > As reported by IVY-297, Ivy suffers from some name inconsistencies and > strange attribute names. Ivy 2.0 is a good opportunity to fix some of > them, since I think we can afford some more deprecation warnings. > > So I'd like to fix IVY-297 by marking allownomd as deprecated, and > providing a descriptor="required | optional" attribute. > > To go further, we could rename the attribute skipbuildwithoutivy in > buildlist in skipbuildwithoutdescriptor, or even better change it to > buildwithoutdescriptor="skip | fail | warn | tail | head", which wold make > it both more readable and more powerful. > > Another area where the name 'ivy' is used to talk about module descriptors > in general is patterns. This lead to some strange settings, where you give > an 'ivy' pattern to tell where the poms are. In this case I think we could > support both 'ivy' and 'descriptor' (for resolver patterns for instance), > since the use case for ivy files is still predominant, so I don't think > deprecating the old name would really be better. > > So, what do you think about these changes? > > Xavier > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping - 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 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 > 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 > > depreca
IvyDE source headers
Hi, I am adding missing Apache License headers in the sources files of IvyDE. In some file [1] there is: Copyright Jayasoft 2005 - All rights reserved Can I assume that I can replace them safely with the Apache License ? Nicolas [1] https://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/src/java/org/apache/ivyde/eclipse/ui/console/IvyConsole.java - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IvyDE source headers
On Mon, Mar 31, 2008 at 3:25 PM, Nicolas Lalevée < [EMAIL PROTECTED]> wrote: > Hi, > > I am adding missing Apache License headers in the sources files of IvyDE. > In > some file [1] there is: > > Copyright Jayasoft 2005 - All rights reserved > > Can I assume that I can replace them safely with the Apache License ? Sure, Jayasoft donated all the code to the ASF, I simply forgot to update headers in IvyDE. BTW, I wrote a small ruby script to add license headers to Ivy. Feel free to use it if you need: http://xhab.blogspot.com/2007/03/adding-license-header-to-whole-code.html Xavier > > > Nicolas > > [1] > > https://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/src/java/org/apache/ivyde/eclipse/ui/console/IvyConsole.java > > - > 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?)
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 > > 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 th
Re: IvyDE source headers
Le lundi 31 mars 2008, Xavier Hanin a écrit : > On Mon, Mar 31, 2008 at 3:25 PM, Nicolas Lalevée < > > [EMAIL PROTECTED]> wrote: > > Hi, > > > > I am adding missing Apache License headers in the sources files of IvyDE. > > In > > some file [1] there is: > > > > Copyright Jayasoft 2005 - All rights reserved > > > > Can I assume that I can replace them safely with the Apache License ? > > Sure, Jayasoft donated all the code to the ASF, I simply forgot to update > headers in IvyDE. BTW, I wrote a small ruby script to add license headers > to Ivy. Feel free to use it if you need: > http://xhab.blogspot.com/2007/03/adding-license-header-to-whole-code.html Great ! thanks, Nicolas > > Xavier > > > Nicolas > > > > [1] > > > > https://svn.apache.org/repos/asf/ant/ivy/ivyde/trunk/src/java/org/apache/ > >ivyde/eclipse/ui/console/IvyConsole.java > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] -- Nicolas LALEVÉE ANYWARE TECHNOLOGIES Tel : +33 (0)5 61 00 52 90 Fax : +33 (0)5 61 00 51 46 http://www.anyware-tech.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 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 > > > 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 > > > dependen
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]
