Has anyone considered the possibility of making ant be a bunch of mbeans running in a jmx server? I can't say I've thought it through, however it would provide quite a few features similar to many things being discussed here. For instance, mlets provide an extensible classloader.
david jencks On 2002.02.11 07:27:47 -0500 Erik Hatcher wrote: > Just a few off the top of my head: > > - Property immutability holes! :) > > - Fileset restrictions - all files must be under a directory root, so its > a > very limited view of a file "set" and often leads to some strange > constructs. I'm planning on making a change eventually to allow a single > file fileset to be specified with a path and no 'dir' - but I don't see a > way to make it more generic in Ant 1.x without breaking something because > of > the way DirectoryScanner is used and such. Thoughts? > > - Classpath issues that require JAR's to be in system classpath. For > example, junit.jar. Is there a way to solve this so the classpath can > literally be empty and internal to the build file a reference to > junit.jar's > location is specified? I've got no classloader experience so I haven't a > clue. This leads to the next one... > > - Drop-in tasks - being able to extend Ant's capabilities more easily > > - Flexible element/attribute naming so that a task can be extended with > more > natural constructs without requiring the code be modified: > <ejbjar>/<jonas> > for example. Sure, <vendor classname="org.....jonas...."> could be used, > but thats clunky, especially when it comes to dealing with attribute > names > that should be more descriptive than <var name="someProperty" value=""/>. > > How's that for a start?! :) > > Erik > > > ----- Original Message ----- > From: "Peter Donald" <[EMAIL PROTECTED]> > To: "Ant Developers List" <[EMAIL PROTECTED]> > Sent: Monday, February 11, 2002 3:28 AM > Subject: Re: TryCatchFinallyTask - thoughts and possible syntax > > > > On Mon, 11 Feb 2002 09:14, Bevan Arps wrote: > > > At 20:25 10/02/2002 +1100, Peter Donald wrote: > > > >Error handling in ant sucks ... > > > > > > I agree 100% > > > > As a side issue. Would everyone mind describing what they think are the > worst > > features of ant are? I can think of 4 things that bug me no end (error > > handling is one of them) - anyone else care to generate a list? I would > be > > interested to here it. My list basically is > > > > * error handling sucks > > * missing selection (if) constructs (others may add missing repetition > > constructs) > > * PITA to create reusable build file chunks > > * PITA to extend and manage extensions, dependencies and so forth > > > > > Peters Example to explain: > > > ><tbody> > > > > <try> > > > > <echo message="About to fail"/> > > > > <fail message="Failing!"/> > > > > </try> > > > > <catch> > > > > <echo message="the task failed but we are ignoring it"/> > > > > </catch> > > > > <finally> > > > > <echo message="Cleaning up after myself ..."/> > > > > </finally> > > > ></tbody> > > > > > > When does the finally task get executed - before the catch or after? > > > > after - same as in java language. > > > > > For the first, how about this: > > > > > > <try> > > > <echo message="About to make a mess"/> > > > ... > > > <finally> > > > <echo message="Cleaning up mess"/> > > > .... > > > </finally> > > > </try> > > > > > > For the second case, and keeping in mind that the Ant term is "fail": > > > > > > <try> > > > <echo message="About to fail"/> > > > ... > > > <onFail> > > > <echo message="It failed."/> > > > </onFail> > > > </try> > > > > > ... > > > Just my 2c - what do you think? > > > > Interesting - I am going to play with a few build files and see what it > looks > > like ;) > > > > -- > > Cheers, > > > > Pete > > > > ---------------------------------------- > > Whatever you do will be insignificant, > > but it is very important that you do it. > > --Gandhi > > ---------------------------------------- > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
