Re: Property expansion in macrodef attributes
On 2012-02-12, Jesse Glick wrote:
On 02/12/2012 05:13 AM, Stefan Bodewig wrote:
I'm not sure whether the macrodef writer will always know whether she
wants double-expansion or not.
I would say that if you come across a problem like that mentioned in
#42046 then you know you do not want double expansion and should
explicitly turn it off.
Most likely you don't want double expansion in most cases.
In most cases the script calling the macro will be the same as the
script defining it, or at least located in the same project, so I
doubt documentation of the macrodef is an issue;
The biggest problem I see is AntUnit. Here the macro is defined in a
different place and we'd need a new release that requires Ant 1.8.3 to
fix it.
Right now I'm inclined to revert to the behavior of Ant 1.8.2 for the
1.8.x branch, add the attribute to trunk but make trunk's behavior
default to not expand ${} twice (flagging it as breaking BWC).
though discoverability of the flag in the macrodef task may be poor
even with a FAQ entry.
Agreed.
If this problem had been noticed when macrodef was first introduced,
then single expansion would be the more intuitive behavior, especially
if #29347 were fixed properly so that ${thing.${choice}} works the way
people expect it to, but it is too late to change the default behavior
of macrodef.
I'm with Matt in that property helpers already provide the foundation
for a solution and the props Antlib (anybody wants to cut a release?)
implements it.
I also understand Ant users don't like to add more dependencies,
something to keep in mind if we ever want to redesign Ant.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: Regarding exec task
On 2012-02-12, Vimil Saju wrote: So I thought of somehow extending the 'Execute' class of ant to use the functionality of this 3rd party library, but I find that its difficult if not impossible to extend this class. It has certainly not been designed for this, no. Is it possible to make the Execute class in ant extensible so that it becomes possible to plugin our own implementation of Process class. If you had a way to provide your own CommandLauncher then you could wrap Execute's default choice with your own implementation and return a Process class of your liking. This is not possible today, but I'm testing whether this would be enough for you. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Regarding exec task
Thanks Stefan, Your help is very much appreciated. Would using a custom CommandLauncher make it possible for all the built-in ant tasks that support fork attribute to use it. I was thinking of an approach similar to how ant allows property expansion to be customized. By just adding our own custom PropertyHelper we can change how properties are expanded globally. If we have something like that for processes too, it would be great. I'd like to write a patch for this if possible, but I'd like to know the best way to implement it, without breaking anything else. My idea was to provide something like ProcessHelper class that can be stored as a reference in the project. The Execute class then calls this class to get an appropriate Process implementation. This ProcessHelper class should then have the ability to provide a default Process implementation as well as a mechanism to delegate process creation to a user-defined class. Thanks again. Vimil From: Stefan Bodewig bode...@apache.org To: dev@ant.apache.org Sent: Tuesday, February 14, 2012 4:46 AM Subject: Re: Regarding exec task On 2012-02-12, Vimil Saju wrote: So I thought of somehow extending the 'Execute' class of ant to use the functionality of this 3rd party library, but I find that its difficult if not impossible to extend this class. It has certainly not been designed for this, no. Is it possible to make the Execute class in ant extensible so that it becomes possible to plugin our own implementation of Process class. If you had a way to provide your own CommandLauncher then you could wrap Execute's default choice with your own implementation and return a Process class of your liking. This is not possible today, but I'm testing whether this would be enough for you. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Regarding exec task
On 2012-02-14, Vimil Saju wrote: Your help is very much appreciated. Would using a custom CommandLauncher make it possible for all the built-in ant tasks that support fork attribute to use it. Right now Execute uses a static CommandLauncher instance which is initialize inside the static initializer (class constructor). CommandLauncher's responsibility is tro create the Process instances. We don't have a way to make Execute use a different CommandLauncher, but if there was (like using the ProcessHelper you describe) then it would be used by all Execute instances - or we could make it so. I was thinking of an approach similar to how ant allows property expansion to be customized. By just adding our own custom PropertyHelper we can change how properties are expanded globally. If we have something like that for processes too, it would be great. I'd like to write a patch for this if possible, but I'd like to know the best way to implement it, without breaking anything else. That's great. My idea was to provide something like ProcessHelper class that can be stored as a reference in the project. The Execute class then calls this class to get an appropriate Process implementation. I'm not sure about the name ProcessHelper when CommandLauncher is already there, but I'm not good at names either. One thing you must keep in mind is Execute may not have access to a Project instance at all - it may know about one if setAntRun has been used, but using that is somewhat optional. Also some methods in Execute are static and don't provide a Project. There need to be usable defaults for this case. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
On 2012-02-13, Bruce Atherton wrote: I spent some time starting to implement a very simple (only a few tasks) new version of Ant that started from Java 7. Personal issues have taken me out of the game for a while, but I've still been wondering, could Java 7 and NIO 2.0 be a good reason to create Ant 2.0? There are things in NIO2 that can be added via FileUtils one way or the other, but it could also make us rethink our concept of Resources (although nio2's Path looks too limited for that). If we really want to take the burden of redesigning Ant on us then it certainly wouldn't only be NIO2 but also revolutionary things like generics. OTOH there will always be a reason to wait longer (lambdas, modules). I fully understand that throwing away the existing cruft can set free new energy. Personally I enjoy working on the Commons Antlib way more than working on the built-in Zip/Tar tasks because I could design them from a fresh start while the later have accumulated features with big care for API backwards compatibility. To me the strength of Ant (as it is) is in its tasks. The tasks are proven pieces of code that have been tested by an incredibly big amount of people. And even if we have about 200 bug reports open, most tasks do what they are supposed to do and do so very well. Any rewritten Ant would have a long way to reach the same level of stability. The same is true for the Compress Antlib vs the core tasks, of course. It could be a way to sweep away the kind of cruft that is holding up the release and to redesign Ant to reflect all the lessons learned about how to build software in the last 10 years. This will lead us to the discussion of what Ant2 would be. A rewritten Ant that remains compatible (or mostly so) on the build file level or something quite different? Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Property expansion in macrodef attributes
On 02/14/2012 07:39 AM, Stefan Bodewig wrote:
Most likely you don't want double expansion in most cases.
Right, but how often would you even notice the difference? Usually property values do not themselves contain interpolable variables, as seen by the fact that this problem
has just been reported twice since macrodef was introduced.
The biggest problem I see is AntUnit. Here the macro is defined in a
different place and we'd need a new release that requires Ant 1.8.3 to
fix it.
True; so release a new AntUnit - a much smaller user audience than Ant itself I
suppose.
add the attribute to trunk but make trunk's behavior
default to not expand ${} twice (flagging it as breaking BWC)
This would cause a major problem for the many scripts out there which rely on the current behavior. They could not run unchanged on 1.9 (and few people will find this
item in the release notes, much less understand its implications); nor could they be fixed in advance, since the attribute would be rejected by 1.8.x.
-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
On Tue, Feb 14, 2012 at 8:13 AM, Stefan Bodewig bode...@apache.org wrote: On 2012-02-13, Bruce Atherton wrote: I spent some time starting to implement a very simple (only a few tasks) new version of Ant that started from Java 7. Personal issues have taken me out of the game for a while, but I've still been wondering, could Java 7 and NIO 2.0 be a good reason to create Ant 2.0? There are things in NIO2 that can be added via FileUtils one way or the other, but it could also make us rethink our concept of Resources (although nio2's Path looks too limited for that). If we really want to take the burden of redesigning Ant on us then it certainly wouldn't only be NIO2 but also revolutionary things like generics. OTOH there will always be a reason to wait longer (lambdas, modules). I fully understand that throwing away the existing cruft can set free new energy. Personally I enjoy working on the Commons Antlib way more than working on the built-in Zip/Tar tasks because I could design them from a fresh start while the later have accumulated features with big care for API backwards compatibility. To me the strength of Ant (as it is) is in its tasks. The tasks are proven pieces of code that have been tested by an incredibly big amount of people. And even if we have about 200 bug reports open, most tasks do what they are supposed to do and do so very well. Any rewritten Ant would have a long way to reach the same level of stability. The same is true for the Compress Antlib vs the core tasks, of course. It could be a way to sweep away the kind of cruft that is holding up the release and to redesign Ant to reflect all the lessons learned about how to build software in the last 10 years. This will lead us to the discussion of what Ant2 would be. A rewritten Ant that remains compatible (or mostly so) on the build file level or something quite different? It would be very beneficial to have Ant 2 remain compatible at the build file level if for no other reason than to facilitate testing of v2 tasks: AntUnit-based tests should continue to pass, and as we've seen, the vast majority of Ant's unit tests are expressible in the AntUnit style. Agreed that a v2 could allow us to cast off accumulated baggage. The core of the redesign would be the most important thing to get right. I suspect that the concept of a Resource would be closer to the core (hindsight and all that) and would be interface-based. TBH, I've never looked closely at nio1, let alone 2, until just now, but after a quick look at java.nio.file.Path I confess that I don't immediately see what it lacks that we would need. Matt Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
On 2/14/2012 6:13 AM, Stefan Bodewig wrote: This will lead us to the discussion of what Ant2 would be. A rewritten Ant that remains compatible (or mostly so) on the build file level or something quite different? My opinion. I think we need at least an option for being backwards compatible at the build file level and it should be the default for quite a while after an initial 2.0 release. I'd hope, though, that a redesign would have a fully pluggable parser so that even with the first release there was an option to use something other than XML. I actually think build file compatibility should be a feature of the first alpha. Here is how I thought it might be achieved using the change in namespace that would allow Ant1 and Ant2 to coexist: Phase 1: Ant 2 handles a tag if it knows how, otherwise passes it to Ant 1. Originally all the infrastructure would call Ant 1 but that would gradually change as more facilities were developed for Ant 2. Phase 2: Ant 2 can do most things, but there are a few concepts and tags that are foreign to it that it needs to pass to Ant 1. Ant 1 comes with Ant 2 but only in the bootstrap form. Phase 3: Ant 2 can emulate enough of Ant 1 that it isn't necessary to ship it, but it is an option for those who want to run in compatibility mode or use an ant-one tag or similar. Basically I am talking about an aggressive refactoring with no thought to backwards API compatibility. That compatibility has tied our hands from doing a real refactoring for a decade. I agree with you that our tasks are fully debugged. They should be reused as much as possible. I would imagine that as far as tasks were concerned, a simple massaging before moving them to a new package would be all that was required, to take away cruft and to use a new style for defining tasks. And to move calls to the infrastructure over to the new one. What I started to implement was to make everything that is visible in a build file an immutable property, tasks and selectors and conditions, everything. They would all be POJOs with annotations to indicate how they are exposed to the dependency tree. The annotations would be a dependency on Ant that may not be desirable or possible for legacy classes, so a base proxy class could be extended to provide the annotations and automatically call into a reference POJO for behaviour. Creating a PropertyProxy from the POJOs to make them immutable could likewise be done. Any @Modifiable method on the Task would simply not do anything or throw an exception. Making everything a property would have an effect on what immutable means. It would mean that it was not the value of the property that was immutable, but the behaviour. So calling tstamp would always set TSTAMP to the current time, and the available task and condition would return true or false depending on whether a file exists at this point in the build. Given how dependencies are currently resolved I can't think of a way this change would affect the ordering of the build. Of course if you set the value to an Ant1 style property the value becomes immutable, so backward compatibility would be maintained. Some might not like this change. Personally, before macros I found far too many time1, time2, thisfileexists1 in my build files. After, the fact I have to create macros to handle this basic functionality is just an irritant. But it is an irritant I would love to see removed from our lives. Anyway, those are my thoughts on backward compatibility. I would love to see more discussion about this. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
On 2/13/2012 2:55 PM, Jesse Glick wrote: On 02/13/2012 01:25 PM, Bruce Atherton wrote: could Java 7 and NIO 2.0 be a good reason to create Ant 2.0? While the new java.nio.file.* APIs are indeed valuable for a tool like Ant, I hardly think a fork or major rewrite is required to take advantage of them. As Stefan pointed out, it would be as easy as creating a new FileUtils subclass, and for now compiling it conditionally. Required, no. If there is not enough interest in creating an Ant 2 then everything will be fine staying with Ant 1.x. We've been doing it through massive changes in the Java libraries and we can keep doing it the same way. If there aren't enough people interested in doing the work then we should just drop it. But I've talked about a few of the advantages I see in dropping backward API compatibility and doing a major refactoring. Let me list a few more. My biggest problem with Ant is the many ways that files are dealt with. It is all over the map. This isn't anyone's fault, it happened because of hysterical porpoises, but both our users and ourselves have to deal with the fallout. Users have to deal with understanding the differences between paths and filelists and filesets and dirsets and resources. They have to come to grips with how include and exclude don't work like selectors. Filters aren't much better since there are different ways that they can work. We have it a bit easier because under the covers most things have been normalized. Resources, for example. But thanks to API compatibility that brings its own problems. For example, we have two completely separate yet very similar set of classes for Selectors, one for FileSelectors and one for ResourceSelectors. Fix a bug in one, did you remember to fix it in the other? Does it matter if users of the FileSelector APIs still have the bug? Or look at the utility classes. How many methods, or lines of extra code in methods that should be relatively simple, are devoted to dealing with edge cases and these hangers on from our past? All of these things were an itch bad enough that I started to scratch it, but for now I won't be doing any coding at all for a while. Maybe, though, there are others who are as bothered by these things as I am who are looking for a scratching post. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
