Re: VOTE: add an antlib (and optional task) loader to ant 1.7
Peter Reilly wrote: Vote: yes this is a good thing for 1.7 [ ] no, let us stabilize 1.7[ X] Please let us get 1.7 first, Martijn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: add an antlib (and optional task) loader to ant 1.7
Peter Reilly wrote: yes this is a good thing for 1.7 [ ] no, let us stabilize 1.7[X] Looks promising - but take our time and put it in when it is ready. I agree with Steve McConnell that class loader mutation is not something we should encourage. If we have to do it for ant-*.jar optional bundled tasks for compatibility reasons, then OK, but it is unnecessary for nonbundled tasks which can be taskdef'd with a proper classpath, and we can probably do something cleaner for namespaced antlibs. -J. -- [EMAIL PROTECTED] x22801 netbeans.org ant.apache.org http://google.com/search?q=e%5E%28pi*i%29%2B1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: add an antlib (and optional task) loader to ant 1.7
Peter Reilly wrote: Sorry for asking for another vote on the Classloader for ant issue, but I think that the last vote was very half-hearted in slight support of including the (new) classloader task. However, I think that there was not enough support. In the meantime, I have been looking at Jesse's idea to have a secondary classloader that is used to load antlibs and optional tasks. I presented an initial implemention (see the classloader for 1.7 subject). Vote: yes this is a good thing for 1.7 [ ] no, let us stabilize 1.7[ X] I think right now I'm going to in the no category, though +0 rather than -1. This is not because I dont think its a good idea -I think it is wonderful- but I think the complications of adding it will add lots of surprises. Most importantly, it becomes really hard to uninvent once it has shipped. What we could do is take this as the opportunity to make a working 1.8 branch and put in in there, and post 1.7.0 think about adding it to the 1.7.x branch. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: add an antlib (and optional task) loader to ant 1.7
On Mon, 2006-09-04 at 20:25 +0100, Steve Loughran wrote: Peter Reilly wrote: Sorry for asking for another vote on the Classloader for ant issue, No problem. I think right now I'm going to in the no category, though +0 rather than -1. This is not because I dont think its a good idea -I think it is wonderful- but I think the complications of adding it will add lots of surprises. Most importantly, it becomes really hard to uninvent once it has shipped. I agree with Steve here. 1.7.0 has been 'just around the corner', for a while now, I'd rather not have any new additions that may require a quick 1.7.1 release (not that I think your idea + code is bad). I'm eager to try and get a cleaner integration of scripting into Ant and a new classloader-style mechanism seems a good way to approach that (I like the syntax in the example you posted), but right now I think it's more important to ship what we have. What we could do is take this as the opportunity to make a working 1.8 branch and put in in there, and post 1.7.0 think about adding it to the 1.7.x branch. +1 new branch for 1.8 and include code for experimental classloaders etc Thanks, Kev - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: add an antlib (and optional task) loader to ant 1.7
On Mon, 04 Sep 2006, Steve Loughran [EMAIL PROTECTED] wrote: Vote: yes this is a good thing for 1.7 [ ] no, let us stabilize 1.7[ X] I think right now I'm going to in the no category, though +0 rather than -1. This is not because I dont think its a good idea -I think it is wonderful- but I think the complications of adding it will add lots of surprises. Most importantly, it becomes really hard to uninvent once it has shipped. Same here. What we could do is take this as the opportunity to make a working 1.8 branch and put in in there, and post 1.7.0 think about adding it to the 1.7.x branch. Or rather create an 1.7.x branch and put the classloader into trunk. We are not required to let three years pass between 1.7.0 and 1.8.0. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VOTE: add an antlib (and optional task) loader to ant 1.7
On 9/4/06, Peter Reilly [EMAIL PROTECTED] wrote: yes this is a good thing for 1.7 [ ] no, let us stabilize 1.7[ ] +0, since didn't fully follow the ClassLoader discussion, so can't really yeah or nay this. Note though that I liked Jesse's idea of not loading tasks by default, and allow taskdef to specify which classpath to use. --DD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: VOTE: add an antlib (and optional task) loader to ant 1.7
-Original Message- From: Peter Reilly [mailto:[EMAIL PROTECTED] Vote: yes this is a good thing for 1.7 [ ] no, let us stabilize 1.7[ ] I'm a *non-binding* -1 on doing this relative to 1.7. This position is on the basis that I think that there is an fundamental flaw with the notion of classloader mutation (with the exception of system classloader mutation necessary in a small number of special cases). I think that Ant is moving in the right direction based on the separation of jar files dealing with individual optional task groups (e.g. Junit, Java Mail, Jdepend, etc.) - but I think that the direction forward should be discrete classloaders per extension. For example - the Java Mail task does not need nor is related to Junit testing concerns and both can co-exist is separate classloaders. Establishing a classloader specifically addressing a particular extension would eliminate potential conflict issues inherent in the current proposal and I believe its feasible to do this at the level of a the taskdef definition by adding classloader criteria to the antlib XML definition. In effect the classloading hierarchy should look more like the following: || | System CL | || ^ | || | Ant Project CL | (configurable to include custom project extensions) || ^ | | ... | | | || |-| |---| | Core Tasks CL | | Junit Antlib CL | | XYZ Antlib| || |-| |---| Where each antlib classloader is created based on XML data declaring new classloader creation criteria (i.e. no mutation in the general case) and where the taskdef task incorporates parallel/equivalent functionality. Cheers, Steve. -- Stephen McConnell mailto:[EMAIL PROTECTED] http://www.dpml.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
