-0 to including version number in the xml-apis.jar filename, unless someone can show it will actually make sense to most people. Hmmm. But what about including a versioned name, only for use by other projects that already include their whole mess of dependent jars in their default installs? It's tough figuring out the best deployment strategy when we should ensure that both power users who pull components individually can work, as well as downstream projects that include us can work.
I haven't looked at code in far too long, although I originally wrote the xml-commons build scripts. A couple of random notes: -- Versions should be stored only in build.xml files. Each component's build should put the version number in a Version class, in the jar's manifest, and the version number is hard coded into the .zip/.tar/gz distros. -- HEAD or the commonly-used tck-* branch? I'm not sure if we've been good at pushing changes - esp. to builds - back and forth between these two. -- xml-commons builds both the Resolver and Which components, as well as the external components in xml-apis.jar in separate build files. In theory, I wanted the whole project build file to be able to call all the other build files and have it 'just work'. But that, perhaps, is not as important as ensuring the individual components work. For example: at one point, I thought we could have an xml-commons 'release' that included everything - each separately versioned somehow - but I don't think this really works very well. -- I planned to have the xml-xalan build simply call out to the xml-commons / external build.xml and build the sources inline that way. I don't know if this is still true, or if xalan simply assumes a prebuilt xml-apis.jar is already there. -- GUMP! Remember, xml-commons is at the bottom of the dependency chain, so remember that lots of projects may fail using the latest gump if xml-commons fails. (hey, do we have something like -stable and -current GUMPs running or something? - Shane Sarah McNamara <[EMAIL PROTECTED]> wrote on 10/15/2004 11:12:44 AM: > David Crossley wrote: > >One thing that we must have this time around, is a > >version number on the xml-apis.jar filename. [1] > >I suppose that is an Xml-commons "build" issue. > >By the way, that build system is seriously in need > >of improvement, but it gets us by. > > A version number 'on' the jar filename? Are you suggesting something like > xml-apis.1.3.xx.jar ? > > I'm not a big fan of having a version number 'on' the jar filename itself > since this causes maintenance issues for scripts and automated tools and > for users it requires changes to environment configurations, etc. > > I agree we need a mechanism to identify different versions of an > xml-apis.jar, but would prefer to see a versioning scheme worked out such > that we can incorporate a Version class in the jar, version information in > the jar's manifest, and a release distribution package (source, or binary, > or both) that contains a version number on the package. > > These changes were done on the tck-jaxp-1_2_0 branch in xml-commons. Would > something like this meet your requirements and be acceptable on the main > branch? > > > Sarah McNamara >
smime.p7s
Description: S/MIME Cryptographic Signature
