xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edwin Goei <edwi...@sun.com>
Subject Re: [PROPOSAL-strawman] xml-commons source usage in other projects
Date Tue, 30 Oct 2001 23:12:08 GMT
Arved_37@chebucto.ns.ca wrote:
> Quoting Edwin Goei <edwingo@sun.com>:
> > Shane_Curcuru@lotus.com wrote:
> > >
> > > This is still a little rough, but I was hoping it would make sense to
> > > someone else who might help start making the appropriate Ant code to do
> > > it...  8-)
> > >
> > > As a first step towards using xml-commons sources in other xml.apache.org
> > > projects, here's a proposal that optionally uses the sources from
> > > xml-commons in your builds.  Xalan and Crimson have already implemented
> > > somewhat similar schemes but I'd like to go a step further.
> >
> > After more consideration, I think I've changed my mind on this issue.
> > Right now crimson automatically copies code from xml-commons whenever
> > crimson is built.  So it has a dependency on the xml-commons module to
> > build.  Now I think it's probably better to have a separate copy of the
> > code in each project and then sync the code at specific points.  Special
> > "sync" targets can be added to an Ant build file to make it easier.  So
> > I'd like to change the crimson build to do this, but I haven't gotten
> > around to it yet.
> Speaking from a sub-project viewpoint, it seems to me that what I need
> available, at any time, is a known snapshot of xml-commons, just as I want known
> versions of all other sources that I am dependent on. An Ant 'cvs' task might
> suffice.
> In other words, I should be expected to know that FOP 0.x requires a specific
> version of xml-commons, either by a tag or by date, whatever works. _FOP_
> configuration management should bear the responsibility of recording that
> information (which is easy enough to do in a build.xml file).
> I think I am missing some information you must have been considering when you
> decided to argue for 'sync' points, Edwin. I understand the requirement for
> grabbing known controlled versions, but not why they have to be local copies.

So one requirement is being able to recreate a distribution (Andy Clark
for one specifically mentioned this).  I agree with this.  When I
implemented the automatic copy of xml-commons code into crimson and
released a version of crimson, I tagged the code in xml-commons to
support this.  Ideally, xml-commons would have a particular release of
some external software like SAX2.0r2 or DOM L2 + errata thru a
particular date.  So one approach would be to tag xml-commons whenever
say Xerces2 is released.

Another possible requirement is to be able to build without having to
have a dependency on xml-commons.  The easiest way to achieve that would
be to check in a copy of the xml-commons code in each subproject
repository.  This would also solve the previous requirement.

So I think it's probably easiest to check in the common code in each
subproject repository.  Then before a release or when a bug needs to be
fixed in the common code, the fix can be synced up to the version in
xml-commons.  Ideally, the xml-commons code would correspond to a
particular version of the externally defined code, like SAX2.0r2.  Then
the sync could be done as needed.  An ant target could be added to make
this process easier.

Does this make sense?


In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org

View raw message