Indeed, the ASF is a meritocracy, and welcomes input from everyone, both
in the form of patches from everyone, as well as code checkins, once
someone becomes a committer on any project.
The issue here is validating that the patches submitted properly follow
the various XML-ish specs available.
I really thought I replied earlier! Yes, I would love to see a new
release of xml-commons-external. However, there are a couple of
questions we need answered. Anyone from the Xerces/Xalan teams want to
chime in with the info, since they've done much of the maintenance in
the past here?
- W
Sure, sounds fine. Please be sure to post your specific plan for
checking this stuff into the repository (exact directories, legal
issues, likely integration issues) to the list well before you actually
commit, so folks have chance to comment on it.
- These should be under /external in their
+1 from me as well, presuming that the Xerces-J/Xalan-J folks don't
object (since they directly rely on this code for their releases).
Thanks for starting the ball rolling!
- Shane
Excellent news! Thank to Sun folk and Geir for picking up the ball on
this one.
Note: once the papers are in the Hallowed Halls, I presume that Neeraj
will get some consensus from xml-commons, xalan-dev, and xerces-j-dev as
to how to actually check this in? I'm presuming you have someone with
Anyone? I thought Sun had a plan to donate the JAXP 1.3 sources to the
xml-commons project, but I haven't heard anything for quite a while.
Anyone at Sun have info in this area?
Being able to offer the latest version of JAXP is pretty important for
a wide variety of XML projects. 8-)
- Shane
A couple of comments:
- Please cc: [EMAIL PROTECTED], since xml-commons is the
actual repository that holds the JAXP code.
- Yay! Great progress all, both Xerces/Xalan folks for coordinating,
and Sun folks for getting the process unstuck. 8-)
- Both Elliotte's and Clay's questions below are imp
I presume you mean you want to use the Resolver with a JDK 1.2.2 version
(I'm guessing Sun's?)? I would think it should work, but haven't tested
it. I'll try to check resolver functionality later this week myself.
Note that as an all-volunteer organization, we don't often have a chance to
'ce
Anyone worked on getting a proven-TCK-passing version of our xml-apis
component so we can have a official versioned release of this that other
projects can incorporate?
Lacking that (I don't have the JAXP TCK setup myself), we should recommend
that other projects should just take the xml-apis.j
Since we've had a Resolver beta 1.1b1 out for a while now with no
complaints, as soon as I have time I plan to bump the version number to 1.1
and make an official release. I'll make sure there's both a Version class
available as well as sticking the version number in the jar manifest.
Any othe
Dear Antites:
Yes, the xml-commons team is working on getting an official relase of our
external component, xml-apis.jar, which would be suitable for using in your
1.6 release. (big thanks to Stefan for kicking me awake on this)
However, there are a number of issues including getting TCK compli
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The xml-commons team is pleased to announce a beta release of our
popular Resolver component version 1.1b1 (beta before a 1.1 release).
The release is available at
http://www.apache.org/dyn/closer.cgi/xml/commons/
Blurb
- -
Resolver
(http://xml.apa
Guys, you two ROCK! These look great.
David - I'd say +1 to going live anytime you have time. This is far better
than the cheesy structure I put on the website long ago. Any nits can be
picked at later. (For some reason, the nicely curved bottom border of the
search area has an extra square
Ooops! My bad since I meant to nominate someone and then got caught up
in too much other work lately.
+1 to running the vote on [EMAIL PROTECTED], since that is the mailing
list that the commons community should be living on.
+1 to announcing the vote on [EMAIL PROTECTED], since technically accor
Norm - although the forrestized docs aren't fully complete yet, we could
have another public resolver release whenever you're ready. Plenty of
people should have had a chance to test this by now.
- you Brian Smith <[EMAIL PROTECTED]> wrote -
> (a) the library defaults to logging things
Great! Sorry I'm so late with comments - you two are off to such a
good start, I was wondering if I had big comments!
-- BRANCH: Although originally I thought this code should go on the
HEAD, I agree with you now that it should be on the branch. I suggest
something like tck-jaxp-1-2_0 (arbitrari
Greetings from ApacheCon!
I've been mulling a number of things about xml-commons for a while and
figured I'd better let people know about them - sharing ideas can be a
good thing! (Thanks to ~crossley for prodding me to do this by
checking in a forrestized seed site which I'll beef up soon with m
Brian Smith <[EMAIL PROTECTED]>
> Right now it seems that the Resolver library is the only thing in
> XML-Commons CVS. But, what will happen when other code gets added to
> XML-Commons? Will all of the code get mixed together? In particular,
> will it be easy to check out _just_ the co
David Crossley <[EMAIL PROTECTED]>
> I envisaged a "common" home page and some top-level docs,
> then separate sections for each thing that is distributed.
Yup, we'll definitely need some overviews about the project as a whole,
and then separate sections for each distributable component
Wow, I was just about to redo xml-commons to be forrestized - although I
had planned to completely restructure it, since the README.html that I
created long ago kinds of sucks (I don't feel bad about writing that since
I wrote it in the first place...).
Basically, I need to write up my proposal
First off: why in the world are you using jaxp.jar? xml-apis.jar
should include everything you need for JAXP/DOM/SAX inside it, albeit
of possibly slightly different versions than an official jaxp.jar that
you get from a Sun distribution.
Also, I have had problems in the past when the .jars that
Please use the [EMAIL PROTECTED] mailing list for any
questions about the XmlResolver, so that the rest of the community can
see it as well.
That's a good question though: Since xml-commons may produce several
small .jar or other resource files that folks may want to conveniently
reference, what i
By request and as an experiment to try new packaging, I've posted a 1.0
release of the XmlResolver component of xml-commons. This release
includes just Norman Walsh's org.apache.xml.resolver package, which
implements a number of useful XML catalog resolving features.
You can download the releas
Paul Libbrecht <[EMAIL PROTECTED]>
> I think it is immensely important for anyone receiving these APIs to
be
aware of:
> - the license for each (among others, the, possibly limited, rights
to
redistribute)
> - cleanly defined authorship and origin
I agree; I thought they were pretty clea
I'll see what I can do tomorrow; I've known we needed to be able to
ship each part of xml-commons separately at some point. I'm wondering
what version number I should call resolver?
=
- Shane
__
Do you Yahoo!?
HotJobs - Search new jobs daily
If ya wanna talk turkey about xml-apis.jar, then come over to the
[EMAIL PROTECTED] list. But general answers follow:
- xml-apis.jar should always have the full DOM/SAX/JAXP set in it. The
specific versions of these files may change; in the near future we hope
to have one that is TCK-compatible
Thanks for the commentary Gary - at least someone else is reading this
list!
Um, I'm still thinking in a background process... Classloaders and the
rest of my job are taking priority right now.
Hmmm - the survey idea is an excellent one, except: getting the time to
do it. Volunteers, anyone? 8-
Here's a starting proposal for better version management of the
standards-based files in xml-commons' external directory. Although I've
passed these ideas by a few Xerces and Xalan folks, we need community
feedback on this issue.
Actively manage and document the file versioning strategy for
xml
In principle, moving org.w3c.css and org.w3c.dom.svg to xml-commons
would make sense. In practice, we still need to get a little more
definition to the split between the external half of xml-commons
(standards files) and the internal half (Which, Resolver). We also
need clarity on versioning of t
Did you try any other variations on the exact URL for the file? I think to
be a legal absolute file: URL you need at least two slashes separating the
scheme file:// from the path portion (or three, I always forget).
- Shane
Here's a brief report on what the xml-commons project has done to
address potential licensing issues brought up recently.
The xml-commons project is a little unusual in that it contains a
variety of different items, including code sourced from several
locations. Hopefully we've made it obvious to
I'm happy to announce the second 'preview' release of the xml-commons
project. Updates since our first 1.0.b1 preview release include:
- NEW! Norman Walsh's entity resolver utility, recently donated to the
xml-commons project. Docs are in the distro, not yet on the website.
- Licensing: separat
Actually, I was hoping to post another quick beta build of xml-commons
that included a license for exporting. Then I was planning on checking
this license into xml-xalan's repository to match. That way projects
that use xml-commons don't have to search for a license to use; they'll
just checkin t
(sorry, my webmail sent this before completing the last couple of
paragraphs)
Here's a report on the licensing status of files in the xml-commons
project repository currently. If anyone has any questions about this
topic, please raise them now; this is also notice for the [EMAIL PROTECTED] of
wha
Here's a report on the licensing status of files in the xml-commons
project repository currently. If anyone has any questions about this
topic, please raise them now; this is also notice for the [EMAIL PROTECTED] of
what the xml-commons project has done to ensure clear license for all
our files.
Action Item:
- Edwin - since you're the JAXP guy, can you do this for the javax.*
packages?
Status:
- Shane has checked in good-faith-layperson README.*.txt and
LICENSE.*.txt files for the Apache, SAX, and DOM portions of
xml-commons as they exist today.
- Do we still need to cc: the PMC with th
Sorry for the noise, but my work email account @us.ibm.com/@lotus.com
will be down for at least the next two days, so if you have any urgent
Xalan issues for me, please send them to this @yahoo.com address
directly.
(I wouldn't normally bother everyone, but we're urgently working on a
couple of bu
One important question about the resolver: what dependencies does it
have? I'm presuming that it will only depend on JDK 1.2 and other code
in xml-commons, and not have other external dependencies. Correct?
you Norman Walsh <[EMAIL PROTECTED]> wrote
> Some time ago, Stefano started a t
edwingo wrote
> BTW, the JAXP code in xml-commons by itself in a sense does not have
a
> version number. See
> http://xml.apache.org/~edwingo/jaxp-faq.html#versioning for more
info.
Yeah, I kind of knew that but I wanted to identify the code in the
release *somehow*. I mainly wanted to
you Guillaume Rousse <[EMAIL PROTECTED]> wrote
> A perfect exemple: why is xml-api code from xml-commons stored into a
module
> named java/external ? Apart after careful examination of classes
files found
> three directories later in src/javax/xml, how can someone deduce he
has found
> wa
you Jeff Turner <[EMAIL PROTECTED]> wrote
[jt]>> What needs to change? Do you see something specific? This
paragraph from xml-commons/README.html:
> New modules generally shouldn't go in until at least two separate
> other projects express interest in using the module. I think this is
41 matches
Mail list logo
