Re: Task for Reading POMs
Brett Porter wrote: This probably isn't going to be as easy as you hope - for instance POMs often rely on property interpolation and inheritence of other files. Which is why I'm extending XmlProperty. XmlProperty provides the property interpolation (with semanticAttributes turned on) and by extending it, my custom task can handle inheritance. But I'd be open to other methods of reading a POM, including... Is there any reason not to use org.apache.maven.MavenUtils? Good question (though perhaps better suited for Maven's developer list). In a perfect world, I'd love to use the same classes that Maven uses for reading in POMs. In that same vein, I'd love to see Java tool makers standardize on a schema for project descriptors, so you could have one POM that Eclipse, JBuilder, Java Studio Creator, Ant, Maven, and [insert your favorite IDE/project/build tool here] would know how to read. But... Those classes are currently bundled up into the Maven JAR, and there's a high degree of dependency on other Maven-specific classes. I ran into this while writing Ant tasks that wrapped around Maven's dependency verifier and the artifact plugin. Looking at MavenUtils code, it appeared to be the same situation (correct me if I'm wrong). I'd jump all over using those classes if they were separated out into a sort of jPOM project :-) with a generic API for reading/writing a standard POM and a lightweight, non-Maven-specific, library-type JAR. I think that would also make a standardized POM much more attractive to Java tool developers. Am I out in left field here, or does that sound reasonable? Kyle _ Kyle Adams | Java Developer | Gordon Food Service | 616-717-6162 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Task for Reading POMs
Brett Porter wrote: I think that's what JAM does. Don't know the URL off the top of my head. The URL is http://www.javagen.com/jam.jsp and I'm actually working on this task in relation to JAM :-) JAM can't directly read a POM; rather there are Maven plugins provided as part of JAM that allow you to generate JAM-specific config files from a POM. In the interest of tighter integration with Maven, I'd like to create an Ant task that could read the POM directly and bypass the keep JAM config files in sync with POM step. I've been looking around XmlProperty and noticed a bit of oddness when it comes to the visibility of the methods. Some, like addNodeRecursively(Node, String, Object) are private. Then addNodeRecusively calls processNode(Node, String, Object), which is public. Finally, addNodeRecursively(Node, String) uses the default package visibility. It would be nice (from my perspective) if all of the methods above were protected, making it easy for me to extend XmlProperty and create a PomProperty task. Is there a ryhme or reason for their existing visibilities that I'm missing? Kyle _ Kyle Adams | Java Developer | Gordon Food Service | 616-717-6162 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Task for Reading POMs
Before I go re-inventing the wheel, I wanted to check and see if anyone else was working/had worked on scratching the same itch: I'd like to be able to utilize Maven's POM for describing a project; XmlProperty gets me most of the way there, but there are a few things (like imported POMs) that it doesn't handle. Consequently I'd like the write a PomProperty (probably extending XmlProperty) to handle these extra bits of functionality. Thanks, Kyle _ Kyle Adams | Java Developer | Gordon Food Service | 616-717-6162 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML, XSL, and Ant
Kyle should receive an updated jar any time now. Indeed I did (though it took awhile before I un-busied enough to test it). And indeed it works quite nicely, for both resolving entities in a stylesheet, and resolving entities/dtds in anything xsl:import'ed, xsl:includ'ed and document()'ed. Nice fix! Kyle _ Kyle Adams | Java Developer | Gordon Food Service | 616-717-6162 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XML, XSL, and Ant
We should be able to change this if SAXSource is supported, I'll take a stab at it - but I will need testers before I'm willing to merge my changes into the 1.6 branch. If I'd send you a changed ant-trax.jar, could you test it in your Ant 1.6beta environment? No problem - I've got a simple test case already setup that's currently failing, so I'm all set for testing :-) Kyle _ Kyle Adams | Java Developer | Gordon Food Service | 616-717-6162 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
XML, XSL, and Ant
This is an extension of a thread that originally began in users (http://marc.theaimsgroup.com/?t=10667642568r=1w=2), but is moving more towards a dev-type discussion. I've noticed some odd behaviors in how style utilizes xmlcatalog - I'm not sure if they're bugs, or just the way things work. 1) xmlcatalog only applies to source XML document - if there are entities/dtds in the stylesheet, these can't be resolved by xmlcatalog. Confirmed on Ant 1.5.3/Xalan 2.2, D11/Xerces 2.3.0 and Ant 1.6, B2/Xalan 2.5.1/Xerces 2.5.0/10-22-2003 snapshot of commons-resolver. 2) Any XML documents accessed via the document() function in the XSL will not have their entities/dtds resolved. Confirmed on Ant 1.5.3/Xalan 2.2, D11/Xerces 2.3.0 Are these just the way things are with resolvers, or should the resolver be catching entities/dtds in the XSL and/or any XML documents validated during a transformation? Thanks, Kyle _ Kyle Adams | Java Developer | Gordon Food Service | 616-717-6162 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Adding support for XMLCatalog in EjbJar
I've taken a first stab at adding support for nested xmlcatalog elements within ejbjar, but I'm running into some problems I thought I'd run by the list. First glance, it appeared pretty easy. Add a few methods and insert the following bit of code in the execute method: if (xmlCatalog != null) { saxParser.getXMLReader().setEntityResolver(xmlCatalog); } Since saxParser gets passed into the various vendor-specific deployment tool classes, I thought that would do the trick. But it's not (why would I be writing this otherwise :-) ?). The problem is that I'm not familiar enough with SAX; previous hacking involved adding XMLCatalog support to tasks that used DOM. Also, I'm not intimately familiar with the inner workings of the org.apache.tools.ant.taskdefs.optional.ejb.* classes. So I thought I'd throw this out there and see if I'm doing something stupid/easily fixed. Diff included below for full disclosure. Thanks, Kyle === --- EjbJar.java.old 2003-05-21 16:54:44.0 -0400 +++ EjbJar.java 2003-05-21 16:52:50.0 -0400 @@ -74,6 +74,7 @@ import org.apache.tools.ant.types.Path; import org.apache.tools.ant.types.EnumeratedAttribute; import org.apache.tools.ant.types.FileSet; +import org.apache.tools.ant.types.XMLCatalog; /** * Provides automated EJB JAR file creation. @@ -226,6 +227,18 @@ /** The list of deployment tools we are going to run. */ private ArrayList deploymentTools = new ArrayList(); +/** for resolving entities such as dtds */ +private XMLCatalog xmlCatalog = new XMLCatalog(); + + +/** + * Add the catalog to our internal catalog + * + * @param xmlCatalog the XMLCatalog instance to use to look up DTDs + */ +public void addConfiguredXMLCatalog(XMLCatalog xmlCatalog) { +this.xmlCatalog.addConfiguredXMLCatalog(xmlCatalog); +} /** * Add a deployment tool to the list of deployment tools that will be @@ -538,6 +551,14 @@ } /** + * Initialize internal instance of XMLCatalog + */ +public void init() throws BuildException { +super.init(); +xmlCatalog.setProject(getProject()); +} + +/** * Invoked by Ant after the task is prepared, when it is ready to execute * this task. * @@ -574,6 +595,9 @@ SAXParserFactory saxParserFactory = SAXParserFactory.newInstance(); saxParserFactory.setValidating(true); SAXParser saxParser = saxParserFactory.newSAXParser(); +if (xmlCatalog != null) { + saxParser.getXMLReader().setEntityResolver(xmlCatalog); +} DirectoryScanner ds = getDirectoryScanner(config.descriptorDir); ds.scan();
Re: J2EE Deployment Models
Gah - this really was supposed to go to the ant users mailing list. My apologies; I just set my mind on autopilot. Resending... now. Kyle
J2EE Deployment Models
This is not an Ant-specific question, but I'm not aware of any general build/deploy/promotion practices e-mail lists, and this is the closest thing to that. If someone does know of such a list/newsgroup, let me know and I redirect my query as appropriate. Our current deployment for J2EE apps is to use an EAR. Inside the EAR's base directory, we have a lib directory, which contains JARs that the EJB JARs may reference in their Class-Path entry (ie, fop.jar, log4j.jar, etc.). Also within the base directory are all the WARs and EJB JARs that make up the EAR. We have a third party source providing us with an EAR that uses a radically different deployment model, and I'd be curious to hear opinions and thoughts on it. Within the EAR the application is split up into three different groupings: presentation, common, and service tiers. Each group is a JAR file, containing within it whatever EJB JARs or WARs fall within that logical grouping. So there are 3 layers of packging that occur - the EJBs and WARs get wrapped up into a generic JAR by group, and then the 3 groups composing the application get wrapped up into an EAR. As build manager and deployer, our build, deploy, and promotion processes (and by that, I mean the automated scripts, including Ant files) would face signifigant change to support this new model. I also have concerns about how standard or non-standard this type of deployment model is. We really try to stick close to the specs for J2EE and avoid anything that ties us to non-standard practices, or vendor lock-in. Thoughts? Thanks, Kyle Adams Developer, Gordon Food Service
XLTC task?
Just checking before I re-invent the wheel - is anyone else aware of an Ant task for compiling XSL stylesheets into translets? Kyle A.