Re: target-group committed
I was asking to myself the same question : why only 2 levels? I think you are right, we don't need different type of targets, what we should have is a new type of relationship between targets : the PartOf relationship that allow to plug a 'lower' level target INTO an other target. But for the idea of numerical level, I think it is going too far into a strict layer decomposition. This might be too restrictive. Having a PartOf relationship allow to do strict layering elegantly, but there might be other usage to partOf. If the only benefits of a numerical layer is to hava a -p1 .. -pn options, then I think the benfit is too limited. Gilles 2008/11/25 Bruce Atherton [EMAIL PROTECTED]: I am in the same boat as Stefan. I also don't understand yet why target-groups are not just targets to the person running Ant. What you appear to be arguing here is that there should be two levels to Ant targets. But why just two? Why not three or four or five? I've written build systems this way in the past. Here is an example: Level 1 = top level targets that span multiple modules, depend on level 2 targets and add timestamps to logs. Description defined. Level 2 = top level targets for a specific module, depend on level 3 targets and add timestamps to logs. Description defined. Level 3 = more granular targets that encapsulate reusable sets of behaviour, depend on level 3 and 4 targets. No description. Level 4 = fine-grained targets, depend only on initialization targets. Used when you know exactly the state of your environment and want to do something specific with no time wasted, like in a developer sandbox. Description defined. Level 5 = initialization targets. No description. I used naming conventions for targets to differentiate the levels. For example, level 4 targets all ended with -only to indicate there were few dependencies being run. There are other solutions, though. Perhaps targets could have a level attribute and -projecthelp could take an optional numeric parameter to indicate the level you want to see. Someone building a module could run ant -p2 to find out which targets were available to them. A developer could run ant -p4. To make things more user-friendly, EasyAnt could define a standard set of levels and name them rather than using numbers. That is just one idea. Regardless, I think a more general solution would be better than treating target-groups in a special way, or even worse by adding target-parts to the mix. But then again, I may be missing something. Jean-Louis BOUDART wrote: I agree with Xavier a target-group is something at a higher level than a target. I think that the key feature of target-group is dependency injection but as Xavier says if thread-group is the only way to have target dependency injection, then people may use it only for that, and complain about the distinction in project help. The fact is target-group is not only a way to have dependency management, but a new way to think your build-script. I guess for us target-group is useful to make build modules easily reusable in a standard build (with standard target-group), without requiring any specific orchestration. This means target-group allow you to have a kind of generic target, that's why in EasyAnt we want to have separated help for generic targets (target-group) and specific target (normal target). In addition, as we use target-group to have more genericity we doesn't want to have prefix on those generic targets. - 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: CoreLoader not used for antlib typedef [Re: Launching unit test of antunit]
I still have move-test.xml failing. I tried on windows XP and on cygwin, with a JDK 1.6 and with 1.5. The antunit test is always failing. Did others have the problem? I already had some file-system issues on my machines when deleting files, (the delete of freshly created files were sometime failing, being ignored or being delayed). Maybe I have the same problem again... Gilles 2008/11/20 Gilles Scokart [EMAIL PROTECTED]: 2008/11/20 Stefan Bodewig [EMAIL PROTECTED]: On 2008-11-19, Gilles Scokart [EMAIL PROTECTED] wrote: I was thus thinking to provide this classpath using the project.setCoreLoader. But that didn't worked. Indeed, the coreLoader is not used when declaring antlib. Is coreLoader used at all? Anywhere? Yes, in a very few tasks : Which ressources and ExecuteJava (but only when no classpath is given) It is also used for the core ant tasks types. There are bugzilla issues talking about making it functional. I don't recall the details but think the core loader is the result of an unfinished experiment. It was what I was suspecting. There is indeed a lot of tasks that use Project.createClassLoader that was not considering the coreLoader. In parallel I wanted to ask feedback for such sensible change for which I can't really mesure all the impact. Classloader changes are dangerous, in particular since our unit tests don't cover many scenarios (and it would be difficult to do, you'd need lots of forked junits) and Gump uses a very specific construct so won't catch problems here. Oups, I was hoping Gump could help... Specialy for the different antlibs test suites. For your concrete patches I'll need more time to review before I comment. I can understand. Take your time. On my side, I managed to launch the unit test. I works at the exception of the antunit move-test.xml. But I guess it is related to cygwin (or java 1.6?). I will have a look to be sure. I have also rethink about the change. I feel that the change in BuildFileTest in maybe too intrusive and there is a risk of incompatibility, specialy if some test are testing things linked to classLoader. Maybe transfering the unit test classLoader into the project coreLoader should be optional, to reduce this risk. Also, in the componentHelper, the call definer.setAntlibClassLoader(project.getCoreLoader()); is useless with the change done in Project. I did it this change first to allow the automated antlib to be found, but then I realized that it still didn't worked for the declared typedef and I made the more impacting change in Project. -- Gilles Scokart -- Gilles Scokart - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CoreLoader not used for antlib typedef [Re: Launching unit test of antunit]
On 2008-11-26, Gilles Scokart [EMAIL PROTECTED] wrote: I still have move-test.xml failing. I tried on windows XP and on cygwin, with a JDK 1.6 and with 1.5. The antunit test is always failing. Did others have the problem? Never, neither on Windows/Cygwin nor on Linux. BTW, I thought you were talking about AntUnit's own test suite. To run Ant's AntUnit tests I simply invoke ./build.sh test and that's it. No fiddling with -lib or anything like that. I already had some file-system issues on my machines when deleting files, (the delete of freshly created files were sometime failing, being ignored or being delayed). Maybe I have the same problem again... Virus-Scanner? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: CoreLoader not used for antlib typedef [Re: Launching unit test of antunit]
2008/11/26 Stefan Bodewig [EMAIL PROTECTED]: On 2008-11-26, Gilles Scokart [EMAIL PROTECTED] wrote: I still have move-test.xml failing. I tried on windows XP and on cygwin, with a JDK 1.6 and with 1.5. The antunit test is always failing. Did others have the problem? Never, neither on Windows/Cygwin nor on Linux. BTW, I thought you were talking about AntUnit's own test suite. To run Ant's AntUnit tests I simply invoke I initially was. But I fall on the problem with this unit test while testing the patch for the coreLoader usage. ./build.sh test I found it,thanks. (it was easier to find ;-) ) and that's it. No fiddling with -lib or anything like that. I already had some file-system issues on my machines when deleting files, (the delete of freshly created files were sometime failing, being ignored or being delayed). Maybe I have the same problem again... Virus-Scanner? I already tried, I disbled all process and services I could... But the problem was still there. This is specialy visible in ivy unit tests that creates and deletes a lot of files. :-( One day, I will reinstall everything... Stefan - 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: target-group committed
Right. I see a part-of relationship of arbitrary depth as being best implemented using a Composite design pattern. A target-group is a composite for targets but is itself also a target. The level idea was only an example off the top of my head, but in thinking about it you are right that numeric levels would be a bad choice. The reason I thought of using numbers was so that the lower layers would implicitly contain the higher ones but it really is obscure and arbitrary from the users perspective. Another solution would be to create different interfaces onto the build file for different types of users running Ant. A visibility attribute on targets could be set to the names of interfaces that could be requested and would list that target if you ran Ant with the interface specified, e.g. -p=developer. You would need some new tag if you wanted extends behaviour, though. Yet another solution would be to add an attribute to allow stripping descriptions from imported and included targets. Then the user could write different top-level build files for different classes of users, each choosing which imported targets got to keep their descriptions. Or you could just live with the verbosity of the target list, like I did, and use naming conventions in EasyAnt. I'm sure there are many other ways to address the issue. Gilles Scokart wrote: I was asking to myself the same question : why only 2 levels? I think you are right, we don't need different type of targets, what we should have is a new type of relationship between targets : the PartOf relationship that allow to plug a 'lower' level target INTO an other target. But for the idea of numerical level, I think it is going too far into a strict layer decomposition. This might be too restrictive. Having a PartOf relationship allow to do strict layering elegantly, but there might be other usage to partOf. If the only benefits of a numerical layer is to hava a -p1 .. -pn options, then I think the benfit is too limited. Gilles 2008/11/25 Bruce Atherton [EMAIL PROTECTED]: I am in the same boat as Stefan. I also don't understand yet why target-groups are not just targets to the person running Ant. What you appear to be arguing here is that there should be two levels to Ant targets. But why just two? Why not three or four or five? I've written build systems this way in the past. Here is an example: Level 1 = top level targets that span multiple modules, depend on level 2 targets and add timestamps to logs. Description defined. Level 2 = top level targets for a specific module, depend on level 3 targets and add timestamps to logs. Description defined. Level 3 = more granular targets that encapsulate reusable sets of behaviour, depend on level 3 and 4 targets. No description. Level 4 = fine-grained targets, depend only on initialization targets. Used when you know exactly the state of your environment and want to do something specific with no time wasted, like in a developer sandbox. Description defined. Level 5 = initialization targets. No description. I used naming conventions for targets to differentiate the levels. For example, level 4 targets all ended with -only to indicate there were few dependencies being run. There are other solutions, though. Perhaps targets could have a level attribute and -projecthelp could take an optional numeric parameter to indicate the level you want to see. Someone building a module could run ant -p2 to find out which targets were available to them. A developer could run ant -p4. To make things more user-friendly, EasyAnt could define a standard set of levels and name them rather than using numbers. That is just one idea. Regardless, I think a more general solution would be better than treating target-groups in a special way, or even worse by adding target-parts to the mix. But then again, I may be missing something. Jean-Louis BOUDART wrote: I agree with Xavier a target-group is something at a higher level than a target. I think that the key feature of target-group is dependency injection but as Xavier says if thread-group is the only way to have target dependency injection, then people may use it only for that, and complain about the distinction in project help. The fact is target-group is not only a way to have dependency management, but a new way to think your build-script. I guess for us target-group is useful to make build modules easily reusable in a standard build (with standard target-group), without requiring any specific orchestration. This means target-group allow you to have a kind of generic target, that's why in EasyAnt we want to have separated help for generic targets (target-group) and specific target (normal target). In addition, as we use target-group to have more genericity we doesn't want to have prefix on those generic targets. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Re: target-group committed
On Wed, Nov 26, 2008 at 2:06 PM, Bruce Atherton [EMAIL PROTECTED] wrote: Or you could just live with the verbosity of the target list, like I did, and use naming conventions in EasyAnt. I'm sure there are many other ways to address the issue. One possible way would be to provide an in-build-file hook to intercept the -p switch, and this hook (I envision a target) would then be responsible to display the help. Couple that with a new configurable task to generate the -p output, and then it's up to the user to select (via some kind of include/exclude) whatever targets are going to be listed. My builds used to all have a help target which java'd back into Ant on the same build file with the -p switch added. It's the same idea, but exposing a builtin task instead, and allowing to run that target when -p is specified, if it's hooked via for example a project help-target=help. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
