---- you Andy Clark <[EMAIL PROTECTED]> wrote ---- > I will say again that I don't think automatically pulling the > latest copies of things from xml-commons in the build is the > right thing to do. Yes, projects should take every effort to > stay up to date with the commons packages but it should not be > a required part of the build process.
I can definitely see your point and I'm not trying to be combative, but I do want to analyze our different project's takes on the general xml-commons issue. Fundamentally the choice is up to the community for each xml.apache subproject. But having a common way to do this might be a benefit to all of our subprojects. We might also think about 'publishing' builds of xml-commons as a convenient way for any users to get a known set of SAX/DOM/JAXP classes - something several people have asked me about recently. Hmmm. OK, to help start more of a discussion: - What specifically don't you like about attempting to pull in xml-commons sources to [project 'x']'s build? Risk - to your project's daily build due to unexpected changes? Inter-project dependencies - in that this is also a risk and a coordination issue with all projects that use xml-commons directly? Extra work - in that you may need to checkout xml-commons along with your own codebase? Other? Also, I've setup Xalan's build to work without xml-commons. It's about half-way to my goal for how I want Xalan's build to work: - Committers who checkout xml-xalan run a build: - if xml-commons exists next to xml-xalan, copy and use it's sources - if it doesn't, use the sources in xml-xalan and post a warning - Users who download a dist module run a build: - here, we'd probably want to just use the files that came from the dist, so users don't need to know or bother about external files (unless they want to) - Shane --------------------------------------------------------------------- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
