[EMAIL PROTECTED] writes: > Hi Paul, > > The lisp function would need to: > > find the build.xml file >
Can you send me an example of a real build.xml file with its associated entity files for using in testing? - Paul > parse any entity declarations, including references to external files. > Example: > > <?xml version="1.0"?> > <!DOCTYPE project [ > <!ENTITY properties SYSTEM "file:../properties.xml"> > <!ENTITY tasks SYSTEM "file:../tasks.xml"> > ]> > <projects> > <task name="init"> > <!-- module specific properties set here --> > &properties; > </task> > > &tasks; > </projects> > > > expand those entities in the remainder of the build.xml wherever they > appear. > > Return the value of the "name" attribute for every element of type "target" > from this pre-processed parse tree. Those values are what is used in tab > completion when doing jde builds with ant. > > Cheers, > Eric > > -----Original Message----- > From: Paul Kinnucan [mailto:[EMAIL PROTECTED] > Sent: Monday, July 14, 2003 2:28 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: Getting jde and ant to play nicely. > > > [EMAIL PROTECTED] writes: > > There is, alas, a limit to how far one can get with the currently > approach > > to parsing Ant build files in JDE. For my project, I've got several > > components, each of which has its own build files. These build files all > > have a number of targets in common along with a number of common > properties. > > > > The standard way to share XML markup chunks of this kind is to push them > out > > into separate files and then define external entities for them in the > > document type declaration. The entities are then included in the parse > tree > > by reference: &tasks; &properties; and so on. > > > > To make a short story long, this means that the parser needs to > understand > > this feature of XML and that it needs to look in external places for task > > definitions. Obviously the regexp used by jde-ant on the single > 'build.xml' > > buffer is not up to the task. I don't know whether psgml could handle > this > > or not, but the upshot is that it makes target completion in jde non > > functional. This is not a big deal as I just write lisp code to call > > jde-ant-build with the target names "directly" and everything is fine. > > > > Hi Eric, > > I believe psgml knows how to resolve external entities. Alternatively, > it would be no big deal to include a Java-based parser (e.g., Xerces) > in the JDEE distribution (it's just another jar file) and have the > Beanshell invoke it to extract info from Ant build files. > > I'm currently developing a Java app that uses Xerces to extract information > from complex XML files so I could help someone who knows Ant to solve the > problem you describe. I don't know Ant so someone would have to tell > me "I need a Lisp function that, given an Ant build file, returns the > following > info." I could then write a Lisp function to invoke Xerces via the BeanShell > to get the info. > > > - Paul > > > > Eric > > > > -----Original Message----- > > From: Paul Kinnucan [mailto:[EMAIL PROTECTED] > > Sent: Monday, July 14, 2003 2:11 PM > > To: [EMAIL PROTECTED] > > Cc: [EMAIL PROTECTED] > > Subject: Getting jde and ant to play nicely. > > > > > > Sean Ross writes: > > > > > > Hi all, > > > > > > I'm busy struggling to get ant and jde to cooperate. > > > Our build files currently use the ant filter tag to > > > replace @SHORTNAME@ with our package names (which are horribly long), > > > the downside is that this confuses the heck out of semantic and > > > friends ie. wrecking various wonderful beanshell utils. > > > > > > I was wondering if anyone knows of a fix for this? > > > > > > > One approach might be to define a file load hook function > > that would replace the tag with its expansion whenever > > one of your files is loaded into an Emacs buffer and a file save > > hook function that would perform the inverse operation when you > > save a file. > > > > - Paul
