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]
