I'm all for anything that will help speedup the startup. For the eclipse issue, you could grab the URL objects of the .xml and .fixml and do url.openConnection().getLastModified() to see if the .xml is newer. I think that should work.
Alternatively, it COULD be done post jar. The mojo could act on the jar itself examining it for the xmls and adding the fixml things. Thus, it would have no impact on running in eclipse. Dan On Friday 21 March 2008, Benson Margulies wrote: > We could get another very visible speedup out of the time it takes to > initialize the bus with Spring. Since the predominant cost is still > XML reading, even with WoodStox, any reduction in this process can be > very visible. I posted the raw comparison of WoodStox and FI > yesterday. > > Before I go here (and, arguably, I should hold this horse until after > 2.1), I want to make sure that folks appreciate the implications. > > It would work as follows, I think. > > 1) we'd add an mvn mojo to 'compile' XML files to FI blobs. > 2) I've already given us a customized subclass of Spring's XML reading > class. I propose to make it work as follows: when asked to read an XML > file, it will look to see if there is a file with '.xml' replaced by > '.fixml' in the same place. If it's there, it will load it > preferentially. > > This has the potential to make life a bit interesting in eclipse. > Developers modifying the .xml files will need to run mvn -Pfastinstall > to recompile in order to see their changes, unless I include (e.g.) a > system property to turn off this mechanism. I confess that I don't > have much enthusiasm for trying to make eclipse keep up. > > Also note that none of this is any help to users who make their own > application context and start including our files unless we document > for them how to use our reader in preference to the stock Spring > reader. We might feel that 'ControlledValidationXmlWhateverICalledIt' > is not the right class name if we are going to advertise this. *That* > might be a change that wants to be made for 2.1. > > Anyway, this is potentially disruptive/strange enough that I have no > interest in tacking it without some evidence of consensus or > disinterest. -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
