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: CoreLoader not used for antlib typedef [Re: Launching unit test of antunit]
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 - 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-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? 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. 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. For your concrete patches I'll need more time to review before I comment. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
