RE: Overridable targets?
Thanks. I knew it was a feasible idea. -Original Message- From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 10:05 AM To: [EMAIL PROTECTED] Subject: Re: Overridable targets? Steve Cohen wrote, On 06/06/2003 16.54: > Here is a radical idea that I'd like to kick around a little. > > The prohibition against more than one target of the same name in the > same build script seems logical, but it impedes a form of reuse that I > think would be very handy to use. It is already done in the task that is in CVS for Ant 1.6. So no more entity includes but a task to include other buildfiles, also with target override, and "super" target calling, so you can basically "extend" the imported target. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - 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: Overridable targets?
A propos, Nicola, and Costin In the path docs/manual/CoreTasks of the ant CVS, there is some room between gzip.html and input.html for ... guess what. Antoine - Original Message - From: "Nicola Ken Barozzi" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, June 06, 2003 5:04 PM Subject: Re: Overridable targets? ... > It is already done in the task that is in CVS for Ant 1.6. > So no more entity includes but a task to include other buildfiles, also > with target override, and "super" target calling, so you can basically > "extend" the imported target. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Overridable targets?
Steve Cohen wrote, On 06/06/2003 16.54: Here is a radical idea that I'd like to kick around a little. The prohibition against more than one target of the same name in the same build script seems logical, but it impedes a form of reuse that I think would be very handy to use. It is already done in the task that is in CVS for Ant 1.6. So no more entity includes but a task to include other buildfiles, also with target override, and "super" target calling, so you can basically "extend" the imported target. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Overridable targets?
Personally I'd find this very useful, our Ant script started off quite small with limited uses. But like most things in software it soon became a victim of its own success and soon became quite unwieldy. Obviously this was down to our lack of fore throught. We currently use Ant calls to separate documents, but in reality overridable targets would have made our life allot easier. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 06 June 2003 17:13 To: [EMAIL PROTECTED] Subject: RE: Overridable targets? We are currently using a modified version of ant to do this. It basically provides the functionality to override target in sub builds (with the ant task). We use it so that projects can be built independently or as a sub project of another project using the same build.xml file. This allows you to redefine or set a sub project target to a no-op. I posted a long description of why we did this and why we felt it was necessary a couple months ago on this list if you want to look at the archives or I can dig it up and repost if you want. Tim Tye -Original Message- From: Steve Cohen [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 9:54 AM To: [EMAIL PROTECTED] Subject: Overridable targets? Here is a radical idea that I'd like to kick around a little. The prohibition against more than one target of the same name in the same build script seems logical, but it impedes a form of reuse that I think would be very handy to use. If you include one build file within another (using ENTITY inclusion mechanism) and you want to use all the targets in the included file except one, which you would like to replace with a slightly different functionality, and that target is called by another in the INCLUDED file, you have to go through a lot of annoying stuff using if, unless, etc. and perform redesigns on your script that render it far less clear and less readable. In many ways it feels like a straitjacket. SO... what if... targets followed the same rule as properties That is, if two targets with the same name are found in one build script (after inclusions performed), the first is used and the second discarded (instead of as now, when this throws an error). Then you could include your generic bag of generally useful targets, but redefine one "inner" target differently, to customize a particular build outside of the generic pattern in some way. The rule against two targets with the same name is an ant rule, not an xml rule, so this is in theory doable. It doesn't seem like it would break that much because this has never been allowed before, there is no previous set of semantics working against it against which backward compatibility must be preserved. There is probably some reason why this cannot work but I can't think of it, so I will throw it out to the group for discussion. Have at it! Please, though, not too hard. :-) -- Steve Cohen Sr. Software Engineer Sportvision Inc. [EMAIL PROTECTED] http://www.sportvision.com - 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: Overridable targets?
We are currently using a modified version of ant to do this. It basically provides the functionality to override target in sub builds (with the ant task). We use it so that projects can be built independently or as a sub project of another project using the same build.xml file. This allows you to redefine or set a sub project target to a no-op. I posted a long description of why we did this and why we felt it was necessary a couple months ago on this list if you want to look at the archives or I can dig it up and repost if you want. Tim Tye -Original Message- From: Steve Cohen [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 9:54 AM To: [EMAIL PROTECTED] Subject: Overridable targets? Here is a radical idea that I'd like to kick around a little. The prohibition against more than one target of the same name in the same build script seems logical, but it impedes a form of reuse that I think would be very handy to use. If you include one build file within another (using ENTITY inclusion mechanism) and you want to use all the targets in the included file except one, which you would like to replace with a slightly different functionality, and that target is called by another in the INCLUDED file, you have to go through a lot of annoying stuff using if, unless, etc. and perform redesigns on your script that render it far less clear and less readable. In many ways it feels like a straitjacket. SO... what if... targets followed the same rule as properties That is, if two targets with the same name are found in one build script (after inclusions performed), the first is used and the second discarded (instead of as now, when this throws an error). Then you could include your generic bag of generally useful targets, but redefine one "inner" target differently, to customize a particular build outside of the generic pattern in some way. The rule against two targets with the same name is an ant rule, not an xml rule, so this is in theory doable. It doesn't seem like it would break that much because this has never been allowed before, there is no previous set of semantics working against it against which backward compatibility must be preserved. There is probably some reason why this cannot work but I can't think of it, so I will throw it out to the group for discussion. Have at it! Please, though, not too hard. :-) -- Steve Cohen Sr. Software Engineer Sportvision Inc. [EMAIL PROTECTED] http://www.sportvision.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Overridable targets?
I can see that that would work, but it seems to be more difficult than what I am proposing. You have to make sure that EVERY build file that includes your generics defines the changeable behavior, and you can't have a overridable default implemenation in the generic file. Or am I missing something. -Original Message- From: Matt Smith [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 10:05 AM To: Ant Developers List; [EMAIL PROTECTED] Subject: RE: Overridable targets? I have implemented this in ant 1.5.1 and 1.5.3 and have been using for multiple projects without issue. I have cascaded build files throughout each of my projects, and each build file has a set of common targets with are included in the project specific buildfiles via the XML ENTITY. I also allow project to overloaded so that you can include a completely separate buildfile in a target and use am using it to define project dependencies in a hierarchical way! Works Great! Matt -Original Message- From: Steve Cohen [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 9:54 AM To: [EMAIL PROTECTED] Subject: Overridable targets? Here is a radical idea that I'd like to kick around a little. The prohibition against more than one target of the same name in the same build script seems logical, but it impedes a form of reuse that I think would be very handy to use. If you include one build file within another (using ENTITY inclusion mechanism) and you want to use all the targets in the included file except one, which you would like to replace with a slightly different functionality, and that target is called by another in the INCLUDED file, you have to go through a lot of annoying stuff using if, unless, etc. and perform redesigns on your script that render it far less clear and less readable. In many ways it feels like a straitjacket. SO... what if... targets followed the same rule as properties That is, if two targets with the same name are found in one build script (after inclusions performed), the first is used and the second discarded (instead of as now, when this throws an error). Then you could include your generic bag of generally useful targets, but redefine one "inner" target differently, to customize a particular build outside of the generic pattern in some way. The rule against two targets with the same name is an ant rule, not an xml rule, so this is in theory doable. It doesn't seem like it would break that much because this has never been allowed before, there is no previous set of semantics working against it against which backward compatibility must be preserved. There is probably some reason why this cannot work but I can't think of it, so I will throw it out to the group for discussion. Have at it! Please, though, not too hard. :-) -- Steve Cohen Sr. Software Engineer Sportvision Inc. [EMAIL PROTECTED] http://www.sportvision.com - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Overridable targets?
I have implemented this in ant 1.5.1 and 1.5.3 and have been using for multiple projects without issue. I have cascaded build files throughout each of my projects, and each build file has a set of common targets with are included in the project specific buildfiles via the XML ENTITY. I also allow project to overloaded so that you can include a completely separate buildfile in a target and use am using it to define project dependencies in a hierarchical way! Works Great! Matt -Original Message- From: Steve Cohen [mailto:[EMAIL PROTECTED] Sent: Friday, June 06, 2003 9:54 AM To: [EMAIL PROTECTED] Subject: Overridable targets? Here is a radical idea that I'd like to kick around a little. The prohibition against more than one target of the same name in the same build script seems logical, but it impedes a form of reuse that I think would be very handy to use. If you include one build file within another (using ENTITY inclusion mechanism) and you want to use all the targets in the included file except one, which you would like to replace with a slightly different functionality, and that target is called by another in the INCLUDED file, you have to go through a lot of annoying stuff using if, unless, etc. and perform redesigns on your script that render it far less clear and less readable. In many ways it feels like a straitjacket. SO... what if... targets followed the same rule as properties That is, if two targets with the same name are found in one build script (after inclusions performed), the first is used and the second discarded (instead of as now, when this throws an error). Then you could include your generic bag of generally useful targets, but redefine one "inner" target differently, to customize a particular build outside of the generic pattern in some way. The rule against two targets with the same name is an ant rule, not an xml rule, so this is in theory doable. It doesn't seem like it would break that much because this has never been allowed before, there is no previous set of semantics working against it against which backward compatibility must be preserved. There is probably some reason why this cannot work but I can't think of it, so I will throw it out to the group for discussion. Have at it! Please, though, not too hard. :-) -- Steve Cohen Sr. Software Engineer Sportvision Inc. [EMAIL PROTECTED] http://www.sportvision.com - 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]
