Re: Donation of JAXP 1.3 Sources to Apache (xml-apis version)

[sh...@us.ibm.com]

-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 <mc...@ca.ibm.com> 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
>