Re: Ant properties access based Object notation rather than script based
Tried to use this feature of nightly build of ant 1.8 and understand that still there is a issue in custom tasks. Is there a replacement for Variable task of ant contrib as Variable task is not adopted to ant 1.8 Property helpers and hence the interface methods are not called yet. Regards, Nagendra -- View this message in context: http://old.nabble.com/Ant-properties-access-based-Object-notation-rather-than-script-based-tp26688713p26708490.html Sent from the Ant - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AW: Does Anybody Have Some Unfinished Work for 1.8.0?
is anybody working on something that should go into 1.8.0 or could we start thinking about doing that release thingy more or less right now? I try to migrate the autoconf to use IntrospecitionHelper. But I wouldnt see that as Showstopper ... Jan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ant properties access based Object notation rather than script based
On 2009-12-08, Raja Nagendra Kumar nagendra.r...@tejasoft.com wrote: Stefan, are there any time line for 1.8.. I see many people asking the same thing but no clear answer we see. Like in most open source projects, the answer to any such question is when it's done. In the case of Ant 1.8.0 it looks as if we have one remaining feature to agree on - so we get it right before it is out in the wild and needs to be supported in the future. This shouldnt take too long so I hope we'll be able to start the whole release procedure which involves quite a bit more than just saying here it is before christmas. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ant properties access based Object notation rather than script based
On 2009-12-09, Raja Nagendra Kumar nagendra.r...@tejasoft.com wrote: Is there a replacement for Variable task of ant contrib as Variable task is not adopted to ant 1.8 Property helpers and hence the interface methods are not called yet. It should be possible to write a PropertyHelper implementation that acts like the variable task. See what the implementation for local properties does, this is way more complex than making properties mutable. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Maybe we should open up depends for all targets [again]
Well, the title of this mail is referencing [1], as announced I was thinking that we should, but after gathering my ideas and writing this email, I am not so sure. So was introduced lately the concept of target group in Ant. I found it quite interesting as it would help writing sharable ant script, just as it is used in EasyAnt. I have a build system to maintain, shared between several different kind of project, simple java ones, webapp ones, flex app ones, flex lib ones, webservice ones, etc... All of these projects share the same release process and dependency management (Ivy of course ;) ). So I have a common-build.xml, a common-build-java.xml, a common-build-webapp.xml, a common-build-flex, etc... There is some sort of inheritance between those build scripts: common-build-java.xml depends on common-build.xml, common-build-webapp.xml depends on common-build.java, etc... I have a dist target in common-build which expect things to be build before being published with Ivy. Then in common-build-java I have targets to build jars, and dist is overridden so dist depends on the targets that build jars: target name=dist depends=jar,sources,common-build.dist / In common-build-webapp dist is overridden so it depends on the target that build a war. In common-build-flex dist is overridden so it depends on the target that build a swf. And here comes the trouble: multi inheritance doesn't work well. If I have a webapp project that require some flex to be build, here comes the mess. Depending of the order of import of common-build-webapp.xml and common-build-flex.xml, either the flex will be published, either the war. I have to override dist in the project's build.xml so it explicitly call the build of the java, the swc and the war. Here would help target group. If I define dist a target group, everything will then work fine. And I think that attaching a target to a target group is a way more proper than overriding targets, as it doesn't change any dependency declared between targets in common-build, it just adds new ones. If I focus on seeing an Ant build script as a DAG (direct acyclic graph), properly overriding a DAG seems to me just adding new edges and targets, not changing them. And many overriding (which we can see as multi inheritance) can apply without interacting. Adding targets to the dependency of another target (as target groups do) seems to be the way to go. But using target groups expect me to know which part of the common-build can be extended. And I got every day some new need on some project that require a specific move in the common-build workflow. On the other hand, if I today look closely to the 2200 lines of the common build files I maintain, I have very few targets that I need to be changed as a target group. And for most of them, they are already empty of tasks. The actual heavy customization required by some project, are done in the project itself. In the project itself I don't need to care about reusability or extension, so target overriding is fine. To conclude, I don't know if opening up targets dependency can be that useful, I don't know if there is real use case where you want a spaghetti of target dependencies to be opened to a third party. Maybe it is better to explicit where target dependencies can be injected by using a special element, the target groups. Now thinking loud, maybe a simple attribute on target like dependencies=public would also fit ? Nicolas [1] http://old.nabble.com/Maybe-we-should-open-up-%22depends%22-for-all-targets-p20603861.html - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
import and include in trunk
Hi, this mail is just summarizing the changes we've made so people can yell now before we release anything if anything is wrong. import has a few changes: * the importing build file can determine the target prefix of the imported targets (it still defaults to the imported project's name) * the importing build file can override the character(s) separating the prefix and the target name (it still defaults to .) * it can import multiple resources in one task * it can import any file- or URL-providing resource (javaresource provides URLs). And we've added a new task include which is similar to import with the following differences: * target names are always prefixed, they are not additionally available by their plain name outside of the included build file. * the depends-attribute of an included target is rewritten to use prefixed target names. This means an included build file is self-contained and you always know which targets will be executed. There is no target-overriding. * a resource can be included more than once if you use different prefixes. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
target-group in trunk
Hi, this is just a description of what target-group in trunk currently is and what it is not. I'll describe the implementation rather than the initial phase concept as it is implemented in EasyAnt which uses a custom ProjectHelper to implement its slightly different concept. This mail serves as background in addition to the thread Nicolas has started. A target-group is basically a target with two differences: * must be empty * its depends list can be added to during parse time. Other targets and target-groups can declare themselves as part of the group and get added to the group's depends list. That's all. Order of execution is still only determined by the depends attributes of all targets. For anybody running a build target-groups are just like targets. They are listed together with targets in -projecthelp and create BuildEvents and log output of targets. A target-group is not a container of targets. It doesn't provide a grouping in a sense that a target would be executed as part of a group - the depends lists of all targets and target-groups still determine the order. Since a target-group is always empty, the if and unless attributes don't have any effect at all. Of course we could change the implementation to get to a more composite-like implementation - making if and unless useful and maybe introduce new build events - it is just not clear (to me) whether the additional effort would provide anything more useful. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ant properties access based Object notation rather than script based
true, project.setProperty() does allow overides and setNewProperty() is read only/set only once method. Regards, Nagendra -- View this message in context: http://old.nabble.com/Ant-properties-access-based-Object-notation-rather-than-script-based-tp26688713p26722475.html Sent from the Ant - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
